「我发布了我没读过的代码」：当 AI 负责写，验证成了新的实现

Sun, 30 Aug 2026 09:00:00 +0800

一年前，我编辑器里的代码，几乎每一行都是我亲手敲出来的。我拥有每一行，慢的地方是「写」。今天，很大一部分代码是「已经写好的」。我描述我想要什么，模型读完我的请求和我的仓库，几秒钟后，屏幕上多出一份 diff。我读它，修剪它，留下好的，删掉坏的。打字不再是难的部分，阅读才是。

难的不是「写代码」，而是快速判断一段代码到底值不值得存在。

这不是一句漂亮话，而是整个职业正在发生的位移。机器没有取代我，它只是把工作挪了个位置：我一天的重心，从「实现」挪到了「验证」。

两个方向的人，拼出完整的图景

有两位我很敬重的人，从相反的方向看到了这个趋势，把他们放在一起，正好画出全貌。

Peter Steinberger 是我在 PSPDFKit 时的老板，也是我近距离观察过的最有产品直觉的人之一，对「发布」这件事有一种近乎偏执的冲动。最近他走得比我们大多数人都远：他做了 OpenClaw，一个 AI 代理，从一个周末实验做到 GitHub 上最火的仓库之一，只用了几个月，然后他加入了 OpenAI。The Pragmatic Engineer 给他起了个标题，把潜台词直接说了出来：「我发布我没读过的代码」。

这句话值得再读一遍。一个世界级的工程师，公开承认自己以「推理速度」发布他没读过的代码。这不是偷懒，而是一个赌注：吞吐量现在比亲手写每一行更重要，而模型足够好、足够频繁地让这个赌注能回本。我还没有完全活在那个世界里，但我理解那个方向，而且我认为 Peter 只是走得早，不是走得错。

另一侧是 antirez，Salvatore Sanfilippo，Redis 的创造者，可能是我见过的最谨慎的程序员之一。如果说 Peter 是踩油门的人，antirez 就是那个时刻确认车还稳不稳的人。他用一种罕见的诚实写了几篇文章来讨论这个转变：在《Coding with LLMs in the summer of 2025》里，他把前沿模型描述成「扩展和放大优秀程序员」的工具；在《Automatic programming》里，他点出了最关键的一点，同一个模型，做同一个任务，结果会因为引导它的人不同而天差地别；在《A new era for software testing》里，他转向那个最直接的推论：当代码来得这么快，我们检查它的方式也必须跟着变。

把两个人拼起来，结论很清楚：一个能干的模型，五分钟产出的正确代码，比一个人一小时能认真读完的还多。瓶颈不再是我们写得多快，而是我们验证得多快、多准。

真正的瓶颈，从「写」挪到了「验证」

这就是这篇文章的核心论点，我把它说直白一点：

当 AI 写代码，验证就是新的实现。

稀缺资源不再是打字速度，而是被快速调用的判断力。是你面对一份不是你写的大 diff，能不能看懂它、信任值得信任的部分、抓住不该信任的部分，然后签上你的名字。新前沿不是生产更多代码，我们已经有无穷多的代码了；新前沿是在这种生产里保持控制，而不是悄悄把判断力交出去。

我自己的感受是，这个转变其实比它听起来更彻底。过去十年，工程师的身份认同感，很大一部分建立在「我亲手写下了这些代码」这件事上。当写代码的成本趋近于零，这份认同感会自然瓦解，取而代之的是另一种更冷静的自我定位：我是那个为代码质量负责的人，无论代码是谁写的。这有点像从「作者」变成了「编辑」，而好编辑的门槛，一点都不比好作者低。

验证需要配得上它的工具

如果读 diff 成了工作本身，那么展示 diff 的工具，就成了我的主要乐器。它应该即时、绝不阻塞、尽量不挡路。这也解释了为什么最近冒出了一批用 Zig 写的、又快又小的工具：Ziggity 是一个 1.9 MB 的静态二进制，3.6 毫秒启动，空闲只占 8 MB 内存；pi 是 Mario Zechner（libGDX 的作者）做的一个小巧的终端代理，一行命令装好，专注做好一件事。

验证 on Codexer

「我发布了我没读过的代码」：当 AI 负责写，验证成了新的实现

两个方向的人，拼出完整的图景

真正的瓶颈，从「写」挪到了「验证」

验证需要配得上它的工具