AI功能PRD怎么写？把“准确提取”拆成可验收的字段级指标

写AI功能的PRD，最坑的坑就是开头写“准确提取”“智能识别”“理解用户意图”这种话。我见过的项目里，十份AI产品需求书有八份栽在这上面——开发拿着“准确提取”不知道做到什么程度算完成，测试拿着“准确提取”不知道构造什么用例算通过，算法工程师看着“准确提取”更是一脸茫然：提取错了要不要修？修到几成算合格？最后交付的时候互相扯皮，原本一个月能上线的功能拖成三个月还吵不清。今天就把这事儿聊透：怎么把“准确提取”这种主观描述，改写成每个字段都有指标、每个指标都有验证方法、每个验证方法都有通过标准的可检查需求。

这篇文章适合两类人：一类是被AI功能需求折磨的产品经理，另一类是跟AI功能需求对接的开发、测试和算法工程师。文章里会用一个贯穿始终的例子——发票要素提取，从字段拆解、样本定义、指标设定到验收模板，一步一步演示怎么写出一份能落地的AI功能PRD。

1. 为什么“准确提取”是PRD里最危险的四个字

先搞清楚问题出在哪。我拆过很多AI项目需求，发现模糊描述不只是“不专业”这么简单，它会直接污染整个研发链条。

1.1 模糊需求如何拖垮整个团队

AI功能跟传统功能有个本质区别：传统功能是确定性逻辑，输入是什么，输出就能推断出来；AI功能是概率性输出，同样的输入，不同模型、不同版本、甚至同一版本不同参数，结果都可能不一样。正因为这种不确定性，PRD里每个字都必须变成约束条件，“准确提取”这种词压根不构成约束。

我说个真实发生的场景。某次项目要做一个增值税发票信息提取功能，PRD里写“准确提取发票上的关键信息”。开发拿到需求后，着手方案时第一个问题就是：准确率目标是多少？项目负责人说至少90%吧。开发又问：是字符准确率还是字段准确率？是全部字段都算，还是每张票至少有多少个字段对？负责人愣住了——他没想过这个问题。然后测试也来问：测试样本用谁的？真票还是扫描件？模糊票算不算？这时候整个项目已经进入泥潭了。

问题根源在于，传统PRD的验收标准是“功能跑通即可”，AI功能的验收标准必须是“指标达标才算完”。模糊的“准确提取”没有任何指标，等于没有验收标准，项目就只能靠“感觉”推进。等到联调阶段，产品说“这效果不太行”，开发说“我觉得已经挺准了”，两边吵起来，根本无解。

1.2 可检查需求的核心：断言思维

要治这个毛病，我习惯用“断言思维”。写过单元测试的同学都知道，断言就是“我认为这个条件下必须满足这个结果”，不满足就算失败。AI功能PRD也应该用断言来写需求，把每一句模糊描述拆成至少一条可以判真/假的断言。

比如“准确提取发票号码”，拆成断言就是：

• 当输入一张清晰、不倾斜、分辨率不小于1200px的增值税发票正面图像时，系统输出的invoiceNo字段值必须与人工标注值完全相同。

这句话可验证吗？可验证。有输入条件（清晰、角度正常、分辨率阈值）、有输出定义（invoiceNo字段）、有比对基准（人工标注值）、有比对方式（完全相同）。满足所有条件就通过，任何一个不满足就记为一条错误。这样的需求才能进入研发流程。

所以把“准确提取”改成可检查需求，核心就一句话：给每个抽象能力绑定可量化的行为描述。接下来我用发票提取这个例子，完整演示怎么操作。

2. 把“准确提取”拆成可验证的字段级指标

2.1 从“整体准确”到“字段级准确”的拆解

一开始拿到“准确提取发票信息”这个需求，我先不急着写指标，而是先把“准确提取”这个词拆成输出字段。这一步是后面的所有工作的地基。

以增值税发票为例，常见的需要提取的字段至少有：单据编号、开票日期、销售方名称、购买方名称、金额、税额、价税合计、备注等。拆字段的时候有个原则：宁细勿粗。因为每个字段的提取难度差异巨大——单据编号是一串结构化编号，容易校验；销售方名称是自由文本，可能有歧义；金额涉及小数点、负号、币种；备注可能为空也可能有长文本。如果笼统地写一个“整体准确率90%”，等于默认所有字段难度相同，这不符合实际。

