AI Engineering Skills Map:Shaping the Build 的工程实践拆解

当 coding agent 让实现速度上升，工程师的关键能力会往上游移动：定义问题、拆实验、设指标、控风险，并持续推动 build loop。

核心判断

Andrew Ng 在 2026 年 9 月 11 日发布了 AI Engineering Skills Map 系列的一篇文章，主题是 Shaping the build。它讨论的不是某个模型 API，也不是某个 agent 框架，而是 AI 工程师在开发流程里应该承担什么样的上游职责。

原文给出的主线很清楚：当现代 AI 工具提高了单个开发者的产出能力，工程师的工作就不再只是实现别人写好的 spec。更熟练的 AI engineer 会参与塑造要构建什么、怎么构建、什么时候验证、什么时候扩大投入。

如果把这件事翻译成工程语言，它其实是在说：AI 让 implementation throughput 变高以后，系统瓶颈会从“谁来写代码”转移到“谁来定义正确的迭代闭环”。

Shaping the Build 不是替代 PM

很多人看到 Shaping the build，第一反应可能是：工程师是不是要去做 PM 的活？我不这么理解。更准确的说法是，工程师需要把技术可行性、反馈速度、风险边界和产品目标连接起来。

在传统软件流程里，常见分工是 PM 和设计师定义要做什么，工程师负责实现，项目经理推动时间线。Andrew Ng 的观察是，AI 工具把这些角色边界变模糊了。工程师有了更快试错的能力，也就更容易直接参与“下一步应该做什么”的判断。

这不是组织架构上的越界，而是开发反馈链路被压缩之后的自然结果。以前一个原型可能要排期一周，现在 coding agent 可以把第一个版本压到几个小时。既然实验成本下降，工程师就不能只等完整 spec，而要会提出可验证的技术假设，并把它变成一个足够小的 build。

Build Loop：从写代码到驱动闭环

Andrew Ng 把 Driving the build loop 放在关键能力的第一项。这里的 loop 可以抽象成一个很工程化的流程：写一点代码，获得反馈，然后决定下一步。AI 改变的是这个循环的速度和粒度。

一个可操作的 AI build loop 至少应该包含六个节点：

Hypothesis 是这次迭代要验证的判断，例如“RAG 加 reranker 能把召回错误降低到可接受范围”。Small Build 是最小实现，不是完整系统。Verifier 是验证器，可以是单元测试、离线 eval、人工抽检表、线上灰度指标。Feedback 是实际结果。Decision 是继续、回滚、重做还是扩大投入。Next Batch 则是下一次小批量发布。

这套循环的重点不是快，而是每一次快都要产生信息。如果一个 agent 帮你一天生成 5000 行代码，但没有 verifier、没有指标、没有风险门禁，那只是更快地产生未知状态。

什么时候原型，什么时候 MVP，什么时候工程化

原文提到，工程师需要判断下一步是做快速原型、做 MVP 给用户验证价值、继续加功能，还是投入 enterprise-grade system。这个判断非常技术，因为它背后是成本、风险、确定性和反馈延迟的权衡。

可以用一个简单矩阵判断投入级别：

以一个客服工单分类 agent 为例。如果只是验证“模型能否识别投诉和退款”，可以先离线跑历史数据。这个阶段不需要复杂权限系统，也不需要接入生产工作流。

但如果它要自动改变工单优先级、触发 SLA 告警、甚至建议退款动作，风险等级就变了。此时就要加入人工复核、日志追踪、回滚机制、权限隔离、成本监控和失败兜底。AI 功能不是因为用了模型就特殊，它仍然要回到软件工程的风险分层。

产品决策要变成可观测指标

Andrew Ng 在 Making product decisions 里提到，开发者不需要变成 PM，但会遇到 spec 没有覆盖的决策；如果没有 spec，也要知道怎么把 spec 做出来。工程师真正能补位的地方，是把抽象产品判断落成可观测指标。

例如“让客服效率更高”不是一个工程目标，因为它不能直接驱动实现。更好的拆法是：平均首响时间下降多少，人工分类工单比例下降多少，高优先级误判率不能超过多少，模型建议被人工接受的比例是多少，单次处理成本和延迟上限是多少。

