那么，如何理解这种变化？企业又应当怎样建设自己的软件体系？笔者认为，从业务能力的形成和使用来看，今天的软件可以分为四个层次：以记录业务事实为基础的数据层，以表达业务规律为核心的模型层，以组织公共能力为手段的平台层，以解决实际问题为目标的应用层。这四层并不涵盖计算机系统的全部技术细节，却有助于看清软件如何把企业的业务资源转化为经营能力。

一家制造企业，接到客户订单后，要采购原料、安排生产、检验产品，再组织发货和收款。每个环节都会产生数据：客户订购了什么产品，原料什么时候到货，设备运行了多长时间，产品合格率是多少，货款是否按期收回。这些数据连在一起，才能反映一笔业务的完整过程。

过去，这些信息有的留在纸面上，有的存在员工的电脑里，有的分别保存在销售、生产、仓储和财务系统中。销售人员知道客户催货，生产人员知道设备停机，财务人员知道货款未收，但企业很难及时判断，这几件事情之间究竟有什么关系。

数据层的作用，就是把分散在业务过程中的事实，有组织地记录下来，使其能够被查找、关联和使用。

所谓有组织，首先要有统一的含义。销售系统中的“客户”和财务系统中的“客户”，需要能够对应起来；生产部门说的“完工”，与仓储部门说的“入库”，需要明确各自的业务边界。否则，数据虽然集中到一起，却不能直接用于分析。其次，数据还要有来源、有时间、有质量要求。同样一份库存数据，昨天的和现在的，对于安排交货可能具有完全不同的意义。

数据的范围也在扩大。订单、库存、账款是数据，设备发出的振动信号、售后人员留下的维修记录、客户提出的产品意见，同样是数据。过去一些只能由人阅读的文档、图片和录音，现在也可以借助模型进行识别和处理。

但数据并不会因为存放在服务器里就自动产生价值。一份设备维修记录，如果能够对应具体设备、故障现象、处理方法和维修结果，就可以为下一次维修提供依据；如果只有一句“已处理”，能够积累的经验就很有限。

因此，数据层建设要深入业务过程。哪些事实必须记录，记录到什么程度，由谁维护，多久更新，都需要在工作发生时落实。只有业务事实能够持续、准确地进入系统，上面的模型和应用才有可靠的基础。

有了设备的运行数据，是否就能知道设备什么时候需要检修？有了客户的购买记录，是否就能判断客户下一次可能需要什么？有了企业的历史销售额，是否就能制定下一季度的生产计划？

这中间，还需要模型。

模型是对现实对象及其关系的一种抽象。软件中的客户模型，需要说明客户有哪些属性，与订单、合同、账款有什么关系；库存模型，需要说明货物的出入如何改变库存；排产模型，则需要考虑订单交期、设备能力、材料供应等约束，计算生产任务怎样安排。

这些模型，把业务知识变成了软件能够处理的结构和规则。

比如，同样是“有货”，有的库存已经分配给其他订单，有的还在等待质检，有的虽然存放在仓库里，却已经超过使用期限。只有把这些业务关系表达清楚，软件才能计算出真正可用的库存。单纯把仓库数量相加，并不能回答能否向客户交货。

人工智能进一步扩展了模型层的能力。预测模型可以根据历史数据估计需求变化，视觉模型可以辅助识别产品缺陷，语言模型可以理解客户的问题、提取合同信息、整理维修经验。一些过去难以逐项编写规则的任务，由此有了新的处理方法。

这里需要注意，模型层不能简单等同于大模型。企业仍然需要业务对象模型、本体模型、商业规则和各种专业模型。语言模型适合处理自然语言，但账款如何结算、库存如何扣减、审批权限如何判定，仍然需要明确的业务规则来约束。

设想一位设备维修人员询问系统：“这台机器温度升高，同时伴有异响，可能是什么原因？”语言模型可以理解问题，检索模型可以找到相关资料，故障诊断模型可以结合运行参数给出排查建议，而设备模型则提供型号、使用年限和维修历史。几种模型共同工作，才能形成有依据的回答。

模型层的价值，就在于把数据和知识组织成可重复使用的处理能力。模型是否有效，也要通过实际结果检验：预测与现实相差多少，诊断是否准确，给出的建议能否执行。模型需要在使用中不断校正，才能适应业务的变化。

