• 有人问：都用 AI 做分析了，企业怎么还没有数仓？

• 有人提醒：正规的 ERP 不应该随意直连数据库。

• 也有人觉得，中间表太麻烦，给 AI 一个表级只读权限不就行了？

这些问题都很专业，但它们讨论的层面并不完全一样。数仓解决的是经营分析的数据体系；ERP 接口讨论的是系统边界；表级只读控制的是写入权限。可一旦 AI 要进入 ERP 查询数据，企业最终面对的是一个更具体的管理问题：

在现有条件下，这是不是一次可以被授权、被约束、被追责的数据访问？

其实，AI直连ERP数据库不是一种常规的架构方案：ERP系统才是数据库操作的大管家，在正常情况下，数据库应该都隐藏在ERP之后面，对外部的系统应该是透明的。

因此，我的判断是：AI 直接查询 ERP 数据库，可以是一种权衡方案，但绝不是默认方案。至少要同时满足下面五个前提。

1. ERP 未开放 API 或 CLI，或开放能力不足以支撑目标业务场景

企业第一步不该问“数据库能不能连”，而应该先盘点：ERP 现有的官方能力，到底能不能解决业务问题。

如果 ERP 已经有 API、CLI、报表接口或受控导出能力，并且能满足需求，优先走这些路径。它们通常更符合 ERP 原本的权限、业务规则和升级维护方式。

但现实中，确实会有一些例外。比如，有些本地部署多年的 ERP 没有开放接口；有些接口只能查单张单据，无法支持跨订单、库存、采购、生产等模块的关联查询；还有些接口字段不全、调用频率有限，无法支撑业务人员每天重复进行的查询。

这时，数据库查询才可能被摆到桌面上， 但“没有 API”还不够。企业需要把缺口说具体。

是缺字段？缺跨模块关联？缺实时性？还是业务人员每天要反复导出几个报表，再手工拼成一张经营分析表？

这些问题越明确，后续的方案才越能收敛， 如果需求只是“让 AI 看看 ERP 里有什么问题”，那就不适合直连。这个目标太大，也无法验收。

我想更合格的表述应该是：

• • 每天找出未来 14 天可能延期交货的订单；
• • 汇总缺料、采购未到、生产未完工导致的库存风险；
• • 让业务员快速查询某客户近期订单、退货、应收和交期异常；
• • 把运营人员每天重复导出、合并、核对的数据工作交给 AI 完成。

接口能力不足，是 AI 直连 ERP 的第一个前提。

它解决的是“为什么有必要”的问题，没有必要性，再安全的技术方案也不值得投入。

2. ERP 为本地部署，且存在经授权、可审计的访问入口

第二个前提，讨论的是企业有没有能力控制这个入口。

本地部署的 ERP，通常意味着企业对网络、数据库、账号和访问路径有更多控制权。可这并不等于“数据库在自己手里，就可以随便开放”。

这里要区分两件事：

一件是技术上能不能访问。

数据库账号能否登录？网络能否打通？AI 所在的服务能否连到数据库？

另一件是管理上是否允许访问。

谁批准了这次访问？AI 用哪个身份访问？能查哪些内容？操作记录保存在哪里？出了问题由谁处理？

很多项目的风险，恰恰出现在后者。

一个数据库账号交给程序后，往往很快就失去可见性。业务部门不知道它查过什么，IT 不知道它为什么查，管理者也无法判断它是否超出了最初的业务范围。

这不是 AI 的问题，而是入口没有被治理。

所以，能进入下一步的访问入口，至少应该满足：

• • 有明确的授权主体；
• • 有独立的访问账号或服务身份；
• • 有网络隔离和访问来源限制；
• • 有完整的查询日志；
• • 有撤销权限和停止服务的能力。

可以把它理解成一扇门。门能打开不重要，重要的是谁拿钥匙、什么时候开、进去了做什么，能不能留下记录。

如果这些都说不清，AI 访问 ERP 数据库就不该进入生产环境。

3. 业务确有高频、明确的查询或取数需求，人工导数成本已成为问题

有些团队一谈 AI，就容易从“让它看看数据”开始，但是，这类需求听上去很有想象空间，落地时往往最容易失控。

因为 AI 一旦面对全量 ERP 数据，首先遇到的不是能力不足，而是业务问题不清楚：它该看哪些表？按什么口径判断？结果交给谁？结果出来后要做什么？

我坚定认为，真正值得投入的场景，通常有三个特征。

第一，足够高频。

每天、每周，或者每一个业务节点都会重复发生。它不是偶尔查一次数据，而是持续消耗人力。

第二，足够明确。

业务人员能说清楚：要查什么对象、哪些字段、什么时间范围、什么判断规则。

第三，人工成本已经显性化。

运营每天导数、合表、核对；业务经理在多个系统之间来回确认；管理者拿到数据时，已经错过了处理窗口。

例如，“查询待交订单”仍然偏宽泛。但如果改成“每天上午 9 点，筛选未来 7 天交期内、库存不足且采购在途未覆盖的订单，并按仓库和负责人汇总”，这个需求就开始具备可落地性。

