企业官网建设流程全解析

AI 功能的 PRD 怎么写？把“准确提取”改成可检查的需求

做产品经理这几年，我最怕看到的一句话就是“准确提取”。每次评审 AI 相关功能，但凡 PRD 里出现“准确提取用户意图”“准确提取关键信息”这种描述，我基本能预判会议走向：需求方觉得意思很明确，研发一脸茫然，测试无从下手，最后大家和稀泥地定了个“差不多能用”就上线。说到底，问题不在需求本身，而在于我们还在用写传统功能页面的方式，去写一个输出结果带有概率属性的 AI 功能。

这几年我陆续做过信息抽取、智能搜索、文档解析类的功能，把各类需求文档来回改了几十版之后，才慢慢摸清楚一套思路——AI 功能的 PRD，核心不是描述“它应该做什么”，而是定义“它做成什么样算合格”。也就是说，把“准确提取”这种模糊的主观描述，翻译成一套可以直接验证、可以量化、可以争论的指标和样例集。这篇文章就围绕这件事展开，聊聊我怎么把一句“准确提取”改造成真正可检查的需求，里面包含具体的指标拆法、样例集构建方法、PRD 模板片段，以及我在实际项目中踩过的坑。

1. 先搞清楚：AI 功能 PRD 和传统 PRD 的本质差异

很多人写不好 AI 功能 PRD，是因为潜意识里还在用传统软件的逻辑。传统功能是确定性逻辑：用户点“保存”，数据库就写入一条记录；用户选“按时间排序”，列表就按时间倒序排。这种功能的需求描述天然是可验证的，因为输入和预期输出是一一对应的，产品经理甚至不用花太多心思去定义“什么叫正确”。

AI 功能完全不是这样。以“关键信息提取”为例，同一个输入文本，两个标注人员可能给出略有差异的结果；同一个模型，参数微调前后输出的字段边界也会不同；甚至同一个模型同一版参数，对同一段文本的两次调用结果也可能有波动（比如开启了采样温度后）。这是概率性系统的基本属性——它不是在执行逻辑，而是在做分布预测。

这个底层差异带来三个直接变化。

第一个变化是“输入”的定义方式不同。传统功能你只需要定义字段格式，比如“用户输入手机号，11 位数字”。AI 功能你面对的是开放、多样的现实输入，文本可能有错别字、口语化表达、长尾格式、排版混乱。PRD 里如果只写“支持输入一段文本”，根本不足以约束后续的测试和迭代方向，你需要给出输入样例的分布描述，甚至按来源、场景去分类描述。

第二个变化是“输出”的验收方式不同。传统功能你写“点击按钮后生成 Excel 文件”，研发做完你打开文件检查一下格式和数据对不对就行。AI 功能的输出没有唯一正确答案，只有“接不接受”和“质量高低”。比如抽取结果里某个字段答错了，你不能简单地说功能坏了，你得判断这个错误是系统性问题还是极端个案，这个判断需要依赖统计指标，而不是单个样例。

第三个变化是“质量标准”的位置不同。传统 PRD 里质量标准往往是性能要求、兼容性要求、异常处理要求，写得再多也是“锦上添花”。但 AI 功能里，质量标准是需求的核心构成部分，因为“准确提取”这个需求本身没法指导研发做任何决策，只有“准确率达到多少”“有哪些典型错误可以容忍”“哪些错误绝对不允许出现”才能真正驱动技术选型和模型调优。指标和样例不是附加的验收文档，它们本身就是需求的一部分。

理解了这三点，就不会再纠结“为什么研发老说我的 PRD 没法开发”。不是研发不配合，而是你没有提供能指导开发的“判定标准”。AI 系统的开发过程本质上是逼近一个目标分布，如果你的 PRD 里只有一句“要准确”，那研发只能靠猜。猜出来的东西大概率不是你要的。

2. 把“准确提取”拆成可衡量的指标

拆指标这一步是整个 PRD 的地基。很多 PRD 写不准，不是因为理解不到位，而是缺少一套能把“准确”分解为可计算指标的框架。

