#533. Anthropic如何运营一个 AI 原生工程组织 - 跨国串门儿计划

这期播客是"跨国串门儿计划"通过 AI 声纹克隆技术翻译的 Anthropic 内部分享会。主讲人 Fiona Fun 负责 Claude Code 和 Cowork 的工程与产品，此前曾在 Meta 和微软带领多个大型产品团队。她在这次分享中系统回顾了自己在搭建 Claude Code 团队过程中的核心教训——而这些教训跨越了她在三家公司的经历，同样成立。

本期最核心的洞察是：AI 已经让工程带宽不再是最昂贵的资源，瓶颈已经发生了根本性的转移。 当写代码变得便宜，围绕"写代码很贵"这一假设建立的一整套流程——计划方式、代码审查、团队结构、知识分享——全部需要重写。Fiona 逐一分享了 Claude Code 团队在每个维度上的具体调整：减少了什么、增加了什么、遇到了什么新问题。她反复强调的一句话贯穿始终：

"以前管用的东西，今天未必还管用。"

最反直觉的发现是：即使在 Anthropic 这样的 AI 原生公司内部，流程的惰性依然顽固——流程很少会自己死掉，必须有人主动去清理。而 Fiona 给出的最核心建议，也是她"最喜欢的一条原则"：明确给团队许可，去干掉那些流程。

Fiona 首先带听众做了一趟"时光机"。她回忆了2000年自己职业生涯起步时在微软做 Visual Studio 2005 的经历——

"在那些年里，我们软件是刻在光盘上发布的，再往前其实是软盘。VS 2005 的交付日期是铁打的，因为得把软件送到生产车间，刻盘装进盒子再运到店里卖。"

后来在线分发出现，彻底改变了发布方式。她用这段历史做类比：我们行业一直在适应瓶颈的转移，现在正在经历又一次根本性的变化。

具体到 Claude Code 团队，Fiona 观察到：写代码已经很少是最慢的环节了。 而且不仅是速度变快——吞吐量本身也涨了非常多。多年来，整个软件行业围绕"工程带宽太贵"这一假设建立了大量流程：瀑布开发、敏捷开发、详细的前期规划、排期做重构——

"所有这一切，甚至我们以前做计划的方式，全都是因为工程带宽太贵了。"

当这个瓶颈消失，新的瓶颈浮现了：验证、审查、跨职能伙伴、安全。 因为代码量在急剧增加，但审查和验证的能力并没有同步提升。Fiona 收到工程负责人最多的一个问题就是：

"人类是怎么跟上你们这种写代码的节奏的？"

维护的问题也随之而来——生成大量代码变得容易，但维护成本必须认真考虑。

更隐蔽的是那些"悄悄失效"的流程。Fiona 说她很喜欢"悄悄失效"这个说法：

"很多时候我们设流程是有原因的，可这么多年下来，我发现流程很少会自己死掉，我们往往是一直往上叠。"

她举了一个例子：在之前的团队，高优先级审查事件（SA/P0 级别）太多了，于是她又建了一套优先级排序系统让工程师知道哪条更重要——但这本身就说明流程在不断增生。

Fiona 列出了在 Claude Code 团队不得不重写的规范清单：代码审查、入职方式、计划方式、招聘、组织形态。

计划方式："喷射计划"取代六个月路线图

Fiona 把 Claude Code 的新计划方式命名为"喷射计划"（JIT planning），类比喷射编译（JIT compilation）——在合适的时间做恰如其分的计划，不多也不少。

她回忆自己刚加入时还在问"我们不需要一个六个月路线图吗？"团队花了些功夫写出来，前三个月执行得还行，但过完新年回来发现大量内容已经过时。她得出结论：六个月的路线图在 Claude Code 的迭代速度下已经太长了。 甚至她这次分享的幻灯片，一个月前做的，到演讲时已经得改内容了——比如 routines 这个产品在她做幻灯片时还不存在。

"原型设计和代码生成已经不是瓶颈了。"

技术讨论：代码说了算

Fiona 讲了一个生动的故事。她刚加入 Claude Code 团队时想做一次重构，跟 Boris 进行技术讨论。她差点就拿出了"老工具箱"——

"我差点就拍拍它说走，去那个房间找块白板。然后我忽然打住，等一下，现在我可以直接把我们在讨论的不同方案全都生成出来。"

她让 Claude 生成了三个不同版本的 PR。这件事最关键的价值在于：技术讨论不再只涉及 API 的实现细节，而是能够同时看到每个方案对所有调用方的影响。

"当构建变得便宜，争论却依然昂贵的时候，这又会怎么改变你的团队规范呢？"

但她特别强调，这反而更需要好的团队文化。如果没有文化保障，很容易出现一种病态竞争：

"绝对行不通的一种做法是因为代码生成这么快，就搞成谁最后提交谁赢——我熬到凌晨三点把这个 PR 发上去，设个定时，就为了拿到最后一句话。这种事绝对不行。"

减少的部分

