[OpenAI CPO亲述：别再写死代码了，"Evals"才是AI时代的生死线]
📝 创作说明
- 选题方向: AI产品构建核心逻辑与"深度研究"（Deep Research）背后的实操方法论
- 评分: AI相关性 48/50 + 故事性 42/50 + 加分项 15/20 = 总分 105/120
- 字数: 2150/2000字
- 核心价值: 揭秘OpenAI内部如何用"Evals"机制驯服不确定性，以及"Deep Research"产品从0到1的具体构建流程。
正文内容
开场钩子
你现在手里用的 ChatGPT，是你这辈子用过的最烂的人工智能。
听起来很刺耳？但这正是 OpenAI 首席产品官 Kevin Weil 每天面对的现实。在这个每两个月模型能力就会发生"质变"的疯狂时代，你今天引以为傲的护城河，可能下个月就被一个新的基础模型彻底填平。
大多数人还在纠结 Prompt 怎么写的时候，OpenAI 内部已经彻底改变了产品构建的逻辑。他们不再写死板的代码，而是在"训练"模型。如果你还用传统的软件工程思维去对待 AI 产品，你的失败率是 100%。
主角背景
Kevin Weil，现任 OpenAI 首席产品官（CPO）。
这个位置，堪称目前硅谷风暴眼中的"暴风眼"。在加入 OpenAI 之前，他掌舵过 Instagram 和 Twitter 的产品部门，甚至还参与过 Facebook 那个野心勃勃却最终折戟的 Libra 加密货币项目。
作为一个在传统互联网大厂摸爬滚打多年的老兵，他曾习惯了确定性：点击按钮 A，必须跳出页面 B。但当他坐上 OpenAI 的驾驶座，他发现以前的经验不仅没用，甚至可能有毒。他面对的是一个拥有 300 万开发者的庞大生态，以及一个永远在"胡言乱语"和"绝顶聪明"之间反复横跳的超级模型。
核心冲突
传统的软件工程是建立在"确定性"之上的。
你写一个数据库查询，要么成功，要么报错。如果成功率是 99.95%，那就是合格的；如果是 60%，那就是严重的 Bug，工程师得连夜修补。
但在 AI 的世界里，规则崩塌了。
Kevin 发现，LLM（大语言模型）本质上是概率性的。你给它同样的输入，它可能三次给你三个不同的答案。有时候它能写出诺贝尔奖级别的分析，有时候连个简单的加减法都会算错。
痛点非常具体且量化：对于 OpenAI 的产品团队来说，如果一个新模型在创意写作上提升了 20%，但在代码生成上准确率下降了 5%，这到底算进步还是退步？能不能发布？
在没有标准答案的情况下，怎么构建一个拥有 4 亿用户的超级产品？如果沿用旧的 QA（质量测试）流程，ChatGPT 可能永远都无法上线。
转折点
破局的关键，在于一个被称为 "Evals"（评估） 的核心概念。
Kevin 意识到，AI 时代的"编程"，不再是写具体的逻辑代码，而是编写考卷。
他们不再试图控制模型的每一个输出步骤，而是建立了一套庞大且复杂的自动化测试系统——就像给学生出题一样。这就是 OpenAI 能够保持极速迭代（Shipping fast）而不至于翻车的秘密武器。
特别是当他们决定开发"Deep Research"（深度研究）这个功能时，这个逻辑被发挥到了极致。这不仅仅是一个功能的开发，更是一场关于"如何教机器像人类专家一样思考"的实战教学。
方法论拆解：OpenAI 内部的"Evals"构建法与深度研究工作流
Kevin 毫无保留地拆解了 OpenAI 内部打造爆款产品（如 Deep Research）的 4 个关键步骤。这套方法论，对于任何想做 AI 应用（AI Agent）的团队都具有极高的复制价值。
第一步：定义"英雄用例"（Hero Use Case）
在开发"Deep Research"之前，OpenAI 的团队并没有先写代码，而是先做了一次残酷的人力测试。
他们设定了一个极其复杂的查询任务。如果让人类专家来做，流程是这样的：
- 花 2 小时在 Google 上海量搜索。
- 下载并阅读 5-10 篇专业的学术论文。
- 开始写草稿，发现逻辑漏洞。
- 回头再搜资料，补全信息。
- 最终产出一份 20 页的深度报告。
数据基准：人类专家完成这个过程，平均需要 1 周 时间。
Kevin 的团队把这个"1 周产出 20 页报告"设定为"英雄用例"。产品的目标非常明确：模型能不能在 25-30 分钟 内，达到人类专家 1 周的产出质量？
第二步：编写 Evals（把需求变成考卷）
这是最反直觉的一步。产品经理不再写 PRD（需求文档），而是开始写"考题"。
"Evals" 本质上就是 AI 的单元测试。你需要把"好报告"的标准量化成模型能理解的测试题。
- 准确性测试：引用的数据是否真实存在？（杜绝幻觉）
- 逻辑性测试：论点 A 是否能支撑结论 B？
- 覆盖率测试：是否覆盖了该话题的 3 个核心争议点？
Kevin 强调，撰写 Evals 将成为未来产品经理（PM）的核心技能。你必须懂得如何设计一套测试，来衡量模型在特定领域的"智商"。如果你的模型在"创意写作"考卷得 90 分，但在"研究生级科学研究"考卷只得 40 分，你就知道产品该往哪个方向调整了。
第三步：爬山算法与微调（Hill Climbing）
有了考卷，接下来就是疯狂的刷题。
OpenAI 的团队开始对模型进行针对性的微调（Fine-tuning）。他们不断地跑 Evals，看着分数一点点上涨。
- 版本 V1：逻辑通顺，但引用全是编的。
- 版本 V2：引用真实，但废话太多。
- 版本 V3：结构完美，但缺乏深度洞察。
这就像爬山一样，每一个版本的迭代，都是基于 Evals 分数的反馈。Kevin 透露，这个过程不是静态的，由于模型是不确定的，他们必须进行成千上万次的自动化测试，确保模型在 95% 的情况下都能表现稳定，而不是偶尔蒙对一次。
第四步：设计"思维链"的用户体验（UX of Reasoning）
当后台技术跑通后，前端体验遇到了新问题。
"Deep Research" 需要思考 25 分钟。在互联网时代，让用户等 25 分钟等于自杀。用户会以为网页卡死了，然后直接关掉。
Kevin 的团队发现了一个有趣的心理学现象：人类是可以接受等待的，只要他们知道你在干什么。
于是，他们设计了显性化的"思维链"（Chain of Thought）。界面上不再是一个转圈的 Loading 图标，而是实时显示模型在干什么：
- "正在阅读 PDF..."
- "发现数据冲突，正在重新搜索..."
- "正在规划报告大纲..."
这不仅仅是进度条，这是 AI 在"大声思考"。Kevin 惊讶地发现，用户甚至很享受看着 AI 思考的过程。这种透明度建立了一种前所未有的信任感——你不是在等一个黑盒子出结果，你是在看一个数字员工在为你卖命工作。
理论升华
这套方法论背后，其实印证了艾森豪威尔的那句名言："计划是无用的，但规划是必不可少的。"（Plans are useless, but planning is indispensable.）
在 OpenAI，他们制定年度战略，但绝不相信写在纸上的季度路线图。因为技术迭代太快了（每两个月一次质变）。
Kevin 提出的核心理念是 "迭代部署"（Iterative Deployment）。既然模型是不完美的，既然世界是不确定的，那就不要试图在实验室里造出完美产品。把一个半成品（比如早期的 GPT-3）扔给用户，和全世界一起"共同进化"。
你今天看到的 ChatGPT，不是设计出来的，而是通过数亿用户的反馈"生长"出来的。
局限性提醒
虽然"Evals + 微调"的方法论很强大，但 Kevin 也泼了一盆冷水：这并不适用于所有场景。
- 容错率极低的领域：如果你的产品是银行转账系统，需要 100.000% 的准确率，目前的 LLM 仍然不适合直接接管核心逻辑。你不能接受 AI "偶尔"把钱转错账户。
- 缺乏私有数据的领域：基础模型（如 GPT-4）拥有世界通用的知识，但它不懂你公司的"黑话"和内部流程。如果你没有高质量的私有数据来构建 Evals，模型永远无法成为你公司的专家。
- 套壳创业的陷阱：如果你的产品只是薄薄地包了一层 OpenAI 的 API，而没有构建自己独特的 Evals 和数据闭环，那么下一次模型更新（比如 GPT-5 发布），你的公司就会瞬间失去价值。
金句收尾
Kevin 在访谈最后说了一句极具煽动性的话： "如果你正在构建的产品，刚好处于目前模型能力的边缘，甚至稍微超出一点点，那么请坚持下去，因为你正在做正确的事。"
别因为现在的模型做不到而放弃。再过两个月，新模型发布，那些曾经把你卡住的技术瓶颈，会瞬间变成你的通天大道。
现在，去写你的第一份 Evals 考卷吧。