过去二十年，研发流程的主线其实很清楚：代码产能贵，所以要尽量减少返工、减少沟通损耗、减少方向摇摆。瀑布也好，敏捷也好，很多制度差异背后，默认前提都差不多——工程师手工写代码是稀缺资源。
这个前提一旦松动，很多看起来“天经地义”的流程就会开始变形。
Claude Code 团队最近公开分享的实践，很有代表性。它真正有意思的地方，不是“AI 能写代码”这种已经不新鲜的结论，而是他们开始承认：当智能体编码变成默认工作方式后，原有研发流程并不会自然适配，组织本身要重写。
一、真正变化的，不是写代码方式
很多团队聊 AI 编程，还停留在“Copilot 能提速多少”“一个工程师能不能顶两个”这种层面。这个视角太窄了。
如果模型已经能稳定承担一大块编码、补测试、修 lint、做局部重构，那研发系统里的主瓶颈就会迁移。你会发现，最慢的地方不再是实现，而是这些环节：
- 需求是否值得做
- 原型是否足够快地被验证
- 代码是否真的正确
- 评审是否还能跟上提交速度
- 安全边界是否被悄悄突破
- 后续维护成本是否失控
这类变化，和过去从本地软件发布走向持续交付有点像。以前发版慢，所以重点是减少发版次数；后来上线快了，重点变成自动化测试、灰度、监控和回滚。今天也是同样的逻辑：代码生成变快了，治理链路就必须跟着迁移。
所以，AI 原生工程组织讨论的重点，不该是“人会不会被替代”，而是“哪些流程原本是为低产能时代设计的，现在已经过时了”。
二、流程为什么会失效
Claude Code 团队讲了一个很朴素、但很重要的判断：流程通常是为了解决某个历史问题建立的，但问题消失以后，流程往往不会自己消失。
这是很多团队的真实处境。
一个流程最初可能非常合理。比如：
- 先写完整设计文档，再排期开发，是因为编码和修改成本高
- 所有 PR 都要求资深工程师逐行 review，是因为代码主要由人手工写，产出速度可控
- 遇到问题先找原作者，是因为上下文分散在人脑和聊天记录里
- 角色边界严格区分，是因为工具门槛高，跨角色协作成本大
这些假设在 AI 编程场景下会逐步松动。于是流程表面还在，实际效果却已经变差了。
很多团队做到这里会卡住。不是不知道旧流程笨重，而是不敢动。因为旧流程再低效，至少大家熟；新流程虽然可能更适合，但带着不确定性。
工程管理里有个很现实的事实：低效流程之所以活得久，往往不是因为它有效，而是因为它显得安全。
三、规划在变短，验证在前置
Claude Code 团队提到，他们原来做过一份六个月路线图，但三个月就过时了。这个现象并不意外。
当原型产出速度大幅提升后，长期规划的收益会下降，短周期验证的收益会升高。因为你不再需要为了控制实现成本，提前把大量细节一次性想清楚。很多问题，做个原型给内部用户试一下，反馈来得更快也更真实。
这就是他们说的 JIT planning，本质上是“刚好够用的规划”。
这里的重点不是不做规划，而是调整规划颗粒度：
| 规划方式 | 适用前提 | 优势 | 风险 |
|---|---|---|---|
| 长周期路线图 | 市场稳定、需求明确、实现成本高 | 资源分配清晰，协同强 | 在高变化环境里容易快速失效 |
| 即时规划/JIT | 变化快、原型成本低、反馈渠道畅通 | 决策更贴近真实使用情况 | 如果缺少方向约束，容易陷入局部优化 |
这就是典型的工程权衡。
JIT 规划不是“反文档”“反产品”。它成立的前提是：
- 原型构建成本足够低
- 用户反馈回路足够短
- 团队对目标有统一理解
- 基础设施允许频繁试错
如果你的系统是强合规金融核心链路、医疗流程系统或者底层数据库内核，很多变更没法靠“先做出来看看”推进，那就不能照搬这种节奏。AI 把编码成本打下来了，不代表所有行业都能把决策过程同步压缩。
四、上下文获取，开始从“找人”转向“找系统”
这部分我觉得特别关键，因为它影响的不只是效率，还有组织记忆。
传统团队里，遇到一段陌生代码，第一反应往往是找作者。这个习惯很自然，因为上下文主要绑定在人身上：谁写的、为什么这么写、当时有什么约束，通常散落在 PR、会议、IM 记录和个人记忆里。
但在 Claude Code 这种高频 AI 辅助提交环境中，问“是谁改的”已经不够用了。因为提交动作的执行者可能是人，但真正相关的信息在于：
- 为什么要改
- 改动依据了哪些上下文
- 是修复回归、响应用户反馈，还是为了后续演进铺路
- 有哪些替代方案被放弃了
这也是为什么他们提倡先问 Claude。
这里不是把模型神化，而是在重构知识入口。过去入口是人，现在入口更像是“带语义检索能力的组织记忆层”。
如果做得更系统一点，它应该长这样：
这类模式成熟之后，团队会越来越少依赖“关键人记忆”。这对扩张中的组织尤其重要。
但这里也有边界。模型可以帮你汇总上下文、定位线索、回答“发生了什么”，却不一定能可靠回答“这个决策是否还适合今天”。尤其当历史上下文本身已经过时，模型只是把旧信息检索得更顺滑，并不会自动帮你完成正确判断。
所以，“先问 Claude”更准确的理解是：先让系统帮你压缩信息搜集成本，再由人做最终判断。
五、代码评审不会消失，但重点会重排
很多工程负责人现在最头疼的问题，其实就是评审跟不上。
代码变多了，PR 更快了，理论上是好事；但人类 review 的注意力没有线性扩张。于是旧的评审模式会开始崩：大家还在逐行看风格、格式、样板逻辑，但真正高风险的地方反而被淹没了。
Claude Code 团队给出的做法很明确：把机器适合做的 review 交给机器，把人类真正重要的判断保留下来。
这个分工很合理：
适合交给 Claude 的部分
- 代码风格与 lint
- 明显 bug 模式
- 测试补全
- 重复逻辑发现
- 小范围重构建议
- PR 描述补充与变更摘要
必须保留人工判断的部分
- 安全边界
- 权限模型
- 法律与合规风险
- 关键架构决策
- 产品体验与交互细节
- 可维护性判断
这个差异本质上不是“AI 智商不够”，而是责任结构不同。
比如一个权限校验逻辑，模型也许能写出通过测试的代码，但它不承担事故责任，也不会真正理解组织的风险容忍度。生产环境里，麻烦往往就出在这里：代码在局部上没问题，在系统边界上出了问题。
如果要把这件事落到执行层，一个更现实的 PR 评审策略可能是分层的：
L1：自动检查
- lint / type check / test / SAST / dependency scan
L2：AI评审
- 风格一致性
- 代码异味
- 潜在回归点
- 测试缺口提示
L3：人工评审
- 领域规则
- 安全边界
- 架构一致性
- 产品决策
这比“所有代码都人工逐行过一遍”更可扩展。
但也别走到另一个极端：把 review 全丢给模型。尤其在团队还没建立稳定测试基线、权限模型和回归机制之前，这么做风险很高。吞吐量会上去，隐患也会上去。
六、角色边界会模糊，但不会消失
“产品经理开始写代码，工程师开始做设计”，这类说法最近很流行。它有真实成分，但也容易被讲得过头。
Claude Code 团队观察到角色边界在模糊，这很正常。因为 AI 降低了很多执行门槛，原来需要专门技能才能完成的任务，现在跨角色也能参与一部分。产品经理可以做原型，设计师可以做交互验证，工程师也可以更早介入需求表达。
但这不等于角色已经不重要。
真正会被削弱的，是“纯执行型分工”；真正会被放大的，是“高判断密度能力”。
他们特别看重两类人，这个判断很有代表性：
- 有产品感觉的创意型构建者
- 有深度系统能力的工程师
这个组合背后其实很有工程逻辑。
前者负责发现值得做什么，并快速把模糊想法变成可验证的东西。后者负责在复杂系统里守住可靠性、边界、性能和演进能力。
反过来看，最容易被稀释的，是单纯依赖人肉产能的角色价值。因为“写得快”这件事，模型已经在很大程度上把门槛打平了。
所以，未来招聘标准大概率会更偏向这些维度：
| 能力方向 | 价值为什么上升 |
|---|---|
| 产品感觉 | 能判断什么问题值得解决 |
| 系统设计 | 能处理复杂环境下的约束和边界 |
| 验证能力 | 能分辨产出是否真的可用 |
| 自动化意识 | 能把重复劳动沉淀成系统 |
| 跨角色协作 | 能缩短从想法到验证的链路 |
这也是为什么很多人会觉得，AI 时代的工程组织看起来更“扁平”。不是因为管理消失了，而是因为信息、执行和试错的成本在下降，很多原来必须层层传递的工作可以直接闭环。
七、真正该盯的，不是提交量，而是瓶颈转移
Claude Code 团队提了三个观察指标：
- 新人上手时间
- PR 周期时间
- Claude 辅助提交比例
这三个指标都对，但我更建议把它们当成“诊断指标”，不要当成最终目标。
1. 新人上手时间
这个指标很值钱。它反映的是团队的可理解性、工具链可用性、知识可访问性，以及 AI 是否真的成为增幅器。
如果一个新工程师第一周就能提交真实代码，说明至少几件事做对了：
- 仓库结构不算太反人类
- 上下文获取足够顺滑
- 测试和发布链路能支持快速试错
- 团队默认允许用 AI 辅助产出
2. PR 周期时间
这几乎是 AI 原生研发最重要的中间指标之一。
因为它能直接暴露瓶颈迁移后的新堵点：CI 跑不过来、环境准备太慢、review 排队、测试不稳定、构建系统拥塞，都会在这里体现。
很多团队以为自己已经进入 AI 研发时代，结果真正卡住的是 CI 一跑 40 分钟，或者 staging 环境三天没人维护。代码是快了，流水线没跟上，整体吞吐量照样上不去。
3. AI 辅助提交比例
这个指标能衡量 AI 是否真正进入默认工作流，但它不能单独代表成功。
原因很简单：AI 参与率高，不等于交付质量高，也不等于业务价值高。一个团队完全可能在“几乎所有提交都由 AI 辅助”的同时，把系统复杂度和维护债务一起抬高。
所以我更倾向配套看一组组合指标：
- PR 周期时间
- 变更失败率
- 回滚率
- 缺陷逃逸率
- 新人上手时间
- 单位需求的验证成本
只有把吞吐量和质量一起看，数据才不容易骗人。
八、最值得先改的，通常是最烦的流程
Claude Code 团队最后给的建议很实在：去找团队里最吵、最烦、最耗精力的工作流，问它还有没有存在价值，能不能自动化，甚至能不能直接删掉。
这是非常典型的工程实用主义。
很多流程优化项目容易失败，是因为一上来就想做全局变革。最后变成一轮组织运动，文档写了很多，日常工作没什么变化。
更有效的做法，往往是从一个具体痛点切进去。比如：
- 每周高成本状态同步会
- 大量重复的客户反馈整理
- PR 描述和变更归类
- 测试补全
- 回归定位
- 线上问题分诊
- 发布 checklist
这些点有个共同特征：高频、重复、消耗注意力，而且出错收益低。
完全可以从一个很小的自动化开始。举个示意流程：
这比空谈“全面 AI 转型”靠谱得多。
九、这套方法的前提，也别忽略
看完这类案例，最容易出现两种误读。
一种是过度乐观：觉得传统研发流程已经过时，所有团队都应该立刻改成 AI 原生模式。另一种是过度保守：觉得这只是少数 AI 公司特例，普通团队没法学。
这两种判断都太快了。
Claude Code 团队的做法成立，有几个前提条件：
- 团队本身就在做 AI 产品，使用意愿和密度天然更高
- 内部反馈链路短，原型验证很快
- 组织文化允许流程被挑战
- 工具、模型和上下文系统已经比较成熟
- 团队能接受边试边改，而不是一次定死
如果你的团队目前连测试基线都不稳定、文档沉淀薄弱、权限边界混乱，那最优先的事可能还不是“全面改流程”，而是先把验证和治理补起来。否则 AI 只会把混乱放大。
说白了，AI 原生组织不是“代码写得更快”这么简单，它要求组织在另一个层面更强：更会验证、更会筛选信号、更能持续删掉无效动作。
十、接下来淘汰的，可能不是岗位，而是低效协作结构
“传统研发流程正在被淘汰”这句话，容易被理解成一种耸动结论。更准确一点说，被淘汰的不是研发本身，而是围绕旧瓶颈设计的一整套协作结构。
以前最贵的是编码，所以大家围着编码排兵布阵。现在编码越来越像廉价能力，贵的部分变成了判断、验证、边界控制和系统性思考。
这会带来几件很现实的变化：
- 规划会更短，验证会更早
- 文档会更偏向上下文索引，而不是一次性说明书
- 评审会更集中在高风险决策点
- 团队更看重高判断密度人才
- 自动化不再是效率优化，而是组织生存能力
这件事的冲击，可能比“AI 帮你写几段代码”大得多。
如果今天就要开始动手，我会建议先问团队一个问题： 现在最耗人、最吵、最不值得靠人肉维持的流程，究竟是哪一个？
别急着做宏大转型。先把那个点拆掉。
很多时候，AI 原生工程组织不是设计出来的，而是从一次次“这个流程已经没必要了”开始长出来的。