Claude Code 团队不再在每次代码仪式之前写设计文档（但 Fiona 特别说明：在某些团队、某些异步讨论场景下，设计文档仍然重要）。他们大部分讨论是拿 PR 说话而不是靠文档。他们有句内部说法：

"有个想法？去搞个原型。"

产品评审也大幅减少了——因为变化太快，传统的评审跟不上。取而代之的是做原型、让大量内部用户先用起来、收集反馈。

加倍投入的部分

验证。 Fiona 用"左移"（shift left）来描述这个策略：以前是代码发出去之后希望在用户发现之前找到 bug；现在的目标是在更靠近源头的地方，用自动化把问题抓住。

这对于角色模糊化的团队尤其重要。Fiona 举了一个亲身经历：她修了一个关于简历页的 bug，第二天在 Boris 的消息里看到有人报了一个新 bug，当时心里"咯噔"一下——

"不知道大家有没有过那种感觉——这 bug 不会是我搞出来的吧。"

因为吞吐量上来了，她希望每个人——不管什么角色——对自己的改动都能有更高的信心。

代码所有权的模糊化："深挖一层"

"这段代码谁写的？"——以前这个问题很自然，但现在所有 PR 都有 Claude 的辅助，再问"谁写的"就有点奇怪了。Fiona 的建议是深挖一层：当你问"谁写的"时，你真正想回答的是什么？

• 想找谁导致了这次回归？
• 想找专家来回答客户问题？
• 想获取上下文？

找到真正的问题之后，再看有没有办法把它自动化。她举了自己的例子：一个月前她每天早上打开 Claude Code，进到客户反馈频道，让 Claude 帮她总结——这只是一个手动的"晨间仪式"。后来 routines 出来了，她可以设定自动执行，而且比手动做的还好。

Fiona 给出了一个非常清晰的划分框架。

大量靠 Claude 的部分：

• 代码风格和 lint
• PR 反馈请求
• 在正式提交前抓 bug 并修好
• 自动加测试

仍然坚定需要人的部分：

核心原则是信任但要核实（trust but verify）。

第一，法务审查——涉及风险容忍度的决策，Fiona 表示"永远要让法务伙伴参与进来"。

第二，信任边界和安全敏感的代码——仍然需要把专家拉进来。

第三，产品感和品味。她讲了一个有趣的故事：上个假期她想用 Claude Code 给终端里的 Claude 换一个节日皮肤——做个雪人，配上帽子。Claude 生成的结果被同事评价为"你把 Claude 变成了花生先生那样的角色"。后来她让 Claude 做了个简单的冰蓝色雪花图案，但她仍然需要请设计师伙伴来帮她把关产品感觉。

在角色模糊化的大背景下，Fiona 分享了她非常看重的两种工程师画像：

第一种：有产品感的创意构建者。 这类人有梦想、有巨大的好奇心，总是兴奋地发现问题并想用产品来解决，接着会进行大量迭代确保体验令人愉悦。

第二种：深厚的系统专家。 她刚加入 Claude Code 团队时发现产品通才和创意人员挺强，但缺少有分布式系统经验的人。当团队要做 Claude Code Remote 这样需要"保证到处都能跑"的产品时，这些硬核专家不可或缺。

"不管你参与还是支持哪个软件工程团队，你都要想清楚那些最难的地方——那里可能你最需要持续投入。"

她明确表示越来越不看重单纯的吞吐量，因为模型已经让效率大幅提升。

角色模糊带来的新可能

跨职能的缺口变得可以用 Claude 来弥补。Fiona 举了自己的例子：她作为工程师，写作能力"真的挺烂"，想更新问卷的回复措辞但身边没有专职的内容设计师。以前她得找一群内容设计师来回沟通修改，但现在 Claude 成了"非常好的内容设计搭档"，能帮她把措辞打磨得又准又简练。

反过来，产品经理也在大量写代码。

"有了 Claude，非传统编程背景的人现在能做更多工程活。而我们工程师也可以更深入地去碰以前不属于技术范畴的东西，比如内容或者设计。"

扁平与自用

Fiona 讲到自己加入 Claude Code 时面对的招聘压力：团队在问要扩到多少人，招聘团队还在用老一套——十个 IC 对一个经理，然后开始想怎么分层嵌套。但她倾向于保持极其精简的打法。

回顾自己在 Anthropic、Meta、微软的经历——做 Visual Studio、Facebook Marketplace、AR/VR 设备——她发现真正能帮她推出好产品的就是一件事：

"特别狠地、特别深地自己用自己产品，也就是 dogfooding。对领导者来说尤其重要。"

她要求 Claude Code 团队里的每个经理一开始都得先当 IC，理由有二：一是赢得团队信任，二是真正学会如何成为高效的工程师。招聘团队对此有顾虑：

"你要招经理，又让人家先从 IC 开始，哪有经理会对这个感兴趣啊？"

Fiona 的回答很直接：

