name: 文档协作编写 description: 引导用户通过结构化工作流程进行协作文档编写。当用户想要编写文档、提案、技术规格、决策文档或类似结构化内容时使用。此工作流程帮助用户高效转移上下文、通过迭代精炼内容，并验证文档对读者的有效性。在用户提到编写文档、创建提案、起草规格或类似文档任务时触发。
文档协作编写工作流程
此技能提供了一个结构化工作流程，用于指导用户进行协作文档创建。充当主动引导者，带领用户通过三个阶段：上下文收集、精炼与结构和读者测试。
何时提供此工作流程
触发条件：
- 用户提到编写文档：“写一个文档”、“起草提案”、“创建规格”、“撰写”
- 用户提到特定文档类型：“PRD”、“设计文档”、“决策文档”、“RFC”
- 用户似乎正在开始一个实质性的写作任务
初始提供： 为用户提供一个用于协作编写文档的结构化工作流程。解释三个阶段：
- 上下文收集：用户提供所有相关上下文，同时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进行所有编辑 - 每次更改后提供工件链接
- 切勿使用工件进行头脑风暴列表 - 那只是对话
质量优先于速度：
- 不要匆忙通过各阶段
- 每次迭代应做出有意义的改进
- 目标是创建一个确实对读者有效的文档