Claude Code 团队只招聘这两类人：会做梦的人 + 懂底层的人

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

大家好，我是 Ai 学习的老章

昨天 Anthropic 放了一篇博客 + 一个 28 分钟的演讲视频

主讲人是 Claude Code 和 Claude Cowork 的工程与产品总监，履历跨越 Microsoft（Visual Studio）和 Meta（Marketplace、AR/VR），现在直接负责这个星球上最早把"AI 写代码"当成默认工作方式的工程团队

全篇就讲一件事：

❝当 Claude 自己开始写代码之后，整个工程团队该怎么活

我把博客和视频都过了一遍，越看越觉得这玩意儿信息密度比一般 AI 公司年度白皮书还高，而且视频里有一堆博客根本没收的现场细节

国内做工程团队管理的同行，我建议都读一下，不是因为 Anthropic 多牛，而是因为他们踩过的坑大概率就是接下来一两年所有 AI-native 团队都要踩的坑

一句话先抛出来

整篇内容的内核就一句话：

❝过去几十年所有的工程流程，本质都是建立在「写代码很贵」这个前提上的；现在写代码不贵了，那些流程也跟着废了——但它们不会自己死掉

这种现象叫 the shift（瓶颈位移）

我画了一张图，更形象体现这个变化

工程瓶颈的世代位移

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

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

那些"悄悄失效"的流程

❝Processes rarely kill themselves（流程很少会自己死掉）

举个反面例子，过去某团队同时跑着一堆 SLA：P0 SLA、P1 SLA、Code Review SLA、Sub Review SLA……到后来 SLA 多到没法处理，团队不得不做出一份 "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 实现方案的差别，还直接看到每个方案对所有调用方的影响——这件事彻底改变了团队的辩论方式

老章想多说一句：这件事看着是个段子，本质上是个特别根本的转变——以前要先辩论清楚再写，是因为「写一遍代码很贵」，得先想清楚再下手

现在写一遍代码非常便宜，那就直接每个方案跑一遍，让代码替你说话

但有一个非常重要的提醒

❝代码便宜了，绝不能演变成"谁最后 commit 谁赢" 凌晨 3 点起床打个 routine 把自己的 PR 顶到最上面——这肯定不行

正因为代码便宜了，团队对齐的文化反而比以前更重要

很多人误读了 AI 提效，以为以后就是各自卷 PR 数量，实际上 AI 越强，文化和共识越值钱

代码评审：trust but verify

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

Trust but Verify 代码评审分工

Claude 直接接管的：

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

必须留给人的：

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

product sense 不能让 AI 一个人玩，但还埋着一个更值钱的判断

❝信任边界会随模型变好而往后挪——今天必须人审的部分，下一代模型可能就不需要了 trust vs verify 的比例不是设一次就定下来，每次发模型都要重新评估

这一条我觉得是国内团队最容易忽略的，很多人 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 一点的话题

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

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

两种组织形状对照

和招聘搭档之间的一段对话，可以说是把传统 HR 配比模型怼到墙上

招聘搭档按惯例的 "10 IC : 1 Manager" 配比开始问怎么分层；回复是：不行；每一个 Manager 在团队的第一段时间必须先做 IC：先 ship 真代码，先赢得 street cred（街头信用），先亲身体验"在 Anthropic 当工程师是种什么体验"

最后扁平化的团队就这么搭起来了，背后的逻辑很硬：

• Manager 必须 dogfood（吃自己狗粮）：不写代码就完全感受不到产品好不好用
• 团队尽可能扁平：决策快、转向快、上下文同步快
• 一个统一的团队 mission：不要每个 pod 各自定 mission，一旦要 pivot 就要全员重新对齐

更扎心的吐槽是：在 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，这样既有一份人类能读的真相，也有一份机器能用的上下文

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

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

三个度量指标

但紧接着会被泼一盆冷水

❝Don't confuse throughput with success（别把产出量当成功）

AI 生成了多少代码是一个指标，但不是目标；真正的目标是产品要解决的问题、质量、可靠性

各家每天在喊"我们 X% 的代码是 AI 生成的"——这话单独拿出来基本没意义

老章特别赞同这一段，一堆公司用"AI 写了多少代码"做 KPI，结果给所有人安装了一个反向激励：让大家拼命让 AI 多写代码，哪怕这件事本来不需要写代码

还没想明白的几件事

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

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

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

老章的几点感受

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

我自己用 Claude Code 半年了，深有体会：代码写起来真的不慢了，但代码 review 比以前更焦虑

而国内团队最容易卡的，恰好是 演讲里说的"explicit permission to kill old processes（明确授权杀掉旧流程）"

一堆代码评审检查表、上线发布流程、设计 review 节点、双周 demo 会、月度技术分享、季度路线图……每一个都有"理由"

但你问自己：这件事要是 Claude 来干，是不是 5 分钟搞定？是的话，要么自动化掉，要么直接砍掉

如果你是工程团队的负责人，这篇至少值得一读

如果你是一线工程师，建议把这两份材料丢给你老板看（手动狗头）