当代码变得廉价:AI 如何重写产品研发团队的分工与职位-AI协作开发 · 2026 · 组织重排的拐点

你以为 AI 颠覆的是“写代码”这一段。

但 Cat Wu 在 Lenny’s Podcast 里讲的其实是另一件事：当交付速度从“季度”变成“每日”，组织里最昂贵的东西不再是产能，而是判断与取舍。

如果你正处在一个“大家都很忙，但总觉得做出来的东西没变好”的团队里，你会更早感到这股拧巴：不是你不努力，是旧秩序用来“确保正确”的那些步骤，在加速时代开始变成摩擦。

一、第一钉：当“6 个月”被压成“1 天”，你熟悉的研发秩序会先崩掉

想象一个你熟悉的场景：

一个功能从想法到上线，要经历 PRD、评审、排期、依赖对齐、发布窗口、灰度、复盘。流程本身像一条巨大的“组织缓冲器”——它让所有人都显得理性、稳健、可追责。

Cat 说，Anthropic 把这条链路直接拆了：

• 功能交付周期：从 6 个月 → 1 个月，甚至 1 天
• 决策原则：从“跨部门对齐”→ 清除一切障碍
• 发布方式：从季度发布 → 每日发布
• 工程师权限：从“等 PM”→ 端到端从想法到交付

金句：当实现变快，真正拖慢你的不是代码，而是“把责任拆碎的流程”。

这不是“工程效率提升”，而是组织重力被 AI 改写：

当实现成本下降、迭代成本下降、回滚成本下降，“不发布”反而成了更昂贵的选择。

于是很多过去合理的岗位边界，会突然显得像一种拖延的仪式。

二、速度革命的真正抓手：Research Preview，把“承诺”从发布里拿掉

你会发现 Anthropic 这套高频发布并不是盲目冒进，它有一个关键保险丝：Research Preview（研究预览）。

做法很简单：

所有新功能默认以研究预览发布，明确标注：

• 这是早期产品
• 需要早期反馈
• 可能不会永久支持

它的价值不在文案，而在组织心理学：

当“发布”不再等价于“承诺”，团队就敢把迭代速度推到极限。

这一步会直接牵引出两类职位变化：

1）“把关型岗位”会被压缩

过去很多岗位靠“你不能上线”来证明存在感：安全评审、法务流程、品牌审核、对外口径确认……

Research Preview 不会消灭这些职能，但会迫使它们从“卡口”转为“护栏”——从审批转为规则化、自动化、可并行化。

2）“能把护栏写进系统的人”会更值钱

谁能把风险控制、口径模板、发布 checklist 做成默认流程，让工程师按按钮就能跑通？

这种人不一定是传统意义的 PM，更像是“组织产品经理”（Operational PM / Systems PM）。

三、AI 时代最贵的不是代码，而是“决定写什么”：Product Taste 成为核心稀缺

Cat 在访谈里说了一句极其关键的话：

As code becomes much cheaper to write, the thing that becomes more valuable is deciding what to write.

当代码变得更便宜，价值更高的是决定写什么。

很多团队听到这里会本能理解为：“PM 的价值回归了”。

但更准确的说法是：“产品品味”会从一种模糊优势，变成组织里最硬的生产要素。

因为当你能一天发十个功能时，真正的风险不再是“做不出来”，而是：

• 你做了一堆没人用的东西
• 你把用户心智做碎了
• 你把团队方向做散了
• 你把未来的架构债提前透支了

Cat 给的“品味强”的判断标准非常现代：

• 能从用户对产品的“滥用”里看到未来方向
• 能从数万条 issue 里筛出“该做什么”
• 能在“模型迷信”和“模型悲观”之间找到平衡

这套能力会把团队职位推向一个新排序：

• “会做”越来越不稀缺（AI + 工程效率）
• “做什么”越来越稀缺（品味 + 方向 + 取舍）
• “为什么现在做”成为组织竞争力（窗口判断）

四、PM 没死，但会被迫“融化”：角色融合不是口号，是组织必然

Cat 说：

All of the roles are merging.

PMs are doing some engineering work, engineers are doing PM work.

这句话的残酷之处在于：它不是鼓励复合型人才，而是在描述一种新常态——边界变贵了。

当迭代速度极快时，任何“交接”都会成为瓶颈。

这会带来三种职位的结构性变化：

1）传统“对齐型 PM”被挤压

