不换ERP也能上AI：查数、分析、代办业务实战

上周一位做精密制造的朋友跟我聊了近一个小时，核心就一句话：公司用了十多年的ERP，老板最近天天在问，AI能不能直接从系统里把数据要出来。他的困境很有代表性——流程单据全在老系统里，历史数据动不得，换套系统又得按年算周期，风险大到没人敢拍板。我给他的回答也很直接：换不换ERP不是关键，真正要解决的是怎么让AI和存量ERP系统协作。

这篇文章就是我帮多家制造、贸易、服务类企业做"存量ERP+AI"落地时的经验整理，专门聊三件事：让AI查询数据、让AI分析经营、让AI代办业务。内容偏实操，会给出账号权限、查询视图、Python连接Oracle的脚本、指标字典模板、Agent代办业务的边界设计，以及实施过程里最容易踩的几个坑。适合正在做ERP智能化改造的技术负责人、实施顾问，以及准备给业务管理层提方案的CIO们参考。

1. 先想明白：不换ERP，到底是想解决什么问题

很多企业陷入一个误区：老板看到同行上了新系统，第一反应是自己的ERP太老，得换。但真去梳理需求会发现，老板要的往往不是"新ERP"，而是"快速从数据里拿到答案"。

1.1 老板要的不是新系统，是"从数据到答案"的效率

以制造企业为例，ERP里通常有销售订单、采购、生产工单、库存、财务等模块，跑十几年下来，历史数据积累了几百GB，业务流程被审批流、权限矩阵、单据模板绑得死死的。换系统意味着重新规划物料编码和客户主数据、迁移历史数据、全员重新培训，实施周期基本是按年算的。

但老板的实际诉求往往是即时性的——"这个月哪些产品毛利下降了""某客户回款怎么一直拖着""华东仓和华南仓哪个周转更慢"。传统做法是打开ERP，找到对应报表，手动筛选，导出Excel，再自己算一轮，快的半小时，慢的半天。遇到跨模块的问题（比如销售毛利要关联订单、成本、回款三块数据），经常要拉好几个部门的Excel才能拼出来。

AI能压缩的恰恰是"从问题到答案"这段路。它不需要替代ERP的流程引擎，只需要读懂ERP里的数据，并把它转化成业务人员能直接看懂的结论。这里有个关键认知要摆正：ERP负责"记录和流程"，AI负责"理解和反馈"，两者是叠加关系，不是替代关系。如果流程本身是乱的，AI帮不上忙；但如果流程是顺的、只是要数太难，AI就有巨大发挥空间。

1.2 AI与存量ERP的分工边界，以及一个先决条件

为了讲清楚这种叠加关系，我一般用下面这张表跟企业方对齐预期：

这个边界想清楚之后，落地方案才有骨架。还有一个先决条件必须提醒：数据质量体检。如果客户主数据一塌糊涂、物料编码重复率超过10%、同一个字段被不同部门塞了不同含义，AI再聪明也查不对——它只是把脏数据更快地翻出来而已。所以启动AI项目前，至少要做一轮数据质量评估，重点看重复、空值、口径漂移这三类问题。这个步骤省不得，后面所有环节都建立在它之上。

2. 让AI查数：从只读账号到自然语言SQL的完整链路

查询数据是整个项目里最容易快速见效、也最容易翻车的环节。翻车的原因通常不是AI不够聪明，而是给了AI过大的数据库权限，或者让它直接面对几百张结构复杂的业务表。

2.1 优先建只读账号和视图层，不要让AI直连生产核心表

这条必须放在最前面。实践中有项目直接给大模型配了一个生产库的读写账号，结果AI生成的SQL出现全表扫描，甚至有误操作风险。正确做法是在数据库里单独创建一个只读账号，只授予查询视图的权限，不碰业务原始表和事务数据。

CREATE USER ai_query IDENTIFIED BY "safe_password"; GRANT CONNECT, CREATE SESSION TO ai_query; GRANT SELECT ON reporting.v_sales_order TO ai_query; GRANT SELECT ON reporting.v_inventory_balance TO ai_query; GRANT SELECT ON reporting.v_ar_aging TO ai_query;

