AI PM 到底需要多技术？看了 40+ 个 JD 后，我把要求拆成了 4 层

这是「现在公司到底在招什么样的 AI PM」系列第二篇。

这一轮我整理了截至 2026 年 8 月 20 日的 43 个公开 AI 产品岗位，包括 OpenAI、Anthropic、Scale AI、Box、Binance、Apple、Ford、n8n，以及金融、保险、医疗等行业公司的职位；同时参考 Stanford AI Index 2026、PwC 2026 AI Jobs Barometer 等资料。

第一篇先做了一张地图：

所谓 AI PM，其实已经是很多种完全不同的工作。

有人离模型很近，有人在做 Agent Platform，有人负责 Evals，也有人负责把 AI 接进具体行业和企业工作流。

这也解释了一个我之前一直觉得很难回答的问题：

AI PM 到底需要多技术？

如果只看讨论，很容易得到两个极端答案：

一边说，PM 不需要写代码，理解用户和产品就够了；

另一边说，现在做 AI PM，不懂 Python、ML、System Design 已经不行了。

看完这批真实 JD，我觉得两边都说对了一部分。

问题在于：

“技术能力”本身不是一件事。

我会把招聘里的要求大致拆成四层。

第一层：AI Literacy —— 至少知道自己在做什么

这是最基础的一层。

不一定要写代码，但至少需要理解：

• LLM 大概擅长什么、不擅长什么；
• Hallucination 为什么会出现；
• RAG 是解决什么问题的；
• Agent 和普通 Chatbot 有什么区别；
• Tool Calling、Grounding、Context、HITL 分别在做什么。

这些概念并不难学。

真正重要的是，它们会不会影响产品判断。

例如工程师说：

这个场景不适合继续把信息塞进 Context，应该改成 Retrieval。

或者：

这个步骤不能直接让 Agent 执行，最好保留 Human Approval。

PM 不一定要自己实现，但至少应该能参与讨论：

为什么？代价是什么？有没有别的方案？

如果所有涉及 AI 的决定最后都只能变成：

Engineering 建议这么做。

那其实不只是技术被外包了。

一部分产品判断也一起被外包了。

所以我现在会把 AI Literacy 理解成：

不需要成为工程师，但至少要听得懂这个产品为什么这样工作。

这应该已经是 AI PM 的基本门槛。

第二层：Builder Fluency —— 能不能自己先试一下

再往上一层，我看到越来越多 JD 开始出现：

Hands-on、Prototype、Python、SQL、Notebook……

这里很容易让人产生压力：

PM 现在也要写代码了吗？

我觉得不必直接得出这个结论。

这些岗位更常表达的是另一种要求：

不要把所有验证都依赖工程团队。

例如有一个产品想法，可以自己先：

• 调用一个 Model API；
• 搭一个简单的 RAG；
• 让 Agent 调两个 Tool；
• 跑几十个测试 Case；
• 比较两个模型；
• 看 Trace 和 Log；
• 用简单的 Python / SQL 看一下结果。

Box 的 Product Manager, AI Evaluations 是一个很典型的例子。

它明确要求 PM 能使用 Python、SQL、Notebook，自己构建 Evals、分析结果、Prototype Data Pipeline。

这不是让 PM 去维护 Production Code。

更像是在说：

如果一个问题几个小时就能自己验证，不要先花几天写文档，再等别人替你验证。

这件事其实和 Coding Agent、AI-assisted Building 的发展也有关系。

Prototype 的成本已经明显下降。

以前“PM 自己做不了”很合理的事情，现在有一部分已经变成：

“为什么不先自己试试？”

所以 Builder Fluency 真正重要的，不是“会不会某种编程语言”。

而是：

能不能独立把一个模糊想法推进到有证据可以判断。

第三层：System Fluency —— 知道一个 AI 产品为什么会失败

再往上一层，我觉得才是真正拉开 AI PM 差距的地方。

一个 Demo 能跑，不代表它是一个产品。

真正投入使用以后，很快会遇到：

• Agent 可以调用哪些 Tool？
• 什么 Tool 绝对不能调用？
• Context 应该放多少？
• 什么时候需要 Memory？
• Tool 连续失败以后，是 Retry、Fallback，还是直接停止？
• 什么动作必须由人确认？
• 模型更新以后，怎么知道有没有 Regression？
• 质量提高一点，但成本翻倍，要不要上？
• 更强的模型慢两秒，用户是否能接受？

这时候需要理解的已经不是：

“RAG 是什么？”

而是：

整个系统在什么条件下会可靠，又会在什么地方失效。

例如 Binance 的 AI Agent & Harness PM，职责里会出现：

Task Flow、Capability Boundary、Failure Fallback、Harness Evaluation、Task Set。

OpenAI 的 API Agents PM，则需要和研究、工程一起讨论 SDK、API 和 Agent Infrastructure。

这类岗位不一定要求 PM 自己实现所有东西。

但它要求 PM 能对这些东西做产品判断。

我觉得这里有一个挺重要的区别：

第二层问的是：

我能不能自己做实验？

第三层问的是：

我知不知道实验结果意味着什么，以及这个系统能不能上线？

