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

42章经 · 2025-05-05 · 41 min · https://www.xiaoyuzhoufm.com/episode/6818517a6970cc7b4db62789?utm_source=rss

## 逐字稿

曲凯

我们今天很开心请到丁丁。丁丁从 2024 年初开始加入 Kimi，那个时候 Kimi 的 App 刚上线，相当于是去了以后参与上线 Kimi 的 App，之后一直做 Kimi 的 App，做了大概 1 年多的时间，也算是 Kimi 早期的产品同学之一。最近丁丁刚出来。

我们可以从最近比较火的一篇文章先切入，正好通过那篇文章聊一下模型的上下半场。前两天 OpenAI 的那个人写了一篇文章，标题大概就是《AI 的下半场》。我看他里面讲的核心点是，大家对于当下模型能力的开发其实已经到了一定阶段，之前很多 evaluation 用的一些 benchmark 可能没有那么有效了，应该需要一些新的、更偏向实际落地的 evaluation benchmark。

我不知道你是怎么看这个问题的。

丁丁

### 定义 AI 下半场

在聊这个问题之前，可能还是要先讲一个最基础的概念：什么是 evaluation？其实就是对模型性能的好坏进行分析和评估的过程，而 benchmark 则是一系列基准测试。你也可以理解为给模型出的一套套题，然后看它表现怎么样。

“下半场”那篇文章传播得非常广，其中最重要的一个观点就是，在这个阶段，定义问题可能会比把现有 benchmark 刷分更重要。其实这些 benchmark 跟业务的真实场景，或者用户的实际需求之间，还是存在一定 gap 的。

我记得文章里面有个观点，说鼓励研究者用产品经理的思维，去关注实际的产品体验和效用问题。不然就会出现所谓的智能水平越来越高，但是实际解决问题的效用并没有提升的状况。

曲凯

对。它里面提了一个点，我觉得其实挺对的：现在各种模型看刷分的结果，可能很多 AI 已经达到研究生、博士生的水平了，但实际上落地的时候，可能最多连个实习生的水平都还算不上。

这个背后的原因到底是什么？是 benchmark 设定的问题吗？

丁丁

实际上在真实的业务场景里，除了基准测试之外，我们还会关注很多结合业务和用户真实使用情况的 benchmark。因为刚刚提到的这些基准测试，和真实世界中模型产品在不同业务里的表现，偏差还是会比较大的。

比如说你是一个端到端的模型产品，那你要评估的除了基座模型本身的能力之外，可能还包括整个流程当中的 system prompt、搜索 API、知识库以及接口等一系列环节，它们共同构成了用户体验。

另外，在不同业务或者不同领域内，实际的输入可能跟我们看到的那些基准测试题目完全不一样。基于这个前提，就会出现 benchmark 分数很高，但如果完全拿来即用，在真实业务场景中的表现却并不会特别好的情况。

曲凯

所以你是认可“AI 下半场”这个说法的吗？

丁丁

我完全认可。

曲凯

回顾上半场，至少从国内的认知来讲，应该是从 2023 年初开始，一直到 2024 年底或者 2025 年初，差不多这两年的时间。在你做 Kimi 的这些经验里，包括你看到国内这些大模型公司的发展来看，上半场我们可以总结出哪几个阶段？大家核心提炼出了哪些认知和答案？

丁丁

### 上半场押注基座模型

首先，上半场大家还是在努力提升基座模型的能力，或者说还在努力挖掘 pre-training 的潜力。对 Kimi 来讲，其实也很早就意识到了 RL 的重要性，但是 RL 的效果最终必须建立在一个很好的基础模型，或者很好的 pre-training 环节之上。DeepSeek 的成功经验其实也验证了这一点。

另外，我觉得大家在过去一年当中，都在积极尝试用现有基座模型的能力，去包装出一些好的生产力产品。但是我们也会同时看到，在过去基座模型能力还不够好的情况下，或者训练范式还没有调整的情况下，提示词工程会被提到一个非常重要的维度。

我记得应该是在去年的上半年，大家还在说你一定要成为一个提示词工程师，或者这可能是一种新的职业。今天不是说提示词不重要，而是相比过去非常复杂的提示词，随着基座模型能力的提升，可能只需要更加简单、清晰、明确地描述你想要的结果，就能输出跟以前一样、甚至超越之前的结果。

曲凯

我记得之前 Sam Altman 说过，好像提示词工程未来是不存在的。

丁丁

