一句话看懂：AI 从业者 Madhu Guru 在 X 上指出，团队最常见的错误是把评估（evals）当成 agent 做完之后的附加 QA 步骤；他认为 AI 产品本质不同，评估本身就是产品规格说明书。这条观点引发了对“评估驱动开发”的讨论。
事件核心：发生了什么
2026 年 10 月 6 日，Follow Builders 社区的 Madhu Guru 在 X 发布了一段简短判断：多数团队把 evals 放在 agent 开发完成之后，当作质量检查环节来跑。他给出的替代思路是——对于 AI 产品，evals 不应该事后补，而应该在最前面定义清楚“什么叫做对”，它承担的是产品规格的角色。
这条帖子获得了约 3,112 次浏览和数十次互动，评论区出现了几个有代表性的回应。用户 @ItsGoharr 直接总结为“evals 才是产品，模型只是依赖项”；@iafineden 分享了自己做语言学习应用的经验：第一版评估只检查解释是否正确，真正改变产品的评估是检查系统是否会跳过学习者已经掌握的单词；@GoecolJohn 则强调，评估不只是验证产品能不能用，而是定义“能用”到底意味着什么。
为什么重要
传统软件可以用单元测试和人工验收来兜底，但大模型输出是概率性的，同一个 prompt 在不同上下文、不同模型版本下表现都会漂移。当团队把 evals 当 QA 用，通常意味着规格是模糊的，测试只能覆盖开发完成后能想到的边界，而真正影响体验的失败模式——比如多轮对话里丢失指令、工具调用参数错误、检索结果与回答不一致——往往在上线后才暴露。
把 evals 前置为产品规格，实际上改变的是研发流程：先定义任务成功标准和失败样例，再决定用哪个模型、怎么设计 prompt、是否需要微调或增加检索与工具调用。这也解释了为什么模型可以被替换，而 eval 集合和判断标准才是团队的长期资产。目前公开信息显示，这仍是工程实践层面的方法论讨论，并非某家公司的官方产品发布。
对用户/开发者/创作者的影响
对开发者而言，这意味着在调用 API、搭建 agent 或接入图像生成、语音等能力时，第一份该写的文档可能不是 PRD，而是评估集：包含正常样例、边界样例和已知失败样例，并能自动重复运行。模型升级、换供应商或调整推理参数之后，靠同一套 evals 判断是否真的变好，而不是只看 demo 观感。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
对产品团队和企业采购方，评估标准会直接影响选型与验收：如果一个 AI 应用无法说明自己的成功指标和回归测试方式，它在生产环境中的风险更难被量化。对内容创作者和独立开发者，@iafineden 那条评论提示了一个更实际的角度——最有价值的评估往往不是“答案对不对”，而是“这个产品有没有做它该做的事”。
值得关注的后续
一是这套“evals 即规格”的方法能否沉淀为可复用的开源评估框架或工具链，降低小团队的门槛；二是模型厂商是否会把评估能力和回归测试进一步做进 API 与平台侧，让评估像日志一样默认存在；三是当评估标准成为产品核心资产后，团队如何管理版本、防止评估集过拟合，这可能是下一轮讨论的焦点。
