AI-Native 成熟度完全指南:从工具试用到持续进化

先说结论：AI-Native 不是“全员都在用 AI”

一家企业采购了 Copilot，研发团队接入了大模型 API，内部搭了十几个 Agent，并不等于已经 AI-Native。

真正的区别在于：AI 是否从个人工具变成了组织可以稳定复用、治理、度量和持续改进的系统能力。它至少要同时满足六个条件：

• •AI 投资能对应明确的业务结果；
• •团队知道人和 AI 各自负责什么；
• •数据和知识可被安全、准确地使用；
• •工程平台能够支撑开发、评测、发布和回滚；
• •治理与安全不是上线前临时补课；
• •生产运行可以观察质量、成本、风险和价值。

DORA 2025 年研究给出了一个很重要的判断：AI 更像一个放大器，会同时放大组织已有的优势和弱点。工具本身不是最大回报来源，底层组织系统才是。

什么是 AI-Native

本文把 AI-Native 定义为：

这一定义刻意避开三个误区。

AI-Native 不等于 AI-First

AI-First 强调优先考虑 AI 方案；AI-Native 强调组织是否具备长期运行这种方案的能力。不是每个问题都应该用生成式 AI。Microsoft 的 AI Strategy 指南也建议先识别业务问题，再判断使用非确定性的生成式 AI，还是更适合确定性流程的传统自动化或分析模型。

AI-Native 不等于模型自研

采购 SaaS、使用托管模型、搭建自有平台都可能达到较高成熟度。Microsoft 将现成 Copilot、低代码 SaaS、PaaS 和自管基础设施视为不同的控制权与复杂度选择，而不是从低到高的价值排行榜。

AI-Native 不等于无人化

成熟组织不是一味扩大自动化，而是根据风险设置建议、辅助决策、受控执行和自主执行的不同边界。高风险动作仍可能需要人工审批。

为什么需要成熟度模型

成熟度模型的价值不是给企业贴一个“先进”或“落后”的标签，而是回答三个具体问题：

1. •当前最短的能力板在哪里？
2. •下一阶段应该补什么，而不是继续采购什么？
3. •什么时候可以扩大场景范围和 Agent 自主性？

如果没有分级，企业常出现两种相反错误：

• •能力不足却过度自动化：数据、权限和评测尚未准备好，就让 Agent 修改生产系统；
• •能力已经具备却停留在试点：每个团队重复做 PoC，没有平台、标准和投资机制承接。

Microsoft 的官方 AI adoption planning 提供了 4 级技能与数据就绪度，用来判断哪些 Azure AI 用例当前可行。本文在此基础上扩展到战略、组织、平台、治理和运营，但不会把两套等级混为一谈。

六个评估维度

战略与价值

看组织是否从业务问题出发，是否能把 AI 用例连接到收入、成本、风险、体验或速度等结果。

关键证据：

• •AI 战略与业务战略有明确关系；
• •用例有负责人、受益对象和成功指标；
• •投资组合按价值、可行性与风险排序；
• •PoC 结束后有停止、迭代或规模化决策；
• •持续比较 AI 方案与非 AI 方案。

组织与人才

看人、团队、职责和协作方式是否已经适应 AI 工作。

关键证据：

• •员工拥有与岗位相关的 AI 能力，而非只学提示词；
• •产品、业务、数据、工程、安全和法务共同参与；
• •明确哪些结果由人负责，哪些动作可委托给 AI；
• •有内部社区、专家支持和复盘机制；
• •绩效制度不会鼓励隐藏风险或盲目追求使用量。

数据与知识

看 AI 是否能获得及时、准确、有权限边界和来源记录的数据。

关键证据：

• •数据源、所有者、敏感等级和用途可查；
• •企业知识可检索，且文档有版本、有效期和来源；
• •权限在检索、生成和工具调用过程中保持一致；
• •有代表生产分布的黄金数据集；
• •能处理过期知识、数据漂移和跨租户隔离。