"在 Claude Code 团队深度用产品就是我们做事的方式，这是我对大家的期望。如果一个人对这个不感兴趣，那咱们还不如早点分开。"

她补充说，如果没有 Claude，她自己根本不可能这么快上手写代码——因为她的时间总在各处切换上下文。Claude 让经理参与 IC 工作变得可行。

代码库即真实来源

在知识分享方面，Claude Code 团队的做法是直接把代码库作为"真实来源"。Fiona 回复客户请求时就直接打开桌面上的 Claude Code，连着本地代码仓库，靠这些就能回答大量客户问题。这样做还能避免以前那种"文档跟代码对不上"的滞后问题。

她也指出，如果你的团队仍然有很好的规格文档，那就把它们放进代码仓库，然后让 Claude 帮你验证代码和规格是否一致。

Claude Code 团队在践行几条核心原则：

1. 每一位团队成员（包括跨职能伙伴）都在用 Claude Code 和 Cowork。
2. 尽可能量化一切。 时刻想着有没有比自己手动做更好的方式——让 Claude 来做。
3. 明确给团队许可去干掉那些流程。 这是 Fiona 最喜欢的一条。

"流程它自己能把自个儿玩死。"

她讲了一个具体的例子：刚进 Claude Code 时团队开站会，后来团队大了改成电子表格填写周进度。有一天大家突然意识到——为什么不写个脚本？于是搞了个站会脚本，用 Claude 跑起来，所有人都能随时看到更清晰的状态更新。

在强制推行和给予自主权之间，Fiona 保持了平衡。核心原则是团队层面必须对齐的，但每个 pod 在具体执行方式上拥有很大的自主权——怎么做分类、怎么做计划仪式和站会、怎么看待 on-call、先量化哪些工作流——这些都由 pod 自己决定。

她加入后优先推进的三件事：

1. 让团队尽可能扁平——只有一个整体团队使命，不让每个 pod 各搞一套，避免转向时要逐一沟通
2. 让 Claude 来做那些比人做得更好的事——让团队解放去做更难的活
3. 主动清理流程——鼓励团队一起看看有哪些流程该放手了

这些原则本身也在持续更新——每隔几个月就反思一下，这条原则现在的效果还跟刚开始时一样吗？

Fiona 推荐关注三个指标来判断变革是否在正确方向上：

第一，入职上手时间（应该缩短）。 一位工程师、设计师或 PM 多快就能在团队里产出有效的工作。Claude Code 团队已经大幅缩短了这个时间。

第二，PR 周期时间（应该缩短）。 这个指标不仅反映 AI 采纳程度的不足，还能帮你发现流水线上其他环节的瓶颈。Fiona 举例：当涌入的代码量大了很多，有时候产品基础架构（比如 CI）可能跟不上工程师提交代码的速度。

第三，Claude 辅助的提交占比（应该上升）。 在 Claude Code 团队，默认每个提交都是 Claude 辅助的——Fiona 近四个月几乎没见过不是 Claude 辅助的提交。

但她特别强调：不要只看吞吐量。 有时候会看到新闻说某公司百分之多少的代码是 AI 生成的，吞吐量当然好，但真正要衡量的是你最终想解决的那个问题。比如 Claude Code 团队更关心的是质量和可靠性。

Fiona 坦诚分享了自己仍在琢磨的几个问题：

iOS 和 Android 团队结构——当工程师能更高效地跨移动平台灵活输出时，传统上分配一个 iOS 团队、一个 Android 团队的做法到底还有没有道理？

自动化审查推到什么程度——平衡点在哪儿？什么时候是够快了，什么时候丢掉了重要的东西？而且随着模型能力持续提升，某一块今天需要人来验证和信任的地方，下一个模型一来情况可能又变了。所以必须不断重新评估。

角色模糊后如何保证每个人都有产出感——这是组织管理层面的新挑战。

她给出的最后一条建议非常实操：

"挑出你那里最吵的那个工作流——可能是最费钱的那种，想一想哪个事儿你自己一想到就怕，或者你团队里根本没人想碰它——然后去问一句，这事儿它现在还有用吗？它当初的目的还存在吗？"

她讲了一个故事来收尾：在之前的团队，她们每周有个复盘会，五十来个人挤在一个大屋子里，每个人都在埋头看自己的笔记本，只有轮到自己汇报状态时才抬头说几句。她问了一个简单的问题："咱们干嘛要开这个会啊？"所有人都说"确实没啥用"，于是直接取消了。

