周三下午，一个后端工程师第无数次关掉了AI审查工具的弹窗。不是没报错，是报得太多了——十个警告里八个是风格偏好，剩下两个还看漏了真正的空指针。团队 sprint 还没结束，这个"智能助手"已经被集体静音。
问题出在哪？上线前没人认真测过。聊天机器人可以靠"有帮助吗"的点赞混过去，代码审查不行。一个模型能揪出五个真bug带一个误报，和只找到一个真bug塞五个噪音，在开发者体验上是天壤之别。离线评估要做的，就是在部署前回答这个问题：这条代码该路由给哪个模型，什么时候该升级人工，整个系统是在变好还是变坏。
建评测集的第一步是挖历史PR，但得狠下心过滤。作者秒关的评论、审查者自己认错的评论、代码已经被删掉的评论——这些标签不可靠，必须剔除。最后剩下的是（代码变更、发现问题、接受/拒绝）三元组，人标的结论足够可信，才能拿来当标准答案。
但光有三元组不够，得切三刀看细节。第一刀是变更类型：专治空指针的模型可能完全看不懂并发bug，如果你的评测集90%是风格问题，分数再高也说明不了正确性能力。第二刀是文件归属：后端服务上表现好的评估器，砸在前端组件上可能直接崩盘。第三刀是语言：Python里类型是可选注解，TypeScript里类型是结构契约，同一套打分逻辑跨语言就是失效。单一总分会把这些失败全藏起来，必须分片单独算。
精度和召回的权衡在代码审查里有明确偏向。漏掉真bug是机会成本，误报是信任成本——而后者是非线性崩塌的。一个PR里出现两到三个垃圾评论，开发者就会开始条件反射式忽略，之后信噪比再好看也没人读了。底线是召回率0.7以上、精度0.85以上，才能让人看到输出。
标签体系也别搞二极管。硬拒绝（事实错误或有害）、软拒绝（ valid 但价值低，比如风格挑刺或边际改进）、接受（有效捕获）——这三档能算出不同严格度下的精度。只看硬拒绝精度，测的是"会不会害人"；软拒绝+硬拒绝一起算，测的是开发者实际容忍度。两个数字讲两个故事，路由决策都得用。
热门跟贴