AI 产品：当"确定性交付"变成"概率性经营"

一、AI 产品的四个本质差异

在动手设计之前，先把差异想清楚，后面所有决策都由此推导。

第一，输出是概率性的。 传统产品"点击→结果"是确定的；AI 产品的同一次输入可能得到不同输出，且可能出错。产品设计的起点不是"如何让它对"，而是"它错了之后用户怎么办"。

第二，能力边界是流动的。 换一个模型版本、改一段提示词、加一个检索源，能力边界就可能整体位移。产品经理必须接受：产品的能力定义是版本化的、需要持续维护的，而不是一劳永逸写在 PRD 里的。

第三，成本随使用线性增长。 传统软件边际成本趋近于零，AI 产品每次调用都在花钱。这意味着定价、限额、缓存、路由都是产品设计的一部分，而不是工程细节。

第四，错误形态不可穷举。 传统产品的 bug 可以列清单；AI 产品的失败是长尾的、场景化的，只能靠评估集抽样逼近，无法靠穷举覆盖。

这四点决定了：AI 产品必须"以评估为中心"来开发，而不是"以功能为中心"。

二、产品定义：先写清楚"它做不到什么"

传统 PRD 的重点是功能清单。AI 产品的 PRD 里，最有价值的一节往往是能力边界与失败模式。

具体要回答四个问题：

• 任务定义：用户到底要完成什么任务？输入是什么、输出是什么、成功的判定标准是什么？
• 能力边界：在哪些输入下它能稳定工作，哪些输入下会失败？失败时输出长什么样？
• 失败代价：错了会怎样？是用户多看一眼就能发现，还是会造成真实损失？
• 兜底设计：失败时产品如何接住？转人工、降级到规则、明确拒答，还是提示用户复核？

一个实用的做法是把任务按"失败代价 × 发生频率"画成四象限：高代价高频率的场景先做人工复核闭环，低代价高频的场景可以做全自动，高代价低频的要设置强约束和二次确认，低代价低频的可以暂时不做。

能明确说出"我们不做什么"，比列出二十条功能更能体现产品成熟度。

三、评估驱动开发：把"感觉变好了"变成"数据变好了"

这是 AI 产品方法论的枢纽。传统产品靠 AB 测试验证功能，AI 产品在 AB 之前必须先有离线评估，否则线上实验成本高、周期长、结论噪声大。

评估体系要解决三件事：评什么、怎么评、什么时候不许上线。

评什么：从真实业务场景抽样构造评估集，覆盖典型场景、边缘场景和已知失败案例。评估集是产品资产，应当版本化管理，每次模型或提示词变更都跑一遍。

怎么评：能用客观判定的用客观判定（结构化输出比对、关键字段命中）；主观质量用评分量表加人工抽检；大规模场景可用更强模型做裁判，但必须定期人工校准裁判的可靠性。

什么时候不许上线：把评估阈值写成发布门禁，让它成为流程里的一道硬约束。

# product-gate.yaml —— 每个 AI 功能都必须有一份
feature: contract-clause-extraction
eval_dataset: evals/clause/v4.jsonl
gates:
  field_accuracy:  >= 0.92      # 关键字段抽取准确率
  hallucination_rate: <= 0.02   # 编造条款比例
  p95_latency_ms: <= 2500
  cost_per_call_usd: <= 0.004
on_fail: block_release

这份配置的价值不在 YAML，而在于它强迫产品团队在开发早期就回答："什么叫做好了？"——这个问题在传统产品里可以拖到验收，在 AI 产品里拖不得。

配套的还有一条纪律：评估集只增不减，失败案例自动回灌。每次线上出现新类型的错误，就把它补进评估集，让同类问题不再复发。这是 AI 产品唯一的"防回归"手段。

四、体验设计：为不确定性而设计

AI 产品的体验设计，核心不是"让 AI 显得聪明"，而是让用户在不确定中保持掌控感。几条经过验证的原则：

1. 渐进式自动化。 不要一上来就全自动。先做"建议—用户确认"，再逐步放开到"自动执行—用户可撤销"。用户对自动化的信任是赚来的，不是宣称的。

2. 可编辑、可追溯。 输出结果要允许用户直接修改；涉及事实性内容要给出引用来源；涉及多步推理的要展示过程摘要。用户不需要看懂模型，但需要知道"该不该信"。

3. 失败要体面。 模型不确定时应明确表达不确定，而不是硬编一个答案。一句"这个问题我把握不大，建议核实"远比一个自信的错误答案有价值。

4. 人在回路要有明确位置。 高风险环节必须设计人工审核节点，并且要让审核者的工作尽可能轻——AI 负责初稿，人负责判断，而不是让人从头重做。

5. 控制交互成本。 AI 产品很容易让用户陷入"反复追问"的泥潭。要设计好澄清机制：一次问清关键信息，而不是来回拉扯。

一句话总结：好的 AI 产品让用户感觉"我在用工具"，而不是"我在赌运气"。

五、数据飞轮：产品越用越好的机制

AI 产品的长期竞争力不在模型，而在数据闭环。飞轮的基本结构是：使用产生数据 → 数据转化为评估样本与优化信号 → 优化提升效果 → 效果带来更多使用。

设计飞轮时要回答三个问题：

