AI产品经理的起点不是模型，而是定义问题。本文从外卖需求案例出发，拆解从用户问题到产品方案再到模型能力的完整链路，帮你避开“看到需求就画功能，看到AI就做Agent”的常见误区。

首先，在讲知识之前，先让我们看一个外卖的需求案例。

一位上班族每天点外卖。中午11点50分，他还在处理工作，一小时后又要开会。他希望平台增加一个按钮，直接购买上次的外卖。

如果把用户的话直接当成需求，答案似乎很简单：做一个按钮。

但继续追问就会发现，他真正想解决的并不是“平台少了一个按钮”，而是在时间紧张、注意力被工作占用时，不想再花精力挑选午餐。他需要的是用更低的决策成本，快速吃到一顿符合预期的饭。

按钮只是一种方案。平台也可以根据历史偏好推荐三家餐厅，或者为用餐时间、地点都比较固定的人提供周期订餐。方案不同，背后解决的却可能是同一个问题。

这是我入行 AI 产品经理第一周最重要的认识：产品经理不能从功能出发，AI 产品经理也不能从模型出发。

真正需要建立的，是一条从用户问题到产品方案，再到模型能力的完整链路。

一、AI 产品经理的起点不是 AI，而是定义问题

我最初接触 “AI 产品经理” 这个岗位时，很容易把注意力放在后半部分：大模型是什么、Agent 怎么做、模型如何微调。第一周学下来，我才意识到，前面的 “产品经理” 才是所有工作的起点。

产品经理经常被称为用户、业务和研发之间的翻译者。但这里的“翻译”不是把老板的一句话整理成需求文档，再交给设计和开发。真正的翻译至少包括三步：

1. 把模糊想法还原成具体问题
2. 把具体问题转化为多种解决方案
3. 再把方案的价值、成本和风险整理成可以决策的选项。

这也是为什么产品经理的核心能力不是记住多少方法，而是判断：这个问题是否真实，是否值得解决，应该先解决哪一部分。

到了 AI 产品中，还要再增加一层判断：这个问题是否需要 AI，模型当前有没有能力稳定地解决它。

二、用户和场景，决定需求是否真实

讨论需求之前，首先要回答两个问题：用户是谁？他在什么场景下遇到了问题？

“用户” 不能只写成 “年轻人” “上班族” 或 “外卖骑手” 。同一个产品中，使用者、付费者和决策者可能不是同一个人；同一个人在不同生命周期和使用频率下，也会表现出不同需求。

“场景” 也不只是地点,它由人物、时间、空间、情绪、任务和上下文共同构成。还是前面的外卖案例，如果时间从工作日中午变成周末晚上，地点从办公室变成家里，用户可能不再追求最快下单，而会更在意选择丰富、家人偏好和配送体验。

所以，需求发现可以写成一条关系：

什么用户，在什么场景下，遇到了什么问题，产生了什么需求。

竞品分析、用户访谈、实地观察和问卷，都是帮助我们补全这条关系的方法。定性研究更适合解释“为什么出现这个问题”，定量研究则帮助判断“问题出现在哪里、有多普遍”。

课堂中的相机用户访谈和骑手保险案例，也让我意识到，用户未必能准确说出自己的真实需求。骑手说“不懂保险”，背后可能同时包含投保前看不懂权益、保障中不知道状态、出险后不清楚流程与时长。一个笼统反馈，需要放回完整过程，才能拆成可以解决的问题。

三、需求分析，不是把用户的话变成功能

用户会表达功能，产品经理需要诊断问题。

“我要一个再来一单按钮”是功能要求；“我不想思考，希望尽快完成一次满意的午餐决策”才更接近真实需求。退回到真实问题以后，解决方案才会被打开。

这时至少要比较四件事：用户是否愿意使用或付费，公司能否获得合理收益，研发与运营成本是否可控，方案未来是否还有延展空间。

例如，周期订餐适合时间、地点、预算和用餐人数相对固定的场景，却未必适合每天计划都在变化的普通上班族。历史偏好推荐实现成本可能更低，也能更快验证用户是否真的需要“省心点餐”,两种方案没有脱离场景的绝对优劣。

