AI 时代到底该怎么管一个工程团队

中文精读

原文约 4,842 词 · 14 节

1. 开场：一场已经过时的演讲

   • Fiona Fung 在 Anthropic 大会上讲了 28 分钟，主题是 AI 时代怎么管一个工程团队。
   • 她做幻灯片时 Anthropic 还没推出 Routines（让 Claude Code 在云端按计划自动跑任务的功能），三周后该功能上线，等她真正站上 Code with Claude 2026 讲台时，好几张幻灯片已经过时。
   • 她是 Anthropic 旗下 Claude Code 和 Cowork 两条产品线的工程与产品负责人，此前在微软干了十二年（从 Visual Studio 做起），后来在 Meta 带过 Facebook Marketplace 和 Instagram 的工程团队，2025 年 9 月加入 Anthropic。
   • 演讲讲的是这一年在 Claude Code 团队踩过的坑、砸碎的旧规则和还没想明白的挑战，没有抽象空话。

2. 要点速览

   • 瓶颈从“写代码慢”转移到验证、评审、跨职能协作和安全性；旧流程都建立在“写代码很贵”的假设上，现在必须重构。
   • 流程极少自然消亡，组织只会层层叠加 SLA、规章制度和评审，所以第一步是明确允许砍掉陈旧流程。
   • 技术辩论从白板房画架构图，变成让 Claude 同时搓出三个 PR、连同 API 影响范围一起对着代码讨论。
   • 团队所有 PR 都有 Claude 参与，“这段代码是谁写的”已渐渐失去意义。
   • 经理必须从一线 IC（个人贡献者）做起，Fiona 招人时死咬这一条，不能接受的就早点分开。
   • 组织尽量扁平、所有小组共享一个团队目标（mission）：目标一变，层级越多对齐损耗越大，扁平意味着灵活。

3. 要点速览（续）

   • 代码是唯一的事实来源（source of truth）而非设计文档；非要保留 spec 就提交进代码库，让 Claude 校验代码与文档是否一致。
   • 衡量看三个指标：新人上手时间、PR 的生命周期、Claude 辅助提交的比例；但别死盯“多少代码是 AI 写的”，那只是虚荣指标，关键看产品质量和可靠性。

4. 二十年里，行业被重塑了两次

   • 2000 年代初她在微软做 Visual Studio 2005，软件靠 CD 发行（更早是软盘），每个版本都有雷打不动的发布主线。
   • 互联网把发行方式从 CD 变成在线分发，工程节奏被颠覆；这次 AI 变的不只是发行节奏，而是“写代码”本身。
   • 她反复强调：“过去管用的老经验，现在未必行得通了”（What served you prior may not serve you any longer）。
   • 多年来工程节奏围绕“写代码贵、写测试贵、重构贵”的假设搭建，从瀑布到敏捷都是在分配这块稀缺资源。
   • 一年前她还在抱怨 vibe coding（凭感觉编程，由 Andrej Karpathy 在 2025 年初提出）到处用常量、工程实践不好；一年后模型能力已远超单纯提速，吞吐量直接跃升一个数量级。

5. 当编码不再是瓶颈，新的卡点出现在哪里

   • Claude Code 团队现在的瓶颈是验证、评审、跨职能协作和安全。
   • 其他工程负责人最常问她“这些代码人怎么审得过来”，她也想知道维护成本怎么算：生成代码几乎免费，但维护成本不会跟着归零。
   • 她列出一份正在失效的旧流程清单：半年产品路线图、繁琐排期会议、代码所有权划分、马拉松式代码评审、按部就班的团队结构、知识库分享、漫长的新人培训（onboarding）——都是“开发成本太高”倒逼出的历史产物。
   • “流程极少会自然消亡，我们习惯的是不断往上叠加”（Rarely do processes kill themselves, we tend to just layer more and more and more processes on）。
   • 她举例：某团队 SLA 多到要拉大表格强制排序，工程师才弄清哪条优先响应；她早想清理，到 Anthropic 后才真正动手。

