�� AI 把代码写得更快了,但真正稀缺的是“管住它”的能力

生成式 AI 正在把“写代码”这件事从稀缺技能，变成高吞吐操作。  

过去一个资深工程师一天能稳稳交付一段新逻辑；现在，一个人加一个模型、一套 agent 工具、一轮 prompt 链路，半天就能产出过去两三天的代码量。看上去像是产能革命，但很多团队很快会发现：代码产量上来了，重复逻辑、冗余实现、审查压力、测试欠账和架构熵增，也会一起被放大。

这正是今天工程团队最容易误判的地方：  

AI 不是自动交付的代名词。它只是把“生成代码”这一步变得极度便宜了。真正昂贵、真正稀缺的，仍然是审查、测试、架构和治理。

这篇文章想回答 4 个问题：

1. 为什么 AI 会把“代码治理问题”放大，而不只是把“开发速度”提升？
2. 在 Vibe Coding 的真实流程里，问题通常是怎么一步步长出来的？
3. 工程团队应该用什么系统工程方法，把这种失控风险压回去？
4. 有没有一种可以产品化、skill 化的治理能力，把这些动作固化下来？

一、一个容易被误解的现实：AI 提升的是代码生成速度，不是工程确定性

关于这一点，最近几组公开信息非常值得注意。

• 根据 GitClear 2025 研究摘要（211 million lines of code），复制/粘贴代码比例明显上升，重构型 moved lines 明显下降，短期 churn 上升。这意味着团队在“更快地新增代码”，但没有同步提升“复用、整合、重构”的能力。
   参考：  
• GitClear 2025 摘要转述

• DevClass 对 GitClear 的报道

• Simon Willison 对 Vibe Coding 的定义边界讲得非常清楚：如果你已经 review、test、understand 了代码，那就不是 vibe coding，而是正常的软件工程，只是用了 LLM 当加速器。
   参考：  

• Simon Willison：Vibe coding

• 与此同时，很多行业文章都在强调同一个矛盾：速度确实提升了，但安全、稳定性、可维护性和审查负担，并不会自动改善。
   参考：  

• Baytech: AI Technical Debt / AI Trust Paradox
• Wikipedia: Vibe coding

所以，今天真正的问题不是“AI 能不能写代码”。这件事已经被证明能。  

真正的问题是：

当代码生成足够便宜时，团队有没有能力控制它的结构、质量、边界和演化方向？

以后拼的可能不是“谁写得多”，而是“谁更能管住不断增殖的代码系统”。

图 1：如果只盯代码产量，很容易忽略重复率、重构率和 churn 这些真正能反映治理质量的指标。

二、Vibe Coding 不是一个点问题，而是一条会持续放大风险的流程

很多团队讨论 AI 研发风险时，只盯着“单段代码对不对”。
但真实的失控，往往不是某一段函数错了，而是整条工作流没有治理闭环。

下面是一条典型的 Vibe Coding 流程：

1. 人用自然语言提出需求  
2. AI 生成一版实现  
3. 人跑通 happy path  
4. 遇到报错后继续 prompt 修补  
5. 多轮对话后代码逐步膨胀  
6. 人只做局部 review，不再完整理解全局  
7. 代码进入主干，测试和架构治理滞后  
8. 进入迭代期后，重复逻辑、边界漂移和维护成本开始积累

它危险的地方在于：
每一步单独看都“好像还行”，但连起来之后，就形成了一个对技术债友好的增殖系统。

图 2：Vibe Coding 的问题很少在单点爆炸，更多时候是沿着“生成—修补—提交—上线”链条连续放大。

三、Vibe Coding 流程里最常见的 7 类问题

下面我按流程拆开讲，并给出工程团队最常遇到的典型例子。

1）Prompt 很抽象，AI 会优先生成“能跑的局部最优解”

当需求是“加一个审批流”“做一个积分系统”“支持多租户权限”时，AI 常常会先把表面功能拼出来，而不是先去判断：

• 现有系统里有没有相近模块？
• 这个逻辑应该落在哪一层？
• 是否已有统一的领域模型、共享组件和服务边界？

于是最常见的结果是：