我觉得他说“不存在”的意思是，专门的提示词工程师这个职业可能不存在，但是提示词本身一定会存在。

曲凯

明白。我的感知是，从 2023 年开始，几家模型厂商都在追求 pre-training 的极致，追求 AGI。但过去一年多的时间里，大家其实各自都落在了产品上面。

比如 Kimi 落在它的 App 上，字节落在豆包上，MiniMax 最后可能选择了 Talkie、星野这些方向。大家开始去卷谁的 DAU 更高。DeepSeek 出来以后，反而像是一个警钟，大家又发现，原来智能更高以后，前面这些东西可能都没有那么重要。

所以现在我的感觉是，大家又回到追求 AGI 的路线。从你的视角来讲，是不是这么回事？

丁丁

### DAU 不是智能指标

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

过去在移动互联网时代，大家用什么来衡量产品是否成功？用户规模可能就是一个非常直接的指标。其实这正好也跟 benchmark 相关：大家没有一个客观指标能够评价你的东西到底做得怎么样，很难讲我的模型做了一年就比别人强多少。Benchmark 大家又都知道可以刷分，所以不管是内部定 OKR、KPI，还是对外面向资本市场和用户，能够评价的可能就是 DAU。

所以我觉得这也是一个必然结果。我觉得 DAU 并不是不重要，而且其实你必须要有用户，才能获得反馈，获得真实的用户输入。只是说，一味地追求 DAU，对模型能力的提升可能没有帮助。

这里面我觉得也可以从 benchmark 的来源来理解。我们所说的 benchmark 有哪几种来源？一种是刚刚说的基准通用 benchmark；还有一种可能是用户线上真实的反馈，可能跟 DAU 或者用户使用情况相关；另外还有人工构造的 benchmark，包括合成数据 benchmark。

刚刚我们说的 DAU，会积累用户数据，而且你有一定的 DAU 规模，一定能够帮助你获得独家数据。但问题是，用户输入很多时候噪音太大了。比如一个快手来的用户，和一个真正把模型当生产力工具、聊 50 轮上下文，最终输出一份调研报告的用户，他们的数据可能完全不一样。

也就是说，用户数据仍然重要，但是高质量的用户数据和我们想要提升的模型能力之间，必须是 aligned 的。你必须挑选准确的 benchmark，才能对模型智能的提升有帮助。

曲凯

我们一直在讲，数据对于模型来讲特别重要，长期以来也一直在讲数据是壁垒。大家会说 ChatGPT 发得早，有这么多用户使用，所以有很多数据，模型效果会更好。

但过去几个月，很多人在讨论 DeepSeek 到底要不要接这些用户，这些数据到底对 DeepSeek 有没有用。所以你觉得这些数据对于模型进展、对于智能水平提升，作用有多大？

丁丁

当然重要。当你没有用户数据的时候，公司的人或者产品经理本身也是有局限的。他不是每个行业的专家，也没有亲自尝试模型所有的用法，更没有尝试各种模态的混合输入。

我觉得用户数据或者高质量数据，恰恰能够提供这些行业视角。如果你能结合一些专家访谈、调研之类的工作，我觉得就能帮助每一家基座模型公司更好地理解用户，以及定义出更好的 benchmark。

曲凯

但你看，OpenAI 的数据肯定远高于其他家，Anthropic 一样追上来了。这个原因是什么？是不是数据肯定有用，但是用处还没有那么大？

丁丁

因为最终的表现其实有非常多的环节。你的 pre-training 基模训得好不好，后训练的过程做得好不好，SFT 激活得好不好，当时有没有使用 RL，还是大家都在使用 SFT，都会产生影响。

RL 也依赖高效的 infra 基建，以及对这个范式的绝对笃定。这些环节层层相乘，最终共同构成了它是不是一个好的体验。

曲凯

所以以你的模型产品视角，如果你是半年前的梁文锋，你要不要接那些 DAU 和数据？

丁丁

如果资源充足，我一定想接。

曲凯

但前提是资源充足，对吧？恰恰就是资源不够充足。

丁丁

还是想接，这是不是古典产品经理的通病？

曲凯

你会吧？对吧？你这么多用户来，还是有这个想法的，我觉得。

丁丁

但从最后结果来讲，他们好像就顺其自然，对吧？他也没有特意的要去接这个东西。

曲凯



然后我们讲回到你在模型公司做的那段时间。最终总结下来，你觉得最大的几个收获和经验是什么？

丁丁

### Benchmark 进入实战

我觉得还是对模型评估，以及对整个 benchmark 的认知。