我习惯用的框架是“正确性、完整性、稳定性”三个维度加“一个核心指标”的组合。拿字段提取功能来举例：假设我们要从房屋租赁合同里提取租金、租期、押金方式这几个字段，那“准确”这个词至少意味着三件事——提取出来的值对不对、该提取的字段有没有漏、同一个合同你在不同时间跑结果是不是一致。这三个需求分别对应正确性指标、完整性指标和稳定性指标。

正确性指标层面，很多人第一反应是“准确率”。坦率说，准确率在信息抽取场景里是个非常粗糙的指标，尤其是类别分布不均衡的时候。举个例子，100 个测试样本里 90 个不含“押金方式”字段，模型全部预测为空，准确率还有 90%，但这个模型实际毫无用处。我建议至少补充精确率和召回率：精确率关心“提取出来的值里有多少是对的”，召回率关心“应该提取的值里有多少被找到了”。这两个指标哪个更重要，取决于功能定位。如果是辅助人工审核，你可以牺牲一点召回率保证准确率，减少人工纠错成本；如果是自动填充系统，你更希望召回率优先，漏了可以后续补，错了会写进库里就很难清理。

完整性指标不要只看单个字段的召回率，要按“实体级别”去定义。比如房租合同里“押金方式”可能是一个短语，也可能是“押一付三”这种缩写，模型把“押一付三”整体提取出来算对，还是必须拆成“押金月数=1、付款月数=3”才算对，这个必须在 PRD 里界定清楚。不然研发按整体提取做了，你拿到结果发现没法用，又要返工。

稳定性指标在国内做 AI 功能的 PRD 里经常被忽略，但恰恰是上线后被投诉最多的点。稳定性指标的定义方式很简单：同一份测试集，用同一版模型跑两次或者多次，看结果的一致性率。建议在 PRD 里明确写一个允许的波动范围，比如“相同输入的重复输出一致性需高于 98%”。注意这里说的是模型配置不变的重复推理，不含因为开启采样温度带来的合理多样性。

指标拆完后，还要做一件同样重要的事：给每个指标设定阈值和优先级。我的习惯是把阈值分成三档——目标值、可接受值、不可接受值。目标值是产品理想状态的指标，用于定义长期目标；可接受值是上线的最低门槛，低于这个值应阻塞发布；不可接受值是一个预警线，用于标注那些即使整体指标达标、但特定场景下绝对不能出现的情况。举个例子，字段提取的“合同编号”字段因为格式统一，准确率目标 99%、可接受 95%；“押金方式”字段因为表达多样，目标 92%、可接受 85%。但有一条不可接受的红线：如果“租金金额”字段出现提取错误，哪怕整体指标达标也不允许上线，因为这是核心交易字段，错了用户直接投诉。

阈值怎么定，不能拍脑袋。我一般会参考三个来源：一是找一批历史真实数据做快速标注，跑一下现有规则或模型看基线水平；二是看竞品或者公开评测集上同类任务的合理水平；三是结合人工兜底成本算账。用“兜底成本”举例子：如果提取错误率是 5%，每天 1 万份合同就有 500 份需要人工修正，按每份修正耗时 2 分钟算，需要 17 人时——你可以用这个数字去和业务方确认，到底哪个指标值是他们能接受的。这个方法往往比讨论指标本身更能推动决策。

3. 构建样例集：让需求从“怎么说”变成“怎么检查”

指标定义得再漂亮，如果没有对应的样例集去执行评估，一切都是纸上谈兵。我踩过一次很大的坑：和研发敲定了“准确率 95%”的目标，大家都没异议，结果研发用自己的测试集跑出来 96%，高高兴兴提测，我用业务真实数据一测只有 80%，两边吵得不可开交。后来复盘才发现，问题出在“测试集”没有统一。PRD 里写了指标，却没写清楚拿什么数据去测，这个指标就等于没有定义。

所以现在我写 AI 功能 PRD 有个铁律：指标和样例集必须绑定出现。每个核心指标后面都要附上一份评估样例集的定义方式，甚至直接在 PRD 里列出抽取一定数量的代表性样例作为附录。研发开发时用这套样例集做基准测试，测试用例从这套样例集里抽样，验收也以这套样例集上的结果为准。这样才能真正做到“可检查”。

