AI编程成熟度模型：从3倍到10倍的路径

每个用AI写代码的人都说”我变快了”。但快了多少？上限又是什么决定的？

这个问题没有单一答案，但我们可以精确描述决定因素。

效率的两个维度

这个倍数其实有两个维度：

• 开发效率——写代码、调试、让功能跑通的速度
• SDLC效率——工程师在整个软件开发生命周期中的效率，包括on-call、流水线维护、工单处理、监控审查等非编码工作

答案取决于AI能在这两个维度上自主执行多少环节。下面介绍一个四层成熟度模型，从开发效率的提升，转到全面SDLC的提升。

模型总览

L1——复制粘贴（Chat时代）

你问AI一个问题。它给你代码。你复制到编辑器里。跑一下。失败了。把报错贴回去。循环往复。

人是I/O层——手动在AI和开发环境之间搬运上下文。

效率提升：微乎其微。受限于复制粘贴速度和上下文窗口管理。

L2——规格驱动（引导式开发）

AI可以访问你的代码库（通过IDE集成或CLI agent）。你描述需求；它直接写文件。你review、跑测试、接受或拒绝。

这是大多数团队目前的状态。

瓶颈在验证-修复循环。 每次修改仍然需要人来看输出，验证改得对不对。

这产生了一个公式（简化模型，具体倍数因项目而异）：

DevTime = (CodingTime + VerifyTime) × Iterations

在L2，AI把CodingTime压缩得很低（例如1分钟）。Iterations可以通过良好组织的文档来降低。瓶颈就到了VerifyTime。

假设人类开发1小时，验证30分钟，那么一次迭代就是90分钟。使用AI，开发1分钟，验证30分钟，那么一次迭代就是31分钟，大约3倍的提升。

L3——反馈循环（自主开发）

关键洞察：如果AI能跑测试并读取结果，它就能验证自己的工作。

在L3，AI生成代码、执行验证（构建+测试）、解读结果、自我修正——全程无需人工干预。人只需要review最终产出。

DevTime = CodingTime + VerifyTime
（迭代发生在AI循环内部，对人而言等效为单次）

降低VerifyTime就是3倍变10倍的关键。瓶颈从”人验证多快”转移到”测试套件跑多快”。同样的例子，VerifyTime如果只需要1分钟，那么一次迭代就只需2分钟，相比L2的31分钟，又获得了约15倍的提升。

L3的前提：测试基础设施

流水线上的集成测试是我们想在本地复现的目标：它覆盖真实行为，是全流程部署的守门员，但跑一次要30分钟。L3的目标是把同等覆盖率的测试压缩到秒级。

L3要求测试：

• 本地可运行（越快越好）
• 确定性（不能有flakiness）
• 覆盖真实行为（不只是mock）

没有这些，AI就无法闭合循环——它没有可靠的信号来迭代。

L3实践：进程内本地集成测试

以我们的一个后端服务为例，在L2中AI已经能快速写好代码，但验证周期仍然约30分钟：编译 → 构建Docker镜像 → 启动远程开发环境 → 启动服务 → 设置SSH隧道 → 运行集成测试。每次迭代的瓶颈就在这30分钟的验证上。

我们构建了一个进程内本地集成测试框架将VerifyTime压缩到30秒以内：

• 本地代理 不去部署服务，而是直接通过方法调用真实的业务逻辑类（无HTTP、无部署）
• 真实下游服务 通过SSH隧道连接测试环境
• Record/Replay 模式录制下游响应，支持离线迭代
• 多环境验证 自动管理凭证和隧道

工作流：AI识别未覆盖的API → 写测试 → 运行 → 失败 → 修复 → 重跑 → 通过。端到端约10分钟写好一个API的集成测试，运行E2E的一个API集成测试所需时间不到30秒。

关键定位：把本地集成测试视为开发工具而非测试工具。它的首要价值是赋能AI反馈循环，而不仅仅是抓回归。

良性循环：

1. AI写集成测试
2. 测试成为未来代码修改的反馈信号
3. 代码修改导致的测试失败在同一个循环里自动修复
4. 遇到新模式 → 经验更新 → 下一次测试更容易

选择你的依赖策略

