AI 时代 PRD 失效：评估集正在取代需求文档
Lisa Murkin（数字产品咨询公司 Elsewhen 的资深产品经理）在 Mind the Product 撰文指出一个正在发生的变化：规格说明正从散文式文档转向可执行制品。PRD 作为一份又长又静态的文档，已经不再承担规格说明的核心工作——因为这项工作现在必须存在于"可以被运行"的地方。而那个地方一直就在眼前：一个黄金评估数据集（golden dataset）。
她写道，开始构建 AI 产品几个月后，通常的 PM 工具包就跟不上了：三四个专职工程师在构建，产品团队产出的 PRD、调研、文档速度远低于他们交付的速度。新功能每天都在到来，每一个放在一年前都要花几周甚至几个月。演示看起来总是不错——因为你可以挑选输入；而"产品是否真的在变好"这个问题，却越来越难以有把握地回答。
为什么 PRD 失灵了
三个因素同时打破了 PRD 对 AI 工作的契约：
- 工程已经比产品更快。一个熟练的工程师用现代工具一个下午就能交付一个一年前需要两个迭代周期的 AI 功能。发现、PRD、范围、迭代、评审的传统节奏比构建周期还慢。等 PRD 写完，三个版本已经被原型过了。
- PRD 从来就是用错误的语言写给 AI 工作的。功能需求描述"意图"：功能是做什么的、给谁用。对确定性软件这足够，工程闭环弥补意图与行为之间的差距，QA 捕获偏差。但对 AI 系统，同一个意图可以被数千种输出分布满足，其中大多数不是你想要的。
- 早期 AI 产品没有稳定目标。产品形态被与利益相关者和用户不断变化的对话持续塑造，而 PRD 假设有一个固定的、可被规格化描述的东西。书面规格的衰减速度比 AI 产品演化还快。
黄金数据集到底是什么
黄金数据集是一组经过整理的真实输入 + 好的输出示例（或当输出难以界定时的"可接受输出"判定标准）。系统每次做出有意义的变更时，都要拿它跑一遍。作者项目里一位工程师把数据集建成图片集合：品牌合规的创意示例 + 明显不合规的示例，任何对模型、提示词或工作流的改动都能用同一套参考集来测试。这种整理本身也是产品工作：决定什么该进入、什么是好的输出、边界案例在哪里——"什么是好的样子"的答案就活在这个数据集里，而不是在描述数据集的文档里。
Eric Schmidt 的话很尖锐："10 倍优势不再是执行，而是定义什么算成功。程序员写好规格和评估函数，晚上 7 点跑起来，第二天醒来发现一夜之间被发明出来的东西。"对 PM 来说，这段话的不适之处在于：精确定义问题本来就是 PM 的工作——过去我们靠工程补上差距，现在工程不再帮我们补了。
黄金数据集能做三件 PRD 做不到的事：把"好"编码成系统会被自动测试的形式（文档描述意图，数据集就是规格）；它被运行而不是被阅读（每个新功能、每次迭代、每个提示词改动都会拿它跑一遍）；它随产品一起进化而不是反向衰减（新的生产边界案例进入、过时示例退出）。
作者提醒：数据集最好不由产品独占。工程以他们觉得最有用的方式搭建，产品负责整理标准与边界案例——被产品把关的数据集会重新制造 PRD 曾经的问题。
会在哪里出错
"PRD 很糟，黄金数据集解决一切"是不诚实的。三个值得点名的失败模式：
- 对数据集过拟合：只为通过固定示例而调优的系统无法泛化。对策是持续用真实使用中的新鲜示例替换过时示例，静态数据集腐烂得很快。
- 小样本带来的虚假信心：30 个示例足以抓住明显的回归，却不足以证明系统可用。早期数据集应视为方向性参考，而非定论。
- 与现实使用脱节：数据集反映你以为用户会做的事，生产反映他们实际做的事，差距快速拉大。定期把生产样本拉入数据集，是唯一能弥合差距的方法。
难点在哪
你必须把"什么是好的"具体到能放进电子表格的程度——这比大多数 PRD 逼出来的定义要锋利得多。你必须把评估分数与商业结果挂钩（任务完成率、支持负荷或收入），否则你只是在优化一个只对自己说话的指标。你还必须接受数据集是一个需要持续照料的活制品，而不是一份写完就忘的文档。
PRD 仍有价值
团队对"聚焦与方向"的诉求是正确的，PRD 不是错的直觉，只是错误的形式。一份 20 页没人读的 PRD 比没有文档更糟；一份整个团队一分钟就能对齐的简短、可视化优先的概览才值得一读。"为什么"与"为谁"用散文和图片，"做什么"用数据集。
作者建议周一就这么开始：选一个你负责的 AI 功能，用一句话写出好的输出长什么样；找 10 个真实输入，为每个写出可接受输出的标准；用当前系统跑一遍，给输出打分；与工程师讨论他们想如何扩展和维护。第一次在变更上线前用数据集跑它——那一刻，关于"什么是好的样子"的权力会回到一个共同、可衡量、鲜活的规格手里。
16IDC 观察
对正在做 AI 建站或 AI 产品的团队，这篇文章的核心启示是：需求分析的对象正在从"文档"变成"可运行的评估"。做任何 AI 功能前，先定义清楚"什么是好的输出"，并把它整理成一份能反复跑的数据集，比写一份静态 PRD 更能驱动工程。需要系统化方法论，可参考本站 需求分析分类中的 技术选型评估 与 AI 提示工程入门。