需求中心
选择测试需求
先选择一项需求，再查看该需求绑定的截图、评分与参赛信息。
模型总榜
大模型评测榜单
按各需求的加权平均得分排序，同时展示用户打星评分。
效率与质量
加权平均耗时与加权通过率
横轴为各需求按需求权重计算的加权平均耗时，纵轴为各需求加权通过率的需求权重平均值。点击图表空白处可放大，点击散点可查看该模型已测试的需求。
阅读方式：越靠左上越好，代表耗时更短、加权通过率更高。
Token 效率
Token 用量与加权通过率
横轴为按需求权重计算的加权平均 token 用量，纵轴为按需求权重计算的加权通过率；credit usage 模型不计入。
阅读方式：越靠左上越好，代表 token 更少、加权通过率更高。
测试记录
意外情况
记录该模型在当前需求测试过程中出现的未预期行为或其他 badcase。
最终测试结果
需求排行榜
按人工评分复核记录汇总排名、得分与每个测试用例的通过状态。点击“通过”或“未通过”状态可查看对应说明；在测试用例说明中可点赞或踩。
测试用例数量读取中
测试基线
需求上线
执行指令
测试 Prompt
参赛配置
Agent 软件与版本
橙色模型名代表多模态模型
| 模型 | 软件 | 版本 | 上下文 | 思考等级 | 测试状态 |
|---|
测试方法
统一测试方法
所有参赛 Agent 使用同一套环境约束、提示词与验收标准完成测试需求。
测试基线
同一项目与同一任务
测试基于每项需求各自指定的基础 commit 与需求基线，所有 Agent 都要完成该需求对应的同一项测试任务，并提交自己的 commit，无需 push。
执行环境
保持参赛条件一致
所有测试均基于 macOS 环境进行；统一使用最大思考强度、最大上下文和 yolo 模式；确认 Agent 能读取项目根目录的 AGENTS.md，并关闭记忆功能。
隔离方式
先创建独立 worktree
每位参赛 Agent 先使用相同的 git-worktree skill 创建 worktree，再在各自工作区内执行后续任务，避免互相污染。
验收数据
统一验收数据
根据当前测试需求准备一致的演示数据与验收环境，检查功能结果、页面反馈、日志记录和实际产物。
测试数据与验收要求随需求归档
执行流程
从准备到验收
- 准备工作区：创建独立 git worktree，确认项目基线、AGENTS.md 和 Agent 运行参数。
- 执行任务：先发送统一的首个 prompt，再发送当前需求对应的任务 prompt；任务期间 Agent 自行完成决策，不咨询用户。
- 启动与检查：启动开发服务，使用统一验收数据检查页面、接口、日志和实际产物。
- 记录结果：按测试用例逐项记录通过状态、失败等级、截图和最终得分，同时收集用户对结果的打星评分。
第一步
首个 Prompt
使用 git-worktree skills 创建一个 worktree，等待我的下一步指示
第二步
当前需求 Prompt
每项测试需求使用对应的统一任务 Prompt。具体内容请在左侧选择需求后，查看「需求信息」中的「测试 Prompt」。
评分规则
测试用例与用户评分
统一满分：后续所有需求的测试满分都是 200 分，会根据测试用例数量动态调整扣分策略。
测试用例评分：根据评测配置动态计算，总分为 200 分，扣分策略会随测试用例数量调整。
加权通过率：单项需求按最终得分除以满分计算，不同优先级失败用例的扣分不同；模型总榜再按需求权重对各需求的通过率求平均。
加权平均耗时：将模型在各需求中的实测耗时按需求权重求平均，仅统计已记录有效耗时的需求。
用户打星评分：用户可对每个 Agent 的最终结果进行 1—5 星评分，单独展示在排行榜中。
FAQ
为什么不用统一的 harness 工具来测试？
回答：本测试是以偏向真实环境为出发点开展的。若所有模型都使用相同的 harness，虽然控制了变量，但和真实环境会有偏差（比如很少会有人在非 Claude Code 里面用 Claude 模型，很少有人会在非 WorkBuddy 里面用 Hy3 等等）。此外，网上已有博主制作过在相同 harness 下的多模型测试，可参考其他博主的测试。
多模型并列