样例集怎么构建？我一般分三步。

第一步，确定样例规模和分布。不要盲目追求数量，关键是覆盖度。我的经验是初期先拿 500 到 1000 条真实数据做首轮标注，其中至少包含 20% 的边界情况和负面样例。这 20% 非常关键，因为模型真正的差异不是在标准样例上拉开的——在标准样例上大家都差不多——而是在边界输入上分高下的。所谓边界情况，对合同信息提取来说包括：金额大小写混排、日期格式五花八门、字段缺失或重叠、口语化表达、扫描件 OCR 错字等。

第二步，做标注规范并验证一致性。这一步容易被产品经理忽略，因为你默认“提取正确”这件事很客观，但实际标注起来会发现歧义特别多。比如合同里写着“每月租金 5000 元，押一付三”，我问三个标注同学“押金方式”字段提取什么：有人写“押一付三”，有人写“押金 1 个月”，有人写“押金 5000 元”。所以建样例集必须配套一份标注规则，规则里明确字段边界、格式归一化方式、歧义处理原则。然后让两个标注者对同一批数据分别标注，计算标注一致率，一般要打到 90% 以上才敢拿来当评估基准。否则你拿到的“金标准”本身是抖的，后面所有指标都失真。

第三步，把样例集分级管理。我不会把所有样例混在一个桶里面，而是分成 P0、P1、P2 三级。P0 是高频主流程样例，比如最常见的合同格式，占样例集 60% 左右，这部分错了系统基本不可用；P1 是常见变体，占 30%，错了影响体验但仍可容忍；P2 是长尾极端样例，占 10%，出错可以接受，但要记录在案作为后续优化方向。分级之后，上线门槛可以定义为 P0 准确率不低于 98%、P1 不低于 90%、P2 不作硬性要求。这样定义比笼统的“准确率 92%”更精细，研发也心里有底，知道力气应该花在哪些数据上。

这里还要提一个容易被骂的细节：不要在 PRD 里只给正面样例。很多产品经理习惯把“希望系统做到的样子”写清楚，比如给一段正确提取结果作为示例，但从来不写“不希望出现什么”。我见过一次事故，AI 客服的知识库问答，开发全拿正确回答做测试，结果用户问“你们和XX公司什么关系”，系统一本正经地编了个回答——因为 PRD 里从头到尾没规定过“面对知识库中不存在的信息，系统必须回答不知道”。AI 功能如果不约束失败模式，系统会以很有自信的方式犯错，这种错误比回答慢、答非所问更难接受。所以样例集里一定要包含负面样例和拒绝回答的判断边界，这部分往往比正面样例更影响用户体验。

4. 实操 PRD 模板：从验收标准到错误边界一口气说清

前面讲了不少方法论，这一节给一份可以直接套用的 PRD 片段。以“租房合同关键字段提取”功能为例，我会把 PRD 里关于需求核心的部分拆成五段来写，每一段都有明确目的。

第一段写功能概述和用户场景。这段克制一点，三五行说清楚就行，因为你不是在写产品宣传文案。我通常会写：用户上传租房合同图片或 PDF，系统自动提取租金、租期、押金方式、双方姓名等字段，回填到录入表单，辅助运营人员提升录入效率。这段的目的是让所有评审人员快速对齐上下文，而不需要在脑子里脑补业务场景。

第二段写输入定义和范围边界。输入定义要包含文本来源、格式范围、文本长度限制、清晰度要求。范围边界则明确什么情况不在本次功能支持范围内，比如手写合同暂不支持、英文合同暂不支持、图片旋转超过 30 度不保证效果等。这段特别重要，因为 AI 功能最怕“范围不收敛”，研发在开放域里做优化会累死，而且效果也很难让人满意。明确说不支持什么，不是能力不足的表现，反而能让模型把注意力集中在主要场景上，整体效果更好。

第三段写输出定义和验收标准。这是全篇的重心。我一般用表格列出每个字段的示例、取值范围、目标指标。举个例子：

