Fiona Fung（冯菲奥娜）
01演讲核心论点
问题不在工具，在你的流程。
The tool is not your problem. Your processes are.
Fiona 开门见山：不要讨论「该用哪个 AI 工具」，要讨论的是「全面采用 AI 之后，你的整个运营模式会发生什么」。
她在 Claude Code 团队上观察到一个根本性的转变：写代码已经不再是工程团队的瓶颈了。 不只是「不那么慢」，而是产出量已经发生了数量级的跃升。旧有的约束 — 写代码、写测试、重构的时间 — 正在消失。但新的约束正在浮现，而且它们比旧的约束更难解决。
旧瓶颈（正在消失）
写代码的速度、测试覆盖、重构人力、编码吞吐量
新瓶颈（正在浮现）
代码验证是否正确、代码审查人力、安全审计、跨职能协调（法务/设计/合规）
Fiona 的原话：「在 Claude Code 团队，写代码真的已经不是慢的那部分了。不只是不慢 — 吞吐量真的、真的大幅增加了。」当 Noah Zweben（Anthropic 另一位工程负责人）的团队在三个月内将每周合并到主分支的 PR 数量从 500 提升到约 1,150 时，文档和验证流程成了新的卡脖子环节。
过去服务你的东西，未必会继续服务你。
What served you prior may not serve you any longer.
02五个正在崩溃的旧流程
Fiona 指出，大多数团队的流程是为「人类亲手建造」的世界设计的。当每一个 PR 都是 AI 辅助完成时，这些流程的底层假设就站不住脚了。
流程很少会自我消亡。我们倾向于一层又一层地往上堆。
Processes rarely kill themselves. We tend to just layer more and more on top.
-
规划规范（Planning Norms）
六个月路线图在三个月后就失效。Fiona 提出「JIT 规划」——像编译器一样，在正确的时间规划正确的量，不多不少。在 Claude Code 团队，「先写设计文档再写代码」的仪式已基本被 PR 和原型取代。
-
代码所有权（Code Ownership）
「这是谁写的？」在 AI 辅助编码的世界里变成了越来越奇怪的问题。Fiona 的重新框架：别问「谁写的」，问「谁导致了回归？谁能回答客户问题？谁有上下文？」然后再问：Claude 能帮我回答这个问题吗？
-
代码审查（Code Review）
Claude Code Review 已经承担了风格检查、lint、bug 捕捉、补全测试。人类审查者的重心应该转向：法务合规、信任边界、安全敏感代码、产品感和品味。Fiona 的原则：「信任，但要验证。」
-
团队构成（Team Make-up）
角色正在模糊：工程师在做内容设计，PM 在提交代码，非工程师在用 AI 构建产品。Fiona 现在招聘时看两类人：一是有产品感的创意建造者（好奇心、迭代、追求愉悦），二是深度系统专家（分布式系统、基础设施）。她不再那么看重「纯编码速度」。
-
知识共享（Knowledge Sharing）
文档不再是真相来源。在 Claude Code 团队，「代码库本身就是真相来源」。Fiona 回答客户问题时，打开的是 Claude Code 桌面版和本地仓库 — 而不是 wiki 或 Confluence。
03Anthropic 的推行模式：强制 + 弹性
Fiona 分享了 Anthropic 内部推行 AI 原生工程文化的双轨模型：一部分是非协商的强制机制，一部分是交给团队自己决定的弹性空间。
| 强制机制（Forcing Function） | 弹性空间（Room to Adapt） |
|---|---|
| 每位工程师必须使用 Claude Code（跨职能伙伴也不例外） | Claude 在每个团队的事故排查中扮演什么角色 |
| 「Claudify everything you can」— 如果还在手动做，先问 Claude 能不能做 | 规划仪式、站会、值班轮次的具体形式 |
| 明确授权：可以杀掉旧流程（最被低估的一条） | 哪些工作流优先被 Claudify |
核心原则：强制原则，让团队拥有实现方式。
具体案例：站会的消亡与重生
Claude Code 团队曾经做站会，后来换成共享电子表格做每周更新。某天 Fiona 看着表格想：「等等，这还有意义吗？」于是他们写了一个 Claude 驱动的站会脚本 — 30 秒设置，所有人自动同步。她强调这种思维方式不是「怎么把 AI 加进这个流程」，而是「这个流程还值得存在吗？」
另一个案例：50 人的每周例会
一个 50 人参加的每周状态会，所有人盯着笔记本等到自己发言。Fiona 问：「我们为什么要开这个会？」没人能给出好答案。于是他们取消了它。50 个人的时间，就这样还了回来。
04三个必须立即基线化的指标
Fiona 在演讲中放了一张幻灯片：「每位工程 leader 现在就应该基线化的三个数字」。
吞吐量很棒，但真的要想想你怎么衡量你真正想解决的问题。更多 AI 生成的代码不是目标。质量、可靠性、用户愉悦才是。
05Fiona 自己也没答案的问题
演讲中令人尊敬的一点是，Fiona 坦诚地列出了一系列她自己也在思考、还没有定论的问题。这不是一份「照着做就行」的蓝图，而是一份「我们一起探索」的邀请。
尚未回答的组织难题
- 当工程师可以高效跨平台开发时，独立的 iOS 团队和 Android 团队还有意义吗？
- 在把审查推向全自动之前，临界点在哪里？什么时候会丢失重要的东西？
- 当角色边界模糊时，如何确保每个人仍然感到同样高效、同样被需要？
Fiona 的回应：「这些问题还没有剧本。模型在进化。今天需要大量人工验证的东西，六个月后可能需要得少得多。」
06金句墙
过去服务你的东西，未必会继续服务你。
瓶颈已经从写代码转移到了写代码周围的一切。
技术争论中，代码说了算。
流程很少会自我消亡。我们倾向于一层又一层地往上堆。给你的团队明确的授权去杀掉它们。
信任，但要验证。
挑出你最吵的流程。最贵的那个。你的团队最怕的那个。问一个简单的问题：它还在服务于原本的目的吗？然后要么自动化它 — 要么杀掉它。
07实践要点总结
强制使用 + 弹性实施
原则不可妥协，但具体怎么落地交给团队。每个人都必须用 AI 工具，但站会怎么开、哪些流程先改，团队自己决定。
代码取代文档成为真相来源
不再维护会过时的 wiki。让 AI 从代码库中实时提取答案。问题是「答案在哪里」变成「怎么问 Claude」。
管理者先当个体贡献者
Fiona 坚持自己写代码。她认为管理者用自家产品能建立团队信任、让 bug 更有紧迫感、给自己「创造者时间」。
追踪三个核心指标
入职上手时间、PR 周期时间、AI 辅助提交占比。如果 PR 周期没变短，检查 CI/CD 是否成了新瓶颈。
验证左移（Shift Verification Left）
随着吞吐量激增，质量不能靠事后检查维持。必须在编码阶段就嵌入更强的验证机制。
招聘标准重新校准
不再以「纯编码速度」为核心指标。看两类人：有产品感的创意建造者 + 深度系统专家。
08写在最后
Fiona Fung 的这场演讲之所以在工程管理圈引发广泛讨论，不是因为她给了一份「照着做就行」的操作手册，而是因为她坦诚地描绘了一个正在发生的组织转型 — 包括已经验证有效的方法，也包括她自己还在困惑的问题。
她的核心信息可以压缩成一句话：AI 改变的不是工程师个体如何工作，而是工程组织如何运行。 当编码速度提升十倍时，审查、验证、协调、规划的旧模式就会像公路上的减速带一样，从「可接受的摩擦」变成「致命的瓶颈」。
对于正在经历或即将经历这种转型的团队，Fiona 的建议是：不要等完美答案。选一个最吵、最贵、最让人痛苦的流程，问它是否还在服务原本的目的 — 然后动手。要么自动化，要么杀掉。
在一个你可以成为任何东西的世界里，选择善良。
— Fiona 的座右铭：In a world where you can be anything, be kind.