AI 正在重写软件团队的工作方式

过去很多年，软件工程管理默认围绕一个前提展开：写代码很贵。

所以我们才有漫长的规划、详细的设计文档、严格的 Sprint、层层代码评审，以及一套又一套用来“节省工程时间”的流程。

但现在，这个前提正在变化。

在 AI 编程助手和 Agentic Coding 逐渐成为默认工作方式之后，真正稀缺的东西不再只是“谁能更快写代码”。代码、测试、重构，都可以被 AI 大幅加速。新的瓶颈开始转移到别处：验证、评审、安全、产品判断、系统设计，以及组织如何重新分配人的注意力。

A社 的 Claude Code 团队最近分享了他们运行 AI 原生工程组织的经验。最有意思的一点是：他们并没有把 AI 当成一个“提效工具”塞进旧流程里，而是反过来问了一个更根本的问题：

当写代码不再是最贵的环节，工程组织还应该怎么运转？

一、长期路线图开始失效，规划变成“刚刚好”

传统工程团队喜欢做长期 roadmap。

这当然有原因。以前写代码慢、交付周期长、沟通成本高，如果不提前规划，后面就会付出巨大代价。

但当团队的产出速度被 AI 拉快之后，过度规划反而会成为负担。

Claude Code 团队曾经做过一份六个月路线图，结果三个月后就已经过时。不是因为规划质量差，而是因为现实变化太快，团队试错和交付的速度已经超过了传统规划节奏。

于是他们把规划方式改成了 JIT，类似“Just-in-time planning”。

也就是说，不再把大量时间花在提前写完整设计文档，而是更快做原型、更快给内部用户试用、更快根据反馈调整。

这背后的逻辑很简单：

当构建成本下降，最重要的能力就不再是“提前猜对”，而是“快速验证”。

以前我们靠文档降低风险。现在，很多时候原型本身就是最好的讨论材料。

二、找上下文，不再先找“写代码的人”

过去一个工程师想理解某段代码，最自然的方式是问：“这是谁写的？”

但在 AI 辅助开发成为常态之后，这个问题不够用了。

因为很多 PR、提交、重构都可能是人与 AI 共同完成的。真正重要的问题不是“谁敲下了这段代码”，而是：

这段代码为什么这样设计？它解决了什么问题？它有没有引入回归？它背后的产品或技术判断是什么？

Claude Code 团队的新习惯是：先让 Claude 帮忙梳理上下文。

比如让 AI 总结某段代码的历史、相关 PR、客户反馈、潜在影响，再由人判断是否需要进一步找领域专家确认。

这其实代表了一种新的知识管理方式。

过去组织知识沉淀在人脑、会议和文档里。现在，AI 可以成为组织上下文的第一入口。人不再总是“信息检索器”，而是更像“判断者”和“校准者”。

三、代码评审不消失，但评审重点变了

很多团队担心 AI 生成大量代码后，人类代码评审会跟不上。

这个担心是对的。

但解决方法不是让人类继续逐行检查所有东西，而是重新定义“什么地方必须由人看”。

Claude Code 团队的做法是：让 AI 处理风格、lint、常见 bug、测试补充、PR 反馈等高频标准化工作；而人类评审集中在真正需要专业判断的地方。

比如：

法律风险要找法务伙伴参与。安全边界要让安全和系统专家确认。产品体验要让 PM 和设计师判断。关键架构决策仍然需要资深工程师把关。

这很像一句新的工程管理原则：

信任 AI，但验证关键判断。

人类评审的价值不再是“看过每一行代码”，而是确保系统方向、风险边界和用户体验没有偏。

四、团队角色开始模糊

AI 原生团队还有一个明显变化：角色边界开始松动。

PM 可以写原型。工程师可以参与内容、设计和用户研究。设计师可以更直接地把想法变成可交互 demo。 

当代码能力不再只属于传统工程师，团队里很多人的创造半径都会扩大。

这也改变了招聘和团队配置。

Claude Code 团队提到，他们更看重两类人：

第一类是有产品感的创造型建设者。他们好奇、主动、愿意快速把想法变成东西。

第二类是有深厚系统能力的专家。AI 可以写很多代码，但复杂系统的边界、性能、安全、可靠性，依然需要真正懂系统的人。

相反，单纯的“代码吞吐量”变得没那么稀缺。因为吞吐量可以由模型补上，人的核心价值会更多转向判断、创造力和专业深度。

五、AI 原生组织不是“人人随便用 AI”，而是重写工作规范

Anthropic 的经验里，有几条原则很值得参考。

第一，团队必须深度 dogfood 自己的产品。

也就是团队成员自己高频使用 Claude Code 和相关工具，不只是工程师用，跨职能伙伴也要用。只有这样，团队才会自然发现哪些流程可以被 AI 改造，哪些体验真的不顺。

第二，组织尽量保持扁平。

管理者也需要先理解一线工程实践，知道 AI 辅助开发下真实的工作状态是什么。这样才能避免用旧管理方式约束新生产方式。

第三，允许团队主动杀掉过时流程。

很多流程一开始都有价值，但当环境变了，它们可能只是惯性。AI 原生团队需要持续问：这个流程还在解决问题吗？如果没有，能不能自动化，甚至直接取消？

这个问题非常朴素，但杀伤力很强。

很多公司真正的问题不是没有 AI 工具，而是把 AI 放进旧流程之后，旧流程依然原封不动。

六、怎么判断新流程是否真的有效？

文章里提到三个可以观察的指标。

第一，新人上手时间是否下降。

如果 AI 能帮新人理解代码库、补齐上下文、生成初始实现，那么工程师、设计师、PM 应该更快进入有效产出状态。

第二，PR 周期是否缩短。

AI 生成代码变快之后，瓶颈可能转移到 CI、构建系统、代码评审和发布链路。PR 周期能反映整个研发管道是否跟得上。

第三，AI 辅助提交是否上升。

但这里有一个关键提醒：不要把吞吐量误认为成功。

提交更多、代码更多，不等于产品更好。真正要衡量的，还是团队想解决的问题有没有更快、更好地被解决。

七、普通团队可以从哪里开始？

不必一上来就重构整个研发体系。

最好的起点，是找一个团队里最吵、最贵、最让人疲惫的流程。

可能是每周状态会。可能是重复的需求同步。可能是每天人工整理客户反馈。可能是冗长的缺陷分诊。也可能是每次都要靠老员工口头解释的代码上下文。

然后问三个问题：

它现在还服务于原来的目标吗？它能不能被 AI 自动化一部分？如果不能自动化，是否可以直接取消或简化？

AI 原生工程组织的本质，不是“让所有人都用上 AI 编程工具”。

它真正改变的是组织对工作的理解：

当执行成本下降，人的时间应该从重复劳动中释放出来，转向判断、创造、验证和负责。

未来的工程团队，可能不会以“谁写了最多代码”来定义强弱。

真正强的团队，是能最快识别旧瓶颈、重写旧流程，并把人的注意力放在最有价值地方的团队。