我之前做过搜索产品，搜索以前也会有一些评测，这个工作还是有点类似的。但在过去做搜索的时候，评测数据集变化的速度可能没有那么快，你可以用一套相对通用的测试集，使用很长一段时间。

但是在模型公司，因为模型能力本身也是动态迭代的。当模型某一个维度上的能力通过一个 benchmark 已经解决了，这个 benchmark 的生命周期可能就结束了。之后你可能就需要定义很多不同维度、不同梯度的 benchmark，一步步推进模型的进步。

最终，模型智能的体现就是 benchmark 的难度。无非就是说你出什么样的题，得到一个什么样的结果。最终让各家模型产品拉开差距、表现出各自特点的，恰恰是它们对 benchmark 出题这件事的不同定义。

曲凯

我能不能简单理解为，evaluation 肯定是最重要的？对于模型的表现和产品最终表现来讲，evaluation 就是通过 benchmark 来进行评估和实现。Benchmark 可能是第三方，或者产品内部自己出的一套题。

你能不能举一些例子？这些题大概是什么样的？

丁丁

比如一个典型的深度搜索题，可能会是：“你能帮我把腾讯过去 10 年的财报都找出来，并且预测一下今年它的净利润会上升多少？”

这个时候模型会有一个输出，然后会有另外一个 reward 来评价模型的输出到底好不好。刚刚看到的输入、输出，以及对输出的评价，就构成了一个 benchmark 最小颗粒度的单位。

但实际上，在不同业务当中，评测标准或者在意的点是非常不一样的。比如刚刚讲到，如果你做深度搜索，你可能希望模型能够基于检索到的所有数据源，给出一个尽量真实且全面的结果。

但如果你是一个 Character.AI，它可能是一个情感陪伴类产品，那刚才的标准就变得不重要了。你不希望它在情感陪伴的时候说：“根据你的心情状态，我有以下几个建议：一，什么；二，什么。”

但也许这种结构化输出，在研报等很多场景下又非常适用。所以这又回到了刚刚讲的：在不同业务场景中，评估标准的好坏会有非常大的区分度。

曲凯

所以我听起来，这个问题其实就是用户在真实场景中会给的一段 prompt，对吧？它作为一个问题，然后你去评估的时候，可能不是简单地判断对错或者好坏，而是分好几个维度，甚至会有一个很复杂的表格来评价这段话。

丁丁

我觉得最终一定能够抽象出几个维度，然后让模型学习你对“好”的判断。

曲凯

但这几个“好”也是有优先级的吗？我在想，有的场景里，给用户的回复是不是足够口语化、长度是不是适中，可能是好几个标准。这几个标准有时候可能是相悖的：有可能这个是 A 好，那个是 B 好，那最后怎么定义好呢？

丁丁

还是会回到真实的用户场景。比如 Character.AI 的场景，产品侧的业务视角已经做了一层判断：对用户意图的理解和口语化，可能比其他指标更重要。

所以在这个过程中，你抽象的不只是元素和分类，同时也会抽象它们的重要性。

这里面有一个非常有意思的例子，就是当时 DeepSeek 出圈的时候，很大的原因是大家觉得 DeepSeek 的文风特别有意思，显得非常有哲思和优雅。但其实这背后反映的是，他们的团队对于什么是“好”这件事情，一定有一条隐含标准：模型这样回答是好的。

在那之前，没有任何一家公司，哪怕把时间倒回到 DeepSeek 出现之前，我们在内部说这种文风很重要，大家一定会觉得它是一个好的指标吗？我觉得也未必。

所以模型评估本身就是特别难的一件事情。我觉得，所有人都有共识且 100% 正确的评价标准，其实不太好制定。

曲凯

我听起来，这个世界上好像就没有百分之百确定的标准。它还是一个比较偏人类喜好的结果。

丁丁

要看是哪些领域。数学题肯定有，代码题肯定有，这些有 ground truth 的题目就比较好做。今天大家也会非常偏好采用这类题目，因为它有一个标准答案。

但对于一些不好量化的层面，比如语言风格、表达方式等，我觉得这些其实不太好制定，甚至没有共识。

曲凯

从这个角度，我在想两个问题。

一个问题是，如果是这样，未来会不会应该有更多模型？每个模型都有自己的性格，有的人喜欢这个，有的人喜欢那个。

另外一种可能是，未来 benchmark 会不会细到给不同人群做分类？比如我有 1,000 个用户，极端一点，我甚至有 1,000 个 benchmark，分别对应不同的用户，每个人得到的结果都不一样。

