传统 PRD 定规则，AI PRD 定期望
传统 PRD 的核心是流程图加条件分支：用户点 A 按钮就跳 B 页面，库存大于 0 就能下单，逻辑是可以穷举的。AI 产品没法这么写——你不可能穷举用户会问什么，也不可能写「当用户问退款政策时返回这段话」，因为用户会有一千种问法。
所以 AI PRD 的主线变了：你定义的不是规则，是期望行为。比如智能客服的 PRD 里，你写的是「能准确回答售后政策类问题，覆盖退货、换货、保修三类；超出范围的问题礼貌拒答并转人工；语气口语化，不堆砌敬语」。行为是描述性的，具体怎么做到交给 prompt 工程和模型。这一转变没想清楚，写出来的 PRD 就是传统模板塞个「接入大模型」章节，开发看完照样不知道要做什么。
评测集就是验收标准
这是最大的实操差异。传统 PRD 验收靠测试用例一条条点，AI 产品验收靠评测集：PRD 里必须附带（或至少约定）几百条代表性问题加标准答案，验收时看模型在评测集上的通过率。我做客服类产品时，PRD 里直接写死「评测集 500 条，准确率不低于 85%，拒答率不超过 10%，其中红线问题（涉敏、涉资金）错误率为 0」——这三个数字就是验收的尺子，地位等同于传统 PRD 里的「接口响应小于 500ms」。
评测集本身也要写进 PRD：怎么采样（真实用户日志脱敏优先，没有就人工构造）、怎么分层（高频问题占多少、长尾占多少、故意刁难的对抗性问题占多少）、谁来标注标准答案。这块写得含糊，验收时一定扯皮——业务说效果不好，算法说按你给的集子测是达标的，最后发现两边说的根本不是一个评测集。
badcase 库和兜底策略是正式章节
传统 PRD 的异常处理通常一页纸带过，AI PRD 里它得是重头。模型一定会答错，PRD 要写清楚整条处置链：错了怎么被用户发现（引用来源、置信度提示）、发现后怎么纠正（重新生成、反馈按钮）、纠正不了怎么兜底（转人工的触发条件和话术）。badcase 库也要跟着 PRD 一起建，每轮迭代把线上踩到的坑归档，成为下个版本的回归测试集。这玩意是资产，越攒越值钱。
和算法团队的分工要写明白
PRD 里最容易扯皮的是边界：PM 定「要什么行为、什么算合格」，算法和工程定「怎么做到」。prompt 初稿谁写、改动谁审批、上线前谁跑评测，写清楚能省掉无数会议。我的习惯是 PM 写行为规范（人格、语气、禁区清单），工程同学翻译成具体 prompt 措辞，评测集双方共建共签。PM 越界去抠 prompt 字眼，或者把「效果达标」整个甩给算法，都是灾难的开端。
上线节奏和指标口径也归 PRD 管
AI 功能很少一把全量。PRD 里要写清灰度策略：先内部员工、再 5% 白名单、再按指标阶梯放量，每档的准入准出标准是什么——比如「灰度期间满意度不低于 4 分、严重 badcase 率不高于 3%，达标开下一档，不达标回滚」。线上指标口径也得在这定死：满意度的分母是全量会话还是有效会话、转人工率是高好还是低好（高可能是模型不行，低可能是入口藏太深），这些口径不提前定，上线后的复盘会一定开成吵架会。