拆完字段之后，要给每个字段单独定指标。可以参考我这个做法：字段本身的校验规则决定指标口径。单据编号必须是纯字符串，匹配就是0或1，用“字段完全匹配率”最合适，即该字段在所有测试样本中整个字段完全正确的比例。

金额字段更复杂，因为它有语义要求——OCR识别出“12345.6”和人工标注的“12345.60”类型不同，但数值一样，到底算不算对？我建议在字段定义阶段就约定归一化规则：金额去掉货币符号、去除千分位、统一小数位为两位、转成数值比较。规则定了，才算“可检查”。

重要提示，拆字段时一定要跟最终使用方确认字段清单。我遇到过一次，需求方只说要提取金额，结果交付时才发现他们还要区分“不含税金额”和“含税金额”，整个字段体系都得重来。提前把字段清单列出来，找使用方签字确认，后面能少走很多弯路。

2.2 定义输入样本集与前置条件

字段指标定完之后，紧接着要回答一个问题：在什么输入上算这个指标？AI模型最怕的就是训练和测试分布不一致——你拿高质量扫描件做的评测结果，拿到手机随手拍的照片上立刻崩掉。所以PRD里必须明确输入样本集的构成。

样本集不能只有一个总集，至少要分成三个子集：主集（正常条件下的标准样本）、边界集（临界条件下的样本）、异常集（不符合输入条件的样本）。我用发票场景来说：

• 主集：2000张清晰的扫描件，纸张完整、文字清晰、印章不遮挡关键字段。这部分用于定义“正常工作条件下的效果基线”。
• 边界集：500张倾斜角度15度以内、光照不均、或者分辨率略低但人眼仍可辨认的图像。这部分用于定义“临界条件下模型不能崩”的下限。
• 异常集：200张非发票图片、超出倾斜范围的图片、或者分辨率极低的图片。这部分用于定义模型拒绝处理的兜底行为，比如“不应该返回虚假字段”。

前置条件也必须写清楚。比如上一条说“输入一张清晰、不倾斜、分辨率不小于1200px的发票正面图像”——这就是前置条件。AI模型不是万能的神谕，它有能力边界，PRD要把边界画出来。注意，前置条件不是推卸责任的借口，而是让验收有条理的必要代价。真正专业的做法是：前置条件越明确，越过边界时的行为也越明确——要么返回“无法识别”的置信度标识，要么提示用户重新拍照。

2.3 阈值、容错边界与格式归一化

有了字段和样本集，第三步才是定阈值。这里最容易犯的错是拍脑袋写一个“准确率99%”，得想清楚一个现实问题：字段A可能很容易到99%，但字段B拼尽全力只能到90%。如果整体合并成一个指标，字段之间的难度差异就被平均了，弱字段的短板会被掩盖。所以指标分配的逻辑应该是：关键字段高指标，非关键字段合理指标。

以发票提取为例，我会写这样一张表：

这张表的价值在于：每个指标都有匹配口径（不看值域的精确匹配，会导致口径不一致）、有子集分解（主集和边界集分开考核）、有错误等级（用于决定出问题时的优先级）。这种写法才叫可检查的需求，它把“准确提取”翻译成了开发能执行、测试能验证的验收基线。

3. 验收与评测：怎么才算“过关”而非“感觉还行”

指标写进PRD只是第一步，更关键的是建立一套评测和验收机制。没有机制的指标，就是写在纸面上的空话。

3.1 样本标注规范与争议裁决机制

任何AI功能的准确率指标，都依赖“ground truth”，也就是人工标注的正确结果。如果标注本身有分歧，“准确率到底是多少”就成了公说公有理婆说婆有理。所以PRD里必须包含标注规范，并且明确规定分歧处理机制。

我给团队定过一个标注规范原则：每个测试样本必须由至少两人独立标注，标注结果完全一致才进入样本集；对标注结果不一致的样本，由需求方和技术负责人共同仲裁，一次仲裁定不出结论的样本直接丢弃，不计入任何指标。这个规则能保证评测基准的可信度。

为什么标注规范这么重要？还是发票场景。发票上的“购买方名称”可能因为公司改名、简写、抬头不同，在票面上呈现不同写法，标注员A认为“百度在线网络技术（北京）有限公司”和“百度在线网络技术北京有限公司”是同一回事，标注员B认为必须严格按票面文字记录。如果没有仲裁机制，同一个模型同一个输入，不同人评测可以得出相差五个百分点的“准确率”。到时候验收环节出现巨大分歧，根本没法收场。

3.2 可接受的失败模式有哪些

