doc-coauthoring

文档协作工作流

本 Skill 提供一套结构化工作流，引导用户完成协作式文档创作。请扮演主动的引导者，带领用户完成三个阶段：背景收集、细化与结构梳理，以及读者测试。

何时提供此工作流

触发条件：

• 用户提到撰写文档，例如“写一份文档”“起草一份提案”“创建一份规格说明”“写一份总结”
• 用户提到具体的文档类型，例如“PRD”“设计文档”“决策文档”“RFC”
• 用户似乎正在开始一项篇幅较大的写作任务

初始提议： 向用户提供一套结构化的文档协作工作流，并说明三个阶段：

1. 背景收集：用户提供所有相关背景，Claude 提出澄清性问题
2. 细化与结构梳理：通过头脑风暴和编辑，逐节迭代完善内容
3. 读者测试：使用一个没有任何上下文的全新 Claude 测试文档，在他人阅读之前发现盲点

说明这种方式有助于确保文档在他人阅读时（包括他们将文档粘贴给 Claude 时）效果良好。询问用户是想尝试此工作流，还是更喜欢自由协作。

如果用户拒绝，则自由协作。如果用户接受，则进入第一阶段。

第一阶段：背景收集

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

初始问题

首先向用户询问关于文档的元信息：

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

告知用户可以用简短的方式回答，也可以按自己的习惯完整提供信息。

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

• 询问其是否有可以共享的模板文档
• 如果用户提供了共享文档的链接，请使用合适的集成工具获取该文档
• 如果用户提供了文件，请读取该文件

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

• 使用合适的集成工具读取文档当前内容
• 检查是否存在缺少替代文本（alt-text）的图片
• 如果存在缺少替代文本的图片，说明当他人使用 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 个适合该文档类型的章节。

询问该结构是否可行，或用户是否希望调整。

结构确定后：

创建包含所有章节占位文本的初始文档结构。

如果可以使用 artifact： 使用 create_file 创建一个 artifact，为 Claude 和用户提供一个可供协作的骨架。

告知用户将创建包含所有章节标题和占位文本的初始结构。

创建包含所有章节标题及简短占位文本的 artifact，例如“[待撰写]”或“[此处填写内容]”。

提供骨架链接，并说明现在可以开始填写各个章节。

如果无法使用 artifact： 在工作目录中创建一个 Markdown 文件。为其取一个合适的名称，例如 decision-doc.md 或 technical-spec.md。

告知用户将创建包含所有章节标题和占位文本的初始结构。

创建包含所有章节标题和占位文本的文件。

确认文件名已创建，并说明现在可以开始填写各个章节。

对每个章节：

第 1 步：澄清问题

宣布开始撰写 [SECTION NAME] 章节。提出 5-10 个关于应包含哪些内容的澄清问题：

根据上下文和章节用途，生成 5-10 个具体问题。

告知用户可以简短回答，或只需指出哪些内容是重点。

第 2 步：头脑风暴

针对 [SECTION NAME] 章节，头脑风暴出可能包含的 [5-20] 项内容，具体数量取决于该章节的复杂程度。重点关注：

• 可能被遗忘的已共享上下文
• 尚未提及的角度或考虑因素

根据章节复杂度生成 5-20 个编号选项。最后，询问用户是否需要更多选项。

第 3 步：筛选

询问哪些要点应保留、删除或合并。请用户简要说明理由，以便为后续章节确定优先级。

提供示例：

• “保留 1、4、7、9”
• “删除 3（与 1 重复）”
• “删除 6（读者已了解该内容）”
• “合并 11 和 12”

如果用户给出自由形式的反馈（例如“看起来不错”或“大部分都可以，但……”），而不是编号选择，则提取其偏好并继续推进。梳理用户希望保留、删除或修改的内容，并据此执行。

第 4 步：遗漏检查

根据用户已选择的内容，询问 [SECTION NAME] 章节是否还遗漏了重要内容。

第 5 步：起草

使用 str_replace，将本节中的占位文本替换为实际起草的内容。

宣布现在将根据用户的选择起草 [SECTION NAME] 部分。

如果使用 artifacts： 起草后，提供 artifact 的链接。

请用户通读内容，并指出需要修改的地方。说明反馈越具体，越有助于后续章节的学习。

如果使用文件（不使用 artifacts）： 起草后，确认已完成。

告知用户 [SECTION NAME] 部分已起草并写入 [filename]。请用户通读内容，并指出需要修改的地方。说明反馈越具体，越有助于后续章节的学习。

