假设、日志和二分查找
一旦 AI 提出了一个原因，不要直接接受。用低成本的方式测试它。 最便宜的测试通常是一行日志。
让 AI 添加临时日志：
"在我们改任何东西之前，添加一个
console.log（或user的值，这样我们就能看到它是不是真的为 undefined。"
运行它，把输出粘贴回来。现在你拥有的是证据，而不是一个理论。也许 user 确实是 undefined——这就确认了假设。也许它没问题，真正的元凶在上一层。无论哪种情况，你都向前推进了。调查时要慷慨地打日志：变量的值，以及一个标签，说明它是哪个变量、日志在哪里。一个打印出 undefined 的光秃秃的 console.log(user)，远不如 console.log("user at validate.js:14 =", user) 有用。还有，bug 修好后记得把临时日志拔出来——遗留的调试噪音本身就是一小摊烂摊子。
当 bug 藏在一个很长的流程中的某处，而你说不清在哪里时，使用二分查找。把可疑区域对半切分：在中点添加一条日志。那里的值看起来正确吗？那么 bug 在它之后——搜索那一半。那里的值已经看起来不对了吗？那么 bug 在它之前——搜索那一半。每一步都把搜索空间减半，所以即使是一千行的路径，也能在大约十次检查内缩小范围。明确地告诉 AI："帮我二分排查——我应该在哪个中点打日志？" 同样的技巧不仅对代码有效，对历史也有效：如果某个功能上周还能用、今天坏了，就对你的提交做二分查找，找到引入这个 bug 的那个确切改动。