一句话总览
Fiona 的核心判断是：工程管理的旧制度默认“人类写代码很慢且昂贵”，所以我们发明了大量前置计划、所有权边界、评审流程、团队分层和状态同步。现在 Claude Code 这类工具把实现成本大幅压低，旧制度没有立刻崩溃，但会“安静地失效”。新的管理任务，是把瓶颈从写代码处迁移后暴露出来的验证、评审、协调、质量、产品判断和安全边界重新设计清楚。
1. 瓶颈已经移动
她反复强调一句话：过去有效的东西，不一定继续有效。软件行业以前也经历过类似迁移。Visual Studio 2005 时代，软件要进制造实验室、压 CD、装盒、进商店，发布日期和流程围绕物理分发设计。后来在线分发改变了发布节奏。现在 AI 代码工具带来的变化类似，但它冲击的是工程组织内部的默认假设。
过去，写代码、写测试、做重构是昂贵动作。团队因此花很多时间做前置规划，避免走错方向。Fiona 说，在 Claude Code 团队，编码已经很少是最慢的部分。更大的变化不是“大家写得快一点”，而是产出量整体变大。产出一旦变大，旧瓶颈就被挤到下游。
“the bottlenecks have moved”这是整场分享的主轴：瓶颈从写代码移动到代码周边。
新瓶颈主要包括四类：验证、代码评审、跨职能协作、安全与信任边界。以前这些事情也重要，但它们不是主瓶颈。现在代码生成速度上来后，问题变成：这段代码对不对？谁该审？怎么维护？谁理解上下文？CI、构建、产品基础设施能不能跟上更高的变更频率？
她用了一个很准确的管理观察：流程很少会自己死掉。组织通常是不断叠流程。一个 SLA 不够，再加一个；优先级冲突了，再加排序；会议没用了，也不会自动消失。AI 带来的危险不是流程立刻报错，而是它们继续消耗团队注意力，却不再解决真实瓶颈。
2. 计划方式：从长路线图到 JIT Planning
Fiona 刚加入时也问过：是否需要六个月路线图？团队确实写了，但三个月后许多条件已经变化。她由此得到的结论不是“不要规划”，而是只在合适时间做合适粒度的规划。她把这称为类似 JIT 编译的计划方式。
这对管理者很关键。AI 时代的规划不是把未来六个月拆成确定工单，而是保持方向、约束和判断标准清楚，同时把不确定部分尽早变成原型。因为原型成本下降，团队可以用真实 artifact 学习，而不是靠抽象争论消耗时间。
技术争论的新规则
她讲了自己与 Boris Cherny 关于一次重构的分歧。按旧习惯，她差点想拉人进会议室画白板。后来她意识到，可以让 Claude 生成三种 PR。这样争论对象就不只是 API 实现本身，还包括对调用方的影响、迁移成本和实际代码形态。
“code wins”不是说谁先提交谁赢，而是让可运行代码成为讨论载体。
这里有一个容易误读的点：当构建变便宜，最后提交 PR 的人不能自动获得话语权。Fiona 特意提醒，团队文化和对齐机制反而更重要。否则 AI 会放大“抢先落地”的坏习惯。正确做法是用原型提升讨论质量，而不是用原型绕过共识。
减少什么，增加什么
| 过去的默认动作 | Claude Code 团队的变化 | 背后的管理含义 |
|---|---|---|
| 每次编码前写设计文档 | 许多讨论改为围绕 PR 或原型展开 | 当实现便宜，文档应服务于异步对齐和复杂决策，而不是作为仪式 |
| 大量产品评审 | 更快内部试用，更快听真实用户反馈 | 不确定性高时，反馈回路比评审层级更重要 |
| 把重构排进稀缺工程时间 | 重构、测试生成、变体探索成本下降 | 管理者要重新计算技术债处理的经济账 |
| 人工在末端发现问题 | 更重视 shift-left 验证和自动化 | 产出量变大后，质量系统必须前移 |
3. 代码评审：AI 处理常规项，人类守住判断项
代码评审是她说最常被工程领导问到的问题：AI 辅助后 PR 变多，人类如何跟上？Claude Code 团队大量使用 Claude 做代码评审，让它处理风格、lint、PR 反馈、潜在 bug、补测试、照看 PR 迭代等工作。
但 Fiona 没有把答案推向“全自动评审”。她的原则是 trust but verify。AI 可以承担重复性和机械性检查，人类仍然要在高风险和高判断密度区域出现。
| 更适合 AI 先处理 | 仍需人类明确介入 | 原因 |
|---|---|---|
| 格式、lint、样式、常规 review comments | 法律审查 | 涉及组织风险和责任边界 |
| 生成或补齐测试 | 安全敏感代码、信任边界 | 错误成本高，专家判断不可省 |
| 初步 bug 检测和局部修复 | 产品 taste、用户体验、风险容忍度 | 模型能给答案，但未必知道什么是“好” |
| PR 状态跟进和反馈整理 | 架构取舍和长期维护性 | 需要理解未来演进和团队能力 |
她举的“小雪人 Claude”例子很有用：让 Claude 在终端里做节日主题 ASCII art，结果不够好。设计伙伴指出它像 Mr. Peanut，于是她改成更简单的冰蓝色和雪花。这说明产品感不是语法正确性，AI 可以生成，设计判断仍然稀缺。
我的整理：AI 代码评审的第一阶段是“帮人类省眼力”，第二阶段才是“改变评审制度”。如果团队只把 Claude 当更便宜的 reviewer，但不重构风险分层、所有权、验证前移和质量指标，瓶颈只是换了位置。
4. 所有权问题：不要问谁写的，要问你真正想知道什么
AI 辅助后，“谁写了这段代码”变得不再是好问题。Claude Code 团队里所有 PR 都有 Claude 参与，因此简单追问作者容易把问题带偏。Fiona 建议 double click，也就是把表层问题展开成真实目的。
- 如果你想找回归原因，问题应是：谁最后触碰了相关区域？哪次变更最可能引入问题？
- 如果你想回答客户问题，问题应是：谁最懂这段行为？代码和历史上下文在哪里？
- 如果你想获得上下文，问题应是：能否让 Claude 从仓库、PR、反馈渠道和讨论记录里自动总结？
她提到自己以前每天早上用 Claude 总结客户反馈频道，后来这件事可以变成 routines。这个例子说明，所有权在变得模糊的同时，知识检索和上下文生成也变得可自动化。管理者要把“找人问”迁移为“让系统带出上下文，再找人判断”。
5. 团队画像：少看原始吞吐，多看产品感与系统深度
当模型提升个人产出，招聘画像也要变。Fiona 说她在 Claude Code 团队更看重两类工程师。
跨职能角色也在互相扩展。PM 可以写代码，设计师可以直接修改体验，工程师也能借助 Claude 做内容设计、文案压缩和产品表达。她提到自己要调整 survey response，但没有专门的 content designer，于是用 Claude 做内容设计搭档，把终端里的文案写得更短、更清晰。
这不是说专业岗位不需要了，而是说团队接口变少了。过去要排队找某个职能支持的工作，现在可以先由 AI 补位，再由专家在关键处校准。管理者要重新思考团队里的“等待队列”：哪些等待是必要的质量关卡，哪些只是旧分工带来的摩擦。
6. 组织形态：更扁平，管理者先做 IC，重度 dogfooding
这是她称为 spicy 的部分。传统招聘和组织设计常用类似 10 个 IC 配 1 个 manager 的比例，再往上嵌套管理层。Fiona 在 Claude Code 团队选择更扁平、更 scrappy 的结构，并要求 manager 先从 IC 做起。
她的理由很直接：如果你管理的是 Claude Code 这样的产品，管理者必须真正使用它，最好还能在代码里工作，获得团队信任，也理解产品现实。她说自己在 Meta 时每年还会努力提交一个 PR，但内部工具变化太快，重新熟悉成本很高。现在有 Claude 帮忙，管理者重新接近代码变得可行。
管理启示：AI 原生团队里的管理者不该只管理“人类生产代码”的排班表，而要管理“人类加代理系统”的产出系统。不了解工具、代码库和真实工作流，就很难设计有效流程。
她还强调统一使命的重要性。Claude Code 和 co-work 下可以有 pod，但整体保持一个 team mission。因为每个 pod 如果都有独立使命，方向变化时重新对齐会慢。AI 原生团队需要高机动性，过多组织边界会抵消工具带来的速度。
7. 知识源：代码成为 source of truth
在 Claude Code 团队，代码库是核心事实来源。Fiona 回答客户问题时，会让 Claude 结合本地仓库理解行为。这减少了文档滞后问题，因为外部文档常常跟不上代码变化。
但她没有主张丢弃所有 spec。更稳妥的做法是：如果团队有高质量 spec，把它们放进 repo，让 Claude 帮忙对照 spec 验证代码执行是否符合预期。也就是说，知识仍要结构化，但应尽量靠近代码、测试和实际行为。
8. 推行方式：强制原则与 pod 自主并存
她区分了两层管理动作：哪些必须统一，哪些让各 pod 自己适配。Claude Code 团队的强制原则包括：
- 每个 Claude Code 团队成员都使用 Claude Code，不只是工程师，跨职能伙伴也要使用。
- 尽可能 Claudify，也就是把重复工作、验证、triage、知识同步、反馈总结等任务交给 Claude 协助。
- 明确授权团队杀掉旧流程。流程不会自己消失，领导者要给团队许可去质疑和移除。
与此同时，各 pod 可以自行决定 triage 怎么做、on-call 怎么做、规划仪式怎么做、先自动化哪个 workflow。她不主张“总部规定所有人先自动化 X”，因为不同问题域的最佳切入点不同。
她举了 stand-up 的例子：团队大起来后，用 spreadsheet 写周进展。后来她意识到这可以变成一个 stand-up script，让 Claude 帮团队保持彼此知情。这类变化不是炫技，而是把状态同步从人工表格迁移到更低摩擦的自动化。
9. 怎么判断是否有效
Fiona 没有公开 Claude Code 团队的具体数字，但给了三个方向性指标。
| 指标 | 期望方向 | 应该怎么读 |
|---|---|---|
| Onboarding ramp-up time | 下降 | 新人、设计、PM 多快能对团队产生有效贡献 |
| PR cycle time | 下降 | 如果没下降，可能不是 AI 采用不够，而是 CI、构建、评审、产品基础设施跟不上 |
| Claude-assisted commits | 上升 | Claude Code 团队默认所有 commit 都由 Claude 辅助，近几个月几乎没见过非 Claude 辅助 commit |
她也提醒不要只看“多少代码由 AI 生成”。更重要的是最终产品是否更好，用户问题是否被解决，质量和可靠性是否稳定。否则吞吐提升只是制造更多需要维护、评审和验证的东西。
我的整理：AI 工程管理的指标应从 output 转向 system health。提交数、生成代码比例、PR 数可以作为早期信号，但不能替代质量、可靠性、用户价值和团队认知负担。
10. 她仍在思考的问题
这场分享最值得尊重的地方，是 Fiona 没把 Anthropic 的做法包装成终局答案。她明确说自己仍在问几个问题。
- 当工程师可以更有效跨 iOS 和 Android 工作，传统移动团队按平台拆分是否仍然合理？
- 自动化评审应该推进到什么程度？什么时候会从“足够快”滑向“丢了重要东西”？
- 模型能力持续变化时，哪些今天必须人工 verify 的部分，下一代模型后可以重新评估？
- 角色边界模糊后，怎样让工程、PM、设计都感到同样有效，而不是某些角色被边缘化？
她留给听众的行动建议很朴素：找出团队里最 noisy 的 workflow。它可能是最贵的、最让人抗拒的、最耗时间的，或者大家只是习惯性参加的会议。然后问：它还服务原来的目的吗？能不能自动化？能不能取消？
她举过一个 50 人周会的例子。每个人都低头用电脑，轮到自己才抬头报状态。她只问了一句为什么还开，大家发现确实没必要，于是取消。AI 时代的流程重写，很多时候就是从这种问题开始。
给工程管理者的落地清单
- 列出团队当前交付链路，从需求、设计、实现、评审、验证、发布、反馈到维护，标出真实瓶颈。
- 把所有评审项分成三类：AI 可自动处理、人类抽样验证、必须专家介入。
- 把技术争论从抽象方案转成小 PR、spike 或可运行 demo，但同时保留团队对齐机制。
- 检查计划周期。六个月路线图如果三个月就失效，改成方向清楚、短周期原型验证。
- 重写招聘画像，降低对原始编码速度的权重，提高产品感、系统深度、验证意识和学习能力权重。
- 要求管理者亲自 dogfood 工具，至少能跑通真实工作流，而不只是看报表。
- 把高质量 spec、runbook、设计约束靠近 repo，让代码、测试、规格共同构成可被 AI 使用的事实层。
- 给团队明确许可，每个月杀掉或自动化一个低价值流程。
- 指标上同时看速度和健康度：ramp time、PR cycle time、CI 等待、回归率、用户反馈、可靠性。
来源与阅读说明
这份笔记主要基于视频完整转录稿反复阅读后整理，辅以官方议程页和参会者笔记交叉校验。8news 页面提供了可读的完整 transcript，我没有逐字搬运，而是按管理主题做了中文重组和解释。