后者比“会写一点 Python”重要得多。

第四层：ML / Infrastructure Depth —— 有些 AI PM，本来就是技术 PM

再往上，就是 Core Models、Training、Post-training、Inference、Compute、ML Platform 这些岗位。

它们可能要求理解：

• Model Training；
• Inference；
• Search / Recommendation；
• Data Infrastructure；
• Serving；
• 分布式系统；
• Experimentation Framework。

这时候竞争者本来就经常来自：

ML Engineer、Data Scientist、Search / Recommendation PM、Infrastructure PM。

所以如果看到 OpenAI、Anthropic 的一些 JD，觉得：

AI PM 为什么已经要求这么深的技术？

其实不一定代表所有 AI PM 都变成这样。

更准确的理解是：

你正在看一种本来就非常靠近模型和 Infrastructure 的 PM。

一个 Healthcare Agent PM 和一个 Core Models PM，虽然 Title 里都可能有 Product Manager，但能力结构完全不同。

这也是为什么上一篇先把 AI PM 分类很重要。

否则所有技术要求都会被揉成一张吓人的学习清单。

真正让我觉得更重要的，是这三种能力正在跨岗位出现

看完这些 JD 后，有三个东西我反而比“会不会写代码”更在意。

1. Evals：你怎么知道它真的变好了？

这是我觉得 AI PM 和传统产品工作差异很明显的一点。

过去我们很容易说：

“用户反馈不错。”

AI 产品里，这句话不太够。

需要继续问：

• 和什么 Baseline 比？
• 在哪些任务上更好？
• 测试集怎么来的？
• 哪些错误改善了？
• 又有哪些地方退化了？
• 什么错误可以接受？
• 什么错误一次都不能发生？

所以 Evals 即使没有变成每个人职位名称的一部分，也很可能慢慢变成 AI PM 的基础工作方法。

不是每个人都需要成为 Eval 专家。

但至少应该知道：

我凭什么说这个版本更好？

2. Trade-off：不是单纯追求“模型更聪明”

一个 AI 产品通常同时存在很多目标：

QualityLatencyCostReliabilitySafety

它们经常彼此冲突。

• 更强的模型可能更贵；
• 更快的模型可能效果差一点；
• Context 放得更多可能更准，但延迟和成本一起上涨；
• Agent 权限更大可能完成更多任务，同时也更危险。

这里不存在一个工程师可以算出来的唯一答案。

产品还是需要决定：

我们到底在优化什么？

以及：

底线在哪里？

3. Failure Design：先想它会怎么坏

普通软件当然也需要处理异常。

但 AI 系统的不确定性，让 Failure 变成一个更核心的产品问题。

• 不知道怎么办？
• 信息冲突怎么办？
• Tool 返回错误怎么办？
• 模型非常自信地答错怎么办？
• 执行到一半失败怎么办？
• 什么时候应该让人接管？
• 错误发生以后能不能恢复？

我现在反而觉得：

看一个 AI PM 是否真的理解产品，最好的方式之一不是看他能不能讲 Happy Path，而是看他怎么讲 Failure。

所以，AI PM 到底要不要会写代码？

如果一定要给一个很短的答案：

不一定。

但另一个答案也很明确：

完全不碰技术，会越来越限制可以竞争的岗位。

不是因为 PM 要变成 Engineer。

而是因为 AI 把很多过去藏在工程实现里的问题，变成了产品问题。

• 模型选哪个；
• 什么时候可以发布；
• 怎样评价质量；
• Agent 有多大权限；
• 失败后怎么办；
• Quality、Latency、Cost 怎么取舍。

这些事情都不能只靠：

“技术团队会处理。”

我觉得可以用五个问题自测

与其问自己：

“我会不会 Python？”

不如拿一个真实 AI 产品，看看自己能不能回答：

1. 为什么这里需要 AI，而不是普通规则？

2. 什么结果算好？

3. 准备怎么测？

4. 最容易失败在哪里？

5. 上线以后，怎么知道它有没有持续变差？

如果这些问题已经能独立回答，即使代码能力还有限，技术也开始真正服务于产品判断了。

如果这些问题答不了，即使知道很多 Framework 和新名词，可能仍然只是：

知道 AI，而不是会做 AI 产品。

所以这一篇研究下来，我最后对“AI PM 要多技术”的理解反而比开始时简单了一点：

学技术，不是为了替代工程师。

是为了不要把本来属于产品的判断，也一起交出去。

下一篇会继续看另一个很有意思的变化：

为什么招聘里开始出现 Evals、Harness、Model Behaviors、Forward-Deployed 这些几年前很少见的职位？

它们到底是在发明新名词，还是 AI 产品组织真的开始长出新的专业分工？

「现在公司到底在招什么样的 AI PM」系列 2/4。研究基于截至 2026 年 8 月 20 日整理的 43 个公开 AI 产品岗位；本文主要参考 Box AI Evaluations、OpenAI API Agents / Core Models、Binance AI Agent & Harness、Scale AI Forward-Deployed 等招聘信息，并结合 Stanford AI Index 2026、PwC 2026 AI Jobs Barometer 做趋势交叉参考。