名称： 文档协同创作
描述： 引导用户完成结构化的文档协同创作流程。适用于用户需要撰写文档、提案、技术规范、决策文档或类似结构化内容时。此流程帮助用户高效传递上下文、通过迭代优化内容，并验证文档对读者的有效性。当用户提及撰写文档、创建提案、起草规范或类似文档任务时触发。

文档协同创作流程

本技能提供了一个结构化的工作流程，用于引导用户完成协作式文档创作。请扮演积极的引导者角色，带领用户完成三个阶段：上下文收集、优化与结构化、读者测试。

何时提供此流程

触发条件：
- 用户提及撰写文档："写一份文档"、"起草提案"、"创建规范"、"撰写"
- 用户提及特定文档类型："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 个适合该文档类型的部分。

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

一旦结构达成一致：

创建初始文档结构，为所有部分添加占位文本。

如果可访问工件：
使用 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% 以上的部分已完成），宣布将重新阅读整个文档并检查：
- 各部分之间的流程和一致性
- 冗余或矛盾之处
- 任何感觉像"敷衍"或通用填充的内容
- 每个句子是否都有分量

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

当所有部分都已起草并优化时：
宣布所有部分已起草。表明将再次审查完整文档。

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

提供任何最终建议。

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

第三阶段：读者测试

目标： 用全新的 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. 请用户验证文档是否达到了他们期望的影响

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

如果用户想要最终审查，请提供。否则：
宣布文档完成。提供一些最终提示：
- 考虑在附录中链接此对话，以便读者了解文档是如何开发的
- 使用附录提供深度内容而不使主文档臃肿
- 当收到真实读者的反馈时更新文档

有效指导技巧

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

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

上下文管理：
- 在整个过程中，如果提到某事物时缺少上下文，主动询问
- 不要让空白累积——在出现时解决

工件管理：
- 使用 create_file 起草完整部分
- 使用 str_replace 进行所有编辑
- 每次更改后提供工件链接
- 切勿使用工件进行头脑风暴列表——那只是对话

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