在真实后端上跑分，不是做选择题
场景取自真实的支持工单、Bug 报告和 GitHub issue，覆盖建 schema、调试报错的 Edge Function、修坏掉的 RLS 策略等任务，并按产品、主题和 build / deploy / investigate / resolve 四个阶段编排。每个场景都跑在容器里的真实环境：智能体调用真正的 MCP server 和 CLI，评分由确定性检查（SQL 校验、以模拟用户身份发起客户端调用、检查生成的文件）加 LLM 裁判组成，评分前允许一次重试。公开的 benchmark 场景负责覆盖广度，另一套每日刷新的 regression 场景盯已知失败模式，不计入公开分数。
技能文件的增量比模型差距更明显
按 Supabase 公布的首批快照，build 阶段在不加载技能文件时，Opus 5 与 Kimi K3 已经满分通过；Sonnet 5 从 78% 提升到 100%、GPT-5.6 Sol 从 89% 到 100%、GPT-5.4 mini 从 78% 到 89%，缺口主要由 Supabase 自带的上下文文件补上。另一处差异在查文档：Codex / GPT-5.6 平均每个场景读约 8 页文档，Claude Code 约 2 页，即使加载技能，也只有不到四成场景会去翻文档。Supabase 还提到，把 Postgres 最佳实践技能的描述重写后，它被激活的比例从约十分之一升到六成。
怎么用这份榜单
这是厂商围绕自家产品做的基准，测的是「智能体会不会用 Supabase」，不该当成通用编程能力排名，分数也只是发布时的快照。它更实在的价值在于把提示词、评分器、运行时和实验配置一并开源：做 SDK 或 API 的团队可以照着给自己的产品搭一套 agent 回归测试，用同样的方式验证自家的技能文件和文档改动到底有没有让智能体少犯错。
via: Supabase 官方公告 Introducing Supabase Evals、supabase/evals 仓库、MarkTechPost 报道；核实于 2026-08-03