两条完全不同的曲线
传统软件开发的难度曲线,大致是平缓起步、匀速爬坡:搭环境、学框架、写脚手架,一步一个脚印;后期代码变多,难度的确在涨,但你知道每一分难度是从哪来的。
AI 辅助开发完全是另一条曲线。前期陡峭得吓人——一天出 demo,三天出原型,一周就能上线一个像模像样的产品。但这种速度不是免费的,只是账单被推迟了:当代码规模超出 AI 的上下文上限,开发难度不是线性上升,是直接爆炸。
拐点出现在 AI 再也装不下整个项目的那一刻。之前,它是全知全能的合伙人;之后,它变成一个只看得见局部的外包——你让它改 A,它不知道 B 依赖 A 的旧行为;你让它加个功能,它不知道三个月前某个角落里写下过一条隐含的约定。
修 bug 的账,越到后期越算不平
这个阶段的体感,一句话就能说清:
解决了一个 bug,同时又产生了 1-3 个显式 bug,外加 n 个隐性 bug。
显式 bug 还好办——报错了、页面白了,看得见就能修。真正可怕的是那 n 个隐性 bug:不报错、不崩溃,只是某个边界条件悄悄错了、某段数据慢慢脏了。它们在暗处发酵,几周之后,以"线上莫名其妙的问题"的形式回来找你。
传统开发里,工程师对自己代码库的心智模型是连续的:哪里埋了雷,他心里有数,因为雷是他亲手埋的。AI 开发里,雷是 AI 埋的,埋的时候没人知道,修的时候 AI 自己也看不见全局。上下文装不下的部分,就是隐性 bug 的滋生地。
复杂度有七张脸,AI 只能按住其中几张
想明白后期为什么爆炸,得先承认一件事:软件工程的"难"不是一种难,而是一组彼此独立的复杂度:
- 规模复杂度(Size):代码行数、文件数本身带来的理解负担。十万行的屎山和十万行的精心设计,读起来是两个世界。
- 圈复杂度(Cyclomatic):一个函数里有多少条执行路径。if 套 if 套 if,路径数指数膨胀,测试都盖不全。
- 算法复杂度(Big-O):数据量涨十倍,程序是慢十倍,还是慢一百倍。
- 架构复杂度:模块怎么切、边界在哪、谁依赖谁。切错了,每改一处都牵动全身。
- 依赖复杂度:每引入一个第三方库、一个外部服务,就是引入一个你控制不了的变量。
- 状态复杂度:系统里有多少可变状态,它们在什么时间、被谁、以什么顺序改变。这是隐性 bug 最大的温床。
- 数据复杂度:数据的结构、流向、一致性。脏数据不报错,但它污染一切下游。
AI 能帮你压住前三种:批量生成代码、捋平嵌套逻辑、写个像样的算法,都不在话下。但后四种——架构、依赖、状态、数据——恰恰要靠全局视野才能管理,而这正是上下文爆炸之后 AI 最先丢掉的能力。
这就是曲线后期爆炸的内在解释:AI 压住了简单的复杂度,放走了难的复杂度,而难的那些,随代码规模指数增长。
AI native,不等于可以跳过软件工程
我们这一代开发者当然是 AI native 的,这一点我毫不怀疑——我自己所有项目,都是 AI 主力写的。但最近我越来越确信另一件事:软件工程,还真得系统地学一遍。
逻辑很简单:AI 把"写代码"的成本打到接近零,瓶颈就整体后移了。以前卡在"会不会写",现在卡在"hold 不 hold 得住"——hold 住架构、hold 住状态、hold 住依赖。而这些,恰恰是软件工程这门学科几十年沉淀下来的主干:模块化、信息隐藏、状态管理、复杂度控制。
尤其是我这种非科班、全靠 AI 上路的人——欠下的基础课,后期的每一个隐性 bug 都会来讨债。
AI 消灭的是打字员,不是工程师。它把工程能力的门槛抬得更高了,而不是更低。
对知识心存敬畏,对计算机心存敬畏
最后说一点情绪,也是这篇随笔真正想说的。
有一种说法越来越流行:AI 都来了,还学什么软件工程?甚至——还学什么计算机科学?
说实话,我觉得这种想法很愚昧。
计算机科学,是几十年里最聪明的一群人,和"复杂度"这个天敌搏斗时攒下来的东西。它没有因为 AI 的出现而过时,反而变成了驾驭 AI 的驾照:不懂复杂度的人,连 AI 写的东西会在哪里坏掉,都判断不了。
对知识心存敬畏,对计算机心存敬畏。工具越强,握工具的手,越需要功力。