传统PRD描述确定性功能行为，AI产品的核心在于管理不确定性。本文从实际项目出发，聊聊如何将需求表达从"定义功能"转向"描述意图"，用结构化Prompt替代功能清单，用评估指标替代验收标准，并分享实操中的三个常见坑。
为什么传统PRD写不好AI产品
做过AI产品的PM大概都有过这种经历：你花了一周写了一份详尽的功能PRD，每一个交互细节、每一个边界条件都写清楚了。开发拿到手，用大模型跑了一遍，结果输出完全不是你想要的样子。
问题出在哪？传统PRD的核心假设是：功能行为可预测。你写"点击按钮A，弹出弹窗B"，开发就给你实现这个行为，一比一还原。但AI产品的核心特征恰恰相反——输出是概率性的。同一个输入，模型可能给出十种不同的回答，每一种都"没错"，但只有一种是用户真正需要的。
这不是开发能力的问题，而是需求表达方式的问题。你没法在PRD里写"模型应该这么回答"，因为模型的行为不是被代码定义的，而是被Prompt和数据定义的。
这意味着，AI产品经理需要一种新的需求表达方式。
从"定义行为"到"描述意图"
传统PRD的逻辑是：定义每一个功能的行为，然后验收这些行为是否被准确实现。
AI产品的逻辑是：描述你希望系统达到的意图，然后通过Prompt、数据和评估来逼近这个意图。
举个例子，你在做一个AI客服功能。传统写法是：用户输入问题→匹配知识库→返回标准答案。每一步都是确定性的。
AI产品写法是：用户输入问题→系统理解意图→生成符合品牌调性的回复→如果不确定就转人工。每一步都有不确定性，你的PRD需要描述的是"什么样的回复是好的"，而不是"返回哪个字段"。
具体怎么做？我总结了一个三层结构。
AI需求的三层结构
第一层：输入约束。定义系统接收什么输入、如何预处理。比如：用户输入限制在200字以内；过滤敏感词；识别输入语言并做相应路由。
第二层：意图描述。这是最核心的部分。你需要描述系统应该如何理解用户意图、用什么角色和风格来回应。这本质上就是一段结构化的Prompt。比如：你是一个品牌客服助手，语气专业但不生硬，回答基于知识库内容，不编造信息。
第三层：输出规范。定义输出的格式、长度、风格、兜底策略。比如：回复不超过150字；如果置信度低于0.7，引导转人工客服；遇到无法回答的问题，不要硬编，主动告知用户。
▼ 传统PRD vs Prompt驱动需求对比
看这张对比表就清楚了。传统PRD和AI需求文档的差异不是形式上的，而是底层假设不同。传统PRD假设行为可穷举，AI需求承认输出有概率分布，转而用约束和评估来管理这种不确定性。
从验收标准到评估指标
传统PRD的验收标准是二值的：通过或不通过。功能要么实现了，要么没实现。
AI产品做不到这一点。你不能说"这个回复正确"或"这个回复错误"，因为很多回复是部分正确、方向对但细节有偏差。所以AI产品经理需要用评估指标替代验收标准。
▼ AI产品经理工作时间分配
Prompt编写与调优 25%
评估与测试 25%
需求分析 20%
功能设计 15%
数据标注管理 10%
其他 5%
看这个时间分配。传统PM花15%在测试验收上，AI PM要花25%以上在评估上。这不是因为AI PM更闲了，而是评估这件事本身变得更复杂、更重要。
具体怎么评估？三个层次：
第一层：准确率。模型给出的回答在事实层面是否正确。这是基础，但远远不够。
第二层：相关性。回答是否真正解决了用户的问题。一个事实正确但答非所问的回复，用户体验依然很差。
第三层：用户满意度。最终用户的实际感受。可以通过点赞/踩、后续追问率、满意度评分来衡量。
▼ PM核心技能需求变化趋势（2020-2026）
评估不是一次性的，而是持续的。你的Prompt每改一个字，评估结果可能就变了。所以AI PM需要建立一套自动化评估流程，用批量测试替代手动测试，用指标看板替代主观判断。
实操中的三个坑
第一个坑：把Prompt当代码写。有些PM喜欢在Prompt里堆大量约束条件，试图穷举所有情况。结果是Prompt又长又复杂，模型反而理解不了。好的Prompt像好的需求文档一样，简洁、清晰、有重点。
第二个坑：只测Happy Path。传统产品测试有边界值、异常值，AI产品更需要。用户可能输入任何东西，你的Prompt可能在99%的case下表现完美，但在那1%的case下输出灾难性的内容。Edge case测试不是可选的，是必须的。
第三个坑：评估指标和业务目标脱节。模型准确率95%看起来很好，但如果那5%的错误恰好发生在高价值用户身上，业务效果可能很差。评估指标要和业务目标对齐，而不是只看技术指标。
写在最后
不是抛弃PRD，而是进化它。PRD里的用户分析、竞品调研、数据指标定义，这些在AI产品里依然重要。变的是你对"功能"的定义——从一个确定性的行为，变成一个有概率分布的输出。
AI产品经理的新核心技能，不是写Prompt的技术，而是把模糊的用户需求转化为可评估的系统能力的思维。
— END —
