ARTICLE · 1042923
吴恩达 Andrew Ng:AI 工程必备技能 Part 3——软件工程基础
The AI Engineering Skills Map
代码能交给智能体写了，甚至能自己开 Pull Request——那工程师还要不要学数据库、系统架构、部署运维？
吴恩达（ Andrew Ng ）在 2026 年 8 月底放出的「 AI 工程技能图谱」系列第三篇《软件工程基本功》（ Software engineering fundamentals ），给了一个和直觉相反的答案：要，而且重要性正在上升。
市面上多数转述把这篇读成"老生常谈的软件工程清单"。真正的信息量在它的论证内核——AI 降低的是手写语法与样板代码的价值，没有降低工程判断的价值。当代码产量突然变快，瓶颈就从"能不能写出来"迁移到"需求是否清楚、架构能否承受变动、数据是否正确、漏洞能否被发现、出错后能否恢复"。这五问，没有一道是智能体替你回答的。
这篇与前一篇《构建并部署 AI 应用》（ Part 2 ）并列，同属 AI 工程四大支柱。据 DeepLearning.ai 团队的说法，整套图谱来自对超过一万份职缺的分析，外加数十位 AI 专家、招聘经理与猎头顾问的访谈及问卷。
为什么代码交给 AI ，基本功反而更值钱
判断这件事，光看吴恩达一方的说法不够，得看第三方数据。几组 2025 年的研究指向同一个方向： AI 是放大器，不是替身。
谷歌云的 2025 DORA 报告回收了近五千份问卷，超过九成受访开发者已在工作中使用 AI ，八成以上认为生产力提升；但同一份报告也指出， AI 采用度与交付稳定性的下降相关。翻译过来就是——测试、自动化、版本控制做得扎实的团队，能把更高的产量转成更快的交付；流程松散的团队，只会让变更更快地涌向下游，事故和返工一起变多。
Stack Overflow 2025 开发者调查补上了另一半： 46% 的受访者不信任 AI 工具的正确性，信任者仅 33%；高达 66% 把"答案几乎对、但没全对"列为头号困扰， 45% 认为调试 AI 生成的代码更费时间。
"几乎对"比"明显错"更难缠。界面正常、测试通过，问题只在特定权限、特定数据量或特定时间顺序下才冒出来。没有基本功的人，压根不知道该追问哪一个 case 。
就连以"AI 提效"著称的 METR ，在 2025 年那项让 16 位资深开源开发者完成 246 个任务的随机对照实验里，也测出用上当时的 AI 工具反而慢了约 19%（后续对更新的智能体测得约 4%–20% 的提速，但样本存在选择偏误）。结论不是"AI 没用"，而是提效幅度高度依赖工具、任务与团队既有的工程能力。
一句话收束这一层：智能体放大的是你已有的判断力，地基不牢，放大出来的只有混乱。
其一：全栈应用——看懂一条从界面到数据库的路径
智能体编码让前端、移动端工程师也能去够更宽的全栈活。但熟练与否，不在于会不会逐层手写，而在于能否画出一个功能从界面到数据库的完整路径，并知道每一层该用什么方式验证。
关键组件一张清单就能列出来： UI 组件、缓存、页面渲染、 API 的选型与设计、身份认证、状态与会话管理、异步处理、数据持久化、测试、安全、无障碍访问。拿"登录"举例，屏幕上的按钮只是入口，后面还挂着身份验证、 Session 、权限、数据读取、超时与登出。按钮能点，不代表数据守得住——只验收"能不能登进去"，最容易漏掉的恰恰是"别人能不能读到不属于他的数据"。
其二：数据管理——地基最难改， AI 连自己不知道什么都不知道
数据值得单拎出来：它是软件赖以构建的地基，一旦打下就相对难改，哪怕智能体能帮忙做迁移也一样。按钮颜色明天就能重画，用户姓名、订单、权限、付款记录一旦存错，后面每个功能都建在歪地基上。说白了，地基歪了，上面盖多高都是危房。
懂数据的人，会先想清楚访问模式，再决定存什么、存多久；能挑对存储类型——关系表、文档、键值还是图——并清楚这些选择如何直接牵动速度、可扩展性、可用性、可靠性与成本；还理解事务与并发，知道怎么让数据干净、一致、新鲜。
原文里最锋利的一句是： AI 系统的输入上下文来自你的数据源，如果数据架构选得糟糕， AI 连"自己不知道什么"都无从知晓。
其三：系统架构——没有永远正确的答案，只有适配阶段的取舍
理解软件与数据全栈的主要组件之后，才谈得上把它们拼到一起。好的系统设计先问目标：多少用户？延迟多重要？成本多重要？再就应用平台、前后端边界、系统拆分方式、状态存放位置、架构粒度（单体还是微服务）做选择。
这里没有标准答案，只有移动靶。为快速原型选的简单架构，未必适合第一个生产版本；等规模上来，后者又得再变。智能体很擅长照常见范例吐出一套"看着挺完整"的架构，却不知道你这产品是 50 个内部用户，还是要服务几百万人。缺了上下文，它可能给 MVP 做出昂贵的过度设计，也可能给正式服务留下无法扩展的单点故障。
真正的功夫，是能说清"此刻为什么选它"，以及哪个数据一变、就该换选择。
其四：安全与可靠性——跑通正常流程，不等于扛得住异常
可靠系统不是"能跑"，而是"坏了也不至于拖垮全局"。这要求先定测试策略——单元与集成测试怎么配比、用什么框架、覆盖率达到多少，再围绕"可能出故障"来设计：如何处理限流、如何内建优雅降级（ graceful degradation ）、如何把一次故障的爆炸半径（ blast radius ）压到最小。
安全也在往前提。所谓"左移"（ shift left ），是把安全工作挪进生命周期更早的阶段，就像开发者人人开始兼做全栈，如今许多开发者也兼职当起了安全工程师。 AI 工具能扫代码漏洞、查依赖有没有被植入供应链攻击、审计云配置的攻击范围——GitHub 在 2026 年就把 CodeQL 漏洞扫描、恶意依赖检查与密钥泄露扫描套到了第三方编码智能体产出的代码上，并称这类自动检查已拦下数百个潜在泄露与漏洞。但要把这些工具用对，仍需要人具备相应的安全知识。
其五：生产环境的扩容与运维——真正的考验从部署之后才开始
本机能跑通，只算过了第一关。服务真实用户，得懂软件开发生命周期（ SDLC ）：配置部署环境、制定发布策略、落地 CI/CD 、理解基础设施即服务（ IaaS ）。跑起来之后，要搭可观测性、设告警、处置线上事故。要扛住规模，得了解真实负载，会扩容服务器、做负载均衡、调整数据基础设施（分片、索引、副本），必要时直接改架构让系统具备弹性。
吴恩达还把版本控制、代码评审、依赖维护、技术债管理归进这一块。它们不会让 Demo 更好看，却决定产品能不能持续改版——当智能体把代码变更的速度抬上去，团队若没有自动测试、清晰的合并规则和可回滚的部署，只会更快地堆出维护不动的债。
语法会过时，内功不会
编码智能体确实改写了造软件的方式，连不含 AI 组件的软件也不例外。一部分知识——比如死记语法——正在贬值；但真正理解软件如何运转的人，远远胜过不懂原理、只会氛围编程（ vibe coding ）的人。
更微妙的是，理解软件基本功还能帮你看清软件能做与不能做什么。这份认知，正是"使用编码智能体"和"塑造构建过程"这两大支柱的重要上下文——也是吴恩达预告里，接下来要拆的下一块。
信末照例一句： Keep building!