AI Native 时代，我是怎么学一个新东西的

写在前面

我之前一直在做 iOS 开发，涉及到一些 APM 相关的业务，后来转向大前端，使用 React Native 和 Flutter 做一些跨端的程序，另外也用 Python 和 Rust 写一些后端的任务。接着在去年开始做 AI Agent。

按理说这是两个领域，该从零开始。但真做起来，我几乎没有”从零开始”的感觉，我一直在用同一套方法学东西，只是换了对象。这套方法只有几条，都很朴素，但帮我扛过了好几次技术栈的整体换代。

不过它有个前提。想清楚这个前提之后，我才明白为什么它有时候特别灵，有时候又完全不灵。

一、熟悉的地方 AI 是放大器，陌生的地方它是生成器

在 iOS 性能优化这个领域，我跟 AI 聊天像在过招。它说一句话，我立刻能判断：这句是对的，这句有点泛，这句跟我的经验冲突，这句背后还有一层，这句是新版本的变化值得追下去。

于是对话会形成闭环。我不是在听课，我是在跟它交手。

但在 RAG 这种我没碰过的领域，情况完全不同。我觉得自己看懂了，也能接着往下问，甚至能复述一些概念。可我没法像是在 iOS 的性能优化领域一样进行深入判断——哪里是真正关键的，哪里只是一句表面说法。

看起来效率很高，掌握深度却不够。

差别在于：熟悉领域里我有一套现成的判断力，陌生领域里我没有。AI 在我熟悉的领域是认知放大器，它把我已有的判断放大；在我陌生的领域，它很容易退化成一个信息生成器。

AI 源源不断地产出听起来对的东西，但没人能替你判断哪句重要哪句片面哪句错误。

所以学一个新领域，问题不在于要不要多问 AI，而在于先给自己搭一套判断力的脚手架。这套脚手架我搭得最顺手的三样是——一张地图、一批边界、一个闭环。

下面这些经验，说到底都是在讲怎么把判断力一点点搭起来，这三样只是其中最常用的抓手。

二、先要整体，再要细节

我学新东西有个规则：一上来绝不死抠细节。

过早钻进细节，代价是失去对整体的判断:你会不知道自己在哪、要往哪去，学了一堆东西却拼不成一张图。所以我总是先搭一张粗的、能拿来思考和讨论的图，哪怕它不精确，哪怕有错。等这张图立住了留下一个简单的脉络，再让问题带着我往下挖。

研究 iOS 的启动优化的时候，我没有一上来就去研究 dyld（负责加载动态库的底层组件）。我是先知道了”应用启动有一大块在动态库加载上”，才回过头开始研究 dyld 的，后来还为它写过一篇文章。

搭图的时候，我不问”怎么才能做好”，这个问题太早了。我问的是更笨的问题：这个领域由什么组成？一条完整的链路有哪些步骤？每个步骤最常见的坑是什么？

拿到地形图，比拿到细节重要。人在陌生领域最容易犯的错，就是把一块局部知识，误当成对整体的理解。

深度没有上限，只有顺序。这一点想通了，很多”我是不是该先补基础”的焦虑就没了——基础当然要补，但补的时机是”你需要它的时候”或者”你好奇的时候”，不是”你以为你该学它的时候”。

三、向 AI 要边界，不要答案

熟悉领域学得快，是因为脑子里存了大量判别点。比如我知道卡顿和掉帧不是一回事，主线程阻塞和渲染瓶颈要分开看，某些性能指标不能孤立解读。

这些判别点，在新领域里一个都没有。怎么办？

我的做法是，主动向 AI 要”容易混淆的边界”。不要只问”RAG 是什么”，要问：RAG 和微调的边界在哪？检索和重排各自解决什么问题？召回很好但答案很差，通常是哪几类原因？什么场景压根不该用 RAG？

这些问题问下来，拿到的不是更多知识，是更多分界线。

我在笔记里写过一句话：和 AI 学习的时候，要习惯当一个杠精。它的每一句解释，都值得追问一句”什么情况下不成立”。追问出来的那些条件，就是判别点。

