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

文档协作撰写工作流

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

何时提供此工作流

触发条件：

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

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

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

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

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

阶段 1：上下文收集

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

初始问题

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

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

告知他们可以用简写或任意方式提供信息。

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

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

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

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

信息倾泻

一旦初始问题回答，鼓励用户倾泻所有上下文。请求信息如：

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

建议他们不要担心组织——只需全部倾泻。提供多种提供上下文的方式：

信息倾泻流式意识
指向团队频道或线程读取
链接到共享文档

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

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

告知他们一旦完成初始倾泻，将询问澄清问题。

在上下文收集期间：

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

询问澄清问题：

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

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

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

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

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

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

阶段 2：精炼与结构

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

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

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

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

部分排序：

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

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

如果用户不知道需要哪些部分：基于文档类型和模板，建议 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%+ 部分完成）时，宣布意图重新读取整个文档并检查：

各部分间的流程和一致性
冗余或矛盾
任何感觉像"冗余"或通用填充的内容
每个句子是否都有分量

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

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

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

提供任何最终建议。

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

阶段 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 进行所有编辑
每次更改后提供工件链接
切勿使用工件进行头脑风暴列表——那只是对话

质量优先于速度：

不要匆忙通过阶段
每次迭代应做出有意义的改进
目标是产生对读者实际有效的文档