夜雨聆风很多团队聊 AI 进入组织，第一反应还是替代。
会不会少招人，能不能砍编制，哪些岗位先被吃掉。
坦率的讲，我觉得这个问题问早了，而且问偏了。
对研发团队来说，AI 先带来的变化，不是谁先出局，而是谁还在用旧时代那套协作假设写代码、跑项目、搭组织。
因为过去我们默认的协作对象，只有人。
这句话听着像废话，但你把它想透，会有点头皮发麻。过去几十年里，研发流程几乎所有关键设计，都是围绕人的局限长出来的。需求要拆，是因为一个人大脑装不下全部复杂度。模块要切，是因为不同人之间需要降低耦合。文档、会议、排期、汇报、owner、层层评审，这些东西之所以存在，不是大家闲得没事干，而是人在协作这件事上天然就有摩擦。
沟通会失真，记忆会衰减，情绪会波动，注意力会碎掉，刚进入状态又被拉去开会，一下午基本就没了。
我们太习惯这些约束了，习惯到甚至不再觉得这是约束。
可 AI 进来之后，最先被打穿的，恰恰就是这一层默认前提。
它不是过去那种工具型增强。
不是把编辑器更聪明一点，把搜索更快一点，把自动化脚本再多一点。
它更像是研发现场里，多了一个新的协作参与者。
这个参与者很奇怪。
它不嫌烦，不会累，不需要你鼓劲，不太在乎上下文切换，也不会因为昨天开会被怼了两句今天状态就差一点。你凌晨一点把任务甩给它，它接着干。你早上八点再问，它还能顺着昨天的话题往下接。很多以前在团队内部靠人力硬扛的沟通损耗，到了它这里，突然就没那么成立了。
这才是让我后知后觉的地方。
AI 不是简单地把研发效率往上推了一截，它是在悄悄改写研发系统默认服务的对象。以前这套系统服务的是人，现在它开始同时服务人和 agent，而这两类协作主体的物理形状几乎是相反的。
人适合在模糊里摸索，在不完整信息里猜，在关系里补洞。AI 适合在清晰约束里执行，在结构化上下文里展开，在确定边界内高速迭代。
一个擅长补灰度，一个擅长跑确定性。
所以问题不是 AI 会不会替代人，问题是当这两种主体同时进入研发系统，原来那套只为人设计的组织方式还能撑多久。
我最近越看越觉得，真正开始往 AI Native 走的研发团队，都会慢慢长成一种双层结构。
底下那层越来越硬。
代码规范、测试覆盖、CI 流水线、环境配置、接口契约、文档、权限边界、运行日志、世界模型，这些东西会被疯狂结构化。以前很多团队也有这些，只不过更多是给人看、给人兜底、给流程交差。现在不一样了，现在这些东西要变成 agent 真能读懂、真能调用、真能验证、真能失败后被追踪的形态。
这一层如果没搭起来，AI 看起来很能干，实际上一落地就开始四处撞墙。
而上面那层，反而会越来越松。
讨论、脑暴、方案试错、产品感知、业务判断、一些还没成形的直觉，一些你说不太清但总觉得哪里不对的感觉，这些东西不会因为 AI 变强就消失，反而会更重要。因为当执行被大量接管之后，真正稀缺的就不再是把活做完，而是搞清楚什么活值得做，什么方向值得赌，什么异常其实不是 bug，而是机会。
这一层，不但不能被流程压死，反而得故意留白。
我有时候觉得，先进团队接下来真正的分水岭，不是谁把 AI 用得最花，而是谁先接受一个事实，底层必须比过去更像机器，上层必须比过去更像人。
很多管理者一想到结构化，就本能觉得会扼杀创造力。很多工程师一想到流程化，就会担心自己被变成流水线工人。可问题在于，AI 时代的结构化，不是为了把人管死，而是为了把人从那些低价值对齐里解放出来。
你把底层做硬，不是为了让所有人都听话。
是为了让上层可以更大胆地乱一点。
这一点我站在研发团队里感受特别强。以前我们总觉得组织图能描述团队，谁归谁管，哪个组负责什么域，谁是 owner，谁来拍板。可一旦 agent 真正参与执行之后，组织图这玩意就开始失真了。
因为真正决定事情怎么发生的，已经不只是汇报关系了。
一个需求从哪里进入，谁做判断，谁拆成任务，哪些任务交给 agent，agent 能访问哪些仓库、哪些环境、哪些工具，在哪些地方必须人工审批，出了问题谁接住，最后谁为结果负责。这些连接起来，才是事情真正流动的路径。
你再去看组织，会发现它越来越不像一张 org chart，而更像一张 execution graph。
这个变化很微妙，但很致命。
旧时代我们问的是，这件事是谁的。
新时代你更该问的是，这个意图怎么进入系统，经过哪些节点被转成行动，谁定义约束，谁在关键点兜底。
从研发管理的角度看，这个变化特别大。因为它直接动摇了过去很多默认动作。
以前一出问题，我们先找 owner。现在很多时候更该先找 routing。到底是信息没进来，还是上下文断了，还是权限设计错了，还是 Harness 不够，还是 agent 被扔进了一个根本不可执行的灰区。
我是真的觉得，未来很多研发事故复盘的重点都会变。
以前偏向追责任。
以后会更像追图谱。
顺着这条线再往下看，你会发现一个更扎心的事实。
过去很多研发系统能跑，不是因为它们设计得多先进，而是因为工程师一直在偷偷补洞。
一个需求写得很烂，最后也能交付，为什么。因为有人会去猜你老板真正想要啥。一个接口文档缺胳膊少腿，最后服务还是能接上，为什么。因为有人会凭经验试，会去问写这个模块的人，会看调用链自己脑补。一个环境很脏、配置很乱、前置条件到处散落，最后上线居然也没炸，为什么。因为团队里总有几个老哥，脑子里装着系统的暗知识，哪儿不对他们闻一下就知道。
这些工作以前几乎不被记账。
但它们一直都在。
而且它们很贵。
很多组织以为自己的研发流程还过得去，其实只是因为队伍里有足够多聪明、耐烦、熟系统的人，在替整个组织吃脏活。
问题是，人能这样补，agent 补不了。
它不会顺着你半句黑话脑补出真实需求，也不会默认知道某个服务虽然文档没写但上线前要去另一个页面点一次刷新，更不会自己去找老王问一句这个参数到底传字符串还是数组。
所以 AI 一旦真正开始接手执行，过去那些被人默默吞掉的信息缺失，会第一次成批量地暴露出来。
你就会发现，新瓶颈根本不在模型那儿。
不在于它会不会写代码，会不会调接口，会不会生成 PR。
真正卡住它的，是研发系统本身还保留着非常强的人形偏置。
代码可以跑，是因为人看得懂。
流程可以走，是因为人会打补丁。
信息可以传，是因为人愿意反复解释。
可 AI 不吃这一套。
它要的是明确输入、稳定边界、可查询知识、可回放过程、可验证结果。
没有这些，它再强也只是看起来很聪明，真进线就开始犯错。
所以很多团队今天最荒诞的地方在于，员工明明已经感受到 AI 很能干了，但自己还在当人肉中间件。去这个系统复制一点数据，去那个平台导一点日志，贴给 AI 分析，再把结果搬回 Jira、飞书、GitLab、监控平台。整个人像一条临时拼出来的集成链路。
你说好笑吧，也挺好笑。
但笑完会有点难受。
因为这其实是在说明，很多公司不是没看到 AI，而是根本没给 AI 进入工作流留下合格的接口。
所以我越来越认同一个判断，接下来研发团队最值钱的工作，未必是多写多少业务代码，而是把系统改造成对 agent 友好的形态。
这个活一点都不浪漫。
甚至很枯燥。
补测试、补文档、清理环境、消灭隐式依赖、打通权限、补充日志、整理 SOP、给流程加观察点、给异常设计回退策略。你做的时候很难有那种卧槽我在改变世界的感觉，反而会觉得自己像在打扫卫生。
可真相往往就是，未来速度最快的团队，前期都干了大量这种脏活。
因为这类工作有非常强的复利。
Harness 一旦搭起来，agent 接手得越多，暴露出来的失败模式就越丰富。失败模式越丰富，团队对系统的理解就越深。理解越深，下一轮结构化就越精准。再往后，agent 能做的事会越来越多，人的工作重心自然被抬到更高层。
这不是一个线性提效过程。
更像是飞轮。
一开始很费劲，甚至让人怀疑值不值。可一旦转起来，后面会突然加速，而且是那种后来者很难补课的加速。
这也是为什么我觉得，AI 时代研发团队真正要抢的，不是某个模型红利，而是系统可被 agent 接管的深度。
谁先把暗知识外显，谁先把依赖机器可读化，谁先把流程从人脑默契改成可执行约束，谁后面就更快。
站在这个视角回头看，管理这件事也会发生很大变化。
不是管理消失了。
是管理里那些以人为中介的信息搬运工作，会先塌掉。
以前 manager 花大量时间做同步、跟进、对齐、搬运、汇总、转译，这些动作存在，是因为信息散、链路长、上下游彼此看不清。可如果 execution graph 逐渐成形，很多一手状态和过程数据天然就在那里，很多日常协调会被系统直接吃掉。
那 manager 还剩什么。
我自己的感觉是，剩下的会越来越偏向几件事。
第一类是判断。
不是告诉大家今天干啥，而是帮团队分辨什么值得做，什么不值得做，什么风险必须承认，什么噪音可以忽略。
第二类是设计约束。
不是自己下场写所有东西，而是帮团队把边界、标准、优先级、治理方式设计清楚，让人和 agent 都知道在哪些地方可以快，哪些地方绝对不能乱来。
第三类是接人。
这里的接人，不是客套意义上的关怀，而是真的处理人的焦虑、身份迁移、成长断裂和价值感重建。AI Native 说起来很燃，落到个人身上很多时候是发虚的。以前你靠写代码获得确定反馈，现在代码越来越多不是你写的，那你到底还值不值钱。这个坎，不是系统能帮你过的。
所以我现在越来越不相信一个简单粗暴的说法，叫中层管理没用了。
我觉得更准确的说法是，旧型管理正在失去必要性，新型架构者正在变成关键角色。
尤其是在研发组织里，会越来越需要一类人。
他们不是最会卷代码的人，也不只是画大图的人。
他们更像是在设计整套协作系统如何让 agent 真正进场的人。
什么能力该沉淀成 SOP，什么经验该变成判据，什么流程该自动化，什么异常必须人工接管，什么知识要写进世界模型，什么接口必须重新定义，什么日志必须保留，什么权限必须收紧。
这些人，正在成为新组织里最贵的杠杆。
因为他们每做对一次设计，后面都不是只帮一个同事，而是帮一群 agent、一串流程、多个项目一起提速。
一个优秀 Architect 的产出，不是一天多写了多少行代码。
而是他定义的结构，能被整个组织反复复用。
这才是研发团队视角下，我觉得最值得警惕也最值得兴奋的地方。
警惕的是，很多团队还在拿旧问题理解新变化，以为 AI 只是更快的外包，更便宜的执行层，或者更高级的 Copilot。这样看，你会把真正该投的钱和精力都投错地方。
兴奋的是，一旦你把视角调过来，会发现 AI 带来的不只是提效，而是研发系统第一次有机会从靠人硬扛，转向靠结构复利。
过去团队能跑，多半靠好工程师兜底。
未来团队能飞，靠的会是好工程师把兜底这件事，变成系统能力。
这两者的差别，非常大。
前者消耗人。
后者放大人。
而这，也许才是 AI 真正进入研发组织之后，最深的一层变化。
它不是先替代谁。
它是先逼你承认，过去很多被认为理所当然的协作方式，其实只是对人类局限的一整套临时妥协。现在新的协作主体进场了，这套妥协开始松动，研发团队也终于要认真回答一个以前可以一直拖着不答的问题。
我们到底是在搭一个给人勉强能用的系统。
还是在搭一个能让人和 agent 一起高效工作的系统。
这两个答案，会把团队带去完全不同的地方。
