ARTICLE · 1081148
怎样做好 AI 产品的PM
怎样做好 AI 产品的PMAI PM 和 传统PM 的区别不在于懂不懂模型，而在于交付物从确定性的变成概率性的——这一件事重写了需求、验收、体验和运营的全部做法。 市面上大多数「AI PM 能力模型」把重点放在「懂模型原理、懂 RAG、懂微调」。这些有用，但不是分界线——因为它们会被工具链和模型能力快速消化掉。 真正的分界线只有一条：交付物从确定性变成了概率性。 4、5是区分新手和熟手的地方。传统软件的 bug 会报错，AI 的失败是静默的——它给你一个读起来很通顺、实际上错了的答案，而你的监控看不到任何异常。 这条分界线往下推到底，会得出一个很具体的结论：AIPM最重要的产出不是 MRD，是一套能判定好坏的尺子。下文大部分内容都是围绕这把尺子展开的。 AI 产品所有特殊的做法，都能从两个事实推出来： 事实 A：输出是概率的。同样的输入不保证同样的输出；对错不是二元的，是一个分布。 事实 B：能力边界在移动。你所依赖的那个核心组件，每几个月换一次上限和性格。 传统产品方法论默认的恰恰是反面：输出确定、能力固定。所以要换的不是技巧，是下面四条前提。 因为输出是分布，个案和直觉必然骗人。三个好例子不能说明它可用，一个坏例子也不能说明它不可用。你能依靠的只有一组有代表性的样本上的统计表现。 它反对什么：先把功能做出来，上线后再想怎么衡量。这条路走不通不是因为懒，而是一旦有了真实用户，你就失去了干净的基线，以后永远说不清是改好了还是改坏了。 具体做法：任何 AI 功能启动前，先能回答「拿什么判断它做对了」。这个答案必须是一组具体样本加一个判定方式，不能是形容词。 自检：现在把核心模型换掉，你多久能知道产品是变好了还是变坏了？超过一天，说明尺子不存在。 传统软件的失败会报错——它是响亮的、可复现的。AI 的失败是静默的：它给你一个读起来很通顺、实际上错了的答案，而你的监控面板一切正常。 所以「把准确率做高」不是唯一解，甚至常常不是最优解。 它反对什么：把资源全压在提升正确率上，而不投入在「错了之后会怎样」。 具体做法： 按错误成本给场景分级，成本决定交互形态 撤销、diff、可追溯优先于准确率——降低错误的成本，通常比降低错误率便宜一个量级 主动设计发现机制：人工介入率、改写率、放弃点，这些不需要标注就能实时反映不满意 自检：你的产品出错时，用户需要几步才能恢复？你多久能知道它出过错？ 你今天为绕开模型短处而建的东西，明天可能既多余又碍事。它不只是浪费了，还挡住了模型本可以做得更好的部分——而你不会发现，因为你从来没有不带它测过。 它反对什么：把针对当前能力缺口的补丁，当成长期架构来建设和维护。 判断方法：每加一层东西，问「如果这个核心组件明天强一倍，它还需要吗」。不需要则为补丁，需要但要重调则为适配，会更有用则为资产。具体的取舍框架见第四节。 自检：过去半年你删掉了多少东西？一个只增不减的 AI 系统，一定在积累负债。 自然语言入口意味着输入空间是开放的，你无法穷举用户会怎么用；输出是概率的又意味着你无法从规格推演出实际表现。两头都堵死了「想清楚再做」这条路。 它反对什么：靠访谈、脑暴和竞品分析来定义 AI 产品的需求和质量标准。这些方法对确定性产品有效，是因为那里「设想」和「实现」之间可推导。 具体做法： 定期亲自读完整的真实交互记录，不是看别人汇总的结论 重点看两类：用户反复改写输入的地方（说明没说清楚），和用户拿产品干你没设计过的事的地方（说明有未满足的强需求） 需求和质量标准都从这里长出来，而不是反过来 自检：你上周亲自读了多少条真实交互记录？ 一条推论：验证比论证便宜 四条原则之外，还有一个成本结构的变化：做出可运行的东西成本大幅下降，而论证它对不对的成本没变。 所以但凡一个分歧能用两小时做三个版本解决，就不要开两轮评审会。这不是「敏捷」的老话——老话里做一版很贵，所以先想清楚是理性的；现在做一版很便宜，继续先想清楚就成了浪费。 四条原则的共同点：传统方法论默认世界是确定的、静止的，AI 产品的世界是概率的、移动的。所有技巧上的差异，都是这两个词的后果。 这是行业共识里最硬的一条：在AI产品里，评测集是PM的核心产出，地位相当于传统产品里的需求文档。 它同时扮演四个角色：验收标准、回归测试、模型自我验证的依据、以及换代模型时做消融实验的尺子。没有它，上面四条原则一条都落不了地。 先做错误分析，再做指标 这是最容易做反的一步。很多团队上来就选指标、上平台，结果测了一堆和产品成败无关的东西。 正确顺序是反过来的： 看真实输出。至少 100 条真实 trace，其中 30 条你亲自逐条看。 开放编码。边看边随手写下「这条哪里不对」，不预设分类。 归类。把笔记聚成失败模式分类（比如：编造数字、忽略约束条件、格式不稳定、过度道歉）。 按失败模式建judge模型。尽早的使用模型做判断。 验证judge模型。拿人工标注对照，同时看漏报和误报。 定期重做错误分析，因为失败形态会随模型和用户变化。 行业里有个经验值：开发时间的 60–80% 花在错误分析和评测上是正常的。这不是浪费，这就是开发。 PM 具体要交付什么 5–8 个参考输出（理想态）：具体的好例子和坏例子，比任何形容词都有用 质量 rubric：什么维度、怎么打分、什么是一票否决 数据集策略：覆盖哪些真实场景、哪些已确认的失败案例 失败分类法：这是错误分析的沉淀，也是团队的共同语言 有一句话值得记：trace取代了点击事件，成为产品数据的原子单位。以前看漏斗，现在看任务成功率——任务是否正确、高效、安全地完成了。 传统体验设计假设功能会做对，设计的是成功路径。AI 产品要反过来：假设它会做错，设计的是错之后的那一段。 落到实处，只需要回答一个问题：这件事做错了，代价多大？代价决定交互形态。
信任是慢变量，但崩得很快 用户对 AI 的信任需要几十次正反馈累积，但一次离谱的错误就能清零。所以： 宁可少做，不要在不确定时硬编 “我不知道”是个好输出，要在 eval 里给它正分 基础： 核心：定义质量标准，写 rubric 和验收集（验证方式：交给别人能不能独立判断对错） 领域：供给领域事实和数据陷阱（验证方式：需求里有几条是外人不可能知道的） 判断：说不，定反目标和停止条件（验证方式：本季度明确拒绝了几个需求） 注意里面没有「懂 Transformer 架构」。不是不重要，而是它不区分好坏——懂原理但不看trace的PM，比不懂原理但每周看 100 条真实输出的 PM 差很多。 我本月亲自读了多少条真实输出？（< 100 是警报） 我们的回归集本月增加了几条真实失败案例？ 我本月删掉了什么？（提示词、规则、功能） 我本月拒绝了什么？ 我们的需求文档里，「怎样算做对」占多少篇幅？ 人工介入率是升是降？
参考来源 Key takeaways from Boris Cherny on building Claude Code — WorkOS Claude Code's creator on the end of the software engineer — Platformer Building Claude Code with Boris Cherny — The Pragmatic Engineer Boris Cherny: “Just Let the Model Cook” — YC Startup Podcast 摘要 We Deleted 80% of Claude Code's System Prompts for Opus 5 AI Evals: Everything You Need to Know — Hamel Husain How AI evals are changing product management — Calibre Labs Evaluation best practices — OpenAI
一、真正的分界线
需求：传统PM会描述行为，AIPM会定义质量也就是什么是好答案； 验收：传统PM看对错，AIPM看通过率和失败形态； 上线：传统PM功能完成即可，AIPM需要持续回归，因为模型会变； 失败：传统PM处理好报错即可，AIPM需要静默的编一个合理的错误答案，或者一套拒答策略； 体验：传统PM避免出错，AIPM要假设出错，设计错误怎么被发现和纠正；
二、四条底层原则
原则一：先有尺子，再有产品（来自 A）
原则二：为失败设计，不为成功设计（来自 A）
原则三：押注模型能力增长，不弥补模型能力缺口（来自 B）
原则四：从行为取证，不从设想推演（来自 A+B）
三、核心资产：评测集
四、AI 产品的体验设计
五、AIPM能力模型与上手路径
四层能力
自己做可点原型（验证 方式：一个下午能不能出三个版本） 读得懂 trace，做得了错误分析（验证方式：能不能从 50 条输出里归纳出失败分类）