Transcript
00:00:00Clare Liguori：我叫克莱尔·利瓜里，是 AWS 的资深首席工程师。
00:00:17我主要负责我们的代码解码助手 Kiro，但今天我想聊聊
00:00:23我们在亚马逊内部团队中看到的一些实践，在那里我们看到了
00:00:28令人兴奋的生产力提升结果，这实现了自以往
00:00:35我们在 AI 领域看到的内容以来的阶跃式改进。我从事智能体 AI 的研究已经三年多了，
00:00:43我可以说见证了我们行业在 AI 辅助编程方面经历的演变。
00:00:48首先，我们有内联代码补全来帮助我们编写下一行、
00:00:55甚至是下一个函数。接着我们转向了聊天，询问有关我们代码的问题。去年某个时候，每个人都开始进行
00:01:02氛围编程（vibe coding），但现在我们开始看到一种早期采用者阶段，
00:01:08也就是我们一直在说的前沿开发。完全根据我自己的个人经验来看，
00:01:14在经历了之前所有的这些阶段后，我真的只觉得自己产出了大约 10% 到 20% 的效率提升。
00:01:20但现在在亚马逊内部，我们一直在与公司各个团队进行试点，
00:01:27我们发现生产力中位数提高了 4.5 倍，有时甚至超过 10 倍。所以，
00:01:34既然我们看到了生产力的这种阶跃式提升，这里的事情确实发生了重大变化。
00:01:40我喜欢用我所看到的三个行为来定义我们一直在亚马逊内部称之为前沿开发者的群体。
00:01:47首先是免手写编程。前沿开发者编写的代码可能只占他们产出的
00:01:541% 到 2%。其余的都由智能体完成。其次是他们与智能体的交互频率不高。
00:02:01他们的目标是让他们的编程助手无需他们干预就能连续运行几个小时。
00:02:08第三是他们最大限度地减少了空闲时间。这些前沿开发者往往会
00:02:15并行运行多个智能体，从而快速处理积压的任务。我第一次见到前沿
00:02:24开发者团队是在 Bedrock Mantle 团队。Bedrock 是我们的模型托管服务。它托管了诸如 Claude
00:02:34和 GPT 之类的 LLM。去年某个时候我们知道，或者我说我们，但 Bedrock 团队知道他们
00:02:43将需要构建一个新的推理数据平面。但他们估计这需要 30 人花费 18 个月。这是一个非常、
00:02:52非常大的服务。构建新服务、迁移客户、迁移模型都需要时间
00:02:58。他们决定退一步。他们用了 6 个人，并在 Kiro 的帮助下于 76 天内构建完成了它。
00:03:06所以这是一个巨大的成就。这是我们在亚马逊内部首次看到此类成果。
00:03:12因此，这确实是先锋团队，证明了获得高达 20 倍提升是可能的。现在他们查看了
00:03:21提交记录，我稍后会谈论我们用来衡量生产力提升的其他几种方法。但
00:03:27这个故事有一个问题，那就是，是的，它是用 6 个人构建的。它是用
00:03:34公司里名副其实的顶级工程师构建的，其中包括两名杰出工程师。所以这
00:03:40绝不仅仅是随便的 6 人团队。他们是分布式系统的专家，是 LLM 及其
00:03:49架构的专家。所以这个故事非常惊人，在亚马逊内部如野火般传开。但它对
00:03:57对许多团队来说是很难实现的。大家纷纷质疑，这真的能在
00:04:03别的团队重现吗？因此，我想谈的另一个实验是Prime Video
00:04:10在 Prime Video 组织中进行的实验性冲刺。他们进行了为期 10 天的冲刺并做了一个实验，同样是将 6 名工程师
00:04:19关在一个房间里，让他们放手使用 Kiro。他们将项目交付时间的估计值从原本的
00:04:2990 周缩短到了 24 周，这全凭他们在这次 10 天冲刺中取得的进展。
00:04:36他们查看了自己的提交历史，也查看了在这 10 天里
00:04:42他们在这个 10 天冲刺之前通常做什么，以及他们仅在这 10 天内产出了多少次提交。所以这次冲刺真的
00:04:49证明了我们可以再次实现，至少接近 Bedrock Mantle 团队
00:04:58用另一组工程师所取得的成就。但同样，这个故事也有一个挑战，那就是有 6
00:05:05名工程师被关在一个房间里，他们没有值班职责，会议很少，干扰极少，而我们都
00:05:12知道这些是工程师生活中的家常便饭。团队中的高级工程师花在前面的
00:05:20三周时间里，为这 6 名工程师创建了非常详细、微型、范围明确的任务以及详细的要求，
00:05:28好让他们在那两周里直接开干。所以这再次不一定是真实的现实生活。
00:05:35这是一次结构化的冲刺，是他们能够取得这一成果的一个时间节点。但同样，
00:05:41问题是，这在真实的日常工作团队中能否实现？因此，亚马逊商店（Amazon Stores），它涵盖了
00:05:51Amazon.com、我们所有的零售网站以及实体店，进行了更具结构化的试点。
00:05:59他们观察了 50 个完全正常的团队，其中包含初级、中级
00:06:07和资深高级工程师的正常分布，并且他们处理的是现有系统。不像 Mantle 团队那样可以从头开始
00:06:14构建全新的项目，而是拥有现有代码库的现有系统。他们在去年大半年的时间里
00:06:21观察了他们，并发现了一些超级有趣的事情。他们发现，
00:06:28其中一半团队与另一半团队在生产力提升方面存在巨大差异。而且在
00:06:34这种情况下，他们使用的生产力指标是部署到生产环境的速度。因此，不仅仅是提交次数，即他们产生了多少
00:06:41提交，而是我们以多快的速度将更改交付给客户？我们以多快的速度
00:06:48能够发布产品？他们发现对于一半的团队来说，其增长率低于 3 倍。而他们发现的
00:06:56实现低于 3 倍生产力提升的团队与那些实现了
00:07:014.5 倍中位数、在某些情况下甚至超过 10 倍的团队之间的差异，在于他们如何使用这些工具。其中 90% 的团队在我们的其他内部工具中使用了 Kiro。
00:07:11他们发现，关键不在于工具，而在于他们
00:07:18工作的方式。实现阶跃式提升的团队刻意改变了他们的工作方式，
00:07:26而其他团队只是简单地将 Kiro 和我们拥有的其他一些工具点缀在他们
00:07:31原有的工作方式之上。至少对我而言，这是一个重大的顿悟时刻，为什么我一直没有感受到
00:07:39AI 所承诺的大规模生产力提升，关键在于改变我们
00:07:47工作的方式。因此在整个试点过程中，他们去采访了参与试点的团队，以及
00:07:55Bedrock Mantle 团队和 Prime Video 上的其他一些团队，并发现了五个习惯。
00:08:03我非常具体地使用了“习惯”这个词，因为同样，这不单单是那一次冲刺，而是要在日常中
00:08:09这样去做。当他们采访这些团队时，他们发现这确实是他们必须在日常中
00:08:15养成的习惯。当我们改变工作方式时，很难培养这些习惯，建立这些习惯需要时间。
00:08:22让我们逐一过一遍这些习惯。习惯一：投资于智能体上下文。
00:08:30我们脑子里有很多东西，我们倾向于通过 Slack 交流，
00:08:35通过指导新人、通过代码评审、通过站会和冲刺规划等方式，将脑子里的所有东西传达给其他人，
00:08:42而现在他们必须把这一切都写下来。他们养成的习惯是：
00:08:50每当智能体犯错或者没有按照你的预期去完成某项工作时，
00:08:55就要思考：我的技能文件中缺少了什么？我的引导文件中缺少了智能体所需要的东西吗？
00:09:01但正如我们所知，在过去的一年里，我们看到模型的能力和行为都取得了长足的进步。
00:09:09去年中旬的 Sonnet 3.7 有很多怪癖，我们必须在引导文件中
00:09:16写下大量的“不要”。而自去年 11 月推出 Opus 4.5 以来，我们现在不需要做那么多了，
00:09:23并且自那以后，随着此后发布的所有新版本模型，我们已经有了六个多月的改进。
00:09:29所以新的习惯再次是：我的引导文件中是否仍然需要这个？还是说这只是在增加上下文的臃肿？
00:09:35第二个习惯是：放慢速度以实现加速。在几乎每个接受采访的团队中，
00:09:41他们都报告说，当他们刻意采用新的工作方式时，其生产力实际上
00:09:48下降了。这很反直觉，
00:09:53对吧？在你看到生产力提升的曲棍球棒曲线之前，你必须先进行有意识的工程工作。
00:09:59因为我们必须先在代码库中完成真实的工程工作，智能体才能在那里取得成功，特别是在棕地现有代码库中。
00:10:05所以他们必须建立智能体上下文，他们必须改善现有工具的错误消息，
00:10:11以便模型在失败时知道发生了什么，他们构建了新工具、新的 MCP 服务器来帮助模型真正
00:10:17完成它需要完成的工作。许多团队最终重构了他们的代码库，以便智能体
00:10:24能够更轻松地进行导航。我甚至见过激进的改变，比如更改
00:10:29代码库的编程语言。我经常看到团队在 Python、JavaScript 方面苦苦挣扎，因为它们是
00:10:36无类型语言。这很难测试。没有编译器错误。所以模型只能瞎猜
00:10:43然后把它交还给你。因此，我看到团队正在转向 TypeScript。Rust 在亚马逊内部
00:10:50变得非常受欢迎。编译器会给出很好的错误消息。你不需要这样做。但我见过很多
00:10:56团队为了能够看到的生产力提升而做出这些有意识的改变。
00:11:03第三个习惯是：喂养智能体，而不是保姆式照看智能体。对我和许多人来说，这是
00:11:09第三点是喂养智能体，而不是当保姆。对我和许多人来说，这是见证这种生产力阶跃式提升的顿悟时刻之一。
00:11:16一整天都在与你的智能体进行来回的对话，当然，你不会看到
00:11:23四到五倍的生产力提升，因为你从头到尾都身处其中。你可能
00:11:30坐在那里等上 30 秒到一分钟，等它生成代码并把代码拿回来让你
00:11:36审核。如果你坐在那里等着它，你就无法抽身去做别的事情。
00:11:42带着代码回来让你审查。如果你坐在那里干等，
00:11:48你就没办法去忙别的。让多个代理同时运行真的很困难，也很难把自己分身
00:11:55克隆成多个智能体非常不容易。因此，如果你的对话有点像左边这样，那么你
00:12:01其实是在照顾智能体，而不是像右边那样，为它提供它需要做的事情以及
00:12:08如何进行自我验证。这才是关键所在，这样智能体才能自我纠错，并且只在
00:12:14达到特定质量标准时、在代码真正运行编译并通过测试时、在
00:12:20代码可测试且具备高覆盖率时才找你。当然，更高阶的做法是将所有这些
00:12:26内容写入你的引导文件中。这样它每次都会自动执行，无需你手动提示。
00:12:33第四个习惯是明确意图。在亚马逊，我们进行了大量的规范和开发实践。
00:12:40我们已将这一点内置到 Kiro 产品中。因此，亚马逊工程师在 Kiro 中采用这种方式非常自然
00:12:46。与前沿工程相比，我通常看到随性编程（vibe coding）的做法是给出
00:12:54非常高阶的提示词，让智能体生成大量代码，然后进行来回的
00:13:02对话，说：“哦，这其实不是我的意思。你没有完全搞懂需求。”
00:13:10“不，我其实不想那样构建。这是一个技术设计。”我发现，当意图本身不正确时，
00:13:17与智能体围绕代码进行迭代的效率较低。因此，对于模糊、复杂的功用，亚马逊
00:13:26工程师通常会经历编写技术规范的过程。
00:13:34当然，在 Kiro 中你不需要编写完整的规范，你可以让模型生成它。
00:13:39但围绕文档与模型进行来回对话迭代，要比围绕散布在代码库中的
00:13:46代码更改进行迭代容易得多。第五个习惯是将测试左移。
00:13:56这里的关键之一是赋予智能体快速反馈循环，因为这能让它连续数小时自主运行
00:14:04并自我纠错。智能体难免会犯错，这没关系。但只要你提供正确的信号，它就能
00:14:12自我纠错，并且可以花上一段时间来完成。因此，我看到团队纷纷添加代码检查工具、单元测试、
00:14:20集成测试、性能测试和安全测试。这些都是我们一直都知道应该
00:14:24去做的事情，是良好的工程卫生和实践。但现在，我认为其投资回报率（ROI）终于
00:14:32高到足以让我们真正进行投资了。我看到很多团队在做的一件事是模拟（Mock）服务。
00:14:40过去做集成测试时，我们会对整个系统进行端到端测试，包括实时
00:14:46服务。但我们一直在大力投资完全在本地运行且带有确定性
00:14:52响应的模拟服务，因为这能让智能体在本地完成所有事情。在你的笔记本电脑上完成一切，而不必
00:15:01启动一堆其他服务并连接到云端服务，会让所有事情变得快得多。
00:15:07因为智能体获得的反馈越快，意味着它能进行的循环次数就越多，
00:15:14你自己的智能体就能发挥越高的生产力。综合来看，这些就是我们所看到的一些
00:15:21习惯。但当然，如果我告诉你只要采用所有这些习惯，
00:15:28你就能达到极乐境界，成为世界上生产力最高的工程组织，那我就是在说谎了。
00:15:35事情依然很艰难。我们仍处于早期采用者阶段，各团队也还在摸索中。
00:15:42因此，我们在组织层面各团队中看到的一个问题是职业倦怠（burnout）的风险。
00:15:48这个词不是我发明的，我忘了是谁在哪个会议上提出的，但 FOMAT（错失 AI 效能的焦虑）是真实存在的。我们看到
00:15:56工程师们深夜不睡，试图写出完美的提示词，好让他们的
00:16:03智能体在夜间运行几个小时，这样他们早晨醒来时就能直接拿到准备好的代码更改。认知负荷
00:16:09会随着你并行运行这些多个智能体而增加，你需要不断在
00:16:15终端标签页之间切换。此外，我们发现审查 AI 的输出通常比实际
00:16:22编写代码更难，尤其是对职业早期的人来说。资深工程师已经将他们职业生涯的
00:16:29很大一部分时间花在了审查他人代码上。但初级工程师还没有这种肌肉记忆。因此，审查代码
00:16:37所带来的认知负荷可能会比他们亲自动手编写时感到的大得多。另一个
00:16:44问题是组织变革。作为工程师，改变我们工作的方式本来就很困难。
00:16:52当我们成为前沿工程师时，我们度过整整一天的方式会发生彻底改变。但同时，组织也必须
00:16:58做出改变以赋能前沿工程团队。我经常看到的一个现象是：接受“慢下来以求快”。
00:17:07我自己就犯过这个错误，我的同行领导们也犯过这种错误，他们会说：
00:17:14“好了，你们现在有 AI 工具了，模型也这么惊艳了。为什么你们没有跑得更快？”
00:17:22那是因为你必须花那两个月时间投资你的代码库，为你的团队找出最佳
00:17:29实践，在团队中做出艰难的习惯改变。如果你总是期望
00:17:38每个月都交付功能，因为我们现在有了这些出色的模型，而且我们看到
00:17:44X（原推特）上的所有这些公司都在说他们一天能交付 20 个 PR，我们就必须放慢脚步才能跑得更快。
00:17:54第二点是在组织内部推广得太宽、太快。我认为，如果我们
00:18:01期望庞大组织中的所有团队立即成为前沿团队，我们就不会有
00:18:08来自先锋（pathfinder）、冲刺实验以及亚马逊内部试点团队的经验教训了。
00:18:16而现在对我们的挑战是，如何将其实际规模化？这就是 2026 年的主题。
00:18:22对于亚马逊来说，是如何将这套模式推广到更多团队，推广到接下来的 2000 个团队，而不仅仅是 50 个团队。
00:18:31因此我认为，当你推广得太快时，你会发现很多团队根本不知道自己在做什么。
00:18:37你还没有时间为自己的组织找到最佳实践、组织所需要的
00:18:43上下文。最后一点是，你会发现新的瓶颈。
00:18:49以前，手动编写代码是瓶颈。我发现，在亚马逊内部，我们发现
00:18:58决策速度成了新的瓶颈。你花在审查“是否要构建新产品”这一决策上的时间越多，
00:19:05实际上线一款新产品的决策审查花费越多，现在构建产品的速度反而越慢，因为写代码只需要一到两个月。
00:19:12所有与产品发布相关的审查流程都成了新的瓶颈。
00:19:20当构建新产品过去需要 9 到 12 个月时，在整体大局中
00:19:27这倒显得没那么重要。如果花两个月时间做出构建产品的决策，然后再花两个月时间
00:19:33来审批发布。但现在这些成了瓶颈，成了最耗时的环节。于是你会发现所有这些
00:19:40拖慢你速度的事情。我经常发现，前沿工程团队花在做决策上的时间比写代码的时间还要多。
00:19:48因此，你越能快速做出决策，尤其是那些容易被推翻的决策，效果就越好。
00:19:54所以，我给这里每个人的最大启示是，前沿工程的关键在于刻意改变你的工作方式。
00:20:03这很困难，需要时间。这是在培养新习惯和建立新的工作方式。
00:20:10这适用于任何工程团队以及你的整个组织。因此，我鼓励大家思考你如何与 AI 工具互动，
00:20:18以及这种互动如何改变，从而把你从“身处循环之中”的状态中解放出来。
00:20:27谢谢大家。如果后排有人有任何问题，我会再待一会儿。
00:20:34感谢大家今天抽出时间。