有个很实用的自检方法。如果一个领域里，你只能问”是什么”“怎么做”“有什么方案”，说明你还停在收集信息的阶段。如果你开始能问”这两个方案的本质差异是什么”“这个说法在什么条件下不成立”“你的这个说法还有哪些不足”“这个系统最先会崩在哪”，说明你进入理解阶段了。

再往上，如果你能问”我该怎么设计实验来证明它”“我怎么构造反例推翻这个结论”，那才算开始掌握。

精通并不是知道得更多更广，而是能敏锐地察觉到细节里的错误，能顺着这些细节提出更锋利的问题。

四、先做起来，再把循环转起来

陌生领域如果没有项目闭环，理解永远是飘的。

学 RAG 的时候，我没有一上来就想做企业级系统。我做的是极小的东西：拿一批自己熟悉的文档，搭一个本地问答，把切分、向量化、检索、重排、提示词拼装各做一个最基础的版本，然后自己出二十个问题去测它。

这个过程会立刻打脸：为什么明明检索到了却答不好？为什么回答看着像对的、其实不准？为什么换个切分策略效果就变了？

一旦亲手撞墙，判别系统就开始长出来了。陌生领域入门，靠”读懂”不够，得靠”撞懂”。

我特别喜欢一句话：最小验证，让坏想法死得早。有想法就赶紧做一个最小的版本出来，让它坏掉。以前验证一个想法要花好几天——查资料、学技术、搭环境、写代码，跑不通就全打水漂。现在跟 AI 聊半小时把逻辑捋顺，一两个小时就能出原型。试错成本降下来之后，我的习惯从”想清楚再做”变成了”做了再想”。

我用 Swift 从头写过一个终端渲染引擎，最后算是失败了。但那一堆失败攒下的经验，比任何一个成功的小项目都多。所以别怕做出来的东西没用，哪怕真的没用也没关系，要学会从中挖掘出经验。

做完之后还有一步，我觉得比做本身更重要：把循环转起来。做一个小东西、拿去用、收反馈、把经验写出来、输出又倒逼你回头系统思考。小循环做项目，大循环做分享。学习、记录、总结、思考、输出，转起来之后会越来越快。

不过”收反馈”这三个字容易被说轻。这里往下还有一层，我管它叫把手弄脏。重点不在”手”，在”脏”：没被潜在用户（包括开发者自己）骂过，不算脏；没把细枝末节论证清楚，不算脏。而且论证要基于能查证的事实，不是基于自己的设想。AI 时代这一点反而更重要——很多东西不认真做下去、只靠 AI 全程代劳，是做不好的，也是学不到的，甚至很多时候 AI 会拿直接但是错误的结论蒙骗你。

输出这一步特别不能省。看懂 AI 的解释，和把一个问题讲清楚，完全不是一个层次。我常用的办法是费曼那套：每学一样东西，就逼自己做一个最小可运行的东西，或者讲给别人听。讲不清楚的地方，就是还没学会的地方。

五、类比能带你进门，但要记得拆脚手架

转行 Agent 的时候，我几乎是本能地把 iOS 那一套听诊器直接贴了上去：Agent 从收到一句话到吐出回答，中间要走哪些步骤，这不就是应用启动流程吗？一次任务跑多久、卡在哪一步，这不就是耗时分析吗？

这套类比帮我省了大量时间。别人还在读文档搞不清一个框架是干嘛的，我已经能凭直觉猜出它大概在哪一层。

但危险也在这里。类比会让你把新东西的形状，硬掰成旧东西的形状。掰得越顺，你越看不见它真正不一样的地方。

应用启动是一条确定的路：从点开到渲染，每一步都排好了，量出总时长就知道瓶颈在哪一格。可 Agent 不是路，是个会拐弯的圈——同一句话进去，它可能跑一轮就收工，也可能来回折腾八轮、调十几次工具。它没有一条固定的关键路径。

如果我抱着旧地图不放，就会一直去找 Agent 的”关键路径”，找不到，然后得出一个错误结论：这东西不可预测、没法做工程。