• 瓶颈已经从写代码转移到验证、审查、跨职能协作和安全——围绕旧瓶颈建立的一切流程都需要重新审视
• 流程很少会自己死掉——必须有人主动去清理，Fiona 建议"明确给团队许可去干掉流程"
• "以前管用的东西，今天未必还管用"——在 AI 时代尤其如此，保持成长型思维
• 技术讨论中代码说了算——直接生成多个方案比在白板上争论更有效率
• 代码审查分界线清晰：Claude 做风格/lint/bug/测试，人做法务/安全/产品品味
• 减少前期计划和设计文档，用 PR 和原型说话；加倍投入验证和左移
• 两种工程师画像：有产品感的创意构建者 + 深厚的系统专家；不再看重单纯吞吐量
• 经理先当 IC——在 Claude Code 团队，深度使用产品是做事方式的一部分
• 代码库就是真实来源——减少文档与代码不同步的风险
• 三个衡量指标：入职时间↓、PR 周期↓、Claude 辅助提交↑——但最终看质量和可靠性
• 组织尽可能扁平，只有一个整体使命，给每个 pod 自主权
• 每隔几个月反思原则本身——它还在服务于当初的目的吗？

来源: 播客 · https://www.xiaoyuzhoufm.com/episode/6a02de0b1b7bd50295fd547a

欢迎收听跨国串门计划。这是一档专注于让中文听众无障碍欣赏全球优质外语播客的节目，属于通过先进的AI声纹克隆技术，我们不仅将内容翻译成中文，还完美保留了原主持人和嘉宾的独特声音，为您呈现全球顶尖的AI财经、健康与科技领域精品内容。与我是主播一凯，一位热衷于AI领域的产品经理，很荣幸能为您搭建这座跨越语

言障碍的桥梁。接下来让我为您简单介绍本期我们克隆的这档节目，并分享几句非常精彩的原话，属于本期我们克隆的是enthrop公司内部的一场深度分享会，主题是cloud code团队的成长与工程实践，主讲人fi是cloud code和work的产品与工程负责人。此前曾在meta和微软带领多个大型产品团队。

在分享中，它有几句话让我印象非常深刻，以前管用的东西，今天未必还管用，当瓶颈转移后，你怎么去调整它周边的一切，明确给你许可，去干掉那些流程？因为流程它自己能把自个儿玩死，属于在技术讨论里代码说了算。这些话背后藏着它多年的实战洞察。接下来我们就一起走进这期完整的对话，大家好，听得见吗？好，我保证这不是

什么cloud code的套路，但你们介意我拍张照吗？因为Boris和jry的两点有个分享会，我当时真以为这儿会空下来，我想着那场结束之后不可能还有人特意跑过来。天呐，谢谢大家，我保证我跟Boris没有成天拍自拍。下午好，感谢各位来，我叫Fiona fun，负责cloud code和work的工程与

产品，团队跟Boris cat合作非常紧，来anthro之前我在meta和微软都带过团队，也把团队做大了，今天的分享大概有这么个议程，但核心是想聊聊。在帮cloud code和cowork成长搭团队的过程中，我学到了哪些教训，有意思的是，这些教训哪怕我回想在meta甚至微软那会儿，包括在Anthro

p都同样成立。好玩的是，这份片子我大概一个月前做的，现在已经不得不改一些内容了，比如刚开始做的时候还没有routines这个东西，就连那种工作方式对我来说都还是新的。所以我真的很想聊聊我注意到的五个主题。第一个瓶颈已经转移了，变了，瓶静一变，我们在cloud code团队里就不得不重写一批团队规范。

我还想稍微展示一下，我们重写了哪些规范，怎么推下去的，以及有哪些信号让我觉得方向是对的。对我来说始终得盯着一件事，这套东西是不是还在正轨上。最后我会抛几个我自己还在琢磨的问题再给一些建议，也许你们能带回去跟自己的团队一起讨论。好了，第一部分瓶颈转移了，我管它叫转移，但你们可能会反复听到我念叨这句话，

以前管用的东西，今天未必还管用。而且说实话，不管是回想在anthro还是meta，微软那种持续的成长心态真的是对我特别管用的一项能力，尤其现在，不知道你们有没有感觉变化的速度简直有点离谱对吧。我记得自己第一次搞vicoding是去年那会儿，他还是会出一些bug，我就想怎么全在用常量啊？这可不是好的工

程习惯，可现在他的能力已经强太多了。但这就是我看到的那个有趣的变化，当瓶颈转移后，你怎么去调整它周边的一切？也许你们也感觉到了，多少年来工程带宽一直是最贵的东西，写代码的吞吐量非常昂贵。你想想我们发布软件的那些流程，很多都是围绕这个来的。你好，欢迎。那边有把椅子，把预留标签拿掉吧，没人坐好。这边也有

一把先生欢迎。可是没错，所有这一切，甚至我们以前做计划的方式，还记得吗？我们搞过瀑布，然后又搞敏捷，全都是因为工程带宽太贵了。其实我想稍微岔开一下，这在我们行业不是头一回，我们一直都得适应。我带大家做一趟时光机，跟我一起回到2000年那会儿那是我职业生涯起步的时候，我在做Visual Studio，

当时在发布Visual Studio 2005。不骗你们，在那些年里大家还记得吧？我们软件是刻在光盘上发布的，再往前其实是软盘。所以我现在还记得vs 2005交付日期是铁打的，我们必须赶上。因为得把软件送到生产车间，刻盘装进盒子再运到店里卖。所以你看后来我们能在线上分发软件了，那也彻底改变了发布方式

