问题：你的文档并没有真正起作用
你花了数小时撰写技术规格书、提案或决策文档。你包含了所有必要信息，遵循了模板，也检查了拼写错误。然而，当你的同事阅读时，他们带着困惑的问题回来，错过了关键点，或者基于误解做出了决定。你原以为清晰的文档，在实践中却未能实现其主要目的：有效沟通。
这是技术和协作工作中的一个常见痛点。写作者所知与文档所传达内容之间的差距，往往对写作者自己是不可见的。你拥有所有背景信息——之前的讨论、技术限制、组织内部情况。然而，你的读者却是从零开始。没有这些背景，你精心组织的文档可能就像一个缺少了关键拼图的谜题。
其后果是真实的：在澄清会议上浪费时间、团队目标不一致、以及基于不完整信息做出的决策。一个好的解决方案需要系统地弥合这种背景差距。它应该迫使写作者阐明假设，从读者的角度测试文档，并反复修改，直到信息对没有内部知识的人来说也是清晰的。
介绍一种结构化的协作写作流程
解决这个问题的一个实用方法是采用结构化的协作写作流程，例如 doc-coauthoring 技能 中描述的流程。这不是一个为你代笔的魔法工具，而是一个引导过程，帮助你作为写作者，与 AI 助手一步步合作构建更好的文档。
其核心思想是将文档创建视为一个三阶段的协作：首先，收集你所有的原始背景；其次，通过迭代来优化和构建内容；最后，用一个“新读者”（即没有先前背景知识的 AI）来测试草稿，以发现盲点。这种方法旨在将隐含的信息显性化，并确保最终文档对目标受众有效。
该流程如何解决核心问题
该流程通过将背景转移作为一个刻意的第一步，直接解决了背景差距问题。你不是直接开始写作，而是首先倾倒所有相关信息——背景、限制、相关讨论，甚至是组织层面的细微差别。然后，AI 助手会提出澄清性问题以填补空白，确保在开始起草之前拥有坚实的基础。
这个过程迫使你阐明那些你可能认为理所当然的事情。例如，在撰写技术规格书时，你可能假设每个人都知道为什么某个遗留系统是一个限制。澄清性问题会揭示这个假设，促使你在文档中对此进行解释。仅此一点就能防止许多误解。
迭代优化阶段逐节构建文档，包含头脑风暴和编辑循环。这避免了试图一次性写出完美草稿的常见错误。相反，你通过讨论来完善每个部分，确保每一节在进入下一节之前都是扎实的。最后的读者测试至关重要：AI 扮演一个天真的读者，在没有你提供的任何背景的情况下审查文档。如果它能理解文档并回答相关问题，那么你的真实读者也很有可能做到。
何时应考虑使用这种方法？
这种结构化流程特别适用于：
- 高风险文档：决策文档、RFC、技术规格书或项目提案，其中误解会带来重大后果。
- 面向多样化受众的文档：当你的读者来自不同团队（例如工程、产品、法务），他们可能不具备你的技术背景时。
- 复杂主题：当主题涉及许多相互关联的部分、权衡取舍或不明显的历史背景时。
- 当你“过于沉浸”于材料时：如果你已经在一个项目上投入了数周时间，这个过程可以帮助你退后一步，用新的视角看待文档。
对于简单的内部笔记，或者受众与你拥有完全相同背景且风险较低的文档，可能就不那么必要了。
评估该技能是否适合你的工作流程
在决定是否使用 doc-coauthoring 技能 之前，请考虑以下几点：
它的优势所在
- 结构化指导：它提供了一个清晰、可重复的过程，如果你经常苦于不知从何开始或如何组织思路，这会很有帮助。
- 背景管理：明确关注前期收集和澄清背景，是其解决读者理解问题的最强特性。
- 读者测试：让 AI 扮演天真读者进行最后审查，是模拟真实世界阅读条件的一种实用方法。
能力边界与最佳用例
- 它是一个流程，而非写手：该技能引导你进行写作。它不会根据一行提示就生成一份完整、精炼的文档。你需要是一个积极的参与者。
- 最适合结构化文档：它专为具有清晰章节和目的的文档（规格书、提案、决策文档）而设计。它不太适合创意写作、营销文案或纯粹叙事性的内容。
- 依赖于你的输入质量：输出质量直接取决于你提供的背景信息。输入的是垃圾，输出的也是垃圾。你需要愿意彻底地进行最初的“信息倾倒”。
何时不应使用它
- 用于快速、简单的文档：如果你只需要一封简短的邮件或一个简要的更新，三阶段流程就显得过于繁琐了。
- 当你没有时间进行迭代时：该流程本质上是迭代的。如果你需要在 30 分钟内完成一份文档，这个过程会让你觉得太慢。
- 如果你更喜欢完全自主：有些写作者觉得结构化流程是一种束缚。如果你在自由形式、意识流的方式下工作得最好，这可能不适合你。
使用前需要检查什么
如果你考虑将此流程整合到你的工作中，以下是一些需要实际检查的事项：
- 理解触发条件：该技能设计为在你提到撰写文档、提案、规格书等时激活。开始时请明确你的意图。
- 为背景倾倒做准备：准备好你的背景信息。这包括共享文档的链接、会议笔记、技术图表以及任何相关的团队讨论。你前期提供的信息越多，指导就越好。
- 检查集成可能性：该流程可以利用集成（如 Slack、Google Drive 或 SharePoint）直接拉取背景信息。检查你的环境是否支持这些。如果不支持，请准备好手动粘贴内容。
- 承诺遵循各阶段：该流程在你按顺序遵循三个阶段时效果最好。例如，跳过读者测试就违背了该流程的一个关键目的。
- 查看代码仓库：该技能是 anthropics/skills 代码仓库 的一部分。你可以检查源代码以详细了解该流程的逻辑。该仓库拥有大量星标，表明了社区的兴趣，但务必自行审查代码和许可证（如果有的话）以确保符合你的合规要求。
一个实际例子：撰写技术规格书
假设你正在为一个新的 API 撰写技术规格书。如果没有结构化流程，你可能会直接开始设计端点。使用协作写作流程：
- 背景收集：你会从业务目标、现有系统的局限性、团队过去的尝试以及关键利益相关者的担忧开始解释。AI 会问诸如“不可协商的性能要求是什么？”或“这如何与认证服务交互？”等问题。
- 优化与结构：你会决定章节（概述、设计、考虑过的替代方案、发布计划）。对于“设计”部分，你会头脑风暴所有可能的数据模型，然后在起草该部分之前进行筛选。
- 读者测试：AI 扮演新团队成员，阅读规格书并尝试回答：“这解决了什么问题？”“主要风险是什么？”“我如何实现客户端？”如果它感到困难，你就修改那些部分。
这种有条理的方法将写作从一个孤立的任务转变为一个协作审查过程，在问题到达你的团队之前就将其捕获。
结论
有效的文档对于团队对齐和执行至关重要，然而要写好却异常困难。根本原因通常在于写作者的背景与读者理解之间那道无形的鸿沟。结构化的协作写作流程，例如 doc-coauthoring 技能 所提供的，为弥合这一差距提供了一个实用的框架。它强调背景转移、迭代优化和读者测试——这些是创建真正有用文档的关键要素。如果你经常为混合受众撰写复杂文档，并且在清晰度方面遇到困难，那么这是一个值得检查并根据自身需求进行调整的工作流程。