但事实恰恰相反。做 Agent 不仅是工程，而且是一种更有意思的工程——它的核心不是找一条确定的路径，而是在不确定环境中，通过闭环反馈持续纠偏，让系统误差有界、并尽量收敛到目标区间。这就是控制论研究的事，也是我做 Agent 最大的乐趣来源。

关于用控制论思路做 Agent 开发，我单独写过一篇：读《工程控制论》悟 Agent 开发，感兴趣可以读。

所以我的经验是：类比用来进门，不用来住。用它快速上手，然后主动去找”哪里不一样”。不一样的地方，才是新知识真正住着的地方。

六、理清流程是我的本能

看到一个系统，我会本能地想知道：一个输入进去，到输出出来，中间经过了哪些步骤？每一步的输入是什么、输出是什么、可能在哪里坏掉？

这是做应用 APM 落下的习惯。做性能优化的时候，我脑子里最清楚的一张图，就是从手指点开图标，到界面完整渲染出来，这中间发生的每一件事。换到 Agent，就是从一个问题进去，到答案出来，这中间发生的每一件事。

这个习惯听起来平平无奇，但它是所有后续工作的地基。因为你不把流程理清楚，你连”该在哪里盯”都不知道。很多人做 AI 产品时对效果没底，不是不努力，而是在他脑子里，那个东西就是一个从输入到输出的黑盒子。既然是黑盒子，出了问题你只能对着最终结果瞎猜。

把黑盒子拆开，是解决问题的第一步，也是学习一个系统的第一步。

七、我偏爱会喊疼的失败

我喜欢失败。理由跟”失败让人成长”那套鸡汤无关——暴露出来的失败是安全的。

这是 APM 留给我的一个宝贵的经验。做性能监控最怕的不是崩溃——崩溃虽然难堪，但它会喊，会留下痕迹，你顺着痕迹就能找到它。

真正让人恐惧的是另一种：程序照常跑、界面照常刷、各项指标一片绿灯，但结果是错的。它递给你一个”一切正常”的表情，你在假表情上继续做决策，等有一天终于露馅，已经不知道它是从哪一步开始歪的了。

还有一种夹在中间的更讨厌：大多数时候一切正常，只在极少数情况下突然崩溃。它既不像崩溃那样稳定复现，也不像沉默错误那样完全不响——它偶尔跳出来咬你一口，你想抓它的时候，它又消失了。这种问题排查成本最高，因为你连稳定复现都做不到。

我专门写过一篇文章讲这类沉默故障：一段被截断的回答，渲染出来毫无破绽，从头到尾没有任何报错。那篇叫《没报错，就代表输出没问题吗？》，我甚至按照这套方法，测试出不少有名的开源项目都有问题，给它们提交了修复的 PR。

所以我会有意识去做那些容易暴露错误的事。快速做出原型，让它跑起来，看它怎么坏。坏得越明显，我学得越多。

失败是朋友，沉默是敌人。

八、碎片不碎片，看有没有主线

我经常逛 X，上面有不少 AI 相关的分享。看到不懂的、有意思的，我会复制下来，转身就去问 AI 这是什么、为什么、靠不靠谱。

最开始的时候我自己也觉得是不是有点碎片化啊。

然后经过我的思考和对着 AI 进行激烈的讨论，看法变成了：碎片化的反面是有没有主线，不是学得够不够系统。

如果你手上正好有一些在钻的问题，那么刷到的每一条信息都会被自动筛一遍——相关的留下，挂到已有的问题上；不相关的划走。这时候碎片是养料，因为偶遇能带给你主动搜索搜不到的东西：你根本不知道该搜什么关键词，只能靠撞见。

如果你手上什么都没有，那再系统的东西也是噪音。

这个经验我不仅用在计算机相关的学习上，还用在生活上：看任何东西的时候，都带着一个问题，哪怕这个问题有点牵强。我看金融新闻的时候会想，这跟我要不要在某地买房有什么关系？问题牵强没关系，它逼着你把新东西往自己的框架里挂。

