用真实 Angular 需求检验模型能力

公开榜单上只差几分的模型，放进真实前端仓库，交付质量可能相差一整个档位。作者让 8 个模型连续完成同一组 20 张 Angular 需求单，再请 4 人盲评，结果前三名集中在 7.5～8.25 分，其余只有 3.5～4.75 分。

这次实验最有价值的地方，是把「功能能运行」和「代码值得合并」分开了。它提供了一套团队可以借鉴的选型方法，但不足以证明某家厂商在所有开发场景中领先。

榜单分数接近，为什么交付质量可能差很远

作者引用的是 2026 年 10 月 25 日的 Artificial Analysis 快照。其 Intelligence Index v4.3.2 汇总了 10 项评测，覆盖 Terminal-Bench、GDPval、SciCode 等任务。

榜首确实很挤：Opus 5.5 得到 58 分，Sonnet 5.5 和 Muse Wonder Full 为 56 分，Kimi K3.1 Pro 为 55 分，Fable 5.1、GPT-6 Astra、Gemini 4 Argon 均为 53 分，Muse Wonder 为 52 分。8 个模型只差 6 分。

如果再看价格，便宜模型更有吸引力。GPT-6 Luna 每项任务约 0.07 美元，Fable 5.1 则是 7.63 美元，相差约 100 倍。GPT-6.1 Sol 的综合指数为 52，每项任务不到 1 美元。

但综合能力接近，不代表适合处理同一个仓库。

作者提出三个原因：公开题目可能进入训练数据；厂商会围绕榜单优化；测试通过与团队愿意接手代码之间存在距离。前两点解释榜单可能受到的影响，第三点直接关系到程序员的工作：功能实现了，仍可能遗漏文档、扩大修改范围，或者留下大量重复逻辑。

选模型时，需要测的是自己的交付要求，而不只是模型能否答对题。

价格也受配置影响。公开评测中，Sonnet 5.5 在「max with fallback」下每项任务花费 5.46 美元，接近 Opus 5.5 的 5.98 美元。作者自己的实验改用 high，Sonnet 的成本明显降低。他反对真实工作使用 max，但这仍是个人经验，原文没有给出同一批任务的完整配置对照。

这场盲评怎样接近真实的前端开发

实验对象是作者开发的企业级 Angular 组件库，包含 secondary entry points、作为文档的演示应用、严格风格规范、AGENTS.md，以及 Cypress e2e 测试。

20 张需求单提前冻结，并用每张单子的「Decisions」区块确定已知争议。第 1～16 张扩展已有组件，第 17～20 张新增状态徽章、AG Grid 主题、进度指示器和面包屑。

所有模型从同一提交开始，接收相同提示和仓库规则：每张需求单提交一次；在新上下文中自审，再通过 amend 合入修订；每次提交前，lint、库构建、应用构建和涉及的 e2e 都要通过。模型不能追问，未明确之处自行决定并记录假设。

不过，执行工具没有统一。Claude 模型使用 Claude Code，GPT 使用 Codex CLI，Gemini 使用 Antigravity，Grok 使用 Cursor。因此，这次测量的单位实际是「模型与执行工具的组合」。

评审分四个角度进行：

• 需求作者抽查 5 张单子，判断实现是否符合原意。
• 功能测试者检查 19 张单子，用鼠标和键盘寻找问题。
• 资深开发者抽查每个分支的 4 个提交，判断能否直接合并。
• 作者阅读全部 20 张单子的代码，检查风格与维护质量。

分支和演示应用经过匿名编号；作者原本知道模型映射，评审时又使用重新编号的副本，评分完成后才查映射。最终分数取四项评审中位数的简单平均。4 人总共投入超过 20 小时。

结果形成两个明显区间：Opus 5.5 为 8.25 分，Sonnet 5.5 为 7.75 分，Fable 5.1 为 7.5 分；Gemini 3.8 为 4.75 分，Grok 4.7 和 GPT 6.1 Sol 均为 4.25 分，GPT 6.0 Luna 为 3.75 分，Haiku 5.5 为 3.5 分。