DORA 的能力模型特别强调健康数据生态和 AI 可访问的内部数据。这里的“可访问”不是无条件开放，而是让授权范围内的数据能够可靠进入工作流。

工程与平台

看 AI 应用能否像其他生产系统一样被开发、测试、部署和恢复。

关键证据：

• •Prompt、模型、工具、数据 Schema 和策略均版本化；
• •有统一模型网关、身份、密钥、限流和成本接口；
• •建立离线评测、在线监控和回归门禁；
• •实验、开发、测试和生产环境隔离；
• •支持灰度、回滚、模型替换和供应商切换；
• •平台提供“铺好的路”，而非强迫每个团队重复造轮子。

DORA 的七项能力还包括强版本控制、小批量工作和高质量内部平台。这些都是 AI 研发速度转化为稳定交付的基础。

治理与安全

看风险管理是否贯穿战略、设计、开发、部署和运行，而不是只靠一份原则文档。

关键证据：

• •对用例按数据、用户、动作和影响分级；
• •明确模型、平台、应用团队和业务负责人的责任；
• •高风险用例有影响评估、红队测试和人工监督；
• •Agent 使用最小权限、短期凭据和隔离执行；
• •有事件响应、Kill Switch、取证和通知流程；
• •定期复核偏见、隐私、安全和合规风险。

NIST AI RMF 用 Govern、Map、Measure、Manage 组织风险管理活动，并强调可信要求应进入 AI 产品的设计、开发、使用和评估过程。它是自愿性风险框架，不是成熟度认证。

运营与度量

看生产系统能否稳定运行，并用数据判断质量、成本和业务价值。

关键证据：

• •能追踪一次请求中的模型、检索、工具和 Agent 调用；
• •同时监控任务成功率、延迟、成本、安全和业务结果；
• •模型或数据变化后自动触发回归评测；
• •有容量、故障、降级、备份和灾难恢复方案；
• •能按模型、团队、用例和客户归集成本；
• •用户反馈和生产失败会进入下一轮改进。

AWS Generative AI Lens 将运营卓越、安全、可靠性、性能效率、成本优化和可持续性作为生产级生成式 AI 工作负载的主要支柱，也说明“能上线”与“能长期运营”是两回事。

AI-Native 五级成熟度

L1：工具试用

典型状态：个人或小团队自发使用通用 AI 工具，价值以体验和案例描述为主。

主要风险：影子 AI、敏感信息外泄、重复采购、把新鲜感当价值。

升到 L2 的门槛：选出少量低风险、高频场景；明确数据红线；建立基础培训；为试点定义业务指标和负责人。

L2：团队协作

典型状态：多个团队开展受控试点，形成初步模板、规范和案例库。

主要风险：PoC 很多但口径不同；团队各建一套 RAG、评测和权限逻辑。

升到 L3 的门槛：确认至少一批可重复产生价值的场景；沉淀共性平台；统一身份、数据、评测和发布标准；成立明确的能力责任团队。

L3：平台治理

典型状态：AI 从项目能力变成平台能力，团队在统一边界内自主交付。

主要风险：中心平台过度集中，变成审批瓶颈；标准很多，但开发体验差。

升到 L4 的门槛：平台服务达到可用性目标；策略可自动执行；核心用例能跨团队复用；单位任务成本和业务结果可持续度量。

L4：规模运营

典型状态：AI 能力进入多条核心业务流程，交付、治理和运营大部分标准化。

主要风险：规模放大错误；团队为了效率绕过门禁；模型和供应商变化造成系统性影响。

升到 L5 的门槛：建立跨业务反馈网络；能快速发现能力退化；可在受控条件下调整模型、流程和自治边界；组织结构和产品设计随 AI 能力共同演进。

L5：持续进化

典型状态：AI 参与产品和流程设计，组织通过实时证据持续调整人机分工、平台能力和商业模式。

L5 不是“完全自治”。恰恰相反，成熟组织更清楚哪些决策不能交给 AI，以及何时应该降低自主性。

与驾驭工程成熟度模型是什么关系

