文档协同创作工作流程

此技能提供了一个结构化的流程，用于引导用户完成协作文档创建。作为主动引导者，带领用户经历三个阶段：上下文收集、优化与结构、以及读者测试。

何时提供此工作流程

触发条件：

• 用户提到编写文档：“写一个文档”、“起草一份提案”、“创建一个规范”、“撰写”
• 用户提到特定的文档类型：“PRD”、“设计文档”、“决策文档”、“RFC”
• 用户似乎要开始一个重要的写作任务

初步提议：
向用户提供一个用于协同创作文档的结构化工作流程。解释三个阶段：

1. 上下文收集：用户提供所有相关背景，同时 Claude 提出澄清性问题
2. 优化与结构：通过头脑风暴和编辑，迭代地构建每个部分
3. 读者测试：用一个全新的 Claude（无上下文）测试文档，以便在其他人阅读前发现盲点

解释这种方法有助于确保文档在其他人阅读时（包括当他们把文档粘贴给 Claude 时）也能很好地工作。询问他们是愿意尝试此工作流程，还是更喜欢自由形式的工作方式。

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

第一阶段：上下文收集

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

初步问题

首先询问用户关于文档的元背景：

1. 这是什么类型的文档？（例如，技术规范、决策文档、提案）
2. 主要受众是谁？
3. 当有人阅读本文档时，期望产生什么影响？
4. 是否有需要遵循的模板或特定格式？
5. 有任何其他约束或背景需要了解吗？

告知他们可以用速记或任何对他们最有效的方式回答或提供信息。

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

• 询问他们是否有可共享的模板文档
• 如果他们提供了共享文档的链接，使用相应的集成工具获取它
• 如果他们提供了文件，则读取文件

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

• 使用相应的集成工具读取当前状态
• 检查是否存在没有替代文本的图像
• 如果存在没有替代文本的图像，解释当其他人使用 Claude 理解文档时，Claude 将无法看到它们。询问他们是否需要生成替代文本。如果需要，请他们将每张图片粘贴到聊天中以便为其生成描述性的替代文本。

信息倾泻

在初步问题得到回答后，鼓励用户倾泻他们拥有的所有背景信息。请求的信息包括：

• 项目/问题的背景
• 相关的团队讨论或共享文档
• 为何没有采用替代方案
• 组织背景（团队动态、过往事件、政治因素）
• 时间压力或约束
• 技术架构或依赖项
• 利益相关者的顾虑

建议他们不必担心组织问题——只管把所有东西都说出来。提供多种提供背景的方式：

• 意识流式地倾泻信息
• 指向团队频道或主题以供阅读
• 链接到共享文档

如果集成了相关工具（例如，Slack, Teams, Google Drive, SharePoint 或其他 MCP 服务器），提及这些工具可用于直接获取上下文。

如果未检测到集成，并且在 claude.ai 或 Claude 应用中：建议他们可以在 Claude 设置中启用连接器，以便直接从消息应用和文档存储中获取上下文。

告知他们，在他们完成初步信息倾泻后，将会提出一些澄清性问题。

在上下文收集期间：

• 如果用户提到了团队频道或共享文档：
  • 如果集成了可用工具：告知他们将立即读取内容，然后使用相应的集成工具
  • 如果集成工具不可用：解释无法访问。建议他们在 Claude 设置中启用连接器，或直接粘贴相关内容。
• 如果用户提到了未知的实体/项目：
  • 询问是否应该搜索已连接的工具以了解更多信息
  • 在搜索前等待用户确认
• 随着用户提供上下文，记录已了解的内容以及仍不清楚的地方

提出澄清性问题：

当用户表示他们已完成初步信息倾泻（或在提供了大量上下文之后），提出澄清性问题以确保理解：

根据上下文中的缺失信息，生成 5-10 个编号的问题。

告知他们可以使用速记来回答（例如，“1: 是”、“2: 见 #频道”、“3: 否，因为向后兼容”），链接到更多文档，指向要阅读的频道，或者继续倾泻信息。选择对他们最高效的方式。

退出条件：
当提出的问题表明已充分理解时——能够询问边缘情况和权衡，而无需解释基础知识，则说明已收集到足够的上下文。

过渡：
询问他们在这个阶段是否还有更多上下文要提供，或者是否可以进入文档起草阶段。

如果用户想补充更多内容，就让他们补充。当他们准备好时，进入第二阶段。

第二阶段：优化与结构

目标：通过头脑风暴、筛选和迭代优化，逐节构建文档。

给用户的说明：
解释将逐节构建文档。对于每一节：

1. 会提出关于该节应包含内容的澄清性问题
2. 会头脑风暴出 5-20 个选项
3. 用户指出保留/删除/合并哪些内容
4. 会起草该节内容
5. 通过精细化编辑进行优化

从未知因素最多的部分开始（通常是核心决策/提案），然后处理其余部分。

章节顺序：

如果文档结构清晰：
询问他们想从哪个部分开始。

建议从未知因素最多的部分开始。对于决策文档，这通常是核心提案。对于规范文档，这通常是技术方案。总结部分最好留到最后。

如果用户不知道需要哪些部分：
根据文档类型和模板，建议适合该文档类型的 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% 以上的部分）时，宣布打算重新通读整个文档，检查：

• 各部分之间的流畅性和一致性
• 冗余或矛盾之处
• 任何感觉像是“陈词滥调”或通用填充的内容
• 是否每句话都有分量

阅读整个文档并提供反馈。

当所有部分都起草并优化完成后：
宣布所有部分已起草完成。表示打算再次审查完整文档。

审查整体连贯性、流畅性和完整性。

提供任何最终建议。

询问是否准备好进入读者测试，或者是否想进一步完善其他内容。

第三阶段：读者测试

目标：使用一个全新的 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. 请他们验证文档是否达到了预期的效果

询问他们是希望再进行一次审查，还是工作已完成。

如果用户希望进行最终审查，则提供审查。否则：
宣布文档完成。提供一些最终建议：

• 考虑在附录中链接此次对话，以便读者了解文档的演变过程
• 使用附录提供深度信息，而不会使主文档过于臃肿
• 随着收到真实读者的反馈，更新文档

有效引导的技巧

语气：

• 直接且按程序行事
• 在影响用户行为时简要解释理由
• 不要试图“推销”这种方法——直接执行即可

处理偏离：

• 如果用户想跳过某个阶段：询问他们是否想跳过并自由写作
• 如果用户显得沮丧：承认这比预期花费了更长时间。建议可以更快推进的方式
• 始终让用户有能力调整流程

上下文管理：

• 在整个过程中，如果缺少所提及内容的上下文，主动提问
• 不要让缺口累积——在它们出现时就解决

作品管理：

• 使用 create_file 起草完整章节
• 对所有编辑使用 str_replace
• 每次更改后提供作品链接
• 切勿将作品用于头脑风暴列表——那只是对话

质量重于速度：

• 不要仓促完成各阶段
• 每次迭代都应做出有意义的改进
• 目标是创建一份真正对读者有效的文档