AINMM：存量生产级工程向 AI Native 演进的五级成熟度模型

前言

副标题：AI Native Maturity Model (AINMM) — 定义文档 v1.0

本文的写作契机，源于公司在年度战略会上，管理层对全集团提出的 AI Native 战略要求。讲话中，将 AI Native 定义为组织形态升级的核心标准：任何应用、任何任务，都必须拆解到全链路 AI 驱动的流程中；Agent 与 Agent 之间通过标准化的协议和上下文进行交互，而非靠人工开会串联；最终目标是实现10倍级的生产效率跃迁，让产品具备“每天一个版本”的迭代能力。这一要求不仅指向从零开始的 Agentic 原生项目，更关键的是——如何让我们大量随业务发展沉淀下来的存量生产级工程，逐步演进为 AI Native 工程。

在实践层面，我们团队一方面在 Agentic 原生项目中已经积累了较为成熟的 AI Native 经验；另一方面，也切身感受到存量工程转型的复杂性与特殊性。不同于0-1就是Agentic的项目，这些工程往往具有以下特征：工程面向人开发和维护，缺乏面向 AI 的上下文环境与执行约束；生产级稳定性要求高，任何改动都需要经过严格的回归与验证；端分离明显、系统组成复杂，不少项目横跨多个组织、涉及多端（前端、后端、移动端等）交付；需求长期处于持续迭代状态，不能承受"停下来重构"的成本。正因如此，存量工程的 AI Native 转型不能完全照搬新项目的AI Native方式，它需要一套可测量、可比较、可指导的渐进式框架——告诉团队"现在在哪""缺口是什么""下一步该做什么"。

本文提出的 AI Native 能力成熟度模型（AINMM：AI Native Maturity Model），正是基于上述背景，结合 Vibe Coding、Spec 驱动开发以及 Harness Engineering实践和思考后，所形成的一套评估与提升框架。模型中的每一个等级定义、每一条实践路径、每一组度量指标，源于所维护的两个生产级项目在向 AI Native 演进过程中的真实踩坑与阶段性沉淀。

最后需要说明的是：没有一种范式是银弹。AINMM 提供的是一个通用参考框架，而非必须逐字照搬的标准答案。不同团队的业务特点、技术债规模、人员情况各不相同，在实际落地时，需要结合改造 ROI 和团队现状进行裁剪与适配。欢迎大家反馈与实践补充，一起推进存量项目向AI Native转型，我也会持续实践并结合踩坑经验持续打磨这个通用框架，让这个框架在真实的工程土壤中不断进化。

AI Native 能力成熟度模型（AI Native Maturity Model，简称 AINMM）是一套用于评估和指导软件工程组织在 AI 原生研发范式下成熟程度的结构化框架。它借鉴了 CMMI（Capability Maturity Model Integration，能力成熟度模型集成）的核心思想，针对"AI Agent 参与软件研发全生命周期"这一新工程范式，定义了五个成熟度等级（ML1—ML5），以及每个等级需要达成的目标、关键过程域、度量标准和提升路径。模型假设组织已引入 AI 参与研发过程，评估的是"AI 参与的深度和工程化程度"，而非"是否引入 AI"。

▐  为什么需要 AINMM

当前行业面临一个结构性矛盾：AI 的代码产出能力在快速增长，但团队的端到端交付效率并未同步提升。随着AI的发展越来越快，尽管部分统计数据存在滞后性，但为了体感更量化，我和AI整理了下面几组可供参考的数据进行说明。Sonar 2025 年度报告显示全球新增代码中 42% 由 AI 辅助生成[1]，GitClear 2025 年研究指出代码搅动率（代码被频繁修改、删除或重写的程度）近乎翻倍、重复代码增长近四倍，开发者 Review 时间首次超过编写时间[2]。Stack Overflow 2025 开发者调查进一步显示，84% 的开发人员已在使用或计划使用 AI 编码工具，但仅有 29% 表示信任 AI 产出，信任度较上年下滑 11 个百分点[3]。OpenAI 在 2026 年初正式将这个缺口定义为 Harness Gap[4]。

问题在于：大多数组织对自身的 AI 协作能力缺乏客观、可量化的评估手段。团队的状态描述往往是模糊的——"我们在用 AI"、"效率提升了一些"、"AI 替代了 XX% 的工作"——这些说法既无法横向比较，也无法指导改进方向。

AINMM 的目标就是把这些模糊感知变成可测量、可比较、可指导的工程框架，让组织能够：

1. 准确定位当前 AI Native 能力所处的成熟度等级

2. 明确差距识别当前等级与目标等级之间的关键能力短板

3. 规划路径获得从当前等级提升到下一等级的具体改进路线

4. 度量进步用客观指标跟踪改进效果

5. 横向对标在组织内部不同团队之间建立统一的评估语言

▐  适用范围与局限性

适用范围：AINMM 主要面向具备一定规模和复杂度的软件研发组织——典型画像是拥有多人以上研发团队、维护至少一个生产级系统（数百个源文件以上）、使用 CI/CD 流程的团队。技术栈不限（Java、Python、Node、Go 等均适用），部署环境不限（云原生、传统 IDC、混合部署均可）。

