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

核心结论（一句话）

AI 时代工程团队的最大变革不是”用上 AI”，而是”杀掉旧流程”——当写代码不再昂贵，所有建立在”代码很贵”前提上的旧流程（SLA、设计 review、双周 demo、月度路线图……）都失效；Claude Code 团队用 5 个动作（规划/代码评审/入职/招聘/组织形状）做了系统性改造，并提出”招聘只招两类人：会做梦的人 + 懂底层的人”。

分类提炼

知识节点

关联图谱

上游（基于 / 来自）

下游（应用于 / 验证于）

同级（横向 / 并列）

正文要点

一、核心论断：The Shift（瓶颈位移）

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

时代 瓶颈 流程
2000 年代 软件需要刻 CD-ROM 装运 死硬的截止日期
互联网时代 可以在线分发 持续更新、敏捷开发
Agentic Coding 时代 写代码本身 验证/评审/安全（新瓶颈）

Coding rarely is the slow part anymore. 但写代码不慢不代表所有事情都不慢——瓶颈只是移动了。

二、那些”悄悄失效”的流程

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

反面例子：某团队同时跑一堆 SLA——P0/P1/Code Review/Sub Review……SLA 多到没法处理，只能做”SLA 优先级排序表”——给优先级排优先级。

❝ 什么 SLA 都重要 = 什么 SLA 都不重要

三、5 个改造动作（按重要性）

1. 规划：从”六个月路线图”到 JIT 规划

新规则：

视频里的现场小故事：刚加入团队想做一次重构，原本要”走，咱去会议室白板画一画”——突然反应过来可以让 Claude 直接生成三个不同方案的 PR。让 Claude 各跑一份，不仅看到 API 实现的差别，还看到每个方案对所有调用方的影响——彻底改变了团队的辩论方式。

根本转变：以前要先辩论清楚再写（”写一遍代码很贵”），现在让每个方案跑一遍，让代码替你说话。

重要提醒：

❝ 代码便宜了，绝不能演变成”谁最后 commit 谁赢”

凌晨 3 点起床打个 routine 把 PR 顶到最上面——这肯定不行。正因为代码便宜了，团队对齐的文化反而比以前更重要。

2. 代码评审：Trust but Verify

Claude 直接接管 必须留给人
Style / Lint（自动跑） 法律审查（永远拉法务）
PR 反馈（自动改） 信任边界 + 安全敏感代码（找专家手审）
常见 Bug（commit 前抓住） 产品感和品味（PM + Designer 必须在场）
加测试（直接帮你写）  

❝ 信任边界会随模型变好而往后挪——今天必须人审的部分，下一代模型可能就不需要了

Trust vs Verify 的比例不是设一次就定下来，每次发模型都要重新评估。

3. 入职：Onboarding 爬坡

新人第一周就能 ship 真代码（指标期望：下降）。具体怎么做没在博客里展开（视频讲了）。

4. 招聘：两类人画像

锁定的两类人：

  1. Creative builder with product sense（会做梦的人）——dreamer、好奇心爆棚、看到问题立刻做产品
  2. Deep systems expertise（懂底层的人）——分布式系统、性能、底层基建

不再看的是什么：

❝ 因为模型已经够快了，纯产出这件事不稀缺了，稀缺的是判断力和深度

简单翻译：以后招人，别再看每天 commit 多少行了——要看的是判断力、产品感、对底层的理解

5. 组织形状：扁平化 + Manager 先做 IC

两种组织形状对比：传统的 10 IC : 1 Manager 配比 vs 每个 Manager 先做 IC 的扁平化结构。

逻辑：

AI 把 Manager 重新拉回了能写代码的位置——前提是你想，而且你愿意。

四、上下文获取：从”找作者”到”问 Claude”

老问题：以前接手别人的代码，第一反应是去问”这玩意儿是谁写的？” 新问题：所有 PR 都是 Claude 辅助生成的，”Who made this change?” 已经不有效

新做法 double click：

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

五、Source of Truth：代码就是真相

回客户问题的工作流：桌面端 Claude Code → 本地所有相关 repo → 直接让 Claude 翻代码给答案。

完全不用维护一份永远滞后的文档。

老章补的不同看法：

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

六、三个度量指标

指标 期望方向 老章注
Onboarding 爬坡时间 下降 新人第一周就能 ship 真代码
PR Cycle Time 下降 如果反而上升，说明 build/CI 撑不住了
Claude-assisted commit 比例 上升 团队过去 4 个月没出现过非 Claude-assisted 的 commit

冷水：

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

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

老章特别赞同：很多公司用”AI 写了多少代码”做 KPI，给所有人装了一个反向激励——让 AI 多写代码，哪怕不需要写代码。

七、还没想明白的 3 件事

视频结尾大方承认还在思考：

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

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

表格：5 个改造动作的 Before / After

维度 Before（旧流程） After（AI 时代）
规划 六个月路线图 / Design Doc / 会议室白板 JIT 规划 / prototype 替代 / 让 Claude 跑三个 PR
代码评审 人审一切 / 慢 Claude 接机械动作 / 留人审法律+信任+产品感
入职 数月爬坡 第一周 ship 真代码
招聘 看 commit 行数 / 10:1 管理配比 两类人 / 扁平化 / Manager 先做 IC
组织形状 层级管理 / 各自 mission 扁平 / 统一 mission / Manager dogfood

我的理解

适合关联的主题