--- id: "kspZP5BgkEU" title: "AI 写代码之后，工程师还剩下什么？" channel: "AI Engineer" host: ["AI Engineer 大会主持方"] guests: ["Laurie Voss"] date: "2026-10-24" updated: "2026-10-25" duration: "27:09" duration_seconds: 1629 source_type: "youtube" youtube: "https://www.youtube.com/watch?v=kspZP5BgkEU" canonical: "https://pod-exp.pages.dev/kspZP5BgkEU/" transcript_jsonl: "https://pod-exp.pages.dev/kspZP5BgkEU/transcript.jsonl" language: "zh-CN" translation: true translated_from: "en" timestamp_precision: "block" topics: ["AI 编程","AI 智能体","产品","职业发展"] series: ["AI 与软件","AI 软件工程师"] --- # AI 写代码之后，工程师还剩下什么？ > 中文译文，由英文原音字幕翻译整理，不是官方逐字稿；引用原话请核对英文原视频。说话人标签由整理者依上下文标注，带「未确认 / 未标注 / 不确定」等字样的标签不可靠。时间戳一般为块级（所在时间块的起点），不是逐句时间；正文自带 [hh:mm:ss] 的段落除外。 **内容提要：** Laurie Voss 认为，编码智能体让写代码的成本大幅下降，但代码审查、运维和安全等瓶颈仍然存在，而且会依次转移。长期来看，真正难以自动化的是了解用户需求、界定什么算“好”，并把这些判断写进规格说明和评估标准。他将这种融合产品判断与工程交付的角色称为“产品工程师”。这也带来人才培养问题：传统初级工程师通过实现明确任务、接受反馈来成长，但这些任务正被智能体接手。工程团队需要重新设计入门路径，培养能够理解用户、定义问题并借助智能体交付产品的人。 ## [0:14] 开场：AI 工程师之后是什么 · YouTube **Laurie Voss：** 我叫 Laurie，是 Arize AI 的开发者关系负责人。以前我和别人共同创办了 npm，所以 JavaScript 时代的一些朋友可能还记得我。如今我关注的是 AI 智能体，以及它们正在如何改变我们的工作。 三年多以前，Swyx 写了一篇文章，题为《AI 工程师的崛起》。他的观点是，开发 AI 产品需要的是工程师，而不是研究人员。我想这句话引起了很多人的共鸣，尤其是来参加这场大会的人。于是，“AI 工程师”这个职位名称出现了，此后公司也一直在招聘这个岗位。 我今天想说服大家的是：他其实还没有把话说到位。发生变化的不只是 AI 工程师这个岗位，而是所有类型的工程师。所有工程岗位都在被一种新型工作取代，而且并不是每个人都会喜欢这个消息。 ## [1:19] 写代码变得近乎免费，瓶颈随之转移 · YouTube **Laurie Voss：** 引发这一切的根本变化是，智能体让写代码基本变成了免费。你仍然要付 token 费用，但和过去投入的时间成本相比，几乎可以忽略。写完代码之后的所有环节，却没有同时变得免费。于是瓶颈从“写代码很慢，其他事情大致跟得上”，变成了“代码写得飞快，我们开始卡在新的事情上”。眼下这个月，首先卡住我们的是代码审查。 我的判断是，这不会止步于此。我们会找到自动化代码审查的方法，让审查速度跟上智能体，然后又会遇到另一个瓶颈、再一个瓶颈、再一个。最终我们会碰到一道无法跨越的坎。人类剩下要做的，就是智能体无法突破的那个瓶颈。我打赌自己能想到一件智能体确实做不到的事。等我们走到那道瓶颈前，还得想办法培养下一代工程师去做那份工作，因为我们现在并没有在这样培养他们。 先提醒一下，也算道个歉：我只有 18 分钟，因为 Swyx 给演讲安排的时间就是这么长。我为这次演讲做了大量研究，手里有一大堆数据，却没时间一一讲完，也没时间逐条引用来源。所以我会直接报一些数字，幻灯片上会放很多引文，大家就先信我吧，兄弟。（笑） ## [3:05] 代码多了八倍，交付只快了 30% · YouTube **Laurie Voss：** 开启自主编码智能体的开发者，写出的代码增加了 741%，也就是八倍。但他们的交付速度只快了 30%。快 30% 并不是小事，已经很惊人了；我们确实比过去交付了更多代码。但代码写了八倍，真正交付的东西只多了三分之一，这就不太理想了，对吧？这说明我们卡在了某个环节。 我们卡在代码审查上，原因是人类没法单纯靠加快速度来审查。思科二十年前做过一项大型研究，考察代码审查的速度和准确性。结果发现，人类理解代码内容的能力，在每小时审查大约 450 行之后就会急剧下降。因此，如果智能体给你生成了一份一万行的差异代码，要合理地审完它大概要花一周。可现实是没人真的这么做，因为如今大家都在随手扔出一万行的差异代码。 我之前在一届 AIE 上专门讲过这个现象，那场演讲叫《代码审查之死》。想了解细节可以去看那场演讲。但我这次要解决的问题有所不同：生成看起来合理的代码的成本已经崩塌，而判断这些代码是否值得信任的成本却原封不动。 ## [4:41] 机器能做代码审查吗？ · YouTube **Laurie Voss：** 显而易见的做法，是让机器来审查代码；这件事已经在发生。上个月，GitHub 上超过五分之一的代码审查由 Copilot 完成。你可以选择让 Copilot 成为代码进入生产环境前的最终审查者，甚至授予它批准权限。这听起来很疯狂，我不知道谁会打开这个选项，但你确实可以这么做。OpenAI 也表示，内部的 pull request 可以由人审查，但并非强制要求。 问题在于，机器审查者现在还不够好。我找到的一项研究让四种 AI 审查工具接受测试，它们都找出了不少 bug，但找出的并不是同一批 bug；它们对任何一个具体 bug 都没有达成一致。它们确实都发现了代码里的真实问题，只是各自发现的问题不同。因此这些工具值得运行，但如果你认真对待代码审查，就不会只用一个，因为它们目前还不够可靠。 有些人走得更远，干脆说：“我不再审查代码了，就假设我的智能体一次就能完美完成。”Dexter Horty（他可能在现场，也可能不在）曾花六个月劝大家别读代码；六个月后他上台承认：“我错了。完全跳过代码审查行不通。我们试过，结果是一场灾难，不得不把整个系统推倒重做。”这不是可行选项。智能体还不够好，没法一次就把代码写对。 亚马逊经历了一连串故障，并在复盘后认为，原因是他们的编码智能体生成了一堆粗糙代码，团队没有仔细思考就把它们发布了。现在他们不再允许这么做，亚马逊的代码审查必须由资深工程师签字。Anthropic 也发布过复盘，讲述一些 bug 如何同时绕过了所有人工和机器审查者。问题是，我们迄今搭建的代码质量自动检查机制本身还不够好。 Claude Fable 5 在标准编码基准的测试中有 80% 能通过。Cognition，也就是 Devin 的开发商，做了一个不同的基准测试：不问代码是否通过测试，而是问你作为这个仓库的审查者和维护者，会不会合并这个 PR。换成这个问题，成绩就从 87% 降到了 54%。因为判断是否合并还需要很多额外信息：代码风格、副作用、外部系统，以及没有写进代码库、只存在于维护者脑中的历史。 维护者确实带来了智能体尚未获得的信息和技能，那就是对“什么才算好”的判断。这是智能体目前缺少的关键能力，我稍后会再谈到。 ## [8:02] 约束理论 · YouTube **Laurie Voss：** 这里可以用约束理论来理解。生产线的吞吐量由最慢的环节决定；如果你把那个瓶颈加快，瓶颈就会转移到别处。写代码变快以后，审查成了瓶颈；当审查也被加速，限制我们的因素还会继续移动。 Eliyahu Goldratt（如果我没念错的话）是一位后来成为管理学大师的物理学家。他在 1984 年写了一本关于经营工厂的小说。听起来像是一本有趣的小说吗？书名叫《目标》。他提出的核心思想就是约束理论：每个系统都有一个瓶颈；除非你加速的正是瓶颈，否则加速其他环节并没有用。这正是我们的代码审查问题：代码写快了，审查却没有跟上。 他的第二个观点与今天更相关：解决瓶颈并不会让它消失，它只会转移，然后在另一个瓶颈前堆积。尽管我刚才说了现在的代码审查工具有多糟，我们还是先假设最终能把自动化审查做到更高水平，把这个瓶颈移开。那么接下来会撞上什么？ ## [9:00] 下一个瓶颈：运维与安全 · YouTube **Laurie Voss：** 如果我们解决了审查，下一个瓶颈可能就是运维：怎么部署、怎么扩容？然后大概会碰到安全问题：怎样让系统在规模化运行时仍然安全？怎样保护隐私？怎样确保它不会严重失控？ 这场演讲有一个很大的跨越：我先假设这些问题我们也都会解决，因为人类已经积累了大量相关经验和数据。如果我们能用越来越先进的智能体解决运维、扩容和安全，最终还剩什么要人做？那种情况下，人类扮演什么角色？ 这是个大问题，也是个长期问题。我不是在预测接下来 12 个月会发生什么。我认为未来一年代码审查会取得实质进展，但 12 个月后，我们还不会解决运维、扩容和安全。我觉得这些需要 5 到 10 年。尽管有人喊着“2027 年实现 AGI”，现实中我们会在这些事情上逐步迭代。 我的论点还依赖另一个假设：我们对软件的需求实际上是无限的。这个论点要容易得多。想想你在生产环境中遇到过的各种网站，大概都挺糟糕。糟糕并不是因为我们不知道怎样做出好网站，而是没有足够的人手把所有网站都做好。无论是理发店、政府机构还是银行的网站，做得差都不是因为没人懂得如何做好。原因有两个：把它做好很贵，而且懂这些的人正忙着做别的事——也许是在交付 AI 智能体。 所以，假设我们几乎可以免费生产任意数量的软件，而人们对软件的需求也近乎无限。这是个很好的处境：需求无限，供给也突然变得无限。瓶颈最终会落在哪里？ ## [11:21] 智能体难以取代的：判断什么才算好 · YouTube **Laurie Voss：** 我们觉得智能体不会吞掉什么？我尽量把软件开发拆成所有能想到的环节，再按智能体多久会接手来排序。写代码已经大幅自动化；审查和维护代码很快也会如此；发布到生产环境、扩容也是下一个目标，尽管目前这方面的数据还不多。我认为相对安全的部分，是决定要做什么、定义“好”是什么样，以及最终让产品变得令人愉悦。 剩下的工作，是弄清人们真正想要什么。每一款软件，都是把某个人想完成的事情形式化。客户说“我需要追踪订单”，市面上有一万种能追踪订单的软件，但如果你经营的是面包店，可能只有一种（如果幸运的话）真正好用。汽车零件店的需求又不同，大型制造企业则完全不同。仅仅说“追踪订单”还不够；工作在于弄清这对你的业务究竟意味着什么、软件要做什么、具体该怎么运作。 这些知识不在训练数据里，也不在模型权重里，而在经营者脑中。要把它挖出来，唯一办法就是和他们面对面交流：你动动嘴，他们也动动嘴。总之，你得跟他们谈。 这项工作有个重要特点：经验无法直接迁移。日历应用和排期应用解决的问题很相似，但它们是完全不同的软件，需求和“好”的定义都截然不同；而类似的使用场景还有无数种。你有没有用过配置选项多得不得了、却还是不能满足需求的软件？我说的就是你，Jira。这就是试图面面俱到的软件仍然处处不合用的问题。 因此，瓶颈会转移到描述问题，以及定义怎样才算解决问题上。这是我这场演讲、也是我对未来十年的核心判断：瓶颈会停在这里。 ## [13:47] 本质复杂性与规格说明 · YouTube **Laurie Voss：** 曾负责 IBM System/360 项目的 Fred Brooks，也写过《人月神话》。他在 1986 年把软件开发的困难分成两类：偶然复杂性来自工具、语言、打字和语法；本质复杂性则来自问题本身。他预言，没有任何单一工具能让我们的生产力提高十倍，因为真正困难的是问题本身。 Brooks 的判断看起来相当准确：代码生成快了八倍，交付速度却没有快多少，因为困难的部分是本质问题。OpenAI 的 Shawn Grove 一年前也表达过类似观点：代码是规格说明的一种有损投影。无论规格说明是由产品经理、立法者、工程师还是营销人员写的，写规格的人就成了程序员。如今，价值就在于把“好”是什么写下来。 我快没时间了，这次时间安排得不太好。任何能够低成本验证的东西，模型开发者都可以拿来训练，直到模型达到或超越它。Cognition 因为自己的基准测试，尝试把“什么样的代码可以合并”写清楚：能不能把所有额外信息都纳入基准，再据此训练模型？Cursor 的审查工具 BugBot 会把团队给出的每个差评转成一条规则，他们现在已经有大约 44,000 条规则。 维护者一旦把脑中的知识写下来，让模型可以据此训练，瓶颈就又会移动。这就是我认为安全和运维终究可以交给智能体处理的原因：虽然现在还没做到，但我们最终能把这些知识写下来。 Google Brain 和 Coursera 的联合创始人 Andrew Ng 说，他团队里有人提议让产品经理数量达到工程师的两倍。他说这是他第一次听到这种建议，但他的应对方式不是多招产品经理，而是模糊这两个岗位的边界。用他的话说，工程师了解用户，能决定做什么并直接把它做出来，就能极快地执行。我认为，我们正开始找到答案。 ## [16:36] 产品工程师 · YouTube **Laurie Voss：** 20 世纪 60 年代有一种叫系统分析师的工作，他们不写代码，而是和业务部门交谈，找出问题。后来分析师演变成今天的产品经理；原来一个半职业的工作变成了两个职业。我认为现在它们正在重新合并，我们正在回到 60 年代。 这不再是 AI 工程师——他们不只是构建 AI，也不只是用 AI 开发，而是构建所有类型的软件。我把这个岗位叫作“产品工程师”：他们发现人们需要什么，定义什么才算好，再让智能体代替自己敲代码并交付产品。Pragmatic Engineer 通讯作者 Gergo Orosz（名字可能被我念错了）在 2019 年把“有产品思维的工程师”描述为一种可取的特质；而我现在的观点是，这已经从加分项变成了必需品：过去是资深工程师才需要的技能，现在每个工程师都得具备。 市场已经在为这种能力付钱。类似产品工程师的“前线部署工程师”岗位，在 2025 年的九个月里，招聘信息增加了 800%。他们到处都有人招。在场有谁正在招前线部署工程师？举个手看看。好吧，举手的人比我预期少。顺便说一下，这类工程师的平均薪酬是 24 万美元，也就是资深工程师的水平，因为他们本来就是资深工程师，而且非常有用。不过，这个岗位现在有上千种不同叫法，我只是随意把它叫作产品工程师。 你们中有些人也许会想，这不算编程，你们说得对，这不是编程，编程由智能体完成。但它显然仍是软件开发。我们必须接受这样一个想法：到了 2026 年，软件开发者和程序员已经不再是同一个概念。 我说“难点是判断什么才算好”时，也意识到自己可能落入了 AI 圈常见的陷阱：所有事情都能被 AI 自动化，唯独我擅长的事情不行，因为那太难了。我前几天听一位风险投资人也这么说，心想：“朋友，别这样。总有一天你的工作也会被自动化。”所以请对我的判断持保留态度。软件开发中我喜欢的是找出问题；这会不会只是我觉得困难的部分？如果我错了，你们可以告诉我。 ## [19:45] 初级开发者的问题 · YouTube **Laurie Voss：** 假如你相信我前面说的：编程趋近于零，产品工程趋近于无限。这就带来一个重要的新问题：初级开发者。过去我们培养初级开发者的方式，是给他们定义得很清楚的任务：“按这个特定方式把软件写出来，然后交给我，我来告诉你哪些地方错了。”这种模式正在消失，因为我们现在让编码智能体先写东西，再告诉它哪里不对，然后和它来回沟通。我们不再需要人来做这份工作。 但我们仍然需要大量前线部署工程师，也就是产品工程师，而且得从某个地方培养出来。不能抛下新一代开发者不管；他们来问“这些工作该怎么做”，我们却回答“我不知道，因为我也不知道你的工作现在是什么了”。（笑） 这不是对未来的猜测，而是一张从 2023 年 1 月开始的真实劳动力统计图，按年龄分组。红线代表 22 到 25 岁的工程师，他们的就业正在急剧下滑。公司没有在招初级工程师。这不是我觉得将来会发生的事，而是已经持续两年的现实，他们的就业市场很糟糕。与此同时，41 到 49 岁工程师的就业大幅增加。资深工程师仍然非常有价值，甚至比以前更有价值；但初级工程师正在受损，我们这个行业必须解决这个问题。 如果我们要享受代码产出提高十倍的好处，并且解决软件供应链的其他环节、弄清人类该做什么，我们就需要很多人来做这些事。我说过，软件需求会趋向无限；我们需要无限多的人。上哪儿找？ 到目前为止，我们只是无意间培养出了这类人才，现在得想办法有意识地培养。Google 的副产品经理项目每年培养出 50 人，他们的能力很像产品工程师；我们每年需要 10,000 人。把 Google 的 APM 项目广泛复制的其他公司也算进来，每年总共大约只培养 1,000 人，而我们的需求至少是这个数字的十倍。 大学教数据结构，训练营教 React，却没有人教“去面包店待一周，再带着规格说明回来”。我们需要的正是这种人。如果你领导工程团队，就得有意识地培养他们。IBM 已经在重新设计入门级岗位，让新人和客户交流、编写规格说明，而不是编程。你也得想办法培养产品人才，而且得尽快：我们两年前就该开始了。现在有整整一批很难过、失业中的初级开发者遇到这个问题，而我们没有雇用他们。我们必须有所行动，否则受害的不只是他们，我们自己也会陷入困境。 ## [22:57] 对热爱编程手艺的人来说 · YouTube **Laurie Voss：** 如果这一切发生，有件大事我不想轻描淡写地带过：很多人当初学编程，是因为热爱这门手艺。他们喜欢干净的抽象，喜欢一个棘手的 bug 终于被攻克的感觉，喜欢让机器精准执行自己指令的过程。他们可不是为了去采访面包师、了解对方想过什么样的生活才入行的。这并不是他们选择的工作。他们会讨厌这种变化，而且已经有人在大声抱怨。我没法给他们什么安慰奖。 但我有个观察：很多以为自己爱的是敲代码的人，也许真正喜欢的是开始敲代码前的那一刻——想明白问题的时刻。那部分不会消失。你突然想到“我知道怎么把这件事变成一个可重复的系统”，脑中闪过创意火花的感觉也不会消失。 编程这门手艺会继续存在，就像木工在家具工厂出现后仍然存在一样。程序员编程，就像歌手唱歌：即使没人看、独自在空房间里，他们也会因为热爱而去做。这不会消失，只是它不再是别人每年花几十万美元雇你去做的工作。 这是我的预测：接下来的十年会很艰难，过去两年已经很艰难了。变化在工具准备好之前就涌来了；培养初级开发者的阶梯消失了，我们还没想出怎么培养新一代。许多热爱编程手艺的人，也得决定自己是否喜欢取代它的新工作。 不过，这种事以前发生过。编译器、框架、开源软件，都曾让一代人原本要敲的代码变得不再必要；每次之后，软件开发者反而更多了。只是软件开发的含义改变了。我认为这次也会如此。十年后，这个职业的规模会比今天更大，薪酬大致相当，工作形态则主要是产品工程。这就是我今天想提出的判断。 但这些都是很宏观的预测，我不喜欢这种说法。它们到底意味着什么？今天你们实际该怎么做？ ## [25:11] 现在该怎么做 · YouTube **Laurie Voss：** 首先，要为一个人类几乎不参与代码生产的世界做好准备。把影响范围最大的高风险代码列出来，今后只重点审查这些部分，其余代码交给自动审查工具处理。 然后，把所有容易验证的事情交出去。花时间想想，怎样建立自动方法来判断某件东西是否合格，再把这个方法交给智能体，而不是亲自琢磨审查流程。 最后，把最优秀员工的判断写进规格说明、评分标准和评估里。你们知道，我是 Arize 的人，总要在某个时候提到评估。把只存在于人脑中的知识变成代码。这就是产品工程师的工作：把对问题的感知转化成问题的规格说明，让智能体替我们构建产品。 还要衡量正确的指标。代码多了 741% 从来不是目标，要衡量实际交付了多少。衡量审查者的意见有多少被采纳，衡量“测试通过”和“维护者愿意合并”之间的差距。别忘了，最后的审查者是生产环境。观察产品在生产环境里的表现，再用另一个模型来评分，这本身就是评估。我不是在推销 Arize，这只是我们的工作，也是我们现在很受欢迎的原因。就说到这里。 三年前，Swyx 写了《AI 工程师的崛起》，讲的是工程师学习用模型构建产品。如今“产品工程师的崛起”，说的是模型负责构建之后还剩下什么：发现人们的需求，写下“好”究竟意味着什么，再把产品做成大家喜欢的样子。这就是现在的工作，也将成为在场每个人的工作，不管我们喜不喜欢。我们现在都是产品工程师了。 非常感谢大家的时间与聆听。（掌声）