夜雨聆风写在前面
代码以前是贵的。围着这根承重柱，一整个工程组织搭起来：waterfall、agile、PRD、设计评审、code ownership、refactoring sprint。所有规矩都为了一件事，写代码贵，得省着用。
现在敲键盘几乎零成本。承重柱搬走了。但围着它布的那一套家具，会议、流程、组织阵型，还在原地。
Fiona Fung 在 Code with Claude 2026 大会上演讲
Anthropic Claude Code 团队的工程总监 Fiona Fung 在 Code with Claude 2026 大会上，把过去一年她在 Claude Code 团队的「砍」和「重砌」摊开讲了一遍。她要问的问题比「怎么用 AI 提效」狠：以前为了「写代码贵」布的整个阵型，现在哪些得拆？
演讲视频：https://www.youtube.com/watch?v=igO8iyca2_g
她开场就把这事说清楚了：
What served you prior may not serve you any longer.
过去对你有用的，现在不一定还对你有用。
——Fiona Fung
下面是她拆出来的 14 个具体点位。
1. 瓶颈搬家了
瓶颈从写代码搬到了写代码周围的一切：验证、评审、跨职能、安全
工程产能（engineering bandwidth）不再是贵的那一头。代码生成快了一个量级，但「这代码对不对」「谁来 review」「跨职能怎么对齐」「安全怎么把关」这些事，反而成了新的堵点。
For years, engineering bandwidth was the expensive thing. Coding throughput was really expensive... Now, coding is rarely the slow part anymore.
很多年里，工程产能都是昂贵的资源，代码产出本身就是贵的。但现在，写代码已经很少是慢的那一环了。
——Fiona Fung
Because coding is no longer the bottleneck, and also we're doing so much more of it, these are some of the new bottlenecks that we're seeing: verification, review, cross-functional partners, security.
因为写代码不再是瓶颈，再加上我们写得比以前多得多，新的瓶颈就在这些地方冒出来了：验证、评审、跨职能协同、安全。
——Fiona Fung
她顺手回到了 2000 年代初。那时候她在做 Visual Studio 2005，软件要刻成 CD-ROM 寄到店里，「分发」才是真正的卡点。互联网起来之后，那一根柱子早就换了位置。现在 AI 又把柱子搬了一次。
2. 流程不会自杀
这是整场演讲最值得记住的一句。流程不会大声宣告「我失效了」。它只会静悄悄地停作用：你还在每周二开会，还在填那张表，但它早就不产出价值了。
Rarely do processes kill themselves. We tend to just layer more and more and more processes on.
流程极少会自己死掉。我们的本能反应是不停地往上叠加新流程。
——Fiona Fung
These were some of the processes that I noticed quietly stops working.
这些，就是我注意到的、悄无声息就停止起作用的流程。
——Fiona Fung
她举的例子是 SLA。以前一个团队搞了一堆，P0 bug SLA、code review SLA……多到她得做 stack rank，让工程师知道哪条更优先。每条 SLA 当初都解决过一个真问题，但谁也不会主动来砍。
3. 计划：从「六个月路线图」到 JIT
One thing we reduced：design doc 仪式；One thing we doubled down on：验证
Fiona 刚进 Claude Code 团队的时候还在问「我们要不要做个六个月路线图」。结果团队花了很大的劲写完，三个月后她过完年回来一看，基本作废。
她把计划改成「Just-In-Time」，像 JIT 编译，要用的时候才编。
I call it JIT planning, almost like JIT compiling. When I first joined, I'm like, "Don't we need a six-month roadmap?" And we put some effort in, we wrote it, it was pretty good for three months, and then I came back over the new year and so many things had changed already.
我管这叫 JIT planning（即时规划），有点像 JIT 编译。我刚加入团队的时候还在问"我们要不要做个六个月路线图"——结果花了点劲写出来，前三个月还能用，过完年回来一看，已经变了一大半。
——Fiona Fung
Prototyping and code generation is just not the bottleneck that it used to be.
做原型、生成代码这件事，已经不再是过去那种瓶颈了。
——Fiona Fung
逻辑很简单：原型变便宜后，原型本身就是最便宜的对齐方式。你不用再写一份 RFC 让大家读完再讨论再改，直接写一个 PR 给大家看就行。
4. 技术辩论：用三个 PR 替代白板
In technical debates, code wins — Building is cheap. Arguing is expensive. Keep in mind alignment.
有一次她想跟 Claude Code 团队的 Boris 重构一段代码，本能反应是约个会议室画白板。
她在最后一刻刹住了车：现在让 Claude 直接生成三个版本的 PR 不就行吗？三份具体方案，连「会影响哪些调用方」都看得见，比白板上抽象画两个箭头有用十倍。
In technical debates, code wins. I almost tapped him on the shoulder to go, "Let's go to that room and have a whiteboard." Wait, wait, wait, wait. Nowadays, I can just generate all the different options we've been discussing. I generated three PRs.
技术辩论里，代码说话。我差点就拍着他肩膀说"走，咱们去会议室画白板"——等等、等等、等等、等等。现在我可以直接把我们讨论的所有方案都生成出来。我直接做了三个 PR。
——Fiona Fung
When building is cheap, arguing [is] expensive.
造出来变便宜的时候，争论反而变得昂贵。
——Fiona Fung
但她也补了一句警告：建造便宜了不等于可以「谁最后 check in 谁赢」。团队对齐反而更重要：
What totally won't fly is, because code is so much faster for us to generate, it shouldn't be like the last person who checks in wins. "I'm going to stay up at 3 a.m. to submit this PR. I set up a routine so that I get the last word in." Definitely a no-no.
绝对不能接受的是：因为代码生成变得这么快，就搞成"谁最后 check in 谁赢"。比如"我熬到凌晨三点提 PR"或者"我设个 routine 让我自动抢最后一票"——这些绝对不行。
——Fiona Fung
5. 设计文档：换成 PR
Claude Code 团队基本不写 design doc 了。讨论的载体是 PR。
Most of our discussions, instead of a doc, is a PR. "Hey, we found an idea, go prototype." We don't really do a lot of product reviews because the landscape is changing fast. Let's prototype, let's actually get a lot of internal ants using it, and then ship it out.
我们大部分讨论的载体不是文档，而是 PR。"嘿，我们想到一个点子，去做个原型出来。"产品评审会我们也开得少，因为环境变化太快。直接做原型，让一堆内部用户用起来，然后发出去。
——Fiona Fung
某些场景她也留了口子，比如异步讨论、规模较大的 spec，文档还是有价值的。她真正要打的不是文档本身，是「让大家讨论的对象，从一份描述变成一个能跑的东西」。
6. 验证：往源头推（Shift Left）
砍了那么多，砸进去更多的是验证。生成快了，错的也快了，所以要把验证往最源头推，越早越好。
I call it kind of shift left. In the old days, you would get code out and I would love for me to find bugs before any of you find it. What's better than me finding a bug is actually shift left—more automation, so we catch it earlier to the source.
我把这个叫 shift left（左移）。以前代码发出来，我希望在你们之前先抓到 bug。但比"我抓到 bug"更好的，是把验证往左移——加更多自动化，越靠近源头越早抓住。
——Fiona Fung
而且现在非工程角色（PM、设计师）也在提 PR，「我提交这个改动会不会搞坏什么」这种信心，对所有角色都更关键，不只是工程师的事。
7. Code Ownership：换个问法
「这段代码是谁写的？」这个问题在 Claude Code 团队变味了。所有 PR 都是 Claude 协助写的，「谁写的」本身就过时了。
她的处理是：往下追一层，你真正想问的是什么？
Because all our PRs are assisted by Claude, [asking who wrote it] is a little bit of an odd question. What is more helpful is what I call double clicking into it. Are you looking for who caused this regression? Or are you looking for an expert to answer a customer question? Or are you looking to gain context?
因为我们所有 PR 都是 Claude 协助写的，问"谁写的"本身就有点怪。更有用的做法是我说的"再点一层进去"——你到底是想找出谁造成了这个 regression？还是想找懂这块的专家来回答客户问题？还是想了解上下文？
——Fiona Fung
想抓回归？让 Claude 跑 bisect。想找专家？让 Claude 解释代码。想要上下文？让 Claude 摘要。具体的问题换具体的工具。
8. Code Review：信任但验证
哪些活交给 Claude，哪些必须人盯，边界要划清。
样式、lint、加测试、babysit PR、甚至抓简单 bug，这些 Claude 完全接管。
We definitely have Claude handle all the styling and lint and PR feedback requests, even maybe catching some bugs and fixing them before it does a full commit. And also adding tests.
我们确实把代码风格、lint、PR 反馈处理这些都交给 Claude 了，甚至在正式提交之前就让它抓一些 bug 并修好。加测试也是。
——Fiona Fung
下面这些她坚持要人来：
Where I still definitely want a human is that expertise. It's all about trust but verify. Legal review—I always want to make sure I'm getting my legal partner. Risk tolerance—trust boundaries and security sensitive code, I still want to make sure I'm pulling in the experts.
我依然坚持要人来做的，是那些需要专业判断的部分。核心原则就是"信任但验证"。法律审核——我一定会拉法务伙伴一起。风险判断——信任边界和涉及安全的代码，我还是要把专家拉进来。
——Fiona Fung
法律、安全、信任边界、产品 taste，这几样，人盯。
9. 招人：押 Dreamers 和分布式专家
她不再 index on「打字快、产出多」，AI 把这条抹平了。她重押两类人：
On Claude Code, there's two profiles for engineers that I'd really heavily indexed on. One are creative builders with product sense—usually you'll see these are the dreamers. The other one is deep systems expertise.
在 Claude Code 团队，我重点押两类工程师。一类是有产品感觉的创意建造者——通常就是那些 dreamers（梦想家）。另一类是深度系统专家。
——Fiona Fung
What I index less on is raw throughput, because thanks to the models, we just saw a lot more efficient.
我现在不太看重的是纯粹的产出量，因为模型已经把这部分效率拉得很高了。
——Fiona Fung
AI 拉低了「做出东西」的门槛，「做出好东西」反而稀缺，这是 dreamers 的活。有些硬骨头 AI 啃不动（比如分布式系统），那就靠专家。
10. 组织形态：扁平 + Manager 必须先做 IC
No 10:1 ratio here. Every manager started as an IC.
这是 Fiona 自己说「最辣」的一条。
招聘伙伴一开始觉得她疯了，说「没有 manager 愿意降级做 IC」。她坚持。
I wanted every manager in Claude Code to start out as an IC first. And also earn some street cred with the team and really learn how to be an effective engineer.
我希望 Claude Code 团队的每个 manager 都先从 IC（一线工程师）做起，先跟团队挣得一份信任，也真正学会怎么做一个有效的工程师。
——Fiona Fung
My recruiters had some concerns. They said, "You want to hire managers and they will start as an IC first. No manager would be interested in that." I'm like, "Well, this is what dogfooding on the Claude Code team is about. And if someone's not interested, it's better for us to do an earlier separation."
我的招聘伙伴当时有点担心。他们说："你要招经理，还得让他们先做 IC，没有经理会愿意干这个。"我的回应是："这就是 Claude Code 团队的 dogfooding（吃自己的狗粮）。要是有人不愿意，那不如咱们早点分道扬镳。"
——Fiona Fung
逻辑很简单：你不亲手用产品、不踩坑、不写 PR，你就不知道流程哪里在卡。Dogfooding 不是口号，是 manager 的硬指标。
What I have found to really help me ship great product is heavy heavy heavy dogfooding.
我的经验是，真正帮我交付出好产品的，是大量、大量、大量地用自己的产品。
——Fiona Fung
组织尽可能扁。一个团队一个 mission，不让每个 pod 各搞各的目标。这样要转向的时候，不用花一周让每个 pod 重新对齐。
11. 真相源：从文档迁回代码
以前文档是真相源（source of truth），因为代码看不过来。现在 Claude 能直接读代码答客户问题，代码本身成了真相源。
On our team on Claude Code, the code is the source of truth. That's why when I'm answering customer requests, I just have my desktop Claude with desktop Claude Code and my local repository. Having that code base be the source of truth also prevents some of the lag that you might have had before of how to keep up the documentation correct with the code.
在我们 Claude Code 团队，代码就是 source of truth（唯一事实来源）。这就是为什么我处理客户问题的时候，开桌面版 Claude + Claude Code + 本地仓库就够了。让代码做事实来源，也消除了以前"文档要怎么跟得上代码"这个时间差。
——Fiona Fung
如果团队有很好的 spec，那就把 spec check 进仓库，让 Claude 拿 spec 去验证代码。source of truth 是什么，看团队的实际情况。
12. 落地策略：少量原则 + 大量自治
砍砍砍听起来很猛，但 Fiona 的具体打法是温和的。
她给全团队画了三条红线：
1. Every Claude Code team member uses Claude Code—including cross-functional partners.
每个 Claude Code 团队成员都用 Claude Code——包括跨职能伙伴。
2. Claudify everything you can. What's better than one of us doing it? Having Claude.
能让 Claude 干的就让 Claude 干。比"我们其中一个人去做"更好的是什么？让 Claude 来做。
3. Explicit permission to kill old processes.
明确授权——你有权砍掉老流程。
——Fiona Fung
红线之外，每个 pod 自己定规矩。一个例子：团队从 standup 演化到每周填 spreadsheet，最后她一拍脑袋，「这个不应该写个 skill 让 Claude 跑吗？」
最值钱的是第三条「明确授权砍老流程」。流程不会自杀，所以「砍」这件事必须从「造反」变成「职责」。
13. 怎么衡量
她没有给出具体数字（「I can't go into the explicit numbers」），但给了三个 directional signal：
新人 onboarding ramp-up 时间下降 PR cycle time 下降 Claude-assisted commit 占比上升（她团队过去四个月基本 100%）
By default every commit is Claude-assisted. I don't think I've seen a non-Claude-assisted commit probably in the last 4 months or so.
我们默认每个 commit 都是 Claude 协助完成的。过去四个月左右，我应该一个非 Claude 协助的 commit 都没见过。
——Fiona Fung
但她紧接着泼了盆冷水：
Sometimes you see in all the headlines, "This company said X percent of code is now generated by AI." I think throughput is great, but really think about how you measure what it is that you're actually really trying to solve. We really want to make sure we're keeping an eye on quality and reliability.
你经常会看到各种新闻标题"某公司说他们 X% 的代码现在是 AI 生成的"。产出量是好事，但你要认真想一下：你真正想解决的是什么？我们盯的是质量和可靠性。
——Fiona Fung
她团队真正盯的是 quality 和 reliability。「X% 代码 AI 生成」是空的，要看用户感受到的质量。
14. 收尾
Pick your noisiest workflow. Ask if it still earns its place.
她结尾给听众布置了一个动作：
Pick your noisiest workflow. By noisiest, it could be most expensive, what's something that you yourself might be dreading, or even your team might not really look forward to. And ask, is it still really serving its purpose?
挑出你最吵的那个流程。所谓"最吵"，可能是最贵的、你自己最头疼的、或者团队大家都不情愿做的那个。然后问一句：它现在还在 serve 它本来的目的吗？
——Fiona Fung
一句话总结
承重柱搬家了，围着它布的所有家具，都该重新摆一遍。
或者用 Fiona 自己反复在台上自问的那一句：
Is it still serving this purpose?
它还在 serve 当初设立它的那个目的吗？
——Fiona Fung
这一问，比她讲的所有具体改动都重要。
生成变便宜后，「该不该做」比「做得快」重要十倍。大家都盯着 AI 让产出翻倍，但真正稀缺的资源已经从「产出」换到了「判断」：判断哪个流程该留、哪个该砍，判断哪个版本对、哪个错。
下次开会前，先问一句：这个会，还在 serve 什么？
