同一个问题解决了三次，它还在
先问你一个扎心的问题：有没有哪个问题，你已经"解决"过好几次了，可它每隔一阵还是回来找你？
大部分人的第一反应是——是我方案不够好。于是加班加点，做个更强的工具、写个更全的脚本，把它"彻底"干掉。结果呢？下个月它又冒出来了。
我做了十来年测试开发，越到后面越发现：一个问题反复解决不掉，十有八九不是你手不够快，而是你从一开始，就没挖到那个真正的问题。
今天不聊代码，聊一件更值钱的事——怎么把问题挖到底。
一、大多数人，把"现象"当成了"问题"
举个栗子。
假设团队里有套自动化测试，跑了大半年，通过率一直上不去，红红绿绿一大片。老板问起来，大家都说"用例不稳定"。
于是一个同学接了任务：优化框架、加重试、把 flaky 的用例挑出来重写。忙活两周，通过率从 60% 提到了 75%。看着是进步吧？可再过一个月，又掉回去了。
问题出在哪？他解决的不是问题，是现象。 "通过率低"是你眼睛看到的那个红灯，是现象；它背后到底为什么低，才是问题。你盯着红灯猛擦，红灯当然还会亮。
把现象当问题去解，是最常见、也最贵的一种白忙。 因为你投入越多，越会误以为自己在进步。
二、往下挖两层，才够得到根因
那怎么才算挖到底？给你一个我自己一直在用的笨办法：现象 → 问题 → 根因，逼自己往下挖两层。 每一层，都用"为什么"去追下一层。这套追问，精益里叫「5 Whys」，说白了就是别在第一个答案上停手。
还是上面那个栗子，我们往下挖：
第一层，现象：自动化通过率低。为什么？ 因为一堆用例挂了没人修。为什么没人修？ 因为用例挂了根本没人知道，跑挂了也没人管、修好了也没啥好处。为什么会这样？ 因为压根没有一套"谁负责这条用例、挂了通知谁、修不修有没有后果"的机制。
挖到这一层，你会发现一件反直觉的事：这道题根本不是技术题。 框架再牛、用例写得再漂亮，只要"坏了没人管"这个机制缺口还在，通过率就永远稳不住。
这就是挖问题最值钱的一铲子——你会挖出一个和最初完全不一样的问题。表面是技术问题，根因常常在流程、在机制、在人和人之间的信息差上。
三、根因找对了，解法往往轻得意外
这里有个特别爽的规律：根因挖得越准，解法往往越轻。
因为你发现根因是"机制缺失"而不是"技术不行"，那接下来该做的就不是重写框架，而是补那个机制——比如让用例挂了自动 @ 到负责人，比如定一条"红灯不清零不许发版"的硬规则。可能就是一个通知机器人加一条流程约定，成本极低，却能把反复冒头的问题真正摁住。
反过来看那些"挖到一半就动手"的人：他们花最大的力气，做最重的系统，解决的却是一个伪问题。忙得昏天黑地，问题还在。
做一个大系统，从来不是本事；看清该解决哪个问题，才是。 想清楚了，最优解经常轻得让你意外。
挖问题这件事，恰恰是 AI 这波浪潮里最替不了你的一铲子。
AI 能帮你把方案做得又快又好，能替你写完那些代码。可"这到底是不是真问题、根因在哪一层"——这一铲子，得你自己下。你把问题挖错了，AI 只会帮你把错误的答案，做得又快又漂亮。
所以下次再遇到一个反复解决不掉的问题，先别急着动手。停一下，往下多问两个"为什么"。
挖到根因的那一刻，问题往往已经解决了一半。 这，就是破局的起点。