已知局限：第一，AINMM 当前版本基于作者实践基础上，结合AI对阿里组织内部和开源社区的提炼，在跨行业（航空航天、医疗设备、嵌入式系统）等领域的适用性尚未知。第二，模型假设已具备基本的版本控制和 CI/CD 基础设施——对于尚未建立这些基础的组织，需先补齐传统工程能力再评估 AI Native 成熟度（即没有设定ML0，保留5级与CMMI形成参照）。第三，五维度评分标准在评分颗粒度上仍有提升空间（详见第六章评估方法），不同评估者之间可能存在一定的主观偏差，这部分可以由具体团队、具体项目在通用框架基础上进行差异化定制。第四，框架评估脚本按照通用习惯和个人喜好进行命名，因此可能存在脚本评分偏差（例如工程真实存在AI上下文文件，但非AGENTS.md格式则同样不计分）。

▐  目标读者

本文面向以下角色，不同读者可按需选择阅读路径：

技术 Lead / 架构师——本文的核心读者。关心"怎么系统性地把 AI 融入团队的日常研发流程"，建议通读全文，重点关注第三章（五级定义）、第五章（提升路径）和第六章（评估方法）。拿到文章配套的 Evolution Kit 工具后，可以直接用 audit.sh 对你的项目做第一次评估。

具体开发者——关心"AI 协作到底怎么干、有没有可执行的东西"，建议先看第三章的 ML1-ML2 定义了解起步标准，然后跳到第五章 5.1-5.2 看具体操作步骤。配套代码库中的 init-workspace.sh 和 evolve.sh 可以帮你快速搭建 AI Native 基础设施。

研发总监（AI YY）——关心"怎么量化团队的 AI 能力、怎么横向比较、投入产出比"，建议重点看第一章（为什么需要 AINMM）、第四章（等级总览）和第七章（模型价值）。成熟度等级和雷达图评分可以直接用于组织级的对标和汇报。

AI 基础设施开发者——关心"怎么让自己的 AI 工具/基础设施更好地融入企业研发流程"，建议看第二章基本思想，以及第三章中各等级的过程域要求——你的工具/基础设施应该帮助用户向更高等级进阶。

▐  配套工具：AI Native Evolution Kit

本文定义了 AINMM 的理论模型，而 AI Native Evolution Kit 是该模型的工程实现——一套开源的命令行工具框架，支持从评估到生成到持续进化的全链路操作。

# 克隆工具框架git clone :top/ai-native-evolution-kit.git# 审计你的项目（输出五维度评分 + ML 等级）./audit.sh /path/to/your-project --detail# 一键初始化 AI Native 工作空间./init-workspace.sh# 深度分析 + 生成 Harness 五层基础设施./evolve.sh /path/to/your-project --output /path/to/workspace

文章中涉及的所有概念——五大过程域（PA1-PA5）、五个评估维度（D1-D5）、成熟度等级（ML1-ML5）、8 阶段 SOP——目前均与代码库的命名和逻辑保持一致，统一维护。

▐  AINMM 与 CMMI 的关系

AINMM 是 借鉴CMMI 思想在 AI Native 研发领域的探索应用[5]，为了实现这一目标，尝试定义二者的关系，如下：

关键继承：CMMI 的"逐级递进、每级是下一级基础"原则完整保留——ML1 是 ML2 的基础，ML2 是 ML3 的基础，不存在跳级的捷径。AINMM 与 CMMI 保持相同的五级结构，模型假设组织已引入 AI 参与研发，ML1 作为起始等级评估 AI 协作的初始工程化水平。

AINMM 的核心设计哲学可以用三句话总结：

第一，Harness 比 Agent 更重要。 模型在快速迭代发展，今天的限制明天可能消除，今天的提示词可能在明天模型升级后更简单。但 Harness是稳定的控制面，不依赖特定模型。AINMM 评估的不是"用了多先进的 AI 模型"，而是"为 AI 搭建了多完善的工作环境"。

第二，信任是可以工程化的。 不需要全信 AI 或全不信 AI。通过上下文工程、能力集成封装、验证回路、协作契约和自进化机制，信任可以被分级、被验证、被逐步释放。AINMM 的每个等级本质上都是在回答"这个组织在多大程度上能安心地把工作交给 AI"。

第三，成熟度是渐进式的螺旋上升，尤其在存量生产应用中，不是 big bang 式的跃进。 每一级独立有价值，可持续叠加优化。我们不需要"等条件成熟"再开始，从 AGENTS.md 或者一个wiki开始就是一个有价值的起点。

仿照 CMMI 的双表示法设计，AINMM 提供两种互补的评估视角：

阶段式表示法（Staged Representation）——组织整体成熟度等级。将组织的 AI Native 能力整体评定为 ML1—ML5 中的某一级，适用于组织级别的对标、汇报和战略规划。等级判定规则：取最低满足的等级——即所有关键过程域都达标的最高等级。

雷达图式表示法（Radar Representation）——五维度独立评分。对五大过程域（上下文工程 D1、能力封装 D2、验证回路 D3、协作契约 D4、自进化 D5）分别独立评分（每维度 0-20 分，总分 0-100 分），适用于识别具体短板、制定针对性改进方案。一个项目可能 D1 得 16 分但 D3 只有 4 分——雷达图能精确呈现这种不均衡。

两种表示法的关系：阶段式等级由雷达图评分推导。当五个维度的得分都满足某一等级的阈值要求时，该等级才成立。

