跨国深谈← 返回←AWS 高级首席工程师:AI 提效 4.5 倍,靠的不是工具而是改工作方式

AWS 高级首席工程师:AI 提效 4.5 倍,靠的不是工具而是改工作方式

关联

人物 Clare Liguori

公司 Kiro · Amazon · AWS · Bedrock

概念 智能体 · 前沿开发 · vibe coding · steering 文件 · 测试左移

「过去用各种 AI 编程工具,我只觉得自己生产力提升了 10% 到 20%。但现在在 Amazon 内部的试点里,我们看到了中位数 4.5 倍、有时超过 10 倍的生产力提升。

」说这话的人是 Claire Liguori,AWS 的高级首席工程师,主要负责智能体编程助手 Kiro。她在一次演讲里,把 Amazon 内部这一轮「阶跃式提升」的来龙去脉摊开讲了——核心结论很反直觉:关键不在工具,而在改变工作方式。

先看几个真实数字

Liguori 把 AI 编程辅助的演进分成几步:行内代码补全 → 聊天问答 → vibe coding(随手给个高层指令、让 AI 生成代码)→ 现在被她称为「前沿开发」的早期采用阶段。她定义前沿开发者有三个行为:

• 放手式编程:自己写的代码只占产出的 1% 到 2%,其余全是智能体写的;
• 低频交互:目标是让编程助手不干预连续运行数小时;
• 消灭空闲时间:并行跑多个智能体,不断消化积压任务。

第一个标杆是 Bedrock Mantle 团队。Bedrock 是 AWS 的模型托管服务(托管 Claude、GPT 这类大模型),团队原本估算要重建一个新的推理数据平面(承载推理流量的核心服务层),需要 30 人干 18 个月。

结果他们退了一步,用 6 个人、靠 Kiro 在 76 天内建成了——按 commit 衡量,提升最高到 20 倍。 但这个故事有个「作弊」之处:这 6 个人是公司最顶尖的工程师,包括两位 distinguished engineer(.AWS 内部最高技术职级),都是分布式系统和 LLM 架构专家,对多数团队不可复制。

于是 Prime Video 组织做了第二个实验:10 天冲刺,又是 6 名工程师关起门来用 Kiro,把项目交付时间估计从 90 周压到 24 周。但这里也有水分:没人 on-call、几乎没会议、而且一位资深工程师提前花了三周把任务拆成非常细小、范围清晰、带详细需求的条目,工程师只管开工。

【背景】这里讲的 Kiro 在转写稿中有时被语音识别写成 Curo,是同一个产品。

关键实验:50 个普通团队,差距在使用方式

两个标杆都有「不可复制」的嫌疑,所以 Amazon Stores(涵盖 Amazon.com、零售网站和线下实体店)做了更结构化的试点:观察 50 个完全普通的团队——人员构成正态分布、维护的是带既有代码库的现有系统,不是从零开始的 Greenfield 项目——跟踪了去年大半年。

结果很有意思:一半团队提升不到 3 倍,另一半中位数 4.5 倍、有些超过 10 倍。这次用的指标不只是 commit,而是部署到生产的速度——多快能把变更交付给客户。

90% 的团队都在用 Kiro 等内部工具,所以差别不在工具。「实现了阶跃式改进的团队,是有意地改变了他们的工作方式;其他团队只是把 Kiro 零星地撒在现有工作方式之上。」 Liguori 说这是她的最大顿悟:这解释了她自己为什么一直没感受到 AI 承诺的巨大提升。

试点团队走访出了五个日复一日的习惯(她特意强调是「习惯」,不是一次性冲刺):

五个习惯

1. 投资于智能体上下文。 脑子里的知识原来靠 Slack、导师、代码审查、站会传给同事,现在必须写下来。

具体习惯是:每当智能体犯错或做得跟你会做的不一样,就问「我的 skills 文件、steering 文件(给智能体的长期指导文件)里缺了什么?」还要定期清理:去年年中的 Sonnet 3.7 怪癖多,steering 文件里写满「不要做」;到去年底的 Opus 4.5 就没那么多要写的了,而且此后又有超过六个月的模型迭代——每条规则要问自己「还必要吗,还是只是在让上下文臃肿?」

