---

name: doc-coauthoring slug: doc-coauthoring displayName: 文档协同创作 description: 引导用户通过结构化工作流进行文档协同创作。用于用户想要撰写文档、提案、技术规格、决策文档或类似结构化内容时。该工作流帮助用户高效传递上下文、通过迭代精炼内容，并验证文档对读者是否有效。当用户提及撰写文档、创建提案、起草规格或类似文档任务时触发。 summary: 引导用户通过上下文收集、精炼结构与读者测试三阶段创作文档。 version: 1.0.0

---

文档协同创作工作流

本技能为引导用户进行协作式文档创建提供结构化工作流。作为积极的引导者，带领用户经历三个阶段：上下文收集（Context Gathering）、精炼与结构（Refinement & Structure）、读者测试（Reader Testing）。

何时提供此工作流

触发条件： - 用户提及撰写文档：“写个文档”、“起草一份提案”、“创建一个规格”、“写出来” - 用户提及具体文档类型：“PRD”、“设计文档”、“决策文档”、“RFC” - 用户似乎正要开始一项较大的写作任务

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

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

解释这种方法有助于确保文档在他人（包括将其粘贴进 Claude 时）阅读时也能良好运作。询问他们是否想尝试此工作流，还是倾向于自由发挥式地工作。

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

阶段一：上下文收集

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

初始问题

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

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

告知他们可以用速记方式回答，或以最适合他们的方式倾倒信息。

如果用户提供了模板或提及了文档类型： - 询问他们是否有可分享的模板文档 - 若提供了共享文档链接，使用相应的集成来获取它 - 若提供了文件，则读取它

如果用户提及编辑现有的共享文档： - 使用相应的集成读取当前状态 - 检查是否有缺少替代文本（alt-text）的图片 - 若图片缺少替代文本，解释当他人使用 Claude 理解文档时，Claude 将无法看到它们。询问是否需要生成替代文本。如果需要，请他们将每张图片粘贴到对话中以生成描述性替代文本。

信息倾倒（Info Dumping）

一旦初始问题得到回答，鼓励用户倾倒他们所拥有的所有上下文。请求如下信息： - 项目/问题的背景 - 相关的团队讨论或共享文档 - 为何不使用替代方案 - 组织上下文（团队动态、过往事件、政治因素） - 时间压力或约束 - 技术架构或依赖关系 - 利益相关者的顾虑

建议他们不必担心如何组织——先把所有内容倾泻出来。提供多种提供上下文的方式： - 自由联想式的信息倾倒 - 指向要阅读的团队频道或话题串 - 链接到共享文档

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

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

告知他们，完成初始倾倒后会提出澄清问题。

在上下文收集期间：

• 如果用户提及团队频道或共享文档：
• 若集成可用：告知将立即读取内容，然后使用相应集成

• 若集成不可用：解释无法访问。建议他们在 Claude 设置中启用连接器，或直接粘贴相关内容

• 如果用户提及未知的实体/项目：

• 询问是否应搜索已连接的工具以了解更多

• 在搜索前等待用户确认

• 随着用户提供的上下文，跟踪正在学习的以及仍不清楚的内容

提出澄清问题：

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

根据上下文中的空白，生成 5-10 个编号问题。

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

退出条件： 当问题显示出理解——可以询问边界情况和权衡取舍而无需解释基础概念时，即表示已收集到充足的上下文。

过渡： 询问在此阶段是否还有任何上下文要提供，或者是否该进入起草文档。

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

阶段二：精炼与结构

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

对用户的说明： 解释文档将逐章节构建。对于每个章节： 1. 将提出关于包含内容的澄清问题 2. 将头脑风暴出 5-20 个选项 3. 用户指出要保留/删除/合并哪些 4. 将起草该章节 5. 将通过精细编辑进行精炼

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

章节排序：

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

建议从未知数最多的章节开始。对决策文档而言，通常是核心提案。对规格而言，通常是技术方法。摘要类章节最好留到最后。

如果用户不知道需要哪些章节： 根据文档类型和模板，建议 3-5 个适合该文档类型的章节。

询问此结构是否可行，或他们是否想调整。

一旦结构确定：

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

如果可以访问工件（artifacts）： 使用 create_file 创建一个工件。这为 Claude 和用户都提供了一个可工作的脚手架。

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

创建带有所有章节标题和简短占位符文本（如 “[待撰写]” 或 “[内容在此]”）的工件。

提供脚手架链接，并指示现在该填充每个章节。