给用户的关键说明（起草第一部分时加入）： 提醒用户不要直接编辑文档，而是指出需要修改的地方。这样有助于后续章节更好地学习用户的风格。例如：“删除 X 项——Y 已经涵盖了这部分内容”，或“让第三段更简洁一些”。

第 6 步：迭代优化

用户提供反馈后：

• 使用 str_replace 进行修改（不要重新输出整份文档）
• 如果使用 artifacts： 每次修改后提供 artifact 的链接
• 如果使用文件： 只需确认修改已完成
• 如果用户直接编辑文档并要求你阅读：留意他们所做的修改，并在起草后续章节时记住这些偏好（这能体现你对用户偏好的了解）

继续迭代，直到用户对本节满意。

质量检查

连续 3 次迭代都没有实质性修改后，询问是否可以在不损失重要信息的前提下删减内容。

本节完成后，确认 [SECTION NAME] 已完成。询问用户是否准备好继续下一节。

对所有章节重复此流程。

接近完成时

当完成度达到 80% 或更高时，宣布将重新通读整份文档，并检查以下方面：

• 各章节之间的衔接和一致性
• 冗余或矛盾之处
• 是否有“凑数”或泛泛而谈的内容
• 是否每句话都切实有用

通读整份文档并提供反馈。

所有章节都已起草并优化后： 宣布所有章节均已起草。说明将再对整份文档进行一次审阅。

检查文档的整体连贯性、行文流畅度和完整性。

提出任何最终建议。

询问用户是否准备进入读者测试，或者还想继续优化其他内容。

第 3 阶段：读者测试

目标： 让一位全新的 Claude（不带任何上下文）测试文档，确认读者能否顺利使用。

给用户的说明： 解释现在将进行测试，以确认文档是否真正便于读者使用。这有助于发现盲点——某些内容对作者来说很明白，却可能让其他人感到困惑。

测试方法

如果可以使用子 Agent（例如在 Claude Code 中）：

直接进行测试，无需用户参与。

第 1 步：预测读者会提出的问题

宣布将预测读者在查找本文档时可能会提出的问题。

生成 5～10 个读者实际可能提出的问题。

第 2 步：使用子 Agent 测试

宣布将使用一个全新的 Claude 实例（不带本次对话的上下文）测试这些问题。

针对每个问题，仅向子 Agent 提供文档内容和该问题。

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

第 3 步：进行其他检查

宣布将进行其他检查。

调用子 Agent 检查内容中的歧义、错误假设和矛盾。

总结发现的问题。

第 4 步：报告并修正

如果发现问题： 说明 Reader Claude 在哪些具体问题上遇到了困难。

列出具体问题。

说明将修正这些疏漏。

返回优化流程，处理有问题的章节。

---

用户需要手动进行测试。

第 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 测试通过后： 宣布文档已通过 Reader Claude 测试。完成前：

1. 建议你自己再通读一遍。你是这份文档的所有者，需对其质量负责
2. 建议复核所有事实、链接和技术细节
3. 请你确认文档是否达到了你期望的效果

询问你是否需要再进行一轮审阅，还是工作已经完成。

如果用户需要最终审阅，则提供审阅。否则： 宣布文档完成，并提供以下几点最终建议：

• 考虑在附录中链接本次对话，让读者了解文档的形成过程
• 使用附录补充深度内容，避免主文档过于臃肿
• 根据真实读者的反馈持续更新文档

有效指导的要点

语气：

• 直接且按流程执行
• 当理由会影响用户行为时，简要说明原因
• 不要过度“推销”这种方法，直接执行即可

处理偏离流程的情况：

• 如果用户想跳过某个阶段：询问其是否希望跳过此阶段并自由撰写
• 如果用户显得不耐烦：承认这比预期花费的时间更长，并建议加快进度的方式
• 始终尊重用户调整流程的主导权

上下文管理：

• 在整个过程中，如果提到的某些内容缺少背景信息，主动询问
• 不要让信息缺口积累，遇到就及时处理

产物管理：

• 使用 create_file 起草完整章节
• 所有编辑均使用 str_replace
• 每次修改后都提供产物链接
• 不要用产物来记录头脑风暴列表，那只是对话内容

质量优先于速度：

• 不要急于跨越各个阶段
• 每一轮迭代都应带来实质性改进
• 目标是打造真正对读者有用的文档