AINMM 将 AI Native 研发能力分解为五大过程域（Process Area，PA），每个过程域对应 Harness 五层架构中的一层：

每个过程域包含：特定目标（Specific Goals，SG）、特定实践（Specific Practices，SP）、通用目标（Generic Goals，GG）和度量指标（Metrics）。

一句话定义：已认识到 AI 开发的价值，开始建立基础上下文，同样的领域内容不用重复告诉AI，AI 能"认识"项目但尚无可控的执行能力。

典型特征：

• 项目具备 AGENTS.md 或等效的结构化上下文文档，AI Agent 能理解项目的基本结构

• 上下文文档遵循"地图而非手册"原则——控制在 200 行内，索引指路而非面面俱到

• 关键编码规范、架构约定、禁止事项已落入仓库文档，不再纯靠口口相传

• AI 的使用仍然是"辅助模式"——人写需求、AI 补全或生成片段、人全程审查

• 没有形成标准化的 Skill，AI 的行为不可预测和复制

五维度基准分：D1≥8, D2

关键过程域要求：

通用目标：GG1——AI 能"认识"项目，不需要人在对话框中反复补充背景，节省人的时间和交接成本。

度量指标：

判定标准：PA1 的所有特定目标和特定实践已达成，AI 能正确理解项目全貌。

一句话定义：AI 的执行能力被结构化封装为可复用的 Skill，产出通过自动化门禁验证，AI 从"辅助工具"进化为"可管理的执行者"。

典型特征：

• 高频操作被封装为标准化 Skill（SKILL.md），定义了触发条件、执行步骤、验证标准和已知陷阱

• AI Agent 执行时调用对应 Skill，行为可预测、可复制

• 建立了基础的自动化验证门禁（至少覆盖编译检查和架构约束验证）

• AI 产出不再完全依赖人工 Review，门禁系统承担了一部分质量保障

• 经验开始沉淀到 MEMORY.md 和 known-bad-patterns，但尚未系统化

• AI 能"触达"生产系统——如协议桥、API 网关等基础设施就位

五维度基准分：D1≥12, D2≥8, D3≥8, D4

关键过程域要求：

通用目标：GG2——AI 的核心操作可预测、可复制、可验证。

度量指标：

判定标准：PA1 和 PA2 的所有特定目标已达成，PA3 的基础门禁已就位。

一句话定义：人机协作边界通过契约式设计明确定义，AI 在约定的范围内可自主执行，组织级标准流程形成。

典型特征：

• 协作契约通过 Design by Contract 原则定义——前置断言、后置断言、不变式

• 置信度路由机制运行——高置信度任务（>90%）自动推进，中置信度（60-90%）标记审查，低置信度（30-60%）暂停等人，极低置信度（

• 8 阶段协作 SOP 标准化运行（目标收敛 → 状态恢复 → 上下文装配 → 任务分块 → 链路设计 → 执行前校准 → 外部验证 → 回写）

• 验证门禁覆盖全链路（编译 → 架构 → 单元测试 → 集成测试 → 端到端验证）

• 知识资产化开始系统化——执行过程中的知识自动沉淀（不依赖人工记忆）

• AI 协作流程在组织层面标准化——不同团队遵循相同的基本框架

五维度基准分：D1≥16, D2≥12, D3≥12, D4≥10, D5

关键过程域要求：

通用目标：GG3——人机协作边界清晰，AI 在约定范围内可自主运行，异常时按协议升级。

度量指标：

判定标准：PA1-PA4 的所有特定目标已达成，PA5 有初步实践但不作为硬性要求。

一句话定义：AI 协作过程实现数据驱动的量化管理，自进化机制开始运行，关键指标可预测。

典型特征：

• 所有关键指标（Gate 通过率、Review 修改率、AI 自主完成率、举手频率等）持续采集和监控

• 自进化机制从被动积累（Level 1）进化到主动优化（Level 2-3）——定期 Skill 审查 + 离线优化

• 自进化与主运行时严格解耦——运行时产生轨迹，离线进化器分析优化，人工确认后写回

• 量化目标驱动优化——不再是"感觉变好了"，而是"Gate 通过率从 70% 提升到 85%"

• 对抗式审查机制运行——AI 审 AI（Critic Agent），加上橡皮图章检测（大 diff + 零 issue = 可能走过场）

• Evolution Kit 等标准化工具在组织内推广使用

五维度基准分：D1≥18, D2≥16, D3≥16, D4≥12, D5≥8（总分约 70-85 分）

关键过程域要求：

通用目标：GG4——AI 协作过程可量化、可预测，进化受控且有数据支撑。

度量指标：

判定标准：PA1-PA5 的所有特定目标已达成，关键指标实现持续量化跟踪。

一句话定义：AI Native 能力实现组织级持续优化，进化成果可复制到新项目，组织形成自我演进的 AI Native 生态系统。

典型特征：

• 低风险进化自动生效（如 Gotchas 追加、MEMORY.md 精炼），高风险进化经人工确认

• 个体项目的进化成果可复制——例如挽单优化出的 patterns、Skill、阈值、最佳实践能复用给下一个项目

• Evolution Kit 形成"双螺旋"——目前在做的尝试之一，借助个体项目进化反哺通用框架，通用框架升级支撑新项目

