4. AI PM 的能力模型：一个有战斗力的 AI PM 长什么样

一个有战斗力的 AI PM，不是会用 AI 工具的人，而是能把不确定的模型能力，转化为可交付、可评估、可迭代、可商业化产品能力的人。

---

前三节，我们分别探讨了生成式 AI 在信息革命中的宏观坐标、产品经理角色的范式演进，以及产品 Agent 化的三种形态。这些讨论都在回答同一个问题的上半段：这个时代在发生什么。

本节要回答的，是下半段：在这个时代，什么样的产品经理才真正具备战斗力。

---

一、从 GUI 时代到 AI 时代：PM 的能力基准在哪里变了

GUI 时代的八股文

GUI 时代，产品经理有一套约定俗成的能力体系——可以称之为「八股文」：

画好看的原型图，从低保真到高保真各种设计规范；设计高效的内容容器框架，瀑布流、双列流、全屏流各种信息流布局；与运营一起制定内容活动策略，拉新活动、发帖激励等增长手段。甚至有相当一部分产品经理，以熟练掌握 Axure 为核心求职竞争力。

这套能力体系并非没有价值——它服务于 GUI 产品的核心命题：如何在有限的屏幕空间内，设计出高效流动、用户易于操作的界面系统。

但在 AI 时代，这套能力体系的边界，正在被一个全新的能力基准所重新划定。

图 1：GUI 时代 vs AI 时代 PM 能力基准对比

┌──────────────────────────┐         ┌──────────────────────────┐
│   GUI 时代的 PM 能力       │         │   AI 时代的 PM 能力        │
├──────────────────────────┤         ├──────────────────────────┤
│ • 原型设计（低保真/高保真）  │         │ • 领域知识深度（专家）     │
│ • 信息架构与容器框架        │         │ • 产品架构与协议设计       │
│ • 界面流程与交互逻辑        │  能力   │ • 模块编排与状态管理       │
│ • 内容活动策略             │ ──────▶ │ • 动手验证（Demo/Coding）  │
│ • 用户研究与需求文档        │  基准   │ • 评测体系设计             │
│ • Axure / Figma 工具       │  重新   │ • 模型理解与 Prompt 工程   │
│ • 数据分析（漏斗/留存）     │  划定   │ • 跨职能沟通与翻译能力     │
├──────────────────────────┤         ├──────────────────────────┤
│ 核心命题：                 │         │ 核心命题：                  │
│ 如何设计高效易用的界面系统  │         │ 如何把模型能力转化为可交付  │
└──────────────────────────┘         └──────────────────────────┘

这不是说 GUI 时代的能力全部作废——用户研究、需求定义、项目推进，这些基础能力在 AI 时代依然有价值。但决定一个 AI 产品经理天花板的核心变量，已经彻底改变了。

核心观点

AI 时代，评价一个产品经理是否有战斗力的核心标准，不再是能否画出漂亮的原型图，而是能否把不确定的模型能力，转化为可交付、可评估、可迭代、可商业化的产品能力。

这是一个更高维度的命题，它要求产品经理同时具备领域深度、技术理解、验证能力与沟通能力。

---

二、五维能力模型：有战斗力的 AI PM 的全貌

五个相互咬合的能力维度

综合对 AI 产品实践的观察，有战斗力的 AI PM 需要具备五个相互咬合的核心能力维度。它们并非孤立存在，而是构成一个完整的产品力系统——任何一个维度的缺失，都会在产品落地的某个环节形成明显的短板。

图 2：AI PM 五维能力模型

                  领域知识 (Domain)
                       ▲
                       │
       沟通表达 ◀──────┼──────▶ 架构协议
    (Communication)    │      (Architecture)
                       │
                  ┌────┴────┐
                  │ 有战斗力 │
                  │ AI PM   │
                  └────┬────┘
                       │
       动手实现 ◀──────┼──────▶ 编排管理
        (Code)         │     (Orchestration)

表 1：AI PM 五维能力模型总览

