AI Coding 评测、审查与治理¶
到 2028,真正有价值的 AI Coding 系统,不是“偶尔写对一段代码”,而是“长期、稳定、可治理地交付正确改动”。
1. 为什么评测比提示词更重要¶
没有评测,你无法回答:
- 这套系统到底有没有提升成功率?
- 它只是会写样例,还是能处理真实仓库?
- 速度、成本、正确率之间是什么 trade-off?
所以 AI Coding 的核心问题,最终都会落到:
- 任务定义
- 验收标准
- 自动化检查
- 人工复核
2. 至少要评什么¶
| 维度 | 典型指标 |
|---|---|
| 正确性 | 测试通过率、任务完成率、回归率 |
| 工程质量 | 代码风格、可维护性、架构一致性 |
| 效率 | token、延迟、步骤数、人工介入次数 |
| 稳定性 | 同类任务波动、长任务中断率 |
| 安全性 | 越权工具调用、危险命令、数据泄露风险 |
| 成本 | 单任务成本、平均重试成本、失败成本 |
3. 评测分三层¶
只有把评测分层,你才能知道问题究竟出在单次输出、任务闭环,还是团队治理机制。
3.1 单任务层¶
适合检查:
- 单文件修改
- 单函数修复
- 单元测试补全
3.2 仓库任务层¶
适合检查:
- 多文件改动
- 架构一致性
- 回归风险
3.3 生产治理层¶
适合检查:
- 工具权限
- 审计日志
- 回滚能力
- 人工门禁策略
4. 审查链路建议¶
一个更接近真实团队的链路是:
高风险改动一般包括:
- 数据库 schema
- 权限与认证
- 删除逻辑
- shell / infra 变更
- 影响核心链路的架构调整
5. 你简历里的“评测与治理”应该怎么写¶
不要只写:
- 做了一个 AI Coding Agent
更应该写成:
- 构建仓库级代码修改与审查系统
- 支持符号检索、按行读取、测试回归与结果审计
- 建立
X类任务评测集,任务成功率从A提升到B - 设计只读/可写工具边界与人工门禁机制
6. 最容易被忽略的部分¶
- 失败样例回放
- 成本上限
- 人工接管点
- 审计日志
- 对旧仓库和脏仓库的适配
这些往往比“模型名称”更能体现你的工程成熟度。