AI 产品：从“模型能力”到“用户价值”的最后一公里

一、引子：Demo 很惊艳，上线却翻车

几乎每个做过 AI 产品的团队都经历过同一个场景：内部演示时，模型回答得漂亮、生成得流畅，老板鼓掌，立项通过。三个月后产品上线，真实用户的第一批反馈却是——“它有时候胡说八道”“同样的问题两次答案不一样”“一到高峰期就转圈”“用了几次就不想用了”。

这不是模型不够强的问题。今天的大模型在绝大多数基准测试上都远超三年前，但模型能力不等于产品价值。中间隔着的这条“最后一公里”，恰恰是 AI 产品经理存在的意义。

传统软件产品的核心挑战是“把确定性的逻辑做对”；AI 产品的核心挑战是“在不确定的输出上，构建可信赖的用户体验”。这两件事的方法论几乎完全不同。本文想聊的，就是这条最后一公里上真正重要的东西。

二、AI 产品与传统软件产品的四个结构性差异

理解差异，才能理解为什么很多传统产品方法论在 AI 产品上会失灵。

1. 输出是概率分布，不是确定值。 传统产品：输入 A 必然得到 B，测试通过即上线。AI 产品：输入 A，输出是一个分布，可能 90% 的情况下是 B，8% 是 C，2% 是离谱的 D。你无法“证明”它永远对，只能度量它有多大概率对、错的时候错得多离谱。

2. 成本随用量线性增长，而且不便宜。 传统 SaaS 的边际成本接近于零，用户越多越赚钱。AI 产品的每一次调用都在烧 token、烧 GPU，毛利率可能随规模下降。这让“免费试用”“无限量套餐”这类传统增长手段变得非常危险。

3. 质量不是一个数字，而是一组权衡。 准确率、延迟、成本、覆盖率、安全性——它们互相拉扯。把准确率从 85% 提到 92%，可能需要三倍成本和两倍延迟。AI 产品经理的核心工作之一，就是在这组权衡里找到业务可接受的那个点，而不是盲目追求最高分。

4. 数据飞轮决定长期壁垒。 模型是公共基础设施，谁都能调用。真正的护城河来自：你的场景数据、用户反馈、评估集、以及围绕业务打磨的 prompt/工作流/工具链。没有数据回流设计的 AI 产品，本质上是在给模型厂商打工。

三、先问一个问题：这里真的需要 AI 吗

这是 AI 产品立项时最该问、却最常被跳过的问题。技术团队有热情、老板有期待，于是很多“AI 产品”最后变成了“用大模型包装的 if-else”。

一个务实的判断框架：当任务满足“输入非结构化 + 输出需要理解或生成 + 容错空间存在”三条时，AI 才真正有优势。

• 发票金额求和：规则引擎更快更准，不要用 AI。
• 客服工单分类：标签体系固定、样本充足，传统分类模型成本更低。
• 从合同里抽取关键条款并生成风险摘要：AI 明显更优。
• 帮用户把一段口语化需求改写成结构化查询：AI 明显更优。

按产品形态，AI 产品大致可分四类，难度与风险递增：

建议从低风险形态切入，用真实反馈验证价值，再逐步向高风险形态扩展。反过来做，往往一次事故就把信任透支光了。

四、设计原则：为“会犯错”的系统做产品

这是 AI 产品设计最反直觉的地方——你不能假设它总是对的，而要设计一个在它犯错时仍然可用的产品。

1. 失败要优雅。 模型不确定时，应该输出“我不确定，建议你查证 X”而不是编一个自信的答案。产品层面要有“置信度提示”“引用来源”“一键反馈”。宁可少答，不可乱答。

2. 人机协同是长期形态，不是过渡态。 在医疗、金融、法律、运维这些高 stakes 场景，“AI 建议 + 人确认”会长期存在。产品设计要把人的审核成本算进去，而不是假设人只是点个“同意”。

3. 渐进式信任。 新用户不该一上来就被要求信任 AI 的自动操作。合理路径是：先展示建议 → 用户确认执行 → 逐步放开高频低风险动作的自动化。这和企业里给新人授权的逻辑一模一样。

4. 让不确定性可见。 同一句话在 UI 上的呈现方式影响巨大。“根据 3 份文档，答案可能是……”比一句斩钉截铁的断言更诚实，也更能建立长期信任。

5. 控制面要留给用户。 语气、长度、是否联网、用哪个知识库——把可控项暴露出来，用户对结果的接受度会显著提高。

五、技术侧：三个真正影响产品质量的工程点

AI 产品的技术栈里，模型选型往往不是最关键的。真正决定体验的，通常是下面三件事。

5.1 结构化输出 + 校验重试

下游系统要的是 JSON，模型却总爱多说一句“好的，以下是结果”。工程上必须做约束解码 + 解析校验 + 失败重试。

import json

