Claude Code团队内部5条工作原则排行榜

今天凌晨，AIHOT发布了一篇来自Claude Code团队的博客，内容干货十足。

像Claude这种真正在一线冲锋的AI公司，愿意公开分享组织层面的方法论，实在罕见。

更难得的是，这篇文章的作者正是Claude Code团队的工程总监——Fiona Fung，一位当下炙手可热的AI工程领导者。

她分享的核心主题是：作为AI原生组织，团队的工作方式和流程正在经历怎样的深刻变革。

整场分享加半小时的演讲视频看下来，不少思路和做法都在我的实践中得到了印证。尤其她反复强调的一个习惯：团队每次遇到问题，第一反应都是追问——这件事能不能自动化。

这个逻辑，和许多高效团队推崇的理念高度一致：如果一件事需要重复三次以上，就一定要想办法用AI把它自动化。今天看到Claude Code团队几乎在用一模一样的底层逻辑运转整个工程组织，确实令人振奋。

所以，我把这篇分享里最有价值的部分提炼出来，希望能给你带来实实在在的启发。

开头，Fiona抛出了一个非常犀利的判断。她认为，过去几十年软件工程的所有流程——无论是瀑布还是敏捷，那些规范和方法论——本质上都是围绕一个核心成本运转的：写代码太贵了。工程师时间值钱，所以你需要花大量时间做规划、写需求文档、搞各种评审、开各种会，所有动作都在管理这个最昂贵的资源。

没错，在互联网行业待过的人都能感同身受。

但在AI时代，或者说Agent时代，这个前提彻底变了。

在Claude Code团队，写代码几乎不再是拖慢速度的环节了。

问题随之而来：如果写代码本身不再是瓶颈，那么围绕它的所有上下游流程，就必须全部重新思考。

Fiona Fung提出了整场分享最核心的一个词：转移。瓶颈没有消失，只是转移了——它转移到了验证、代码评审、安全。代码生成速度太快了，新问题变成了：这些代码对不对？怎么维护？人的review速度到底跟不跟得上节奏？

左边灰色部分是旧瓶颈：写代码和发布代码的产能。右边黑色部分是新瓶颈：验证、评审、跨职能协作、安全。这个关于“转移”的判断，AI介入组织结构越深，感受就越明显。组织结构、流程，都必须围绕这个变化重新设计。就像当年从马车到汽车，不光是换发动机，整个公路系统、交通规则、城市规划都得重来。

那么具体哪些东西需要重新审视？Fiona列了一张图。

她指出了五个正在悄然失效的旧流程领域：

1. 规划方式——工程速度和产出量完全不同了。
2. 代码所有权——谁写的这段代码，变成了一个奇怪的问题。
3. 代码评审——新的规模、新的形态、新的工具。
4. 团队构成——角色在模糊化，什么技能组合才是你真正需要的。
5. 知识共享——文档不再是唯一的真相来源。

对应的，她分享了五个他们重建的新规范。

包括：让人类的判断力聚焦在真正需要的地方；新人入职成本大幅降低，甚至一周就能直接产出代码；减少前期规划，多做原型；招聘更看重创造力和判断力，而非纯产出速度；组织架构更扁平，每个管理者也要从一线干起。每个部分，她都展开了详细的分享。

一. 规划的变化

以前因为coding时间贵，需要花大量时间提前规划。Fiona说，她刚加入Claude Code团队时，团队写过一份非常漂亮的六个月路线图。结果呢？因为Claude Code本身迭代太快，三个月左右这份路线图就过时了。

所以她们现在的做法叫JIT规划——Just-In-Time，就像JIT编译一样，在正确的时间做恰好足够的规划。不再写长篇大论的设计文档，直接在PR或原型里讨论；不再做冗长的产品评审，先做原型让内部用户去用，然后根据反馈快速迭代。

左边是她们砍掉的东西：写代码之前必须先写设计文档的仪式。Fiona说，对大部分工作来说，这就是theater——做戏。现在换成原型先行，如果文档确实需要，等写完代码后觉得合适再补。

