为什么AI时代软件出事的最根本原因,不在代码里?

9 月 19 日，一位自称热爱终端的开发者发了一份清单，叫 What I believe about the future of software development。

十六条判断里，差不多一半是死刑判决：代码审查会死，单元测试可能会死，终端已死，产品、设计、工程的铁三角也会散。

清单里我最喜欢的一句是讲鞋的。他说，意大利还有手工鞋匠，但你低头看看自己的脚。

这个动作我照做了。然后想起一件他没提的事：流水线把鞋做便宜了，但没有把质检做没。

我在金融行业做架构，工作里很大一块，是判断一个系统能不能上线。读完这份清单，大部分方向我是认同的，可每一条都踩在同一个没写出来的前提上。

这个前提在大多数公司成立。在我待的行业里，一天都不成立。

他说对的那一半

先说我同意的部分，这部分其实不少。

写代码这门手艺在退场，这一点我信。他举了个例子：模型写了 900 行 Arduino C，一次编译通过，烧进设备直接跑起来。这种事放在 2026 年，已经算不上新闻。

大量的增删改查、报表、接口适配，交给模型写，质量不会比人差，速度快得多。我的判断是，这部分代码以后基本不会有人手写了。

他另一条判断，我更想举双手赞成：以后大部分 bug 不会出在写法上，而是出在你一开始就要错了东西。这类 bug，在金融系统里太常见了。

举个最小的例子。需求文档里写一句按日计息。存入当天算不算一天？到期那天算不算？银行常见的做法是算头不算尾，可需求里没写，模型就只能猜。

它猜错了，代码依然完美：编译通过，逻辑清晰，注释工整。逐行审一百遍也审不出问题，因为问题压根不在代码里。

讲到这里，我和他的路就分岔了。他从这一条推出，审查会死，测试也可能会死。我觉得他推反了。

写代码的成本归零，验证的成本没动

如果大多数 bug 都是要错了东西，那唯一能抓住它的办法，是把你到底要什么，写成机器能检查的样子。

这东西有个老名字，叫测试。

他把单元测试比作自行车的辅助轮，骑稳了自然就拆。我更愿意把它看成山路边的护栏。车技再好，也没人去拆护栏，它防的是弯道后面你看不见的东西，跟车技没关系。

一条写着利息必须算头不算尾的测试，就是一段能自动执行的需求。模型越聪明，越需要这种东西告诉它，什么叫做对。

再往下想一层，事情比测试要不要留更大。

2025 年 7 月，研发效能平台 Faros AI 发布了一份报告，分析了 1255 个团队、一万多名开发者的数据。

AI 用得多的团队，合并的代码请求（PR）多了 98%，PR 的审查时间也涨了 91%。

这组数字常被拿来证明，人已经审不过来了，审查该死了。

我读出来的是另一件事：写代码的成本在往零走，验证的成本几乎没动，于是验证成了整条流水线上唯一的瓶颈。

瓶颈不会因为你宣布它死了就消失。它只会挪到下一个没人盯着的地方，通常是生产环境。

这件事，制造业早就经历过一次。

1924 年 5 月 16 日，为贝尔电话系统生产设备的西方电气公司里，工程师休哈特写了一份只有一页纸的备忘录，里面画着后来被叫做控制图的东西。

在那之前，工厂管质量基本就是在成品里挑次品。休哈特的思路是盯住生产过程，让质量在过程里被测量出来。质检从此从老师傅的眼力，变成了一门统计学。

鞋子便宜了，质检没有消失，反而成了更专业的工作。我认为软件正在走同一条路。

写代码越便宜，证明它是对的就越值钱。

审查不会死，它会搬家

逐行看 PR 的那种审查，我同意它在衰落。模型一次改几千行，人确实看不过来，硬看也只是在走流程。

可审查从来不只有找 bug 这一个用处。在银行，它还有个更硬的用处：留下一个签字的人。

金融行业有个通行做法，叫双人复核，也叫四眼原则。一笔大额付款，录入的人和复核的人必须是两个人。一次生产变更，要有人在投产审批单上签字。

模型可以帮你写代码，也可以帮你查代码，查得比人还细。可在金融监管的逻辑里，责任最后要落到具体的机构和人身上。模型不是责任主体。

签字栏里，写不了模型的名字。

所以我的判断是，审查会从读代码搬到读证据。签字的人以后要看的，是这次变更到底想干什么，有哪些证据表明它真干成了。回退方案当然也得备好。

