AI 功能 PRD 模板：先写清问题和失败边界

从一次翻车说起

上个月，团队做了一个「智能客服摘要」功能。需求文档里写的是「自动生成对话摘要，提升客服效率」。上线第一周，客服主管找我：摘要确实生成了，但有 30% 的摘要把客户的投诉意图写反了——本来是要求退款，摘要写成了「客户对方案满意」。

这不是模型能力不够。是 PRD 里没有写清楚三件事：什么算「意图识别正确」、摘要里哪些字段绝对不能错、出错后谁来兜底。

我后来翻了团队历史上十几份 AI 功能 PRD，发现一个规律：写「生成更优质的内容」的需求几乎都会在后期的评测和验收阶段反复返工。而写清了「输入是什么、输出长什么样、什么情况下必须拒绝、怎么证明质量变好」的需求，开发周期反而更短。

AI 功能的 PRD 和传统功能有一个本质区别：传统功能的行为是确定性的，按钮点了就是点了；AI 功能的输出是概率性的，同样的输入可能给出不同的结果。PRD 如果按传统方式只写「做什么」，不写「做不好怎么办」，工程师和测试就会在灰色地带反复拉扯。

这篇文章把我在实际项目里踩过的坑整理成一份可直接套用的模板，附带案例、代码示例和检查清单。

理论依据：为什么 AI PRD 需要不同的结构

OpenAI 产品负责人 Miqdad Jaffer 在 Product Compass 上分享过一份 AI PRD 模板，核心观点是 AI PRD 需要同时覆盖三个维度：战略上下文（为什么做）、产品与技术卓越性（怎么做，包括 AI 特有的不确定性处理）、上市策略（怎么验证）¹。

这个框架和传统 PRD 最大的区别在于「非功能需求」部分被大幅强化了。传统 PRD 的非功能需求通常是「响应时间 < 200ms」「可用性 99.9%」这类确定性指标。AI PRD 需要额外定义：

• 准确率基线：在标注测试集上的最低准确率要求
• 幻觉率上限：模型编造事实的比例不能超过多少
• 安全护栏精度：不当内容拦截的精确率和召回率
• 漂移监控：模型上线后持续监测输出质量是否退化

国家标准 GB/T 45288.2-2025《人工智能大模型 第2部分：评测指标与方法》也明确提出了覆盖性能、安全、伦理等核心维度的评测体系²。这说明「写清边界」不是工程偏好，而是合规要求。

另一个值得参考的概念是 LLM 失败模式分类法（Failure Mode Taxonomy）。把 AI 可能的错误事先分类——事实错误、格式违规、指令遗漏、安全越界——然后在 PRD 里逐一写清每种失败的容忍度和处理方式³。这比笼统写一句「保证输出质量」有效得多。

模板结构总览

把上面的理论落地，一份 AI 功能 PRD 至少包含以下模块：

案例一：智能客服摘要——意图反转

场景

客服系统将每通对话自动生成摘要，供后续客服快速了解上下文。

翻车

PRD 原文：

// ❌ 坏的 PRD 写法
功能：自动生成对话摘要
目标：提升客服效率
验收标准：摘要能准确反映对话内容

「准确反映」没有定义。开发按通用摘要模型来做，结果模型在摘要时把客户的否定语气理解成了肯定。客户说「我不要这个方案」，摘要写成「客户接受方案」。

修复

重写 PRD，增加三个关键约束：

// ✅ 好的 PRD 写法
功能：自动生成对话摘要

输入规格：
- 来源：客服会话记录（文本，含时间戳和角色标记）
- 长度：500-5000 字
- 异常输入：纯图片会话不走摘要，返回空状态

输出规格：
- 格式：JSON，包含 summary / intent / action_items 三个字段
- intent 必须是枚举值：[退款, 咨询, 投诉, 建议, 其他]
- 如果无法确定 intent，输出 "其他" 并附带 uncertainty_reason

