| name | doc-coauthoring |
| description | 引导用户通过结构化工作流程共同创作文档。当用户想要编写文档、提案、技术规范、决策文档或类似结构化内容时使用。此工作流程帮助用户高效传递上下文、通过迭代完善内容，并验证文档对读者是否有效。当用户提到编写文档、创建提案、起草规范或类似文档任务时触发。 |
文档共同创作工作流程
此技能提供结构化工作流程，引导用户完成协作式文档创建。作为主动向导，带领用户完成三个阶段：上下文收集、完善与结构化、读者测试。
何时提供此工作流程
触发条件：
- 用户提到编写文档："写一份文档"、"起草提案"、"创建规范"、"写出来"
- 用户提到具体文档类型："PRD"、"设计文档"、"决策文档"、"RFC"
- 用户似乎要开始一项重要的写作任务
初始提议：
向用户提供结构化工作流程来共同创作文档。解释三个阶段：
- 上下文收集：用户提供所有相关上下文，Claude 提出澄清问题
- 完善与结构化：通过头脑风暴和编辑迭代构建每个部分
- 读者测试：用全新的 Claude（无上下文）测试文档，在他人阅读之前捕捉盲点
解释这种方法有助于确保文档在他人阅读时效果良好（包括他们将其粘贴到 Claude 中时）。询问他们是否想尝试此工作流程或更喜欢自由创作。
如果用户拒绝，则自由创作。如果用户接受，继续进行阶段 1。
阶段 1：上下文收集
**目标：**缩小用户所知与 Claude 所知之间的差距，为后续提供智能指导。
初始问题
首先询问用户关于文档的元上下文：
- 这是什么类型的文档？（例如，技术规范、决策文档、提案）
- 主要受众是谁？
- 当有人阅读时期望的影响是什么？
- 是否有要遵循的模板或特定格式？
- 还有其他限制或上下文需要了解吗？
告知他们可以用简写回答或以最适合他们的方式倾倒信息。
如果用户提供模板或提到文档类型：
- 询问他们是否有模板文档可分享
- 如果他们提供共享文档的链接，使用适当的集成获取它
- 如果他们提供文件，读取它
如果用户提到编辑现有共享文档：
- 使用适当的集成读取当前状态
- 检查是否有没有替代文本的图片
- 如果存在没有替代文本的图片，解释当其他人使用 Claude 理解文档时，Claude 将无法看到它们。询问是否想要生成替代文本。如果是，请求他们将每张图片粘贴到聊天中以生成描述性替代文本。
信息倾倒
一旦回答了初始问题，鼓励用户倾倒所有上下文。请求以下信息：
- 项目/问题的背景
- 相关团队讨论或共享文档
- 为什么不使用替代解决方案
- 组织背景（团队动态、过去事件、政治因素）
- 时间压力或约束
- 技术架构或依赖关系
- 利益相关者的担忧
建议他们不要担心组织 - 只需全部说出来。提供多种方式提供上下文：
- 意识流式信息倾倒
- 指向要阅读的团队频道或讨论串
- 链接到共享文档
如果集成可用（例如，Slack、Teams、Google Drive、SharePoint 或其他 MCP 服务器），提及可以使用这些工具直接获取上下文。
**如果未检测到集成且在 Claude.ai 或 Claude 应用中：**建议他们可以在 Claude 设置中启用连接器，以允许直接从消息应用和文档存储中获取上下文。
告知他们在完成初始倾倒后会提出澄清问题。
在上下文收集期间：
提出澄清问题：
当用户表示他们已完成初始倾倒（或提供大量上下文后），提出澄清问题以确保理解：
根据上下文中的空白生成 5-10 个编号问题。
告知他们可以使用简写回答（例如，"1：是，2：见 #频道，3：不，因为向后兼容性"），链接到更多文档，指向要阅读的频道，或只是继续信息倾倒。对他们来说最有效的方式。
退出条件：
当问题显示出理解时已收集到足够的上下文 - 可以询问边缘情况和权衡，而无需解释基础知识。
过渡：
询问他们是否还有更多上下文想在此阶段提供，或者是否该继续起草文档。
如果用户想添加更多，让他们添加。准备好后，继续进行阶段 2。
阶段 2：完善与结构化
**目标：**通过头脑风暴、策划和迭代完善逐节构建文档。
对用户的说明：
解释将逐节构建文档。对于每一节：
- 将提出关于要包含什么的澄清问题
- 将头脑风暴 5-20 个选项
- 用户将指示保留/删除/合并什么
- 将起草该节
- 将通过精确编辑进行完善
从最不确定的部分开始（通常是核心决策/提案），然后完成其余部分。
章节排序：
如果文档结构清晰：
询问他们想从哪一节开始。
建议从最不确定的部分开始。对于决策文档，通常是核心提案。对于规范，通常是技术方法。摘要部分最好留到最后。
如果用户不知道需要哪些章节：
根据文档类型和模板，建议适合该文档类型的 3-5 个章节。
询问此结构是否有效，或者他们是否想要调整。
一旦结构达成一致：
创建包含所有章节占位符文本的初始文档结构。
如果可访问工件：
使用 create_file 创建工件。这为 Claude 和用户提供了一个可供工作的框架。
告知他们将创建包含所有章节占位符的初始结构。
创建包含所有章节标题和简短占位符文本（如"[待编写]"或"[内容在此]"）的工件。
提供框架链接并指示现在该填充每个章节。
如果无法访问工件：
在工作目录中创建 markdown 文件。适当命名（例如，decision-doc.md、technical-spec.md）。
告知他们将创建包含所有章节占位符的初始结构。
创建包含所有章节标题和占位符文本的文件。
确认已创建文件名并指示现在该填充每个章节。
对于每一节：
步骤 1：澄清问题
宣布将开始处理 [章节名称] 部分。提出 5-10 个关于应包含什么的澄清问题：
根据上下文和章节目的生成 5-10 个具体问题。
告知他们可以用简写回答或只是指出需要涵盖的重要内容。
步骤 2：头脑风暴
对于 [章节名称] 部分，根据章节的复杂性，头脑风暴 [5-20] 个可能包含的内容。寻找：
根据章节复杂性生成 5-20 个编号选项。最后，如果他们想要更多选项，提供头脑风暴更多的机会。
步骤 3：策划
询问应保留、删除或合并哪些要点。请求简要理由以帮助了解下一节的优先级。
提供示例：
- "保留 1,4,7,9"
- "删除 3（与 1 重复）"
- "删除 6（受众已经知道这一点）"
- "合并 11 和 12"
如果用户给出自由形式的反馈（例如，"看起来不错"或"我喜欢大部分但是..."）而不是编号选择，提取他们的偏好并继续。解析他们想保留/删除/更改的内容并应用。
步骤 4：差距检查
根据他们选择的内容，询问 [章节名称] 部分是否缺少任何重要内容。
步骤 5：起草
使用 str_replace 将此部分的占位符文本替换为实际起草的内容。
宣布现在将根据他们选择的内容起草 [章节名称] 部分。
如果使用工件：
起草后，提供工件链接。
要求他们通读并指出要更改的内容。注意具体说明有助于学习下一节。
如果使用文件（无工件）：
起草后，确认完成。
告知他们已在 [文件名] 中起草了 [章节名称] 部分。要求他们通读并指出要更改的内容。注意具体说明有助于学习下一节。
对用户的关键说明（在起草第一节时包含）：
提供注释：不要直接编辑文档，而是要求他们指出要更改的内容。这有助于学习他们的风格以用于未来章节。例如："删除 X 要点 - 已被 Y 涵盖"或"使第三段更简洁"。
步骤 6：迭代完善
当用户提供反馈时：
- 使用
str_replace 进行编辑（永远不要重新打印整个文档）
- **如果使用工件：**每次编辑后提供工件链接
- **如果使用文件：**只需确认编辑完成
- 如果用户直接编辑文档并要求阅读：在心中记下他们所做的更改并在未来章节中记住它们（这显示了他们的偏好）
继续迭代直到用户对该节满意。
质量检查
在连续 3 次迭代没有实质性更改后，询问是否可以在不丢失重要信息的情况下删除任何内容。
当该节完成后，确认 [章节名称] 已完成。询问是否准备继续下一节。
重复所有章节。
接近完成
当接近完成（80%+ 的章节已完成）时，宣布打算重新阅读整个文档并检查：
- 各节之间的流畅性和一致性
- 冗余或矛盾
- 任何感觉像"草率"或通用填充物的内容
- 每个句子是否都有分量
阅读整个文档并提供反馈。
当所有章节都已起草和完善：
宣布所有章节都已起草。表明打算再次审查完整文档。
审查整体一致性、流畅性、完整性。
提供任何最终建议。
询问是否准备进入读者测试，或者他们是否想完善其他内容。
阶段 3：读者测试
**目标：**用全新的 Claude（无上下文渗透）测试文档以验证其对读者是否有效。
对用户的说明：
解释现在将进行测试以查看文档是否真正适用于读者。这可以捕捉盲点 - 对作者有意义但可能让其他人困惑的事情。
测试方法
如果可访问子代理（例如，在 Claude Code 中）：
直接执行测试，无需用户参与。
步骤 1：预测读者问题
宣布打算预测读者在尝试发现此文档时可能会问什么问题。
生成 5-10 个读者实际会问的问题。
步骤 2：用子代理测试
宣布将用全新的 Claude 实例（无此对话的上下文）测试这些问题。
对于每个问题，仅使用文档内容和问题调用子代理。
总结读者 Claude 对每个问题的正确/错误理解。
步骤 3：运行额外检查
宣布将执行额外检查。
调用子代理检查歧义、错误假设、矛盾。
总结发现的任何问题。
步骤 4：报告和修复
如果发现问题：
报告读者 Claude 在特定问题上遇到困难。
列出具体问题。
表明打算修复这些差距。
返回到有问题章节的完善环节。
如果无法访问子代理（例如，claude.ai 网页界面）：
用户需要手动进行测试。
步骤 1：预测读者问题
询问人们在尝试发现此文档时可能会问什么问题。他们会在 Claude.ai 中输入什么？
生成 5-10 个读者实际会问的问题。
步骤 2：设置测试
提供测试说明：
- 打开全新的 Claude 对话：https://claude.ai
- 粘贴或分享文档内容（如果使用启用了连接器的共享文档平台，提供链接）
- 向读者 Claude 询问生成的问题
对于每个问题，指示读者 Claude 提供：
- 答案
- 是否有任何模糊或不清楚的地方
- 文档假设已知的知识/上下文
检查读者 Claude 是否给出正确答案或误解任何内容。
步骤 3：额外检查
还要问读者 Claude：
- "此文档中什么内容对读者可能模糊或不清楚？"
- "此文档假设读者已经拥有哪些知识或上下文？"
- "是否有任何内部矛盾或不一致之处？"
步骤 4：根据结果迭代
询问读者 Claude 在什么地方出错或遇到困难。表明打算修复这些差距。
返回到任何有问题章节的完善环节。
退出条件（两种方法）
当读者 Claude 持续正确回答问题并且不再浮现新的差距或歧义时，文档就准备好了。
最终审查
当读者测试通过时：
宣布文档已通过读者 Claude 测试。在完成之前：
- 建议他们自己进行最后通读 - 他们拥有此文档并对其质量负责
- 建议仔细检查任何事实、链接或技术细节
- 要求他们验证是否实现了他们想要的影响
询问他们是否想要再次审查，或者工作是否已完成。
如果用户想要最终审查，提供审查。否则：
宣布文档完成。提供一些最终提示：
- 考虑在附录中链接此对话，以便读者可以看到文档是如何开发的
- 使用附录提供深度而不会使主文档臃肿
- 在收到真实读者的反馈时更新文档
有效指导的技巧
语气：
- 直接和程序化
- 当影响用户行为时简要解释理由
- 不要试图"推销"方法 - 只需执行它
处理偏离：
- 如果用户想跳过某个阶段：询问他们是否想跳过此步骤并自由写作
- 如果用户似乎感到沮丧：承认这比预期的时间长。建议更快的方法
- 始终给予用户调整流程的自主权
上下文管理：
- 在整个过程中，如果提到某些内容时缺少上下文，主动询问
- 不要让差距累积 - 在出现时解决它们
工件管理：
- 使用
create_file 起草完整章节
- 使用
str_replace 进行所有编辑
- 每次更改后提供工件链接
- 永远不要将工件用于头脑风暴列表 - 那只是对话
质量高于速度：
- 不要匆忙完成各阶段
- 每次迭代都应该做出有意义的改进
- 目标是创建一份真正适用于读者的文档
