AI 下半场：聊透 Benchmark 与 Evaluation | 对谈前 Kimi 产品经理丁丁

2024 年初，丁丁加入 Moonshot，Kimi App 刚上线。她此前在微信做了 5 年搜索产品，也在美团做过策略产品，随后在 Kimi 负责 App 一年多，是早期产品成员之一。2025 年 5 月，她刚离开，坐到 42章经的录音间。

曲凯从 OpenAI 研究员姚顺雨那篇《AI 即将进入下半场》切入。文章的核心判断是，AI 进入第二阶段，从解决问题转向定义问题，评估的意义会超过训练本身；评估的关键不在设置更难的基准测试，而在真实业务场景里重新设计一套实用的评估标准。

丁丁认可这个判断。她在大模型公司做了一年多产品，这期节目聊的就是 Benchmark 和 Evaluation：模型公司怎么出题，怎么判断一道题好不好，创业公司该维护多少道题，以及古典产品经理转到 AI 产品经理，哪些能力仍然值钱。

刷分读到博士，真实体验还像实习生 1:10

先把两个词说清楚。Evaluation 是对模型性能好坏进行分析和评估的过程。Benchmark 是一系列基准测试，可以理解成给模型出的一套套题，再看它表现怎么样。

姚顺雨文章里有个判断传播很广：这个阶段，定义问题会比把现有 Benchmark 刷分更重要。丁丁的解释是，很多基准测试和业务真实场景、用户实际需求之间存在 gap。研究者需要带上产品经理的思维，关注实际产品体验和效用，否则会出现智能水平越拉越高，实际解决问题的效用没有提升的状况。

曲凯提到文章里另一个扎心的对比：刷分结果里，很多 AI 已经达到研究生、博士生的水平，真实使用起来可能连实习生都算不上。

丁丁认为原因不只在基准测试怎么设定。真实业务里，一个端到端的模型产品不只看基座模型能力，还要看 system prompt、搜索 API、知识库、接口等一系列流程，这些环节共同构成用户体验。不同业务、不同领域的输入，和公开基准测试里的题目也完全不一样。

Benchmark 分数高，不等于端到端产品体验好。 把公开榜单的高分直接搬进业务，表现未必理想。这也是丁丁完全认可“AI 下半场”说法的原因。

上半场从拼模型到拼 DAU，DeepSeek 敲了警钟 3:22

回顾上半场，丁丁把时间范围划在 2023 年初到 2024 年底、2025 年初这两年。第一阶段，大家都在努力提升基础模型能力，挖掘预训练潜力。Kimi 很早就意识到 RL 的重要性，但 RL 的效果必须建立在一个很好的基础模型和很好的预训练环节上，DeepSeek 的成功经验验证了这一点。

第二阶段，大家积极用现有基础模型能力包装生产力产品。基础模型能力不够、训练范式没调整时，提示词工程会被提到非常重要的位置。2024 年上半年，行业里流行一句话：你一定要成为提示词工程师，这可能是新职业。今天提示词仍然重要，只是基础模型能力提升后，过去非常复杂的提示词，可能只需要更简单、清晰、明确地描述想要的结果，就能输出相同甚至更好的结果。

奥尔特曼说过提示词工程未来不存在。丁丁的理解是，专门的提示词工程师职业可能不存在，提示词本身一定存在。

产品侧的变化也很明显。2023 年几家模型公司追求预训练程度，追求 AGI；过去一年多，各自落在产品上。Kimi 落在 App，字节落在豆包，MiniMax 选择星野等方向。大家开始卷 DAU。DeepSeek 出来以后，像一记警钟，行业发现智能更高以后，前面这些东西可能没那么重要，现在又回到追求 AGI 的路线。

丁丁对单一指标追 DAU 的评价很直接。

一味的或者单一指标去追求 DAU，某种程度上是一种经验的惯性或者有点偷懒的行为。

移动互联网时代，用户规模是衡量产品成功非常直接的指标。模型公司缺少客观指标评价模型做得好不好，Benchmark 又存在可刷空间。内部定 OKR、KPI，外部面向资本市场和用户，能评价的常常只剩 DAU。

DAU 当然重要。没有用户，就得不到反馈，也拿不到真实用户输入。问题在于一味追 DAU，对模型能力提升可能没有帮助。

