M3在SWE-Bench上得分不错，但让我印象深刻的并非分数，而是那些无法用基准测试衡量的东西。

m3 刚刚发布，基准测试分数不错：SWE-Bench Pro 59.0，BrowseComp 83.5，再加上人们已经在争论的 agent/tool 分数。但我反复在想的是：这些数字没有一个真正衡量了那些浪费我时间的编码 agent 的问题。Claude Code 和 Cursor 在需要快速独立脚本或 UI 微调时很棒。但如果把一个 agent 丢进一个混乱的遗留仓库，要求它做跨文件修改，它就会崩溃。agent 修复了一个文件，破坏了另一个文件中的未记录依赖，然后开始修补自己制造的漏洞。四十分钟后，你的 git 历史看起来像犯罪现场，你会想为什么当初不自己写。每个人都在追逐同样的解决方案：更大的上下文窗口、更高的基准分数、更多的 token。假设是，如果模型足够聪明，它就不会再犯愚蠢的错误。但在实践中，我遇到的大部分失败并不是因为原始智能。而是因为模型不知道自己不知道什么，直接冲进去打补丁，却没有检查要编辑的东西是否与五个其他文件纠缠在一起，这些文件由三个不同的团队维护了四年。所以当 m3 发布时，我没有让它写代码来测试。我测试的方法是，在写任何代码之前先问它可能出什么错。我把它指向我维护的一个项目中的功能变更：更新一个内部 API 接口，该接口被几个下游服务依赖。不是一个大任务，但是那种粗心的重构会制造无声的 bug，三天后出现在生产环境中。在让它碰任何东西之前，我问：“浏览这个仓库，告诉我你在做这个修改之前想要验证什么。哪些文件有风险？当前接口隐含了哪些假设，一个天真的重构会忽略它们？你会把验证检查放在哪里？”返回的不是待办列表或代码片段。它更像是一个“事前验尸”。它通过它能找到的每个导入路径追踪了接口，并标记出哪些下游调用者依赖隐式类型转换而不是显式契约。它指出了两个看起来像是死代码但实际上通过配置文件中隐藏的动态导入被调用的包装函数。它建议了哪些测试文件覆盖了快乐路径但没有覆盖重构会产生的边缘情况。它还提出了一个顺序：先运行这些特定测试，然后按这个顺序修改这些文件，并在继续之前在这三个检查点停止并验证。老实说，这些东西通常是我在调试失败的构建二十分钟后，滚动浏览 grep 结果，嘀咕着“谁写了这个包装器，它为什么存在”时，才会艰难地弄清楚。模型在写一行代码之前就发现了大部分问题。这就是让我印象深刻的地方。不是基准分数。不是每秒 token 数。只是它在拿起锤子之前试图构建一个故障地图。现在，问题来了。有时候它会过度处理。对于较小的改动——比如只是重命名一个参数并更新六个调用点——它还是会给你完整的风险评估待遇：依赖图、测试差距分析、建议的回滚计划。如果你在重构支付管道，这很有用；如果你在修复日志消息中的拼写错误，这就很烦人。模型默认进入审计模式，你必须明确告诉它“这只是小改动，只检查明显的部分，然后继续”。但老实说？我愿意接受这个交换。我被过于自信的补丁坑的次数远多于过于谨慎的。一个在行动前问“这里可能会出什么问题”的 agent，比一个在基准上高 5% 但仍然会在生产环境中搞崩我构建的 agent 更接近我真正想要的。更新后的 minimax 代码工具在这个背景下也很有趣。他们将一个生产者 agent 与一个完全独立的验证器配对：单独的会话，没有共享历史，验证器只看到提议的修改和原始规格。如果生产者的“事前验尸”输出变成了验证器的检查清单，你就得到了一个看起来不太像 vibe coding、而更像是实际审查过程的东西。我仍然对验证器在底层模型相同时究竟有多独立持怀疑态度，但从概念上讲，这种形状符合问题。我并不是说 m3 是最快的编码器或最好的日常驱动。Opus 在什么时候该闭嘴直接写函数方面仍有更敏锐的本能。但 m3 是我用过的第一个模型，它的补丁前风险评估感觉像是我真正想在工作流中拥有的东西，而不是一个两天后我会忽略的花哨功能。有人试过用这些模型来执行“三思而后行”步骤，而不是编码本身吗？在小型任务上，过度谨慎会不会碍事，还是你只是学会了以不同的方式限定提示范围？