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 的分享横跨工程实践、团队管理、流程设计与人的体验，她给出的不是一套标准答案，而是一组在高速变化中持续迭代的解题思路。