内容来源
整理：基于原 32 页幻灯片的结构化重组与阅读优化版。
前段时间看到关于 ai 协作的视频，我觉得说的挺好的，它借用中国传统"道法术器"四层框架组织经验，读起来很轻，用起来很实。并且在此基础上我抽了一个对应的 Skill 感兴趣的朋友可以访问 Codex 协作Skill
阅读顺序：四个层次解决不同问题
| 层次 | 解决什么 | 一句话 |
|---|---|---|
| 道 | 底层判断 | 建立协作时最重要的判断：为什么协作会失焦、失真、失稳 |
| 法 | 协作组织 | 理解任务该怎么组织，而不是直接堆提示词 |
| 术 | 具体打法 | 遇到具体局面时，去找对应打法 |
| 器 | 拿来即用 | 需要马上复制时，直接用模板和通用补充句 |
建议先按"道→法→术→器"理解，再直接用"器"上手。
一页纸速览
如果只记住一句话：用结构降低偏差，用验证确保结果。
- 道 · 三个底层判断：以边界换聚焦、以信息换准确、以文档和验证换稳定。
- 法 · 协作组织：七条组织原则 + 最小闭环五段式 + 推荐骨架。
- 术 · 13 种局面：从诊断、直推到止血、硬切，每种都带模板与误用边界。
- 器 · 开箱即用：4 个组合模板 + 4 条通用补充句 + 技术债 / 防临时解专项。
在单次任务里，七条原则通常可以压缩成一条链：
目标 → 模式 → 约束 → 输出 → 验证
它的价值不在格式本身，而在于提前说清偏差最容易出现的地方。
通用推荐骨架（可直接套用）：
markdown
目标：解决【具体问题】；如果适合，尽量逼近【最终可用状态】。
模式：【直接推进 / 先诊断 / 先复现 / 先收敛计划】。
约束：这次只解决【范围 A】，不扩展到【范围 B】；这次任务属于【长期建设 / 阶段性过渡 / 短期止血】，优先【长期可维护 / 短期可交付】。
输出：先给【判断 / 方案 / 完整计划】，再【落地 / 继续问关键问题】。
验证：通过【测试 / 最小验证步骤 / 验收标准】证明结果有效。第一章 · 道：先讲底层判断
这一章只回答一件事：为什么有些协作会失焦、失真、失稳。
- 以边界换聚焦：不给边界，Codex 就只能平均用力；明确不做什么、什么可妥协、什么不能妥协，结果才会真正聚焦。
- 以信息换准确：你提供的信息密度，决定结果和预期的贴合度；目标、背景、约束和细节说得越清楚，返工越少。
- 以文档和验证换稳定：上下文会衰减，口头共识会丢失；目标、方案、进度要尽早落文档并持续更新，结果还要靠测试或验证闭环来证明。
第二章 · 法：再讲协作如何组织
"法"解决协作组织。目标、边界、阶段、验证，要被组织成一条可执行的链。
七条组织原则
| # | 原则 | 说明 |
|---|---|---|
| 01 | 先收敛，再展开 | 目标、边界、路径不清时，先收敛问题。 |
| 02 | 明确任务的时间尺度 | 长期建设、阶段性过渡、短期止血，是三种不同任务，方案选择标准也不同。 |
| 03 | 根据阶段定模式 | 方案期适合讨论和计划，问题模糊时适合先诊断，修 bug 适合先复现，主线清晰后再进入执行，阶段结束后再独立复查。 |
| 04 | 用结构化表达降低偏差 | 不要想到什么说什么，尽量把请求组织成稳定结构，让目标、约束、输出和验证标准都清楚可读。 |
| 05 | 用文档沉淀阶段共识 | 多轮协作不要只靠会话记忆，目标、方案、决策、进度和风险要尽早外化并持续更新。 |
| 06 | 用验证闭环约束结果 | 不要只停在"已经改了"，要用测试、验收标准或最小验证步骤确认结果真的成立。 |
| 07 | 兜底方案必须显式确认 | 采用临时解前先说明更优路径为何暂不可行；实施前确认，实施后再验证并说明风险与回收方式。 |
闭环链：在单次任务里，这 7 条通常可压缩成"目标 → 模式 → 约束 → 输出 → 验证"。通用骨架见上文"最小闭环"。
第三章 · 术：进入具体局面后，再选择打法
不是零散技巧，而是几类高频局面下的常用打法。先给一张速查表，再逐一展开。
局面速查表（13 打法）
| # | 局面 | 何时用 | 类型 |
|---|---|---|---|
| 01 | [局面未明：先诊断](# 局面 何时用 类型 01 局面未明：先诊断 任务模糊、想先找问题再开工 诊断 02 主线清晰：直接推进 方向清楚、不想频繁确认 执行 03 长期建设：优先可维护 改动后续还会演进 执行 04 短期止血：优先恢复可用 线上问题先恢复、快速止损 止血 05 不需兼容：直接硬切 破坏存量契约且不需兼容层 硬切 06 连续失败：先复盘 反复失败、怀疑方向不对 复盘 07 链路越深：评估停点 投入产出比开始下降、未彻底失败 评估 08 临近收口：补验证闭环 不想停留"代码已改" 验证 09 Bug 场景：先复现 修 bug、先锁定再改 复现 10 多轮协作：先落文档 跨多轮、目标变复杂 文档 11 任务复杂：先收敛计划 目标不清、多分支决策 计划 12 中型项目：按阶段推进 中型项目 / 独立模块 阶段 13 技术债：先挂账 主线中发现技术债，不轻易打断 债务 "#%E6%9C%AF01-%E5%B1%80%E9%9D%A2%E6%9C%AA%E6%98%8E%E5%85%88%E8%AF%8A%E6%96%AD%E4%B8%8D%E6%80%A5%E7%9D%80%E6%94%B9") | 任务模糊、想先找问题再开工 | 诊断 |
| 02 | [主线清晰：直接推进](# 局面 何时用 类型 01 局面未明：先诊断 任务模糊、想先找问题再开工 诊断 02 主线清晰：直接推进 方向清楚、不想频繁确认 执行 03 长期建设：优先可维护 改动后续还会演进 执行 04 短期止血：优先恢复可用 线上问题先恢复、快速止损 止血 05 不需兼容：直接硬切 破坏存量契约且不需兼容层 硬切 06 连续失败：先复盘 反复失败、怀疑方向不对 复盘 07 链路越深：评估停点 投入产出比开始下降、未彻底失败 评估 08 临近收口：补验证闭环 不想停留"代码已改" 验证 09 Bug 场景：先复现 修 bug、先锁定再改 复现 10 多轮协作：先落文档 跨多轮、目标变复杂 文档 11 任务复杂：先收敛计划 目标不清、多分支决策 计划 12 中型项目：按阶段推进 中型项目 / 独立模块 阶段 13 技术债：先挂账 主线中发现技术债，不轻易打断 债务 "#%E6%9C%AF02-%E4%B8%BB%E7%BA%BF%E6%B8%85%E6%99%B0%E7%9B%B4%E6%8E%A5%E6%8E%A8%E8%BF%9B") | 方向清楚、不想频繁确认 | 执行 |
| 03 | [长期建设：优先可维护](# 局面 何时用 类型 01 局面未明：先诊断 任务模糊、想先找问题再开工 诊断 02 主线清晰：直接推进 方向清楚、不想频繁确认 执行 03 长期建设：优先可维护 改动后续还会演进 执行 04 短期止血：优先恢复可用 线上问题先恢复、快速止损 止血 05 不需兼容：直接硬切 破坏存量契约且不需兼容层 硬切 06 连续失败：先复盘 反复失败、怀疑方向不对 复盘 07 链路越深：评估停点 投入产出比开始下降、未彻底失败 评估 08 临近收口：补验证闭环 不想停留"代码已改" 验证 09 Bug 场景：先复现 修 bug、先锁定再改 复现 10 多轮协作：先落文档 跨多轮、目标变复杂 文档 11 任务复杂：先收敛计划 目标不清、多分支决策 计划 12 中型项目：按阶段推进 中型项目 / 独立模块 阶段 13 技术债：先挂账 主线中发现技术债，不轻易打断 债务 "#%E6%9C%AF03-%E7%9B%AE%E6%A0%87%E5%81%8F%E9%95%BF%E6%9C%9F%E5%BB%BA%E8%AE%BE%E4%BC%98%E5%85%88%E9%95%BF%E6%9C%9F%E5%8F%AF%E7%BB%B4%E6%8A%A4") | 改动后续还会演进 | 执行 |
| 04 | [短期止血：优先恢复可用](# 局面 何时用 类型 01 局面未明：先诊断 任务模糊、想先找问题再开工 诊断 02 主线清晰：直接推进 方向清楚、不想频繁确认 执行 03 长期建设：优先可维护 改动后续还会演进 执行 04 短期止血：优先恢复可用 线上问题先恢复、快速止损 止血 05 不需兼容：直接硬切 破坏存量契约且不需兼容层 硬切 06 连续失败：先复盘 反复失败、怀疑方向不对 复盘 07 链路越深：评估停点 投入产出比开始下降、未彻底失败 评估 08 临近收口：补验证闭环 不想停留"代码已改" 验证 09 Bug 场景：先复现 修 bug、先锁定再改 复现 10 多轮协作：先落文档 跨多轮、目标变复杂 文档 11 任务复杂：先收敛计划 目标不清、多分支决策 计划 12 中型项目：按阶段推进 中型项目 / 独立模块 阶段 13 技术债：先挂账 主线中发现技术债，不轻易打断 债务 "#%E6%9C%AF04-%E7%9B%AE%E6%A0%87%E5%81%8F%E7%9F%AD%E6%9C%9F%E6%AD%A2%E8%A1%80%E4%BC%98%E5%85%88%E6%81%A2%E5%A4%8D%E5%8F%AF%E7%94%A8") | 线上问题先恢复、快速止损 | 止血 |
| 05 | [不需兼容：直接硬切](# 局面 何时用 类型 01 局面未明：先诊断 任务模糊、想先找问题再开工 诊断 02 主线清晰：直接推进 方向清楚、不想频繁确认 执行 03 长期建设：优先可维护 改动后续还会演进 执行 04 短期止血：优先恢复可用 线上问题先恢复、快速止损 止血 05 不需兼容：直接硬切 破坏存量契约且不需兼容层 硬切 06 连续失败：先复盘 反复失败、怀疑方向不对 复盘 07 链路越深：评估停点 投入产出比开始下降、未彻底失败 评估 08 临近收口：补验证闭环 不想停留"代码已改" 验证 09 Bug 场景：先复现 修 bug、先锁定再改 复现 10 多轮协作：先落文档 跨多轮、目标变复杂 文档 11 任务复杂：先收敛计划 目标不清、多分支决策 计划 12 中型项目：按阶段推进 中型项目 / 独立模块 阶段 13 技术债：先挂账 主线中发现技术债，不轻易打断 债务 "#%E6%9C%AF05-%E4%B8%8D%E9%9C%80%E8%A6%81%E5%85%BC%E5%AE%B9%E8%BF%87%E6%B8%A1%E7%9B%B4%E6%8E%A5%E7%A1%AC%E5%88%87") | 破坏存量契约且不需兼容层 | 硬切 |
| 06 | [连续失败：先复盘](# 局面 何时用 类型 01 局面未明：先诊断 任务模糊、想先找问题再开工 诊断 02 主线清晰：直接推进 方向清楚、不想频繁确认 执行 03 长期建设：优先可维护 改动后续还会演进 执行 04 短期止血：优先恢复可用 线上问题先恢复、快速止损 止血 05 不需兼容：直接硬切 破坏存量契约且不需兼容层 硬切 06 连续失败：先复盘 反复失败、怀疑方向不对 复盘 07 链路越深：评估停点 投入产出比开始下降、未彻底失败 评估 08 临近收口：补验证闭环 不想停留"代码已改" 验证 09 Bug 场景：先复现 修 bug、先锁定再改 复现 10 多轮协作：先落文档 跨多轮、目标变复杂 文档 11 任务复杂：先收敛计划 目标不清、多分支决策 计划 12 中型项目：按阶段推进 中型项目 / 独立模块 阶段 13 技术债：先挂账 主线中发现技术债，不轻易打断 债务 "#%E6%9C%AF06-%E8%BF%9E%E7%BB%AD%E5%A4%B1%E8%B4%A5%E5%90%8E%E5%85%88%E5%A4%8D%E7%9B%98%E5%86%8D%E7%BB%A7%E7%BB%AD") | 反复失败、怀疑方向不对 | 复盘 |
| 07 | [链路越深：评估停点](# 局面 何时用 类型 01 局面未明：先诊断 任务模糊、想先找问题再开工 诊断 02 主线清晰：直接推进 方向清楚、不想频繁确认 执行 03 长期建设：优先可维护 改动后续还会演进 执行 04 短期止血：优先恢复可用 线上问题先恢复、快速止损 止血 05 不需兼容：直接硬切 破坏存量契约且不需兼容层 硬切 06 连续失败：先复盘 反复失败、怀疑方向不对 复盘 07 链路越深：评估停点 投入产出比开始下降、未彻底失败 评估 08 临近收口：补验证闭环 不想停留"代码已改" 验证 09 Bug 场景：先复现 修 bug、先锁定再改 复现 10 多轮协作：先落文档 跨多轮、目标变复杂 文档 11 任务复杂：先收敛计划 目标不清、多分支决策 计划 12 中型项目：按阶段推进 中型项目 / 独立模块 阶段 13 技术债：先挂账 主线中发现技术债，不轻易打断 债务 "#%E6%9C%AF07-%E9%93%BE%E8%B7%AF%E8%B6%8A%E8%B5%B0%E8%B6%8A%E6%B7%B1%E5%85%88%E8%AF%84%E4%BC%B0%E5%81%9C%E7%82%B9%E5%86%8D%E5%86%B3%E5%AE%9A%E6%98%AF%E5%90%A6%E7%BB%A7%E7%BB%AD") | 投入产出比开始下降、未彻底失败 | 评估 |
| 08 | [临近收口：补验证闭环](# 局面 何时用 类型 01 局面未明：先诊断 任务模糊、想先找问题再开工 诊断 02 主线清晰：直接推进 方向清楚、不想频繁确认 执行 03 长期建设：优先可维护 改动后续还会演进 执行 04 短期止血：优先恢复可用 线上问题先恢复、快速止损 止血 05 不需兼容：直接硬切 破坏存量契约且不需兼容层 硬切 06 连续失败：先复盘 反复失败、怀疑方向不对 复盘 07 链路越深：评估停点 投入产出比开始下降、未彻底失败 评估 08 临近收口：补验证闭环 不想停留"代码已改" 验证 09 Bug 场景：先复现 修 bug、先锁定再改 复现 10 多轮协作：先落文档 跨多轮、目标变复杂 文档 11 任务复杂：先收敛计划 目标不清、多分支决策 计划 12 中型项目：按阶段推进 中型项目 / 独立模块 阶段 13 技术债：先挂账 主线中发现技术债，不轻易打断 债务 "#%E6%9C%AF08-%E4%B8%B4%E8%BF%91%E6%94%B6%E5%8F%A3%E8%A1%A5%E9%AA%8C%E8%AF%81%E9%97%AD%E7%8E%AF") | 不想停留"代码已改" | 验证 |
| 09 | [Bug 场景：先复现](# 局面 何时用 类型 01 局面未明：先诊断 任务模糊、想先找问题再开工 诊断 02 主线清晰：直接推进 方向清楚、不想频繁确认 执行 03 长期建设：优先可维护 改动后续还会演进 执行 04 短期止血：优先恢复可用 线上问题先恢复、快速止损 止血 05 不需兼容：直接硬切 破坏存量契约且不需兼容层 硬切 06 连续失败：先复盘 反复失败、怀疑方向不对 复盘 07 链路越深：评估停点 投入产出比开始下降、未彻底失败 评估 08 临近收口：补验证闭环 不想停留"代码已改" 验证 09 Bug 场景：先复现 修 bug、先锁定再改 复现 10 多轮协作：先落文档 跨多轮、目标变复杂 文档 11 任务复杂：先收敛计划 目标不清、多分支决策 计划 12 中型项目：按阶段推进 中型项目 / 独立模块 阶段 13 技术债：先挂账 主线中发现技术债，不轻易打断 债务 "#%E6%9C%AF09-bug-%E5%9C%BA%E6%99%AF%E5%85%88%E5%A4%8D%E7%8E%B0%E5%86%8D%E4%BF%AE%E5%A4%8D") | 修 bug、先锁定再改 | 复现 |
| 10 | [多轮协作：先落文档](# 局面 何时用 类型 01 局面未明：先诊断 任务模糊、想先找问题再开工 诊断 02 主线清晰：直接推进 方向清楚、不想频繁确认 执行 03 长期建设：优先可维护 改动后续还会演进 执行 04 短期止血：优先恢复可用 线上问题先恢复、快速止损 止血 05 不需兼容：直接硬切 破坏存量契约且不需兼容层 硬切 06 连续失败：先复盘 反复失败、怀疑方向不对 复盘 07 链路越深：评估停点 投入产出比开始下降、未彻底失败 评估 08 临近收口：补验证闭环 不想停留"代码已改" 验证 09 Bug 场景：先复现 修 bug、先锁定再改 复现 10 多轮协作：先落文档 跨多轮、目标变复杂 文档 11 任务复杂：先收敛计划 目标不清、多分支决策 计划 12 中型项目：按阶段推进 中型项目 / 独立模块 阶段 13 技术债：先挂账 主线中发现技术债，不轻易打断 债务 "#%E6%9C%AF10-%E5%A4%9A%E8%BD%AE%E5%8D%8F%E4%BD%9C%E5%85%88%E8%90%BD%E6%96%87%E6%A1%A3%E5%86%8D%E7%BB%A7%E7%BB%AD%E6%8E%A8%E8%BF%9B") | 跨多轮、目标变复杂 | 文档 |
| 11 | [任务复杂：先收敛计划](# 局面 何时用 类型 01 局面未明：先诊断 任务模糊、想先找问题再开工 诊断 02 主线清晰：直接推进 方向清楚、不想频繁确认 执行 03 长期建设：优先可维护 改动后续还会演进 执行 04 短期止血：优先恢复可用 线上问题先恢复、快速止损 止血 05 不需兼容：直接硬切 破坏存量契约且不需兼容层 硬切 06 连续失败：先复盘 反复失败、怀疑方向不对 复盘 07 链路越深：评估停点 投入产出比开始下降、未彻底失败 评估 08 临近收口：补验证闭环 不想停留"代码已改" 验证 09 Bug 场景：先复现 修 bug、先锁定再改 复现 10 多轮协作：先落文档 跨多轮、目标变复杂 文档 11 任务复杂：先收敛计划 目标不清、多分支决策 计划 12 中型项目：按阶段推进 中型项目 / 独立模块 阶段 13 技术债：先挂账 主线中发现技术债，不轻易打断 债务 "#%E6%9C%AF11-%E4%BB%BB%E5%8A%A1%E5%A4%8D%E6%9D%82%E5%85%88%E6%94%B6%E6%95%9B%E8%AE%A1%E5%88%92%E6%8E%A8%E8%8D%90%E5%BC%80%E5%90%AF%E8%AE%A1%E5%88%92%E6%A8%A1%E5%BC%8F") | 目标不清、多分支决策 | 计划 |
| 12 | [中型项目：按阶段推进](# 局面 何时用 类型 01 局面未明：先诊断 任务模糊、想先找问题再开工 诊断 02 主线清晰：直接推进 方向清楚、不想频繁确认 执行 03 长期建设：优先可维护 改动后续还会演进 执行 04 短期止血：优先恢复可用 线上问题先恢复、快速止损 止血 05 不需兼容：直接硬切 破坏存量契约且不需兼容层 硬切 06 连续失败：先复盘 反复失败、怀疑方向不对 复盘 07 链路越深：评估停点 投入产出比开始下降、未彻底失败 评估 08 临近收口：补验证闭环 不想停留"代码已改" 验证 09 Bug 场景：先复现 修 bug、先锁定再改 复现 10 多轮协作：先落文档 跨多轮、目标变复杂 文档 11 任务复杂：先收敛计划 目标不清、多分支决策 计划 12 中型项目：按阶段推进 中型项目 / 独立模块 阶段 13 技术债：先挂账 主线中发现技术债，不轻易打断 债务 "#%E6%9C%AF12-%E4%B8%AD%E5%9E%8B%E9%A1%B9%E7%9B%AE%E6%8C%89%E9%98%B6%E6%AE%B5%E6%8E%A8%E8%BF%9B") | 中型项目 / 独立模块 | 阶段 |
| 13 | [技术债：先挂账](# 局面 何时用 类型 01 局面未明：先诊断 任务模糊、想先找问题再开工 诊断 02 主线清晰：直接推进 方向清楚、不想频繁确认 执行 03 长期建设：优先可维护 改动后续还会演进 执行 04 短期止血：优先恢复可用 线上问题先恢复、快速止损 止血 05 不需兼容：直接硬切 破坏存量契约且不需兼容层 硬切 06 连续失败：先复盘 反复失败、怀疑方向不对 复盘 07 链路越深：评估停点 投入产出比开始下降、未彻底失败 评估 08 临近收口：补验证闭环 不想停留"代码已改" 验证 09 Bug 场景：先复现 修 bug、先锁定再改 复现 10 多轮协作：先落文档 跨多轮、目标变复杂 文档 11 任务复杂：先收敛计划 目标不清、多分支决策 计划 12 中型项目：按阶段推进 中型项目 / 独立模块 阶段 13 技术债：先挂账 主线中发现技术债，不轻易打断 债务 "#%E6%9C%AF13-%E4%B8%BB%E7%BA%BF%E6%8E%A8%E8%BF%9B%E4%B8%AD%E5%8F%91%E7%8E%B0%E6%8A%80%E6%9C%AF%E5%80%BA%E5%85%88%E6%8C%82%E8%B4%A6%E4%B8%8D%E8%BD%BB%E6%98%93%E6%89%93%E6%96%AD") | 主线中发现技术债，不轻易打断 | 债务 |
术 01 · 局面未明：先诊断，不急着改
适用：想看 UI / 代码 / 方案哪里还不够好；任务还比较模糊；想先找问题再决定是否开工；懒得一开始把背景讲得很细；只是想看看 AI 能给出什么建议。
模板（稳定诊断式）
markdown
先不要急着改。先从【指定维度】系统指出当前存在的问题，并按优先级排序；如果需要，再补充你推荐的修正方向。模板（引导提问式，不想讲太细时）
markdown
先基于【当前现状 / 目标方向】，给我 3 到 5 条值得优先考虑的建议，并说明各自适用的前提。先从【产品 / 代码 / 方案 / 体验】这些角度看，指出当前最值得注意的问题，以及为什么它们值得优先关注。误用边界：不限定"指定维度"输出易发散；任务已明确不必绕回诊断；落地时仍要补齐目标、约束、范围；最好让它先列关键假设与缺失信息，区分已知事实与启发式建议；输出过泛时先让它指出最缺哪 1--3 个关键信息再收敛。
术 02 · 主线清晰：直接推进
适用：方向已经清楚；不想频繁来回确认；更关心结果，不想被过程噪音打断。
markdown
你直接按逼近最终目标的思路推进，先读上下文再动手；非关键问题不要频繁停下来，只有你不能拍板的问题再集中问我。误用边界：边界不清时容易顺手扩散改动，最好同时写上范围约束（见"通用补充句"）。
术 03 · 目标偏长期建设：优先长期可维护
适用：这次改动后面还会继续演进；担心短期通过掩盖长期问题。
markdown
不要为了短期通过牺牲长期可维护性、健壮性和扩展性。优先选择中长期站得住的方案；如果必须做短期方案，请明确标注取舍和后续风险。误用边界：若本身就是一次性 / 临时方案，要明确告诉它可以接受短期解。
术 04 · 目标偏短期止血：优先恢复可用
适用：线上问题需要先恢复；目标是快速止损而非一次性彻底治理；可接受阶段性技术债，但不能接受继续失效。
markdown
这次以短期止血为主，优先恢复可用和控制影响面，不追求一次性彻底治理；如果用了临时方案，请标注后续治理项。误用边界：非应急场景不要用止血替代长期建设；即便止血也要说明遗留风险与后续治理事项。
术 05 · 不需要兼容过渡：直接硬切
适用：改动会破坏存量契约；明确不需要兼容层、双写、灰度适配或过渡方案；希望直接切到目标状态。
markdown
这次不考虑兼容过渡，直接按目标状态修改；不要额外保留兼容层、桥接逻辑或过渡方案。如果会破坏存量契约，请直接同步调整调用方和相关实现。误用边界：若真实需要平滑迁移、灰度发布或跨版本兼容，不要强行硬切；决定前确认受影响范围和调用方可控。
术 06 · 连续失败后：先复盘，再继续
适用：已反复试了多轮；怀疑方向本身不对；需要重新对齐目标、路径和停点。（若未失败但怀疑投入产出比，用术 07）
markdown
这件事已经反复失败多次。请先判断是目标错、路径错，还是执行细节错，并给出下一轮最值得尝试的方案，以及建议停掉哪些低收益动作。误用边界：不要求"下一轮方案"容易停留在空泛复盘。
术 07 · 链路越走越深：先评估停点，再决定是否继续
适用：分支链路已展开多轮；还没彻底失败但收益变不确定；怀疑继续投入产出比下降；想判断继续 / 收口 / 换路 / 暂停。（若已连续失败，优先回术 06）
markdown
先不要继续顺着当前链路往下做。先评估这条链路到目前为止的投入产出比：已经获得了什么、还缺什么、继续投入最可能带来什么收益、主要风险和成本是什么。然后判断现在更适合继续深挖、先收口、切换方向，还是在当前停住，并说明理由。误用边界：不要每步都机械评估，否则打断执行；重点判断"现在最合适的动作"而非复述过程；目标清楚、链路稳定产出时不必过早收口。
术 08 · 临近收口：补验证闭环
适用：不想只停在"代码已改"；希望它证明改动真的有效；希望它先给验收标准再实现和验证。
markdown
写出这次完成的验收标准，再补充必要测试或验证步骤，证明这次修改确实解决了问题，而不是靠硬压、绕过或碰巧通过。误用边界：验收标准不要写空话；验证步骤要能真正证明问题已解决；不要为补验证顺手扩大改动范围。
术 09 · Bug 场景：先复现，再修复
适用：正在修 bug；希望先锁定问题再改代码；不希望修复变盲改。
markdown
先不要直接改代码。优先补一个最小失败测试来稳定复现这个 bug；如果不适合写自动化测试，就先给出最小可行复现和验证步骤。确认问题被稳定复现后，再修改代码并检查没有引入误伤。误用边界：不要为让测试通过而写得太宽或偏离真实 bug；测试尽量最小化，只锁定这次问题。
术 10 · 多轮协作：先落文档，再继续推进
适用：任务跨多轮持续推进；目标、方案、进度开始变复杂；担心上下文压缩后丢失关键共识。
markdown
这件事会跨多轮推进。请先把当前目标、关键约束、已达成结论、待决问题和下一步计划整理成文档或结构化记录；后续推进过程中持续更新，不要只依赖会话上下文。误用边界：很小的一次性任务不必为形式额外维护文档；文档不是一次性快照，后续关键变化要同步更新。
术 11 · 任务复杂：先收敛计划（推荐开启计划模式）
适用：任务目标还不够清楚；需求里有多个分支或决策点；希望先讨论方案、拆步骤、确认边界再实现。
markdown
先不要急着落代码。先把目标、约束、范围边界、关键分歧点、推荐路径和执行步骤梳理清楚；如果有需要我确认的地方，按优先级逐条拿出来。误用边界：任务已很直接时不必机械开启计划模式；计划模式适合收敛问题与确认路径，不适合代替落地。
术 12 · 中型项目：按阶段推进
适用：在做中型项目或独立模块；业务和场景需先对齐再实现；希望先把文档、边界和开发路径收敛清楚。
推荐流程（7 步）：
- 先对齐业务目标、场景边界和不做项，不急着落代码。
- 文档未定时，先做计划收敛，把关键共识定下来。
- 文档基本定下后，再用计划模式查漏补缺，整理出可推进的完整计划。
- 若方案刚收敛完、担心有遗漏，可加可选复核：让辅助代理或独立视角先审一遍再决定是否执行。
- 进入执行阶段后默认直接推进，不要常驻计划模式。
- 只在阶段切换、明显偏航、反复失败或需重新收敛时，才回到计划模式。
- 关键阶段完成后，再做一次独立复查。
说明：并行代理或辅助执行更适合复查、补充视角和并行审视，不适合承接必须立刻解决的主线任务。
术 13 · 主线推进中发现技术债：先挂账，不轻易打断
适用：Codex 推进主任务时顺手暴露存量结构问题；你在旁路阅读时发现技术债；不希望它顺手优化偏离主线；又不希望观察被遗忘。
markdown
如果在推进主任务过程中发现技术债，先不要立刻切进去治理。先判断它是否阻塞当前任务的正确性、稳定性或最小可交付结果：
- 如果阻塞，就说明为什么必须现在处理，再处理。
- 如果不阻塞，就先记录到技术债文档，写清位置、问题表现、当前不处理的原因、风险、后续建议和建议处理时机，然后继续推进主任务。
无论这个问题是你发现的，还是我在旁路阅读中发现的，都先按这个规则处理；不要因为顺手优化而偏离当前主线。误用边界：不要把所有问题都挂账------真正阻塞交付的要现在处理；债务文档不要写成情绪记录，要可执行；不要只写"以后再说"，至少写清风险与建议处理时机；若主线正沿明显错误结构扩展，不应放任。
第四章 · 器：最后讲"拿来即用"
需要马上复制时，直接用模板和通用补充句。四个组合建议按 01→02→03→04 顺序使用，都是把"目标 / 模式 / 约束 / 输出 / 验证"压成的完整骨架。
组合 01 · 方案讨论型
markdown
目标：先收敛【某个方案 / 某个模块怎么做】，先不急着写代码。
模式：必要时先做计划收敛。
约束：把真正关键的分歧点提炼出来，不要把低价值问题一起抛给我。
输出：按"问题、选项、利弊、推荐"格式整理，我来拍板。
验证：明确这次准备解决什么、不解决什么，以及为什么。组合 02 · 直接开发型
markdown
目标：解决【具体问题】，并尽量逼近【最终可用方案】。
模式：如果任务已经明确，就直接推进。
约束：先读上下文再动手；非关键问题不要频繁停下来；这次只解决【当前核心问题】，不顺手扩展到【无关范围】。
输出：先给问题判断和推荐方案，再直接落地；如果有必须我拍板的问题，按"问题、选项、利弊、推荐"来问我。
验证：改完后补充【测试 / 最小验证闭环】。组合 03 · Bug 修复型
markdown
目标：修复【某个 bug】，并避免盲改。
模式：一般不需要先做计划收敛，除非背后牵涉较大范围的方案调整。
约束：优先先复现，再修复；不要为了让测试通过而绕开真实问题。
输出：说明 bug 根因、如何复现、代码如何修复。
验证：确认问题先被稳定复现，再确认修复后通过，并补充必要的回归验证。组合 04 · 独立复查型
markdown
目标：对当前结果做一轮独立复查，而不是重复主流程。
模式：适合在主流程基本完成后使用。
约束：从【前端 / 架构 / 接口 / 文档】视角重点检查【稳定性 / 可维护性 / 一致性】；聚焦复查，不重复实现。
输出：指出风险、遗漏、更优建议，以及哪些点已经足够，不需要继续投入。
验证：把"必须改"和"可选优化"分开列出。通用补充句（可直接粘贴）
markdown
1. 这次只解决当前核心问题，不顺手扩展、不做无关重构。
2. 这次不考虑兼容过渡，直接按目标状态修改；不要额外保留兼容层、桥接逻辑或过渡方案。
3. 如果有需要我确认的问题，请只提最关键的 1 到 3 个，并按"问题、选项、利弊、推荐"格式来问。
4. 先列出你的关键假设和缺失信息；能自行拍板的直接继续，不能拍板的最后集中列出。专项模板 · 技术债挂账型
markdown
目标：推进【当前主任务】，不要因为顺手发现的技术债偏离主线。
模式：默认继续主任务；只有在技术债已经阻塞当前正确性、稳定性或最小可交付结果时，才中断处理。
约束：无论技术债是你自己发现的，还是我在旁路阅读中发现的，都先判断是否必须现在处理；不必须现在处理的，先登记，不直接扩展治理。
输出：如果需要挂账，就记录到【技术债文档 / 债务清单】，写清位置、问题表现、当前不处理的原因、风险、后续建议和建议处理时机，然后继续主任务。
验证：主任务结束后，补一次债务清单回看，确认哪些要开单独治理。专项模板 · 防擅自用临时解
适用：你更在意方案是否自然、易维护；不接受它在未确认前直接使用兜底方案。
markdown
如果过程中出现兜底方案，不要直接采用。先说明更优正解是什么、为什么暂时不可行；只有在确认没有更合适方案后，再向我说明风险、局限和回收方式，得到我确认后再实施。收束
道 引方向 · 法 定组织 · 术 讲打法 · 器可复用。
用结构降低偏差，用验证确保结果。
本文整理自 Codex Cookbook