网硕互联帮助中心TL;DR
- 2026-09，吴恩达发布技能地图序列文收官篇：深解"定义构建"
- 这一项被拆成 4 项技能：驱动构建循环、做产品决策、沟通与领导、高主动权担责。
- 核心判断：过去"PM 定需求、开发者只管实现"的分工正在模糊。会 AI 工程的开发者，既建软件，也参与定需求、排优先级。
- 一个反直觉的机会：很多高管还不清楚 AI 能做什么、什么是好方向。这给懂技术的人留了位置——发现 problems、提方案、亲手落地，不用等精确的自上而下指令。
吴恩达《AI工程技能地图》的深解系列到最后一篇了。第四篇拆解"定义构建"，地图里的第四项技能。他给这篇定的调子是：等你精通 AI 工程，你最好的工作就不再是实现别人写好的规格，而是主动决定要构建什么。我为大家逐条拆开：这一项背后，藏着 4 项技能。文末附四篇连读总览，整个系列一次看全。 
背景：这篇回应的是什么问题？
8 月 14 日，吴恩达发布《AI工程技能地图》，提炼出 4 项核心技能。之后三周，深解01 拆"构建和部署 AI 应用"，深解02 拆"软件工程基础"，深解03 拆"使用编程智能体"。第四篇落地，主题是地图最后一项：“定义构建”（Shaping the build）。
这篇回应的是一个老问题的新版本：需求谁定，代码谁写，这条线还分得开吗？
过去的分工很清楚：产品经理（PM）和设计师定义做什么，开发者负责实现，项目经理推排期。 吴恩达的判断是：这条分工线正在模糊，而且是双向的——会 AI 工程的开发者在参与定需求，PM 和设计师也在学 AI 工程参与构建。
带来的变化很实际：会定义构建的人，不用等 PM 把每件事想清楚才能动手。这就是本篇要拆的 4 项技能。
定义构建，为什么能拆出4项技能？
先看全貌。吴恩达把"定义构建"拆成 4 项技能：
| 驱动构建循环（Driving the build loop） | 写一点、拿反馈、定下一步，让项目以 AI 允许的速度跑起来 |
| 做产品决策（Making product decisions） | spec 没覆盖的事也能拿主意，产品感、设计感、商业感都在线 |
| 沟通与领导（Communicating and leading） | 跨职能协调，替组织"翻译"AI 到底能干什么 |
| 高主动权担责（High-agency ownership） | 不等指令，发现问题、提方案、亲手落地 |
这 4 项不是步骤顺序，是"会定义构建"的四个侧面。下面逐条拆。
技能1：驱动构建循环——为什么"先动起来"排在第一位？
大部分软件是这么造出来的：写一点代码，收集一些反馈，决定下一步做什么。这是个循环。
会定义构建的人，在这个循环里扮演驱动者的角色：反复决定下一步怎么走，让项目往前挪。 吴恩达给这类人贴了一个标签：偏向行动（bias for action）——用 AI 带来的高速度去推这个循环。
具体怎么推，有一组典型选择：快速做个原型，验证一个技术概念或用户功能；搭一个 MVP（最小可行产品）拿给用户，演示价值；或者反过来，往企业级系统投入。他特别强调小批量发布（shipping in small batches），用小步快跑保住速度。
什么时候该找用户或利益相关者拿反馈？什么时候该先跑一个技术实验（比如训练一个模型）来收集信息？这是驱动循环的人要反复做的判断。判断依据是一串约束：产品愿景、项目阶段、技术可行性、关键风险、工作量、预算。
项目成熟之后，还有一层功夫：定义关键指标（key metrics），用项目管理把指标推上去。
技能2：做产品决策——为什么 spec 没写的地方也要你拿主意？
吴恩达把话说得很清楚：开发者不必变成 PM，但你要能对"spec 没覆盖的事"做决策。 如果有人让你在没有 spec 的情况下开工，你要知道怎么把 spec 开发出来。
这背后是三种感觉：
- 产品感（product sense）：能挑出满足真实用户需求的产品方向，不用等 PM 做每个决定。
- 设计感（design sense）：至少有基本的审美判断，做出来的东西不光能用，还得好用。
- 商业感（business sense）：能想明白进入市场策略（go-to-market）、市场规模（market size）、单位经济（unit economics）、损益（P&L），在花钱和赚钱之间做合理的权衡。
这三种感觉从哪来？扎在用户共情（user empathy）上。 共情不是玄学，它靠方法持续打磨——他给了一个从轻到重的工具箱：
- 找 2-3 个用户做快速非正式访谈；
- 发几百人的问卷；
- 跑大规模 A/B 测试；
- 分析成千上万甚至上百万用户的行为数据。
这些输入，都会变成你对用户理解的一部分。
技能3：沟通与领导——为什么懂技术的人最适合替组织"翻译"AI？
AI 工程让你的工作范围不再限于技术。 一个项目会碰到营销、财务、法务这些职能，你的沟通能力变得比过去更重要——把利益相关者对齐、协调好，项目才能往前推。 顺带一提，沟通能力也是你和用户对话、打磨共情的基础。
这一节还有个特别的观察。 AI 技术变化太快，很多工程以外的人——包括管理层——正在努力理解这项技术、它对自己工作的影响、以及它带来的新做法和新产品。
这时候，你的 AI 工程技术能力就成了稀缺资源：你可以解释某些举措在技术上到底可不可行，帮组织建立对 AI 的判断，进而帮助整个组织往前走。
技能4：高主动权担责——为什么"不等指令"反倒是机会？
这是全文最有意思的一节。 吴恩达点出一个现状：很多人——包括一些高管——还不理解 AI 能做什么，也就判断不了什么是好的项目方向。
这个认知缺口，给有技术能力的人开了一扇窗：你可以去发现 problems、提出 solutions、然后亲手执行。前提是尊重组织的优先级和约束，但不需要等一份精确的自上而下（top-down）指令才动。
“高主动权”（high-agency）说的就是这个：AI 工程技能给了你大量做成事的机会，抓住它的方式，是自己走上前去认领。
收官：四篇连起来，这张地图长什么样？
至此，《AI工程技能地图》四项技能全部拆解完毕。把四篇连起来看，整张地图是这样的：
| 总纲 | 4 项技能总览 | — | 所有开发者都需要 AI 工程技能，不只是"AI 工程师" |
| 深解01 | 构建和部署 AI 应用 | 6 项子能力 | AI 输出不可预测，用评测闭环把它治理住 |
| 深解02 | 软件工程基础 | 5 个能力模块 | AI 越会写代码，判断 trade-off 的能力越值钱 |
| 深解03 | 使用编程智能体 | 5 个核心能力 | 会调用只是起点，会指挥、会验证才是会用 |
| 深解04 | 定义构建 | 4 项技能 | 从"实现别人定的规格"走向"决定该构建什么" |
看得出这条主线：越往后，离"写代码"越远，离"决定做什么、并对结果负责"越近。 吴恩达在总纲里就点明了：托住这四项技能的底座是持续学习。工具和最佳实践都在快速变，学习本身就是一项工程技能。
这个系列到这里告一段落。后续吴恩达在 The Batch 的新内容，我会持续跟进。
FAQ
Q：这篇深解和前面三篇是什么关系？ 深解01 拆"构建和部署 AI 应用"（6 项子能力），深解02 拆"软件工程基础"（5 个能力模块），深解03 拆"使用编程智能体"（5 个核心能力）。这篇是地图第四项"定义构建"的详细展开，也是收官篇。四项技能至此全部拆完。
Q："定义构建"到底是什么？一句话说清。 就是从"拿到 spec 去实现"，变成"参与决定 spec 里该有什么"，并对构建结果负责。
Q：工程师要转岗做 PM 吗？ 不用。吴恩达的原意是：你不必成为 PM，但要能对 spec 没覆盖的事做决策，没有 spec 时能自己开发一份。产品感、设计感、商业感是补充，不是转行。
Q：四项技能里，该先学哪一项？ 按总纲的说法，四项是能力的划分，不是学习步骤。一个常见的参考顺序是：先补软件工程基础和评测闭环（01、02），再练智能体协作（03），定义构建（04）更多靠在真实项目里持续练。底座的持续学习贯穿始终。
系列文补充：
- AI工程技能地图：企业数字化团队最该补的4项能力
- 吴恩达AI技能深解①：构建部署AI应用，6项硬功夫逐条拆
- 吴恩达AI技能深解②：软件工程基础，为什么"AI越会写代码它越重要"？
- 吴恩达AI技能深解③：使用编程智能体，“会指挥“比“会写码“更值钱
- 吴恩达AI技能深解④：定义构建，工程师为什么不用再等 PM？
附录：原文速查
原文出处
- 原帖：https://x.com/AndrewYNg/status/2098459474608672916（2026-09）
- 原文标题：The AI Engineering Skills Map In Detail: Shaping the Build
- 配套总纲：The AI Engineering Skills Map（DeepLearning.AI《The Batch》第 366 期，2026-08-14）
4 项技能中英对照
| 驱动构建循环 | Driving the build loop |
| 做产品决策 | Making product decisions |
| 沟通与领导 | Communicating and leading |
| 高主动权担责 | High-agency ownership |
关键术语中英对照
| 定义构建（旧译：塑形构建） | shaping the build |
| 构建循环 | build loop |
| 偏向行动 | bias for action |
| 原型 / 最小可行产品 | prototype / MVP (minimum viable product) |
| 小批量发布 | shipping in small batches |
| 关键指标 | key metrics |
| 产品感 / 设计感 / 商业感 | product sense / design sense / business sense |
| 进入市场策略 / 市场规模 | go-to-market / market size |
| 单位经济 / 损益 | unit economics / P&L (profit and loss) |
| 用户共情 | user empathy |
| 非正式访谈 / 问卷调查 | informal interviews / surveys |
| A/B 测试 | A/B tests |
| 利益相关者 | stakeholders |
| 产品经理 | PM (product manager) |
| 技术可行性 | technical feasibility |
| 高主动权 | high-agency |
| 自上而下的指令 | top-down direction |
| 持续学习 | continuous learning |
关键原句对照
开篇定调（逐字原文）：
When you’re skilled at AI Engineering, your best work won’t be merely implementing a product that someone else spec’ed out. Instead, you will actively shape the build.
（中译：当你精通 AI 工程，你最好的工作将不只是实现别人写好规格的产品。你会主动去定义构建。）
角色模糊（原文要点转述，非逐字）：
过去由 PM 和设计师定义产品、开发者负责实现、项目经理推排期。这些角色的边界正在模糊：会 AI 工程的开发者不仅构建软件，还参与这些角色的工作；反过来，PM 和设计师也在学习 AI 工程技能、参与构建软件。
机会窗口（原文要点转述，非逐字）：
很多人——包括一些高管——还不理解 AI 能做什么，因此判断不了什么是好的项目方向。这为有技术能力的人创造了桥梁机会：发现问题、提出方案、执行落地，尊重组织的优先级和约束，但不等着精确的自上而下指令。
提示：X 平台在国内访问不便。需要核对原文细节时，可把原帖链接发给任意 AI 助手协助转述，或参考 DeepLearning.AI《The Batch》官方栏目（本篇原文在官方栏目有完整英文版）。
参考来源
[1] Andrew Ng. The AI Engineering Skills Map In Detail: Shaping the Build. X 帖文 / DeepLearning.AI《The Batch》官方栏目. 2026-09.（浏览量 47 万，转发 552） [2] Andrew Ng. The AI Engineering Skills Map. DeepLearning.AI《The Batch》第 366 期 / X 帖文. 2026-08-14.
评论前必须登录！
注册