为什么一定要通过视图而不是直接授权表？三方面考虑。第一，视图可以提前过滤敏感列，比如成本明细、折扣底线、个人薪资这些不该让AI回答的内容，直接在视图层拿掉。第二，可以在视图里统一字段命名，把ERP原本的拼音缩写或英文缩写转换成业务术语（比如把AR_BAL字段命名为应收余额），大幅降低AI理解门槛。第三，视图能限制查询范围，比如默认只允许查近三年的数据，避免AI在几十亿条历史数据上跑出灾难性查询。

2.2 自然语言转SQL的落地策略：先把20个高频查询固化成视图

Text2SQL听起来很美好，但直接让AI对着几百张表生成SQL就是灾难：表名缩写看不懂、同名字段一抓一把、连表关系复杂到连老实施顾问都要想半天。我的经验是：不要追求让AI直接理解全集，而是梳理出业务高频查询场景，前20个左右，每个场景对应一个视图或一个参数化查询，让AI在受控范围内把问句翻译成对标准视图的查询。这个策略能把准确率从60%直接拉到90%以上。

这里给一套我常用的Prompt模板，供参考：

你是一个ERP数据查询助手。只能基于以下视图回答： - v_sales_order: 销售订单头与行，含客户、产品、数量、金额、区域、订单日期、交付日期 - v_inventory_balance: 库存余额，含物料编码、仓库、可用量、冻结量 - v_ar_aging: 应收账龄，含客户、账期区间、余额 任务规则： 1. 把用户问题翻译成SQL，字段名只能使用视图中存在的命名； 2. 问题如果涉及视图之外的字段，必须回答：暂无权限查询该数据； 3. 查询结果为空时，如实说明，禁止编造数据。 用户问：华东区上个月销售额是多少？

注意最后两条规则很重要。模型在自由对话中习惯了"有问必答"，但在数据分析场景里，"查不到就说查不到"比硬编答案安全得多。你要在Prompt里明确授权AI拒绝回答。

2.3 Python连接Oracle的实操脚本：从cx_Oracle到python-oracledb

热词里有个"python连接oracle查询数据"，实践中很多项目的查询中间层就是Python写的。早期大家习惯用cx_Oracle，但Oracle官方已经停止cx_Oracle的新功能开发，转向了python-oracledb。这个库有个很友好的特性：支持thin模式，不需要额外安装Oracle客户端，一台装了Python的机器就能直连数据库，部署成本低很多。

下面是我在中间层里实际跑过的脚本骨架：

import oracledb conn = oracledb.connect(user="ai_query", password="safe_password", dsn="192.168.1.10:1521/ORCL") cur = conn.cursor() sql = """ SELECT region, SUM(order_amount) AS total_amount FROM reporting.v_sales_order WHERE order_date >= TO_DATE(:start_date, 'YYYY-MM-DD') GROUP BY region """ cur.execute(sql, start_date="2025-01-01") for row in cur: print(row) cur.close() conn.close()

这脚本看着简单，但有个容易被忽略的点：绑定变量。AI生成的SQL在执行前一定要做参数化改写，不能直接把字符串拼进语句里。这样一方面降低SQL注入风险，另一方面也方便做查询缓存——同样参数的查询可以直接命中缓存，减少数据库压力。开发过程中我见过太多团队图省事把AI生成的SQL当纯字符串执行，结果一个"客户名里带单引号"的问题就能让查询服务崩掉。

2.4 查询性能与缓存：别让AI把生产库压垮

ERP白天业务高并发，AI查询如果不加限制，几个大查询就能把生产库拖慢。我见过一个案例，AI生成的查询在几千万行的订单明细表上做全表扫描，直接把数据库CPU打到90%，前台开单都卡了。从那以后我定了一条铁律：AI查询链路必须有三道闸。

