Claude Code团队内部的5条工作原则

今天读到卡兹克一篇文章，聊的是 Claude Code 团队工程总监 Fiona Fung 的一次分享，主题是 AI 原生组织在工作方式和流程上的变化。读下来很有共鸣，记录几点核心思考。

核心判断：瓶颈已经转移

过去软件工程的一切流程——瀑布、敏捷、规划、评审、会议——本质上都在围绕一个核心成本转：写代码太贵。工程师时间贵，所以得花大量时间做规划、写需求文档、搞评审、开各种会。全是在管理这个最贵的资源。

在 AI/Agent 时代，这个前提变了。写代码不再是瓶颈。

瓶颈转移到了验证、代码评审、安全。Fiona 用了一个非常精准的词来描述这个变化：转移。代码生成太快了，新问题是——这些代码对不对？怎么维护？人怎么跟得上 review 的节奏？

这个判断如果代入组织越深，触动越大。就像马车到汽车，不只是把马换成发动机——公路系统、交通规则、城市规划全得重来。

五条新规范

1. JIT 规划：做东西很便宜，争吵才昂贵

Fiona 说她刚加入时团队写了一个漂亮的六个月路线图，结果 Claude Code 迭代太快，三个月就过时了。

现在的做法叫 JIT 规划——在对的时间做恰好够的规划，不再写长篇设计文档。原型先行，Fiona 说大部分长设计文档就是”theater（做戏）”。文档如果需要，写完代码再补。

让我印象最深的一句：

Building is cheap. Arguing is expensive.

两个人对方案有分歧？不吵、不写 PPT 对线——让 Claude 把两个方案都做成原型，看实物聊。十分钟两个原型都出来了，比对着 PPT 吵高效一万倍。

2. 自动化：形成肌肉记忆

Fiona 说 Claude Code 团队每个人遇到重复性工作都会条件反射地问一句：能不能把这件事自动化？ 已经成了肌肉记忆。

她举了一个自己的例子：以前每天早上端着咖啡手动总结各客户反馈渠道的内容。后来把这个变成了后台自动运行的任务——咖啡还是那杯咖啡，但不需要边喝边刷了。

重点不在这一件事，重点在这个习惯。

我自己也一直在跟团队讲同样的理念：一件事重复 3 遍以上，必须想尽一切办法用 AI 自动化掉。

以前自动化成本高，只有高频高价值的事才值得。现在用 Claude Code，很多自动化十分钟就搞定。逻辑反过来了——几乎所有重复 3 次以上的事都应该自动掉。一个小自动化接着一个小自动化，最后会在你没反应过来的时候，长成苍天大树。

3. 代码评审：Trust but Verify

Fiona 说过去六个月被问到最多的就是：人怎么跟得上代码 review 的速度？

她的回答：Trust but Verify。

Claude 负责所有风格检查、linting、PR 反馈、bug 捕捉、补充测试——这些占了以前 review 工作量 60-70% 的部分。人类聚焦在真正需要专业判断的地方：法律合规、信任边界与安全敏感代码、产品方向与品味。

关键是，这个 trust 和 verify 的平衡是动态的。今天需要人做的事情，下一个模型可能就能做了。得像打游戏一样，每个版本用不同的攻略。

4. 角色模糊化：品味比产出能力更稀缺

在 Claude Code 团队，PM 在大量写代码，工程师也在做内容和设计——边界正在消融。

Fiona 招聘主要看两种特质：

• 有产品 sense 的创意 builder——能识别出该做什么，能快速做出原型
• 有深厚系统背景的工程师——负责”微妙错误仍然是错误”那些最需要人的部分

她的原话：

Taste is scarce, typing is not. I don’t care how many lines you write per hour. I care about what you choose to do and how you know it’s right.

当 AI 把执行速度提升 10 倍时，决定性的因素变成了——你知道该做什么吗？你知道什么样的结果才算真正优秀？

这就是品味。

5. 主动杀死旧流程

人不会主动去删除流程，只会在旧流程上面继续叠新流程。

所以你得主动站出来，指名道姓地说哪些流程可以走了。

Fiona 举了一个例子：她在一个团队里，有一个每周的 review 会议，一大堆人坐在会议室里，所有人都低头看电脑，只有轮到自己汇报才抬一下头。她问了一句：”我们为什么还在开这个会？”所有人才意识到——好像这个会根本不需要。于是取消了。

这种事太常见了。无数流程和会议，设立时有道理，环境变了、工具变了，早失去了存在的意义，只是靠惯性还在那里空转。

没有人觉得它有用。但也很少有人站出来说一句：这破会太浪费时间了，能不能别开了。

对管理者的借鉴价值

Fiona 的分享虽然来自 Claude Code 这个 AI 原生团队，但其中的原则对任何正在经历 AI 转型的管理者都有直接启发：

重新审视”规划”的成本结构

过去规划贵，是因为执行贵。现在执行变便宜了，过度规划就是浪费。JIT 规划的核心不是不做规划，而是只做”刚好够”的规划——能原型解决的问题不要写文档，能十分钟验证的事情不要花两小时讨论。

把”自动化”从工具升级为文化

这不是买几个 AI 会员、配几个 API Key 就完事的事。真正的自动化文化是全员级的——从管理者开始，每次遇到重复工作就条件反射地问”这能自动掉吗？”。这个习惯从上往下传染最快，管理者以身作则的效果远胜于发文通知。

重新设计评审和验证流程

AI 能承担大量 review 工作（风格、lint、测试补全），但人类的判断力更珍贵了。不是不重要——是更珍贵了。把人类从机械化劳动中解放出来，聚焦在需要领域经验、品味、风险判断的地方。同时要意识到这个边界是动态的，需要定期重新评估。

更新招聘标准

当 AI 能把执行速度提升 10 倍，”写代码快”不再是一个核心优势。品味、判断力、选择做什么的能力——这些才是 AI 时代最稀缺的资源。如果你还在用”每小时产出多少行代码”来衡量工程师，这个标准该改了。

主动做流程”剪枝”

这是最难但最值得做的事情。AI 在组织中介入越深，过去许多步骤和流程就越失去意义。管理者有责任定期审视每个流程，问一句：”这个会/这个步骤/这份报告还配占着这个位置吗？” 别等 AI 改造组织，要主动用 AI 审视组织。

接受不确定性，边做边学

连 Claude Code 自己的团队也没把所有事想明白——独立团队架构要不要保留？自动化 review 的边界在哪？角色模糊了怎么保证信心？这些没有标准答案。但 Fiona 把问题放出来这个行为本身就值得学习：把问题摊在桌面上，不假装有答案，一起摸索。

三个还没有答案的问题

Fiona 最后放了三个问题，她说没有答案：

1. 还需要独立的 iOS 和 Android 团队吗？
2. 全自动化的 review 能推到多远？”够快了”和”漏掉了重要的东西”之间的线在哪？
3. 角色越来越模糊时，怎么确保所有角色都对产出有信心？

连 Claude Code 的亲爹团队也没把所有事想明白。每一次大型技术变革，都不只是工具升级，整个组织的运作方式都要推倒重来。很多时候，这就不是一个有标准答案的事情。

贯穿始终的一句话

Pick your noisiest workflow. Ask if it still earns its place.

找到你最繁琐的那个工作流，问问它：是不是还配占着这个位置。

原文链接：分享Claude Code团队内部的5条工作原则 分享者：卡兹克 核心人物：Fiona Fung，Claude Code 团队工程总监