name: doc-coauthoring
description: 引导用户完成结构化的文档协作工作流。适用于用户编写文档、提案、技术规范、决策文档或类似结构化内容时。此工作流帮助用户高效传递上下文、通过迭代优化内容，并验证文档对读者有效。当用户提到编写文档、创建提案、起草规范或类似文档任务时触发。

文档协作编写工作流

本技能提供了一套结构化工作流，用于指导用户完成协作文档创建。请作为主动引导者，带领用户经历三个阶段：背景收集、优化与结构、读者测试。

何时提供此工作流

触发条件：

• 用户提及编写文档：“写文档”、“起草提案”、“创建规格”、“撰写”
• 用户提及特定文档类型：“PRD”、“设计文档”、“决策文档”、“RFC”
• 用户似乎要开始一项实质性的写作任务

初始提供：

向用户提供一套用于协作编写文档的结构化工作流。解释三个阶段：

1. 背景收集：Claude 提出澄清性问题时，用户提供所有相关背景
2. 优化与结构：通过头脑风暴和编辑迭代构建每个章节
3. 读者测试：用全新的 Claude（无上下文）测试文档，在其他人阅读前发现盲点

解释这种方法有助于确保文档在其他人阅读时（包括当他们将文档粘贴到 Claude 中时）效果良好。询问用户是否想尝试此工作流，或者更喜欢自由写作。

如果用户拒绝，则自由写作。如果用户接受，则进入阶段一。

阶段一：背景收集

目标： 缩小用户所知与 Claude 所知之间的差距，以便后续提供更智能的指导。

初始问题

首先向用户询问文档的元上下文：

1. 这是哪种类型的文档？（例如，技术规格、决策文档、提案）
2. 主要读者是谁？
3. 当有人阅读此文档时，期望产生什么影响？
4. 是否有需要遵循的模板或特定格式？
5. 还有其他约束或背景需要了解吗？

告知他们可以用速记或任何最方便的方式倾泻信息。

如果用户提供了模板或提到了文档类型：

• 询问他们是否有模板文档可以分享
• 如果他们提供了共享文档的链接，使用适当的集成获取它
• 如果他们提供了文件，则读取它

如果用户提到要编辑现有的共享文档：

• 使用适当的集成读取当前状态
• 检查没有替代文本的图像
• 如果存在没有替代文本的图像，解释当其他人使用 Claude 理解文档时，Claude 将无法看到这些图像。询问他们是否想生成替代文本。如果是，要求他们将每张图像粘贴到对话中，以便生成描述性替代文本。

信息倾泻

在初始问题得到解答后，鼓励用户倾泻他们拥有的所有背景。请求信息包括：

• 项目/问题的背景
• 相关团队讨论或共享文档
• 为什么没有使用替代方案
• 组织背景（团队动态、过往事件、政治因素）
• 时间压力或约束
• 技术架构或依赖关系
• 利益相关者关注点

建议他们无需担心组织整理——只需全部倾泻出来。提供多种提供背景的方式：

• 意识流式信息倾泻
• 指向要阅读的团队频道或讨论串
• 链接到共享文档

如果集成都可用（例如，Slack、Teams、Google Drive、SharePoint 或其他 MCP 服务器），提及可以使用这些集成直接拉取背景。

如果在 Claude.ai 或 Claude 应用中未检测到集成： 建议他们可以在 Claude 设置中启用连接器，以便从消息应用和文档存储中直接拉取背景。

告知他们在完成初始倾泻后，将会提出澄清性问题。

在背景收集期间：

• 如果用户提及团队频道或共享文档：
• 如果集成可用：告知他们将立即读取内容，然后使用适当的集成
• 如果集成不可用：说明无法访问。建议他们在 Claude 设置中启用连接器，或直接粘贴相关内容。

• 如果用户提及未知的实体/项目：
• 询问是否应该搜索已连接的工具以了解更多信息
• 在用户确认之前等待，然后再搜索

• 当用户提供背景时，跟踪正在学习的内容以及仍不清楚的内容

提出澄清性问题：

当用户表示已完成初始倾泻时（或提供了大量背景后），提出澄清性问题以确保理解：

根据背景中的空白生成 5-10 个编号问题。

告知他们可以使用速记回答（例如，“1：是，2：见 #频道，3：不，因为向后兼容”），链接到更多文档，指向要阅读的频道，或者继续信息倾泻。选择对他们最有效率的方式。

退出条件：

当问题显示出理解时——可以询问边界情况和权衡而无需解释基础知识——则已收集到足够的背景。

