从个人编码工具到开发平台：AWS Kiro 产品经理谈智能体编码的信任与成本

你信任谁来合并代码？

我经常向工程负责人问一个类似的问题：如果代码是智能体写的，你会让谁合并它？答案五花八门。我见过一些团队，智能体直接发布到生产环境，而人类几乎不看一眼 diff。我也见过一些团队，没有两位评审签字，就不让智能体靠近分支。同样的工具，舒适度却大不相同。

我感兴趣的是原因，因为这通常与模型有多好、或公司在工具上花了多少钱关系不大。它主要归结为一件比任何功能清单都更难谈论的事：你实际上有多信任这个东西。

大约三年来，我一直在观察各组织如何从“我的编辑器帮我补全这一行”走向“我的团队运行的东西更接近一座软件工厂”。混乱的部分在中间，而这正是我要尝试谈论的。

我的背景

我是 AWS 的高级首席产品经理，多年来从事容器和无服务器方面的工作，现在我在构建和发布 Kiro，这是亚马逊的智能体编码工具。这给了我几个观察角度：我与众多行业的 AWS 客户交流，也观察亚马逊内部的团队亲身经历这一过程。所以请把这一切当作一个人从这些位置上的解读。

最近发生变化的是帮助的规模。大约一年前，“AI 编码”主要意味着内联建议，即编辑器里更聪明的自动补全。现在，智能体会规划一项变更、跨多个文件编辑、运行测试并打开拉取请求。而最新的这一步最让人不安：智能体可以自行决定先做什么，从待办列表或失败的构建中挑出下一个任务，无需人类提示。我们从行级别的帮助，到任务级别的帮助，再到由它自己选择任务，而自动补全时代人们假设的许多东西，一旦发生这种情况就不再成立。

我越来越怀疑，这看起来像采购工具，其实没那么简单。据我所见，从个人辅助走向团队平台，往往是一场恰好涉及工具的组织变革。继续之前先提醒一句：这更多是故事而非电子表格，部分是因为好数据仍然稀少，部分是因为故事才是我真正学到东西的地方。

信任的获得速度取决于检查的速度，而非模型的速度

你可能会以为，随着模型变聪明，团队会给智能体更多工作。我看到的并非如此。他们给智能体更多工作，是因为他们更擅长检查工作了。基准分数上升不会打动任何人。真正打动人的是能够廉价地验证智能体的输出，并看着这些检查一次又一次干净地通过。

把信任看作是非此即彼的判断，并无帮助。它是一个光谱，每个团队都处在不同的位置。代码评审只是这个光谱上的一个点，从人类逐行阅读，到快速浏览，到由机器人把关合并，再到完全没人看。你落在哪里，取决于你能承受多少风险、变更周围的上下文（不是双关）比如它有多关键、多可逆，以及更小的事情，比如是谁写的、测试是否靠谱。同一个团队在调整配置和修改计费路径时会处在不同位置，而这恰恰是应该的。

所以，那些取得进展的团队并没有去追求能力最强的智能体。他们让输出易于阅读、易于测试、易于撤销，然后让智能体像新员工一样赢得更多空间——先把小事做对，直到你愿意把更大的事情交给它。那些挣扎的团队则把高自主性的智能体直接指向他们最重要的服务，然后寄希望于运气。做得好的团队则让它从枯燥的工作开始：测试覆盖率、迁移、依赖升级——在这些地方，糟糕的答案代价低廉且显而易见。

账单随智能体工作强度而增长

而这一切都要花很多钱。比大多数人目前意识到的还要多。

一位客户曾对我提出异议，因为一个智能体席位大约 19 美元，而对应的 Kiro SKU 是 20 美元。整整一美元。我只能笑笑，因为这一美元并不是人们会长期讨论的话题。这些人根本不知道等待他们的是什么。

在自动补全时代，成本是固定的按席位计费，无论开发者使用多少，账单都不会变动。智能体打破了这一点。当工作单元是一整个任务，而智能体在读取文件、运行测试、重试、推理一项变更时，你就要为所有这些活动付费。你让它做得越多，它运行得越多，成本就越高，席位价格反而成了你最不担心的事。

这是大多数预算未曾考虑过的反馈循环，因为你通过信任赢得的自主性，正是推高账单的自主性。一个在少数开发者身上看起来很棒的试点，一旦整个组织每天都让智能体处理每张工单，情况就大不相同了。

真正让我惊讶的是这个模式，因为我看到一个又一个客户在没有相互交流的情况下得出了相同的形态。支出极度不均衡。大约 80% 的开发者只使用约 20% 的预算，偶尔处理一些任务；而真正围绕智能体重构工作方式的 20% 则消耗了其余部分。没有“平均开发者”可以作为定价依据，你的账单主要来自第二组人。

所以问题不是“一个席位多少钱”，而是“一个有用工作单元的成本是多少，是否值得”。有时显然值得：一项原本需要人花半天时间的变更，只花几美元 token 就能完成，这是很容易的取舍。但很多智能体活动是重试、死胡同，以及在上下文中摸索，以重建一个更便宜的配置本来就知道的东西。关注这一点的团队像对待任何云账单一样对待 token，按团队和工作流提供可见性，以便区分有价值的支出和空转。

为什么这指向工厂

组织者要求我们把话题置于新兴的软件工厂概念中——智能体、开发者、团队、工具和上下文协同工作，来构建和演进软件。我越是思考信任和成本，它们就越像是链条上的两个环节：信任让你拥有工厂，而工厂让你控制成本。

信任排在第一位，因为工厂只有在智能体能够自主朝着目标取得真正进展时才能运转，而不是每隔几分钟就停下来确认，或者更糟——完成后留下人类去审查它从未费心证明正确的代码。除非你信任它能无人值守地运行，否则你就没有工厂，你只有一个非常昂贵的助手，仍然需要保姆。所以信任是首先解锁工厂的东西。

而工厂正是最终让你把成本控制住的东西。如果交给个人，节俭就是一千次私人的判断，关于什么时候值得运行一个智能体。一旦工作流经一个共享系统，你就可以把纪律固化进去，用预算、限额，以及把廉价任务路由到更便宜的模型，这样支出克制就成了流水线的属性，而不是你希望每个人都养成的习惯。你无法在一个开发者及其编辑器的层面上做到这一点。你甚至需要工厂才能拥有这些旋钮。这就是我认为仍未解决的部分，也是我最想和大家一起讨论的部分。

简短版本

从个人编码助手转向团队平台，与其说是购买工具，不如说是一种组织变革，而且顺序就是如此：你赢得足够的信任，让智能体无人值守地工作，这种信任让你能在它们周围建立一个真正的工厂，而工厂是唯一能真正把成本控制住的地方。

如果你只记住一件事：信任优先。它是解锁下游一切的关键，包括账单。为此而建设，剩下的就会成为你真正能管理的问题。

来参加这场分享听故事吧，我们会玩得开心。一个提醒：我保留在现在到会议之间更改演讲内容的权利。生成式 AI 的一年大约相当于三个狗年，几周就能改写整个对话，所以如果地基变了，演讲也会随之改变。