AI产品经理的核心能力被拆解为内外两层：对外三座桥（AI技术理解、用户研究、产品思维）连接需求与方案，对内三根根（上下文构建、视觉设计、效果评测）支撑落地与迭代。本文结合实战案例，直击大厂面试真相。

最近参加了AI产品大会，里面就谈到了很多人一直想问的问题：想进大厂做 AI 产品，到底得会点啥？

之前我给不出那种标准答案，但结合这次嘉宾的分享以及这两年我和十几个做 AI PM 的朋友深聊过，发现大家踩的坑出奇地像，缺的能力也出奇地集中。

后来我试着把这些东西理了理，发现正好能分成内外两层——外层是对外的，内层是对内的。

对外那层是桥，接不住需求，你啥也干不了；对内那层是根，根虚了，再漂亮的方案也落不了地。

下面这张图就很形象。

先说对外的三座桥。

第一座是 AI 技术理解。

这里最容易误会，以为得会写代码才算懂。真不是。

我有个朋友做企业知识库，一开始上来就要微调模型，折腾半天成本高得离谱，后来才发现 RAG 又便宜又能溯源，一句话的事。

从那以后我就信了：懂 AI 不是会背 Transformer，是知道什么活该用什么刀，以及每一次调用到底花多少钱。

评审需求前我习惯随手画张小表，把候选方案、优缺点、成本区间列一排，哪怕不严谨，也能逼自己想清楚边界，而不是把“上大模型”当成万能许愿池。

第二座是用户研究。

做 AI 产品最反直觉的一点，是用户自己根本说不清要什么。

我看过一个做 AI 写作工具的团队，访谈时用户都喊着“要更多模板”，结果一拉后台日志，大家卡的根本不是模板，是“第一段提示词不知道怎么写”。

从那以后我的习惯就变了：少做问卷，多看行为。每天翻十条用户反馈，再拉一段真实会话日志，比开三场焦点小组都管用。

第三座是产品思维。

这块最容易让人飘，因为 AI 让原型变得太便宜了——你下午想到一个点子，晚上就能搓出个 demo。

可越是一切皆有可能，越考验你敢不敢说“不”。我有个朋友，兴致冲冲给客服系统加了个 AI 闲聊功能，技术跑通了，上线却没人用，因为用户来客服系统是想快点解决问题的，不是来聊天的。

后来他跟我感慨：AI 时代 PM 最大的本事，不是想出更多功能，而是能说清楚”这个我们不做，因为……”。

产品思维说到底就两件事：

一是把模糊的价值链讲明白——这事帮谁、解决什么痛、凭什么值钱；

二是动手前先定义清楚“好”长什么样，不然你和开发对完需求连验收标准都没有，最后只能靠感觉。

所以我现在聊需求，第一句永远是：这事儿为什么非得是 AI 来做？

能用一百行规则引擎稳稳搞定的，就别碰大模型，可控性、成本、延迟哪一个崩了都是事故，尤其是政务等 容错性较低的项目。

再说说对内的三根根。

第一根是上下文构建能力。

最被低估、也最容易被误解的一根是上下文构建能力。

很多人以为这就是“会写提示词”，把 prompt 写漂亮点让 AI 出好东西。没错，但只说了一半，而且是被讲烂的那一半。

真正少有人提的是另一半：你怎么给你的队友构建上下文。

搁以前，PM 给开发、测试、项目经理的上下文，就是一份 PRD。

我见过最夸张的，一份 PRD 五六十页，从背景写到异常分支，密密麻麻。写的人累，看的人更累——开发只盯着自己那块功能看，测试对着用例抠，项目经理只关心排期和依赖。

一份超长的文档，每个人只取自己那一小段，剩下几十页全是噪音。更要命的是，PRD 写完就过时，需求一变，整本得返工，没人愿意维护。

现在这件事被 AI 彻底改写了。我聊过一个朋友做法很典型：他不再憋那份大文档，而是先把需求的核心——目标、约束、边界、验收标准——用 AI 整理成一份高密度的小结，当作唯一的“真相源”。

然后让 AI 基于同一份源，分别给开发生成技术视角的上下文包，给测试生成用例和边界场景，给项目经理生成排期和依赖关系。

同一份信息，按需切片，又短又准。开发拿到的不再是五十页里勉强翻出的三页，而是一份为他定制、当下最新的上下文。

上下文构建能力，本质上是「把对的信息，用对的密度，送给对的人」。

它有两层：一层是你跟 AI 模型的上下文，定角色、拆任务、给约束、卡输出格式，还得学会给上下文瘦身，别把历史对话硬塞进有限的窗口；

另一层是你跟人的上下文，别再指望一份 PRD 包打天下，用 AI 把长文档压成短而密的上下文包，传递更快、质量反而更高。

这两层通了，你才算真正入了 AI PM 的门。

第二根是视觉设计（换句话说就是审美）。

大厂 PM 不要求你会画，但经常要求你能比划出来。

我见过最顺的一次协作，是个朋友先用 AI 生图拉了张情绪板往设计师桌上一放：“我要这种克制的科技感。”

比写三页 PRD 都管用，沟通损耗砍掉一大半。关键不是你会不会画，是你脑子里有没有审美，能不能把“我觉得好看”翻译成“这里留白、这里强对比”这种具体的语言。

第三根是效果评测。

AI 功能和传统功能最大的区别，是它上线根本不是终点。

同一个提示词，今天对明天可能就翻车。

所以我一直劝朋友建个 badcase 库，典型的错例收集、分类、复盘、反推。

我自己的习惯是每个 AI 功能只盯一个主指标加两个护栏，比如对话类就看“首次解决率”，旁边盯“人工接管率”和“合规拦截率”。

不量化，你根本不知道是在变好还是变坏。

最后的话

总结下来就这么内外两层：外面三项是桥，里面三项是根。

如果你想往这行走，别急着报课背术语，先挑一个你天天用的 AI 产品，对照着拆一拆它外三项、内三项都做到了没——你能拆明白，大厂面你的时候你也就不慌了。