为什么评测比训练更重要

从「没有评测的后果」走到「评测的价值时间线」

「没有评测的后果」先把问题落在「飞行盲区：修一个 Bug，制造三个新的 没有评测体系的团队，每次改动都是一场赌博。你修了用户 A 反馈的问题，却可能悄悄破坏了用户 B、C、D 依赖的功能。更糟的是： 你根本不知道自己破坏了什么 ，直到下一波用户投诉涌来。 真实场景 用户反馈「Agent 这周明显变差了」，团队翻了三天 commit 记录，试了十几种回滚方案，最后发现是两周前一个看起来无害的 Prompt 微调导致的。如果有评测，这个问题会在合并代码…」上；到了「评测的价值时间线」，讨论继续推进到「早期 -- 定义成功 评测的第一个价值是 迫使团队定义成功长什么样 ，测试反而是其次。当你写不出 eval，往往说明你对任务的理解还不够清晰。这个过程本身就能帮助产品经理更好地理解需求。 中期 -- 回归测试 & 变更验证 每次改 Prompt、换模型、调参数，都能在几分钟内知道改动对整体性能的影响。 回归测试 防止你在优化一个维度时不小心破坏其他维度； 变更验证 让你有数据支撑每一次决策。 后期 -- 新模型快速采…」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。

把这条判断带到下一个场景

算法题换成真实任务后，先找出重复工作，再问输入规模如何变化，最后用一个小基准验证理论判断。这样不会把复杂度记成脱离场景的标签。

• 「没有评测的后果」：飞行盲区：修一个 Bug，制造三个新的 没有评测体系的团队，每次改动都是一场赌博。你修了用户 A 反馈的问题，却可能悄悄破坏了用户 B、C、D 依赖的功能。更糟的是： 你根本不知道自己破坏了什么 ，直到下一波用户投诉涌来。 真实场景 用户反馈「Agent 这周明显变差了」，团队翻了三天 commit 记录，试了十几种回滚方案，最后发现是两周前一个看起来无害的 Prompt 微调导致的。如果有评测，这个问题会在合并代码…
• 「评测的价值时间线」：早期 -- 定义成功 评测的第一个价值是 迫使团队定义成功长什么样 ，测试反而是其次。当你写不出 eval，往往说明你对任务的理解还不够清晰。这个过程本身就能帮助产品经理更好地理解需求。 中期 -- 回归测试 & 变更验证 每次改 Prompt、换模型、调参数，都能在几分钟内知道改动对整体性能的影响。 回归测试 防止你在优化一个维度时不小心破坏其他维度； 变更验证 让你有数据支撑每一次决策。 后期 -- 新模型快速采…
• 「关键建议」：先从 20 条开始 不要等到有几百条测试用例才开始做评测。 20 条精心设计的 Task，就能覆盖你最核心的场景。 关键在于开始，数量是其次。一个有 20 条 eval 的团队，比一个有 0 条 eval 但「计划做 500 条」的团队，领先了一整个时代。 评测也是产品理解的手段 写评测用例的过程，会逼你回答最难的产品问题：「用户到底想要什么结果？」「什么算好，什么算不好？」「边界情况怎么处理？」很多团队在写 eva…

最后的「关键建议」把讨论落到「先从 20 条开始 不要等到有几百条测试用例才开始做评测。 20 条精心设计的 Task，就能覆盖你最核心的场景。 关键在于开始，数量是其次。一个有 20 条 eval 的团队，比一个有 0 条 eval 但「计划做 500 条」的团队，领先了一整个时代。 评测也是产品理解的手段 写评测用例的过程，会逼你回答最难的产品问题：「用户到底想要什么结果？」「什么算好，什么算不好？」「边界情况怎么处理？」很多团队在写 eva…」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。