去年年底我们集团数字化例会上老板指着大屏问这个 ERP 里攒了十年业务数据能不能让 AI 直接告诉我上个月哪个产品线毛利下滑了销售总监在旁边补了一句最好还能帮我查一下某个客户回款到没到别每次都让财务导 Excel。我当时第一反应是换一套自带 AI 能力的 ERP 算了。但认真把账算完之后我彻底打消了这个念头。换 ERP 的成本远超一般人的想象——不只是软件许可费还有历史数据迁移、接口重写、全公司用户培训、业务流程重新梳理稍有不慎就是半年到一年的业务动荡。而我们真正想要的其实不是换一个系统而是让现有系统里的数据能被 AI 用起来查得到、分析得了、还能替人办点标准业务。这篇就把我们完整跑通的一套方法整理出来不换 ERP如何让 AI 查询数据、分析经营并办理业务。整套思路的核心是让 AI Agent 成为 ERP 的“外脑”——通过 API 和只读数据通道接入而不是动不动就动 ERP 的筋骨。无论你用的是金蝶、用友、鼎捷还是其他国产 ERP只要系统有接口、数据库能读出来这套方法基本都可以复用。1. 先算一笔账为什么“不换 ERP”才是大多数企业的最优解1.1 换系统的真实成本远不止软件费用很多企业一听说“ERP 不支持 AI”第一反应就是换系统。但换 ERP 的真实成本往往要在项目启动后才会逐渐暴露出来。第一块是历史数据。十年的采购、销售、库存、财务数据分散在几十张表里很多表甚至没有规范的外键关联。把这些数据清洗、映射、迁到新系统按我们经历过的项目估算单这一项的工作量就可能占整个项目周期的四成以上。第二块是周边系统。老的 ERP 往往接了十几个外部系统OA 审批流、MES 报工、CRM 客户资料、电子发票平台、银行银企直连。其中很多接口已经运行了七八年接口文档可能都丢了全靠当年的实施顾问脑子里记着。换 ERP 意味着这些接口全部重写每一条都可能踩坑。第三块是隐性成本——员工习惯。业务人员已经在老界面上形成了肌肉记忆财务月末结账的节奏、仓库盘点的时间窗口全都是按老系统的逻辑设计的。换个系统哪怕是公认好用的新平台至少也要三个月到半年的适应期。这个适应期里业务效率短暂下降几乎不可避免。所以当“AI 能力”成为新诉求时最理性的选择通常不是换系统而是让 AI 适配旧系统。旧 ERP 的核心价值——稳定的业务闭环、完整的历史数据、成熟的审批流——依然存在缺的只是一层“聪明的接口”。1.2 画清楚边界什么留在 ERP什么交给 AI 外脑不换 ERP意味着我们要先明确职责边界。ERP 本身继续承担它最擅长的事单据处理、库存扣减、财务记账、审批流转。这些事讲究严谨和可追溯不能有半点模糊。AI 外脑则负责三类事情。第一类是查询类帮业务人员用自然语言问数据不用记报表编号、不用懂 SQL。第二类是分析类把查询到的数据进一步加工做趋势对比、异常定位、归因分析。第三类是办理类帮用户完成标准化操作比如创建采购申请单、录入销售订单。这类操作要有明确的规则和权限边界后面我会专门讲怎么做得安全。这里有一个很重要的认知AI 不是要把 ERP 替换掉而是像给老房子装了一套智能家居中控——窗帘还是那副窗帘灯还是那些灯但你可以用语音命令统一控制它们。老房子的管道不用拆中控只需要接上每个房间的开关就行。2. 长在 ERP 边上的 AI 助手整体架构怎么摆2.1 不侵入的接入方式OpenAPI、只读库、消息事件这一层是整个方案的“地基”决定你能让 AI 做什么、不能做什么。我按实际可靠程度把接入方式排了个序供你参考。接入方式能做什么风险等级适用场景ERP 官方 OpenAPI / SDK查询数据、创建单据、读取审批流低首选方式金蝶、用友、鼎捷都提供只读数据库副本从库或数据仓库任意历史数据查询、分析低查询和分析为主配合语义层使用消息事件如 ERP 触发 Webhook监听单据变更、实时通知中做实时提醒如回款到账通知RPA 模拟操作界面能查能填但脆高实在没有 API 时的兜底方案不推荐做核心链路我强烈建议优先确认 ERP 的 OpenAPI 覆盖度。以鼎捷为例它的 OpenAPI 体系支持按单据类型查询与创建金蝶云星空也提供了标准 WebAPI可以覆盖绝大多数查询和部分单据操作用友的 U8 Cloud 和 YonBIP 同样有开放平台。如果你的 ERP 版本比较老没有开放平台那么优先找实施厂商要数据库视图或中间表用只读账号接入而不是一上来就上 RPA。为什么不推荐 RPA 作为首选因为 RPA 本质是模拟人操作界面任何界面改版、网络慢、弹窗异常都会导致脚本挂掉。企业业务最怕的就是“静默失败”——表面上看操作成功了实际单据没有生成。API 调用则不同成功失败有明确的状态码和日志出错能立刻发现。2.2 AI Agent 的内部结构意图识别、工具调用、记忆与上下文接入层打通后就要设计 AI Agent 的内部结构。我的经验是不要把 Agent 当成一个“黑盒子”而是拆成四个清晰的部分。意图识别模块负责判断用户想问什么。比如“查一下上个月华东区的回款”和“帮我看看华东区回款怎么下降了”一个是查询一个是分析背后的处理逻辑完全不同。这里可以是基于大模型的自然语言分类也可以用规则加小模型的方式实现关键在于稳定。工具调用模块是 AI 与 ERP 之间的桥梁。大模型不会直接连数据库而是通过“函数调用”Function Calling来使用一系列预先定义好的工具。例如定义一个get_sales_retrieval(region, time_range, metric)工具AI 会把用户的自然语言自动翻译成这个函数的入参然后执行调用。工具定义的好坏直接决定了 AI 的可用性。记忆与上下文模块解决“多轮对话”的问题。用户说“上个月的数据呢”AI 需要记住“上个月”指的是对话历史里的华东区回款场景。这里需要维护一个短时记忆比如把最近 5 轮对话的关键参数保存为结构化变量还要维护一个长时记忆比如用户偏好的分析维度。权限控制模块是最容易被忽略但最重要的部分。它决定 AI 能查哪些数据、能执行哪些操作。后面业务办理部分我会详细展开这里的核心原则是AI 永远不能拥有比提问者更高的权限。2.3 分层设计每一层都可以独立替换整套架构我建议按四层来设计交互层承接用户的自然语言输入输出回答和报表。AI 层大模型加业务规则引擎负责任务拆解和工具调度。连接层语义映射、API 适配、数据清洗。这是最花功夫的一层。ERP 层现有的金蝶、用友、鼎捷或其他系统保持不动。分层的最大好处是后续如果更换大模型供应商、调整提示词策略甚至从云端模型迁移到本地部署都只需要改 AI 层如果 ERP 升级了 OpenAPI 版本只需要改连接层的适配器。我们实际运行中改过一次模型供应商当时只花了半天时间替换调用接口业务完全无感这就是分层带来的收益。3. 第一步先打通“数据查询”让 AI 学会读 ERP 的表和数据3.1 建一个语义层把 ERP 的表结构翻译成业务语言很多 ERP 数据查询项目失败不是 AI 不行而是语义层没建好。ERP 表结构是为业务逻辑设计的不是为自然语言设计的。比如销售出库单在数据库里可能叫SEOUT表里还有一堆代码字段CSTNUM客户编号、PLIST价目表、SALUNIT销售单位。如果你直接让大模型对着一堆表名字段名做 SQL它大概率会蒙。所以第一步是建立语义层——一张“业务词汇表”和“指标定义表”。我们当时做了一张映射表把常见业务问题里的词汇映射到 API 参数或数据库字段上。用户可能问的词标准指标对应 ERP 查询口径卖了多少 / 出库数 / 销量销售出库数量SUM(出库单数量)排除退货单回款 / 到账回款金额收款单核销金额按收款日期统计欠款 / 应收余额应收账款余额应收发生额减核销额按截至日期计算库存够不够 / 库存水平可用库存实时库存减锁定库存映射表建好之后AI 的所有查询都走这个语义层而不是直接访问原始表。这样既保证了业务口径统一又避免了 AI 在几十个相似字段之间猜来猜去。3.2 自然语言转查询为什么我坚持不用“直接生成 SQL”市面上的方案里有一种做法是让大模型直接生成 SQL 查询数据库这叫 NL2SQL。听起来很酷但我实际用下来风险非常大。ERP 的数据库是核心系统如果有大量临时生成的 SQL 直接打到主库上一旦出现一个全表扫描的查询整个 ERP 性能都会受影响。更别提如果模型生成了一条带删除条件的 UPDATE 语句后果不堪设想。所以我们的实现思路是NL2API——让大模型理解用户意图然后把查询动作映射到预先封装好的 API 调用上。SQL 只出现在固定封装好的查询函数内部由开发人员手工控制不会让模型自己拼。比如我们定义了一个query_sales_summary(company, start_date, end_date, dimension, metric)的函数底层 SQL 是写死的只允许传参数。模型的工作是“把自然语言翻译成参数”而不是“写 SQL”。这样做有两个好处。第一是安全模型永远接触不到原始 SQL也就不会出现误操作。第二是性能可控底层 SQL 经过 DBA 审查和优化走索引、限制扫描行数稳定性有保障。3.3 一段可参考的查询链路设计一个典型的查询请求在我们系统里会完整走一遍这样的链路用户提问“上个月华东区的回款是多少”AI 先做意图识别判定这是一个“时间 区域 指标”的查询请求。参数抽取模块提取语义参数时间范围上个月、区域华东区、指标回款金额。权限校验模块检查当前用户的组织归属。如果用户不属于华东区直接拒绝。参数标准模块把“上个月”转换为具体的起止日期把“华东区”映射为 ERP 中的销售组织代码。调用query_receivable_collection这个封装好的 API传入转换后的参数。拿到 ERP 的返回结果后再由大模型组织成自然语言答案附上数据来源。这一步看起来简单但每一步都可能出问题。比如“上个月”到底是自然月的 1 号到月底还是财务月有的企业财务月是上月 26 号到本月 25 号。我们当时把这类规则全部预置在参数标准模块里不做成“模型自己理解”而是按企业财务日历精确计算。宁可多写几行规则代码也不要让 AI 去猜。4. 第二步再上“经营分析”AI 得能讲清数据背后的业务原因4.1 从“取数”到“分析”先定义指标体系和归因逻辑查询解决的是“是什么”分析要回答“为什么”。这一步的门槛比大部分人想象的要高。我们一开始踩过一个典型的坑老板问“上个月利润为什么降了”我们让 AI 去查利润表然后输出“利润比上月下降 10%”就完了。老板非常不满意说“我知道降了我问的是为什么”。后来我们意识到分析必须建立在指标体系之上而且要有归因逻辑。我们重新设计了整个分析流程先从 ERP 中拉取核心指标数据营业收入、销售成本、期间费用、毛利率、库存周转天数、应收账款周转率。对每个核心指标预置一个归因逻辑。比如毛利下降可能的原因包括销量下降、单价下调、原材料成本上升、产品结构变化。让 AI 调用额外的查询工具去逐项验证这些假设。比如要验证“原材料成本上升”需要调用 BOM 材料成本查询要验证“产品结构变化”需要调用品类销售占比查询。最后 AI 才能输出一份有依据的分析结论而不是凭空推测。4.2 给 AI 一整套“分析工具”而不是让它自由发挥很多人以为让 AI 做分析就是让它“看着数据自由发挥”。这是一个严重的误解。大模型擅长的是归纳总结但如果你没有给它结构化的分析路径它很容易给出听起来有道理但实际经不起推敲的结论。我们的做法是给 AI 预设一组分析动作让它像查案一样按步骤走。比如毛利率下降时的归因流程第一步调用get_profit_margin_trend(period)确认毛利降幅和趋势。第二步调用get_sales_by_product_category(period)检查品类结构变化。第三步调用get_cost_structure(period)检查材料、人工、制造费用占比变化。第四步调用get_price_volume_analysis(period)检查是降价还是销量下滑。AI 每调用一个工具都会产生一个中间结果。这些中间结果组合在一起才构成分析的证据链。这套证据链的思路跟审计很像——结论要有依据依据要能追溯。我们用几周时间把常见的分析场景都预设好销售波动分析、库存积压分析、应收逾期分析、成本异常分析。每个场景都有独立的人写归因逻辑然后封装成 Agent 可调用的分析模块。一旦场景覆盖到一定程度AI 的分析能力其实非常接近一个中级的业务分析师。4.3 分析报告的交付日报、周报、会议摘要一次生成分析做完之后另一个关键问题是交付形态。我们发现如果只是把分析结果直接回给提问人价值有限有价值的做法是把分析结果沉淀为结构化报告。我们在系统里做了一套模板引擎AI 每次完成分析后会按模板生成一份包含以下内容的报告核心指标摘要数据概览用简洁的表格展示环比、同比。异常发现列出 2~3 个最值得关注的异常点并给出异常方向。原因分析每个异常点附带归因逻辑和证据数据。建议动作基于归因结果生成可执行的下一步建议比如“华东区大客户订单延迟导致出货量下滑建议跟进销售订单交付进度”。这套报告现在成了我们每周经营例会的输入材料。以前经营分析需要财务部门三个人忙一整天现在 AI 半小时跑完财务同事只需要复核结论、补充业务判断。这不只是效率提升更是把财务从“做报表”解放到“做管理”的重要一步。5. 第三步业务办理AI 下单、审批、改单据的安全姿势5.1 写操作的风险边界AI 到底能不能碰 ERP 里的单据这是整个项目里争议最大的部分。让 AI 查询数据大家普遍能接受但让 AI 创建采购单、录入销售订单每个人都会问一句万一它搞错了怎么办我的答案是AI 可以碰单据但必须有边界、有兜底、有审计。核心原则有三条第一AI 只能做“发起”不能做“放行”。创建采购申请单是可以的但审批通过必须走原有的审批流而且审批人一定要看到单据上的“由 AI 根据 XX 需求生成”的标识。第二写操作前必须做强制规则校验。金额上限、供应商黑名单、数量合理性这些都应该在 AI 调用 API 前用规则引擎过滤一遍不能依赖模型自觉。第三任何写操作都要产生完整的操作日志。5.2 落地模式草稿确认 审批流 防重防误我们把业务办理设计成了三种模式风险逐级递增模式一草稿模式推荐首选。AI 根据用户指令生成完整的单据草稿展示给用户确认用户点击确认后AI 才调用 API 写入 ERP。这个模式适合初期上线也适合用户信任度还不高的阶段。数据准确性由 AI 负责最终确认权在用户手里。模式二自动模式配合强校验。针对高频且规则清晰的场景比如根据库存预警自动生成采购申请AI 在满足所有前置条件时自动创建单据并同步通知相关人。这个模式的前提是规则引擎足够完善每一条规则都是确定性代码而不是“模型大概率能判断对”。模式三半自动模式推荐长期稳定运营。AI 自动创建单据并提交审批流审批人看到的是“AI 建议”标识可以一键通过或退回修改。审批通过后单据正式生效。以采购申请单为例我们实际配置过一套完整规则AI 只能针对已列入采购计划内的物料生成申请申请数量不能超过安全库存缺口的 1.2 倍单笔金额超过 5 万元必须人工确认供应商必须从合格供应商名单中选择创建后 15 分钟内允许创建人撤销。这组规则下来基本把事故空间压缩到极小。5.3 审计与回滚每个操作都要对得上号业务办理类功能最怕的就是“找不到责任人”。所以在设计之初我们就建立了全链路审计。每次 AI 执行写操作都会在系统里生成一条调用记录包含操作人真实用户、AI 会话 ID、生成参数、校验结果、API 请求报文和返回报文、ERP 单据号。这些记录汇总成一张审计明细表任何一笔单据都能溯源到“谁让 AI 干的、AI 是怎么干的、干成了没有”。我们还利用 ERP 自带的单据变更日志做二次校验。比如鼎捷和金蝶在单据修改时都会留下字段级变更记录把这些记录和我们的审计表关联就能形成双重证据链。万一出现争议可以精确到某个字段的改动人和改动时间。6. 实测中反复踩过的坑和解决思路6.1 脏数据导致的“AI 幻觉”其实不是幻觉AI 上线初期我们经常发现 AI 给出“看似精确但实际错误”的答案。比如问“上月库存周转率”AI 自信地回答了一个数字后来人工复核发现它把“库存数量”和“库存金额”两个口径混在一起用了。查下来发现问题出在 ERP 里有很多字段名称相似但含义完全不同加上历史数据里有大量冗余编码。物料有 3 套编码体系并存同一种物料在采购模块是一种编码在销售模块是另一种。AI 不是不会查而是被“脏口径”带偏了。解决办法分两步。第一步是数据清洗前置建立主数据映射表把各模块的物料、客户、供应商编码统一映射到主数据 ID。第二步是口径校验在语义层里对每个指标都标注计算口径和适用场景查询前自动校验参数合法性。比如用户问“库存”AI 需要先确认是“账面库存”还是“可用库存”两者之间可能差了几万个。宁可在对话开始时多问一句也不要直接给一个误导性的数字。6.2 接口文档和实际功能对不上要准备一个“接口摸底”阶段金蝶、用友、鼎捷这些 ERP 厂商虽然都有开放平台但接口文档的质量参差不齐。我们碰到过文档里说支持某参数实际调用却返回报错的情况也碰到过文档没有写、但通过抓包发现其实有更简洁的内部接口可用的情况。所以建议不要拿到文档就开始写代码先留一周做接口摸底把核心场景涉及的所有接口都实际调一遍记录入参、出参、错误码、性能耗时。有些老版本的接口返回字段名是拼音缩写或乱码命名也需要在这个阶段梳理清楚。如果精力有限我建议优先跑通“报表查询类”接口因为查询是所有分析的基础链路通了后面的事都好办。6.3 多组织、多账套、多币别带来的上下文难题集团型企业的 ERP 通常有多个法人公司、多个利润中心数据天然是隔离的。AI 查询时必须先确定数据范围否则就会出现“集团汇总”和“单体公司”口径混在一起的问题。我们的做法是引入会话上下文变量——每个用户在进入 AI 对话前先选择自己所在的组织账套这个选择在整个会话中一直生效。如果用户问的问题是跨组织的AI 需要明确指出“这个数据是集团合并口径不区分公司”。币别的问题也很典型。外贸企业往往同时有人民币、美元、欧元业务。AI 查询金额类指标时必须确认币别是“原币”还是“本币”否则就可能出现把美元当人民币汇总的严重错误。我们后来在语义层里给每个金额字段都加了币别属性查询时强制带上过滤条件。6.4 模型选型与部署方式先跑通再优化别一步到位最后聊一下模型选型。很多人一开始就纠结“要不要本地部署大模型”其实正确的顺序是先用云端 API 跑通业务再根据数据隐私要求决定是否迁移到本地。查询和分析类场景因为只涉及只读数据放在云端跑问题不大很多企业连脱敏都不需要做。但业务办理类涉及写操作如果企业有严格的数据合规要求建议把模型部署到内网。部署参数量上我们也有一个心得不要盲目追大模型。我们实际跑了 14B 的开源模型配合封装好的工具调用查询和分析的准确率完全够用。真正影响效果的不是模型大小而是工具定义是否清晰、语义层是否完善、提示词是否经过迭代。如果基础工作没做好换再大的模型也一样翻车。最后说一点个人体会。这类“不换 ERP 加 AI”的项目最大的难点从来不在技术而在组织协调——业务部门希望 AI 一步到位财务部门担心数据失控IT 部门怕维护负担增加。我的建议是先从一个高频小场景开始比如“销售回款查询”跑通之后让业务感受到真实价值再逐步扩展到分析和业务办理。步子可以慢一点但每走一步都要可追溯、可回滚。AI 不是来颠覆 ERP 的它是来帮 ERP 里的数据发挥剩余价值的这个定位想清楚了项目就成功了一半。