这个时代信息不是不够，是太多了。所以要限制输入，放大判断力——少刷一点，多想一点，哪怕想得有点离谱。想法扯淡没关系，思考的过程本身是有价值的。 孔子说”学而不思则罔，思而不学则殆”，我想在这里补两句：做而不学则废，学而不做则飘。

还有一点。收藏是囤积，追问是盘问。别做成资料收集癖(虽然我自己也是😂)——真正拉开差距的，是你把多少东西真的跑起来过、拆开过、验证过。

九、什么才算”懂了”

现在用 AI 做东西太容易了。你有个想法，跟它聊两句，它就能给你一个能跑的东西。那么如果一个人不太懂原理，但靠 AI 做出了一款应用，他算懂还是不懂？

我的答案是：他算做出来了，但不算懂。而这两者之间的差距，正在被 AI 越拉越大。

我把”懂”分成三层。最外面一层是能把它做出来，这一层 AI 已经基本包办了。中间一层是知道有哪些做法、各自的代价是什么、什么场景下该选哪个，这一层 AI 能给一半——它能列出选项，但经常选不对，因为它不知道你的场景和约束。最里面一层是知道什么才算”好”，这一层 AI 基本给不了，因为那需要对问题本身的理解，而不是对答案的记忆。

有意思的是，AI 恰恰最擅长最外面一层，又最不擅长最里面一层。它的默认输出永远是”大多数人会怎么写”的平均水平:逻辑清楚、能跑通、挑不出错，但也就仅此而已。

它不会主动为了性能去换一个更复杂的数据结构，也不会主动为了复用去做抽象，因为那些做法在它的训练数据里不占多数。

于是出现了一个以前没有的局面：做出来和做好之间，裂开了一道缝。以前你必须先会做才能谈做得好不好，两者是绑在一起的；现在最外面那层被外包了，你不用自己会做也能做出东西，但中间和里面两层，AI 替不了你。

所以我的定位也变了。我不再把自己当做纯粹写代码的，我把自己当成 Tech Lead，AI 是我的团队成员。执行层交给它，不用有心理负担；我的价值集中在两头——定义问题，和验收结果。

定义问题，是把一个模糊的需求，拆成 AI 刚好能接住的模块。这件事得强迫自己往产品经理的位置上站，而且随着开发反复回头想。验收结果靠的是品味——而品味这东西不玄，它是靠大量输入加自己上手磨出来的：读很多、自己也写，好的差的放在一起比，品味就出来了。我给不出有效的反馈，往往是因为我看得还不够多、动手还不够少。

最后

回到最开始那个前提。我后来发现，AI 压缩了一些东西，也留下了一些东西。

它压缩的是：查资料的时间、解释的时间、对比方案的时间、准备试错的时间。

它没有压缩的是：形成判断的时间、积累反例的时间、建立直觉的时间、做取舍的时间。

而真正的掌握，恰恰主要来自后者。很多人误以为获取知识变快了，自己应该也能很快精通，于是急着到处学，最后每一门都停在”看过”的层面。我也有过这种焦虑，后来想通了：快的部分本来就不是瓶颈。

三年前我开始了解 RAG。那时候我学会的流程，和今天在用的几乎完全不是一回事——文档怎么切、怎么找、找到之后怎么筛、怎么塞给模型，每一环都换过好几茬。要是我当年学的是具体做法，今天基本得重学。

好在当年我记住的不是做法，是问题：怎么把外面的知识高效地塞进 AI 的脑子里，让它答得更准。这个核心问题从第一天到今天，一个字都没变过。变的都是手段。

底层的东西该学还是要学。哪怕它以后会变，你至少知道它为什么要变、怎么变的、变成了什么——这跟只会用新版本是两回事。而有些问题，一开始就是模糊的，甚至可能本身就提错了，答案也未必只有一个。事前别假设有标准答案，先把问题定位清楚，而定位这件事本身，也可能随时在变。

现今技术很像一艘不断换木板的忒修斯之船。你每换一块都觉得只是小修小补，等回过神来，整艘船已经没有一块是原来的了。你没法阻止它换，能做的是保证自己手里那门手艺没丢——船是别人的，手艺是你的。