前沿团队正在做的，并不仅仅是借助AI来写更快的代码。他们正在从根本上重新设计软件构建的方式。结果呢？生产力提升了4.5倍，有些案例甚至超过了10倍。
六个工程师，七十六天。一个原本预估需要30名开发者、耗时12到18个月的项目，在一个季度内交付了。这不是纸上谈兵。它是Amazon Bedrock团队的真实经历——他们不再把AI当成一个写代码的快捷键，而是把它当作整个工作方式的基础。结果，这个团队在五个月内交付的生产级代码，比过去十年加起来还要多。
像这样的团队，和其他所有人之间的差距正在急剧扩大。AI编码袋里已经从根本上改变了软件编写的速度，但并未改变软件抵达客户手上的速度。提交量在激增，CI/CD管道也比以往任何时候都更繁忙。然而，真正部署到生产环境的功能，并没有跟上同样的节奏。瓶颈不在于袋里生成输出的能力，而在于袋里获取做出正确决策所需知识的途径，以及团队是否愿意围绕这个现实来重构工作方式。
我们把那些已经想明白这点的团队称作“前沿团队”。他们并不局限于那些精英实验室。他们遍布各行各业和各种规模的公司，并且共享一套共同准则：他们把采用AI视为一项工程投资，而不是一次工具部署。任何工程团队都能成为前沿团队；我们也可以告诉你其中的门道。
Amazon内部通向AI原生开发的三种路径
AI原生软件开发，是把AI当作软件构建的基础，由人类专家指导能力日益增强的袋里来工作。团队如何指导这些袋里，决定了最终的结果。在Amazon，引入AI进行开发的主要动力，是为了减少开发者在文档编写、协调和运维等非编码任务上花费的时间，清理技术债务，并最小化数千个小型“双披萨团队”之间的编码不一致性。我们已经在数百个工程团队中进行了实验，并至少确定了三种路径：由专家挑战难题的探路者计划、执行明确计划的结构化冲刺，以及将团队一分为二、对比现有方法和AI适配工作流的原位实验。这些路径在结构上各有不同，但最终都指向了同一个洞察。
探路者计划是一场受控实验。六位资深工程师接到了一个单一任务：重建Amazon Bedrock推理引擎，一个最初估算需要30名开发者工作12到18个月的项目。团队没有增加人手，而是在头几周重新设计了围绕AI的工作流，从离散任务转向目标驱动，并行运行多个袋里，并搭建了让AI能在非工作时间独立工作的系统。项目在76天内交付。按归一化的提交速度（每位开发者每周的提交次数，已根据仓库复杂度和团队规模调整）衡量，个人开发者的生产力提升了约20倍。提交量从每周2次跃升到40次。按部署到生产环境的代码行数计算，这个团队在五个月内交付的高质量代码，超过了他们在过去十年项目中交付的总和。
结构化冲刺则采用了不同的方法。Prime Video财务系统团队受到探路者模式的启发，进行了一次为期10天的实验。六位工程师，一个房间，零上下文切换，没有on-call值班，没有其他项目，有限的会议。一位资深工程师花了三周时间，事先将复杂任务拆解成范围明确的子任务，并附上了详细的需求。团队对复杂的特性开发采用了规范驱动开发模式，而对需求已经明确的任务则直接采用袋里辅助开发。10天里，他们产生了556次提交，而基线是96次，并将一个预估需要90周的项目时间缩短到了24周。这相当于近6倍的吞吐量和4倍的加速。他们将AI带来的增益归功于三个因素的叠加：对低判断力工作的加速（1.5倍）、对高判断力工作零上下文切换的更高专注（1.5倍），以及对袋里捕获领域专业知识的即时访问（1.5倍）。去掉任何一个因素，增益都会消失。这个团队现在正在探索如何在日常运营中，通过封装了领域知识的详细产品规范和解放专注时间的自主袋里，来优化这三个因素。
在原位实验中，在被研究的50多个团队里，那些同时实施了新工具和新实践的25个团队，其表现远超那些仅仅将AI添加到现有工作流中的团队。Amazon Stores与典型的开发团队一起，针对他们常规的待办事项列表，使用了Kiro和特定用途的AI工具进行结构化试点，没有任何特殊条件，也没有精挑细选的工程师。结果是中位生产力提升了4.5倍，有些团队的归一化部署速度（每个Sprint部署的特性数，已根据历史基线归一化）甚至达到了10倍以上的提升。Perfect Order Experience现在能在一下午之内交付一个特性，而以前需要两周。WW Grocery将设计文档的创建时间从五天缩短到了几个小时。
路径不同，但教训一致。关键在工作流，而不仅仅是工具。
成为前沿团队的五个步骤
纵观所有三种路径，表现最好的团队都遵循着五项具有共同逻辑的实践：减少袋里获取上下文信息的障碍，并增加它能独立完成的工作量。
这就是前沿团队与以往习惯的分水岭所在。传统方法优化的目标是个人代码生成的速度。前沿团队则优化了另一个目标：正确且可投产的软件到达客户手中的速率。这一区别驱动了下面所有的实践。
- 投资于袋里的上下文。最先进的团队会大力投资，通过创建袋里引导文件、提供团队约定、编码标准、测试和代码库导航等方面的指南，让项目和知识更容易被袋里消费。Bedrock基础设施团队将所有代码和文档都放入了单一代码库，并保留了AI袋里生成的内联注释，将其视为持久化记忆。跳过这一步的团队，最终都会纳闷为什么他们的袋里总是在犯同样的错误。
- 欲速则不达。上述实践需要时间，要求团队有耐心。每个高绩效团队都报告说，在学习新模型的最初阶段，速度反而慢了下来。他们将跨职能的专业知识编码成袋里可复用的引导文档，重构了仓库结构使其便于大语言模型推理，增加了注释并重新架构了代码分割以利于AI消费。那些坚持走完学习曲线、先明确预期结果再行动的团队，最终都体验到了指数级的加速。而那些期望在不改变工作流程的情况下就能立竿见影的团队，则感到了失望。要预期到前两周会感觉更慢，也要预期到之后几周会感觉快得惊人。在第二周就放弃的团队，永远看不到后面的指数增长。
- 喂养袋里，而不是当保姆。前沿团队会维护一个稳定的、范围明确且结果清晰的任务积压列表，并行运行多个袋里，并进行异步评审。开发人员报告说，他们能在短时间内完成重大特性，即使他们没有主动等待袋里完成任务，工作也在推进。一位首席工程师只用了“零散的几个小时”就完成了一次完整的代码变更，因为在他穿梭于代码评审、运维支持和会议之间时，袋里一直在工作。
- 在代码编写之前，先明确意图。无论是通过结构化规范、详细的需求文档，还是范围明确的任务分解，前沿团队都会确保袋里在开始生成代码之前，就对“完成”的状态有清晰的上下文。使用这种方法的团队报告说，他们手写的代码只占总量的1-2%，而每人每周推送的提交量却比以前多得多。
- “将测试左移。”前沿团队会构建工具，使得袋里能够在代码到达流水线之前，就在本地运行所有集成测试并自我纠正。Prime Video团队投资于自动化防护、组件测试、性能测试和代码格式化工具，这些工具及早地捕获了问题。代码评审的重点也随之转向了接口定义和架构决策，而不是代码风格和命名规范。
技术领导者现在就能做的事
并非每个团队都能取得这样的成果。那些跳过上下文构建阶段、将AI视为即插即用替代品、或者期望在不重构工作方式的情况下看到立竿见影效果的团队，表现始终不佳。整个行业的开发者都已经采用了AI编码工具，但并非所有人都看到生产环境的增益。他们用的工具没错，问题在于他们在错误的工作流中使用了正确的工具。
核心要点如下：
- 改变你的工作方式，才能让AI发挥最佳效能。
- 三个因素相乘才能带来成果：AI处理低判断力工作 × 不受干扰地专注高判断力工作 × 即时获取领域专业知识。
- 先试点，再推广。
实际的起点，不是大规模部署，而是精心设计的试点。从一个愿意花头几周时间（在编写生产代码之前）构建袋里上下文（引导文件、规范模板、单一代码库）的小团队开始。给这个团队下达一个任务：重构工作流。衡量提交速度、部署频率、问题解决时间，以及开发者满意度评分。然后，用他们学到的经验，为组织的其他部分打造一本行动手册。
那些实现了4.5倍到10倍以上生产力提升的团队，并不仅仅是采用了更好的技术。他们想明白了如何用一种不同的方式来开展工作。这个决定，今天任何工程组织都可以做出。当然，代码提交速度只是故事的一部分。我们希望能帮助改善软件开发生命周期的方方面面，无论是简化发布管理、运维和安全运营，还是处理生命周期终结升级和无数的软件开发中的非差异化任务。敬请关注后续文章，届时我们将深入探讨如何着手处理这些问题。
了解更多关于前沿团队 >
关注AWS Summit纽约市，获取更多关于AI原生开发的信息。
关于作者
Swami Sivasubramanian是亚马逊云服务（AWS）袋里式AI副总裁。在AWS，Swami领导了诸如Amazon DynamoDB、Amazon SageMaker、Amazon Bedrock和Amazon Q等领先AI服务的开发和发展。他团队的使命是，为客户和合作伙伴提供他们所需的规模、灵活性和价值，使其能够自信地利用袋里式AI进行创新，并构建出不仅强大高效，而且值得信赖和负责任的袋里。Swami还曾在2022年5月至2025年5月期间，担任国家人工智能咨询委员会成员，该委员会负责就国家人工智能倡议相关事宜向美国总统和国家人工智能倡议办公室提供建议。