这个思路很多人没想过。传统功能的验收是二元化的，能跑则过、不能跑则不过。AI功能的输出具有概率性，必然有失败样本，关键问题不是“有没有错误”，而是“哪些错可以接受、哪些错绝对不能碰”。

我在PRD里会写一个“失败模式分级”，给这个功能做一次风险分类：

• 不允许出现的错误（致命错误）：单据编号错、价税合计错，这类字段一旦出错，下游记账、报税流程就会错，属于绝对不能接受的错误。报告中必须单独统计该类错误，数量超过样本总数的1%，直接判定整体不通过。
• 允许出现但必须控制的错误（重要错误）：销售方名称、购买方名称错。实际业务中名称偶尔出错可以由人工复核发现，但漏字、多字会导致检索困难，需要控制在整体错误的2%以内。
• 允许出现且影响有限的错误（一般错误）：备注、开户行及账号等，偶发性识别不全会影响体验但不伤核心流程，控制在5%以内即可。

把失败模式分级写进PRD，开发会非常感激。因为它能帮算法团队做出关键取舍：模型如果能在“核心字段不犯错”和“非核心字段尽量对”之间合理分配容量，总体的每次迭代方向就更聚焦。否则算法同学往往会为了拉升平均准确率牺牲关键字段，把模型调成“平均数好看但关键场景出事”的状态。

3.3 PRD中的完整验收条目怎么写

到这里就可以把验收条目真正落笔了。一门心思写“准确提取”的人，这时候根本不知道要写什么；但按上面步骤走下来，验收条目几乎是水到渠成。我提供一个可以往PRD里直接粘贴的书面版本：

本节验收不以主观体验为准，仅依据在正式样本集运行得到的客观指标。验收触发条件与通过标准如下：

1. 测试环境：评测服务独立部署，不与应用服务共享资源。
2. 样本集：全部使用不可更新的定版本样本集，样本编号S-D-001总数量2700条（主集2000条+边界集500条+异常集200条），样本集版本号当前为v2.1。
3. 评测命令与参数：按附件中的评测脚本统一执行，模型服务响应超时5秒记为一次错误。
4. 指标要求矩阵如下：
   • 主集单据编号字段完全匹配率：不低于99.0%。
   • 主集价税合计字段数值归一化匹配率：不低于98.0%。
   • 边界集单据编号字段完全匹配率：不低于95.0%。
   • 全量样本集单据编号字段完全匹配率：不低于97.5%。
   • 全量样本集不允许出现的失败模式数量：小于10条（约等于全量的0.37%）。
5. 所有指标在评审时提交原始评测报告，报告须包含逐条失败样本截图或原始图像切片、对应的输出值和标注值，经过标注仲裁后方可计入最终结果。

这已经是完整的验收协议了。测试拿到它可以执行，开发拿到它知道边界，需求方拿到它能对质量做出判断——需求从“觉得行”变成了“证明行”。

4. 一套可直接抄的AI-PRD模板（示例）

下面我把上面所有拆解过程，整理成一份可以在实际项目中套用的PRD主体示例。你以后写AI功能需求的时候，不用从零开始，按这个框架填充自己的内容即可。

4.1 需求描述部分

功能名称：发票影像要素提取服务v2。功能定位：将用户上传的增值税发票图像转换为结构化字段，供下游报销、归档、核对流程直接调用，不依赖人工转录。

输入条件说明：

• 支持输入格式：JPG、PNG、PDF导入后的首帧。
• 支持输入大小：单张不超过10MB。
• 清晰度要求：图像最短边不低于800px，文字区域可被人类肉眼辨认。
• 拍照条件：拍摄角度不超过30度，票面四角完整可见。
• 不支持的输入：手写小票、电子发票PDF截图且缺少完整版式、非发票类图像，此类输入系统必须返回“无法识别”标记，不得猜测输出。

输出定义：

• 返回结果包含字段明细表、置信度分数、识别状态（成功/低置信度/失败）。
• 字段明细表采用统一扁平JSON结构，每个字段均携带字段名、值、置信度和解析耗时。
• 置信度低于规定阈值时，对应字段必须返回空值并标记为低置信度，禁止强行填充。

4.2 指标定义部分

指标定义按主集和边界集分别给出，使用绝对数量与百分比结合的方式，避免百分比被样本量“稀释”或被极端样本操纵。

另附加一条底线指标：全量测试样本集上，致命错误总数不超过10条。

4.3 样本管理与评测流程部分

样本管理规则：