第一道闸是查询副本。优先连接只读备库或独立的数据仓库，而不是生产主库。如果公司没有备库，至少要把AI查询限定在视图层，并设置数据库资源组限制CPU和IO。第二道闸是超时熔断。在查询中间层设置合理的超时时间，我一般用10秒，超过就自动取消SQL并提示用户"查询太复杂，请换个更具体的问法"。第三道闸是行数限制。自动在SQL末尾追加FETCH FIRST 200 ROWS ONLY或Oracle的ROWNUM限制，防止一次性返回几十万行打爆内存。

缓存这层也值得做。同一类问题（语义相近，参数相同）在5分钟内直接命中缓存，重复查询不再打到数据库。用Python写一个带过期时间的字典或接入Redis都很简单，但对ERP库的减压效果非常明显。

3. 让AI懂经营：指标口径和语义层建设才是不花冤枉钱的关键

查询数据做到位，AI已经能"回答"了。但"回答得对"和"分析得准"之间，隔着一道企业特有的坎——指标口径。这一章也是热词里"企业erp或crm产品的ontology"指向的核心：让机器理解业务流程里的词汇和关系。

3.1 先别搭知识图谱，先做一张指标字典

"本体论"或"ontology"这个词听起来很玄，很多团队一听就想着要建知识图谱、做实体关系标注，结果投入巨大、产出寥寥。我在实践里的判断是：对大多数企业来说，真正见效的是用Excel或Wiki做一张"指标字典"，它就是AI分析经营时的"翻译词典"。

这张表的价值在于：把业务语言和计算逻辑彻底显式化。比如"毛利率"这个指标，销售理解的毛利可能只扣出厂成本，财务理解的毛利要分摊制造费用和物流成本，两者算出来能差好几个点。指标字典里明确写明用什么口径，AI照着字典去算，结果才经得起业务人员的质疑。

3.2 指标口径的清洗与确认流程

指标字典不是IT团队关起门来写的，必须由业务部门确认。我的做法是召集财务、销售、生产、仓储各出一个人，花半天时间开"指标对齐会"，逐条过一遍高频指标。这个会虽然看起来不像技术活，但几乎所有AI经营分析项目的成败都会卡在这里。

开会时我习惯准备一张"指标确认单"，列这几项：

• 指标名称（业务叫法）
• 计算公式（可执行的数学表达式）
• 数据来源表/视图
• 适用范围（哪些部门用、哪些业务线用）
• 默认口径（AI回答时优先使用哪个）
• 口径变更时通知谁

会议结束一定要发会议纪要，标注"财务负责人确认XX指标口径为……"。这类确认记录后期既是AI的prompt素材，也是团队之间免扯皮的凭证。没有这步，AI上线后你就会被"这个数不对"淹没。

3.3 经营分析提示词与"分步确认"机制

让AI直接回答"分析一下上个月的经营情况"这种大问题，等于逼它胡说。我踩过这个坑，当时AI给了一堆看似合理的结论，仔细一核对，一半是编的。后来改成了"分步确认"机制，把分析任务拆成带检查点的小步骤：

任务是分析上月经营情况，按以下步骤执行： 第一步：列出该问题需要哪些指标，并说明每个指标的口径； 第二步：用只读视图查询上月数据，输出指标数值； 第三步：和上上月对比，找出变化最大的三项，给出变化幅度； 第四步：尝试归因，比如从客户、产品、区域维度下钻； 第五步：如果某个归因没有数据支撑，必须写明"数据不足，待确认"。

这个机制的好处是每一道都能检查。老板看到AI结论时，可以顺着步骤反向核查，而不是面对一个无法解释的最终答案。从工程角度看，也容易定位问题出在哪一步——是SQL错了、指标算错了还是归因逻辑有问题。

3.4 一个完整的经营分析案例

拿一个真实场景串一下。某制造企业老板问："华东区这个月订单交付及时率怎么下降了？"

• 第一步，AI从指标字典里找到定义：订单交付及时率等于按期交付订单数除以应交付订单数。
• 第二步，从reporting.v_sales_order视图查询华东区本月和上月数据，计算后得到本月80%、上月92%，下降12个百分点。
• 第三步，下钻到产品线，发现新款产品BOM准备时间过长，导致该产线订单大面积延期。
• 第四步，AI给出结论：华东区整体交付及时率下降主要由新款产品的物料齐套延迟造成，建议调整排产优先级。

