AI 产品落地，不是给现有流程加一个聊天框

很多 AI 项目的起点都是一句“我们也想做一个智能助手”。这句话提供了技术方向，却没有定义产品问题。模型会回答，不代表用户愿意用；Demo 能跑，也不代表产品能上线。

先定义用户任务

我更习惯先把“想要 AI”翻译成具体任务：谁在什么场景下，需要处理什么输入，最后要得到什么可执行结果？

在政务场景里，群众需要的不是一段听起来合理的政策解释，而是办事条件、所需材料、办理位置和可信来源。窗口人员还需要权限内的知识、内容审核与人工接管。两者看似都在“问答”，产品边界却完全不同。

任务定义清楚后，模型、知识库、工具调用和人工流程才有各自的位置。

把不可控变成流程

生成式能力天然有波动。产品经理不能用一句 Prompt 承担全部可靠性，而需要把风险拆到流程里：

• 检索结果是否覆盖关键事实；
• 回答中的论断能否回到原始来源；
• 低置信度问题何时拒答或转人工；
• 失败后是否能重试、恢复并保留上下文；
• 知识、Prompt 与模型变更如何回归验证。

我在 RAG 和 DeepResearch 项目中，把引用门禁、Golden Dataset、Bad Case 复盘和质量评分做成产品机制，就是为了让质量不只依赖某次运气好的生成。

用指标验证价值

AI 产品的指标至少分三层：

1. 能力层：召回率、忠实度、工具调用成功率、响应时延；
2. 任务层：任务完成率、人工接管率、一次解决率、用户采纳率；
3. 业务层：处理周期、运营成本、转化率、收入或风险降低。

只看模型准确率，容易得到一个技术上漂亮、业务上没人使用的产品。只看短期转化，又可能用不可持续的算力和人工成本换来表面增长。

产品经理的价值，是在用户体验、工程约束与业务结果之间建立一套可以被验证的判断。AI 是新的能力，但把复杂问题做成可靠产品的方法，仍然从理解用户任务开始。