刚开始学编程的时候，我以为进步就是记住更多东西。更多不用查就能想起来的函数、命令、写法。当然，知道得多确实有用。但做得越久，我越觉得编程的很大一部分，其实是学会怎么去调查一件事。

因为很多时候，你面对的局面基本是这样的：

打开网易新闻 查看精彩图片

  • 可能有一条报错信息。
  • 可能什么都没有，这最"好玩"。
  • 可能某个函数返回了奇怪的东西。
  • 可能本地跑得好好的，一部署就崩。
  • 可能某个库的行为和文档写的完全对不上。

于是你开始到处戳。重新读一遍报错——这次是真的读，而不是看一眼就认定它是什么意思。搜 GitHub issue。把别的地方弄坏。慢慢地，你收集到的小碎片足够多，问题就不再像一团巨大的谜。

问题的第一个版本通常是："这玩意儿到底为什么不行？"这没法执行。所以你把问题缩小：这个函数真的在跑吗？请求发出去了吗？服务端收到了吗？数据的形状和我想的一样吗？这个值是不是在五步之前就变成 undefined 了？我是不是根本看错了地方？这到底是我写的 bug，还是我误解了这个库的用法？

每一个答案都会排除掉几种可能。到最后你调试的不再是"这个应用"，而是一个函数，然后是一个傻乎乎的值。突然之间，问题就露出来了——某个小得离谱的东西，造成了这一切。

搜索技术答案本身就是一项技能。有时候把报错粘进搜索框，三十秒就能拿到准确答案。有时候那条报错基本没用。有时候答案取决于你的操作系统、浏览器、包版本、GPU、运行时、构建工具，甚至月相。

你越擅长判断问题的哪一部分才是关键，你的搜索就越准。这对我来说是个很大的转变。不再搜"为什么坏了"，而是搜一个具体得多的东西。然后你就不再翻到十页毫不相关、只是碰巧包含同一句报错的结果了。

我现在读文档大概比刚学的时候更多。不是因为我变成了那种负责任的、会主动读文档的成年人，通常是因为出问题了。有时候文档立刻给出答案。有时候它给的信息足够让你意识到，自己一直想错了方向。有时候它已经过时。有时候答案埋在一个 GitHub issue 里，有人随口提了一句："对，这个选项开着的时候就不行。"——这话要是一小时前看到就好了。

有时候我最后会去读源码，因为到某个点我就是想知道这东西到底在干什么。你不需要理解整个库。有时候只要顺着一个函数追下去，回答一个问题就够了。

新手很容易觉得，有经验的开发者就是什么都知道。他们看一眼问题就懂了，知道该用哪个函数，记得住每一条命令，从来不用搜。而你坐在那儿想："为什么同一个东西我要查第四遍？"

但我不觉得经验长这样。它更像是：更擅长从卡住的状态里出来。知道去哪儿找，知道哪些信息重要，知道怎么把一团乱麻的问题变小，知道自己的假设什么时候大概率是错的，并且愿意继续挖下去，而不是盯着代码指望它突然自己解释自己。

AI 确实让调查变快了。它能解释一个奇怪的报错，帮你追踪不熟悉的代码，建议下一步该查什么，指出某个明显的东西——那东西我明明盯着看了六遍都没看见。但它也会错，有时候错得非常自信。它可能给你一个针对错误库版本的答案，可能没抓到真正的原因，可能只修了症状，把底层问题留在那儿等着你。

所以我不认为 AI 替代了调查这件事。它只是变成了我调查时用的又一个工具，仍然不是可以盲目信任的东西。

你永远不可能什么都知道。总会有下一个库、下一个框架、下一个奇怪的边界情况、下一条你从没见过的报错。说实话，这件事以前比现在更让我困扰。因为我觉得目标已经不是知道一切了，而是当你撞上某个看不懂的东西时，能想："行，我现在还不知道发生了什么。但我大概能把它搞清楚。"

然后你开始缩小范围。有时候故意把东西弄坏。最后那个奇怪的东西不再奇怪了。至少，直到下一个奇怪的东西出现。而这，显然就是编程的大部分内容。