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