Anthropic Claude Code 负责人：代码不再稀缺，瓶颈已转移

Anthropic Claude Code 与 Cowork 团队负责人 Fiona Fung 在播客中提出一个核心判断：随着 AI 大幅降低编码成本，软件工程的瓶颈已从「写代码」转向「验证、审查与质量保障」。Fiona 拥有 25 年工程经历，经历过 Visual Studio 时代、在线发布时代到 AI 编码时代的三轮范式更迭。她观察到，每次旧瓶颈被打穿，新的瓶颈就会浮出水面。

编码不再是瓶颈：交付量 8 倍跃升，角色边界消失

Fiona 援引了一组数据：Anthropic 工程师平均每个季度交付的代码量，是 2021 至 2025 年间的 8 倍，曲线在长期平稳后突然陡峭上扬。但比代码量暴增更值得关注的是「提交代码的人变了」：在 Claude Code 团队，设计师、产品经理乃至几乎所有角色都开始直接提交代码。「写代码」正在从工程师的专属动作，演变为一种跨角色的基础能力。

Fiona 在播客中表示：过去工程团队的核心约束是「工程带宽」，所有规划都围绕稀缺的编码时间展开；如今这个约束消失了，代码可以廉价、迅速地生成出来，真正稀缺的是验证与质量保障能力。她引用团队中一位工程师的转变作为佐证——过去听到复杂需求的第一反应是「做不了」，现在的反应是「让 Claude Code 搞就行了」。

验证成为新瓶颈：四套质量保障方法

针对 AI 生成代码的质量问题，Fiona 在团队内部推行了四类做法。

自动化代码审查：把可标准化的检查项交给 Claude 执行，但涉及深层专业知识的部分仍由人工完成。Fiona 建议团队把「什么算好」的定义（设计规范、代码风格、架构原则）写进规则文件，与代码仓库同步更新。
测试驱动开发（TDD）回归：先写测试用例、再写代码。Fiona 透露，她用 Claude 修的第一个 bug 就是按这套流程走的。她形容过去写测试「像被逼着先吃西兰花」，现在 AI 把烦人的部分嚼完了，开发者只管收现成。
「Bad vs Sad」判断框架：Bad 指的是不可恢复的严重错误（如数据丢失、命令行崩溃），Sad 指的是不适但可恢复的问题。关键洞察是：Sad 攒多了会变成 Bad，团队需要同时盯紧 Bad 的修复与 Sad 的趋势。
跟踪用户说脏话的频率：这一去年九月由团队工程师提出的指标，后来被用作监测用户情绪的辅助信号。脏话频率上升，意味着产品在某处让人抓狂，它提供了与性能指标完全不同的观察角度。

管理者角色重写：从「亲自上手」到「搭系统的人」

Fiona 自己的工作流也因 Claude Code 推出的 Routines 功能被彻底重写。她设置了一个每日 Routine，让 Claude 自动监控反馈频道、提炼主题并生成摘要，早上醒来时已有多个 PR 等待她审阅。Lenny 在对话中追问道：这是否意味着管理者从「派人修」变成了「审 PR」？Fiona 回答「对，还不止」——如果验证机制足够完善，Agent 可以获得更多自主权直接执行。

她概括了三次角色跃迁：

过去：自己写指令，等结果。
后来：一次发多条指令，异步收集结果。
现在：设定固定流程，流程自己写指令并分派，你的角色是「事后审一下」，再往前一步就是「搭系统的人」。

Fiona 同时承认，新工作流带来了一种「全新的上下文切换负担」：过去脑子累在写代码上，现在脑子累在来回切换、逐个验收上。

规划节奏压缩：六个月路线图被「毙掉」

Fiona 加入 Claude Code 时曾尝试做一份六个月路线图，三个月后发现没人再看了，果断终止。团队现行的做法是「即时规划」：只排一个月计划，载体是一个轻量电子表格，连正式文档都没有；每半年做一次主题对齐，确定大方向，具体功能在月度窗口内现定。她甚至在琢磨把这个表格本身也自动化，「别让更新表格反过来成了一种新负担」。

在流程管理上，Fiona 的态度是「没用就杀」：挑一个让你头疼的流程，问一句「它还在服务于它原本要解决的问题吗」，如果答案是否定的，就直接砍掉。

招人标准与人才配对

Fiona 现在主要招两类人：

dreamers：有产品触觉的创造型选手，能从想法独立推到落地，全程自己扛。
深度系统专家：真正懂底层系统与分布式架构的工程师，模型再强也需要有人理解底层运行逻辑。

她反复强调的配对原则是「高 agency + 高 accountability」：团队成员可以主动出击解决问题，但必须回答清楚「要解决什么、假设是什么」。她要求所有新晋管理者必须先回到一线写代码至少一个季度，理由是 Claude Code 与 Cowork 的迭代速度以周计，管理者若不每天亲手用产品，很快就会丧失判断力。

指标需要被反复质疑

Fiona 以 Facebook Marketplace 的经历为例：当年 Marketplace 按地区上线，团队盯的指标是卖家数量，首个地区上线后卖家数不多，看似未达标。但她注意到有少数「超级卖家」覆盖了大量品类。如果团队死盯「卖家数量」这一门槛指标，就会完全错过这个洞察。后来指标体系被更新，把超级卖家维度补了进去。

她给出的建议朴素而直接：「不要把折腾当进步；盯工具使用量，你盯的只是折腾的量。」面对任何指标——代码行数、提交次数、算力消耗——都要确保自己没戴上眼罩，今天有用的指标，明天可能就是盲区。

结语：AI 编码时代的人

Fiona 最后聊到了人的体验。她观察到，过去工程师那种「死磕一个棘手问题、最终灵光一闪」的成就感正在变少，因为最难的那部分代码往往被 AI 写完了。另一个变化是孤独感：以前团队一起写代码有交集、有摩擦、也有默契，现在可以同时开十个 AI 助手并行跑，所有事都在推进，唯独你是孤身一人。

她的团队最近搞了一个叫「结对编程午餐」的活动，试图在 AI 协作时代重新找回人与人之间的连接。Fiona 的分享横跨工程实践、团队管理、流程设计与人的体验，她给出的不是一套标准答案，而是一组在高速变化中持续迭代的解题思路。