Benchmark 的来源可以分几类：通用基准测试、用户线上真实反馈、人工构造的 Benchmark、合成数据 Benchmark。DAU 规模能帮助公司获得独家数据，用户输入的噪音也很大。一个从快手来的用户，和一个用生产力工具聊 50 轮上下文、最终输出调研报告的用户，数据价值完全不同。

用户数据重要，噪音也大，关键在筛选出和模型能力提升真正 align 的高质量部分。 曲凯追问，数据对模型进展的作用到底多大。丁丁说当然重要。没有用户数据时，公司内部的人、产品经理本身也有局限，不可能是每个行业的专家，也不可能试遍模型的所有用法、所有模态的混合输入。用户数据提供了行业视角，再结合专家访谈、调研，能帮助基座模型公司更好理解用户，定义出更好的 Benchmark。

OpenAI 的数据量远高于其他家，其他家后来也追上了。丁丁把体验拆成层层累积：预训练基座训得好不好，后训练做得怎么样，SFT 做得怎么样，有没有用 RL，RL 又依赖高效 infra 和对范式的笃定。最终是不是好体验，取决于这些环节共同作用。

曲凯问了一个假设题：如果你是半年前的梁文锋，要不要接这波 DAU 和数据？丁丁回答，资源充足一定想接，恰恰是资源不够充足。她也承认，这可能是古典产品经理的通病，看到这么多用户来，总会有想法。从结果看，DeepSeek 顺其自然，没有特意去接。

一道题怎么出，决定模型往哪走 10:04

在模型公司做了一年多，丁丁总结最大的收获是对模型评估和 Benchmark 的认知。她做过搜索产品，搜索也有评测，两者有相似之处。区别在数据集变化速度。搜索评测的数据集变化没那么快，一套相对通用的测试集能用很长时间。模型公司的模型能力动态迭代，某个维度上的能力被一个 Benchmark 解决后，这个 Benchmark 的生命周期可能就结束了。团队需要定义不同维度、不同梯度的 Benchmark，一步步推进模型进步。

模型智能的体现，最终就是 Benchmark 的难度。出什么样的题，得到什么样的结果。各家模型产品拉开差距、表现各自特点，恰恰来自他们对出题这件事的不同定义。

一道题长什么样？丁丁举了深度搜索的例子：帮我把腾讯过去十年的财报都找出来，并且预测一下今年它的净利润会上升多少。模型给出输出，再用一个 reward 评价输出好不好。这个输入、输出、评价，构成 Benchmark 的最小颗粒度单位。

不同业务在意的点非常不一样。深度搜索希望模型基于引导的数据源，给出尽量真实、全面的结果。C.AI 这类情感陪伴产品，这个标准就不重要了。用户不希望模型在陪伴时说“根据你的心情状态，我对你有以下几个建议，一什么，二什么”。同样的结构化输出，在研报等场景又非常适用。

评估标准最终要抽象出几个维度，还要抽象维度之间的优先级。C.AI 场景里，对用户意图的理解、回复的口语化，可能比事实性、完整性更重要。产品侧的业务视角已经先做了一层判断。

DeepSeek 出圈时，很多人觉得它的文风有意思，显得有哲思、优雅。丁丁认为，这背后反映的是团队对“什么是好”有一条隐含标准：模型这样回答是好的。在 DeepSeek 出来之前，哪怕在内部说文风重要，大家也未必认为它是一个好指标。

模型评估本身特别难。所有人都共识、百分百正确的评价标准不太好制定。数学题、代码题有 ground truth，比较好做，今天大家也偏好采用。语言风格、表达这类层面不好量化，甚至没有共识。

曲凯顺着问：未来会不会多模型各有性格，有人喜欢这个，有人喜欢那个？甚至一千个用户配一千个 Benchmark？丁丁说，多模型偏好已经存在。编程时第一优先级可能选 Claude，做深度搜索时可能用 o3。个性化可以转换成模型能力或产品能力，比如用 memory 解决偏好，不一定需要那么细分的 Benchmark，但模型要有内化的能力帮用户达成目标。

曲凯又举了一个极端例子：C.AI 公司希望产品情商、智商越来越高，但有用户就喜欢“蠢”的，通过对话把 bot 调教得越来越蠢，这和公司对基座模型的期待矛盾吗？丁丁说，不矛盾。用户希望它蠢，本质上是一种指令遵循能力，也是模型基础能力。模型要足够聪明，才能扮蠢。最顶尖的人也能做到大智若愚，面对不同的人，可以迎合对方喜好。

