需要协作撰写文档、提案、技术规格、决策文档或 RFC 时…

适用于用户要协作撰写 PRD、设计文档、决策文档、RFC、提案或技术规格等结构化文档时。

适用场景

解决思路

1. 当用户提到写文档、起草提案、创建规格、写说明，或提到 PRD、设计文档、决策文档、RFC 等文档类型，或看起来要开始大量写作任务时，提供该结构化协作流程。
2. 初始提供时，解释三个阶段：Context Gathering 收集上下文、Refinement & Structure 精炼与结构、Reader Testing 读者测试；说明该方式能确保文档在他人阅读（包括粘贴到 Claude）时有效；询问用户想尝试此流程还是自由格式。
3. 如果用户拒绝，按自由格式工作；如果接受，进入 Stage 1。
4. 进入 Stage 1 后，先明确目标：缩小用户已知与 Claude 已知之间的差距，以便后续给出聪明指导。
5. 先询问文档元上下文：1 文档类型是什么（如技术规格、决策文档、提案）；2 主要受众是谁；3 期望读者读后产生什么影响；4 是否有模板或特定格式要遵循；5 还有其他约束或上下文吗。告知用户可简写或按最方便的方式提供。
6. 如果用户提供模板或提到文档类型：询问是否有模板文档可分享；如果提供共享文档链接，使用适当集成获取；如果提供文件，读取它。
7. 如果用户提到编辑现有共享文档：使用适当集成读取当前状态；检查无 alt-text 的图片；如果存在无 alt-text 图片，解释他人用 Claude 理解文档时看不到它们，询问是否要生成 alt-text；如果要，请用户把每张图片粘贴到聊天中以生成描述性 alt-text。
8. 初始问题回答后，鼓励用户倾倒所有上下文，请求包括：项目/问题背景；相关团队讨论或共享文档；为什么不使用替代方案；组织上下文（团队动态、过往事件、政治）；时间压力或约束；技术架构或依赖；利益相关者关注点。
9. 建议用户不必组织信息，先把所有内容倒出；提供多种提供上下文的方式：意识流信息倾倒；指向团队频道或线程供阅读；链接共享文档。
10. 如果集成可用（如 Slack、Teams、Google Drive、SharePoint 或其他 MCP servers），说明可用它们直接拉取上下文。
11. 如果未检测到集成且在 Claude.ai 或 Claude app 中：建议用户在 Claude 设置中启用连接器，以便从消息应用和文档存储直接拉取上下文。
12. 告知用户初次倾倒后会问澄清问题。
13. 在收集上下文期间，如果用户提到团队频道或共享文档：如果集成可用，告知现在会读取，然后使用适当集成；如果集成不可用，解释无访问权限，建议在 Claude 设置启用连接器或直接粘贴相关内容。
14. 如果用户提到未知实体或项目：询问是否应搜索已连接工具以了解更多；等待用户确认后再搜索。
15. 用户提供上下文时，跟踪已了解和尚不清楚的内容。
16. 当用户表示初始倾倒完成或已提供大量上下文后，基于上下文缺口生成 5-10 个编号澄清问题；告知用户可简写回答（如「1: yes, 2: see #channel, 3: no because backwards compat」）、链接更多文档、指向频道阅读或继续信息倾倒。
17. 退出条件：当问题显示理解——能在无需解释基础的情况下询问边缘情况和权衡时，上下文足够。
18. 过渡：询问用户是否还想提供更多上下文，或是否进入起草；如果想添加，允许；准备好后进入 Stage 2。
19. 进入 Stage 2 后，先明确目标：通过头脑风暴、策展和迭代精炼逐节构建文档。
20. 向用户说明文档将逐节构建；每节流程：1 询问要包含什么澄清问题；2 头脑风暴 5-20 个选项；3 用户指示保留/删除/合并；4 起草该节；5 通过精准编辑精炼。从未知最多的节开始（通常是核心决策/提案），然后处理其余部分。
21. 节排序：如果文档结构清晰，问用户想从哪节开始；建议从未知最多的节开始；决策文档通常是核心提案，规格通常是技术方案，总结节最好留到最后。
22. 如果用户不知道需要哪些节：根据文档类型和模板建议 3-5 个合适节；询问该结构是否可行或是否想调整。
23. 结构达成后：创建初始文档结构，为所有节放占位文本。
24. 如果可访问 artifacts：使用 `create_file` 创建 artifact；告知将创建含所有节标题和占位符的初始结构；用所有节标题和简短占位文本如「[To be written]」或「[Content here]」创建 artifact；提供 scaffold 链接并说明可以填充每节。
25. 如果无 artifacts：在工作目录创建 markdown 文件，适当命名（如 `decision-doc.md`、`technical-spec.md`）；告知将创建含所有节标题和占位文本的初始结构；创建文件；确认文件名已创建并说明可以填充每节。
26. 对每节 Step 1 澄清问题：宣布开始 [SECTION NAME] 节；基于上下文和节目的生成 5-10 个具体问题，询问应包含什么；告知可简写回答或指出重要覆盖点。
27. Step 2 头脑风暴：为该节头脑风暴 5-20 个可能包含项，取决于复杂程度；寻找可能被遗忘的共享上下文、尚未提到的角度或考虑；生成 5-20 个编号选项；最后提出如需要可再头脑风暴更多。
28. Step 3 策展：询问哪些点应保留、删除或合并；要求简短理由以帮助了解后续节优先级；提供示例：「Keep 1,4,7,9」「Remove 3 (duplicates 1)」「Remove 6 (audience already knows this)」「Combine 11 and 12」。
29. 如果用户给自由反馈（如「looks good」或「I like most of it but...」）而不是编号选择：提取其偏好并继续；解析保留/删除/更改并应用。
30. Step 4 缺口检查：基于用户选择，询问 [SECTION NAME] 节是否缺少重要内容。
31. Step 5 起草：使用 `str_replace` 将该节占位文本替换为根据选择写出的实际草稿；宣布现在起草 [SECTION NAME] 节。
32. 如果使用 artifacts：起草后提供 artifact 链接；请用户通读并指出要改什么；说明具体反馈有助于学习后续节。
33. 如果使用文件（无 artifacts）：起草后确认完成；告知 [SECTION NAME] 节已在 [filename] 起草；请用户通读并指出要改什么；说明具体反馈有助于学习后续节。
34. 起草第一节时包含关键用户指令：不要直接编辑文档，而是指出要改什么；这有助于学习其风格供后续节使用。例如：「Remove the X bullet - already covered by Y」或「Make the third paragraph more concise」。
35. Step 6 迭代精炼：用户反馈时，用 `str_replace` 做编辑（绝不要重印整个文档）；如果使用 artifacts，每次编辑后提供 artifact 链接；如果使用文件，只需确认编辑完成；如果用户直接编辑文档并要求读取，记住其更改并用于后续节（体现其偏好）。
36. 继续迭代直到用户对该节满意。
37. 质量检查：连续 3 次迭代无实质更改后，询问是否可删除任何内容而不丢失重要信息；该节完成时确认 [SECTION NAME] 完成；询问是否准备进入下一节；对所有节重复。
38. 接近完成时（80%+ 节完成），宣布打算重读整个文档并检查：跨节流畅性和一致性；冗余或矛盾；任何像「slop」或通用填充的内容；每句话是否有分量；读取整个文档并提供反馈。
39. 所有节起草和精炼后：宣布所有节已起草；表示打算再完整审阅一次；审查整体连贯性、流畅性、完整性；提供最终建议；询问是否准备进入 Reader Testing，或还想精炼。
40. 进入 Stage 3 后，先明确目标：用全新的 Claude（无上下文污染）测试文档，验证对读者有效。
41. 向用户说明：现在测试文档是否对读者有效；捕捉盲点——作者觉得合理但可能困惑他人的地方。
42. 如果可访问 sub-agents（如 Claude Code）：直接执行测试，无需用户参与。
43. 子代理测试 Step 1 预测读者问题：宣布打算预测读者尝试发现该文档时可能问什么；生成 5-10 个读者现实会问的问题。
44. 子代理测试 Step 2 用子代理测试：宣布这些问题将用全新 Claude 实例（无本次对话上下文）测试；对每个问题，仅用文档内容和问题调用子代理；总结 Reader Claude 每个问题答对/答错什么。
45. 子代理测试 Step 3 运行额外检查：宣布将做额外检查；调用子代理检查歧义、错误假设、矛盾；总结发现的问题。
46. 子代理测试 Step 4 报告并修复：如发现问题，报告 Reader Claude 在具体问题上挣扎；列出具体问题；表示打算修复这些缺口；回到问题节精炼。
47. 如果无 sub-agents（如 claude.ai 网页界面）：用户需手动测试。
48. 手动测试 Step 1 预测读者问题：问人们尝试发现该文档时可能问什么；他们会在 Claude.ai 输入什么；生成 5-10 个读者现实会问的问题。
49. 手动测试 Step 2 设置测试：提供说明：1 打开全新 Claude 对话 https://claude.ai；2 粘贴或分享文档内容（如使用启用连接器的共享文档平台，提供链接）；3 向 Reader Claude 提生成的问题。对每个问题，指示 Reader Claude 提供：答案；是否有任何模糊或不清楚；文档假设已知道什么知识/上下文。检查 Reader Claude 是否给出正确答案或误解任何内容。
50. 手动测试 Step 3 额外检查：也问 Reader Claude：「What in this doc might be ambiguous or unclear to readers?」「What knowledge or context does this doc assume readers already have?」「Are there any internal contradictions or inconsistencies?」
51. 手动测试 Step 4 根据结果迭代：问 Reader Claude 错在哪里或挣扎什么；表示打算修复这些缺口；回到问题节精炼。
52. 退出条件（两种方法）：当 Reader Claude 持续正确回答问题且未浮现新缺口或歧义时，文档准备好。
53. Final Review：Reader Testing 通过后，宣布文档已通过 Reader Claude 测试；完成前：1 建议用户自己做最终通读——他们拥有此文档并负责质量；2 建议双重检查任何事实、链接或技术细节；3 询问他们验证是否达到期望影响；问是否要再审查一次或工作完成。
54. 如果用户想要最终审查，提供；否则宣布文档完成，并提供最终提示：考虑在附录中链接此对话，使读者看到文档如何开发；使用附录提供深度而不膨胀主文档；随着真实读者反馈更新文档。
55. 语气：直接且程序化；当影响用户行为时简要解释理由；不要试图推销方法——只需执行。
56. 处理偏离：如果用户想跳过阶段，问是否想跳过并自由写作；如果用户沮丧，承认比预期更长，建议更快推进的方法；始终给用户调整流程的自主权。
57. 上下文管理：全程如果提到某事缺少上下文，主动询问；不要让缺口累积——出现即解决。
58. Artifact 管理：用 `create_file` 起草完整节；用 `str_replace` 进行所有编辑；每次更改后提供 artifact 链接；绝不用 artifacts 做头脑风暴列表——那只是对话。
59. 质量优于速度：不要匆忙推进阶段；每次迭代应有意义改进；目标是对读者真正有效的文档。

适用边界 · 注意事项

• 用户明确拒绝结构化流程或只想自由格式写作时，不要强制使用。
• 文档极短、简单或只需局部润色时，逐节头脑风暴与读者测试成本过高。
• 没有共享文档集成、artifacts 或 sub-agents 时，部分步骤需手动降级；若无法模拟读者测试且不愿手动测试，则不适合完整流程。