def call_llm_json(client, prompt, schema_keys, retries=2):
    for attempt in range(retries + 1):
        raw = client.chat(prompt, temperature=0)  # 低温更稳定
        try:
            data = json.loads(raw.strip().strip("`").removeprefix("json"))
            if all(k in data for k in schema_keys):
                return data
        except json.JSONDecodeError:
            prompt += "\n\n注意：只输出合法 JSON，不要任何解释文字。"
    return None  # 明确失败，交给上层降级处理

这段代码的重点不是技巧，而是“明确失败并降级”这个设计：返回 None 让产品层可以展示兜底话术，而不是把脏数据塞进数据库。

5.2 RAG 的质量瓶颈在检索，不在生成

很多团队做 RAG，80% 的精力花在调 prompt，结果幻觉依旧。经验是：召回不对，生成再强也没用。优先投入的是切分策略、元数据过滤、混合检索（向量 + 关键词）和重排序。

def hybrid_retrieve(query, vector_store, bm25, top_k=5):
    vec_hits = vector_store.search(query, k=top_k * 2)
    kw_hits  = bm25.search(query, k=top_k * 2)
    # 简单融合：RRF（倒数排名融合），无需调权重
    scores = {}
    for rank, doc in enumerate(vec_hits): scores[doc.id] = scores.get(doc.id, 0) + 1/(60+rank)
    for rank, doc in enumerate(kw_hits):  scores[doc.id] = scores.get(doc.id, 0) + 1/(60+rank)
    return sorted(scores, key=scores.get, reverse=True)[:top_k]

RRF 的好处是不需要为两路检索调权重，冷启动就能用，是性价比极高的一招。

5.3 评估集：AI 产品最重要的“新基建”

传统软件有单元测试，AI 产品的对应物是评估集（Eval Set）。没有它，任何 prompt 改动、模型升级、检索策略调整都是“凭感觉”。

一个好的评估集应该包含：真实用户 query 抽样、边界与对抗样本、历史 badcase 回归、以及每条样本的评分标准（规则判定 / 模型判定 / 人工标注分层使用）。

def run_eval(pipeline, eval_set, judge):
    results = []
    for case in eval_set:
        out = pipeline(case["input"])
        ok = judge(case, out)          # 规则 or LLM-as-judge
        results.append({"id": case["id"], "pass": ok, "out": out})
    pass_rate = sum(r["pass"] for r in results) / len(results)
    return pass_rate, [r for r in results if not r["pass"]]  # 返回 badcase 供复盘

关键纪律：评估集要版本化，上线门槛要量化。比如“核心场景通过率不低于 90%，且历史 badcase 回归不得退化”。这一条纪律，比任何 prompt 技巧都更能保证产品质量不塌方。

六、单位经济学：AI 产品经理必须会算的账

很多 AI 产品死于“用得起模型，养不起用户”。上线前必须算清三个数：

• 单次调用成本 = 输入 token × 单价 + 输出 token × 单价（注意输出通常更贵）
• 单用户月成本 = 单次成本 × 人均调用次数 × 缓存命中后的修正系数
• 毛利 = 客单价 − 单用户月成本 − 基础设施分摊

对应的产品手段也很明确：缓存高频请求、按场景选小模型、限制上下文长度、对重度用户做分级定价。这些都是产品决策，不是纯技术决策。

七、落地路线图与常见坑

推荐节奏（3–6 个月一个闭环）：

1. 第 1 月：锁定单一高价值场景，定义成功指标（如“人工处理时长下降 30%”），而不是“准确率提升”。
2. 第 2 月：搭建最小可用链路 + 评估集 + 反馈入口。评估集先于功能开发。
3. 第 3 月：小范围灰度，收集 badcase，迭代检索与 prompt。
4. 第 4 月起：扩量，建立模型/成本监控，规划数据飞轮（用户反馈如何回流）。

几个必须警惕的坑：

• 用 demo 效果做立项依据：demo 是精心挑选的样本，上线面对的是长尾。立项前先跑一遍真实数据。
• 没有评估集就迭代 prompt：改一处、坏三处，永远不知道是进步还是退步。
• 把 LLM 用在确定性任务上：该用规则的地方用规则，AI 不是万金油。
• 忽视延迟与成本：用户对 8 秒以上的等待容忍度极低，成本失控会直接杀死商业模式。
• 没有数据回流：上线即终点，产品永远不会变好。
• 安全与合规后置：提示注入、数据泄露、版权风险，必须在架构阶段就考虑，而不是出事后补丁。

八、结语：AI 产品经理的新基本功

AI 产品没有改变产品经理的本质——理解用户、定义价值、做取舍。但它确实新增了几项硬功夫：

会写评估集，会读失败样本，会算单位成本，会设计人机协同的边界。

这四项能力，比“会不会调 prompt”重要得多。因为模型会一直变强、变便宜，今天的最佳实践半年后可能就过时；但“用数据度量质量、用设计管理不确定性、用经济学约束方案”这套方法，会长期有效。

最后一句话送给正在做 AI 产品的同行：用户不关心你用了什么模型，只关心这件事它能不能可靠地帮我办成。把这句话刻在立项文档的第一行，能避开一半的坑。