运营一个 AI 原生的工程组织

• 讲者 Fiona Fung，负责 Anthropic 旗下 Claude Code 和 Cowork 两条线的工程与产品（"I lead engineering and product for Cloud Code and Co-work"）；加入 Anthropic 前曾在 Meta 和 Microsoft 组建并带过团队。本场是 Code with Claude 大会的单人分享，定位是分享带这两个团队学到的经验，"希望你们能找到一两个对自己有帮助的小点子（a couple of tidbits）"。 → 详细
• 全场围绕五个话题：① 瓶颈已经转移（the bottlenecks have moved）；② 哪些团队规范因此"得重写了"；③ 这些规范怎么落地推行（how we rolled it out）；④ 有哪些信号让她"有信心走向是对的"；⑤ 留一道话题给观众带回团队讨论。 → 详细
• 贯穿全场的座右铭，幻灯片小标题写着 "以前对你管用的，现在可能不再管用了"（what served you prior may no longer）。她认为真正帮到自己的就是这块"肌肉"：始终保持成长型心态——"我们的变化速度只会越来越快（our rate of change is just increasing）"，所以要时不时回头问：你定下的规范、流程，"它还在发挥它原本的作用吗（is it still serving its purpose）？" → 详细

• 过去很多年里，工程带宽（engineering bandwidth，工程师能投入的时间精力，是稀缺产能）是一种很昂贵的东西。她点破：我们做软件工程的方式，"几乎所有事情都是围绕着保护这个资源在转"——想做大量规划，是为了"在动手之前就高度确信自己做的是对的东西"；想做严格评审，也是因为"工程带宽是制约因素时，围绕它有一大堆动作"。 → 详细
• 她请观众"跟我坐上时光机往回走，一直回到二十一世纪初"。那时她刚加入 Microsoft 做 Visual Studio，"根本没有'云'这个概念"——"现在听起来很疯狂，对吧？现在云已经无处不在了"。当年构建 Visual Studio 的方式是：就一间服务器机房，每个人都得轮值一周 on-call（值班待命）；整个构建流程是个队列，"我们一次最多只能合并六个 PR"（PR = pull request，一次代码改动的合并请求），而且"任何时候只要有一个测试挂了，你就得去 debug 到底是哪个 PR 导致的失败"。"在那时候，那确实是个很大的瓶颈。"后来有了云、有了持续构建（continuous build，代码一改就自动构建、不必排队），那个瓶颈也转移了——所以 AI 带来的只是"又一次转变"。 → 详细
• 把镜头拉回当下：在 Claude Code 团队，"编码真的已经不是慢的那部分了（coding is really the slow part anymore）"。正因如此，"上游和下游的那些流程，都得稍微做点改变"——核心追问是 "当编码不再是瓶颈时，会发生什么变化（when coding is no longer the bottleneck, what changes）？" → 详细

• 旧瓶颈具体是写代码、写测试、重构（refactoring，不改功能、整理优化代码结构）。亲身故事：刚加入想边熟悉边修 bug，试 TDD（测试驱动开发：先写测试、再写实现）——"先写测试感觉就像吃西兰花一样"（她澄清自己其实很爱吃西兰花，只是拿它当例子），因为"它并不总是整个过程里最享受的那部分"，她"老是手痒，急着想去搭产品"。有了 Claude 后再修第一个 bug，完整步骤是先写测试、验证它确实失败（"这样我才能确认这个测试真的在测某个东西"）、再做修复，做完测试已现成。结果让她大为惊讶——TDD"竟然变得有意思多了、舒服多了，把测试驱动开发里那种'税负'给抹掉了（took the tax out of test-driven development）"，"那对我来说是个很大的顿悟（a big aha）"。 → 详细 → 详细
• 重构同理。以前团队"时不时得做大重构或软件架构清理"，但"永远在纠结：什么时候才能挤出时间？我们明知它非常重要，但它总得以牺牲做产品的时间为代价"。结论——"感谢这些模型，有了 Claude，重构也不再是瓶颈了"。 → 详细

• 当上述旧瓶颈被抹平，新瓶颈随之浮现。第一个是 验证（verification，确认代码到底对不对）——她直说"这是个大问题（a big one）"，原因是 "带宽一下子涨了太多，我们必须更加关注：它对不对？" 加上"角色边界开始模糊、越来越多的人在提交改动时，我们也想确保每个人都对自己的改动是正确的有信心"。 → 详细
• 其他新焦点："谁来评审（who reviews）？这是个非常热门的话题"，以及 "它要怎么维护（how is it maintained）？" 她解释——"因为同样地，现在吞吐量大了太多，你还得去考虑维护的成本（cost of maintenance）"。 → 详细
• 金句：这些旧流程是 "悄无声息地不再奏效（quietly stops working）"。她特别喜欢这个说法，并补了一层因果反思："每当——但愿是这样——有人定下一个流程，那都是为了解决某个问题。但我们经常忘了去复盘、去问：'等等，这些流程现在还有必要吗？或者说它还在发挥它原本的作用吗？'" → 详细

