结论先行:不用会写,但要看得懂、玩得转
我的观点是:AI 产品经理不需要能写生产代码,但需要具备三样能力——自己会调 API 做实验、看得懂技术方案在说什么、对成本和边界有数量级直觉。缺了这三样,你在 AI 团队里会寸步难行:需求评审时算法同学说「这个做不了」,你无法判断是真做不了、做起来贵、还是他不想做。传统产品里这种信息差还能糊弄,AI 产品里模型能力边界就是产品边界,糊弄一次产品方向就歪一次。
三个层次的能力要求
第一层是动手玩。给你 OpenAI 或国产模型的 API key,你能写二十行 Python(或者干脆用现成工具)把一个想法跑起来:比如「用大模型自动给客服对话打标签」,半小时内你得能搞出一个能看的最小验证。现在有了 Cursor 这类工具,这个门槛已经低到几乎没有——你描述需求,AI 帮你写脚本,你只管跑和看结果。一个从没写过代码的 PM,花一个周末就能到这一层。
第二层是读得懂方案。算法同学给你讲「我们打算上 RAG,用向量检索召回 top 5,拼接进 prompt」,你要知道每个环节在干什么、可能的坑在哪:召回不准怎么办、上下文超长怎么办、为什么不直接微调。不需要你能推导公式,但需要你能问出「为什么选 A 不选 B」这种层面的问题。
第三层是判断边界和成本。这是最重要也最稀缺的一层。看到「AI 自动生成周报」的需求,你脑子里要立刻浮现:输入多少字、调用什么模型、单次成本几分钱、延迟几秒、错误率大概什么水平、用户愿不愿意等这三秒。这本账算不出来,需求评审就是在拍脑袋。
必须建立的技术直觉
有几个概念是 AI PM 的「识字量」,不懂就没法参与讨论:
token 和成本。一次对话消耗多少 token、输入输出分开计价,这是算成本的基本功。经验上,一次普通客服对话几百到一千多 token,按现在的价格成本在几厘到几分钱——知道量级,就能快速判断一个场景的商业模式成不成立。
上下文窗口。模型能「记住」的对话长度有限,窗口外的内容它真的忘了。所以「AI 助手聊着聊着就忘了开头说的事」不是 bug,是物理限制,产品设计上要么做记忆摘要,要么引导用户开新会话。
幻觉。模型会一本正经地编造,这是概率生成的天性,不是工程没做好。所以涉及事实的功能(查政策、查订单)必须接检索或工具,不能指望模型自己答对。这条直觉决定了无数功能的技术选型。
延迟和流式。大模型生成是逐字的,首字延迟和完整生成时间差很多。产品上用流式输出让用户先看到开头,本质是用感知设计掩盖技术限制——这类「用产品手段消化技术短板」的思路,是 AI PM 的核心价值。
怎么补:别去报 Python 就业班
很多转行的人第一反应是报班系统学编程,这是性价比最低的路径。你学三个月的 Web 开发、数据库,90% 的内容和 AI 产品经理的工作无关。
更有效的路径是:找一个真实的小需求,用 API 或低代码平台(Dify、Coze 都行)把它做出来。比如做一个「每天抓取十个 AI 新闻源,让大模型生成摘要推送到微信」的小工具。这个过程会强迫你理解 API 调用、prompt 调优、模型选择、失败重试、成本控制——全是 AI PM 日常要打交道的东西。做完两三个这样的小项目,你和工程师对话的底气完全不一样。
再往深走,读几篇经典的科普级内容:GPT 的原理(知道它本质是预测下一个词就够了)、RAG 的基本流程、微调在什么情况下值得做。到这个程度,足够应付 95% 的产品工作。
什么不用懂
模型训练的数学细节、分布式训练、CUDA 优化、论文里的新架构——这些是算法工程师的饭碗,PM 懂了是锦上添花,不懂不丢人。团队分工的意义就在这里,你的价值是在技术可能性、用户需求和商业约束之间找交点,不是替工程师干活。