右边是她们加码的东西：验证。因为在AI原生的工作流里，出bug的方式跟以前完全不同了，唯一能保证质量的方法，就是不断把验证流程向前推。

她还讲了一个格外精彩的观点。

在技术讨论中，代码赢才是硬道理。如果两个人对一个方案有分歧，最快的解决方式不是继续争论，而是让Claude把两个方案都做成原型，用实际结果来决策。Building is cheap——做东西很便宜。Arguing is expensive——争吵才昂贵。

想想以前的场景：互相争论某个方案，各自PK可能要写几份PPT，开两轮会来讨论。现在呢？十分钟两个原型都出来了，看着实物聊，比对着PPT吵高效一万倍。

很多团队也走在这条路上。以前写PRD的时间，比直接用Claude Code把东西做出来还长。后来就改了：有想法先做原型，能用了再说。很多功能都是在使用过程中发现不对，当场就改，极速迭代。坦率说，在AI时代，过度规划就是浪费。

二. 自动化的变化

Fiona说，在Claude Code团队，每遇到一个问题，都会追问一句：能不能把这件事自动化。

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

这个例子听起来很小——就一个总结客户反馈的事，能有多大工作量。但重点不在这一件事，重点是这个习惯。Claude Code团队里的每个人，每次遇到一个重复性工作，都会条件反射地问自己：能不能自动化？她说，这已经快形成一种肌肉记忆。

这就是我一直强调的那句话：如果一件事需要重复三遍以上，请想尽一切办法用AI把它自动化。在公司里我反复跟团队讲，这甚至不是建议，是要求。

但坦率讲，要把这真正变成团队的肌肉记忆，比说起来难太多。因为大多数人对自动化的理解还停留在很粗的层面：自动化就是写个脚本嘛，搞个定时任务嘛。但AI时代的自动化，跟以前完全不是一个量级。

现在用Claude Code，很多自动化的事情十分钟就能搞定，甚至更短。比如为了同步家里电脑和公司电脑，可以跟Claude说一句“帮我写一个hook，每次打开XX项目之前都去github拉取最新的代码”，几分钟就能跑起来。

以前自动化成本高，只有高频、高重复度、高价值的事情才值得自动化。现在自动化成本几乎为零，逻辑反过来了——几乎所有重复超过三次的事情都应该自动化。除了工作流之外，触发器hook是一个非常好用的工具。一个个小的自动化攒起来，最后这些东西会在你可能都没反应过来的时候，一起长成一棵参天大树。

所以如果你还在犹豫要不要开始，别想太大。别一上来就想着搭建一个完整的自动化体系——那太吓人，也没必要。就从今天开始，找一件你重复做了的事，花十分钟让Claude Code或者Codex帮你自动化掉。明天再找一件，后天再找一件。一个月以后回头看，你的工作方式已经完全不同了。

三. 代码评审的变化

代码评审这块，Fiona说她在过去六个月跟其他工程leader聊天，被问到最多的一个问题就是：你们人怎么跟得上代码review的速度。

她的做法叫Trust but verify——信任但验证。Claude Code团队大量使用Code Review功能。Claude负责处理所有的风格检查、linting、PR反馈、bug捕捉和修复、补充测试。这些以前可能占了review工作量60%-70%的部分，现在Claude全接了。

但人类review仍然不可替代，在那些真正需要专业判断的地方。法律合规的东西，永远需要法务伙伴参与风险评估；信任边界和安全敏感代码，需要领域专家；产品方向和品味的判断，需要PM和设计师。

而且她特别强调了：这个trust和verify之间的平衡是动态的。今天需要人做的事，下一个模型可能就能做了，所以必须不断重新评估这条线。就像打游戏，每个版本的版本答案都不一样，你不能拿上个版本的攻略打新版本——那只会被人干死。

四. 团队角色的变化

Fiona说在Claude Code团队，角色界限已经变得很模糊了。PM在大量写代码，工程师也在做内容和设计的事情，以前泾渭分明的边界正在消融。

