AI Product Growth 101｜02｜Evidence Prototype：原型不是缩小版产品
传统软件原型经常用来验证交互。
按钮放在哪里，流程是否顺畅，用户能不能理解页面。
AI 原型还要多验证一件事：这项能力在真实输入下，到底能不能稳定完成任务。
这让 AI 原型很容易走向两个极端。
一种只有漂亮界面，背后是精心挑选的输入。另一种只有 Notebook，证明模型偶尔能给出惊艳结果，却没有人知道怎样把它放进工作流。
两种都能 Demo。两种都不等于产品证据。
人机交互研究里有一个老方法叫 Wizard of Oz：用户以为自己在使用自动系统，幕后其实有人完成关键步骤。它的价值从来不是伪装技术已经成熟，而是让团队在投入完整工程成本前，看见用户会怎么说、系统应该在什么时候介入、哪些错误会破坏信任。Microsoft Research 后来提出 participatory prompting，把研究者和用户共同调试提示的过程也变成研究材料。对 AI 产品来说，幕后那个人不是临时客服，而是一支活的探针。
原型要回答三个问题
能力证据
模型在真实输入分布下，能否达到最低可用标准？
不要只测试五个理想样本。至少要覆盖常见任务、边界任务、脏数据、信息缺失和高风险案例。
重点不是算出一个漂亮的平均分，而是找到失败模式。
它什么时候会漏掉关键事实？什么时候过度自信？什么时候需要更多上下文？什么时候应该拒绝回答？
行为证据
用户是否愿意改变原有做法？
“这个 Demo 很酷”不是行为证据。
愿意上传真实材料、在下一次任务中再次使用、把结果发给同事，或者允许系统接入工作账号，才更接近行为证据。
用户的投入往往比口头反馈更诚实。
价值证据
结果有没有进入真实工作流？
一份 AI 生成的报告如果被完整重写，生成成功也没有产生多少价值。
如果用户只改了两个字段就提交，价值就清楚得多。
原型阶段应该记录结果是否被接受、修改了多少、节省了什么，以及用户是否愿意为下一次使用付出成本。
三层原型
可以把早期验证分成三层。
Layer 1：离线任务集
先收集 20 到 50 个真实案例，去除敏感信息，建立最小评估集。
每个案例至少包含：输入、期望结果、不可接受错误和判断理由。
这一层用来快速试模型、提示词、上下文结构和输出格式。
它回答“能不能做”。
Layer 2：人工幕后服务
让用户提交真实任务，团队在幕后组合模型、工具和人工检查，再交付结果。
不要急着把所有步骤自动化。
手工流程能帮你看见真正困难的部分：上下文缺在哪里，用户怎样描述任务，哪些判断必须由人完成，哪些异常最常出现。
这一层回答“怎样做才有用”。
Layer 3：工作流内原型
把最小能力放到用户本来工作的地方。
可能是浏览器扩展、Slack 命令、IDE 面板、CRM 按钮，或者文档侧栏。
此时才测试触发时机、确认方式、失败恢复和结果回写。
这一层回答“用户会不会持续用”。
不要过早自动化异常
团队看到人工步骤，第一反应通常是把它消灭。
但原型阶段的人工处理，是学习装置。
如果团队每次都要补充同一种上下文，说明产品需要新的输入机制。
如果团队总在检查同一类错误，说明那里需要确定性规则或专门评估。
如果团队经常不知道结果是否正确，说明这个任务的可验证性可能比预期更差。
过早自动化，会把这些信号藏起来。
记录一条任务账本
每次原型运行，至少记录这些字段：
- 用户原本想完成什么。
- 输入是否完整。
- 模型和工具做了哪些步骤。
- 哪一步需要人工介入。
- 用户是否接受结果。
- 用户修改了什么。
- 总耗时和推理成本。
- 用户是否再次使用。
这份账本比一组宽泛的访谈笔记更有价值。
它会变成后续评估集、产品需求、异常设计和定价模型的共同来源。
一个停止规则
原型不应该无限做下去。
进入产品化之前，可以设一个简单门槛：
- 核心任务在目标案例中大部分可完成。
- 严重错误有明确识别和回退方式。
- 一小批用户主动重复使用。
- 结果有可观察的接受行为。
- 单次有效结果的成本存在合理下降路径。
如果这些条件长期不成立，继续美化界面通常没有意义。
你需要缩小任务、补充上下文，或者换一个切口。
小结
AI 原型不是缩小版产品，也不是路演素材。
它是一台制造证据的机器。
最好的原型会让团队更早看见三件事：能力在哪里失效，用户什么时候愿意委托，什么结果真的进入工作流。
下一篇，我们把这些证据接进开发过程，建立一条适合概率系统的产品迭代闭环。