• 新增了一套 相似但不相同 的业务逻辑
• 旧组件没有复用
• 新逻辑被塞进了最容易改的地方，而不是最合理的地方

例子：
一个 CRM 系统里，本来已经有客户手机号标准化函数 normalizePhone()，但 AI 在营销模块里重新生成了一套 formatMobile()，在客服模块里又多了一套 sanitizePhone()。三套函数都“基本可用”，但边界条件略有差异：有的保留区号，有的不保留，有的会吞掉前导零。  

上线后短时间没人发现；等到报表、搜索、短信发送和风控规则开始依赖这些字段时，团队才发现同一个手机号在三个子系统里表现不一致。

这不是“代码 bug”那么简单。
这是 复用路径断裂。

2）多轮“报错-修补”会制造分叉实现和隐藏死角

Vibe Coding 的强大之处，是可以快速把错误贴给模型再修。
但这也带来一个典型副作用：问题不是被系统性解决，而是被局部缝补。

常见表现包括：

• 先生成 A 方案，报错后 AI 补一个兼容分支
• 第二轮再报错，AI 增加兜底逻辑
• 第三轮再出异常，又多了一层 fallback
• 最后功能是通了，但代码路径已经非常分叉

例子：
一个支付结算模块，AI 最初生成了基于订单金额的折扣逻辑。后来业务提出“会员折上折”，AI 补了一段会员逻辑；再后来又加“渠道券优先级”，AI 再补一个判断；最后为了修边界错误，又加了一层异常兜底。  

最终结果是：

• 结算公式分散在 4 个函数里
• 后台展示价和用户支付价不是同一条逻辑链
• 测试只覆盖了 happy path
• 运维侧发现投诉时，没人能在 10 分钟内说清楚到底哪条规则生效

这类问题在 AI 时代更容易发生，因为修改成本被压低了，结构约束却没有同步增强。

3）AI 更擅长“新增块”，不擅长“整合旧块”

GitClear 报告之所以值得重视，就在这里：
AI 让“再写一段新的”变得太容易，但它不天然偏好“把旧的合并成一个更好的”。

因此团队会逐步出现三种现象：

• 同一能力多处重复实现
• 新模块越来越多，公共模块越来越弱
• PR 里新增代码很多，但 moved/refactor 的比例越来越低

例子：
前端已经有统一的“导出 CSV”能力，但 AI 在数据分析页、客服页、运营页各自写了一版导出逻辑。
短期看交付很快；长期看：

• 编码风格不一致
• BOM 处理不同
• Excel 打开兼容差异出现
• 安全过滤（如公式注入）有的地方做了，有的地方没做

最后你会发现，团队不是没有能力，而是复用意愿被生成便利性稀释了。

4）Review 吞吐跟不上生成吞吐，导致审查沦为“看起来没问题”

这是 AI 时代最核心的瓶颈之一。  

过去一个 reviewer 一天看 3 个中等 PR，已经很吃力。
如果 AI 把每个工程师的代码产量都抬高 2-5 倍，而团队仍然沿用同样的 review 机制，就会发生两个变化：

• review 时间不变，但变更总量暴涨
• reviewer 只能从“完整理解”退化为“快速扫一遍”

于是 code review 很容易退化成：

• 看命名顺不顺
• 看有没有明显语法错误
• 跑一下页面
• 只确认“这次改动好像能工作”

但真正关键的问题往往藏在这些 review 盲区里：

• 有没有重复发明领域逻辑？
• 有没有绕过原有模块边界？
• 有没有新增不可观测状态？
• 有没有把未来维护成本显著抬高？

这就是 AI 时代 review 的第一性变化：
review 不再只是“查错”，而是要承担“系统守门”职责。

5）测试债会比以前更快累积，因为“生成功能”比“补齐验证”更有即时快感

AI 最大的诱惑之一，是你很容易在几分钟内“看到功能成形”。
而测试、回归、契约校验、异常路径覆盖，则天然没有那么即时的反馈快感。

于是团队很容易出现：

• 页面已经做出来了，测试以后补
• API 已经通了，异常路径以后补
• 监控先不上，先发看看
• 用 AI 写了测试，但没人确认测试是否验证了真正的不变量

