重新思考什么是"软件工程" —— 从业近 30 年老鸟的 AI 工程化观察笔记

引言

我 1998 年进入这个行业。那时的软件工程，还带着一种手工作坊式的庄重：一个人能写多少、写得多稳，是能被同行一眼看出来的能力。此后近三十年，从 C++ 到 Java，再到微服务、云原生，一路走来，见过几轮技术更替，也听过好几回“程序员要完了”的断言。而每一轮过去，写代码这件事本身，反而变得更值钱、更专业——被换掉的从来只是语言、架构与工具，始终没被换掉的，是那个朴素的前提：代码，由人逐行写出来。

但真正让我心里一沉的，不是某一天，而是两个阶段之间那段短短的路。

先是 AI 代码插件百花齐放的那阵子：写代码变成了无休止的 Tab、Tab，一行接一行，快得让人上瘾。那时我还以为，这只是让敲键盘更快了一点。

接着，Code Agent 出现了。写代码第一次成了一个黑盒子——我给出目标，它整个完成，我不再逐行参与。当时我正在重构一个企业邮件的安全网关，一个对确定性和可解释性要求极高的系统。也就在那时，我第一次感到的不是兴奋，是一种说不清的失重。

不是因为它写得快，快是可以预期的。让我在意的是另一件事：软件工程里，什么正在变重，什么正在变轻。代码在同一时间被更快地生成出来，可如何把它写对、写进一个能活十年的系统里，反而更难了。

这篇文章不谈工具用法，也不预测谁会失业。我想谈一个更根本的问题：当 AI 介入之后，软件工程的骨架发生了怎样的位移。看清这个位移，比学会任何一个新工具都重要。

第一部分：工程师的工作，发生了什么质变

软件工程从来就不只是写代码。写代码是其中一环，而且很可能是最不"工程"的一环。需求怎么被理解、边界怎么被划分、风险怎么被控制、一个系统怎么在十年后还能被后人接手——这些才是"工程"二字真正的分量。AI 改变的，恰恰是这一整套安排的重心，而不只是"更快地写程序"。把软件工程等同于写代码，就会看不清正在发生的事。

AI 对工程师工作的改变，落在性质上，而不只是效率上。工具有先进与落后之分，性质的变化却会重塑一个人的工作方式，进而重塑这门学科的骨架。有三处位移，我认为最值得被认真对待。

一、核心动作：从"生成"移到"判断与验收"

很长一段时间里，工程师的价值有很大一部分凝结在一个具体动作上——把需求写成正确、可维护的代码。这门手艺需要长期训练：语法要准，结构要稳，边界要清，命名要让人看得懂。一个人写了多少、写了多久，大致就能看出他积累到了哪一步。

AI 让这个动作变得廉价了。生成一段能跑的代码，如今几乎是瞬时的事。真正发生位移的，是工程师在流程中所站的位置：他从"生产代码的人"，变成"判断代码的人"。生成不再是他工作的核心；判断 AI 的生成物是否正确、是否合适、是否经得起时间考验，才是真正的核心。

这个位移带来一个很少被点破的后果：问责的范围扩大了。过去，工程师对自己亲手写下的每一行负责；现在，他要对自己"放行"的每一段负责。代码可以不是他写的，但只要经他确认进入系统，它就归入了他的责任。代码生成被外包了出去，责任却没有随之减轻，反而更重了——你要为一件并非出自你手的东西，担保它的长期健康。这并不是孤例：2025 年底，OCaml 维护者关闭了一个 1.3 万行、由 AI 生成的 PR，理由之一是这样的补丁无人能真正审查；2026 年初，matplotlib 关闭 AI 智能体提交的补丁时，把规矩写在了明处——机器可以写，但必须有人审、有人负责。而这条线，近几个月还在继续收紧：7 月，Godot 干脆禁止了几乎所有生成式 AI 提交，理由很直白——“AI 承担不了责任”；10 月 7 日，QGIS 又把“人在环中”收紧为“不允许 AI 贡献”。

这里藏着一个不对称：生成是廉价的，判断是昂贵的。AI 把廉价的一端做到了极廉价，却没有让昂贵的一端跟着变便宜。恰恰相反，当生成变得唾手可得，判断的稀缺性反而被放大了——一个团队可以在一夜之间产出过去一个月才有的代码量，却不会在一夜之间多出两个能对架构负责的人。

二、底层假设：从"确定性"滑向"概率性"

传统编程建立在一个几乎不会被质疑的信念上：相同的输入，必得相同的输出。系统的行为可推理、可预测，出了问题能顺着逻辑一路追到底。工程师的职业安全感，正来自这种确定性——他相信自己能完整地解释自己造出来的东西。而现在，AI 每改一次代码、提一次 PR，测试就得完整重跑一遍。

AI 写下的代码，本质上是概率的产物。同样的意图，两次生成可能不同；模型做出某个取舍的依据，未必能被完整追溯。引言里那个"黑盒子"的要害，正在这里：它给你结果，却不大给得出可以逐步复盘的过程。于是工程师第一次要在一种陌生的前提下工作：他要交付一个系统，却无法完全解释它为何是这样写的。这已经超出"代码质量"的范畴，触到了工程师的心智模型——他赖以立足的"可解释性"，第一次出现了缺口。

