AI原生团队实践：Anthropic工程师效率如何提升8倍

文章正文

在过去两年里，软件工程师这份工作发生了近乎彻底的重构。Anthropic 官方数据显示，其工程师人均季度代码交付量相比此前基线增长了8倍——图表几乎是从长期平稳后直接冲向月球。这一数字背后，是大型语言模型（LLM）在代码生成领域的质变：Claude Code等AI编程工具不再只是"智能输入法"式的单行补全，而是能理解整个代码仓库上下文、自动调试、跨文件重构，乃至独立承接完整任务——学术界将此称为从"工具"到"智能体（agent）"的范式跃迁。

这一跃迁的技术根基，在于近年来LLM的两项关键突破：其一是上下文窗口从数千token扩展到数十万token，使模型得以"看到"整个代码仓库而非单个文件片段；其二是工具调用（function calling/tool use）能力的成熟，让模型可以主动执行终端命令、读写文件、运行测试，形成"生成-执行-反馈-修正"的完整闭环，在技术架构上对应了ReAct（Reasoning + Acting）范式的工程落地。当"编程不再是瓶颈"成为现实，一个AI原生团队究竟该如何运转？

Anthropic 的 Fiona Fung 或许是回答这个问题的最佳人选。她同时负责 Claude Code 和 Cowork 两大产品团队，拥有超过25年工程经验：曾在微软主导 TypeScript 和 Visual Studio 团队（TypeScript 由 Anders Hejlsberg 团队于2012年推出，是 JavaScript 的强类型超集，其核心设计哲学是"通过静态类型系统在大规模代码库中维护工程质量"，这与她今日强调框架化验证的思路一脉相承），在 Facebook 从零打造如今年 GMV 超千亿美元的 Marketplace（其成功很大程度上依赖 Facebook 既有的社交图谱，买卖双方往往有共同好友，大幅降低了信任成本），还参与了 Meta 首款智能眼镜与 AR 眼镜 Orion 的研发（Orion 是 Meta 历时十年、耗资数十亿美元的增强现实项目，需要在极轻薄的镜片上实现光学波导显示，工程复杂度极高，这段经历让她深刻理解了"只有深度用户才能发现的感知级bug"）。在 Lenny's Podcast 的这期对谈中，她分享了大量一线管理与工程实践的洞察。

编程不再是瓶颈：AI工具彻底抬高能力天花板

Fiona 反复强调一个核心判断：AI 抬高了每个人能力的天花板。"理论上一切都变得可能，现在的问题变成了——你能有多大野心？"

她举了一个生动的例子：团队里一位并非移动端出身的工程师，因为业务需要为某功能补齐移动端，过去他会本能地拒绝"这太难了"，但现在他直接对 Claude 说"帮我在移动端也实现"，然后它就真的做到了。这种心态转变正在整个行业蔓延——过去"这个功能很复杂做不了"，如今"这完全可行，交给 Claude Code 就行"。

有意思的是，这种变化并非仅限于工程师。在 Claude Code 团队，设计师、PM 乃至所有人都在提交代码。"每个人都开始成为 builder。"当不同职能都能写代码、且吞吐量如此之高时，一个全新的核心命题浮现了：验证（verification）。代码量翻了8倍，如何保证质量依然过硬、真正能跑通？这成了 AI 原生团队最核心的挑战之一。

用 Claude 管理 Claude：AI原生团队的新工作流

Fiona 分享了一套她亲身实践的管理方法。她在所有代码仓库中都部署了一个 Claude Code 远程会话实例，这个实例可以访问全部代码、所有 Slack 频道以及团队追踪的各项指标。

每个月，她会和团队一起打开这个 Claude 会话，共同回顾：这个月的重点是什么？哪些产品上线了？表现如何？用户反馈渠道说了什么？"过去我只会用这些会话生成 PR 和修 bug，现在我用它来支撑与团队成员的深度对话。"

她的每日晨间工作流也被彻底自动化。过去她端着咖啡逐条翻看反馈频道、手动挑出可以改进的地方；现在通过 routines（例程） 功能，她设定每天定时运行的任务："帮我盯着这个反馈频道，总结主题，等我醒来时给我一份摘要，甚至直接生成一些我可以 review 的 PR。"

这里的关键是抽象层次在不断上移——从"我写 prompt 同步执行"，到"我异步 kick off 多个 agent"，再到"我写一个 routine，让 agent 帮我生成 prompt、自动派生多个 agent"。这正是 AI 应用架构的最新演进方向：单一 LLM 调用是第一代范式，引入工具调用的智能体是第二代，而多 Agent 协作系统（Multi-Agent System）是正在到来的第三代。