丁丁

### Benchmarks Become Personal

对于第一点，我觉得是的，其实现在已经有一些偏好了。比如当你编程的时候，第一优先级肯定会选择 Claude；但如果你做一些深度搜索，可能今天就会去用 o3。

对于第二个问题，我觉得可以换一个角度，最终还是要把这种个性化抽象到某种模型能力或者产品能力上。举个最简单的例子：能不能通过 memory 来解决你刚刚说的个性化偏好？我觉得有这个可能性。

OpenAI 本身也在努力做这件事。所以可能不一定需要像你说的那样，把 benchmark 细分到那么多，但它一定会通过某种模型内化的能力，帮助你达成最终目标。

曲凯

我又想了一个极端例子。假设还是一个 Character.AI 产品，公司本身希望这个产品的情商越来越高、智商越来越高。但如果有个用户说：“我就喜欢蠢的。”他会通过各种对话去调教这个 bot，希望这个 bot 变得越来越蠢。

但同时，这家公司的底模就是想把它变得越来越聪明。这是不是一个矛盾？

丁丁

我觉得不是。用户希望它“蠢”，本质上是一种指令遵循能力，也是模型的基础能力。要让它足够聪明，以至于它可以扮蠢。

曲凯

最顶尖的人，我觉得也是可以做到这样，大智若愚。面对不同的人，完全可以去迎合对方的喜好。

Benchmark 我听起来，好像大家能想到的应该差不多。所以有没有一两个例子，是你觉得特别巧妙、别人不太容易想到，但定出来以后对产品和模型提升特别有帮助的？

你刚才说的那种，我觉得大家坐在那里硬想，总归能写出各种题目，包括去看用户互动的数据、提问的数据，做个排序，大概也能分出来一些。最终 A 公司和 B 公司，通过 benchmark 定义的不同，带来的结果不同。这个 benchmark 的不同到底体现在哪儿？

丁丁

首先在同一领域，benchmark 的难度可能就不一样，而这个难度通过什么体现？就是通过你怎么理解这个业务。

比如一开始你做搜索的时候，会用一些特别简单的题目，当时可能会觉得这就是用户输入。但再过一段时间，你会发现，有些金融领域的用户可能会通过上下 5 到 10 轮对话，提出一个比较复杂的 prompt，然后让模型直接一步到位输出结果。

这时候你可能就会有一个更难的 benchmark。对于这个 benchmark，什么是好的标准，各家公司一定也会有差异，而这个差异会直接引领模型迭代的方向。

另外，过去模型确实可能会出现这样的情况：你把模型 A 训练好了，可能就直接丢到了模型 B 上。但我们最希望出现的场景，是在前一代模型的基础上，新的能力不断增长。

这个时候你更看重哪个方向的能力，我觉得也是一种取舍。

曲凯

Benchmark 的好坏，是不是还是一个相对主观的事情？有哪些客观指标能够衡量？

丁丁

### Benchmark 需要持续迭代

一个比较好的 benchmark，可能有几个原则。

首先，它一定是真实的，能够反映线上用户的需求；同时也要有一定的难度和区分度，不能所有题目的难度都一样。

其次，benchmark 要随着整个模型迭代的生命周期流转。刚刚说过，你可能会抛弃旧 benchmark，也可能加入新的题目。

曲凯

古典产品经理看的指标，可能是用户使用频次、使用时长，对吧？放到 AI 里面，可能就是对话轮次，以及留存这类数据。那 benchmark 和这些数据是挂钩的吗？

丁丁

它一定存在关联关系。Benchmark 本质上反映的是模型某一方面的能力到底好不好用，而好不好用本质上又会转化成用户指标。

只不过今天的用户指标可能像我们刚刚说的那样：模型好，并不一定代表 DAU 好。在不同业务下，相关的用户指标可能会变化。它最佳的用户指标，也可能是某种我们还没有想到、但更好的指标。

曲凯

我前两天还在想一件事：Manus 火出圈了，Manus 的核心用户指标有可能是什么？我能想到的可能是最少步骤，以及结果被用户下载或者引用的比率。

所以 benchmark 跟最终的用户指标是强关联关系吗？你们会不会看，比如我今天出了这个 benchmark，如果它变得更好，理论上这些用户指标应该也变得更好？

丁丁

是的。如果没有变得更好，就要去改你的 benchmark，至少要让它们不断 align，不然你的评估就没有意义。它们应该是正相关的。

