Anthropic实录：6个危险信号拆冗余流程

绝大多数企业应对AI浪潮的方式，是在旧架构上小心翼翼地外挂大模型。但站在浪潮之巅的Anthropic却在做截然相反的事：他们正在疯狂拆除过去30年积累的管理常识。

过去三十年，整个软件工业的流程——瀑布模型、敏捷开发——都建立在一个前提上：写代码很贵，工程带宽是组织最稀缺的资源。设计文档、PRD、Code Review、六个月的路线图，所有这些你习以为常的管理实践，本质上都在应对同一个约束：人的产出速度跟不上需求的增长速度。

当AI把代码成本压到趋近于零，这个底座塌了。

Anthropic最近公开了两件事。Claude Code产品负责人Cat Wu在Lenny's Podcast做了一期访谈，工程负责人Fiona Fung在内部活动上做了一场演讲。两个人讲的是同一个团队，传递的是同一个信号：所有建筑在那个旧假设上的流程，正在静默失效。这不是"用AI提效"的故事。这是一份"组织操作系统重装"指南。

从六个月到一天：每次都删功能，而不是加功能

Cat Wu给出了一个数字：Anthropic很多功能的交付周期，已经从六个月压缩到一天。几乎每天都有重大功能或产品发布。

怎么做到的？不是加了什么，是拆了什么。

传统发布流程里堆满了摩擦：需求评审、技术方案评审、跨部门对齐、层层审批。Anthropic的做法是把这些摩擦一件件拆掉。功能以Research Preview形式发布——明确告知用户这是试水版本，不保证永远支持。工程师觉得功能ready了，往一个Slack频道发一条消息，文档、市场、开发者关系团队第二天就能把公告写好。

但最反直觉的事在后面。

"每次发布新模型，我们会做的很多工作是移除功能。"Cat Wu说。早期Claude做大模型重构时会漏掉修改点，团队加了一个Todo List工具强制模型列清单逐项完成。后来模型变强了，不再需要提醒也能自己做完。这个Todo List现在还在，但它已经从"驱动模型完成任务的必要工具"退化成了"给用户看的进度指示"。

她管这类功能叫"拐杖"——因为模型能力不够，产品层面打的补丁。模型强一分，拐杖拆一根。这是Anthropic的产品进化论：不是在旧地基上盖新楼，是每层楼盖好之后把脚手架拆干净。 传统软件公司做的是加法，Anthropic做的是减法。

推而广之，放在组织管理上也是一样的道理。那些没人想开的50人周会、形同虚设的PRD、漫长的跨部门审批——本质上都是前AI时代，为了弥补人类协同效率低下而杵上的"组织拐杖"。传统公司总喜欢在旧流程上打新补丁，而真正的AI原生组织，是把算力注入底座后，毫不留情地把那些用来维稳的脚手架统统踢开。

当写代码不再是瓶颈，堵点搬到了哪里

Fiona Fung上来就给了一句最值得抄下来的判断：

Coding is rarely the slow part anymore.

写代码，已经成了整个交付链条里最快的一环。 但这不是一个轻松的好消息。她列了一串新的堵点：验证（这段代码到底对不对）、Code Review（人的审查速度跟不上AI的产出速度）、跨职能审批（法务、安全、设计被排期塞爆）、维护成本（产出爆量了，要维护的东西也跟着爆量）。

这个判断的杀伤力在于，它意味着你花了十年优化的那件事，已经不是瓶颈了。而你还没开始优化的那几件事，正在变成新的瓶颈。 你的团队如果还在花第一优先级改进交付速度，就相当于在一个已经不再堵车的高速公路上继续拓宽车道。

她甚至把矛头指向了规划本身。她刚到Claude Code团队时，本能地要了一份六个月路线图。团队认真写了，撑了三个月。过完年回来，市场变了、模型变强了、产品方向也修正了。

"六个月的路线图太长了。"她说，"大部分讨论不是写设计文档，而是直接打开PR。有想法就先prototype，内部dogfood，收反馈再迭代。"