多智能体系统在工程实现上，通常包含一个"编排者"（orchestrator）和多个专门化的"执行者"（executor）：编排者负责任务分解与调度，执行者专注于特定子领域，如代码生成、测试编写、文档撰写。多个并行的LLM实例通过消息传递进行协调，核心工程挑战在于"上下文传递"与"结果一致性"——这也是当前AI系统设计中最活跃的探索方向之一。这种架构把人类工程师从任务执行者提升为任务架构师。Fiona 认为这正是工程演进的下一个前沿：异步化（async）与 agent 编队（fleets of agents）。

拥抱者与抗拒者：成长型思维是真正的分水岭

随着角色剧变，一个鸿沟正在形成：有人全力拥抱 AI、如鱼得水，有人则充满挫败、抗拒甚至恐惧。Fiona 观察到，做得最好的人有一个共同点——成长型思维（growth mindset）。

这一概念源自斯坦福大学心理学家 Carol Dweck 的研究。Dweck 在其著作《Mindset》中提出，固定型思维者认为能力是天生固定的，而成长型思维者相信能力可以通过努力发展。在 AI 重塑工作方式的背景下，这一框架尤为切题——那些认为"编程能力是我的核心身份"的工程师，往往更难接受 AI 介入；而那些认为"解决问题才是目标"的人，则更容易将 AI 视为杠杆而非威胁。

"过去让你成功的方式，未必能继续支撑你。"她坦言这很难，因为每个人都是靠某种既有方式获得成功的，被要求改变时会本能地感到恐惧。而挫败感往往正源于恐惧，以及"一切都不在我控制范围内"的无力感。

她的建议直接：主动出击（lean in），问自己"什么在我的掌控之中？我能做点什么？"她引用了经济学家 Tyler Cowen 的观点——表现最好的人都有极强的"initiative（主动性）"或"agency（能动性）"。Cowen 是乔治梅森大学经济学教授，他的研究发现，在 AI 时代表现最出色的人具备极强的能动性——即不等待指令、主动定义问题、自发寻找解决方案的能力。这与麻省理工经济学家 Daron Acemoglu 等人的研究呼应：AI 自动化冲击最小的岗位，往往是那些需要主动判断、灵活应对非结构化情境的工作。在 Claude Code 和 Cowork 团队，Fiona 将其提炼为一组辩证关系：高能动性伴随高问责（high agency, high accountability）。给予团队充分"施展拳脚"的自由，同时要求他们对每个尝试都有清晰的假设并为结果负责。

她还引用了一句话——"你所恐惧的洞穴，正藏着你所寻找的宝藏"，鼓励人们在职业生涯中"偶尔做一些让自己害怕的事"，因为那往往正是成长发生的地方。

质量守门：从人工审查到框架化验证

当代码交付量激增，传统的人工 code review 成了巨大瓶颈。Fiona 的解法是把"什么是好"这件事显式地写进仓库。

"Claude 在你给它一个框架去校验时表现极好。"她建议将规格说明（spec）、内容设计规范等以 skill 的形式 check 进仓库，并保持与代码同步更新。这样 Claude Code review 就能持续确保产出符合既定标准。她将此类比为测试驱动开发（TDD）的进化——TDD 由极限编程先驱 Kent Beck 在2000年代初系统化提出，核心流程是"先写测试、再写实现、再重构"。

TDD 的历史推广充满挫折，核心阻力始终是"写测试的时间成本"——业界调查显示，即便在推崇工程质量的硅谷团队，实际测试覆盖率也普遍低于80%的理想目标。AI 编程工具的出现正在根本改变这一经济账：Claude Code 可以在生成业务逻辑的同时，以几乎为零的额外时间成本生成边界条件测试、Mock对象和集成测试脚手架。Fiona 的更深层洞察在于，将"产品规范"本身也纳入这套体系——spec 进仓库后，AI 可以持续校验生成物是否符合产品意图，构建出"产品规范即测试用例"的新型质量闭环。这意味着历史上因人力成本而被妥协的质量标准，在 AI 辅助下有望全面复活。

在质量监控上，团队建立了一套"bad vs. sad"框架：bad 指严重、不可恢复的错误（如 CLI 崩溃、丢失工作），sad 指可恢复的痛点（如界面闪烁）。有意思的是，sad 累积起来也可能演变为 bad。基于"高能动性"原则，每个团队自行定义各自 surface area 的 bad 与 sad 标准。团队甚至一度上线过追踪用户"脏话频率"的看板——当大家频繁爆粗口，往往意味着体验出了大问题。

核心启示是：在无法用人力跟上速度的时代，监控与测试（evals）才是守住质量最可靠的工具，而非投入更多时间做人工审查。

AI改变了什么，又带走了什么

这场变革有得也有失。Fiona 诚实地谈到了那些正在消逝的东西。

过去工程师最享受的心流体验——戴上耳机、播放专注歌单、在攻克难题后迎来"终于搞定了"的巅峰时刻——正在减少。更值得警惕的是孤独感。软件工程本是协作的事业，有人做后端、有人做前端、有人做 iOS，如今可能是"10 个 Claude 并行跑着做所有事"。

