前沿团队如何重塑 AI 原生开发

前沿团队使用 AI 并不只是为了更快地编写代码。他们正在重新设计软件的构建方式。其结果是生产力提升 4.5 倍，在某些情况下甚至超过 10 倍。

六名工程师。七十六天。一个原本按 30 名开发人员、12 到 18 个月规划的项目，在一个季度内交付。这并不是假设。这是一个 Amazon Bedrock 团队不再把 AI 当作编码捷径，而是开始把它视为工作方式基础时发生的事情。该团队在五个月内交付的生产代码，比此前十年还要多。

这类团队与其他团队之间的差距正在迅速扩大。AI 编码代理从根本上改变了软件编写的速度，但并没有改变软件触达客户的速度。提交量正在激增，CI/CD 流水线比以往任何时候都更繁忙。然而，发布到生产环境的功能并没有保持同样的速度。瓶颈不在于代理生成输出的能力，而在于代理能否访问其做出良好决策所需的知识，以及团队是否愿意围绕这一现实重构工作。

我们把那些已经摸索出方法的团队称为“前沿团队”。它们并不局限于顶尖实验室，而是存在于各行各业、各种规模的公司中，并且共享一项共同的纪律：它们把 AI 采用视为一项工程投资，而不是一次工具推广。任何工程团队都可以成为前沿团队；我们可以向你展示如何做到这一点。

Amazon 通往 AI 原生开发的三条路径

AI 原生软件开发将 AI 视为软件构建方式的基础，由人类专家指导能力日益增强的代理。团队如何指导这些代理，决定了最终结果。在 Amazon，开发中采用 AI 的主要驱动因素，是减少开发者花在文档、协调和运维等非编码任务上的时间，消除技术债务，并尽量减少数千个小型“两张披萨”开发团队之间的编码不一致。我们已经在数百个工程团队中开展实验，并识别出至少三条路径：由专家应对挑战的探路者计划、执行明确定义计划的结构化冲刺，以及将团队一分为二、分别采用现有方法和 AI 适配工作流的现场实验。这些路径在结构上有所不同，但都指向同一个洞见。

pathfinder 计划是一项受控实验。六名高级工程师收到了一项单一任务：重建 Amazon Bedrock 推理引擎，该项目最初估计需要 30 名开发人员工作 12 至 18 个月。团队没有增加人手，而是在最初几周围绕 AI 重新设计工作流程，从离散任务转向目标驱动的成果，并行运行多个智能体，并建立系统，使 AI 能够在非工作时间独立工作。该项目在 76 天内交付。按标准化提交速度（每名开发人员每周的提交次数，并根据代码库复杂性和团队规模进行调整）衡量，单个开发人员的生产力约提升了 20 倍。提交次数从每周 2 次增加到 40 次。按部署到产品中的代码行数衡量，该团队在五个月内交付的高质量代码超过了其过去十年项目中的交付量。

这场结构化冲刺采取了不同的方法。Prime Video Financial Systems 团队开展了一项为期 10 天的实验，灵感来自 pathfinder 模型。六名工程师、一个房间、零上下文切换、无需值班、没有其他项目、会议有限。一名资深工程师事先花了三周时间，将复杂性拆解为范围明确、需求详细的任务。团队针对复杂功能工作采用规格驱动开发，而对于需求已经明确的任务，则采用直接的代理辅助开发。在 10 天内，他们完成了 556 次提交，而基线为 96 次，并将一个预计 90 周的项目缩短到 24 周。这相当于吞吐量提高近 6 倍、速度加快 4 倍。他们将 AI 带来的收益归因于三个因素的共同倍增：低判断工作加速（1.5 倍）、在无上下文切换的情况下对高判断工作的专注度提高（1.5 倍），以及即时访问

在现场实验中，在所研究的 50 多个团队里，同时实施新工具和新实践的 25 个团队，表现优于那些只是将 AI 添加到现有工作流中的团队。Amazon Stores 开展了结构化试点，由典型开发团队处理其常规积压任务，使用 Kiro 和专门构建的 AI 工具，没有特殊条件，也没有精心挑选工程师。生产力提升的中位数为 4.5 倍，一些团队在标准化部署速度（每个 sprint 部署的功能数量，并按历史基线标准化）上实现了超过 10 倍的提升。Perfect Order Experience 现在可以在一个下午发布功能，而不是两周。WW Grocery 将设计文档创建时间从五天缩短到几个小时。

路径不同，经验相同。重要的是工作流，而不仅仅是工具。

成为前沿团队的五个步骤

在所有三条路径中，表现最好的团队都共享五项实践，并遵循共同的逻辑。降低智能体获取上下文的障碍，并扩大其能够独立完成的工作范围。

这正是前沿团队与以往习惯分道扬镳的地方。历史上的做法优化的是个人代码生成的速度。前沿团队优化的则是另一件事：正确且可投入生产的软件到达客户手中的速度。这一区别驱动了以下每一项实践。