能力维度	本质定义	核心工具
领域知识	成为特定业务领域的专家，深入理解用户真实场景与行业知识	领域评测集（手动构建）
架构协议	将业务抽象建模为产品模块，定义模块间的输入输出与通信协议	产品架构图
编排管理	对架构模块进行动态组织编排，通过状态控制实现业务的确定性效果	状态图 / 流程图
动手实现	亲自 Demo 验证想法，离线通过才有资格推进工程开发	代码 / Notebook
沟通表达	将大模型业务翻译为各协作方能听懂的语言；用 Prompt 与模型高效沟通	Prompt / 文档

下面逐一展开每个维度的核心内涵。

---

三、领域知识能力：产品经理即用户，即专家

定义与本质

领域知识能力（Domain Knowledge） 的本质，是对业务能力要求的进一步升级——AI 时代的产品经理，必须成为某个领域的真正专家。

这一维度强调的是领域复合人才的培育路径：领域知识 + 业务理解 + 产品能力 三位一体，缺一不可。

这个逻辑非常好理解：

做运动大模型，你必须理解运动科学，理解超量恢复原理、五分化训练法等专业知识；

做编程大模型，你必须自己会写代码，能评估代码补全的质量，而不是只看产品外观；

做医疗大模型，你必须了解医疗领域的基本诊疗知识，能分辨回答中的专业错误；

就算是做通用大模型，也需要在若干顶级领域问题上达到可评测的专业水准。

原因是：如果你只懂产品，不懂对应的领域或业务专业知识，你根本无法与大模型以及用户需求做对齐，也无法理解用户的真实诉求与模型输出的质量高低。

这意味着「产品经理即用户」这一传统原则在 AI 时代需要升级为：产品经理即用户，即专家。

图 3：领域知识能力的建构路径

   ┌──────────┐         ┌──────────┐         ┌──────────┐
   │ 传统 PM   │  AI 时代 │  AI PM   │  能力    │ 领域复合  │
   │ 产品经理   │   升级   │ 产品经理  │  内化    │ 知识+业务 │
   │ 即用户    │ ──────▶ │ 即用户   │ ──────▶  │ +产品    │
   │           │         │ 即专家   │          │           │
   └──────────┘         └──────────┘         └──────────┘

   核心工具：领域评测集——由 PM 亲自手动构建并评分，
            是检验领域知识深度的直接证明

核心工具：领域评测集

领域知识能力最直接的体现，是能否自己手动构建并评分一套领域评测集。

一套有价值的领域评测集，应当满足：覆盖该领域中真正有难度的长尾问题；包含业界最佳实践与专业错误的对比样本；PM 自己能够给出有依据的评分标准，而非完全依赖专家外包。

这一能力的缺失，会直接导致产品经理在评估模型效果时缺乏判断基准，进而在技术团队面前失去话语权。

---

四、架构协议能力：从功能列表到业务建模

定义与本质

架构协议能力（Architecture） 的本质，是业务模型的抽象——产品有哪些模块，模块间怎么通信，在业务建模中分别代表什么实体对象。

具体来说，这要求产品经理能够：从业务需求出发，抽象出产品的核心模块；明确每个模块的 Input 和 Output 分别是什么；定义模块之间用什么协议互相交互；本质上，这是协议字段的设计、表结构的设计、接口契约的定义。

以一个 AI Agent 产品为例，典型的模块包括：模型（Model）、上下文（Context）、工具（Tools）、数据（Data）、权限（Permission）等。这些模块的合理拆分与交互协议设计，直接决定了产品的可扩展性与工程落地效率。

图 4：（示例）AI Agent 产品的架构协议视图

                    ┌──────────────┐
                    │ 用户意图输入   │
                    └──────┬───────┘
                           │
                           ▼
   ┌──────────┐  消息    ┌─────────┐  函数调用  ┌──────────┐
   │ 上下文    │ ────────▶│  模型    │◀──────── │  工具     │
   │ Context   │   格式   │  Model  │   协议    │  Tools    │
   └──────────┘           └─────────┘           └──────────┘
                              ▲
   ┌──────────┐  向量/    ┌────┴────┐  鉴权     ┌──────────┐
   │ 数据      │ ────────▶│  模型    │◀──────── │  权限     │
   │ Data     │   结构化  │  Model  │   令牌    │ Permission│
   └──────────┘           └─────────┘           └──────────┘
                              │
                              ▼
                    ┌──────────────┐
                    │ 产品侧响应输出  │
                    └──────────────┘

   PM 架构定义的边界：模块拆分 × 协议设计 × 实体建模
   （不同产品的模块拆分方式各有不同，此图仅为一种可能的拆分示例）

