TL;DR： AI 用 5-Why 有三个问题：浅尝辄止（深度不够）、单线追踪（广度不够）、确认偏差（推理偏误）。三个问题独立但往往一起出现——浅层结论形成锚定后，会同时压缩探索空间和引导证据偏好。本文用一个四轮归因全部失败的真实案例，拆解每个问题的具体表现。

这篇是「用 TDD 驯服 AI 编码代理」和「AI 根因诊断」两个系列的交叉文章。

我最近在做 AI 辅助根因诊断的工具，想用工业界成熟的 5-Why 方法。但在手动引导 AI 使用 5-Why 追问定位 bug 根因的过程中，发现 AI 停得太早、只走一条线、只找支持证据，需要大量追问。这对自动化是一种挑战——如果要将人解放出来，引导 AI 进行 5-Why 根因分析的脚手架应该怎么设计？

要设计脚手架，先得搞清楚 AI 在用 5-Why 时具体有哪些问题。

5-Why 靠人的判断力，AI 缺这个判断力

5-Why 最早源自大野耐一在丰田生产系统里的实践[1]，他主张遇到问题要连续追问为什么，追到根因为止。后来被提炼为"问五次为什么"的经验法则。

这个方法的一个特点是：终止条件没有显式定义。什么时候算追到了根因，全靠使用者的经验和判断力。训练有素的人类工程师有这个判断力——知道什么时候该停、什么时候该换方向、什么时候自己可能在骗自己。

学术界对 5-Why 有一些批评。Card 在 2017 年指出：同一件事画因果树能找到 75 个以上的原因，5-Why 只能找到 1 到 2 个，覆盖率不到 3%[2]。但他的例子来自医疗不良事件调查——医疗事故背后通常有十几个甚至几十个交互作用的贡献因子，和软件 debug 是完全不同的场景。

有研究统计过，软件 bug 的根因聚类到 3 到 9 个类别，70% 以上是语义层面的逻辑错误[5]，很多 bug 只有一个主导根因。而且大约 80% 的服务端 bug 是确定性的——同样的输入复现同样的故障[6]。这和医疗事故的多因子交互完全不同。

Card 说 5-Why 覆盖率不到 3%，但 debug 场景下根因本来就没几个，不存在"75 个原因漏了 73 个"的问题。5-Why 分析是强目的性的，在实践中使用者自然会过滤掉不可控的影响因素。我在 debug 的时候，引起 bug 的可控原因通常只有很少的几个，我需要快速找到它们，而不是用逻辑上有理但毫无可行性的原因去分散注意力、消耗精力。

Card 批评的是覆盖率，Paradies 批评的是另一个问题：确认偏差。2005 年他指出，调查者会主动找证据支持自己已经预设的结论，忽略矛盾的信息[3]。这个批评和覆盖率不一样——确认偏差不是 5-Why 方法本身的问题，而是使用者的认知陷阱。有经验的工程师知道主动找反例来对冲，5-Why 在他们手里不会跑偏。

覆盖率批评在 debug 场景下不成立，确认偏差是真实风险但可以被对冲。两个批评都不构成"5-Why 不能用"的理由——前提是使用者有足够的经验。而 AI 没有这个经验，也没有人类那种"不对劲"的直觉。

我在没有外部追问干预的情况下做过多次测试，AI 做 5-Why 默认只会问到 2 到 3 层就停。给出的答案看起来逻辑通顺，实际上根本没到可执行的根因。比如调试一个指令不执行的问题，AI 能指出是指令本身的问题，但不会继续追问为什么同一份文件里的另一部分指令就能正常执行。方向对，每一步也有据可依，就是走得不够远。

一个四轮归因案例：AI 具体怎么掉链子的

我在 Aristotle 项目里碰到过一个典型案例：SKILL.md 里的指令不被执行，前三次归因都失败了，每次都指向了相关线索，但都没追到位。

第一轮： AI 的诊断是"opencode run 不支持异步通知"。方向部分正确，问题确实和运行环境有关，但它停在了测试方法层面，根本没追到根因。我发现同一份代码在其他环境里运行结果不一样，质疑了这个结论，才进入下一轮。

