# doc-coauthoring

> 技能工具 - 专业的技能工具

- Author: sanwenjing
- Repository: sanwenjing/opencode
- Version: 20260204091223
- Stars: 0
- Forks: 0
- Last Updated: 2026-02-06
- Source: https://github.com/sanwenjing/opencode
- Web: https://mule.run/skillshub/@@sanwenjing/opencode~doc-coauthoring:20260204091223

---

---
name: doc-coauthoring
description: "技能工具 - 专业的技能工具"
license: 专有。LICENSE.txt 包含完整条款
---

---
name: doc-coauthoring
description: "---
name: doc-coauthoring
description: 指导用户通过结构化工作流程进行协作编写文档。当用户需要编写文档、提案、技术规范、决策文档或类似结构化内容时使用此技能。此工作流程帮助用户高效地传递上下文、通过迭代完善内容，并验证文档对读者的有效性。当用户提及编写文档、创建提案、起草规范或类似文档任务时触发此技能。
---

 文档协作编写工作流程

此技能提供结构化工作流程，指导用户进行协作式文档创建。作为积极指导者，引导用户完成三个阶段：上下文收集、完善与结构、读者测试。

 何时提供此工作流程

**触发条件：**
- 用户提及编写文档："write a doc", "draft a proposal", "create a spec", "write up"
- 用户提及特定文档类型："PRD", "design doc", "decision doc", "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: yes, 2: see channel, 3: no because backwards compat"），链接到更多文档，指向频道进行阅读，或者继续信息倾倒。以他们最有效的方式为准。

**退出条件：**
当问题显示出理解能力时，即收集了足够的上下文 - 能够就边缘情况和权衡进行提问而无需解释基础知识。

**过渡：**
询问在此阶段他们是否想提供更多上下文，或者是否是时候开始起草文档了。

如果用户想添加更多内容，让他们添加。准备就绪后，进行第二阶段。

 第二阶段：完善与结构

**目标：**通过头脑风暴、策划和迭代完善逐节构建文档。

**给用户的指示：**
解释将逐节构建文档。对于每个部分：
1. 将提出关于包含内容的澄清问题
2. 将进行 5-20 个选项的头脑风暴
3. 用户将指示保留/删除/合并什么
4. 将起草该部分
5. 通过精确编辑进行完善

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

**部分排序：**

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

建议从有最多未知数的部分开始。对于决策文档，通常是核心提案。对于规范，通常是技术方法。摘要部分最好留到最后。

如果用户不知道需要什么部分：
根据文档类型和模板，建议适合该文档类型的 3-5 个部分。

询问这个结构是否可行，或者他们是否想调整它。

**一旦结构达成一致：**

用占位符文本为所有部分创建初始文档结构。

**如果有访问构件的权限：**
使用 `create_file` 创建构件。这为 Claude 和用户提供了一个可以工作的脚手架。

告知将创建带有所有部分占位符的初始结构。

创建包含所有部分标题和简要占位符文本如"[待编写]"或"[内容在此]"的构件。

提供脚手架链接并指示是时候填充每个部分了。

