← 返回博客

博客

五种角色之外，PM 还要回答什么

产品AI Agent方法论

一个产品经理站在原型卡片和验证清单之间，象征 AI 时代 PM 在选择与验证之间的工作

最近，Business Insider 报道了 Claude Code 负责人 Boris Cherny 的一个观察，挺值得琢磨。

他说，随着工程、产品、设计、数据这些职能慢慢融在一起，未来团队里真正区分人的，可能不再是职位，而是五种「角色原型」：有人负责不断抛原型，有人负责把原型做成产品，有人负责清理系统，有人负责增长，有人负责守住成熟系统的可靠性。

他还补了一句：这些角色不和职位绑定。设计师、工程师、产品经理，都可能落在不同原型里。一个健康团队，也要按产品阶段来配比。早期更缺原型者和构建者，成熟期更缺清理者和维护者。

这个观察很准。但我觉得，它只回答了一半。

它讲清了「怎么干活」，没讲清「怎么做选择」。

这个框架并不新

按阶段分人，其实不是新东西。

1992 年，Robert Cringely 就把科技公司里的人分成突击队、步兵、警察：有人打下滩头，有人把它变成可量产的系统，有人守住并扩大它。后来 Simon Wardley 换了一套词，叫拓荒者、定居者、城市规划师。Peter Thiel 又把它压缩成「从 0 到 1」和「从 1 到 n」。

这个形状反复出现，是因为它确实存在。喜欢混乱、能从零做出东西的人，和喜欢稳定、能把系统守十年的人，本来就不是同一种人。

Boris 新的地方，不在于重新发现了这件事，而在于他把这根轴翻了上来。

过去，「你擅长哪个阶段」只是性格差异，主轴仍然是「你是工程师、设计师，还是产品经理」。现在 AI 把职能边界溶掉了，阶段能力反而变成了更重要的身份标签。

看懂这一点，比记住那五个名字重要。

漏掉的是决策层

把这五种角色摆在一起，你会发现它们基本都在处理一个已经被选中的问题。

原型者抛点子。构建者把它做出来。清理者把它变干净。增长者让它贴合市场。维护者让它稳定运行。

但中间少了一步：这一堆原型里，到底哪个值得继续做？

构建者不能永远靠手感从一堆 demo 里挑。增长者也不能等产品已经上线了，才发现一开始选错了方向。真正被省略的，不是第六种人，而是一个决策机制：把很多可能性，收敛成一个明确选择。

这也是 AI 时代 PM 最容易被误解的地方。

很多人讨论 PM 职能时，会列一长串：战略、用户洞察、原型管理、需求说明、验收标准、评测方案、灰度上线、增长复盘、复杂度治理、合规信任。

这些都对，但平铺成清单，反而把重点冲淡了。

我更愿意把它们压成三类产出。

第一类是机会判断：为什么这件事值得做，为什么是现在做。

第二类是选择记录：为什么这堆原型里选 A，不选 B。

第三类是验证规则：什么算做对，什么情况必须退回。

需求文档会变薄，甚至在很多团队里不再是中心产物。但这三类东西不能消失。因为越来越多执行者不再是人，而是 agent。它能读文档、读代码、读聊天记录，但它读不到你脑子里的犹豫、品味和取舍。

没写下来、检索不到的判断，对机器来说就等于不存在。

所以 PM 的产出，不是「告诉别人该做什么」那么简单了，而是让组织知道什么值得做，也让人和机器都能接着做对。

两家公司，两种做法

抽象地讲职能，谁都会讲。更有意思的是，那些跑在前面的团队到底怎么做。

公开信息里，Claude Code 和 Codex 给了两种不太一样的答案。

Claude Code 更像是「原型优先，内部使用当筛选器」。它最早是 Boris Cherny 做出来的一个内部工具，后来在 Anthropic 内部扩散。AP 的报道里，Cat Wu 也讲过，使用这类工具时，人不再盯着每一行代码，而是在表达更高层的目标。但她也强调，最后责任仍然在人手里。

这套机制的重点，不是写一份很长的需求文档，然后等工程排期。它更接近：先把东西跑起来，让团队自己用，谁真的离不开它，谁就给了一个很强的发布信号。

Codex 这边，更像是「把仓库变成 agent 的工作环境」。

AGENTS.md 这样的文件，本质上是在告诉 agent：这个项目是什么、怎么构建、怎么测试、哪些规则不能破、什么算完成。相关研究也开始测这类仓库级指令对 agent 的影响，有研究发现 AGENTS.md 能降低运行时间和 token 消耗，但这不代表写得越多越好。规则一多，agent 也会被你绕晕。

这说明一件事：把判断写进仓库是必要的，但写多少、怎么写，本身也是产品能力。

两条路看起来不一样。Claude Code 更偏真实使用，Codex 更偏结构化上下文。但共同点很清楚：它们都不是把旧世界的长流程搬回来；也都不是让机器完全替人判断。人的判断仍然留在方向、品味、取舍和质量边界上，只是执行环境变了。

但别急着照抄

这些讨论背后有个前提：执行变便宜了。

这句话在一些团队里是真的。尤其是人才密度高、技术用户就是自己、内部能快速吃自己狗粮的环境里，原型和构建速度确实变了。

但换到一家普通公司，尤其是客户不在内部、场景复杂、交付链条长的 ToB 产品里，这个前提不一定成立。

METR 做过一个很刺眼的随机对照实验：他们让一批资深开源开发者使用 AI 工具，结果任务完成时间反而慢了 19%。更有意思的是，开发者自己以为快了 20%。另一边，斯坦福相关研究也发现，在高度暴露于 AI 的岗位里，22 到 25 岁的早期员工就业出现明显下降，而资深员工相对更稳。

这些证据放在一起，不支持一个简单结论，比如「AI 一定让所有执行变便宜」或者「AI 没用」。

更诚实的说法是：AI 会重塑执行，但它先奖励那些已经知道什么是好、也能快速验证结果的人。

所以照抄别人的组织形态之前，先问一句：在我这里，执行真的已经便宜了吗？如果还没有，那就不能拿一个没验证的前提，去改组织、改流程、改人的位置。

最后

五种角色是一张快照，PM 职能清单也是。

它们描述的是此刻一些 AI 原生团队里，人正在怎么分工。但这个「此刻」本身变得很快。真正值得抓住的，不是某个固定岗位，也不是一份更长的职能表，而是两个问题：

在还没有答案的地方，我能不能做选择？

在可以验证的地方，我能不能把判断写成系统能继承的规则？

Boris 用五种角色给了一个答案。Claude Code 和 Codex 又各自给了一个答案。它们都值得看，但都不值得照抄。

最后还是要回到自己的场景里：你的团队里，哪些判断必须由人来做？哪些规则可以写下来交给机器跑？哪些地方看起来是流程问题，其实是没人敢做选择？

PM 真正的位置，就藏在这些问题里。

参考资料