第二轮： AI 的诊断是"模型不遵循 SKILL.md 指令"。大方向是对的，确实和 SKILL.md 有关。但它只沿着"模型不配合"这一条线追，完全没有同时追"指令格式本身是否有问题"这条分支。它停在了"模型不配合"的层面，没有继续问为什么同一份 SKILL.md 里的 ROUTE 段就能被正常遵循，只有 ACTIONS 段不被遵循。我问了这个问题，才继续往下走。

第三轮： AI 的诊断是"LEARN.md 存在导致模型绕过 dispatcher"。方向也对，指向了文件加载机制。但它停在了"文件存在"的层面，给出的方案是删除 LEARN.md，完全经不起追问。我问"为什么方案是删文件"，才进入第四轮。

第四轮： 终于找到了根因：SKILL.md 的 ACTIONS 段用的是文档风格的 bullet list，没有用带具体动词的执行风格，模型把它当成普通文档忽略了。

从案例里归纳出来的问题

前三轮的诊断都不是胡说，每一步都有对应的依据，只是离根因还差一层。没有我的追问，AI 会在第二轮或者第三轮就停下来，认为自己已经找到了答案。

回头看看这三轮，能归纳出三个问题。

浅尝辄止——每一轮都停得太早。 第一轮停在测试方法层面，第二轮停在"模型不配合"层面，第三轮停在"文件存在"层面。每一轮的方向都对，但都差一层——停在操作层面而非语义层面。根因在指令格式的语义层面，AI 连续三轮都没触达。AI 默认走到 2-3 层就觉得自己够了，不会主动往下追。

单线追踪——只走一条路径，不探索分支。 第二轮最典型——AI 已经把方向指向了 SKILL.md，但只追了"模型不配合"这一条线，完全没碰"指令格式有没有问题"这条分支。

确认偏差——只找支持证据，不找反例。 第一轮到第三轮都有：AI 在每一轮都给自己找支持证据，没有主动寻找可能推翻自己结论的信息。2025 年 Wan 等人的研究发现，AI 的思维链推理过程中，模型的初始信念会影响整条推理链——推理会朝着支持初始信念的方向偏移[4]。

三个问题，三种性质

三个问题是三种独立的类型。

浅尝辄止是深度不够——AI 默认走到 2-3 层就停，这是它的工作模式，不需要额外机制解释。

单线追踪是广度不够——只走一条路径，不探索其他可能性。

确认偏差是推理偏误——只找支持证据，不找反例，导致错误归因。

后两个问题为什么往往跟着浅尝辄止一起出现？因为锚定机制。浅层结论一旦形成，会变成一个锚，约束后续推理。它压缩探索空间——原本可以追的分支不追了（广度不够→单线追踪）。它还引导证据筛选偏好——推理朝着支持初始结论的方向偏移（推理偏误→确认偏差）。锚定不解释深度为什么不足，它解释的是浅层结论形成后，广度和推理怎么被带偏。

那能不能设计一套可验证的规则和流程，通过它们把 AI 本该有的思考质量和深度水平发挥出来？

下篇预告：知道问题不等于知道怎么解决——三个问题靠什么机制拦住？下一篇 →

参考文献

  1. Ohno 1988, Toyota Production System: Beyond Large-Scale Production, Productivity Press, https://www.routledge.com/Toyota-Production-System-Beyond-Large-Scale-Production/Ohno/p/book/9780915299140
  2. Card 2017, “The problem with ‘5 whys’”, BMJ Quality & Safety, vol. 26, no. 8, https://doi.org/10.1136/bmjqs-2016-005849
  3. Paradies 2005, “What’s Wrong with 5-Whys???”, TapRooT®, https://taproot.com/whats-wrong-with-5-whys-complete-article/
  4. Wan et al. 2025, “Unveiling Confirmation Bias in Chain-of-Thought Reasoning”, Findings of the Association for Computational Linguistics: ACL 2025, https://aclanthology.org/2025.findings-acl.195/
  5. Tan et al. 2014, “Bug characteristics in open source software”, Empirical Software Engineering, https://doi.org/10.1007/s10664-013-9258-8
  6. Sahoo, Criswell & Adve 2010, “An Empirical Study of Reported Bugs in Server Software with Implications for Automated Bug Diagnosis”, ICSE, https://doi.org/10.1145/1806799.1806870

交叉引用