> For the complete documentation index, see [llms.txt](https://doras-dreamland-adventure.gitbook.io/enterprise-ai-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doras-dreamland-adventure.gitbook.io/enterprise-ai-transformation/di-yi-bu-fen-ren-zhi-pian/03-ben-zhi-dui-zhao.md).
# 第 3 章 · 与信息化、数字化的本质区别
把 AI 当成"更聪明的数字化"，是最常见、也最容易让人走错方向的一个判断。表面上两者确实很像：都要接数据、配权限、做系统集成，也都是 IT 预算里的一笔开销。但只要看清机器在其中究竟替企业做了什么，就会发现这是两件不同性质的事。
先说数字化。它让机器替企业处理信息：规则事先定好、写成代码，机器负责把它高速、准确地执行下去。它的能力上限，取决于规则能被说清楚到什么程度。说得清的事——订单如何流转、库存到什么水平预警、单据该走哪条审批——它做得又快又稳；可一旦规则说不清，比如一封邮件该怎么写、一个难缠的客户该怎么谈，它就无能为力，只能交回到人手上。
过去几十年，信息技术带给企业的三样东西——连接、存储、计算——本质上都在做同一件事：让信息更顺畅地流动、沉淀、被处理。它们解决的是"信息在哪里、怎么流动"的问题，却始终没有触碰"信息意味着什么、该怎么办"这一层。后者一直留在人的脑子里。
AI 真正触及的，正是这后半层。它不依赖事先写好的规则，而是从大量样本中自己归纳出应对的方式，因此能处理那些规则写不清、只能依靠判断的工作：读一份合同、拟一个方案、把一堆零散信息梳理成结论。它给企业新增的能力，也可以对应地概括为三样：理解，把文字、图像、语音这些非结构化的内容读成机器能处理的含义；生成，产出新的文本、方案、代码，而不只是搬运既有数据；判断，在规则难以穷尽的情形下做出取舍。
如果说数字化让信息流动起来，那么 AI 让判断得以规模化。用一句话概括这条分界：数字化把"流程"交给机器，AI 把"判断"交给机器。
分清这条界线，不只是概念上的讲究，它直接决定企业该把力气用在哪里。把 AI 当成"更聪明的数字化"，最典型的后果，是它被当作又一个 IT 采购项目：立项、招标、上线，交给技术部门去落地。可 AI 转型真正的难点，从来不在系统本身，而在于重新回答一个问题——企业里原本靠人做的哪些判断，现在可以部分交给机器；交出去之后，人和流程又该如何重新安排。这不是任何单一部门能独自回答的，于是常见的结局是：钱花了、试点做了、演示也漂亮，却始终没有触及真正创造价值的那部分。要避开这个结局，方向其实不复杂：AI 转型不能当成技术部门的采购任务，而要作为一次"哪些判断能交给机器、交出去之后工作怎么重排"的业务重新设计，由业务和决策层牵头。至于该建怎样的组织、怎么从试点走到规模化，是后面几章的事；这一章要立住的，只是它在性质上不同于一次系统上线。
这个"性质不同"，从两者出错的方式上看得最清楚。传统系统出的是 bug：能复现、能定位，找到出问题的那行代码改掉，它就不再犯同样的错。AI 不是这样。同一类合同，它可能这一份读得准、那一份读错，却找不出规律，也没有"错在哪一行"可查——因为它并不是在执行某条规则，而是在给出一个"最像正确答案"的猜测。传统系统的错误可以一个个查出来、逐步清除；AI 的错误是概率性的，只能压低，却无法彻底消除。
这里的"猜"，需要稍作解释，免得把 AI 想得过于神秘。底层的计算机并没有变，它仍然是确定的——把输入和随机数都固定下来，同一个问题它每次给出的答案完全一样。之所以看上去飘忽，一是因为它在输出时被有意加入了一点随机性，免得回答千篇一律；二是因为每一次的上下文乃至模型版本，都可能略有不同。真正变了的是它处理问题的方式：传统程序沿着写好的规则走，大模型则沿着概率走，它计算的是"在这样的上下文里，下一步最可能是什么"，再把最像的那个给出来。所谓幻觉，并非它有意欺骗——它根本没有"真假"的概念，只有"像不像"。编造一条不存在的合同条款，和复述一条真实的条款，在它内部是同一种操作。
于是可以用一个简单的划分来把握这层区别：企业里其实有两台机器。一台负责"算"，确定而精确——计算、对账、执行逻辑，对错分明，错了必须改对；另一台负责"猜"，概率而流畅——起草、归纳、把模糊需求变成初稿，给出的是起点而非终点。数字化这些年打磨的是前一台，AI 带来的是后一台。把这两台机器分清楚，是理解这一整章的关键；至于它们在实际工作中怎么搭配、边界划在哪里，后面会专门谈。
还有一点可以先记下：机器能接过越来越多的判断，却接不走责任。Klarna 的例子很说明问题——它的 AI 客服上线第一个月就处理了两百多万次对话，相当于约七百名全职客服，可一年多以后，公司又转回头重新招人，因为一味压成本把服务质量拉低了。\[1]\[2] 机器把"处理咨询"规模化了，而"这个客户究竟该怎么对待"的判断和责任，最终还是落回人身上。这条界线为什么稳固、具体怎么把握，留到后面讲"边界"时展开。
最后需要说明一点，免得引出误会：说数字化和 AI 是两回事，并不意味着数字化白做了。恰恰相反，那台"会猜的机器"要靠数字化积累的数据来喂养、靠确定的系统来兜底；地基没打好，AI 就是浮在上面的。这一点，下一章专门讨论。
## 要点速查
* 数字化处理"规则写得清"的事，AI 处理"规则写不清、只能靠判断"的事；前者把流程交给机器，后者把判断交给机器。
* 这是性质之别，不是聪明程度之别：传统系统的错误是能逐步清除的 bug，AI 的错误是只能压低、无法根除的概率。
* 企业里有两台机器：算的（确定）和猜的（概率）；数字化打磨前者，AI 带来后者。
* 机器能接过判断，却接不走责任；这条边界后面专门谈。
## 给管理者的三步
* 现在：把核心业务拆成两类——规则写得清的（流程），和只能靠判断的（判断）。这张分类表是后面选场景的底图。
* 三个月：在"判断"这一类里，挑一两个容错较高、结果好核的环节先试起来（比如文案初稿、工单分类），目标是建立手感，不追求规模。
* 一年：把"算的归确定系统、猜的归 AI"变成一条明确的分工规矩——钱、计量、合规这类必须走确定系统，起草、归纳这类可以让 AI 先出草稿。
## 用到的案例
* \[\[案例库/klarna-客服AI-roi陷阱]] —— 见正文 Klarna 段。
## 来源
1. Klarna 官方新闻稿：
2. CX Dive《Klarna credits AI for slashing customer service costs》：
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://doras-dreamland-adventure.gitbook.io/enterprise-ai-transformation/di-yi-bu-fen-ren-zhi-pian/03-ben-zhi-dui-zhao.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.