AI 原生工程组织，瓶颈不在写代码了
Anthropic 这篇《Running an AI-native engineering org》很适合工程负责人读。
它聊的不是“Claude Code 能写多少代码”，而是一个更现实的问题：当写代码、写测试、重构都变快以后，团队原来的流程还站得住吗？
我读下来最该带走的一点是：瓶颈没有消失，只是从编码转到了验证、代码评审和安全。
旧流程为什么会失效
以前工程流程默认一件事：写代码很贵。
所以团队会提前做路线图、写设计文档、开很多评审会，目的都是减少返工。
但 Claude Code 团队的情况变了。原文说，他们现在很少被写代码、写测试和重构拖慢。真正卡住他们的，是代码是否正确、怎么维护、谁来承担安全和产品判断。
这会让很多“以前合理”的流程变成摩擦。
规划要更短，更靠近反馈
Fiona Fung 提到，她刚加入 Claude Code 团队时，团队写过一份六个月路线图。结果到第三个月，因为 Claude Code 带来的变化，路线图已经过时。
他们现在更像是在做 JIT planning：在刚好的时间做刚好的规划。
具体变化是：
- 少一点长设计文档；
- 多用 PR 讨论和原型推进；
- 先让内部用户试起来；
- 根据反馈快速调整。
这不是不要规划，而是别让规划跑在真实反馈前面太远。
代码评审：Claude 先筛，人看关键处
我会把这套代码评审方式概括成 trust but verify。
Claude Code 团队会大量用 Claude 做风格检查、lint、PR 反馈、bug 捕捉、提交前修复和补测试。
但人没有退出。
法律风险、信任边界、安全敏感代码、产品感觉和设计品味，仍然需要领域专家参与。因为这些地方不是“能不能跑”的问题，而是“能不能负责”的问题。
这条边界要说清楚：AI 原生团队不是让模型替代评审，而是让模型先处理高频机械问题，把人的注意力留给高风险判断。
团队画像也会变
Claude Code 团队里，PM 也会写很多代码；工程师也会参与内容、设计这类过去更偏非技术侧的工作。
角色边界变模糊以后，招聘重点也会变。
Fiona Fung 说她更看重两类人：
- 有产品感的创意型构建者；
- 有深厚系统经验的工程师。
相反，单纯的原始吞吐量没以前那么稀缺，因为模型已经承担了很多产出。
所以未来更值钱的能力，可能是会定义问题、会判断边界、会理解系统约束，也知道哪些流程该自动化。
怎么判断新流程真有用
原文建议工程负责人盯三个指标：
- Onboarding ramp time：新人多久能开始有效工作。Claude Code 团队观察到，这比一年前快很多，工程师第一周就能交付真实代码。
- PR cycle time：PR 周期有没有下降。代码生成变快后，构建系统和 CI 可能变成新瓶颈。
- Claude-assisted commits：Claude 辅助提交的比例是否上升。他们团队默认每个提交都有 Claude 辅助，Fiona Fung 说过去四个月没看到非 Claude 辅助的提交。
但原文也提醒：不要把吞吐量当成成功本身。真正要量的，还是团队原本想解决的问题。
我会怎么落地
如果你想借这篇文章改团队流程，先别喊“全员 AI 原生”。
先挑一个最吵、最贵、大家最不想参加的流程，问三个问题：
- 它现在还服务原来的目的吗？
- 如果服务，能不能让 AI 先做一部分？
- 如果不服务，能不能砍掉？
文中还提到作者过去经历过一个每周大型评审会：一堆人坐在会议室，只有轮到自己汇报时才抬头，其余时间都在看电脑。后来团队问了一句“为什么还要开这个会”，最后直接取消。
这才是 AI 原生工程组织最该先做的事：不是给旧流程套一层 AI，而是重新检查旧流程还值不值得存在。
Meta（发布信息）
建议标题（20字以内）
- AI原生团队怎么跑
- 写代码不再是瓶颈
- Claude团队的流程变化
正文描述（用于发布）
Anthropic 这篇文章最值得看的点，不是 Claude Code 写代码多快，而是团队流程怎么被重新改写。写代码、写测试、重构变快以后，瓶颈会转向验证、评审、安全和产品判断。适合工程负责人、Tech Lead、正在推进 AI 编程工具落地的团队收藏。
参考资料
话题标签
#ClaudeCode #AI编程 #工程管理 #技术团队 #代码评审 #研发效能