• 鉴于这些转变，她列出一整张"必须重写的团队规范"清单：代码评审（code review）、上手（onboarding）、规划（planning）、招聘（hiring）、组织形态（org shape，团队怎么分组、层级多深）。其中"今天上午 Cat 在演讲里也重点讲了 Claude Code review"，她评价那是个"非常棒的工具"。 → 详细
• 代码归属权（code ownership） 被重新拷问：现在 Claude Code 几乎所有提交都由 Claude 共同署名（co-authored by Claude）——"过去这几个月里，我印象中就没见过哪个提交不是这样的（I don't think I've ever saw a commit that wasn't）"。组织形态：她们"真的很想让所有人都更敏捷、组织更扁平"，但有个反直觉安排——每个 manager 一开始都先做 IC；知识分享（knowledge sharing） 也变了，她抛出悬念："当文档也许不再是你的事实来源时，会发生什么？" → 详细 → 详细

• 新原则一句话概括："在技术争论里，代码说了算"，配套金句 "构建很便宜，争论很贵（building is cheap, arguing is expensive）"。案例：她上手时想做代码重构，和 Boris 在方案上有过几次争论（a couple of debates of approach）；"要是搁在以前"她会说"嘿 Boris，咱们去会议室白板上画出来吧"，但她转念"多亏有了 Claude，我其实可以直接生成出来"——于是 当场生成三个不同版本的 PR，因为"我想看的不只是代码怎么实现，还有对同事们的影响（impact to the colleagues）"。 → 详细 → 详细
• 原型设计（prototyping） 是另一例。多年前一场争论分两派：一派认为原型"让你快速行动、搭出大致骨架、对产品有直观感觉"；另一派担心"你做代码原型是偷工减料（cutting corners）"，怕"勉强能跑的原型让你产生执念、舍不得扔，硬着头皮想发布——可它压根不是为规模化构建的（not built to scale）"。她的结论：有了 Claude，原型既是"很好的起步方式"，又能 "把一个原型更快地扩展到生产环境（scale out a prototype to production a lot faster）"——两派顾虑同时被化解。 → 详细

• 减掉的：深度设计文档。她说"我以前待过的团队，可能你们也一样，会写设计文档（design docs），那种特别深入的规划和设计文档"；而现在 "我们大部分讨论其实都发生在 PR 或者原型里"，原因是"工程产能现在提上来了、写代码不再是瓶颈"。 → 详细
• 加倍投入的：验证。她强调这是"我想确保我和我们团队持续做得更好的一点，因为现在产能这么充裕，怎么验证质量就变得更加重要"。她给这套做法起名 "左移"（shift left，把质量把关动作尽量往开发流程的更前端、更靠近源头的位置挪）。 → 详细
• 金句逻辑（把因果讲完整）："有什么比你自己撞上 bug 更糟呢？对我来说真的很难受的是，当我听到客户、开发者、还有你们大家撞上某段代码的问题时，我总会想：'唉，要是我们能先发现就好了。'"紧接着反转："但其实有什么比我先撞上这个 bug 更好呢？那就是我们提前部署好自动化，在更靠近源头的地方就把它抓住（automation in place actually catch it closer to the source）。" 所以团队"一直在琢磨：怎么不断往左移、把更多东西自动化"。 → 详细

• 旧问题——"嘿，这块儿最后是谁动过的？谁是这部分代码的 owner（负责人）？"——她现在的建议是深挖问题的根源："如果你发现自己在问这个问题，就去深挖一下……你到底想搞清楚什么？你是在找谁引入了某个回退（regression，原本好的功能被改坏了），还是在找某个人来回答一个问题？还是你想补充一些 context（背景信息）？"而很可能 "Claude 其实就能帮上你这个忙"。 → 详细
• 她举了自己设的一个 routine（例行任务，指让 Claude 按固定流程自动跑的活） 作为例子：每天早上"就着早晨那杯咖啡"，让这个 routine "把所有反馈渠道里的反馈都过一遍……帮我把所有反馈汇总到一起，帮我识别出共性的主题（identify themes）"。 → 详细

