技能介绍

要解决的问题

在多人协作的工程环境里，文档经常是「写完就死」的。一份 RFC 如果只罗列了背景和方案，却没有交代约束、假设和被否决的选项，后来者很难判断当时的决策依据；一份技术方案如果忽略了读者的验收标准，评审会上就容易陷入「这段到底想说明什么」的争论。更常见的是，作者把未经核实的传闻当成事实写进文档，等到实施阶段才发现前提是错的。这类问题的根源不是文笔，而是缺少一套把输入拆成可追溯证据的工作流。

核心能力与工作步骤

这个技能把写作当成一个连续的协商过程，而不是一次性的润色。它会先和你对齐写作契约，确认文档类型、主要和次要读者、需要促成的决策或行动，以及格式、篇幅、截止时间和审批限制。只有那些会真正改变文档形态的问题才会被提出来，你可以用简短的备忘或者零散的上下文直接回答。

随后，技能会建立一张证据地图，把输入分成六类：已核实事实、决策、约束、假设、悬而未决的问题，以及观点。已核实的事实可以直接陈述并给出来源；决策需要记录提出人、理由和后果；约束要说明它对备选方案的影响；假设则必须显式标注，并说明需要怎样验证。如果输入里引用了文件或资料，技能会实际去读取，而不是凭空推断。

证据整理完成后，技能会先给出一份符合文档目的的结构草案，并解释那些非显而易见的排序逻辑。对已有文档，它会保留仍然有用的骨架，只提出针对性修改，而不是推倒重写。进入起草阶段后，技能优先处理信息密度最高的章节，保持术语一致，把模糊的词汇定义一次，并用具体的例子和判定标准替代空泛的表述。未证实的证据会在正文里用 待确认 之类的标记内联提示，悬而未决的重大决策则单独跟踪，避免被淹没在段落之间。

初稿成型后，技能会执行一次读者测试：预测新读者拿到文档时会提出的问题，逐条检查文档能否在没有对话上下文的情况下回答这些问题，然后找出含糊的指代、未定义的术语、隐藏的假设和缺乏支撑的结论。如果手边有可以调用的独立 agent，技能会把文档和读者问题交给这个 agent 做冷读，避免把预期答案泄露给对方；否则就基于文档文本自行冷读。重复这个循环直到不再出现实质性的阅读障碍。

适用边界与注意点

这个技能适合需要说服读者采取行动的文档，包括提案、RFC、技术方案、战略规划和跨团队计划。它解决的是论证结构和证据透明的问题，不负责替代领域知识。你仍然需要提供足够的业务上下文和技术细节，技能不会凭空补全缺失的工程判断。

如果需求集中在产品文档体系、API 参考或技术教程，技能本身会把这些任务路由到对应的专项技能上。当作为主要挑战的并不是读者契约、论证结构或冷读测试，而是文档类型本身的专业规范时，最好直接使用对应的专项技能。技能不会声称自己拥有当前环境中不存在的集成权限或数据访问能力，所有引用文件必须真实存在于工作目录中。