AI 时代,读代码的能力比写代码值钱

最近总有人问我一个问题：

“AI 写代码又快又好，我是不是该考虑转行了？”

我一般不直接回答，而是反问一句：

AI 生成的代码，你敢不敢一行不读，直接合入主分支？

没有人敢。

这就很有意思了。既然“写”已经可以被机器代劳，而“合入”前那一步永远绕不开人，那说明你的价值并没有消失——它只是挪了个位置：从生产代码的那一端，挪到了审判代码的这一端。

这篇文章的观点就一句话，先放在这里：

AI 把“写代码”的成本打到接近零，同时把“验证代码”的成本完整留给了人。生成越便宜，审判越昂贵。而审判能力只有一种来源——大量读代码读出来的判断力。

下面我用几个追问，来印证这个观点。

追问一：AI 都会写了，“会写”还值钱吗？

值钱，但不再稀缺。这是两回事。

经济学里有个朴素常识：价格不取决于重要性，取决于稀缺性。空气最重要，但免费，因为它不稀缺。

“会写代码”正在经历同样的事。以前一个团队一个月能交付的功能，上限卡在工程师的打字速度和构思速度上——供给稀缺，所以“写得快”是高级工程师最直观的标志。现在 AI 把供给曲线直接打穿了：二十分钟生成两百行，要多少有多少。

供给不再稀缺，价格自然回落。

这种事历史上发生过不止一次。印刷术普及之后，识字不再稀缺，判断一本书值不值得读变得稀缺；计算器普及之后，心算不再稀缺，一眼看出结果数量级不对变得稀缺。

你会发现规律是一样的：机器接管的永远是“生产”，留给人的永远是“审判”。

所以问题从来不是“写代码还有没有用”，而是：当写不再是瓶颈，什么是瓶颈？

追问二：代码能跑、测试也过了，为什么还要读？

这是最容易让人放松警惕的一问。答案是：因为 AI 犯的错误，和人犯的错误，不是同一种。

人写代码，错在逻辑。边界条件没考虑、循环写错了、状态漏更新了——这类错误有明显的“破绽感”，测试和 review 都比较容易兜住。

AI 写代码不一样。它生成的每一行都合理，语法正确、命名规范、模式标准，单独看任何一段都挑不出毛病。它错的地方在接缝处——几段各自正确的代码，拼在一起时依赖了一个不成立的前提。

看个真实感很强的例子。你让 AI 实现“更新用户信息并刷新缓存”，它给了你这样的代码：