• "你是怎么跟上 code review 的节奏的？"——上线 Claude Code 的 code review 功能前，这是她"经常被问到的问题"。她说 Claude Code review "绝对是真正帮到我们的一个工具，让我们能跟上写代码的产能"。Claude 真正擅长的地方：代码风格和 lint（代码格式/规范检查）、"那些明显的 bug"；还有——"如果你有一份 spec（规格说明，对功能该怎么做的书面定义），我鼓励你把 spec 也提交进代码库（check into your code base），因为 Claude 特别擅长检查代码有没有偏离 spec（spec drift，代码逐渐跑偏、与当初的规格说明不一致）"。 → 详细
• 但她紧接着强调 "仍然非常重要的一点是，还是要有人在回路里（human in the loop，关键环节始终保留人来把关）"。哪些地方即便在 code review 里"依然非常需要人"？法务审查（legal reviews）、任何涉及风险容忍度（risk tolerance）的东西，"尤其是当你看信任边界（trust boundaries，系统里区分可信/不可信的那条分界线）的时候"。核心原则是 "信任但要验证（trust but verify）"，以及"人在哪些地方能贡献那些不可或缺的专业判断"。 → 详细

• 案例"Mr. Peanut（花生先生）"：去年十二月她想给 CLI 里的 Claude 加点节日气氛，"野心还挺大，我想把 Claude 变成一个雪人（a snowman）"。她写了个示例请设计师 review，结果设计师给了"特别棒的反馈"："不，这一点都不像雪人。你这是把 Claude 变成了 Mr. Peanut（花生先生）。"（她解释 Mr. Peanut 是美国一个罐装花生品牌的吉祥物。）她当场认了："我的天，你说得太对了。我还以为是个雪人，可你说得没错，这就是颗花生。"结论：在产品这件事上，同样要把人的专业判断保留在回路里。 → 详细
• 怎么练产品直觉（她在旧金山讲完后"有很多工程师跑来问"）：第一步是 dog fooding（吃自家狗粮，自己天天用自己做的产品；Anthropic 内部叫 ant food）。"尤其对管理者来说，真的要确保自己花时间去用你正在做的、你团队正在做的产品"——每次加入新团队，亲自用产品"就是我最先做的几件事之一"，因为 "这样你才会真正打心底里感受到你的产品（feeling your product in your bones）"，会一直追问"我当初做这个产品时，想解决的到底是什么问题？想为用户创造什么样的体验？"团队成员看到她亲自用产品常会说"看到你用我们的产品太棒了，因为这说明你是真的在乎（you really care）"。 → 详细
• 产品直觉还来自 "不断迭代、发布，然后走出去跟客户聊（going out to speak to customers）"。她个人特别热衷和小企业打交道——"我觉得小企业是构成我们社区的命脉（the lifeblood that forms our community）"，Anthropic"刚刚发布了面向小企业的 Claude"。她有很多开餐厅的朋友"工作起来真的特别拼"，于是亲自带他们上手 Cowork，"因为我想看看，在企业客户之外，小企业用户实际是怎么完成上手的"，结果收到"特别宝贵的反馈"——"看到在上手流程里有那么多本可以做得更好的地方，真的很让人清醒（really humbling）"。警示金句：如果不 dog food，"过一阵子你可能会发现自己做的产品决策全都只是基于一些指标、仪表盘或者 PowerPoint（metrics or dashboards or PowerPoints）"——所以"一定要用自己的产品，用、用、再用"。 → 详细

• 她强调"这点很有意思，因为我发现它适用于所有角色"。设计师方向：以前 Claude Code 团队的设计师想做打磨或 UX 修正（polish or UX fixes），都得"画出标注稿（red line），然后交接给工程"，可这"总是要等，因为工程那边永远是：我得做这个产品、我得修这个 bug，哪有时间做打磨"。现在设计师会用 Claude 自己做很多这类打磨，"把那个迭代闭环收得快多了（closes that iterative loop a lot faster）"。反过来对工程师：她自嘲"作为工程师，我写东西往往特别啰嗦（very verbose）……往往会陷进太多细节里（go too much into the weeds）"，而 "Claude 在内容设计上是个特别好的搭档（a really great content design partner）"。总结：对所有角色，Claude 都在你不那么擅长的那些地方增强着你（augmenting all the areas where you may not be strong）。 → 详细 → 详细