为此，Claude Code 团队做了两件人性化的事：一是发起 pairwise programming lunch（结对编程午餐），因为每个人使用 Claude Code 的方式差异巨大，互相观摩能学到很多；二是坚持通过黑客松等形式创造团队共同的"maker time"。这是一种类似儿童"平行游戏"的新协作形态——各自构建自己的东西，但在彼此身边、互相观察借鉴。

关于"工程师会不会因为不再写代码而技能退化"，Fiona 的态度是：坚持"trust but verify"，务必花时间理解架构、理解你所依赖的每一层（"always double click on the layer beneath"）。这一忧虑并非空穴来风——认知科学中的"技能生锈"（skill rust）研究表明，长期不直接练习某项能力会导致底层认知模型的退化，这在飞行员依赖自动驾驶后面临的操作能力下降问题上已有充分记录。至于新一代工程师的培养，她坦承这是让她夜不能寐的开放问题之一——也许未来会走向类似 fellowship 或 apprenticeship 的模式。

从六个月路线图到JIT即时规划

Fiona 分享了一个反直觉但极其务实的管理理念：明确授权团队去"杀掉"不再服务于目标的流程。

她刚加入 Claude Code 时，曾想做一份轻量级的六个月路线图文档。结果三个月后她发现，因为领域变化太快，这份文档根本没人再引用了。于是她转向了她称之为 JIT planning（just-in-time，即时规划） 的方式：只做一个月的、极其轻量的规划（甚至就是一张简单的表格，列出团队认为最重要的几件事），然后每周快速 check 一次"这些还是我们要做的吗"。同时保留每半年一次的全团队大方向对齐。

"JIT"这个命名借用自精益制造中的"准时制生产"概念——由丰田工业工程师大野耐一在二战后发展完善，核心是消除七种浪费，其中"库存"映射到知识工作领域，对应的正是"未被执行的计划"和"过时的文档"。这一理念进入软件工程，首先体现在2001年《敏捷宣言》将"响应变化高于遵循计划"列为核心原则。Fiona 的实践是将这一原则推向更激进的极限：在VUCA环境（波动性、不确定性、复杂性、模糊性）下，越是动荡的领域，越需要缩短计划周期、强化反馈回路，传统的OKR年度框架在AI加速迭代的节奏下几乎失去意义。

她甚至还在思考如何把这个每周更新的动作也自动化掉，避免任何人因为"要更新表格"而感到被压迫。这背后的元原则是：在变化如此之快的领域，永远要问自己——这个流程还在发挥它的作用吗？

结语：Dogfooding精神与让她失眠的团队文化

贯穿整场对话的一个高频词是 dogfooding（吃自己的狗粮）。这个词源自1988年微软高管 Paul Maritz 给员工发送的一封邮件，要求团队内部使用自己开发的产品，此后成为科技行业的通用文化术语。

Dogfooding 的深层价值，根植于认知科学中的"默会知识"（tacit knowledge）概念——哲学家迈克尔·波兰尼的核心命题是"我们知道的比我们能说出的多"。用户往往无法准确描述自己的痛点，但能在体验发生的瞬间感知到。依赖反馈表单来发现产品问题，存在系统性的信息损耗；而产品团队亲身使用，能直接获取这种难以语言化的体验信息。心理学中的"同理心鸿沟"（empathy gap）研究进一步表明，不亲身体验某种状态时，人们极易低估该状态下的感受强度——这正是为何 Fiona 在 Facebook Marketplace 卖 MacBook 时亲历诈骗流程、在 VR 团队总能发现诡异的地面高度 bug，能带来团队内部测试所无法替代的洞察。

从管理学角度，dogfooding 的核心价值在于缩短反馈回路——产品团队成员作为高密度用户，能更快速地发现普通用户会遇到但难以语言化表达的体验问题。她那句话"用户会以你意想不到的方式使用产品"，正是对此的直白注脚。引用贝索斯的名言——当数据和轶事冲突时，相信轶事。定量数据揭示"发生了什么"，而亲身体验才能解释"为什么"，两者结合才能指向真正的问题根源。

而真正让 Fiona 夜不能寐的，不是产品或工程难题，而是团队文化。"文化是活的、会呼吸的东西，不是贴在墙上的海报。"在 Anthropic 这样处于史上最陡峭增长曲线的公司，如何在飞速扩张与频繁招聘中维系那份"one-team mentality"（当你接近终点线时，回头看看是否有队友需要帮助，也许你们该作为一个团队一起冲线），是她最深的牵挂。

对于那些感到被时代甩下的人，Fiona 的建议朴素而有力：主动拥抱，问自己"什么在我的掌控之中"。知识即力量，而 AI 工具，正是那盏可以照亮前路的灯。

核心要点