 开篇：先介绍一下场景

这两年很多传统制造业、工程领域的企业搞数智化建设，做出了一个很别扭的产物：把大模型、知识库、智能体塞进原来的门户里，变成"智能模块""AI 助手菜单"。页面是新的，逻辑是旧的，**人还是得登录、找入口、填表单、走审批，只不过旁边多了个会聊天的框**。

这不是 AI 赋能，这是把 AI 当成了平台的又一层皮。

正确的站位应该反过来：**AI 站到第一梯队，做人和平台之间的对接层；平台退到第二梯队，变成被调用的后台。**

- 平台不拆、不减、不弱化：它承载数据、规则、流程、合规，是记录真相的系统（System of Record）；
- 变的是**谁去操作它**：以前是人，现在是 AI 代操作；
- 人对平台界面的直接依赖被去掉了，这就是"去平台化"里那个"去"字的真实含义：**去的是"人必须亲自进系统"这件事。**

下面所有内容，都围绕一张企业 AI 应用架构图展开。

![image.png](https://developer.qcloudimg.com/http-save/yehe-2356176/5b8e643c3b4094154d84054670bb44d4.png)

这张图从左到右是三段：

- **左侧**：用户 / 业务场景（业务人员、AI Agent、客户/供应商、管理者）；
- **中间**：企业 AI 应用层（LLM、Workflow、Action、RAG、Ontology、Logic，底下压着 Governance）；
- **右侧**：企业业务系统（ERP、CRM、MES、WMS、QMS、APS、更多系统）；
- **底部**：数据与基础设施层。

关键在于**中间那一层怎么理解**。

绝大多数落地现场把它理解成"平台新增的功能模块"，于是配了入口、配了菜单、配了权限、配了流程，**中间层被做成了一个新平台**。但在去平台化的思路里，它的定位完全不同：

> **中间层不是"又一个系统"，它是"人与系统之间的对接层"。**

LLM 负责把人话翻译成任务，Ontology 负责让双方指代对得上，Workflow 负责把跨系统的动作串起来，Action 负责替人去点那些按钮，Governance 负责在底下兜住权限和审计。**它存在的唯一目的，是让工程师不必再去学那些系统的界面。**

## 一、一个真实的尴尬：东西是好东西，就是不顺手

先说一个碰到过的数智团队遇到过的场景。

某企业上线了一套智能助手：能查规程、能提工单、能生成方案初稿。产品同学做了完整的流程设计，选择场站、选择设备类型、填写问题描述、选择知识范围、确认参数、预览、提交、归档。每一步都有提示文案，每个字段都有校验规则，一共七步。

上线三个月，活跃度在首周见顶，之后一路走平。访谈时工程师说了句很实在的话：

> "我知道它挺好，但我手头在画图，为了查一条规程切出去走七步，算了我问旁边老张更快。"

这句话里三层信息：

1. **"我知道它挺好"** ：不是否定能力，工程师认可价值；
2. **"我手头在画图"** ： 他的注意力在真正的专业工作上；
3. **"切出去走七步"** ：成本不在功能多寡，而在**上下文切换**。

传统制造与工程行业的数智团队，这些年确实做了不少好东西，真金白银投进去，升级ERP等系统、构建全新企业架构、云原生、AI模型、知识库、本体、工作流等等等一个不少。但有些时候**舍本逐末了**，把"平台建成了没有"当成 KPI，而建设它的目的，本来是**为业务赋能、为工程提效**。

平台是手段。手段一旦变成目标，就开始自我繁殖：加功能、加流程、加管控节点，越做越完整，也越做越重。**而每加重一分，人就离它远一寸。**

## 二、知识陷阱：互联网产品思维的"流程洁癖"

为什么互联网背景的产品同学，几乎必然会把流程设计得严丝合缝？

因为在互联网产品的世界里，这套做法是**正确的**。

它的底层假设是：**用户的行为闭环就发生在产品内部**。用户在你的产品里浏览、点击、下单、复购，你拥有完整的用户旅程，可以度量、可以引导、可以优化转化、可以提升留存。于是"把每一步都精细化设计"就有了充分理由，每一步都是漏斗的一环，优化 1% 都是真金白银。

这套方法论有一个隐含前提：**用户是可以被迁移的，而且迁移成本由用户承担。**

工程行业的现实恰好相反：

| 维度     | 互联网产品场景       | 工程设计 / 传统制造场景                     |
| -------- | -------------------- | ------------------------------------------- |
| 主战场   | 在产品内             | 在 CAD、仿真软件、Excel、图纸会审、施工现场 |
| 成果物   | 订单、内容、行为数据 | 图纸、算稿、方案、签章文件                  |
| 用户身份 | 消费者，行为可被引导 | 专业责任人，对成果签字负责                  |
| 系统角色 | 目的地               | 办事通道 + 记录真相的地方                   |
| 优化方向 | 提升停留与转化       | **降低打扰与中断**                          |
| 系统数量 | 通常就是一个 App     | 一个人日常要面对 6~10 套专业系统            |

工程师对流程"不感冒"，不是保守、不是排斥数字化。真实原因是：**在他的认知排序里，这些东西是辅助项**。它们重要，但排在"把图画完""把算稿交出去"之后。有些时候不得不用，要留痕、要走流程、要合规，但"不得不用"和"愿意主动用"，是两种完全不同的产品命运。

于是就有了那个精准的说法：**新瓶装旧酒**。

瓶是新的：AI 对话、智能推荐、Copilot、智能体。酒是旧的：人必须进入系统，按系统设定的路径走完全程。**变量换了，范式没换。**

这就是**知识陷阱**，它害人的方式不是"懂得少"，而是"懂得太熟"。熟到把方法论的适用边界给忘了：互联网那套精细流程之所以有效，是因为**用户本来就在你的产品里**；而工程行业的用户，从来就不在你的产品里。

## 三、"去平台化"到底去什么

现在回到核心。

**去平台化，去的是"人对平台界面的直接操作依赖"。**

平台还在，而且活得更好，它依然是规则的定义者、数据的持有者、合规的兜底者。只是**它不再要求人亲自进来操作它**，改为被 AI 通过 API 调用。
![image.png](https://developer.qcloudimg.com/http-save/yehe-2356176/a67217d391dbeb1cc4c28740a5142574.png)

新的站位讲得很直白：

- **第一梯队（左）**：人 + AI 对接层。人只做两件事，说清楚要什么、对结果签字负责。剩下的翻译、查找、串联、执行，全部交给 AI 对接层。
- **第二梯队（右）**：平台与业务系统（ERP、MES、WMS、QMS、CRM、APS、数据中台……）。它们退居幕后，**规则一条没改，只是不再被人直接操作**。
- **契约（中）**：AI 和平台之间必须白纸黑字写清楚四件事。

### 一个容易被忽略的反直觉结论：平台不是变轻了，是变重了

很多人以为"平台退居二线"等于"平台可以少投入"。恰恰相反。

平台原来只服务人，现在多了一类用户是**AI**。这意味着它必须补上以前可以不做的东西：

- **稳定的 API**：不能靠界面自动化去点按钮，那是脆的；
- **幂等与回滚**：AI 会重试，一次操作不能写两遍；
- **回执与状态码**：调用成功与否必须可判定，不能靠猜；
- **调用审计**：每一次代操作都要能追到"是谁让 AI 干的"。

**不是把平台做小，是把平台的接口做硬。** 这才是去平台化真正的技术工作量所在。

### 四份契约，缺一份都不敢上线

1. **调用契约** ：平台暴露稳定 API，幂等、可回滚、有回执。AI 不模拟点击，走正规接口。
2. **语义契约**： 这是最要命的一条，由 **Ontology** 承担。AI 说"3 号机组"，平台必须知道那是 ERP 里的哪个资产号、MES 里的哪个工单对象、QMS 里的哪个检验批。**对接失败，九成不是模型笨，是两边指代对不上。**
3. **权限契约** ： AI 用的是**操作者本人的身份**，不是超级管理员。他能看的 AI 才能看，他不能改的 AI 也不能改，越权即拦截。
4. **责任契约** ： AI **只代操作，不出结论**。签字人永远是工程师本人，留痕归属于人。

第四份契约尤其关键。工程设计是有签字责任的，责任边界一旦模糊，工程师就会选择最保守的做法就是**不用**。因为他承担不起一个"系统说没问题"的后果。

> 把责任边界划清楚，才敢把 AI 放得更靠前。管控不是 AI 的对立面，是 AI 能走远的前提。

## 四、同一件事的两条路径：人跑系统，还是系统被 AI 串起来

抽象的思路落到一次具体操作上，差别非常直观。

假设工程师要办的事跨三个系统：查设备台账、查检修记录、查质量检验结果。
![image.png](https://developer.qcloudimg.com/http-save/yehe-2356176/1782bae8e2a86b936e3d95fe0952c1df.png)
**路径 A（人跑系统）**：登 ERP 找菜单填单 → 再登 MES 重新找入口 → 再登 QMS 对齐口径 → 拷到 Excel 人工汇总 → 得到答案。全程约 30 分钟，切出主战场 4 次，还容易抄错数。

**路径 B（系统被串起来）**：一句话 → Ontology 定位"是哪个设备" → Action 并行调三个系统 API → 汇总成带出处的答案。30 秒，0 次登录。

**注意这里最关键的一点：三个系统一个都没少，规则一条都没改。**

变的只是"谁去跑"。这不是推翻重来，这是把**跨平台的操作成本，从人侧转移到了系统侧**。

这也给出了判断一个 AI 应用做得对不对的分水岭：

> 它把复杂度留在了用户侧，还是搬到了系统侧？
>
> 更狠的一句：如果工程师不用它，会卡在哪一步？如果答案是"也不太卡，就是多花半小时"——那它在工作流里就是装饰品。

---

## 五、三个经常被搞反的指标

思路变了，度量指标必须跟着变。沿用互联网那套指标，会把团队往错误的方向推。

| 常见指标         | 它隐含的错误假设    | 应该换成什么                                           |
| ---------------- | ------------------- | ------------------------------------------------------ |
| **平台日活 DAU** | 人来得多 = 价值大   | **AI 代操作占比 / 人工介入率**：多少事是 AI 替人跑完的 |
| **功能覆盖率**   | 功能做得多 = 用得多 | **可调用覆盖率**：核心业务动作有多少已暴露成稳定 API   |
| **流程完整度**   | 分支越全 = 质量越高 | **一次对话办结率**：一句话能不能端到端办完             |

第一行最容易被误判，而且方向是反的。

在去平台化的思路下，**平台门户的日活下降是好事，不是坏事**。它说明人不再需要亲自进去了。真正的健康度指标是：AI 替人完成了多少次跨系统操作、其中有多少次需要人工介入兜底。

如果一个平台的日活是靠"不登录就办不了事"逼出来的，那这个日活本身就是成本，不是成绩。

## 六、四条设计原则

落到产品设计上，去平台化可以收敛成四条可执行的判断。
![image.png](https://developer.qcloudimg.com/http-save/yehe-2356176/8c2b938d9e50f19346ad4b1b1b843754.png)

**① AI 做统一入口，而不是再建一个门户。**
人对付 N 套系统，凭什么要记 N 套界面？更糟的做法是建第 N+1 个门户，那只是多了一个要记的地方。入口应该是**说话**（对话框、CAD 右键、企微一句话），背后统一接到 AI 对接层，再分发到各业务系统。

**② Ontology 是对接的命门，先钉语义再谈智能。**
AI 说"3 号机组"，平台认得出来吗？先把业务对象、关系、状态钉死，让 ERP 的资产号、MES 的工单号、QMS 的检验批指向同一个东西，AI 才接得进去。**这一步不做，后面所有智能都是空中楼阁。**

**③ 平台仍是真相源，AI 只代操作不另立账。**
AI 可以替你在 ERP 里建一张工单，但工单编号、审批流、状态机，全部走 ERP 自己的规则。规则、口径、台账只有一份，在平台里。AI 是代操作的手，不是第二本账。

**④ 平台界面做减法：前台让给 AI，后台留给少数人。**
同一个功能，以前要给人做 6 个页面；现在做 1 个 API + 1 个异常处理台就够了。剩下的界面服务于管理员、审计员，以及处理异常的人，**给全员用的界面越来越少，这是成功标志，不是失败标志。**


## 七、上线前的三问自检

每次评审一个 AI 应用，问三个问题：

1. **这件事现在还需要人进系统吗？** 还需要，说明对接没做完，继续补 API。
2. **AI 说的"3 号机组"，平台认得出来吗？**  认不出来，说明 Ontology 没建，别急着上模型。
3. **出错了账在谁那里、谁签字？** 说不清，工程师就不敢用，再智能也是零。

再加一条我一贯的立场：**别为 AI 而 AI。**

工程师真正的需求，很多时候一个检索、一个模板、一个批量脚本就能解决，不需要大模型。能用确定性规则解决的，不要上概率模型；能靠平台原有 API 解决的，不要再造一层中间系统。**AI 应该是最后一段路的加速器，不是推倒重来的理由。**

还有一句更朴素的判断：**如果一个功能 AI 能做、人也能在三秒内做完，那它不值得做。**

## 结语

回到开头那张架构图。

它真正要表达的，不是"企业该建一个 AI 平台"，而是：**在人和已经存在的那些系统之间，插一层会听人话、认得对象、敢受控操作的对接层，然后把平台从"人必须去的地方"，变成"AI 替人去的地方"。**

所以去平台化从来不是否定平台。恰恰相反**它要求平台做得更硬：接口更稳、语义更清、权限更严、审计更全。** 它否定的只有一件事：**让人去适应系统。**

判断成败的标准也就一句话：

> 工程师几乎没有感觉到系统在存在，事情却办完了，而且账在平台里、字是他签的、痕迹一条不少。这才叫提效。


这两年很多传统制造业、工程领域的企业搞数智化建设，做出了一个很别扭的产物：把大模型、知识库、智能体塞进原来的门户里，变成"智能模块""AI 助手菜单"。页面是新的，逻辑是旧的，人还是得登录、找入口、填表单、走审批，只不过旁边多了个会聊天的框。

企业级应用的「去平台化」产品思路：你的平台很完美，所以工程师不用它

企业级 AI 建设最常见的偏差，是把「建平台」当目标本身：门户齐全、流程精细、每步都有引导与审批，做的人很用心，工程师却很少打开。问题不在不用心，在站位错了。该退到第二梯队的不是 AI，是平台。它承载数据、规则与合规，一条都不用改；该变的是谁操作它。从前人登录、找菜单、填表单，现在交给 AI 通过 API 代操作。去掉人对界面的直接依赖，就是去平台化。

数智化技术专家

人工智能

架构设计

后端

去平台化不是否定平台，而是让人不再直接操作ERP、MES等系统，由AI作为统一入口代为调用。关键在于AI与平台间建立调用、语义、权限、责任四份契约，实现数据互通与责任留痕。成败标准：工程师感觉不到系统存在，事办完了，账目清晰，签字有据。

让每一个 Agent，都跑在云上

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

企业级应用的「去平台化」产品思路：你的平台很完美，所以工程师不用它-腾讯云开发者社区-腾讯云

企业级应用的「去平台化」产品思路：你的平台很完美，所以工程师不用它

企业级应用的「去平台化」产品思路：你的平台很完美，所以工程师不用它

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