AI编程推动软件工程的进步

最近和朋友聊天，他兴奋地说：“现在有了AI，我只要喊一嗓子‘给我写个电商网站’，代码就哗哗往外冒。软件工程是不是快过时了？”

我看了看他电脑屏幕上那个跑起来就报错、数据库连接串明文写在提示词里的“电商网站”，拍了拍他的肩膀：“兄弟，你这不是在搞工程，你是在玩抽卡游戏。”

这恰好点出了当下一个流行的幻觉：AI能写代码了，那还要软件工程干什么？

我的看法恰好相反——AI编程不是软件工程的丧钟，而是它等了三十年的一剂猛药。

这剂药逼着我们想清楚一个过去可以稀里糊涂混过去的问题：到底什么才算“把软件做好”？

代码变便宜了，但结构变贵了

早年间的程序员有一项祖传手艺：从寄存器分配开始，亲手把每一比特安排得明明白白。后来汇编来了，C语言来了，Python来了，云原生来了……每一层抽象都让“写点东西跑起来”这件事变得更便宜。当然，每一层也带来了新的技术债：性能开销、运行时黑盒、依赖地狱、微服务半夜断连。

现在AI把这根抽象梯子又往上猛推了一层。

过去你要写五十行排序算法，现在跟AI说“排个序，用快排”，它零点三秒就给你。过去你要琢磨一个支付回调的状态机，现在说“做个支付成功后的处理流程”，AI能给你画一个带重试和超时的草图。

但便宜不等于免费。

这些问题的答案，就是软件工程一直以来的内核。

AI只是撕掉了“写代码很累”这块遮羞布，让我们不得不直面内核本身。

一个形象的类比：过去你手工打造一把椅子，从砍树到榫卯，累得要死，所以只要椅子不散架你就谢天谢地。现在有了数控机床和3D打印机，你做一把椅子只需要在电脑上拖拽几下——但正因如此，你才会发现，真正决定椅子能不能坐的，不是机器打印的速度，而是你画的图纸上那几毫米的公差、材料的承重计算、以及靠背倾斜的工学设计。

制造越便宜，设计越值钱，AI编程同理！

确定性契约：别让AI猜你的潜规则

软件工程里有一个古老的、但经常被人遗忘的宝贝：确定性契约。

简单说就是，一个组件在面对什么输入、什么状态、什么环境时，应该有什么行为，失败时怎么表现，以及这一切能否被客观验证。

在传统开发中，这个契约散落在代码、注释、单元测试和项目经理的PPT里，但人类有个讨巧的本事——我们默认“不说大家都懂”，比如，你让一个同事写“获取用户订单列表”，他大概率会自己加上分页、鉴权、超时处理和空列表的友好提示，因为团队的文化、过往的踩坑经验、代码库里已有的模式，都在无声地告诉他该怎么写。

AI没有这个“不言而喻”的能力，它不是你的老同事，它是一个在全世界所有公开代码上训练出来的、平均主义的概率模型。你跟它说“获取用户订单列表”，它可能给你一个毫无鉴权的SQL查询，可能给你一个只返回十条数据不带分页的接口，也可能给你一个带了Redis缓存但缓存键永远不过期的华丽方案。每个方案都是“某处”的最佳实践，但未必是你的系统需要的正确实践。

这就带来一个尴尬的局面：你以为你下达了指令，其实你只是在抛硬币。

幽默地说，这就像你让一个顶级厨师“做个好吃的”，他端上来一份法式鹅肝，而你想要的是楼下的煎饼果子。鹅肝没错，煎饼果子也没错，错的是你们之间的“菜单”没有写清楚。

在AI时代，软件工程的第一项进步就是：我们必须把过去那些“心照不宣”的规则，变成显式的、可检验的契约。

什么是允许AI访问的数据？什么操作绝对不允许？失败重试几次？日志怎么记？审计怎么追？这些过去可能写在Wiki里但没人看的东西，现在必须成为系统定义的一部分。