• 虚拟 Monorepo 开始运行——AI 的上下文从代码仓库扩展到业务文档、产品文档、设计文档、测试文档、线上运维信息，构建统一的、版本化管理的真相源

• 组织具备"在飞行中换引擎"的能力——新项目通过 Kit 快速搭建 Harness，存量项目渐进式进化

• AI Native 能力成为组织级资产——不依赖个人，人员轮岗不影响 AI 协作能力

五维度基准分：D1≥18, D2≥18, D3≥18, D4≥16, D5≥16（总分约 86-100 分）

关键过程域要求：

通用目标：GG5——组织级 AI Native 能力持续自我优化，形成可复用、可演进的系统。

度量指标：

判定标准：ML4 全部达成 + 跨域能力的所有特定目标已达成，具备自我演进和知识遗传能力。

ML5 ┃ 持续优化级 │ Self-Evolving          │ 进化可遗传，组织级持续创新    ┃ Optimizing │                       │ AI Native 成为组织级资产━━━━╋━━━━━━━━━━━┿━━━━━━━━━━━━━━━━━━━━━━━┿━━━━━━━━━━━━━━━━━━━━━━━━━━━ML4 ┃ 已量化级   │ Measured & Controlled │ 数据驱动，自进化受控运行    ┃ Quant.Mgd  │                       │ Critic 审查━━━━╋━━━━━━━━━━━┿━━━━━━━━━━━━━━━━━━━━━━━┿━━━━━━━━━━━━━━━━━━━━━━━━━━━ML3 ┃ 已定义级   │ Proactive             │ 契约式协作，置信度路由    ┃ Defined    │                       │ 组织级标准流程形成━━━━╋━━━━━━━━━━━┿━━━━━━━━━━━━━━━━━━━━━━━┿━━━━━━━━━━━━━━━━━━━━━━━━━━━ML2 ┃ 已管理级   │ Managed               │ Skill 封装 + 基础门禁    ┃ Managed    │                       │ AI 行为可预测可复制━━━━╋━━━━━━━━━━━┿━━━━━━━━━━━━━━━━━━━━━━━┿━━━━━━━━━━━━━━━━━━━━━━━━━━━ML1 ┃ 已感知级   │ Aware                 │ 上下文就位，AI 认识项目    ┃ Aware      │                       │ 仓库即真相源━━━━┛           │                       │

核心行动：Context Day——建立项目的结构化上下文，让 AI 对项目建立系统认知，构建项目 truth source。

具体步骤：

1. 创建 AGENTS.md（~100-200 行）：包含项目概览、技术栈、目录结构、包结构注释、关键编码约定、本地开发流程、禁止事项。遵循"地图而非手册"原则——只做索引和指路，详细内容放 docs/ 目录。

2. 建立 docs/ 目录：将口口相传的编码规范、架构约定、中间件使用说明落入文档。不追求完美，先覆盖"AI 不知道就会写错"的关键知识。

3. 信息分级判断：对每条知识问自己——"AI 不知道这个会写错？还是只是写不够好？"前者放 AGENTS.md，后者放 docs/ 链接。

4. 验证：让 AI 读完文档，问三个问题——"这个项目做什么？特定的领域知识是什么？哪些事不能做？"如果回答正确，ML1 达标。

预期耗时：借助AI约0.5d。

常见障碍与对策：

核心行动：Skill Sprint + Gate Sprint——在演进中持续封装完善核心 Skill 并建立基础门禁。

具体步骤：

1. 识别 Top 高频操作：梳理AI 反复被要求做的事情（如：新增 API、新增数据库字段、代码审查）。

2. 封装第一批 Skill：为每个高频操作创建 SKILL.md——定义触发条件（什么时候用这个 Skill）、执行步骤（做什么）、验证标准（怎么确认做对了）、已知陷阱（Gotchas）。

3. 建立基础门禁：至少覆盖编译检查（Gate 1）和架构约束验证（Gate 2）。关键是报错信息质量——"什么规则违反了 + 为什么是问题 + 怎么修"。

4. 建立基线：对存量项目，先记录已有问题，只报新增 issue。

5. 启用 MEMORY.md：每次踩坑后记录"发生了什么 → 根因是什么 → 怎么解决"。

6. 验证：用 AI 完成一个小需求，走通"Skill 调用 → 代码生成 → 门禁验证 → 人工 Review"全流程。

预期耗时：天级别，不用硬做，日常中抽象复用。

关键里程碑：AI Agent 能以可预测、可复制的方式完成至少一类标准操作，且产出通过自动化门禁验证。

核心行动：Contract Sprint——周级别，在日常需求迭代中探索并建立人机协作的正式契约。

具体步骤：

1. 引入契约式设计：为 AI 执行流程定义前置断言（开始前复述目标）、后置断言（完成后用外部证据验证）、不变式（外部 Spec 不可篡改）。

2. 部署置信度路由：定义四级分流规则——高置信自动推进、中置信标记审查、低置信暂停等人、极低置信拒绝执行。初始阈值可以保守，后续基于数据校准。

3. 标准化 8 阶段 SOP：在团队中推行统一的协作流程——目标收敛 → 状态恢复 → 上下文装配 → 任务分块 → 链路设计 → 执行前校准 → 外部验证 → 回写。

4. 定义偏航检测信号：当 AI 出现以下行为时触发预警——绕过阶段目标直接谈总目标、跳过中间产物直接改代码、用主观语气替代客观证据、混淆阶段完成和全局完成。