企业有了数据，也有了模型，为什么还需要平台？

假设一家企业要建设销售助手、采购助手和售后助手。这三个应用都要识别员工身份，都要查询企业数据，都可能调用语言模型，还需要保存操作记录。如果每个应用都单独建设这些功能，就会形成三套连接方式、三套权限管理和三套运行维护机制。应用越多，重复建设和相互协调的工作也就越多。

平台层，就是把这些共同需要的能力组织起来，供不同应用使用。

比如，企业员工登录后，平台确定他的身份和权限；应用需要分析订单时，平台提供相应的数据接口；任务需要模型处理时，平台调用适合的模型；需要向业务系统写入结果时，平台检查操作条件，并记录执行过程。

这样一来，应用开发者可以把更多精力放在具体业务上。建设售后应用，重点考虑故障怎样受理、如何分派、何时升级处理；建设采购应用，重点考虑需求如何汇总、供应商怎样选择、交期如何跟踪。共同需要的技术能力，可以通过平台获得。

平台还要解决从“能够运行”到“持续运行”的问题。一次模型调用可能失败，一项任务可能执行到中途停止，一个数据接口可能暂时无法访问。系统需要知道哪些操作可以重试，哪些必须交给人员处理，哪些结果已经生效，避免重复执行。模型使用的费用、响应时间和结果质量，也需要持续监测。

尤其当模型能够调用工具、执行任务时，平台的作用更加明显。查询一笔订单和修改一笔订单，所需权限并不相同；提出采购建议和提交采购单，也有不同的业务责任。平台需要把这些边界落实到运行过程之中。

当然，平台不宜脱离应用预先铺得过大。企业可以从已经反复出现的需求中提炼公共能力，再随着应用增加逐步完善。能够减少重复建设、缩短交付时间、降低运行维护负担的平台，才具有实际价值。

企业使用软件，最终要落实到具体工作。销售人员要跟进客户，采购人员要保证材料供应，生产主管要按期完成订单，经营者要了解收入、成本和现金流。这些需求，都由应用层承接。

应用是数据、模型和平台能力在业务场景中的具体组合。对于用户而言，后台采用什么模型、调用多少接口，通常不是最关心的问题。他关心的是，工作能不能顺利完成，结果是否可靠，出了问题能否处理。

以采购为例。系统根据库存和生产计划，计算出未来两周的材料缺口，这是分析能力；进一步比较供应商交期、价格和历史履约情况，形成采购建议，这是决策支持；再把建议转成采购申请，按照权限完成审批，跟踪到货并处理异常，才构成较为完整的采购应用。

因此，一个应用是否成熟，要看它覆盖了多长的工作过程。只给出一份分析报告，后续仍需要人工反复复制数据、填写表单、核对状态，能够节省的工作就比较有限。如果分析结果能够进入业务流程，并且在必要环节由人员确认，软件就能承担更多事务。

应用的交互方式也可以更加灵活。用户既可以通过表单、图表和按钮完成操作，也可以用自然语言表达需求。对于边界清楚的重复任务，可以由系统自动执行；对于需要经验判断的事项，则提供证据和建议，交由人员决定。

这种变化并不意味着所有应用都要改成对话窗口。查看大量订单，表格可能更方便；比较经营指标，图表可能更直观；表达一个复杂查询，自然语言可能更省事。采用什么方式，应当由工作的特点决定。

应用层还承担着反馈的作用。用户修改了哪些建议，哪些任务经常失败，采取措施后业务指标有没有改善，这些结果都应当被适当记录。经过分析，可以据此完善数据、调整模型、改进平台和优化流程。软件的持续改进，由此与企业的日常经营联系起来。

数据、模型、平台和应用，在实际系统中未必分别对应四套独立产品。一家企业可以使用外部平台和通用模型，也可以保留自己的数据体系、业务规则和特色应用。关键在于明确各层承担的责任，以及它们之间如何连接。

企业建设这四层结构，也不必一次全面到位。可以从一个实际问题出发，比如减少设备停机、提高交付准确率、缩短客户响应时间，先整理相关数据，建立适用模型，借助平台形成应用，再根据运行结果逐步扩展。