把报错粘给 AI 说「修一下」，它会改一个条件、加一个空值检查、包一层 try/catch，错误消失了——但你知道它为什么会发生、这个修复是不是真的解决了问题吗？这就是「让症状消失」和「理解一个 bug」的差别。作者给出更好的开场提示：「先别改代码，帮我复现这个失败，并为它的成因找出证据。」文章用一个搜索场景说明为什么看似合理的修复会漏掉真正的 bug：用户输入新查询后偶尔显示旧结果，真因是响应乱序返回（后发的请求先返回，先发的结果晚到并覆盖了正确结果），而 AI 建议的 debounce 只减少请求发起的次数，并不能保证最新的请求最后返回。随后是一套可操作的工作流——先描述失败（预期 / 实际 / 触发条件 / 出现频率）而不给代码，再要求列出最多三种可能原因、把观察到的事实与假设分开、说明每种原因需要什么证据来支持或推翻、并给出最小的复现；接着把间歇性失败变成可重复的失败（例如强制先发的请求后返回），最后让 AI 证明成因，而不是交付一个补丁。