写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%。如果整体合并成一个指标字段之间的难度差异就被平均了弱字段的短板会被掩盖。所以指标分配的逻辑应该是关键字段高指标非关键字段合理指标。以发票提取为例我会写这样一张表字段指标口径主集目标边界集目标错误等级单据编号整串完全匹配忽略换行符≥99.0%≥95.0%致命开票日期按YYYY-MM-DD归一化后完全匹配≥99.0%≥95.0%致命价税合计数值归一化后比较允差0.01≥98.0%≥93.0%致命销售方名称全角/半角归一化后完全匹配≥97.0%≥90.0%重要购买方名称全角/半角归一化后完全匹配≥96.0%≥88.0%重要备注为空时跳过非空时要求核心语义一致≥90.0%≥80.0%一般这张表的价值在于每个指标都有匹配口径不看值域的精确匹配会导致口径不一致、有子集分解主集和边界集分开考核、有错误等级用于决定出问题时的优先级。这种写法才叫可检查的需求它把“准确提取”翻译成了开发能执行、测试能验证的验收基线。3. 验收与评测怎么才算“过关”而非“感觉还行”指标写进PRD只是第一步更关键的是建立一套评测和验收机制。没有机制的指标就是写在纸面上的空话。3.1 样本标注规范与争议裁决机制任何AI功能的准确率指标都依赖“ground truth”也就是人工标注的正确结果。如果标注本身有分歧“准确率到底是多少”就成了公说公有理婆说婆有理。所以PRD里必须包含标注规范并且明确规定分歧处理机制。我给团队定过一个标注规范原则每个测试样本必须由至少两人独立标注标注结果完全一致才进入样本集对标注结果不一致的样本由需求方和技术负责人共同仲裁一次仲裁定不出结论的样本直接丢弃不计入任何指标。这个规则能保证评测基准的可信度。为什么标注规范这么重要还是发票场景。发票上的“购买方名称”可能因为公司改名、简写、抬头不同在票面上呈现不同写法标注员A认为“百度在线网络技术北京有限公司”和“百度在线网络技术北京有限公司”是同一回事标注员B认为必须严格按票面文字记录。如果没有仲裁机制同一个模型同一个输入不同人评测可以得出相差五个百分点的“准确率”。到时候验收环节出现巨大分歧根本没法收场。3.2 可接受的失败模式有哪些这个思路很多人没想过。传统功能的验收是二元化的能跑则过、不能跑则不过。AI功能的输出具有概率性必然有失败样本关键问题不是“有没有错误”而是“哪些错可以接受、哪些错绝对不能碰”。我在PRD里会写一个“失败模式分级”给这个功能做一次风险分类不允许出现的错误致命错误单据编号错、价税合计错这类字段一旦出错下游记账、报税流程就会错属于绝对不能接受的错误。报告中必须单独统计该类错误数量超过样本总数的1%直接判定整体不通过。允许出现但必须控制的错误重要错误销售方名称、购买方名称错。实际业务中名称偶尔出错可以由人工复核发现但漏字、多字会导致检索困难需要控制在整体错误的2%以内。允许出现且影响有限的错误一般错误备注、开户行及账号等偶发性识别不全会影响体验但不伤核心流程控制在5%以内即可。把失败模式分级写进PRD开发会非常感激。因为它能帮算法团队做出关键取舍模型如果能在“核心字段不犯错”和“非核心字段尽量对”之间合理分配容量总体的每次迭代方向就更聚焦。否则算法同学往往会为了拉升平均准确率牺牲关键字段把模型调成“平均数好看但关键场景出事”的状态。3.3 PRD中的完整验收条目怎么写到这里就可以把验收条目真正落笔了。一门心思写“准确提取”的人这时候根本不知道要写什么但按上面步骤走下来验收条目几乎是水到渠成。我提供一个可以往PRD里直接粘贴的书面版本本节验收不以主观体验为准仅依据在正式样本集运行得到的客观指标。验收触发条件与通过标准如下测试环境评测服务独立部署不与应用服务共享资源。样本集全部使用不可更新的定版本样本集样本编号S-D-001总数量2700条主集2000条边界集500条异常集200条样本集版本号当前为v2.1。评测命令与参数按附件中的评测脚本统一执行模型服务响应超时5秒记为一次错误。指标要求矩阵如下主集单据编号字段完全匹配率不低于99.0%。主集价税合计字段数值归一化匹配率不低于98.0%。边界集单据编号字段完全匹配率不低于95.0%。全量样本集单据编号字段完全匹配率不低于97.5%。全量样本集不允许出现的失败模式数量小于10条约等于全量的0.37%。所有指标在评审时提交原始评测报告报告须包含逐条失败样本截图或原始图像切片、对应的输出值和标注值经过标注仲裁后方可计入最终结果。这已经是完整的验收协议了。测试拿到它可以执行开发拿到它知道边界需求方拿到它能对质量做出判断——需求从“觉得行”变成了“证明行”。4. 一套可直接抄的AI-PRD模板示例下面我把上面所有拆解过程整理成一份可以在实际项目中套用的PRD主体示例。你以后写AI功能需求的时候不用从零开始按这个框架填充自己的内容即可。4.1 需求描述部分功能名称发票影像要素提取服务v2。功能定位将用户上传的增值税发票图像转换为结构化字段供下游报销、归档、核对流程直接调用不依赖人工转录。输入条件说明支持输入格式JPG、PNG、PDF导入后的首帧。支持输入大小单张不超过10MB。清晰度要求图像最短边不低于800px文字区域可被人类肉眼辨认。拍照条件拍摄角度不超过30度票面四角完整可见。不支持的输入手写小票、电子发票PDF截图且缺少完整版式、非发票类图像此类输入系统必须返回“无法识别”标记不得猜测输出。输出定义返回结果包含字段明细表、置信度分数、识别状态成功/低置信度/失败。字段明细表采用统一扁平JSON结构每个字段均携带字段名、值、置信度和解析耗时。置信度低于规定阈值时对应字段必须返回空值并标记为低置信度禁止强行填充。4.2 指标定义部分指标定义按主集和边界集分别给出使用绝对数量与百分比结合的方式避免百分比被样本量“稀释”或被极端样本操纵。评测集样本数单据编号整串匹配率价税合计数值归一化匹配率备注字段可选匹配率主集2000≥99.0%≥98.0%≥90.0%边界集500≥95.0%≥93.0%≥80.0%异常集200不允许出现字段级“虚构输出”非发票图片允许返回“无法识别”或空结果同左同左另附加一条底线指标全量测试样本集上致命错误总数不超过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不是写文案是在写一套能让所有参与角色共识对齐的验收协议。“准确提取”四个字谁都认识但只有把它拆成字段、样本、指标、归一化规则、错误分级、评测流程才能让产品、开发、测试、算法四个人站在同一张评测报告前说出同一句“这回真的达标了”。
写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%。如果整体合并成一个指标字段之间的难度差异就被平均了弱字段的短板会被掩盖。所以指标分配的逻辑应该是关键字段高指标非关键字段合理指标。以发票提取为例我会写这样一张表字段指标口径主集目标边界集目标错误等级单据编号整串完全匹配忽略换行符≥99.0%≥95.0%致命开票日期按YYYY-MM-DD归一化后完全匹配≥99.0%≥95.0%致命价税合计数值归一化后比较允差0.01≥98.0%≥93.0%致命销售方名称全角/半角归一化后完全匹配≥97.0%≥90.0%重要购买方名称全角/半角归一化后完全匹配≥96.0%≥88.0%重要备注为空时跳过非空时要求核心语义一致≥90.0%≥80.0%一般这张表的价值在于每个指标都有匹配口径不看值域的精确匹配会导致口径不一致、有子集分解主集和边界集分开考核、有错误等级用于决定出问题时的优先级。这种写法才叫可检查的需求它把“准确提取”翻译成了开发能执行、测试能验证的验收基线。3. 验收与评测怎么才算“过关”而非“感觉还行”指标写进PRD只是第一步更关键的是建立一套评测和验收机制。没有机制的指标就是写在纸面上的空话。3.1 样本标注规范与争议裁决机制任何AI功能的准确率指标都依赖“ground truth”也就是人工标注的正确结果。如果标注本身有分歧“准确率到底是多少”就成了公说公有理婆说婆有理。所以PRD里必须包含标注规范并且明确规定分歧处理机制。我给团队定过一个标注规范原则每个测试样本必须由至少两人独立标注标注结果完全一致才进入样本集对标注结果不一致的样本由需求方和技术负责人共同仲裁一次仲裁定不出结论的样本直接丢弃不计入任何指标。这个规则能保证评测基准的可信度。为什么标注规范这么重要还是发票场景。发票上的“购买方名称”可能因为公司改名、简写、抬头不同在票面上呈现不同写法标注员A认为“百度在线网络技术北京有限公司”和“百度在线网络技术北京有限公司”是同一回事标注员B认为必须严格按票面文字记录。如果没有仲裁机制同一个模型同一个输入不同人评测可以得出相差五个百分点的“准确率”。到时候验收环节出现巨大分歧根本没法收场。3.2 可接受的失败模式有哪些这个思路很多人没想过。传统功能的验收是二元化的能跑则过、不能跑则不过。AI功能的输出具有概率性必然有失败样本关键问题不是“有没有错误”而是“哪些错可以接受、哪些错绝对不能碰”。我在PRD里会写一个“失败模式分级”给这个功能做一次风险分类不允许出现的错误致命错误单据编号错、价税合计错这类字段一旦出错下游记账、报税流程就会错属于绝对不能接受的错误。报告中必须单独统计该类错误数量超过样本总数的1%直接判定整体不通过。允许出现但必须控制的错误重要错误销售方名称、购买方名称错。实际业务中名称偶尔出错可以由人工复核发现但漏字、多字会导致检索困难需要控制在整体错误的2%以内。允许出现且影响有限的错误一般错误备注、开户行及账号等偶发性识别不全会影响体验但不伤核心流程控制在5%以内即可。把失败模式分级写进PRD开发会非常感激。因为它能帮算法团队做出关键取舍模型如果能在“核心字段不犯错”和“非核心字段尽量对”之间合理分配容量总体的每次迭代方向就更聚焦。否则算法同学往往会为了拉升平均准确率牺牲关键字段把模型调成“平均数好看但关键场景出事”的状态。3.3 PRD中的完整验收条目怎么写到这里就可以把验收条目真正落笔了。一门心思写“准确提取”的人这时候根本不知道要写什么但按上面步骤走下来验收条目几乎是水到渠成。我提供一个可以往PRD里直接粘贴的书面版本本节验收不以主观体验为准仅依据在正式样本集运行得到的客观指标。验收触发条件与通过标准如下测试环境评测服务独立部署不与应用服务共享资源。样本集全部使用不可更新的定版本样本集样本编号S-D-001总数量2700条主集2000条边界集500条异常集200条样本集版本号当前为v2.1。评测命令与参数按附件中的评测脚本统一执行模型服务响应超时5秒记为一次错误。指标要求矩阵如下主集单据编号字段完全匹配率不低于99.0%。主集价税合计字段数值归一化匹配率不低于98.0%。边界集单据编号字段完全匹配率不低于95.0%。全量样本集单据编号字段完全匹配率不低于97.5%。全量样本集不允许出现的失败模式数量小于10条约等于全量的0.37%。所有指标在评审时提交原始评测报告报告须包含逐条失败样本截图或原始图像切片、对应的输出值和标注值经过标注仲裁后方可计入最终结果。这已经是完整的验收协议了。测试拿到它可以执行开发拿到它知道边界需求方拿到它能对质量做出判断——需求从“觉得行”变成了“证明行”。4. 一套可直接抄的AI-PRD模板示例下面我把上面所有拆解过程整理成一份可以在实际项目中套用的PRD主体示例。你以后写AI功能需求的时候不用从零开始按这个框架填充自己的内容即可。4.1 需求描述部分功能名称发票影像要素提取服务v2。功能定位将用户上传的增值税发票图像转换为结构化字段供下游报销、归档、核对流程直接调用不依赖人工转录。输入条件说明支持输入格式JPG、PNG、PDF导入后的首帧。支持输入大小单张不超过10MB。清晰度要求图像最短边不低于800px文字区域可被人类肉眼辨认。拍照条件拍摄角度不超过30度票面四角完整可见。不支持的输入手写小票、电子发票PDF截图且缺少完整版式、非发票类图像此类输入系统必须返回“无法识别”标记不得猜测输出。输出定义返回结果包含字段明细表、置信度分数、识别状态成功/低置信度/失败。字段明细表采用统一扁平JSON结构每个字段均携带字段名、值、置信度和解析耗时。置信度低于规定阈值时对应字段必须返回空值并标记为低置信度禁止强行填充。4.2 指标定义部分指标定义按主集和边界集分别给出使用绝对数量与百分比结合的方式避免百分比被样本量“稀释”或被极端样本操纵。评测集样本数单据编号整串匹配率价税合计数值归一化匹配率备注字段可选匹配率主集2000≥99.0%≥98.0%≥90.0%边界集500≥95.0%≥93.0%≥80.0%异常集200不允许出现字段级“虚构输出”非发票图片允许返回“无法识别”或空结果同左同左另附加一条底线指标全量测试样本集上致命错误总数不超过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不是写文案是在写一套能让所有参与角色共识对齐的验收协议。“准确提取”四个字谁都认识但只有把它拆成字段、样本、指标、归一化规则、错误分级、评测流程才能让产品、开发、测试、算法四个人站在同一张评测报告前说出同一句“这回真的达标了”。
