你有多久没阅读源码了

一件让我心慌的事

最近工作中处理了一个 MCP 相关的问题，顺带着想到：Feat 的 MCP 规范实现还停留在老版本。于是我试着让 WorkBuddy 帮我适配新版规范。

它在适应了我的项目风格之后，很快就完成了任务。代码看上去和我的风格如出一辙，说实话，很省心。

但紧接着，一种更强烈的感觉涌了上来：心慌。

因为我发现，自己竟然没有动力去学习新规范的变更点了。反正 AI 已经改好了，能跑，风格还对，我为什么还要去啃那份枯燥的规范文档？

这个念头让我警惕。新规范改了什么、为什么改、边界在哪里，我一无所知。代码在我的项目里，但理解不在我脑子里。

AI 的效率，是一种存量红利

细想下来，AI 的高效是有前提的：它建立在使用者过往的经验和能力之上。

你懂的部分，它是杠杆。这次我之所以敢把适配任务交出去，是因为老版规范我熟、项目我熟，真出了问题，我有把握兜底。但新规范本身，我并没有因为这次适配而多懂一分。

AI 放大的是你的存量。而人是有惰性的——当连增量也可以被代劳的时候，我们就会悄悄停止生长。省心是真的，停止生长也是真的。

半小时的问题，为什么修了三天

这种停滞并不总是温和的，它有时会以事故的方式显形。

自从 AI 越来越好用，有些人陷入了 vibe coding：描述需求、生成代码、跑一下、能跑就上线，连 review 都省了。正常情况下，效率确实是提升的。可一旦出问题，局面就变了——自己没看过代码，只能让 AI 去修 AI 写出来的缺陷，改一处坏一处，原本半小时能解决的问题，拖成半天，甚至几天。

僵局的根源有两个：一是自己不曾看过一眼代码，脑中没有系统的心智模型，AI 给的每个说法都无从判断对错；二是回忆不起当初和 AI 沟通的处理逻辑，连上下文都丢了，想自己接手都不知道从哪接。

AI 能生成答案，但给不了“这里味道不对”的直觉。判断力不是知识，是伤疤。

同样是用 AI，差别在哪

上一篇文章里我写过，前阵子我让 AI 给 Feat 的底层做了次体检，查出 9 处问题。但有一处细节当时没展开：每一处修不修、怎么修，都是我自己读完代码之后拍的板。AI 负责体检，人负责判断。

对照这次的 MCP 适配，同样是我在用 AI，体检那次我守住了判断权，这次我却差点把学习权也一并交了出去。工具没有变，变的是我站在什么位置上用它——是在自己懂的领域借它省力，还是在不懂的领域让它顶替。

前者让人更强，后者让人更闲，然后更弱。

你有多久没阅读源码了

每一个资深程序员，都是经历无数个项目和线上问题的排查磨炼出来的，都是一次次研究底层源码，从小白成长为大牛的。代码只是那个过程的副产品，真正的产出，是那个被磨炼过的人。

现在，阅读源码有 AI 代劳，排查问题有 AI 代劳，连学习新规范都有 AI 代劳。程序员似乎只剩下一件事：提要求。

可是结果可以交付，过程不能。恰恰是那些看起来最“低效”的笨功夫——读源码、啃规范、在完全搞不懂的问题里熬——塑造了人本身。AI 可以替你交付代码，但交付不了那个被过程塑造过的你。

所以，你有多久没阅读源码了？

长此以往，最终沉淀给我们自身的，到底是什么？

我是 Feat 的作者。Feat 是一个高性能 Java Web 服务框架，编译期 AOT、零反射，启动毫秒级、内存占用仅为传统框架的零头，在边缘设备、长连接、私有化部署等场景尤其得心应手。如果你对这个方向感兴趣，欢迎来 GitHub 或 Gitee 看看，点个 Star 就是最大的支持。