Kevin Weil 在 OpenAI 办公室打开 ImageGen 内测版时，公司内部的小画廊像炸开了锅。每个人都在疯狂生成图片，刷新页面看别人在做什么。工程师把自己的狗变成吉卜力风格，设计师让客厅家具按照 AI 建议重新排列，连首席人才官都用 Windsurf 花 30 分钟给自己做了个内部工具。
如果你还在用 PPT 做产品评审，你可能正在用打字机时代的方式工作。
Kevin 是 OpenAI 的首席产品官，掌管着这个星球上最重要的 AI 产品。在此之前，他带领过 Instagram Stories、Twitter 产品线、Facebook 的 Libra 加密货币项目。但这次不同——他面对的不是一个稳定的技术平台，而是每两个月就能做到「以前从未做过的事情」的 AI 模型。
这个人的日常工作，就是站在风暴中心，思考 3 亿开发者和 4 亿用户将如何与超级智能对话。
困境从一个事实开始
在传统公司做产品，你知道自己在用什么技术。数据库今年可能比两年前好 5%，你可以花时间想清楚要解决什么问题、为谁解决、怎么改变用户习惯。
但 AI 的世界完全不同。
Kevin 说，如果你现在给他 GPT-3，插到 ChatGPT 里，他会觉得「这是什么东西？一片混乱」。而这个模型在两年前推出时，所有人都震惊了。
问题是，你无法用开发传统产品的方式开发 AI 产品。因为 LLM 不会给你确定性的答案——你做同样的事情三次，可能得到三个不同的输出。它们擅长模糊微妙的输入，但输出也是模糊的。
这意味着，当你构建产品时，模型在 60% 时间内正确、95% 时间内正确、99.5% 时间内正确，你要做的产品完全不同。
数据库工作一次，它每次都会工作。但 AI 不是。
转折点在一次产品评审
Kevin 和团队在开发「深度研究」(Deep Research) 功能时，遇到了这个问题。
这个功能的设计目标是：你给 ChatGPT 一个复杂问题，它会像人类研究员一样花 25 到 30 分钟，阅读论文、网页，发现思维漏洞，再去做更多研究，最后写出 20 页的答案——完成你一周才能干完的事。
但他们怎么知道这个功能「够好」了？
答案是：写评估。
评估(Evals)，本质上就是给模型出考卷。就像你上微积分课要参加微积分测试，检查你是否学到了该学的内容。你可以评估模型的创意写作能力、研究生阶段的科学研究能力、竞争性编码能力。
Kevin 的团队在设计产品的同时设计评估，把「英雄用例」(hero use cases)转化成考卷——这是你想问的问题，这是一个令人惊艳的答案——然后让模型在这些评估上「爬山」，持续学习。
当评估分数开始上升，他们就知道：「我们这里有一个产品了。」
模型不是静态的。你可以教它。
方法论拆解：如何用评估驱动产品
重场景：在客户支持场景中，评估如何变成生产力
OpenAI 每周有超过 4 亿活跃用户，客户支持团队只有 30 到 40 人——比任何同类公司都少得多。
秘密在于自动化流程，而自动化的核心是评估。
他们把内部知识库、回答问题的指南、个性类型等信息喂给模型，教它回答大多数问题。当模型对某个问题没有完全信心时，它会建议一个答案，请求人类审核。而那个人类的答案，会自动成为模型的微调数据——你在特定情况下告诉了它正确答案。
这个循环的关键是：你得先有评估，才知道模型在哪些问题上能达到 99.5% 的准确率(可以全自动)，哪些只有 60% 的准确率(需要人类兜底)。
更进一步，他们在不同环节使用不同模型。需要更多推理、对延迟不敏感的地方，用 O 系列推理模型；需要快速检查的地方，用 Four Oh Mini，超快且超便宜。就像一家公司是「一系列模型的集合」，每个人都根据自己在大学和职业生涯中学到的内容进行了微调，拥有不同的技能组合。
Kevin 说：「你可能对不同的问题有不同的延迟要求或成本要求。基本上，你想将问题分解为更具体的任务，然后用专门的模型来很好地完成每件事。」
但这套体系能运转，前提是你得先写出好的评估。
问题出在下一步。
轻步骤一：找到你的英雄用例
不要试图让模型「什么都能做」。先找到一个具体场景，一个具体问题，一个令人惊艳的答案。
深度研究的英雄用例是：「我想研究一个复杂话题，需要阅读论文、网页，思考一周，写出 20 页报告。」然后把这个场景变成评估。
轻步骤二：用评估倒逼微调
当你有了评估，你就可以微调模型——给它一堆「这是问题，这是好答案」的例子，乘以一千或一万次。突然间，模型在处理这件特定事物时，比一开始好得多。
轻步骤三：把评估嵌入团队工作流
OpenAI 内部，每个产品团队都有研究人员、工程师、PM、设计师。他们不是「研究人员做出模型，然后产品团队拿去用」，而是「一起设计产品，一起写评估，一起微调模型」。
Kevin 说：「最好的产品将是由 ENG、产品、设计和研究团队作为一个团队共同努力打造的新颖产品。」
如果你看到一个功能在某些场景下正确率只有 60%，你会设计完全不同的产品形态——可能需要加人类审核，可能需要拆解成更小的步骤。
轻步骤四：模型极繁主义——相信模型会追上
Kevin 反复提到一个哲学：「模型极繁主义」(model maximalism)。
他们的总体思路是：两个月后将会出现一个更好的模型，它将打破目前的所有限制。所以如果你正在构建的产品正好处于模型能力的边缘，那就继续，因为你做的事情是对的。再过几个月，模型就会变得很棒，突然间，你刚刚勉强能用的产品就会真正大放异彩。
这也是他们对开发者的建议：不要在不匹配的地方构建太多脚手架，因为模型很快会追上。
理论升华：评估是产品经理的「单元测试」
想想软件工程师为什么要写单元测试。不是因为他们不信任自己的代码，而是因为他们知道代码会变——有人会改一行逻辑，有人会升级依赖库，有人会在凌晨 3 点修 bug。单元测试的作用，是确保「这个函数在这个输入下，永远输出这个结果」。
评估之于 AI 产品，就像单元测试之于传统软件。
区别在于，传统软件的「正确」是确定的——1+1 永远等于 2。但 AI 的「正确」是概率的——这个模型在这个问题上有 95% 的概率给出好答案。所以你需要评估来量化「好」的标准，然后持续监控模型是否退步。
Kevin 说得更直白：「AI 的惊人程度几乎取决于我们在评估方面的表现。」因为智能从根本上来说是多维的——一个模型在竞争性编码方面非常出色，可能与它在前端编码、后端编码、或将 COBOL 代码转换成 Python 方面的表现完全不同。
你需要针对每个维度写评估，才能知道模型在哪些地方「够格」上生产。
局限性提醒
这套方法论有明确的适用边界。
首先，它适用于「模型能力正在快速提升」的阶段。如果你面对的是一个成熟、稳定的技术平台(比如数据库)，写评估的价值就没那么大——因为数据库不会每两个月变聪明一次。
其次，写评估需要资源。OpenAI 只有 25 个左右的 PM，但每个产品团队都有研究人员、工程师参与。如果你的团队没有懂 AI 的人，写评估会变成一件「不知道从哪里开始」的事。
最后，评估不能解决所有问题。Kevin 提到，他们仍然会犯错，会推出不够好的产品，会撤回功能。评估只是帮你「更快地知道你错了」，而不是「确保你不会错」。
余韵收尾
Kevin 的首席人才官 Julia，前几天用 Windsurf 做了一个她以前工作时用过的内部工具。她真的很想在 OpenAI 中使用这个工具，然后她打开 Windsurf，花了不到一小时，把它做出来了。
Kevin 说：「如果我们的首席人力资源官正在这样做，我们没有理由不做更多。」
他停顿了一下，「实际上，我仍然对我们感到有些失望。如果我将我五年前在其他公司开发的自主主导产品传送到我的日常工作中，我仍然会认出它。我认为我们应该处在这样一个世界，肯定是一年后，甚至可能更久以后，我几乎认不出它了。」
这可能才是真正的转折点——不是模型变得多聪明，而是我们什么时候开始用「认不出的方式」工作。