当AI能力从技术炫技走向业务落地，产品经理如何驾驭这一不确定性工具？本文系统梳理从理想态样例准备、POC概念验证到成本性能平衡的全流程方法论，通过具体案例解析如何建立可量化评价指标、接受合理容错率，将模糊的AI能力转化为可落地的产品解决方案。

随着 AI 大模型技术越来越成熟，产品经理的工作中，越来越多的需求都需要用到 AI 技术来实现。产品经理需要与时俱进，学习怎样做 AI 需求。

传统的需求流程是需求调研、写需求文档、需求评审、开发测试、上线复盘，但因为 AI 能力存在边界，且不是能一目了然的就知道边界在哪，所以做 AI 需求的流程与传统的需求不太一样。那么，怎么做 AI 需求呢？

前期准备

需求调研

在需求调研阶段，AI 需求和传统需求没什么区别，AI 只是一种解决方式，需求还是来自于用户 + 场景。

因此，首先需要找到我们要解决什么用户在什么场景下的什么问题，即真正的需求是什么，而不是单纯为了 AI 而 AI。

准备理想态样例

确定了需求之后，准备理想态样例在 AI 需求中是优先级最高的事情，理想态是该需求在几个典型情况下的理想表现内容。

简单举个例子，比如教育中常见的 AI 讲题场景，对于下面这道题：

正确答案是B，如果学生作答时选了C，他找 AI 提问为什么选C不对时，讲解及对应板书的理想态如下：

因为通常用到大模型生成内容的需求，都会需要对用户进行个性化的呈现，这很难在 PRD 中纯通过语言逻辑准确描述。而有了理想态之后，各方就可以具象地拉齐认知，沟通时也会更言之有物。

同时，理想态样例也能更好地帮助大家判断需求的解决方案是不是有效的。有一些需求场景可能靠想象觉得大有可为，但整理出理想态样例之后，才发现并没有解决真正的问题。

项目启动

理想态准备好且确定能解决需求后，就可以拉业务方和研发开个项目启动会，明确目标和要做的事情。因为接下来POC的过程是需要三方频繁沟通重度参与的，这样才能保证实现过程中不会出现大的方向性的偏差。根据理想态的内容，研发也可以大概预估下POC过程的成本。

POC阶段

POC是Proof of Concept的缩写，中文译为概念验证，指通过小规模实现验证想法或理论的可行性。POC阶段一般是研发主导，因为研发掌握着各项调研点的细节，产品和业务也要参与其中。

建立评价指标

产品和业务方首先需要建立明确的可量化的评价指标，即需要评测哪些方面、每个方面达到什么准确率才可以准出。评价不能仅靠感觉，类似“调了一版后大家感觉好了很多”，这样不能准确估计距离交付还有多远。

评价指标不是确定后就不能改的事情，我们不需要在设定好完美的评价标准后再开始调试，可以先初步拍一个评价指标，然后随着POC和项目的进展再逐步迭代评价指标。

在这里顺便提一句，产品经理心理上往往很难接受不完美，但在 AI 需求中需要调整下心态。因为传统的需求中的bug只要发现基本都可解决，但在 AI 需求中，需要接受有 badcase 的存在，比如准出的准确率定的95%，那就会有5%左右的 badcase 一直出现。如果一直调试 prompt 死磕，大概率会出现按下葫芦浮起瓢的情况，因此，只要符合准出标准，就可以上线。

调试过程

调试过程主要是研发主导，产品和业务方只需要配合研发的需求提供一些帮助即可，一般是准备数据集，每天关注下调试进展。

数据集需要分为训练集和测试集，两个集合的数据需要隔离，数量视场景的情况来定，一般可以各准备200条左右，用于调试 prompt 和测试 prompt 的合理性。数据最好贴合目标场景，但一般从已有数据中较难获取，如果没有合适的数据的话，就需要业务方人造数据。

研发调试完成后使用测试集跑出数据，初期需要业务方或产品对数据进行标注，一起建立问题分类的标准，并确定每一类问题的优先级，然后按优先级来解决问题。

AI 项目在调试过程中，最好每天或者每两天通过晨会来同步前一天的进展以及遇到的问题，明确接下来要做的事项。等测试集达到准出标准后，可以认为调试阶段基本完成。

当然，在这个过程中，POC失败也是件正常的事情，可能模型的能力还没达到要求，一直调试不到准出指标，这种情况下要及时止损，等基座模型有了明显迭代之后，再重启项目。

大测试集评测

小测试集评测达到准出标准后，说明 prompt 已初步可用，这时候需要在更大的范围内评测，即用大测试集进行评测。大测试集标注如果需要业务经验的话需要业务方来标注，如果不太需要业务经验或者经验比较容易传授，可以通过实习生来标注，当然，标注后需要专业人员抽样看下标注质量。

大测试集标注后，如果依然能达到准出标准，说明在当前的测试范围内已基本可用，接下来就可以进入实现阶段了。

成本与性能

与传统需求仅有单次开发成本，使用成本在用户量大时可忽略不计不同，大模型不是免费的，每次使用都会有使用成本，且不同模型之间的差异不小。因此，在POC阶段，产品经理必须计算Token成本，即一个用户使用一次大概要多少钱，全量之后 ROI 是否合适。

一般POC阶段会用最好的模型，先看技术的上限，如果能达到准出指标后，可以调研下切换成成本低一些但效果略差的模型是否还能达到准出标准，然后决定是否更换便宜的模型。

在性能方面，你需要大模型做的事情越多，大模型的反馈速度就会越慢。耗时长的情况下，用户是否能接受这个等待时间，如果不能接受的话，在交互层面怎么设计可以弱化用户对等待时间的感知，比如流式输出或者在等待过程中与其他流程结合，这些都是要体现到PRD中的部分。

实现阶段

工程开发

这里和传统的需求流程相同，先进行需求评审，然后进行工程侧的开发，这部分不再赘述。

验证泛化能力

在工程开发的同时，AI 方面需要继续验证泛化能力。

因为在POC阶段时，一般只会选择需求的其中一个类别来验证（当然，prompt 最好还是向着通用的方向去做）。大模型在一个类别的范围上达到标准后，在其他的类别中不一定能达到相同的水平，这种情况下需要明确分类，每一类问题都需要单独进行评测。

还是拿 AI 讲题举个例子，每个学科中都会有不同的知识点题型，比如 AI 在计算题上可以讲解，那么在应用题上的讲解是否能达到使用要求还需要验证。

如果泛化能力较好的话，第一类问题跑通后，后面的几类问题的成本就会低很多；如果泛化能力较差，每一类问题就都需要按上面的流程来处理一遍。

需求上线

开发和测试完成之后，需求就可以上线了，上线后需要进行灰度，观察线上用户的使用情况和反馈。

因为开发阶段使用的测试数据往往都是人工造的，或者从其他场景中扒的历史数据，不一定符合目前场景中的真实使用情况，所以上线后这部分需要重点关注，以防偏差过大。

如果没有预期外的问题，且线上的准确率也达标的话，就可以逐步扩量到全量了。

以上，就是关于产品经理做 AI 需求的流程，有什么想法欢迎大家交流。