文档协作工作流

引导用户通过三个阶段完成协作文档创作：上下文收集 → 迭代完善 → 读者测试。

何时使用此工作流

触发条件:

用户提及撰写文档："写文档"、"起草提案"、"创建规格"
用户提及具体文档类型：PRD、设计文档、决策文档、RFC
用户似乎要开始一个较大的写作任务

初始引导: 向用户介绍三阶段工作流：

上下文收集: 用户提供所有相关背景，AI 提出澄清问题
迭代完善: 逐节构建文档，通过头脑风暴和编辑迭代
读者测试: 用全新视角测试文档，捕捉盲点

询问用户是否愿意使用此工作流，还是更喜欢自由撰写。

阶段 1：上下文收集

目标: 缩小用户知识与 AI 认知之间的差距。

初始问题

这是什么类型的文档？（技术规格、决策文档、提案等）
主要读者是谁？
读者读完后期望产生什么影响？
是否有模板或特定格式要求？
其他需要了解的约束或背景？

信息倾倒

鼓励用户倾倒所有已有背景信息：

项目/问题背景
相关讨论或文档
为什么不采用替代方案
组织背景（团队动态、历史事件）
时间压力或约束
技术架构或依赖
利益相关者关切

告知用户不必组织内容 — 尽管倾倒。

澄清问题

用户完成初始信息倾倒后，生成 5-10 个编号的澄清问题。用户可用简写回答（如"1: 是, 2: 因为兼容性, 3: 否"）。

退出条件: 能够询问边界情况和权衡问题，而不需要基础概念解释时，上下文收集足够。

阶段 2：迭代完善

目标: 逐节构建文档。

节结构确定

如果文档结构清晰，询问从哪个节开始。建议从未知最多的节开始（决策文档通常是核心提案，技术规格通常是技术方案）。摘要节留到最后。

如果用户不确定需要哪些节，根据文档类型建议 3-5 个节。

每节的处理流程

步骤 1：澄清问题 针对该节询问 5-10 个关于应包含内容的具体问题。

步骤 2：头脑风暴 根据节的复杂度头脑风暴 5-20 个可能包含的要点。寻找：

用户分享的可能被遗忘的背景
尚未提及的角度或考量

步骤 3：筛选 询问保留/删除/合并哪些要点。示例：

"保留 1,4,7,9"
"删除 3（与1重复）"
"合并 11 和 12"

步骤 4：缺口检查 基于选择的内容，询问是否遗漏了重要内容。

步骤 5：起草 根据文档类型选择合适的工具：

Markdown 文档：使用 create_file_or_folder 创建文件 + rewrite_file 写入内容
Word/PDF 正式文档：使用 create_document 创建（type 为 "word" 或通过 document_convert 转 PDF）

步骤 6：迭代细化 根据用户反馈使用 edit_file（Markdown/代码文件）或 edit_document（Word/Excel 文件）进行精确编辑。不要重新输出整个文档。持续迭代直到用户满意。

质量检查: 连续 3 次迭代无实质变化后，询问是否有可以删除而不影响信息的内容。

接近完成时

完成 80%+ 的节后，重新通读整个文档，检查：

跨节的流畅性和一致性
冗余或矛盾
空洞的"水分"内容
每句话是否都有价值

阶段 3：读者测试

目标: 用全新视角验证文档对读者有效。

步骤 1：预测读者问题

生成 5-10 个读者实际会问的问题。

步骤 2：测试

使用子智能体（无上下文污染）或请用户在新对话中测试：

只给文档内容和问题
检查 AI 是否能正确回答
检查是否有模糊或不清晰的地方

步骤 3：额外检查

文档中有什么可能模糊或不清楚？
文档假设读者已经知道什么？
是否有内部矛盾或不一致？

步骤 4：修复

根据测试结果回到阶段 2 修复问题节。

退出条件: 读者测试一致通过，无新的缺口或模糊之处。

最终审查

通过读者测试后：

建议用户自己做最终通读 — 他们对文档质量负最终责任
建议双重检查事实、链接或技术细节
询问是否达到了预期影响

完成建议

考虑在附录中链接此对话，展示文档是如何开发的
使用附录提供深度而不膨胀主文档
收到真实读者反馈后更新文档

引导技巧

语气: 直接、程序化，简要解释理由
处理偏离: 用户想跳过某阶段时，询问确认
上下文管理: 发现缺口时立即提问，不让缺口累积
质量优先: 不急于完成，每次迭代应有实质改进

doc-coauthoring