别再迷信 SWE-bench 分数了
很多开发工具的 LLM 功能在 Demo 阶段看着很唬人，结果上线后用户反馈像抽奖。根本原因就是团队在做 Eval（评估）时逻辑混乱，把“模型说话像样”当成了“功能好用”。实操建议： 别用 LLM 当裁判，直接上编译器和测试套件。有 Ground Truth 就用 Ground Truth，能跑通才是正确。 核心判断： 这个输出是否真的让用户离目标更近了？而不是在增加认知负担。 重点检查： 是否泄露了环境变量？是否执行了未经确认的删库命令？是否被 README 里的 Prompt 注入给带跑偏了？
下一篇
NF4量化反量化速度能快1.41倍？ →
针对开发者工具，我认为评估必须死磕这三个维度，少一个都是在裸奔：
1. 正确性 (Correctness)
这是最简单的，非黑即白。代码能不能编译通过？单元测试是不是全绿？SQL 返回的结果对不对？
2. 实用性 (Usefulness)
这是最容易被忽视的坑。一个正确但没用的答案依然是垃圾。比如用户只想改一行代码，AI 给你写个 14 步的重构计划，虽然逻辑正确，但用户绝对想把它删掉。
3. 安全性 (Safety)
聊天机器人安全是指“不冒犯人”，但 AI Agent 的安全是指“别把服务器搞崩”。
总结一个结论：
如果你只测正确性，你会发现模型分数很高但用户在骂娘；如果你只测实用性，你会发现功能很流畅但代码全是 Bug。
一个合格的 Dev-Tool 评估工作流应该是：执行结果验证 (正确性) -> 用户意图匹配度 (实用性) -> 边界条件/权限压测 (安全性)