架构能力与功能列表的根本区别

有一个常见的认知误区值得点破：架构协议能力不等于写功能列表。

功能列表回答的是「有什么」；架构协议回答的是「是什么、怎么组合、用什么协议通信」。前者是枚举，后者是建模。

一个缺乏架构协议能力的产品经理，写出来的 PRD 往往是「功能堆砌型」——需求很多，但模块边界模糊，接口协议缺失，导致工程团队不得不自己做本应由 PM 完成的抽象工作。在 AI 产品中，这一问题会被放大数倍——因为大模型系统的模块依赖关系远比 GUI 产品复杂，协议设计的质量直接影响整个系统的工程可维护性与迭代效率。

---

五、编排管理能力：让模块动起来

定义与本质

编排管理能力（Orchestration） 的本质，是对架构模块的动态组织逻辑——非静态一成不变，而是受到状态控制的动态过程。

具体来说，编排管理能力要求产品经理能够通过不同模块的动态编排，实现业务的确定性效果。典型的编排形式包括：

• Prompt 编排：系统 Prompt、用户 Prompt、上下文 Prompt 的组织结构；
• Workflow 编排：多步任务链路的节点定义与执行顺序；
• 多 Agent 协作：不同 Agent 之间的任务分发与结果汇聚；
• 人机协同：人类介入节点的触发条件与接管机制。

编排管理能力与架构协议能力的关系可以类比为：架构协议是乐器与乐谱（静态的），编排管理是演奏过程（动态的）——同样的乐器与乐谱，不同的演奏方式会产生完全不同的效果。

图 5：编排管理能力的四种形式

   ┌─────────────────┐             ┌─────────────────┐
   │ Prompt 编排      │             │ Workflow 编排    │
   │                  │             │                  │
   │ 系统/用户/上下文  │             │ 多步任务链路的    │
   │ Prompt 的层次化   │             │ 节点定义与执行    │
   │ 组织结构          │             │ 顺序控制           │
   └────────┬─────────┘             └─────────┬───────┘
            │                                  │
            └──────────┐         ┌─────────────┘
                       ▼         ▼
                    ┌─────────────┐
                    │  编排管理     │
                    └─────────────┘
                       ▲         ▲
            ┌──────────┘         └─────────────┐
            │                                  │
   ┌────────┴─────────┐             ┌─────────┴───────┐
   │ 多 Agent 协作    │             │ 人机协同         │
   │                  │             │                  │
   │ 不同 Agent 的    │             │ 人类介入节点的   │
   │ 任务分发与汇聚    │             │ 触发条件与接管   │
   │ （并行/串行/路由）│             │ 机制设计         │
   └──────────────────┘             └──────────────────┘

核心工具：状态图。 将看似无限的业务可能收拢到有限的状态集合，用状态转移定义产品的确定性行为边界。

为什么编排管理是 AI PM 的核心门槛

编排管理能力之所以成为 AI PM 有别于传统 PM 的核心门槛，原因在于大模型的输出天然具有不确定性——同样的 Prompt，不同的上下文编排，可能产生截然不同的结果。

传统 GUI 产品的行为是完全确定的：按钮点了就跳转，规则满足就触发，逻辑写死在代码里。而 AI 产品的行为，依赖于编排层对模型行为的有效约束。产品经理如果无法设计出有效的编排策略，就无法将模型的「统计概率」转化为用户可信赖的「产品确定性」。

核心观点

编排管理能力的本质，是在不确定中建立确定。

大模型的输出本质上是概率分布，而产品需要向用户提供确定的交付承诺。

弥合这两者之间差距的核心机制，正是状态驱动的编排管理——将无限可能的用户意图，收拢到有限的系统状态，通过状态转移逻辑定义产品的行为边界。

---

六、动手实现能力：Demo 说话

定义与本质

动手实现能力（Code） 的核心逻辑，只有一句话：Demo it。

「让模型更智能一点」、「让推荐更精准一点」——这样的需求没有任何意义。