她管这叫JIT Planning——Just-in-Time规划。类比的是编程语言里的JIT编译：不是在运行前把代码全编译好，而是在运行时看哪里需要优化就编译哪里。

Fiona提出的JIT规划，不仅杀死了六个月的路线图，更宣判了传统敏捷开发中那些繁琐仪式的死刑。 当工程师可以在一天内交付重大功能，用两周时间去规划一个Sprint、在Jira里来回拨弄Story Point，本身就成了一种巨大的算力浪费。AI时代，连"敏捷"本身都显得太慢了。

当prototype成本趋近于零，用会议和文档决策反而变成浪费。

所有角色边界都在溶解——包括「纯管理者」

Cat Wu说了一个细节：她团队的PM几乎全当过工程师，或者现在还在Claude Code上写代码。设计师也做过前端。这不是招聘偏好，是逻辑必然——当代码变便宜了，判断"这个功能应该多难实现"和"这个实现对不对"的人，比"能把代码写出来"的人更有价值。

Fiona补充了另一面：她团队的PM和设计师也在提交PR。她自己作为工程负责人，文案能力不好，换作以前要找content designer来回几轮。现在Claude直接帮她补上这个角色的能力。反过来说，非工程角色也在用Claude跨过原来需要工程支持的门槛。

角色边界不是被战略重新定义的。是被成本逻辑自然溶解的。 当每个角色都能用AI补齐其他角色的基础技能时，守住"这不是我的活"就失去了经济学意义。

但真正刺痛管理者的，是Fiona的另一条规矩。

她坚持Claude Code团队的每个主管刚加入时都要以IC（独立贡献者）身份开始工作。招聘团队说："你要招主管然后让他们先当IC？没有主管会接受这种条件。"她的回答是：那这就是我们团队的文化，不接受就提前分道扬镳。她补充说，在Meta的时候她每年都试图亲手写一个PR但总是碰壁——内部工具一直变、Git命令记不熟、上下文切换成本太高。有了Claude之后，主管能写代码这件事才真正变成可能。"现在连Git命令我都不背了，全部交给Claude。"

Anthropic强制主管做IC，不是在展示极客文化。它揭示了一个残酷的未来：纯粹的"People Manager"——那种只负责分发任务、对齐进度、传递信息的管理者——正在失去生存空间。 为什么以前的主管不写代码？因为跨部门沟通、催进度、处理"最吵的工作流"占据了他80%的时间。当AI把信息拉齐的成本降到最低，组织不再需要只会分配任务的"人肉路由器"。未来的技术Leader，必须是将双手重新放回键盘上、懂得用AI杠杆撬动团队的超级IC。

「最吵的那个工作流」——你的组织在做哪一年的假设？

Fiona在演讲结尾留了一个作业。她管它叫"Pick your noisiest workflow"——挑出你团队里最吵的那个流程。所谓最吵，可以是成本最高的、你最不想参加的、或者整个团队都觉得烦的。

然后问三个问题：

她在前司有一个每周50人的进度报告会。她进去之后发现所有人都在低头打笔记本，轮到自己抬头讲两句，讲完继续低头。她问了一句："我们为什么要开这个会？"全场安静了一下，然后异口同声："对耶，为什么？"会议就此取消。

她真正想说的是：流程很少会自己死掉。它们只会一层一层叠上去，变成一堆没人想动的仪式。 必须有一个人有勇气站起来问出那句尴尬的问题。Fiona带头取消的那个50人周会，就是一根生了锈的组织拐杖。

再把视线拉回你自己团队。过去一年里新增的流程、周报、评审会、同步会，有多少是因为"当时某个风险出现了所以我们加了一把锁"？现在那个风险还在吗？那把锁还在吗？

诊断清单：6个危险信号

关联阅读：

• KPI物理失效：AI原生组织的效能重构与技能度量
• AI裁员2026年中盘点：被裁的都有这三个特征7%飙到40%：你的公司在做减法还是乘法
• 麦肯锡2026最新组织报告：HR必须从"培训"转向"筛选"