AI原生组织为什么需要“小前台、强中台”？

这几个月，我听到“AI原生组织”这个词越来越多。

有意思的是，大家嘴里说的是同一个词，理解的却完全不是一回事。

有人觉得，公司成立得足够晚、员工都在用大模型，就是AI原生；有人开始统计每天调用多少次模型、消耗多少Token，把Token消耗量当成一家公司的“AI浓度”；还有一些企业干脆把AI转型理解成组织扁平化——少几层管理者，让更少的人完成更多工作。

但我越来越觉得，这些指标都只能说明一家公司用了多少AI，不能说明它是不是一家真正的AI原生组织。

因为真正发生变化的，并不是“大家都会不会写Prompt”，而是：

AI正在打破一家公司内部原本稳定了几十年的速度比。

而一旦速度比被打破，组织结构就必须跟着改变。

这也是为什么，我现在越来越愿意用六个字概括AI原生组织：

小前台，强中台。

这里的“强中台”，不是人更多、权力更集中、审批更复杂。

恰恰相反，它指的是：

公共能力越来越强，而调用这些能力的成本越来越低。

---

一、AI最先打破的，其实是公司的“速度比”

吴恩达在2026年4月谈AI原生软件团队时，举过一个非常形象的例子。

过去开发一个软件可能需要几个月，法务审核需要一周，这并不会显得特别慢。

但当一个AI辅助的小团队一天就能做出软件，而法务仍然需要一周时，法务审核立刻变成了新的瓶颈。

吴恩达把这种现象称为“legal compliance bottleneck”，也就是法务与合规瓶颈。与此同时，他提到自己观察到的一些AI原生团队规模大约在2—10人，并认为AI正在提高通才型人才在小团队中的价值。

我觉得真正值得注意的，其实不是“法务是不是太慢”。

法务当然有理由谨慎。一个合同条款、一项隐私政策或者一次跨境数据处理，如果判断错误，带来的损失可能远远超过晚几天上线。

真正的问题是：

公司的局部生产速度突然提高了十倍，但公司的整体运行机制没有提高十倍。

以前，一家公司内部很多工作的时间单位其实差不多。

写代码，以周计算。

做设计，以周计算。

市场准备物料，以周计算。

预算审批，也许几天到一两周。

法务审核，再花几天。

虽然有快有慢，但整体还处在一个相近的时间尺度里。

现在不一样了。

代码可能一天出来。

产品原型半天完成。

几十个广告文案十分钟生成。

市场分析一小时跑完。

数据报告可以随时更新。

结果接下来发生什么？

申请数据库权限，等三天。

找负责人开会，约到下周。

预算超过某个数字，需要逐级签字。

法务直到准备上线才第一次看见项目。

信息安全部门发现数据来源不清楚，又让整个项目重新走流程。

这就像一场4×100米接力赛。

第一棒突然换成了职业短跑运动员，剩下三棒还按照原来的速度跑。

第一棒越快，后面的落差反而越明显。

所以很多企业开始使用AI之后，会出现一种很奇怪的体感：

每个人都觉得自己变快了，但公司没有明显变快。

原因就在这里。

个人生产力提高，并不自动等于组织生产力提高。

---

二、给所有员工买AI工具，不等于AI原生

这也是我为什么不太赞成用Token消耗量衡量一家公司的AI化程度。

Token当然是一个很重要的运营指标。

它可以告诉你模型调用量、成本、活跃度，甚至能帮助判断员工是不是在真实使用AI。

但它回答不了另外几个更重要的问题：

AI生成的东西有没有真正进入业务流程？

有没有产生客户价值？

有没有减少决策等待？

有没有缩短从想法到验证的周期？

有没有形成可以重复使用的能力？

更关键的是：

AI做完之后，后面的流程还要等多久？

假设以前一项任务是：

5天分析 + 3天写方案 + 5天审批。

AI把前面8天压缩成了1天，但审批仍然需要5天。

整个周期从13天变成6天。

当然有进步。

可一旦前面的生产环节继续加速到几小时，组织瓶颈就会完全转移到审批、权限、协调和决策上。

到了这个阶段，继续给模型加算力、给员工买更多AI工具，边际收益会越来越低。

真正应该改的，是组织。

---

三、小前台：为什么未来很多团队会越来越小？

吴恩达关于2—10人AI原生团队的观察，我觉得非常值得关注。

但我不认为重点是“2—10”这个具体数字。

真正重要的是：

过去需要多个职能部门接力完成的第一轮工作，现在可能被一个拥有充分上下文的小团队直接跑通。

比如过去做一个新产品：

产品经理写需求；

设计师画原型；

工程师开发；

数据分析师做分析；

市场团队写推广方案；

运营准备上线；

销售整理客户反馈。

每个人负责一小段。

而AI正在快速降低这些专业能力之间的调用成本。

