瓶颈没有消失，只是转移了
Fiona 整场分享里最重要的一个词是「转移」。
工程师的时间贵，所以你得花大量时间做规划、写需求文档、做评审、开会，所有这些规范和方法论，本质上都是在管理「写代码」这个最贵的资源。在互联网行业待过的人对此都不陌生。
但在 Agent 时代，这个前提变了。在 Claude Code 团队，写代码已经很少是拖慢速度的那个环节。一旦写代码不再是瓶颈，围绕它的所有流程就都得重想。
瓶颈并没有消失，它转移了——从「写代码和发布代码的产能」（旧瓶颈），转移到了「验证、代码评审、跨职能协作、安全」（新瓶颈）。代码生成太快，新问题变成了：这些代码对不对、怎么维护、人到底怎么跟得上 review 的节奏。
这就像从马车到汽车，不只是把马换成发动机那么简单，整个公路系统、交通规则、城市规划全都得重新设计。Fiona 列出了五个正在悄悄失效的旧领域，以及对应重建的新规范：
- 规划方式——工程速度和产出量完全不同了，要让人类判断力聚焦在真正需要的地方
- 代码所有权——「谁写的这段代码」变成了一个很奇怪的问题
- 代码评审——新规模、新形态、新工具，新人入职成本大降，一周就能开始产出代码
- 团队构成——角色在模糊化，招聘更看重创造力和判断力，而非纯产出速度
- 知识共享——文档不再是唯一的真相来源，组织更扁平，管理者也先从一线干活做起
规划：JIT，恰好足够的规划
以前 coding 时间贵，所以要提前大量规划。Fiona 刚加入团队时，他们写了一份漂亮的六个月路线图，结果因为 Claude Code 自身迭代太快，大约三个月就过时了。
现在他们的做法叫 JIT 规划（Just-In-Time），像 JIT 编译一样，在对的时间做恰好足够的规划。不再写长篇设计文档，直接在 PR 或原型里讨论；不再做冗长的产品评审，先做原型，让内部用户去用，再根据反馈快速迭代。
他们砍掉的，是「写代码之前必须先写设计文档」这个仪式。Fiona 说对大部分工作来说这就是 theater（做戏）。现在换成原型先行，文档如果确实需要，等代码写完、感觉可以了再补。加码的则是验证——在 AI 原生工作流里，东西出 bug 的方式跟以前不一样，唯一能保证质量的方式就是不断把验证流程往前推。
她还有一个观点特别好：在技术讨论中，代码赢才牛逼。 两个人对方案有分歧，最快的解决方式不是继续吵，而是让 Claude 把两个方案都做成原型，看实物判断。
Building is cheap, arguing is expensive.（做东西很便宜，争吵才昂贵。）
当年争方案要各写一份 PPT、开两轮会，现在十分钟两个原型都出来了，看实物比对着 PPT 吵高效一万倍。坦率说，在 AI 时代，过度规划就是浪费。
自动化：把它变成肌肉记忆
Fiona 反复提到团队的一个习惯：每遇到一个问题，都会追问一句——能不能把这件事自动化。
她举了自己的例子。她以前每天早上端着咖啡，手动去总结各个客户反馈渠道的内容，这是固定工作。后来她把这件事变成了一个后台自动运行的任务，咖啡还是那杯咖啡，但她不再需要边喝边刷了。
例子很小，重点不在这一件事，而在这个习惯。团队里每个人遇到重复性工作，都会条件反射地问「能不能自动化」，她说这已经快形成肌肉记忆了。
要真正把它变成团队的肌肉记忆，比说出来难太多。因为大多数人对自动化的理解还停留在「写个脚本、搞个定时任务」的层面，但 AI 时代的自动化跟以前完全不是一个量级。现在用 Claude Code，很多自动化十分钟就搞定，甚至不用十分钟。比如想同步家里和公司的电脑，只要跟 Claude 说一句「帮我写一个 hook，每次打开我的某个项目之前都去 github 拉取最新代码」，几分钟就能跑起来。
逻辑因此反过来了：以前自动化成本高，只有高频、高重复、高价值的事才值得做；现在成本几乎为零，几乎所有重复超过三次的事都应该自动化。除了工作流，触发器 hook 也是个非常好用的东西。
所以如果你还在犹豫，建议是别想太大。别一上来就想搭一套完整的自动化体系，那太吓人也没必要。就从今天找一件你重复做了的事，花十分钟让 Claude Code 或 Codex 帮你自动化掉；明天再找一件，后天再找一件。一个月后回头看，工作方式已经完全不同——一个个小自动化攒起来，会在你没反应过来的时候长成一棵参天大树。
代码评审：Trust but verify
过去六个月跟其他工程 leader 聊天，Fiona 被问得最多的问题是：你们人怎么跟得上代码 review 的速度。
她的做法叫 Trust but verify（信任但验证）。团队大量使用 Code Review 功能：Claude 负责所有风格检查、linting、PR 反馈、bug 捕捉和修复、补充测试——这些以前可能占了 review 工作量 60–70% 的部分，现在 Claude 全接了。
但人类 review 在真正需要专业判断的地方仍不可替代：
- 法律合规——永远需要法务伙伴参与风险评估
- 信任边界和安全敏感代码——需要领域专家
- 产品方向和品味——需要 PM 和设计师
她特别强调，trust 和 verify 之间的平衡是动态的。今天需要人做的事，下一个模型可能就能做了，所以你必须不断重新评估这条线。这就像打游戏，每个版本的版本答案都不一样，拿上个版本的攻略打新版本只会被干掉。
团队角色：Taste is scarce, typing is not
在 Claude Code 团队，角色界限已经很模糊。PM 在大量写代码，工程师也在做内容和设计，泾渭分明的边界正在消融。
举个例子：以前工程师修完一个 bug，要等内容设计师排期来写用户端文案，结果要么等好几天，要么赶进度发个凑合的文案。现在的流程是工程师修完 bug，Claude 起草文案初稿，人类做最终判断，当天就能发。跨职能的 gap 不再是瓶颈，而成了协作——人类还是做最终决策的那个人，只是不再是写初稿的那个人。
Fiona 说她现在招人主要看两种特质：
- 有产品 sense 的创意 builder：能识别出该做什么，能快速做出原型。她特意强调一句——Taste is scarce, typing is not.（品味是稀缺的，打字不是。）
- 有深厚系统背景的工程师：负责「trust but verify」里最需要人的部分，因为 subtly wrong is still wrong（微妙的错误仍然是错误）。
她说：我根本不在乎你一小时能写多少行代码，我在乎的是你选择去做什么，以及你怎么知道它是对的。当 AI 把执行速度提升十倍，决定性因素就变成了你知不知道该做什么、什么样的结果叫真正优秀。这，就是品味。
推动变化：人不会主动删流程
团队的核心原则被分成两类：一类是必须做的硬性要求，一类是大家自己摸索的空间。本质上是给团队设计了一个 harness——大方向统一，具体怎么落地各团队自己定。
Fiona 总结了她最看重的三条：
- 保持团队尽可能扁平，管理者支持各小组，但保持灵活，让人能流动到工作需要的地方。
- 如果 Claude 能做，就让 Claude 做，这样人能腾出手做更难的工作。
- 人不会主动删除流程，只会在旧流程上叠新流程，所以你得主动站出来，指名道姓地说出哪些流程可以走了。
最难的是第三条。她讲过一个团队的每周 review 会议：一屋子人坐着，所有人都在看电脑，只有轮到自己时才抬头说两句 status，说完又低头。直到她问了一句「我们为什么还在开这个会」，所有人才意识到这个会根本不需要——于是从此取消了。
这种事太常见了。无数流程和会议当初设立都有道理，但环境变了、工具变了，它们早就失去了意义，只是因为惯性还在那里被迫转着。没人觉得它有用，但也没人站出来说一句「这破会太浪费时间了，能不能别开了」。AI 在组织里介入得越深，你会发现很多步骤其实早就能自动化了；如果不主动审视，它们就会一直留着，最后变成纯粹的形式主义。
三个没有答案的问题
Fiona 最后抛出了三个她自己也在思考、但没有答案的问题：
- 你还需要单独的 iOS 和 Android 团队吗？因为工程师已经可以更灵活地跨平台工作。
- 全自动化的 review 到底能推到多远？在「够快了」和「我们漏掉了什么重要东西」之间，那条线在哪里？
- 当角色越来越模糊，怎么确保每个角色都对自己的产出有信心？
她愿意把这三个问题放出来，这个动作本身就很有价值。因为你会发现，即便是 Claude Code 的亲爹团队，也没把所有事想明白。他们也在摸索——很多时候，这本来就不是一个有标准答案的问题。
所谓 AI Native，并不是买几个 Claude 会员、包个 API Key 给大家用就算转型了。真正的 AI 原生组织，从规划方式到知识管理、到评审流程、到人才结构，每一层都是重新设计过的。
而贯穿所有这些变化的，其实就是那个最朴素的思维习惯：遇到重复的事，自动化掉；遇到没用的流程，干掉；遇到不需要人做的判断，交给 AI。一个一个来，不着急，但不能停。
用 Fiona 的最后一句话收尾：找到你最繁琐的那个工作流，问问它——是不是还配占着这个位置。