Evaluation

上周发完 一切皆插件：DeepSeek Harness 的野心与收敛鸿沟，一位带研发团队的读者给我发消息：「十次修改能不能收敛，你说取决于 eval。那我们让团队多写点测试用例，是不是就能收敛了？」

「多写点测试」是标准答案，也是错误答案。

它错在把 eval 当成一个纯的工程问题——好像数量上去了，收敛自然就来。但真正决定收敛的，不是 eval 有多少，而是 eval 集长什么样。而 eval 集长什么样，取决于一个更不好量化的东西。

品位。

最近一个月，有三个人问过我同一个问题：「我们公司想做 AI，从哪开始？」

三个人的背景很不一样：一个做制造，一个做跨境电商，一个做连锁餐饮。但他们的第一反应惊人地一致：先看看现在的模型能干什么，再从公司里找个场景套上去。

Jeff Dean 给的答案正好相反。今年 YC Startup School 上，他给了一个我认为值得每个企业贴在墙上的选题标准：

去找模型成功率是 0% 或 1% 的问题，不是 20%。

这就是 1% 法则。在 AI 的竞争变了：未来是上下文的竞争 里我讲过这个判断的战略含义；这篇往前一步——把它变成一套你在自己公司就能执行的盘点方法。

上周有人请我整理一套数字员工的术语，用途是整理会议纪要。

整理的时候我意识到一件事：会议纪要看起来是最容易交给 AI 的岗位。语音识别模型足够强，转写免费，人人会用。按常理，它应该是数字员工最先上岗的岗位。

但我们真动手做的时候，发现不是这样。

第一版会议纪要机器人，把会议里的每一句话都转写出来了。问题是，没人看得懂：

「关于上次说的那件事，就按讨论的办。」——哪件事？怎么讨论的？

「这个意见我同意。」——谁的意见？

「后续小王跟进一下。」——哪个小王？

而且，转写本身也不总是干净的。真正容易出错的，不是通用技术术语，而是企业自己的语言——项目代号、产品名、客户简称、组织缩写、内部黑话。比如「北极星二期」「天穹计划」「A17 客户」「P0 升级」「DWS」「飞鹰版本」，通用模型根本不知道这些词代表什么，转写很容易出现同音字或拆词错误。

看起来是两个问题：术语转不准；就算转准了，也没人看得懂。

其实是同一个问题：缺上下文。术语转不准，是因为模型的词典里没有你公司的词；看不懂，是因为纪要里没有这些人是谁、属于哪个项目、上次讨论了什么决定、谁负责什么事。

这次经历让我们得到一个后来反复验证的判断： 数字员工不是任何岗位都能做，只有「上下文充分」的岗位才能做好。

判断一个岗位是否适合数字员工，只需要看五件事。

上周我让一个 Coding Agent 给一个 Web 应用实现登录功能。三轮迭代之后，它汇报：「完成了，所有测试通过。」

我打开浏览器一看：登录按钮不见了。

我把截图丢回去，它看了一眼，回复：「抱歉，上一轮我把按钮组件误删了。」

有意思的不是 Agent 会犯错——犯错很正常。有意思的是： 它直到看见那张截图，才知道自己犯了错。 那三轮迭代里，它有编译反馈，有测试报告，但它没有任何办法知道最终页面长什么样。它的「世界」是残缺的。

这件事让我更确认了一个琢磨了很久的判断：

对于 Coding Agent，最重要的基础设施不是更聪明的模型，不是 Benchmark，而是端到端（E2E）Test Harness。

上个月，我们团队一位产品经理花了两周写了一份 40 页的 PRD，描述一个智能审批 Agent 的需求。用户故事、流程图、异常分支、验收标准，写得滴水不漏。

她把 PRD 丢给 Coding Agent，说：「按这个做。」

三天后 Agent 交付了。代码能跑，测试通过，接口对齐。但她试了五分钟就皱眉：「这不是我要的东西。」