这件事之所以严重，是因为整套软件工程方法论，本就建立在对确定性的依赖之上。可复现的缺陷、可追溯的因果、可审计的决策——调试、评审、回归测试、事故复盘，每一样都要求"同样的输入得到同样的输出"。概率性把这条地基撬松了：当系统的一部分行为无法被完整解释，我们再谈"责任到人""根因分析"时，底气就不那么足了。

三、度量与知识结构：同时失效

当生成变得廉价，一些沿用多年的标尺开始失灵。代码行数与实现速度是典型的例子：AI 让行数轻易暴涨，价值却未必随之增长，这类指标甚至可能反向——写得越多，未来要维护的越多。

与此同时，真正稀缺的东西浮了上来：把意图讲清楚的能力、判断产出的能力、对系统长期健康负责的能力。与之相应，工程师的知识结构也在迁移——"记住怎么做"越来越不值钱，"知道什么算对、什么该不该做"越来越值钱。这不是一次技能更新，而是一次价值重估：过去被当作"基本功"背下来的东西，正在退居幕后；过去被当作"软技能"打发掉的东西，正在走到台前。

这三处位移指向同一件事：软件工程的重心，正从"实现"这一环，向两端移动。这是下一节要谈的。

第二部分：工程的重心，从中间移向两端

如果只看到"编码变快"，会得出一个过于轻松的结论：工程没有变，只是效率提高了。真实的情况是，当实现环节被压缩，整条流水线的权重分配被打破、重新洗牌。它不是整体前移，而是中间塌陷、两端抬高。

把软件工程的流水线摊开看：需求分析 → 规格（PRD/SOW） → 架构设计 → 任务分解 → 编码实现 → 测试验证 → 部署交付 → 运维反馈。（真实的过程是迭代的，为了看清权重怎么迁移，这里把它简化成一条线性链。）逐个环节看它在这轮变化里的处境，会得到一个清晰的图景。

环节	权重	原因
需求分析	↑	AI 是意图的放大器：意图清晰则产出准，意图模糊则错误被同等放大，而且落得更快
规格（PRD/SOW）	↑↑	规格从"给人看的文档"，变成"给 AI 的输入 + 验收基线"，第一次成为一等公民
架构设计	↑↑	判断力与决策的集中地，也是本轮变化里"变贵"最明显的一环
任务分解	↑	会不会分解，决定能不能把 AI 用到极致；不会分解，只会更快地生产混乱
编码实现	↓↓	从最耗时、最占人力的环节，变成最快、边际价值最低的环节
测试验证	移位	从"末端关卡"前移为"全程地基"，由 AI 批量生成；但"什么叫对"必须由人定义
部署交付	—	几乎没被 AI 解决，甚至更险：AI 给的版本、依赖、配置信息可能已经过时
运维反馈	↑	生成代码量上升，长期可维护性、可观测性、技术债，成为新的核心矛盾

软件工程重心的迁移：中间塌陷，两端抬高（权重为示意）

这张图里有两处最值得警惕。

一是左端。AI 是意图的放大器：你越能把需求说清楚、把问题拆干净，它越能替你省事；你说不清楚，它不会停下来追问，而会用一个看起来合理的实现，把模糊之处填满。于是意图里的每一分模糊，都被放大成系统里的一分混乱——而且落地比以往更快。这里有一个关键的成本结构变化：过去，规格里的含糊可以在编码和测试阶段被慢慢发现、慢慢补救；现在，规格几乎直接变成代码的输入，含糊会被瞬间固化下来。补救没有消失，只是被推迟到了代价最高的时刻。规格先行（Spec First）从一句正确的旧话，变成了一道新的门槛：它不再只是"好习惯"，而是能不能用好 AI 的前提。

而在左端之内，架构设计是最重的一块。架构决策有两个特征：不可逆，且成本后置。今天划下的一条模块边界、定下的一个数据契约，对错往往要到三年后、业务量涨了十倍时才显形。这恰恰是 AI 帮不上、也更危险的地方——它能帮你更快地实现一个决策，却判断不了这个决策值不值得做。当生成被加速，架构的责任不是变轻了，而是变成整个流程里最不能外包的一环。

二是右端。实现被加速之后，压力全部转移到了生命周期的下游。代码生成得越快、越多，长期维护、可观测性、技术债的负担就越重。更要紧的是，部署这一环几乎没有被 AI 真正解决，反而更容易被误导——模型给出的版本号、依赖关系、配置项，可能来自过时的训练资料，照单全收，就是在为未来埋雷。在这一环，AI 提供的不是产能，而是一种新的、更隐蔽的认知风险。

夹在两端的，是测试验证。它发生了一次位置迁移：过去它是流程末端的关卡，负责在交付前把问题拦下来；现在它更像贯穿全程的地基，由 AI 批量铺设。这听上去是好事，却藏着一个陷阱——AI 能生成大量测试用例，却判断不了"什么叫对"。边界条件与验收标准，本质上是对需求的理解，而不是对代码的枚举。用例可以由机器写，"对错的标准"必须由人定。覆盖率上去了，正确性未必跟着上去。

