调试协作：错误信息的喂法与假设树
一句话定义
高效调试协作 = 结构化投喂（完整错误栈 + 最小复现 + 相关代码 + 已排除项）+ 假设树方法（让 AI 列出按概率排序的假设，逐个验证），而不是「报错了怎么办」式的求助。
为什么重要
调试是最容易产生幻觉修复的场景：信息不足时模型会编造一个「听起来合理」的原因与补丁，人如果不加验证就应用，常把真问题埋得更深。结构化投喂压缩猜测空间，假设树把「模型一锤定音」变成「模型提出候选、人用证据裁决」，两者结合把 AI 从不可靠的先知变成高产的侦查员。
前置知识
kp-007（修 Bug 提示模板）、kp-010（定位相关代码的探索策略）。
核心概念
结构化投喂四件套：
- 完整错误栈：从最顶层异常到最深层帧，裁掉重复重试段。
- 最小复现：能在本地触发的最短路径（命令/请求/输入文件）。
- 相关代码：栈中出现的函数实现 + 你怀疑的数据流上游签名。
- 已排除项与已观察现象：日志特征、复现规律（偶发/必现/与数据相关）。
假设树方法：让 AI 输出 3-5 个候选原因，每个附「验证方法」与「若为真应看到的现象」；人按成本从低到高逐个执行验证，用结果剪枝。禁止让 AI 在未验证前直接给补丁。
二分法配合：可稳定复现的历史回归，让 AI 生成二分查找脚本（对 commit 或对输入数据二分），人执行并回填结果。
原理与机制
假设树有效的原因是它改变了模型的输出目标：从「给答案」（会被逼着在高不确定性下编造）转为「给可证伪的候选集」（不确定性被显式承认）。每个假设附验证方法，把后续工作交还给可观察证据，这是对幻觉的结构性防御。结构化投喂则决定候选集质量：错误栈给出精确故障帧（模型的推理锚点），最小复现保证候选可被快速证伪，已排除项防止候选集退回原点。
实例或案例
Before：
接口偶尔 500，帮我看看怎么回事。After：
现象：POST /orders 约 0.5% 返回 500，日志均为同一异常栈（附后）。
复现：并发 50 创建相同 sku_id 订单，本地必现；单请求不复现。
代码：services/order.py:88-120（扣库存段）附上；Stock.deduct 签名附上。
已排除：非鉴权（4xx 正常）；非数据缺失（单请求成功）。
任务：列出 3-5 个按概率排序的假设，每个附验证方法；
不要给补丁，我验证后回来告诉你结果。操作步骤：
- 按 kp-007 修 Bug 模板收集四件套（5 分钟内完成）。
- 发起假设树请求，拿到候选清单。
- 按验证成本排序执行：先跑日志核对（零成本），再写复现脚本，最后加断点/埋点。
- 每验证一个假设回填结果：「假设 1 排除，因为 X；假设 2 部分成立……」
- 根因确认后才进入修复阶段（回到 spec 流程kp-011）。
排错清单：
- AI 编造了不存在的 API/日志字段 → 要求它「只依据我贴的代码与栈推理，引用行号」。
- 假设全部落空 → 四件套缺关键材料，通常是数据流上游签名；补料重开假设树。
- 偶发问题无法复现 → 先让 AI 设计「提高复现率」的实验（并发/特殊数据/时序注入），再谈定位。
- 修复后复发 → 用二分法找引入点，别只修症状。
公式或模型
本节不适用：调试是证据驱动流程，无闭式模型。
图示
四件套投喂 ──▶ 假设树(3-5候选+验证法) ──▶ 逐个验证/剪枝 ──▶ 根因 ──▶ 回到spec修复
▲ 人：裁决证据；AI：生成候选与实验设计直观类比
像会诊：不问「他怎么了，开药吧」，而是让各科医生列出鉴别诊断（假设）与检查单（验证方法），化验结果回来剪枝——最后才开药。
常见误区
- 一步到位要补丁：未定位根因的补丁是症状压制，常引入新缺陷。
- 只贴最后一行报错：丢失故障帧与上下文，模型只能泛泛而谈。
- 假设树一轮定案：第一轮候选全错是常态，剪枝信息本身就是进展，回填后再生成第二轮。
与其他知识点的关系
kp-011 规定根因确认后的修复流程；kp-008 的六件套是本节四件套的通用版。
自测题
要点：完整错误栈、最小复现、相关代码与签名、已排除项与现象规律。
要点：把输出目标从高不确定性下编造答案，转为可证伪候选集；用证据裁决替代直觉采信，阻断幻觉修复。
- 结构化投喂四件套是什么？
- 为什么要求 AI「先给假设不要给补丁」？
延伸阅读
《Debugging：The 9 Indispensable Rules》David Agans——九条调试铁律与假设树精神一致。