另外，在做 evaluation 的时候，可能会涉及 auto eval 和 human eval：一个是用大模型评价自己模型的任务完成效果，另一个是用人最终评价端到端的效果。

我理解这两种 eval 也需要不断校验。不然就会出现模型自动打分，打出来的结果却跟真实用户体验之间存在 gap 的情况。这个过程本身也是动态的。

曲凯

就你现在跟 AI 公司产品经理交流下来，你觉得大家对于 benchmark 的理解和实践，已经差不多在同一个水平了吗？还是会有哪些差异化的东西？

丁丁

首先，创业公司和大厂可能会有一些分化。

大厂里我看到的是，不同团队还在按照以前的方式流转：高质量数据标注和评测集，完全由数据团队去做；评测或者策略产品拿到结果以后，再去跟功能侧或者端侧产品沟通。我觉得这里面的断点其实比较多。

但对于创业公司来讲，因为团队足够小，或者组织方式不一样，大家的认知迭代其实比较快。

曲凯

Benchmark 多久变一次比较合理？

丁丁

我觉得没有标准答案，越快越好，还是要看数据。

曲凯

对，越快说明你们模型能力迭代得越快。但对于很多创业公司来讲，如果它不动模型，迭代的应该是预制的 prompt 和工程侧的能力，然后影响它的结果。

丁丁

我补充一点：一开始用户基数比较少的时候，评价维度可能相对单一，因为用户分化也不严重。当用户变得更广之后，用户需求分布会越来越不一样。

在这种情况下，你仍然要适应不同用户，达到最好的效果，那你的标准可能也会进行补充或者调整。

曲凯

我又想到几个问题。一个是你觉得市场里，尤其是创业公司来讲，它的 benchmark 大概在多少量级比较合理？

比如说今天你自己要做一个创业公司，一开始会出多少道题来测这个产品？假设是 400 道题，这个题是越多越好，还是越少越好？

丁丁

我觉得不是越多越好，而是你能够衡量模型的表现就可以了。

曲凯

那我能不能先让产品上线，让用户使用起来，然后把用户所有的 prompt 排序，或者做一个类似模糊搜索的东西，最后排出前 400 个，就把它们作为我的 benchmark？

丁丁

你说的这个特别有意思，因为这就是以前搜索 benchmark 之一：对高频 query 的效果进行评测。

但还是那个问题，你可能要过滤一些噪音，或者没有那么有效的用户数据。另外，跟搜索一样，很多需求可能非常长尾。你如果只解决头部的 400 个，剩下的需求怎么办？

曲凯

假设整个 QV 量是 100 万，头部 400 个可能只覆盖其中 20 万，那剩下的 80 万要不要解决？

丁丁

肯定要解决。所以又回到我们刚刚说的原则：还是要尽量符合线上用户的分布，而不是单一地只看头部。

但我们确实会更关注大家都会去看的一些强烈负反馈信号，这种信号可能更能帮助你判断底线问题。

曲凯

如果现在给你一家公司，它的 benchmark 是 400 道题、40 道题或者 100 道题，你能很快分辨出这个 benchmark 的好坏吗？大概会是什么样的？

丁丁

我觉得首先要看它是不是我所了解的领域。假设是我了解的领域，当然可以，因为你能知道它的 benchmark 是否有梯度，是否符合你对产品的理解、用户需求以及真实数据分布。

曲凯

你举一个典型的坏 benchmark 的例子。

丁丁

我做了这么多好的 benchmark，从来没人问过我一个坏 benchmark 长什么样。

比如它特别简单，或者 benchmark 里的题目单一地集中在某一个维度、某一个困难程度上，那就是一个非常糟糕的 benchmark。

曲凯

我听到这里，感觉给模型表现做 benchmark，有点像给你一堆点数，让你去点不同的技能树。

有没有一种可能，我把所有点数都点在某一项上，让长板足够长，用户对我这个产品的长板感知足够明显，反而可以脱颖而出？还是说平均地去点这些点数才是最好的选择？

丁丁

这个问题可能得分两层看。

一个是基座模型的能力。我们会看到，基座模型能力越强，它在一些垂类里的表现确实也会越好，这就是泛化能力。你什么都不做，天然一个博士生就是比一个小学生更聪明。

但另外一个视角是，在此之上，确实存在一些垂直产品、模型或者 agent 的机会。它不完全只基于模型能力，而是加入很多其他因素，比如工程能力、独家数据，以及对业务本身的理解。

