AI 工程成熟度模型：团队进阶的 5 个阶段

AI 工程成熟度模型是一个面向软件组织的五阶段框架。它描述了团队如何从临时的 AI 辅助编码发展到带有治理的多智能体编排。团队首先需要开发者信任，然后是评审带宽，接着是平台质量，最后是面向委派智能体的治理控制。通用企业框架涵盖整个企业的 AI 采用；该模型则聚焦于工程团队。在下面比较的七个框架中，六个聚焦于企业 AI 采用，只有 Gigacore AI-MM SET 面向覆盖完整开发生命周期的软件工程团队。

试图对团队 AI 成熟度进行基准评估的工程负责人面临着一组分裂的七个框架。有些涵盖通用企业采用，另一些则描述个人实践者的进阶阶梯。主要的企业和咨询出版机构各自发布自己的框架，而其中没有哪个主要框架聚焦于软件工程团队。像 Steve Yegge 的 8 个 AI 采用级别这样的实践者模型从下方填补了这一空白，但它追踪的是单个开发者对智能体的信任，而非团队的操作模型。结果就是测量缺口。一位工程副总裁可能在通用企业量表上被评为“运营级”，而其组织合并的拉取请求增加了 98%，交付指标却毫无改善。

本指南通过定义五个阶段、每次转变背后的数据，以及能告诉你团队所处位置的指标，来诊断个人速度与组织吞吐量之间的脱节。Augment Cosmos，我们统一的云智能体平台，出现在后续阶段，作为跨软件开发生命周期的共享上下文、风险分级治理和多智能体编排的参考实现。

大多数 AI 成熟度框架衡量的是通用企业采用，而非软件交付机制。工程负责人需要一个将 AI 使用与评审吞吐量、平台质量和受治理的智能体工作流联系起来的模型。在当前研究收录的框架中，只有 开源的 Gigacore AI-MM SET 面向覆盖完整开发生命周期的软件工程团队。下表按发布方、阶段数量和工程聚焦度比较了被引用最多的七个框架。

采用数据解释了为什么需要专门针对工程领域的模型。一项调查发现，只有 1% 的高管认为其 生成式 AI 部署已成熟，而软件工程占生成式 AI 总潜在价值的 25%。负责这一价值池的领导者需要一个将 AI 采用与软件交付联系起来的模型。

在表中的七个模型中，Yegge 的阶梯是最接近实践者的尝试。正如 O'Reilly Radar 所总结的，“前四个层级是关于日益复杂的 IDE 使用；第五到第八个层级是关于编码智能体。”这个阶梯在一个轴上追踪单个开发者的信任度。团队模型还需要治理、共享工具和工作流集成，这些维度在我们的智能体协作模型指南中有所涵盖。

五阶段 AI 工程成熟度模型追踪团队的主导 AI 模式、标志该阶段的组织信号，以及阻碍进入下一阶段的约束条件。工程领导者由此可以定位将个人 AI 使用转化为团队级交付成果的瓶颈。下表总结了每个阶段在实践中的样子以及阻碍进阶的约束条件。

第 1 阶段临时辅助团队使用由开发者逐个采用的自动补全和聊天工具。个人实验达到了 Stack Overflow 报告的 84% 使用或计划使用规模，而信任、策略和度量仍然是团队级实践的约束条件。Stack Overflow 对 49,000 多名受访者的 2025 年调查发现，84% 的开发者使用或计划使用 AI 工具，高于 2024 年的 76%。同一调查发现，51% 的专业开发者每天使用这些工具，而 JetBrains 对 24,534 名开发者的 2025 年开发者生态系统状况调查发现，85% 的人经常使用 AI 工具进行编码和开发。JetBrains 的2026 年 1 月 AI Pulse 后续调查报告称该数字已攀升至 90%。

这一阶段的组织姿态默认是宽松的。一项 2024 年开发者调查发现，近 80% 的公司允许第三方 AI 工具或没有正式限制。

信任是迈向第 2 阶段的门槛。只有 29% 的开发者信任 AI 输出的准确性，低于 2024 年的 40%，而 46% 的人积极不信任它们。DORA 关于对 AI 的信任的研究展示了程序上的解决办法。当开发者相信代码审查和自动化测试会在生产环境之前捕获 AI 引入的错误时，他们更信任 AI，而信任度会随着培训和专门的实验时间而上升。

同样的信任问题使入职成为第 1 阶段的一个测试案例。Augment Code 将培训和实验与代码库模式识别联系起来，因此开发者先学习代码库约定，然后信任才依赖于个人判断。采用这种方法的团队看到入职时间从 6 周降至 6 天。

