AI Native组织:横向业务全栈、纵向技术全栈的实践,以及我等中登的第二春.

         

旁边大佬亲自带的一个小组在尝试一种组织、任务、人才形态，比较认可，但是还不敢在我的团队内推广，产品、技术负债太多，但后面也会慢慢推进。他们全员自带干粮上班，都用的最顶级的工具和模型，服气。

核心点：打穿模块、角色固化出来的边界，拔掉萝卜坑、“核心科技”的现象。

有几个关键点：

0. 改变团队成员的思维：要认识到自己是可以全能的（个人经验：真正优秀团队是比较容易达成这个共识的）。

1. 打破业务横向边界；
2. 打破技术纵向边界；
3. 打破思维边界：人不再按坑位固化，专家也不再靠占坑证明价值。

01

AI 平权不只是技能平权，还有知识平权

组织变形的基础是AI带来了两个平权：

1. 技能平权
2. 知识平权：我这里说的知识平权，不是指的通过AI工具获取通用知识的知识平权，而是构建了团队知识库之后，内部的私域知识平权。以前会有人把一些核心设计拿在手上，现在构建知识库，就算他不拿出来，AI也能基于现有代码等各种资料逆向出来。

这两个平权：对某些萝卜坑思维的人是有害的，但是对整个团队来说是利大于弊的，团队需要活力，人才需要流动和机会，否则就会逐步热寂。

再重点说下好处：让其他人终于有机会进入原本封闭的模块；也让原本被困在坑里的真专家，能从各种”救火队员“抽出身来干最有价值的事情。

02

技术纵向全栈：一杆子捅到底，但不能瞎捅

基于两个平权，第一个带来的组织变化和调整就是技术上的纵向全栈调整：打破专业职责固化。

前端只做前端，后端只做后端，测试只做测试，DBA 只看数据库，产品只写 PRD。这种分工在过去很有效，因为每一层都有门槛，一个人跨层成本很高。

拿我来说，现在让我再不看任何资料，回去手搓go代码，我就有点吃力了，但是不影响我拿他写很多东西。

所以现在体感变了。

现在要让一个人可以沿着一个业务问题往下捅到底，穿过产品、前端、后端、数据、测试、发布这些层，能把链路跑通、把事情一个人干完。

所以未来协作不是简单接力棒：产品交给研发，研发交给测试，测试交给运维。

更像是一个负责人带着 AI 一杆子往下捅，捅到底。

03

业务横向全栈：模块不能再变成私人领地

第二个全栈是横向的业务全栈：模块不能再变成私人领地，打破功能模块的萝卜坑现象。

以前很多团队会自然形成这样的分工：客户管理归 A，合同归 B，权限归 C，报表归 D，某个历史客户定制只能问 E。

短期看，这样效率很高。找对人，问题就能处理。

长期看：模块越来越像私人领地，别人不敢碰；负责人越来越被模块绑住，想转去做更大的事情也走不开；组织抗风险能力很差，人一休假、一离职、一转岗，模块就开始发抖。

AI Native 组织要反过来设计任务。

不是“这个模块永远归谁”，而是“这个业务结果由谁端到端负责，哪些模块需要进入，如何完整功能的实现、完整验证等。”

比如做一个优惠券支付的功能，设计到了优惠券模块，购物车模块，订单模块等等。需要人能够业务横向一刀子切到底，完成各个模块的改造，而不是改造完优惠券模块，等着其他模块来改动。

但横向全栈的风向要远大于纵向全栈，难度也一样远大于，所以这个措施实施需要很谨慎。

PS. 之所交业务横向全栈，主要是为了区分于技术的纵向全栈。

04

专家守门，不是专家包办

“一杆子捅到底 + 专家守门”，这套模式得到了团队成员的认可，但正如前面说说，这也是有风险的。

就如我，拿AI写了go代码，能看明白，能完成Review和测试，不代表我的解法是契合特殊设计或者整体设计的。

也如某些小伙伴，该了之前不熟悉的模块，功能可能正确，但是不代表不会出现其他他不知道的副作用。

所以：专家守门必须还是必须存在。

前端专家守架构和体验一致性。后端专家守服务边界、性能、事务和可靠性。测试专家守测试策略和质量证据。安全专家守权限、审计和合规……

不过，专家守门也不是说专家包办，权责，不然又会和以前的萝卜坑一样了。

这里的”专家“/”专岗“的价值应该从“我来Review、确认”，转成“我来定义规则、维护样例、审关键风险、训练其他人和 AI”。

这也是为什么我之前一直强调知识底座、规约、Review 清单、自动化测试和 Agent Skill。

专家如果只靠口头经验守门，团队还是堵在他身上。要把专家脑子里的东西蒸馏出来，团队才能变大，专家也才真的能够释放出来。

05

中登的第二春，前提是你真的下场

额外说下，AI Native 组织里最有机会走出横向全栈、纵向全栈的人，不是刚毕业的新人，也不是已经完全不下场的老管理者，而是那批有丰富经验、还愿意动手、思维没有完全固化的中年老登们。

懂技术的产品中登，优势很明显。

他知道业务目标不是文档里的漂亮话，也知道研发落地不是一句“这个很简单”。他可以用 AI 快速补齐竞品、用户故事、验收标准、原型状态、数据口径，也能和研发讨论接口、数据、边界和风险。

理解业务的技术中登，优势也很明显。

他见过系统怎么烂掉，见过需求怎么变形，见过客户怎么卡死，也见过团队怎么在质量和交付之间拉扯。他带着 AI 做端到端交付时，不会只看“代码能不能跑”，还会看“这个改法三个月后会不会坑自己”。

这类人特别适合做三件事：

1. 做端到端任务负责人，从需求、方案、实现、测试、发布到复盘，一杆子捅到底。
2. 做专家守门人，把经验变成规则、样例、检查表、Skill、测试和知识底座。
3. 做年轻人的能力放大器，教他们怎么组织上下文、验证 AI 结果、识别风险。

但前提是：中登必须真的下场，不要站在旁边纸上谈兵。

如果只是纸上谈兵的人，那就不是第二春，是第二轮被淘汰前的热身，在我团队内会快快的退场。 -- 索性我团队未出现这类登。

对我等中登而言，其实也有个困难需要自我克服：知识和经验就像一个牢笼，你一旦走进去了，再想走出来，会很困难，很多时候需要否定自己。

06

可以快速尝试的一点小心得：

1. 选 3 个非核心但有代表性的业务模块，做横向进入试点。每次跨模块任务必须留下影响面分析、测试证据和一条新知识沉淀。
2. 建立“主守门人 + 副守门人 + 可进入成员”的模块知识梯队，避免单点专家被坑位长期锁死。

最后：AI Native 组织不是取消分工，而是把分工从固定坑位拉出来，让知识和经验能的”变现“能力得到充分放大。

最后的最后：我等中登，带团队、不带团队的，都还是要抓住这个机会，亲自下场，可能真的还能迎来我们35后的的第二春。