模型边界：
- 禁止推断客户未明确表达的情绪
- 禁止将否定表述转为肯定表述
- 客户原话中的关键诉求必须原文引用，不可改写

失败处理：
- 如果模型置信度 < 0.7，标记为「待人工复核」
- 如果对话包含敏感词（投诉/赔偿/法律），强制走人工摘要

对比

案例二：电商商品描述生成——SEO 翻车

场景

为电商商家提供 AI 商品描述生成，输入商品标题和属性，输出一段 100-300 字的描述文案。

翻车

第一版上线后，商家反馈两个问题：

1. 生成的描述里出现了竞品的品牌名。模型在训练数据里见过大量商品描述，生成时把其他品牌的信息混了进来。
2. 描述里的参数和商品实际参数不一致。标题写「续航 8 小时」，描述里变成「续航 10 小时」。

根源是 PRD 只写了「生成高质量商品描述」，没有约束「哪些信息必须从输入中提取、不可编造」。

修复

// ✅ 好的 PRD 写法
功能：AI 商品描述生成

输入规格：
- 商品标题（必填）
- 商品属性表（必填，JSON 格式，包含品牌、价格、规格等）
- 商家自定义关键词（选填，最多 5 个）

输出规格：
- 字数：100-300 字
- 必须包含的属性：品牌名、核心卖点、适用场景
- 禁止出现：竞品品牌名、未在购买属性中的参数、价格承诺

模型边界（关键）：
- 所有数值型参数（续航、重量、尺寸）必须从输入属性中原样引用
- 禁止添加输入中不存在的功能特性
- 禁止出现「最好」「第一」「绝对」等绝对化用语

输出校验（后处理）：
- 提取输出文案中的所有数值，与输入属性交叉验证
- 提取输出中的品牌名，与输入品牌 + 竞品黑名单比对
- 任一校验不通过，返回「生成失败，请修改输入后重试」

后处理校验的代码示例：

# ✅ 好的做法：输出后处理校验
def validate_description(input_attrs: dict, output_text: str) -> tuple[bool, str]:
    """校验 AI 生成的商品描述是否与输入属性一致"""
    
    # 检查 1：数值参数一致性
    for key in ["续航", "重量", "尺寸", "容量"]:
        if key in input_attrs:
            expected = input_attrs[key]
            # 如果输入中有该参数但输出中出现了不同数值
            if key in output_text and expected not in output_text:
                return False, f"参数 {key} 不一致：输入为 {expected}，输出中未找到匹配值"
    
    # 检查 2：竞品品牌名黑名单
    competitor_brands = get_competitor_list(input_attrs["brand"])
    for brand in competitor_brands:
        if brand in output_text:
            return False, f"输出中包含竞品品牌名：{brand}"
    
    # 检查 3：绝对化用语
    forbidden_words = ["最好", "第一", "绝对", "顶级", "无敌"]
    for word in forbidden_words:
        if word in output_text:
            return False, f"输出中包含绝对化用语：{word}"
    
    return True, "校验通过"
 
 
# ❌ 坏的做法：不做后处理，直接返回模型输出
async def generate_description(title: str, attrs: dict) -> str:
    prompt = f"请为以下商品生成描述：{title}，属性：{attrs}"
    # 直接返回，没有任何校验
    return await llm.generate(prompt)

对比

案例三：内部知识库问答——权限越界

场景

企业内部知识库接入 AI 问答，员工可以用自然语言查询公司制度、技术文档、项目资料。

翻车

安全审计发现，普通员工通过 AI 问答查到了高管薪酬方案和未公开的组织架构调整。模型没有权限意识——它对所有输入都一视同仁地回答。

PRD 里只写了「基于知识库内容回答问题」，没有提到文档权限。

修复

// ✅ 好的 PRD 写法
功能：知识库 AI 问答

输入规格：
- 用户查询文本
- 用户身份标识（从登录态获取，不可由前端传入）
- 查询上下文（最近 3 轮对话）