确定性没有退场

清单里最激进的一条是终端已死，配套的说法是：tokens 是新的计算范式，我们正在进入后二进制时代。

有意思的是，这两年最受关注的几款 AI 编程工具，恰恰都长在终端里。

Anthropic 的 Claude Code、OpenAI 的 Codex CLI、Google 的 Gemini CLI，都在 2025 年推出，全是命令行程序。

人确实不怎么敲命令了，敲命令的换成了智能体。他说人类不再需要记命令行参数，这点没错。

那智能体为什么偏爱终端？我的理解是，终端给的反馈不含糊。编译过没过，测试是红是绿，没有商量的余地。

模型本身是概率的，它正需要这种确定的回答来校正自己。

金融系统是同一个结构。模型可以帮你起草一笔复杂的冲正分录，但最后落账的记账引擎必须是确定的：借贷必须相等，日终对账一分钱都不能差。

这条规矩来自复式记账，几百年没变过，不归技术选型管。

概率负责生成，确定性负责验收。

我认为 tokens 确实会成为新的计算层。但它会长在确定性系统上面，把验收交给下面那层去做，不会把它替换掉。

他说我们把计算机一直如何工作，误当成了计算机必须如何工作。可有些地方的必须，是真的必须。

真正的分界线：犯一次错要花多少钱

带着这个视角回去重读那份清单，会发现好几条都在同一个地方拐弯。

好代码不重要，性能不重要，创业公司别学谷歌那一套。这些话成立，有个前提：错了能马上发现，发现了能马上撤回。

他自己也说，99% 的软件没有用户，没人在跑。剩下那 1% 里，跑着工资、存款和清算。

2012 年 8 月 1 日，美国做市商骑士资本做了一次部署。八台服务器里有一台没装上新代码，一个被复用的旗标，唤醒了早已废弃的旧逻辑。

接下来的 45 分钟，系统不停地向市场发单，亏掉 4 亿多美元。当年 12 月，这家公司同意被收购。

这次事故里，没有一行代码是难写的。出问题的是部署和验证：没人确认八台机器是不是都对上了。

在这类场景里，代码好不好读、模型贵不贵，都要让位给一件事：错了能不能被及时拦住。

大公司和小公司的分化确实会加剧，只不过分线不在公司大小，在犯错的代价。

便宜模型那条也一样。他说聪明的模型犯错少，没人愿意接受它错上好几次。

道理没错，可很多受监管的内网环境里，数据不能出域，你未必用得上最强的模型。模型能力打了折，能补回来的只有验证。

判断一个场景能不能照搬这份清单，我会问三个问题：错了多久能发现？发现了能不能撤回？撤不回的时候，谁来签字？

答案要是马上、能、没人在乎，那就放心让模型飞。只要有一个答案让你犹豫，验证就是你最该花钱的地方。

我还没想通的一件事

写到这里，结论看上去挺圆满：写代码的手艺退场，验证的手艺接班。

但有个问题，我想了很久也没想通。验证靠的是判断力，判断力又是从哪儿来的？

我对一段代码靠不靠谱的直觉，是写了很多年代码、踩过很多坑攒下来的。很多资深工程师的手感，是半夜被叫起来查生产故障时长出来的。

如果下一代工程师从入行第一天起就不手写代码，他们拿什么去判断模型写得对不对？

航空业在这件事上交过学费。

2009 年 6 月 1 日，法航 447 航班在大西洋上空遇到皮托管结冰，自动驾驶断开。机组接手后的操作让飞机进入失速，机上 228 人全部遇难。

法国调查机构 BEA 的报告指出，机组没有接受过高空人工操纵的飞行训练。

平时一切交给自动驾驶，人的手艺就没有机会被磨出来。等到真正需要人接手的那一刻，手艺不在。

软件会不会走到这一步？我不知道。也许验证的能力可以不靠写代码来练，比如专门去读模型写的代码，专门给它挑错，像飞行员定期上模拟机那样。也许不行。

这件事我还在想。如果你正在带新人，很想知道你是怎么做的。

你想要那份工作吗

清单最后一条是个问题。他说，今天还有人靠写 ASP 过得挺开心，十年后也还会有人靠写代码吃饭。但你想要那份工作吗？

写代码的那份，说实话，我不太想要了。

我想要的是另一份：替一个系统说清楚什么叫做对，拿出证据证明它确实对了，然后在签字栏里，写下自己的名字。