1. 投资于智能体上下文。最先进的团队会投入大量资源，通过智能体引导文件，以及关于团队约定、编码标准、测试和代码库导航的指导，让项目和知识更易于被智能体理解和使用。Bedrock 基础设施团队将所有代码和文档放入一个 monorepo，并保留 AI 智能体生成的内联注释，将其视为持久记忆。跳过这一步的团队会困惑于为什么他们的智能体总是犯同样的错误。
2. 慢下来才能加速。上述实践需要时间，也要求团队保持耐心。每个高绩效团队都报告说，在学习使用这些模型的初期，事情会先变慢。他们将跨职能专业知识编码进可复用的智能体引导文档中，重构代码仓库以便 LLM 能够对其进行推理，并添加注释、重新设计代码拆分以供 AI 使用。那些坚持度过学习曲线并首先定义预期结果的团队，随后经历了复合式加速。那些期待不改变工作流就能立即获得收益的团队则感到失望。预期前两周会感觉更慢。预期之后几周会感觉快得多。那些在第二周就放弃的团队，永远看不到这种复合效应。
3. 给智能体“投喂”任务，而不是全程看护它们。前沿团队会维护一个稳定的任务积压清单，其中包含范围明确、结果清晰的任务，并行运行多个智能体，并异步审查输出。构建者们报告称，他们能在短时间冲刺中完成重大功能，即使他们并未主动等待智能体完成任务，工作也会持续推进。一位首席工程师仅用“几个小时的连续时间”就交付了一项完整变更，因为在这位工程师切换于代码评审、运维支持和会议之间时，智能体一直在工作。
4. 在代码编写之前明确意图。无论是通过结构化规格说明、详细的需求文档，还是范围清晰的任务拆解，前沿团队都会确保智能体在开始生成代码之前，清楚理解“完成”意味着什么。一些采用这种方法的团队报告称，他们手写的代码仅占 1–2%，同时每人每周提交的次数比以前显著增加。
5. “将测试左移。”前沿团队构建工具，使智能体能够在本地运行所有集成测试，并在代码进入流水线之前自我纠正。Prime Video 团队投入建设了自动化护栏、组件测试、性能测试和格式化工具，以便及早发现问题。代码审查的重点从代码风格和命名约定转向接口定义和架构决策。

技术领导者今天可以做什么

并非每个团队都能取得这些结果。那些跳过上下文构建阶段、将 AI 视为即插即用的替代品，或期望在不重构工作方式的情况下立即获得收益的团队，表现一贯不佳。整个行业的开发者都已采用 AI 编码工具。但并非所有人都看到了生产力提升。他们并不是用了错误的工具，而是在错误的工作流中使用了正确的工具。

关键要点如下：

1. 改变你的工作方式，让 AI 发挥最佳效果。
2. 三个因素相乘可带来成果：AI 处理低判断力工作 × 不受干扰地专注于高判断力工作 × 即时获取领域专业知识。
3. 先试点，再扩展。

切实可行的起点并不是大范围推广，而是有意识地开展试点。先从一个小团队开始，这个团队愿意在编写生产代码之前，用最初几周来构建智能体上下文（引导文件、规范模板、monorepos）。赋予该团队重构工作流程的职责。衡量提交速度、部署频率和问题解决时间，同时衡量开发者满意度评分。然后利用他们学到的经验，为组织其他部门制定行动手册。

实现 4.5 倍到超过 10 倍生产力提升的团队，并不只是采用了更好的技术。他们已经弄清楚了如何以不同的方式与这项技术协同工作。如今，每个工程组织都可以做出这样的选择。当然，代码提交速度只是其中一部分。我们希望在软件开发生命周期的各个方面提供帮助，无论是简化发布管理、运维和安全运营，还是处理 EOL 升级以及软件工程中无数无差异化的任务。请继续关注下一篇博客，我将介绍我们如何应对这些问题。

了解更多关于前沿团队的信息 >

收看 AWS Summit New York City，了解更多关于 AI 原生开发的内容。

关于作者

Swami Sivasubramanian 是 Amazon Web Services（AWS）Agentic AI 副总裁。在 AWS，Swami 领导了 Amazon DynamoDB、Amazon SageMaker、Amazon Bedrock 和 Amazon Q 等领先 AI 服务的开发与增长。他的团队的使命是提供客户和合作伙伴所需的规模、灵活性和价值，使其能够自信地利用 agentic AI 进行创新，并构建不仅强大高效，而且值得信赖且负责任的智能体。Swami 还于 2022 年 5 月至 2025 年 5 月担任国家人工智能咨询委员会成员，该委员会的任务是就与国家人工智能倡议相关的议题向美国总统和国家 AI 倡议办公室提供建议。