业务系统AI赋能的三个层次：从能问到能决策

Hello，大家好，我是人月聊IT。

今天咱们接着上一期的话题，继续聊聊业务系统的AI赋能。如果你本身就在做业务系统的开发和实施，想必对当前主流的技术路线深有体会——现在给业务系统增加AI能力，最常见的做法就是在页面上加一个悬浮的AI助手弹窗，或者侧边栏对话框，形式上有点像客服机器人，只不过换了个更“智能”的名头。但不管你前端UI怎么设计，实际落地的功能基本都集中在智能填单、智能审核、智能问答、智能问数这几个场景上，好像AI进了业务系统，就天然该干这些“打辅助”的活儿。

然而，这种模式存在一个相当隐蔽却又致命的问题：每一个具体的AI功能，几乎都要单独训练一套业务语义数据。换句话说，你如果想用AI做智能填单，就得先梳理填单涉及的所有字段、校验规则、数据来源，把这些上下文整理成训练语料喂给AI，AI才能学会“怎么填”。可一旦你换个需求，比如想让AI帮忙做批量审批——它立刻就懵了，因为批量审批涉及的是流程权限、阈值判断、单据状态流转，这和填单的语义空间完全不同，AI没有对应的业务语义支撑，自然没法执行。于是，你就得再为审批功能重新训练一套语义模型，周而复始，每加一个AI能力就要重复一遍“建语料—训练—调优”的流程，这显然不是一条可持续的路径。

图片

正是基于这个痛点，我在之前的分享中提出过一个思路：对业务系统进行向量化和语义蒸馏。什么叫“向量化和语义蒸馏”？简单说，就是当我们拥有一个成熟的业务系统时，我们可以把它的需求文档、设计文档、数据库模型、接口契约，甚至完整的源代码，全部作为输入，通过大模型技术进行语义抽取和压缩，最终沉淀出一套承载了该业务系统全部业务语义的“原模型”。这套模型不一定非得是严格意义上的本体模型（Ontology），但它必须做到一点——只要业务系统里有的概念、规则、流程、数据关系，它都能“理解”并“记住”。

有了这套原模型之后，我们就能解锁第一个层面的能力：能回答。你可以像跟一个资深业务专家聊天一样，随意向AI提问。比如：“这个业务系统到底是干什么用的？”AI会给你一个概括性的业务定位说明。再比如：“采购订单从创建到结算，端到端的业务流程是怎么走的？”AI能按步骤画出完整的流转路径，包括每一步涉及的角色、单据、状态变更。更细一点，你可以问：“创建采购订单时，金额超过多少需要走特殊审批？”AI会精准地告诉你具体的规则阈值。甚至你可以问：“我要完成一笔采购订单录入，在系统界面上需要依次操作哪些菜单和按钮？”AI也能给你一个操作指引。这些问题的背后，靠的就是原模型对业务语义的全面覆盖，不需要再为每一个问题单独训练，因为所有语义都已经内化在模型里了。所以，第一步“能回答”的核心价值是——让AI真正“懂”你的业务，而不是只会匹配关键词。

但光能回答还远远不够，业务系统最终是要“干活”的。于是我们进入第二个层面：能执行。怎么实现？关键在于，我们在进行语义蒸馏的同时，还需要将原有业务系统的底层能力层剥离出来。什么叫能力层？就是系统对外暴露的所有API接口、服务端点、事件触发器，包括创建单据、更新状态、提交审批、发送通知、查询报表等等。这些接口原本是给前端界面调用的，现在我们要把它们统一接入到AI的“工具箱”里。一个比较成熟的参考模式就是MCP Server（Model Context Protocol Server）——你可以把MCP Server理解为一个中间层，它把业务系统的各种操作能力封装成标准化的工具函数，并配上清晰的参数说明和调用约束。AI在获得了这些工具的描述之后，再结合原模型的业务语义，就能像人类操作员一样，通过“思考—选工具—调用—验证”的链路去完成实际任务。