模型公司真正的差异，常常藏在“出什么题”里。 同一领域，Benchmark 难度不同，难度通过团队对业务的理解体现。搜索早期用简单题目，觉得那就是用户输入。后来看到金融领域用户通过五到十轮对话，发现一个复杂的 problem 提问也能让模型一步到位输出结果，于是有了更难的 Benchmark。好与坏的标准各家公司有差异，这个差异会直接引领模型迭代方向。

好 Benchmark 的三条硬标准 17:55

丁丁给了一个比较清楚的判断框架。一个好的 Benchmark 首先真实，能反映线上用户需求；其次有难度和区分度，不是所有题都一样难；第三，它会随着模型迭代的生命周期流转。旧题被解决就抛弃，新题补充进来。

Benchmark 和古典用户指标有关联。古典产品经理看使用频次、使用时长，放到 AI 产品里可能是对话轮次、留存。Benchmark 反映模型某一方面能力好不好用，好不好用最终会转化成用户指标。模型好不代表 DAU 好，不同业务关联的用户指标会变化。

曲凯问，Benchmark 和最终用户指标是不是强关联？丁丁说是，应该正相关。如果 Benchmark 变好，用户指标没有变好，就要改 Benchmark，至少要让他们不断 align，否则评估没有意义。

评估过程里还有 auto eval 和 human eval。用大模型评价自己模型的任务完成效果，和用人评价端到端效果，两种 eval 都需要不断校验。否则会出现自动打分和真实用户体验之间的 gap。这个过程本身是动态的。

落到公司实践，大厂和创业公司有分化。大厂里不同团队还按以前的方式流转：高质量数据标注、评测集完全由数据团队做，评测或策略产品拿到结果，再和功能测、端测产品沟通。断点比较多。创业公司团队小，组织方式不一样，认知迭代更快。

Benchmark 多久变一次比较合理？丁丁说没有标准答案，越快越好。越快说明模型能力迭代很快。很多创业公司如果不训练模型，迭代的是预制 prompt 和工程能力。

用户基数少的时候，评价维度可以相对单一，用户分化不严重。用户变广以后，需求分布越来越不一样，标准也要补充和调整。

题量呢？曲凯问，创业公司大概多少道题合理。丁丁说自己会准备 400 道题。不是越多越好，能衡量模型表现就够。

曲凯提了一个很产品经理的做法：先上线，把用户所有 prompt 排序，取前面 400 个当 Benchmark。丁丁说这特别有意思，以前搜索 Benchmark 之一就是高频 query 的效果。问题还是要过滤噪音和无效用户数据。搜索需求很长尾，只解决头部 400 个不够。假设整个 qv 量是 100 万，头部 400 个可能占 20 万，剩下 80 万也要解决。

你还是要尽量的去符合线上用户的这个分布。

团队会特别关注点踩这类强烈负反馈信号，它更能帮助判断底线问题。坏的 Benchmark 长什么样？特别简单，里面全是类似某一个维度、某一个困难程度的题，就是一个非常糟糕的 Benchmark。

好 Benchmark 要能随模型迭代流转，旧题解决后必须换题。 题量不是核心，覆盖真实分布、有梯度、能指导迭代才是核心。

让 AI 陪聊，先得定义“好的安慰” 24:25

曲凯把 Benchmark 比作点技能树：把所有点数点在某一项上，让长板足够长，用户对产品长板的感知足够明显，反而能脱颖而出；还是平均点，全面均衡更好？

丁丁分两层看。基座模型能力越强，在一些垂类里表现也越好，这是泛化能力。什么都不做，一个博士生天然比小学生更聪明。另一层是垂直产品、模型、agent 的机会，机会不只基于模型能力，还要加入工程能力、独家数据、对业务本身的理解。比如一个做销售的业务，它对销售交互、对抽象反馈信号的理解，就是比其他公司或其他人更深，它能设计出更好的基于模型的产品，也能告诉模型到底应该奖励什么。

拿 C.AI 这类 AI 陪聊产品举例，难点很具体。情感聊天、陪伴场景没有 ground truth，也没有标准答案，评估标准怎么定才准确，很难衡量。