只有离线验证通过的想法，才有资格被推进到工程开发，才有机会上线到用户端做真实效果测试。

这不是说产品经理要取代工程师的角色——而是说，产品经理的想法必须先经过自己的动手验证，才有资格成为推动工程团队投入资源的需求。

在 GUI 时代，这个验证过程可以通过原型图和用户访谈来完成。在 AI 时代，只有实际跑通模型调用、拿到真实的输出结果，才算完成了基础验证。

图 6：动手实现能力的价值链路

   ┌────────┐        ┌────────┐        ┌────────┐        ┌────────┐
   │ 产品想法 │ ──────▶│ 离线 Demo│ ─────▶│ 工程开发 │ ─────▶│ 上线测试 │
   │ 概念意图 │        │ 动手验证 │       │ 有依据投入│       │ 真实效果 │
   └────────┘        └────────┘        └────────┘        └────────┘
        │
        │  ✗ 无 Demo 直接推进工程开发——
        └─── 意味着在低质量想法上浪费资源

动手实现的门槛是什么

值得强调的是，这里的「动手实现」门槛，不是要求产品经理写出生产级代码，而是要求能够：

• 调用大模型 API，跑通基本的 Prompt 实验；
• 使用 Jupyter Notebook 等工具做离线效果评测；
• 能够独立判断「这个想法在当前模型能力下可行吗」；
• 能够用代码复现一个最小可行的产品原型（MVP）。

这是 AI 时代产品经理的基础能力下限，也是之前第二节已经提到的：招聘市场不接受「纯 Vibe Coding」的产品经理。不会用代码验证想法的产品经理，在 AI 产品团队中会持续处于「没有发言权」的位置。

---

七、沟通表达能力：翻译的艺术

定义与本质

沟通表达能力（Communication） 在 AI 时代面临一个特殊的挑战：大模型带来了巨大的理解鸿沟。

这个鸿沟，存在于两个层面：

对内翻译：你需要把大模型业务的内容，翻译为团队各协作方能听懂的语言——设计能听懂的语言、运营能听懂的语言、高管能听懂的语言，以及工程师能听懂的产品意图描述。

与模型沟通：你每天要与大模型沟通无数次，Prompt 就是与模型沟通的艺术。如何把一个模糊的业务需求，转化为让模型准确理解意图的结构化指令，是 AI PM 必须掌握的沟通技能。

图 7：沟通表达能力的双向翻译模型

                    ┌────────────────┐
                    │ 大模型/Prompt   │
                    └────────┬───────┘
                             │ ↕ Prompt 艺术
                             ▼
   ┌──────────┐         ┌─────────┐         ┌──────────┐
   │ 设计团队  │ ◀──────│         │──────▶ │ 高管决策层 │
   ├──────────┤         │  AI PM  │         ├──────────┤
   │ 运营团队  │ ◀──────│ 翻译者   │ ──────▶│  用户     │
   ├──────────┤         │         │         └──────────┘
   │ 工程/算法 │ ◀──────│         │
   └──────────┘         └─────────┘
   对内翻译                                  对外表达
   （业务语言转化）                          （决策与用户沟通）

为什么沟通能力在 AI 时代变得更难

在 GUI 时代，产品经理的沟通对象是相对确定的——需求来自用户，功能交给工程师，语言体系虽有差异但基本在同一认知框架内。

AI 时代，沟通的复杂度大幅提升，原因有三：

1. 大模型的工作方式超出大多数人的认知范畴，导致产品经理在向非技术同事解释「为什么 AI 不稳定」、「为什么效果评测如此重要」时面临极大的理解鸿沟；

2. 效果驱动的迭代节奏与传统瀑布式开发节奏差异显著，产品经理需要用新的语言体系去解释「为什么需要这么多轮迭代」；

3. Prompt 本身是一种特殊的沟通艺术——它不是编程语言，但需要结构化思维；它不是自然语言，但需要准确表达意图；掌握 Prompt 工程是 AI PM 与模型高效协作的核心能力。

---

八、五维能力的综合画像：有战斗力的 AI PM

能力组合的现实分布

五维能力并非要求产品经理在每个维度都达到满分——现实中，不同类型的 AI 产品对不同维度的权重需求也不相同。

