# 吴恩达谈AI职业发展：代码越来越容易写，工程师该把能力放在哪里？

**来源：** 微信公众号「AI觉醒观测者」
**作者栏：** AI觉醒观测者（原始演讲者为吴恩达、Laurence Moroney）
**发布时间：** 2026-09-18 13:16
**原文链接：** https://mp.weixin.qq.com/s/MKh5hvraDl8ee-N9XWD3jA
**获取时间：** 2026-09-24（Asia/Shanghai）
**抓取方式：** 浏览器核对正文，Chrome UA 获取 HTML，BeautifulSoup 清洗末尾关注引导
**正文 SHA-256：** 2de956b1cd3bcb09ccfc4b8225129f6995b566912325feaa7a58f0a48e5acb7b

---

## 正文

一家欧洲公司找到 AI 教育者劳伦斯·莫罗尼（Laurence Moroney），希望得到一个 Agent。
公司的负责人相信，Agent 能降低成本，让业务变得更好。这些预期来自社交媒体上的介绍。但继续追问下去，需求逐渐变得具体：销售人员花了太多时间搜集客户资料，需要提高拜访前的准备效率。
从“做一个 Agent”到“减少销售的重复调研”，技术方案才有了明确的落点。
这个案例出自吴恩达与莫罗尼在斯坦福的一场职业发展课堂演讲。两人的讨论覆盖 AI 编码、产品管理、技术债、求职和小模型，贯穿其中的是一个问题：当实现想法越来越容易，什么能力能够让一个人持续创造价值？
对 LLM 与 Agent 从业者而言，这场演讲提供了一条值得细读的思路：把技术深度、业务理解和实际交付连接起来，用可检验的成果说明能力。
01｜实现提速之后，需求与验证更关键
吴恩达首先谈到两种变化：可组合使用的 AI 能力更丰富，从想法走到可运行原型的过程也在缩短。LLM、检索增强生成（RAG）、Agent 工作流等，为开发者提供了更多构建软件的方式。
这让更多想法具备了低成本试验的条件。不过，一个环节提速，并不意味着整个产品过程会以相同幅度加速。
软件开发通常需要反复经历几件事：明确需求、实现功能、交给用户试用、根据反馈调整。当“从清晰需求到代码”的距离缩短，另一个问题就更加突出：需求是否清晰，方向是否值得继续？
吴恩达将其称为产品管理瓶颈。他观察到，部分团队的工程师与产品经理配比在下降：实现工作加快以后，需求梳理和优先级判断需要跟上。背后的逻辑是：代码产出的速度提高后，团队需要更快地回答“下一步应该做什么”。
这也解释了他为什么鼓励工程师接触用户。能直接理解反馈的人，可以更快判断：某个功能确实缺失，还是现有入口太难找；用户要求增加按钮，背后是否存在流程上的障碍；一个看起来复杂的需求，能否通过缩小范围先解决主要问题。
这种能力减少了需求在不同角色之间反复传递的等待。
吴恩达也回顾过一次不太成功的尝试。他曾推动工程师承担更多产品工作，却让一些优秀工程师因为不擅长产品管理而感到挫败。这段经历，使他在鼓励跨界的同时，也意识到不同人的兴趣与长处需要得到尊重。
因此，这项建议更适合作为能力扩展方向。工程师可以从理解一个使用场景、参与一次用户访谈、写清一组验收条件开始，并不需要人人转成产品经理。
能力进步怎样转化为工作收益？
吴恩达的乐观判断，部分来自 METR 对长任务能力的研究。这项研究以人类专家完成任务所需的时间作为尺度，再估计 AI 在特定成功率下能够完成多长的任务。演讲引用的“约七个月翻倍”，是 2025 年论文对历史数据中 50% 成功率任务时间跨度的估计。它衡量的是可处理任务的范围，与模型实际运行多久、工程师节省多少时间是不同指标。
后续研究让这幅图景更具体：2026 年 1 月的 TH1.1 扩充了评估任务，并展示了任务构成对趋势估计的影响；同年 5 月，METR 发布了一项针对 349 名技术工作者的自报调查，分别询问工作速度和产出价值的变化。受访者报告的速度中位数为原来的 3 倍，不同价值问法得到的中位数则为 1.4—2 倍。
这一区分很适合带回日常工作：一个功能很快就能生成，是否值得优先做它，仍需要判断。衡量 AI 的帮助时，除了记录省下多少编码时间，也要看完成了哪些有用的工作，以及审查、返工和交接花了多少时间。
02｜一个 Agent 项目，应该从“为什么需要它”开始
回到开头的销售案例。
莫罗尼先与负责人和销售人员交谈，确认他们的工作到底卡在哪里。
销售拜访之前，需要了解目标企业、联系人以及可能的需求。相关信息分散在企业网站和职业社交平台上，不同网站的结构又不一致。每次查找都需要重新辨认页面、定位信息、整理材料。
这给技术方案设定了一个具体任务：帮助销售人员更快得到有用的拜访简报。
莫罗尼用四个阶段解释这个过程：理解意图、制定计划、执行工具、检查结果。如果结果没有满足原始意图，再回到前面的步骤修正。
据莫罗尼介绍，试点减少了销售人员花在重复调研上的时间，后续改进又让他们更快拿到拜访简报。销售人员得以将更多精力放在客户沟通上，工作体验也随之改善。
这个案例更有价值的部分，是需求被逐层澄清的过程：从追求一个流行技术名词，到识别一项反复发生、用户确实不愿意做、又可以验证改进幅度的工作。
把流程做出来，还要把结果验收清楚
沿着这四个阶段设计系统，接下来需要确定的是自主决策的范围：哪些步骤可以由程序预先规定，哪些需要模型根据环境反馈动态决定？
Anthropic 在《Building effective agents》中，将前者称为工作流，将后者称为 Agent。这一划分有助于确定自主决策的范围，也提醒开发者从能够解决问题的简单方案开始。
以销售简报为例，如果查询与整理步骤能够提前确定，固定工作流可能已经足够。遇到需要根据搜索结果不断决定下一步查什么的任务，再考虑让模型动态规划查询路径。同一个应用中，也可以把两种方式组合起来。
把这个案例转成实际项目，可以进一步提出几项验收要求：资料是否对应正确的企业与人物，关键结论能否追溯到来源，缺失信息是否被明确标出，人工纠错耗时是否抵消了自动化节省的时间。
这与 Anthropic 在 2026 年发布的 Agent 评估文章中的一个区分相呼应：执行记录里声称完成了任务，与环境中确实出现了目标结果，需要分别检查。评估通常结合代码检查、模型评分和人工判断；模型评分也需要与人工判断校准。
因此，销售简报的验收可以同时看来源证据与使用者反馈。循环应有停止条件；信息不足时，系统可以明确留下待确认项，交给人工处理。这样，“生成了一份简报”才逐步接近“这份简报值得使用”。
03｜代码生成变便宜，后续维护仍然需要有人负责
演讲中篇幅很大的一部分，讨论的是生成代码带来的技术债。
莫罗尼提出一个实际问题：当一个原型很快就能生成，团队是否也理解了它会留下哪些维护工作？缺陷要修复，需求会变化，代码需要交接。如果只有创建它的人知道它如何运转，一旦人员变化，系统就可能成为负担。
他举了自己开发 macOS 应用的例子：生成结果混入了不适用于目标平台的接口，继续依靠提示词打补丁，反而使结构越来越混乱。这个例子提示了一种值得警惕的开发状态：每次都在修复眼前的报错，却没有停下来检查目标环境与整体设计。
技术债的“利息”，就体现在这些不断增加的修改成本中。Martin Fowler 对这一概念的解释是：系统内部质量的缺陷，会让后续修改与扩展比原本更费力。
正常增加功能、维护文档，是软件持续使用所需的工作；如果模块过度耦合、逻辑难以理解、关键行为缺少验证，使每一次修改都得付出更多代价，就需要考虑偿还技术债。
这对 AI 编码尤其有启发。生成代码时，应同时保留三个判断：
目标是否明确：这段代码对应哪个需求，有什么可观察的完成标准？
收益是否成立：它减少了什么工作，改善了什么体验，是否有人愿意实际使用？
实现是否可理解：团队能否解释关键逻辑、定位失败原因，并继续修改它？
快速试错依然有价值。莫罗尼提到，他在自己的项目中多次生成原型、测试、放弃，再根据更清晰的需求重新构建。这个过程能够帮助理解问题，前提是清楚每个版本承担什么职责。
用于验证想法的原型，可以有意缩小支持范围；进入持续使用的系统，则需要相应的测试、文档和维护安排。交付之前，应当说清楚系统能处理哪些情况、还有什么限制，以及出了问题由谁接手。
从这个角度看，工程师的工作会自然延伸到代码生成之后：解释取舍，识别脆弱环节，建立验证方式，决定哪些部分可以保留，哪些部分值得重写。
04｜用项目支撑讨论，让求职材料更有说服力
莫罗尼将职业能力概括为三个支点：深入理解技术、关注业务价值、主动完成交付。
这三个支点各有作用。技术深度帮助解释系统为什么有效、什么时候会失败；业务理解帮助确定值得解决的问题；交付能力则把前两者转成别人可以检查和使用的东西。
他的求职经历提供了一个例子。应聘云相关岗位时，他提前开发了运行在目标公司云平台上的应用，并将项目放入简历。随后，面试中的大量讨论围绕这段代码展开。
作品让讨论拥有了具体对象：方案为什么这样设计，哪里做了取舍，遇到什么问题，又怎样解决。对招聘方而言，这比单独列出一长串工具，更容易判断候选人如何工作。
对 LLM 与 Agent 项目，可以把这一建议转化为几类适合展示的证据：
能力
项目中可展示的证据
能进一步回答的问题
理解与深度
方案说明、失败样例、替代方案比较
为什么采用这个方案，适用边界在哪里？
业务理解
用户场景、原有流程、验收指标
用户的哪项工作得到改善？
实际交付
可运行版本、测试记录、迭代记录
别人能否复现结果，失败时怎样处理？
协作能力
使用文档、反馈记录、交接说明
团队成员能否理解并继续维护？
例如，一个销售调研助手，如果只能演示一次顺利运行，能说明它具备基本功能。若进一步展示同名企业如何区分、资料缺失如何处理、人工检查需要多久，以及用户反馈推动了哪次修改，就能支撑更深入的工程讨论。
没有真实客户数据时，也可以使用公开资料构建练习项目。写清测试样本、任务范围、成功与失败的情况，就能让别人了解成果，也为后续改进留下依据。
莫罗尼还反复强调，要成为别人信得过的技术顾问。他给出的一个方法是：尝试把热门技术讲得尽量平实，说明它接受什么输入、经过哪些步骤、能够得到什么结果。业务人员理解了这些，才更容易把技术与自己的经验连接起来，也更容易提出有价值的需求。
面试也在观察协作方式
莫罗尼还讲到一位技术能力很强、却屡次在面试后期被拒绝的求职者。在模拟面试中，他发现，对方把“坚持立场”的建议理解成了强硬防守：面对边界条件和质疑时，容易表现出对抗性。
这段经历提醒求职者：面试官也在判断，将来能否和候选人一起处理困难。
对于技术讨论，更有说服力的表现是说明依据、澄清假设、回应反例，在新证据出现时调整结论。工程工作需要这样的交流，AI 系统的失败分析也同样需要。
05｜小模型与自托管值得关注，能力也要延伸到应用层
演讲后半段，莫罗尼对小模型和自托管方向表达了较强的看好。他以影视内容分析为例：如果一个组织希望分析未公开的剧本和项目资料，同时又对材料流转有严格要求，由自身掌控部署环境的方案就值得考虑。他也因此看好针对具体任务进行模型微调的技能。
2026 年的工程进展，让这个方向有了更具体的落点。例如，Google 在 6 月发布了经过量化感知训练（QAT）的 Gemma 4 权重，针对手机、笔记本等设备降低内存需求，并提供不同部署格式。这里的工作重点已经深入到模型压缩、运行时适配和设备资源利用。
这也让职业能力的落点更加清楚：既要理解模型，也要能回答它在目标设备上运行得怎么样，质量是否满足任务要求，部署和维护需要付出什么成本。
选型时，可以把几个维度分开看：参数规模决定了部分资源需求，模型许可约定了使用条件，部署方式决定了服务由谁运行。小模型、开放权重和自托管各自回答不同的问题。对具体项目，应当把这些条件与数据处理要求、效果评估放在一起判断。
莫罗尼在问答中进一步澄清了“技能多样化”的含义。他关心的范围包括应用开发、系统扩展、软件工程和用户体验，而不局限于在语言模型、计算机视觉等方向之间切换。
这一点与演讲前半段相互呼应：如果专业能力已经深入到某类模型，下一步可以尝试把它接入真实流程。完成一次数据准备、部署、评估和用户反馈的循环，能够暴露出单独调用模型时很少遇到的问题。
专业深度仍有价值，向应用层延伸则让这份深度有更多使用场景。
06｜选择工作环境，也是在选择学习方式
吴恩达强调了身边人的作用。他讲过一位希望从事 AI 的学生，进入一家具有热门 AI 品牌的公司后，却被分配到与预期不同的项目。这个经历使他建议求职者认真了解实际团队，而不只看公司名称。
日常工作中，能够从谁那里得到反馈，谁会审查方案，团队是否允许讨论失败，都会影响学习过程。一个响亮的品牌，无法自动回答这些问题。
因此，评估机会时可以尽量问清：入职后主要解决什么问题，与哪些人合作，项目如何验收，新人能够得到怎样的指导。答案越具体，越有助于判断岗位与职业方向是否匹配。
两位讲者也谈到了努力。吴恩达鼓励具备条件的人投入时间学习和构建，同时明确尊重因家庭、健康等原因无法高强度工作的人。莫罗尼则补充，单纯记录工作时长，不能替代对产出的衡量。
将这两点放在一起，更适合落地的做法是：根据自身条件持续投入，并定期检查投入产生了什么。可能是一个被用户接受的改进，一类被定位的错误，一份更清楚的需求，也可能是及时终止了一个缺乏价值的方案。
结尾｜让能力留下可以检查的结果
将整场演讲的建议放在一起，可以得到一条清晰的成长路径：理解技术，弄清需求，完成交付，与他人协作，再从结果中修正判断。
对于正在学习 LLM 或开发 Agent 的人，一个可行的起点，是选择一项范围明确的实际任务：记录原有做法，构建一个能运行的版本，请使用者试用，再根据效果做一次修改。
在这个过程中，模型选择、提示词、工具调用与代码生成都会获得具体意义。它们服务于同一个问题：这项工作是否被完成得更好？
代码生成的门槛降低后，把问题定义清楚、把系统做得可理解、把效果验证出来，会成为更值得积累的能力。

## 清洗与证据说明

仅移除文末关注引导，保留六节正文、结尾及原文列出的研究、案例和表格文本。公众号将吴恩达与 Laurence Moroney 演讲、METR 研究、Anthropic 文章和 Google 模型发布资料编在一起；未取得逐字演讲或全部一手研究原件，不把转述数字、引语与案例当作已独立核验的事实。