表格后面还要附加说明：这里的准确率基于第 3 节定义的评估集计算，评估集包含 800 条已标注真实数据，P0 样例 480 条。指标以离线评估结果为准，上线后通过标注回流数据持续监控线上表现，若连续一周 P0 准确率跌破可接受值，触发迭代优化流程。

第四段写失败模式和错误边界。这里我会明确列出一组“不可接受行为”，即使整体指标达标，出现这些行为也必须返工。常见不可接受行为包括：租金金额与其他数字字段混淆、同一字段出现两个值时随机二选一但无任何优先级说明、低置信度结果直接进入表单而没有标记等。还要写清楚系统的兜底方式：比如当模型置信度低于阈值时，表单该字段应展示为空并提示人工填写，而不是把可能错误的结果写进正式数据里。

第五段写数据需求和迭代计划。AI 功能上线只是起点，标注数据和模型迭代是一个持续过程。我会在 PRD 里写明上线后需要回收哪些数据，由谁负责抽检标注，多久做一次回归测试，模型更新的最小间隔是多少。这些内容写不写，直接影响功能的长期表现。很多 AI 功能死在“上线即巅峰”，上线时指标挺漂亮，三个月后业务数据分布一变，准确率垮了，但没有标注回流机制，产品只能干瞪眼。

这五段写下来，需求文档自然就“可检查”了：研发有明确的目标指标和评估集，测试有统一的验收用例和不可接受清单，数据团队知道上线后要回收什么数据，业务方也知道系统在什么场景下会翻车、翻车后有什么兜底。整个过程务实、能落地，不依赖神仙打架式的口头沟通。

5. 与研发协作时的落地技巧：指标不是用来施压的

写出一份可检查的 PRD，只是把“准确提取”变成合格需求的第一步。真正的考验在于和研发协作的过程中，你是不是把指标用对了地方。我见过不少产品经理，PRD 里指标写得很全，开发评审会上一拍桌子：“准确率必须 95%，达不到别上线！”这种沟通方式基本会把项目带沟里。

先说清楚一个认知：指标是用于指导决策的起点，而不是卡人的工具。如果你把 95% 当作一个不容讨论的裁决数字，研发很自然会想尽办法在评估集上凑数字——数据清洗一下、挑几个容易的样例替换，数字上去了，实际效果没变。正确做法是把指标当作一个“共同语言”，用指标去定位问题、讨论取舍。开发阶段如果实测准确率只有 88%，你不要急着发火，而是先看误差分析报告：错误主要是集中哪个字段？分布在什么类型的输入上？如果只是押金方式字段的长尾表达没过关，而高频主流程已经很稳，那这个版本的准确率是可以接受的部分达标，优先级调整后继续迭代就好。如果你一上来就用指标压人，研发反而没有动力给你输出这些有价值的分析信息。

其次是不要提一次指标就撒手不管。做 AI 功能的 PRD，需要你在开发周期内持续跟进。我习惯在项目启动时和研发约定每次模型实验输出一份简单的评测报告，包含当前版准确率、召回率、错误样例 Top 20。每次拿到报告，我会花半小时逐条看错误样例，判断哪些是标注规范本身的问题、哪些是真实模型缺陷、哪些是 PRD 里没有定义清楚的新边界情况。这个方法很笨，但效果最好。因为错误样例本身就在告诉你需求的盲区在哪里，不少边界规则就是看错误样例看出来的。

还有一个实操技巧：别在 PRD 里写“不准出现幻觉”这种没有操作性的要求。和研发聊的时候，把“幻觉”定义清楚——是指“提取出原文中不存在的值”，还是“把非该字段的内容填进了该字段”，还是“在信息不足时强行推断”。定义越具体，研发越容易通过后处理规则、置信度阈值等方式处理。这是我在多次合作里悟出来的经验：AI 的问题描述得越贴近数据表现，解决起来越快。

另外提醒一点，如果你对接的是外包团队或者跨部门协作团队，指标和评估集的约束要写进商务合同或 SLA 里。口头约定“差不多准确就行”是纠纷的温床，白纸黑字定义好评估集、指标值、不可接受行为分类，验收时才有客观依据。我在跨团队项目里吃过这个亏，后来宁可多花一周整理样例集和验收规则，也不愿意在验收阶段靠吵架解决问题。