阶段 2 的受监督智能体团队在 IDE 内运行编码智能体。智能体编辑文件并执行命令，而开发者则逐步引导每一步。这提高了产出量，并将瓶颈转移到人工审查带宽上。在 10 个月的时间窗口内，工具从单个 IDE 插件转向了具名的编码智能体产品，Cline 于 2024 年 7 月推出，Cursor 和 Windsurf 的智能体模式于 2024 年 11 月推出，GitHub Copilot Coding Agent 于 2025 年 5 月推出，以及 Claude Code。采用率落后于工具：根据 Stack Overflow 的 2025 年调查，23% 的开发者经常使用 AI 智能体。

InfoQ 的AI 时代开发分析发现，“开发者正在从代码的唯一作者转变为更像管理者的角色，引导智能体、验证输出并确保需求真正得到满足”，并且一门新学科正在出现：上下文工程，“设计智能体生成生产就绪代码所需的输入、脚手架和护栏。”

五个维度定义了阶段 2 的诊断模式：

这一模式解释了为什么智能体采用可以在团队交付改善之前先提高本地产出。

审查带宽决定了退出这一阶段的门槛。InfoQ 关于多智能体架构的演讲描述了数量问题：“Cursor，你给它一个提示，5 分钟内，你就得到 1,000 行代码……”该演讲报告了一种趋势，即大约 80% 的智能体生成代码没有接受人工审查。

这一审查缺口是阶段 2 的控制点。Augment Code 的代码审查通过自动化拉取请求分析来解决它，该分析会根据仓库上下文、架构模式和团队标准审查变更，之后人工审查者才成为唯一质量关口。该工具在基准测试中取得了 59% 的 F-score。

阶段 3 的标准化团队实践组织将个人 AI 使用转化为受认可的工具、共享配置、治理关口和度量。在这一阶段，生产力提升取决于平台质量和审查流水线容量。Faros AI 遥测覆盖 1,255 个团队的 10,000 多名开发者，发现 AI 采用率高的团队完成了多 21% 的任务，并多合并了 98% 的 PR。同一批团队的 PR 审查时间增加了 91%，平均 PR 规模增长了 154%，缺陷数量上升了 9%，而组织层面的 DORA 指标没有显示出可衡量的改善。其机制就在研究结论本身：“当 AI 工具加速个人代码生成，却没有相应加速审查流水线时，结果就是未审查拉取请求队列不断增长，并在组织层面吸收掉生产力收益。”

阶段 3 的度量将产出增长与吞吐量改善区分开来：

2025 DORA 报告（n≈5,000）在大规模上证实了这一模式：AI 采用如今与软件交付吞吐量和产品性能呈正相关，但与软件交付稳定性仍呈负相关。该报告还提出了一个隐藏的验证税：写代码节省的时间又被重新花在审计代码上。当未经授权的 AI 使用绕过审查、安全和合规控制时，影子 AI 会加剧这一风险。

DORA 的平台工程数据通过平台质量定义了出路。“当平台质量高时，AI 采用对组织绩效的影响变得强劲且积极。反之，当平台质量低时，影响则微乎其微。”这些第三阶段症状在没有统一系统的情况下，对应个人采用中的四种机制：每个工程师都构建个人工作流导致设置碎片化、专业知识被困在个人配置中、没有跨团队的质量信号，以及将人工介入集中在最终 PR 的审查瓶颈。

第三阶段团队需要在最终 PR 之前拥有共享上下文。Augment Cosmos，我们统一的云代理平台，将代理工作流上下文保存在共享 Sessions 中，以便团队可以复用有效的工作模式。Augment Code 在多文件重构和迁移工作流中实现 5–10 倍更快的任务完成速度。Context Engine 通过语义依赖图分析处理 400,000+ 文件的整个代码库，赋予代理架构级的理解能力。Sessions 的默认共享和专家注册表也让整个团队能够找到并复用某位工程师的工作模式。

第四阶段自主委托团队在隔离的远程环境中运行无头代理，并返回拉取请求。只有当风险分级治理控制审查范围时，委托能力才会增加。Gartner 的编码代理预测预计，到 2027 年，超过 65% 使用代理式编码的工程团队将把 IDE 视为可选。

两项纪律至关重要：

• 评估基础设施。评估基础设施围绕行为质量以及功能正确性重新构建自主代理 CI。关于可合并代理输出的学术研究发现，在自主代理条件下，代理输出可能无法真正“可合并”，并且可能包含细微的回归或表面修复。
• 风险分级治理。风险分级治理需要共享的 AGENTS.md 文件、提示库、SSO/SCIM、密钥扫描、对代理输出的 PR 门禁、审计日志以及经批准的模型网关。Gartner 的关于代理失败的治理预测警告称，到 2027 年，40% 的企业将因代理治理缺口而降级或停用自主 AI 代理，而这些缺口企业往往只有在生产事故之后才会发现。该警告将风险与一种二元姿态联系起来：“企业正在将 AI 代理治理视为二元选择——要么锁定，要么完全信任。”在校准的分级中，策略自动批准常规变更，批准带日志记录的重构，要求对业务逻辑进行人工审查，并要求对安全变更进行强制人工审查。