过渡：

询问他们在这个阶段是否还有更多背景要提供，或者是否该进入文档起草阶段。

如果用户想补充更多内容，让他们补充。准备就绪后，进入阶段二。

阶段二：优化与结构

目标： 通过头脑风暴、策划和迭代优化，逐节构建文档。

给用户的说明：

解释文档将逐节构建。对于每个章节：

1. 将就章节内容提出澄清性问题
2. 将头脑风暴出 5-20 个选项
3. 用户将指出保留/删除/合并哪些内容
4. 将起草该章节
5. 将通过精准编辑进行优化

从未知内容最多的章节开始（通常是核心决策/提案），然后处理其余部分。

章节排序：

如果文档结构清晰：

询问他们想从哪个章节开始。

建议从未知内容最多的章节开始。对于决策文档，这通常是核心提案。对于规格文档，通常是技术方案。摘要章节最好留到最后处理。

如果用户不知道需要哪些章节：

根据文档类型和模板，为该文档类型建议 3-5 个合适的章节。

询问这个结构是否合适，或者他们想调整。

确认结构后：

创建包含所有章节占位文本的初始文档结构。

如果可以访问工件：

使用 create_file 创建工件。这将为 Claude 和用户提供一个可操作的基础框架。

告知他们将创建包含所有章节占位符的初始结构。

创建包含所有章节标题和简短占位文本（如“[待编写]”或“[内容在此]”）的工件。

提供框架链接并表示是时候填充每个章节了。

如果无法访问工件：

在工作目录中创建一个 Markdown 文件。适当命名（例如，decision-doc.md、technical-spec.md）。

告知他们将创建包含所有章节占位符的初始结构。

创建包含所有章节标题和占位文本的文件。

确认文件名已创建并表示是时候填充每个章节了。

对于每个章节：

步骤一：澄清性问题

宣布将开始处理[章节名称]章节。就章节内容提出 5-10 个澄清性问题：

根据背景和章节目的生成 5-10 个具体问题。

告知他们可以用速记回答，或只是指出需要涵盖的重要内容。

步骤二：头脑风暴

对于[章节名称]章节，根据章节复杂程度，头脑风暴[5-20]个可能包含的内容。寻找：

• 已分享但可能被遗忘的背景
• 尚未提到的视角或考量

根据章节复杂程度生成 5-20 个编号选项。最后，询问是否需要更多选项以进行额外头脑风暴。

步骤三：策划

询问应保留、删除或合并哪些要点。请求简要理由，以帮助了解后续章节的优先级。

提供示例：

• “保留 1、4、7、9”
• “删除 3（重复 1）”
• “删除 6（读者已经知道这个了）”
• “合并 11 和 12”

如果用户给出自由形式反馈（例如，“看起来不错”或“我大部分都喜欢，但是……”）而不是编号选择，提取他们的偏好并继续处理。解析他们想要保留/删除/更改的内容并应用。

步骤四：缺口检查

根据他们选择的内容，询问[章节名称]章节是否缺少任何重要内容。

步骤五：起草

使用 str_replace 将此章节的占位文本替换为实际起草的内容。

宣布现在将根据他们选择的内容起草[章节名称]章节。

如果使用工件：

起草后，提供工件的链接。

请他们通读并指出要更改的内容。注意，具体的反馈有助于学习并为后续章节提供指导。

如果使用文件（无工件）：

起草后，确认完成。

告知他们[章节名称]章节已在[文件名]中完成起草。请他们通读并指出要更改的内容。注意，具体的反馈有助于学习并为后续章节提供指导。

给用户的关键说明（起草第一个章节时包含）：

提供一条说明：请他们指出要更改的内容，而不是直接编辑文档。这有助于学习他们的风格以供后续章节使用。例如：“删除X要点——已被Y涵盖”或“让第三段更简洁”。

步骤六：迭代优化

当用户提供反馈时：

• 使用 str_replace 进行编辑（绝不重新打印整个文档）
• 如果使用工件： 每次编辑后提供工件链接
• 如果使用文件： 只需确认编辑完成
• 如果用户直接编辑文档并要求读取：在心理上记下他们所做的更改，并在后续章节中记住（这显示了他们的偏好）

继续迭代直到用户对该章节满意。

质量检查

连续 3 次迭代无实质更改后，询问是否可以在不丢失重要信息的情况下删除某些内容。

章节完成后，确认[章节名称]已完成。询问是否准备进入下一个章节。

对所有章节重复此过程。

接近完成