例子：
AI 帮你写了 20 个单测，看起来 coverage 很高，但实际上：

• 它只验证了 mock 返回值
• 没验证事务一致性
• 没验证权限边界
• 没验证接口幂等

这类“测试存在但没有保护力”的状态，在 AI 时代会比过去更常见。

因为以前工程师写测试时，往往要经历“我到底在保护什么”的思考；
而现在，测试也可能被自动生成，于是验证行为本身也开始被自动化稀释。

6）架构边界会慢慢被侵蚀，因为 AI 对“全局约束”的理解弱于对“局部可用”的追求

AI 非常擅长补功能，但对“系统该如何长期演化”并不天然敏感。  

它可能会：

• 把本该在 domain service 的逻辑写进 controller
• 把本该在共享库的逻辑复制到页面组件
• 把临时脚本变成长期依赖
• 把同步流程和异步流程混在一起
• 在不该跨层访问的地方直接访问数据库或第三方 SDK

例子：
为了追求“用户点击后立刻有结果”，AI 可能直接在 Web 接口里串联：

• 数据库写入
• Redis 缓存更新
• 第三方通知
• 向量索引刷新
• 异步任务回写

表面看“一次请求全做完，很方便”；
实际上，你已经把控制层变成了耦合中枢。
后续任何一项失败，都会把这条链路拉成复杂故障源。

7）最后真正失控的，不是代码量，而是“没人再能清楚解释系统为什么这样长成”

这件事很关键。  

技术债最可怕的状态，不是代码烂，而是：

• 代码是怎么来的，不知道
• 为什么这样实现，不知道
• 哪些 prompt 导致了这个结构，不知道
• 哪些地方是复用、哪些地方是临时 patch，不知道
• 哪些地方必须保留、哪些地方其实可以删，不知道

当 AI 参与越来越深以后，团队如果没有变更来源、审查结论、风险级别、测试证明、架构决策这些记录，系统会进入一种危险状态：

它还在运行，但它的可解释性已经开始流失。

这时候的核心问题就不是“写得快不快”，而是“你还能不能对它负责”。

四、所以真正该治理的，不是 AI 本身，而是 AI 参与后的工程流程

很多团队会问：那是不是应该减少 AI 使用？

我更倾向于另一个答案：
不是少用，而是要把它从“写代码工具”升级成“受控的工程参与者”。

也就是说，重点不在于禁止生成，而在于把生成后的流程变成一个可治理、可审查、可测试、可回滚的系统。

在这里，我建议用一套更适合 AI 时代的工程框架：

图 3：CONTROL 不是单点工具，而是一条从意图契约、复用约束到发布门禁的治理闭环。

五、CONTROL：面向 AI 代码治理的系统工程方法论

我把它叫做 CONTROL。  

它不是一套单点工具，而是一条治理闭环。

C — Contract First：先写“意图契约”，再让 AI 动手

在 AI 写代码前，先定义清楚：

• 目标功能是什么
• 禁止修改哪些模块
• 必须复用哪些现有能力
• 哪些是不变量
• 哪些风险必须显式检查

这一步的本质，是把“模糊自然语言”转成“工程可执行约束”。

如果没有这一步，AI 默认会追求“最容易生成的实现”；
有了这一步，它才可能优先走“最符合系统约束的实现”。

O — One Path Reuse：强制单一路径复用

团队要建立一个明确机制：

• 同一领域逻辑只能有一条主实现路径
• AI 提交改动前，必须先搜索是否已有近似模块
• 发现重复能力时，优先扩展现有模块，而不是再起一份新实现

这一步是反 AI 时代“复制块增殖”的关键。

你要把团队从“功能做出来了没有”升级到“这个能力是不是还只有一条可信主路径”。

N — Narrow Diffs：把 AI 变更切小，控制审查半径

AI 最危险的时候，不是写了很多代码，而是一次改太多地方。

因此应当建立：

• PR 大小预算
• 单次改动文件数上限
• 高风险模块必须拆分提交
• 架构变更与功能变更分开 review

当 diff 足够窄时，review 才能真正回到理解层面，而不是靠直觉扫过去。

