Anthropic Claude Code 团队工程总监 Fiona Fung 在 Code w/ Claude 2026 旧金山站说了一句话，让台下不少人沉默了几秒：
“在我们团队，写代码、写测试、重构——这些事基本上已经不再拖慢我们了。”
这不是在吹牛，而是在引出一个更难的问题：如果写代码变得那么快，为什么交付还是很慢？
瓶颈没有消失，它只是换了地方
用 Claude Code 这类 agentic 工具开发一段时间之后，团队会遇到一道无形的墙——但这道墙不在代码本身。它通常在这几个地方：
- 评审容量：代码 PR 多了三倍，评审人还是那几个
- 跨职能对齐：设计、安全、法务对新功能的确认变成了关键路径
- 所有权模糊：AI 生成的代码谁负责维护？出问题找谁？
- 安全验证：80% 的代码由 Agent 提交，安全审计的节奏跟不上
这不是"用 AI 没用好"的问题，而是整套组织流程都是围绕"写代码很贵"这个假设设计的。假设变了，流程就得跟着变。
他们重写了哪些规范
1. 团队结构：尽量扁平，管理者必须先做 IC
Claude Code 团队的原则是：每一位 manager 都必须从 IC（独立贡献者）做起，先学会怎么在这套 AI-native 流程里有效地把事情做出来，才能管别人。
这背后的逻辑很简单：如果你自己没用过 Claude Code 把一个完整功能从需求跑到 PR，你根本不知道哪些流程在阻碍别人。
2. 评审：从"审代码"变成"审意图"
当 Agent 能在分钟内生成大量代码时，等到 diff 出来再去评审已经太晚了。Fiona 团队把质量关口往上移：
- 在动手写代码之前，先对齐需求意图（intent）
- 人工评审的重点从"这段代码写对了吗"转向"这个功能到底该不该做"
- 机器负责验证实现，人负责验证方向
3. 所有权：每一块代码都要有人类负责人
AI 写的代码不是"无主之地"。Fiona 的团队有一条硬性规定：任何合并进主干的代码，必须有一个真实的人类工程师作为 DRI（直接负责人）。Agent 可以是"提交人"，但不能是"负责人"。
这看起来像是废话，但实操中很容易滑坡——当 Agent 生成了 90% 的代码，很多团队会下意识地认为"AI 搞定了，不用太担心"。这是一个系统性风险点。
4. 招聘：招判断力，而不只招编码能力
这是最反直觉的一条。既然 AI 能帮写代码，是不是不需要那么多工程师了？
Fiona 的答案是：需要的人和以前一样多（甚至更多），但招的人画像变了。她们现在更看重：
- 能不能快速判断 Agent 输出的对不对
- 能不能清晰表达需求（prompt 质量直接决定 Agent 输出质量）
- 能不能在高速推进中识别系统性风险
用她的话说：“AI 把低水平的任务交给了机器，但它同时把高水平判断的要求推到了每一个人面前。”
哪些事情"断"了，又是怎么修的
Fiona 坦言，这套转变并不顺滑。以下是她提到的几个"断掉的地方"：
代码评审机制断了——PR 数量暴增，老的评审 SLA 根本撑不住。修法：引入分层评审，常规 PR 由 CI + 自动化检查主导，只有涉及安全、架构的才拉人工。
所有权感断了——工程师开始觉得"反正是 AI 写的，我只是改了改"。修法：在 PR 模板里加了一行"我（DRI）已经理解这段代码的每一处改动，并对其正确性负责"，要求提交人签字确认。
跨团队节奏断了——产品和设计没跟上 AI 提速后的工程节奏。修法：把 spec 阶段（需求细化）拉进了工程流程，而不是单独由 PM/设计完成再交接。
一个值得注意的信号
这场分享里有一句话值得单独拎出来：
“我们现在的问题不是代码写不出来，而是我们得学会在快速生成大量代码之后，有纪律地说不。”
AI 降低了动手的成本，这件事有两面性。一面是交付更快，另一面是"随手加个功能"的冲动也变得更廉价。技术债的积累速度可能和代码生成速度一样快，甚至更快。
能控制住这种冲动，可能是 AI-native 时代最核心的工程能力之一。
原文：Running an AI-native engineering org | Claude by Anthropic
本文根据原文改写，保留核心观点，加入了结构性整理与中文语境下的补充说明。
关于
关注我获取更多资讯