整个过程从人工翻报表的两个小时压缩到两分钟。而且AI给的是"数据线索"，最终调整排产的决策仍然由人拍板。这个分工模式在管理层那里很容易通过，因为AI不再是"做决定"，而是"把依据摆到桌面"。

4. 让AI办事：Agent代办业务的安全边界与落地姿势

查询和分析都是只读操作，到了"办理业务"这一步，事情就变得敏感了，因为涉及到数据写入和流程推进。热词里"AI Agent"被点得很频繁，但企业场景里的Agent不能只会聊天，它必须能调用系统接口、生成单据、发起流程，同时不破坏现有治理结构。

4.1 三种操作模式与风险分级

我把AI代办分成三个级别：

大部分企业不要一上来就做L3。我见过最稳妥的路径是先把L1跑稳，让业务人员习惯用AI查数据；接着挑一个高频低险的L2场景（比如采购申请单草稿），让AI能真正"动手"而不越权；等信任建立了再谈自动化，那时候自然会有业务部门主动提需求。

4.2 Agent的落地架构：工具调用与接口封装

AI Agent要办理业务，靠的不是直接改数据库，而是调用ERP已有的业务接口。比如创建采购申请，就应该走ERP的WebService或REST API；填写销售订单，就要调用对应的单据新增接口。Agent的工作流程是：解析用户意图，选择工具，生成参数字段，调用接口，展示结果。

{ "name": "create_purchase_request", "description": "创建采购申请草稿，不提交审批", "parameters": { "type": "object", "properties": { "material_code": { "type": "string", "description": "物料编码" }, "quantity": { "type": "number", "description": "申请数量" }, "request_reason": { "type": "string", "description": "申请原因" } }, "required": ["material_code", "quantity"] } }

这个JSON Schema就是Function Calling里的"工具说明书"。模型看到用户说"帮我申请一下缺料的钢材"时，会解析出material_code=GC-001、quantity=5000、request_reason=库存低于安全阈值，然后填充到工具调用参数里。这个模式的关键点是"草稿"两个字：AI生成的申请单默认不提交，给用户留一个确认和修改的余地。这套"草稿代理"模式在企业的接受度非常高，因为它把AI放在了"助手"的位置，而不是"决策者"。

4.3 用工作流引擎兜底：AI出意图，系统走流程

实际执行层面，不要把AI和审批引擎耦合得太深。推荐架构是：AI负责生成"建议动作"（填写申请单、推荐审批人、计算采购数量），真正的单据流转、审批规则、会签逻辑仍然由现有工作流引擎控制。AI的产出物写在业务表的一个"AI建议备注"字段里，而不是直接进入正式单据。

拿采购申请举例。采购员对AI说"帮我申请一下缺料的原材料"，AI解析后生成一张采购申请草稿，备注栏自动带出"由AI根据库存阈值建议，数量仅供参考"。采购员确认后点提交，单据转入原有审批流，后续照旧。这样即使AI建议错了，也会被人工拦截在草稿阶段。这套设计的核心是把AI当"副驾"而不是"司机"，方向盘始终在业务人员手里。

4.4 权限、审计与并发控制

办理业务环节最容易被忽视的是权限体系。这里有一个必须记住的原则：AI的操作权限不能超过使用者的权限。也就是说，AI调用接口时必须带当前登录用户的身份，ERP侧按照该用户的角色控制数据可见性和操作权限。绝不能给AI一个"系统管理员"身份去操作所有单据，那种做法等于给每个员工配了一把万能钥匙。

审计日志要记录完整链路：谁在什么时间通过AI执行了什么动作、AI生成的关键参数是什么、用户有没有修改、最终有没有提交。我把这种日志称为"AI指纹"，出问题的时候可以精确追溯到AI参数、用户行为和系统结果三层。并发方面，AI批量提交时要特别注意锁冲突和重复提交。通常做法是接口加幂等键（唯一请求号），防止AI重试导致重复单据——这个错误我见过不止一次，AI网络超时后自动重试，结果一张采购单在系统里被创建了三遍。