用户说“我今天失恋了，我和我的对象分手了”，预期模型怎么回复？没做过口语化、情绪识别回复的模型，可能会说：听到这个很难过，我给你推荐以下几种方式放松心情，一、下楼跑一跑，二、去见见朋友。这个画面很多模型都出现过。

丁丁认为更好的回复首先像真人，可能会问“怎么了”。如果模型有 memory 能力，甚至会问“不是上个星期你跟我讲你们俩之间还好好的吗”。有的模型会关心具体出了什么问题，有的会说“抱抱你，我一直都在这里陪你，如果你有什么不开心可以仍然跟我分享”。

一个真实的人在这种情况下，到底预期获得什么回复，没有百分百正确的答案。团队只能尽量定义：希望模型先关注用户情绪变化；从 memory 角度知道用户的情感状态，要不要 call back；从心理咨询师的专家角度，不急于给解决方案，先关心背后发生了什么，让用户把情感状态和具体故事倾诉出来。

曲凯补了一句：有的人就是喜欢解决问题，有的人喜欢被怼一下，有的人喜欢闺蜜式安慰。几乎无法定出一个统一的好 Benchmark。

丁丁由此判断，未来一定会出现一些小众猎奇的产品。一个 Benchmark 可能只能照顾 80% 的用户，剩下的靠个性化和基座模型足够强的能力解决。

曲凯把问题推到更抽象的一层：定评价标准和价值观时，整体上是人类价值观的映射，这个映射真的对吗？丁丁说，答案分两种。一种是社会约定俗成的答案，另一种是更高级版本的答案。身边朋友都会给一个答案，某个教授角色会给出另一个答案，后者可能让人醍醐灌顶。做题、生产力场景里，现有映射仍然 work。情感场景里，是否完全准确，不好说。

情感陪伴类产品的评估，先要定义“什么算好的安慰”。 生产力类产品确定性更强，标准更好找，Benchmark 也更好定。

Benchmark 是核心资产，越少人知道越好 29:30

曲凯问，以前公司会偷竞对的代码，未来会不会偷 Benchmark？丁丁的回答很干脆。

Benchmark 确实是一个核心资产。

如果是她，会维护一个只有自己知道的 Benchmark。这个 Benchmark 甚至不应该让算法团队知道。算法同学知道后，训练时可能不由自主地让模型去打出这个问题，或者模型找到 hack 的办法。她会在每次上线前拿来测一下，但不公布具体题目。

接着聊 AI 产品经理和古典产品经理的异同。丁丁认为相同的地方是懂用户，相同的能力叫翻译能力：发现问题，把用户和业务场景抽象出来。过去抽象的是交互设计和结构设计，今天在模型产品里，是把业务流程抽象成好的评估标准、观测指标。抽象能力、对用户场景需求的翻译能力仍然重要。

古典产品经理对交互体验有敏锐感知，知道什么是美、什么是丑、什么符合直觉，什么不符合。这个能力仍然需要，而且稀缺。今天大家谈了很多模型，基于模型能力的最好的交互还没有诞生。垂类产品里交互可能更重要，交互直接反映团队能不能为模型迭代、产品迭代设计出合适的反馈节点或反馈信号。

不同的地方有两点。第一，对数据质量的重视程度发生非常大的变化。第二，对模型能力边界的理解。后者需要很多时间积累，是最难也最重要的一部分。

模型进展很快，有人担心现在做的东西半年后就被模型颠覆。怎么更好理解模型边界，甚至预判边界？丁丁给了方法。

先多用。用不同的最好的模型和它们的 API，理解不同模型在不同领域、不同能力上的表现。每隔一两个月，新版本一定会有能力提升，要跟着熟悉。

再把所有想做的事情先用 AI 做一遍。以前做 C 端产品，除了 PRD，可能先要花一个交互。现在可以试着把交互逻辑清楚地说出来，让 Claude 帮你制作一个交互。这个过程里，你会摸到模型能力边界，也会知道它能帮你实现什么。动态地跟模型一起迭代、一起使用，可能会发现某个方向的能力比你想象得越来越强。

丁丁举了前阵子很火的“言出法随”图像生成。没体验之前，会觉得指令遵循、特别是上下文多轮修改图片非常难。今天会发现模型完全能做到。它伴随模型能力边界迭代而产生，在这个基础上又能快速做出新产品。

