程序员是最先“读懂”智能体AI的一群人——在它能够实质性改变其生产力与效率这个意义上。原因之一在于代码是可检查的。他们把智能体放到某个函数上，读diff、跑测试，然后决定是否保留。输出以他们已经知道如何阅读的形式反馈回来，所以信任机器并不一定需要多大的信念。

而整天和数据打交道的人，离同一扇门还差一步。在美国，从事业务和财务运营岗位的人数是软件开发者的约六倍，而到目前为止，他们最多只拿到了工程领域所吸收的生产力收益中很小的一部分。没错，他们能够描述自己想要的分析——这正是需要其专业知识的地方。但反馈给他们的，是一个数字、一张图表，或者也许是两百行代码，其中没有任何东西能向分析师展示结果是如何产生的。

换句话说，这些输出不能被自动假定为用对了数据、正确地做了组合，并且最终用了正确的公式；也可能智能体漏掉了一大堆数据。结果就是一个黑箱，而黑箱不该让人产生信心。

那么问题就变成了为什么，这里有三个可以解决的变量。

问题一：用户自己的数据触不可及

业务用户的数据散落在电子表格、SharePoint里的文件、Salesforce这类应用，以及Databricks、Snowflake或BigQuery这类数据平台之中。要拿到这些数据，意味着向一个负责治理一切的数据平台团队提交申请。当然，几乎任何一位数据平台工程师都会告诉你，这个团队的人手相对于它收到的请求而言严重不足，而业务用户作为变通拿到的，往往是一份副本的副本。也许是一个几个月前导出的CSV，或者一份被转手四次、改动无人追踪的工作簿。当智能体拿这些数据开工时，业务用户虽然得到了快速的结果，却是在一个“真相的影子版本”上工作。等智能体动手时，数据血缘早就断了，所以没人真正确定某些数字从何而来，信任也就此丧失。无论什么用例，这都不妙；如果你身处一家金融机构，这大概会变成一件“职业生涯级别”的事故。

问题二：数据没有“事实核查”

聊天机器人给业务用户一个结果，却几乎没有提供可供其验证结果的上下文。把生成的代码给他们看并不是答案，因为这些用户本来就不该去读代码。正确的回应，不是为基于无法核查的数据所做的决策背书；但就像程序员交付代码一样，快速推进和交付的压力，在很多时候压过了“正确”。而且当审计人员或上级追问某个数字是怎么算出来时，“AI这么说”并不是业务用户愿意给出的答案。

问题三：工具止步于真正重要的环节

市面上面向业务用户的许多产品，都假定数据是干净且就绪的，整齐地躺在那里的某张表里，等着被“智能体化”。这些基于文本转SQL查询的产品假定数据已就绪，它们并不为AI准备数据。业务用户的一天从更早的地方开始：供应商文件以五花八门的格式送达，数据以四种不同的方式存储。跳过AI的数据准备工作、直接进入查询，正是这类工具演示效果惊艳、实际却很少被真正使用的原因。

AI处理数据时，必须展示其工作过程

当业务用户拿到一件他们能够理解的产物时，工程领域发生过的那种信任解锁就会重演。当智能体准备数据时，结果应当是可视化的工作流，逐步展示数据在每个阶段是如何被读取和转换的。你应当希望不存一丝疑虑地知道，一个营收数字从何而来，或者当日期范围变动时会发生什么。业务用户可以自己走一遍流程，修正智能体误解业务逻辑的步骤。他们可以更有信心地把自己的名字署在输出上。这种审计能力意味着真正意义上的护栏——人在回路中，是真正处于回路之中，而不是对一个智能体黑箱默许地点头。

在一个受治理的平台内运行这套流程（按有人监控的排期、在既有访问控制之下），可以让工作队列持续消化，同时不失去对数据出口的监督。当受治理的路径同时也是最快的路径时，“影子电子表格”就会萎缩。

AI已经来了，自服务AI终将向业务用户开放。但我们不要重复前几波自服务浪潮的错误。桌面工具把工作流构建分散到上千台机器上，带来了数据孤岛和长达十年的技术债。在这个时代，让我们把信任和治理做对。

接下来的事情，不是靠又一轮模型基准测试就能解决的。有六倍于工程同行的人，正站在他们身后一步的位置，而工程同行早已获得了阶跃式的生产力提升。用可审查的AI工作把这些用户连接到真实数据上，分析积压就会消失。