写了好几年 PRD，最近突然有点迷——以前那套写法，放到 AI 类产品上感觉哪里不对劲，但又说不清楚问题在哪。
后来慢慢想明白了：传统 PRD 是在对一个确定性系统下指令，AI/Agent 类产品是在给一个概率性系统划边界。这是两件完全不同的事。
传统 PRD 在 AI 产品上会出什么问题
传统 PRD 的核心逻辑是"描述清楚功能长什么样"。用户点击这个按钮，会发生这件事，状态从 A 变成 B，完成。
但 AI 产品没有这种确定性。你无法说"用户提交研报，AI 输出正确摘要"——因为"正确"是个概率，不是开关。你也没法只写"生成摘要功能"，因为你还需要说清楚：生成的摘要里出现了捏造的数字怎么办？解析失败了跳到哪里？用户不满意能改吗？
这些问题，传统 PRD 的格式里没有对应的位置。
AI 类 PRD 多出来的四个核心模块
我总结下来，AI/Agent 类产品的 PRD 比传统 PRD 至少多四块内容：
① Agent 的角色定义：这个 Agent 在整个流程里干什么、不干什么。边界要写清楚，"不干什么"往往比"干什么"更重要。
② 人机分工与介入点：哪些步骤 Agent 自主跑，哪些需要用户确认，出错了人从哪里接管。这个用流程图表达最直观。
③ 多维验收标准：不能只写"功能上线"，要写模型性能指标（准确率、幻觉率、延迟）、业务指标（完成率、留存）、体验指标（用户修正率、重试率）。
④ 容错与降级策略：AI 必然会犯错，这不是 bug 而是系统特性。PRD 里要提前说好：什么情况触发降级、降级到哪一层（AI → 规则 → 人工）、用户侧怎么感知。
其他的，比如数据来源、合规要求、成本红线，也比传统产品更需要明确写出来。
一个真实的模版：研报智能摘要 Agent
光说原则没用，直接看一份具体的怎么写。
场景背景：投研用户每天要读 20-50 份研报，想做一个 Agent 帮他们自动提炼关键结论。
1. 背景与目标
投研用户信息处理压力大，每份研报平均花 15 分钟，每天要消耗 3-8 小时在阅读上。
目标：通过 Agent 把单篇研报的处理时间压缩到 3 分钟以内，不损失关键信息（核心结论、目标价、评级变化、主要风险）。
成功标准：目标用户中 40% 次日留存；用户主动修正摘要的比例低于 15%。
2. 用户与场景
主要用户：买方投研（基金经理/研究员），日均阅读量 20 份以上。
核心场景：上传 PDF → 获取结构化摘要 → 决定是否精读原文。
本期不做：跨研报比较、历史评级追踪、主动推送。
3. Agent 角色定义
| Agent 负责 | Agent 不负责 |
|---|---|
| 提取：核心结论、目标价/评级、风险提示 | 判断研报结论是否正确 |
| 输出固定格式的结构化摘要 | 跨文档关联分析 |
| 标注不确定内容 | 给出投资建议 |
4. 人机分工流程
用户上传 PDF
↓
[Agent] 解析文档结构，识别研报类型
↓
[Agent] 提取关键字段，生成结构化摘要（自动执行，无需用户确认）
↓
[置信度判断]
├── 正常：直接展示摘要
├── 低置信：展示摘要 + 标注"⚠️ 以下内容不确定，建议核对原文"
└── 无法解析：提示"该文档格式暂不支持，请上传文字版 PDF"
↓
用户查看摘要 → 可点击"查看原文对应段落"（溯源验证）5. 输出格式规范（也是 Prompt 的核心约束）
摘要必须包含以下字段，缺失项标注"未提及"：
- 公司/标的
- 评级（维持/上调/下调/首次覆盖）
- 目标价（若有区间，取中值）
- 核心逻辑（3 条以内，每条不超过 30 字）
- 主要风险（2 条以内）
- 数据截止时间
禁止：补充原文未提及的信息、生成带有投资建议性质的语言。
6. 验收标准
| 维度 | 指标 | 达标线 |
|---|---|---|
| 模型性能 | 关键字段提取准确率 | ≥ 90%（人工抽样 50 份验证） |
| 模型性能 | 幻觉率（编造数字/结论） | ≤ 2% |
| 体验 | 平均处理时长 | ≤ 30 秒/篇 |
| 体验 | 用户修正率 | ≤ 15% |
| 业务 | 次日留存 | 目标用户 ≥ 40% |
7. 容错与降级策略
| 失败情形 | 处理方式 |
|---|---|
| 扫描版 PDF（无文字层） | 提示不支持，引导上传文字版；后续 roadmap 加 OCR |
| 关键字段置信度低 | 输出摘要 + ⚠️ 标注，不隐藏结果 |
| 模型响应超时（>60s） | 允许用户离开后通知；超时失败则提示重试 |
| 非研报文档 | 提示"当前文档可能不是研报，摘要效果可能不准确" |
8. 数据与合规
- 研报内容处理完即丢弃，不持久化存储（版权合规）。
- 不将用户上传内容用于模型训练。
- 摘要结果界面注明"AI 生成，以原文为准"。
9. 上线后的监控计划
- 每周抽样 30 份，人工验证准确率。
- 监控用户的"修正"行为——哪些字段被改得最多 = 模型的弱点，优先迭代。
- 收集点踩 + 原因标签，反哺 Prompt 优化。
写这份 PRD 的核心逻辑
你会发现这份 PRD 里没有出现"用 GPT-4o"、"chunk size 512"、"用 LangGraph 框架"这类字眼——那些是技术的事。但"幻觉率 ≤ 2%"和"禁止补充原文未提及的信息"，本质上也是在约束技术实现，只是用的是产品语言。
产品写目标、边界、标准、容错规则。技术写实现细节。分工清楚，PRD 就不会变成伪技术方案，也不会变成空洞的功能描述。
这个分寸感，是 AI 时代写 PRD 最难拿捏的地方，也是最值钱的地方。
「AI 时代产品经理转型」系列第二篇。下一篇聊技术安全感的问题——为什么学了 LangGraph 之后还是觉得懵？