为你的产品找到最合适的 AI 模型

在 AI 应用快速普及的背景下，模型选型已成为产品开发中一个被低估的工程难题。OpenRouter 在其博客中指出，尽管平台上可供选择的模型已超过 500 个，大多数团队在做选型时仍缺乏系统性方法——要么依赖社交媒体上的口碑推荐，要么参考通用基准排行榜。这些信息源本身有价值，但它们的共同局限在于：测试的是固定任务集，反映的是他人的应用场景，而非你自己的提示词、数据和业务逻辑。

Ori Eval 的使用入口极为简洁：在编程 Agent 中执行一条 curl 命令，工具便会自动接管后续流程。它首先扫描代码库，找出所有调用模型的位置，展示对应的使用场景、文件路径和当前使用的模型。随后，它会向开发者提问，确认评测覆盖范围以及最看重的指标——准确率、速度、成本还是其他维度。整个过程无需开发者具备任何评测经验，Ori Eval 会像一位有经验的工程师朋友一样引导你完成配置。

完成信息收集后，Ori Eval 自动生成一个 review.eval.ts 文件，并将 Agent 同时运行在 5 个候选模型上，输出一张多维对比表格，涵盖 bug 命中率、P50 延迟、每次 PR 的调用成本以及是否通过评测等字段。推荐结论不只是一个模型名称，还附带具体理由，例如在成本约束内命中率最高的选项，以及当业务量增长时的性价比备选方案。这种透明度让选型决策有据可查，而非凭感觉拍板。

评测文件的核心是一个以 bun test 运行的 TypeScript 文件，它从三个维度检验 Agent 的行为：Agent 是否调用了预期工具、是否避免了不该调用的工具、以及答案质量是否达标。对于开放式问题，Ori Eval 引入 LLM 作为评判者，开发者可以自定义评分标准和最低分数线。这套机制同样适用于 bug 复现场景——用自然语言描述一个已知问题，Ori Eval 会将其转化为可执行的断言，让 bug 从描述变成可测试的用例。

Ori Eval 的另一个关键设计是与 CI/CD 流程的深度集成。评测文件本质上是代码，可以直接加入 GitHub Actions 工作流。评测失败会导致构建失败，从而阻止回归问题进入生产环境。此外，开发者还可以设置定期自动运行，当有新模型发布且表现优于当前使用模型时，系统会自动开启一个 Pull Request，开发者只需合并即可完成模型升级，无需手动介入评测流程。

从工程实践角度看，Ori Eval 将模型选型从一次性的主观判断转变为可重复、可验证的工程流程。OpenRouter 在设计上刻意降低了使用门槛：预置了最优的评测框架和评判模型，开发者无需从零配置。由于路由层覆盖 OpenRouter 支持的全部模型和厂商，评测结果具有横向可比性。对于正在将 AI 能力嵌入产品的团队而言，这套工具提供了一种将模型治理纳入常规工程实践的可行路径。

要点

• Ori Eval 通过扫描代码库自动定位模型调用点，无需开发者手动编写评测用例，大幅降低评测门槛。
• 评测结果以多维表格呈现，涵盖命中率、延迟、成本等指标，推荐结论附带可解释的理由。
• 评测文件以代码形式存在，可集成进 CI/CD 流程，实现回归拦截和定期自动模型比较。
• 支持将自然语言描述的 bug 转化为可执行断言，让已知问题成为持续监控的测试用例。
• 通过 OpenRouter 路由层，评测覆盖全部 500 多个可选模型，具备跨厂商横向对比能力。