**如果没有访问构件的权限：**
在工作目录中创建 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` 将此部分的占位符文本替换为实际起草的内容。

宣布将根据他们选择的内容现在起草 [部分名称] 部分。

**如果使用构件：**
起草后，提供构件链接。

要求他们通读并指示要更改的内容。注意具体化有助于学习下一部分。

**如果使用文件（无构件）：**
起草后，确认完成。

告知 [部分名称] 部分已在 [文件名] 中起草。要求他们通读并指示要更改的内容。注意具体化有助于学习下一部分。

**给用户的关键指示（在起草第一部分时包括）：**
提供说明：不要直接编辑文档，而是要求他们指示要更改的内容。这有助于学习他们的风格以供未来部分使用。例如："删除 X 要点 - 已由 Y 涵盖"或"让第三段更简洁"。

 第六步：迭代完善

随着用户提供反馈：
- 使用 `str_replace` 进行编辑（永不重印整个文档）
- **如果使用构件：**每次编辑后提供构件链接
- **如果使用文件：**只确认编辑完成
- 如果用户直接编辑文档并要求读取：在心中记录他们所做的更改并在未来部分中记住它们（这显示了他们的偏好）

**继续迭代**直到用户对该部分满意为止。

 质量检查

在连续 3 次迭代没有实质性更改后，询问是否可以在不丢失重要信息的情况下删除任何内容。

当部分完成时，确认 [部分名称] 已完成。询问是否准备好进入下一部分。

**对所有部分重复。**

 接近完成

当接近完成（80%+ 部分完成）时，宣布意图重新阅读整个文档并检查：
- 各部分之间的流程和一致性
- 冗余或矛盾
- 任何感觉像"泥浆"或通用填充物的内容
- 每个句子是否有分量

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

**当所有部分都起草和完善时：**
宣布所有部分已起草。表示意图再次审查完整文档。

审查整体连贯性、流程、完整性。

提供任何最终建议。

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

 第三阶段：读者测试

**目标：**用全新的 Claude（无上下文泄露）测试文档，以验证它对读者有效。

**给用户的指示：**
解释现在将进行测试以查看文档是否真的对读者有效。这可以发现盲点 - 对作者来说有意义但可能让他人困惑的事情。

 测试方法

**如果有访问子代理的权限（例如，在 Claude Code 中）：**

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

 第一步：预测读者问题

宣布意图预测读者在尝试发现此文档时可能提出的问题。

生成 5-10 个读者会现实地提出的问题。

 第二步：用子代理测试

宣布这些问题将与新的 Claude 实例（无来自此对话的上下文）进行测试。

对于每个问题，调用子代理，只提供文档内容和问题。

总结阅读 Claude 在每个问题上正确/错误的内容。

 第三步：运行额外检查

宣布将进行额外检查。

调用子代理检查模糊性、错误假设、矛盾。

总结发现的任何问题。

 第四步：报告和修复

如果发现问题：
报告阅读 Claude 在特定问题上遇到困难。

列出具体问题。

表示意图修复这些空白。

循环回到有问题的部分进行完善。

---

**如果没有访问子代理的权限（例如，claude.ai 网页界面）：**

用户将需要手动进行测试。

 第一步：预测读者问题

询问人们在尝试发现此文档时可能提出什么问题。他们会在 Claude.ai 中输入什么？

生成 5-10 个读者会现实地提出的问题。

 第二步：设置测试

提供测试指示：
1. 打开新的 Claude 对话：https://claude.ai
2. 粘贴或分享文档内容（如果使用启用连接器的共享文档平台，提供链接）
3. 向阅读 Claude 提出生成的问题

对于每个问题，指示阅读 Claude 提供：
- 答案
- 是否有任何模糊或不清楚的内容
- 文档假设读者已经了解什么知识/上下文

检查阅读 Claude 是否给出正确答案或误解任何内容。

 第三步：额外检查

同时询问阅读 Claude：
- "此文档中什么内容对读者可能模糊或不清楚？"
- "此文档假设读者已经具备什么知识或上下文？"
- "是否有任何内部矛盾或不一致？"

 第四步：根据结果迭代

询问阅读 Claude 错误或遇到困难的内容。表示意图修复那些空白。

循环回到任何有问题的部分进行完善。

---

 退出条件（两种方法）

当阅读 Claude 一致地正确回答问题且没有发现新空白或模糊性时，文档就准备好了。

 最终审查

当读者测试通过时：
宣布文档已通过阅读 Claude 测试。在完成之前：

1. 建议他们自己做最终通读 - 他们拥有此文档并对其质量负责
2. 建议双重检查任何事实、链接或技术细节
3. 询问他们验证是否达到了他们期望的影响

询问他们是否想要最后一次审查，或者工作是否完成。

**如果用户想要最终审查，提供它。否则：**
宣布文档完成。提供一些最终提示：
- 考虑在附录中链接此对话，以便读者可以看到文档是如何开发的
- 使用附录提供深度而不膨胀主文档
- 根据真实读者的反馈更新文档

 有效指导的提示

**语调：**
- 直接和程序化
- 当影响用户行为时简要解释理由
- 不要试图"推销"方法 - 只需执行它

**处理偏离：**
- 如果用户想跳过阶段：询问他们是否想跳过这个并自由形式写作
- 如果用户似乎感到沮丧：承认这比预期花费的时间更长。建议加快速度的方法
- 始终给用户调整过程的自主权

**上下文管理：**
- 整个过程中，如果提到的内容缺少上下文，主动询问
- 不要让空白累积 - 出现时就解决它们

**构件管理：**
- 使用 `create_file` 起草完整部分
- 对所有编辑使用 `str_replace`
- 每次更改后提供构件链接
- 永远不要将构件用于头脑风暴列表 - 那只是对话

**质量优于速度：**
- 不要匆忙通过阶段
- 每次迭代都应该进行有意义的改进
- 目标是真正对读者有效的文档 - 专业的技能工具，用于..."
license: 专有。LICENSE.txt 包含完整条款
---

---
name: doc-coauthoring
description: 指导用户通过结构化工作流程进行协作编写文档。当用户需要编写文档、提案、技术规范、决策文档或类似结构化内容时使用此技能。此工作流程帮助用户高效地传递上下文、通过迭代完善内容，并验证文档对读者的有效性。当用户提及编写文档、创建提案、起草规范或类似文档任务时触发此技能。
---

# 文档协作编写工作流程

此技能提供结构化工作流程，指导用户进行协作式文档创建。作为积极指导者，引导用户完成三个阶段：上下文收集、完善与结构、读者测试。

## 何时提供此工作流程

**触发条件：**
- 用户提及编写文档："write a doc", "draft a proposal", "create a spec", "write up"
- 用户提及特定文档类型："PRD", "design doc", "decision doc", "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: yes, 2: see #channel, 3: no because backwards compat"），链接到更多文档，指向频道进行阅读，或者继续信息倾倒。以他们最有效的方式为准。

**退出条件：**
当问题显示出理解能力时，即收集了足够的上下文 - 能够就边缘情况和权衡进行提问而无需解释基础知识。

**过渡：**
询问在此阶段他们是否想提供更多上下文，或者是否是时候开始起草文档了。

如果用户想添加更多内容，让他们添加。准备就绪后，进行第二阶段。

## 第二阶段：完善与结构

**目标：**通过头脑风暴、策划和迭代完善逐节构建文档。

**给用户的指示：**
解释将逐节构建文档。对于每个部分：
1. 将提出关于包含内容的澄清问题
2. 将进行 5-20 个选项的头脑风暴
3. 用户将指示保留/删除/合并什么
4. 将起草该部分
5. 通过精确编辑进行完善

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

**部分排序：**

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

建议从有最多未知数的部分开始。对于决策文档，通常是核心提案。对于规范，通常是技术方法。摘要部分最好留到最后。

如果用户不知道需要什么部分：
根据文档类型和模板，建议适合该文档类型的 3-5 个部分。

询问这个结构是否可行，或者他们是否想调整它。

**一旦结构达成一致：**

用占位符文本为所有部分创建初始文档结构。

**如果有访问构件的权限：**
使用 `create_file` 创建构件。这为 Claude 和用户提供了一个可以工作的脚手架。

告知将创建带有所有部分占位符的初始结构。

创建包含所有部分标题和简要占位符文本如"[待编写]"或"[内容在此]"的构件。

提供脚手架链接并指示是时候填充每个部分了。

**如果没有访问构件的权限：**
在工作目录中创建 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` 将此部分的占位符文本替换为实际起草的内容。

