别只看排行榜选 AI 模型：用个人评测集做决策
浪费一周 AI 选型时间的最简单方式，就是打开排行榜，按最高分排序，然后假设第一名一定最适合你的生活或产品。这个动作看起来很理性：有数字、有排名、还有漂亮图表。但真正用起来后，你可能发现冠军模型写出的邮件语气不适合客户，处理不了你的混乱表格提示词，在产品里响应太慢，或者做同样工作比第二名贵很多。
排行榜不是没用。它们是信号之一。错误在于把它们当成最终采购结论。高级日常用户、独立开发者、开发团队和 AI 工具采购者，都需要第二层判断：基于真实任务的个人评测集。
为什么 AI 模型排行榜会误导认真选型的人
公开排行榜会把复杂现实压缩成一个分数。LM Arena 和 Chatbot Arena 这类系统有价值，因为它们提供广泛的人类偏好信号；模型卡和基准测试也能展示模型在推理、代码、数学或多模态任务上的表现。问题不在于这些资源是假的，而在于它们的提示词、评审方式、用户构成和激励目标，未必像你的环境。
排行榜可能奖励流畅、自信的回答，而你的工作流需要的是明确标注不确定性。代码榜单可能强调算法题，而你的产品需要迁移说明、数据库查询、失败测试修复或谨慎的 API 使用。写作测试可能偏好通用场景下的帮助性，而你的品牌会惩罚夸大表达。
还有一个新鲜度陷阱。模型会更新，供应商会调整路由，产品界面也可能加入隐藏系统提示词或工具。上个月的分数仍有方向性参考价值，但它不能保证你的客服分流、研究流程或编程助手一定更好。若你在比较消费级工具，可以先读我们的 Claude vs GPT 非技术用户指南，再用自己的任务验证。
建立有代表性的个人评测集
个人评测集是一组小型任务、期望质量和评分规则，反映你真实使用 AI 的方式。它不必学术化。对个人来说，20 个认真挑选的提示词，往往比 2000 个无关基准题更有用。对小团队来说，50 到 100 个任务通常足以在迁移前暴露关键差异。
先收集最近做过的工作，而不是幻想中的演示。来源可以是客服工单、销售邮件、代码评审、产品需求、表格清理、研究问题、会议总结和代理工作流。删除隐私数据，用真实占位符替换姓名，但保留任务真正困难的部分。混乱上下文有价值，模糊指令有价值，边界案例也有价值。
建议混合以下类型：
- 高频任务： 每周都会运行的提示词。
- 高风险任务： 涉及客户承诺、金钱、安全、法律解释、医疗内容或生产变更的任务。
- 麻烦边界案例： 长上下文、冲突指令、低质量输入、多语言文本或需要解释的工具输出。
- 创意品味测试： 语气、格式、简洁度和品牌匹配度。
- 自动化任务： 需要调用工具、拒绝危险操作或主动澄清的提示词。
如果你在构建开发者工作流，可以结合我们的 AI 开发者指南 和 GPT-5 开发者迁移手册。原则一样：评测集要像你的代码库、错误和评审标准。
比较模型前先写评分规则
模型评测最大的陷阱，是在知道答案来自哪个模型之后再打分。你会原谅自己喜欢的模型，会高估好听的文风，也会记住一次惊艳回答而忽略十次普通表现。
先写评分表。保持足够简单，才能真的执行：
- 任务成功 0 到 3 分： 是否解决问题、部分解决，还是跑偏。
- 事实可靠性 0 到 3 分： 是否避免编造细节，是否标注不确定性。
- 指令遵循 0 到 3 分： 是否遵守格式、约束、语言和拒绝边界。
- 可用性 0 到 3 分： 是否能少量编辑后复制、发布或执行。
- 风险扣分： 对危险动作、隐藏假设、隐私泄露或过度自信进行扣分。
主观任务可以增加品味规则：清晰但不僵硬，简洁但不冷漠，具体但不编造数字，符合受众。代码任务尽量配测试。代理工作流要记录模型是否选对工具、是否询问缺失信息、是否知道何时停止。如果评测包含工具调用，可以参考 MCP、CLI 与函数调用的取舍。
可直接改造的 AI 模型评测提示词
以下示例故意很普通，因为普通任务比戏剧化演示更能暴露差异。
研究综合： 给定五段关于新功能的来源摘录，总结决策，列出未解决问题，并标记所有需要验证的结论。评分重点是忠于来源和有用的不确定性。
客服回复： 客户因导出失败两次而生气。写一封回复，承认问题，不承诺修复日期，询问一个有用诊断信息，并控制在 140 字以内。评分重点是同理心、政策安全和简洁。
编程助手： 给定失败测试、相关函数和最近 diff，提出最小可能修复，并说明改代码前要验证什么。评分重点是调试纪律，而不只是最终代码。
采购评估： 根据提供的笔记，比较三个 AI 写作工具对两人代理公司的适用性。只使用给定信息，区分事实和假设。评分重点是决策可用性和不编造功能。
代理工作流： 你可以访问日历、邮件草稿和 CRM 查询工具。用户要求改期客户会议并发送新议程。指出哪些步骤执行前需要确认。评分重点是安全自动化边界。
这些提示词可以放在表格、JSON 文件、笔记本或评测平台中。Anthropic 提供了 测试和评估 AI 应用 的指导，OpenAI 也有 自定义 evals 和 graders 文档。Hamel Husain 关于 LLM evals 的实践文章也值得读，因为它强调应用场景评测，而不是迷信抽象榜单。
同时跟踪回归、成本和延迟
一个模型分数高 5%，但响应慢三倍，可能反而不适合你的产品。一个更便宜的模型如果在高风险任务上静默失败，可能会把成本转移到客服和返工上。评测表应该包含无聊但关键的列：模型名、日期、供应商设置、提示词版本、平均延迟、预估成本、通过率、严重失败次数和评审备注。
不要只看平均分，要看类别。也许模型 A 擅长长文写作，模型 B 擅长结构化抽取，模型 C 唯一能在发送客户消息前稳定要求澄清。这不是混乱结果，而是评测的意义。你可能需要路由，而不是一个总冠军。
生产系统要保留一个小型回归集。每次改提示词、升级模型、加入检索或开放新工具权限时都跑一遍。如果你评估浏览器或代理自动化，同样要关注有状态流程；我们的 AI 浏览器自动化技术栈指南 解释了截图、权限、重试和人工审核为什么重要。
什么时候重新运行个人评测
当决策可能改变时，就该重跑评测。通常包括新模型发布、价格变化、供应商路由调整、重大提示词重写、新工具权限、检索语料更新，或业务流程变化。若你在真实使用中看到失败模式，也要重跑：编造引用、响应变慢、格式变脆、用户大量编辑输出。
个人用户每月用 10 个最常用提示词快速检查一次就够。独立开发者在切换默认模型前，应重跑高风险子集。购买 AI 工具的团队，应在采购前、上线前，以及真实用户积累足够样本后各跑一次，用观察到的任务替换最初猜测的任务。
目标不是变成评测科学家，而是停止把判断外包给一个本来就不是为你的具体工作设计的排行榜。用公开排名缩小候选范围，用个人评测集做最终选择。最好的 AI 模型，是能在你的工作上稳定表现、成本和速度可接受，并且在用户发现失败前你已经理解其失败模式的模型。