比如有一个业务就是做销售，那么它可能比其他任何公司或者任何人，都更了解销售这件事情中的交互，以及抽象出的正反馈信号。这样一来，它就可能设计出更好的基于模型的产品，也能告诉模型到底应该奖励什么。

曲凯

明白。那我们举一个例子，大家日常可能都用过类似 Character.AI 这样的聊天类产品。

假设现在你做一个 AI 陪聊类产品，难点可能在哪里？要怎么做这件事？

丁丁

情感聊天或者陪伴这个场景，因为没有 ground truth 或者标准答案，所以评估标准到底怎么定才完全准确，这件事情还挺难衡量的。

比如现在你在跟一个陪伴型产品聊天，你说：“我今天失恋了，跟我的对象分手了。”你预期模型会怎么回复你？

如果没有做过口语化或者情绪识别回复的模型，它可能会说：“听到这件事我很难过，我给你推荐以下几种方式来放松心情：一，下楼跑一跑；二，去见见朋友。”

曲凯

非常有画面感，很多模型确实是这样的。

丁丁

但你觉得比较好的回复，肯定会希望它首先像一个真人一样，可能会问你：“怎么了？”

如果它具有 memory 能力，甚至可能会问：“不是上个星期你还跟我讲，你们俩之间好好的吗？”

有的模型可能会关心具体出了什么问题；但有的模型可能会回复：“抱抱你，我一直都在这里陪你。如果你有什么不开心的，仍然可以跟我分享。”

一个真实的人在这种情况下，到底预期获得什么样的回复，我们没有一个非常细、百分之百正确的答案。我们只能尽量说，在这种情况下，希望模型首先关注到用户情绪的变化；其次，从 memory 的角度，希望它知道用户的情感状态，判断要不要进行 callback。

再从心理咨询师这类专家的角度来说，我们不会急着给解决方案，而是会关心背后到底发生了什么，让用户先把自己的情感状态和具体故事倾诉出来。

曲凯

我听起来就觉得，这件事确实非常难定义。因为有的人可能就是喜欢解决问题；有的人喜欢别人怼他一下，说：“你失恋了又怎么样？别把它当回事。”还有的人就喜欢有一个像闺蜜一样的人去安慰他。

几乎无法定义一个好的 benchmark。

丁丁

从这个角度来讲，我觉得未来一定会出现一些小众、猎奇的产品。因为像你刚刚讲的，benchmark 的定义可能只能照顾到 80% 的用户。也许加上个性化和足够强的基座模型能力，也能够解决一部分问题。

但我其实还在想一个更抽象的问题：我们刚刚在定义很多评价标准或者价值观的时候，会发现它整体上是人类价值观的映射。这件事情对吗？

曲凯

这个确实很抽象。

丁丁

无非就是，你觉得整个人类世界当中，一定存在某个问题上相对更好的答案，所以你再去做这个映射。但这种映射真的是对的吗？我不知道。

我在想，答案可能分两种：一种是社会约定俗成的答案；另外一种可能是更高级版本的答案。比如你在讨论一个问题的时候，身边的朋友都会给你一个答案，但这时可能有一个类似教授角色的人，会给你另外一个答案，你会觉得这个答案可能更有醍醐灌顶的感觉。

我觉得在做题、生产力等很多场景里，这种方式现在还是 work 的。但刚刚讲到的那些场景，有时候就会让人想：这样就是完全准确的吗？不好说。

曲凯

所以从这个角度来讲，生产力类产品的确定性更强，或者说它的标准相对更好找，也就更好做，benchmark 肯定更好定义。

以前不是会有公司说偷竞争对手的代码吗？未来会不会说偷 benchmark？

丁丁

这个话题特别有意思。我觉得 benchmark 确实是一个核心资产。如果是我的话，可能会维护一个只有自己知道的 benchmark，甚至算法团队的同学也不应该知道。

因为如果他们知道了，可能会在训练过程中不由自主地让模型答出这些问题，也不知道会不会被 hack。

我可能每次上线之前测一下，但不会公布 benchmark 具体是什么。所以 benchmark 确实是一个特别特别重要的东西。

曲凯

你之前最早在微信做搜索类产品，后来又在美团做过策略产品，之后在 Kimi 做模型产品。你回过头来看，AI 产品经理和古典产品经理相比，大家相同和不同的地方在哪儿？

丁丁

### AI 产品经理的新能力

我觉得相同的地方是懂用户。相同的能力点叫做翻译能力，也就是发现问题，并把用户和业务场景进行抽象。

