夜雨聆风有个 C++ 任务，看起来简单到不像 benchmark：实现一个 LOG_WARNING()，然后把项目里所有打印 warning: 的地方，都改成用它。
模型写出来的代码能跑。输出也对。但维护者可能还是不想合。
问题就在这里。
软件工程里，行为一样，不代表设计一样。
这也是 Cognition 最近发布的 FrontierCode 真正值得看的地方。它不是又一个“谁家模型更强”的排行榜。它问的是另一个问题：
AI 写出来的代码，真实项目维护者愿不愿意合并？
我觉得这个问题比“测试能不能通过”重要得多。
因为代码生成正在变便宜。
但判断代码值不值得留下，正在变贵。
先说刚才那个 LOG_WARNING()。
任务来自一个 C++ 项目 jsonschema。需求很普通：实现一个日志辅助函数，用它统一输出 warning。这个函数要把内容打印到 stderr，自动加上 warning: 前缀，并且不受 --verbose 参数影响。
如果只看运行结果，模型很容易写出看起来正确的代码。
比如多行 warning。第一行用 LOG_WARNING()。后面几行继续直接用 std::cerr。
今天看，输出可能一样。但维护者不一定接受。
因为这段代码偷偷写死了一个假设：LOG_WARNING() 永远等于 std::cerr。
可这个假设不一定成立。以后 LOG_WARNING() 可能要加统一前缀，可能要接入结构化日志，可能要带线程信息，也可能要做别的封装。
到那时，裸露的 std::cerr 就会变成漏网之鱼。
这不是“代码错了”那么简单。
更准确地说，它现在没错，但把未来的变化空间堵住了。
测试通常只看现在。维护者会多看一步。
这一步，就是工程判断。
过去的 benchmark，更像考试
很多代码评测的逻辑很像考试。
给模型一个 issue。模型改代码。系统跑测试。测试过了，就算成功。
这当然有用。代码连测试都过不了，就不用谈质量。
但真实项目不是考试。考试题有标准答案。真实项目没有那么干净。
一个 patch 可能通过测试，但 reviewer 还是不想合。原因也不复杂：
- • 改动太大。
- • 绕过了已有抽象。
- • 测试没有抓住问题。
- • 风格不像这个仓库。
- • 解决了今天的 bug，却给明天的维护埋了坑。
这些东西很难靠普通单元测试完整表达。但它们每天都出现在 code review 里。
所以 FrontierCode 的转向很有意思：它把评测中心从“能不能过测试”，往“能不能被合并”挪了一步。
这一步看起来小，其实很工程。
因为真实软件开发里，PR 合并才是代码进入系统的入口。
代码质量，很多时候是克制
FrontierCode 很重视 scope。
也就是改动范围。
这个词不酷，但很关键。
我一直觉得，很多工程能力不是体现在“能改多少”，而是体现在“知道少改什么”。
修一个小 bug，就只动该动的地方。
- • 不要顺手重构半个模块。
- • 不要把无关格式一起改了。
- • 不要让 reviewer 被迫审一堆和问题无关的 diff。
这是克制。
人类工程师要学这个。AI 也要学这个。
AI 很容易多写。它看到附近代码不顺眼，就可能顺手改。它为了让测试过，也可能扩大改动面。
但在真实团队里，每一行无关改动都是成本。
- • review 成本。
- • 回归风险。
- • 以后排查问题的成本。
所以评估 AI coding agent，不应该只问它能不能完成任务。还要问它有没有控制住手。
能做是一种能力。
知道不该做什么，是另一种能力。
后者更接近成熟工程师。
测试也可能只是摆设
FrontierCode 还有一个方法，叫 reverse-classical testing。
名字有点绕，想法很简单：它检查 AI 写的测试到底有没有用。
做法是：把 AI 写的新测试拿回旧代码上跑。
如果旧代码也能通过，那这个测试就没抓住问题。
真正有价值的回归测试，应该在修复前失败，在修复后通过。
否则它只是长得像测试。
这件事很现实。
我们现在让 AI 写测试，经常会看到一堆看起来很完整的文件。命名对，结构对，断言也有。
但它到底有没有测到关键行为？
不一定。
测试的价值不在数量。
而在约束力。
它要能把错误拦住。
如果拦不住，再多测试也只是让人安心一点。
这种安心不可靠。
真正难的是理解一个代码库的脾气
FrontierCode 找开源维护者一起设计任务。
我觉得这个动作比排行榜更重要。
因为很多代码质量问题，只有维护者知道。
- • 代码是否符合项目风格。
- • 抽象是否自然。
- • 改动是否尊重已有设计。
- • 这个写法是不是这个仓库里的人会写出来的。
这些东西不是玄学。
它们来自长期维护一个项目的经验。
维护者知道哪些地方不能乱碰。知道哪些看起来奇怪的代码，其实背后有历史原因。知道哪些“更优雅”的重构，放在这个项目里反而会带来麻烦。
这些知识不一定写在 README 里。它们散在历史 PR、issue、代码习惯、团队默契里。
所以 AI 写代码的难点，不只是理解语法和 API。
它还要理解一个代码库自己的脾气。
每个成熟项目都有自己的脾气。
AI 不能只会写“正确的代码”。
它还得写“放在这里合适的代码”。
这也是我一直觉得从零实现有价值的地方。
不是因为造轮子本身多厉害。
而是你亲手实现过一个系统，才会知道一个抽象为什么长这样，一个边界为什么不能乱动，一个看似笨的设计为什么可能是活下来的结果。
这些判断，光靠读 API 很难长出来。
对程序员来说，价值会往判断上移
我不太相信“AI 替代程序员”这种粗糙说法。
真实发生的事更像是：写代码的成本下降了，但判断代码该不该留下的成本上升了。
这对程序员不是坏事。但它会改变能力重心。
以后你不该只和 AI 比谁写得快。更应该练的是判断力。
你要能看出一个 patch 为什么现在能跑、以后危险。
你要能看出一个测试是不是只是在装样子。
你要能判断一个改动是不是太大。
你要知道什么时候该让 AI 放手写，什么时候必须把边界收紧。
这不是唱高调。
这就是每天 review 代码时会遇到的事。
当代码越来越容易生成，真正稀缺的东西会变成筛选。
写出代码的人会很多。
知道哪些代码不该合的人，会更重要。
对团队来说，别只看通过率
如果一个团队在评估 AI coding agent，只看测试通过率，会有点危险。
测试通过率只能说明一部分问题。
团队还应该看真实成本。比如：
- • AI 生成的 PR 平均要改几轮？
- • 有多少次是因为 scope 太大被打回？
- • 它写的测试，有多少能在旧代码上失败？
- • 它有没有引入后续回归？
- • 它是不是经常违反项目约定？
这些指标不一定好看。
但它们更接近真实工作。
工程效率不是“代码写得更快”。
工程效率是从需求到稳定合并的总成本。
如果 AI 只是让前面写代码更快，却让后面的 review、调试和维护更慢，那它没有真正省时间。
它只是把成本换了个位置。
也别迷信 FrontierCode
FrontierCode 的方向是对的。
但它也不是标准答案。
它引入了维护者判断、rubric 和 LLM review，所以更接近真实工程。
也因为这样，它更难完全客观。
任务不公开，可以减少污染。但外部更难验证。
Rubric 能表达质量。但也可能带入维护者偏好。
LLM review 能评估一些软质量。但 LLM review 本身也需要被评估。
所以不用迷信它。
真正重要的是，它把问题问对了。
过去我们太容易把“通过测试”当成“会做工程”。
FrontierCode 至少把这两件事拆开了。
代码不是答案，是承诺
软件工程不是把代码写出来就结束。
代码会被阅读。会被修改。会被调试。会被下一批人继续维护。
一个 patch 被合并，不只是说明它能跑。
它还说明它没有把问题藏起来，没有把复杂度甩给后来的人。
所以我更愿意把代码看成一种承诺。
不是“我写完了”。
而是“这段东西可以留在系统里，别人以后接得住”。
AI 如果想成为真正的工程伙伴，也要学会承担这种承诺。
这一天还没完全到来。
但方向已经清楚了。
下一阶段，衡量 AI 编程能力的重点，不是它能生成多少代码。
而是它生成的代码，有多少值得留下。
