写代码被压扁，Review/Verify/Security 堆成山，旧流程僵尸还在抓脚踝

Anthropic 昨天放了一篇博客和一个28分钟的演讲视频，信息量巨大。主讲人是 Claude Code 和 Claude Cowork 的工程与产品总监，履历横跨 Microsoft（Visual Studio）和 Meta（Marketplace、AR/VR），现在直接负责这个星球上最早把“AI 写代码”当成默认工作方式的工程团队。

整篇内容的核心其实就一句话：

写代码不再是瓶颈了——但瓶颈并没有消失，只是换了个地方。

这种现象叫 the shift（瓶颈位移）。我画了一张图，可以更直观地看到这个变化。

工程瓶颈的世代位移

2000年代，在 Microsoft 做 Visual Studio 2005，软件得刻在 CD-ROM 上、装箱、铺货，所以有死硬的截止日期。互联网时代，可以在线分发了，于是改成持续更新、敏捷开发。现在这个 agentic coding 时代，写代码本身已经不是瓶颈，旧流程到了又一次重排的拐点。

在 Claude Code 团队，coding rarely is the slow part anymore，但写代码不慢，不代表所有事情都不慢——瓶颈只是移动了，移到了 verification（验证）、code review（评审）、security（安全）这些地方。

那些“悄悄失效”的流程

举一个反面例子。过去某团队同时跑着一堆 SLA：P0 SLA、P1 SLA、Code Review SLA、Sub Review SLA……到后来 SLA 多到没法处理，团队不得不做出一份 “SLA 优先级排序表”——给优先级排个优先级，听着是不是很魔幻？

这种事情，相信不少团队看着都眼熟。

Claude Code 团队动手改了5个东西，按重要性排序：规划、代码评审、入职、招聘与团队组成、组织形状。

我做了一张 Before / After 对照图，可以先看个全貌。

Claude Code 团队改造的 5 个工程流程

下面挑几个视频里讲得最生动、博客里又写得最简略的展开说说。

规划：从「六个月路线图」到 JIT 规划

刚加入 Claude Code 团队的第一件事，是认真写了一份六个月路线图——前三个月还挺好用，新年回来发现已经过期了。

于是新规则诞生：JIT planning（Just-In-Time，灵感来自 JIT 编译）——不写 Design Doc，直接 prototype；不开产品 Review，先发给内部同事 alpha 跑，根据反馈改；讨论场所从「文档」转移到「PR」。

视频里有个小故事挺有意思。

刚加入团队时，为了熟悉代码库想做一次重构，和搭档起了一次健康的技术争论——习惯性动作是拍肩说“走，咱去会议室白板画一画”——然后突然反应过来：等等，现在可以让 Claude 直接生成三个不同方案的 PR 啊。让 Claude 各跑一份，结果不仅看到三个 API 实现方案的差别，还直接看到每个方案对所有调用方的影响。这件事彻底改变了团队的辩论方式。

这里值得多提一句：这件事看着像个段子，本质上是个特别根本的转变——以前要先辩论清楚再写，是因为“写一遍代码很贵”，得先想清楚再下手。现在写一遍代码非常便宜，那就直接每个方案跑一遍，让代码替你说话。

但有一个非常重要的提醒：正因为代码便宜了，团队对齐的文化反而比以前更重要。很多人误读了 AI 提效，以为以后就是各自卷 PR 数量，实际上 AI 越强，文化和共识越值钱。

代码评审：trust but verify

先放一张分工图，看看 Claude 接管什么、人类必须把关什么。

Trust but Verify 代码评审分工

Claude 直接接管的：Style / Lint 自动跑、PR 反馈自动改、常见 Bug 在 commit 之前就抓住修掉、加测试直接帮你写。

必须留给人的：法律审查（永远拉法务搭档进来，没得商量）、信任边界与安全敏感代码（找该领域专家手审）、产品感和品味（PM 和 Designer 必须在场）。

product sense 不能让 AI 一个人玩，但这里还埋着一个更值钱的判断：依赖清单必须跟着模型升级动态调整。这一条，我觉得是国内团队最容易忽略的。很多人2024年定的“必须人审清单”，现在还原封不动在用。

招聘：找会做梦的人，和懂底层的人

这一节的内容，可以说很碘伏传统 HR 的认知。

Claude Code 团队的人才画像只锁两类：

1. Creative builder with product sense（有产品感的创造型构建者）
关键词：dreamer、好奇心爆棚、看到一个问题立刻想到能做个产品出来、为了把体验打磨到极致愿意反复迭代。

2. Deep systems expertise（深度系统专家）
刚加入团队时发现，Product Generalist 和 Creative 不缺，缺的恰恰是分布式系统专家——因为要做 Claude Code on the Web，让 Claude 跑在所有地方，没有这种深度积累根本搞不定。