6. 常见问题与排查技巧：写 AI PRD 时遇到的典型坑

写 AI 功能的 PRD 踩过的坑，比写传统功能多得多。这里整理几个出现频率最高的，每一个都是真金白银换来的经验。

第一个坑是“评估集数据来源不真实”。很多团队为了赶进度，标注数据是产品经理和开发“编”出来的模拟数据，看起来格式很标准，内容很大路。这种评估集跑出来的指标像面镜子——照出来的不是模型能力，而是你出题的水平。模拟数据完全无法覆盖真实场景里的脏数据、口语化表达、格式变化。我现在做信息抽取类需求，第一周宁可花时间去找真实数据源、做脱敏、写标注规则，也不要急着建评估集。真实数据里藏着的多样性，是任何能力都替代不了的需求信息来源。

第二个坑是“标注规范写在 PRD 正文外”。很多团队用独立文档管理标注规范，PRD 里只一句话带过。问题在于，标注规范是验收基准的一部分，如果它和 PRD 分离，评审的时候没人会认真看标注规范，于是也没人发现争议字段的定义漏洞。我建议至少把标注原则和公认的歧义处理规则嵌入 PRD 附录，正式评审时逐条过一遍。这既是对研发负责，也是对测试负责，省得后期扯皮。

第三个坑是“指标只看了算法指标，没看业务指标”。准确率、召回率再高，如果业务使用效果不达预期，对产品来说仍是失败的。我自己常用的检查维度是“端到端节省率”和“人工修正率”——上线前人工录入一份合同平均耗时 8 分钟，上线后系统自动填充部分字段，人工核对修正后平均耗时降到 3 分钟，这个变化比单纯一个模型准确率更有说服力。所以在 PRD 里除了算法指标，我也会带上业务侧的前后对比目标和埋点方式。两个维度一起看，才算真正闭环。

第四个坑是“忽略了失败反馈闭环”。产品上线前 PRD 里没有写清楚低置信度结果如何处理，也没有定义用户反馈渠道。文本类提取功能可能还好，对话类和生成类功能一旦没有失败反馈机制，用户反复提问没有得到纠正，体验会极其糟糕。建议在需求里明确：置信度低于阈值的输出必须在界面有标记，用户可以对结果点赞或点踩，反馈数据自动回流到标注池。这个闭环看起来是个小细节，实际上是 AI 功能持续变好的发动机。

第五个坑是“没有预留模型迭代的时间”。PRD 评审时大家总觉得开发完成、测试通过就结束了，但 AI 功能几乎不可能一次成型。我经历过一个文档解析项目，第一版测试准确率只有 76%，离门槛差不少。好在那时候 PRD 里预留了两轮模型优化的时间窗口，而不是把时间全部排死在开发上，否则项目只能延期或者带病上线。写排期的时候，请一定把“数据标注、模型调优、回归测试”这些环节单独排期，别天真的以为开发完了就彻底完事了。

7. 最后聊聊我的真实体会

写了这么多版 AI 功能的 PRD，我最大的感受是：所谓把“准确提取”改成可检查的需求，本质上是逼自己想清楚两件事——到底什么算对，什么算错。前者靠指标和样例集去定义，后者靠失败边界和兜底机制去约束。这两个问题一旦想透了，研发、测试、数据、业务四方各拿各的尺子去量同一个需求，项目效率会高很多。

过程确实麻烦，比起写一句“准确提取”，你得多花很多精力去整理样例、写标注规则、定义阈值、梳理边界情况，还要上线后持续跟进回流数据。但正是这些麻烦事，才让 PRD 从“需求描述”变成了“质量标准”。我个人的建议是，哪怕前期时间紧，也不要砍掉样例集和标注规范这两个环节，因为后面节省的沟通成本和返工时间，远比你前期投入的多。

如果你现在正准备写 AI 功能的 PRD，又正好卡在“不知道怎么写准确”这一步，不妨先停一下，别急着动笔描述功能。先去找一批真实数据，找两个同事把结果标一遍，看看你们自己有没有歧义。只要这一步做完，后面所有内容都会自然顺畅很多。想清楚再写，比写完再改，省力太多了。