从需求到原型：如何验证 AI 产品想法

一、验证的目标不是"做出来"

一个 AI 想法进入开发前，最贵的错误是把它直接排进 roadmap。八个月后上线，用户说"不是我想要的"——这时才发现，最初的需求描述里根本没有包含"什么情况下这个功能算成功"。

原型阶段的任务不是把功能做出来，是把"成功长什么样"变成一个能当场判断的东西。

二、动手前：把想法写成三个可证伪的命题

行为命题： 目标用户现在正在用某种笨办法做这件事。答不上来"笨办法是什么"，说明需求可能是想象的。

输入命题： 这件事需要的材料，以客户现有的形式就能拿到。需要用户"以后按这个格式填"的需求，落地时会死在执行力上。

验收命题： 产出结果后，一线人员能判断对错。判断标准说不清的项目（"感觉不准"），后续所有调优都没有方向。

三个命题有一个写不出来，先别写代码，回去聊用户。

三、动手时：原型只走一条路径

选最高频的那一个场景，端到端跑通，其他分支全部返回"暂不支持"。原型阶段加功能不是谨慎，是稀释——每个功能都半成品，等于没有任何功能被验证过。

两条纪律：用真实数据（哪怕是脱敏的一小批），演示数据和真实数据的差距就是原型和产品的差距；记录失败，模型答错的每一个 case 都存下来，它们是下一阶段调优的全部依据，比成功样本值钱。

四、动手后：一次汇报定去留

原型做出来，拿给三类人看：提需求的（问"这是你要的吗"）、一线用的（问"你会用它吗，为什么不用"）、拍板给钱的（问"看到什么才愿意付钱"）。

三种回答的交集就是下一阶段的范围。三种回答互相矛盾——提需求的人说好看、用的人说不用、给钱的人问 ROI——这是最常见的状态，也是原型最值钱的发现：它用两周暴露了需求传导链的断裂，而不是用八个月。

五、验证通过的信号

不是"大家都说好"，而是一个具体行为：有人开始问"什么时候能在我这里用起来"，并且能说出他要接哪个流程、用什么数据。从这一刻起，才值得谈完整开发的报价。

撰稿：邓湘雷