当 AI 把写代码变便宜,软件工程反而成了最值钱的东西

我以为自己捡到了”武功秘籍”

最近我干了件挺折腾但值的事：彻底抛弃 Claude Code、Trae IDE 转投 Codex，然后给它接上了国产大模型 GLM-5.2 并开启了 reasoning …… 

本来只想试试，结果越用越上头。我摸出一套效率翻倍的工作流：先用 Superpowers 跟它一起整理思路，把产品逻辑、页面怎么规划，一条条聊清楚；聊透了，让它生成一份 specs（规格说明）；我对照 specs 逐条查证，确认没问题，再让它分阶段创建 tasks；最后启动 /goal 模式，它会拉起好几个 agent，像流水线一样把任务分头干完。

“流水线”这个词不太精确，但那种感觉就是这样：以前我独自对着编辑器敲一天，现在更像站在指挥台上，把活儿派下去，等着收货。以前这种活儿，我得自己把每个页面、每条接口在脑子里过一遍，再一行行敲出来；现在思路理顺、specs 定好，剩下的几乎不用我动手。

我对着屏幕愣了一下 —— 这不就是大学《软件工程》课上讲的那套东西吗？需求分析、规格说明、任务分解、分阶段交付……当年我嫌它枯燥得要命，现在自己用得停不下来。

我有点得意。这套打法，团队里应该没人玩过吧？我得赶紧去给他们”传经布道”。

结果被他们反向科普了

我兴冲冲把思路整理成“课件”，准备惊艳全场。

结果还没开始，先撞了一鼻子灰。

他们居然早这么干了，而且比我走得远。

我那点得意劲儿还没落地，就被一连串细节打懵了：他们已经会互相分享、合并 specs —— 你写登录模块的规格，我写支付模块的，最后对着合并，确保不打架；前后端的接口，直接拉 AI 来对齐，几轮对话就把字段、参数、返回值捋得清清楚楚，然后各回各家，分头开发。

更让我触动的是他们工作重心的转移。以前闷头写代码、调 bug、为某个语法细节抠半天；现在，大量时间花在理清思路、做好架构、写好文档上，代码交给 AI 去写，自己只做最终验收。他们甚至跟我吐槽：“现在一天写得最多的，不是代码，是 Markdown 文档。“

我本是去当”老师”的，站上讲台才发现，台下坐着一群比我还会用功的人。

怎么说那种感觉呢 —— 不是挫败，是又惊又喜，还带点自嘲：还以为自己捡了本武功秘籍，人家早练到下一层去了。

原来软件工程才是 AI 时代的硬通货

回过神来，我开始琢磨：为什么偏偏是”软件工程”？

大学那会儿，《软件工程》是公认的”水课”。需求分析、概要设计、详细设计、测试验收，一套流程背下来，枯燥得像抄规章制度。我们那会儿崇拜的是能写炫酷算法、把代码压到极致的高手，谁在乎你需求文档规不规范？

可现在，这套被我们嫌弃的东西，恰恰是 AI 时代最值钱的能力。

我搜索了一圈，有个理论能解释这件事。1987 年，软件工程泰斗 Frederick Brooks 写过一篇著名的《没有银弹》，把软件的难度分成两类：偶然复杂性和本质复杂性。偶然复杂性，是工具、语言、手工编码带来的麻烦；本质复杂性，是问题本身有多复杂、需求有多模糊、领域逻辑有多纠缠。Brooks 的判断是：工具再怎么进步，能砍掉的只有偶然复杂性，本质复杂性纹丝不动¹。

这话放在今天再合适不过。AI 干掉的，正是偶然复杂性 —— 查 API、写样板代码、调语法，它秒级就能给你。可”这个需求到底要解决什么”、”模块怎么划分才不乱”、”哪些地方以后会变、得留口子”，这些本质复杂性，AI 替不了你，顶多在你想清楚之后帮你执行。

而这，不正是软件工程一直教的事吗？

所以你会发现，程序员的能力结构正在倒转。以前”敲得快、写得熟”是核心竞争力，谁手速快谁是大腿；现在”想得清、说得准”才是。 你能把模糊的需求变成 AI 听得懂的 specs，能画出扛得住变化的架构，你就有价值。价值从键盘上，挪到了脑子和嘴上。

“软件工程”这个词，本是 1968 年从建筑工程那儿借来的²。以前总觉得名不副实 —— 写代码哪像盖楼，更像手艺人捏泥巴。可现在 AI 时代的工作方式，倒真把这行从”泥瓦匠”逼成了”建筑师”：图纸得你画，规范得你定，施工可以让出去，但楼歪了你得负责。

从来没觉得软件工程如此重要

从”想炫耀”到”被教育”，再到释然，我大概花10分钟去消化。

说释然，是因为作为管理者，看到团队不用我催就跑到了前面，这比我自己学会一个新工具高兴一百倍 —— 上一篇文章我还因为他们学会”偷懒”请了顿新疆菜，这次怕是得再请一顿了。

但真正让我心里发紧的，是另一个感受：AI 没让软件工程过时，反而逼着它回归了本质。当年那些被我们当成”无聊规定”的东西 —— 把需求写清楚、把架构想明白、把文档留好、把验收做严 —— 从来不是形式主义，它们就是对抗复杂性的全部武器。只是以前我们忙着敲代码，没空在意。

现在代码有人替你敲了，你总该好好学学怎么把楼盖对了吧。

从来没有觉得，软件工程如此重要。

人生中，第一次。

参考文献

1. Brooks, F.P. “No Silver Bullet: Essence and Accidents of Software Engineering.” IEEE Computer, 20(4), 10-19 (1987). 

2. Naur, P. & Randell, B. (eds.) “Software Engineering: Report of a conference sponsored by the NATO Science Committee.” NATO, 1968.

本公众号所有内容，未经书面授权禁止一切形式的转载、摘录及摘抄，违者依法追究其相关责任。