最近和一些朋友交流，发现不少大厂都在推行新的组织形态——有讲超级个体的，有讲 STL 的，有讲 FDE 的，百花齐放。我所在的公司算国内互联网大厂里比较早期在做这类探索的，而我带的团队、负责的产品，又恰巧是从 0 到 1 起步，正好和 AI 撞在了一起。
所以无论组织对我的期待，还是我自己，都非常相信「AI 会重新安排组织里谁做什么」。过去两年，我实实在在经历了几次范式的迁移。回头看，我觉得 AI 拿走的不是岗位，先是岗位里的一部分活；每拿走一次，谁定义、谁判断、谁负责，就跟着变一次。每次迁移，都有人手上的活变了样：有的变轻了，有的换了一种做法，还有的是凭空长出来的。
先说一句：下面提到的项目，出于保密原因，都不是公司真实的业务。我用行业里大家熟悉的类似项目来对标——项目是代称，过程是真的。
最开始的样子
很多在大厂待过的同学，应该都对一件事有体感：一个需求最难的不是方案，是协同。
一个需求背后站着产品、运营、研发、测试、设计、数据这一圈人。方案是想得出来的，难的是把这一圈人协调到同一个节奏上——什么时候对齐、谁来评审、谁等谁。为了保证不乱套，每个团队都有自己的提需流程：MRD、PRD、设计稿、评审、研发、测试、上线。哪怕一个小需求，从提出来到真正上线，也可能要走几个迭代。
这套流程有它存在的理由。复杂的东西需要清晰的边界和责任，分工越清楚，越不容易出事。但它也有两个代价。一个是验证永远在最后面——东西做出来上线了，才知道是不是业务要的，不对，再改一轮，资源已经花了。另一个是协同本身消耗的精力，往往比做方案还多。
那时候我们没觉得这有什么问题。分工细是成熟的标志，流程长是严谨的表现。这些分工说到底，就是在回答一件事：这件事由谁来做。直到 AI 出现。
从写代码，到写清楚
AI coding 工具刚冒出来的时候，我们拿一个结算需求试了试水：根据各种规则计算资金，展示给运营对账。这是个前后端协作的需求——后端有复杂的数据计算、要设计接口，前端要展示各种聚合维度的账单，帮运营对账。当时的想法很简单：能不能让产品自己写需求、自己上线？
初期的答案是「可以，但有限」。纯前端、独立的小工具——数据看板、个人小工具这类——用 vibe coding 加个数据库，真的能跑起来，看着特别爽。但结算这个需求一碰就露馅了：前端展示可以很快搭出来，后端复杂计算、接口设计、联调、把新代码融进运行了好几年的老系统里，每一步都在教我做人的道理。算下来，花的时间和正常提需求差不多，甚至更多。
这个尝试留下一个很具体的认知：
AI 降低的是「从 0 到 1」的门槛，不是「从 1 到 100」的成本。
试水之后，我们把这套实践写成了一篇文章，分享在公司内部。没想到被 CEO 评论了一句：「这个 AI PRD 怎么生成的？」就这一句，这篇文章有了上千人阅读。
我当时被这句话点了一下。我们那会儿还不知道「spec coding」这个词，但隐约有个感觉：如果 PRD 是写给 AI 看的，它写得好不好，会直接决定 coding 的效果。以前 PRD 是给评审的人看的，讲清楚需求就行；可当写代码这件事也交给 AI 之后，这份文档悄悄多了一个读者——AI。文档没有消失，变的是看它的人。
于是第一次迁移发生了。研发的岗位没有被拿走，但重心开始上移——从「写每一行代码」往上，移到「搭架构、处理存量系统、兜住最后一公里」。产品这一侧，长出一个以前没有的念头：原来有些东西，我可以先自己动手，而且可以把需求写得让 AI 也看得懂。
把定义权往下放
结算试水之后，我们想找更难的场景：判责。判责，大概就是电商购物里，未按既定标准履约后的售后纠纷处理，以及门店检核员工的服务标准是否达标。这类需求的特点是规则极其琐碎，而且每个行业、每家门店，规则又不一样。
以前的做法，是产品去访谈业务，把规则抽象成系统逻辑，再让开发做成配置项。业务只负责录入，规则的理解和定义全堆在产品这一层。结果就是那个经典场面：业务永远觉得系统不对，产品永远在改需求。
我们这次换了位置。业务同学可以在后台自己上传数据、写 prompt、写 few-shot 示例，跑不通的地方再由产研代码化。判责规则从「产品定义、开发实现」，变成了「业务定义、AI 执行、产研兜底」。
这件事最难的不是技术，是认知从产品挪到业务——以前业务把规则讲给产品听就够了，现在要业务自己把规则讲给 AI 听，讲得越准，判得越对。AI 不是把产品干掉，是把「定义权」往下放——谁最懂规则，谁就来定义规则。
职能列表第一次长出了新样子：
- 业务：上传数据、写 prompt、写 few-shot，自维护判责规则
- 产研：把业务定义好的规则代码化，兜底，做平台
- 产品：从「定义规则」，退到「定义怎么让业务好定义」
我后来才意识到，这背后其实是同一件事：AI 让「做出来」变便宜之后，定义权开始跟着最懂规则的人走，而不是跟着最会用工具的人走。这个认知，我们吃了 2024 年底到 2025 年初一整季才消化完。
值不值得做，排在能不能做前面
2025 年 3 月，我们开始做 AI 外呼——类似电话销售，给潜在客户打电话、做意向筛选。
这次和前两次不一样。前两次我们赌的是「能不能做出来」，这次第一次开始赌「值不值得做」。做法是先搭了个 playground：话术、语料、意向筛选逻辑，全部先在里边跑，跑得通的才进产研正式链路。于是「验证」这个动作，第一次从需求末尾挪到了需求开头——以前验证在尾部，做完了才知道对不对；现在验证在最前面，还没写一行正式代码，就知道这套话术行不行、这条链路通不通。门槛从「能不能做出来」，变成了「值不值得做」。
这个判断，2025 年全年都在用：先证明值不值得，再谈做不做得出来。以前是产研把需求做出来，业务等着验收；现在业务和产品要更早站出来，证明这件事值得被做出来——实现的责任往后挪了，验证的责任往前挪了。
文档对齐，不如原型对齐
2025 年，我把「先做 prototype」定成了规矩：所有系统需求，先做原型，再做正式开发。这个规矩是我定的。效果是评审节奏整个变了——以前一个需求，光对齐就要好几天；现在先做出一个能跑的原型，大家在原型上对齐，比在文档上对齐快得多。以前按周计的活，现在几小时就能到。
更重要的是，prototype 变成了一面照妖镜，照两层：一层照需求——靠不靠谱、能不能落地、边界在哪，原型比文档诚实得多，很多在文档阶段发现不了的问题，原型阶段就露出来了；另一层照人——以前需求没想清楚也不慌，开发能补、评审能帮腔、流程能兜底，东西总能「看起来」往前走。可现在原型一摆，谁真的想明白了、谁只是在等别人接住，一眼就能看穿。原型照的不只是需求，还有做需求的人——以前想不清楚，总有人帮你补上；现在一摆出来，责任回到了提需求的人手里。
这一年，需求的解决方案从「一行行写代码」，变成了「先证明价值，再决定投入」。
从做界面，到定义能力
2026 年初，openclaw 类的开源项目火了。我们也开始部署数字助理——给门店的老板、店长、员工，各配一个。数字助理长什么样？不是又一个 App，是一个 IM 终端里的机器人。你问它任何问题，它去查数据、看洞察、追踪指标、盯行为、派任务。它不给你一个界面，它直接给你答案。
到这时候我才意识到，变化走到了一个我完全没预料到的地方：
以前 GUI 就是边界：用户看得见的，才是系统允许做的。当界面消失，边界也跟着没了形状，得重新靠人画出来。
系统不再是「给一个人用的界面」，而是「一群人共享的执行力」。可没有界面之后，边界就从页面上散掉了：助理直接开口回答，它知道什么、答应什么、答不上来怎么办，都要有人重新定义。那谁来定义这个数字助理会的技能？谁来定义权限、审批、边界？不是做系统的团队，是那些真正懂业务、又能把业务讲成技能的人。到这一步，变的已经不只是「谁写代码」，而是「谁定义能力」。一路看下来，人离单纯的执行越来越远，离判断、定义、负责越来越近。
回到一开始的问题
回头看这五次迁移，组织里的位置，在悄悄分成三种：
- 变轻的：写代码、做表单、录数据这类确定性执行
- 长出来的：描述需求、定义规则、验证价值、定义技能
- 更重的：判断、兜底、对人负责
这个列表还会变。但方向已经很清楚了：
AI 时代，没有一个职能是被干掉的，但每个职能，都被要求往「判断和定义」那一端挪。
而且迁移只是开头。真正要紧的是另一件事：**认知不是等来的，是扎进去长出来的。**我们不是坐在原地，等 AI 成熟到某一天，团队就突然有了能力。是每一次迁移，都有人真的把手伸进新的活里，认知才一层层长出来。越靠下的认知，越托着今天的位置——这也是为什么，我把这篇文章的意象想成地层。
把这一路放在一起看：AI 能承担越来越多的执行，规则可以由最懂业务的人直接定义，原型让需求提前对齐，边界一次次重新划分。但每一步，都还得有人站出来——判断什么值得做，定义什么叫做好，为最后的结果负责。这一份责任，AI 替不了。
我还没完全想明白，下一次迁移会先从谁开始。但有一点我越来越确定：位置会变，责任不会。