。所以我现在觉得特别有意思的是，在这个新转变里，工程带宽不再是那个最贵的东西了。据cloud code团队来说，写代码很少是那个最慢的环节了。而且我要说它不只是不慢，吞吐量也真的涨了很多很多。所以不只是耶我们都能做更多了，而是我们产出的量也完全不一样了。我们发现当你的瓶颈从写代码敲键盘本身移开，还记

得吧？以前写代码很贵，写测试很贵，重构也很贵。我还记得那些讨论，我们得排期做重构，可又有产品工作太贵了，你什么时候能找到时间做这些？全都转移了，不再是瓶颈了当这发生以后，我注意到瓶颈常常会挪到其他领域，比如验证审查跨职能伙伴安全，因为写代码不再是瓶颈，而我们又越做越多，这些就成了我们看见的新瓶颈。所

以我们劳德问自己，代码写的对吗？谁来审查？这大概是我从工程负责人那里收到的最多问题之一，人类是怎么跟上你们这种写代码的节奏的？有意思的是还有维护的问题，因为现在生成大量代码也容易多了，维护成本也就得琢磨起来。于是我发现下面这些流程在悄悄失效，我很喜欢悄悄失效这个说法，不知道你们有没有体会，很多时候我

们设流程是有原因的对吧？我们觉得这里有个缺口想改进一下。可这么多年下来，我发现流程很少会自己死掉，我们往往是一直往上跌。我记得在一个团队，我们有一堆sa什么P08G的A高优先级审查事件，反正太多了。后来我就想不行，我们得给优先级排个序，让所有工程师知道哪条s更重要。记得那会儿我就觉得咱们得开始想想哪

些东西该清理清理了。但是没错，这些就是可能曾经管用的流程。再念一遍那句话，以前管用的，今天未必还管用。比如计划规范，我们过去在前期规划上花的时间多得多，因为写代码的时间贵，代码所有权以前也老问。谁写的这段代码谁负责？现在这问题就有点奇怪了，代码审查我们后面再聊。团队构成也很有意思，不光是角色在模糊，

对吧？工程师现在靠AI也能补强非工程岗位的能力，而我的非工程伙伴们也全在提交代码。那角色模糊了，那些竖井也没了会怎么样？这又影响到知识分享，员工入职。这些都是我们在cloud code注意到的信号，说明以前做事的方式也变了。那么第一部分聊了转移，在cloud code团队内部有哪些规范是不得不重写的

呢？我想分享一些，希望有的能引起共鸣或者对你们有用。第一，代码审查也就是由人来判断到底谁需要审查。我们挨着过一遍，入职方式也变了，做计划的方式也变了。你们听我聊过很多计划的话题，招聘尤其随着角色模糊和团队构成变化也变了，还有组织形态，这可是我最爱聊的代次话题。我给大家讲讲，当我在anthro开始推这

些的时候，我爱我的招聘伙伴们，他们特别棒。但我记得有位招聘伙伴真觉得我疯了，这事儿特别想分享给大家。计划怎么变的呢？还有技术讨论计划，我们现在做的少多了，时机也不一样了。我管它叫喷射计划，就像喷射编译一样。因为我刚加入那会儿还在问我们不需要一个六个月路线图吗？我们花了些功夫写了出来，前三管的挺好，结

果过完新年回来一看，好多东西已经变了，我才发现六个月的路线图好像太长。所以又是那个问题，怎么在合适的时间做恰如其分的计划？因为再说一次，原型设计和代码生成已经不是瓶颈了。技术讨论这一块也很有意思，在技术讨论里代码说了算。跟大家讲个故事，我刚开始加入cloud cloud团队时想做一次重构，去熟悉代码

库，于是跟Boris搞了一场健康的技术讨论，到底走哪条路？我差点就抄起我的老工具箱了，我差点拍拍它说走去那个房间找块白板我们然后我忽然打住，等一下，现在我可以直接把我们在讨论的不同方案全都生成出来。我生成了三个片R这件事最棒的地方是对于技术讨论，我不只关心api的实现，也很关心这个变动对所有调用方的

影响。所以当我能让cloud帮我生成三个不同版本时，这场讨论就不止涉及实现，还能顾及对同事们的影响。我觉得这是另一个非常关键的转变。你看当构建变得便宜，争论却依然昂贵的时候，这又会怎么改变你的团队规范呢？我得特地强调，这反而让你更需要建立起好的团队文化来想清楚怎么对齐。比方说绝对行不通的一种做法是因

为代码生成这么快，就搞成谁最后提交谁赢，你懂吧？我熬到凌晨三点把这个pr发上去，设个定时，就为了拿到最后一句话，这种事绝对不行。这更要求你有好的团队文化，能开放诚实的做技术讨论，同时有好的协同。好了，我讲了很多在cloud code我们减少了什么？尤其是计划方面，我们的确不再在每次代码仪式之前都写设

