软件从现实开始：知识驱动计算（KDC）的Reality First主张

作者：vivo 肖博AI 合作者：ChatGPT（GPT-5.5）创作模式：Human-led, AI-collaborated责任声明：文章观点、理论体系及最终内容由作者负责；AI 参与讨论、推演、表达优化及部分内容生成。 研究说明：知识驱动计算（Knowledge-driven Computing, KDC）是我们正在提出和持续打磨的一套 AI 应用软件工程理论，目前仍处于开放研究阶段。它不是业界已有的通用概念，也不是已经成熟的架构标准。这一系列文章将从具体工程问题出发，逐步说明我们为什么提出 KDC、它试图解释什么，以及哪些判断仍有待实践验证。 摘要：当 AI 应用开始在运行时解释数据、选择工具并影响业务状态时，数据表示中的遗漏和歧义可能直接转化为行动风险。本文从退款案例出发，提出 Reality First 的观察顺序：先明确系统面对的领域现实，再讨论现实模型、数字表示以及验证反馈如何共同支撑软件的判断与行动。 让我们从一个真实案例开始。 退款接口返回成功，订单状态已经更新为“已退款”，客服后台也显示流程结束。 三天后，用户再次联系客服：钱还没有到账。 从系统内部看，这笔退款没有明显异常。退款接口返回了 HTTP 200 状态码，数据库事务已经成功执行，退款单状态符合预期，通知消息也正常发出。检查服务、表结构和调用链，这个流程可以被判断为“执行成功”。 但从用户面对的现实看，退款还没有完成，因为钱没有到账。 这类问题通常会被归入最终一致性、外部渠道延迟、对账异常或状态同步失败等工程问题。但在这些问题分类之前，还有一个更基础的问题： 应用软件中的状态，究竟是不是现实本身？ 如果不是，那么软件架构的第一层究竟是什么？ 从传统架构视角看，应用软件经常被描述为数据在程序、数据库、接口和流程之间流动的系统。这个抽象很有解释力，但它通常从数据已经存在之后开始，没有继续追问这些数据在表示什么现实。 本文尝试暂时离开数据表、服务和接口这些应用软件架构中常见的组件，从更基础的问题重新审视应用软件。我们研究的初步判断是：应用软件其实不是从数据开始，而是从它试图观察、表示和影响的领域现实开始。数据库、API、事件、对象模型和页面状态，都只是现实进入数字系统后的表达。 这个判断看起来朴素，却会改变我们设计 AI 应用软件时提出问题的顺序。 我们习惯从数据开始设计软件 多数应用软件项目都有一条熟悉的设计路径。 需求经过分析后，被翻译成领域对象、数据表、接口和流程：订单需要哪些字段，状态如何枚举，服务之间如何调用，事件如何传递，事务在哪里提交，失败后怎样重试。页面、报表和外部系统再围绕这些数据结构工作。 这套方法没有错。过去几十年的软件工业已经证明，清晰的数据模型、稳定的接口契约、可靠的事务和消息机制，是构建复杂系统不可缺少的基础。 问题在于，我们很容易在长期工程实践中形成一种错觉：仿佛数据模型就是业务现实，字段变化就是现实变化，接口成功就是业务目标实现。 实际上，订单表不是交易本身，库存数字不是仓库中可交付的商品本身，支付状态不是资金流本身，物流轨迹也不是包裹本身。它们都是系统对现实的观察、编码和表达。 在固定流程中，这种简化往往足够有效。程序员提前决定了数据从哪里来、每个字段在当前流程中代表什么、什么条件下可以调用接口、失败后如何处理。很多没有写进数据模型的业务含义，实际上被补充在代码分支、规则引擎、页面交互、操作手册和人工审核中。 举个例子。数据库里可能只有一个 refund_status = success。但编写售后流程的开发者知道，这个 success 只表示支付渠道已经受理退款，并不表示资金已经进入用户账户。因此，程序可以继续等待到账回执，客服也可能按照操作规范提醒用户关注后续进度。 换句话说，传统系统并不是只依靠数据运行。它还依靠程序员在设计阶段把数据的语义、适用条件和例外处理写进确定的执行路径。数据表示即使不完整，代码和人工流程仍可能补上缺失的解释。 AI 应用改变的正是这个前提。 大模型不再只是被某段固定代码调用，用来完成分类、摘要或文本生成。它开始进入应用软件的运行时，直接读取数据库字段、业务文档、API 响应、历史对话和检索片段，在当前上下文中解释这些表示，再据此形成判断、选择 Tool，甚至触发会改变订单、资金、权限和流程状态的行动。 这意味着，过去主要由开发者在设计阶段完成的部分语义解释和行动选择，现在被移动到了运行时： 传统程序 数据表示 -> 预先编写的解释逻辑 -> 固定条件分支 -> API 调用 AI 应用 多种表示 -> 模型在当前上下文中解释 -> 运行时判断 -> 动态选择行动 这里真正新增的风险，不是“大模型可能读错一个字段”这么简单，而是表示层中的问题会沿着一条更短、更动态的路径进入现实行动。 第一，模型接收到的通常不是完整现实，而是多个系统留下的局部表示。订单状态来自订单系统，支付状态来自支付渠道，用户诉求来自对话，退款政策来自文档检索。每一种表示都有自己的观察范围、更新时间和语义边界。 第二，模型需要在运行时自行拼接这些表示。它不仅读取值，还会推断值之间的关系。比如，它可能把 refund_status = success、支付渠道返回 accepted 和“退款流程已结束”的旧版客服话术组合成“用户已经收到退款”。这个结论在语言上很连贯，却超出了任何一个输入实际能够证明的范围。 第三，模型形成的解释可能直接影响下一步行动。在传统系统中，一个新结论通常需要开发者把它写进代码后才能改变执行路径。在 Agent 系统中，同一次运行里的解释就可能决定是否关闭工单、是否通知用户、是否再次发起退款，或者是否调用其他业务能力。 第四，Tool 调用成功还会制造一种额外的确定感。接口返回成功，只能证明某个数字系统接受或完成了某项操作。如果系统没有定义后续现实反馈，模型和使用者都可能把技术成功误认为业务目标已经实现。 于是，一个原本位于表示层的缺口，会被逐级放大： flowchart LR R[“领域现实“] -->|观察与建模| RM[“Reality Model 现实模型“] RM -->|编码：遗漏、压缩、延迟| RP[“Representation 数字表示“] RP -->|解释：歧义、超证据推断| J[“运行时判断“] J -->|行动选择| C[“Tool / Capability“] C -->|执行| A[“现实行动“] A -.->|结果反馈| R 图 1：表示偏差如何沿 AI 判断链进入现实行动 需要强调的是，表示偏差并不是 AI 出现后才有的问题，传统系统也会遭遇脏数据、状态延迟和模型失真。AI 带来的变化在于：系统开始动态解释更多异构表示，判断路径不再全部预先写死，而且判断可以更快地转化为行动。原有的数据质量问题，因此进一步变成了语义边界、判断依据和行动治理问题。 所以，在 AI 时代继续只从数据开始，已经不只是建模视角上的局限。如果系统没有说明数据对应什么现实、能够支持什么结论、又需要什么反馈才能验证，那么表示层中的遗漏、过期和歧义就可能穿过模型的判断，最终成为现实世界中的行动风险。 为什么我们开始研究 KDC 我们提出 KDC，并不是因为代码