调用真实下游服务只是频谱上的一个点。选择取决于服务的读写特征：

• Replay模式（无下游调用）——最安全、最快、可离线。适合有写操作或敏感副作用的服务
• 只读调用测试环境——在测试不修改状态时是安全的。提供最高保真度的信号
• 写调用共享测试环境——有风险（状态污染、通知触发）。需要谨慎

原则是相同的：快速、确定性的反馈，让AI可以迭代。

L4——Agent循环（自主SDLC）

L3加速的是编码阶段。但编码只是开发者工作的一部分。L4将自主运行扩展到整个软件开发生命周期。

指导原则：控制熵

软件系统自然趋向混乱（熵增）：依赖变旧、测试变flaky、配置漂移、文档过时、流水线腐化。这些是重要的工作，但从来不会被优先排期——因为不紧急。

L4的核心定位：让agent持续产出代码变更来对抗软件熵。人审阅并批准。

需要注意的是：不是所有熵都需要清除。有些技术债是有意识的权衡。Agent选择”修什么、不修什么”本身需要人来校准。

L4的设计原则

1. Agent要么产出代码变更，要么产出backlog。 如果搞不定，就写一个待办事项，后续由人类驱动AI来解决。
2. 生产环境只读。 Agent永远不部署、不修改生产环境。
3. 信噪比。 Agent不能用误报或低优先级修复淹没reviewer。
4. 并行性。 多个领域专用agent并发运行。
5. 透明性。 Agent的运行历史、状态、待处理事项对人类可见，随时可以查看当前状态。

L4的覆盖范围

• 流水线与构建——修复阻塞的流水线、解决依赖更新导致的构建失败
• 测试稳定性——修flaky test、为关键路径补测试
• 依赖管理——安全补丁升级、废弃API迁移、检测未使用依赖
• 配置漂移——实际状态vs声明代码的漂移、跨Region配置不一致
• 代码健康——死代码检测移除、日志格式标准化
• 监控与可观测性——检测无告警的API、Dashboard异常检测
• 文档同步——代码变更后保持文档同步
• 合规与安全——IAM最小权限收紧、安全风险修复
• 主动学习——扫描公开故障报告产出预防性修复

L4实践：流水线熵控制

我们有一个agent按工作日定时运行，扫描团队所有流水线，自动修复故障：

定时任务 (工作日晚9点)
    -> 编排器读取配置
        -> 扫描流水线健康
        -> 分类故障类型
        -> 派发子agent（并行，最多3个）
            |-- 版本策略违规 -> 升级依赖版本
            |-- 构建失败 -> 诊断 + 修复
            |-- 部署失败 -> 诊断 + 修复
            +-- 集成测试失败 -> 诊断报告
        -> 验证代码变更（本地构建 + 静态分析）
        -> 发布变更 -> 分配给on-call review
        -> Slack摘要 + 面板报告

护栏： Agent永远不会merge。代码变更必须通过本地构建+静态分析后才会发布。修不了的问题生成诊断报告写入backlog。

实测（一周）： 15个代码变更提交，12个包修复，88条流水线监控。人只需review：约5分钟/个。

局限性： 集成测试失败目前只能诊断不能自动修复；跨团队上游包的构建失败需要人跟进；偶尔会被拒（选择了错误的升级路径）。

L4中人的角色

人从执行者转变为审阅者和系统架构师：

• Review代码变更——生产代码的最终责任
• 驱动Backlog——解决AI还无法自主解决的问题
• 改进Agent循环——元工作：让agent变得更好
• 决定做什么——战略、用户同理心、权衡取舍
• 跨团队协商——社交动态、组织上下文

最高杠杆的活动是”改进agent循环”——因为每一次改进都会在所有未来任务中复利式累积。

改进Agent循环的两种路径

路径一：人类驱动改进。 人处理agent搞不定的backlog时，顺便把解决方法固化。下次agent就能自己处理了。每一次backlog的消化都在扩大agent的能力边界。

路径二：AI自主迭代（早期探索）。 Agent在运行过程中发现自身的不足，自主将经验写成新的规则文件，提交供人review。这个能力仍在早期阶段，产出质量参差不齐，需要人来把关。但方向是明确的：agent的知识库能随使用自动增长。