T — Test Mesh：建立“多层测试网”，而不是只追求 coverage

AI 时代的测试，必须从“有没有测试”升级到“有没有保护关键不变量”。

建议至少分成 5 层：

1. 单元测试：保护局部纯逻辑  
2. 契约测试：保护上下游接口约定  
3. 回归测试：保护历史故障不再出现  
4. 性质测试 / 边界测试：保护异常输入和组合空间  
5. 安全与权限测试：保护生产约束

AI 可以参与写测试，但不能代替团队定义什么值得被保护。

R — Review Routing：让不同风险走不同审查路径

不是所有 AI 代码都该走同一种 review。

建议分级：

• 低风险：文案、样式、小型页面交互  
• 中风险：业务逻辑、接口改动、状态处理  
• 高风险：权限、支付、计费、数据一致性、基础设施、架构边界

低风险可以走轻 review；
高风险必须走：

• 领域 owner 审核
• 测试 owner 审核
• 必要时架构 owner 审核

这样团队才不会把有限的资深审查资源，浪费在所有变更平均用力上。

O — Observability & Provenance：让 AI 变更可追溯、可解释

一条 AI 参与的代码变更，至少应记录：

• 需求意图
• 使用的 prompt / agent 目标
• 涉及模块
• 风险等级
• reviewer 结论
• 测试结果
• 发布批次
• 回滚路径

如果这些东西没有记录，团队在故障时就无法快速回答：

• 这段逻辑是谁引入的？
• 为什么要这么做？
• 它影响哪些边界？
• 如果回滚，要回到哪里？

这一步，是把“AI 参与开发”从黑箱行为，变成工程资产。

L — Limit Release：用渐进发布和自动回滚把风险关在外面

即便通过了 review 和测试，也不代表应该直接全量。

AI 代码更适合默认配套：

• feature flag
• canary
• shadow traffic
• error budget
• rollback script

这样一来，即使模型生成了一段“看起来合理、线上才暴露问题”的逻辑，损失也能被限制在小范围内。

六、把 CONTROL 落到团队日常，应该怎样实施？

如果你是工程负责人，我建议按下面 4 层推进，而不是一下子搞很重的平台工程。

第一层：先把“意图契约 + 风险分级 + PR 大小控制”立起来

这是见效最快的三件事：

• AI 提交前先写约束卡片
• 每个改动先做风险分级
• 单个 PR 控制规模

这三件事可以立刻降低“AI 一次写太散、review 一次看太多”的问题。

第二层：补“复用搜索 + 重复逻辑检测”

这一步专治 AI 时代的重复实现：

• 改动前先搜索现有模块
• 对新增逻辑做近似重复检测
• 对同域功能做单一路径约束

第三层：补“测试网 + 发布门禁”

包括：

• 契约测试
• 高风险路径回归测试
• 生成式安全扫描
• 发布前门禁
• 失败自动回滚

第四层：最后做“治理平台化 / skill 化”

当团队积累了一定规则后，就不要再靠口头提醒了。
把它做成工具、做成 skill、做成 CI 阶段能力，才是真的把工程纪律沉淀下来。

七、如果团队想判断自己有没有“管住 AI”，应该看哪些指标？

很多团队一谈 AI 研发指标，第一反应还是：

• 代码行数涨了多少
• PR 数量涨了多少
• 需求交付提速多少

这些都不能说没价值，但它们只回答了“产出有没有变快”，没有回答“系统有没有变稳”。

如果你真的想判断团队有没有把 AI 用对，我建议至少同时盯住下面 8 个指标：

1. 重复逻辑比例
     新增 diff 中的近似重复片段占比是否持续上升？

2. Refactor / Move 比例
     新增代码和重构代码的比例是否失衡？

3. 短期 Churn
     新代码在两周内被反复改写的比例是否过高？

4. 高风险改动占比
     AI 参与的高风险改动是否在持续增多？

5. 高风险改动测试覆盖率
     支付、权限、数据一致性等路径是否有真正的保护性测试？

6. Review 吞吐压力
     reviewer 平均每天需要审多少 AI 生成改动？是否已经超过理解上限？

7. 架构越界次数
     controller 写业务、页面写服务逻辑、跨层直连依赖的次数是否增多？

