给企业做AI咨询的感想:AI 不该取代员工,而该把员工变成超级员工

最近我们在给一家企业做 AI 咨询和数字化转型。

开会时冒出不少有启发的判断。我们讨论的不是某个模型怎么用、某个 Agent 怎么搭，而是企业到底该怎么理解 AI这件事。

我整理成了 7 点。

本文看点

产品经理有一项非常独特的技能，他既理解用户及其使用场景，又懂技术开发，能把二者连接起来。

产品经理测试产品时，总能找到最刁钻的角度。但刁钻才真实，因为用户永远会以你意想不到的方式使用产品。

这种把用户、使用场景和技术、产品连接起来的能力至关重要——AI 可以加快开发，但不能替你理解真实场景。

我们给企业做 AI 咨询、AI 落地，目的不是用 AI 取代员工，而是赋能员工，让他成为超级员工。

具体怎么做？一种常用方法是给员工做数字分身。

很多企业低效的原因是信息不流通、分工过分明确。销售不懂技术，技术不懂销售，大家各自掌握一块信息，谁也看不见全貌。

如果给销售做一个 AI 分身，让技术身边永远站着一个 AI 销售，技术随时可以问客户关心什么、销售为什么这么承诺、这个功能到底解决什么问题，技术就开始懂销售了。

反过来也一样：给技术做一个 AI 分身，让销售身边永远站着一个 AI 技术，销售也就有技术视角和能力了。

在许多企业里，不同人员掌握的数据和文档版本完全不一样。

老板看到的是一个版本，总监手里是另一个版本，产品经理还在用上周的文档。表面上讨论的是同一件事，实际上每个人面对的是不同的信息。

因此企业 AI 转型的第一步通常是确定一套统一的数据底座，让所有人都能在权限范围内拿到最新数据。

这里最重要的是分层。这些数据谁能看？哪些数据能对外公布？数据从哪里来？Agent 可以调用哪些数据？哪些绝对不能调用？

先把权限、来源和敏感度搞清楚，再把一个个数据孤岛连成完整的数据底座。

这一步做完，哪怕 Agent 还没搭起来，企业的协作效率也已经上来了。

这其中最麻烦的是整理历史文档。企业内部往往沉淀了大量乱七八糟、格式各异、版本不明的文件。这些文档需要归类、去重、确认版本，哪怕有 AI 辅助，做起来也不轻松。

但先忘掉 AI 的存在，这件事本来就该做。

先有数据，再有 Agent。

数据底座可以来自购买的系统，也可以自己开发，关键是统一。至于接哪个大模型，用 Codex 还是 WorkBuddy，反而没那么重要。工具会变，Skill 和流程也可以迁移，真正难搬走的是沉淀的数据和业务积累。

企业做 AI 转型，别一上来就想搞个大动作。

现实的顺序是：先从个人开始，让员工养成使用 AI 的习惯；再选一个部门，把部门里的 Agent 和流程打通；跑顺以后再做跨部门协作。

跨部门从来都不只是技术问题，权限、利益、流程和责任……

推进难度大大增加。

先跑通一个部门的闭环，再去搞企业级 Agent。

会上老大说了一句话，很有启发：未来办公就是编程，编程就是办公，这两件事会变成同一个动作。

写报告、做表格、查资料、整理客户信息、搭工作流……只要一件事有 SOP，就能编写一套程序让电脑执行。

AI 编程未来会成为所有人的底层能力。

未来不会 AI 编程，约等于不会办公。

SaaS 提供一套相对固定的功能，尽量满足一类企业的共同需求。智能体则进入一家企业自己的数据、流程和岗位，跟着真实业务运转。

每家公司的销售方式、审批流程、交付标准都不一样，企业智能体很难直接买来就用。无论找外部公司做，还是自己开发，都绕不开定制。

如果企业买一个标品拿来就用，很可能为了使用产品，被迫修改自己的流程。

以前一个人一天才能完成的工作，AI 可能 10 分钟就做完了。

如果一件事本身没有价值，做得再快也没用。

这是 AI 时代的陷阱：因为执行成本变低了，就开始做大量碎片、无用、没有结果的工作。看起来每天跑了很多任务，Token 消耗不少，最后没给业务带来任何收益。

即使 AI 替你干活，也必须算 ROI。

AI 解决的是“怎么更快地做”，但值不值得做，最后还得人来判断。