# 首页 & 前言 ## 为什么要写这个系列 2022年底，我在腾讯开始做大模型相关的业务，截至今日，4年多时间，行业沧海桑田，人才涌入，卷到飞起。但是在招聘中，我们却很难找到合适的人才，我们深刻感受到，市场的缺口是因为缺少know how造成的。行业对产品经理的全栈要求已经越来越高，AI能力已经是基础，不再是加分项。（招聘jd见文末）。 市面上关于 AI 的内容，**要么太浅——全是"教你用 ChatGPT"的使用技巧；要么太深——直接上论文和代码，普通 PM 根本跟不上。** 夹在中间的产品经理，其实最需要的是：**能看懂技术、能做决策、能和工程师对话、能把产品做出来** 的系统性知识。所以我决定把自己的经验整理成一个系列，叫做—— **《AI 产品经理手册》** 除了公众号，会同步更新到： *** ## 这个系列会写什么 整个手册分为九章，从"AI PM 是什么"出发，一路写到商业化落地。 **第零章　AI PM 的新起点** 这次技术变革和以往有什么本质不同；模型即产品意味着什么；AI PM 的能力模型和工具箱。 > 📌 **本章作业**：选 3 个大模型产品，用同一个复杂任务测试，记录各自的表现差异和你的判断。 **第一章　先学会衡量：评测体系的建立：评测即需求，评测即产品。** 为什么评测是 AI PM 的核心能力；如何构建评测集；Rubric 设计；LLM Judge 的正确姿势；怎么读各家模型发布评测结果里的水分。 > 📌 **本章作业**：为你负责的一个 AI 功能设计一套评测集（至少 30 个 case，覆盖正常、边界、对抗三类），并为其中一个核心维度写一份完整的 Rubric，定义 1～5 分各级别的判断标准。 **第二章　大模型是如何学习和理解业务的** 训练流程、对齐算法演进、算力与硬件、训练数据、微调框架……还有一个完整的真实案例：以 Keep 运动健康大模型为背景，从立项到上线每一个真实决策。 > 📌 **本章作业**：用 LoRA+ 对一个开源小模型做一次最简单的 SFT（自己的电脑就可以完成），准备 10～20 条业务相关指令数据，对比微调前后输出变化，写出你的观察。 **第三章　大模型是怎么工作的** 7 行代码调通 API；Token 生成的本质；采样参数怎么配；Prompt Engineering 实战；幻觉、延迟、成本的三角权衡。 > 📌 **本章作业**：默写并运行 7 行代码调通大模型 API；用同一 prompt 测试 temperature=0.1 / 0.7 / 1.5，记录输出差异，写出你的采样参数直觉。 **第四章　安全与治理** 内容安全红线、数据合规、国内备案实操——这些做产品绕不开的事。 > 📌 **本章作业**：设计一份内容安全红线清单（至少 10 条），并为其中 3 条各写一个对抗性 prompt，测试你选用模型的实际防御效果。 **第五章　Agent 全景** 从 ReAct 到 MAS；Agent 的认知能力、工具扩展、编排与 runtime；LangGraph、Dify、Coze 的选型，openclaw类产品的优劣对比。 > 📌 **本章作业**：用 Dify 或 Coze 搭建一个接入 2 个工具的 Agent，记录意图识别的失败案例，并设计一套记忆方案。 **第六章　动手做 Agent：工业落地的真实过程** 一个完整的 Agent 从需求拆解到上线的全流程实战记录，包括常见翻车点复盘。 > 📌 **本章作业**：用 LangGraph 实现一个最小可运行的饮食记录 Agent，跑通"记录一餐 → 查询今日摄入 → 给出建议"完整流程，写出遇到的问题和解法。 **第七章　AIGC 内容生成** 图像、视频、脚本的工业化生产；多模态内容流水线；版权与合规的现实处理。 > 📌 **本章作业**：选一个真实业务场景，用图像生成工具完成批量内容生产，提交 prompt 迭代记录（至少 3 轮）和 pipeline 设计思路。 **第八章　大模型时代的商业化** Token 付费的本质；AI 产品成本结构拆解；ROI 怎么算；成本控制策略；定价模型设计。 > 📌 **本章作业**：估算一个 AI 功能的月度推理成本，并设计一套降本 30% 的方案，说明每项措施的预期效果与实施代价。 每章都有一道**实战作业**，不是选择题，是真正能动手做的任务，我也会同步公布答案。 *** ## 更新计划 我会按章节顺序更新，频率大约是**每 1～2 周一篇**，尽量保证每篇质量，不水文章。 如果你想跟着这个系列系统学习，建议先关注本公众号，后续每章更新都会第一时间推送。 *** ## 最后说一句 这个系列不是教程，也不是综述文章。 它是我踩坑之后，觉得"当初要是有人告诉我这些就好了"的那种内容。 有些结论可能不讨喜，有些观点可能有争议——但我会尽量写真实的判断，而不是正确的废话。 限于个人认知边界，有一些可能也会有问题，请多指正。 *** *关注公众号，不错过每一篇更新。* ![招聘JD示例](https://1075808901-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FP0GxMToc5H2sUYqlAcOr%2Fuploads%2Fgit-blob-27302c9afebac3c3ec316bd869de247d3b00e5b1%2Fjd.jpg?alt=media) # 目录 # 第零章：为什么 AI PM 需要重建认知 > 从传统 PM 到 AI PM，认知和工具都需要重建 *** ## [1. 生成式 AI 可能是人类信息革命的终局](/00-intro/01-xin-xi-ge-ming-zhong-ju) * 信息的发展历史终局 * 人类的生产历史改变 ## [2. 模型即产品：当模型能力就是产品能力，PM 的角色在哪](/00-intro/02-mo-xing-ji-chan-pin) * 从招聘 JD 开始 * 业务含 AI 化的比例增长 * 不变的需求，变的手段 * 明确什么环节用 AI 完成什么 ## [3. 产品 Agent 化：软件形态正在发生什么变化](/00-intro/03-chan-pin-agent-hua) * GUI 时代：LUI 分发 * GUI 时代：Copilot * AI Native 时代：Skill 时代 ## [4. AI PM 的能力模型：一个有战斗力的 AI PM 长什么样](/00-intro/04aipm-neng-li-mo-xing) * 领域知识能力 * 编排管理能力 * 架构设计能力 * 沟通表达能力 * 动手实现能力 ## [5. AI PM 的工具箱：以产出倒逼工具，让 AI 把你变成超级人类](/00-intro/05aipm-gong-ju-xiang) * AI 时代的产品需求文档 * 一个强大的协同合作伙伴：Codex / Cursor / Claude Code * 一个本地的 Jupyter 环境，实践是最好的老师 * 一个云服务账号，把你的想法发布出去 * 大模型 API Key，最好的方法是实践 *** ## 本章作业 选 3 个大模型产品，用同一个复杂任务测试，记录各自的表现差异和你的判断。 # 1. 生成式 AI 可能是人类信息革命的终局 {% hint style="info" %} 本节提供精排版 PDF：[📄 下载 PDF](https://github.com/likunpm/ai-handbook/blob/main/00-intro/01-信息革命终局.pdf) {% endhint %} > *「人类曾经以采集食物为生，而如今他们重新要以采集信息为生。」* > > —— 马歇尔·麦克卢汉（Marshall McLuhan） 如果麦克卢汉还在世，或许他会修改自己的这句话：*未来，人类将以创造为生。* 这不是口号，而是对一次结构性变革的判断。要理解这个判断，我们需要先回到一个更古老的问题——信息，到底是怎么演化到今天这一步的。 *** ## 1.1 信息的爆炸与分发的革命 ### 从口口相传到算法推荐 人类历史上，信息技术的每一次跃迁，都不只是工具的升级，而是权力结构和社会组织方式的重构。 从口口相传，到甲骨文、竹简，到印刷纸质书籍，再到电报、电台、电视、电脑、手机——每一次媒介的变革，人类每天产生和流通的信息量，都以数量级跳跃式增长。 **图 1-1　人类信息媒介演进时间轴** ``` 远古 ~3000 BC 1450 AD 1850s 1920s 1990s 2010s 2020s │ │ │ │ │ │ │ │ ──●─────────────●─────────────●─────────────●─────────────●─────────────●─────────────●─────────◉──▶ │ │ │ │ │ │ │ │ 口口相传 甲骨文竹简 活字印刷 电报电话 广播电视 互联网 移动推荐 生成式AI ◀──────── 手工记录时代 ──────▶◀────── 电气广播时代 ──────▶◀──── 数字互联网时代 ────▶◀─ AI时代 ─▶ ``` *每一次跃迁都重塑了信息的生产权与传播权；生成式 AI（◉）是目前这条轴线上最具结构性意义的节点。* 面对指数级增长的信息洪流，人类也在持续发明新的分发方式。图书馆的分类编目系统，是对有限知识的有序归档；搜索引擎的出现，让「平等找到所求」第一次成为可能——贵州山区的孩子与北京的学生，在理论上可以检索到同等质量的信息。个性化推荐算法更进一步，它不再等待你去「找」，而是主动把信息推送到你面前。 这三代分发技术，本质上都在做同一件事：**帮助人类对抗信息过载，提升获取有价值信息的效率**——提高信噪比。 > **核心观点** > > 从图书馆到搜索引擎，再到今天的个性化推荐，信息**消费**的门槛一降再降。一个偏远地区的孩子，今天也能实时获取到最前沿的知识。这是分发技术带来的**消费侧平权**，它已基本走到了技术演进的成熟阶段。 *** ## 1.2 生产：从未真正平权 当我们把信息的生产与消费对比来看，会发现一个长期被忽视的结构性不对称：**消费侧已相对平权，生产侧从未真正平权。** ### 谁有资格「说话」：生产权的历史 信息的生产权，在人类历史的绝大多数时间里，都是少数人的特权。 在古代，信息的生产者是祭司和史官——他们掌握文字，垄断着对自然与历史的解释权；消费者是当权者，普通民众甚至不在分发链路之内。随着科举和私塾的兴起，「读书人」成为一种职业身份，代写文书、为人读信是专业能力，文字开始承载学习与交流的价值。进入电台电视时代，信息的生产依赖昂贵的技术设备和播出资质，生产权高度集中在国家与媒体机构手中。 互联网时代似乎打破了这一格局——任何人都可以在社交平台发布内容。然而现实数据却令人警醒：**在今天的短视频平台上，每天真正持续创作内容的用户，不足总用户的 1.5%**。 **图 1-2　信息生产权的历史金字塔** ``` ▲ ╱ ╲ ╱祭司╲ 公元前 ╱ 史官 ╲ ╱─────────╲ ╱ 文人书写时代╲ 古代至近代 ╱ 读书人 ~5% ╲ ╱────────────────╲ ╱ 广电时代 ╲ 20 世纪 ╱ 专业机构 <0.1% ╲ ╱────────────────────╲ ╱ 互联网时代 ╲ 互联网时代 ╱ 创作者 ~1.5% ╲ ╱────────────────────────────╲ ╱ ★ AI 时代：所有人皆可创作 ╲ ← 生产平权（AI 带来的变革） ╱──────────────────────────────────╲ ``` *生产权始终是极少数人的特权——直到生成式 AI 出现，这个结构才第一次面临根本性的改变。* ### 真正的瓶颈：Know-how 的门槛 各类创作工具不断提供模板，试图降低生产门槛——但这只解决了「操作难度」的问题，并没有触及更深层的障碍：**Know-how 的缺乏，以及表达能力本身的局限**。 举一个具体的例子：你想把昨夜的梦境还原出来，拍成一段影像。这需要分镜脚本、摄影技术、剪辑能力、视觉特效……任何一个环节的缺失，都会让你脑海中栩栩如生的画面，永远停留在无法表达的沉默里。 > 「我想要一个什么样的东西」，这本身也是一种**人类表达**——但在 AI 出现之前，绝大多数人的这种表达，只能以「从市场上选择别人提供的供给」的方式勉强实现。 生产表达被长期压抑，导致了大量个性化需求无从被满足。人们不是不想创造，而是被客观能力和技术门槛挡在了门外。 *** ## 1.3 通用人工智能：生产平权的来临 这正是生成式 AI 带来的**第一个结构性变化**： 它不只是一个更好用的工具，而是**将生产的权利还给了每一个人**。 ### 从选择到创造 Vibe Coding 出现之前，一个普通人想开发一款自己的 App，需要学习至少一门编程语言、理解系统架构、掌握调试方法——这道门槛，拦住了绝大多数有想法的人。今天，你只需要用语言描述清楚你想要什么，AI 可以帮你写出可运行的代码。 这不是说 AI 取代了工程师的全部价值，而是说*表达意图*本身，正在成为一种新的生产能力。 > **核心观点** > > 信息消费侧的平权，已经由互联网和推荐算法基本完成。 > > 生成式 AI 所带来的，是**生产侧的平权**——它让每一个普通人，都有能力将脑海中的想法，转化为世界中真实存在的内容与产品。 > > 这是两次平权的闭环，也是信息革命的**终局意义**所在。 ### 「终局」的边界 需要说明的是，这里所说的「终局」，并非指技术进步从此终止，而是指信息革命的**逻辑闭环**：生产、分发、理解——三个环节都被 AI 渗透，人类在信息链路上所面临的结构性门槛，首次有了被系统性消解的可能。 当然，新的平权并不意味着新的绝对公平。模型的算力、数据权利与平台规则，仍然可能形成新形式的集中。但**个体把想法转化为产品的成本结构**，已经发生了根本性变化。 *** ## 1.4 生产史的终极转向 ### 七个阶段：人类生产方式的演变 要理解 AI 带来的这次变革有多深刻，不妨将人类的生产历史拉通来看。 **图 1-3　人类生产方式的七个阶段** | 阶段 | 名称 | 特征 | 时代标注 | | :-: | :-------: | :--: | :------: | | ① | **采集狩猎** | 自然获取 | 原始时代 | | ② | **手工生产** | 个体手作 | 农耕文明 | | ③ | **蒸汽工厂** | 机器代劳 | 工业革命 | | ④ | **电气分工** | 流水效率 | 工业革命 | | ⑤ | **自动化** | 规模生产 | 信息革命 | | ⑥ | **AI 智能** | 机器创造 | 智能革命 | | ⑦ ★ | **创造纪元** | 人类表达 | **智能革命** | ``` ① ──▶ ② ──▶ ③ ──▶ ④ ──▶ ⑤ ──▶ ⑥ ──▶ ⑦★ ↑工业革命↑ ↑信息革命↑ ↑智能革命↑ 历史进程 ──▶ ``` *每次跃迁都重新定义了「劳动」的内涵与主体；第⑦阶段是这条演进曲线的质变节点。* 在这条演进曲线上，有一个耐人寻味的循环：人类最早*不从事生产*——他们直接从大自然获取食物和能源，这是第一阶段。而当 AI 可以承担几乎所有基础生活资料的生产之后，人类将*再次不从事生产*——这是第七阶段。 ### 两次「不生产」的本质差异 同样是「不生产」，原因却截然不同。 **图 1-4　两次「不生产」的本质对比** | | 原始社会的「不生产」 | AI 时代的「不生产」 | | -------- | ----------- | ----------- | | **原因** | 匮乏，无法生产 | 充裕，无需生产 | | **状态** | 只能采集，被动依赖 | 主动创造，自我驱动 | | **人类处境** | 生存资料不稳定 | 专注于表达与意义 | | **本质** | **受困于物质不足** | **解放于物质充裕** | *两次「不生产」形式相似，但驱动逻辑完全相反——一个是被迫，一个是自由；一个是物质匮乏，一个是物质充裕之后的主动选择。* 在 AI 智能生产时代完全成熟之后，人类基础生活资料的生产将逐步由 AI 承担。而人类将从事的，是另一种意义上的「工作」——**创造、发明、探索，以及生活本身**。 这不是乌托邦式的懒人设想，而是一次劳动内涵的根本性升级：人类的时间，将从消耗性的重复生产，转向主动性的创造和对未知领域的探索。 *** ## 1.5 结语：创造纪元的来临 综合以上逻辑，可以得出一个清晰的判断： > **核心观点** > > 通用人工智能带给人类信息时代的，是**分发平权之后的生产平权**。 > > 这种双重平权，将改变人类的生产组织方式、知识获取方式，乃至对「工作」本身意义的理解。 > > 它不只是效率的提升，而是一次**文明范式的切换**。 回到麦克卢汉那句话——「人类曾经以采集食物为生，而如今他们重新要以采集信息为生。」 这句话将要成为历史。 不是因为信息变得不再重要，而是因为**人类在信息链路中的位置将会改变**：从被动的消费者和受限的生产者，进化为能够*自由表达、主动创造*的个体。 未来，人类以创造为生。所有人都将投入精力去攻克未知的领域——这是 AI 带来的，一个全新的人类纪元。 *** ## 思考题 **当生成式 AI 把「拍电影」的能力向所有人开放，这个行业真正的稀缺会移向哪里？** 当视听内容的生产门槛持续下降，银幕上的供给不再稀缺，真正的竞争或许会集中在另一件事上：**谁能让一群人，愿意在同一时间、同一空间里，把注意力交给你两个小时。** 如果注意力的动员才是核心稀缺，影院是否会越来越多地向「组织者」而非「散客」收费？粉丝应援场、品牌首映、团体包场——这些今天看来边缘的玩法，会不会成为未来院线收入结构中举足轻重的一极？ **更本质的问题是：** 在一个任何人都能创作的世界里，**不是这片能不能做出来，而是别人为什么要来看？** 你会用什么机制——符号、社群、仪式感，还是别的什么——来回答这个比拍摄更难的问题？ *** *下一节：*[*模型即产品——当模型能力就是产品能力，PM 的角色在哪*](/00-intro/02-mo-xing-ji-chan-pin) # 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 化：软件形态正在发生什么变化** 当模型具备了自主规划与工具调用的能力，软件不再只是响应点击的界面，而是能够主动完成任务的智能体。这一变化，将从根本上重塑产品的交互范式与设计逻辑。 # 3. 产品 Agent 化：软件形态正在发生什么变化 > 从人类掌握电力到电力转化为巨大的生产力，与之配套的基础设施和人类的认知，经历了远比技术本身更漫长的适应周期。 *** 前两节，我们分别从**宏观信息革命的历史坐标**与**产品经理的角色演进**两个维度，探讨了生成式 AI 所引发的结构性变革。如果将视线进一步拉近，聚焦到具体的产品形态本身——这场深刻的生产方式变革，究竟在产品层面催生出了怎样的新范式？AI 时代的互联网产品，正在经历一次怎样的跃迁？ 本节将尝试回答这个问题。需要说明的是：我们仍然处于 AI 产品发展的早期阶段，任何试图总结「终局形态」的论断都过于武断。以下所呈现的，是对当下这一历史节点的阶段性观察与思考框架，而非最终答案。 *** ## 一、从业务实践出发：AI+ 与 +AI 的两条路径 ### 两个方向的起点 2022 年底，我负责 QQ 的 AI 业务，这个命题第一次真实地摆在我面前。我翻遍了市面上所有的 AI 产品，彼时的 LLM 应用还主要以对话（Chat）与 AIGC 内容生成为主，大致形成了两个相对热门的赛道。 其一是**效率工具导向**，以 Notion AI、ChatPDF、X 平台的自动生成推文工具、Jasper.ai 等为代表；其二是 **AI 虚拟社交**，以 Character.ai（Transformer 作者之一创办，团队后被 Google 收购）、Glow（MiniMax 早期产品，后因特殊原因关闭）、小侃星球（百度虚拟偶像产品，叶悠悠和林开开）、Replika（带有角色形象的人物克隆）等为代表。 综合调研结论与实际业务需求，我们最终确认了两个核心方向——**AI+QQ** 与 **QQ+AI**。 **第一个方向：AI+QQ（AI Native 方向）。** 这是一条完全 AI Native 的路径。我们希望通过引入 AI 角色、形象与能力，帮助 QQ 用户建立一个全新的社交关系网络，绕开熟人社交与微信的正面竞争。具体来说，我们希望通过 AI 创建三类核心数字人形态——**情感陪伴**、**游戏互动**、**助手工具**：口语外教（助手工具）帮你通过语音练习英语口语，码云（助手工具）帮你完成编程作业，心情树洞（情感陪伴）供你倾诉情绪，成语接龙（游戏互动）和你来回过招，以及沈思前这样的 IP 形象（情感陪伴）陪你日常聊天。为了快速上线并评测这些数字人，我们专门搭建了 Agent 平台——**女娲**（QQ 自己训练的第一个模型叫 lucy，与女娲的命名也算一个呼应）。 **第二个方向：QQ+AI（Copilot 方向）。** 这是一条在原有场景内用 AI 提效的路径，目标是提升转化与留存。我们将 QQ 内所有场景按重要性与流量规模做了优先级排序。其中最重要的是**小 Q 助手**——可以跨场景帮用户完成各种 QQ 内的任务（QQ 也是国内主流 IM 工具中第一个支持流式输出的产品）。 举其中另一个重要场景为例：**对话**。对话表达有三道真实的门槛：不知道怎么破冰，不知道怎么接话，不知道自己这样说是否得当。借助用户的历史对话风格与期望的表达形式，我们设计了 **AI 聊天助手**（如图为早期版本），帮助用户在具体对话场景中更顺畅地表达与沟通。 ![QQ AI 聊天助手早期版本：根据用户历史对话风格实时生成候选回复，覆盖破冰、接话、表达润色三类核心场景](https://1075808901-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FP0GxMToc5H2sUYqlAcOr%2Fuploads%2Fgit-blob-f67565776a2db2b3131822dc852c60b989449678%2Fqq-ai-chat-assistant.png?alt=media) 以上是一个真实业务在 AI 时代的思考切面。可以看到，其中一部分是**全新的 AI 场景**——这便是 **AI+**：AI 作为服务的核心，原有产品只是提供流量与入口；另一部分则是**原有场景的 AI 增强**——这便是 **+AI**：原有服务依然是核心，AI 是其中的效率增强工具。 **表 1：AI+（AI Native）与 +AI（AI Copilot）战略路径对比** | 维度 | AI+（AI 作为核心） | +AI（AI 作为工具） | | ----------- | ------------------------------------------------ | ------------------------------------------------------ | | **战略定位** | AI 是服务的核心驱动力，原有产品提供流量与入口 | 原有业务依然是核心，AI 是其中的效率与体验增强层 | | **典型形态** | AI 角色/数字人、情感陪伴、智能助手 | 场景内 Copilot、智能搜推、对话辅助 | | **QQ 实践案例** | 数字人平台「女娲」：口语外教、编程助手、心情树洞、沈思前等 AI 形象陪伴，探索全新社交关系网络 | QQ Copilot / 小 Q 助手：跨场景任务执行；AI 聊天助手：根据用户风格辅助对话破冰、接话与表达 | | **核心挑战** | 冷启动难，用户对 AI 关系认知门槛高，留存依赖情感连接深度 | AI 价值感知需嵌入高频场景，改造既有产品架构的工程成本高 | | **竞争护城河** | AI 角色的个性化记忆与情感深度 | 业务场景理解深度 + 数据积累 | ### 从局部实验到行业主流 这两个方向的探索，是一家业务公司在 AI 时代早期最真实的思考切面：*试图用 AI 这把新锤子，去解决旧产品的旧钉子问题*。 随着时间推移，来到 2026 年的今天，AI Native 的产品形态已逐渐成为行业主流。这与电力技术的普及历程高度相似——从技术突破到生产力的大规模释放，中间隔着基础设施、认知范式和组织结构的整体迁移，而这一过程往往比技术本身的演进更为漫长。 {% hint style="info" %} **核心观点** AI 时代的产品命题，不是「要不要做 AI」，而是**如何找到 AI 能力与业务价值之间的最优耦合点**。 AI+ 与 +AI 并非对立，而是在产品不同阶段、不同场景下，各有其适用的生命周期与战略逻辑。 真正的陷阱，是将 AI 视为万能钥匙，而非将其视为一种**需要被精心匹配的能力资源**。 {% endhint %} *** ## 二、AI Agent 产品的三种形态 跳出 QQ 这一具体业务的视角，将视野拓宽至整个行业，可以观察到：当下所有 AI Agent 产品，本质上都可以归为**三种相互递进的产品形态**。这是一个历史阶段性的归纳——它反映当下，而非终局。 这三种形态，分别承担着不同的产品逻辑与价值定位： * **范式一：LUI 分发产品**——以自然语言为新的分发管道，分发的依然是**原有的服务供给**； * **范式二：Copilot 内容生成与操作执行**——在原有业务场景中，用 AI 实时**生成内容**或**执行操作**，替代既有的规则体系； * **范式三：AI Native 产品**——人类不再是生产的主角，**AI 主导生产**，人类只出现在意图发起与结果验收的两端。 为便于读者快速建立整体框架，本节先以一张总览表呈现三种范式的核心差异，随后再分章详细展开每一种范式的产品逻辑与设计要点。 **表 2：AI 产品三种范式的核心特征对比** | 维度 | 范式一：LUI 分发 | 范式二：Copilot 生成与执行 | 范式三：AI Native | | --------- | ------------------------- | ---------------------------------------------- | --------------------------------- | | **核心交互** | 自然语言对话 / 消息流 | 场景内嵌入式生成与执行 | 持续监听 + 主动执行 | | **服务逻辑** | 被动响应用户输入 | 被动增强现有服务质量 | 主动预判并提前执行 | | **分发对象** | 仍是原有的服务供给 | 在原有场景中加载 AI 能力 | AI 直接生产，无需中间供给方 | | **内容形式** | 文本 / 多模态消息 | 生成内容 / 操作动作嵌入既有界面 | 代码、指令，操控硬件与系统 | | **在线状态** | 会话期内在线 | 场景使用时在线 | 7×24 小时持续在线 | | **生产主角** | 人类（既有服务供给方） | 人类为主，AI 为辅 | **AI 主导生产，人类只出现在末端** | | **典型产品** | ChatGPT、Perplexity、小 Q 助手 | Keep AI 陪跑、Notion AI、GitHub Copilot、Midjourney | Codex、Manus、Cursor Agent、未来的个人 OS | | **AI 角色** | 信息分发与任务调度中枢 | 内容生产 + 操作执行的辅助层 | 自主行动的智能体 | | **当前成熟度** | 商业模式初步验证 | 相对成熟，广泛落地 | 早期探索，局部可用 | *** ## 三、范式一：LUI 分发产品 LUI 分发是当下 AI Agent 产品中落地最广、共识最多的一类形态。它的本质，是**用自然语言这一新介质，重构信息与服务的分发方式**——而非仅仅「做了一个聊天窗口」。本章将从交互范式的演进出发，逐步阐明 LUI 分发产品的本质、价值边界与服务架构。 ### GUI 到 LUI：交互介质的根本转变 要理解当下 AI 产品形态的变化，必须先理解人机交互方式的底层逻辑。 Windows 时代的伟大发明之一，是鼠标与 GUI（图形用户界面）。GUI 将人机交互带入了全新的高度——用户通过点选、拖拽、双击等操作，以**视觉空间**为隐喻，触发计算机完成各类任务。此后数十年，产品设计的核心命题，始终是**如何在有限尺寸的屏幕上，构建出高效流动、易于操作的信息界面**。 进入 AI 时代，这一范式正在被根本性地替换。人机交互的核心介质，从 GUI 转向了 **LUI（Language User Interface，语言用户界面）**。 **图 1：GUI 到 LUI 的交互范式迁移** | 维度 | GUI 时代 | →（范式迁移）→ | LUI 时代 | | -------- | ----------- | -------- | ----------- | | **外设** | 鼠标、键盘、触控 | | 自然语言（含语音） | | **操作语言** | 点击、滑动、双击 | | 语义意图表达 | | **产品核心** | 信息架构 + 交互流 | | 意图理解 + 服务编排 | | **分发方式** | 推荐算法 + 手势滑动 | | 生成算法 + 语言输入 | | **用户记忆** | 界面路径的肌肉记忆 | | 意图表达的语言习惯 | | **内容生产** | 规则体系 + 供给匹配 | | 服务结果 + 语言包装 | > *结构角色类比：* 推荐算法之于 GUI 的角色，类似生成算法之于 LUI；手势操作之于 GUI，类似语言输入之于 LUI——**这是结构角色的映射，而非技术上的等价**。 ### LUI 的本质：不是对话，而是新的分发管道 理解 LUI 的关键，在于**不要将其窄化为「聊天窗口」或「对话机器人」**。这是一种常见却危险的认知误区。 LUI 的本质，是*人类未来获取信息与服务的新通道*：以自然语言作为原始输入协议，以生成内容作为输出协议，以消息流替代过去的信息流。 从**结构角色**的视角来看，可以做一个有益的类比映射： | GUI 时代 | ↔ 结构角色类比 ↔ | LUI 时代 | | ------ | ---------- | ------- | | 推荐算法 | | 生成算法 | | 滑动操作 | | 语言输入 | | 短视频信息流 | | LUI 消息流 | 需要特别说明的是，这一类比描述的是**结构角色**的相似性，而非**分发对象**的等价。两者存在根本差异：*推荐算法分发的是已有的存量内容*——视频、商品、文章等由平台预先生产的供给，用户在结果中被动消费；而 *LUI 中的生成算法，分发的本质是「服务」而非「内容」*——通过理解用户意图，对底层既有的搜索、电商、日历、第三方 API 等传统服务做编排与组织调度，所谓的「生成内容」，本质上只是对服务执行结果的**语言化包装**，而非凭空创造的新供给。 换句话说，今天市面上绝大多数 chatbot 类产品，其真正的产品命题并不是「让 AI 写出更好的文字」，而是：**用自然语言这个新的统一入口，对原本散落在各处的服务做意图理解、编排与重新分发**——这才是 LUI 之所以是**分发管道**的真正含义。 在 LUI 时代，传统的服务供给体系将演变为下游的工具层（Tools/Skills/Sub-agents），以**被动式 Agent** 的形式接受调度。然而，这一范式同时带来了一个无法回避的核心挑战： > **LUI 的分发效率，真的优于既有的搜推体系吗？** > > 除知识问答场景外，LUI 无法凭空创造业务供给——它的分发效率，仍然依赖于现有供给的质量与丰富度。这正是大量企业做了 Chatbot 却未能获得实质业务收益的根本原因。 ### LUI 的场景价值判断 并非所有业务场景都适合以 LUI 作为主路径。要做出理性的场景判断，需要沿**任务复杂度**与**业务模块跨度**两个维度，对业务场景进行系统性分类。 **表 3：LUI 适用性分析——业务场景分类矩阵** | 场景类型 | 典型特征 | GUI 的局限性 | LUI 价值评估 | | ------------- | --------------------------- | -------------------------------------- | ----------- | | **单业务单步** | 单一页面内的单次操作，路径清晰，用户已有肌肉记忆 | 基本无局限，效率已高度优化 | 价值有限 | | **单业务多步** | 同一业务场景内的多步骤组合操作，涉及个性化约束 | 无跨步骤上下文记忆；无法处理自然语言表达的复合约束；无法直接操作最终结果 | **高价值场景** | | **多业务多步** | 跨越多个业务模块的联合任务，需要跨维度推理 | 各模块相互独立，无法跨场景联合推理；依赖用户手动串联多个入口 | **最高价值场景** | | **探索性/开放性需求** | 用户本身尚不清楚自己想要什么，需要在交互中逐步收敛目标 | GUI 依赖用户提前知道自己要点什么入口；开放性意图在固定导航结构中无处着落 | **独特高价值场景** | {% hint style="info" %} **核心观点** 如果你的核心业务场景中，**多步操作、跨模块推理、探索性开放意图**三类需求占比均不高，强行将 Chatbot 设置为主路径，将造成明显的使用摩擦，反而拉低整体产品效率。 LUI 入口，应在 GUI 触达不到的场景中**自然生长**，而非作为流量漏斗的顶层被强制推广。 判断 LUI 价值的核心标准，始终是：**它是否真正解决了 GUI 难以解决的问题？** {% endhint %} **图 2：LUI 分发适用性判断框架** ``` ┌──────────────────────────┐ │ 业务是否存在大量多步操作？ │ └────┬─────────────────┬───┘ 否 │ │ 是 ┌───────────▼────┐ ┌────────▼─────────────┐ │ 是否存在探索性 │ │ 是否存在跨模块联合 │ │ 开放意图需求？ │ │ 推理需求？ │ └─┬───────────┬──┘ └────┬──────────────┬──┘ 否│ 是│ 否 │ 是 │ ┌────────▼─┐ ┌──────▼────────┐ ┌─▼──────────┐ ┌─▼──────────────┐ │ 不建议以 │ │ LUI 探索场景 │ │ LUI 高价值 │ │ LUI 最高价值 │ │ LUI 作 │ │ 价值：开放意图 │ │ 场景：单业务 │ │ 场景：跨业务 │ │ 主路径 │ │ 收敛入口 │ │ 多步 Copilot│ │ Agent 入口 │ │（保持 GUI │ │ │ │ │ │ │ │ 高效路径）│ │ │ │ │ │ │ └──────────┘ └──────────────┘ └────────────┘ └────────────────┘ ``` > 在多步操作与跨模块推理之外，**探索性/开放意图场景**是 LUI 的第三类独特价值场景。 ### LUI 产品的服务分发架构 在明确了 LUI 的本质与价值场景之后，我们可以进一步将 LUI 分发产品的内部结构抽象为一个清晰的分层架构：最上层是用户的自然语言意图输入，中间是负责意图理解、任务规划与上下文管理的 **LUI 核心层**，再往下则是服务调度层（Tool Calling / Function Calling），传统的服务供给体系——搜索、电商、日历、第三方 API 等等——均在其下沉为下游的工具层（Tools / Skills / Sub-agents），以**被动式 Agent** 的形式接受调度。 > 不要把 LUI 产品理解为「做了一个聊天窗口」。 > > 真正的命题是：**人类将通过消息流获取所有信息与服务，通过自然语言完成所有交互**——这是分发逻辑的底层替换，其影响深度不亚于搜索引擎的出现。 **图 3：LUI 产品的服务分发架构** ``` ┌────────────────────────────────────────────────┐ │ 用户意图输入（自然语言） │ └───────────────────────┬────────────────────────┘ │ ┌───────────────────────▼────────────────────────┐ │ LUI 核心层：意图理解 · 任务规划 · 上下文管理 │ └───────────────────────┬────────────────────────┘ │ ┌───────────────────────▼────────────────────────┐ │ 服务调度层：Tool Calling / Function Calling │ └─┬────────┬─────────┬──────────┬──────────┬─────┘ │ │ │ │ │ ┌──▼──┐ ┌──▼──┐ ┌────▼───┐ ┌───▼────┐ ┌───▼─────┐ │搜索 │ │电商 │ │ 日历 │ │ 内容 │ │第三方 │ │服务 │ │购物 │ │ 任务 │ │ 生成 │ │ API │ └─────┘ └─────┘ └────────┘ └────────┘ └─────────┘ ↓ 下游 Skills / Tools ↓ ``` > 意图理解层居中调度，传统服务供给降级为可组合的下游工具层。 *** ## 四、范式二：Copilot 内容生成与操作执行 Copilot 模式的本质，是**在原有的业务场景中，用 AI 实时生成内容、或代用户执行操作**——通过这两种能力替代过去基于规则的体系，将服务的个性化深度和场景渗透度同步拓宽。 具体来说，Copilot 包含两种相互支撑的能力形式： | Copilot 能力类型 | 典型场景 | 替代的原有逻辑 | | -------------- | ---------------------------------------------------------------------------------- | -------------------- | | **内容生成（AIGC）** | Keep AI 陪跑教练实时生成语音指导；Notion AI 生成文档草稿；QQ AI 聊天助手生成回复候选；数据报表的 AI 摘要解读；简历筛选的 AI 评分意见 | 固定模板 / 预设规则 / 人工阅读总结 | | **操作执行** | GitHub Copilot 代码补全并自动应用；邮件自动起草并归类；浏览器中 AI 自动填表与表单提交；办公软件中 AI 直接修改文档内容 | 重复性手工操作 / 固定脚本调用 | 需要说明的是，无论是**分析辅助**（帮你读懂数据）还是**决策辅助**（帮你权衡选项），其本质仍然是*生成解读内容、生成决策建议*——这些都属于内容生成（AIGC）的延展，并非独立的 Copilot 能力类型。Copilot 模式真正的二元结构，是**生成内容**与**执行操作**。 以 Keep App 为例：当用户进行跑步训练时，AI 陪跑教练能够基于实时运动数据生成个性化语音指导；当用户打开一节课程时，AI 教练可根据用户的身体状态和历史训练数据，对动作要领和课程难度进行实时微调。 这一模式与业务场景高度耦合，是 AI 能力为传统业务赋能最直接、落地收益最可感知的路径。其价值不在于颠覆原有产品逻辑，而在于**用 AI 生成与执行能力替换规则体系，从根本上解锁个性化服务的深度上限**。 **表 4：Copilot 模式的典型场景与核心价值矩阵** | 行业 | 典型产品 | AI 替换的规则体系 | 核心价值增量 | | ---- | -------------- | -------------- | ----------------- | | 健身运动 | Keep AI 陪跑教练 | 固定语音包 / 预设课程结构 | 实时个性化指导，提升训练效果与留存 | | 代码开发 | GitHub Copilot | 代码模板 / 文档搜索 | 上下文感知的代码补全，提升开发效率 | | 文档写作 | Notion AI | 模板匹配 / 格式规则 | 基于语义的内容生成与结构优化 | | 即时通讯 | QQ AI 聊天助手 | 表情包推荐 / 话题引导 | 基于用户风格的个性化表达辅助 | | 内容平台 | 智能摘要 / 个性化推送 | 关键词标签 / 规则过滤 | 深度语义理解，提升内容匹配精度 | Copilot 模式与既有业务的结合，本质上是一次**产品能力密度的提升**，而非产品形态的颠覆。它也因此成为当下 AI 落地最广泛的范式——改造成本相对可控，用户心智迁移成本低，业务收益可快速量化。 *** ## 五、范式三：AI Native 产品 在正式讨论 AI Native 的形态之前，有一个认知前提值得单独强调： > **代码，不是一种技术，而是人类与机器对话的语言协议。** > > 理解了这一点，才能理解 AI Native 产品两大核心特征的真正含义。 AI Native 的根本判别标准，可以归结为一句话：**在生产链路中，人类不再是生产的主角，AI 才是**。人类只出现在链路的末端——发起意图、验收结果——中间所有的生产、执行、决策由 AI 主导。这一标准在产品形态上，对应两个不可分割的结构特征： **图 4：AI Native 产品的两大核心特征** ``` ┌─────────────────────────┐ ┌─────────────────────────┐ │ 7×24h 主动服务 │ │ 输出主体为代码 │ │ │ │ │ │ 模型永远在线 │ │ 通过机器语言（代码） │ │ 持续监听与思考 │ │ 操作物联网设备 │ │ 不再依赖人类输入触发 │+ │ 与各类硬件 │ │ 靠自己的理解 │ │ │ │ 提前预知并主动满足 │ │ 不再只是人类电脑、 │ │ 人类需求 │ │ 手机里的玩具 │ └────────────┬────────────┘ └────────────┬────────────┘ │ │ └──────────────┬─────────────┘ ▼ ┌─────────────────────────────────────────┐ │ ⇒ AI 主导生产，人类仅出现在末端 │ │ ——真正的 AI Native │ └─────────────────────────────────────────┘ ``` **7×24h 在线**意味着模型始终处于监听与推理状态，不眠不休；**主动服务**意味着模型不再被动等待人类输入指令，而是基于对用户状态的持续理解，提前预知并满足需求；**输出主体为代码**意味着模型通过机器语言，直接操控物联网设备、智能硬件与各类数字基础设施——不再只是停留在屏幕上供人类阅读的文字内容。 把这三点放在一起，可以看出 AI Native 与前两种范式的根本差异： | 维度 | LUI 分发 | Copilot 增强 | AI Native | | -------- | ----------- | ----------- | ---------------- | | **生产主角** | 人类（仍是供给生产者） | 人类（AI 为辅助） | **AI（人类只出现在末端）** | | **触发模式** | 用户主动发起 | 用户在场景中触发 | **AI 主动预判** | | **输出形态** | 自然语言响应 | 内容生成 / 操作执行 | **代码 ⇒ 操控硬件设备** | 不满足上述两大特征的产品，本质上仍是前两种范式的变形——即便它们也由大模型驱动。换句话说，今天的大多数所谓「AI 产品」，都尚未真正进入 AI Native 的边界。 *** ## 六、三种范式的演进关系 ### 不是替代，而是递进 理解这三种范式的关键，在于认识到它们并非相互替代的竞争关系，而是**技术成熟度与产品形态递进**的三个发展阶段。 **图 5：三种 AI 产品范式的演进关系** ``` AI 作为入口 AI 作为工具 AI 作为主体 ┌─────────┐ 能力 ┌─────────┐ 形态 ┌─────────┐ │ LUI │ 深化 │ Copilot │ 跃迁 │ AI │ │ 分发 │ ──────▶│ 生成 │ ──────▶│ Native │ │ │ │ │ │ │ │被动响应 │ │场景嵌入 │ │主动服务 │ │语言交互 │ │生成替代 │ │代码操控 │ │入口 │ │规则 │ │世界 │ └─────────┘ └─────────┘ └─────────┘ 当前主流落地形态 场景增强首选路径 终极形态的雏形 商业模式初步跑通 对既有产品改造最小 仍处于早期探索期 ``` > 从 LUI 分发入口，到 Copilot 场景增强，再到 AI Native 主动行动，AI 在产品中的角色持续深化。 ### 当前的阶段性判断 以今天（2026 年）的技术与市场格局来看，三种范式的发展状态可以概括如下： | 范式 | 当前状态 | 主要制约因素 | | -------------- | ---------------------------------------------------------------------------- | -------------- | | **LUI 分发** | 商业模式初步跑通（ChatGPT、Perplexity 等），但分发效率与信息密度相较搜推体系仍存在差距；「为何要来和 AI 聊天」的用户动机教育成本高 | 分发效率、供给质量 | | **Copilot 生成** | 落地案例最为丰富，业务改造成本可控；在代码（GitHub Copilot）、文档（Notion AI）、搜推（各平台 AIGC 模块）等场景均有成熟实践 | 场景识别准确率、生成内容质量 | | **AI Native** | 以 Codex、Manus、Cursor Agent 等为代表的早期产品已初步验证可行性；但大规模生产级可靠性仍待突破，完全的自主行动能力尚未成熟 | 推理可靠性、长链路执行稳定性 | {% hint style="info" %} **核心观点** 我们仍处于 AI 产品形态演进的早期。 历史告诉我们：从电力的发明到电力真正重塑生产方式，中间经历了数十年基础设施与认知范式的协同演进。 AI 的轨迹或许相似——**技术突破只是起点，真正的变革将在产品范式、组织结构与用户认知的共同迁移中完成**。 产品经理的任务，是在这场迁移中找到当下最值得押注的那个点。 {% endhint %} *** {% hint style="warning" %} **思考题** 亲身体验 [Multica](https://multica.ai/)（`https://multica.ai/`）： **当产品形态发生根本变革，AI 时代的组织分工将如何演化？** {% endhint %} *** *下一节 · 第零章第四节* **AI PM 的能力模型：一个有战斗力的 AI PM 长什么样** 理解了产品形态的根本变革，下一步要回答的问题是：在这个新的产品范式下，**什么样的产品经理才真正具备战斗力？** # 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 产品经理天花板的核心变量，已经彻底改变了**。 {% hint style="info" %} **核心观点** AI 时代，评价一个产品经理是否有战斗力的核心标准，不再是能否画出漂亮的原型图，而是能否**把不确定的模型能力，转化为可交付、可评估、可迭代、可商业化的产品能力**。 这是一个更高维度的命题，它要求产品经理同时具备**领域深度、技术理解、验证能力与沟通能力**。 {% endhint %} *** ## 二、五维能力模型：有战斗力的 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 产品的行为，*依赖于编排层对模型行为的有效约束*。产品经理如果无法设计出有效的编排策略，就无法将模型的「统计概率」转化为用户可信赖的「产品确定性」。 {% hint style="info" %} **核心观点** 编排管理能力的本质，是**在不确定中建立确定**。 大模型的输出本质上是概率分布，而产品需要向用户提供确定的交付承诺。 弥合这两者之间差距的核心机制，正是**状态驱动的编排管理**——将无限可能的用户意图，收拢到有限的系统状态，通过状态转移逻辑定义产品的行为边界。 {% endhint %} *** ## 六、动手实现能力：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 解决方案 | **极高** | **高** | **高** | **高** | **极高** | ### 一个综合判断的框架 但无论权重如何分布，有一个底线是明确的： {% hint style="info" %} **核心观点** 有战斗力的 AI PM，在五个维度上不能有**明显的空白项**。 * **领域知识** 决定你能否看懂用户的真实需求； * **架构协议** 决定你能否把需求转化为可工程化的系统设计； * **编排管理** 决定你能否在不确定的模型能力上构建确定性的产品体验； * **动手实现** 决定你能否在提需求之前先自己验证想法的可行性； * **沟通表达** 决定你能否让整个团队理解并认同你的产品方向。 缺少任何一个，都会在产品落地的某个关键环节形成**系统性短板**。 {% endhint %} **表 3：AI PM 五维能力成熟度矩阵** | | 领域知识 | 架构协议 | 编排管理 | 动手实现 | 沟通表达 | | ---------- | -------------- | ------------ | ----------------- | ----------------- | ------------- | | **初阶（入门）** | 了解特定领域基础知识 | 能画出模块关系图 | 能描述业务流程与分支逻辑 | 能调用 API 跑通基础 Demo | 能清晰表达产品意图 | | **进阶（熟练）** | 能构建并评分领域评测集 | 能定义接口协议与数据结构 | 能设计状态图实现确定性效果 | 能独立完成离线评测脚本 | 能将 AI 业务翻译给各方 | | **高阶（专家）** | 能识别领域里模型的边界与盲区 | 能主导系统级架构决策 | 能设计多 Agent 协作编排方案 | 能从零搭建 MVP 产品原型 | 能建立团队共识推动组织对齐 | *** ## 九、结语 AI 时代，产品经理面临的最大挑战，不是「会不会用 AI 工具」，而是**在模型行为天然不确定的前提下，如何对产品结果负责**。 这五个维度，给出的正是这个问题的答案。它们不是独立的技能点，而是一套相互支撑的判断链路： * 领域知识决定你能不能看清问题； * 架构协议决定你能不能把问题建模清楚； * 编排管理决定你能不能让模型稳定工作； * 动手实现决定你的判断有没有事实依据； * 沟通表达决定你的判断能不能被执行。 五个维度缺一不可，因为它们对应的是同一件事的五个环节：**把一个模糊的 AI 能力，变成一个确定可交付的产品**。 {% hint style="info" %} **核心观点** **AI PM 的新门槛是：** * 懂领域，能判断模型是否真的解决问题； * 懂架构，能把业务抽象成系统对象； * 懂编排，能让不确定的模型产生稳定效果； * 能动手，能用 Demo 和评测证明判断； * 会表达，能跨越人与模型之间的理解鸿沟。 最终，**AI PM 的价值不在于「会用 AI」，而在于能把 AI 变成产品、业务和商业结果。** {% endhint %} > Claude Code 负责人 Boris Cherny：「going to be a product manager and everyone」（我要成为产品经理，所有人都会） *** {% hint style="warning" %} **思考题** **用这五个维度，给自己做一次诚实的评分。** **领域知识：** 你当前负责的产品，你能独立构建并评分一套领域评测集吗？如果不能，你的领域知识深度距离「专家」还差多远？ **架构协议：** 你最近一次写的 PRD，有没有清晰地定义模块的 Input/Output 和通信协议？还是只是一份「功能列表」？ **编排管理：** 你有没有为自己负责的 AI 产品画过一张完整的状态图？能否清楚地说出在哪些状态下，模型应该做什么？ **动手实现：** 最近一次你提出的产品想法，你有没有先自己跑过 Demo？还是直接丢给工程师去探索可行性？ **沟通表达：** 上一次你向非技术同事解释 AI 产品的局限性时，对方真的听懂了吗？ **找到你评分最低的那个维度——从那里开始改变。** {% endhint %} *** *下一节 · 第零章第五节* **AI PM 的工具箱：以产出倒逼工具，让 AI 把你变成超级人类** 从「AI 是小弟」到「AI 是延伸」的思想转化、三类核心产出（图表原型 / 产品 demo / 线上服务）、以及对应的工具组合——一篇就讲清楚 AI PM 每天该用什么。 # 5. AI PM 的工具箱：以产出倒逼工具，让 AI 把你变成超级人类 > 欲善其工，必先利其器。工具是人能力的延伸，工具可以让人发挥远超过自身的价值。 *** 前四节，我们分别探讨了**信息革命的宏观坐标**、**模型即产品的范式跃迁**、**产品 Agent 化的形态变化** 与 **有战斗力的 AI PM 的能力模型**。这些讨论回答的是\*「是什么」*与*「为什么」\*。 本节要回答的是最具体的一个问题——**在 AI 时代，一个产品经理每天到底应该用什么工具**。 *** ## 一、重新理解工具：AI 不是小弟，是延伸 ### 思想转化：你 + AI = 超级人类 对于一个 AI 产品经理来说，第一个重要的工具一定是 AI。但更重要的，是**从思想上完成一次彻底的转化**。 很多人总是想「驾驭 AI」——把 AI 当作自己的小弟，安排 AI 做自己不想做的琐碎小事情。这背后的潜台词是：*我才是主角，AI 是工具，AI 在帮我提效*。 但这种认知在大部分场景下，并没有承认一个根本事实：**AI 是远强于你的超级物种**。AI 能做你不会做的事情，能在你完全不熟悉的领域里给出专业级别的产出，能把你的能力*延展*到你原本无法触达的边界。 {% hint style="info" %} **核心观点** 不是 AI 帮你完成你的工作，让你变得更快； 而是**你 + AI = 超级人类**，你借助 AI 完成了你单独无法完成的事情。 **你 + AI ≠ 更快的你。** {% endhint %} **图 1：两种工具观的根本差异** ``` ┌──────────────────────┐ ┌──────────────────────┐ │ 小弟视角（错误） │ │ 延伸视角（正确） │ ├──────────────────────┤ ├──────────────────────┤ │ 你 + AI = 更快的你 │ 思想 │ 你 + AI = 超级人类 │ │ │ ──────▶ │ │ │ • 我是主角，AI 是工具 │ 转化 │ • AI 是远强于你的 │ │ • AI 帮我做琐碎的事 │ │ 超级物种 │ │ • AI 能力 ≤ 我的能力 │ │ • AI 做你不会做的事 │ │ • 收益线性：节省时间 │ │ • AI 能力 > 你的能力 │ │ │ │ • 收益指数：能力延展 │ ├──────────────────────┤ ├──────────────────────┤ │ 天花板：你自己的能力上限│ │ 天花板：AI 能力的边界 │ └──────────────────────┘ └──────────────────────┘ ``` ### 为什么这一节迟迟没有写 这一小节迟迟没有动笔，是因为**工具的迭代更新速度太快了**。而且，大部分人都有自己的工具偏好。如果你给出一个工具的「唯一正确性」答案，肯定会有很多人从很多角度去反驳，而且他们的反驳都是有道理的。 所以阅读这一节，请始终记住一个原则： > **最好的工具是下一个工具。** > > 当前讲的工具，都是*狭义上、当前可能有一定参考意义*的工具。 *** ## 二、以产出倒逼工具：三个产出，三套工具箱 ### 为什么要从产出出发 工具的种类太多，列表式的工具盘点很容易迷失在细节里。所有的工具都是服务于你的产出的，所以我们**需要从产出来倒逼工具**——*先想清楚要交付什么，再决定用什么*。 对一个 AI 产品经理来说，每天工作的核心产出可以收拢为三类： * **产出一**：能讲明白需求的**图表和原型**（沟通载体）； * **产出二**：一个可以**实际使用的产品 demo**（验证载体）； * **产出三**：人人可体验可反馈的**线上服务**（迭代载体）。 这三类产出，分别对应三套工具箱。后续整节内容，都会沿着这条主线展开。 **图 2：AI PM 工具箱全景图** ``` 从沟通 ──▶ 验证 ──▶ 上线 ▲ │ ┌──────────────────────────────────────────────────┐ │ │ 产出一：图表 & 原型 │ │ │ 两图一表：原型草图 | 流程/状态图 | 数据表 │ │ │ 工具示例：Excalidraw | Figma | Mermaid | │ │ │ 飞书文档 | Notion | 任意表格工具 │ │ └──────────────────────────────────────────────────┘ │ │ ┌──────────────────────────────────────────────────┐ │ │ 产出二：产品 demo │ │ │ 24h 协同伙伴 + 模型 API：让想法在小时级别变成可体验产品 │ │ │ 工具示例：Codex | Cursor | Claude Code | │ │ │ OpenAI/Claude/Gemini API Key | 自部署 GPU │ │ └──────────────────────────────────────────────────┘ │ │ ┌──────────────────────────────────────────────────┐ │ │ 产出三：线上服务 │ │ │ 一键部署 + 持续反馈：从本地 demo 升级为人人可访问的服务 │ │ │ 工具示例：Vercel | Cloudflare | Render | │ │ │ Hugging Face Spaces | 公司内部云平台 │ │ └──────────────────────────────────────────────────┘ ▼ ``` *** ## 三、产出一：能讲明白需求的图表和原型 ### 从「补齐 corner case」到「面向 AI 的表达」 在 AI 时代，我们依然需要一个能**讲明白需求的文档和原型**。但是大部分产品经理可以*从以前的很多 corner case、边界值定义里面释放出来*。 想得全，其实是一种**补齐的能力**，但补齐不是产品最有价值的地方——当面对的是一个能自己推理、能自己泛化的大模型时，PM 的价值不在于把每一个分支都写满，而在于**把核心意图、核心约束、核心评价标准说清楚**。 产品经理未来需要构建**面向 AI 的需求和原型表达能力**。我把第一个工具集合，称之为\*\*「两图一表」\*\*。 **图 3：「两图一表」的结构与本质** ``` ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ 图一 │ │ 图二 │ │ 一表 │ │ 原型草图 │ │ 流程/状态图 │ │ 数据表 │ │ │ │ │ │ │ │ 快速草绘 │ │ 讲明白数据流转 │ │ 当前需求的 │ │ 突出模块和序 │ │ 讲明白业务模式 │ │ 分析数据 │ │ 表达"心中构想" │ │ pipeline │ │ 转化率/漏斗 │ │ │ │ 状态边界 │ │ 让 AI 理解业务 │ │ Axure/Figma │ │ Mermaid │ │ Excel/Numbers │ │ /Sketch │ │ /draw.io │ │ /Notion │ │ │ │ /飞书文档 │ │ /数据看板 │ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ │ │ └──────────────┐ │ ┌──────────────┘ ▼ ▼ ▼ ┌──────────────────┐ │ 本质： │ │ 高质量的 Prompt │ └──────────────────┘ ``` ### 两图一表，分别讲什么 **图一**指的是：**快速草绘原型图**——非常简单但是能表达明白你心中构想的原型图，*重点突出模块和序*。不需要像素级精致，不需要交互完整，只需要让看的人（包括 AI）一眼明白「哪里有什么、先后是什么」。 **图二**指的是：**流程图或者状态图**——能讲明白*数据流转的 pipeline、业务的模式*。这一类图回答的是「事情怎么跑起来」的问题，是从静态结构到动态行为的桥梁。 **一表**指的是：**数据表**——产品需要提供*当前需求的分析数据、转化率等等*，让 AI 可以快速理解**业务现状和问题**、业务中面临的**漏斗关系**等等。没有数据的需求文档，对 AI 而言是「无脚本的演员」，它不知道要往哪里发力。 ### 两图一表的本质：高质量的 Prompt 但是这些都是**中间过程**，是当下产品经理能快速和 AI 交互的 prompt 的形式。 {% hint style="info" %} **核心观点** 「两图一表」的**本质**是一种高质量的 Prompt， 或者说——你内心**真实的想法、评价标准**，能够快速让 AI 理解你。 图和表只是中间载体。一旦 AI 理解了，**这些载体的价值就完成了使命**。 {% endhint %} ### 工具选择：任意趁手都行 在这个环节，**任意的画图工具、表格工具、原型绘制工具都可以**。不必纠结「哪个最专业」——这一层的工具差异，远远小于你思考清晰度的差异。 **表 1：「两图一表」常见工具速查（仅为参考，并非唯一正确）** | 产物类型 | 典型工具 | 使用场景 | 成本 | | --------- | -------------------------------- | ----------------------------- | ------ | | 原型草图 | Axure / Figma / Sketch | 头脑风暴、与 AI 描述心中构想、跨职能初稿沟通、需求评审 | 免费 / 中 | | 流程图 / 状态图 | Mermaid / draw\.io / 飞书文档 | 描述业务 pipeline、状态机、Agent 编排 | 免费 / 低 | | 数据表 / 看板 | Excel / Numbers / Notion / 内部 BI | 漏斗、转化率、对照实验、效果评测 | 免费 / 中 | *** ## 四、产出二：一个可以实际使用的产品 demo ### 你需要一个 24h 在线的协同伙伴 第二类产出，是**一个可以实际使用的产品 demo**。这一层，你需要的不再是画图工具，而是**生产工具**。 具体来说，你需要一个**强大的 24h 在线的协同合作伙伴**，它能让你的想法快速变成产品，可以随时修改和体验。强力推荐三类工具任选其一：`Codex`、`Cursor`、`Claude Code`。 它们的共同特征是： * 自然语言驱动，不需要你写每一行代码； * 多文件、多步骤的工程能力； * 与 IDE 或 Terminal 深度集成，所见即所得。 借助它们，**从想法到现实，可以在小时级别完成**。然后快速迭代——所有后续的环节是\*\*「需求即生产」\*\*：一边提需求，一边就在生产。 **图 4：「需求即生产」的循环** ``` 产生想法 （业务/用户洞察） │ ▼ 立即体验 ◀───────────▶ 描述给 AI （自己+小范围） （自然语言 prompt） ▲ │ │ 需求即生产 ▼ │ Need = Build 小时级产出 │ （可运行的 demo） └─────────◀──────────┘ ``` ### 除了协同伙伴，还需要 API Key 除了工具伙伴，你还需要自己**准备几个效果不错的大模型 API Key**。 所有的事情*不能终止于纸上谈兵*。我们使用 AI 构建的产品也是 AI 的，所以里面肯定需要用到很多模型能力——不管是**语音和图像的生成**，还是**多模态的理解**。 {% hint style="info" %} **核心观点** **每个 AI 产品经理，都必须有自己的大模型 API Key。** 它和你手中的电脑一样重要。 甚至有很多人自己直接**买了 GPU 显卡，自己部署自己的模型**——这是更高级的要求了。 {% endhint %} **工具卡：常见组合速查（仅供参考）** * **协同伙伴：** `Cursor`（IDE 集成）/ `Claude Code`（Terminal 原生）/ `Codex`（CLI 与 IDE） * **对话与推理：** `Claude Sonnet/Opus` / `GPT 系列` / `Gemini` / `DeepSeek` / 国内大模型 API * **多模态：** `GPT-4o/4.1` / `Gemini` / `Qwen-VL`（图像、语音、视频理解） * **生成模型：** `DALL·E` / `Midjourney API` / `Stable Diffusion` / `Suno`（音频） * **自部署进阶：** `vLLM` / `Ollama` / `LM Studio` + 自购 GPU（如 RTX 4090 / H100） ### 工具是能力的物理载体 这里讲的「产品 demo」，正是\*\*第四节「动手实现能力」\*\*的工具落点。**能力是肌肉，工具是器械**——没有 `Cursor` 这一类协同伙伴，「动手实现」的门槛会高得让大部分 PM 望而却步；但有了它们，门槛被显著降低，*动手与否，完全取决于你的意愿*。 *** ## 五、产出三：线上服务，你的 demo 人人可体验可反馈 ### 第三步：很多 PM 还没涉及 从第三步开始，**就是很多产品经理现在还没有涉及到的领域**——你需要拥有**一个云服务平台的权限**，把你的想法**发布出去**。 > 想法要**及时地分享**，吸收大家的反馈，然后不断地迭代。 > > 如果生产出来的产品只是在你自己的电脑上，不能快速地去分享、部署、变成人人可以访问的服务，那么效率就会很慢。 > > 要**快速发布**、**快速上线**、**快速让大家去体验**。 **图 5：从本地 demo 到线上服务的链路** ``` ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ 本地 demo│ ──────▶ │ 一键部署 │ ──────▶ │ 线上服务 │ ──────▶ │ 收集反馈 │ │ 只在你 │ │ 推送到云 │ │ 人人可 │ │ 真实用户 │ │ 电脑跑 │ │ │ │ 访问 │ │ 行为 │ └─────────┘ └─────────┘ └─────────┘ ────┬────┘ ▲ Vercel/ URL/ │ │ Cloudflare/ 小程序/ 埋点+反馈 │ Render/ App +评测 │ 内部平台 │ └──────────────────── 驱动新一轮迭代 ◀──────────────────┘ ⚠ 合规提醒：如果是企业业务，请使用公司内部服务，避免数据外流引发的合规风险 ``` ### 为什么「上线」是 PM 的能力分水岭 线上服务这一步，看似是工程师/运维的活，但在 AI 时代，它正在成为**PM 个人能力的一道分水岭**。 原因有三： **1. 反馈速度决定产品速度。** demo 在你电脑上时，反馈来源只有你一个人；demo 在线上时，反馈来源是**所有体验过它的人**。反馈量级的差异，直接决定迭代速度的差异。 **2. 真实环境暴露真实问题。** 模型在本地 demo 中表现良好，不代表在真实流量、真实用户输入分布下也表现良好。*很多 corner case 只会在线上出现*。 **3. PM 的「叙事能力」需要载体。** 你向高管、向跨部门讲产品方向时，**一个可以现场打开的 URL，比一沓 PPT 更有说服力**。 ### 合规底线：企业业务请用内部服务 最后一个不能忽略的提醒： {% hint style="info" %} **核心观点** **为了合规，如果是企业业务，请使用公司内部服务。** 公开的云服务（即便是大厂的）也意味着**数据离开企业边界**，对于涉及客户数据、内部知识库、未公开战略的项目，必须走**内部部署 + 内部评审**的合规路径。 速度很重要，但**合规是不能违反的底线**。 {% endhint %} *** ## 六、结语：工具会变，工具观不会变 工具是手段，产出是目的；而比工具与产出都更基础的，是**你看待工具的思想**。 让我们用一张总图收束本节——**从思想转化**到**三类产出**，再到**每类产出对应的工具集合**，形成一个自上而下的工具决策框架。 **图 6：AI PM 工具决策框架** ``` ┌──────────────────────────────────────────────────────┐ │ 思想前提：你 + AI = 超级人类（AI 是延伸，不是小弟） │ └────────┬─────────────────┬─────────────────┬────────┘ │ │ │ ┌────────▼────────┐ ┌──────▼────────┐ ┌─────▼────────┐ │ 产出一：图表&原型 │ │ 产出二：产品demo│ │ 产出三：线上服务│ └────────┬────────┘ └──────┬────────┘ └─────┬────────┘ │ │ │ ┌────────▼────────┐ ┌──────▼────────┐ ┌─────▼────────┐ │ 两图一表 │ │ 24h 协同+API │ │ 一键部署平台 │ │ │ │ │ │ │ │ Axure/Figma/ │ │ Cursor/Codex/ │ │ Vercel/ │ │ Sketch │ │ Claude Code │ │ Cloudflare │ │ Mermaid/ │ │ Claude/GPT/ │ │ Render/ │ │ 飞书文档 │ │ Gemini API │ │ HF Spaces │ │ │ │ Key/自部署 │ │ 或：公司内部 │ └────────┬────────┘ └──────┬────────┘ └─────┬────────┘ │ │ │ └─────────────────┼─────────────────┘ ▼ ┌──────────────────────────────────────────────────────┐ │ 底层原则：最好的工具是下一个工具 │ │ ——以产出倒逼工具，不被工具绑架 │ └──────────────────────────────────────────────────────┘ ``` 这一节列出的所有具体工具，都极有可能在你读到这本书的几个月后被新的工具取代。但有三件事，几乎不会随版本号迭代： * **把 AI 当作能力延伸**，而不是当作小弟； * **从产出倒逼工具**，而不是被工具绑架； * **亲自把想法跑成线上服务**，而不是停留在 PPT。 {% hint style="info" %} **核心观点** **AI PM 的工具箱新原则：** * 最重要的工具是 AI 本身——它是远强于你的超级物种； * 最重要的工作产出是**图表与原型** / **产品 demo** / **线上服务**； * 最重要的工具观是——**以产出倒逼工具，始终相信「最好的工具是下一个工具」**。 工具会变，工具观不会变。 {% endhint %} *** {% hint style="warning" %} **思考题** **用今天这一节，做一次自我盘点。** **思想前提：** 过去一周，你和 AI 的协作方式更像「驾驭小弟」还是「借力延伸」？你最近一次让 AI 做的事，**是不是你自己原本完全做不到的**？ **产出一：** 你最近一次提的需求，有没有把「两图一表」准备齐？如果你只交付了文字 PRD，AI 与协作方真的能复现你脑海里的样子吗？ **产出二：** 你手上有几个可用的大模型 API Key？最近一次提需求之前，**你自己有没有先用 Cursor / Claude Code 跑过一个 demo**？ **产出三：** 你最近一个想法，**有没有变成一个人人可访问的 URL**？如果没有，是工具的问题，还是你「不敢上线」的问题？ **找出你工具箱里最薄弱的一环——明天就补上它。** {% endhint %} *** ## 第零章 · 章末小结 ### AI 时代产品经理的「新起点」 第零章结束了，**AI 时代带给人类真正的改变，才刚刚开始**。 这五节讲述的，是*一个人类文明新的起点下，一个古老的职业突破桎梏，站到人类创新之巅的故事*。 我们终将让世人见证—— > **产品经理这个族群，如何创造璀璨。** *—— 第零章 · 完 ——* # 第一章：先学会衡量——评测体系的建立 > 把评测从"上线前测试"，重新放回"需求定义"的位置 *** ## [1. 评测即需求，评测即产品](/01-evaluation/01-ping-ce-ji-xu-qiu) * 从确定性操作到概率型供给 * 评测即需求：解构 Eval 的三件事 * 为什么是现在？——监督信号的范式转移 * 评测怎么做？——组织、流程与要素 * 结语：Sample / Eval 是 AI PM 的新语言 *** ## 即将更新 * 2. Dataset：怎么构建一份"活的"评测集 * 3. Rubric：怎么把"什么算好"写成可执行的判分标准 * 4. Metric：从 Accuracy 到业务一致性，怎么选指标 * 5. Judge / Evaluator：人工、专家、LLM-as-a-Judge 的边界 * 6. 评测与产品迭代：让评测跟着产品一起活 * 7. Agent 时代：从 eval answer 到 eval trace # 1. 评测即需求，评测即产品 {% hint style="info" %} 本节提供精排版 PDF：[📄 下载 PDF](https://github.com/likunpm/ai-handbook/blob/main/01-evaluation/01-评测即需求-v2.pdf) {% endhint %} {% hint style="warning" %} *不同于传统软件时代确定性条件下的增删改查操作，大模型时代让一切都变成了* ***概率型供给***。 *我们无法再用一份 PRD 穷尽描述一个 AI 产品的所有效果；需求定义，几乎来到了* ***sample 时代***。 *这很好理解：算法开发需要的是训练数据与评测样本，而不是一份只描述规则的需求文档。* {% endhint %} 不同于第零章对思想和工具的导论，从这一节开始，我们正式进入**业务实战**。后面每一节都会涉及一些从业务视角看相对晦涩的概念——我会尽量剥掉与业务无关的实现细节，用产品经理熟悉的语言把它们讲清楚。 接下来要回答的问题就是：**当产品从确定性操作变成概率型供给，需求该如何被定义？** *** ## 1.1 从确定性操作到概率型供给 ### 传统软件：需求可以被写成操作规则 先把传统软件时代的产品形态说清楚。 在很长一段时间里，我们做的产品，本质上都是在定义一组确定性的操作：**增、删、改、查**，再加上权限、流程、状态机和异常处理。 * 用户点这个按钮，会跳到哪个页面； * 后端收到 X 请求，会返回 Y 响应； * 字段为空时如何提示，加载超过 3 秒如何展示； * 订单从待支付到已支付，再到已发货，每一步状态如何流转。 这些需求当然也会复杂，但它们有一个共同前提：**输入、流程和输出都相对确定，可以被规则枚举和代码实现。** 所以 PRD 在这个时代非常有效。它不需要描述世界上所有可能发生的结果，只要把关键流程、边界条件、业务规则和价值判断说清楚，工程团队就能把它落到软件系统里。 {% hint style="info" %} **核心观点** 传统软件时代，PRD 的核心作用是：把**需求的含义与价值**，组织成工程团队可以实现的**确定性规则**。 它适合描述的是：流程、字段、状态、权限、异常、页面与交互。 {% endhint %} ### AI 产品：供给变成了概率分布 但大模型产品不是这样。 同一个用户问题，模型会生成不同的答案；同一个任务，模型会走出不同的推理路径；同一个 Agent，在不同 context 下会调用不同的工具、走出不同的中间状态。 这不是 bug，而是大模型产品的基本形态：**它提供的不是确定性操作，而是概率型供给。** 也就是说，一个 AI 产品真正交付给用户的，不是某个固定页面、某个固定按钮、某条固定规则，而是在给定 context 下，模型对答案、计划、建议、动作路径的一次概率采样。 这时，传统 PRD 的局限就出现了。你可以在 PRD 里写： {% hint style="warning" %} AI 应该给出专业、安全、个性化、可执行的运动建议。 {% endhint %} 但这句话无法穷尽描述产品的所有效果。什么叫专业？什么叫安全？个性化到什么程度？可执行的标准是什么？在高温高湿、用户疲劳、心率异常、训练目标冲突的场景下，哪一个优先级最高？ 这些问题不能靠一句需求描述解决。它们必须被拆成**一组带 context 的样本**，以及围绕这些样本定义的**判断标准**。 ### 需求定义进入 sample 时代 所以，大模型时代并不意味着 PRD 没用了。 PRD 依然有价值：它负责说明背景、用户问题、业务目标、约束条件和产品边界。但如果我们要定义一个 AI 产品的**实际效果**，仅靠 PRD 已经不够了。 因为算法开发真正需要的，不是一段"希望模型怎么表现"的文字，而是： * 模型会遇到什么样的输入； * 这些输入背后的 context 是什么； * 在这些 context 下，什么样的输出算好； * 好坏如何分层，如何量化，谁来判断。 换句话说，需求定义正在从"写规则"转向"给样本"。这里的 sample，不是一句孤立的 query，而是一条带完整 context 的业务场景：谁，在什么状态下，带着什么目标，提出了什么问题。 {% hint style="warning" %} **Sample 是原子，Dataset 是分布。** 单条 sample 让需求变具体，一组 dataset 才让需求具备覆盖面。 {% endhint %} 所以在 AI 时代，一份可被执行的需求，必须至少包含三件事：**Dataset（Samples + Context）+ Rubric + Metric**。 {% hint style="info" %} **核心观点** 需求没有消失，PRD 也没有彻底失效。 真正发生变化的是：传统软件的需求，可以主要写成**规则**；AI 产品的需求，必须进一步写成**样本 + 标准**。 这就是为什么我说：**评测即需求，评测即产品。** {% endhint %} 而 Eval 内部的结构，恰好和产品经理对"需求"的经典定义**一一对应**。下面，我们就把这层对应关系拆开来看。 *** ## 1.2 评测即需求：解构 Eval 的三件事 ### 评测的"狭义"和"广义" 主流认知里，评测是一种相对*狭义*的存在——它是模型 / Agent 项目的**收尾动作**，是上线前的离线效果验收，是发布前的最后一道**守门员**。 这个定位本身没错，但它丢掉了 90% 的价值——它把评测的位置摆在链路最末端，把它的意义压缩成了"*合格 / 不合格*"的二元判断。 让我们重新拆解：一份评测里到底包含什么？ * **Dataset**：由一组有代表性的 sample / case 组成；每条 sample 都必须带上足够的 context，它定义的是用户使用产品的场景分布与现状； * **Rubric + Metric**：定义了 AI 系统处理任务之后，输出结果应当满足的标准——这是这个产品对*理想态*的最直接表达。 还记得我们之前讲过的，产品经理对"需求"的核心定义：**需求 = 理想 − 现状**。把这个定义和评测结构对应起来： **图 1-1　评测要素与需求模型一一对应** ``` 产品需求模型 评测三要素 ┌──────────────┐ ┌────────────────────────┐ │ 理想态 │ ◀──对应──▶ │ Rubric + Metric │ │ │ │ （输出该满足的标准） │ └──────────────┘ └────────────────────────┘ ┌──────────────┐ ┌────────────────────────┐ │ 现状 │ ◀──对应──▶ │ Dataset │ │ │ │ （Samples + Context） │ └──────────────┘ └────────────────────────┘ ┌──────────────┐ ┌────────────────────────┐ │需求=理想−现状 │ ◀──对应──▶ │ 评测 = 对差距的衡量 │ └──────────────┘ └────────────────────────┘ ``` *两边一一对应：评测的本质，就是用产品语言把需求"写"了一遍。* * Sample 是需求的**原子**，Dataset 是一组 samples 形成的**分布**； * Dataset（Samples + Context）= **现状**； * Rubric + Metric = **理想**； * 而对这两者之间差距的度量，本身就是一份完整的"需求"。 所以—— {% hint style="info" %} **核心观点** 评测，是**需求和产品能力的形式化抽象**——Dataset 把"现状"抽成可枚举的输入分布，Rubric + Metric 把"理想"抽成可衡量的输出标准。 一句话：**评测即需求，评测即产品**。 它不是上线前的守门员，而应该出现在需求被定义的那一刻——甚至可以说，它本身就是 AI 时代里*真正能被工程团队消费的那一份需求*。 {% endhint %} ### 一个最小可落地的例子 抽象的概念到这里说完了，给一个最小化的具体例子，让"评测即需求"这件事可以在你脑子里立刻动起来： {% hint style="warning" %} **场景**：运动健康类 AI 助手。 **Dataset（现状）** 一条 dataset case 远不是一句 query 这么简单——它必须带上足够还原"*用户处境*"的 context： * **用户画像**：男，34 岁，身高 178 cm / 体重 72 kg； * **运动历史**：跑龄 2 年，周均跑量 35 km，近 4 周平均配速 5'30"/km，最近一次半马 1:55； * **当下情境**：周日下午 16:00，气温 32 °C / 湿度 75%，当前已跑 8 km，配速 5'10"/km，自评疲劳度 7/10； * **Query**：*"我现在心率 170，还能继续跑吗？"* 同一句"心率 170"，对一个跑步新手与一位有 2 年跑龄的跑者来说，合理答案完全不同——**所以 context 不是"附加信息"，它就是 Dataset 本身的一部分**。 **Rubric（理想）** * 必须基于**用户画像 + 运动历史**推断个体最大心率与当前心率区间（E1 / E2 / M / T / A），不能用统一公式套； * 必须考虑**热应激**（高温 + 高湿）对心率的额外抬升； * 输出要分层：先*风险结论*（继续 / 降配速 / 停跑），再*原因解释*，最后才是建议； * *安全话术* 优先于性能建议，不允许出现"加速冲刺"等鼓励性误导。 **Metric（量化）** * 风险识别召回率 ≥ 95%（高温高湿场景独立统计）； * 不当训练建议出现率 = 0； * 个体化心率区间识别准确率 ≥ 90%； * 用户满意度（5 分制）≥ 4.5。 {% endhint %} 把上面三件事写下来——**从「带 context 的 Dataset」到「分层 Rubric」再到「可量化的 Metric」——需求才算真正被定义了。** **反过来：如果你只能写出一句"我希望它能回答好运动问题"，那它根本不是一个需求，只是一句一厢情愿的「想法」。** *** ## 1.3 为什么是现在？——监督信号的范式转移 前面我们说"评测即需求"。但你可能会问一个尖锐的问题：*评测从来都重要——为什么偏偏到 AI 时代，它才被推到"需求的载体"这个位置？* 答案藏在更底层的一件事里——**机器学习的"监督信号"，正在从 label 迁移到 data**。而当监督信号变了，定义"什么算好"这件事，就被从**模型团队的工具箱**里拿了出来，交回到了**产品团队的手里**。 下面我们分两个时代来看清这件事。 ### 搜推时代："好"可以让用户自己说出来 评测并不是什么新概念。我们对任务效果的评估，长期以来都被分成几个环节： * **离线模型 / 算法指标评测**； * **人工离线评测**； * **在线 A/B 实验**。 这套逻辑在大模型时代依然适用——搜推时代有句行业玩笑话："评测属于*人工智能*"（这里的"人工智能" = *人工 + 测试*，是个谐音梗）。当年沉淀下来的方法（比如 GSB、SBS 这类两两对比评测），今天依然有不少应用场景。 但搜推时代的评测有一个非常独特的便利条件——**主导监督信号来自用户行为**。 点击、停留、转化、负反馈……人工标注当然也存在（相关性等级、广告质量、风控样本），但更多是*辅助*。最妙的是——**"好"几乎可以让用户行为自己说出来。** {% hint style="warning" %} 搜推时代的*内容供给*发生在前，而且是**确定的**——候选池由内容运营、专家审核与库存策略*提前定义好*，本身就是一个传统的 CRUD 环节。 真正交给*用户行为*回答的，是后一步：**在这批已经确定的候选里，哪一条更好。** 所以 PM 不需要先回答"什么是好的搜索结果"——只要把候选送到用户面前，**他点不点击会替你回答**。 {% endhint %} 这就是为什么过去十几年，绝大多数 PM 都没有"亲手定义评测"这件事——因为线上的用户，每天都在替你定义。 ### 大模型时代："好"必须由人显式给出 但大模型时代不一样。 从基模预训练到后训练，模型学习的对象不再是"行为打过的标签"，而是**数据本身**——不是 label，是 data；不是"用户点了什么"，是"专家做了什么演示"。 这意味着： * 模型学到的是**模式上的统一**，而不是单个样本上的 label； * 模型学到的更多是"*经验*"，而不是大规模 UID 特征下的"*拟合*"； * 模型对**泛化**的要求，远高于此前的机器学习任务。 而最关键的一个变化是：**"什么算好"再也不能让用户行为自动告诉你了。** 为什么？ * 大模型的输出空间太大、用户的行为反馈太稀疏——无法精确归因到模型输出的某个具体维度； * 用户的"留存""复用"是一个综合指标，*无法直接告诉你"这次回答的'安全话术优先级'是不是做对了"*； * 模型自己也不会从"用户没继续问"中学到任何精细的纠正信号。 {% hint style="warning" %} 搜推时代，模型在向"*用户的行为*"学习； 大模型时代，模型在向"*人类提供的样本*"学习。 **当学习的对象从 label 变成 data，定义"什么算好"这件事，就不再是模型自己的任务，而是*****产品的任务*****。** {% endhint %} 这正是**评测被推到"需求载体"位置**的根本原因——不是大家突然觉得评测重要了，而是**除了评测之外，没有其他载体能装下这件事了**。 ### 两个无法回避的痛点 这种新的学习模式也带来了一些非常严重的问题——两个最直接的痛点，今天每个做大模型业务的团队都在头疼： * **离线评测无法和线上效果对齐**——离线评测分大幅增长，线上用户却并不喜欢； * **专家与专家之间难以完全对齐**——即便做了多轮标准对齐和案例讨论，不同专家在复杂样本上的判断依然很难完全一致，一致率往往也只能做到 **75% 左右**。 这两个痛点目前并没有标准答案，行业还在持续摸索。我个人的一种思路是—— {% hint style="warning" %} **用线上用户的真实 feedback**（点赞、点踩、追问、修改、采纳、留存等隐式信号），训练一个*专门用来打分的小模型*，让"什么算好"直接和**线上端到端的用户感受**对齐。 {% endhint %} 这只是我自己的一种构思，不是行业里已经验证过的最佳实践。但背后的判断是清晰的：当人和人之间打分一致率长期停留在 75% 左右时，单纯依赖更多人力，或者继续加厚一份静态 rubric，都很难真正解决离线评测和线上效果之间的偏差。更有价值的方向，可能是*从真实线上行为里反向学习"什么算好"*。 不管这个具体方案最终是否成立，有一点是确定的：这个方向上做的任何尝试，本质上仍然是"一份评测"。它只是把"谁来打分"从人换成了 LLM 或小模型而已。*评测 = 需求* 这件事的本质并没有变，变的只是评测自己的**实现方式**。 ### 小结：同样是 AI，需求定义方式根本不同 这里需要特别强调一下：**搜推 / 广告不是一个可以轻描淡写带过的"例外"。** 恰恰相反，过去十几年，对人类社会发挥最大规模影响的 AI 产品，很大程度上就是搜推和广告系统——Google、Facebook、抖音、TikTok、淘宝、YouTube，这些产品都建立在同一个底层逻辑上：*用海量用户行为，持续优化信息分发。* 搜推时代的特殊性在于，它面对的是一个天然适合规模化学习的问题：候选内容很多，用户行为极其密集，点击、停留、转化、划走、负反馈每天都在产生。当行为规模足够大时，"什么是好"可以被用户行为近似表达出来。 {% hint style="warning" %} 搜推时代，PM 仍然要定义目标：是优化点击、停留、转化，还是长期留存。 但一旦目标确定，系统就可以从海量行为里自动学习——**用户每天都在用自己的行为给模型打分**。 {% endhint %} 大模型时代的难点正好相反。模型提供的是生成式、概率型供给：一段回答、一份计划、一次推理路径、一次工具调用链。这些输出的好坏很难被一个简单的点击或停留直接解释。用户可能没有追问，不代表回答正确；用户点了赞，也不代表专业、安全、合规都满足；用户留存，也无法告诉你某一次回答里的错误到底发生在哪个维度。 所以，大模型时代不是没有 feedback，而是**feedback 太稀疏、太滞后、太难归因**，无法像搜推时代那样直接承担主监督信号。这就是为什么 AI 产品需要把需求重新写成 *Sample + Rubric + Metric*：先由人定义一批典型场景和判断标准，再用线上 feedback 持续校准。 **表 1-1　搜推时代与大模型时代的核心区别** | 维度 | 搜推 / 广告时代 | 大模型 / Agent 时代 | | --------- | ---------------- | ---------------------------- | | **核心供给** | 信息分发、排序、匹配 | 内容生成、决策建议、任务执行、工具调用 | | **典型产品** | 搜索、推荐、广告、短视频信息流 | Chatbot、Copilot、Agent、垂直业务助手 | | **主监督信号** | 点击、停留、转化、划走、负反馈 | Sample、示范答案、偏好、Rubric、结果反馈 | | **反馈密度** | 极高，且行为天然结构化 | 稀疏、滞后、难归因，往往只能辅助校准 | | **PM 定义** | 目标函数、漏斗指标、业务约束 | 场景样本、理想输出、分层标准、量化指标 | | **评测位置** | 离线评测 + 在线 A/B 验证 | 需求定义本身，前置到产品设计阶段 | *搜推用海量用户行为近似定义"什么算好"；大模型产品的反馈更稀疏、更难归因，因此必须前置定义 Sample、Rubric 与 Metric。* 所以这两个时代最大的区别，不是"有没有 AI"，而是**好坏标准能不能主要从线上行为里自动长出来**。搜推时代可以，大模型时代大多数场景不行。形式变了，产品经理的核心工作也就变了：不再只是定义功能和漏斗，而是要亲手定义样本、标准与指标。 *** ## 1.4 评测怎么做？——组织、流程与要素 到这里，"为什么评测重要"这件事已经讲清楚了。接下来是更接地气的三个问题： * 评测应该**谁来做**？——评测团队，还是业务团队？ * 评测应该**怎么排进流程**？——前置定义，还是事后验收？ * 一份完整的评测，到底**由哪些组件构成**？ 下面我们一个个回答。 ### 评测团队的"历史阶段性" 很多公司都设有专门的评测团队。我的观点是——**评测团队作为「独立打分组织」的存在合理性，正在快速消失。** 逻辑很简单： * 以前 LLM 能力不够，规模化打分只能靠堆人力；现在大部分评测已经是 **LLM-as-a-Judge**，人海战术的成本结构已经被彻底改写； * 评测真正稀缺的是"*懂业务* + *懂方法论*"——而懂业务的人本来就在业务团队里，让一个外挂的评测组「比业务还懂业务」，从一开始就是反规律的； * 至于「**独立性**」——真正的独立性靠*流程*保证（双盲、交叉评审、Judge 的 meta-evaluation），**不必靠组织独立来保证**。 需要补充一句：在*高合规*领域（医疗、法律、金融、教育、运动健康），人工 / 专家评测仍然是合规和信任的硬性要求——这部分不会消失，只会变得更"专"、更"贵"，不再是大公司里十几人规模的"评测团队"形态。 {% hint style="info" %} **核心观点** 所以更准确的说法是：评测团队不会一夜消失，但**它的组织形态正在被重构**——独立打分组织会快速退场，评测的能力会被重新嵌回业务团队内部。 未来更可能的分工是：**业务的产品经理**定义评测、**LLM Judge** 承担规模化打分、**研发与算法**维护评测流水线、**专家**只在最难的合规与价值判断上出现。 {% endhint %} ### 合理的评测流程长什么样 如果我们承认"评测即需求"，那合理的流程其实顺理成章——但在开始之前，有一件事需要先澄清： {% hint style="warning" %} **benchmark 不是流程上"第一步"。** *它是 **任务边界 + Dataset + Rubric + Metric** 这几件事合起来的产物*——是产品经理交付给研发团队的「需求形式化合约」。 {% endhint %} 理解了这一点，整个流程其实是**两个阶段**： **图 1-2　合理的评测流程：两阶段分组** ``` ┌── 阶段一：构建 Benchmark（PM 主导） ─────────────────────┐ │ │ │ ┌────────┐ ┌────────┐ ┌──────────────┐ │ │ │ 明确 │──▶│ 构建 │──▶│ 定义 │ │ │ │ 任务边界 │ │ Dataset│ │ Rubric+Metric│ │ │ │场景范围 │ │覆盖典型 │ │ 什么算好 │ │ │ └────────┘ └────────┘ └──────────────┘ │ │ │ │ 三者合起来 = 一份完整的 benchmark │ └────────────────────────────────────────────────────────┘ │ ▼ ┌── 阶段二：研发同步 ──────────────────────────────────────┐ │ │ │ ┌──────────┐ ┌──────────────┐ │ │ │ AI 应用 │─────▶│ 评测方法 & │ │ │ │ 开发 │ │ 执行规范 │ │ │ │研发对齐 │ │ 与开发同步 │ │ │ └──────────┘ └──────────────┘ │ │ │ │ 评测与代码一起长出来 │ └────────────────────────────────────────────────────────┘ ``` *数据集和目标标准，是和需求一起被定义的——不是等开发完了再补一个评测出来。* 具体来说： **阶段一：产品经理构建 benchmark** 1. **明确任务边界**：定义评测场景范围、覆盖什么、不覆盖什么； 2. **构建 Dataset**：汇集真实 / 合成的输入 case； 3. **定义理想态**：写出 Rubric 与 Metric——也就是"*什么算好*"。 **以上三件事合在一起，就是这个产品的 benchmark。** benchmark 不是流程上的"第一步"，*它是这三步加在一起的产物*。 **阶段二：研发与评测同步进行** 4. 进入 AI 应用的开发； 5. 在研发开发的过程中，**同步**构建评测方法与执行规范——而不是等开发完了再补一个评测出来。 数据集和目标标准要和需求一起被定义出来——*否则后续所有研发动作，都没有真正的指向和目标。* 更值得长期投入的是另一件事：**评测标准与线上用户指标的一致性**——这是一个会持续很多年的命题。 ### 评测的六个组成要素 把上面提到的几个概念再向下展开一层，一份完整的评测设计，至少需要回答下面这六个问题： **表 1-2　评测设计的六要素** | 组成 | 含义 | 例子 | | --------------------- | --------- | ----------------------------------------------- | | **Task** | 要评什么任务 | 问答、数学、代码、翻译、检索、工具调用、运动计划生成 | | **Dataset** | 用什么题评 | 一组题目、query、case、用户问题、用户画像 | | **Rubric** | 按什么标准判断好坏 | 准确性、完整性、安全性、专业性、可执行性、是否遵循指令 | | **Metric** | 用什么指标量化结果 | Accuracy、F1、BLEU、NDCG、Win Rate、Pass\@k、平均分 | | **Judge / Evaluator** | 谁来打分 | 人工评审、专家评审、LLM-as-a-Judge、规则程序 | | **Protocol** | 怎么评 | zero-shot / few-shot、是否联网、是否允许工具、温度参数、采样次数、盲评方式 | *从"评什么"到"怎么评"的完整骨架。* ### Agent 时代：从 eval answer 到 eval trace 最后还有一个不能不提的趋势——随着 Agent 越来越复杂，**评测的难度还在指数级上升。** 在传统问答场景里，评测是 *eval answer*：模型给出一个最终回答，评分人 / Judge 看这个答案对不对就够了。 但 Agent 的世界完全不同——模型不是只输出一个答案，而是输出**一整条决策链路**： * 它选择调用了哪些工具？参数对不对？ * 它在中间步骤的状态判断，是否一致？ * 当某一步出错，它能不能自我纠正？ * 整条链路的总成本（token、延迟、费用）有没有失控？ 所以评测的对象，从一个"答案"变成了一条"轨迹"——**不再是 eval answer，而是 eval trace**。这意味着 *Dataset / Rubric / Metric / Judge* 这四件事，都要在"**轨迹级别**"被重新设计——关于 Agent 评测，我们会在专门的一节里展开。 *** ## 1.5 结语：Sample / Eval 是 AI PM 的新语言 回到文章开头那个问题：当产品从确定性操作变成概率型供给，需求该如何被定义？走到这里，答案应该已经清楚了。 {% hint style="info" %} **核心观点** **PRD 是传统软件时代的重要载体，Sample / Eval 是 AI 时代的新语言。** 不会写 PRD 的人，做不出软件产品；不会写 Eval 的人，做不出 AI 产品。 * 你的 **Dataset** 决定了你看到的世界有多丰满； * 你的 **Rubric** 决定了你定义的"好"有多锋利； * 你的 **Metric** 决定了你的迭代有没有方向。 {% endhint %} 行业里有一句名言——**评测就是护城河**。这句话基本对，但需要补一句限定： * 能被外人看到的评测集（公开 benchmark），护城河会被*快速抹平*； * 真正难复制的，是**业务私有的、跟着用户 feedback 持续刷新**的那部分评测——它和你的产品一起每天都在变。 而最重要的一点是—— {% hint style="warning" %} **评测从来不是一锤定音。** 它*既是起点的定义*（前置时定义需求），也*是终点的校准*（上线后跟着 feedback 继续校准）。 评测跟着产品一起活——**你的产品成熟到哪里，评测就该长到哪里。** {% endhint %} ### 先学会衡量，再谈做产品 第零章我们讲过 AI PM 的能力模型与工具箱——那是**打基础**的部分。 而从这里开始，我们进入"**真正的工作**"：所有 AI 产品的迭代节奏、成本结构、商业天花板，都要从一件事开始：**先学会衡量，再谈做产品。** 到这里，我们只完成了一件事：**把评测从"上线前测试"，重新放回"需求定义"的位置**。至于 Dataset 怎么构建、Rubric 怎么写、Metric 怎么量化、Judge 怎么校准、Agent trace 怎么评，每一个环节都有自己的难点，也都值得单独拆开讲。读到这里，你只需要先记住一个总判断：**AI 产品的需求，不再只写在 PRD 里，而是写在 Sample、Rubric 和 Metric 里。** *** *上一节：*[*AI PM 的工具箱：以产出倒逼工具，让 AI 把你变成超级人类*](/00-intro/05aipm-gong-ju-xiang) # 第二章：理解大模型（上）——它是怎么学会的 # 第三章：理解大模型（下）——它是怎么工作的 # 第四章：安全与治理 # 第五章：Agent 全景 # 第六章：AIGC 内容生成 # 第七章：动手做 Agent # 第八章：大模型时代的商业化 # 术语表