它有输入，有规则，有输出，也能定义谁来接收和处理。AI 在这里承担的，不是自由浏览 ERP，而是完成一项边界清楚的数据查询工作。

这也是我更建议企业采取的起步方式：先让 AI 稳定解决一类重复出现的业务问题，再考虑扩大它的访问范围，不要一开始就给它整个 ERP。

4. AI 访问的是受控查询入口

即使前面三个条件都满足，也不意味着 AI 可以直接查询生产库里的任意表。这是最容易被忽视的一步，很多人会说：给只读权限不就行了吗？

我觉得话说对了一半，尽管只读权限确实能降低“改数据”的风险，但它解决不了另外几类问题：

• • AI 会不会看到不该看的客户、成本或财务字段？
• • 会不会因为错误关联，把数据解释错？
• • 会不会执行大范围查询，把 ERP 性能拖慢？
• • 会不会把敏感结果带到不该出现的对话、群聊或文档中？
• • 当业务规则变化时，AI 是否还能理解原来的查询逻辑？

所以，企业真正要控制的，不只是“有没有数据库账号”，还包括“AI 通过什么入口看见哪些业务事实”。

推荐的访问顺序可以是：

• 如果企业已经有数仓或经过治理的数据集市，AI 优先进入这些分析层。

• 如果数仓尚未覆盖某个业务场景，也可以考虑只读副本、数据库视图或专题数据集。

• 中间表也可以用，但它的价值不只是“复制数据”，更适合当成一份数据合同，提前明确：

• • AI 可以查询哪些业务对象；
• • 哪些字段允许暴露；
• • 指标按什么口径计算；
• • 数据多久更新一次；
• • 异常数据如何标记；
• • 业务规则变更后谁维护。

给个例子，一个交期风险 Agent，不需要看到全部 ERP 表。

它可能只需要订单、可用库存、采购在途、生产计划和客户优先级等有限数据。复杂关联和口径计算，可以先固化在视图或专题数据集中，再交给 AI 调用。

这样做会多一些前期设计，却能显著减少后续维护成本。

AI 的自然语言请求，也不该直接等同于一条可以自由执行的 SQL。

更稳妥的做法是：让 AI 调用被限制好的查询工具、视图或参数化模板。

它负责理解问题、选择工具、解释结果，数据库负责执行受控查询。

5. 查询范围、字段脱敏、性能限制、操作日志和人工接管责任均已定义

第五个前提，决定了这个方案能不能从 Demo 走到生产。

很多 Demo 看起来都很顺：AI 能查订单、能看库存、能回答问题。

但一旦业务人员真的开始依赖它，问题就会马上出现：

• • 不同角色看到的数据是否一样？
• • 成本、报价、客户联系方式能不能暴露？
• • 查询高峰期会不会影响 ERP 正常业务？
• • AI 回答错了，谁来修正？
• • AI 发现风险后，谁负责处理？
• • 处理过程有没有留痕？

查询范围

AI 允许查哪些视图、表、组织、仓库、客户和时间范围？

不同岗位的可见范围不同，不能因为 AI 能查，就把所有数据都交给所有人。

字段脱敏

成本、底价、客户联系方式、员工信息、财务数据，哪些字段必须脱敏，哪些字段根本不应该进入 AI 的上下文？

“能查”与“能展示”是两回事。

性能限制

要限制查询频率、返回行数、超时时间和高峰时段。

ERP 是交易系统。订单录入、库存扣减、生产排程都依赖它。AI 查询再有价值，也不能影响一线业务正常运行。

操作日志

谁问了什么问题？AI 实际调用了哪个查询？用了什么过滤条件？结果返回给了谁？

这些都应该保留记录。

日志的意义不只是安全审计。后续发现回答不准确时，团队才能回到原始查询、字段口径和业务规则上定位问题。

人工接管

AI 查询失败、结果不确定、发现异常，或者涉及后续业务动作时，谁来接？这一步非常适合放到飞书里完成。

AI 可以把异常整理成待办，推送给对应负责人；负责人在飞书确认、补充原因、提交审批；处理过程留在任务、审批或多维表格中。

飞书在这里承担的角色，不是复制一套 ERP 数据，而是把 AI 无法独自承担的责任接回来。

尤其当结果涉及订单调整、库存处置、价格变更、采购决策或财务动作时，AI 可以提出建议、创建待办、生成审批材料，但不应该直接修改 ERP 核心数据。

当然，写回动作仍应走 ERP 原有的业务接口和审批链路。

五个前提，缺一个都别急着直连

如果企业正在评估 AI 查询 ERP 数据，可以先对照下面这张表。

这五项不是打分题，并非满足三项就可以先跑起来。

只要权限、审计、性能限制或人工接管有一项缺失，风险就会落到实际业务人员身上。

AI 直连 ERP，真正需要避免的，不是多建一张中间表，而是真真实实地少了一段责任。

当企业把业务需求、数据入口、查询范围、权限边界和人工接管都定义清楚后，AI 才有机会从一个“会查数据的聊天框”，变成真正能帮助团队处理业务问题的助手。

你们企业的 ERP，目前最卡的是接口能力、数据口径，还是权限与责任边界？欢迎留言说说具体场景。

阅读原文：点击这里