name: doc-coauthoring description: 指导用户通过一个结构化的文档协作工作流。当用户想要编写文档、提案、技术规范、决策文档或类似结构化内容时使用。这个工作流帮助用户高效传递上下文、通过迭代精炼内容，并验证文档对读者有效。当用户提到写作文档、创建提案、起草规范或类似文档任务时触发。 license: MIT

文档协作工作流

这个技能提供了一个结构化的工作流，指导用户通过协作文档创建。作为主动引导者，引导用户经历三个阶段：上下文收集、精炼与结构化、读者测试。

何时提供此工作流

触发条件：

用户提到编写文档：“写文档”、“起草提案”、“创建规范”、“撰写”
用户提到特定文档类型：“产品需求文档”、“设计文档”、“决策文档”、“请求评论”
用户似乎正在开始一个重要的写作任务

初始提供： 为用户提供一个结构化的文档协作工作流。解释三个阶段：

上下文收集： 用户提供所有相关上下文，同时 Claude 询问澄清问题
精炼与结构化： 通过头脑风暴和编辑迭代构建每个部分
读者测试： 用一个无上下文的 Claude 测试文档，以在他人阅读前发现盲点

解释这种方法有助于确保文档在他人阅读时有效（包括当他们粘贴到 Claude 中时）。询问他们是否想尝试这个工作流或偏好自由形式工作。

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

阶段 1：上下文收集

目标： 缩小用户知识和 Claude 知识之间的差距，以便后续进行智能指导。

初始问题

首先询问用户关于文档的元上下文：

这是什么类型的文档？（例如，技术规范、决策文档、提案）
主要受众是谁？
有人阅读时希望产生什么影响？
是否有模板或特定格式要遵循？
有任何其他约束或上下文需要了解？

告知他们可以用简写或任何方式回答。

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

询问是否有模板文档可以分享
如果他们提供共享文档链接，使用适当的集成来获取
如果他们提供文件，读取它

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

使用适当的集成读取当前状态
检查是否有图像没有 alt-text
如果图像存在没有 alt-text，解释当他人使用 Claude 理解文档时，Claude 将无法看到它们。询问是否希望生成 alt-text。如果是，请求他们粘贴每个图像到聊天中以生成描述性 alt-text。

信息转储

一旦初始问题得到回答，鼓励用户转储所有拥有的上下文。请求信息如：

项目/问题的背景
相关团队讨论或共享文档
为什么替代方案未被使用
组织上下文（团队动态、过去事件、政治）
时间压力或约束
技术架构或依赖
利益相关者关切

建议他们不要担心组织 – 只需全部输出。提供多种方式提供上下文：

信息转储自由联想
指向团队频道或线程阅读
链接到共享文档

如果有集成可用（例如，Slack、Teams、Google Drive、SharePoint 或其他 MCP 服务器），提及其可用于直接拉入上下文。

如果没有检测到集成且在 Claude.ai 或 Claude 应用程序中： 建议他们可以在 Claude 设置中启用连接器，以允许直接从消息应用和文档存储拉入上下文。

告知他们在初始转储完成后将询问澄清问题。

在上下文收集期间：

如果用户提到团队频道或共享文档：
- 如果集成可用：告知内容现在将读取，然后使用适当的集成
- 如果集成不可用：解释缺乏访问权限。建议他们在 Claude 设置中启用连接器，或直接粘贴相关内容。
如果用户提到未知实体/项目：
- 询问是否应搜索连接工具以了解更多
- 等待用户确认后再搜索
当用户提供上下文时，跟踪正在学习的内容和仍然不清楚的内容

询问澄清问题：

当用户表示已完成初始转储（或提供大量上下文后），询问澄清问题以确保理解：

生成 5-10 个编号问题，基于上下文中的差距。

告知他们可以用简写回答（例如，“1: 是，2: 见 #channel，3: 不因为向后兼容”），链接到更多文档，指向频道阅读，或继续信息转储。以最高效率为准。

退出条件： 当问题显示理解时，即收集到足够上下文 – 当可以询问边缘情况和权衡而无需解释基础知识时。

过渡： 询问在此阶段是否有更多上下文要提供，或是否该继续起草文档。

如果用户想添加更多，让他们添加。当准备好时，进入阶段 2。

阶段 2：精炼与结构化

目标： 通过头脑风暴、策展和迭代精炼逐部分构建文档。

给用户的指示： 解释文档将逐部分构建。对于每个部分：

将询问澄清问题关于要包括的内容
将头脑风暴 5-20 个选项
用户将指示保留/移除/合并的内容
将起草该部分
将通过精准编辑精炼它

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

部分排序：

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

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

如果用户不知道需要哪些部分：基于文档类型和模板，建议 3-5 个适合文档类型的部分。

询问这个结构是否有效，或是否要调整它。

一旦结构达成一致：

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

