写于 2026 年 6 月
2026 年 5 月，Anthropic 在旧金山举办首届 Code with Claude 开发者大会。除了产品发布，有一场演讲引起了广泛讨论——Claude Code 工程总监 Fiona Fung 的《Running an AI-native Engineering Org》。
这不是又一个「AI 提效 10 倍」的故事。Fiona 讲的是一个更根本的问题：当写代码不再是瓶颈，围绕它的一切流程——规划、评审、团队结构、知识共享——全部需要重新设计。
核心论断：瓶颈没有消失，只是转移了
Fiona 的起点判断很清晰：过去几十年，软件工程的所有流程——无论瀑布还是敏捷——本质上都围绕一个约束在运转：工程师时间贵。写代码贵，所以你需要大量前期规划、设计文档、评审会议来管理这个最昂贵的资源。
但在 Claude Code 团队，写代码已经很少是拖慢速度的环节了。
瓶颈转移到了哪里？验证、代码评审、跨职能协作、安全。 代码生成速度极快，新问题变成了：这些代码对不对？谁来 review？怎么维护？
她用了一个精准的类比：从马车到汽车，不只是把马换成发动机，整个公路系统、交通规则、城市规划都要重新来过。
五个正在失效的旧流程，以及重建方式
1. 规划：从长期路线图到 JIT
Fiona 说她刚加入团队时写了一份漂亮的六个月路线图。三个月后就过时了。
现在的做法叫 JIT 规划（Just-In-Time）——在对的时间做恰好足够的规划。不再写长篇设计文档再开会讨论，而是直接做原型，让内部用户试用，根据反馈快速迭代。
她提了一个我很认同的观点：技术分歧的最快解决方式不是继续吵，是让 Claude 把两个方案都做成原型，看实物判断。
Building is cheap. Arguing is expensive.
这不是说规划不重要，而是规划的时机和深度要匹配实际的不确定性。当做出原型的成本比写 PRD 还低时，原型本身就是最好的规划工具。
2. 自动化：重复三次以上的事情，全部自动化
Claude Code 团队有一个近乎肌肉记忆的习惯：每遇到一个重复性工作，条件反射地问一句——能不能把这件事自动化？
Fiona 举了自己的例子：她以前每天早上手动总结各渠道的客户反馈。后来变成了后台自动运行的任务。事情本身很小，但这个习惯才是重点。
过去自动化成本高，只有高频、高价值的事情才值得投入。但现在自动化成本趋近于零——Claude Code 可以在几分钟内帮你搭建一个 hook、一个定时任务、一个工作流。逻辑反过来了：几乎所有重复超过三次的事情，都应该被自动化掉。
团队把这个原则提炼成三条硬性要求之一：“Claudify everything you can”——能让 Claude 做的，就让 Claude 做。
3. 代码评审：Trust but Verify
Fiona 说她过去半年被其他工程 leader 问最多的问题是：「你们人怎么跟得上 code review 的速度？」
答案是分层。Claude 负责处理风格检查、linting、PR 反馈、bug 捕捉、补充测试——这些以前占了 review 工作量 60-70% 的部分。人类 review 聚焦在真正需要专业判断的地方：
- 法律合规与风险评估
- 信任边界与安全敏感代码
- 产品方向与品味判断
关键点在于，trust 和 verify 之间的那条线是动态的。今天需要人做的事情，下一个模型版本可能就能做了。你必须持续重新评估这条线在哪里。
4. 团队角色：品味稀缺，打字不是
在 Claude Code 团队，角色界限已经很模糊了。PM 在写代码，工程师在做内容设计。以前要等内容设计师排期写文案的流程，现在变成工程师修完 bug → Claude 起草文案 → 人类做最终判断，当天就能发布。
Fiona 说她招人主要看两种特质：
- 有产品 sense 的创意 builder——能识别该做什么，能快速做出原型
- 有深厚系统背景的工程师——负责那些最需要人类判断的验证工作
Taste is scarce, typing is not.
她说得很直接：「我不在乎你一小时能写多少行代码。我在乎的是你选择去做什么，以及你怎么知道它是对的。」
当 AI 把执行速度提升 10 倍时，决定性因素变成了你知不知道应该做什么，以及什么样的结果叫真正的优秀。
5. 流程治理：人不会主动删流程
这可能是五条里最容易被忽视、但最重要的一条。
Fiona 观察到一个规律：人不会主动删除流程，只会在旧流程上继续叠新流程。 没有人觉得某个会议有用，但也没有人站出来说「这个会可以不开了」。
她举了自己的例子：一个每周 review 会，所有人坐在会议室里看电脑，只有轮到自己汇报时才抬头说两句 status。她问了一句「我们为什么还在开这个会？」——从此这个会就取消了。
她总结了三条核心原则：
- 保持团队尽可能扁平，管理者支持各组工作，但让人能灵活流动到需要的地方
- Claude 能做的让 Claude 做，腾出手来做更难的工作
- 主动站出来指名道姓地砍掉过时流程
第三条最难执行。AI 在组织里介入越深，你会发现越多过去的流程其实已经可以自动化或直接取消了。如果没有人主动审视，它们就会一直占着位置，成为纯粹的形式主义。
三个未解问题
Fiona 最后放了三个她自己也没有答案的问题：
- 还需要单独的 iOS 和 Android 团队吗？ 工程师已经可以更灵活地跨平台工作了。
- 全自动化 review 能推到多远？「够快了」和「漏掉了重要东西」之间那条线在哪里？
- 角色越来越模糊时，怎么确保每个人对自己的产出有信心？
我觉得她把这些问题公开放出来这个动作本身就很有价值。即使是 Claude Code 的核心团队，也没有把所有事情想明白。
我的几点观察
规划的悖论
JIT 规划听起来很自由，但它对团队的判断力要求更高了。过去的重规划流程虽然笨重，但它有一个隐性好处：给了所有人一个同步认知的机会。砍掉设计文档后，你需要其他机制来确保团队对方向的共识——可能是更频繁的非正式同步，可能是更好的 AGENTS.md / CLAUDE.md 规范。
规划变轻不等于方向可以模糊。原型先行的前提是，你知道原型要验证什么假设。
自动化的真正门槛不是技术
Fiona 说团队已经形成了「自动化肌肉记忆」。但我观察到的现实是，大多数团队的阻碍不在于「能不能做自动化」，而在于认知惯性——人们习惯了手动做某件事，甚至没有意识到它可以被自动化。
真正的转变不是学会用某个工具，而是养成那个「反射性追问」的习惯：这件事我是不是在重复做？能不能让 AI 接管？
Trust but Verify 的平衡线会持续移动
今天 Claude 能处理 60-70% 的 review 工作。明年可能是 85%。后年可能是 95%。每次模型能力跃升，你都需要重新评估人类应该聚焦在哪里。
这意味着组织需要一种持续校准的机制，而不是一次性划定边界。每个季度，甚至每个月，都应该重新问一次：哪些判断现在可以放心交给 AI 了？哪些新的风险点出现了？
关于品味
「Taste is scarce, typing is not」这句话很精准，但它也暗示了一个不那么舒服的推论：纯执行型角色的空间在急剧收缩。
如果你的核心竞争力是「写代码快」而不是「知道该写什么代码」，处境会越来越尴尬。这不是危言耸听——Fiona 明确说了，她招人不看每小时产出多少行代码。她看的是判断力和品味。
对个人来说，这意味着需要有意识地投资审美能力、系统思维、领域理解——那些 AI 目前还无法替代的东西。
结语
Pick your noisiest workflow. Ask if it still earns its place.
找到你最繁琐的那个工作流，问问它：还配占着这个位置吗？
这句话是 Fiona 演讲的最后一句，也是我觉得最值得每个团队 leader 拿回去行动的一句。
AI 原生不是买几个 Claude 会员、包个 API Key 就算转型了。从规划方式到评审流程到人才结构，每一层都需要重新设计。 没有标准答案，但有一个明确的方向：让人类的判断力聚焦在真正需要的地方，让机器接管一切它能胜任的重复性工作。
一个一个来，不着急，但不能停。