--- name: doc-coauthoring description: "引导用户通过结构化工作流程进行文档协作。当用户想要编写文档、提案、技术规范、决策文档或类似结构化内容时使用。此工作流程帮助用户高效传递上下文、通过迭代精炼内容，并验证文档对读者有效。触发词：writing docs、creating proposals、drafting specs 或类似文档任务。" license: MIT --- # 文档协作工作流程 提供结构化工作流程，引导用户进行协作文档创建。作为主动指南，引导用户通过三个阶段：上下文收集、精炼与结构、读者测试。 ## 何时提供此工作流程 **触发条件**：用户提到编写文档、特定文档类型（PRD、设计文档、决策文档、RFC）、似乎要开始大量写作任务。 **初始提供**：向用户提供结构化文档协作工作流程。解释三个阶段：1) 上下文收集：用户提供所有相关上下文，Claude 问澄清问题；2) 精炼与结构：通过头脑风暴与编辑迭代构建每个部分；3) 读者测试：用全新 Claude（无上下文）测试文档，在他人阅读前捕获盲点。 如果用户拒绝，自由形式工作。如果接受，进行阶段 1。 ## 阶段 1：上下文收集 **目标**：缩小用户知道与 Claude 知道之间的差距，使后续能提供智能指导。 ### 初始问题 询问文档的元上下文：文档类型、主要受众、期望影响、是否有模板或特定格式、任何其他约束或上下文。 **如果用户提供模板或提到文档类型**：询问是否有模板文档可分享；如提供共享文档链接，使用适当集成获取；如提供文件，读取它。 **如果用户提到编辑现有共享文档**：使用适当集成读取当前状态；检查无 alt 文本的图像；如存在无 alt 文本的图像，解释当他人使用 Claude 理解文档时 Claude 无法看到它们，询问是否要生成 alt 文本。 ### 信息转储 一旦初始问题回答，鼓励用户转储所有上下文。请求信息如：项目/问题背景、相关团队讨论或共享文档、为何不使用替代方案、组织上下文、时间线压力或约束、技术架构或依赖、利益相关者担忧。 建议他们不必担心组织—只需全部输出。提供多种提供上下文方式：信息转储意识流、指向团队频道或线程阅读、链接到共享文档。 **如果集成可用**（如 Slack、Teams、Google Drive、SharePoint 或其他 MCP 服务器），提及这些可用于直接拉入上下文。 **如果未检测到集成且在 Claude.ai 或 Claude 应用**：建议他们可以在 Claude 设置中启用连接器，以允许直接从消息应用与文档存储拉入上下文。 **上下文收集期间**：如果用户提到团队频道或共享文档，如集成可用则使用适当集成读取；如不可用则解释缺少访问，建议启用连接器或直接粘贴相关内容。如果用户提到未知实体/项目，询问是否应搜索连接工具以了解更多，等待用户确认再搜索。 **问澄清问题**：当用户表示已完成初始转储（或提供大量上下文后），生成 5-10 个编号问题基于上下文中的差距。告知他们可用简写回答、链接到更多文档、指向要阅读的频道，或继续信息转储。 **退出条件**：当问题显示理解时—当可以询问边缘情况与权衡而不需要解释基础时，已收集足够上下文。 **过渡**：询问在此阶段是否还有更多上下文要提供，或是否该继续起草文档。 ## 阶段 2：精炼与结构 **目标**：通过头脑风暴、策划与迭代精炼逐部分构建文档。 **给用户的说明**：解释文档将逐部分构建。对每个部分：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）」「合并 11 和 12」。 **如果用户给出自由形式反馈**而非编号选择，提取其偏好并继续。解析他们想要保留/删除/更改的内容并应用。 ### 步骤 4：差距检查 基于他们选择的，询问 [部分名称] 部分是否缺少任何重要内容。 ### 步骤 5：起草 使用 `str_replace` 将此部分的占位符文本替换为实际起草内容。宣布将基于他们选择的起草 [部分名称] 部分。 **如果使用工件**：起草后，提供工件链接。请他们通读并指示要更改什么。注意具体有助于学习下一部分。 **如果使用文件（无工件）**：起草后，确认完成。告知 [部分名称] 部分已在 [文件名] 中起草。请他们通读并指示要更改什么。注意具体有助于学习下一部分。 **给用户的关键说明**（起草第一部分时包含）：提供说明：与其直接编辑文档，请他们指示要更改什么。这有助于学习他们的风格用于未来部分。例如：「删除 X 要点—已由 Y 覆盖」或「使第三段更简洁」。 ### 步骤 6：迭代精炼 当用户提供反馈时：使用 `str_replace` 进行编辑（绝不重新打印整个文档）；**如果使用工件**：每次编辑后提供工件链接；**如果使用文件**：仅确认编辑完成；如果用户直接编辑文档并请求阅读：注意他们所做的更改并记住用于未来部分（这显示他们的偏好）。 **继续迭代**直到用户对部分满意。 ### 质量检查 在 3 次连续迭代无实质性更改后，询问是否可以删除任何内容而不丢失重要信息。 当部分完成，确认 [部分名称] 完成。询问是否准备移动到下一部分。 **对所有部分重复。** ### 接近完成 当接近完成（80%+ 部分完成）时，宣布将重新阅读整个文档并检查：跨部分流程与一致性、冗余或矛盾、任何感觉像「垃圾」或通用填充的内容、每个句子是否承载重量。 阅读整个文档并提供反馈。 **当所有部分已起草与精炼**：宣布所有部分已起草。指示将再次审查完整文档。审查整体连贯性、流程、完整性。提供任何最终建议。询问是否准备移动到读者测试，或是否要精炼其他内容。 ## 阶段 3：读者测试 **目标**：用全新 Claude（无上下文泄漏）测试文档，验证它对读者有效。 **给用户的说明**：解释现在将进行测试以查看文档是否实际对读者有效。这捕获盲点—对作者有意义但可能混淆他人的内容。 ### 测试方法 **如果子代理访问可用**（如 Claude Code）：直接执行测试，无需用户参与。 ### 步骤 1：预测读者问题 宣布将预测读者在尝试发现此文档时可能问的问题。生成 5-10 个读者会现实地问的问题。 ### 步骤 2：用子代理测试 宣布将用全新 Claude 实例（无此对话上下文）测试这些问题。 对每个问题，仅用文档内容与问题调用子代理。 总结读者 Claude 对每个问题做对/做错什么。 ### 步骤 3：运行额外检查 宣布将执行额外检查。调用子代理检查歧义、错误假设、矛盾。总结发现的任何问题。 ### 步骤 4：报告与修复 如发现问题：报告读者 Claude 在特定问题上遇到困难。列出具体问题。指示将修复这些差距。循环回精炼以处理有问题部分。 --- **如果无子代理访问**（如 claude.ai Web 界面）：用户需要手动进行测试。 ### 步骤 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` 进行所有编辑；每次更改后提供工件链接；绝不使用工件进行头脑风暴列表—那只是对话。 **质量优于速度**：不要匆忙通过阶段；每次迭代应做出有意义的改进；目标是实际对读者有效的文档。