• 样本集由需求方建立，测试团队持有，算法团队可以查看但不得修改样本集。
• 样本集随模型版本迭代更新，每次更新必须走评审流程并更新版本号。
• 训练过程中如曾使用过某批样本做早停止或调参，该批样本必须从新评测集中排除；属于样本泄露。

评测流程规则：

• 每次版本提交，由测试团队执行统一评测脚本。
• 评测结果标注样本编号、模型版本、样本集版本、运行时间，生成可追溯报告。
• 指标计算二次确认：对评测脚本的比对逻辑做一次复核，重点检查归一化规则是否有改动、是否误把空字段算为匹配成功。

4.4 回归与版本管理部分

AI功能版本更新的频率远高于传统功能，PRD必须具备适配版本迭代的结构。建议在PRD中预留模型版本记录表格：模型版本、上线日期、评测准确率、主要改动、回滚方案。这样做的好处是功能停止维护后，依然能回答“当前线上的模型是什么时候更新的、达标了没、有多少已知问题”。我强烈建议把这份记录作为PRD的固定附件，后续模型即使换了供应商或者换用了新的多模态方案，这份记录也能在追责排查时快速定位问题。

5. 常见问题与踩坑实录

这部分是我在不同项目里踩过或看别人踩过的坑，一条条整理出来，比看多少模板都有用。

5.1 为什么开发说“达不到99%准确率”

“99%”作为指标本身没问题，问题往往出在指标口径互相冲突。开发可能以为你要的是每个字符都和原件一字不差的字符级准确率，而你实际要的可能是字段级归一化匹配率——带人名的免息名额、大小写、全角半角差异根本不值得计较。解决这个问题的方法就是我在前文反复强调的：在PRD里写清楚“匹配前先做哪些归一化”的规则。把口径写死，开发和产品争论的就不是“能不能做到”，而是“归一化规则是否合理”。这能聚焦讨论方向，极大减少扯皮时间。

5.2 模型迭代后PRD要不要改

必须改，而且要留记录。AI模型每训练一个新版本，准确率、失败模式都可能变化。PRD此时扮演的角色是“验收协议”，协议自然要跟着版本走。我的习惯是PRD按版本归档，每迭代一次需求文档加一个修订记录表，写上修改人、时间、改动点和原因。好处是等模型出问题时，能查到当时是基于什么标准放行的。如果没有版本记录，出了问题根本分不清是模型回退、评测口径变化还是样本集更新导致的指标波动。

5.3 多模型兜底方案的验收口径

很多AI功能会接多套模型做兜底，比如OCR主引擎失败后切换备用引擎，再接一层规则降噪，这也叫多模型协作。写这类PRD时一定要定义一个主评估口径：以最终对用户展示的结果为准。只要最终字段符合验收标准，不管中间经过几层模型套娃都算通过。不过要额外加上性能验收：兜底链路的总耗时不能超过主链路的2倍，单次请求超时5秒即视为失败。还有一点容易被忽略，兜底方案引入后，评测必须按“链路总接口”走，不能只拿主模型的输出做准确率评估。

5.4 用户视角评测和离线指标严重不一致

最后说一个经典现象：指标全绿、用户骂街。原因通常是定义了错误的粒度。比如你统计“整体字段匹配率”达到96%，但用户实际在乎的是“单据编号和金额对不对”。如果这两个关键字段的错误虽然占比小，却真实发生了，用户的观感就是“这破功能怎么老是识别错”。我后期所有AI PRD都会强制加一条：关键字段错误率单独统计、高于阈值为一票否决项。宁可平均指标好看一点，也要守住关键字段的底线，用户对AI的信任只要经历一次关键错误就回不来了。

分享一个收尾的技巧：评测样本集本身也要定期做“口感测试”。什么意思？就是每个季度从线上流量里随机抽一批新样本，补进样样本集，并对照旧样本集的指标曲线，看偏差是否放大。这样能及早发现样本陈旧的问题——纸面上指标一直98%，真实场景换了新票版式瞬间掉到70%。如果没有这个机制，版本上线之后才被真实用户发现问题，那时候损失的都是业务。

我做AI功能的PRD做了几年，最深的一个体会就是：写AI PRD不是写文案，是在写一套能让所有参与角色共识对齐的验收协议。“准确提取”四个字谁都认识，但只有把它拆成字段、样本、指标、归一化规则、错误分级、评测流程，才能让产品、开发、测试、算法四个人站在同一张评测报告前，说出同一句“这回真的达标了”。