计文档了。我得说某些团队，某些特定场景下，好好考虑设计文档依然非常重要，特别是在做异步讨论的时候。但在cloud code这边，我们大部分讨论是拿pr说话，而不是靠文档。我们有句说法是有个想法去搞个原型，这是另一件事。我们也不怎么做产品评审了，因为变化太快。所以我们做原型让很多内部朋友先用起来。我特

别推崇把它发给你们所有人，然后收到大量出色的反馈，这样我们就能你看这已经把我们的计划一式变成了不靠设计文档，更多是在pr或原型里讨论这些。我们减少了在哪些方面加倍投入了呢？我认为有个领域我们其实需要做的更多，持续做好，那就是验证。因为再说一遍，吞吐量不一样了，而且会有全新的出错方式，那你怎么去规模化

？我管这叫左移，以前是你把代码放出去，我特别希望能在你们所有人发现之前找到bug。而比我自己找到还要好的是，我说的左移就是在更靠近源头的地方，靠自动化把它抓住，这是我觉得需要继续加倍做的事。另外一件事也很有意思，因为角色在模糊，比如我那些设计师伙伴，我就特别希望能更有信心确保我自己提交代码时不会搞坏

什么东西。我记得有一次我修了个关于简历页的bug，第二天在翻看Boris的消息时，看到有人at他说发现了个bug，我当时心里咯噔一下，不知道大家有没有过那种感觉，这bug不会是我搞出来的吧，所以因为吞吐量上来了。我真的想确保每个人不管什么角色，对自己做的改动，对于是谁改的都能有更高的信心。我这里的建

议是因为所有pr都有cloud的辅助，再去问这段代码谁写的这问题本身就有点奇怪了。比这更有用的是我称之为深挖一层。就像过去你问这个改动谁做的时，你真正想回答的是什么？是想找谁导致了这次回归吗？绝对不是要责怪谁，就想知道谁是最后一个碰过这段代码可能引发故障的人，还是想找个专家来回答客户问题，还是想获取

上下文。所以不管那个深挖一层的问题是什么，再想想有没有办法可以自动化。好玩的是我在一个月前开始准备这个分享时，每天早上我都会打开桌面端的cloud code，进到一个客户反馈频道，让他帮我总结。那会儿就是我早上端着咖啡随手做的一个晨间仪式。现在呢有了routines对吧？我可以把它设好，而且比我之前

做的还好。以前是我手动触发，现在每天早上喝咖啡时，我总能拿到相当不错的一份概览。所以我想说的是，代码所有权变模糊了。但反过来请你深挖一层，找到你真正想回答的问题，再看cloud能怎么帮你解决，怎么跟上代码审查的节奏。如果大家今天上午看了发布会k讲过这件事，我们确实大量依靠cloud做代码审查。现在有

意思的是什么地方你可以大量信任cloud，而什么地方你仍然需要人。所以毫无疑问，而且cat也展示了cloud，还很擅长保姆式的照看pr我们确实让cloud处理所有的代码风格，lint和pr反馈请求，甚至可能抓一些bug，在正式提交之前就修好以及加测试，这些是我们大量靠cloud的地方。但我仍然坚定需

要人的地方是那些专业判断，核心就是信任。但要核实，比如法务审查，我肯定永远要让法务伙伴参与进来，这关系到风险容忍度。比如信任边界和安全敏感的代码，我仍然要把专家拉进来。还有一个有意思的方面是产品感和品味。我记得我有个小爱好，喜欢用cloud装饰节日或季节主题。上个假期我想在终端里给cloud换一个假

日皮肤，就跟cloud code d说你能把cloud变成雪人吗？那会儿cloud还不太擅长做艺术，这就要用到产品感了。我请一位设计伙伴帮我看，他给了我特别好的反馈。有人跟我说你把cloud变成了花生先生那样的角色。因为我当时想让他做雪人配对，我就说行，那我搞点更简单的，结果cloud直接整了个冰蓝

色的雪花出来，不过你得保持那种产品感觉。这也引出了一个问题，我的团队到底该怎么搭？因为角色在模糊化，cloud在增强，每个人在cloud code上我会跟大家分享我自己非常看重工程师的两种画像。一种是有产品感的创意构建者。这类人你一看就知道他们有梦想，有巨大的好奇心，他们总是特别兴奋。哎，这里有个问

题，也许我可以搞个产品来解决它，但接下来会有大量迭代，确保体验令人愉悦。另一种呢是深厚的系统专家。我刚加入cloud cloud团队的时候，发现我们在产品通才和创意人员方面挺强，但缺少有分布式系统经验的人。当你在做像cloud code remote这样的东西，要保证我们到处都能跑，你依然得靠这些硬

核专家。所以我想说，不管你是参与还是支持哪个软件工程团队，你都要想清楚那些最难的地方，那里可能你最需要持续投入。但有一点我越来越不看重的就是单纯的吞吐量。因为模型的出现让我们变高效了很多跨职能的缺口也很有意思。比如说我记得我想更新一下我们问卷回复的方式，但身边没有专职的内容设计师配合。我我自己就是工