2. 放慢速度以求提速。 几乎所有受访团队都报告:有意采用新工作方式时,生产率先下降。

因为得先做真正的工程工作——把智能体上下文建起来、改进现有工具的错误信息让模型失败时知道发生了什么、建新的 MCP 服务器(给模型接外部工具的标准接口)、甚至重构代码库让智能体更容易导航。 极端案例是换编程语言:Python、JavaScript 这类无类型语言没有编译器报错、难测试,模型只能靠猜;她见过团队迁到 TypeScript,Rust 在 Amazon 内部也因此流行起来——编译器能给出很好的错误信息。

3. 喂养智能体,而不是看管智能体。 这是另一个顿悟点:如果你整天和智能体来回对话(vibe coding),每 30 秒到一分钟等它生成代码再审,你全程在循环里,当然不可能有 4 到 5 倍提升,也没法并行跑多个智能体。

正确姿势是把任务和自我验证方式一起喂给它,让它能自我纠错,只在达到质量门槛——能跑、编译过、测试过、覆盖率够高——时才回来找你。下一层是把这一切写进 steering 文件,让它每次自动照做。

4. 把意图明确化。 Amazon 大量实践规范驱动开发,已内建进 Kiro。

vibe coding 的典型失败模式:给个高层 prompt → 生成一大堆代码 → 来回扯皮「这不是我要的意思」。Liguori 的经验是:当意图本身就不对时,在代码上迭代的效率远低于先在文档上迭代。对模糊、复杂的功能,先写规格说明(可以让模型生成)——就一份文档来回对话,比就散落在代码库各处的改动来回对话容易得多。

5. 把测试左移。 快速反馈回路是让智能体能独自运行几小时并自我纠错的前提。

团队在加 linter、单元测试、集成测试、性能测试、安全测试——都是早该做的事,「但现在投资回报率终于高到值得我们真正投入了」。 一个流行做法是把依赖服务 mock 掉(本地跑、响应确定性的假服务),让智能体一切都在笔记本上完成,不必启动一堆云服务——反馈越快,能跑的循环越多,生产力越高。

还很难:三个坑

别以为 adopting 全部习惯就到极乐境界,Liguori 强调仍在早期采用阶段:

• 倦怠风险(FOMAT):工程师熬夜调「完美 prompt」,想让智能体夜里跑几小时、早上醒来代码就绪;并行多智能体带来认知负担、不断切终端标签页;而且审阅 AI 输出往往比亲手写更难——资深工程师有多年审代码的肌肉,初级工程师没有,审阅的认知负担反而比写大。
• 组织变革:领导者容易犯的错是「你们有 AI 了怎么不更快?」——但团队需要那两个月投资代码库、摸索最佳实践、改习惯。第二个错是铺得太快:如果一开始就要求所有团队立刻成为前沿团队,就拿不到探路者、Sprint、试点带来的经验。Amazon 2026 年的挑战是把这套东西从 50 个团队推广到 2000 个团队。
• 新瓶颈:手动写代码不再是瓶颈,决策速度成了新瓶颈。代码一两个月就能写完,于是「要不要做这个产品」的审查、发布审批流程成了最耗时的环节。前沿工程团队花在做决策上的时间常常比写代码还多——所以快速决策、尤其是容易逆转的决策,越多越好。

本集带走

• 提升上限不在工具,在工作方式:50 个普通团队、同样的工具,一半不到 3 倍、一半中位数 4.5 倍,差距就是「有意改变工作方式」vs「把工具撒在旧方式上」。
• 先接受变慢:引入期生产率会先下降,要花约两个月投资代码库、建智能体上下文、改团队习惯,才看得到曲棍球杆曲线。
• 喂养而非看管:给任务时附上自我验证标准(能跑、编译过、测试过、覆盖率高),让智能体自我纠错、几小时不回来找你——这是并行多智能体和真正提效的前提。
• 意图不对就别在代码上迭代:模糊复杂功能先写规格文档,和模型就文档来回改,比就散落各处的代码改动扯皮高效。
• 测试和 mock 服务的 ROI 终于到位了:快速反馈回路直接决定智能体能跑多少自纠循环;mock 掉外部依赖让一切在本地完成。
• 盯住新瓶颈:代码快了之后,决策和发布审批流程才是长杆——多做得快速、可逆的决策。