如果无法访问工件： 在工作目录中创建一个 markdown 文件。命名适当（例如 decision-doc.md、technical-spec.md）。

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

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

确认文件名已创建，并指示现在该填充每个章节。

对于每个章节：

步骤一：澄清问题

宣布将开始 [章节名称] 章节的工作。提出 5-10 个关于应包含内容的澄清问题：

根据上下文和章节目的生成 5-10 个具体问题。

告知他们可以用速记方式回答，或仅指出需要覆盖的重要内容。

步骤二：头脑风暴

对于 [章节名称] 章节，根据章节复杂度头脑风暴 [5-20] 个可能包含的内容。寻找： - 可能被遗忘的共享上下文 - 尚未提及的角度或考量

根据章节复杂度生成 5-20 个编号选项。最后，若他们需要更多选项，主动提供更多头脑风暴。

步骤三：筛选（Curation）

询问哪些要点应保留、删除或合并。请求简短的理由，以帮助了解后续章节的优先级。

提供示例： - “保留 1、4、7、9” - “删除 3（与 1 重复）” - “删除 6（受众已知此内容）” - “合并 11 和 12”

如果用户给出自由形式的反馈（例如，“看起来不错”或“大部分我喜欢，但……”）而非编号选择，提取他们的偏好并继续。解析他们想要保留/删除/更改的内容并应用它。

步骤四：缺口检查

根据他们选择的内容，询问 [章节名称] 章节是否遗漏了任何重要内容。

步骤五：起草

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

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

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

要求他们通读并指出要更改的内容。注意，具体说明有助于后续章节的学习。

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

告知他们 [章节名称] 章节已在 [文件名] 中起草。要求他们通读并指出要更改的内容。注意，具体说明有助于后续章节的学习。

对用户的重点说明（在起草第一个章节时包含）： 提供一条注释：与其直接编辑文档，不如要求他们指出要更改的内容。这有助于学习他们后续章节的风格。例如：“删除 X 要点 - 已被 Y 覆盖”或“让第三段更简洁”。

步骤六：迭代精炼

当用户提供反馈时： - 使用 str_replace 进行编辑（绝不重印整个文档） - 如果使用工件： 每次编辑后提供指向工件的链接 - 如果使用文件： 仅确认编辑已完成 - 如果用户直接编辑文档并要求阅读：在脑海中记下他们所做的更改，并在后续章节中牢记（这显示了他们的偏好）

持续迭代，直到用户对该章节满意。

质量检查

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

章节完成后，确认 [章节名称] 已完成。询问是否准备好进入下一章节。

对所有章节重复。

接近完成

当接近完成（80%+ 章节已完成）时，宣布打算重新通读整个文档并检查： - 各章节之间的流畅性与一致性 - 冗余或矛盾 - 任何感觉像“水文（slop）”或通用填充的内容 - 每个句子是否都承载着分量

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

当所有章节都已起草并精炼： 宣布所有章节已起草。指示打算再审查一次完整文档。

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

提供任何最终建议。

询问是否准备好进入读者测试，或者是否想精炼其他内容。

阶段三：读者测试

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

对用户的说明： 解释现在将进行测试，看看文档是否真的对读者有效。这能发现盲点——对作者有意义但可能让他人困惑的内容。

测试方法

如果可以访问子智能体（例如在 Claude Code 中）：

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

步骤一：预测读者问题

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

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

步骤二：用子智能体测试

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

对于每个问题，仅使用文档内容和该问题调用一个子智能体。

总结“读者 Claude”对每个问题答对/答错的情况。

步骤三：运行额外检查

宣布将执行额外检查。

调用子智能体检查歧义、错误假设、矛盾。

总结发现的任何问题。

步骤四：报告并修复

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

列出具体问题。

指示打算修复这些缺口。

回到问题章节的精炼环节。

---

如果没有子智能体访问权限（例如 claude.ai 网页界面）：

用户需要手动进行测试。

访问小葱技能站7w4.net，解锁更多实用的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 - 每次更改后提供工件链接 - 绝不将头脑风暴列表用于工件——那只是对话

质量优先于速度： - 不要匆忙走过各阶段 - 每次迭代都应带来有意义的改进 - 目标是产出一份真正对读者有效的文档

这是一款专业且实用的文档协作工具。质量很好，工作流程设计清晰完整，能有效引导用户从零开始产出高质量文档。优势在于步骤细致、考虑周全，支持迭代优化和读者验证，文档产出有保障。主要不足是配置文件中存在小瑕疵需要修复。总体而言值得使用。