工程师可以快速做原型。

产品经理可以直接生成测试代码。

运营人员可以自己分析数据。

销售可以让AI整理几十场客户会议里的共同需求。

一个人并没有突然变成七个专家。

但一个人调用“初级专业能力”的成本正在急剧下降。

于是未来的小团队，会越来越像一支拥有大量外接能力的特种部队。

我理解的“小前台”，至少应该满足几个条件：

离客户近、离结果近、有明确目标、拥有足够上下文，同时拥有一定范围内的自主决策权。

比如一个5人小队负责提高某类客户的续费率。

他们能看到客户数据；

能直接访谈用户；

能够调用AI分析流失原因；

能修改产品；

可以做小规模定价实验；

还有一笔不需要层层审批的小额预算。

他们负责的不是“完成某个部门的任务”。

而是：

把某个业务结果做出来。

这是完全不同的组织逻辑。

---

四、但是，只学“小团队”，很容易把公司拆碎

问题也恰恰出在这里。

很多企业一听AI原生组织强调小团队、自主权、扁平化，第一反应可能是：

那就拆部门。

砍中层。

五十个人的团队改成十个五人小组。

听起来很敏捷。

实际运行一段时间，很可能完全相反。

因为每一个小组突然发现，他们都需要：

模型接口；

企业知识库；

客户数据；

数据权限；

身份认证；

效果评测；

提示词管理；

AI调用日志；

安全检查；

合同模板；

采购流程；

品牌规范；

成本监控。

如果这些东西公司没有统一提供，那么每个五人小队就只能自己做。

A团队自己搭知识库。

B团队重新接一遍CRM。

C团队自己研究数据权限。

D团队自己写一套AI评测。

五个小团队分别去问一次法务同样的问题。

十个团队分别购买十套类似的AI SaaS。

组织图确实变扁了。

但公司内部开始遍地出现“小烟囱”。

这不是AI原生。

这只是把过去中后台承担的复杂度，偷偷转嫁给了一线员工。

---

五、所以真正关键的是后半句：强中台

这里的“中台”，也很容易产生误解。

我说的强中台，绝对不是重新建立一个拥有几百人、审批所有项目的超级部门。

真正理想的AI中台，甚至未必表现为一个传统意义上的“部门”。

它更应该表现为：

接口、组件、规则、数据和护栏。

比如一家真正AI化的公司，模型调用最好不是每个团队自己注册几十个账号，而是拥有统一AI Gateway。

知识不是散落在员工电脑和微信群里，而是形成权限清晰、持续更新的企业知识层。

数据调用不是发消息找数据部门临时导Excel，而是拥有标准化数据接口。

AI应用上线之前，不是每次重新讨论安全要求，而是已经存在统一评测基线。

成本不是月底收到模型账单才发现超预算，而是实时可见。

换句话说：

前台调用能力，中台封装复杂度。

这才是“强”。

---

六、最典型的例子，其实就是法务

很多人讨论AI组织时，很容易把法务、财务、安全理解成“阻碍创新的人”。

我不太认同。

真正应该消灭的，并不是专业判断。

应该减少的是：

重复发生、规则明确、风险很低，却每次都必须找专家人工处理的判断。

传统流程可能是这样：

产品已经开发完；

营销材料已经做好；

准备上线前三天；

团队把几十页材料发给法务。

法务第一次看到产品，只能从头重新理解。

这当然慢。

另一种方式则是，法务提前把经验变成基础设施：

标准合同模板；

禁止条款；

风险等级；

预批准条款；

数据使用规则；

知识产权检查项；

升级条件。

普通低风险合同，AI先审。

标准营销文案，系统自动检查。

只有涉及重大赔偿、未成年人、医疗、金融、跨境数据、大额合同这些高风险事项，才升级给律师。

于是律师没有被削弱。

恰恰相反。

律师真正稀缺的判断力，被从大量重复劳动中释放出来了。

NIST的AI风险管理框架实际上也强调类似方向：风险管理不能等到系统做完以后再补，而应把治理、测量、风险管理和人类监督嵌入AI生命周期，并明确组织中的责任、授权以及法律、合规和监督角色。

我认为这才是AI时代真正有价值的“强中台”。

不是所有事情都要中台批准。

而是：

能规则化的变成规则，能产品化的变成产品，能自动检查的自动检查，只有异常进入专家队列。

---

七、Cloudflare的裁员，把另一个问题摆到了台面上

2026年5月7日，Cloudflare宣布将在全球裁减1100多名员工。

公司2025年末大约有5156名全职员工，因此这次调整接近总人数的20%。

更值得注意的是，这并不是一家业务突然崩掉的公司。

Cloudflare披露的2026年第一季度收入达到约6.398亿美元，同比增长34%。公司同时称，内部AI使用量在此前三个月增长超过600%，工程、HR、财务、市场等部门每天运行数千次AI Agent任务，并把组织调整放在“agentic AI era”的背景下解释。

