ARTICLE · 1128415
AI 工程师为什么仍然需要软件工程基础?
上一篇，我们聊了 AI 工程师的第一项核心能力：构建和部署 AI 应用。
今天，AI 已经不只是帮我们补几行代码。一个好的编程模型，可以根据需求生成代码、调用工具、运行测试、修复错误，甚至独立完成一个完整的开发任务。
于是，一个很自然的问题出现了：既然 AI 已经越来越会写代码，软件工程师还需要学习软件工程吗？
如果代码可以让 AI 来写，那么编程语言、设计模式、系统架构、测试、版本控制、代码质量这些东西，会不会逐渐变得不那么重要？
这是过去一年多里，争论非常激烈的一个问题。
一派认为，Vibe Coding 就是未来，AI 会让编程变得越来越简单，甚至让更多普通人也能成为“程序员”；另一派则认为，AI 生成的代码只是 “屎山加速器” ，短期看效率提升，长期却可能积累更多技术债务
2026 年 8 月 28 日，吴恩达在《The Batch》第 368 期中，专门讨论了这个问题。这也是 AI 工程技能地图中的第二项核心能力——Software Engineering Fundamentals（软件工程基础）。
他没有简单地站在任何一边，而是给出了一个更加冷静的答案：要学，而且比过去任何时候都更重要。
核心判断：Agent 能写代码，但不知道"这里有权衡"
吴恩达这一篇的立论，浓缩成一句话就是：
即使你用 Coding Agent 编写全部代码，理解软件工程基础依然至关重要——因为它能帮你引导 Agent 做出你想要的权衡，甚至让你意识到：这里原来存在需要权衡的问题。
这句话里藏着一个很多人没想明白的因果链。
软件工程的本质，是在一堆互相打架的目标之间做取舍：延迟、可用性、一致性、可靠性、可维护性、简洁度、成本……安全和隐私又给这场博弈加了码。
问题在于：一个不懂软件工程的 vibe coding 新手，根本不知道这些权衡存在。
这张图想说明的，是 vibe coding 最隐蔽的坑：不是 Agent 做错了，而是你根本不知道它做了选择，更不知道它选错了。
吴恩达的原话很直接：
大多数情况下，开发者甚至不知道这些权衡的存在，因此也就没有引导 Agent 针对自己的应用场景做出正确决策。
Agent 负责"实现"，权衡必须留给人。而权衡的前提，是你得先看得见权衡。
正因如此，软件工程基础不是被 AI 淘汰的技能，而是驾驭 AI 的上下文。他把这一项拆成了 5 个能力模块：
吴恩达特别说明：编号只是行文顺序，模块之间没有固定的因果或依赖关系。
模块 1：构建全栈应用 —— Coding Agent 把工程师"拉宽"了
先说一个正在发生的变化：agentic coding 让过去只做前端、只做移动端的开发者，有机会去碰更广的全栈工作。 因为 Coding Agent 能帮你补齐流程里你不太熟悉的那部分。
但吴恩达马上补了一句关键的：这不代表全栈知识不需要了。
Agent 可以帮你实现一个个组件，可"整套系统怎么接起来"，仍然需要人来理解。一个成熟的开发者，要能看懂前端和后端的关键组件与概念：
• UI 组件、缓存（caching）、页面渲染（page rendering） • API 选择与设计、身份认证（authentication） • 状态与会话管理（state / session management）、异步处理、数据持久化 • 测试、安全性、无障碍（accessibility）
实现可以交给 Agent，"知道系统该怎么拼"是人的活。
这其实就是"全栈"这个词在 AI 时代的新含义：不是"每一层都能手写"，而是"每一层如何协同，你都看得懂、判断得了"。Coding Agent 把你从"某一层专家"拉宽成"全栈理解者"，但前提是你得先理解全栈。
模块 2：数据管理 —— 为什么值得单独拎出来讲？
吴恩达把数据管理独立成一个模块，理由有两条，都很有分量：
1. 数据是软件构建的基础； 2. 数据架构相对难以修改——即便 Agent 能帮你做数据迁移，改数据架构依然不轻松。
代码写错了，Agent 分分钟帮你重构；但数据模型选错了，往往意味着一次伤筋动骨的迁移。这就是为什么它值得单独拎出来。
会管数据，意味着你能回答下面这一串问题：
• 系统有哪些访问模式（access patterns）？据此该存什么、存多久？ • 该选哪种数据模型？存储用关系表、文档、键值，还是图？ • 这些决定会如何影响速度、可扩展性、可用性、可靠性与成本？
再往下，还要理解事务（transactions） 与并发（concurrency），保证数据干净、一致、新鲜；必要时落实隐私、治理与合规要求，管理完整的数据生命周期。
而对 AI 应用来说，数据管理还有一个更特殊的因果，吴恩达专门点了出来：
你的 AI 系统，会从你的数据源里获取它自己的输入上下文。所以，如果数据架构选得不好，AI 会"不知道自己不知道什么"（the AI doesn't know what it doesn't know）。
这句话值得反复读。传统软件里，数据缺了会报错；AI 系统里，数据缺了它照样流畅地答——只是答错了，而且毫无自觉。
正因如此，吴恩达说，如何为 Agent（而不只是传统软件或人类用户）构建数据基础设施，会是一个快速演进的新领域，你需要随它一起迭代自己的最佳实践。
数据架构选错，最可怕的不是系统崩，而是 AI"不知道自己不知道"——它会带着残缺的上下文，自信地一路错下去。
模块 3：设计系统架构 —— 为什么没有"标准答案"？
理解了软件和数据的全栈组件后，下一个问题是：怎么把它们组合起来？
吴恩达说，好的系统设计，起点是先搞清楚"这个软件到底要完成什么"：
• 会有多少用户？ • 延迟有多重要？成本有多重要？ • 还有哪些具体约束？
想清楚这些，你才能对架构做出选择：应用平台、前后端边界、系统怎么拆分、应用状态放在哪里、架构粒度——单体（monolith）还是微服务（microservices）。接着再选技术栈：编程语言、运行时、组件 / 前端 / 后端框架、数据技术。有时候，你还需要先做实验来评估不同方案，再定下来。
而这一节最想传达的一个观点是：正确的架构是一个移动靶，它随项目阶段变化。
你为了快速验证原型而选的简单架构，未必适合第一个生产系统；应用规模继续扩大后，生产架构可能又要再变。
真正的工程能力，是知道什么时候该选什么、什么时候该改，而不是背下一套"最佳架构"了事。
这恰恰是纯 vibe coding 最容易翻车的地方：Agent 能飞快产出一套"看似能跑"的系统，但如果你不理解延迟、可用性、可靠性、成本之间的取舍，你就判断不了 Agent 为什么选这个架构，更不知道它是不是选错了。
模块 4：让系统安全可靠 —— 为什么 Security 在"左移"？
可靠的系统，需要一套完整的测试策略。吴恩达列了一组要决策的问题：
• 单元测试与集成测试如何搭配？用哪些测试框架？覆盖率该到什么程度？
除了测试，还要为失败而设计：
• API 遇到限流（rate limit） 怎么处理？ • 某个服务挂了，系统能否优雅降级（graceful degradation）？ • 如何把单点故障的影响范围（blast radius） 压到最小？
而在安全（Security）这块，吴恩达给了一个明确的趋势判断：
安全正在 shift left（左移）——从"软件写完再补安全"，提前到软件生命周期更早的阶段。
这带来一个直接后果：越来越多的开发者，要承担一部分安全工程师的职责。
好消息是 AI 工具能帮上忙：扫描代码漏洞、检查依赖里的供应链注入（supply chain injection）、排查云配置的攻击面（attack surface）。但吴恩达的提醒很清醒：
工具能帮你发现问题，但你仍然要具备足以理解这些问题的安全知识。
否则，扫描报告丢给你一堆高危项，你连哪个该先修、为什么危险都判断不了。
模块 5：规模化与生产运营 —— "能 Demo"为什么不等于"能上 Production"？
AI 编码工具，让"做出一个 demo"变得前所未有的容易。但也正因为如此，吴恩达把"生产运营"列为第五个模块，等于划出了 AI 时代工程人才真正的分水岭：
从 0 到 1 变得很快，从 1 到 100 仍然依赖工程判断。
要服务真实用户，你得理解完整的软件开发生命周期（SDLC）：除了构建与测试，还包括部署环境配置、发布策略、CI/CD 自动化、基础设施即服务（IaaS）。
系统上线后，是另一组问题：可观测性（observability）、告警（alerts）、事故处理（incidents）。
当流量增长时，你要知道怎么扩展服务器、做负载均衡（load balancing），通过分片（sharding）、索引（indexing）、复制（replication）** 调整数据基础设施，必要时改造架构。
最后是长期演进的功夫：版本控制、代码评审、依赖维护、技术债（technical debt）管理。
这一整块，恰恰是 demo 和生产系统之间那道最宽的鸿沟。能跑通一次，和能在真实负载下持续稳定地跑，是两件完全不同的事。
结语
AI 的出现，并没有让软件工程消失。恰恰相反，当 AI 开始参与越来越多的软件开发工作之后，理解软件工程、判断代码质量、设计系统边界、验证最终结果，这些能力的重要性反而被进一步放大。
过去，一个工程师一天只能写有限的代码，因此很多工程实践首先解决的是“如何提高开发效率”。
而现在，AI 可以在很短时间内生成大量代码。新的问题变成了：如何让 AI 生成正确的代码？如何让 AI 在正确的方向上持续工作？如何审查、验证和约束 AI 的工作结果？
这意味着，AI 工程师并不是不需要软件工程了，而是软件工程基础正在从过去的 “亲自写好代码”，逐渐变成今天的 “理解代码、设计系统、约束 AI、验证结果”。
这也是 AI 工程师与普通会用 AI 写代码的开发者之间，越来越重要的一道分界线。
下一篇，我们继续进入吴恩达 AI 工程技能地图的第四项能力：使用编程智能体。当 AI 不再只是一个“代码补全工具”，而是能够理解任务、修改代码、运行测试、调用工具，甚至自主完成一系列开发工作时，工程师到底应该如何与 Coding Agent 协作？
觉得有收获？请 点赞、转发 和 关注 ，让更多工程师看到这篇文章~