5. 完善验证门禁：从 Gate 1-2 扩展到 Gate 1-4 全链路（Gate 1 编译 → Gate 2 架构 → Gate 3 单元测试 → Gate 4 集成测试与端到端验证）。

6. 验证：团队成员能按照 SOP 独立使用 AI 完成一个中等复杂度的需求，全过程走通契约式验证。

预期耗时：周维度沉淀，具体时间不详，供参考。

常见障碍与对策：

关键里程碑：团队对 "什么时候不用管 AI、什么时候必须介入"有清晰的、共识性的答案。从模糊到逐步清晰。

核心行动：Metrics Sprint + Evolution Sprint——月维度探索沉淀（听起来都AI还需要月维度么？实际上，如果我们不建立这种量化度量体系，信不信几个月后我们的老项目还是原地踏步，这里不是要快，而是要稳稳地演进，无需过度投入），建立量化度量体系并启动自进化机制。

具体步骤：

1. 建立指标采集基线：开始系统性采集 Gate 通过率、Review 修改率、AI 自主完成率、举手频率、Skill 调用频次等关键指标。

2. 引入 Critic Agent：部署 AI 审 AI 的对抗式审查机制，配合橡皮图章检测（大 diff + 零 issue = 可能走过场）。

3. 建立进化元约束：所有控制面文本 Git 版本化、每次进化附带证据链、优化先在低风险任务验证。

4. 校准置信度阈值：基于历史数据调整路由阈值，使 AI 自评置信度与实际通过率趋于一致。

5. 验证：关键指标连续 3 个 Sprint 稳步提升。

预期耗时：融入月维度需求迭代。

常见障碍与对策：

关键里程碑：能用数据回答"我们的 AI 协作能力提升了多少"。

核心行动：Ecosystem Sprint——月维度逐渐实现进化成果的跨项目复用和生态建设，通用能力某种程度上能推动组织基础设施完善。

具体步骤：

1. 提取 Evolution Kit：将当前项目的通用 Harness 骨架（~70%）抽取为可复用的工具包。

2. 在新项目验证 Kit：选 2-3 个新项目使用 Kit 快速搭建 Harness，验证达到 ML2 的时间 ≤3 天。

3. 建立反哺机制：新项目的进化成果（patterns、Skill、阈值）回流到 Kit，Kit 升级再惠及其他项目——形成"双螺旋"。

4. 启动虚拟 Monorepo：从单仓 AGENTS.md → 跨域 router.md → 全链路知识图谱，让 AI 的上下文从代码扩展到产品/设计/运维。

5. 建立 AI Native 实践社区：跨团队分享进化成果、交流最佳实践、统一升级框架。

6. 验证：人员变动或引入新人后 AI 协作能力下降 ≤10%，新项目达标时间持续缩短。

预期耗时：-。

关键里程碑：AI Native 能力成为组织级资产而非个人技能——人走了，Harness 还在，且越来越好。

AINMM 采用 AINA（AI Native Assessment）评估方法，参考 CMMI 的 SCAMPI 方法设计，包含三类评估：

每个维度 0-20 分，总分 0-100 分。

D1 上下文工程（0-20 分）：

D2 能力封装（0-20 分）：

D3 验证回路（0-20 分）：

D4 协作契约（0-20 分）：

D5 自进化（0-20 分）：

注："—"表示该维度不作为该等级的硬性要求，但得分越高越有利于向更高等级进阶。总分范围仅为各等级的典型区间，非硬性上限或下限——实际判定以各维度最低分阈值和过程域达成情况为准。

等级判定规则：等级判定需同时满足两个条件：（1）各维度得分达到上表对应等级的最低分阈值；（2）该等级要求的关键过程域特定目标（SG）全部达成。任一条件不满足则判定为较低等级。两个条件的关系是"AND"——分值达标但过程域未落地不算数，过程域落地但分值不达标也不算数。

客观定位：消除"我们在用 AI 所以很先进"的模糊感知，用数据准确定位当前水平。一个 D1=16、D2=14、D3=6、D4=4、D5=2 的项目，能立刻看出"上下文做得不错但验证和协作严重缺位"。

精准补短板：雷达图式评分让团队能识别具体维度的短板，而不是笼统地"我们要提升 AI 协作能力"。把资源和注意力集中在得分最低的维度上，边际效益最大。

规划路径：每个等级提升都有明确的步骤、预期耗时情况和关键里程碑，团队可以根据情况选择提升计划。

统一语言：不同团队可以用同一套标准比较和交流——"你们到 ML 几了？哪个维度最弱？"取代了"你们 AI 用得怎么样？感觉效率提升了吗？"

资源配置：组织可以根据各团队的成熟度等级分配支持资源——ML1 的团队需要培训和工具支持，ML3 的团队需要平台基础设施（如 Evolution Kit、Critic Agent），ML5 的团队可以作为 AI Native 老师辅导其他团队。

衡量 ROI：AI Native 投入的回报可以用等级提升和指标改善来衡量，而不是用"AI 帮我们写了多少行代码"单一指标衡量。