6. 少做什么：六个月路线图、设计文档、产品评审

   • 她刚加入时还问“不需要做六个月路线图吗”，写出来的版本前三个月能用，过完新年再看已变了大半。
   • 她现在用 jit planning（即时规划）这个说法，借 just-in-time 编译的概念：什么时候需要再做什么，因为原型成本趋零，“提前规划”的杠杆消失了。
   • 设计文档大量减少，默认讨论媒介从“先写一份 doc”换成“先发一个 PR”，有想法直接做出来。
   • 产品评审会也开得少，因为产品形态变化太快；与其评审 mock，不如把内部版本推给 Anthropic 全员（她叫 ant-fooding），再推给外部用户看他们怎么用。

7. 多做什么：验证，把质量保障往源头推

   • 她希望在验证上加倍投入，即 shift left（左移）：把质量保障从靠近交付端的人工测试，推向靠近源头的自动化。
   • 角色边界正在模糊，她的设计师同事现在也在提交代码。
   • 她讲了一个小焦虑：修完一个与求职简历相关的 bug 后，第二天看到有人在群里 @ Boris 报新 bug，“心跳都漏了半拍”，生怕是自己捅的娄子。
   • 每个人都不希望自己的提交把服务搞挂，这是高吞吐量环境下非常真实的心理负担。
   • 传统人工 QA 接不住这么高的代码产出率，所以质量保障必须更早依赖自动化机制。

8. 技术辩论的方式变了：从白板到三个 PR

   • 她刚加入时想做一次重构来熟悉代码库，与 Boris 在方案上有分歧，差点习惯性说“走，去白板房画一下”。
   • 她随即意识到可以让 Claude 同时搓出三个版本的 PR，直接对比完整实现，甚至拉出对所有调用方的影响——白板画不出这种全局视角，代码可以。
   • 她强调：“当写代码变得轻而易举，无休止的争论就显得极其昂贵”（When building is cheap, arguing is expensive）。
   • 正因生成成本趋零，团队文化和底线共识反而更关键，决不能沦为“谁最后一个 commit 谁赢”。
   • 她明确点名禁止：熬夜到凌晨三点偷偷交代码，或设定时任务抢在上线前压哨操作。

9. 代码评审：Claude 接什么，人保留什么

   • Cat Wu 在上午 keynote 已讲了 Claude 自动评审 PR 的能力，Fiona 的视角更具体：什么交给 Claude，什么留给人。
   • 交给 Claude 的：风格检查、lint 去重、回应评审意见、抓常规 bug、补全单元测试；Claude 很擅长“打理”PR，常在人工接手前把脏活干完。
   • 仍需人工的三类：法律和合规审核（涉及风险口径）；安全敏感代码的边界确认（漏洞代价太高）；产品体验的 sense（直觉）和品味，这是大模型当前难跨的门槛。
   • 她举例：圣诞节想把 Claude 终端形象改成雪人，让 Claude 画 ASCII 图，设计师同事看后说“你把它画成了 Mr. Peanut”（美国零食品牌 Planters 的吉祥物，轮廓与雪人有点像）。
   • 最终采用简单方案：冰蓝色加雪花。她用这个故事说明产品 sense 意味着抽象判断很难自动化。

10. 代码边界日渐模糊，角色分工也在重新洗牌

    • 团队几乎所有 PR 都有 Claude 参与，“这段代码到底是谁写的”正在变得荒诞。
    • 她建议不要纠结表象，而是问清真正想搞懂什么：是谁的修改引爆了 bug、谁有上下文去跟客户解释技术细节、谁最清楚这块模块的来龙去脉；细问下去往往有更好的自动化路径来回答。
    • 她原本每天早上泡咖啡时用 Claude Code 对接客户反馈频道跑信息汇总，现在这个动作已被编排进 Routines 自动化任务，省去手动敲命令。
    • 角色模糊是双向的：非技术人员也开始写代码（团队里的 PM 就在实打实提交 PR），工程师也去抢别的岗位的活。
    • 她自己想优化用户问卷调查却找不到内容设计师，就直接把 Claude 当文案搭档，自嘲作为典型工程师“把文案写得精炼可谓一塌糊涂”。
    • 招聘重点看两类人：有产品感觉的创意建造者（好奇心强、看到问题就想做产品、反复打磨体验），以及深度系统专家（搭 Claude Code Remote 时发现缺分布式系统经验的人）；她不再看重原始编码吞吐量，模型已把这部分拉平。

