三阶段
- 上下文收集
- 精炼与结构
- 读者测试
文档协作 (doc-coauthoring)
文档协作（doc-coauthoring）
Section titled “文档协作（doc-coauthoring）”doc-coauthoring 是用于协作创建文档的技能。它的核心是：通过结构化工作流帮助用户高效创建文档，从上下文收集到迭代精炼，再到读者测试。
作为文档撰写者，你可能遇到过：
- “想写文档但不知道从哪里开始”
- “写出来的文档别人看不懂”
- “不知道结构怎么组织”
doc-coauthoring 就是解决这些的。
当用户提到：- 写文档："write a doc"- 创建提案："draft a proposal"- 设计规范："create a spec"- 类似写作任务
文档类型：- PRD（产品需求文档）- 设计文档- 决策文档- RFC三阶段工作流：
1. 上下文收集 - 用户提供背景 - Claude 提问澄清
2. 精炼与结构 - 迭代构建各部分 - 头脑风暴 + 编辑
3. 读者测试 - 用全新 Claude 测试 - 发现盲点阶段 1：上下文收集
Section titled “阶段 1：上下文收集”缩小用户知道的和 Claude 知道的之间的差距首先问用户：
1. 这是什么类型的文档？ （技术规范、决策文档、提案）
2. 主要受众是谁？
3. 希望达到什么效果？
4. 有模板或特定格式吗？
5. 其他约束或背景？鼓励用户倾倒所有上下文：
需要的信息：- 项目/问题的背景- 相关讨论或共享文档- 为什么不用其他方案- 组织背景（团队动态、过往事件）- 时间压力或约束- 技术架构或依赖- 利益相关者关注点
用户不需要组织 - 只需要全部说出来在用户完成初始倾倒后：
生成 5-10 个基于上下文差距的问题
用户可以用简写回答："1: 是的, 2: 见 #channel, 3: 不因为向后兼容"当问题显示理解后退出：- 可以问边界情况和权衡- 不需要解释基础
过渡：问是否还有更多上下文，或者可以开始起草了阶段 2：精炼与结构
Section titled “阶段 2：精炼与结构”通过头脑风暴、筛选和迭代精炼来构建文档告诉用户：文档将逐节构建。每节：1. 问澄清问题2. 头脑风暴 5-20 个选项3. 用户指示保留/删除/合并4. 起草该节5. 通过编辑迭代精炼
从不确定性最多的部分开始（通常是核心提案/技术方案）如果文档结构清晰：问想从哪节开始
建议：- 决策文档：核心提案- 技术规范：技术方案- 摘要：最后写1. 澄清问题
Section titled “1. 澄清问题”宣布开始 [章节名] 节问 5-10 个关于应该包含什么的问题2. 头脑风暴
Section titled “2. 头脑风暴”为 [章节名] 节头脑风暴 5-20 个可能包含的内容寻找：- 可能忘记的上下文- 尚未提到的角度
生成 5-20 个编号选项问哪些要点应该保留、删除或合并请求简要理由以帮助学习优先级
示例：- "保留 1,4,7,9"- "删除 3（重复 1）"- "删除 6（受众已知道）"- "合并 11 和 12"4. 差距检查
Section titled “4. 差距检查”根据选择，问 [章节名] 节是否遗漏重要内容用 str_replace 将占位符替换为实际起草的内容
注意：- 提供文档链接- 让用户指出要改什么- 建议具体修改方式6. 迭代精炼
Section titled “6. 迭代精炼”用户反馈时：- 用 str_replace 编辑- 每次编辑后提供链接- 继续迭代直到用户满意
3 次连续迭代无实质性变化后：问是否可以删除而不丢失重要信息当接近完成（80%+ 部分完成）：- 重新阅读整篇文档- 检查：流程和一致性、冗余或矛盾、是否泛泛而谈、每句话是否有分量
所有部分起草和精炼后：- 宣布完成- 再次审查整体连贯性、完整性- 提供最终建议阶段 3：读者测试
Section titled “阶段 3：读者测试”用全新的 Claude（无上下文）测试文档验证它对读者是否有效1. 预测读者问题
Section titled “1. 预测读者问题”宣布意图：预测读者可能问的问题
生成 5-10 个实际问题2. 用子代理测试
Section titled “2. 用子代理测试”宣布用全新 Claude 实例测试这些问题
每个问题：- 调用子代理- 只给文档内容和问题
总结每个问题读者 Claude 的对/错3. 额外检查
Section titled “3. 额外检查”执行额外检查：- 模糊性- 错误假设- 矛盾4. 报告和修复
Section titled “4. 报告和修复”发现的问题：- 报告具体问题- 列出具体问题
意图修复这些差距回到精炼阶段当读者 Claude 始终正确回答问题没有新的差距或模糊文档就准备好了通过读者测试后：
1. 建议他们自己通读 - 文档所有权属于他们 - 负责质量
2. 建议核实： - 事实、链接、技术细节 - 是否达到预期效果
问是否需要更多审查，或者工作完成
完成后：- 考虑在附录中链接此对话- 使用附录提供深度而不膨胀正文- 根据真实读者反馈更新文档- 直接和程序化- 简洁解释原理- 不要"推销"方法 - 只是执行2. 处理偏差
Section titled “2. 处理偏差”- 用户想跳过阶段：问是否跳过- 用户似乎沮丧：承认并建议更快的方法- 总是给用户调整过程的自主权3. 上下文管理
Section titled “3. 上下文管理”- 缺少上下文时主动问- 不要让差距积累4. 质量优先
Section titled “4. 质量优先”- 不要匆忙完成阶段- 每次迭代应有有意义的改进- 目标是真正对读者有效的文档每节步骤
- 澄清问题
- 头脑风暴
- 筛选
- 起草
- 精炼
工具
- str_replace 编辑
- 头脑风暴列表
- 文档链接
原则
- 质量优先
- 受众导向
- 迭代改进
查看源文件: GitHub原始文件