动手能力要很强。不需要像过去的产品经理那样有非常强的模块流转意识，要完全丢掉这个意识。把自己当一个产品经理，当一个设计师，同时再当一个前端，后端不能完全实现也可以试一试，完成全流程闭环。这对理解模型更有帮助。曲凯问未来每个人是不是都要变成全栈，丁丁说是。

看论文呢？丁丁认为这是必备习惯。理解原理和在原理基础上做验证，本来就是一体的。她没见过完全不关心原理、还能用好模型的人。区别在深度，产品经理理解论文的深度和算法同学完全不一样。算法论文努力看也不一定看懂，讲前沿判断的论文可以搭配着看。

创业公司做什么事情不会被模型未来碾压？丁丁的判断是，有很深的领域内 knowhow，同时理解模型，能在当前阶段最快把两者结合在一起，形成产品壁垒或行业认知，并积累用户。

理解模型边界最有效的方式，是把想做的事先用模型做一遍。 只看文档、只听分享，摸不到边界。

微信那套产品原则，在 AI 里仍然有用 35:38

节目最后回到丁丁在微信的经历。她总结了几个产品原则。

先做产品结构，再做功能细节。微信里有很多功能，如果都用不同 tab 表现，不做层级拆分，今天会非常臃肿、复杂。直到今天，微信仍然比较简单，只有四个 tab。张小龙一上来就想清楚要这几个 tab，朋友圈怎么做，公众号怎么做。底层结构从一开始就想得非常清楚。扫码作为一个新入口，背后是一种服务能力，这些甚至在小程序诞生两年前就想好了。

功能模块之间有机联系。用户说想要多个头像，可以左滑右滑，背后的需求其实是想要更多头像照片展示给别人看。这个需求应该由朋友圈承载，不该在单点头像上做设计。

不主动强教育用户一定要用哪个功能。用户在用某个功能往下再下钻一层时，发现一些新体验，才会触发那个能力。

这些原则在模型公司仍然适用，底层原理一样。微信出来的产品有一个被培训过的点：基于更全局的视角，真正想什么是好的体验。今天一些公司验证能力和功能设计太简单，上 AB 实验非常方便，跑八个、二十个实验，选那个最终把指标做正的方案。年轻同学做方案时，不会真的想用户需不需要、跟全局有什么联系、这么做是不是好，因为跑实验就好。

曲凯把古典产品经理的概念往前推了一步：古典产品经理靠个人经验、感觉、用户感知做事，对应更多 AB test 和数据驱动的产品。美国大厂、字节都以 AB test 出名。数据好，哪怕解释不清为什么，也是好。

丁丁先往上说了一层：每个产品有自己的个性、自己的感觉。微信给人的感觉是内敛、极致简单，Instagram 给人的感觉是时髦、漂亮、fancy。调性不能通过 AB 实验得到。一个产品打开很乱，留存却比原来高，这是价值观取向。微信的取向是绝对不可以为了指标容忍那么多东西。

第二是指标选得对不对。公司大了以后，每个部门、每个业务的指标存在被 hack 的空间。大家关注的不再是一个统一的大指标，不会遵循某个调性、价值观，只要做正自己业务的指标就可以。即使非常违反直觉，甚至对大指标是负的，也可能发生。

招 AI 产品经理，丁丁给了三个信号。背景上，她偏好初创模型产品、小公司里完成从零到一或端到端的人，更全栈，自己从头到尾做过东西。第二，有些同学会用业余时间做小 demo、小产品，这是非常好的信号。好的 AI 产品经理未必要做出特别突出的产品，但一定自己跑过一些东西、验证过一些东西。第三，直接问他：你最喜欢的模型是哪个，平时用得最多的是什么，一般在什么场景下用，为什么用那些。即使前两条不满足，从第三点也能看出他对行业的理解、热情和专注度。

这期节目给做 AI 产品的人一个很具体的起点：先别急着刷公开榜，写下三类题，真实高频需求、有难度梯度的难题、点踩这类负反馈底线；每过一两个月，用最强的模型把自己的流程重新做一遍；维护一套不公开的私有 Benchmark，上线前自己测。Benchmark 不是给别人看的分数，它是团队对“什么是好”的共同定义。