这一步让我重新理解了产品经理的价值：不是为每个问题增加一个功能，而是在多个可行方案中，找到现阶段更值得验证的那个。

四、不是所有问题都需要 AI，更不是都需要 Agent

当解决方案进入 AI 领域，最容易出现的误区是先确定 “做一个 Agent” ，再回头寻找适用场景。

更合理的顺序，仍然是从任务出发，根据人和 AI 的分工选择产品形态。

嵌入式 AI 通常只承担原有流程中的一个局部任务，例如润色一段文字、消除一张图片中的杂物。主要流程仍由用户完成，AI 负责降低某一步的操作成本。

Copilot 强调持续协作，用户决定目标和关键步骤，AI 提供建议、生成中间结果，用户不断选择、修改和确认。

Agent 则接收一个相对完整的目标，自主拆解步骤、选择工具、执行任务并根据结果继续调整。用户从逐步操作转向设定目标、提供权限和监督结果。

这三种形态不是从低级到高级的技术排行榜。自主性越高，往往也意味着更高的调用成本、更长的等待时间，以及错误连续累积的风险。步骤固定、规则清楚、错误代价高的任务，普通功能或预设工作流可能更稳定；路径难以预先写死、需要多步调用工具的开放任务，才更适合 Agent。

这里还要避免一个名词混淆：嵌入式 AI 可以写作 Embedded AI，指 AI 被放进现有产品流程；Embedding 通常指把文字等信息转换成向量表示。两者不是同一个概念。

五、理解大模型，是为了判断能力边界

AI 产品经理不需要把自己训练成算法工程师，但必须理解模型为什么会成功，也为什么会失败。

以常见的自回归大语言模型为例，输入文字会先被切分成 Token，再转换成向量。Transformer 中的注意力机制帮助模型处理不同 Token 之间的关系，MLP 等模块继续转换信息，模型最终得到下一个 Token 的概率分布。生成一个 Token 后，它会把新结果放回上下文，继续预测下一个，直到形成完整回答。

这意味着模型生成的不是数据库中的标准答案，而是在当前上下文下不断进行概率预测。温度、Top K 和 Top P 等参数会影响采样范围与输出随机性，却不能替代知识、数据和评测。

理解这一点以后，Prompt、RAG 和微调也不再是三个孤立名词。

如果问题主要是目标、规则或输出格式不清楚，应该先优化 Prompt；如果模型缺少企业内部资料或需要更新的外部知识，可以考虑 RAG，在生成前检索相关材料；如果需要模型长期稳定地学习特定行为、任务模式或表达格式，才进一步评估微调及其数据成本。

SFT、PEFT 和 LoRA 也不在同一层级。SFT 是监督微调方法，通过输入与目标输出样本训练模型；PEFT 是参数高效微调思路，只更新少量参数；LoRA 则是常见的 PEFT 技术之一。实际训练时，可以用 LoRA 这样的 PEFT 方法来完成一次 SFT。

对产品经理而言，技术知识最终要回到几个现实问题：效果能否评测，延迟能否接受，成本能否持续，数据从哪里来，错误发生后由谁发现和纠正。

六、把知识点串成四次产品判断

第一周结束后，我没有因为记住更多名词就立刻变成一名成熟的 AI 产品经理。但我开始把原本分散的知识放进同一条链路，并形成四次判断：

1. 谁在什么场景下遇到了问题？
2. 用户提出的功能背后，真实需求是什么？
3. 普通产品方案能不能解决，是否真的需要 AI？
4. 如果需要 AI，应该选择怎样的人机分工、模型能力和验证方式？

这四个问题还不是完整的产品方法论，却能避免一个新人最容易犯的错误：看到需求就画功能，看到 AI 就做 Agent，看到效果不好就急着微调。

用户、需求和大模型并不是三套彼此独立的知识。

用户和场景帮助我们找到问题，需求分析帮助我们选择方向，模型知识帮助我们判断方案边界。

把它们串起来，才是我真正开始理解 AI 产品经理这份工作的时刻。