11. 组织形态：尽量扁平，经理从 IC 做起

    • Anthropic 招她时默认按“10 个 IC 配 1 个经理、再向下嵌套”的结构招人，她不要这种。
    • 她要尽量扁平：Claude Code 和 Cowork 两条线只共用一个团队 mission，不让各小组各自定 mission，因为 mission 一变、多层级向下对齐很费时间，扁平等于灵活。
    • 她坚持所有经理都要先做 IC（individual contributor，一线工程师），招聘官最初的反应是“你疯了”。
    • 她的原话大意是：每个经理都从 IC 起步是她的期望，不感兴趣就早点分开（better for us to do earlier separation）。
    • 这条也适用于她自己：上一次推代码到生产是 2017 年，加入 Anthropic 后才重新写代码；在 Meta 时每年试着提交一次 PR，但内部工具变得太快，一年学的命令第二年就过期。
    • 她现在连 git 命令都不记得，全靠 Claude 帮忙。

12. 从文档退位，让代码成为“唯一事实来源”

    • 团队把代码视作最终的 source of truth（唯一事实来源）。她回答技术客诉时直接启动桌面版 Claude Code，挂载本地 repo 让模型从代码找逻辑作答，解决了开发文档总与代码不同步的老问题。
    • 她特意说明这条经验并非放之四海皆准：如果业务要求完备的需求文档，就把 spec 一并提交进代码库，让 Claude 交叉校验代码与文档是否吻合。
    • 推行时她区分“必须统一”和“交给小组”：必须统一的是每人都用 Claude Code（含跨职能伙伴，Cowork 也算）、尽可能 claudify everything、明确允许杀掉不再服务于人的旧流程。
    • 例子：团队曾搞站会，变大后改成在共享表格填周进度；她觉得索然无味，因为信息都在 Claude 能读到的地方，让 Claude 写个总结脚本、任何人随时拉别人的状态摘要更划算。
    • 交给小组自定的：bug 的 triage（分诊）机制、排期节奏、谁值班怎么值、哪些工作流优先上 Claude。

13. 三个可观察的指标，和一个警告

    • 她没有透露具体数字，只点了三个方向。
    • 新人爬坡时间显著下降：工程师、设计师、PM 在新团队产生有效产出的速度明显更快。
    • PR 所需周期明显变短：这个指标值得深挖，既反映团队对 AI 工具的接受度，也会暴露下游基建的短板，比如 CI（持续集成）管线或产品基础设施环境吃不消暴增的提交速率。
    • Claude 介入提交的覆盖比例越来越高，带 Claude 的 commit 已是团队默认操作；她说差不多四个月没见过一次非 Claude 辅助的提交。
    • 她明确警告：不要只看“代码有多少由 AI 生成”，新闻稿里这个比例越说越高，但吞吐量本身不是目的，要回看究竟在解决什么问题、产品质量和可靠性是否守得住。

14. 她自己也没想清楚的三件事

    • 第一，工程师能跨平台流转之后，传统的“iOS 团队 + Android 团队”分队还有没有意义。
    • 第二，自动化评审要推到多远；“信任但验证”的边界在哪，会随模型升级再次移动，这不是一次定下来的决定（她提到当天稍早一场关于模型能力的演讲）。
    • 第三，角色模糊之后，怎样让所有人感觉同样有产出感：工程师能做内容、PM 能写代码、设计师能修 bug，产出归属变模糊，公平感的设计是新课题。
    • 她给的建议是：挑出极其折腾人、尤为啰嗦的那条工作流，重新审视它到底还在为谁干活。
    • 她拿自己当反例：带某个团队时有雷打不动的周会，五十多号人挤在大屋子里，除了被点名汇报的人假装抬头，其他人都在低头敲键盘；她只问了一句“我们到底图什么还在开这破会”，全票通过并当场解散。