Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.
文档共同撰写工作流程
本技能提供结构化工作流程，引导用户完成协作文档创建。作为主动引导，带领用户经历三个阶段：上下文收集、完善与结构、读者测试。
何时提供此工作流程
触发条件：
- 用户提到编写文档：“写文档”、“起草提案”、“创建规范”、“撰写”
- 用户提到特定文档类型：“PRD”、“设计文档”、“决策文档”、“RFC”
- 用户似乎要开始一项重要的写作任务
初始提议：
向用户提供共同撰写文档的结构化工作流程。解释三个阶段：
- 上下文收集：用户提供所有相关上下文，同时Claude提出澄清问题
- 完善与结构：通过头脑风暴和编辑迭代构建每个部分
- 读者测试：用全新的Claude（无上下文）测试文档，在他人阅读前发现盲点
解释这种方法有助于确保文档在他人阅读时（包括粘贴到Claude中时）效果良好。询问用户是否想尝试此工作流程，或者更倾向于自由工作。
如果用户拒绝，则自由工作。如果用户接受，进入阶段1。
阶段1：上下文收集
**目标：**缩小用户所知与Claude所知之间的差距，以便后续提供智能指导。
初始问题
首先询问用户关于文档的元上下文：
- 这是什么类型的文档？（例如，技术规范、决策文档、提案）
- 主要受众是谁？
- 读者阅读后期望产生什么影响？
- 是否有模板或特定格式要遵循？
- 还有其他约束或上下文需要了解吗？
告知他们可以用简写回答，或以最适合他们的方式倾倒信息。
如果用户提供模板或提到文档类型：
- 询问他们是否有要分享的模板文档
- 如果他们提供共享文档的链接，使用适当的集成获取它
- 如果他们提供文件，读取它
如果用户提到编辑现有的共享文档：
- 使用适当的集成读取当前状态
- 检查没有替代文本的图像
- 如果存在没有替代文本的图像，解释当其他人使用Claude理解文档时，Claude将无法看到它们。询问他们是否希望生成替代文本。如果是，要求他们将每个图像粘贴到聊天中，以便生成描述性替代文本。
信息倾倒
一旦回答了初始问题，鼓励用户倾倒他们拥有的所有上下文。请求信息，例如：
- 项目/问题的背景
- 相关的团队讨论或共享文档
- 为什么不使用替代方案
- 组织背景（团队动态、过去事件、政治因素）
- 时间压力或约束
- 技术架构或依赖关系
- 利益相关者的担忧
建议他们不要担心组织——只需全部说出来。提供多种提供上下文的方式：
- 意识流式信息倾倒
- 指向团队频道或线程以供阅读
- 链接到共享文档
如果集成可用（例如，Slack、Teams、Google Drive、SharePoint或其他MCP服务器），提及这些可用于直接拉取上下文。
**如果在Claude.ai或Claude应用中未检测到集成：**建议他们在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实例（无此对话的上下文）测试这些问题。
对于每个问题，调用子代理，仅提供文档内容和问题。
总结Reader Claude对每个问题的正确/错误回答。
步骤3：运行额外检查
宣布将执行额外检查。
调用子代理检查歧义、错误假设、矛盾。
总结发现的任何问题。
步骤4：报告和修复
如果发现问题：
报告Reader Claude在特定问题上遇到困难。
列出具体问题。
表示打算修复这些差距。
循环回有问题的部分进行完善。
如果无法访问子代理（例如，claude.ai网页界面）：
用户需要手动进行测试。
步骤1：预测读者问题
询问人们在尝试发现此文档时可能会问什么问题。他们会向Claude.ai输入什么？
生成5-10个读者会实际提出的问题。
步骤2：设置测试
提供测试说明：
- 打开一个新的Claude对话：https://claude.ai
- 粘贴或分享文档内容（如果使用启用了连接器的共享文档平台，提供链接）
- 向Reader Claude提出生成的问题
对于每个问题，指示Reader Claude提供：
- 答案
- 是否有任何内容含糊不清或不明确
- 文档假设读者已经知道哪些知识/上下文
检查Reader Claude是否给出正确答案或误解任何内容。
步骤3：额外检查
同时询问Reader Claude：
- “本文档中哪些内容可能对读者含糊不清或不明确？”
- “本文档假设读者已经知道哪些知识或上下文？”
- “是否存在任何内部矛盾或不一致？”
步骤4：根据结果迭代
询问Reader Claude哪些内容回答错误或难以理解。表示打算修复这些差距。
循环回有问题的部分进行完善。
退出条件（两种方法）
当Reader Claude始终正确回答问题，且不再发现新的差距或歧义时，文档就准备好了。
最终审阅
当读者测试通过时：
宣布文档已通过Reader Claude测试。在完成之前：
- 建议他们自己进行最终通读——他们拥有此文档并对其质量负责
- 建议再次核对任何事实、链接或技术细节
- 请他们验证文档是否达到了他们想要的影响
询问他们是否想要再进行一次审阅，或者工作是否完成。
如果用户想要最终审阅，提供它。否则：
宣布文档完成。提供一些最终提示：
- 考虑在附录中链接此对话，以便读者了解文档是如何开发的
- 使用附录提供深度，而不使主文档臃肿
- 根据真实读者的反馈更新文档
有效指导的提示
语气：
- 直接且程序化
- 当影响用户行为时，简要解释理由
- 不要试图“推销”方法——只需执行它
处理偏离：
- 如果用户想跳过某个阶段：询问他们是否想跳过并自由写作
- 如果用户感到沮丧：承认这比预期花费的时间长。建议加快速度的方法
- 始终让用户有权调整流程
上下文管理：
- 在整个过程中，如果缺少关于某事的上下文，主动询问
- 不要让差距累积——出现时就解决
工件管理：
- 使用
create_file起草完整部分 - 使用
str_replace进行所有编辑 - 每次更改后提供工件链接
- 永远不要使用工件进行头脑风暴列表——那只是对话
质量优先于速度：
- 不要匆忙完成各个阶段
- 每次迭代都应带来有意义的改进
- 目标是创建一份真正对读者有效的文档