两周以后，CEO Matthew Prince又在《华尔街日报》发表文章，把公司里的工作粗略分成三类：

Builder——创造和建设；

Seller——理解客户并创造收入；

Measurer——记录、汇总、检查、管理已经发生的事情。

在他的分类里，内部审计、收入确认、部分财务、法务、合规、中层管理和运营工作，都可能包含大量“Measurer”任务。

这个分类非常锋利。

当然，我不会把Cloudflare的一次裁员直接写成“AI已经证明某类岗位应该消失”。

这是一个CEO针对自己公司的判断，并不是经济学定律。

OECD的研究同样提醒我们：一项职业高度暴露于AI，并不意味着整个职业一定会消失。很多时候，AI首先改变的是岗位内部的任务组合；目前的跨国证据，也不能简单支持“AI暴露度越高，整体就业就必然下降”这种结论。

但Cloudflare这件事至少提醒我：

AI时代，研究“什么岗位会消失”，很可能没有研究“岗位里的什么任务会重新定价”更有意义。

---

八、律师、产品经理和管理者，都可能同时拥有三种角色

拿产品经理来说。

当他定义一个新产品的时候，他是Builder。

当他访谈客户、说服内部团队投入资源的时候，他有Seller的属性。

当他每周把十几个项目的数据复制到PPT、更新进度、整理周报时，他就在做Measurer的工作。

律师也是如此。

设计一个新的标准合同体系，是Builder。

参加重大客户谈判、建立双方信任，是Seller的一部分。

逐条核对几十份高度标准化合同，则大量属于Measurer工作。

所以未来真正危险的，不一定是某一个岗位名称。

而是这样一些任务：

输入已经数字化；

规则足够明确；

历史案例充足；

判断结果可以验证；

错误能够被发现；

流程可以拆成稳定步骤。

这恰恰是AI智能体最容易进入的地方。

反过来，那些涉及巨大责任、利益冲突、模糊上下文、高风险例外和复杂人际信任的决策，依然很难仅靠“模型给出了一个不错的答案”完成。

企业最终仍然需要一个具体的人判断、签字并承担责任。

---

九、一个反常识变化：Measurer可能减少，但“测量”会爆炸

这是我认为特别容易被忽略的一点。

未来专门做报表、汇总、转抄、检查的人可能减少。

但是：

测量本身不会减少，只会越来越多。

因为当AI Agent真正获得执行权限以后，公司必须回答很多以前不存在的问题：

这个Agent访问了什么数据？

调用了什么工具？

发了哪些邮件？

修改了什么价格？

花了多少Token？

消耗了多少预算？

为什么做出这个动作？

它有没有越权？

结果有没有达到预期？

失败以后能不能撤销？

过去可能月底审计一次。

未来可能每一个AI动作都要留下可追踪记录。

于是，AI时代真正先进的“测量系统”，并不是养更多人手工填表。

而是：

把测量本身嵌进系统。

这也是为什么我认为“小前台”和“强中台”必须同时出现。

前台拥有自主权。

中台提供可观测性。

---

十、Codex的Goal模式，其实把这个问题说透了

2026年，OpenAI在Codex中正式提供Goal模式，可以让Codex围绕一个持续目标连续工作。

但OpenAI自己的使用文档强调了一件非常重要的事情：

一个好的Goal，不能只是“帮我把这个项目做好”。

它需要明确结果、验证方式、约束条件、工作边界，以及什么时候应该停止。

换句话说：

AI能不能持续工作，取决于你能不能定义什么叫完成。

这件事情放到企业里，道理完全一样。

很多公司说：

“今年要全面AI化。”

什么叫全面AI化？

员工每天问十次AI？

Token增长300%？

所有部门部署智能体？

还是人均收入提高20%？

再比如：

“让客服满意度提高。”

什么叫满意？

投诉下降多少？

首次解决率提高多少？

平均等待时间缩短多少？

模型幻觉率允许多少？

没有指标，就没有反馈。

没有反馈，就没有Agent真正意义上的自主运行。

所以我越来越认为：

AI原生组织，本质上也是一种“可测量组织”。

目标可以被描述。

结果可以被验证。

权限可以被限制。

行动可以被追踪。

错误可以被回滚。

只有做到这些，公司才敢真正把执行权交给AI。

---

十一、“透明”，可能是AI原生组织最后一块拼图

除此以外，我认为还有一个经常被忽略的条件：

透明。

AI极度依赖上下文。

一个人只知道自己部门发生了什么，他的AI也只能知道这么多。

如果客户信息在销售手里；

产品规划锁在产品部门；

项目经验存在某个老员工脑子里；

合同条款藏在法务电脑里；

数据定义只有数据分析师知道；

