退款接口返回HTTP 200，订单状态更新为“已退款”，客服后台显示流程结束。从系统内部看，事务已提交，通知消息正常发出，一切执行成功。但用户的钱没有到账——退款还没有真正完成。

这类场景通常被装进“最终一致性”“对账异常”“渠道延迟”等工程筐里。一个更基础的问题反而被绕开了：软件到底是从哪里开始的？是数据，还是数据试图描述的那层现实？

打开网易新闻 查看精彩图片

知识驱动计算（Knowledge‑driven Computing，以下简称KDC）的研究团队从这样一个朴素的问题出发，提出了Reality First的观察顺序：应用软件不是从数据开始，而是从它试图观察、表示和影响的领域现实开始。数据库、API、事件、对象模型、页面状态，都只是现实进入数字系统之后的表达。

这个主张看似简单，却会从根本上改变我们设计AI应用软件时提出问题的顺序。当大模型开始在运行时直接读取数据库字段、业务文档、API响应、历史对话和检索片段，并在当前上下文中解释这些表示，再据此形成判断、选择Tool，甚至触发会改变订单、资金、权限和流程状态的行动时，“数据就是现实”的旧假设便开始承压。

传统软件工程中，需求被翻译成领域对象、数据表、接口和流程：订单需要哪些字段，状态如何枚举，服务之间如何调用，事件如何传递，事务在哪里提交，失败后怎样重试。清晰的数据模型、稳定的接口契约、可靠的事务和消息机制，构建了复杂系统的骨架。但这套方法论隐含了一个容易被忽视的惯性：我们很容易把数据模型等同于业务现实，把字段变化等同于现实变化，把接口成功等同于业务目标实现。

实际上，订单表不是交易本身，库存数字不是仓库中可交付的商品本身，支付状态不是资金流本身，物流轨迹也不是包裹本身。它们都是系统对现实的观察、编码和表达。在固定流程中，这种简化往往足够有效，因为程序员提前决定了数据从哪里来、每个字段代表什么、什么条件下可以调用接口、失败后如何处理。大量没有写进数据模型的业务含义，被补充在代码分支、规则引擎、页面交互、操作手册和人工审核里。

数据库里可能只有一个refund_status = success，但编写售后流程的开发者知道，这个success只表示支付渠道已经受理退款，并不表示资金已经进入用户账户。因此，程序可以继续等待到账回执，客服也可能按照操作规范提醒用户关注后续进度。换句话说，传统