# Doc Coauthoring

> 引导用户完成协作文档创建的结构化工作流。作为主动引导者，带领用户经历三个阶段：上下文收集、精炼与结构、读者测试。

- Skill: `kscz0000/doc-coauthoring` (Agent Skill)
- Install (CLI): `npx skillmds@latest add kscz0000/doc-coauthoring`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kscz0000/doc-coauthoring/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: kscz0000 (https://skillmd.com/u/kscz0000)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/kscz0000/doc-coauthoring

---


# 文档协作工作流

本技能提供结构化工作流，引导用户完成协作文档创建。作为主动引导者，带领用户经历三个阶段：上下文收集、精炼与结构、读者测试。

## 何时提供此工作流

**触发条件：**
- 用户提到撰写文档："写个文档"、"起草提案"、"创建规格"、"写出来"
- 用户提到特定文档类型："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 个适合该文档类型的章节。

询问此结构是否可行，或是否需要调整。

**结构确定后：**

创建初始文档结构，所有章节使用占位符文本。

**如果可访问 artifacts：**
使用 `create_file` 创建 artifact。这为 Claude 和用户提供可工作的脚手架。

告知将创建带有所有章节标题占位符的初始结构。

创建包含所有章节标题和简短占位文本（如"[待填写]"或"[内容在此]"）的 artifact。

提供脚手架链接并指出是时候填写每个章节了。

**如果无法访问 artifacts：**
在工作目录中创建 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` 将此章节的占位文本替换为实际起草的内容。

宣布现在将根据他们的选择起草 [章节名称] 章节。

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

请他们通读并指出需要更改的内容。注意具体反馈有助于为后续章节学习。

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

告知 [章节名称] 章节已在 [文件名] 中起草完成。请他们通读并指出需要更改的内容。注意具体反馈有助于为后续章节学习。

**给用户的关键说明（起草第一章时包含）：**
提供说明：请他们不要直接编辑文档，而是指出需要更改的内容。这有助于学习他们的风格以用于后续章节。例如："删除 X 要点 - 已被 Y 涵盖"或"让第三段更简洁"。

### 步骤 6：迭代精炼

当用户提供反馈时：
- 使用 `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` 进行所有编辑
- 每次更改后提供 artifact 链接
- 绝不将 artifacts 用于头脑风暴列表——那只是对话

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

## 何时使用
本技能适用于执行概述中描述的工作流或操作。

## 局限性
- 仅当任务明显符合上述描述范围时使用此技能。
- 不要将输出视为环境特定验证、测试或专家审查的替代品。
- 如果缺少所需输入、权限、安全边界或成功标准，停止并请求澄清。