AI Engineering Skills Map：Shaping the Build
核心主题：AI Engineer 不应该只是“实现别人写好的需求”，而应该逐渐具备主动塑造产品与构建过程的能力。
1. 核心观点
传统软件开发往往有清晰的角色分工：PM 定义产品需求，Designer 设计产品，Developer 实现产品。
在 AI 时代，开发者的工作正在同时延伸到 Product、Design、Engineering 和 Business，角色边界也随之变得模糊。
一个优秀的 AI Engineer 不应该只是说：
“告诉我需求，我来实现。”
而应该逐渐变成：
“我理解问题、判断方向、快速验证、推动开发，并对最终结果负责。”
2. 什么是 Shaping the Build
Shaping the Build 可以理解为：不只是参与开发，而是主动决定“做什么、怎么做、下一步做什么”。
传统开发者更多关注 How to build?，AI Engineer 还需要考虑：
- What to build：做什么？
- Why build it：为什么做？
- Who needs it：谁需要？
- How do we know it works：怎么判断它有没有价值？
- What should we do next：下一步做什么？
3. 四项核心能力
吴恩达将 Shaping the Build 拆成四项主要能力：
Shaping the Build
│
├─ Driving the Build Loop
├─ Making Product Decisions
├─ Communicating & Leading
└─ High-agency Ownership4. Driving the Build Loop
软件开发本质上是一个持续循环：
Build → Feedback → Decision → Build → Feedback → ...AI Engineer 的重要能力之一，就是主动推动这个循环。
Bias for Action
不要一直讨论、等待需求和等待 PM。更好的方式是先做一个小实验，获得信息，再根据结果继续。
用构建获得信息，而不只是通过讨论获得信息。
5. Prototype、MVP 与 Production
不同项目阶段，需要不同程度的工程投入。
Prototype
Prototype 的目的是验证一个想法是否可行。它要快，可以粗糙，不追求完整或扩展性。例如要判断 RAG 能否解决某个问题，先写一个 Demo 验证即可。
MVP
MVP（Minimum Viable Product）的目的是验证用户是否真正需要这个产品。重点不只是“技术能运行”，而是“用户是否真的觉得有价值”。
Production / Enterprise-grade
价值被证明之后，再投入高可用、安全、权限、日志、监控、扩展性、性能、SLA 和成本优化。不要在想法尚未验证时，就先设计一套超复杂的企业架构。
6. Small Batch
AI 提高开发速度后，更应该采用小批量、频繁发布的方式：
Feature A → 上线 → 反馈 → Feature B → 上线 → 反馈小批量能更快获得反馈，更容易发现错误，降低风险，也能更快调整方向。
7. 什么时候需要反馈
AI Engineer 要判断当前缺少的是哪种反馈：
- User Feedback：用户到底需要这个功能吗？
- Stakeholder Feedback：业务方是否接受这个流程？
- Technical Experiment：这个模型能不能达到 90% 准确率？
面对技术问题，答案通常不是继续讨论，而是运行实验。
8. 如何做下一步决策
决策时需要综合考虑产品愿景、项目阶段、技术可行性、风险、工作量和预算。
不能只问“技术上能不能做”，还要问：
“值不值得现在做？”
9. 用 Metrics 推动开发
项目成熟以后，要开始通过指标推动开发。AI 产品的常见指标包括回答正确率、用户留存、任务完成率、延迟、Token 成本、用户满意度和人工转接率。
Metric → Experiment → Improvement → Measure → Repeat10. Making Product Decisions
AI Engineer 不需要完全变成 PM，但必须具备基本的 Product Sense，因为实际工作中的 Product Spec 永远不可能覆盖所有情况。
11. 没有 Spec 怎么办
如果只收到一句“做一个 AI 客服”，不能直接开始写代码。需要先逐步拆解：
用户是谁？
↓
用户的问题是什么？
↓
AI 要解决什么问题？
↓
输入和输出是什么？
↓
什么情况下转人工？
↓
如何判断效果？
↓
有哪些风险？最终形成自己的初步 Spec。
12. Product Sense
Product Sense 的核心不是想很多酷功能，而是判断什么功能真正解决用户问题。
好的工程能力：Can build it
好的产品能力：Should build it
优秀 AI Engineer：Can build it + Should build it13. Design Sense
AI Engineer 不需要成为专业 UI Designer，但至少要做到：
Functional + Usable + Pleasant也就是能工作、好理解、好使用。尤其 AI 产品经常涉及 Chat UI、Streaming、Tool Calling、Agent 状态、Human Confirmation 和 Error Handling，这些都会直接影响用户体验。
14. Business Sense
AI Engineer 还应该理解一些基础商业问题，包括市场规模、Go-to-Market、单位经济模型以及利润与亏损。
例如，一个 AI Agent 每完成一个任务收入 1 美元，但 LLM 成本是 1.4 美元，那么无论技术多漂亮，这个商业模型都不成立。
15. User Empathy
产品决策最终应该来自对用户的理解，而不是“我觉得用户应该喜欢”。
16. 如何了解用户
不同阶段可以采用不同方式：
- 小规模：访谈 2～3 位用户，快速发现关键问题；
- 中规模：通过问卷收集几百位用户的反馈；
- 大规模：使用 A/B Test 验证不同产品方案；
- 超大规模：分析成千上万甚至数百万用户的真实行为数据。
17. Communicating & Leading
AI Engineer 的工作边界正在从 Frontend、Backend、Database，进一步扩展到 Product、Marketing、Finance、Legal 和 Operations，因此沟通能力的重要性正在提升。
18. AI Engineer 为什么更需要沟通
AI Engineer 需要协调用户、产品、设计、工程、管理层、业务、法务和市场。很多时候真正阻碍项目推进的，不是代码不会写，而是大家没有达成一致。
19. 技术领导力
AI 变化非常快，大量非技术人员并不清楚 AI 能做什么、不能做什么、成本是多少、风险是什么。因此 AI Engineer 可以承担 Technical Translator 的角色，连接 AI Technology 与 Business。
20. High-agency Ownership
High Agency 可以理解为：不等待别人告诉你每一步做什么，而是主动推动事情发生。
21. Low Agency vs High Agency
Low Agency：
领导没说 → 所以我没做
High Agency：
我发现了问题 → 分析问题 → 提出方案 → 确认关键约束 → 执行22. Spot → Propose → Execute
这套行动路径非常值得记住：
Spot Problems → Propose Solutions → Execute发现问题，提出方案，完成落地。
23. End-to-End Ownership
真正的 Ownership 不是“我的代码写完了”，而是“项目最终有没有成功”。这意味着对结果负责、出问题主动解决、主动协调相关人员，在模糊中继续推进，并在失败后继续调整。
24. Task Completion vs Value Creation
传统思维关注“我完成了 10 个 Task”，High-agency 思维关注“我创造了什么价值”。
例如，不是“完成了 RAG 模块”，而是“让客服平均响应时间下降 40%”。
25. 在 Ambiguity 中前进
AI 项目天然存在大量不确定性：什么模型最好？RAG 是否有效？用户愿不愿意使用？
真正的能力不是等所有问题都有答案后再开发，而是：
Ambiguity → Experiment → Information → Decision26. Continuous Learning
AI Engineering 变化非常快，需要持续追踪前沿、学习工具、改进工作流和反复实践。
值得关注的方向包括新模型、Agent 框架、Coding Agent、MCP、RAG、Evaluation、Tool Calling、AI IDE，以及 Workflow / Harness。
重点不是“所有工具都学”，而是判断哪些工具真正能够提高构建效率。
27. AI Engineer 与传统 Developer 的区别
| Traditional Developer | AI Engineer |
|---|---|
| 接需求 | 参与定义需求 |
| 实现 Spec | 可以补全 Spec |
| 关注代码 | 关注最终价值 |
| 等待任务 | 主动发现任务 |
| 单纯实现 | 快速实验 |
| 技术判断 | 技术 + 产品判断 |
| 完成 Task | Own Outcome |
| 软件开发 | Shape the Build |
28. AI Engineering 不是“会调用 API”
真正的 AI Engineering 是：
Software Engineering
+ AI
+ Product Sense
+ Experimentation
+ Communication
+ Ownership因此，会调用 OpenAI API 并不等于 AI Engineer。
29. 和 Agent Engineering 的联系
Agent、Loop、Graph、Tools、Memory 和 Harness 解决的是“AI 系统如何工作”，属于 System Level。
Build Loop、Product Sense、Communication 和 High Agency 解决的是“AI Engineer 应该如何工作”，属于 Engineer Level。
两者共同组成真正的 AI Engineering。
30. 一个优秀 AI Engineer 的工作模式
发现问题
↓
理解用户
↓
定义问题
↓
提出方案
↓
快速 Prototype
↓
获取反馈
↓
做出决策
↓
开发 MVP
↓
测量指标
↓
继续迭代
↓
规模化而不是：
拿到 PRD → 写代码 → 交付 → 结束31. 最值得记住的四句话
- AI Engineer 不只是 Build，还要 Shape the Build。
- 用快速构建和实验获得信息，而不是等待所有信息都明确后再行动。
- 不只为 Task Completion 负责，而是为最终 Value Creation 负责。
- High Agency：发现问题、提出方案、执行落地，并推动事情发生。
32. 一句话总结
未来优秀的 AI Engineer，不只是一个“更会写代码的开发者”，而是一个能够融合工程、产品、实验、沟通和商业判断，并主动推动一个 AI 产品从问题发现一路走到价值落地的人。