上周发完 一切皆插件：DeepSeek Harness 的野心与收敛鸿沟，一位带研发团队的读者给我发消息：「十次修改能不能收敛，你说取决于 eval。那我们让团队多写点测试用例，是不是就能收敛了？」
「多写点测试」是标准答案，也是错误答案。
它错在把 eval 当成一个纯的工程问题——好像数量上去了，收敛自然就来。但真正决定收敛的，不是 eval 有多少，而是 eval 集长什么样。而 eval 集长什么样，取决于一个更不好量化的东西。
品位。
一、Eval 分两层，只有一层能抄
先把 eval 拆开看。
┌─────────────────────────────────────────┐
│ 品位层（抄不走） │
│ 评什么 · 什么算好 · 哪些失败值得警惕 │
├─────────────────────────────────────────┤
│ 工程层（谁都能抄） │
│ 采样 · 判分 · 统计显著性 │
└─────────────────────────────────────────┘
# generated by hugo AI
底下那层是工程：怎么采样、怎么判分、样本量多少才有统计显著性。这些有教科书、有开源实现、有成熟工具链，谁都能抄，也早晚会被工具抹平。
上面那层是判断：
- 评什么——在无穷多的行为维度里，你决定测量哪几个
- 什么算好——同一个结果，好到什么程度算过关，及格线画在哪里
- 哪些失败值得警惕——哪种失败是致命的，哪种是可容忍的，哪种反而是响亮且便宜的（这正是 Skill 是组织知识的新载体 里说的「响亮失败」——错得响亮的地方，Agent 学得最快，值得优先投入 eval 资源）
这三问没有一个有标准答案。它们是一个团队对「什么是好产品」的全部理解，压缩成的一组判据。
工程部分谁都能抄，这三个问题抄不走。它们就是品位。
二、同一个能力，两个 eval 集，两个产品
品位不是玄学，它有非常具体的产出：eval 集。而 eval 集是 Agent 的 loss function——loss 不同，优化收敛到的形状就不同。
拿 Evals 是新的 PRD 里那个智能审批 Agent 举例。同一个模型、同一套工具能力，两个团队写出的 eval 集可以完全不同：
| Eval 集 A：效率优先 | Eval 集 B：不打扰优先 | |
|---|---|---|
| 评什么 | 审批处理时长 | 不必要的打扰次数 |
| 什么算好 | 越快越好，超时必提醒 | 安静地把事办成，不漏不扰 |
| 值得警惕的失败 | 超时未提醒 | 领导出差时被无差别提醒 |
| 优化出来的行为 | 全量提醒、逐级催办 | 紧急度判断、非紧急件汇总 |
同一个 Agent，喂 eval 集 A，它会进化成一个催办机器；喂 eval 集 B，它会进化成一个懂分寸的助理。能力没变，变的是「什么算好」——而这个判断，来自写 eval 的人对业务和人的理解。
那个「领导已读不回 48 小时，但该不该提醒要看他是不是在出差」的判断，PRD 写不进去，模型也猜不出来。它只能从 eval 集里长出来——而把它写进 eval 集的那一刻，就是品位在发挥作用。
三、工程决定方差下限，品位决定天花板
这里必须回应一个常见的反驳：「eval 是客观测量，品位是主观偏好，怎么能划等号？」
把测量拆成两件事就清楚了：
- 精不精确，是工程问题。判分器抖不抖、采样有没有偏、p 值够不够——这些决定测量的方差。工程做得好，方差有下限，结果可复现。
- 对不对靶，是品位问题。你测的到底是不是用户真正在意的那件事——这是效度。方差为零但打错靶子，正是「工程很好、品位很差」的典型状态：测试全绿，产品照样没人用。
所以那两句可以合成一个公式：
工程决定方差下限，品位决定天花板。
工程抄到位，你的 eval 不会比行业平均差；但能到哪，取决于你评什么、什么算好。这也解释了为什么两个团队用同样的模型、同样的 Harness，做出来的 Agent 气质完全不同——不是模型不同，是 loss 不同。
四、品位不可教，但 eval 集可以留
还有一个反驳要处理：「说 eval 是品位，等于把 eval 玄学化——品位这东西，学不来啊。」
恰恰相反。eval 集是把品位从玄学里救出来的唯一载体。
品位本来是隐性知识：老师傅看一眼代码说「这个味道不对」，你问他哪里不对，他也说不全。这种判断力传统上只能靠师徒制、靠耳濡目染、靠一起扛几年项目才能传递——传递效率极低，人一离职就归零。
eval 集改变了这件事。「哪些失败值得警惕」一旦被写成一条 eval case，就从老师傅的直觉变成了仓库里的资产：新人第一天就能跑它，Agent 每一次修改都要过它，它不会离职，不会遗忘，不会因为换了一个模型就失效。
品位本身不可教，但 eval 集可以留。这是组织传承判断力的新通道。
五、比 prompt 更深的沉淀
有人会说：传承团队的理解，prompt 不也行吗？
不行，差一个层级：
- prompt 编码的是「怎么做」——过程知识。它会被模型绕过、被长对话稀释、随版本漂移
- eval 定义的是「什么算好」——价值判断。它是 loss 本身，Agent 的每一次优化都绕不开它
一个团队对「怎么做」的理解容易写下来，对「什么算好」的理解却往往说不出口——而 eval 集是少数能把后者装进去的容器。好的 eval 集本身就是品位的沉淀和传承，比 prompt 更能体现一个团队对「好」的理解。
这让我想起前天写的 DeepSeek Harness 的三个细节：dsh 用仅追加的会话日志解决了 Agent 的 记忆 传承——恢复、分叉、回放、审计。而组织这一侧，eval 集解决的是 品位 传承。记忆让 Agent 回到原来的历史，品位让 Agent 继承团队的标准。前者 DeepSeek 已经用工程做出来了，后者还是每个组织自己的作业。
写在最后
回到 收敛鸿沟 留下的那个问题：第 10 次修改，它怎么收敛？
现在可以把答案说全了：收敛靠 eval，而 eval 的质量不取决于你写了多少测试用例，取决于写用例的那个人——评什么、什么算好、哪些失败值得警惕。
收敛问题，说到底是个品位问题。
在 老板 AI 量的不是工程师，是老板自己的品味 里我写过，AI 时代被度量的是品位。这里再往前一步：品位不只是被度量的对象，更是被写入的东西——写进 eval 集，成为 Agent 的 loss，成为团队的资产。
所以一个更实用的问题是：你的团队最近一次认真评审 eval 集，是什么时候？如果你只 review 代码不 review eval，那你 review 的只是实现，不是品位。欢迎留言聊聊。