宣布将根据他们选择的内容现在起草 [部分名称] 部分。

**如果使用构件：**
起草后，提供构件链接。

要求他们通读并指示要更改的内容。注意具体化有助于学习下一部分。

**如果使用文件（无构件）：**
起草后，确认完成。

告知 [部分名称] 部分已在 [文件名] 中起草。要求他们通读并指示要更改的内容。注意具体化有助于学习下一部分。

**给用户的关键指示（在起草第一部分时包括）：**
提供说明：不要直接编辑文档，而是要求他们指示要更改的内容。这有助于学习他们的风格以供未来部分使用。例如："删除 X 要点 - 已由 Y 涵盖"或"让第三段更简洁"。

### 第六步：迭代完善

随着用户提供反馈：
- 使用 `str_replace` 进行编辑（永不重印整个文档）
- **如果使用构件：**每次编辑后提供构件链接
- **如果使用文件：**只确认编辑完成
- 如果用户直接编辑文档并要求读取：在心中记录他们所做的更改并在未来部分中记住它们（这显示了他们的偏好）

**继续迭代**直到用户对该部分满意为止。

### 质量检查

在连续 3 次迭代没有实质性更改后，询问是否可以在不丢失重要信息的情况下删除任何内容。

当部分完成时，确认 [部分名称] 已完成。询问是否准备好进入下一部分。

**对所有部分重复。**

### 接近完成

