夜雨聆风7 月 6 日, XEngineer 实训营第六期开营（* 实训营仓库：https://github.com/1024XEngineer）。七牛云 AI 效能部工程师、第三期 1024 实训营学员、第五期助教、第六期班主任邓军辉，围绕“AI 时代如何做软件工程”做了开营分享。
许式伟在《AI 时代,企业要学会重新想象自己》中有一个判断：写代码效率提升，不等于软件工程效率提升。这场分享，是这个判断在实训营里的落地版本——它如何变成一套能练、也能被检验的规范。以下是分享内容的整理。
01
火车，从来不是更快的马车
第一次工业革命，蒸汽机车刚出现时，人们叫它"铁马"——一辆用煤不用草、跑得更快一点的马车。
这个名字很有意思。它把火车塞进了旧框架——马车。在当时人们眼里,火车只是一辆跑得更快的马车。
但今天我们都知道，火车改变运输，靠的从来不只是更强的动力。真正起作用的，是围绕它长出来的一整套系统——轨道、调度、时刻表、信号、岗位分工、协同规则。没有这套系统，蒸汽机再强，也只是一台会冒烟的锅炉。
任何一次技术变革，真正产生价值的方式都一样：不是用新工具替代旧工具，而是围绕新工具，长出一整套新方法,并且真正把它用起来。
今天的 AI，正站在“铁马”的位置上。
02
生成不等于生产，速度不等于效率
AI 让写代码前所未有地快。一个页面、一个接口、一段完整逻辑，喝口水的功夫就能生成。这些都是一句 prompt 的事。
但速度不等于效率，生成更不等于生产。
如果只是把 AI 当成一个更快的程序员，往旧流程里一塞——需求还是模糊的，设计还是跳过的，架构还是随着编码被动长出来的——那 AI 带来的就不是十倍效率，而是十倍的混乱。
生成越快，错误被制造和放大的速度也越快。
这正是“把火车当成更快的马车”：拿到了更强的动力，却还在用马车的轨道跑它。局部提速了，系统反而更容易失控。
03
稀缺的从来不是代码，而是交付
在七牛内部，从第三期到第五期的带教里，一个现象越来越明显:
“会用 AI 写代码”的人比比皆是，但“能用 AI 把软件交付出去”的人，依然稀缺。
写代码和交付软件，中间差的是什么？差的，恰恰是那套“轨道、调度、协同规则”。差的是：从一个模糊的需求出发,做出产品的取舍，扛住架构的设计，守住过程的管控，最终把软件交到用户手里。
这件事，AI 替代不了。它能帮你写模块内部的实现，但替代不了“做什么、不做什么”的取舍，替代不了“模块边界画在哪、接口怎么定”的系统设计。
所以这两个月，实训营练的不是写代码，是交付。
04
每一轮都要完整交付，而非把开发拖到最后
八周，切成四个阶段，每两周一个 milestone。
这里最容易被误解：很多人以为“迭代”就是把设计做长、开发往后拖。恰恰相反。
这里走的是敏捷，不是瀑布。每一个 milestone 都是一次完整迭代：完整跑一遍“产品→架构→开发”，最后交出一个可演示、可打 tag 的产出物。八周里每两周兑现一次，而不是攒到最后才交付。
更进一步，理想状态是：第一个 milestone 就把系统主干完整串起来——哪怕大部分模块还是空的。方向对了、骨架稳了，后面每一轮只做微调，把精力放在叠加功能上。
判断一个组架构能力强不强，就看两点：架构频繁大改，说明主干当初没定准；架构稳定却迟迟交不出功能，说明架构不支撑迭代。架构稳定 + 功能持续交付，才是真本事。
05
产品设计是取舍，不是功能清单
四个阶段里，每一轮内部的顺序都不能反：先产品,再架构,再开发。
这听起来是常识。但在真实项目里，它被跳过的次数远超想象。很多人拿到需求，第一反应是“好,开始写代码”，直接丢给 AI。产品没想清楚，代码就长出来了，方向一错，AI 还替你把错误放大。
所以规范里的第一句话就是：产品设计是取舍，不是功能清单。
一份合格的产品设计，要说清楚的不是“我们要做 A、做 B、做 C”，而是这样几个问题：这件事有哪几种做法？选了哪一种？为什么选它？本期明确不做什么？
只罗列功能、不呈现取舍的，不叫产品设计，只能叫愿望清单。
产品设计的交付物也在变。静态原型经常表达不清交互和边界，而软件工程最追求的是“无歧义的共识”。所以有界面的产品，推的是 live demo 而不是一张图——AI 恰好让产品经理也能把想法变成可运行的表达。
06
系统架构必须人来写，不能拿 AI 生成的实现冒充
架构分两层。
模块架构，是单个模块内部怎么实现，多数研发都能把握。系统架构，是模块之间怎么配合、接口怎么定义、数据怎么流转——这才是真正难的地方，也是 AI 最容易糊弄过去的地方。
拿造车打比方：发动机怎么点火喷油，是模块架构；动力系统给空调输出什么、制动什么时候介入、彼此通过什么接口协同，才是系统架构。整车设计，操心的是后者。
实训营推行一种表达方式，叫代码即架构：第一个 milestone 就要在仓库里用真实代码把模块、接口、数据模型定义出来。接口是真的，方法签名是真的，调用关系是真的，只有方法体可以留空。目标是——代码可编译、模块已串联、经评审后合并入库。所有人基于同一份契约并行开发，互不阻塞。
这里有一条红线，与许式伟的判断一致：系统架构的代码，一定是人手写，不要依赖 AI。
AI 可以写模块内部的实现，但模块边界在哪、协作关系怎么定、接口契约怎么设计，必须人来主导。每一个 package 怎么拆、每一个 interface 为什么这样定，人要能讲清楚。如果谁直接让 AI 吐一个“能跑的东西”进来说“架构做完了”——不合格，打回重做。
07
AI 可以参与每个环节，但交付的责任在人
过往几期里一个比较大的坑，是 AI 滥用。一句话把需求交给 AI，做完直接提交，上来就是几千行代码，组里没一个人能讲清它做了什么。这对工程本身、对评审的人，都是灾难。
所以有一条 AI 使用红线。AI 可以参与每个环节，但合入前必须满足三件事:
方案经得起拷问，理由能讲清楚；
代码逻辑有人能完整理解、能讲清、出了问题能改；
关键改动要说明背后的关键 prompt 与人工评审。
整个过程放在 GitHub 上，链路是“Milestone → Issue → PR → Review → Merge → Release”，全程可追溯。而且变更用新增，不覆盖旧判断——一个决策定稿就不改了，要改就新开一份，让演进过程可复盘。
最终交付的责任在人，不在 AI。
结语：两个月后，学员应该带走什么
回到最初那个问题：当 AI 让写代码变得如此廉价，还要不要在意软件工程?
答案是：比以往任何时候都更要在意。
因为工具越强，方法的价值就越被放大。一台更强的蒸汽机，配上混乱的调度，只会撞得更惨；配上成熟的轨道系统，才真正成为火车。AI 也一样——它不会自动带来秩序，只会忠实地放大你原有的秩序，或者原有的混乱。
所以两个月后，希望每个人带走的，不是一份证书，也不是一堆代码，而是一次真实、可追溯、经得起拷问的完整交付经历：从模糊的需求出发，经过产品的取舍、架构的设计、编码的实现、过程的管控，最终把一个软件交付出去。
这段经历，才是 AI 时代真正值钱的东西。
火车从来不是更快的马车。这两个月要一起搭起来的，正是那套让火车之所以成为火车的系统。
---
* 本文整理自七牛 XEngineer 实训营第六期开营分享。欢迎关注 XEngineer，携手成长，持续探索。