ARTICLE · 1243950
软件工程半死不死,AI 能拯救它吗?
软件工程半死不死，AI 能拯救它吗？
软件工程这套方法论讲了二十多年，公司里真正把它跑通的却寥寥无几。问题从来不是"软件工程没用"，而是"它太贵了"——成本即时落在个人，收益延迟且被分摊。AI 不是来让它"更重要"的，而是来把评审、测试、集成、前期思考的执行成本大幅压低。当这些事不再需要咬牙坚持时，软件工程会自己活过来。
目录
一个尴尬的现状：软件工程，半死不死 它本该长什么样：Google 眼里的软件工程 回到那个根因：软件工程为什么贵 AI 来了：贵的那一部分，正在被抹平 所以，AI 能拯救软件工程吗？
一、一个尴尬的现状：软件工程，半死不死
如果去问一家普通公司的研发负责人："你们做软件工程吗？"
答案几乎一定是："做啊，我们有需求评审、有代码评审、有 CI/CD、有单元测试……"
但你再追问一句："那这些事，是每周都在认真做，还是项目快延期时第一个被砍掉？"
沉默就来了。
这就是"半死不死"的真实含义：方法论人人都懂，流程人人都有，但只有在不忙的时候才被认真对待。 一旦进入交付冲刺，单元测试先停，代码评审变走形式（"项目紧急，先帮我+2吧"、"没空评审，先过吧"），分支策略退化成"一旦项目紧急，就拉分支干活"，文档更是一句"上线后补"再也没下文。
为什么会这样？理由听上去都特别正当：
"没有时间。" 业务方排着队要功能，哪有空写测试。 "投入产出比太低。" 写一小时测试，可能只挡住一个一周后才出现的 bug，而那个 bug 还不一定会被归因到这次改动上。 "团队没这个能力。" 知道要做，但不知道怎么做才不变成负担——最后做出来的东西反而拖慢了自己。
这三条背后，其实是同一个根因：软件工程的收益是延迟的、隐性的、被分摊的，而它的成本是即时的、显性的、落在个人头上的。 这正是研发效能最尴尬的地方：不是缺少方法论，而是方法论的执行成本超出了团队的承受能力。在恶性竞争和交付优先的环境里，这套机制天然会被挤压变形。
不是企业不想做好，是按住当下不痛，比赌一个未来不亏，要容易得多。
二、它本该长什么样：Google 眼里的软件工程
要判断 AI 能不能"拯救"软件工程，得先知道它理想状态下是什么样。《Software Engineering at Google》里给了我们一个参照系。Google 的做法可以用一句话概括：
软件工程不是"写完代码就结束"，而是"代码在整个生命周期里都能被安全地修改"。
围绕这个目标，他们把几件"费力不讨好"的事，做成了像呼吸一样自然的日常。挑几个跟普通公司差距最大的：
1. 代码评审（Code Review）：每一行改动，提交前都要被另一个人看过
Google 的规则近乎苛刻：几乎所有改动在进入代码库之前都要经过评审，每个工程师既是作者也是评审者。 一份评审要拿到 LGTM（looks good to me）才能合并。
听起来很慢？但他们的逻辑是：评审的价值远不止"抓 bug"。
它是知识流动的通道——代码不再是某一个人的私有知识，至少有第二个人看得懂、改得动。 它是代码质量的稳定器——一种约定俗成的标准，通过人与人之间的反馈被持续校准。 它甚至有心理作用——当你知道有人会逐行看你的代码，你写的时候就不会那么随意。
普通公司不是不做评审，而是评审常常变成"找个人点个同意"。AI 能不能把这件事从形式主义里捞出来？后面会说。
2. 单元测试：80/20 的黄金比例
Google 鼓励的测试比例大约是 80% 单元测试 + 20% 更大范围的测试。原因是单元测试快、确定、好写、好定位。
但书里讲了一个让很多团队扎心的场景：工程师 Mary 加了一个小功能，几十行代码，结果一提交，自动化测试系统返回满屏错误。她花了一整天逐个排查，发现这些失败不是真 bug，而是测试太"脆"——对代码内部结构假设过多，改动一碰就碎。
本来半小时的活，拖成一整天的忙碌，扼杀生产力，消磨士气。
这就是软件工程"做坏了"反而比"不做"更可怕的典型：脆弱的测试、不清晰的测试，会让未来的每一次改动都更贵。 很多公司放弃单元测试，不是因为没试过，而是试出了 Mary 式的灾难，于是认定它"投入产出比太低"。
3. 分支管理与持续集成：让"集成"不再是噩梦
Google 基本上是单一代码库（monorepo）+主干开发，改动频繁集成、频繁评审、频繁上线。核心理念是：越频繁、越小的集成，风险越低、越可控。
普通公司常见的反面是：一个功能分支活十天半个月，最后合并那天像过年——冲突解决到半夜，上线后线上炸到天亮。于是大家更不敢频繁集成了，恶性循环。
4. ATDD / UTDD：先想清楚"怎么算做完"，再动手
ATDD（验收测试驱动开发）：动手前先定义"什么样的行为算交付完成"，用可执行的验收测试把需求钉死。 UTDD（单元测试驱动开发）：写实现之前先写单元测试，让设计天然朝着"可测、低耦合"演进。
它们的共同价值：把"需求是不是清楚了""代码是不是做对了"这种本该靠人脑判断、最容易扯皮的事，变成可执行的检查。 但代价是——写测试、想边界、设计可测结构，都需要时间，而且这些时间在交付压力下最先被牺牲。
三、回到那个根因：软件工程为什么贵
把上面四件事摆在一起，你会发现它们有个共同特征：
每一项都是"当下付钱，未来才见效，而且见效还不一定算到我头上"。 这正是它半死不死的根本原因——不是方法论错了，是经济账对个体不划算。
所以问题不是"再喊一遍重视软件工程"——喊了二十年了没用。问题是：能不能有人把"当下付钱"的那部分成本，大幅降下来？
四、AI 来了：贵的那一部分，正在被抹平
这才是 AI 真正可能改变软件工程定位的地方。它不是又一个"提高生产力"的口号，而是精准地、把上面那张表里"成本"那一列，一项项往下压。
1. 代码评审：从"找人点同意"到"先过机器一遍"
AI 现在可以做的事：
改动一提交，自动给出逐行评审意见：命名是否一致、边界是否处理、是否引入已知反模式、是否和团队历史风格冲突。 自动指出"这段逻辑和三个月前某次线上事故的写法很像"，把隐性经验显性化。 对作者：提交前自评一轮，把低级问题先清掉，评审者只需关注真正有价值的判断。
被抹平的成本：评审者的时间、作者被反复打回的等待。评审从"阻塞"变成"前置过滤"，人只做机器做不了的那部分判断。LGTM 的精神（第二个人看过）得以保留，而形式主义的空转被大幅压缩。
2. 单元测试：让 Mary 式的灾难不再发生
这是 AI 降本最立竿见影的地方：
给一段代码，AI 能快速生成覆盖主要分支的单元测试，包括正常路径、边界、异常。 更关键的是可维护性：它可以生成"测行为而非测实现"的测试——只断言公开行为，不假设内部结构，改动一碰就碎的脆性测试大大减少。 当测试失败时，AI 能解释"这个测试当初想验证什么、为什么现在挂了、是真 bug 还是测试过时"，把 Mary 那一整天的排查压成几分钟。
被抹平的成本：写测试的时间、维护测试的时间、失败后排查的时间。当"写一个不脆的测试"从高级技能变成 AI 的默认输出，单元测试的"投入产出比太低"这个老论调就不成立了——是过去人写得差，不是测试本身不划算。
3. 频繁集成：把 CI 的脏活累活交给机器
冲突预判与自动解决建议：分支还没合并，AI 就能提示"你这段和主干上的改动会撞，建议这样调"。 失败日志自动归因：CI 红了，AI 直接告诉你"是这次改动引起的，问题在 X 函数"还是"是环境/上游依赖的问题，和你的改动无关"。 测试选择：只跑和这次改动相关的测试，让"频繁集成"不再意味着"每次都等半小时"。
被抹平的成本：集成的摩擦、失败排查的心智负担。频繁集成从"需要纪律咬牙坚持"变成"顺手就做"，恶性循环才有机会被打破。
4. ATDD/UTDD：把"前期思考"的门槛拉到地面
这是过去最难推广、也是 AI 最有可能普及的一项：
给一段模糊的需求，AI 帮你把它拆成一组可执行的验收用例（ATDD 的第一步），逼着"需求是否清楚"这件事在动手前就显形。 在此基础上再生成单元测试骨架（UTDD 的起点），让"先写测试再写实现"从一个反直觉的仪式，变成一个自然起点。
被抹平的成本：把模糊需求翻译成可执行测试的认知门槛和时间。过去只有资深工程师才做得好的事，现在普通工程师也能起步。这意味着"前期思考"不再是被牺牲的奢侈品。
五、所以，AI 能拯救软件工程吗？
先说结论：能，但不是靠"让软件工程变得更重要"，而是靠"让软件工程变得不那么贵"。
软件工程半死不死，根因是经济账对个体不划算：当下付钱，未来才见效，收益还被分摊。喊"重视"没用，因为没人愿意持续为一个看不见回报的事买单。
AI 做的事，恰恰是把那张成本表一列列往下压：
评审的时间成本 → 机器前置过滤 测试的编写与维护成本 → 自动生成 + 行为级测试 集成的摩擦成本 → 冲突预判 + 失败归因 前期思考的门槛成本 → 需求到测试的自动翻译
当这些成本被压到一个临界点之下，软件工程那套方法论就不再是"理想状态下才做得到"的事，而是"顺手就做了，不做反而更慢"的事。到那时，它不需要被拯救，因为它会自己活过来。
但也要泼一盆冷水：AI 降的是执行成本，不是判断成本。
AI 能生成测试，但"该测什么、不该测什么"还是要人来定。 AI 能给评审意见，但"这个取舍在当前业务语境下值不值"还是要人来判。 AI 能把需求拆成用例，但"这些用例是否真的覆盖了用户真正在意的场景"还是要人来想。
换句话说，AI 把软件工程的体力活承包了，脑力活反而被凸显、被放大。这恰恰是软件工程本该有的样子——它从来不该是堆样板代码的苦差，而该是把"如何在长生命周期里安全地演进一个系统"想清楚的那门手艺。而这，恰恰是研发效能的核心命题。
写在最后
软件工程没有死，它只是一直被"太贵"压着喘不上气。
过去二十年的解法是"呼吁大家重视"，收效甚微，因为呼吁改变不了经济账。AI 给了一条不一样的路：不动方法论本身，只动它的成本结构。
当写一个不脆的测试、做一次像样的评审、把需求拆成用例，都不再需要咬牙坚持时，软件工程就会从"半死不死的口号"，变回它本来的样子——一门让代码在时间里活得更久、改得更安心的手艺。
至于这门手艺最终能落到多深，不取决于 AI 有多强，而取决于我们愿不愿意，把被 AI 腾出来的那些时间，花在真正需要人去想的问题上。
关注「丁克谈研发效能」，获取 AI 时代研发效能的最新实践与思考。
往期推荐：
用 AI-DLC 方法论做软件研发：一句话需求的全生命周期实践 — AI 驱动的全生命周期开发实践 一文搞懂 SDD 和 Harness Engineering：AI 编程从"能跑"到"可靠" — AI 编程的进化路线图 AI 时代，代码整洁之道是否仍然必要？ — 代码质量的思辨与验证 单元测试生存指南：如何写出稳如泰山的单元测试代码 — 单元测试的实践与误区
互动话题：你的团队里，哪一项软件工程实践最先被砍掉？为什么？
