按钮做出来了，事情解决了吗？
编者依据本文整理的示意图，非吴恩达原图。
设想一个工作场景。同事找到你，说每周整理报表太麻烦，能不能在系统里加一个导出按钮。你把需求交给 Coding Agent，完成开发、验证，按钮很快上线了。
过了几天，你问他好不好用。他说挺好，但每到周五，还是得花不少时间处理那些表格。你坐下来一看，才发现真正费劲的不是导出，而是把几个系统的数据拼到一起，再逐项核对。
按钮没有做错，需求也确实完成了。只是那件让人头疼的事，仍然留在那里。这个假设场景揭示的，是一个越来越值得工程师认真对待的问题：当实现需求越来越快，我们是否也更需要弄清楚，需求背后到底是什么？
这次，吴恩达把问题往前推了一步
Andrew Ng（吴恩达）在新一篇《AI Engineering Skills Map: Shaping the build》中提出：熟练掌握 AI Engineering 的人，最出色的工作不会只是实现别人写好的产品规格，还会主动参与，推动产品成形。
他谈到四项能力：推动构建与反馈循环、做出产品决策、沟通与引领，以及主动担当。原文也明确说，开发者不必成为产品经理，但需要对需求说明没有覆盖的部分做出决定。
如果把上一篇 Using coding agents 的问题理解为“怎样引导 Agent 把事情做好”，这一篇就把视线移到了更前面：接下来应该做哪件事？为什么是它？做完之后，怎样知道它真的有用？
我们的理解是：AI 扩大了工程师的实现能力，也让工程师更有机会参与定义问题，而不只是接收答案。
这不是吴恩达原文的逐句翻译。接下来，我们从日常工作的角度，讨论这个变化意味着什么。
从功能验收到实际效果：还差哪一步？
对开发者来说，最容易观察的证据是代码合并、测试通过、部署成功。这些证据很重要，但它们回答的主要是“实现有没有按预期工作”，不能单独证明“用户的问题已经减轻”。
下面的对照是本文对报表场景的分析，不是吴恩达原文中的表格。
| 观察角度 | 功能验收关注什么 | 实际效果还要确认什么 |
|---|---|---|
| 导出能力 | 按钮可用，文件格式和字段正确 | 导出后还有多少手工整理与核对 |
| 自动核对 | 规则能识别已知样例中的差异 | 提示是否有用，是否漏掉重要异常 |
| 使用流程 | 页面操作顺畅，没有阻断性错误 | 用户是否仍需在几个系统之间重复搬运数据 |
| 上线结果 | 部署成功，运行状态正常 | 实际使用后，耗时、差错和确认负担怎样变化 |
两列不是二选一。没有可靠实现，谈不上改善工作；但只完成左边，也可能留下开头那个“按钮很好用，事情还是很麻烦”的结果。
需求里，常常藏着一个已经选好的答案
“加一个导出按钮”，听上去是一个需求，实际上已经包含了一种解决方案。提出它的人可能很清楚自己的困扰，却不一定知道系统还能提供哪些更省事的办法。
如果工程师只能看到任务单，就容易把按钮本身当作终点。可如果多问一句“你导出之后还要做什么”，就有机会发现：对方需要的也许是一张汇总表、一份差异清单，或者只是统一一下几个部门的数据口径。
这并不意味着用户不懂自己，也不是技术人员应该替别人做决定。恰恰相反，你要更认真地理解对方实际怎样工作，才不会用自己觉得漂亮的方案，替换掉真实需要。
需求文档很重要，但它很难提前装下每一个使用细节。过去，工程师常常在实现过程中补齐这些细节；当实现节奏变快，频繁停下来等待逐项指示，就可能成为新的阻力。
值得培养的能力，是分清哪些小选择可以在已有目标下自行处理，哪些变化涉及业务规则、成本或风险，需要及时与相关人确认。主动，不是所有事情都自己决定，而是知道什么时候应该带着判断去沟通。
spec 没写清楚时，哪些可以自己补？
不是每个空白都值得开一次会，也不是每个空白都可以交给 Agent 自由发挥。一个实用的判断方法，是看这个选择有没有改变已经约定的目标、业务含义和风险边界。
- 已有规范能回答的细节：例如沿用项目现有的按钮样式、错误提示方式和日期展示格式，可以在既定范围内处理，并正常验证。
- 会改变业务含义的选择：例如两个系统的金额不一致时以谁为准、怎样处理重复记录，需要与业务负责人确认，不能仅凭技术便利决定。
- 涉及权限和影响范围的变化：例如跨系统读取数据、扩大可见人群、自动修改生产记录，需要相应授权，不能把原来的“增加导出按钮”理解为批准了这些动作。
给 Coding Agent 的说明也可以把这三类信息分开：已经确定的规则、允许自行选择的实现细节、必须停下来确认的问题。这样做不是为了把文档写得更厚，而是减少它在关键位置猜错的机会。
做得更快，也可能更快地偏离问题
回到报表的例子。发现同事还在手工核对之后，你可能马上想到：干脆做一个完整的数据平台，把导入、清洗、核对、展示都包起来。AI 能帮忙实现，这个念头会显得很有吸引力。
但新方案越丰富，越容易把“我们能做什么”误当成“现在应该做什么”。也许只有两类字段需要核对，也许某些数据不能跨系统流转，也许相关部门根本还没有统一统计口径。
吴恩达在原文中强调 build loop：做一些东西，获得反馈，再决定下一步。他提到快速原型、小批量交付，也提到技术可行性、风险、投入与预算。这些条件并没有因为 AI 会写代码而消失。
在我们的假设场景里，一个更小的下一步，可能是先拿一份获准使用的样例，做出差异清单，让同事判断它是否抓住了真正费时间的地方。数据若涉及敏感信息，还应先确认处理权限，必要时使用脱敏或模拟数据。
实现变快之后，值得加快的不只是交付功能，还有发现自己想错了的速度。
小步尝试的价值，不是让产品永远停在半成品，而是把尚不确定的判断尽早拿出来验证。发现方向不对时，能够少走一些路；确认确实有用之后，再决定值得投入到什么程度。
把“做个平台”缩成一次可验证的尝试
编者依据本文整理的示意图，非吴恩达原图。
沿着报表场景，可以把下一轮工作拆成下面五步。这是本文提出的实践方法，不是原文规定的标准流程。
- 先看一遍真实操作。 请使用者演示从导出到交付报表的过程，记录哪里重复、哪里需要判断。先确认最麻烦的环节，不预设一定要增加自动化。
- 只选一个待验证的判断。 例如：“先列出两张表中的金额差异，是否能减少人工逐行查找？”暂时不承诺自动完成所有核对。
- 明确样例和边界。 使用获准的数据；必要时脱敏或使用模拟数据。约定字段含义，只读处理，不自动回写生产系统。
- 请 Agent 实现并检查。 用已知结果的样例验证一致、不一致、缺失记录等情况；把不确定的匹配显式列出，保留人工确认，而不是让程序悄悄猜一个答案。
- 让使用者试，再决定下一步。 看差异清单是否容易理解、是否增加了无效提示、是否真的减少操作。有效才讨论扩大范围；无效就调整假设，或停止这条尝试。
模拟数据可以帮助验证逻辑，却不能直接证明真实业务有效。获准的小范围试用同样不等于已经具备全面上线条件：数据量、异常覆盖、访问控制和后续维护，仍要随投入规模逐步确认。
这条路线的重点，是把“我觉得它会有用”变成一个可以观察、也可以被否定的判断。Agent 负责加快实现，人和实际反馈一起决定是否值得继续。
经验更值钱，但不是因为你见过更多旧做法
对有经验的工程师来说，这种变化确实可能带来更大的发挥空间。你见过需求怎样走样，知道某个看似简单的字段背后可能有几套业务口径，也经历过功能上线后没人愿意用的尴尬。
这些经验能帮助你更早地提出有用的问题：这一步为什么由人工确认？异常由谁处理？原来的做法虽然慢，是不是也承担了某种检查责任？当工具让改动更容易时，这些问题依然决定改动有没有意义。
不过，资深并不自动等于判断正确。经验既可能帮助你识别风险，也可能让你太快地说“这个以前试过，不行”。技术条件变了，用户习惯也可能变了，过去的结论需要重新接受检验。
因此，更有价值的不是“我做了很多年，所以听我的”，而是“我知道该验证哪些假设，也愿意在证据变化时调整自己的判断”。资历提供材料，理解用户、识别约束和根据反馈修正方向，才把材料变成能力。
懂技术的人，也要把话说到别人能接住
如果你发现自动核对比新增按钮更有效，接下来往往不是继续写代码，而是与几类人把事情说清楚。使用者关心是否真的少了重复劳动，业务负责人关心口径是否正确，管理者关心投入和影响，相关职能部门还可能关心数据与合规边界。
同一项改动，每个人看到的都不一样。你只说“Agent 很快就能实现”，并不能回答这些问题，因为实现速度只是整件事的一部分。
有效的沟通，可以从非常具体的话开始：“我们先只处理这一类差异，其他情况仍然人工确认；先在获准的小范围内验证，确认没有增加错误，再讨论扩大使用。”这比一口气展示很多功能，更容易让别人判断能否一起往前走。
吴恩达把 Communicating and leading 列为关键能力，是因为技术能力让人能够参与更广泛的工作，而更广的参与需要更多协调。它不必表现为管理头衔，也可以表现为：把技术上的可能性说清楚，把别人的担忧带回方案，让分歧变成可以讨论的选择。
主动担当，不是把所有责任揽到身上
编者依据本文整理的示意图，非吴恩达原图。
High-agency ownership 很容易被读成一种新的职场要求：既然 AI 帮你写代码了，产品、设计、业务和交付就都该你负责。这样的理解，会把能力拓展变成没有边界的加码。
但原文保留了一个重要条件：尊重组织的优先事项与约束。主动发现问题、提出建议，与绕过负责人、擅自改变生产系统，是两回事。
你可以先把看到的问题讲清楚，提出一个投入有限、可回退的尝试，说明需要谁参与、哪些地方需要批准。拿到相应授权后，再把事情推进下去。你不必等到每一个细节都有人安排，也不必假装自己拥有所有专业知识。
相应地，如果组织期待工程师承担更广的结果，也应给予相匹配的权限、资源和协作支持。一个人无法控制所有条件，却被要求为所有结果负责，并不是健康的 ownership。这是我们对管理边界的补充，不是原文的直接论断。
下次接到需求，可以多问哪一步？
改变不一定要从重做整个工作方式开始。下一次接到一个小需求，可以先多了解一点：对方在什么情况下用它，前后还要做什么，最困扰他的环节在哪里。
然后与相关人约定一个能观察的结果。报表场景里，可以看核对耗时是否减少、差错是否更容易发现、人工确认负担有没有增加。这里不需要凭空承诺一个提升比例，先弄清楚现状，再用实际反馈判断。
- 做之前：确认要改善谁的什么问题。
- 推进时：选择能验证关键假设的小步尝试。
- 做完后：回到使用现场，看看问题有没有减轻。
如果反馈表明导出按钮已经足够，就没有必要为了展示 AI 能力再造一个平台。如果确实需要更完整的方案，再把投入、分工与边界一起谈清楚。
AI 让我们更容易把想法变成东西。但想法从哪里来，先验证什么，谁愿意使用，出现问题时怎样调整，仍然需要人在真实处境里做判断。
更值得争取的成长，不是接下更多任务，而是逐渐有能力回答：这件事为什么值得做，我们怎样一起把它做成。
来源与事实边界
Andrew Ng（吴恩达）：AI Engineering Skills Map: Shaping the build，北京时间 2026 年 9 月 12 日发布。原帖作者、标题及时间已通过 X 接口核实，正文依据读者提供的英文全文，尚未与 X 长文页面逐段独立核对。
本文为基于原文的独立分析，不是翻译。导出按钮与报表核对均为假设场景，不是作者或吴恩达的真实案例；有关经验价值、验证步骤和组织责任边界的讨论属于本文延伸观点，不代表原文逐字表述。
附录：术语对照
Shaping the build：推动产品成形。Coding Agent：编程智能体。AI Engineering：AI 工程。Using coding agents：使用编程智能体。build loop：构建与反馈循环。
Communicating and leading：沟通与引领。High-agency ownership：主动担当，对结果负责；其中 agency 指主动行动的能力与意愿，不是 AI Agent。