我愿假设它为系统性推进 AI Native 转型的重要抓手：我个人阶段性实践下来，我认为AI Native 不是口号，而是需要业务与技术深度融合的系统工程。基于“统一语言”实现对齐、“资源配置”提供平台通用支撑、“ROI 衡量”验证成效，组织得以将零散的 AI 实践整合为一条清晰的演进路径——从局部试点走向全域智能。因此，这一框架不仅是评估工具，更是驱动组织向 AI Native 终极目标系统性迈进的参考框架。

标准参考：为行业提供一个存量系统 AI Native 进化的参考框架。CMMI 为传统软件过程提供了通用语言，AINMM 试图为 AI Native 研发范式做同样的事。

渐进路径：打消"条件不够好所以不做 AI Native"的顾虑——从 AGENTS.md 开始就是一个有价值的起点（ML1），每一级独立有价值，不需要等到"一切就绪"。

挽单系统是公司内一个典型的存量生产级 Java 系统：千余个 Java 文件，基于内部微服务框架 + RPC + 分布式数据库中间件 + 消息队列 + 配置中心的技术栈，承载售后挽回相关业务。已有 6 个 Qoder Skills、2 个 Agent 平台技能、182 行 MEMORY.md 经验沉淀。

选择我所挽单系统作为 AINMM 的"试验田"，并且我希望通过具体案例沉淀一套具备一定通用性的框架，复用到其他应用场景。该工程对于公司内一些存量生产级工程也具代表性——它集中体现了存量工程向 AI Native 演进的典型挑战：

• 工程面向人开发和维护，缺乏面向 AI 的系统性上下文环境与执行约束

• 生产级稳定性要求高，任何改动都需要经过严格的回归与验证

• 端分离明显、系统组成复杂，横跨多个组织、涉及多端（前端、后端、移动端等）交付

• 需求长期处于持续迭代状态，无法"停下来重构甚至重写"

更重要的是，我把挽单的演进过程本身当成 AINMM 框架的"孵化器"。我不是先写好框架再去套案例，而是在 Harness 思想指导下，一边改造挽单、一边提炼模式、一边沉淀框架——案例驱动框架，框架反哺案例。

第一，原点是什么？ 不是"让 AI 帮我写代码"，而是"让 AI 成为研发流程的正式参与者"。这意味着 AI 不再是工具，而是需要被管理、被约束、被度量的"数字员工"——例如：产品需求文档格式、术语等不统一，过去需要先"翻译"成技术语言给到AI，通过上下文、spec让AI Coding；现在我把原始需求直接丢给 AI，一旦发现还需要我充当"翻译"，就立刻意识到这里缺了一层面向产品的 Spec 约束——从而反向推动产品按规范输出结构化需求，AI 直接基于 Spec 开发。再比如，我不再手动提交代码部署，而是让 AI 帮我完成整个交付链路，差工具就补工具，缺少 CI/CD 领域知识就补充领域知识，直到 AI 能独立跑通从代码到线上验证的完整闭环。

第二，终极目标是什么？ 是公司管理层在 KO 上提出的愿景：全链路 AI 驱动、Agent 间协议交互、十倍效率跃迁、每天一个版本。但这个愿景不能一步到位，必须拆解为可渐进达成的成熟度等级。

第三，路径是什么？ Harness Engineering 告诉我——先建 Harness，再谈 AI 的能力释放。

基于这三个问题的回答，我形成了"双循环"方法论：

┌─────────────────────────────────────────────────────────┐│                    外层循环：框架沉淀                      ││  挽单实践 → 模式提炼 → 通用化 → AINMM 定义 → 反哺挽单    │└─────────────────────────────────────────────────────────┘                            ↑↓┌─────────────────────────────────────────────────────────┐│                    内层循环：工程演进                      ││  评估现状 → 识别短板 → 定向改造 → 验证效果 → 再评估      │└─────────────────────────────────────────────────────────┘

外层循环回答"这个方法是否通用"，内层循环回答"这个改造是否有效"。两个循环相互驱动，挽单实践过程中每一个踩坑都在丰富 AINMM 的肌理，AINMM 的每一条定义都在指导挽单的下一步。

起点状态：尽管挽单工程在日常Vibe Coding/Spec/Plan Mode开发中已经沉淀了一些面向AI的领域知识和上下文产物，但不够系统化、也无法量化，因此本次第一步改造就是让AI 建立系统性"认识"项目。第一轮通过AINA-C 自动评估显示总分 30 分，ML1 水平。

把需求直接丢给 AI 时的可能存在的落差：AI 能生成代码，但完全不理解挽单的业务语境——复杂的业务状态机、RPC 调用链、消息格式等对它来说都是黑盒。产出的代码千篇一律，经常需要解释补充背景。这让我意识到，没有系统性、可演进的上下文，AI 只是高级代码补全，不是数字员工。

ML1 改造行动：

1. 构建 AGENTS.md + docs/ 结构化文档

• 将散落在 Code Wiki、钉钉群、口头约定中的项目知识，索引化为 150 行的 AGENTS.md

• 建立 docs/ 目录，按"AI 不知道就会写错"的标准筛选内容

• 实现信息分级：AGENTS.md 做地图，docs/ 做手册

2. 让 AI"知道它能部署"

• 把内部 CI/CD 命令行工具的能力接入 AI 上下文，让 AI 在 AGENTS.md 中就能看到"我有部署权限，可以通过 a1 提交发布"

• 将预发环境配置、发布流程、回滚策略等部署领域知识结构化到上下文中