• 这是她口中"也许是个有点'辣'（spicy）的话题"的讲管理者那一页，也是她刚加入 Claude Code 最先改的一件事之一：她跟招聘团队合作推动让 每个 manager 一开始都先做一段时间的 IC。动机是"我太相信亲自用产品这件事了"，而 "在 Claude Code，我们用 Claude 来构建 Claude，我们用 Claude Code 来构建 Claude Code"。 → 详细
• 她说这招"效果特别好"，因为它让管理者 "在还没背上'支持下属'这份责任之前，先有时间真正撸起袖子、扎进代码库里，亲身体会在这个团队里当一名工程师是什么感觉"。她还补一句对管理者的邀请：现在是个好时机去 "把一些动手编码的时间（maker hours，能专心写代码/造东西的整块时间）拿回来，重新回到代码库里，因为现在上手要比过去轻松得多了"。 → 详细
• 她补充经历佐证：早在来 Anthropic 之前，她就常在 manager 和 IC 之间来回切换，"每次切回去做 IC，都真的帮我充实了工程上的工具箱（engineering toolbox）"。只是"那个重新上手的过程总会让人有那么一点点犹豫……如果你有阵子没干这个了，它确实会让人发怵（daunting）"——但上手 Claude 时的体验"特别不一样"，这正好引出下一节。 → 详细

• 上手 Claude 时，"代码就是我们的真相来源（the code is our source of truth）"。她现在仍会"去跟团队里所有工程师碰面"，但"现在我们更多聊的是大家心里最关心的事（what's on top of minds）"；而以前她"总会去做那种技术深挖（tech deep dive，对某块系统做深入的技术讲解/钻研）"，现在她"第一次的技术深挖其实是直接跟 Claude 一起做的"，因为"Claude 特别擅长回答我所有的这些问题"。 → 详细
• 具体到修第一个 bug 前，她会先问 Claude："嘿，在我扎进这个 bug 之前，你能先教我一点这块涉及的范围（surface area，这块功能牵涉到的代码面/影响范围），还有这个 bug 周边那些区域的情况吗？" → 详细
• 她给所有团队的建议："不管你的真相来源是什么，哪怕是一份 spec，你都可以把它转成一个 skill，然后 check in 到代码库里（把它做成一个 Claude 技能、提交进代码仓库）。只要能做到，就把你的真相来源放进代码库，因为这样你才能真正让它保持最新。"原因她也讲透了："写代码的时候，带宽要大得多。这也意味着，任何不在这个更新循环里的文档（any documentation that isn't part of the update loop），都更容易变得过时。" → 详细

• 落地的总原则是两条腿走路。必须作为一个团队对齐（自上而下）的是 Claude Code 团队的几条原则，她们管它叫 "强制函数"（forcing function，一种强制大家必须照做、从而把行为掰过来的机制）。她笑称那张列原则的幻灯片"其实已经过时了，我都不该列出来"——因为现状已经是"每个 engineer、每个队友都在用 Claude Code，现在其实也都在用 Cowork"。这几条原则在第十五节逐条展开。 → 详细
• 同时她"想给自下而上（bottoms up）的空间留出余地，因为每个团队关注的点不一样，可能各自有不同的工具链（tool chain）"。留给自下而上的自由包括："Claude 在团队 triage（问题分诊，把涌进来的 bug/任务按轻重缓急分类处理）、各种规划仪式、站会（stand-up，每日简短同步会）里怎么用，或者哪些工作流先被 Claude 化，这些很大程度上都是自下而上决定的"。她总结这个平衡："在团队文化里什么重要这件事上要对齐，并且随着情况变化不断更新这些东西，但同时给每个小组（pod，小型自治团队）留出适配的空间。" → 详细

• 第一：尽量让组织保持敏捷、保持扁平——具体做法是"让管理者也去支持一部分具体工作，同时也真正深入代码库，直接对产品的某些部分负责（directly responsible for parts of the product）"。 → 详细
• 第二：Claude 化（Claude-ify）——"如果 Claude 能做，那就该让 Claude 做（if Claude can do it, Claude should）"，"这永远是我们在问自己的问题"。配套观察："今天早上你们听了关于模型的演讲，模型在以惊人的速度进步"——"有时候你会发现，哪怕两三个月前 Claude 还做不好某件事，现在随着一次模型更新，它其实已经做得非常好了"。这正是为什么要"永远重新审视、永远保持成长型心态，因为模型也在飞快地进步"。 → 详细
• 第三：明确授权大家去砍掉老的流程（explicit permission to kill old processes）。理由是 "人是不会主动去删流程的，流程往往只会越堆越多（people don't delete processes on their own, they tend to pile up）"。反例非常具体：她以前待过一个团队"有一大堆不同的 SLA（service-level agreement，服务等级协议，对响应/处理时限的硬性承诺）——P0 bug（最高优先级故障）有个 SLA，事故响应有个 SLA"，多到"连 engineer 都来找我说：'一天就只有 24 小时，我到底该先做哪个 SLA？'"她当时就意识到"我们真的该好好审计一下（audit），这些 SLA 是不是都还有必要"。补一句：哪怕是她们自己定下的团队原则和流程，"过了几个月之后……我们总是给自己留出这种权限，随时去批判、随时重新审视"。 → 详细

