AI 生成代码质量评测指标与防退化体系建设

虚假的繁荣：用代码行数衡量效率的陷阱

引入 AI 助手后，很多团队发现代码提交量翻了一倍，但随之而来的是后续维护成本剧增。AI 倾向于通过简单的复制粘贴来解决问题，导致代码冗余严重。

圈复杂度（Cyclomatic Complexity）严控：自动检查 AI 新增函数的嵌套深度与分支数量，禁止生成深层嵌套的 if-else 结构；
重复率静态检测（Duplication Detection）：通过 SonarQube 等工具实时拦截高重复度的代码块，强制模型抽象复用通用函数；
变异测试检验测试充分性：针对 AI 编写的单元测试，自动进行变异注入（改变逻辑操作符），若测试未能报警则判定该测试用例无效并要求重写。

度量维度	常见工具举例	反馈时机	接入成本
圈复杂度	lizard、ESLint complexity 规则	本地 pre-commit	低
重复率	SonarQube、jscpd	流水线定时扫描	中
变异测试	Stryker（JS/TS）、mutmut（Python）	夜间或发版前任务	高

建议按成本从低到高逐层引入：复杂度与重复率检查通常一至两天即可接入现有 CI；变异测试计算开销大，通常只对 AI 新增的核心模块按夜间任务运行，不必全库执行。

第一步，在 Agent 提交必经的流水线上启用 lint 与复杂度检查，直接复用团队既有的规则文件，避免新标准与旧代码互相打架。第二步，要求 AI 生成的每段新逻辑必须附带单元测试，测试未通过则构建失败，具体写法可参考测试驱动开发（TDD）在 AI 编程智能体中的落地：用测试用例锚定代码生成质量。第三步，对 AI 产出的 PR 抽样人工复核，把典型缺陷（冗余分支、假断言）沉淀进审查规则，逐步过渡到基于 AI Agent 的自动化代码审查：在 GitHub Actions 中落地零误报实践。

质量哨兵上线后需要反向验证：挑一批历史 AI 提交人工标注问题清单，再看三道检查各自能捕获其中多少；若某类缺陷全部漏过，说明对应阈值过松。另一个常用信号是"指标全绿但缺陷逃逸率上升"，这通常意味着模型学会了贴着阈值写代码，此时应收紧规则而不是放松。

判断体系是否生效的标准很直接：随机抽取最近 20 个 AI 生成的 PR，若其中无测试、高重复或深嵌套的合并进主干的数量为零，且变异测试存活的代码块占比在持续下降，说明门禁在起作用；反之若指标好看但缺陷单变多，优先怀疑阈值被"应试化"绕过，应收紧规则而非新增指标。