过去我们写PRD、画原型、做用户访谈，然后交给开发团队实现。
但在AI类产品设计规划工作中，这套流程失效了。
AI模型的行为是概率性的，同一个输入可能产生完全不同的输出。
你没法像测试传统软件那样写一个“预期结果等于X”的测试用例。
你面对的是一个“黑盒”，它的边界模糊、行为动态变化。
这不是渐进式的变化，而是范式级的迁移。
今天分享最近看的一段内容：https://www.youtube.com/watch?v=tivaWTTVRhY先说说大多数AI产品团队正在经历的困境。
你有没有见过这样的场景：工程师或产品经理灵光一闪，写下了一段精妙的提示词，在内部工具里测试了几个典型案例，结果令人振奋，模型对答如流。团队成员互相传递截图，一片赞叹声中达成共识：“感觉不错，可以上线了。”
然后呢？上线即事故。
用户的真实世界远比我们想象的复杂。
方言、拼写错误、矛盾指令、中途变卦，这些在“感觉不错”阶段从未出现过的输入，瞬间让AI产品原形毕露。
幻觉开始频现，逻辑错误层出不穷，而且这些错误往往是“幽灵Bug”，难以复现、难以定位。
更糟的是“跷跷板效应”：你修复了一个场景的错误，导致另外三个原本正常的场景开始出错。
团队陷入“打地鼠”式的无限修补，每一次提示词的修改都像一次赌博。
这个状态叫作 “抽卡式开发” ，你永远不知道下一次投喂会抽出什么质量的响应。
根本原因在于：传统软件开发追求确定性，而AI系统管理的是概率分布。
传统的测试用例是Pass/Fail的二元判断，但AI的输出没法这样简单二分。你需要一套全新的方法来衡量“好”与“不好”。
这就是评测驱动开发（Evaluation-Driven Development, EDD）的由来。
简单来说，EDD是一种以持续评测为核心驱动力，通过系统性验证和优化AI系统能力与行为逻辑的方法论。
它不是开发完成后的“产物检验”，而是贯穿始终的“能力认证”。
用人话说就是：在写任何代码、调任何提示词之前，先想清楚“怎样才算好”，然后把这个标准写成可执行的评测。
什么意思？传统PRD的作用是描述产品愿景、对齐利益相关方。
但在AI类产品里，驱动用户价值的方式变了，产品经理需要识别用户痛点、理解失败模式、将其转化为可复现的评测集，再把结果反馈给研究团队进行针对性改进。
这不是说PRD完全消失了。
当问题定义清晰时，评测可以充当简写；当问题模糊、需要协调产品、工程、安全和法务团队时，PRD仍然是统一方向的重要工具。但核心工作方式已经变了。
这是最容易被低估的一步，也是最关键的一步。
例如用户反馈说“模型不擅长遵循指令”，但是这个反馈内容对开发人员毫无用处。你没法拿着这句话说让开发解决这个问题。
作为产品经理，需要深入挖掘了这个反馈。
具体怎么做的？我们需要逐条查看对话记录，追问用户：“你说的‘不遵循指令’具体是什么意思？发生在什么情境？你提出了什么要求？模型给出了什么回答？”
最后会发现大约80%的所谓“不遵循指令”问题，其实集中在同一个具体问题上：模型无法按指定格式输出JSON。
一旦定位到这个具体的失败模式，事情就变得可操作了。
可以生成了30到40个失败案例，每个案例包含一个提示词、模型的响应，以及与预期正确答案的对比。
这些案例本身就构成了一个评测集。就可以在每次新模型版本发布后，利用这些评测集对模型进行自动化验证，确保每次新模型的能力达到用户的期望值。
这个案例揭示了一个核心原则：产品经理必须把抽象的用户抱怨，拆解到足够具体的颗粒度，才能转化为研究人员可以采取行动的信号。
有了评测集，下一步是让它真正融入开发流程。
在AI产品发布上线前，如果涉及对提示词、模型版本或工具定义的修改，都会在CI/CD流程中自动触发全量评测集的回归测试。
让系统自动生成评测报告，这样团队可以清晰地看到：这次改动在哪些维度上改善了表现，在哪些维度上导致了退化。
这解决了一个根本性问题：把“感觉不错”变成了“数据证明不错”。
评测集也是设定“及格线”的工具。
在产品上线或迭代之前，团队可以明确约定一个基于数据的、可量化的标准，而不是基于某个人“感觉还行”的主观判断。
单一的评测维度远远不够。在实践中，推荐建立三层评估框架：
第一层：离线评估
在模型或应用部署之前，基于静态的、预先标注的数据集进行验证。
这就像传统软件测试中的回归测试，为每个新版本提供一个可重复、可控的“安全网”。
离线评估的价值在于可复现性。产品经理或者测试人员可以在完全相同的条件下反复测试，准确判断每一次改动带来的变化。
第二层：在线评估
在真实运行环境中进行评估，通过A/B测试、灰度发布等方式验证模型在实际场景中的表现。
离线评估无法完全模拟真实世界的复杂性。
用户在实际使用中的行为模式、上下文变化、边缘情况，只有在真实环境中才能被充分暴露。
第三层：用户评估
这是最容易被忽视的一层。技术指标再好看，用户觉得“不好用”就是不好用。
通过分析日志数据中的用户修正行为、重试模式、负面反馈来反哺优化方向。
此外，定期组织红队测试，邀请内部专家或外部用户专门寻找系统的漏洞与缺陷。
这三层不是孤立的，而是一个持续反馈的闭环：离线评估发现问题 → 在线评估验证真实影响 → 用户评估揭示感知差距 → 回到离线评估继续改进。
这场变革对产品经理意味着什么？
这不是可选项。即使是资深产品经理的入职计划也需要和初级员工完全一样：理解用户、阅读经用户同意的反馈、与客户交谈。
一个从未亲手构建过AI产品的人，很难真正判断什么是好的AI产品体验。这就像从没下过厨的人去评判一道菜，纸上谈兵永远代替不了真实的“手感”。
AI产品经理不能只停留在战略层面。你需要阅读对话记录，理解那些失败的交互轨迹。
你需要像打磨每一个像素一样，精打细算地对待每一个token。
这不是说你要成为工程师。而是说，你不了解模型在真实场景中的表现，就无法做出正确的产品决策。
模型能力的提升不是线性的，而是存在“不连续的跃迁”。
一个模型可能已经具备了某项新能力，但团队尚未意识到。
持续评测的意义不仅在于判断模型好坏，也在于识别哪些能力已经出现、哪些产品机会已经成熟。
如果你现在准备开始搭建AI产品的评测体系，梳理了几条建议：
别追求“大而全”。 一个常见错误是上来就把模型的所有能力拉一张大表，正确性、流畅性、安全性、一致性、创造力，恨不得全测一遍。结果资源全铺开了，每个维度都没测透。正确的做法是用“三层过滤”逐层缩小评测范围，最终得到一份有优先级的方案。
从真实失败案例开始。 不要凭空构造评测用例。从生产环境的失败记录中提取案例，那些用户真正遇到的问题，才是最值得评测的场景。
把评测数据当成核心资产。 题库、标注规则、用户反馈全部沉淀下来。半年后你会感谢自己做了这件事。
评测本身也需要迭代。 随着产品演进和模型能力提升，今天的评测标准明天可能就过时了。定期审视和更新评测集，确保它始终反映当前的产品目标和用户需求。
让评测成为团队共同语言。 建立评估结果的可视化仪表盘，让产品、工程、研究团队对产品质量有共同、实时的认知。评测不是产品经理一个人的事，而是整个团队协作的基础设施。
产品经理已经不再只是“写文档的人”或“传话筒”。产品经理应该是把模糊的用户需求转化为可度量标准的人，是在不确定性的海洋中为团队提供导航坐标的人，是在技术能力不断跃迁时判断“什么值得构建”的人。
评测不是终点，而是手段。它的终极目标是让AI产品真正为用户创造价值。而要做到这一点，没有捷径，你必须深入细节、亲手构建、持续迭代，并且始终保有对用户需求的敏锐感知和对技术可能性的好奇。