表 2：不同类型 AI 产品对五维能力的权重侧重

产品类型	领域知识	架构协议	编排管理	动手实现	沟通表达
通用 LUI 产品	中	高	高	中	中
垂直领域 Copilot	极高	中	高	高	中
AI Native 自主执行	中	极高	极高	高	中
C 端 AI 消费产品	高	中	中	中	极高
B 端 AI 解决方案	极高	高	高	高	极高

一个综合判断的框架

但无论权重如何分布，有一个底线是明确的：

核心观点

有战斗力的 AI PM，在五个维度上不能有明显的空白项。

• 领域知识 决定你能否看懂用户的真实需求；
• 架构协议 决定你能否把需求转化为可工程化的系统设计；
• 编排管理 决定你能否在不确定的模型能力上构建确定性的产品体验；
• 动手实现 决定你能否在提需求之前先自己验证想法的可行性；
• 沟通表达 决定你能否让整个团队理解并认同你的产品方向。

缺少任何一个，都会在产品落地的某个关键环节形成系统性短板。

表 3：AI PM 五维能力成熟度矩阵

	领域知识	架构协议	编排管理	动手实现	沟通表达
初阶（入门）	了解特定领域基础知识	能画出模块关系图	能描述业务流程与分支逻辑	能调用 API 跑通基础 Demo	能清晰表达产品意图
进阶（熟练）	能构建并评分领域评测集	能定义接口协议与数据结构	能设计状态图实现确定性效果	能独立完成离线评测脚本	能将 AI 业务翻译给各方
高阶（专家）	能识别领域里模型的边界与盲区	能主导系统级架构决策	能设计多 Agent 协作编排方案	能从零搭建 MVP 产品原型	能建立团队共识推动组织对齐

---

九、结语

AI 时代，产品经理面临的最大挑战，不是「会不会用 AI 工具」，而是在模型行为天然不确定的前提下，如何对产品结果负责。

这五个维度，给出的正是这个问题的答案。它们不是独立的技能点，而是一套相互支撑的判断链路：

• 领域知识决定你能不能看清问题；
• 架构协议决定你能不能把问题建模清楚；
• 编排管理决定你能不能让模型稳定工作；
• 动手实现决定你的判断有没有事实依据；
• 沟通表达决定你的判断能不能被执行。

五个维度缺一不可，因为它们对应的是同一件事的五个环节：把一个模糊的 AI 能力，变成一个确定可交付的产品。

核心观点

AI PM 的新门槛是：

• 懂领域，能判断模型是否真的解决问题；
• 懂架构，能把业务抽象成系统对象；
• 懂编排，能让不确定的模型产生稳定效果；
• 能动手，能用 Demo 和评测证明判断；
• 会表达，能跨越人与模型之间的理解鸿沟。

最终，AI PM 的价值不在于「会用 AI」，而在于能把 AI 变成产品、业务和商业结果。

Claude Code 负责人 Boris Cherny：「going to be a product manager and everyone」（我要成为产品经理，所有人都会）

---

思考题

用这五个维度，给自己做一次诚实的评分。

领域知识： 你当前负责的产品，你能独立构建并评分一套领域评测集吗？如果不能，你的领域知识深度距离「专家」还差多远？

架构协议： 你最近一次写的 PRD，有没有清晰地定义模块的 Input/Output 和通信协议？还是只是一份「功能列表」？

编排管理： 你有没有为自己负责的 AI 产品画过一张完整的状态图？能否清楚地说出在哪些状态下，模型应该做什么？

动手实现： 最近一次你提出的产品想法，你有没有先自己跑过 Demo？还是直接丢给工程师去探索可行性？

沟通表达： 上一次你向非技术同事解释 AI 产品的局限性时，对方真的听懂了吗？

找到你评分最低的那个维度——从那里开始改变。

---

下一节 · 第零章第五节

AI PM 的工具箱：以产出倒逼工具，让 AI 把你变成超级人类

从「AI 是小弟」到「AI 是延伸」的思想转化、三类核心产出（图表原型 / 产品 demo / 线上服务）、以及对应的工具组合——一篇就讲清楚 AI PM 每天该用什么。