文档协作撰写工作流
本技能提供一套结构化工作流，引导用户进行协作式文档创作。充当积极的引导者，带用户走完三个阶段：上下文收集、打磨与结构、读者测试。
何时提供此工作流
触发条件：
- 用户提到写文档："写个文档"、"起草提案"、"创建规格"、"写一下"
- 用户提到具体文档类型："PRD"、"设计文档"、"决策文档"、"RFC"
- 用户似乎要开始一项实质性的写作任务
初始提议：
向用户提供一个结构化的文档协作撰写工作流。解释三个阶段：
- 上下文收集：用户在所有相关上下文已知时，由 Claude 提出澄清性问题
- 打磨与结构：通过头脑风暴与编辑，迭代式构建每个章节
- 读者测试：用一个全新的 Claude（无上下文）测试文档，在他人阅读前发现盲点
解释这个方法有助于确保文档在他人阅读时（包括他们把文档粘贴进 Claude 时）表现良好。问他们是否想尝试此工作流，还是偏好自由形式工作。
若用户拒绝，则以自由形式工作。若接受，进入阶段 1。
阶段 1：上下文收集
目标： 缩小用户已知与 Claude 已知之间的差距，以便后续给出明智引导。
初始问题
先就文档的元上下文向用户提问：
- 这是什么类型的文档？（如：技术规格、决策文档、提案）
- 主要受众是谁？
- 当有人读它时，期望产生什么影响？
- 是否有模板或特定格式要遵循？
- 还有其它需要知道的约束或上下文吗？
告知他们可以用简写回答，或以最适合他们的方式倾倒信息。
若用户提供模板或提到文档类型：
- 问他们是否有可分享的模板文档
- 若他们提供共享文档链接，用适当的集成获取它
- 若他们提供文件，读取它
若用户提到编辑已有的共享文档：
- 用适当的集成读取当前状态
- 检查无 alt-text 的图片
- 若存在无 alt-text 的图片，解释当他人用 Claude 理解文档时，Claude 看不到它们。问是否需要生成 alt-text。若需要，请他们把每张图粘贴进聊天以生成描述性 alt-text。
信息倾倒
初始问题回答后，鼓励用户倾倒他们拥有的所有上下文。请求如下信息：
- 项目/问题的背景
- 相关的团队讨论或共享文档
- 为何不使用其它替代方案
- 组织上下文（团队动态、过往事故、政治）
- 时间线压力或约束
- 技术架构或依赖
- 干系人关切
建议他们不必操心组织——先把所有内容倒出来。提供多种提供上下文的方式：
- 意识流式的倾倒
- 指向要读的团队频道或帖子
- 链接到共享文档
若集成可用（如 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 个适合该文档类型的章节。
问此结构是否可行，或是否要调整。
结构达成一致后：
用占位文本为所有章节创建初始文档结构。
若可访问制品（artifacts）：
用 create_file 创建 artifact。这给 Claude 与用户一个可工作的脚手架。
告知他们将创建带所有章节占位符的初始结构。
创建包含所有章节标题与简短占位文本（如 "[待写]" 或 "[内容在此]"）的 artifact。
提供脚手架链接，并说明该逐章节填充了。
若无法访问制品：
在工作目录创建 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 将该章节占位文本替换为实际起草的内容。
宣布将基于所选内容起草 [章节名] 章节。
若使用制品：
起草后，提供 artifact 链接。
请他们通读并指出要改什么。注意：具体有助于后续章节的学习。
若使用文件（无制品）：
起草后，确认完成。
告知 [章节名] 章节已在 [filename] 中起草。请他们通读并指出要改什么。注意：具体有助于后续章节的学习。
给用户的要点说明（起草首章时包含）：
附注：与其直接编辑文档，请让他们指出要改什么。这有助于学习其风格，用于后续章节。例如："删除 X 要点——已被 Y 覆盖" 或 "让第三段更简洁"。
步骤 6：迭代打磨
当用户提供反馈时：
- 用 str_replace 做编辑（绝不重印整篇文档）
- 若使用制品： 每次编辑后提供 artifact 链接
- 若使用文件： 仅确认编辑完成
- 若用户直接编辑文档并要求读取：在心里记下他们所做更改，并在后续章节中记在心里（这显示了他们的偏好）
持续迭代 直到用户对该章节满意。
质量检查
连续 3 次迭代无实质更改后，问是否能在不丢失重要信息的前提下删除任何内容。
章节完成时，确认 [章节名] 完成。问是否准备好进入下一章节。
对所有章节重复。
接近完成
当接近完成（80%+ 章节完成）时，宣布将重读整篇文档并检查：
- 跨章节的流畅性与一致性
- 冗余或矛盾
- 任何像"水文"或泛泛填充的内容
- 每个句子是否都有分量
通读整篇文档并提供反馈。
当所有章节都起草并打磨后：
宣布所有章节已起草。表明将再整体评审一次。
就整体连贯性、流畅性、完整性做评审。
提供任何最终建议。
问是否准备好进入读者测试，或是否想再打磨什么。
阶段 3：读者测试
目标： 用一个全新的 Claude（无上下文渗漏）测试文档，验证它对读者是否有效。
给用户说明：
解释现在将进行测试，看看文档对读者是否真的有效。这能捕捉盲点——对作者有意义、却可能迷惑他人的内容。
测试方法
若可访问子 agent（如 Claude Code 中）：
直接进行测试，无需用户参与。
步骤 1：预测读者问题
宣布将预测读者在试图发现这篇文档时可能提出的问题。
生成 5-10 个读者会现实提出的问题。
步骤 2：用子 agent 测试
宣布将用一个全新的 Claude 实例（无本对话上下文）测试这些问题。
对每个问题，仅用文档内容与问题调用一个子 agent。
总结 Reader Claude 对每个问题答对/答错的情况。
步骤 3：运行额外检查
宣布将执行额外检查。
调用子 agent 检查歧义、错误假设、矛盾。
总结发现的任何问题。
步骤 4：报告与修复
若发现问题：
报告 Reader Claude 在特定问题上卡住了。
列出具体问题。
表明要修复这些空白的意图。
回到打磨阶段处理有问题的章节。
若无法访问子 agent（如 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 测试。在完结前：
- 建议他们自己做一次最终通读——他们拥有这篇文档，并为其质量负责
- 建议反复核对任何事实、链接或技术细节
- 请他们验证它是否达到了期望的影响
问是否想要再来一次评审，或工作是否已完成。
若用户想要最终评审，提供它。否则：
宣布文档完成。提供几条最终提示：
- 考虑在附录中链接此对话，以便读者看到文档是如何开发的
- 用附录提供深度，而不要使主文档膨胀
- 随着来自真实读者的反馈更新文档
有效引导的提示
语气：
- 直接且程序化
- 当影响用户行为时简要解释理由
- 不要试图"推销"这个方法——直接执行就好
处理偏离：
- 若用户想跳过某阶段：问是否想跳过并以自由形式撰写
- 若用户似乎受挫：承认这比预期耗时。建议加快的方法
- 始终给用户调整流程的自主权
上下文管理：
- 全程，若提及的内容缺少上下文，主动询问
- 不要让空白累积——出现时就处理
制品管理：
- 用 create_file 起草完整章节
- 用 str_replace 做所有编辑
- 每次更改后提供 artifact 链接
- 绝不用制品做头脑风暴列表——那只是对话
质量重于速度：
- 不要匆忙经过各阶段
- 每次迭代应有实质改进
- 目标是产出真正对读者有效的文档