程师，写作能力真的挺烂的，我写东西很难做到又短又精准，我也不想让问卷在终端里占太多行，因为每行空间都很宝贵。但这时候cloud就派上用场了。换做以前，我肯定得去找一群内容设计师来回沟通，改来改去。但现在cloud帮我补上了，这个角色成了我非常好的内容设计搭档，能帮我把措辞打磨的又准又简练。反过来我也

看到我们的产品经理在大量写代码，这很有趣。所以我得说有了cloud，非传统编程背景的人现在能做更多工程活。而我们工程师呢也可以更深入的去碰以前不属于技术范畴的东西，比如内容或者设计。所以这很有意思。我发现cloud和AI真的把各个角色都增强了，这东西挺刺激的。我记得刚进cloud code的时候，大

家就在说好，你要把团队扩到多少人。我能感觉到招聘那边还在用老一套，比如十个ic对一个经理，然后开始想怎么分层，怎么嵌套，但我自己特别倾向于保持非常精简的打法。其实往回看，不管是在anthropic还是meta还是微软，不管是做Visual Studio还是Facebook marketplace，还

是ar vr设备还是quad，我真正发现能帮我推出好产品的就是特别狠地特别生地自己用自己产品，也就是dofooting对领导者来说尤其重要。现在其实挺有意思，我还能亲自碰代码，但之前有阵子是碰不了的，但我一定会确保自己腾出时间天天都在用我的产品，哪怕没空写代码也得这样。所以我才要求cloud cod

e团队里的每个经理一开始都得先当ic这样既能赢得团队的一些信任，也能真正学会怎么成为一个高效的工程师。然后我把组织架构做的尽可能扁平，因为我想保持超级灵活。但当时我的招聘团队其实有点顾虑，他们跟我讲你要招经理，又让人家先从ic开始，哪有经理会对这个感兴趣啊？我就说在cloud code团队深度用产品

就是我们做事的方式，这是我对大家的期望。如果一个人对这个不感兴趣，那咱们还不如早点分开。但话说回来，要是没有cloud，我根本不可能这么快上手，也没法写代码。因为我的时间总在各处切换上下文切的厉害。所以在座各位经理，我真的很鼓励大家也投入进来。老实说，我在他那几年每年还硬撑着教一次pr但那些代码工作

刘老在变，内部工具也是，我刚学会一个命令，他转眼就变了。现在呢我连get命令都记不住，直接就找clad帮我搞定。那在这么多知识共享里，什么才算是你新的真实来源？对我们cloud code团队来说，代码本身就是真实来源。所以我回复客户请求的时候，就直接打开我桌面上的cloud code，然后连着我本地

的代码仓库，靠这些就能回答大量客户的问题了。对我们来说，用代码库作为真实来源，还可以避免以前那种滞后。你文档总得跟着代码改，很容易就对不上了。不过我觉得这里的关键是做对你团队有意义的事。比如如果你们还有一堆很好的规格文档，那就把他们也放到仓库里，然后让cloud帮你去看看，去验证一下我的代码跑起来是

不是还跟规格上我期望的一样。那这些我们是怎么推行的呢？我之前过了一遍，我们改变了的那些规范。有意思的是这里头有个混合，有哪些东西我们得作为团队规范强推。比如必须跟团队对齐，又有哪些地方我要放手让每个小组自己发挥。在cloud code里头我们有好几个pod，我想要让每个pod都用对他们来说合理的方式

去工作。所以谈到平衡，谈到强制手段，就是跟大家对齐那些必须做的事。这里有几条是我们cloud code团队真正在践行和呼吸的核心原则。顺便提一下，我还是要回到成长型思维，永远想想某件事，他现在对我们还有用吗？我们也在持续更新这些准则。每隔几个月我们就反思一下，嘿这条现在的效果还跟刚开始时一样吗？它还

在服务于我们当初想达到的目的吗？比如说我其实该换一下这一页幻灯片了，他不是说每个工程师都用cloud code，那太显然了。真正写的是每一位cloud code团队成员，包括跨职能的伙伴都在用，而且实际上我们也都大量在用code work。还有一条，尽可能量化一切。我们总在想有什么比我们自己做更好，

那就是让cloud来做。所以时刻留意有没有什么你可以自动化的地方，不管是验证还是做更多左移。在你正干着某件事的时候，就要想这里有没有cloud能帮上忙的地方。最后一条是我最喜欢的，明确给你许可去干掉那些流程，因为流程他自己能把自个儿玩死。但你在支持团队的时候，很关键的一点是要持续给团队拿到快速反馈，

搞清楚哪些事占用了我们大量精力。我记得刚进cloud code的时候，我们还开战会，后来团队大了一点，我们就搞了个电子表格，所有人把每周进度往上填。突然有一天我们恍然大悟，哎，我们干嘛不干脆写个脚本呢？就写个站会脚本，然后直接用cloud跑起来，这样我们所有人都能随时更清晰的知道别人在干嘛，这就是个