如果有对工件的访问权限： 使用 create_file 创建一个工件。这给了 Claude 和用户一个支架。

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

创建工件，包含所有部分标题和简要占位符文本如 “[待写]” 或 “[内容在此]”。

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

如果没有对工件的访问权限： 在工作目录中创建一个 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] 部分。

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

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

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

告知 [SECTION NAME] 部分已在 [filename] 中起草。请求他们阅读并指示要更改的内容。注意，具体化有助于学习下一部分。

给用户的关键指示（在起草第一部分时包括）： 提供一个注释：代替直接编辑文档，请他们指示要更改的内容。这有助于学习他们的风格。例如：“移除 X 点 – 已被 Y 覆盖” 或 “让第三段更简洁”。

步骤 6：迭代精炼

当用户提供反馈时：

使用 str_replace 进行编辑（从不重新打印整个文档）
如果使用工件： 每次编辑后提供工件链接
如果使用文件： 只需确认编辑完成
如果用户直接编辑文档并要求读取：记下他们所做的更改并在未来部分记住（这显示他们的偏好）

继续迭代 直到用户对部分满意。

质量检查

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

当部分完成时，确认 [SECTION NAME] 完成。询问是否准备好移动到下一部分。

重复所有部分。

接近完成

当接近完成（80%+ 的部分完成）时，宣布意图重新阅读整个文档并检查：

各部分之间的流程和一致性
冗余或矛盾
任何感觉像 “垃圾” 或通用填充的内容
每个句子是否都承载重量

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

当所有部分起草并精炼时： 宣布所有部分已起草。指示意图再次查看完整文档。

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

提供任何最终建议。

询问是否准备好移动到读者测试，或是否想进一步精炼任何内容。

阶段 3：读者测试

目标： 用一个无上下文的 Claude（无上下文渗漏）测试文档，以验证对读者有效。

给用户的指示： 解释现在将进行测试，以查看文档是否实际对读者有效。这捕获盲点 – 对作者有道理但可能困惑他人的内容。

测试方法

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

直接进行测试，无需用户介入。

步骤 1：预测读者问题

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

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

步骤 2：用子代理测试

宣布这些问题将用一个新鲜的 Claude 实例（无此对话的上下文）测试。

对于每个问题，仅用文档内容和问题调用一个子代理。

总结对于每个问题，Reader Claude 正确/错误地得到了什么。

步骤 3：运行额外检查

宣布将执行额外检查。

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

总结发现的任何问题。

步骤 4：报告和修复

如果发现问题：报告 Reader Claude 在特定问题上挣扎。

列出具体问题。

指示意图修复这些差距。

循环回有问题的部分进行精炼。

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

用户需要手动进行测试。

步骤 1：预测读者问题

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

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

步骤 2：设置测试

提供测试指示：

打开一个新的 Claude 对话：https://claude.ai
粘贴或分享文档内容（如果使用有连接器启用的共享文档平台，提供链接）
向 Reader Claude 询问生成的问题

对于每个问题，指示 Reader Claude 提供：

答案
是否有任何内容模糊或不清楚
文档假设读者已经知道什么知识/上下文

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

步骤 3：额外检查

也问 Reader Claude：

“这篇文档中什么对读者可能模糊或不清楚？”
“这篇文档假设读者已经有什么知识或上下文？”
“有任何内部矛盾或不一致吗？”

步骤 4：基于结果迭代

询问 Reader Claude 出错或挣扎的地方。指示意图修复那些差距。

循环回有问题的部分进行精炼。

退出条件（两种方法）

当 Reader Claude 一致正确回答问题且未出现新差距或模糊时，文档准备就绪。

最终审查

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

建议他们自己进行最终阅读 – 他们拥有此文档并对质量负责
建议双重检查任何事实、链接或技术细节
要求他们验证是否达到他们想要的影响

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

如果用户想要最终审查，提供。否则： 宣布文档完成。提供一些最终提示：

考虑在附录中链接此对话，以便读者可以看到文档是如何开发的
使用附录提供深度而不膨胀主文档
当从真实读者收到反馈时更新文档

有效指导的提示

语调：

直接和程序化
当影响用户行为时简要解释理由
不要试图 “推销” 方法 – 只需执行它

处理偏差：

如果用户想跳过一个阶段：询问他们是否想跳过此并以自由形式写作
如果用户似乎沮丧：承认这比预期花费更长。建议加快的方法
始终给用户调整过程的自主权

上下文管理：

在整个过程中，如果提到某事缺少上下文，主动询问
不要让差距积累 – 在它们出现时解决

工件管理：

使用 create_file 起草完整部分
使用 str_replace 进行所有编辑
每次更改后提供工件链接
从不使用工件进行头脑风暴列表 – 那只是对话

质量胜过速度：

不要急于完成阶段
每次迭代应做出有意义的改进
目标是实际对读者有效的文档