• 上手时间（onboarding ramp-up time）下降。具体口径是 "一个 engineer 从入职到提交第一个 PR 要花多长时间（time it takes for the engineer to land their first PR）"；这个时间、以及 "他对其他队友造成的占用成本（costs to other team members）" 都在持续下降——"很多时候，一个新人加入团队来问我问题，我会说：'这是个好问题，我们应该去问 Claude。'"她还点出对管理者的副作用：以前重回代码库时"我会觉得很不好意思……我得去问某个 engineer，这会占用他一天里的时间，因为他们都太忙了。但现在多亏了 Claude，我不觉得我在浪费任何人的时间了"。 → 详细
• PR 周期时间（cycle time，一个 PR 从发起到合并/上线走完全程所花的时间） 应该下降，"但这个指标挺有意思的"。她的关键提醒："你不能只看端到端的总时间，而要把它拆开，看看一个 PR 里到底有哪些不同的环节（funnels / chunks）"——因为 "如果你的 PR 周期时间没下降，不一定说明你没在用 AI，也可能是你队列里别的环节被堵住了，正是因为吞吐量上来了。比如说，你的 build 和 CI（continuous integration，持续集成：每次改代码都自动构建并跑测试的系统）系统跟得上吗？" 健康做法是把周期时间"拆成各个环节，看看其中哪些是你能改进或者自动化的"。 → 详细
• Claude 辅助提交（Claude-assisted commits）上升："过去这几个月里，我几乎没见过哪个 commit 不是 Claude 辅助完成的。"但她跳出来强调 "比纯粹的吞吐量更重要的是——不管你和你的团队在试图解决什么……想办法去衡量它（find some way to measure that）。因为除了吞吐量之外，我们希望也在做出有意义的改变，让产品更好、或者提升质量"。 → 详细

• 给作业前她特意"非常坦诚地说：我自己也还有很多问题没想明白"，分享了几个仍在摸索的问题。①"你还需要把 iOS 和 Android 拆成两个独立的组织吗？"——"这算是比较传统的组织方式"，但现在 Claude 让"engineer 能灵活地跨不同移动平台来回切换（flex across different mobile platforms）"，于是在想"真的还需要两个独立的移动团队吗？" → 详细
• ②"完全自动化的 review 你要推到多远（how far do you push fully automated reviews）？"——要在"够快"和"不丢掉重要的东西"之间把握平衡。③角色边界正在变模糊，"怎么确保每个人都保持高产？这就是为什么我们现在在重点研究验证（verification）"，要确保"每个做出改动的人都对自己的改动有信心"。她还提到团队 "其实刚刚发布了 Claude design"，正思考怎么改进团队里各个职能（all the functions）的工作流。 → 详细

• 行动号召："挑出你最'吵'的那个工作流（pick your noisiest workflow）"——"也可以只是某个你不太喜欢、或者对团队来说成本特别高的工作流或团队会议"，然后问自己 "它还在发挥它该有的作用吗？"，或者"如果它成本真的很高，这是不是 Claude 也许能帮你处理的事情？"，关键是 "一步一步来，慢慢做（do this one step at a time）"。 → 详细
• 配套反例画面很传神：她在另一个团队待过，"我们有个每周开的、成本特别高的会，我注意到所有人都低头盯着自己的笔记本，除了轮到自己汇报状态时抬一下头，汇报完又埋回笔记本里"。她的算账方式："你数一数这屋里坐了多少人，这是个成本极高的房间（a very expensive room）。"她希望大家带这道题回团队讨论，并很想听这些内容是否引起共鸣。最后以"非常感谢大家听我的分享……很荣幸"收尾，全场鼓掌。 → 详细

（本场为单人演讲，无 Q&A / 闪电问答环节。）

收尾金句留作团队讨论："Pick your noisiest workflow… and always ask yourself, is it still serving its purpose?"——挑出最"吵"的工作流，反复自问它是否还在发挥原本的作用；成本太高的，看看 Claude 能否帮忙，一步一步来。 → 详细