中国信通院云计算与数字化研究所发布《智能原生软件工程 驾驭工程能力成熟度模型》首批评估通知。评估对象是 AI 智能体在软件全生命周期中的驾驭工程能力。

它解决的是一个更具体的问题：企业能否为软件工程 Agent 建立“可接入、可治理、可执行、可观测、可回放、可迁移”的工程化运行环境。

六大能力域

六个能力域形成“接入—执行—运行—保障—度量”的闭环。官方标准支持企业按单项、多项或整体能力申报评估。

五级名称

1. •L1 工具接入级
2. •L2 运行底座级
3. •L3 治理闭环级
4. •L4 协同自治级
5. •L5 规模生产级

当前公开通知和架构图展示了等级名称，但没有公开每一级的完整判定条款。因此本文不根据名称自行补写认证条件，也不引用搜索引擎生成的等级解释。

两套模型不能直接替换

两套模型可以嵌套使用：先用本文六维模型判断企业整体短板；如果“工程与平台”是重点，再用信通院模型深入评估 Agent 的接入、编排、执行、安全和评估能力。这样既不会把软件研发成熟度误当成企业整体成熟度，也能避免组织级框架在工程细节上过于抽象。

如何评分：不要简单取平均值

建议每个维度按 1～5 分评分，并为每个分数保留证据链接、负责人和观察日期。不要只开会凭感觉打分。

推荐算法

1. •六个维度分别评分；
2. •计算平均分，观察整体位置；
3. •取最低分，识别短板；
4. •对治理与安全设置硬门槛；
5. •最终等级取“平均等级、最低维度门槛、治理门槛”中较低者。

例如，一家公司在战略、组织、数据、工程、治理、运营上的分数为：

4、3、2、4、2、3

平均分是 3，但不应直接判为 L3。数据和治理都停在 L2，继续扩大 Agent 权限会放大泄露和误操作风险。更合理的结论是：整体处于 L2，局部工程能力达到 L4。

评分证据模板

从试点到规模化的跃迁过程

选择高价值场景

先找结果缺口，不先找 AI 用法。适合起步的场景通常具备：高频、耗时、可度量、结果可复核、风险可控制。

不要只做“最容易演示”的场景。演示容易不代表值得长期运行。

验证业务结果

PoC 至少验证四件事：

• •技术上是否可行；
• •用户是否真的采用；
• •结果是否优于当前基线；
• •全量运行成本和风险是否可接受。

Microsoft 建议 PoC 与当前技能、数据和基础设施成熟度匹配，并用结果反向调整优先级和实施估算。

沉淀平台能力

当多个场景反复需要模型接入、RAG、身份、评测、审计和成本控制时，应把共性部分沉淀为平台服务。

平台的目标是减少团队认知负担，而不是制造新的工单队列。可优先提供：

• •模型与工具网关；
• •统一身份和密钥；
• •Prompt、Agent 和 Skill 注册；
• •数据连接与权限继承；
• •评测数据集和发布门禁；
• •Trace、成本和质量看板；
• •Sandbox 与高风险审批。

建立治理门禁

治理应根据风险分级，而不是所有项目走相同流程。

治理不能只写原则，必须转换为权限、Schema、测试、策略代码和发布门禁。

规模化运营

进入规模化后，重点从“能否做出来”转向：

• •质量是否随模型、数据和用户变化而退化；
• •成本能否归集到任务和业务结果；
• •故障能否降级、隔离和恢复；
• •经验能否快速回到平台和工作方式；
• •新能力是否通过小批量、渐进式方式上线。

然后重新选择下一批高价值场景，形成持续循环。

度量什么：从采用率走向价值率

采用率只能说明有人打开工具，不能说明组织变得更好。

建议建立四层指标。

采用与能力

• •目标用户周活跃率；
• •关键岗位培训与实战通过率；
• •使用共享平台交付的用例占比；
• •从想法到首次受控试点的时间。

质量与交付

• •任务成功率；
• •人工修订率；
• •引用或事实支持率；
• •AI 变更的交付周期、变更失败率和恢复时间；
• •回归评测通过率。

业务与用户

