doc-coauthoring

文档共同撰写工作流程

本技能提供结构化工作流程，引导用户完成协作文档创建。作为主动引导，带领用户经历三个阶段：上下文收集、完善与结构、读者测试。

何时提供此工作流程

触发条件：

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

初始提议：
向用户提供共同撰写文档的结构化工作流程。解释三个阶段：

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

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

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

阶段1：上下文收集

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

初始问题

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

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

告知他们可以用简写回答，或以最适合他们的方式倾倒信息。

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

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

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

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

信息倾倒

一旦回答了初始问题，鼓励用户倾倒他们拥有的所有上下文。请求信息，例如：

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

建议他们不要担心组织——只需全部说出来。提供多种提供上下文的方式：

• 意识流式信息倾倒
• 指向团队频道或线程以供阅读
• 链接到共享文档

如果集成可用（例如，Slack、Teams、Google Drive、SharePoint或其他MCP服务器），提及这些可用于直接拉取上下文。

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

告知他们在完成初始倾倒后会提出澄清问题。

在上下文收集期间：

• 如果用户提到团队频道或共享文档：

  • 如果集成可用：告知他们将立即读取内容，然后使用适当的集成
  • 如果集成不可用：解释无法访问。建议他们在Claude设置中启用连接器，或直接粘贴相关内容。

• 如果用户提到未知的实体/项目：

  • 询问是否应搜索已连接的工具以了解更多
  • 等待用户确认后再搜索

• 当用户提供上下文时，跟踪已了解的内容和仍不清楚的内容

提出澄清问题：

当用户表示已完成初始倾倒（或提供大量上下文后），提出澄清问题以确保理解：

根据上下文中的空白生成5-10个编号问题。

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

退出条件：
当问题显示出理解时——即无需解释基础知识就能询问边缘情况和权衡——表明已收集到足够的上下文。

过渡：
询问他们是否还有更多上下文要提供，或者是否该进入文档起草阶段。

如果用户想添加更多，让他们添加。准备好后，进入阶段2。

阶段2：完善与结构

**目标：**通过头脑风暴、筛选和迭代完善，逐节构建文档。

对用户的说明：
解释文档将逐节构建。对于每个部分：

1. 将询问关于包含内容的澄清问题
2. 将头脑风暴5-20个选项
3. 用户将指示保留/删除/合并哪些内容
4. 将起草该部分
5. 通过精确编辑进行完善

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

部分顺序：

如果文档结构清晰：
询问他们想从哪个部分开始。

建议从未知最多的部分开始。对于决策文档，通常是核心提案。对于规范，通常是技术方法。摘要部分最好留到最后。

如果用户不知道需要哪些部分：
根据文档类型和模板，建议适合该文档类型的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实例（无此对话的上下文）测试这些问题。

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

总结Reader Claude对每个问题的正确/错误回答。

步骤3：运行额外检查

宣布将执行额外检查。

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

总结发现的任何问题。

步骤4：报告和修复

如果发现问题：
报告Reader Claude在特定问题上遇到困难。

列出具体问题。

表示打算修复这些差距。

循环回有问题的部分进行完善。

---

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

用户需要手动进行测试。

步骤1：预测读者问题

询问人们在尝试发现此文档时可能会问什么问题。他们会向Claude.ai输入什么？

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

步骤2：设置测试

提供测试说明：

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

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

• 答案
• 是否有任何内容含糊不清或不明确
• 文档假设读者已经知道哪些知识/上下文

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

步骤3：额外检查

同时询问Reader Claude：

• “本文档中哪些内容可能对读者含糊不清或不明确？”
• “本文档假设读者已经知道哪些知识或上下文？”
• “是否存在任何内部矛盾或不一致？”

步骤4：根据结果迭代

询问Reader Claude哪些内容回答错误或难以理解。表示打算修复这些差距。

循环回有问题的部分进行完善。

---

退出条件（两种方法）

当Reader Claude始终正确回答问题，且不再发现新的差距或歧义时，文档就准备好了。

最终审阅

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

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

询问他们是否想要再进行一次审阅，或者工作是否完成。

如果用户想要最终审阅，提供它。否则：
宣布文档完成。提供一些最终提示：

• 考虑在附录中链接此对话，以便读者了解文档是如何开发的
• 使用附录提供深度，而不使主文档臃肿
• 根据真实读者的反馈更新文档

有效指导的提示

语气：

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

处理偏离：

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

上下文管理：

• 在整个过程中，如果缺少关于某事的上下文，主动询问
• 不要让差距累积——出现时就解决

工件管理：

• 使用create_file起草完整部分
• 使用str_replace进行所有编辑
• 每次更改后提供工件链接
• 永远不要使用工件进行头脑风暴列表——那只是对话

质量优先于速度：

• 不要匆忙完成各个阶段
• 每次迭代都应带来有意义的改进
• 目标是创建一份真正对读者有效的文档