AI 帮你写代码之后,软件工程基础不是不重要了,是变成了指挥的语言

有个说法这两年在技术团队里传得很快：AI 都能帮你写代码了，那些底层的工程基础——数据结构、系统设计、数据库原理——是不是可以放一放了？招人的时候，是不是应该更看重"会不会用 agent"，而不是"科班功底扎不扎实"？

吴恩达 8 月底那篇专讲"软件工程基础"的长文，给了一个反直觉的答案：恰恰相反，基础扎实和基础薄弱这两类人之间的产出差距，正在被 AI 拉大，不是缩小。 他的原话很直接——"深刻理解软件运作原理的开发者，表现远远超过不理解的人"。这句话放在 AI 出现之前也成立，但放在现在，它的分量不一样了。

这是吴恩达那张《AI Engineering Skills Map》里，被单独拿出来细讲的第二项技能。在这篇之前，我们已经写过总览《一万份招聘启事聚出来的地图》，也写过"塑造要做的东西"那一项《先定义、再开发？》——这篇接着讲"软件工程基础"，再往后还有"用好编码 agent"这一项。

基础不是拿来跟 agent 比赛的，是拿来指挥它的

这里有个容易被误解的地方：很多人以为"基础重要"这句话的意思是"agent 写不好的地方，你得自己上手写"——好像基础和 agent 是在抢同一份活。吴恩达说的不是这个。基础工程能力，不是用来跟 agent 拼谁写得快，是你用来向 agent 下达指令、并且验收它交上来的东西的那门语言。 你的指挥精度，上限就是你的基础水平上限。

拆开来看，他点了五项具体的基础能力：全栈系统能力、数据、系统架构、安全与可靠性、生产环境规模化。这五项凑在一起，覆盖的正好是一个系统从"能跑"到"能在真实负载下稳定跑"要经过的全部关卡。而这五项里，每一项薄弱，都会在"跟 agent 协作"这个场景里，变成一个具体的失败模式——不是抽象的"基础不好"，是具体某一类坑，agent 会替你挖，你会因为看不出来而把它填平。

举两个吴恩达点到、行业里也确实常见的技术权衡：最终一致性（eventual consistency），说的是分布式系统里，数据更新之后不同节点看到的状态可能有短暂的不一致，系统设计者要在"立刻全局一致"和"允许短暂不一致换取性能"之间做取舍；N+1 查询问题，说的是一段看起来能跑的代码，可能对数据库发出了本该合并成一次的大量重复查询，本地测试数据量小的时候完全看不出问题，一到生产环境的真实数据量就把数据库拖垮。这两个都是经典的、教科书级别的工程权衡问题——不是 AI 时代的新概念，恰恰是"老基础"的一部分。一个没有这层理解的人，agent 给出一版方案，他既提不出要求"这里要不要考虑一致性代价"，事后也看不出方案里悄悄埋了一个 N+1 的坑，只能等它在生产环境爆掉之后再回头救火。

五项基础，各自对应哪种"看不出来"

这张表最大的用处，是把"基础重要"这句正确但空洞的话，翻译成五个具体的、可以拿去问自己团队的问题：agent 交上来的方案，我们在哪一项上，其实压根没有能力去挑刺？

基础这道题，agent 帮不了新人跳过

这里有个自然会冒出来的反问：如果 agent 已经能把大部分基础性的活写出来，那新人是不是可以一边靠 agent 写代码、一边慢慢积累经验，不用像过去那样从底层啃起？

这个想法有一部分道理，但混淆了两件事：跳过"手写"的过程，和跳过"理解取舍"的过程。 靠 agent 生成样板代码去加速上手，这本身没问题，甚至比过去从零手写更快看到系统跑起来的样子；但如果因此就跳过对"为什么这里要一致性、那里要规模化"这些取舍本身的理解，那就是把学习曲线里最有价值的那一段直接删掉了。吴恩达强调的重点从来不是"要不要自己动手写"，是"能不能看懂 agent 交上来的东西里，藏着哪些没被说出口的权衡"——这个理解能力，没有捷径可以靠 agent 帮你补上，因为 agent 本身就是那个可能藏着权衡问题的一方，你不能指望"出问题的人"同时也是"发现问题的人"。

基础没有贬值，它换了一种计价方式

AI 没有让软件工程基础变得不重要，它只是改变了这些基础发挥作用的地方——从"你亲手写出正确的代码"，挪到了"你能不能看出 agent 写的代码哪里不对、该往哪个方向指挥它"。这两件事需要的底层理解，其实是同一套东西，只是被使用的场合变了。

下次你团队里有人问"AI 都能写代码了，还要不要死磕数据库原理和系统设计"，可以直接把上面那张表甩给他：五项基础里，你能挑出 agent 方案里的几个坑？挑不出来的那几项，就是你现在最该补的地方——不是为了跟 agent 比谁写得快，是为了有资格指挥它。

（说句题外话：我们带团队做 AI 项目时，最常见的返工原因就是基础判断没跟上——agent 生成的方案看着能跑，上线后才在扩展性或一致性上栽跟头。如果你们团队也想摸清这道坎该怎么补，欢迎后台聊聊。）