但现在在 Amazon 内部,我们和公司里不同的团队开展了试点,我们看到了中位数 4.5 倍的生产力提升,有时甚至超过 10 倍。
But now inside of Amazon, we’ve been running pilots with different teams across the company, and we’ve been seeing a median of 4.5x productivity improvement and sometimes more than 10x.
—— Clare Liguori · [01:22]

前沿开发者自己写的代码可能只占他们产出代码的 1% 到 2%,其余的都是智能体写的。
Frontier developers write maybe 1% to 2% of the code that they produce. The rest is agents.
—— Clare Liguori · [01:52]

他们发现关键不在于工具本身,而在于他们的工作方式。
And what they found was it wasn’t about the tools, it was about the way that they worked.
—— Clare Liguori · [07:14]

实现了阶跃式改进的团队,是有意地改变了他们的工作方式,而其他团队只是把 Kiro 和我们的一些其他工具零星地撒在现有的工作方式之上。
The teams that achieve step function improvements intentionally changed the way that they worked, and the others simply kind of sprinkled Kiro and some of the other tools that we have on top of their existing way of working.
—— Clare Liguori · [07:19]

你必须先做有意的工程工作,才能看到生产率提升的那条曲棍球杆曲线,因为我们必须先在代码库里做真正的工作,智能体才能在那里取得成功,尤其是在既有代码库中。
You have to do intentional engineering work before you’re going to see that hockey stick curve in productivity improvement because we have to do real work in our code bases first for agents to be successful there, especially in Brownfield existing code bases.
—— Clare Liguori · [09:54]

如果你在 vibe coding,如果你整天和你的智能体来回对话,你当然不会看到 4 到 5 倍的生产力提升,因为你全程都在循环之中。
If you are vibe coding, if you are having a back and forth conversation with your agent all day long, of course, you’re not going to see 4 to 5x productivity improvements because you are in the loop the entire time.
—— Clare Liguori · [11:21]

这才是真正的关键,让智能体能够自我纠错,只有在达到某个质量门槛、真正能跑起来、编译通过、测试通过、覆盖率真的够高时,才回来找你。
And that’s really the key so that agents can self-correct and only come back to you when it meets a certain quality bar, when it actually runs and compiles and passes tests, when it’s testable, when it actually has high coverage.
—— Clare Liguori · [12:09]

而我发现,当意图本身就不正确时,与智能体在代码上迭代的效率会低一些。
And it is less, I find, less productive to iterate with the agent on code when the intent itself was incorrect.
—— Clare Liguori · [13:14]

然后我们也确实看到,对某些人来说,审阅 AI 输出往往比亲自写代码更难,尤其是职业生涯早期的人。
And then we do see that reviewing AI output is often harder for some than actually writing it, especially early in career.
—— Clare Liguori · [16:17]

我们必须慢下来才能快起来。
We have to slow down to speed up.
—— Clare Liguori · [17:51]

你花越多时间去审查是否要真正构建一个新产品的决策,现在构建这个产品就越慢,因为代码只需要一两个月就能写完。
The more that you spend reviewing the decision to actually build a new product, the slower it is to build the product now because the code only takes one to two months to write.
—— Clare Liguori · [19:02]

我经常发现,前沿工程团队花在做决策上的时间比写代码还多。
Often I find that frontier engineering teams spend more time making decisions than they do writing code.
—— Clare Liguori · [19:44]

所以你能做出的快速决策越多,尤其是那些容易逆转的决策,就越好。
And so the more that you can make fast decisions, especially ones that are easy to be reversed, the better.
—— Clare Liguori · [19:51]

所以我在这里给所有人的一个大要点是:前沿工程的核心是有意识地改变你的工作方式。
So my one big takeaway for everyone here is that frontier engineering is about intentionally changing the way that you work.
—— Clare Liguori · [19:57]