当进度吃掉一切人工智能沦为完美替罪羊

先聊聊一个值得关注的现象。

如今，人工智能在应用开发领域可谓势如破竹，攻城略地。你随便问问身边的开发者，有多少人没用过 Copilot 或 Cursor？几乎人人都在用，而且体验普遍不错。生成一个 CRUD 接口、编写业务逻辑、配置路由，这些任务的效率确实得到了显著提升。

为何 AI 在应用层表现如此出色？原因其实并不复杂。

首先，学习样本极其丰富。GitHub 上汇集了上亿个开源项目，涵盖各种编程语言，从电商系统到社交网络，从后台管理到 API 网关，几乎囊括了你能想到的所有业务场景。AI 在这些海量数据上训练过，见过的代码比你写过的还多，生成的结果自然有模有样。

其次，绝大多数业务逻辑，本质上就是增删改查。前端传递参数，后端查询数据库，最后返回一个 JSON。这类工作有多少技术含量？坦白说，并不高。行业内将这类岗位称为“CRUD 工程师”，话虽难听，道理却不假。

所以，AI 处理这些任务确实得心应手。让它生成一个用户列表接口，它甚至会主动考虑分页、排序和模糊查询。这类需求，它见得实在太多了。

但如果你让它做点别的，情况就大不相同了。

比如，让它去阅读 MySQL 的源码，修复一个 Bug 或添加一个新特性。别说修 Bug 了，光是让 AI 把 MySQL 源码下载下来并成功编译，它可能都搞不定。编译环境怎么配置？依赖库从哪里下载？为什么冒出各种莫名其妙的错误？——这些场景，AI 见过的次数屈指可数。

再谈谈运行稳定性。代码能跑通是一回事，能否稳定运行、长期不出问题、出问题时快速定位，则是另一回事。这些能力并非靠“看过足够多的代码”就能掌握。它需要扎实的工程经验、对底层原理的深刻理解，以及对整体系统架构的全局把控。而这，恰恰是 AI 最大的短板。

这里可以做一个明确的判断：AI 在应用层能拿到 90 分，但在基础层，可能连及格线都够不着。

然而，问题的关键在于，现在大家并不关注这些。

大家喜欢看什么？喜欢看表面文章，喜欢听故事。AI 替代程序员、AI 让开发效率提升 10 倍、AI 消灭技术岗位——这样的故事，写的人乐意写，读的人爱看，转发的人乐此不疲。

为什么有人爱看？因为符合预期。许多不懂技术的人，打心底里希望 AI 能大量替代技术人员，最好一个不剩。这样一来，不懂技术的业务人员就再也没有束缚了——想做什么就做什么，再也不用听技术人员说“这个做不了”、“那个工期不够”。

这个愿望美好吗？确实美好。但它真实吗？并不真实。

然而，大家不在乎这些。好听的故事与残酷的现实之间，大多数人会选择前者。

说到这，我想起一个比喻。

火车翻了，你怪车厢质量差，怪乘务员服务不到位——但有没有想过，是谁在驾驶？是谁把火车开进了沟里？

企业经营出现问题，根源并不在技术人员。市场环境恶化、行业下行、战略决策失误、资本盲目扩张——这些才是真正的原因。但最终背锅的，往往是技术团队：“你们系统不稳定”、“你们开发效率太低”、“你们跟不上业务节奏”。

你看，这就是典型的找错了原因。

回到 AI 这件事上。

当前 AI 的发展速度实在太快，快到人力根本来不及审核。你让 AI 每天生成几千行代码，再让开发人员去 review？这简直是天方夜谭。代码审查本来就是稀缺资源，现在变得更加稀缺了。

有人会说，那就让 AI 来审核 AI 写的代码。

说这种话的人，大概率没有真正搞过测试。

很多场景下，测试先天就无法全覆盖。比如高并发下的竞态条件、极端参数组合下的边界行为、以及某些仅在特定硬件或网络环境下才复现的问题。这些情况，让 AI 来测，它根本测不出来。因为它没见过，它的训练数据里没有。

那如果没有测试环境怎么办？在中国，许多小公司和创业团队压根就没有完整的测试环境。生产即测试，上线即验证。这当然不规范。

但你需要明白两件事。

第一，在中国，不规范的企业比比皆是。这不是个别现象，也不是少数团队的问题，而是一个普遍、长期存在的现状。你跟它谈规范，它反问“规范了谁干活”。

第二，你都已经用 AI 来赶进度了，然后回过头来跟我谈规范？这就像你已经开始饮鸩止渴，然后跟我说要注意养生——你不觉得这个逻辑有问题吗？

那些能大面积用 AI 替代开发的企业，绝大多数——注意，是绝大多数，不是全部，别抬杠——他们并不太在意质量，只关注进度。只要代码能跑起来、能交付、能上线，后续的问题以后再说。至于性能好不好、安不安全、维护起来方不方便，那都不是当前要考虑的事。

在这种心态下，出问题只是时间问题。

所以，近两年很多专业人士在呼吁：AI 时代要重视软件工程。

说实话，看过许多行业和公司，真正重视软件工程的，并不多。

有个经历值得一提。当年考软考项目管理时，看到题目，脑子里第一反应永远是“日常是怎么做的”。然后就知道，完了，这道题肯定错了。因为日常的做法，与标准答案之间，差了十万八千里。

这不是个例。这是整个行业的大环境。

有时跟一些朋友交流，会问到这样一个问题：当进度和质量发生冲突时，你怎么选？

作为开发者角色的多数人回答是：“当然保进度。领导要的是进度。”

这才是真正的心声，才是真实的行业大环境。什么代码规范、单元测试、性能优化，在“下周必须上线”面前，统统靠边站。

所以，你现在看到的 AI 替代开发这件事，放到这个大环境里看，就一点也不奇怪了。

如果你不考虑质量、不考虑性能、不考虑安全，那么你可以完全 all in AI，让它去写代码、去做运维、去处理所有的事情。一点问题都没有。谁说有问题，就去反驳他。

但如果你考虑的，是一个系统能否稳定运行三年五年，能否扛住业务高峰期的流量冲击，能否在出现故障时快速恢复——那你就得认真思考了。

火车翻车之前，车厢和乘务员都没问题。

问题是，谁在开车？