对 AI 系统尤其如此。传统功能的正确性往往可以用确定性测试覆盖；AI 功能的正确性通常要靠 eval set、抽检、线上指标和错误分析一起闭环。工程师参与产品决策，不是去写愿景文档，而是把愿景压成可以测量、可以回归、可以报警的系统指标。

这也是 AI engineering 和普通 prompt demo 的分水岭：demo 只要看起来能跑，工程系统必须知道它什么时候不该被信任。

用户反馈不是一句“多访谈用户”

原文把用户同理心作为产品决策的根基，并列举了从 2 到 3 个快速访谈、问卷、A/B 测试到大规模行为分析等方法。对工程师来说，这些不是软技能装饰，而是反馈系统的输入源。

不同阶段应该接不同反馈通道。概念验证阶段，少量访谈可以帮助你确认问题是否真实。MVP 阶段，人工观察和可用性测试能暴露流程断点。功能稳定后，A/B 测试和行为日志才能回答“这个改动是否真的提升指标”。

工程实现上，最好从第一天就给反馈留接口：记录用户是否采纳 AI 建议，记录人工改写了哪些字段，记录模型输出被拒绝的原因，记录每次调用的模型版本、prompt 版本、延迟和成本。

否则你会遇到一个很常见的问题：功能上线后大家都说“感觉还行”，但没有人能回答它到底节省了多少时间、错在什么地方、下一轮应该优化模型、prompt、检索还是产品流程。

沟通能力对应的是技术翻译层

Andrew Ng 还把 Communicating and leading 放进 Shaping the build。对工程师来说，这不是泛泛的“表达能力很重要”，而是要能把技术状态翻译成组织可以决策的信息。

AI 项目里最需要翻译的通常有四类问题：

如果工程师只说“模型效果还不错”，业务方无法决策。如果工程师能说“在 500 条历史样本上，高优先级工单召回率达到 92%，但退款类误报偏高，建议先灰度到只读推荐，不自动改 SLA”，这就变成了可执行的组织语言。

AI 工程师的领导力，很大一部分不是头衔，而是能让不同角色围绕同一个证据面板做决定。

High Agency 的工程含义

High-agency ownership 容易被讲成态度问题，但在工程系统里，它应该落到行为上：主动识别问题，提出方案，尊重组织约束，然后端到端推动落地。

这件事在 AI 项目里尤其重要，因为很多管理者和业务方并不清楚 AI 能做什么，也不清楚哪些方向值得做。此时工程师如果只等待明确需求，项目很容易停在“大家都觉得 AI 有用，但没人知道先做什么”。

更高 agency 的做法，是主动提出低风险实验。例如：“我们先用历史工单做离线分类 eval，不接生产；如果误判率低于阈值，再做客服侧只读推荐；两周后看人工采纳率和误报类型，再决定是否进入灰度。”

这不是拍脑袋冲锋，而是把模糊机会变成可控实验。真正的 ownership 不是任务完成，而是价值闭环完成：问题是否被解决，指标是否变化，风险是否被控制，后续迭代是否有证据。

可以直接套用的技术模板

如果你要在团队里实践 Shaping the build，可以为每个 AI 功能建立一个轻量的 build loop 文档。它不需要很复杂，但必须覆盖假设、实现、验证、指标和风险。

这个模板的价值，是让 coding agent 的速度服务于工程闭环，而不是让它直接把模糊需求扩写成一堆代码。

结论

Andrew Ng 这篇文章表面上在讲 AI Engineering Skills Map 的最后一块能力，实际上指出了一个更深的工程变化：当 AI 提高实现速度之后，工程师的核心价值会更集中地体现在问题定义、反馈闭环、风险分层和指标管理上。

Shaping the build 不是让工程师放弃写代码，也不是让工程师全都变成产品经理。它要求工程师把代码、模型、用户反馈、业务指标和系统风险放到同一个循环里看。

未来更好的 AI 工程师，可能不是最会让 agent 一次性生成大量代码的人，而是最会设计 build loop 的人：知道先验证什么，怎么验证，什么时候扩大投入，什么时候停下来重构，什么时候让人进入闭环。

在 AI 工程里，能 build 已经不够了。真正难的是持续塑造一个值得 build、能够验证、可以上线、出了问题还能收回来的系统。

参考来源