如果一个 PM 的主要价值是“协调资源、开会对齐、写 PRD”，在 AI + 高速迭代面前，这类工作会被两股力量夹击：

一边是工程端到端能力上升（不需要等你排队）；另一边是流程自动化（不需要你挨个催）。

2）“会写代码的 PM”成为新默认

这不一定意味着 PM 必须成为工程师，而是意味着：PM 必须能直接触摸产品现实。

当“写”和“发”变得极快，脱离现实的判断会更快暴露，也更快把团队带偏。

3）出现新的“高价值 PM 形态”：Taste + 系统化 + 模糊判断

可以压缩成四个词：

• 品味（决定什么是好）
• 护栏（建立让团队飞快的流程）
• 方向（在模糊里判断 1 个月后产品该长什么样）
• 翻篇（快速吸收反馈，承认 bug，下一版修）

五、速度的代价：一致性被牺牲，用户教育被转嫁

Cat 也承认他们牺牲了什么：产品一致性。

当你每日发布、每个人都能端到端交付，很容易出现：功能重叠、体验不统一、入口过多。

AI 时代组织不是只有一种最优解，而是分叉成两条路：

• 速度优先型组织：把“发布”当作探索，把一致性交给未来
• 一致性优先型组织：把体验统一当作竞争力

两条路需要不同的人才结构、不同的流程护栏、不同的职位定义。

六、任务驱动文化：真正的分水岭不是工具，而是“使命排序”

访谈里最让我在意的一句不是速度、不是品味，而是：

If Claude Code failed but Anthropic succeeded I would be extremely happy.

当组织能把个人身份从“产品成败”迁移到“任务排序”，部门墙会变薄、资源调度会更像战时体制，人也更能拥抱混乱。

七、把对比拉回到“职位”：未来研发团队会长成什么样？

会被压缩的职位形态（不是消失，是从主角变配角）

• 以 PRD/对齐为中心的 PM
• 以流程审批为中心的发布/运营角色
• 以“写代码”为唯一价值的初级工程工作
• 以“信息搬运”为核心的支持性岗位

会被强化的职位形态（更稀缺、更昂贵）

• Product Taste 型人才：能定义“做什么”与“什么是好”
• 模型理解型人才：知道如何激发模型极限、如何绕过能力边界
• 系统化流程设计者：把跨职能协作写成自动运行的机制
• 高质量反馈策展人：能找到那 5 个最靠谱的反馈者
• 端到端交付者：从想法 → 实现 → 发布 → 反馈 → 下一版

八、历史的五面镜子：每一次“更快”，都会把组织打碎再拼一次

1）流水线与白领管理（1910s）

当泰勒制把“动作”变快，工厂先经历的不是产能飞跃，而是人被流程切碎。

问题是：当你今天把工作切得更碎，是为了更自由，还是为了更可控？

2）计算机化的办公室（1960s–1980s）

电脑进入办公室后，很多岗位没有消失，而是“换了一个更抽象的名字”。

问题是：你所在团队的岗位边界，是在变清晰，还是在变含糊？

3）互联网与敏捷（1990s–2010s）

敏捷把发布频率拉高，也把“对齐”的成本暴露出来。

问题是：你们的流程是为了降低风险，还是为了逃避承担风险？

4）云计算与持续交付（2000s–2010s）

当部署从“上大机房”变成“一键上线”，组织最先被重排的是权限与责任。

问题是：你们的权限结构，是否允许端到端的负责？

5）AI 与组织重排（2025–2026）

当实现接近零成本，最贵的将是判断、品味、护栏与反馈。

问题是：如果明天一切都能做出来，你准备把“选择”交给谁？

一句收束：更快从来不只是更快，它会逼你重新回答“谁该负责什么”。

尾声：AI 不是在抢工作，而是在逼你回答一个更难的问题

AI 时代的真正拷问不是：“产品经理还有没有用？”

而是：当实现几乎不再稀缺，你是谁、你为什么值得被留下？

如果一个岗位的价值来自“我来搬运信息”“我来卡流程”，AI 的确会把它压扁。

但如果一个人的价值来自在混乱里仍能判断方向、在速度里仍能守住品味、把护栏写进系统——那么 AI 不会让它失业，反而会让它更贵。

也许他对，也许他错。

但可以确定的是：当“6 个月”被压成“1 天”，你不可能还用旧世界的职位定义，去理解新世界的研发团队。

信息来源：Lenny’s Podcast × Cat Wu（访谈摘要输入）