有一段时间，我几乎不打开搜索引擎了。
遇到不会的东西，第一反应是切到 AI 对话框，把问题一贴，等它给我一段整理好的答案。说实话，这个体验太舒服了：不用在十个标签页之间来回翻，不用忍受广告和那种互相抄来抄去的“技术博客”，看不懂还可以接着追问，它也不会嫌我烦。
那阵子我甚至跟同事开玩笑说，搜索框可以退休了。
后来发生了几件小事，让我又把搜索框请了回来。现在我两样都用，只是分工比以前清楚多了。这篇就聊聊这个过程，没什么高深的东西，都是日常里的小体会。
第一次翻车：一个报错信息
那天升级了一个依赖的小版本，项目启动直接报错。我把报错堆栈贴给 AI，它很快给了一个解释：大概是某个类加载顺序的问题，建议我调整一下配置，再加一个排除项。
解释得头头是道，我照着改了，没用。又问，它换了个说法，给了第二个方案，还是没用。来回折腾了快半小时。
最后我有点不耐烦，把报错里最关键的那一行，加上引号，直接丢进搜索引擎。第二条结果就是那个依赖的 GitHub issue：这个小版本有个已知问题，维护者已经在 issue 里给了规避办法，下个版本修复。我照着改了一行，好了。
事后想想，这其实一点都不奇怪。AI 的知识有截止时间，而且它是从大量资料里“学”出来的，对于“某个库的某个小版本刚出的问题”这种又新又细的东西，它大概率根本没见过。可它不会说“我不知道”，而是会用通用的经验给你编一个看起来很合理的解释。
精确的报错信息，本质上是一个“查找”问题，不是“推理”问题。 世界上可能已经有人遇到过一模一样的错误，你要做的是找到那个人。这件事，搜索引擎比 AI 擅长得多。
第二次翻车：一个不存在的配置项
还有一次，我想调整某个框架里连接池的一个参数，就问 AI 配置项叫什么。它给了我一个名字，格式规规矩矩，看着就像真的。
我写进配置文件，启动没报错，但参数也没生效。后来去翻官方文档，才发现那个配置项要么是旧版本的写法，要么压根就是它根据命名习惯“推”出来的——反正我用的这个版本里没有这个键。框架对不认识的配置键默默忽略了，所以连个报错都没有。
这件事比第一次更让我警惕。第一次至少有报错提醒我没修好；第二次如果不是我刚好去看了一眼监控，可能很久都发现不了。
从那以后，凡是配置项名称、API 的方法签名、版本号这类“要么对、要么错”的东西，我都会去官方文档核对一遍。AI 给的可以当线索，但不能当答案。
它们到底各自擅长什么
折腾了几次之后，我给自己整理了一张小表，现在基本按这个来分工。
图：什么问题先问 AI、什么问题先去搜索：分工对照表（原创示意图）
简单说：
理解类的问题，先问 AI。 比如“这个概念是什么意思”“这两种方案大概有什么区别”“这段代码在干嘛”。它擅长把东西讲明白，还能顺着我的理解程度往下讲。
查找类的问题，先去搜。 比如精确的报错、某个库的已知问题、“有没有人遇到过”。答案是现成存在的，关键是找到它。
事实类的问题，去看源头。 配置项、API 签名、版本兼容性、发布说明，最可靠的永远是官方文档和更新日志。
这里说的都是我个人的经验，不同的工具差别也挺大。有些 AI 工具带联网搜索，会附上参考链接，这确实能缓解一部分问题。但我还是习惯点开链接看一眼原文，因为我遇到过不止一次：它总结的内容和链接页面里写的，对不太上。
我现在的流程
现在遇到问题，我大概会这样走：
图：遇到技术问题时，我现在先问 AI 还是先搜索的判断流程（原创示意图）
先问自己一句：这是不是一个精确的报错，或者跟某个具体版本有关？
如果是，就先把关键报错原文加上引号去搜，重点看 GitHub issue、官方论坛和更新日志。找到相关的讨论之后，再把内容贴给 AI，让它帮我判断“这个 issue 说的情况和我的是不是一回事”，以及“套到我的代码里应该怎么改”。这一步 AI 特别好用，因为很多 issue 讨论又长又散，它帮我提炼得很快。
如果不是，比如我只是对某个东西没概念，那就先问 AI，让它帮我把思路理清楚。但我会多要一样东西：让它告诉我应该去官方文档的哪一部分核对，或者给我几个适合搜索的关键词。 有了这些，我去核对的时候就快多了。
这个小习惯，让我从“AI 给答案、我照做”，变成了“AI 给线索、我去核对”。前者省事，后者踏实。
一个意外的损失：少了“偶遇”
还有一件事，是我过了很久才意识到的。
以前查东西，经常要把一整页官方文档读下来，或者在几个帖子之间翻来翻去。这个过程很低效，但会顺带看到很多“我没打算看”的东西：相邻章节里的一个配置开关、帖子评论里有人提到的另一个坑、文档角落里的一条注意事项。很多我现在还记得的知识点，都是这么“偶遇”来的。
用 AI 之后，它只回答我问的那一点，干净利落，这些偶遇就没了。效率高了，但我对一个工具的整体印象反而变得很碎，只知道自己问过的那几个点。
所以现在我会刻意留一点“低效”的时间：新接触一个框架或者库的时候，至少把官方文档的入门部分和配置说明从头到尾翻一遍，不急着问 AI。这算是我给自己的一点补偿吧。
问 AI 之前，先把版本告诉它
还有一个很朴素、但我以前总忘的习惯：问 AI 技术问题的时候，先把环境交代清楚。
用的是哪个语言版本、哪个框架版本、哪个依赖的哪个版本，最好一句话写在问题开头。很多时候同一个问题，在不同版本里的答案完全不一样。我不说，它就会按它“印象里最常见”的那个版本来回答，而那个版本往往比我项目里用的老。
我还会在问题后面加一句：“如果这个问题跟版本有关、你不确定，请直接说不确定，并告诉我该去哪里核对。”加了这句之后，它确实更愿意说“这个参数在不同版本里名字可能不同，建议以官方文档为准”之类的话了。效果不是百分之百，但至少能少一些“自信地给错答案”的情况。
说到底，AI 不知道我的项目长什么样，它看到的只有我给它的那几行字。我交代得越清楚，它瞎猜的空间就越小。
两个小技巧
最后分享两个我觉得挺好用的小做法。
一是让 AI 帮你“翻译”搜索词。 有时候我连该搜什么都不知道，只能描述现象。这时候我会让 AI 把我的描述翻译成几个英文的技术关键词，或者告诉我这种现象在行业里一般叫什么。拿着这些词去搜，命中率高很多。
二是把搜到的东西喂回给 AI。 找到一篇很长的 issue 讨论或者文档，我会把原文贴给它，然后问具体的问题：“根据这段内容，我的情况适用哪种解决办法？”这时候它是在我给的材料上回答，而不是凭记忆发挥，靠谱程度会高不少。当然，关键结论我还是会回到原文对一下。
最后
回头看，我当初想让 AI 完全替代搜索引擎，其实是把两件不同的事混在一起了。AI 擅长“讲明白”，搜索引擎擅长“找出来”，官方文档负责“说了算”。
现在我的浏览器里，AI 对话框和搜索框都常驻着。工具不是二选一的问题，而是知道什么时候该用哪个。想明白这一点之后，我反而比“全靠 AI”那段时间更快了——主要是少了很多被自信的错误答案带着绕圈子的时间。
2026-10-14鱼鱼