Fiona Fung 在 Anthropic 的 Code with Claude 大会上讲了 28 分钟。她说 Claude Code 团队现在"四个月没见过非 AI 辅助的提交"，PR 的默认讨论方式是"让 Claude 同时搓出三个版本直接对比"， manager 必须先做 IC——"不接受就趁早好聚好散"。 这些细节被广泛传播。但大多数讨论停在了表面：AI 提速了，流程要改，角色要变。本文要做的事情不一样——从这些现象出发，往下挖一层，看组织在编码去瓶颈化之后真正的变形力学是什么，以及这种变形为什么比看起来深得多。
瓶颈迁移不是"换个地方堵"，而是系统性质变了
一个常见的直觉是：编码加速了，瓶颈从编码移到了评审，就像高速路上一个路段扩容，车流在下一路段排起队。这是对的，但只对了一半。 瓶颈迁移真正的后果不是"堵点转移"，而是系统的主导逻辑变了。当编码是瓶颈时，整个组织的运转逻辑是节约编码资源——排期、评审、分工、文档，全是为了确保每一行代码都花在刀刃上。当评审变成瓶颈时，组织的运转逻辑变成了节约判断力——而判断力的分配和编码资源的分配，遵循完全不同的规则。 编码资源是可量化的（相对来说）。你可以用人月衡量投入，用代码行数衡量产出，用 bug 率衡量质量。判断力不是。判断力依赖上下文、经验、品味、对业务意图的理解。Fiona 讲的那个例子把这一点说得很透：她用 AI 画了个 ASCII 雪人，设计师看了一眼说"你画成了 Mr. Peanut"。这种判断从哪来？不是来自规范，不是来自流程，而是来自一种对成品形态的敏感——Fiona 自己承认"这种抽象判断很难自动化"。 这意味着什么？ 当瓶颈从编码移到评审，组织从管理可量化的资源，变成了管理不可量化的判断力。这不是同一件事的升级版，这是一件性质不同的事。你用管理编码的方式管理判断力，会系统性地失效。 CREAO 的案例从另一面印证了这个转变：CTO 引入 AI 后，人员管理时间从 60% 降到 10% 以下——不是管理变少了，而是管理从"对齐人"变成了"设计系统"。管理层的核心工作不再是分配编码资源，而是设计让判断力高效流转的架构。Fiona 坚持" manager 必须做 IC"、坚持扁平结构、坚持共享一个 mission——这些看起来是管理偏好，实际上是在回答一个问题：在一个判断力而非编码能力是稀缺资源的组织里，什么样的结构能让判断力最快地流动到需要它的地方？
流程不会自己死掉——但真正的原因不是惯性
Fiona 引起了很多共鸣的那句话："流程极少会自然消亡。我们习惯的做法是不断地往上叠加新流程。"她举了 SLA 排序表的例子——工程师需要一个大表格才能搞清楚哪条 SLA 该优先响应。 大多数人对这句话的理解是：组织有惯性，旧流程赖着不走，需要人为砍掉。这是对的，但不够深。 流程叠加的真正驱动力不是惯性，而是规避风险的组织本能。 每一层流程被加上去的时候，都是为了堵住一个已经出现过的问题——SLA 太多搞不清优先级，所以加了排序表；代码出了事故，所以加了评审会；新人上手太慢，所以加了 onboarding 流程。每个流程都有其诞生的合理原因。问题在于，诞生的原因消失了，流程不会消失。因为流程是一种可见的风险控制信号——砍掉它意味着有人在承担"万一又出事"的责任。没有人愿意承担这个责任，所以流程只增不减。 这解释了为什么 Fiona 说的"第一步是明确允许减少旧流程"是整个转型里最难的一步。难的不是减少流程，难的是把风险从隐性变为显性。减少一个流程意味着团队承认：之前这个流程存在防御的风险，我们现在用别的方式处理——或者我们选择不再防御它。"明确允许"这四个字，做的是重新分配风险责任：从"流程兜底"变成"人（或机制）兜底"。 这也解释了为什么个人采用 AI 工具和组织的 AI 转型是完全不同的事。个人采用 AI 是能力增强，不需要砍流程——原来的评审还在，原来的排期还在，只是你干活快了一点。组织转型必须砍流程，因为流程保护的是旧约束条件下的风险分配，约束条件变了（编码变便宜了），但风险没有消失，只是转移了形态。如果不重新分配风险，旧流程和新的工作方式会持续冲突：你在用 AI 的速度产出代码，但代码还要走为手工编码时代设计的评审流程——这不是提速，这是内耗。 Fiona 去掉的那个 50 人的周例会是典型案例：每个人都在低头敲键盘，因为信息已经在别处存在了，但会议作为"风险可见性"的仪式还在。干掉它的条件不是"AI 能生成状态摘要"（这是能力），而是"我们承认状态同步不再是这个会议的真实目的，而且我们愿意承担不再有这个仪式的风险"（这是风险再分配）。
代码便宜了，共识反而更贵了
"当写代码变得轻而易举，无休止的争论就显得极其昂贵。" 这句话被广泛引用，但通常只理解为"多做少说"。真正值得细想的是它暗示的悖论：代码越便宜，共识的代价反而越高。 "多做少说"成立的前提是：做了之后，事实会说话。Fiona 让 Claude 同时搓出三个版本的 PR 进行对比——代码就是事实，白板上的架构图不是。但当任何人都可以用接近零的成本生成一个实现的时候，实现本身的说服力反而下降了。三个 PR 能帮你对比方案，但如果有人用 cron job 半夜三点提交了自己的方案呢？Fiona 专门警告了这种行为。 这不是想象中的极端情况。这是成本结构变了之后的新均衡：当单方面改代码的成本趋近于零，代码本身就不再是共识载体，它变成了意志的博弈场。 在编码昂贵的时代，谁能写出代码，谁就事实上定义了方向——因为重写的成本太高。编码便宜之后，任何人都可以覆盖任何人的设计决策，只需要一个 commit。 这就是为什么 Fiona 说"团队底线共识和文化护栏"变得关键。这不是在说"团队文化很重要"这种空话——这是在描述一个硬性的组织设计约束：在低成本生产环境中，协调成本不会自动降低，反而需要显性的机制来维持。 以前隐性协调靠的是编码成本（改不动所以得商量），现在必须在文化和流程层面显性化（谁有权决定什么、什么行为不可接受），否则协调成本会以冲突的形式爆发出来。 扁平结构和共享 mission 不是"更先进"的组织形态——它们是在高产出、低成本环境中降低对齐损耗的工程选择。每多一层管理层级，就多一层对齐成本。当方向可能每周都在变（因为原型成本趋零，JIT 规划取代了六个月路线图），多层对齐的延迟是致命的。
角色模糊不是混乱，是一种新的分配机制
Claude Code 团队的 PM 在提交 PR。设计师在写代码。Fiona 自己在用 AI 写文案。她说"这段代码谁写的"这个问题正在失去意义。 角色模糊通常被谈论为一种"打破边界"的好事，或者一种"职责不清"的坏事。但两种说法都没说到点子上。角色模糊的本质是：当执行成本趋近于零时，分工的基础消失了。 传统分工的逻辑是：不同技能有不同的获取成本，所以专业化是高效的。你不会让设计师写代码，因为她写代码的成本比工程师高得多。但当 AI 把跨领域的执行成本拉平了——设计师用 AI 提交 PR，工程师用 AI 写文案——专业化的效率优势消失了。 那分工还有意义吗？Fiona 坦诚她还没想明白：当工程师做内容、PM 写代码、设计师修 bug，怎样让所有人感觉同样有产出感？这不是一个测量问题。如果你用代码提交量衡量产出，PM 现在也在提交代码，工程师的贡献就被稀释了。如果你用传统角色定义晋升标准，当角色边界消失了，标准也就失灵了。 Fiona 提出的问题指向一个更深的结构性变化：从"根据技能分工"走向"根据判断力分工"。 如果执行不再是瓶颈，那谁来做什么样的判断——这才是新的分工基础。合规审核必须人做，因为风险口径需要人类判断。安全敏感代码的边界必须人确认，因为出漏洞的代价远超自动化审核的收益。产品的 sense 和品味必须人判断，因为"这是不是 Mr. Peanut"不是一个可规范化的命题。 招聘标准的变化印证了这个方向。Fiona 不再看重原始编码吞吐量——模型把这部分拉平了。她看两类人：有产品感觉的创意建造者，和深度系统专家。前者是判断力，后者是对复杂系统的理解力。两者都不是"编码速度"。
为什么" manager 必须做 IC"不是一个管理偏好
Fiona 在招聘时死咬一条：所有 manager 必须先做 IC。招聘官觉得她疯了。她的回应："不接受就趁早好聚好散。" 这看起来是一种管理风格偏好——亲力亲为型 vs 授权型。但它实际上是一个认识论问题：在 AI 辅助编码的环境里，不做 IC 的 manager 能否做出有效判断？ Bainbridge 1983 年提出的自动化悖论说的是：自动化取代了人类技能，然后在边缘情况下又需要人类介入，但那时人类已经失去了技能。Fiona 的要求是这个悖论的管理层版本：当大部分 commit 都是 AI 辅助的时候，一个没有亲手用过工具的 manager ，分不出 AI 输出的好坏，看不出 Agent 跑偏了，无法提供有意义的评审。 这不是一个"身先士卒"的文化态度问题，而是一个信息问题。 manager 在做判断时需要信息：这个方案可行吗？这个 AI 输出靠谱吗？这个重构方向对吗？不做 IC 的 manager 获取这些信息的唯一渠道是别人的汇报。但在一个高吞吐量、AI 辅助的环境里，代码的变化速度太快，汇报永远滞后于实际。唯一不滞后的信息获取方式是自己动手。 Fiona 自己上次 push 代码到生产环境是 2017 年，加入 Anthropic 后重新写起——"我连 git 命令都不记得了，全靠 Claude 帮我搞定"。重要的是她在写代码，不是她写得多好。她在维持一种基于一手体验的判断力，而不是基于二手汇报的判断力。在 AI 时代，这两种判断力的差距不是量的差异，是质的差异。
"代码占比"是个虚荣指标，但真正危险的不是测量错误
Fiona 警告不要盯着"有多少代码是 AI 写的"这个比例。新闻稿里这个数字越说越高，但吞吐量不是目的，产品质量和可靠性才是。 这个警告通常被理解为：别测量错的东西。但这只是表层。真正危险的不是测量错误，而是测量会重塑行为。 你追踪和奖励什么，团队就优化什么。如果你把 AI 代码占比作为方向标，团队会优化 AI 使用率——不管结果是否真的更好。这在组织层面和 Agent 层面是同一个模式。 Fiona 点出的三个观察方向——新人爬坡时间、PR 生命周期、AI 辅助提交覆盖率——暗含了一个判断：有效的指标衡量的是系统的转换能力，而不是输入量。 新人爬坡时间衡量的是组织将新人转化为有效贡献者的能力。PR 生命周期衡量的是系统将意图转化为交付的能力。这两个指标关注的是 throughput，不是 input。"AI 代码占比"关注的是 input。 PR 生命周期这个指标尤其值得细想。Fiona 提到它的变化不仅反映 AI 工具的接受度，还可能暴露下游基建的问题——CI pipeline 根本吃不消暴增的提交速率。这再次说明瓶颈迁移的系统性：你加速了一个环节，下游的每一个环节都可能暴露为新的约束。测量 PR 生命周期，实际上是在测量"系统消化变化的能力"，而不是"系统产出代码的能力"。
还没想明白的问题，才是最重要的
Fiona 在演讲最后承认三个问题没有答案：
- 平台团队边界要不要消融——当工程师能跨平台工作，"iOS 团队 + Android 团队"还有意义吗？
- 自动化评审推到多远——"信任但验证"的边界在哪？
- 角色模糊后的公平感——当产出归属模糊了，怎样让每个人觉得自己有贡献？
这三个问题有一个共同结构：它们都发生在旧分类法失效、新分类法未建立的过渡区。 "iOS 团队"是按技能分类，"评审边界"是按信任度分类，"公平感"是按贡献分类。当执行成本趋近于零，这三种分类同时失效了。 这些问题没有答案不是因为 Fiona 不够聪明。它们没有答案是因为答案取决于组织做出的选择，而不取决于技术的进步。 模型能力再升级，也不会自动解决"PM 写了代码之后晋升怎么算"这个问题。这是一个组织设计问题——你需要主动设计一个新的分类法，新的贡献衡量体系，新的公平感机制。 这才是"当编码不再是瓶颈"这件事真正深刻的地方：技术消除了旧的约束，但不会自动产生新的秩序。 新秩序需要组织自己创造。创造的过程比技术变革本身更难，因为它需要重新谈判权力、责任和认同的分配——这些是技术无法替你解决的问题。 Fiona 最后的建议看似平凡："挑出最折腾人的那条工作流，重新审视它到底还在为谁干活。"但这个建议的真正力量在于它暗示的方法论：不要试图一次性重新设计整个组织。找到一个已经明显失灵的节点，问它现在服务于什么目的。如果答案是"服务于一个不再存在的约束"，就砍掉它。用一个一个的局部减压，让整个系统慢慢找到新的均衡。 这不是革命。这是进化。但在一个约束条件正在剧烈变化的环境里，进化的压力是真实的——不愿进化的组织，不是变慢，而是会越来越不适应，直到旧结构和新现实之间的张力大到撑破。
本文受 Fiona Fung 在 Anthropic Code with Claude 2026 上的演讲启发，但她演讲的具体内容只是起点。文中关于组织变形力学、风险再分配、判断力分工、认识论问题等分析，结合了更广泛的 AI-first 组织转型观察。Fiona 的价值不在于给出了答案，而在于她是更早遇到这些问题的人之一——而她的"还没想明白"可能比她的"我们已经做到"更值得关注。