当接近完成（80%+ 部分完成）时，宣布意图重新阅读整个文档并检查：
- 各部分之间的流程和一致性
- 冗余或矛盾
- 任何感觉像"泥浆"或通用填充物的内容
- 每个句子是否有分量

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

**当所有部分都起草和完善时：**
宣布所有部分已起草。表示意图再次审查完整文档。

审查整体连贯性、流程、完整性。

提供任何最终建议。

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

## 第三阶段：读者测试

**目标：**用全新的 Claude（无上下文泄露）测试文档，以验证它对读者有效。

**给用户的指示：**
解释现在将进行测试以查看文档是否真的对读者有效。这可以发现盲点 - 对作者来说有意义但可能让他人困惑的事情。

### 测试方法

**如果有访问子代理的权限（例如，在 Claude Code 中）：**

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

### 第一步：预测读者问题

宣布意图预测读者在尝试发现此文档时可能提出的问题。

生成 5-10 个读者会现实地提出的问题。

### 第二步：用子代理测试

宣布这些问题将与新的 Claude 实例（无来自此对话的上下文）进行测试。

对于每个问题，调用子代理，只提供文档内容和问题。

总结阅读 Claude 在每个问题上正确/错误的内容。

### 第三步：运行额外检查

宣布将进行额外检查。

调用子代理检查模糊性、错误假设、矛盾。

总结发现的任何问题。

### 第四步：报告和修复

如果发现问题：
报告阅读 Claude 在特定问题上遇到困难。

列出具体问题。

表示意图修复这些空白。

循环回到有问题的部分进行完善。

---

**如果没有访问子代理的权限（例如，claude.ai 网页界面）：**

用户将需要手动进行测试。

### 第一步：预测读者问题

询问人们在尝试发现此文档时可能提出什么问题。他们会在 Claude.ai 中输入什么？

生成 5-10 个读者会现实地提出的问题。

### 第二步：设置测试

提供测试指示：
1. 打开新的 Claude 对话：https://claude.ai
2. 粘贴或分享文档内容（如果使用启用连接器的共享文档平台，提供链接）
3. 向阅读 Claude 提出生成的问题

对于每个问题，指示阅读 Claude 提供：
- 答案
- 是否有任何模糊或不清楚的内容
- 文档假设读者已经了解什么知识/上下文

检查阅读 Claude 是否给出正确答案或误解任何内容。

### 第三步：额外检查

同时询问阅读 Claude：
- "此文档中什么内容对读者可能模糊或不清楚？"
- "此文档假设读者已经具备什么知识或上下文？"
- "是否有任何内部矛盾或不一致？"

### 第四步：根据结果迭代

询问阅读 Claude 错误或遇到困难的内容。表示意图修复那些空白。

循环回到任何有问题的部分进行完善。

---

### 退出条件（两种方法）

当阅读 Claude 一致地正确回答问题且没有发现新空白或模糊性时，文档就准备好了。

## 最终审查

当读者测试通过时：
宣布文档已通过阅读 Claude 测试。在完成之前：

1. 建议他们自己做最终通读 - 他们拥有此文档并对其质量负责
2. 建议双重检查任何事实、链接或技术细节
3. 询问他们验证是否达到了他们期望的影响

询问他们是否想要最后一次审查，或者工作是否完成。

**如果用户想要最终审查，提供它。否则：**
宣布文档完成。提供一些最终提示：
- 考虑在附录中链接此对话，以便读者可以看到文档是如何开发的
- 使用附录提供深度而不膨胀主文档
- 根据真实读者的反馈更新文档

## 有效指导的提示

**语调：**
- 直接和程序化
- 当影响用户行为时简要解释理由
- 不要试图"推销"方法 - 只需执行它

**处理偏离：**
- 如果用户想跳过阶段：询问他们是否想跳过这个并自由形式写作
- 如果用户似乎感到沮丧：承认这比预期花费的时间更长。建议加快速度的方法
- 始终给用户调整过程的自主权

**上下文管理：**
- 整个过程中，如果提到的内容缺少上下文，主动询问
- 不要让空白累积 - 出现时就解决它们

**构件管理：**
- 使用 `create_file` 起草完整部分
- 对所有编辑使用 `str_replace`
- 每次更改后提供构件链接
- 永远不要将构件用于头脑风暴列表 - 那只是对话

**质量优于速度：**
- 不要匆忙通过阶段
- 每次迭代都应该进行有意义的改进
- 目标是真正对读者有效的文档