CRM可以模糊，ERP不行
很多企业做完"AI+CRM"之后，会自然地把下一个目标定为"AI+ERP"，理由是：不都是接个接口吗？
这个判断忽略了一个根本差别。
CRM里记录的，本质上是人与人的沟通。一个客户的等级填错了，销售看一眼就能发现；一条跟进记录写得不准确，最多影响一次沟通质量。CRM里的数据是可以被人实时修正的、容错较高的描述性数据。
ERP里记录的，是会产生财务后果的事实。一张采购入库单会影响库存数量、影响应付账款、影响成本计算、最终影响利润表和资产负债表。一笔错误的写入不会自己消失，它会一路流转到月末结账，然后在某个对账的深夜被人发现，而那时已经有一堆下游单据依赖它。
所以，"AI接ERP"真正的分水岭不是技术，是你让AI读，还是让AI写。
查询类：先做这个，它值回票价
查询类Agent做的是：把ERP里已有的数据取出来，用自然语言回答，或者做汇总分析。
比如：
"华东仓现在A物料还有多少可用？"
上个月哪些供应商的交期延误超过7天？"
"这批订单里，有哪些是已发货未开票的？"
这类需求的价值很实在。ERP的报表功能普遍强大但难用，业务部门想看一个数往往要提需求给IT，等一两天。用自然语言直接查，能把等待时间从天级压到秒级，这对经营决策的节奏影响不小。
而且它的风险可控：AI答错了，人一眼能看出来，因为看报表的人通常知道自己大概要找什么。
但即便只是查询，也已经有一个坑在等着：口径。
坑一：同一个词，在ERP里有好几个数
"库存还有多少"这个问题，在ERP里至少有四种不同答案：
现存量：仓库实物账面数量；
可用量：现存量减去已被销售订单占用、被其他出库单预留的部分；
在途量：已下单未到货；
待检量：已收货但未质检完成，通常不可用于销售。
业务部门嘴里的"还有多少"，指的通常是"可用量"，但如果没有明确指定，AI很可能取到现存量——因为它是最常被存在主表里的那个字段。这两个数字在旺季能差出30%以上。
更麻烦的是，不同ERP产品、甚至同一产品的不同模块，对这些口径的定义和字段命名都不一样。有的把"预留"放在销售模块，有的放在库存模块，有的需要联查三张表才能算出来。
所以查询类Agent项目的第一件事，不是接模型，是写一份口径字典：把业务口中的每个常用指标，对应到ERP里唯一确定的计算方式，并由财务或仓储负责人签字确认。这份字典是后续所有工作的基础，也是验收的标准。没有它，AI给出的每个数字都会被人质疑，最后没人用。
坑二到坑五：全部出现在"写"的环节
一旦让AI开始制单——自动生成采购申请、自动创建销售出库单、自动生成凭证——下面四个机制就该被认真对待。它们是ERP和CRM最本质的区别所在。
坑二：幂等。AI调用接口超时了，重试一次，结果是生成了两张一模一样的单。这不是理论风险，大模型应用的调用链路长、涉及外部服务多，超时和重试是常态。解决方案是给每张AI生成的单据带一个业务唯一键（比如"来源系统+原始请求ID"），ERP侧做唯一性校验，重复请求直接返回已有单据号而不是新建。这个机制必须在开发前写进设计，事后补的成本高得多。
坑三：状态机。ERP里的单据有一套严格的状态流转：草稿→审核中→已审核→已记账→已关闭，有些还有"反审核""作废"。AI最容易犯的错是跨状态操作——比如试图修改一张已经记账的单据，或者直接删除一张已审核的单。正确的做法是给Agent明确的状态约束：它只能在"草稿"状态创建和修改，提交后的一切流转交给人和审批流。而且，很多ERP不允许物理删除，只能作废，AI必须理解"作废"和"删除"的区别。
坑四：会计期间。每个月末结账后，会计期间会被关闭或锁定。此时写入会失败，或者被写进下一个期间，导致跨期。如果AI在月末最后一天批量制单，很容易撞上这个窗口。设计上需要让Agent感知期间状态，遇到锁定时的行为要有明确定义：是排队到下期、是报错转人工、还是提醒。默认行为绝不能是"找个能写的地方写进去"。
坑五：成本计价。这可能是最反直觉的一个坑。在移动加权平均、先进先出等计价方式下，一笔出库的成本不是在AI制单时决定的，而是在审核/记账的瞬间由系统按当时的库存和单价算出来的。所以AI绝不能自己"算"一个成本填进去，它只能填数量和物料，成本字段留空交给系统。如果让AI填了成本，就会出现账面成本与实际计价不一致，这种差异在月末结转时会集中爆发，且极难追溯。
AI能不能自己审批？
这是个老板常问的问题，答案是：技术上能，但绝大多数企业不该这么做。
审批的本质是责任确认。ERP里"审核"这个动作，通常意味着审核人对这笔业务的真实性、合规性和金额负责。让AI审核，等于把责任交给了一段没有法律主体资格的代码。
更务实的分工是：AI制单，人审批，但AI负责把审批所需的信息准备好。比如AI生成一张采购申请，同时附上：历史采购价对比、供应商近三次交期表现、当前库存与用量预测、预算剩余额度。审批人要看的东西都在一屏内，审批从"翻五个系统查证"变成"看一份摘要做判断"。这个模式既保留了责任归属，又真正省了时间——而且它省的是审批人最贵的时间。
这套分工还有一个好处：审批记录本身就是最好的训练数据和评测集。哪些单被驳回、驳回理由是什么，反过来可以用来优化AI的制单规则。
制单类必须内置的两个机制
如果你确实要上制单类Agent，有两个机制不能省：
第一，草稿优先。所有AI生成的单据默认是草稿状态，不进入审批流，需要人确认后才提交。这听起来降低了自动化程度，但实际上大幅降低了纠错成本——修改一张草稿单是零成本的，而冲销一张已记账的凭证，需要走完整的红冲流程，还要在账务上留下痕迹。
第二，可冲销设计。必须预先设计好"AI批量做错了，怎么一键撤销"。理想状态是每一批AI操作有一个批次号，能按批次整体冲销或导出清单逐条处理。很多项目上线时只想着怎么把单做出来，没想到做错了怎么办，等真出问题时只能人工一条条改。在项目方案里，"批量错误的恢复方案"应该是一节独立内容，而不是附录里的一句话。
接口现实：有些ERP根本没有可用的API
还有一个绕不开的现实问题。
新的云原生ERP通常有比较完整的开放API。但大量企业在用的，是十年前上线的本地部署版本、经过大量二次开发的定制版本，甚至是已经过了厂商主流支持期的老版本。这些系统的情况是：
没有REST API，只有数据库直连；
有API但文档缺失，字段含义靠实施顾问口口相传；
二开逻辑写在存储过程里，绕过应用层直接写库会跳过业务校验；
厂商已不支持，找不到人改。
在这种情况下常见的两条路：一是数据库直连读写，风险是绕过业务校验、容易破坏数据一致性，而且厂商通常不认可、出问题不承担责任；二是用界面自动化技术（模拟人工操作界面）来完成AI的动作，好处是不需要接口、不绕过校验，坏处是速度慢、界面改版就会失效、维护成本高。
选择哪条路，取决于一个现实判断：这个ERP还要用多久？如果两三年内要替换，就不值得为它做深度集成，做个轻量的查询层就够了；如果还要用五年以上，那投入做规范的接口封装才是划算的。
这个判断应该在立项阶段就做，而不是做到一半发现接口不通再讨论。
什么时候不该让AI碰ERP
说清楚边界：
如果你的ERP数据本身就不准（账实不符），先解决这个，不要接AI。AI不会纠正错误数据，它会用流畅的语言把错误数据讲得更可信。账实不符是流程和执行问题，不是系统问题。
如果业务单据量很小，不要做制单自动化。一个月几十张单的业务，人工处理的成本低于维护一套自动化系统的成本，省不下钱。
如果你的ERP正在实施或即将换系统，推迟。在地基没稳的时候做集成，等于把集成做在了会移动的东西上。
最后一个常被忽略的判断：ERP里的很多"效率问题"，其实不是录入慢，而是录入前的信息确认慢——要确认库存、确认价格、确认预算、确认审批人。AI真正能帮上忙的是这一步，不是后面的敲键盘环节。如果瓶颈在前者，价值很大；如果瓶颈在后者，收益有限。
