> For the complete documentation index, see [llms.txt](https://book.likun.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://book.likun.ai/00-intro/02-mo-xing-ji-chan-pin.md). # 2. 模型即产品：当模型能力就是产品能力，PM 的角色在哪 > 传统 PM 的核心工作是定义需求、设计交互、推动交付。AI 时代，这个角色的边界正在重新划定。 *** 如果说上一节探讨了生成式 AI 在人类信息史中的宏观坐标，那么本节将视角拉近至更具体的层面：这场变革究竟如何重塑企业的产品逻辑，以及产品经理这一角色的核心职能？ 当模型的推理水平、知识密度与工具调用能力可以直接等同于产品的核心用户体验时，\*\*「模型能力即产品能力」\*\*便不再是一句比喻，而是一个需要严肃对待的结构性命题。 *** ## 一、产品经理的第一性原理 ### 不变的起点：解决用户的问题 无论技术范式如何更迭，市场格局如何重塑，产品经理职业的第一性原理始终如一：**帮助用户解决真实的问题**。 这不是一句空洞的口号，而是一个严格的分析框架。在这个框架中，有三个概念需要被精确地区分： **需求 = 理想 − 现实** * **需求**，是用户在现实世界中遭遇的真实困境 * **理想**，是需要被精确定义的目标状态——它不是用户随口许下的愿望，而是经过深入洞察后提炼出来的合理期望 * **现实**，则是客观存在的背景条件与资源约束 这个等式的意义在于，它将「解决问题」这一宽泛的使命，分解为两个独立的认知任务：一是**准确理解现实**，即深入洞察用户所处的真实背景；二是**合理定义理想**，即在现实约束之内，为用户建立一个真正值得追求的目标状态。产品经理的全部专业性，都落在这两个认知任务的质量之上。 ### 发现、定义、解决：产品能力的三环循环 基于上述框架，产品经理的核心能力可以被归结为三个持续迭代的环节： ``` 发现问题 ↗ ↘ 用户调研 需求定义 数据洞察 优先级排序 ↑ ↓ 迭代验证 定义问题 效果评估 ↗ ↖ ↙ 解决问题 （持续迭代，不是线性流程） ``` 这三个环节，并非前后相继的线性流程，而是相互支撑、持续迭代的闭环。真正优秀的产品经理，其核心竞争力不在于某一环节的精通，而在于对这个完整循环的驾驭能力——**既能穿透表象发现真正值得解决的问题，又能在复杂约束中清晰地定义问题边界，还能在解决方案的落地中持续评估并修正方向**。 {% hint style="info" %} **核心观点** 无论 AI 技术如何演进，产品经理的第一责任始终是**为用户解决真实问题**。 AI 时代，这一使命并未消失，但实现它的**手段与工具**正在发生根本性变化。 业务理解与用户洞察，在 AI 时代反而更加稀缺——因为它们是**为模型的输入提供质量保证**的核心能力。 {% endhint %} *** ## 二、AI 驱动业务：从功能增强到范式重构 ### 一个案例的演进：评论排序的十年 要理解 AI 如何深入改变企业的产品逻辑，不妨从一个亲历的具体案例出发。 > 2014 年，我在百度作为校招生参与了一个 O2O 项目，当时有一个需求，要对评论区的评论做排序，当时我很困惑，不知道怎么定义合理的排序策略，我也不知道是不是我提出我想要的效果，应该由研发来设计这个具体的实现方法。产品和研发，在这里应该怎么分工。后来去了字节，负责字节的评论系统，真正的开始做个性化排序，开始从 sigmoid 函数学起，才开始了解一个完全由算法 AI 驱动的业务的模式。在字节甚至有一个玩笑，叫**即使你只有两条内容，也应该让模型排一下，你应该先看哪个**。 这个案例是整个行业演进的缩影。随着个性化推荐系统的成熟，答案变得清晰：**用模型来决定**。先展示哪条评论——这个问题的最优解，不依赖于产品经理设计的规则，而依赖于模型对用户行为信号、内容质量、上下文偏好的综合建模。 **企业业务 AI 化的四个演进阶段：** | 阶段 | 时期 | 驱动方式 | 竞争壁垒 | | -------- | --------- | ------------------------ | ------------ | | 第一阶段 | 2010s | 规则驱动——人工制定排序规则、分类标签、运营策略 | 低门槛，易被复制 | | 第二阶段 | 2015s | 数据驱动——A/B 测试、漏斗分析、用户分群 | 中等壁垒 | | 第三阶段 | 2018s | 算法驱动——协同过滤、精排模型、个性化召回 | 高壁垒，需数据积累 | | **第四阶段** | **2023s** | **大模型驱动——生成、理解、推理全面接管** | **护城河，难以逾越** | ### AI 渗透率：从功能到基础设施 这个案例所折射的，是整个行业近十年来的演进轨迹。越来越多的企业开始发现，**AI 在核心业务中的占比，与企业的市值和长期竞争力之间，存在着高度的正相关关系**。 以内容平台为例，过去产品的 AI 化仅体现在推荐和搜索模块；而今天，内容生成、脚本辅助、评论摘要、个性化推送、智能审核——几乎每一个产品模块都有大模型的深度参与。 > AI 不再是产品里的一个「功能」，而是产品的**基础设施**。 这意味着，不懂 AI 的产品经理，将无法参与最核心的产品决策——因为那些决策本身，就发生在模型层。 企业组织结构的变化同样印证了这一趋势：AI 人才与算力在企业成本结构中的占比持续攀升，由算法和数据驱动的业务，已经形成了竞争对手难以短期追赶的护城河。在这样的竞争格局下，**产品经理的价值与角色，必须随着企业核心能力的转移而同步演进**——不接受这一现实的产品经理，将面临职业价值的系统性折价。 *** ## 三、AI 产品经理的全栈能力标准 ### 招聘市场的结构性信号 市场从不撒谎。招聘数据，往往是行业能力需求最直接的反映。 根据 2026 年第一季度的招聘市场数据，AI 人才争夺已全面成为企业招聘的核心战场。对近期主流互联网及 AI 公司发布的 AI 产品经理岗位 JD 进行词频分析，可以直观地看出企业对这一岗位的核心能力期望： *模型、数据、技术、应用、效果、研发等高频词汇，清晰勾勒出市场对 AI PM 的核心能力期望* **2025–2026 年 AI 招聘市场关键数据：** | 指标 | 数值 | 说明 | | ------------------------ | ---------- | ------------ | | 新发 AI 岗位占比（2025 年同期） | 2.29% | 基准值 | | 新发 AI 岗位占比（2026 年 1–2 月） | **26.23%** | 同比增长约 12 倍 ↑ | | AI 人才供需比 | 0.97 | 供不应求 | | 大盘人才供需比 | 1.79 | 对比参照 | 这组数据揭示的不只是数量上的变化，更是一次质的转变：**AI 能力已从「锦上添花」的加分项，转变为企业对人才的硬性要求**。34% 的招聘岗位明确将 AI 能力列为必要条件。AI 人才的人际连接效率同样显著优于普通职场人——在职业社交平台上，AI 人才的好友建立通过率达到 33.74%，而非 AI 人才仅为 21.42%；实质性沟通转化率（双聊率）高达 47.24%，意味着近半数的连接能够进入真实的合作机会探讨阶段。 ### 四大核心能力：新标准的解构 分析近期主流互联网企业对 AI 产品经理的招聘要求，最高频出现的能力维度，可以归纳为四个相互咬合的层面。 **AI 产品经理的能力定位（高业务理解 × 高技术深度）：** ``` 高业务理解 ↑ │ 传统产品经理 AI 产品经理 ★ │ （业务强/技术弱） （全栈能力） ─────┼─────────────────────────────── → 技术深度 │ 通用执行者 算法工程师思维 │ （双维度均弱） （技术强/业务弱） ↓ ``` | 能力维度 | 核心要求 | | ------------- | ----------------------------------------------------- | | **懂产品落地** | 深刻理解具体业务场景与商业价值；能够对平台核心能力进行有效抽象，而非停留在功能层面的罗列 | | **懂 AI 与大模型** | 理解模型能力边界、Prompt 设计、Agent 架构、效果评测方法；能够在技术实现层与工程师保持有效对话 | | **懂数据闭环** | 能够设计合理的评测体系，独立解读效果数据，驱动模型与产品的持续迭代优化——而非仅仅提交需求文档 | | **懂协作推进** | 能够在算法、工程、数据、运营等多个跨职能团队中，有效推进复杂系统级项目按时落地 | 值得特别强调的是，招聘市场已经明确给出信号：**不接受「纯 Vibe Coding」的产品经理**——即仅依赖 AI 工具生成原型和文档、缺乏真正工程理解能力的候选人。编码与技术理解，已成为 AI 产品经理的底层能力要求，而非可选的加分项。 {% hint style="info" %} **核心观点** 企业现在需要的，不是「只会写 PRD 的产品经理」，而是能够**将大模型能力真正转化为业务结果**的人。 四大能力（懂产品落地、懂 AI 大模型、懂数据闭环、懂协作推进）需要**同时具备**，而非单项突出。 {% endhint %} *** ## 四、AI 产品实践的认知框架 ### 大模型的本质：从技术到产品的映射 在投身 AI 产品实践之前，有一个认知前提至关重要：**深刻理解大模型究竟能做什么，以及为什么能做**。 从技术本质来看，大型语言模型所完成的核心任务是一个 **Seq2Seq**（序列到序列）的映射：从一个不定长的输入序列，到另一个不定长的输出序列。这个映射所包含的逻辑、知识与推理能力，就是大模型真正的核心竞争力所在。 ``` 输入序列（不定长） 输出序列（不定长） 用户 · 问题 · 上下文 → [Transformer 核心] → 回答 · 分析 · 代码 · 图像 … 知识 · 推理 · 生成 ``` > **业务映射：** 任何可被抽象为「输入序列 → 理解推理 → 输出序列」的业务场景，原则上都可以利用大模型来完成。 这一认知框架，对于产品经理判断「哪些业务适合用大模型解决」具有直接的指导意义：**只要你的业务可以被抽象为「输入某种信息序列，期望获得某种信息序列」**，它在原则上就适合用大模型来处理。反之，如果业务的核心是精确数值计算、实时状态查询、或需要严格可追溯的决策路径，则应审慎评估大模型的适用性。 ### Prompt 工程的正确认知 业界对 Prompt 工程存在两种典型的误解，都不利于产品实践的有效推进。 第一种误解是**过度神话**：将 Prompt 视为决定大模型效果的核心变量，投入大量时间研究各类「Prompt 技巧」和「咒语配方」。第二种误解是**轻视忽略**：认为 Prompt 无关紧要，只需要把核心业务逻辑输入进去即可。 真实情况是：**Prompt 的质量重要，但其边际收益有明显的天花板**。好坏 Prompt 之间的效果差距，远比大多数人想象的要小——只要表达的意图清晰准确，模型的输出质量主要取决于**模型本身的能力边界**，而非 Prompt 的遣词造句。 因此，对于 AI 产品经理而言，合理的精力分配应当是：快速掌握基本的 Prompt 结构化方法（角色、任务、约束、输出格式），然后将主要精力投入到**评测设计、数据质量和模型选型**之上——那才是真正决定产品质量的上游变量。 ### Agent 的状态驱动方法论 在 AI 产品实践中，许多产品经理遭遇的第一道真正的概念门槛，是如何为 Agent 产品编写需求文档。 传统的 GUI 产品，用户可以操作的空间是有限且确定的——每个界面的状态、每个按钮的行为，都可以被穷举定义。而 Agent 面对的是**自然语言描述的无限可能输入**，用户意图的边界几乎无法穷举。这使得传统的「功能列表式」需求文档在 Agent 场景下几乎失效。 解决这一难题的有效方法，是引入**状态驱动**的思维框架：将看似无限的用户意图收拢到有限个系统状态之上，用状态之间的转移逻辑来定义 Agent 的行为边界。 **Agent 有限状态机示意（举例）：** ``` ┌─────────────┐ 用户输入 │ 初始化 │ ← 新轮次输入 ─────────▶│ 等待输入 │◀──────────────┐ └──────┬──────┘ │ │ │ 意图明确▼ │ ┌─────────────┐ │ 意图不清， │ 意图理解 │ │ 追问 ──────▶ │ │ └──────┬──────┘ │ │ 意图明确 │ ┌──────▼──────┐ │ │ 任务规划 │◀──不满足，重规划─┐ └──────┬──────┘ │ 执行步骤│ │ ┌──────▼──────┐ │ │ 工具调用 │ │ └──────┬──────┘ │ 工具返回│ │ ┌──────▼──────┐ │ │ 结果评估 │───────────────┘ └──────┬──────┘ 结果满足│ ┌──────▼──────┐ │ 生成响应 │───────────────▶ └─────────────┘ ``` 一个典型的 Agent 产品可以被建模为一个有限状态机：**初始化 → 意图理解 → 任务规划 → 工具调用 → 结果评估 → 生成响应**，并在必要时触发重规划或意图澄清的回环。 这种状态化的思维，使产品经理得以将「无限输入」这一难题，转化为**有限状态集合 + 有限转移条件**的可管理问题，从而重新找回在 Agent 需求定义中的专业价值。 *** ## 五、结语：PM 角色的新定义 纵观本章所讨论的四个维度，我们可以为 AI 时代的产品经理角色，勾勒出一幅清晰的演进轨迹。 传统产品经理的核心身份，是**需求的翻译者**：将用户的问题翻译成功能规格，交由工程师实现。这一角色的价值，建立在产品经理作为「用户代言人」与「技术实现层」之间的桥梁地位之上。 而在 AI 时代，这座桥梁的两端都发生了深刻变化。用户需求依然存在，但**满足需求的核心介质**从「界面与流程」转移到了「模型的输入与输出」；技术实现层从「工程师写代码」扩展到了「模型训练、Prompt 设计、数据标注、效果评测」这一套完整的 AI 工程链路。 因此，AI 时代的产品经理，其角色已从「需求翻译者」演进为**效果的负责人**： | | 传统 PM | AI 时代 PM | | -------- | --------- | -------------------- | | **角色定位** | 需求翻译者 | 效果负责人 | | **核心工作** | 定义功能，推动交付 | 定义「好」的标准，评测现状，决策干预方向 | {% hint style="info" %} **核心观点** AI 时代的产品经理，需要清晰地回答三个问题： **什么叫好？** 定义产品效果的评测标准与成功指标 **现在有多好？** 独立执行评测，准确判断当前状态 **如何变得更好？** 决定干预方向：换模型、改 Prompt、优化数据…… 这不仅要求**懂业务**，更要求**深入参与**那些曾经被视为「算法的事」的环节。**懂模型，不是加分项，是门槛。** {% endhint %} 这是一个更高要求的角色，但也是一个更有分量的角色。当模型能力真正等同于产品能力，能够驾驭模型、理解数据、定义效果的产品经理，将成为连接用户价值与技术能力之间最不可或缺的那个人。 *** {% hint style="warning" %} **思考题** **当「懂模型」成为产品经理的基本门槛，产品经理与算法工程师之间的边界，还有必要存在吗？** 一方面，AI 产品经理被要求懂模型、懂评测、懂数据，参与越来越多传统上属于算法团队的决策；另一方面，算法工程师也在借助 AI 工具提升产品感知，开始直接参与用户体验的设计与判断。 两个角色正在向彼此靠近。那么，当重叠区域越来越大，**各自真正不可替代的核心价值还剩下什么？** 是产品经理对用户需求背后深层动机的洞察？还是算法工程师对模型行为与数学直觉的掌握？ {% endhint %} *** *下一节 · 第零章第三节* **产品 Agent 化：软件形态正在发生什么变化** 当模型具备了自主规划与工具调用的能力，软件不再只是响应点击的界面，而是能够主动完成任务的智能体。这一变化，将从根本上重塑产品的交互范式与设计逻辑。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://book.likun.ai/00-intro/02-mo-xing-ji-chan-pin.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.