权限模型（关键）：
- 文档级权限：每篇文档绑定可见角色列表
- 检索阶段过滤：向量检索前，先按用户角色过滤可访问文档集合
- 生成阶段约束：Prompt 中注入「仅基于以下已授权文档回答」
- 禁止跨权限推理：即使用户问题暗示了高权限信息，也不得推断回答

输出规格：
- 如果问题涉及的文档用户无权访问，返回「该信息暂无权限查看，请联系管理员」
- 禁止在回答中暗示「存在相关文档但您无权查看」
- 每条回答附带引用来源（文档标题 + 段落）

失败处理：
- 检索结果为空：返回「未找到相关信息」，不编造
- 模型拒绝回答（触发了安全约束）：记录日志，返回「暂时无法回答该问题」

权限过滤的代码示例：

# ✅ 好的做法：检索前按权限过滤文档
async def answer_question(query: str, user: User) -> str:
    # 1. 获取用户可访问的文档 ID 列表
    allowed_doc_ids = await get_allowed_documents(
        user_id=user.id,
        user_roles=user.roles
    )
    
    # 2. 在已授权文档范围内做向量检索
    retrieved_chunks = await vector_search(
        query=query,
        filter={"doc_id": {"$in": allowed_doc_ids}},
        top_k=5
    )
    
    # 3. 无结果时不编造
    if not retrieved_chunks:
        return "未找到相关信息，建议换个关键词试试，或联系管理员确认权限。"
    
    # 4. 构建 Prompt，明确约束来源范围
    context = "\n".join([chunk.text for chunk in retrieved_chunks])
    prompt = f"""基于以下已授权文档回答用户问题。
如果文档中没有相关信息，回复「未找到相关信息」。
禁止利用已有信息推断文档中未提及的内容。
 
文档内容：
{context}
 
用户问题：{query}"""
    
    # 5. 生成回答并附带引用来源
    answer = await llm.generate(prompt)
    sources = [{"title": c.metadata["title"], "section": c.metadata["section"]} 
               for c in retrieved_chunks]
    
    return format_answer_with_sources(answer, sources)
 
 
# ❌ 坏的做法：不做权限过滤，全库检索
async def answer_question_bad(query: str) -> str:
    # 全库检索，没有权限过滤
    chunks = await vector_search(query=query, top_k=5)
    prompt = f"基于以下文档回答问题：{chunks}\n问题：{query}"
    return await llm.generate(prompt)

对比

决策流程：从需求到上线的完整路径

AI PRD 与传统 PRD 的关键差异

评测标准与指标设计

评测是 AI PRD 中最容易被忽视、也最影响交付效率的部分。很多人的习惯是先上线再补评测，结果工程团队在「到底算不算 bug」的争论上消耗大量时间。

建议在 PRD 中明确三层评测：

第一层：离线评测（上线前）

准备一组标注数据（建议至少 200 条，覆盖正常输入、边界输入、恶意输入），用自动化指标衡量：

第二层：在线评测（灰度阶段）

灰度发布时，对比实验组和对照组的核心业务指标：

• 客服场景：首次解决率、客户满意度、平均处理时长
• 内容生成场景：人工编辑率、从生成到发布的平均耗时
• 问答场景：回答有用率（用户点赞/点踩）、转人工率

第三层：持续监控（全量上线后）

# ✅ 好的做法：持续监控关键指标
class AIMonitoringConfig:
    """AI 功能持续监控配置，PRD 中应明确这些参数"""
    
    # 质量指标 - 每日抽样人工评审
    quality_sample_size: int = 100        # 每日抽样数量
    quality_target_score: float = 0.85    # 最低质量分
    quality_alert_threshold: float = 0.80 # 低于此值触发告警
    
    # 漂移检测 - 对比输入/输出分布
    drift_check_interval: str = "daily"
    drift_threshold: float = 0.15         # 分布偏移超过 15% 触发告警
    
    # 用户反馈
    negative_feedback_rate_alert: float = 0.05  # 负面反馈率 > 5% 告警
    
    # 回滚条件（PRD 中必须写明）
    auto_rollback_conditions: list = [
        "quality_score < 0.75 持续 2 小时",
        "negative_feedback_rate > 0.10 持续 1 小时",
        "hallucination_rate > 0.05 单次检测",
    ]
 
 