比如过去的抽象，可能是抽象在交互设计和整体结构设计上；今天在模型产品里，就是把业务的整个流程抽象出一种好的评估标准和观测指标。

所以我觉得抽象能力，以及对用户场景和需求的翻译能力，仍然非常重要。

另外，我觉得原来古典产品经理非常重要的一点，是对交互体验的敏锐感知能力：什么是美的，什么是丑的，什么是符合直觉的设计，什么又不是。这种能力仍然需要，而且我觉得是稀缺的。

现在大家谈了很多模型，但今天一个不同产品基于模型能力的最佳交互，其实还没有诞生。在一些垂类产品里，交互可能会更加重要。这种交互甚至会直接反映出，你能不能为模型迭代或者产品迭代设计出合适的反馈节点和反馈信号。

不同的地方在于，对数据的重视程度会发生非常大的变化。现在会比以往更加重视数据质量，还有对模型能力边界的理解。这个过程，我觉得也需要很多时间去积累。

曲凯

这部分我觉得可以展开讲讲，应该是最难也是最重要的一部分。

现在模型进展其实还是很快的，有的人会担心：我现在做的东西，半年后是不是就会被模型颠覆掉、没有用了？或者我做的整个产品，是不是就在模型的发展路线上？

怎么样才能像你刚才讲的那样，更理解模型的边界，并且预判模型的边界？

丁丁

我先说方法层面。这个问题可能也有很多产品经理跟我讨论过。我觉得还是要多用不同的、最好的模型，以及它们的 API。你会理解不同模型在不同领域、不同能力上的表现，也会更加熟悉模型每隔 1 个月、2 个月的变化，因为它一定会有新版本和能力提升。

第二点，之前内部同学也会分享：把所有你觉得想做的事情，先用 AI 做一遍。

比如以前做 C 端产品，除了 PRD 之外，可能还要先画交互。你可以试着把想要的交互逻辑清楚地说出来，然后让 Claude 帮你制作一个交互。在这个过程中，你就会摸到模型能力的边界，以及它能帮你实现什么。

在这种动态地跟模型一起迭代、使用的过程中，你可能会发现，它某个方向的能力比你想象中变得越来越强。

这个例子也可以回到前阵子非常火的 GPT-4o 的“言出法随”图像生成。你在没有体验到它之前，可能会觉得生成一个指令遵循、特别是支持上下文多轮修改的图像非常难。但今天你会发现，GPT-4o 完全能做到。

这就是伴随着模型能力边界的迭代而产生的机会。在这个基础上，你可能又能快速做出一些新的产品。

另外，我觉得你的动手能力要很强。不需要像过去的产品经理一样，有非常强的模块流转意识，而是要完全丢掉这个意识。

你要把自己同时当成一个产品经理、设计师和前端。现在可能还不能完全当后端，但也可以试一试，然后完成全流程的闭环。我觉得这对你理解模型也会更有帮助。

曲凯

所以未来你是不是也觉得，每个人真的都会变成全栈？

丁丁

我觉得是。

曲凯

你自己会看论文吗？之前 HACK 做了一期播客，我们也有很多人听，我是那期的忠实用户。张涛在那期里讲了很多点，他自己会日常去看论文。

你觉得看论文是 AI 产品经理的必备能力吗？

丁丁

我觉得是。这个习惯非常重要，因为理解原理，以及在理解原理的基础上做验证，本来就是一体的。

我没有见过哪个人会使用模型，但完全不关心原理的实现。你肯定会想知道它为什么会这样、为什么某些能力做得比较强。

当然，你理解论文的深度，可能跟算法同学理解论文的深度完全不一样。论文也分很多种类，如果完全是在讲算法，我觉得即使我努力看，也不一定能看懂；但如果是讲一些比较前沿的判断，其实也可以搭配着去看。

曲凯

从你做过模型产品的视角来看，你觉得创业公司，或者正在做 AI 产品的人，做哪些事情不会被未来的模型碾压？能给一些大概的判断标准吗？

丁丁

首先，我觉得他可能需要有很深的领域 know-how，同时又具备对模型的理解。这样他可能会在这个阶段，成为最快把两者结合起来的人，形成一定的产品壁垒或者行业认知，并积累用户。

曲凯

我们最后还是讲回到你在微信的那段经历。稍微回顾一下，你在微信那段经历里，有哪些印象特别深刻的东西？

我们前面讲了很多 AI 产品的东西，但那段经历反而是大家认可的、古典产品经理非常经典的一段经历。

