跳转至

AI Coding 评测、审查与治理

到 2028,真正有价值的 AI Coding 系统,不是“偶尔写对一段代码”,而是“长期、稳定、可治理地交付正确改动”。


1. 为什么评测比提示词更重要

没有评测,你无法回答:

  • 这套系统到底有没有提升成功率?
  • 它只是会写样例,还是能处理真实仓库?
  • 速度、成本、正确率之间是什么 trade-off?

所以 AI Coding 的核心问题,最终都会落到:

  • 任务定义
  • 验收标准
  • 自动化检查
  • 人工复核

2. 至少要评什么

维度 典型指标
正确性 测试通过率、任务完成率、回归率
工程质量 代码风格、可维护性、架构一致性
效率 token、延迟、步骤数、人工介入次数
稳定性 同类任务波动、长任务中断率
安全性 越权工具调用、危险命令、数据泄露风险
成本 单任务成本、平均重试成本、失败成本

3. 评测分三层

只有把评测分层,你才能知道问题究竟出在单次输出、任务闭环,还是团队治理机制。

3.1 单任务层

适合检查:

  • 单文件修改
  • 单函数修复
  • 单元测试补全

3.2 仓库任务层

适合检查:

  • 多文件改动
  • 架构一致性
  • 回归风险

3.3 生产治理层

适合检查:

  • 工具权限
  • 审计日志
  • 回滚能力
  • 人工门禁策略

4. 审查链路建议

一个更接近真实团队的链路是:

Text Only
Spec / Issue
  -> Agent 规划
  -> 代码修改
  -> 本地测试 / 静态检查
  -> AI / 规则双重审查
  -> 人工复核高风险改动
  -> 合并或回滚

高风险改动一般包括:

  • 数据库 schema
  • 权限与认证
  • 删除逻辑
  • shell / infra 变更
  • 影响核心链路的架构调整

5. 你简历里的“评测与治理”应该怎么写

不要只写:

  • 做了一个 AI Coding Agent

更应该写成:

  • 构建仓库级代码修改与审查系统
  • 支持符号检索、按行读取、测试回归与结果审计
  • 建立 X 类任务评测集,任务成功率从 A 提升到 B
  • 设计只读/可写工具边界与人工门禁机制

6. 最容易被忽略的部分

  • 失败样例回放
  • 成本上限
  • 人工接管点
  • 审计日志
  • 对旧仓库和脏仓库的适配

这些往往比“模型名称”更能体现你的工程成熟度。


7. 进一步学习