• 什么数据值得收集：不是全量日志，而是"输入—输出—用户行为—最终结果"这条链路。尤其是用户的修改、拒绝、采纳行为，信息量远大于点击。
• 如何低成本标注：用户修改本身就是隐式标注；抽样人工复核补充高质量标签；建立标注规范保证一致性。
• 如何回到产品：新样本进评估集、典型失败进提示词优化、高频场景进微调或规则库。

飞轮最怕的是"收集了但没用起来"。产品团队需要定期做失败案例复盘会，把线上错误按类型归档，并明确每一类由谁、在什么时间窗口内处理。

六、成本与延迟：产品的一等公民

传统产品经理很少关心服务器成本，AI 产品经理必须关心。原因很简单：单位经济模型不成立的产品，规模越大亏得越多。

产品层面常用的控制手段：

• 模型路由：简单任务走小模型，复杂任务才升级到大模型，按任务难度分层。
• 缓存：高频相同或相似请求命中缓存，显著降低成本与延迟。
• 上下文管理：控制检索范围和对话历史长度，避免"什么都塞进去"。
• 异步与流式：长任务异步化，交互场景用流式输出改善感知延迟。
• 限额与配额：按套餐设置调用额度，避免单用户拖垮整体成本。

这些手段应当在产品设计阶段就纳入方案，而不是等成本报表出来再补救。

七、度量体系：从"活跃"到"任务完成"

传统 SaaS 看 DAU、留存、付费转化。AI 产品需要在此基础上增加一层任务层指标，因为"用户来了"不等于"用户把事办成了"。

建议分三层度量：

其中人工接管率和一次通过率是最容易被忽视、却最能反映真实价值的两个指标。一个"看起来很智能"但用户每次都要大改的产品，本质上没有创造价值。

八、上线策略：影子模式与灰度

AI 产品的上线风险远高于传统产品，建议采用三步走：

第一步，影子模式。 新功能在后台运行、不影响用户，把输出与人工结果对比，验证真实分布下的效果。这是最安全的能力验证方式。

第二步，灰度放量。 按用户或流量比例逐步放开，同时监控任务完成率、接管率、投诉率等指标，设置自动回滚阈值。

第三步，全量与监控。 全量后仍需持续监控质量漂移——数据分布会变，模型供应商也会更新模型，效果可能悄悄下降。

配套要有版本可回滚：提示词、模型版本、检索索引都应版本化，出问题能一键切回上一版。

九、商业化：从"卖席位"到"卖结果"

AI 产品的定价是产品设计的一部分，常见几种模式各有适用场景：

• 按席位订阅：适合使用频率稳定、价值与人数相关的场景，收入可预测，但可能与实际用量脱节。
• 按用量计费：按 token、调用次数或任务数计费，成本传导清晰，但用户难以预估支出。
• 按结果计费：按成功处理的任务、节省的工时或创造的价值分成，价值对齐最强，但计量与归因复杂。
• 混合模式：基础订阅 + 超额用量，兼顾可预测性与弹性。

选择的关键是价值归因是否清晰。如果产品效果能被客户明确量化（如自动处理了多少张单据），按结果计费更容易被接受；如果价值是间接的、长期的，按席位订阅更现实。

无论哪种模式，都要保证单位经济模型为正：单任务收入 > 单任务推理成本 + 人工复核成本 + 分摊的研发成本。

十、组织协作：产品经理的新位置

AI 产品团队通常是产品、算法、工程、数据标注、领域专家多方协作。产品经理的角色从"需求传递者"变成"问题定义者与评估标准的守护者"。

几个协作要点：

• 和算法对齐"任务"而非"模型"：讨论的应该是任务定义、评估集、失败模式，而不是"用哪个模型"。
• 和工程对齐"成本与延迟预算"：把 SLO 写进需求，而不是上线后再优化。
• 和领域专家共建评估集：没有业务专家参与的评估集，往往测不出真实问题。
• 和标注团队共建规范：标注标准不一致，评估结果就不可信。

产品经理最不可替代的能力，是把一个模糊的业务诉求翻译成可评估、可交付、可度量的任务定义。这件事没人能替。

十一、常见陷阱

• 用 Demo 验收：挑几个好例子演示通过就上线，真实分布下立刻崩盘。
• 没有评估集：无法判断改动的效果，团队陷入"感觉派"争论。
• 追求全能：一个助手什么都能干，结果什么都不精。
• 忽视失败代价：在低风险场景验证的方法直接搬到高风险场景。
• 成本后置：上线后才发现单位经济模型为负。
• 不做人工兜底：模型失败时用户无路可走，直接流失。
• 把模型升级当产品迭代：换更强的模型不等于产品变好，评估集没变就不知道是否真的提升。

十二、小结

AI 产品的方法论可以浓缩成一句话：用评估定义能力，用体验承接不确定性，用飞轮积累优势，用成本守住生意。

模型是燃料，产品是发动机。燃料越强，发动机的设计就越重要——因为能力越强，用户期待越高，失败代价越大，产品经理越不能把"模型能做什么"直接等同于"产品该做什么"。

真正稀缺的从来不是调用模型的能力，而是把概率性能力包装成可信赖产品的能力。这件事，仍然要靠产品人来完成。