8. 回滚率 / 发布后故障率
     AI 参与的变更是否更容易在上线后触发回滚、告警或热修？

真正成熟的团队，不会只看“AI 让我们写快了多少”，而会看：

AI 有没有让我们的交付系统变得更难审、更难测、更难维护。

八、一个可执行的团队落地清单

如果要把这套方法论落到 1-2 个季度的工程改造里，我建议按下面顺序做：

第 1 步：先止血

• 禁止大而散的 AI 变更直接进主干
• 高风险模块必须拆小 PR
• 所有 AI 变更必须标注风险等级

第 2 步：建立最小治理闭环

• 提交前做复用搜索
• 提交后做重复逻辑检测
• 高风险变更强制补测试
• 所有发布都保留回滚点

第 3 步：建立团队级观测面

• 看重复率
• 看 churn
• 看 review 压力
• 看回滚率
• 看架构越界

第 4 步：把规则技能化

• 让 skill 自动生成意图契约
• 让 skill 自动扫描重复实现
• 让 skill 自动路由 review
• 让 skill 自动补齐测试与发布门禁

只有走到这一步，团队才算真正从“会用 AI 写代码”进化到“会用 AI 做工程”。

九、最后真正该落地的，不只是规范，而是一个治理 skill

如果把这套方法论再往前走一步，我认为最值得做的，不是一份更长的规范文档，而是一个专门的工程治理 skill。

我会把它命名为：

ai-code-governor

这个 skill 不负责“替你写更多代码”，而是负责管住 AI 写出来的代码。

图 4：真正有价值的治理 skill，应该把“复用搜索、重复检测、风险路由、测试网、发布门禁”串成一个自动化系统。

它至少应该包含 8 个核心能力：

1. 意图契约生成器

把自然语言需求转成结构化约束：

• 功能目标
• 禁改区域
• 必须复用模块
• 风险级别
• 测试要求

2. 复用路径扫描器

在生成前和提交前，扫描代码库中已有实现，提醒：

• 是否存在相同能力
• 是否存在近似工具函数
• 是否应该扩展现有模块而不是新增一份

3. 重复逻辑探测器

针对新 diff 做近似重复分析：

• 发现复制/粘贴型实现
• 发现同领域多版本逻辑
• 发现跨模块重复分支

4. 风险分级与审查路由器

自动判断改动风险，并决定：

• 走普通 review
• 走 owner review
• 走架构 review
• 是否必须增加安全测试

5. 测试网编排器

不是只生成测试，而是基于风险要求：

• 最低单测集合
• 必要契约测试
• 关键回归测试
• 权限与异常路径测试

6. 架构边界守卫

检查新变更是否越界：

• 控制层是否侵入领域逻辑
• 页面层是否复制服务逻辑
• 是否直接跨层访问不该访问的依赖

7. 变更可追溯账本

为每次 AI 参与变更记录：

• 需求来源
• 生成上下文
• 审查结论
• 测试证明
• 发布批次
• 回滚点

8. 发布与回滚门禁

在上线前后自动执行：

• canary
• 关键指标监控
• 异常阈值告警
• 一键回滚

这类 skill 的价值不在于“更炫”，而在于它把 AI 研发从高吞吐但无约束，变成高吞吐且可治理。

十、结语：以后工程团队拼的，不只是生产力，而是治理力

AI 让代码生成变得极其便宜。
但越是便宜，越需要昂贵的工程判断来约束它。

当每个人都能快速生成大段代码时，真正稀缺的就不再是“把功能拼出来”的能力，而是：

• 能不能识别重复实现
• 能不能守住系统边界
• 能不能让 review 真正有效
• 能不能让测试保护关键不变量
• 能不能在速度提升后，仍然保持结构稳定

说到底，AI 改变的是“写代码”的成本曲线；
而工程团队最终比拼的，是“治理复杂系统”的能力曲线。

所以未来真正拉开差距的，不会只是“谁用了更多 AI”，而是：

谁能在 AI 抬高产量之后，依然把代码库管成一个可解释、可维护、可演化的系统。

这，才是 AI 时代的软件工程分水岭。