3. 建立 MEMORY.md 经验沉淀机制

• 将 182 行经验按"问题 → 根因 → 解法"结构重排

• 建立"已知陷阱（Gotchas）"清单，让 AI 在生成代码前就能避开常见坑

ML1 阶段的核心洞察：上下文工程不是"写文档"，而是建立 AI 能理解的"项目语义层"。人看代码理解业务，AI 看 AGENTS.md 理解约束——两者的信息介质必须分离。更关键的是，AI 不仅要"认识项目"，还要"认识自己的能力边界"，知道它能调用什么工具、能执行什么操作。

ML1 解决的是"AI 能认识项目"，ML2 要解决的是"AI 的行为可预测、可验证"。这个阶段进行的并不是很顺利，遇到了基建、安全和业务场景如何自动化验证问题，部分工作还在进行中。

真实踩坑：AI 第一次尝试完整交付

上下文有了，我尝试让 AI 完整跑通"拉分支 → 改代码 → 提交 → 部署"的闭环。AI 信心满满地开始执行，却在部署环节连续报错——a1 CLI 虽然对 AI 暴露了命令接口，但缺少足够的领域知识：

• 不知道挽单在预发环境的部署规则

• 没有被告知"提交后必须先跑门禁再发布"的强制顺序

AI 像是一个拿到了工具箱但不会看说明书的工人，在同样的环节跌倒。

改造行动：

1. 给 a1 补充领域层 Harness

• 不是弃用 a1，而是把部署规则、环境约束、常见错误模式编码成 Skill

• 明确告诉 AI："先跑 Gate 1-2 → 再提交 → 再调 a1 部署 → 部署后触发自检"

• 把 a1 报错信息中的领域术语翻译成 AI 能理解的修复建议

2. 建立基础验证门禁（Gate 1-2）

• Gate 1 编译检查：AI 生成的代码必须通过编译，报错信息包含"什么规则违反了 + 为什么是问题 + 怎么修"

• Gate 2 架构约束验证：通过 ArchUnit 规则检测分层违规、循环依赖、包结构破坏

• 对存量问题建立基线，只报新增 issue，避免"一上来就几千条报错"的劝退效应

3. 引入协议桥，打通端到端验证

• 让 AI 能触达 HSF 服务做端到端验证，解决"代码写了但不知道跑不跑得通"的问题

• 协议桥把内部 RPC 接口封装成 AI 可调用的标准格式，AI 部署后能立即自检业务接口连通性。核心思想是给AI铺路，把人完全剥离出来。

协议桥代码地址：内部工具仓库（暂不对外开放），本质上我希望给AI构建一个端到端的验证通路，某种程度上也反映了我们面向AI Native的基础设施的完备性不足。进一步思考，如何组织庞大的自动化业务用例、linter集合、如何定义端到端的自动化验收标准、安全问题，这些问题都是未来可以持续精进、亟待解决的，这里权当抛砖，感兴趣一起探讨和完善。

ML2 让 AI 能"管好自己"，ML3 要让 AI 和人能"协作好"。这个阶段的触发点是另一个真实场景：AI 能独立开发并验证，但我和 AI 的协作边界是模糊的，模糊的就容易犯错——有时候 AI 擅自改了不该改的字段，有时候我重复审查已经验证过的代码，有时候 AI 在不确定的情况下"蒙混过关"。

这让我意识到，人和 AI 之间缺一份"契约"。

ML3 改造行动（进行中）：

1. 引入契约式设计

• 前置断言：AI 执行前必须复述目标，断言不通过拒绝执行

• 后置断言：完成后必须通过外部证据（测试回包 / 日志 / 监控）验证

• 不变式：外部 Spec 不容篡改，跨 session 状态由文档保持

2. 部署置信度路由（待定）

• 高置信（>90%）→ 自动推进

• 中置信（60-90%）→ 标记审查

• 低置信（30-60%）→ 暂停等人

• 极低置信（

3. 标准化 8 阶段 SOP

• 在团队中推行统一的协作流程：目标收敛 → 状态恢复 → 上下文装配 → 任务分块 → 链路设计 → 执行前校准 → 外部验证 → 回写

• 每个阶段定义明确的输入、输出和完成标准

4. 定义偏航检测信号

• 绕过阶段目标直接谈总目标

• 跳过中间产物直接改代码

• 用主观语气替代客观证据

• 混淆阶段完成和全局完成

ML3 阶段的核心洞察：协作契约不是"写个流程文档"，而是建立人机之间的"信任协议"。信任不是靠喊口号建立的，是靠"断言-验证-校准"的闭环一点点积累的。统一语言的背后，是团队对"什么时候不用管 AI、什么时候必须介入"有了共识性的答案。

截至当前，挽单系统的 AI Native 演进取得了以下可量化的指标（仅供参考，数据存在变量差异不用深入推敲，核心是希望借项目演进探索一套可被复用的框架/方法论）：

在挽单的实践过程中，我发现了部分 AINMM 框架尚未覆盖、但对真实落地至关重要的配套设施缺口。这些缺口反过来印证了 §7.2 中的判断——AI Native 不是口号，而是需要业务与技术深度融合的系统工程。如果缺少统一语言的对齐、资源配置的支撑和 ROI 衡量的验证，零散 AI 实践很难自发整合为清晰的演进路径。