同一家厂商内部也差距很大。Haiku 的代码质量得到 6 分，还贡献了一次用表替换 200 行 switch 的重构，但功能测试和可合并性均只有 1 分，因为它遗漏功能、破坏已有行为。

最便宜的实现，可能把费用留给代码评审

Gemini 3.8 是最能说明问题的样本。

它的功能测试得到全场最高的 9 分，每张需求单仅花 1.31 美元。但需求意图为 6 分，可合并性为 3 分，代码质量只有 1 分。

作者的评审记录指出，它堆叠防御判断，留下无效的 ?? [] 回退，同一个表达式复制了 8 次，并引入两处已有组件的回归。抽查的需求中，还有一张因缺少文档和演示，无法按需求作者的预期检查。运行期间，它因上下文满而重启一次，又违反提示要求，停下来提问三次。

这里的关键是，功能测试只代表其中一个观察角度。能通过交互检查的代码，仍可能在其他提交、文档完整性和维护要求上失败。

成本曲线因此发生变化：GPT 6.1 Sol 每张单子花 0.71 美元，得到 4.25 分；Gemini 3.8 花 1.31 美元，得到 4.75 分；Sonnet 5.5 花 1.46 美元，却达到 7.75 分。相比 Gemini，每张多花 0.15 美元，就进入了作者认为可继续开发的区间。

Opus 5.5 每张花 7.20 美元，20 张共运行 3 小时 34 分钟；Fable 5.1 每张花 11.18 美元，用时 5 小时 10 分钟。Sonnet 以约五分之一的费用拿到 Opus 约 94% 的分数，是此次实验中的性价比选择。

但「94% 的评分」不等于「94% 的生产力」。它只是这套评分规则下的比例，尚未计入实际返工时间。

我的判断

我认同这套评估方向：需求理解、功能正确、可合并性和维护质量，都应该进入 AI 编程的验收范围。Fable 因越界重构被扣分，也提醒团队，主动改进未必总能提高交付价值。

但作者把结论扩大为「前端代理编程应使用 Anthropic」，证据还不够。

首先，每个模型只有一次连续运行，没有重复实验或波动区间。后面的需求还会受到前面修改的影响。其次，工具和推理配置没有统一：Fable 使用 medium，多数模型使用 high，Luna 与 Haiku 使用 xhigh。结果可以支持这些具体组合的比较，无法单独归因于模型能力。

此外，Muse Wonder Full、Kimi K3.1 Pro、GPT-6 Astra、Gemini 4 Argon 都没有参加这次盲评。作者对它们，以及中国开放权重模型落后 3～6 个月的判断，不能由这组结果推出。对 Gemini 4 Argon 的评价也只是最初几天的使用感受。

成本同样要保留边界。8 次运行完成 158 张需求，按 API 标价约 613 美元；作者估算人工每张需要 2～4 小时，以每小时 50 欧元计算。这不是人工对照实验，不能据此认定真实项目已获得相同比例的节省。

原文还称，同一 Sonnet 5.5 在 OpenCode 中每张成本约为 Claude Code 的一半，在 Pi 中约为其 60%。但提供的内容到工具讨论前便结束，没有展开测试方法，这两个比例适合当作后续验证线索。

这次实验足以改变作者团队的选型，尚不足以替其他团队完成选型。

能拿来做什么

• 从自己的前端仓库挑选一组真实需求，兼顾组件扩展和新组件开发，并提前写清验收标准、文档要求与允许修改的范围。
• 分开记录功能正确性和可合并性。检查 AI 改动时，除了跑测试，还要看演示是否齐全、逻辑是否重复、是否引入无关重构。
• 比较完整的使用组合，把模型、执行工具、推理强度和仓库规则一起记录。先固定其他条件，再调整其中一项，才能判断差异来自哪里。
• 按「获得可合并结果的成本」记账，记录 API 费用、运行时间、评审时间和返工时间；小任务可以尝试低价模型，但是否进入主开发分支仍由实际验收决定。