吴恩达画了一张 AI 工程技能图：语法贬值，判断力涨价

Coding Agent 已经能从一句需求出发，生成前端、后端、数据库脚本和测试。既然代码可以交给模型写，软件工程基本功是不是也快过时了？

吴恩达最近发布了一张“AI Engineering Skills Map”，给出的答案很明确：语法记忆正在贬值，理解软件如何运行仍然重要，而且会直接影响你能不能把 Agent 带到生产环境。

他说，一个不了解软件基本原理的新手，用 Vibe Coding 做出简单应用并不难。麻烦在应用继续生长之后出现。Agent 会在延迟、可用性、一致性、可靠性、可维护性、简洁性和成本之间做出选择，而使用者甚至可能不知道这些取舍存在。

这正是 AI Coding 最容易制造的错觉：页面能打开、功能能演示，看起来已经“完成”。可软件真正昂贵的部分，通常发生在代码生成之后。

吴恩达把软件基本功分成五块

这张技能图把 AI Engineering 分成四个大方向，其中“软件工程基本功”又包含五个领域：构建全栈应用、管理数据、设计系统架构、保证安全与可靠性，以及在生产环境扩展和运营。

吴恩达发布的 AI Engineering Skills Map（来源：Andrew Ng）

需要先说明：原文把这些内容称为其团队研究所得，但没有公开样本、调研方法或量化结果。因此，这更适合看作吴恩达和 DeepLearning.AI 团队整理的一份工程经验框架，而不是一项可重复验证的实证研究。

它的价值不在于提出了多少新知识。全栈、数据、架构、安全和运维，本来就是软件工程的老问题。变化在于 Coding Agent 把“写出代码”这一步压缩得很短，过去被实现成本遮住的决策，现在更早暴露出来。

Agent 会扩大开发者的边界，也会放大盲区

吴恩达认为，Agentic Coding 会让更多原本专注前端、移动端或后端的开发者承担更广的全栈角色。模型可以补上暂时不熟悉的那部分实现，让一个人跨越更多技术层。

但跨层生成，不等于跨层理解。

一个前端开发者可以让 Agent 写认证接口，却仍需要知道 Cookie、Session、Token 各自带来什么安全边界；后端开发者可以生成 React 页面，却需要判断缓存、页面渲染、状态管理和无障碍是否符合产品场景。

Agent 擅长把明确任务展开成代码。它无法自动补齐那些没有写进需求、也没有出现在上下文里的约束。

例如，“做一个用户登录功能”没有说明账户锁定策略、会话过期时间、设备撤销、审计日志和异常降级。模型当然可以给出一套默认实现，但“默认”只是训练数据中常见的答案，不一定是这个产品的答案。

全栈能力在 AI 时代的含义因此发生了变化。过去强调一个人能亲手写多少层代码；现在更看重他能否看懂整条链路，知道每一层要向 Agent 提供什么上下文，又该检查什么结果。

数据是最难返工的那部分

吴恩达在五个领域中单独强调数据，因为数据架构通常比应用代码更难修改。Agent 能帮忙写迁移脚本，却无法消除错误数据模型留下的长期成本。

做数据决策时，需要先理解访问模式：哪些数据频繁读取，哪些必须强一致，哪些允许延迟更新，保留多久，谁能访问。随后才是关系表、文档、键值或图数据库等存储选择。

这些选择会影响速度、扩展性、可用性和成本，也决定后续 AI 系统能获得什么输入上下文。数据源没有保存的信息，Agent 同样“不知道自己不知道”。

这句话对 AI 应用尤其重要。很多团队花大量时间调整 Prompt 和模型，却把权限混乱、字段含义漂移、数据过期和缺少血缘的问题留在底层。模型层再聪明，也只能在它实际拿到的数据上工作。

所以，AI 工程中的“上下文工程”并不只发生在提示词里。表结构、事件定义、数据生命周期和访问权限，都是上下文的一部分。

架构判断不会被一次生成解决

Agent 很容易生成一个看起来完整的技术栈，也很容易把一个简单需求拆成一组服务。可“能生成”并不能回答“该不该这样建”。

系统设计需要知道用户规模、延迟目标、故障后果和预算，才能决定前后端边界、状态放置、系统拆分，以及使用单体还是微服务。技术栈的选择也可能需要真实实验，而不是让模型按流行度排序。

架构还会随项目阶段变化。为了验证需求，原型可以选最简单的方案；开始服务真实用户后，认证、数据一致性、容量和灾备会改变优先级；规模继续增长，系统可能需要重新拆分。

这类问题没有永久正确的模板。模型可以列出方案、生成试验代码和分析日志，最终取舍仍依赖业务上下文，以及团队愿意承担哪类风险。

代码生成之后的工程决策链（整理自 Andrew Ng 原文）

安全与可靠性，不能等功能写完再补

吴恩达把安全和可靠性放在同一组，因为它们都要求开发者提前设想失败。

测试策略不能简化为让 Agent “多写一些测试”。团队需要决定单元测试与集成测试的比例、关键路径的覆盖方式，以及哪些故障必须通过演练验证。外部 API 限流怎么办？依赖服务不可用时是否降级？一次错误会影响单个请求，还是扩散到整套系统？

安全也在向开发早期移动。AI 工具可以扫描漏洞、检查依赖供应链和云配置，但扫描结果仍需要判断。误报是否可以忽略，修复是否破坏兼容性，某个公开端口在当前网络边界内是否真的危险，这些都不是“通过扫描”四个字能回答的。

Agent 把发现问题和生成补丁变快了。工程师要负责定义威胁模型、故障边界和可接受风险。

生产环境才是基本功的考场

应用交给真实用户后，团队要处理部署环境、发布策略、CI/CD 和基础设施；上线之后还有可观测性、告警、事故响应、容量规划、负载均衡、分片、索引与复制。

这些工作有一个共同特点：答案来自正在运行的系统，而不是代码仓库里的静态文件。

Agent 可以读取指标、分析日志、生成配置，甚至执行部分故障处理。但它需要团队先定义服务目标、告警阈值、操作权限和回滚条件。缺少这些边界，自动化速度越快，事故半径也可能越大。

版本控制、Code Review、依赖维护和技术债管理同样没有消失。代码生成量上升后，这些机制反而承担更多筛选压力。团队需要决定什么代码值得进入主干，什么修改必须由人审查，以及哪些临时方案到了该偿还的时候。

现在学基本功，重点已经变了

如果还按过去的方式学习，花大量时间背 API 和语法细节，收益确实在下降。更有效的练习，是拿一个 Agent 生成的应用，围绕四类问题不断追问：

它在延迟、可用性、成本和一致性之间做了什么默认取舍？
数据放在哪里，生命周期如何管理，模型看不到哪些信息？
哪些故障和攻击路径没有被测试，失败会扩散到哪里？
如何部署、观测、回滚，并在用户增长后继续运行？

学习目标也从“独立写出所有代码”转向“能读懂、能质疑、能验证、能接管”。如果 Agent 给出两个方案，你需要知道该测什么；如果它自信地选错了，你要能看出后果；如果系统线上出问题，你不能只会把报错重新贴给另一个模型。

结语

Coding Agent 正在淘汰一部分低价值记忆工作，比如背诵语法、重复抄模板和手写样板代码。它没有淘汰软件工程的取舍，反而让这些取舍更密集地出现。

吴恩达这张技能图可以压缩成一句朴素的提醒：产码速度不再稀缺，知道该造什么、为什么这样造，以及坏掉后怎么办，才是开发者接下来要守住的能力。