不是因为我们变讲究了，而是因为AI真的会乱来。

可重复性：别让今天的代码明天变幽灵

传统软件工程有一个朴素但强大的信念：给同样的源码、同样的依赖、同样的环境，应该构建出同样的制品，这叫可重复性，它是调试、审计、回滚和供应链安全的基础。

AI编程在这里扔了一颗炸弹。

因为AI的本质是概率模型，同样一句话，今天可能给你一个用for循环的实现，明天可能给你一个用map加filter的实现；GPT-4和Claude 3.5的理解也可能截然不同；甚至完全相同的提示词，由于模型内部的随机采样，输出都会有明显的差异。

这就出现了一个令人抓狂的场景：上周五下午，你用AI生成了一个看似完美的模块，所有测试都绿了，你高高兴兴下班。周一早上，产品经理说有个线上bug，你让同一个AI用同样的需求重新生成一遍——结果出来的代码逻辑变了，测试挂了，你盯着屏幕怀疑人生：“我上周五到底部署了个啥？”

这听起来像个段子，但在真实的AI辅助开发中，这种“生成漂移”每天都在发生。

软件工程因此而进步：我们不能再把生成代码当成一次性魔法，我们需要为每一次生成记录“配方”——用的什么模型、什么版本的提示词、什么上下文、哪些依赖被允许、哪些被禁止。这个配方，再加上生成的代码和验证结果，一起锁定为一个不可变的制品。这就像现代料理不仅记录菜谱，还记录烤箱的型号、面粉的批次、甚至当天的室温——因为只有这样，你才能复现那道成功的舒芙蕾。

这种对可重复性的强迫症要求，在过去是被视为过度工程的，但AI时代，它成了必需品。

工具越不确定，工程的流程就越要确定，这本身就是一种进步：它把我们从一个“写完就忘”的草莽状态，逼进了“可追溯、可复现”的科学状态。

提示债：最隐蔽的技术债务

我们都熟悉技术债务：赶工期写的烂代码，后面要花三倍时间重构，AI编程带来了一种更隐蔽的新物种：提示债。

提示债长什么样？举个例子：

你的提示词里写着“只使用安全的客户数据”，但整个系统里没有任何地方定义了什么叫“安全”——没有策略文档、没有字段级的权限标记、没有测试用例验证“不安全”数据是否真的被拦截。

于是这个提示词就像一张空头支票：AI按照它在训练数据里见过的“最常见的安全做法”，比如只过滤掉明显的<script>标签，然后高高兴兴地把用户的身份证号、家庭住址一起吐给了前端。

你问为什么出事了？

AI说：“你让我用安全的，我用了啊，我把XSS防住了。”

崩溃的你会意识到：你把一个架构决策、一个安全策略、一个本应写在代码里的守卫逻辑，偷偷塞进了一句自然语言里，而且没有评审、没有版本、没有责任人。

这就是提示债。

提示债可怕的地方在于，它看起来不像是债，它看起来就只是几行对话。但当你试图修改一个行为、审计一次事故、或者换一个AI模型重新生成时，这些隐式的约定就会变成地雷。你会发现，原来系统里有一半的“设计”都藏在几千字的提示词里，而没有人敢改其中的任何一个词。

软件工程因此而进步：我们被迫把提示词中的架构决策、约束条件和业务规则，显式地提取出来，放到它们该在的地方——策略文件、合约定义、测试用例、代码门禁中。

提示词不再是私人的魔法咒语，而成为一个可审查、可测试、可版本化的“系统定义层”的一部分。

这个过程很痛苦，但这是软件工程走向成熟的必经之路。

系统定义：给AI代码一个模具

说了这么多，到底怎么才能既享受AI的代码生成效率，又不掉进上面的坑？答案是系统定义。

系统定义不是什么新发明，它是一直存在的软件架构和需求管理的升级版。

区别在于，过去我们定义系统是为了指导人写代码，现在定义系统是为了约束AI生成代码。