一句话：软件工程的新瓶颈，不在中间的编码，而在左端的规格（把意图讲清楚、拆干净）和右端的治理（让被快速生成的代码，能长期活下来）。旧瓶颈是"写不出来"，新瓶颈是"写得太快，但对不对、活不活得下去"。

还有一条更深的线索：这条"标准过程"本身也在被溶解——规格与编码之间的往返越来越短，设计与分解的边界越来越模糊。过程模型的这场变化，比单个环节的权重迁移更为根本。

第三部分：这不是意外，是规律

说到这里，有人会觉得这是一代人的焦虑。我的判断是：不是焦虑，是规律。

这条规律，我算是从头看了一遍。我 1998 年入行，那年 Java 才诞生三年——它 1995 年发布，正卷入一场持续多年的"疯跑"。此后近十年，不是我们不会写 Java，是我们不知道怎么写好 Java：所有人都在写，目录结构五花八门，异常处理随心所欲，同一件事有一百种写法，没人能说清哪种是对的。一个项目换一拨人，就像换了一种方言，谁也读不懂谁留下的代码。那一批系统，很多都没能活下来。

要到 2006 年前后，Java 才真正趋向成熟。泛型与注解随 Java 5 落地，Spring 2.0 这样的框架把配置、分层、事务一点点规范起来——规矩不再是个人习惯，而成了社区共识。也正是从那时起，我才开始用它大规模构建系统。从一门语言的诞生（1995），到它足以支撑严肃工程（2006），中间隔着十余年。

后来活下来的是哪些？不是写得最花哨的，而是那些在混乱里先立起规矩的：有人开始统一分层，有人开始定义接口契约，有人开始要求写测试、做可观测性。这些规矩当时看起来"慢"、看起来"不酷"，却恰好是让系统活过十年、二十年的东西。它们不解决"写得多快"，只解决"能不能长期活下去"——而这，恰恰是软件工程和"写程序"的分水岭。

每一次工具跃迁，走的都是同一条曲线：先疯跑，再规范。能力喷涌在前，秩序紧随其后。今天 AI 编程给我们的，正是同样一次的喷涌——大致相当于 Java 的 1995 年：能力刚打开，人人都在冲，规矩还没影。而重心迁移本身，不是意外，是规律——它会像当年一样，最终收敛到几个朴素的词上：可维护、可观测、可扩展、可问责。

值得留意的是，这一次的曲线或许更陡。当年，从技术诞生到走向规范，花了十余年；而现在，能力迭代以月计，工具的扩散几乎没有摩擦，混乱也会以同样的速度堆积。留给"自然规范"的时间更短了。这既是危险，也是机会：谁能更早地把规矩立起来，谁就能更早地把产能变成资产，而不是负债。

区别只在于时间。当年那轮规范，是被动的——等出了问题、死了系统，大家才慢慢学会。这一次，我们已经有前车之鉴，有理由主动一点。既然已经看清重心在往两端移动，就不必再等它自然发生、以混乱的代价来补齐。

结语

AI 不会取代软件工程。它只是把"什么是软件工程真正贵的部分"，重新标了一次价。那些被 AI 变便宜的部分——熟练地生成代码——过去被当成工程能力的核心，如今正在迅速贬值。而那些被抬高、变得更贵的部分——判断、架构、责任、品味——才是这门学科真正的内核。它们从来都重要，只是过去被"写代码"这个显眼动作挡在了后面。

对个人如此，对一个行业也是。这近三十年里，软件工程的价值标尺换过几次刻度，但每次换完，真正的内核都会被认得更清楚——它从来不是敲键盘的速度，而是对复杂系统的判断力。AI 没有改变这一点，它只是让这一点，重新变得无法回避。

看清了"变了什么"，下一个问题自然是"那该怎么办"。对个人，是能力结构怎么调；对组织，是团队怎么排、人才怎么养、流程怎么改、面对眼花缭乱的新词怎么保持方向感。这些是另一篇的话题——诊断清楚了，处方才有意义。

【预告次篇：《软件工程被重构之后，企业怎么重建》】

---

原文链接

1. OCaml 维护者拒绝 AI 生成的 PR（21CTO）：https://www.21cto.com/article/5218515026812480
2. matplotlib 关闭 AI 智能体提交的补丁（澎湃·新智元）：https://www.thepaper.cn/newsDetail_forward_32627769
3. Godot 禁止生成式 AI 提交（OpenSourceForU，英文）：https://www.opensourceforu.com/2026/07/godot-engine-bans-vibe-coding-to-protect-maintainers-from-ai-slop/
4. QGIS 投票收紧 AI 政策（cnblogs）：https://www.cnblogs.com/aimagician/p/23285171

（本文由作者执笔，观点、经历与判断均出自本人；AI 辅助的只是资料核实、文字润色与排版校对。AI 可以写，但必须有人审、有人负责——这篇也不例外。）