1   asyncfunction updateUser(id: string, data: UserData) {2   // 先更新数据库3   awaitdb.user.update({ where: { id }, data });4   5   // 再删除缓存，让下次读取时回源6   await cache.del(`user:${id}`);7   }

两行代码，每一行都对。注释清楚，逻辑通顺，单元测试大概率也是绿的——因为测试里只有你一个人在操作。

但把它放到真实并发里，接缝就裂开了：

1   时刻 1：请求 A 更新数据库（新数据已落库）2   时刻 2：请求 B 恰好来读取，缓存还没删，读到旧数据3   时刻 3：请求 A 删除缓存4   时刻 4：请求 B 把刚才读到的旧数据回写进缓存——旧数据复活了

从这一刻起，缓存里躺着的旧数据会服务很久很久，而你的数据库明明是新数据。每行代码都没错，错的是“更新”和“删缓存”这两步之间假定不会有别人插进来——这个假设在并发环境里不成立。

这类问题，编译器发现不了，lint 发现不了，大部分单元测试也发现不了。能发现它的只有一种东西：一个读过足够多代码、见过足够多事故的人，在扫到这两行时的那零点几秒警觉。

说白了，AI 时代的代码风险，从“写得不对”迁移到了“假设不对”。而假设这种东西，只能被读出来。

追问三：读代码不就是从头看一遍吗？

不是。“从头看一遍”那叫浏览，不叫读。

真正的读代码，至少在读三层东西。

第一层：读意图

这段代码想干什么，和它实际干的是否一致？

AI 生成的代码最常见的错位就在这里：你让它“过滤掉过期订单”，它写出来的可能是“保留最近三十天的订单”——听起来一样，但“过期”的业务定义真的是三十天吗？还是订单状态字段说了算？意图和实现之间的缝，只有懂业务的人能看出来。

第二层：读假设

这段代码隐含了什么前提，前提在真实环境里成立吗？

上面缓存的例子就是典型的假设问题：它假设了串行执行。类似的假设到处都是——假设列表是排好序的、假设这个字段不为空、假设接口一定会返回、假设调用方传进来的是合法值。代码的杀伤力，从来不写在代码里，写在它没说的假设里。

第三层：读后果

改动这段代码，会波及谁？

这是最深的一层。一个函数被哪些地方调用、它的返回值被谁消费、改了它的行为会不会让三个模块之外的某个页面悄悄坏掉——回答这些问题，需要的不是眼前这几行代码，而是你脑子里那幅系统的全景图。

这幅全景图，恰恰是 AI 最难拥有的。不是它读不到代码——它能——而是它的上下文装不下整个系统，每次只能看到局部；就算它翻遍 git 提交记录，看到的也只是“改了什么”，看不到去年双十一那次事故之后，大家为什么宁可绕路也不动那个模块。读后果的能力，本质上是“在脑子里运行整个系统”的能力，它只能靠长期浸泡在这个代码库里长出来。

三层叠在一起，你就明白为什么“扫一眼”不算读了：浏览只能确认“这像代码”，读出意图、假设和后果，才是在确认“这是对的代码”。

追问四：那“读”能练吗？怎么练？

能练，而且 AI 时代练读的环境比以前任何时候都好——因为你突然有了读不完的素材。关键是用对方法。

方法一：把每次 review 当成刻意训练，而不是走流程

拿到 AI 生成的代码，别问“它哪里写得对”，刻意问自己 “它会在什么情况下错”。这两个问题看起来差不多，练的完全是两种肌肉：前者练的是确认，后者练的是怀疑。

但“保持怀疑”四个字还是太虚，怀疑也需要抓手。我自己的做法是把怀疑变成一张固定的清单，每次 review AI 的产出，机械地过三个问题：

问题一：数据会怎么坏？ 字段为空怎么办？字符串特别长怎么办？列表是空的、只有一条、有一万条，分别会怎样？用户重复提交、乱序到达呢？

问题二：世界会怎么动？ 两个请求同时进来会怎样？依赖的接口超时、返回格式变了会怎样？这段代码跑到一半失败了，现场是什么样？

问题三：它会和谁打架？ 谁还在调用它？它和缓存、定时任务、消息队列里的旧数据碰面时，谁说了算？

别小看这张清单的机械性。拿前面“更新数据库再删缓存”那段代码过一遍试试：问题一，数据没毛病；问题二，“两个请求同时进来会怎样”——就这一问，竞态当场现形。那个 bug 不需要你多聪明，只需要你每次都问。

最后加一个强制动作：每次 review 结束前，要求自己至少写下一个“会出错的场景”，写在评论里或者自己的备忘录里都行。 写得出来，说明你真读了；写不出来，就回去再读一遍。这个动作会把“走流程的 review”和“刻意训练的 review”彻底分开——前者消耗时间，后者积累判断力。坚持三个月，你看代码的眼神会不一样。

方法二：去读 AI 读得到、但读不出分量的地方

看到这个小标题，你可能马上会反问：现在的 AI 明明能跨文件读代码，也能翻 git 提交记录，凭什么说它读不出分量？

问得对，它确实能读到。但“读得到”和“读得懂”之间，隔着两样东西。

第一样是上下文的长度。一个真实项目几百个模块、几十万行代码，没有任何上下文窗口装得下整个系统，AI 每次只能抽样读一小部分。这意味着它能回答“这个函数被谁调用了”，却很难回答“改了这个函数，系统里哪里最可能先出问题”——后者需要的是整幅地图常驻脑中，而这个条件，目前只有长期泡在代码库里的人有。

第二样更重要：代码和 git log 记录的是“发生了什么”，不是“为什么”。提交记录告诉你这行代码三年前被改过，但不会告诉你那次改动是为了扑灭一次线上事故；代码里那个看起来多余的防御性判断，不会自己标注“这是去年大促用真金白银换来的教训”。这些“为什么”散落在事故复盘文档里、离职同事的脑子里、团队口口相传的默契里——它们从来没被提交进仓库，AI 自然也就永远读不到。

所以方法二的重点，不是和 AI 比谁读的文件多——那是必输的比赛——而是去读它读不出分量的部分：主动读那些横跨五六个模块的调用链，训练脑子里的整幅地图；读事故复盘文档里“当时为什么没发现”的段落，那是最浓缩的判断力教材；读那些被全团队绕着走的祖传代码，搞清楚每一个“怪写法”背后挡着的是哪段历史。

能被读进上下文的是代码，读不进上下文的是代价。你的护城河在后者。

方法三：写还是要写，但目的变了

最后这点容易走极端，必须说清楚：练读不等于放弃写。完全不动手写代码的人，读代码的功力也会退化——因为判断力来自体感，体感来自亲手踩坑。

正确的理解是：手写代码的目的，从“产出”变成了“保持手感”。 就像飞行员有了自动驾驶之后，依然要定期手动降落——不是不信任自动驾驶，而是不能让自己失去在自动驾驶失灵那一刻接管飞机的能力。

那么问题来了：总不能什么都手写一遍，那样 AI 还有什么意义？确实不用。我自己的判断标准有三条，哪些代码值得你亲手写：

第一，出了事你要半夜爬起来修的代码。 鉴权逻辑、金额计算、订单状态流转——这些是系统的承重墙。它们必须手写，不是因为 AI 写不了，而是因为线上出事的那一刻，你脑子里必须有这段代码的完整地图，没有现查的时间。手写一遍，就是提前把地图装进脑子里。

第二，你还没踩过坑的领域。 第一次接触的技术、没用过的范式、不熟悉的库，第一次一定要手写。让 AI 代劳的结果是“功能上线了，你没学会”——下次它生成错了，你根本看不出来。亲手写过的技术，才有资格审判 AI 生成的同类代码。

第三，review 时你说不清它为什么对的代码。 读 AI 的产出时，如果某一段你看不太懂、但又挑不出错，别放过它——这种“感觉不对”本身就是信号。把这段亲手重写一遍，重写的成本半小时，换来的往往是一个差点溜进主分支的坑。

反过来说，剩下的都可以放心交给 AI：你闭着眼睛都能写对的套路代码、格式转换、测试样板、CRUD——这些手写一百遍也不会多长一分判断力。交给机器，把省下来的时间花在读上。

写在最后

回头看这几个追问，会发现它们其实是同一个问题的不同侧面：当机器接管了生产，人还剩下什么？

剩下的是判断。而判断不会凭空产生，它只能从大量阅读、大量怀疑、大量踩坑里长出来。

这个变化的影响是实实在在的。团队招人，以前面试考“能不能写出来”，以后更该考“能不能看出问题”；个人成长，以前的路径是“写得越来越多”，以后的路径是“读得越来越深”。

所以下次再有人问“AI 都会写代码了，我是不是该转行”，你可以把那个反问还给他：

你敢不敢不读就合入？不敢，就继续读。

AI 负责生产代码，你负责为代码负责。