它的核心包括四样东西：

• 拓扑
  
  系统由哪些组件构成？AI可以触碰哪些组件，哪些绝对不能碰？
• 契约
  
  每个组件的输入、输出、错误、副作用是什么？用什么格式、什么协议？
• 约束
  
  哪些模式必须使用（比如所有数据库操作必须经过ORM），哪些模式绝对禁止（比如字符串拼接SQL）？
• 评估
  
  如何自动验证生成的代码是否满足契约和约束？失败时怎么办？

这套东西听起来有点官僚，但实际操作中可以很轻盈。

比如，你可以为“退款”这个场景写一个系统定义：它由“资格检查”、“支付网关撤销”、“库存回补”、“通知用户”、“审计日志”五个步骤组成，每个步骤有明确的输入输出 schema，失败时必须回滚并发送告警。然后你对AI说：“根据这个定义，生成五个组件的代码，并运行定义中附带的二十个测试用例，全部通过后，锁定制品。”

你看，这时AI不再是脱缰的野马，而是按照工程图纸施工的精密工具。

定义系统的人，才是真正的架构师，AI只是一个越来越听话的高级技工。

工程师的新角色：从码农到边界警察

这就引出了最终结论：AI编程没有消灭软件工程，而是把它抬到了更高的抽象层。

过去的软件工程师很大一部分精力花在“怎么写代码”上：语法、算法、设计模式、框架细节。这些工作有相当一部分可以被AI接管。

但与此同时，另一类工作变得前所未有的重要：定义边界、设计契约、设置约束、编写评估、管理来源追溯。

未来的工程师更像一个“边界警察”加“系统设计师”，他不一定手写每一行代码，但他要回答以下问题：

• 这个功能应该拆成几个AI能独立生成的模块？模块之间怎么通信？
• 哪些决策必须由人拍板，哪些可以交给AI自由发挥？
• 如果生成的代码有安全问题，是提示词没说清楚，还是系统定义里缺少了安全策略？
• 如何保证下个月换了一个更强的新模型后，系统行为依然是可控、可测、可回滚的？

你看，这些问题没有一个是在问“怎么写循环”或者“用哪个排序算法”，它们问的都是结构、约束、可靠性和可问责性，这正是软件工程的本质，只是过去被大量机械性的编码工作掩盖了。

AI编程像一台抽水机，抽走了那些浅层的复杂度，让深层的工程结构裸露出来。

幽默一点说，以前我们自嘲是“码农”——面朝键盘背朝天，一行一行搬砖。现在AI成了搬砖工，而我们升级成了“建筑设计师”加“工地监理”。

如果你只会搬砖，那确实会被淘汰；但如果你会画图纸、定标准、抓质量、管流程，那AI就是你手底下最好用的那支施工队。

结语：能跑的代码不是终点，能管的系统才是

回到开头那个朋友，我后来跟他说：“你要是想让AI帮你写个今晚演示用的玩具，没问题，随便喊。但你要是想做一个支撑十万用户的真实服务，那你需要的不是更会写提示词，而是更懂什么叫契约、边界、可重复性和可审计性。”

AI编程最大的贡献，不是把代码产量提升了多少倍，而是它用最直接的方式告诉我们：软件工程的真正价值从来不在敲键盘的速度里，它藏在那些一旦缺失就会让系统在第三个月轰然倒塌的结构里，AI让代码变得像空气一样易得，反而让这些结构变得像钻石一样珍贵。

所以，如果你是一个软件工程师，不必担心AI会抢走你的饭碗，你只需要往上走一层——从写代码的人，变成定义系统的人，你的键盘仍然重要，但你的大脑，尤其是那个会画边界、会定契约、会预判失效的大脑，比以往任何时候都更重要。

毕竟，有了AI，谁都可以让代码跑起来，但只有工程师，才能让软件一直跑得稳、跑得对、跑得让人放心。

这，就是AI编程推动软件工程进步的最好证明。