Claude Code 提升十倍效率的管理能力

1 评论 723 浏览 1 收藏 8 分钟
Claude Code 采纳阶段
Claude Code 采纳阶段

写在前面

很多公司现在都有一个很熟悉的画面:某个工程师用 Claude、Codex 或其他 AI 编程工具把产出拉到原来的好几倍,旁边的人一边佩服,一边继续开会讨论“这东西到底能不能进流程”。

Claude Code 负责人 Boris Cherny 把这个现象画成了一张表。它最扎心的地方,不是说一个人能 10x,而是说团队为什么不能跟着一起 10x:不是模型不够聪明,而是组织没有把权限、验证、成本和责任补齐。

这张表被大量收藏,比点赞更能说明问题。大家不是看热闹,而是在拿它给自己的团队打分。

从 0 到 4,真正变化的是人的角色

这套采纳路径可以拆成五个状态。

阶段
人的角色
Agent 数量
典型状态
真正瓶颈
Step 0: Gated
门还没开
0
只能用老旧或轻量模型,审批和网关层层加码
安全流程、采购流程、技术决策缺位
Step 1: Assisted
结对程序员
约 1 个
一个人盯着一个 Agent 干活
注意力被模型占满,不敢离开
Step 2: Parallel
编排者
5-10 个
多个 worktree 并行跑,最后看 diff
Review 输出变成新瓶颈
Step 3: Supervised autonomy
经理的经理
约 100 个
Agent 能主动处理维护、清理和重复任务
信任、上下文、决策吞吐
Step 4: AI-native
用意图掌舵的人
1000+ 个
大量任务由 Agent 自己启动和闭环
规模化识别任务并匹配护栏

从这张表看,AI 编程不是把“写代码的人”替换掉,而是把开发者的工作往上推了一层。

Step 1 的人还在盯每一行输出。Step 2 的人已经开始同时调度多个任务。Step 3 的人关心的是模型缺了什么上下文、哪些任务能自动跑、哪些地方必须人工介入。Step 4 则更像产品 VP 或工程 VP,用意图和例外管理来驱动一组自动化系统。

这不是纯工具路线,而是职业能力路线。

升级的钥匙不是更强模型,而是验证体系

五个状态四步台阶
五个状态四步台阶

很多团队误以为,组织卡住是因为模型还不够好。等下一代模型出来,AI 落地自然会顺起来。

这基本是错的。

从 Step 0 到 Step 1,关键不是模型,而是公司是否允许安全使用:SSO、SCIM、角色权限、预算上限、数据治理、审批和 IAM 是否接得进去。

从 Step 1 到 Step 2,关键不是模型,而是自我验证循环:测试、build、lint、安全扫描、端到端验证是否能让你放心同时放出去 5-10 个 Agent。

从 Step 2 到 Step 3,关键不是模型,而是上下文和任务机制:Agent 能不能读代码、读 wiki、读历史讨论,能不能把重复任务封装成 routine、loop、batch 或 goal。

从 Step 3 到 Step 4,关键仍然不是模型,而是把一类一类领域工作做成可复制自动化,比如代码迁移、漏洞扫描、反馈修复、数据清理、文档同步。

一句话概括:你敢放手的范围,等于验证体系能兜住的范围。

多 Agent 并行之后,Review 会变成新瓶颈

多 Agent 交叉 review
多 Agent 交叉 review

单个 Agent 的问题,是你总想盯着它。多个 Agent 的问题,是你根本盯不过来。

当一个工程师同时开 6 个 worktree,让它们分别改不同模块、补测试、修 lint、跑安全扫描,效率确实会上去。但同时,审查压力也会快速放大。

这时组织必须把“人看每次击键”改成“系统先筛一次输出”。

一个更稳的链路应该是:

任务拆解
  -> 每个 Agent 独立 worktree
  -> Agent 自查测试、build、lint、安全扫描
  -> 自动 code review 和安全审查
  -> 人只看最终 diff、风险点和失败项
  -> 合并走同一套工程标准

这里最重要的是“同一套标准”。AI 写的代码不能走特殊通道,人写的代码也不能绕开测试。否则多 Agent 并行不会带来组织效率,只会扩大事故半径。

国内团队大多卡在 Step 0 和 Step 1

很多开发者个人已经在 Step 2 附近:会用 CLI、会切 worktree、会让模型跑测试、会把大任务拆成几路并行。

但把视角拉到公司层面,大量团队还在 Step 0 和 Step 1 中间。

卡点通常很朴素:

  1. 安全部门不知道怎么审 AI 编程工具;
  2. 采购只看 token 成本,不看产出变化;
  3. 代码不能出网,模型不能接真实仓库;
  4. 没有统一账号、预算、日志和审计;
  5. CI 慢、测试少,根本不敢开 auto mode;
  6. AI 写出的代码和人写出的代码没有同一套 review 标准。

所以企业不要急着讨论 1000 个 Agent。先问三个问题更现实:

测试覆盖够不够让我敢让 Agent 自查?
CI 够不够快、够不够稳定?
AI 代码和人工代码是不是同一套合并标准?

这三个问题答不上来,后面所有“自主智能体”都是空中楼阁。

Claude Code 到底适合做哪一层

Claude Code 的优势在于它不是单纯补全,而是能读仓库、改文件、执行命令、跑测试,并根据结果继续迭代。也正因为它能力强,组织才不能只靠口头规范来管理。

真正适合落地的方式,是先把 Claude Code 放进一个边界清楚的工程环境里:限定仓库、限定命令、隔离 worktree、接入测试、记录日志、统一 review。

常见问题

Q:个人 10x 能不能直接复制到团队?
A:不能。个人靠胆子和习惯,团队靠制度。没有统一验证、权限和审计,个人经验很难规模化。

Q:为什么 Step 2 的瓶颈会变成 Review?
A:因为 Agent 数量增加后,生成速度会超过人的审查速度。没有自动测试、自动 review 和 worktree 隔离,人只会被输出淹没。

Q:企业应该先上 Claude Code,还是先补工程体系?
A:两者要一起做。可以先在小范围使用 Claude Code,但必须同步补测试、CI、权限、日志和合并标准。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 用’验证体系兜住范围’这个框架漂亮,但把Step0到1的关键归到安全审批可能低估了合规成本——很多公司光是打通IAM和审计就要几个季度,不是不想放行。

    来自广东 回复