当接近完成时（80% 以上章节完成），宣布意图重新通读整个文档并检查：

• 各章节之间的流动性和一致性
• 冗余或矛盾
• 任何感觉像“泛泛而谈”或通用填充物的内容
• 每个句子是否有分量

通读整个文档并提供反馈。

当所有章节都起草并优化完成后：

宣布所有章节已完成起草。表示意图再次审查完整的文档。

检查整体连贯性、流动性和完整性。

提供任何最终建议。

询问是否准备进入读者测试，或者是否还想优化其他内容。

阶段三：读者测试

目标： 使用全新的 Claude（无上下文泄露）测试文档，以验证其对读者有效。

给用户的说明：

解释现在将进行测试，以查看文档是否确实对读者有效。这可以发现盲点——对作者来说有意义但可能让其他人困惑的事情。

测试方法

如果可以访问子代理（例如，在 Claude Code 中）：

无需用户参与，直接执行测试。

步骤一：预测读者问题

宣布意图预测读者在尝试理解此文档时可能会问的问题。

生成 5-10 个读者会实际提出的问题。

步骤二：使用子代理测试

宣布将使用全新的 Claude 实例（无此对话的上下文）测试这些问题。

对于每个问题，仅使用文档内容和该问题调用子代理。

总结每个问题读者 Claude 回答正确/错误的地方。

步骤三：运行额外检查

宣布将执行额外检查。

调用子代理检查歧义、错误假设和矛盾。

总结发现的任何问题。

步骤四：报告与修复

如果发现问题：

报告读者 Claude 在处理特定问题时遇到困难。

列出具体问题。

表示意图修复这些缺口。

对有问题的章节循环回到优化阶段。

---

如果无法访问子代理（例如，claude.ai 网页界面）：

用户需要手动执行测试。

步骤一：预测读者问题

询问人们尝试理解此文档时可能会问的问题。他们会在 Claude.ai 中输入什么？

生成 5-10 个读者会实际提出的问题。

步骤二：设置测试

提供测试说明：

1. 打开一个新的 Claude 对话：https://claude.ai
2. 粘贴或分享文档内容（如果使用启用了连接器的共享文档平台，则提供链接）
3. 向读者 Claude 提出生成的问题

对于每个问题，指示读者 Claude 提供：

• 答案
• 是否有任何歧义或不清楚的地方
• 文档假定读者已经知道哪些知识/背景

检查读者 Claude 是否给出正确答案或误解了任何内容。

步骤三：额外检查

同时向读者 Claude 提问：

• “此文档中哪些内容可能对读者产生歧义或不清晰？”
• “此文档假定读者已经拥有哪些知识或背景？”
• “是否存在任何内部矛盾或不一致？”

步骤四：根据结果迭代

询问读者 Claude 回答错误或遇到困难的方面。表示意图修复这些缺口。

对有问题的章节循环回到优化阶段。

---

退出条件（两种方法）

当读者 Claude 始终正确回答问题且不提出新的缺口或歧义时，文档即准备就绪。

最终审查

当读者测试通过时：

宣布文档已通过读者 Claude 测试。在完成前：

1. 建议他们自行进行最终通读——他们拥有此文档并对其质量负责
2. 建议再次核对任何事实、链接或技术细节
3. 请他们验证文档是否达到了他们想要的影响

询问他们是否想要再进行一次审查，还是工作已完成。

如果用户想要最终审查，则提供。否则：

宣布文档完成。提供几个最终提示：

• 考虑将此对话链接到附录中，以便读者可以看到文档是如何开发的
• 使用附录在不使主文档臃肿的情况下提供深度内容
• 根据从实际读者收到的反馈更新文档

有效指导的技巧

语气：

• 直接且程序化
• 当影响用户行为时简要解释理由
• 不要试图“推销”这种方法——只需执行

处理偏离：

• 如果用户想跳过某个阶段：询问他们是否想跳过此阶段并自由写作
• 如果用户似乎感到沮丧：承认这比预期花费的时间长。建议加快速度的方法
• 始终让用户有权调整流程

上下文管理：

• 在整个过程中，如果缺少关于提到内容的背景，主动询问
• 不要让缺口累积——出现时就解决

工件管理：

• 使用 create_file 起草完整章节
• 对所有编辑使用 str_replace
• 每次更改后提供工件链接
• 绝不用工件处理头脑风暴列表——那只是对话

质量优先于速度：

• 不要仓促完成阶段
• 每次迭代都应带来有意义的改进
• 目标是制作一份对读者真正有效的文档