举个例子，你对AI说：“帮我把张三提交的所有合同金额小于500万的采购申请单，全部自动审批通过。”这句话里包含了几层信息：第一，操作对象是“张三提交的申请单”；第二，过滤条件是“合同金额小于500万”；第三，操作动作是“审批通过”。AI拿到指令后，首先通过原模型理解“申请单”“金额”“审批通过”这些词在业务语境下的确切含义，然后从MCP Server提供的接口列表中选出“查询申请单列表”和“批量审批”两个接口，自动构造查询条件，调用查询接口拿到符合条件的单据ID列表，再逐条调用审批接口完成通过操作。整个过程不需要你手动点开任何界面，也不依赖RPA模拟点击，完全是接口级别的自动化调用。这就是“能执行”的本质——AI从“建议者”变成了“操作者”，把重复性的、规则明确的人工操作彻底解放出来。

但是，如果AI赋能只到“能执行”这一步，那它充其量是一个高级版的自动化脚本工具。我认为，最核心、最具颠覆性的价值在于第三个层面：能分析、能决策。很多人在聊本体论的时候，总觉得那是数据中台或者多系统集成才用得上的高深理论，单个业务系统用不着。但我恰恰觉得，即使是一个独立的业务系统，只要它承载了足够的历史数据和业务规则，AI就完全可以基于原模型做跨功能、跨流程的关联推理，进而给出决策建议。

我们拿供应链采购经理的日常场景来说。每个季度，采购部门都有明确的KPI指标，比如采购计划完成率、成本节约率、供应商准时交付率等等。常规做法是月底或季末拉一张报表，看看数据有没有达标，不达标再找原因。但有了“能分析”的AI助手，你可以随时问：“当前这个季度已经过了两个月，我的采购计划执行进度如何？各项KPI的实时完成度是多少？”AI会从系统中提取实时数据，结合原模型的业务语义，给你一个动态的仪表盘式回答。如果你接着问：“按现在的进度，季末想达成KPI，我最好的执行策略是什么？应该优先加速哪些品类的采购？或者是否要调整部分订单的审批阈值？”AI就能基于历史数据和当前状态，结合显性化沉淀下来的专家经验（比如过去相似情况下的最优操作），给出具体的建议清单，比如“建议对A类物料订单启用快速通道”“建议将B供应商的付款周期从30天缩短至15天以换取优先排产”。这些建议不是凭空生成的，而是AI在理解业务逻辑、掌握实时数据、复盘历史规律之后，动态推演出来的可行方案。

更进一步，当AI具备了这种分析和推理能力后，它就不再是“你问我答”的被动工具，而是能够主动发现异常、预判风险。比如它可能会在月初主动提醒你：“本月有一批合同即将到期，其中3家供应商的履约评分连续下降，建议提前启动备选供应商评估。”这种主动预警和策略推荐，才是真正意义上的智慧化。整个IT系统在AI的赋能下，不再是僵硬的流程执行机器，而成了一个可以自我进化、自我迭代的“数字大脑”——它能回答业务咨询，能执行操作指令，更能辅助管理者进行复杂决策。

总结一下，我对业务系统AI赋能的思考，可以概括为三个递进层次：第一层，能回答，让AI完整理解业务语义；第二层，能执行，让AI调用接口完成操作；第三层，能决策，让AI基于数据和规则进行推理和优化。

当前业界绝大多数AI助手还停留在第一层和第二层的浅水区，而且由于缺乏原模型和MCP接口体系的整体设计，每项能力都割裂训练，成本高、效果差。我们真正要做的，是从系统建设之初就规划好语义蒸馏和能力接入的架构，让AI从一开始就站在整个业务系统的“全局视角”上，而不是当个临时工，哪儿缺人往哪儿塞。

当然，这个路径不是一蹴而就的，它需要业务团队、开发团队和AI算法团队紧密配合，也需要对原有系统进行一定程度的改造和接口标准化。但方向对了，每一步积累都不会浪费。未来，我相信每一个业务系统都会标配这样一个“全知全能”的AI伙伴，它懂你的业务，能帮你干活，还能替你出谋划策——到那时，IT系统才真正从“工具”演变为“同事”。

好了，今天的简单分享就到这里。