当 AI 成为默认工作方式，工程团队如何改变？

Claude Code / Claude Cowork 工程负责人 Fiona Fung 在 Code w/ Claude SF 2026 给咱们分享了「如何管理一个 AI-native 工程团队」。她的主要判断是：在 Claude Code 团队里，写代码、写测试、重构已经很少成为主要限制，新的限制变成了验证、代码评审、安全和专业判断。 https：//claude.com/blog/running-an-ai-native-engineering-org

# 四个研发流程变化

1. 规划：从半年路线图转向及时规划 Fiona 说，Claude Code 团队曾经写过一份不错的六个月路线图，但因为变化太快，到第三个月就过时了。于是他们把规划从重文档、重长期计划，转向原型、内部用户反馈和更短周期的判断。

这不是说不规划，而是规划的颗粒度变了。越是 AI 加速明显的团队，越不适合把大量时间花在远期细节上。合理做法是保留方向判断，把执行细节放到更接近真实验证的时间点。

2. 上下文获取：从找人，变成先问系统 传统工程团队遇到问题，常常先找"谁写了这段代码"。但如果大量 PR 都由 Claude 辅助完成，只知道开发作者已经不够。文章建议更深入地问：你到底想知道什么？是找回归原因、找某个决策背景，还是找能回答客户问题的人？

这里的变化很关键：知识不再只绑定在人身上，而要尽量沉淀到代码、PR、日志、反馈和自动摘要里。团队管理的重点也从"问谁"变成"如何让上下文可被检索、可被解释、可被复用"。

3. 代码评审：AI 处理常规问题，人处理专业判断 文章提到 Claude 会大量参与样式、lint、PR 反馈、bug 发现、修复和测试补充；但法律风险、安全边界、产品判断、设计品味这些仍然需要人。

这说明代码评审的价值正在重新分层。低层次的一致性检查、常见 bug、测试补齐，应该更多自动化；高层次的架构判断、安全责任、业务取舍，仍然要由有经验的人负责。

这也是很多团队容易误解的地方：AI 不是让人退出评审，而是让人从琐碎检查中移出来，把注意力放在更难、更有责任的问题上。

4. 团队结构：角色边界变模糊，但深度专业仍然重要 文章提到 PM 开始写代码，工程师也会承担内容和设计相关工作。团队更看重两类人：有产品感觉的创造型建设者，以及有深厚系统能力的工程师。相对而言，单纯"写得多、写得快"的价值下降，因为模型已经能承担大量产出。

这点很现实。AI 会扩大非传统工程角色的能力范围，但并不会消除专业深度。恰恰相反，当更多人都能生成代码，真正稀缺的是：判断要做什么、如何保证可靠、如何处理复杂系统约束。

# 组织管理上的真正变化

第一，流程不能永久存在。很多流程当初是为了解决某个问题，但问题消失后，流程往往还在消耗团队时间。AI 加速后，团队要更频繁地审视哪些会议、文档、审批、评审已经不再有必要。

第二，组织要把"默认使用 AI"变成共同原则，而不是个人偏好。Claude Code 团队要求成员持续使用自己的产品，包括跨职能伙伴也使用 Claude Code 和 Claude Cowork。这会让团队更快发现真实问题，也能形成一致的工作方式。

第三，管理层需要贴近一线。文章提到希望 manager 先作为 IC 参与交付，理解团队真实工作方式。在 AI 改变开发流程时，只靠传统管理汇报，很容易低估变化速度，也容易保留过时流程。

# 可以跟踪的三个指标（建议工程负责人关注）

1. 新成员多久能有效工作。Claude Code 团队认为，现在新人可以在第一周就交付真实代码。

2. PR 周期是否变短。如果代码生成速度上来了，但 CI、构建、评审跟不上，瓶颈会转移到工程平台。