这可能是全网第一个大模型复杂工程能力测试~

为什么大模型总是漏需求? 为什么我用的模型一改我的代码就改坏了? 今天就给大家揭开这个谜底.

我设计了一个大模型工程能力测试, 方法很简单, 给大模型一个需求文档, 然后让大模型使用 Coding Agent 来按照需求修改项目.

项目是 SillyTavern, 就是大名鼎鼎的酒馆. 这个咱们当作「试卷」.

需求文档就是「考题」, 内容是给酒馆增加一个动态数值系统.

大家如果玩过类似的AI角色扮演肯定会有体会, 让大模型用上下文模拟一些数值或者buff, 玩过几回合大模型很可能就忘了, 而且极消耗token.

咱们这个动态数值系统就是内置了一个数值引擎, 大模型可以通过写代码的形式定义数值, 比如定义了一个「吃撑了」的buff, 会在10个上下文内力量+10, 系统就会自动在10回合内应用buff效果. 计时结束后自动取消buff.

这一切只需要在第一次聊天的时候模型调用　tool_call　生成这个　buff　让数值系统执行就可以了. 剩下的10回合大模型完全不需要消耗任何上下文.

是不是听上去特别猛? 猛的代价就是这个需求足足有 21000 token. 所以作为工程能力测试足够了.

首先排行榜第一名是我人肉 vibe coding 的版本. 需求完成度 97.7%.

然后我直接对比了 Kimi-K2.7-Code 与 kimi-k2.6, 其中 kimi-k2.7 能把需求完成93%, 而 kimi-k2.6 只能完成74.4%. 另外 DeepSeek-V4-Pro 只能完成68.6%.

完成的最好的 kimi-k2.7-Code 几乎与我手动 VibeCoding 的版本没区别, 而且它的代码风格也比 VibeCoding 改来改去的要好.

而 kimi-k2.6 分数没有 k2.7 高的主要原因是在制定 Plan 的时候就已经走歪了, 漏掉了需求.

而漏掉的这些需求恰好有一些共性, 它们没有自动化测试, 而完成得好的部分, 恰好在写代码之前就已经写好了黑盒测试(TDD).

这其实就揭示了漏需求或者改坏代码的模型的共性——「注意力管状视野」, 即模型只关注那些自己认为重要的任务, 这些任务非常容易验证修改.

而漏掉的则是web界面, 提示词注入, 命令行快捷指令这些, 需要自己先根据需求文档推理一番, 然后还要自己动脑设计一下该怎么做才能得出 Plan 的需求.

这些都是大模型管状视野的特征: 大模型会挑活干, 然后就漏需求了.

测试中 DeepSeek-V4-Pro 就更离谱了, 它没用 Agent 的 Plan 工具, 而是自己写了个纯文本的 Plan, 然后也没使用这个 Plan 追踪自己的进度. 导致到处都在遗漏需求. 所以这里是 DeepSeek 的 Agent 能力拖了后腿, 它没有利用提供的 Plan Agent 来管理任务状态.

从目前的测试来看, Agent 能力, 任务二次推理拆分, 以及模型的全局注意力能力是模型工程能力的关键.

而这次 Kimi-K2.7-Code 的表现, 则是真正的生产力拐点了. 从 K2.6 的 74.4% 到 K2.7 的 93%, 这近 20 分的提升, 直接跨过了人是否需要中间干预的鸿沟. 证明了只要全局注意力足够强, Agent 能力拉满, AI 完全可以在复杂项目里精准修改, 甚至接近有经验的工程师的 Vibe Coding 的完成度!

Kimi-K2.7-Code 这次的提升, 可谓是国产代码大模型的一记重拳了. 目前其他主流模型我也在测试中, 稍后全量对比结果同步给大家~

#HOW I AI#