# ❌ 坏的做法：上线后没有监控配置
# 出了问题才发现没有数据，不知道什么时候开始的，也不知道影响了多少用户

模板详解：每个字段怎么写

1. 用户问题

不要写「提升效率」，要写清楚：

• 用户现在怎么做的？（手动写摘要、手动查文档）
• 现在的方式有什么问题？（耗时 30 分钟、容易遗漏关键信息）
• 这个问题发生的频率？（每天每个客服 15-20 次）
• 解决后的预期收益？（摘要时间从 5 分钟降到 30 秒）

2. 典型场景与非目标

场景要写「具体到能构造测试用例」的程度。非目标更要写清楚——AI 功能的范围蔓延是最常见的翻车原因。

// ✅ 好的非目标写法
非目标（本期不做）：
- 不生成多语言版本（只做中文）
- 不处理图片和视频内容
- 不替代人工审核高风险内容
- 不做实时流式输出（批量离线生成）

3. 输入来源与可信度

不同来源的输入，模型应该给予不同的信任权重：

4. 模型不可做的事情

这一条经常被跳过，但它可能是 AI PRD 中最重要的部分。明确写出模型不该做什么，可以防止后期需求膨胀和安全事故：

• 不可做最终决策（只能给建议，人工确认）
• 不可跨用户共享信息（A 用户的数据不能出现在 B 用户的回答中）
• 不可执行不可逆操作（不能直接删除数据、发送通知、转账）
• 不可暴露系统 Prompt 或内部逻辑

5. 失败状态与转人工策略

每种失败模式都应该有对应的处理方案：

PRD 完成度检查清单

PRD 写完后，用以下清单自查。所有项目必须能明确回答，否则模板还没填完整。

需求定义阶段

• 用户问题能用一句话描述清楚，且包含具体痛点和频率
• 目标用户有明确的画像，不是「所有用户」
• 至少列出 3 个典型场景，每个场景能构造测试用例
• 非目标至少列出 3 条，明确本期不做什么

输入输出定义阶段

• 输入来源、格式、必填/选填、异常输入处理方式已定义
• 输出格式有明确的 schema（JSON schema 或结构化模板）
• 输出质量标准有量化指标（不是「高质量」，是「准确率 ≥ 90%」）
• 模型不可做的事情至少列出 4 条

安全与失败处理阶段

• 高风险场景（医疗/金融/法律/权限）有人工确认环节
• 每种失败模式有对应的用户提示和降级策略
• 转人工的触发条件有明确的阈值（不是「必要时」）
• 敏感内容有拦截机制和误拦率容忍度

评测与上线阶段

• 离线评测数据集至少 200 条，覆盖正常/边界/恶意输入
• 上线指标包含模型特有指标（准确率、幻觉率、延迟）
• 回滚条件有明确阈值，不依赖人工判断
• 持续监控方案已定义（抽样评审频率、漂移检测周期）

四个核心问题

PRD 完成后，团队里任何人应该能回答这四个问题。答不清，说明模板还没有填完整：

1. 什么输入算成功？ —— 正常输入的边界在哪里，哪些情况模型应该拒绝处理
2. 什么输出必须拒绝？ —— 哪些输出即使「看起来对」也不能展示给用户
3. 如何证明质量变好？ —— 上线前用什么评测集、什么指标，上线后看什么数据
4. 上线后看哪些指标？ —— 日常监控什么、告警阈值是多少、什么条件触发回滚

常见误区

参考资料