文档协作工作流程

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

何时提供此工作流程

触发条件：用户提到编写文档、特定文档类型（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 进行所有编辑；每次更改后提供工件链接；绝不使用工件进行头脑风暴列表—那只是对话。
质量优于速度：不要匆忙通过阶段；每次迭代应做出有意义的改进；目标是实际对读者有效的文档。