不再看的是什么？raw throughput（原始产出量）。简单翻译一下：以后招人，别再看每天 commit 多少行了，那是模型干的事；要看的是判断力、产品感、对底层的理解。

组织形状：一个有点“辣”的话题

这是视频里最 spicy 的话题，博客里没有。

两种组织形状对照看一眼，差别非常直观——

两种组织形状对照

和招聘搭档的一段对话，可以说是把传统 HR 配比模型怼到墙上。招聘搭档按惯例的“10 IC : 1 Manager”配比开始问怎么分层；回复是：不行。每一个 Manager 在团队的第一段时间必须先做 IC：先 ship 真代码，先赢得 street cred（街头信用），先亲身体验“在 Anthropic 当工程师是种什么体验”。

最后扁平化的团队就这么搭起来了，背后的逻辑很硬：Manager 必须 dogfood（吃自己狗粮）；团队尽可能扁平；一个统一的团队 mission。更扎心的吐槽是：在 Meta 时期，每年还咬牙交一个 PR，但内部工具一直在变，今年学的命令明年就废了；现在连 git 命令都不太记，直接问 Claude 搞定。

这一段看着轻松，但藏了一个很现实的判断：AI 把 Manager 重新拉回了能写代码的位置，前提是你想，而且你愿意。

上下文从哪来：从「找作者」到「问 Claude」

老问题：以前你接手别人的代码，第一反应是去问“这玩意儿是谁写的？”

现在这个问题已经不太成立，所有 PR 都是 Claude 辅助生成的，“Who made this change？”已经不是有效问题。新做法叫 double click（深问一层）——你真正想知道的是什么？是找责任人（但不是为了 blame，是为了重现 bug）？是找一个专家来回答客户问题？还是想了解某个技术决策的上下文？

不管是哪一种，下一步都该问：这件事 Claude 能不能直接答？能不能自动化？

一个非常落地的例子：一个月前每天早上的仪式是端着咖啡打开 Claude Code，让它总结客户反馈频道；现在不用了，直接配了一个 routine 让它自动跑，咖啡都不用泡完就有报告。

这就是反复念的那句话：能让 Claude 做的就让 Claude 做。

Source of truth：代码就是真相

在 Claude Code 团队，code 本身就是 source of truth。回客户问题的工作流就是：打开桌面端 Claude Code，拉取本地所有相关 repo，直接让 Claude 翻代码、给答案。

这里需要补充一点不同看法：这个原则适合 Claude Code 这种产品代码即文档的项目；对一般业务团队，建议还是保留 spec 和设计文档，但 check 进 repo，让 Claude 在跑实现时直接对齐 spec，这样既有一份人类能读的真相，也有一份机器能用的上下文。

怎么知道改对了？三个数字

三个度量指标，简单粗暴但很实用。

三个度量指标

但紧接着会被泼一盆冷水：AI 生成了多少代码是一个指标，但不是目标。真正的目标是产品要解决的问题、质量、可靠性。各家每天在喊“我们 X% 的代码是 AI 生成的”——这话单独拿出来基本没意义。一堆公司用“AI 写了多少代码”做 KPI，结果给所有人安装了一个反向激励：让大家拼命让 AI 多写代码，哪怕这件事本来不需要写代码。

还没想明白的几件事

视频结尾还有一段非常真诚——大方承认有几件事内部也还在思考：

• iOS / Android 团队还要不要分？工程师现在可以无痛跨平台，传统的“iOS 团队 + Android 团队”分法还合理吗？
• 自动化 review 推到什么程度算够？太自动 = 漏掉重要的；太手动 = 速度起不来；模型每升级一次这个边界都要重定。
• 角色都模糊了，怎么保证每个人都觉得自己产出有价值？工程师在做内容，PM 在写代码，设计师在 commit——每个人的“专业感”和“被看见”该怎么维护？

这种“我也还没想明白”的姿态，比那种“我们已经全面 AI-native 了”的发言可信100倍。

几点感受

真正难的不是用上 AI，是杀掉旧流程。

从实践经验来看，代码写起来真的不慢了，但代码 review 比以前更焦虑。而国内团队最容易卡的，恰好是演讲里说的 “explicit permission to kill old processes（明确授权杀掉旧流程）”。一堆代码评审检查表、上线发布流程、设计 review 节点、双周 demo 会、月度技术分享、季度路线图……每一个都有“理由”。但你问自己：这件事要是 Claude 来干，是不是5分钟搞定？是的话，要么自动化掉，要么直接砍掉。

如果你是工程团队的负责人，这篇至少值得一读。如果你是一线工程师，建议把这两份材料丢给你老板看（手动狗头）。