做一个 AI 产品，从第一天开始要想清楚哪些事？

行业洞察 · AI 落地实战

很多人问过我一个问题：AI 产品经理和普通产品经理，工作上到底有什么不一样？

我的答案是：工具变了，流程变了，但最核心的那件事没变——在动手之前，把"我们要解决的是什么问题"这件事想清楚。

只是在 AI 产品里，这件事比以前更难，也更重要。

这篇文章想聊的，是我在实际做 AI 产品落地时，从第一天开始会考虑哪些问题、踩过哪些坑，以及我认为在前期规划阶段最值得提前想清楚的几件事。

先说一件很多人没意识到的事：AI 产品的工作流变了

在做传统产品的时候，PM 的工作流大致是这样的：调研需求 → 写 PRD → 评审 → 开发 → 测试 → 上线。

这个流程在 AI 产品里依然存在，但中间多了几个以前完全不需要考虑的环节：

第一，Prompt 设计变成了产品工作的一部分。

以前 PRD 里写的是功能逻辑和交互规范，现在还需要写清楚：这个功能调用大模型时，System Prompt 是什么、约束条件是什么、输出格式要求是什么。这不是工程师的工作，是产品经理的工作。一个写得模糊的 Prompt，会让模型的输出变得不可控，这个锅最后还是得 PM 来背。

第二，评测体系需要从第一天开始建。

传统软件测试的逻辑是：功能对不对、有没有 bug。但 AI 产品的测试逻辑完全不同——你需要建立一套评测集，持续评估模型输出的质量。这个评测集不是上线前才建，而是在产品设计阶段就要开始规划：什么叫"好的输出"，什么叫"不可接受的输出"，边界在哪里。

没有评测体系，你就没有办法客观判断产品有没有在变好，也没有办法和算法团队说清楚"这里有问题"。

第三，Bad Case 分析成了日常工作。

大模型出错的方式和传统软件完全不同——它不是"功能坏了"，而是"输出偏了"。PM 需要持续收集用户反馈里那些"AI 说错了"的案例，分析它错在哪里、为什么错、是 Prompt 的问题、数据的问题还是模型本身的问题，然后推动修正。

这个工作在传统产品里几乎不存在，在 AI 产品里是周期性的标配。

规划一个 AI Agent 产品，前期要踩过哪些坑

说完工作流的变化，再说说我在实际做 AI Agent 产品落地时，观察到的最常见的几类前期规划坑——有些是我自己踩过的，有些是我看着别人踩的。

坑一：场景选错了，做了一个没有真实需求的 Agent。

这是最致命的坑，也是最常见的坑。

很多团队做 Agent 的出发点是"我们有大模型能力，来找一个场景用一下"。这个逻辑听起来合理，但实际上是反的——正确的出发点应该是"业务里有一个效率很低、重复度很高、规则比较模糊的环节，我们来判断 AI 在这里能不能帮上忙"。

我自己在规划产品时有一个判断框架：这个任务，是不是重复度高、需要理解语义、又不需要 100% 准确率？ 满足这三个条件的场景，才是 AI 真正能发挥价值的地方。反过来，如果一个任务需要强确定性、强实时性、或者容错率为零，大模型介入大概率会制造麻烦而不是解决麻烦。

坑二：把 Agent 做成了"什么都能做"的通用助手。

我见过很多团队，做出来的 Agent 宣传页上写着"智能助手，覆盖全业务场景"。但实际用起来，用户发现它什么都能回答，但什么都答得不够准。

Agent 的核心价值在于对特定场景的深度适配。一个专门处理数据查询的 Agent，和一个"什么都能问"的通用对话框，用户体验是完全不同量级的。前者让用户觉得"这个东西真的懂我的业务"，后者让用户觉得"这不就是一个贵一点的搜索框吗"。

不存在"万能的最好 Agent"，只有"最适合特定场景的 Agent"。这句话我高度认同，也是我在做产品规划时会反复拿出来对齐的一个判断。

坑三：数据问题被低估了。

Agent 产品的质量，在很大程度上取决于它能访问的数据质量。

有调研数据显示，70% 的企业数据质量无法支撑 AI Agent 的训练需求。这不是危言耸听——我在实际项目里经常遇到这样的情况：数据库里的字段命名不规范、同一个指标在不同表里有不同的口径、历史数据里有大量脏数据。这些问题如果在规划阶段没有被识别和处理，等到产品上线之后，Agent 给出的答案会让用户觉得"它根本不懂我们的业务"。

前期规划的时候，数据梳理和数据清洗的工作量，一定要比你预期的更多、更重要。

坑四：没有考虑"出错之后怎么办"。

这个我之前专门写过——AI 产品的幻觉问题不可能被完全消灭，所以在规划阶段就需要想清楚：当模型给出一个错误答案时，产品层面有没有机制能拦截它、提示用户、或者让用户可以纠正它？

如果在规划阶段没有给"出错路径"留空间，等到真的出问题了，补救的代价会比一开始就设计好大得多。

坑五：忽视了"员工接受度"这个变量。

这个坑在 B 端尤其明显。

很多 AI 产品失败不是因为技术不行，而是因为使用它的人不接受它。HR 担心 AI 面试官会抢走自己的工作，数据分析师觉得让业务部门直接问数是在削弱自己的话语权，客服团队不信任 AI 给出的答案……

这些阻力是真实存在的，在产品规划阶段就需要被纳入考虑：如何设计产品让它看起来是"辅助工具"而不是"替代威胁"，如何让用户在使用过程中建立对 AI 输出的信任感，是一个产品问题，不只是一个沟通问题。

我自己在前期规划时会做的几件事

最后说几个我自己在启动一个 AI 产品项目时会做的具体动作：

第一件事：把业务流程画出来，找断点。

不是先想"哪里可以加 AI"，而是先把现有的业务流程完整梳理一遍，找出哪些环节是效率瓶颈、哪些是人工最累的地方、哪些是最容易出错的节点。断点找到了，再判断 AI 在这里能不能帮上忙。

第二件事：在设计阶段就把"失败路径"写进 PRD。

正常流程怎么走、模型输出置信度低的时候怎么处理、用户发现答案不对的时候可以怎么操作——这三条路径，在 PRD 里都需要有明确的设计，不能只写 Happy Path。

第三件事：先做一个小闭环，验证可行性再扩大范围。

不要一上来就规划一个覆盖全部业务场景的大系统。先选一个最高频、最痛、最容易量化效果的场景，把它做通，验证技术可行性和用户接受度，再考虑扩大。

这不是保守，是降低风险最有效的方式。我见过太多团队在第一个版本就铺了十几个功能，结果每个都做得不深，用户哪个都不满意，最后项目烂尾。

做 AI 产品，和做任何产品一样——最怕的不是技术难题，而是在错误的方向上走得很快。

前期把问题想清楚，后期省的时间是十倍。