如何运营一家原生 AI 驱动的工程组织
故事是这样的。
Anthropic 的一场开发者大会上，Claude Code 的工程总监 Fiona Fung 站上台，看了看台下满座的观众，说了句大实话：
“我发誓这不是 Claude Code 的特别安排，但我真的以为这个房间会是空的。”
因为在她之前，Boris 和 Jared 的演讲刚结束，她本以为大家都走了。结果呢？一个关于“如何用 AI 重构工程团队流程”的分享，座无虚席。
这说明什么？说明很多人已经意识到了一件事——当 AI 编码能力飞速提升，真正的瓶颈已经不在写代码这件事上了。
编码不再是瓶颈，那瓶颈在哪儿？
Fiona 的核心观察很清晰：过去十几年，工程团队的所有流程——从瀑布到敏捷，从代码审查到发布流程——本质上都是围绕一个前提设计的：工程带宽很贵，编码吞吐量是瓶颈。
她分享了一个很有画面感的回忆。2000 年代初她在微软做 Visual Studio 2005，那时候软件还印在 CD-ROM 上（更早是软盘）。团队有极其严格的截止日期，因为代码写完得送工厂刻盘、装箱、发到零售店。那套流程的瓶颈，是“从开发到用户手里”的物理时间。
后来软件可以在线分发了，发布流程变了。现在 AI 能帮你写代码了，瓶颈又变了。
在 Claude Code 团队，Fiona 发现了一个很直观的变化：编码很少是最慢的那环了。不只是“不慢”，而是整个产出量发生了质变。以前需要排期讨论“我们什么时候安排重构”的问题，现在 Claude 几分钟就能生成多个重构方案。
所以瓶颈转移了。转移到了哪儿？验证、审查、跨职能协作、安全合规。代码写得快了，但“谁审查这些代码”“怎么保证质量”“非工程师也在提交代码了怎么办”——这些才是新问题。
五个必须重写的团队规范
Fiona 分享了 Claude Code 团队重新定义的五个核心领域。坦白讲，每一条都值得任何正在用 AI 工具的团队认真想想。
1. 规划：少做一点，做得更快
Fiona 刚加入时问团队：“我们不需要一份六个月的路线图吗？”
大家花力气写了一份，前三个月还挺好用的。然后新年假期回来，发现很多东西已经变了。六个月的路线图，在这种变化速度下，显得太长了。
所以 Claude Code 团队转向了她所说的 JIT 规划（Just-In-Time Planning），类似编程里的 JIT 编译——需要的时候再做，做到刚好够用。
具体来说：
- 减少了设计文档：大部分讨论从“先写文档”变成了“直接提 PR”或“先做原型”
- 减少了产品评审：因为市场变化太快，不如直接做原型给内部用户用，然后发布给所有用户听反馈
- 验证反而加码了：代码产出量大了，保证不踩坑的自动化测试和 CI 就得更强
说白了，以前是“想清楚再做”，现在是“先做出来再快速迭代”。因为做的成本已经很低了。
2. 技术辩论：代码说话
这条挺有意思的。
Fiona 讲了个故事。她想做一个重构来熟悉代码库，跟 Boris（Claude Code 的另一位负责人）产生了技术分歧——两种方案各有优劣。
换以前，她会怎么做？拉着 Boris 去会议室，对着白board画架构图，讨论半天。但她突然意识到：等一下，我现在可以让 Claude 同时生成三种方案的 PR 啊。
她真的这么做了。三个 PR 放在那里，不只看了 API 的实现方式，还看了每种方案对所有调用方的影响。这不是纸上谈兵的白板讨论，是拿着真代码在做决策。
Fiona 总结得很好：
当构建成本很低，争论才是昂贵的。
但她也特别强调了一点：这反而让团队文化和对齐变得更重要了。绝不能出现“谁最后提交谁赢”的局面——比如有人凌晨三点偷偷提交 PR 试图定调。这种事必须零容忍。
3. 代码审查：该信谁？
这是 Fiona 收到最多的问题：“人类怎么跟得上你们的代码审查？”
Claude Code 团队的做法是分层：
Claude 负责的部分：代码风格、lint 规则、PR 反馈、自动添加测试、甚至 babysit PR（盯着 PR 状态，自动修复小问题）。这些机械性的、规则明确的工作，全交给 AI。
人类必须负责的部分：
- 法律审查：涉及合规的代码，必须让法律团队过目
- 安全敏感代码：信任边界、安全相关的逻辑，必须有专家审查
- 产品感和品味：Fiona 讲了个好玩的例子——她曾让 Claude 把终端里的 Claude 图标变成雪人主题（圣诞节日氛围），结果 Claude 的 ASCII 艺术水平堪忧，设计师朋友看完说“你把 Claude 变成了花生人先生”。这就是 AI 目前还替代不了的——审美判断。
4. 团队构成：不再拼手速
当 AI 能大幅提升编码效率后，招人看什么？
Fiona 说她现在重点看两类人：
第一类：有产品感的创意构建者。有好奇心、有热情、会想“这里有个问题，也许我能做一个产品解决它”，并且愿意不断迭代到体验令人愉悦。
第二类：深度系统专家。她刚加入时发现团队产品通才很多，但缺分布式系统专家。当你在构建 Claude Code Remote 这样的产品——让 Claude 能在任何地方运行——你仍然需要那些真正懂底层的人才。
而她明确说不再那么看重的是原始编码速度。因为模型已经帮你提升了很多效率。
5. 组织结构：尽可能扁平
这是 Fiona 说的“最辣的话题”（spicy topic）。
她的做法：每个管理者必须先从 IC（独立贡献者）做起。不只是技术管理者——是所有人。
招聘伙伴当时觉得她疯了：“你要招管理者，但让他们先做 IC？没人会感兴趣的。”
Fiona 的回答很坚定：这就是 Claude Code 团队的 dogfooding（吃自己的狗粮）。如果你不愿意用自己的产品来做实际工程工作，那不太适合这个团队。
她说了一个让很多人共鸣的感受：在 Meta 的时候，她每年会努力提一个 PR，但内部工具和流程变化太快，等她学会一个命令，那个命令已经换了。现在呢？她说自己连 git 命令都记不住了，全靠 Claude 帮她搞定。
团队结构上，她坚持尽可能扁平，让管理者带领小型 pod（小组）工作，但共用一个整体使命。因为一旦每个 pod 都搞自己的使命，跨组调动和协作的成本就会很高。
推行变革：平衡强制与自主
这些规范不是一天建成的。Fiona 分享了她推行的方法论：
必须对齐的底线（全团队统一）：
- 每个团队成员（包括跨职能伙伴）都用 Claude Code
- 能用 AI 自动化的，就用 AI 自动化
- 给团队明确的“杀死旧流程”的许可
给 pod 留出自主空间：
- 各小组自己决定怎么做 triage
- 自己规划 stand-up 的形式（他们从站会 → 周报表格 → 最终写了个 Claude 技能自动汇总进度）
- 自己决定优先 Claudify 哪些工作流
关键是持续问一个问题：这个流程还在服务于它的初衷吗？ 如果不是，就砍掉它。
Fiona 提了一个有趣的观察：
流程很少会自己消亡。它们只会一层一层叠加。我见过一个团队搞了太多 SLA，最后不得不给 SLA 排优先级，让工程师知道哪个 SLA 更重要。
怎么知道方向对了？
Fiona 给了三个她关注的信号：
- 新人上手时间大幅缩短：不管是工程师、设计师还是 PM，加入后能更快产出有效成果
- PR 周期时间缩短：但要注意，如果只看这个指标，可能会发现瓶颈转移到了 CI/CD 或基础设施上——因为代码提交量太大了，构建系统可能跟不上
- Claude 辅助提交的比例上升：在 Claude Code 团队，默认每个 commit 都是 AI 辅助的。Fiona 说她已经大概 4 个月没见过非 Claude 辅助的提交了
但她特别提醒：别只看代码量。你会看到新闻说“某公司 X% 的代码由 AI 生成”，但吞吐量只是手段，真正要看的是产品质量、用户体验和可靠性。
几个她自己还没想清楚的问题
Fiona 坦诚地分享了她仍在思考的问题，这些可能也是很多团队正在面对的：
- 当工程师可以更高效地跨平台工作（iOS + Android），传统的“iOS 团队”和“Android 团队”的分法还合理吗？
- 全自动化的代码审查要推到什么程度？在“足够快”和“遗漏重要问题”之间的平衡点在哪？
- 角色在模糊化，但怎么确保每个人都觉得自己是高效和有价值的？
写在最后
Fiona 的分享给了我一个很清晰的启发：AI 不只是改变了“怎么写代码”，它改变的是整个工程组织运转的方式。
如果编码不再是瓶颈，那围绕“编码是瓶颈”设计出来的所有流程——冗长的规划、沉重的文档、层层审批——都需要重新审视。
她给了一个很实用的建议：
选一个你团队里最“吵”的工作流。最贵的、大家最不想做的、或者最痛苦的。问一个简单的问题：它还在服务于它的初衷吗？
有时候，就这一个简单的问题，就能帮你砍掉一个 50 人参加、却每个人都在低头看电脑的周会。
代码不值钱了，但软件依然昂贵。 昂贵的部分转移了——从“写代码”转移到了“验证、协作和决策”。认清新瓶颈在哪里，才是 AI 时代工程管理的第一课。
评论互动