AI PM 角色演变 — 从路线图编排到执行加速
What it is
AI 原生产品的产品经理（PM）角色正在经历根本性重构。传统 PM 的核心价值在于协调跨团队路线图、确保功能互相解锁，而 AI PM 的核心价值转向缩短从"有想法"到"产品到达用户手中"的时间。
Why it matters
- 技术变化速度：模型能力在快速提升，6-12 个月的规划周期已不适用
- 工程效率跃升：AI 大幅加速工程效率，功能交付时间从 6 个月 → 1 个月 → 1 周 → 1 天
- 角色边界模糊：PM 在写代码，工程师在做产品决策，设计师在做 PM 的活
Evidence
Cat Wu 的观察（Anthropic）
Cat Wu 面试了几百个 PM 候选人，发现大多数人仍然在用 6-12 个月路线图的思维找工作，而 Anthropic 的节奏是一周甚至一天发布一个功能。
"最好的 AI 产品 PM，能缩短从'有这个想法'到'产品到了用户手里'的时间，并且能定义出产品必须在哪些任务上开箱即用。"
角色融合的三条路径
| 路径 | 描述 | 效率 |
|---|---|---|
| 工程师端到端 | 从用户反馈到发布，几乎不需要 PM | 最高 |
| 有产品品味的工程师 | 大量招聘，Anthropic 的选择 | 高 |
| 传统 PM 引导 | 维持工程师数量、多招 PM | 较低 |
核心能力转变
传统 PM：
- 跨团队路线图协调
- 功能依赖关系管理
- 多季度规划
AI PM：
- 找到最快的方式把东西推出去
- 让工程师有想法、周末就能送到用户手里
- 定义产品必须在哪些任务上开箱即用
"恰好正确程度的 AGI 信仰"
Cat Wu 提出 AI PM 最难的技能：
- 太 AGI pilled：设计假设模型很聪明的产品，结果模型做不到
- 不够 AGI pilled：设计过度保守的产品，错失机会
- 平衡点：足够相信模型能力去设计能利用这些能力的产品，但又不能太相信
PRD 的演变
传统 PRD 正在被替代：
- 每周 metrics readout：整个团队一起看数据，确保每个人都深度理解业务
- Team principles：核心用户是谁、为什么是他们、愿意做什么取舍——让团队每个人都能自己做决策
PRD 并未完全消失，但只保留给：
- 特别模糊的功能（一页纸：目标、理想场景、当前失败模式）
- 需要大量基础设施投入的长期项目
OpenAI 前沿团队视角：代码从资产变负债（2026-05-30）
来源：Ryan Leopo — OpenAI PM 工作方式
Ryan Leopo（OpenAI frontier 团队）提出一组与 Anthropic 互补但方向一致的观察：
Code is a liability
过去软件组织把代码视为最贵重的产出，所有流程、评审、权限和排期都围绕"保护昂贵产出"设计。当 Codex 等模型能并行写出大量代码后，代码本身不再天然代表进度。更多代码不等于更强产品；每一段生成物都需要上下文、测试、业务边界和可观察结果来承接。
模块化决定并行上限
高速增长的代码库最容易变成"一团泥"（big ball of mud），业务逻辑散在各处，改一处牵动一片。OpenAI 的解法是用代码强制边界：业务域之间硬隔离，依赖通过 fake 和测试承接。这样 PM 或 agent 生成的测试不会停留在空壳层，而是能触达真实业务逻辑。
"你不能先允许一团泥出现，再期待 agent 安全地并行工作。"
五个 Codex 实习生
Leopo 让团队假设自己被分配了五个叫 Codex 的实习生。成功标准不是产出量，而是团队如何吸收这些资源：任务拆分、上下文、测试、验收。AI 管理能力成为技术负责人和 PM 的新基本功。
PRD 可以直接长成 demo
OpenAI 内部的具体场景：周初一起看 PRD，周末 demo 时功能已经跑起来，下一周面向客户发布。这能安全发生的前提是代码被拆成模块，每个领域都能导出高保真 fake 供测试使用。
不要盯着 agent 工作
Leopo 曾故意让团队使用略有摩擦的方式启动 Codex（CLI、多标签页），因为他不希望人盯着 agent 每一步。AI 工作流的价值在于并行和异步；人应该去安排更多任务、做更高层判断、检查结果，而不是把 agent 当成慢吞吞的结对程序员。
十亿 token 不是炫技
"如果你一天不用十亿 token，几乎算不认真。" Leopo 想提醒团队：更多 token 代表更多尝试、更多推理、更多候选方案和更深验证。用得少常常说明组织还没有准备好接住并行产能。
Aparna Dhinakaran — Arize AI CPO 视角：Trace 与 Eval 作为 PM 基本功（2026-05-30）
Aparna Dhinakaran（Arize AI 联合创始人兼 CPO）在与 Aakash Gupta 的播客中，将 AI PM 的核心能力拆解为一条可操作的链路：
1. Trace literacy——从黑盒到工作台 PM 以前看的是页面和数据面板，现在还要看 agent 的行为记录。Trace 把"agent 给了一份报告"拆成一串可检查的步骤：它何时去 GitHub 抓 issue，何时给单个调用打分，何时汇总成 executive summary。一个 agent 如果建议改路线图，团队不能只看结果顺眼不顺眼，还要追问它读了哪些 issue、漏了哪些上下文、哪一步判断跳太快。
"会看 trace 的产品经理，已经站进前 1%。"
2. Eval 不是验收表，而是产品迭代反馈回路 Aparna 认为好的 eval 不该全对，也不该全错；它应该露出一部分判断失误，让团队知道 agent 还有哪里能调。看到 eval 出错应该兴奋，因为它告诉团队还有哪里能改。 eval 是反馈回路，不是通过或失败的验收表。
3. 反馈进入系统，agent 生成判断，trace 暴露过程，eval 推动改进 PM 的工作流程变为：
- 从用户反馈（GitHub issue、客服工单、Slack、Discord、Gong、PostHog 等）建立上下文图
- 用 Claude Code 等工具让 agent 生成痛点报告和路线图建议
- 通过 trace 检查 agent 引用了哪些 issue、跳过了哪些用户群
- 用 eval 判断 agent 输出质量，并据此调整标准
- 回到路线图，形成闭环
4. 产品品味成为团队最稀缺的东西 代码生成门槛下降后，PM 可以更早参与原型、评估和改进。但"产品品味"不再是抽象概念，而是需要通过系统化动作被证明：谁能让用户反馈被持续吸收，让 agent 的判断被持续检查，让改进结果被持续记录，谁就能在更短周期里形成更稳定的判断。
5. PM 与工程师的边界正在变薄 AI native 团队里，PM 不需要写业务代码，但要能把任务讲到机器能执行。不会读 trace、不能理解 eval、不能把反馈变成 agent 可执行任务的 PM，会被卡在流程外。产品判断仍然重要，只是判断要落到可运行系统里。
6. 最小启动动作：周末两小时 选一个自己的产品，抓一批真实反馈，让 Claude Code 建一个简单 agent，再接入观测和 eval。两小时足够建立第一条回路。
Counterpoints & Gaps
- "Product taste" 作为筛选标准停留在抽象层面，没有可操作的定义或评估标准
- 如果模型足够强，一个文本框就够了，那 PM 的工作本质上是过渡性的
- 角色融合趋势下，PM 的价值主张需要更清晰的界定
Prompts for witness
- 我现在的项目里，从"有想法"到"交付给用户"需要多久？瓶颈在哪？
- 我是否还在用旧世界的路线图思维规划 AI 功能？
- 我的团队里，工程师、PM、设计师的边界是否正在模糊？这是好事还是坏事？
- 我对模型能力的"信仰程度"是否恰到好处？有没有设计出现阶段模型做不到的东西？
Related
- product-trends/overview — Product Trends 总览
- claude-code/overview — Claude Code 产品哲学
- product-trends/org-design-ai-age — AI 时代的组织设计