那么再强的模型拿到的也是一个残缺世界。

所以AI时代企业真正珍贵的资产，并不只是数据。

而是：

被组织化的上下文。

为什么这个数据是这么定义的？

过去为什么做过这个决策？

哪些客户不能用这种方案？

什么情况下必须找法务？

哪些指标发生冲突时应该优先哪一个？

这些东西如果无法被机器读取，AI只能停留在“个人效率工具”。

而无法成为组织基础设施。

---

十二、我理解的AI原生组织，大概长这个样子

如果让我今天画一张AI原生公司的组织图，我不会先画部门。

我会画三层。

最前面，是很多2—10人左右、围绕明确业务结果组织的小团队。

他们离客户很近。

有足够上下文。

拥有有限但真实的自主权。

产品、技术、运营、销售之间的第一轮工作，可以自己完成。

第二层，是一个人数未必很多、但能力极强的公共AI中枢。

它提供：

模型；

数据；

知识；

权限；

身份；

评测；

安全；

日志；

成本；

工作流；

合同模板；

品牌规范。

这些能力最好通过接口直接调用，而不是通过发邮件排队获得。

第三层，是少量真正的深度专家。

律师、安全专家、财务专家、行业专家、架构师。

他们不负责审批所有事情。

他们负责：

制定规则；

维护护栏；

处理例外；

解决高风险问题；

在必要的时候踩刹车。

于是组织会出现一个很有意思的结构：

前台越来越小，中台越来越厚，专家越来越深。

而不是所有部门一起缩编。

---

十三、我最担心的，是企业只学会了“小前台”

未来几年，我估计会看到不少企业把“AI原生”理解成：

裁人。

减少管理层。

五个人干以前五十个人的活。

然后宣布人均效率提升了300%。

这种模式短期一定会出现非常漂亮的数据。

人均产出提高。

工资成本下降。

原型数量暴增。

项目启动速度提高。

但如果数据基础设施、权限系统、质量评测、AI治理、知识管理和员工能力没有同时升级，那么这些成本只是暂时消失在报表里。

过一段时间，它们会换一种形式回来：

重复建设；

系统失控；

客户投诉；

模型事故；

安全问题；

关键员工疲惫；

技术债快速堆积。

看起来减少了中后台。

实际上只是把中后台工作平均分给了所有一线员工。

---

寄语：AI原生不是让人消失，而是让组织重新设计

所以现在再有人问我：

什么是AI原生组织？

我的答案不会是：

公司每天消耗多少Token。

也不会是：

是不是2022年以后成立的公司。

更不是：

员工人数够不够少。

我更愿意看四件事情：

第一，前台团队是不是围绕结果，而不是围绕职能组织。

第二，公共能力是不是已经产品化、接口化，而不是靠人排队协调。

第三，目标、权限、成本、质量和风险是不是可以被持续测量。

第四，公司的知识和上下文是不是足够透明，可以被人和AI共同调用。

如果这四件事没有改变，那么公司即使给每个人都配上最先进的AI，最终也可能只是：

让员工以十倍速度撞上几十年前设计的流程。

真正的AI原生，不是简单删掉旧组织里的几个人。

而是重新回答一个问题：

当机器第一次拥有持续执行能力以后，人应该负责什么，系统应该负责什么，而组织又应该如何让两者协同。

我现在越来越相信，最后胜出的组织，未必是拥有最多AI的人。

而是那些最早建立起这样一种结构的公司：

小前台负责创造结果，强中台提供公共能力，深专家处理真正困难的例外，而整个组织用透明的数据与可测量的目标连接起来。

这可能才是“AI原生组织”真正值得讨论的地方。

---

关注本站，每天分享跨境电商前沿资讯（ Ctrl + D 收藏本站/收藏为书签 ）

参考资料

1. Andrew Ng，DeepLearning.AI《The Batch》，2026年4月：关于AI-native software teams、2—10人团队以及legal compliance bottleneck的讨论。
2. Cloudflare官方博客《Building for the future》，2026年5月7日：公布全球裁减1100多人、内部AI使用量三个月增长超过600%等信息。
3. Reuters，2026年5月7日：Cloudflare裁员比例、员工规模、季度业绩及“agentic AI-first operating model”相关报道。
4. Matthew Prince，《The Wall Street Journal》，2026年5月：《How I Choose Which Cloudflare Employees to Replace With AI》，讨论Builder、Seller与Measurer。
5. OECD关于AI与劳动市场研究：AI暴露度、任务自动化与岗位变化之间并非简单的一一替代关系。
6. NIST AI Risk Management Framework及AI RMF Playbook：关于AI治理、测量、风险管理、责任和人类监督的框架。
7. OpenAI Codex官方文档《Using Goals in Codex》：Goal需要明确结果、验证方式、约束及停止条件。

---