哪里不对？她说不清。审批流程是对的，权限校验是对的，消息通知是对的。但 Agent 处理「领导已读不回超过 48 小时」的策略，不是她脑子里想的那个。PRD 里写的是「超时后自动提醒」，Agent 就老老实实给所有超时审批发了一轮提醒——包括那些「领导出差没看手机」的非紧急件。她真正想要的是「先判断这条审批是否紧急，紧急的才提醒，不紧急的等下次汇总」。

这个判断，她没写进 PRD。因为她觉得这是「常识」。

Agent 没有常识。Agent 只有你给它的判据。

上个月和一位做 HR SaaS 的朋友吃饭。他刚花了两百万买了一批行业测评数据，准备训练自己的垂直模型。

我问他：「竞品如果也买同样的数据呢？」

他愣了一下：「那……我们还有先发优势。」

「先发多少？」

「大概……半年？」

半年。这就是原始数据作为护城河的保质期。

三个月前，我写了一篇 中国 SaaS 厂商的护城河应该怎么建，核心公式是：

护城河 = 垂直行业数据资产 × 行业 Know-How × 客户成功体系 × 生态协同

那篇文章里，我把「数据壁垒」放在七大维度的第一位，画了一个数据飞轮：客户使用 → 数据沉淀 → 模型训练 → 更精准的服务 → 更多客户使用。

三个月后，我要修正自己。

飞轮里转的不是数据，是 eval。

上个月有人问我一个问题：「我已经有 LLM-as-Judge 做 eval 了，能不能用它来自动优化 Agent 的执行路径？在不降质量的前提下，找到最省钱的轨迹，然后让 Agent 记住？」

这个问题的答案值得展开。答案是能，而且这可能是当前 Agent 优化里最值得投入的方向。但大多数团队理解错了「优化」的对象。

你让悟空生成了一份技术方案，通读一遍觉得「逻辑清晰、结构完整」，直接交给了研发团队。一周后，架构师反馈：方案里 30% 的接口定义缺少边界条件说明，两个核心组件的选型缺乏压测数据支撑，根本无法进入开发排期。

你让 AI 写了一段数据清洗脚本，本地跑通了样例数据，直接部署到生产环境。三天后，监控报警：遇到脏数据时脚本静默失败，导致下游报表连续两天数据断层。

AI 的输出「看起来很好」，不等于「工程上可用」。

在前面的九篇文章中，我们构建了从 需求澄清、交付物定义、示例对齐、分步执行、迭代优化、上下文管理、工具协同、工程化封装 到 多 Agent 协同 的完整工作流。

但所有这些技巧，都依赖一个隐含假设：人类能准确判断 AI 的输出质量。

现实是：人类审查会疲劳、会受认知偏差影响、无法覆盖边界条件，且根本无法规模化。当 AI 协作从「个人玩具」走向「团队基础设施」时，靠「感觉不错」来验收，就是埋下生产事故的种子。

今天，我们探讨技巧十：如何通过「评估与度量」，建立自动化质量门禁和数据飞轮，让 AI 协作从「主观验收」走向「可观测、可度量、可演进」的工程闭环。

上个月参加一个 Agent 产品的内部评审，产品经理拿出一张 benchmark 表格：准确率 92%、响应时间 1.2 秒、幻觉率 3%。数字很漂亮，领导很满意。

然后我问了一个问题：“这个 92% 的准确率，是在什么任务上测的？”

回答是一组通用 QA 数据集。

我又问：“你的目标用户是电商运营，你有没有用电商运营真实工作场景的任务来测？”

会议室安静了五秒钟。

这就是今天 Agent 评测的核心矛盾：我们在用"通用考试"的成绩来预测"专业岗位"的表现。 这就像用高考数学成绩来判断一个人能不能当好外科医生——逻辑上不成立，但大家都在这么干。

在 AI Agent 应用日益普及的今天,会议纪要生成是最常见的落地场景之一。然而,如何科学地评估一个会议纪要 Agent 的性能,却是许多开发者面临的难题。本文将详细介绍如何构建一个完整的 benchmark 体系,包括评估维度设计、数据集准备、指标计算和自动化测试流程。