如果你已经开始用 Coding Agent 做原型、写接口或补测试，吴恩达这篇新长文，像是给产研团队递来一份“续命清单”。
续的不是手写代码的命，而是在 Agent 能写代码之后，你仍然能判断系统该怎么做的能力。
现在做一个应用确实越来越简单：说清需求，等 Agent 生成代码，跑起来，改两轮，一个能演示的产品就出现了。语法不会、框架不熟，似乎都不再是硬门槛。
但吴恩达在最新的 AI Engineering Skills Map 中提醒了一件容易被忽略的事：Agent 可以替你写完所有代码，却不能替你理解软件为什么这样设计。会写代码和会做软件工程，正在变成两件不同的事。
语法在贬值，判断力在升值
过去，开发者要记语法、查文档、处理大量重复实现。Coding Agent 正在接管这些工作。
但一个真实系统从来不是“把功能写出来”这么简单。它要在延迟、可用性、一致性、可靠性、可维护性、简洁性和成本之间不断取舍。
举个假设：产品需要一份经营报表。
Agent 可以同时给出实时计算、定时汇总、缓存查询等方案。三个方案都能生成正确代码，但成本、时效和系统复杂度完全不同。到底选哪一个，不取决于代码能不能写，而取决于业务是否真的需要实时、用户能接受多大延迟，以及团队愿意承担多少长期维护成本。
新手最危险的地方，不是不会写，而是不知道这里存在选择。他无法追问，Agent 就会替他做出默认决定。
这也是 Vibe Coding 的边界：它能快速证明“这个想法可以跑”，不能自动证明“这个系统值得这样建”。
软件工程的五类基本功
吴恩达把软件工程基础拆成五类能力。表面上看，这是一张工程师技能表；换成产品语言，它其实对应了产品从页面走向真实业务的五道关。
01 构建全栈应用：别只看见页面
一个功能背后，还包括前后端边界、API、缓存、身份认证、状态与会话、异步任务、数据持久化、测试、安全和无障碍访问。
Coding Agent 能让人跨越原来的专业分工，但前提是操作者知道完整链路里有哪些部件。否则，页面可以正常点击，权限可能是错的；结果可以显示，状态却无法恢复；演示时很流畅，真实数据一上来就超时。
对产品经理来说，需求不能只描述“页面上有什么”。至少还要回答四个问题：数据从哪里来、状态如何变化、谁能操作、失败后怎么办。
02 管理数据：最贵的不是代码，是改错的数据结构
代码可以重构，数据却带着历史一路累积。
选择关系表、文档、键值还是图，不只是研发细节。它会影响查询速度、扩展能力、可用性、可靠性和成本。字段怎么定义、数据保存多久、谁能访问、何时更新，同样会决定 AI 最终能看到什么。
原文有个很准确的判断：如果数据架构选错，AI 会“不知道自己不知道什么”。它只能在拿到的上下文里推理，无法主动补回系统从未记录、已经过期或无权读取的信息。
所以数据管理是产品经理必须前置参与的领域：业务对象、口径、来源、时效、权限和生命周期，都需要人提供上下文。
03 设计系统架构：正确答案会随阶段变化
原型、首个生产版本和规模化系统，目标不同，合理架构也不同。
原型优先验证价值，可以接受简单方案；生产版本要面对真实权限、故障和数据；规模扩大后，容量、延迟和成本又会成为新问题。
架构不是一次选定的标准答案，而是随项目阶段移动的目标。
产品经理不必决定单体还是微服务，但要把决策条件说清楚：用户规模多大、响应时间要求多高、哪些链路不能失败、成本上限在哪里。没有这些上下文，所谓“最佳架构”只是脱离场景的技术偏好。
04 安全与可靠：不要只验收正常流程
真实系统一定会失败：接口被限流、模型超时、数据库连接中断、第三方服务不可用。
软件工程要做的不是假设故障不会发生，而是提前设计怎么失败：是否重试、何时降级、用户看到什么、故障影响多大、如何恢复。
安全也不能等开发结束再补。权限、隐私、依赖风险和云配置，都应该在需求和设计阶段进入讨论，这就是“安全左移”。AI 可以扫描漏洞，但无法替团队决定哪些数据能被谁看见。
对 PM 而言，验收标准不能只有“成功返回结果”，还应包括异常、降级、权限、审计和恢复。
05 规模化与运维：上线不是句号
把软件交给真实用户，还要配置部署环境、发布策略、CI/CD、可观测性、告警和事故响应。用户量增加后，还可能需要扩展服务器、负载均衡，以及调整索引、复制和分片策略。
这些词听起来偏工程，但对应的都是产品问题：功能失败了多久能发现？哪类失败必须告警？发布异常能否回滚？成本超过多少要介入？技术债何时开始拖慢迭代？
如果一个功能没有运行指标，它上线后就会变成黑盒。团队只能等用户投诉，无法主动判断产品是否健康。
为什么数据和架构要优先判断
五类能力都重要，但从可逆性看，数据与架构的选择通常更难回头。
页面文案可以当天修改，局部代码可以让 Agent 重写。数据一旦积累，迁移要同时处理历史记录、上下游依赖和口径一致性；架构一旦承载真实流量，调整还要考虑停机、兼容、风险和成本。
这不意味着一开始就要设计得很重。相反，原型期仍然应该保持简单。真正要做的是明确：当前方案服务于哪个阶段，它能承载到什么程度，出现什么信号就必须升级。
轻量方案不可怕，把临时方案误当长期方案才麻烦。
产品经理怎么使用 Coding Agent
如果把 Agent 当成一个执行能力很强、但不了解公司业务的新同事，很多问题就容易想明白。
它不缺写代码的速度，缺的是你没有说出口的判断标准。每次让 Agent 生成方案，可以追加一轮追问：
- 这个方案在延迟、成本和一致性上分别做了什么取舍？
- 预计用户规模和峰值负载变化后，哪里会先出问题？
- 数据来自哪里，多久更新，哪些角色可以查看和修改？
- 上游接口、模型或数据库失败时，系统如何降级？
- 上线后用什么指标判断它运行正常？
- 当前设计适用于原型、生产初期还是规模化阶段？
- 哪些决定以后最难修改，现在需要人工确认？
这七个问题不是让 PM 接管技术方案，而是补齐 Agent 最缺少的部分：业务目标、约束条件和优先级。
AI 给产研续的，是判断力
Coding Agent 让记忆语法的价值下降，也让更多产品经理可以亲手做原型、验证想法，甚至完成小型应用。
但实现速度越快，错误决定被固化的速度也越快。以前一份模糊需求会卡在研发评审；现在，它可能在几分钟内变成一个看起来已经完成的系统。
AI 没有让软件工程消失，只是把产研同学的位置从“亲手实现”推向了“决策与驾驭”。
所以，对产品经理真正有价值的技术学习，不是再背一套框架，而是建立一套判断方法：知道系统由什么组成，知道哪里存在取舍，知道哪些选择最难回头，也知道怎样验证 Agent 给出的结果。
会用 AI 写代码，只是起点。能让它在具体业务里做出正确选择，才算真正开始做软件。
参考来源：
- Andrew Ng, AI Engineering Skills Map: Software engineering fundamentals, 2026-08-29