• •单任务处理时间；
• •转化率、解决率或差错率；
• •客户与员工体验；
• •单位流程成本；
• •AI 带来的增量收入或风险减少。

风险与运营

• •数据越权和高风险动作数量；
• •未审批工具调用数；
• •P95 延迟和可用性；
• •单次成功任务成本；
• •模型漂移、数据漂移和异常率；
• •事件发现、隔离和恢复时间。

指标应以“任务”为主语，而不是只看单次模型调用。相关方法可继续阅读《AI Agent 评测与可观测性》。

常见误判

“购买企业版工具就是 L3”

采购能解决接入速度，不能自动解决用例排序、数据质量、责任划分和价值度量。

“自研模型就是 L5”

技术控制权不等于组织成熟度。一个缺少治理、平台和反馈的自研系统，仍可能处于 L1 或 L2。

“Agent 越自主越成熟”

自主性应跟随风险控制能力提升。先扩大权限再补治理，通常会把局部错误变成业务事故。

“平均分达到 4 就是 L4”

成熟度受短板约束。数据、身份、安全或运营只有 L2 时，不应仅凭战略和工程高分进入规模化阶段。

“PoC 成功即可复制”

PoC 常使用精选数据、少量用户和人工兜底。规模化前还要验证峰值负载、长尾输入、权限边界、成本和故障恢复。

“建立 AI CoE 后，业务团队只负责提需求”

中心团队可以提供标准、平台和专家支持，但业务结果仍需业务负责人承担。否则平台会积累很多无人负责价值的功能。

一页式自评清单

如果下面大部分问题无法给出证据，组织可能仍停留在 L1～L2：

• •每个 AI 用例都对应一个业务结果和负责人；
• •有明确的用例停止机制；
• •员工知道哪些数据不能进入外部模型；
• •内部知识有来源、权限、版本和有效期；
• •Prompt、模型、工具和策略均可追踪版本；
• •上线前有代表真实场景的评测；
• •高风险动作经过独立策略或人工审批；
• •生产环境能追踪一次完整任务；
• •成本可以归集到用例或任务；
• •模型升级会自动触发回归验证；
• •系统支持降级、回滚、吊销和停机；
• •用户反馈能进入下一轮产品与平台改进。

Agent 权限、隔离和供应链风险可结合《Agentic AI 专项安全》进一步检查。

写在最后

AI-Native 成熟度衡量的不是企业拥有多少模型、Agent 和许可证，而是组织能否把 AI 转化为可持续的业务能力。

L1 解决“能不能用”，L2 解决“团队能不能协作”，L3 解决“能力能不能复用和治理”，L4 解决“能不能稳定规模化”，L5 解决“能不能根据证据持续重构业务与人机分工”。

真正可靠的升级顺序是：先证明价值，再扩大自主性；先补系统短板，再追求工具覆盖。

参考资料

• •DORA, State of AI-assisted Software Development 2025：https://dora.dev/research/2025/dora-report/
• •DORA, AI Capabilities Model：https://dora.dev/ai/capabilities-model/report/
• •Microsoft Cloud Adoption Framework, AI Strategy：https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai/strategy
• •Microsoft Cloud Adoption Framework, Plan for AI Adoption：https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai/plan
• •Microsoft Cloud Adoption Framework, Manage AI：https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai/manage
• •AWS Well-Architected Framework, Generative AI Lens：https://docs.aws.amazon.com/wellarchitected/latest/generative-ai-lens/generative-ai-lens.html
• •NIST AI Risk Management Framework：https://www.nist.gov/itl/ai-risk-management-framework
• •NIST AI 600-1, Generative Artificial Intelligence Profile：https://doi.org/10.6028/NIST.AI.600-1
• •中国信通院云计算与数字化研究所，《智能原生软件工程 驾驭工程能力成熟度模型》首批评估通知：https://mp.weixin.qq.com/s?__biz=MzU2OTM4MTU1Mg%3D%3D&mid=2247500785&idx=2&sn=d88ba2c561064a5f6e1112ecbe91a6f1