CPP-Summit 2025 结束之后，我把会上关于 AI 原生软件研发成熟度模型的内容重新整理了一遍，这篇算是学习笔记的第二篇。上一篇聊的是为什么 AI 原生不等于"在代码里接个大模型"，这一篇重点放在模型本身：成熟度到底分了几个层级，每个层级有什么典型特征，以及从低到高演进时真正起作用的杠杆是什么。
说实话，成熟度模型这个词在软件工程里不算新鲜，从最早的 CMM 到后来的 DevOps 成熟度评估，大家听得都快免疫了。但这次的内容不太一样——它不是把原来那套流程成熟度的框架换个皮，而是把"AI 作为一种新的研发参与者"这个事实摆进了模型里。也就是说，模型里的每一级，对应的不只是人、流程、工具这三个传统要素的成熟程度，还包括 AI 智能体在研发链路中的角色深度。
如果你正带着团队做 AI 研发转型，或者正在纠结"我们团队的研发流程到底算不算 AI 原生"，这篇文章应该能帮你对号入座。我尽量把会上听到的框架、自己回来后的验证实验、以及踩过的坑都写清楚。
1. 为什么非得搞一个"成熟度模型"出来
1.1 AI 原生不是"上 AI 工具"，而是研发范式的重组
先聊一个普遍误区。过去一年里我接触了不少团队，一说 AI 原生研发，第一反应就是先采购一套 AI 编程工具，让程序员用上代码补全，然后就宣布"我们进入 AI 时代了"。但用上 AI 编程助手，和 AI 原生软件研发，其实是两个层面的事。
打个比方。你给一个传统手工作坊买了几台电动工具，工人确实省力了，但整个生产流程还是靠人脑记忆、靠老师傅口口相传，出了问题还是靠经验排查——这不叫工业化，只是把榔头换成了电钻。真正的工业化，是把流程拆解、标准制定、质量检验、数据反馈这些环节全部结构化，让整个系统在没有人盯着的状态下也能稳定运转。
AI 原生软件研发也是这个逻辑。它不是"在某个环节塞一个 AI 工具"，而是让 AI 能力成为研发体系的基础设施：需求分析有 AI 辅助梳理，架构设计有 AI 参与推演，代码生成有 AI 承担大部分机械劳动，测试用例有 AI 自动补全，线上问题有 AI 辅助定位，甚至连发布策略都可以由 AI 基于历史数据给出建议。这样一种全链路、系统性的重组，才称得上范式转变。
1.2 没有度量就没有演进：模型的价值在于定位和规划
既然 AI 原生是一个渐进过程，那就必须有一套度量体系，让团队能回答两个问题：我们现在处在什么位置？下一步该往哪走？
成熟度模型的价值恰恰在这儿。它不是给你打分的考核表，而是一张路线图。比如有的团队，AI 已经深度参与了代码生成，但测试环节还是纯人工，那它大概率处于"流程重构期"和"智能协同期"之间的过渡地带。清晰定位之后，下一步的资源投入方向就明确了——去补测试链路的 AI 能力，而不是继续在代码生成上堆算力。
会上有一位分享者的观点我特别认同：成熟度模型是给团队用来"照镜子"的，不是用来"贴标签"的。研发团队的真实情况往往不是严格地属于某一级，而是不同维度处于不同层级。比如代码生成环节可能已经到了 L3 的水平，但需求分析环节还停留在 L1。这种"参差不齐"的状态反而是常态，正视它才能制定合理的演进策略。
2. 成熟度模型的分层拆解：从工具接入到组织进化
整个模型我按自己的理解重新组织了一下，大致可以分成四个阶段。每个阶段的核心差异不在于"用了多少 AI"，而在于 AI 在研发链路中扮演角色的大小，以及人和 AI 之间的协作方式。
2.1 L1 工具接入期：AI 是开发者的辅助工具
这个阶段的典型特征是：团队开始引入 AI 编程助手、AI 问答工具，但 AI 只是作为开发者的"外挂"，出现在局部环节。写代码时补全个函数，遇到报错时复制到对话框里问一下，偶尔让 AI 帮忙写个正则或者生成一段单元测试。
这个阶段的价值不可否认——开发者的日常效率提升是实实在在的，尤其对那种重复性、模式化的编码工作，AI 的补全速度远超人手。但问题也很明显：AI 的使用高度依赖个人习惯，产出质量不稳定。同一个工具，在有的人手里是利器，在有的人手里是鸡肋。而且这个阶段 AI 基本不参与工程链路，它不知道你在哪个分支上开发、测试跑没跑通、线上有没有告警，所有上下文都是靠开发者手动喂给它的。
如果用一句话总结 L1，那就是"人驱动 AI"。AI 是人在干活时顺手抓起的一把好工具，但整个研发流程本身没有发生结构性变化。
2.2 L2 流程重构期：AI 进入研发主链路
到了这个阶段，AI 不再是孤立的外挂，而是开始嵌入研发流程的固定节点。比如代码评审环节引入 AI 审查员，自动扫描变更代码的风格问题、潜在缺陷和安全隐患；测试环节引入 AI 用例生成器，基于代码变更自动生成单测和集成测试；CI 流水线里加入 AI 缺陷预测，根据历史数据预判这个变更的回归风险。
这个阶段的关键特征，可以用"AI 成为研发主链路中的固定节点"来概括。它不是可有可无的辅助，而是流程中一个明确的环节，有输入、有输出、有质量标准。
我自己在团队里试行 L2 时感受最深的是：一旦 AI 进入了固定节点，人的角色就自然往上游移了。以前代码评审是开发者自己逐行看，现在先让 AI 扫一遍，人只关注 AI 标记的高风险区域。以前测试用例想不全，现在 AI 生成的用例覆盖了很多边界情况，人反而可以把精力放在用例的有效性判断上。
L2 的挑战在于：AI 的输出质量必须有评估机制兜底。如果 AI 审查员扫完代码后给出几十条建议，但一半是误报，开发者就会对这个环节失去信任，最后变回纯人工审查。所以 L2 阶段有一个隐含前提——必须建立针对 AI 输出效果的度量。
2.3 L3 智能协同期：人与 AI 的深度协同
L3 是我觉得最有意思、也是描述起来最复杂的一个阶段。在这个阶段，AI 开始从"执行者"向"协作者"转变。代码的生成、测试的创建、缺陷的定位、甚至部分简单需求的拆解，都可以由 AI 自主完成，人类工程师则主要负责方向把控、复杂决策和最终审核。
举一个我在实验环境里跑通的场景：给定一个业务需求描述，AI 先进行需求拆解，生成用户故事和验收标准；然后基于拆解结果设计技术方案，生成接口定义和数据结构；再生成实现代码和对应测试；最后自动跑完检查。整个过程中，人的角色更像是一个"主编"，检查 AI 产出的内容是否符合业务预期、技术方案是否合理，而不是逐行写代码。
这个阶段的核心机制是"人机回环"。AI 产出方案，人质询挑战，AI 修改调整，人确认放行——这是一个高频率的协作循环，跟团队里两个工程师结对编程时的互动方式非常像。要实现这种深度协同，光有模型能力是不够的，还需要工程支撑：上下文管理、任务分解、步骤追踪、中间产物的版本管理，这些缺一不可。
2.4 L4 组织进化期：业务、产品、研发的 AI 原生重构
最高层级已经不只是研发环节的事了，它意味着组织层面的全面重构。需求和代码之间的转化可以自动进行，架构决策有 AI 基于组织资产给出建议，甚至产品方向的选择、功能优先级的排序，都可以借助 AI 从用户反馈和历史数据中挖掘信号。
这个阶段的研发组织呈现出一种新形态：小规模的"人机混合团队"就能承担原来一个大型研发部门的工作量。AI 负责大部分执行性、分析性工作，人聚焦在定义问题、评估结果和处置风险上。组织的中层管理结构会明显扁平化，因为 AI 承担的协调和信息传递工作变多了。
当然，能达到这个阶段的组织在目前是极少数，它需要的不只是技术能力，还有业务模式的适配。但作为演进方向，它提供了一个很有价值的参照系——至少我们知道终点大致长什么样。
为了便于对比，我把四个阶段的核心维度整理了一张表：
| 维度 | L1 工具接入期 | L2 流程重构期 | L3 智能协同期 | L4 组织进化期 |
|---|---|---|---|---|
| AI 角色 | 辅助工具 | 流程固定节点 | 协作者/智能体 | 组织级基础设施 |
| 人的角色 | 完全驱动 | 审核与排除误报 | 方向把控与最终决策 | 定义问题与处置风险 |
| 联动方式 | 人主动调用 AI | 流程自动调用 AI | 人机高频回环 | 组织级自动流转 |
| 核心指标 | 个人效率提升 | 单环节质量提升 | 端到端交付效率提升 | 业务响应速度提升 |
| 主要风险 | 使用率不均 | 误报/漏报影响信任 | 上下文管理与失控 | 组织适配与治理 |
表里最后一行我特别想说一下：L3 的"失控"风险是真实存在的。当一个 AI 智能体可以自主完成从需求到代码的一系列动作时，如果过程不可观测、结果不可追溯，出了问题就是灾难性的。所以我在实验环境里强制加了每一步的审核点，宁可慢一点，也要保证中间状态可审查。
3. 演进路径中的关键杠杆：数据、评估与反馈闭环
成熟度模型不是画出来贴在墙上就完事的，从 L1 往 L3 走，有三个杠杆起着决定性作用，也是我在实际推进中被反复教育过的环节。
3.1 高质量工程数据：第一生产力
AI 研发能力的根基是工程数据。"工程数据"这个词听起来很虚，说具体点就三类：代码库数据、缺陷数据、架构决策记录。
代码库数据是训练代码模型和微调专用模型的基础。但这里有个很关键的细节——不是所有代码都值得喂给模型。那些一次提交动辄上千行的"大泥球"、历史包袱极重的兼容层代码，喂给模型反而会把模型带偏。我筛选语料时用的标准是：代码整洁、命名规范、有配套测试、经过评审合入。这四条过滤下来，一个中等规模项目的有效语料可能只剩三分之一。
缺陷数据则是 AI 做缺陷预测、测试生成的基础。很多团队的缺陷记录散落在各个系统的回复里，状态、原因、修复方案都靠人去翻聊天记录，根本无法规模化使用。我建议团队把缺陷数据进行结构化整理，至少要有：缺陷现象、复现步骤、根因类型、修复变更、回归测试结果这五个字段。
架构决策记录（即 ADR）是 AI 能正确进行架构设计辅助的基础。没有历史决策依据，AI 给出的架构建议就是"通用水平"的，你可以从任何一本教科书里看到，毫无组织特定价值。
3.2 评估体系：定一把好用的尺子
AI 能力上线之前，必须有一个能判断"这个模型效果到底行不行"的评估体系，否则就只能靠感觉和演示效果来决定模型去留。
我的做法是维护一个离线评测集。从真实历史数据中抽出一批有代表性的任务，比如一段真实需求的代码生成、一组历史缺陷的定位、一批变更的审查意见，固定下来作为基准。每次候选模型或提示词策略更新时，先在评测集上跑一遍，对比输出质量的差异。
在线指标也不能忽视。模型上线后要持续观察三个数据：采纳率（AI 建议被开发者接受的比例）、修改率（建议被部分修改后使用的比例）、弃用率（开发者完全忽略的比例）。这三个数据能真实反映模型在生产环境的表现，比任何内部测试都可靠。
这里我想特别提一个容易忽视的评估维度——输出稳定性。很多模型在评测集上得分很高，但生产环境里同一个问题问两次，给出的答案相差很大。对研发场景来说，这种不稳定性是致命的，因为开发者无法建立信任感。所以在评估时，我建议对同一个任务用不同温度参数跑多次，评估结果的一致性，而不是只看单次的准确性。
3.3 反馈闭环：让 AI 越用越聪明
有了评估体系，就自然引出反馈闭环。AI 产出的结果被人接受或拒绝，这个信号必须能回流，成为模型优化的输入。
在实际落地中，反馈闭环最难的不是技术，而是人的习惯。开发者用 AI 生成的代码，发现有问题，默默修改完继续下一件事，不会想到去记录"这个问题 AI 是怎么犯的"；测试用例被 AI 生成后直接删掉，也不会反馈"为什么这个用例无效"。
我的做法是把这个环节做成轻量化的埋点，不依赖人主动反馈。比如在 IDE 插件里记录 AI 建议的显示、采纳、修改操作，在代码评审工具里记录 AI 审查意见的接受和驳回。数据模型里加一个字段而已，但对后续的效果优化帮助非常大。
另外，反馈闭环也要覆盖到数据侧。AI 生成的代码在线上出了问题，这类案例一定要被标记出来，作为反例进入语料。相当于给模型做错题本，而且这个错题本是持续更新的。
4. 从模型到平台：AI 原生研发的工程化底座
成熟度要往上走，光有模型能力远远不够，还必须有一套工程化底座来承载。这一章聊聊我搭建这套底座时的选型逻辑和踩坑记录。
4.1 模型接入层的教育成本与选型逻辑
模型接入是整个底座里最活泼、也最容易反复的一层。大模型技术迭代很快，几乎每几个月就有新的基座模型出现，如果团队架构把模型直接和业务代码强耦合，那成本灾难很快会到来。
我建议在模型接入层做统一抽象，所有 AI 能力的调用都走一个内部网关，业务侧不直接感知具体模型。这样做的好处很实际：换模型时不用改业务代码，只需要换网关背后的配置；可以做模型路由，简单任务走小模型降低成本，复杂任务才走大模型；还可以做统一限流、统一缓存、统一审计。
选型决策上，我的思路是"混合使用"。大部分高质量编码场景，用小模型就够用了，速度快、成本低、结果稳定；只有需求拆解、架构推演这种复杂推理场景，才用大模型；而针对团队特定代码风格的场景，比如指定框架的代码生成、私有 API 的调用建议，自建微调模型反而比通用大模型效果好。
给个小建议：不要一开始就在自建微调模型上投入太多。先把通用模型的能力吃透，跑通流程，确认某个环节确实是模型能力的瓶颈，再考虑微调。很多团队在通用模型还没用好时就急着训练专属模型，花的成本很高，效果提升却很有限。
4.2 工具链打通：从需求到发布的可观测链路
AI 原生研发的底座，核心在于把需求管理、代码托管、CI/CD、测试、监控这条链路的工具全部打通，让数据在各个环节之间自动流转。
操作系统层面的集成程度直接决定 AI 能拿到的上下文质量。如果 AI 只看到 IDE 里的几十行代码，看不到这个需求的来龙去脉，看不到当前分支的测试状态，看不到线上相关服务的告警情况，那它的输出质量必然受限。反过来，如果上下文足够完整，AI 能做出很多让人惊喜的决策。
打通工具链的过程中，我踩过最大的坑是"为打通而打通"，即过度集成导致系统复杂度过高，维护成本甚至超过了使用收益。后来我调整了策略：先不追求全链路自动化，而是确保每个环节的产物可以追溯、可被 AI 消费。比如 CI 构建产物和对应代码版本的关联关系必须先建立，测试结果和代码变更的关联关系必须先建立，这些基础数据打通了，后续的 AI 能力才有用武之地。
5. 落地踩坑记录：从"演示惊艳"到"生产可用"的距离
学习成熟度模型的过程中，我在仿真项目上做了一系列验证性实验，就是从需求描述到代码生成全链路跑通的那套流程。实验结果和我想象有不少差距，这些差距恰恰是成熟度演进中最真实的阻力。
5.1 踩坑一：上下文管理是最大短板
第一个大坑是上下文窗口的管理。自动拆解需求后，AI 要同时记住需求描述、技术约束、已有代码结构、生成的接口定义、测试要求等一堆信息，很快就把上下文窗口撑满了。一旦上下文溢出或关键信息被截断，AI 的产出质量就会剧烈下降。
后来我学到的处理方式是任务分解和上下文精简。把一个大任务拆成多个子任务，每个子任务只携带自己需要的最小上下文；把对话历史摘要化，而不是每次都回传完整对话记录；把代码库的关键结构抽成"地图"信息喂给模型，而不是直接填代码全文。
5.2 踩坑二：测试用例生成的"假绿陷阱"
第二个坑出在测试环节。AI 生成测试用例时经常会出现一种情况——测试通过了，但实际上是"假绿"，断言写了等于没写。比如断言一个 mock 对象的方法被调用，却忽略了真实返回值是否符合预期；比如断言目标函数返回了一个非空对象，但没校验内容是否正确。
这个问题极难在验收时发现，因为 CI 是绿的，代码覆盖率数值也不错，但实际上测试质量很低。我最后的做法是引入变异测试思想：故意向被测试代码注入缺陷，然后看测试是否能发现它。AI 生成的测试如果连注入缺陷都测不出来，说明它的断言根本没有捕获核心逻辑的能力。
5.3 踩坑三：工程师群体的心智与习惯迁移
技术和工具层面的坑相对好填，真正难的是人的习惯。我在推进 AI 原生研发流程时，遇到的问题不是工程师不会用 AI，而是不信任 AI。
这种不信任有合理成分——早期确实误报率高、输出不稳定；也有心理因素——很多工程师把"自己写出每一行代码"当作职业尊严的一部分。硬推是不行的，我后来采取的策略是"渐进式托管"：先让 AI 承担最烦人的活，比如脚手架代码、胶水代码、文档生成；用一到两个月的正向体验建立信任；再逐步扩大到核心业务逻辑，让 AI 承担更重的任务。
测试下来，工程师对 AI 的信任大致要经历三个阶段：怀疑期、可用期、依赖期。怀疑期靠高质量的小任务破冰，可用期靠持续的正向反馈积累，依赖期开始后，整个团队的交付速度会有一次肉眼可见的跃升。
6. 一些个人的观察与思考
在这篇的最后，分享几个我从这次学习中得到的思考。
第一，成熟度不是越高越好。我见过一些团队，业务还在快速试错阶段，需求每周都在变，硬往里套 L4 级的高度自动化流程，结果反而是流程负担压过了效率收益。组织自身的稳定度是成熟度演进的前提，业务稳、需求相对明确的场景，才值得投入资源建设深层次的 AI 原生能力。
第二，模型能力的演进会让这张"地图"不断变化。随着上下文窗口扩大、推理能力增强，原来 L3 阶段需要人介入的很多决策点，可能会逐步交由 AI 处理。我倾向于把这个模型理解成一个动态的参考系，而不是静态的等级表。
第三，对一线工程师来说，最值得投入的方向不是学习某个具体的 AI 工具，而是培养一种"和 AI 协作"的思维方式——定义问题、分解任务、校验结果、修正方向。这套能力在任何一个成熟度阶段都用得上。
最后分享一个我在实践中沉淀的小技巧：每周固定挑一个真实的、有典型性的开发任务，让 AI 全流程走一遍，然后复盘它卡在哪儿、错在哪儿、哪些环节需要人提前介入。持续做一段时间后，你会对自己团队当前所处的位置——以及下一步往哪儿走——心里非常有数。
