doc-coauthoringlisted

## 何时使用 当用户要创作一篇**有分量的书面文档**时主动提议本工作流，典型信号： - 提到写文档："写一份文档""起草提案""创建一份 spec""写个材料"。 - 提到具体文档类型：PRD、设计文档、决策文档、RFC。 - 看上去正要开启一项较重的写作任务。 **不该用（负边界）：** - 一句话答复、随手笔记、聊天式短文本。 - 用户明确表示只想自由发挥、不要流程。 - 仅需机械翻译或格式转换，无需共创打磨。 **提议方式：** 简述三阶段——①上下文收集 ②分节精炼 ③读者测试，说明它能确保文档"换个人（或粘进另一个 Claude）也读得懂"。询问采用本流程还是自由写作。用户拒绝则自由写作；接受则进入阶段一。语气直接、按流程推进，不要推销，给用户随时调整流程的自主权。 ## 步骤 ### 阶段一 · 上下文收集 目标：缩小"用户已知"与"模型已知"的差距，为后续提供精准指导。 1. 先问元信息（可速记作答）：①文档类型？②主要读者？③希望读者读后产生什么影响？④有无模板/格式要求？⑤其它约束或背景？ 2. 若有模板/共享文档：请用户提供。给链接则用对应集成（Slack/Teams/Google Drive/SharePoint/MCP 等）拉取；给文件则 Read 读取。 3. 若是编辑已有共享文档：读取现状，检查**无 alt-text 的图片**——提醒用户"他人用 Claude 理解此文档时看不到这些图"，征询是否生成 alt-text。 4. 信息倾倒：鼓励用户把一切背景一股脑倒出（项目背景、相关讨论、为何不用替代方案、组织/政治背景、时间压力、技术架构与依赖、干系人顾虑），不必整理。提到不认识的实体/项目时，先征得同意再用工具检索。 5. 用户倒完后，基于缺口提 **5-10 个编号问题**。 6. **退出条件**：问题已能触及边界情形与权衡、无需再解释基础概念，即上下文充分。询问是否补充，否则进入阶段二。 ### 阶段二 · 分节精炼 目标：逐节通过头脑风暴、筛选、迭代构建文档。 - 先定结构：结构清晰则问从哪节开始；不清晰则按文档类型建议 3-5 个小节。**从未知最多的小节起步**（决策文档通常是核心提案，spec 通常是技术方案），摘要类小节留到最后。 - 结构确定后创建带占位符的初始骨架：有 artifact 能力用 `create_file`；否则在工作目录建 markdown 文件（如 `decision-doc.md`、`technical-spec.md`），各小节填 `[待撰写]`。 **每个小节按 6 步走：** 1. **澄清提问**：就该节提 5-10 个具体问题。 2. **头脑风暴**：按复杂度列 5-20 个编号候选点，留意被遗忘的背景或未提及的角度，末尾可再追加。 3. **筛选**：让用户标 保留/删除/合并 并附简短理由（如"保留 1,4,7""删 3（与 1 重复）""合并 11、12"）；若给自由反馈则解析其意图执行。 4. **查漏**：问还缺什么重要内容。 5. **起草**：用 `str_replace` 把占位符替换为正文，**绝不重印整篇**。 6. **迭代精修**：根据反馈逐处 `str_replace` 修改。**首节起草时务必提示用户**：不要直接改文档，而是**说明要改什么**（如"删掉 X 那条——Y 已覆盖""第三段更精炼些"），以便模型学习其风格用于后续小节。 **质量把关**：连续 3 轮无实质改动时，问"有没有能删掉而不损信息的