缺口一：子工程划分与 Monorepo 策略

挽单系统并非单一工程，而是由前端 H5、后端服务、移动端小程序、配置平台等多个子工程组成。当前 AINMM 的评估维度主要面向单一仓库，对于"跨仓库的上下文如何统一""多端变更如何联动验证""子工程间的依赖如何被 AI 理解"等问题，还需要在 Harness Layer 1（上下文工程）中进一步扩展。

缺口二：电商场景全自动测试链路

挽单承载的是售后挽回业务，涉及复杂的电商状态机（订单状态、退款状态、权益等）。当前的 Gate 3-4（单元测试 / 集成测试）能够验证代码层面的正确性，但业务场景层面的全自动验证仍然依赖人工构造数据和人工判断结果。构建让 AI 能自动生成符合业务规则的测试数据、自动验证端到端业务流程——是 ML3→ML4 阶段必须攻克的关卡。

缺口三：线上数据回流与运维闭环

当前 AI 的上下文主要停留在"开发态"，对于"线上异常如何触发开发态修复""运维数据如何反哺 AI 的上下文理解"还缺乏机制。公司管理层提出的"每天一个版本"不仅要求开发快，更要求发布-监控-修复的闭环快。这需要在 Harness Layer 5（自进化）中建立线上数据回流通道。

这些缺口不会让我否定 AINMM 的价值，反而让我认识到：通用框架提供的是"地图"，具体团队需要结合业务特点在地图上标注自己的"险滩"。AINMM 的当前版本是一个起点，而非终点。

上节识别的三个缺口——子工程上下文贯通、电商场景全自动验证、线上数据回流闭环——正是挽单向 ML3-ML5 演进需要重点攻克的方向。基于此，挽单的终极愿景，不是一个"AI 辅助开发"的系统，而是一个自进化的 AI Native 系统。基于当前的 ML2 基础和未来 ML3-ML5 的演进路径，我设想的完整闭环如下：

需求输入 → 自动 Spec 生成 → 自动开发 → 自动部署     → 自动验证 → 自动回归 → 自动上线 → 自动运维     → 线上问题自动收集 → 自动优化 → 需求再输入

在这个闭环中，人只在必要时介入：

• 需求收敛阶段：人负责判断"做什么"和"为什么做"，AI 负责将需求转化为结构化 Spec

• 开发阶段：AI 基于 Spec 自动生成代码、自动走查、自动修复门禁问题

• 验证阶段：AI 自动构造测试数据、自动执行全链路回归、自动生成测试报告

• 上线阶段：AI 自动灰度发布、自动监控核心指标、自动回滚异常变更

• 运维阶段：AI 自动收集线上异常、自动归因、自动产生修复提案

这个愿景不是空想。ML1-ML2 已经走通了"自动开发 + 自动验证"的小闭环，ML3-ML4 将走通"自动部署 + 自动上线"的中闭环，ML5 将实现"自动运维 + 自动优化"的大闭环。每一步的演进都有 AINMM 的等级定义作为路标，都有审计脚本（audit.sh）的量化评分作为验证。接下来会在AI端到端自动化验证、尝试复用SRE Agent运维自进化的数据打通几个重点方向深入。

挽单的案例对 AINMM 的价值，不是"证明了这个框架完美无缺"，而是验证了"案例驱动框架、框架反哺案例"的双循环方法论是可行的。

具体来说：

1. 定位能力得到验证——五维度评分精确揭示了"D1/D2 领先、D3/D4 滞后"的不均衡状态，避免了"盲目堆 AI 工具"的陷阱

2. 路径指导能力得到验证——评估结果直接指出"PA4 协作契约是最大短板"，让有限的研发资源投向了最关键的方向

3. 度量能力得到验证——改进前后总分从 30 提升到 48，等级从 ML1 提升到 ML2，进步是可量化、可验证的

4. 框架的通用性得到验证——挽单踩过的坑（Skill 缺少验证标准、门禁缺少业务场景覆盖、上下文缺少跨仓库联动）被抽象为 AINMM 的改进方向，让下一个项目可以避免同样的弯路

最后，回到前言中的那句话：没有一种范式是银弹。AINMM 和挽单的实践都是"进行时"，而非"完成时"。框架会持续进化，挽单会持续演进，我也将持续在真实的工程土壤中打磨这套方法。欢迎有兴趣的一起探索。

附录 A：术语表

[1] Sonar. State of Code Developer Survey Report: The current reality of AI coding. SonarSource Blog, 2025. 

https://www.sonarsource.com/blog/state-of-code-developer-survey-report-the-current-reality-of-ai-coding

基于对 1,100 余名企业开发者的调查，报告指出 42% 的新增代码由 AI 辅助生成，并揭示了 AI 代码的验证缺口（Verification Gap）。

[2] GitClear. AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Duplicate Code. GitClear Research, 2025.

 https://www.gitclear.com/ai_assistant_code_quality_2025_research

[3] Stack Overflow. Mind the gap: Closing the AI trust gap for developers. Stack Overflow Blog, 2026-02-18. 

https://stackoverflow.blog/2026/02/18/closing-the-developer-ai-trust-gap/

[4] OpenAI. Harness engineering: leveraging Codex in an agent-first world. OpenAI Blog, 2026. 

https://openai.com/index/harness-engineering/