丁丁

我觉得有一些产品原则。

一个是先做产品结构，然后才是功能细节。比如我们会发现，微信里有很多功能，如果都用不同的 tab 来表现，不做层级拆分，那今天可能会非常冗余，也会非常复杂。但直到今天，微信还是比较简单，也只有 4 个 tab。

曲凯

这个真的是张小龙一上来就已经想好的吗？就是说我要这几个 tab，要怎么做朋友圈、做公众号，再怎么做其他功能？

丁丁

我觉得底层结构他从一开始就想得非常清楚。包括他抽象出“扫码”这样一个新的入口，扫码背后提供的是一种服务能力。这些事情甚至在小程序诞生前两年，张小龙就已经想好了。

另外，功能模块之间是有机联系的。当时很多用户都说，微信要是能不只用一个头像就好了，最好有多个头像，可以左滑右滑。

但实际上你会发现，用户背后的需求是想要有更多头像照片展示给别人看。所以这个需求应该由朋友圈来承载，而不是在头像这个单点上做设计。

这就是刚刚说的，功能模块之间是有机联系的。

另外，我们不会主动强教育用户一定要使用哪个功能，而是让用户在使用某个功能、继续往下钻的时候，自己发现一些新的体验，然后触发新的能力。

曲凯

所以你后来在其他公司，包括模型产品公司做过以后，觉得这些东西仍然适用吗？

丁丁

我觉得适用。底层原理其实还是一样的。

我觉得从微信出来的产品经理，有一个被训练出来的点，就是大家都会基于更全局的视角，真正去想什么是好的体验。

但今天在一些公司，因为验证某些能力和功能的设计太简单了，上 A/B 实验又非常方便，你可以跑 8 个实验，甚至 20 个实验，只要选最终把指标做正的那个就可以。

这样一来，年轻同学在做方案的时候，就不会真的去想用户需不需要这个功能、它跟全局有什么联系、这么做到底是不是好的，因为可能只要跑实验就好了。

曲凯

其实我们刚才讲过好几次古典产品经理。但我理解，这个概念最早提出来，是说古典产品经理依靠很多个人经验和感觉，依靠用户感知来做事情。它最早对应的，可能就是更多的 A/B test 和实验型的数据驱动产品。

比较典型的，美国很多大厂会做很多 A/B test，字节也是以这个出名的，对吧？它也做各种 A/B test，最终看数据。如果数据好，哪怕你解释不清楚为什么会这样，它也是好的。

不知道你最后会不会同意这个说法？

丁丁

谈这个问题之前，我觉得可能得再往上说一层：每个产品首先都有自己的个性，或者说有自己的感觉。

比如微信给人的感觉就是比较内敛、极致简单；Instagram 给人的感觉就是很时髦、很漂亮，是一种很 fancy 的感觉。我觉得这种调性肯定不能通过 A/B 实验得到。

你的产品打开以后很乱，但留存比原来高了，这其实是一种价值观取向：你是不是为了追求指标，就能容忍产品增加那么多东西？微信的取向就是绝对不可以。

第二个问题是，你选的指标到底对不对。公司大了以后，每个部门、每个业务的指标，其实都会存在被 hack 的空间。

因为它关注的不是一个统一的大指标，也不一定遵循某种调性或者价值观的体现。它可能只要做正自己业务的指标就可以了，即使这种做法可能非常违反直觉，最后对大指标来说甚至是负的。

曲凯

最后一个问题：如果一家创业公司想招一个好的 AI 产品经理，现在其实挺难找的，也没有一个典型画像能说明这个人就是 AI 产品经理。

你觉得大家到底应该怎么找，或者怎么培养这样的人？

丁丁

### AI 产品经理的招聘标准

首先，如果从背景上来讲，我可能会更偏好在初创的模型产品或者更小的公司里，完成过从 0 到 1，或者端到端工作的同学。也就是更全栈、自己从头到尾做过一些东西的人。

第二，我也看到过一些同学会利用业余时间，做一些小 demo 或者小产品出来。我觉得这是一个非常好的信号。

因为如果你是一个好的 AI 产品经理，本身就像你说的，可能是个全栈。产品可以不用特别突出，但你肯定自己跑过一些东西，验证过一些东西。

第三，我觉得可以直接问他：“你最喜欢的模型是哪个？你平时用得最多的模型是什么？一般在什么场景下使用？为什么使用它们？”

即使前面两条没有满足，从第三点也可以看出他对整个行业的理解、热情，以及专注度。