评估基础设施和风险分级治理共同决定了自主委托能否在不隐藏生产风险的情况下提高吞吐量。

在 Stage 4 生命周期中，Augment Cosmos 将这些层级映射到带有审计记录的工作流。Environments、Experts 和 Sessions 执行平台策略，并记录智能体做了什么以及为什么这么做。每次运行都会被捕获以供审计和复用，为 SOC 2 审查者提供跨常规变更、重构、业务逻辑和安全变更的运行级证据。

Stage 5 编排型组织运行协调的 工作流编排平台，人类在定义的检查点进行引导，而不再监督单个任务。共享上下文让智能体拥有相同的仓库视图，护栏设定工作流边界，模型路由将工作分配给适合每项任务的模型。在此阶段，编排将目标分解为子任务，将其委托给专门的智能体，管理共享上下文，执行护栏，并合并最终结果。Anthropic 的 2026 年智能体编程趋势报告 描述了此阶段人类的角色：“构建软件时人类的主要角色是编排编写代码的 AI 智能体，评估其输出，提供战略方向，并确保系统为正确的利益相关者解决正确的问题。”

Stage 5 编排通过五个运营维度将智能体工作与人类引导分开：

Model Context Protocol 达到了其 2025-11-25 规范，MCP SDK 月下载量超过 9700 万次，并被捐赠给 Linux 基金会下的 Agentic AI Foundation。

Yegge 的 Level 8 是“构建你自己的编排器”，在组织层面这变成了构建与购买的决策。Augment Code 的 Context Engine 与上下文有限的工具相比将幻觉减少了 40%，而 Augment Cosmos 通过共享上下文、记忆和治理控制支持 Stage 5 风格的多智能体编排。模型路由跨 Anthropic、OpenAI、Bedrock、Vertex 和开源模型运行，因此每个编排步骤都可以使用最适合该任务的模型。Augment Code 凭借其 Context Engine 和代码库范围的上下文在 SWE-bench Verified 上达到 70.6% 的准确率；该数字并未专门衡量智能体工作流或编排的 PR 撰写。智能体规划多步骤任务，执行已批准的命令，并基于仓库上下文创建拉取请求。

借助 Augment Cosmos 的 Cloud Agents Platform，软件交付循环将人类参与引导至优先级排序、规格审查和代码演进审查。这些成为智能体工作流的明确交接点。

我们的 AI 编程自动化 指南在治理层面做出了同样的区分。AI 辅助型组织使用提示-响应工具，而智能体治理型组织通过检查点、审计日志、模型路由和 PR 门禁来协调智能体系统。

使用交付遥测数据来确定团队所处的阶段。PR 周期时间、评审负载、返工和稳定性数据揭示了哪个成熟度约束限制了团队层面的 AI 成果。随着团队不断进步，关键指标也会发生变化，如下表所示。

来自 DORA AI 能力模型 的两项发现为衡量计划奠定了基础。第一，放大器原则：“AI 的主要作用是放大器，放大高绩效组织的优势，也放大陷入困境组织的功能失调。”第二，该模型确定了七种放大 AI 收益的实践，包括清晰且已传达的 AI 立场（“AI 方面的模糊性会扼杀采用并制造风险”）、健康的数据环境、AI 可访问的内部数据以及强大的版本控制。

如需涵盖代码库、数据和治理就绪情况的预评估，请参阅我们的在工程团队中扩展 AI 采用指南。

当每个阻碍因素都映射到可观察的交付指标时，阶段定位最为可靠：

在增加代理之前，用交付数据确定你所在的阶段。代理能力可能超过组织的评审和治理能力，而个体速度可能制造出超过操作系统吸收能力的工作量。

在接下来的两周内，将 PR 评审时间、PR 大小和返工率与代理使用情况一起纳入监测。然后使用交付数据将你的团队定位到上面的五阶段表中。被卡在阶段 3-4 的团队需要共享仓库上下文、强制人工检查点以及可审计的用于端到端功能自动化的自主代理，然后才能扩展代理数量。

• 在工程团队中扩展 AI 采用的 6 种变革管理策略
• 6 种行之有效的 AI-人类开发协作模型
• 从 IaC 到监控的 10 个 AI DevOps 工作流
• 面向 DevOps 的 5 大 AI 工作流编排平台
• 工程速度指标：7 个 AI 增强框架