例子。有一天我盯着那个表格突然觉得等等，这还有意义吗？所以我们要不断提问，不断清理碎片，干掉那些成就流程。我想要确保的是给每个po留足适应空间。其实每个团队在怎么做分类，怎么用cloud来分类，怎么做计划仪式和站会，怎么看待on call以及先量化哪些工作流。这些事上都拥有很大的自主权。所以我们通常

不会强制的说你必须把这个自动化，我们有一些建议和经验教训，但一定给你的团队留出空间，尤其他们面对的问题领域可能各不相同。那如果往大了看，我加入close code后，觉得真正带来最大变化的是我优先推进的三件事。第一，让团队尽可能扁平。比如经理们会放火给po但保持非常敏捷。在cloud code和co

work这边，我们只有一个整体的团队使命。因为你有时候一键po每个po就想自己搞一套使命，以后要转向的时候得花大量时间给每个人再讲一遍。但如果保持越平越好，我觉得对我们帮助特别大。第二，让cloud来做那些比我们自己干的更好的事，去发掘cloud怎么帮到你，他能真正让我们解放，去做更难的活。第三呢，

流程真的会越积越多，所以我鼓励你跟团队一起看看有哪些流程其实是你们该放手的了。那这么做真的管用吗？具体数字我不能展开讲，但我觉得你可以关注三个比较通用的指标，看看在你团队里推行这些变化时，是不是开始把你往对的方向带了。首先是入职上手的时间我们已经大幅缩短了，这很有意思，你能看到一位工程师、设计师或者

pm多快就能在团队里产出有效的工作。其次是pr周期时间在缩短，这点我觉得值得深挖一下，因为它不光帮你看到AI采纳上的不足，还能帮你发现流水线上其他环节是不是在扩展上遇到了瓶颈。比如说现在我们涌入的代码量大了很多，有时候产品基础架构那块，比如ci可能跟不上了，撑不住工程师们往里交代码的速度。所以那两个

时间往下走是好事儿。但同时还有一个该往上走的就是cloud辅助的提交。比如在我们这默认每个提交都是clou辅助的，我大概最近这四个月都没怎么见过不是clou的辅助的提交了，希望这三个指标你可以在自己团队里看看是不是能对上。但我也想说，除了看提交数量，也想想最终目标，往回看你做的产品到底是想让用户更爱

用，还是想解决什么问题？有时候你会看到头条说这家公司百分之多少的代码都是A生成的。我觉得吞吐量当然好，但你真的得想清楚怎么去衡量你真正要解决的那个东西。比如我们就特别想保证质量和可靠性，所以这些才是我们现在更关心的东西。好，最后一部分就是审视你自己的努力。我坦诚跟大家说，其实我自己还有几个问题一直在

问自己，其中一个很有意思的是iOS和and卓ID的组织结构。当工程师现在能更高效地跨移动平台去灵活输出时，那种传统上分配一个iOS团队，一个android团队的做法到底还有没有道理？这一点我自己也还在琢磨。另外自动化审查到底该推到什么程度？平衡点在哪儿？什么时候是够快了，什么时候我们又丢掉了重要的东

西。这又回到那句话，信任但又要验证。有意思的是你今天可能也听到了，在之前Dario的演讲里也提到模型的能力还在持续提升。所以呢哪怕你某一块工作现在需要验证多个信任，下一个模型一来情况可能又变了。所以为啥要不断重新评估，而且角色在模糊，你怎么保证每个人都感觉自己同样有产出？所以如果让我给大家最后一条忠

告，那就是挑出你那里最吵的那个工作流。我说的最吵可能是最费钱的那种，想一想哪个事儿你自己一想到就怕，或者你团队里根本没人想碰她，然后去问一句，这事儿他现在还有用吗？他当初的目的还存在吗？我这再给大家讲个好玩的事儿。我以前在一个团队，我们每周有个复盘会，那个会贵的要命。五十来个人挤在一个大屋子里，然后

我注意到每个人都在埋头看自己笔记本，就除了轮到自己抱状态的时候才会抬头说几句，然后又低下去。我就心想这回也太贵了吧。我就只问了一个简单的问题，咱们干嘛要开这个会啊？就这一个问题，所有人都说是啊，确实没啥用，于是我们把它直接取消了，所以这就是为啥要一直多想一步。我觉得大家可以带回去做的一件有趣的事，就

是看看你那里有没有哪个工作流你是可以去自动化的，或者干脆想一想他现在还到底在不在起你当初想要的作用。好了，我的分享就到这里，非常感谢各位来听我本来是真心觉得这屋子会空空的，谢谢你们没让我一个人站这儿。我今明两天都在，要是有任何问题或者想再多聊会儿，欢迎过来介绍你自己，咱们随时聊，谢谢大家。