比如以前，一个工程师修了个bug，要等内容设计师排期来写用户端的文案。排期这个破事，懂的都懂——结果要么等好几天，要么赶进度发一个凑合的文案出去。现在的流程是：工程师修完bug，Claude来起草文案初稿，人类做最终判断，当天就能发。

跨职能的gap不再是瓶颈，开始变成了协作者。人类还是做最终决策的那个人，只是不再是写初稿的那个人了。

然后她说了一个我非常认同的观点：她现在招人主要看两种特质。

一种是有产品sense的创意builder——能识别出该做什么，能快速做出原型。她特意强调了一句：Taste is scarce, typing is not. 品味是稀缺的，打字不是。

另一种是有深厚系统背景的工程师——负责那些“trust but verify”里最需要人的部分，因为subtly wrong is still wrong——微妙的错误仍然是错误。

她说她根本不在乎一个人一小时能写多少行代码，她在乎的是他选择去做什么，以及他如何判断它是对的。当AI能把执行速度提升10倍的时候，决定性的因素变成了——你知不知道应该做什么，以及什么样的结果才叫真正的优秀。这就是品味。

五. 如何推动团队变化

Fiona她们团队有一些有意思的核心原则。

她把团队原则分成了两类：左边灰色是必须做的硬性要求，右边黑色是团队自己摸索的空间。本质上，就是给团队设计了一个harness——核心是大的方向统一，具体怎么落地，各团队自己定。

Fiona总结了三件她最看重的事情：

1. 保持团队尽可能扁平，管理者支持各个小组的工作，但保持灵活，让人员能流动到工作最需要的地方。
2. 如果Claude能做的事，就让Claude做，这能腾出手来做更难的工作。
3. 人不会主动去删除流程，只会在旧流程上面继续叠新流程。所以你得主动站出来，指名道姓地说出哪些流程可以走了。

这三条说起来都没什么特别的，但难在执行，尤其是第三条。Fiona说，她之前在一个团队里，有一个每周的review会议，一大群人坐在会议室里，但她发现所有人都在看电脑，只有轮到自己汇报时才抬头说两句status，说完又低头继续看电脑。很多会议，其实都是这样的。

然后她问了一句：我们为什么还在开这个会？这时候，所有人才意识到——好像，这个会根本不需要。于是，从此这个会就取消了。

这种事太常见了。无数的流程和会议，当初设立的时候都有道理，但环境变了、工具变了，它们早就失去了存在的意义，只是因为惯性还在那里被迫运转。没有人觉得它有用。但很多时候，也没有人站出来说一句：这破会太浪费时间了，能不能别开了。

AI在组织里介入得越深，就会发现越多的步骤和流程其实已经可以自动化了。如果不主动去审视，这些步骤就一直在那里，最后变成纯粹的形式主义。

最后，Fiona还放了三个她在思考的问题——她没有答案，但很有意思。

第一，你还需要独立的iOS和Android团队吗？因为现在工程师已经可以更灵活地跨平台工作了。
第二，全自动化的review到底能推到多远？在“够快了”和“我们漏掉了什么重要的东西”之间，那条线在哪里？
第三，当角色越来越模糊的时候，怎么确保所有角色都对自己的产出有信心？

把这三个问题放出来这个动作本身就很有价值。你会发现，即使是Claude Code的亲爹团队，也没有把所有事情都想明白。他们也在摸索。很多时候，这本来就不是一个有标准答案的事。

每一次大型技术的到来，都不只是工具升级。整个组织的运作方式，很多时候都要推倒重来。所谓的AI原生，AI Native，也并不是买几个Claude会员或者包个API Key，给大家用就算AI转型了。真正的AI原生组织，从规划方式到知识管理到评审流程到人才结构，每一层都是重新设计过的。

而贯穿所有这些变化的，其实就是开头说的那个最朴素的思维习惯：遇到重复的事，自动化掉。遇到没用的流程，干掉。遇到不需要人做的判断，交给AI。一个一个来，不着急，但不能停。

最后，用Fiona的最后一段话作为结尾吧。

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

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

来源：互联网