5. 落地前绕不开的四个大坑：数据地图、模型幻觉、口径扯皮、评估节奏

这一章是给准备动手的团队看的。前面讲了不少方法和技能，但真正决定项目成败的，往往是实施过程中暴露的"非技术问题"。

5.1 第一个坑：连数据在哪都不知道

很多企业启动AI项目后的第一周，全都在"考古"——查这个字段是什么意思、那个表和哪个表怎么关联。我曾经遇到一个客户，财务说要查"应收余额"，结果数据散在三套表里，命名分别是AR_BAL、YSZK_YE、receivable_bal，三个不同部门维护，数据还不一致。这种情况不能怪AI，它确实不知道该信谁。

建议在项目启动前花一到两周做一张"数据地图"，用Excel就行。列出每个核心字段的业务含义、所属模块、负责人、质量状态。这张图后续既是AI做字段理解的素材，也是指标字典的基础，更是中间层SQL改写规则的来源。没有这张图，后面的工作都像在打盲牌，今天问一个人搞清一个字段，明天再问另一个人，效率极低。

5.2 第二个坑：AI一本正经地胡说八道

大模型的幻觉在经营分析场景同样会出现：它可能编一个不存在的客户名，算一个根本没有的增长率，甚至把两个不相关的表拼在一起"推导"出结论。解决思路有三层：

• 让AI只能查询白名单视图，查不到就明确说"查不到"，并且把这条规则写进Prompt。
• 在中间层对SQL结果做自动校验，比如空值检查、波动检查。如果某个指标环比波动超过100%，系统自动标红提醒，不允许AI直接输出。
• 要求AI在给出结论时附上取数范围和计算口径，比如"本数据来自v_sales_order，区间为2025年3月1日至3月31日"，便于人工复核。

根据我的经验，"允许AI说查不到"这条最简单也最有效。它直接切断了AI编造数据的动力。

5.3 第三个坑：同一个指标，三个部门三个口径

再强调一遍，"回款"这个词，销售认为是客户实际付款，财务认为是应收账款核销，老板觉得是现金流到账。如果AI用销售口径查出来给老板看，老板一定骂数据不对。这不是AI的问题，是企业内部一直存在的"口径之争"被AI放大了。

破解方法就是前面说的"指标对齐会"。把口径冲突的指标列成一张"争议清单"，会上逐个裁定，会后归档作为指标字典的正式内容。这里有个实践技巧：会议纪要一定要发给财务负责人做书面确认，否则到了下次复盘又会有人翻案。

5.4 第四个坑：想一步到位，结果连第一个Demo都跑不出来

我见过不少项目死在"贪多"上。一上来就规划采购、销售、库存、财务四大模块全覆盖，光指标对齐全就用了三个月，Demo连影子都没有。建议的做法是选一个"三好"模块启动：商业价值最高、数据质量最好、流程最标准化。销售订单查询与毛利分析通常是最理想的第一站，因为销售数据相对干净，毛利又是老板最关心的指标。

评估维度建议用四块：查询准确率、业务办理成功率、用户采纳率、平均响应时间。先定一个能接受的下限，比如"准确率80%以上、用户每周至少用三次"，跑两个月再复盘。从我的经验看，从单模块跑通、建立完整链路（视图到指标到Prompt到Agent到审计），再复制到其他模块，是阻力最小的路径。把这个顺序反过来，项目大概率会死在演示阶段。

最后聊一点个人体会。AI项目上线只是开始，真正的难点在持续维护。我每次做这类项目都会给客户留下一套"黄金测试集"：把业务里最重要的五十到一百个场景写成问答对，每个版本改动之后跑一遍回归测试。这套测试集加上前面说的指标字典，是AI在ERP里保持稳定输出的两个支点。守住这两条底线，AI就会从"新鲜玩具"慢慢变成业务离不开的基础设施。