这两条路径形成正反馈：人处理backlog → agent能力增长 → backlog减少 → 人有更多时间改进agent → agent能力进一步增长。

各层是递进依赖的

每一层都依赖下面一层。跳级不是不可能，但效果会大幅打折。

L4 依赖 L3 -- 没有自动验证，agent产出需要人逐一验证
L3 依赖 L2 -- AI写代码不够快的话，快速验证的意义不大
L2 依赖 L1 -- AI需要能访问代码库才能写代码

为什么不建议跳过L3直接做L4： 一个修流水线或处理工单的agent，其可靠性取决于它验证自身工作的能力。没有快速反馈循环，agent的每个产出都需要人完整验证。

我们观察到一个有趣的对比：同一个agent修构建失败时，依赖本地构建作为验证（L3），所以能自动闭环，变更通过率很高。而对于集成测试失败，缺乏快速的本地集成测试环境，只能产出诊断报告而无法自动修复。同一个agent，有L3的场景能自动闭环，没有L3的场景只能半自动。

如何到达下一层

L1 → L2：让AI访问你的代码。 使用IDE集成工具而非聊天窗口。让它读文件、写文件、跑命令。提供良好的上下文文档。

L2 → L3：构建反馈循环。 识别你的验证瓶颈，让它尽快跑完，让结果机器可读，消除flakiness。对于后端服务，进程内调用+Record/Replay是一个已验证的模板。前端可以用headless浏览器+快照比对，数据管道可以用本地执行+样本数据集。

L3 → L4：将运维知识固化。 先用AI一起解决一次，提取模式，写成机器可读指令，让agent自己跑，人review输出。这是一个迭代过程，每个规则初始都不完美，在使用中不断优化。

乘数效应

模型的各层不只关乎个人速度——它们在团队层面复合增长：

• L1：微弱提升，无团队乘数
• L2：数倍（编码速度），微弱团队乘数——每个人仍需自己验证
• L3：数倍~数十倍（编码速度），中等团队乘数——测试框架是共享基础设施，一次投入全团队受益
• L4：解放非编码时间（SDLC效率），高团队乘数——规则写一次，所有使用该agent的工程师立即获益，可跨团队复用

L3和L4提升的是不同维度：L3压缩编码任务的周转时间，L4释放原本花在运维/工单/流水线上的时间。两者叠加才是整体效率的提升。

一些思考

为什么新项目比老项目提升更大？ 因为新项目可以从第一天就设计反馈循环。老项目的集成测试在流水线里跑20分钟，加装快速反馈循环可以做到但需要刻意投入。如果你正在启动新项目，花时间设计L3反馈循环不是额外开销，而是单笔ROI最高的基础设施投资。

为什么快速本地集成测试现在才开始流行？ 两个原因。第一，以前测试不是瓶颈——编码花几个小时，验证才30分钟，占比不大。L2普及后CodingTime趋近于零，VerifyTime才成为主导项。第二，搭建框架以前成本太高——打通服务间的网络和凭证，以前是几周的工作。有了AI之后几天就能搞定。受益于反馈循环的AI，同时也让反馈循环的建设成本大幅降低。

没有L3直接做L4行不行？ 效果很随机。我们观察到：同一个agent，有本地构建验证的场景能自动闭环，没有的场景只能产出诊断报告。feedback loop是让agent可靠自我修正的基础，没有它你得到的是一个昂贵的建议引擎而不是一个自主运维者。

写在最后

从3倍到10倍的路径不在于更好的模型，而在于闭合反馈循环让AI能自主迭代。从10倍编码到10倍SDLC的路径则是教会AI做那些实际消耗工程师大部分时间的非编码工作。

2018年我写过《未来的软件开发什么样》，当时觉得AI和程序员”合作”还只是萌芽。没想到不到八年，我们已经走到了让AI自主运维服务的阶段。那篇文章里的”合作”和”创新”两个预测基本应验了，但演进的速度远超当时的想象。

这个模型还在演进中。也许未来还会有L5——AI自主决定做什么，而不只是执行人类定义的任务。不过那是另一个话题了。