责任声明：文章观点、理论体系及最终内容由作者负责；AI 参与讨论、推演、表达调优及一块内容生成。
当 AI 应用开始在运行时解释数据、选择利器并左右场景状态时，数据表示中的遗漏和歧义可能直接转变为行动风险。本文从退款案例出发，提出 Reality First 的观察顺序：先明确系统面对的领域现实，再讨论现实模型、数字表示以及验证反馈怎样共同支撑软件的判断与行动。
探究解释：知识驱动计算（Knowledge-driven Computing，KDC）是我们提出和正在打磨的一套 AI 应用软件工程理论，目前仍处于开放研究阶段。它不是业界已有的通用概念，也不是早已成熟的结构基准。这一系列文章将从具体项目问题出发，渐渐说明我们为什么提出 KDC、它试图解释什么，以及哪些判断仍有待实践验证。
1分钟看图掌握中枢要点👇
使我们从一个真实样例开始。
退款接口返回成功，订单状态已经更新为”已退款”，客服后台也展现链路结束。
三天后，使用者再次关联客服：钱还没有到账。
从体系内部看，这笔退款没有显见异常。退款接口返回了 HTTP 200 状态码，资料库事务已经成功落实，退款单状态符合预期，通知消息也正常发出。检查服务、表结构和触发链，这个链路可以被判断为”执行成功”。
但从使用者直面的现实看，退款还没有完成，因为钱没有到账。
这类难题一般会被归入最终一致性、外部渠道延迟、对账异常或状态同步失败等项目问题。但在这些难题归类之前，还有一个更基础的问题：
运用软件中的状态，究竟是并非现实本身？
假如不是，那么软件结构的第一层究竟是什么？
从传统架构视角看，应用软件经常被描述为资料在程序、数据库、接口和链路之间流动的系统。这个抽象很有解释力，但它一般从数据早已存在之后开始，没有继续追问这些数据在表示什么现实。
本文尝试暂时离开资料表、服务和接口这些应用软件架构中多见的组件，从更基础的问题重新审视应用软件。我们研究的初步判断是：应用软件其实并非从数据开始，而是从它试图观察、表示和左右的赛道现实开始。资料库、API、事件、对象范式和页面状态，都只是现实进入数字系统后的表达。
这个判断看起来朴素，却会转变我们设计 AI 运用软件时提出难题的顺序。
一、我们习惯从资料开始设计软件
多数应用软件工程都有一条熟悉的构建路线。
被翻译成领域对象、数据表、API和流程：订单需要哪些字段，状态怎样枚举，服务之间如何触发，事件如何传递，事务在哪里提交，需求经过分析后。页面、报表和外部体系再围绕这些资料结构事务。
这套方法没有错。过去几十年的软件工业已经证明，清晰的数据模型、稳定的接口契约、可靠的事务和消息机理，是搭建复杂体系不可缺少的基础。
问题在于，我们很容易在长期工程落地中形成一种错觉：仿佛数据范式就是业务现实，字段变化就是现实变化，API成功就是业务目标实现。
订单表并非交易本身，库存数字不是库中可交付的商品本身，支付状态不是资金流本身，现实上。它们都是体系对现实的观察、编码和表达。
在固定链路中，这种简化通常足够有效。程序员提前决定了资料从哪里来、每个字段在当前流程中代表什么、什么条件下可以调用接口、失败后怎样处理。很多没有写进资料模型的业务含义，实际上被补充在代码分支、规则引擎、页面交互、运维手册和人工审核中。
举个例子。资料库里或许只有一个 refund_status = success。不过编写售后流程的开发者知道，这个 success 只表示支付渠道早已受理退款，并不表示资金已经进入用户账户。所以，程序可以继续等待到账回执，客服也可能按照运维标准提醒用户关注后续进度。
换句话说，传统系统并并非只依靠资料运行。它还依靠程序员在构建阶段把资料的语义、适用条件和例外处理写进确定的执行路径。数据说明即使不完整，代码和人力流程仍或许补上缺失的解释。
AI 运用转变的正是这个前提。
大模型不再只是被某段固定代码调用，用来做完分类、摘要或文本产出。它开始进入应用软件的运行时，径直读取数据库字段、业务文档、API 响应、过往对话和检索片段，在当前上下文中解释这些表示，再据此形成判断、挑选 Tool，甚至触发会改变订单、资金、权限和流程状态的行动。
这意味着，以往主导由开发者在构建阶段完成的部分语义解释和行动选择，现在被移动到了运行时：
传统程序
数据表示 -> 预先编写的解释逻辑 -> 固定条件分支 -> API 调用
AI 应用
多种表示 -> 模型在当前上下文中解释 -> 运行时判断 -> 动态选择行动
这里真正新增的隐患，不是”大模型或许读错一个字段”这么简单，而是表示层中的问题会沿着一条更短、更动态的路径进入现实行动。
第一，模型接收到的一般不是完整现实，反倒多个系统留下的局部表示。订单状态来自订单体系，支付状态来自支付渠道，使用者诉求来自对话，退款政策来自文档检索。每一种说明都有自己的观察边界、更新时间和语义边界。
第二，模型须要在运行时自行拼接这些说明。它不仅读取值，还会推断值之间的关联。比如，它可能把 refund_status = success、支付渠道返回 accepted 和”退款链路已结束”的旧版客服话术组合成”使用者已经收到退款”。这个结论在语言上很连贯，但超出了任何一个输入实际可以证明的范围。
第三，模型形成的解释可能径直左右下一步行动。在传统体系中，一个新结论一般需要开发者将它写进代码后才能转变执行路径。在 Agent 体系中，同一次运行里的解释就可能决定是否关闭工单、是否通知用户、是否再次发起退款，或者是否触发其他业务能力。
第四，Tool 触发成功还会制造一种额外的确定感。API返回成功，只能证明某个数字体系接受或完成了某项操作。如果体系没有定义后续现实反馈，模型和使用者都可能把手段成功误认为场景目标已经实现。
便，一个原本位于说明层的缺口，会被逐级放大：
图 1：说明偏差怎样沿 AI 判断链进入现实行动
须要强调的是，表示偏差并并非 AI 出现后才有的问题，传统系统也会遭遇脏数据、状态延迟和模型失真。AI 带来的变化在于：系统开始动态解释更多异构表示，判断路径不再全部预先写死，并且判断能够更快地转化为行动。原有的数据质量难题，因此进一步变成了语义边界、判断根据和行动治理问题。
所以，在 AI 纪元继续只从资料开始，已经不只是建模视角上的局限。如果体系没有说明数据对应什么现实、能够具备什么结论、又需要什么反馈才能验证，那么表示层中的遗漏、过期和歧义就或许穿过模型的判断，最终成为现实世界中的行动风险。
二、为什么我们起步研究 KDC
我们提出 KDC，并并非因为代码、资料库和 API 早已过时。恰恰相反，这些工程基础仍然承担确定性落实、数据持久化、系统整合和性能保障，是任何生产系统不可缺少的部分。
这项探究并不是先有一个”KDC”名称，再去寻找适用难题。Tool-use 早已使 LLM 能够参与下单、查询和任务执行等流程。我们也借助 MCP、Tool、Skill、LLM 与一套能力治理平台完成了电商链路校验。这里的本领治理底座，是承担工具注册、授权、测试、灰度、限流、熔断、审计和观测等职责的工程系统。这个实践不等于完整生产验证，不过它让一组新的工程问题变得清晰：模型为什么挑选这项运维，根据是否可靠，行动是否越过边界，执行结果是否真的完成了现实目标？KDC 是我们尝试体系回答这些问题后构成的理论探究动机。
这项实践还暴露出几类不能只靠利器列表和调用日志解决的责任：系统不仅要知道数据是什么，还要判断哪些内容能够被信任和复用。不仅要记录模型触发了什么，还要解释它根据什么形成判断。不仅要使范式能够调用 Tool，还要治理模型为什么、以什么权限、在什么隐患条件下采取行动。行动之后，还要知道现实成效可否具备原来的判断。
这些问题分别可以由 RAG、Agent Framework、MCP、API Gateway、IAM、事务流和可观测体系处理其中一一块。但从我们的研究来看，这些机制一般分散在不同架构层和工程团队中，仍须要一个能够把它们放在同一条场景因果链中讨论的软件工程视角：
现实如何进入数字系统？
-> 数字表示如何形成可复用知识？
-> 知识如何支持可审计判断？
-> 判断如何转化为受治理的行动？
-> 行动结果如何反馈并修正系统？
我们把环绕这条链路展开的理论研究称为知识驱动核算。这个名称强调的并非”所有软件都应当由知识替代代码”，而是：在 AI 能够理解上下文文、形成判断并参与现实行动之后，知识、推理、能力、治理和反馈需要像代码、数据和接口一样，成为可以被明确设计和审阅的工程对象。
KDC 并不试图替代 DDD、RAG、MCP、Agent Framework 或既有管控体系。这些方法和机制分别解决领域建模、材料检索、范式连通、作业执行和安全治理等问题。KDC 关注的是：当它们共同进入一个 AI 应用时，怎样环绕现实目标构成一条连续、可追溯的工程链路。
所以，这项探究选择的第一个起点，不是 Knowledge，也不是 Agent，而是 Reality。因为在研讨系统知道什么、如何判断和怎样行动之前，须要先回答：这个应用软件究竟在面对什么？
三、应用软件切实面对的是领域现实
KDC 探究中所说的 Reality，并非一个没有边界的哲学概念，也不是要求软件描述整个物理世界。我们暂时把它当作一个项目概念让用：
在确定的系统界限和系统职责内，系统希望观察、建模、预测或影响的客观存在及其运转规律。
这里有两个必需限定。
第一是系统边界。比如电商体系不须要描述世界上的所有事物，它只需要关注与商品、使用者、交易、库存、支付、履约和售后有关的现实。
第二是系统职责。比如同一个订单，在交易体系、财务系统、仓储系统和客服系统中对应相异的责任边界。财务系统关注资金是否完成结算，仓储系统关注商品能否履约，交易系统关注订单可否成立。它们直面的是同一现实的相异切面。
在这个边界内，赛道现实至少可以从四个角度理解：
Reality = Object + State + Relationship + Dynamics
- 对象（Object）：系统关注的存在，比如使用者、商品、订单、库存、支付和物流。
- 状态（State）：对象在现实中的时期和条件，比如订单待支付、已支付、已发货、已退款。
- 关系（Relationship）：对象之间客观存在的关联，比如用户创建订单、订单含有商品、退款对应原支付。
- 动态规律（Dynamics）：状态和关系如何变化，与哪些约束不能被破坏，比如未支付订单不能进入履约，退款金额不能超过实际支付金额。
这四个维度的意义，不是提供另一套画图术语，而是迫使结构设计回答一个经常被跳过的问题：我们准备编码的数据，到底在说明什么？
以退款为例，切实的赛道现实并不只有一个 refund_status 字段。它至少涉及：
- 使用者提出退款诉求
- 订单与原支付记录之间存在有效关联
- 退款申请经过业务规范和风险判断
- 支付渠道接受退款请求
- 资金进入清算或原路退回流程
- 使用者账户最终收到资金
- 订单、售后、财务和用户通知状态得到对应更新
这里的每一步都可能由不同体系观察，也可能处于不并且间尺度。一个内部字段从 processing 变成 success，只解释某个体系对现实作出了某种判断，并不天然代表用户已经收到资金。
四、资料库保存的是表示，不是现实
现实进入软件体系，须要经过建模和编码。KDC 把这些数字编码统叫作说明（Representation）。
表示可以是：
- 资料库中的一行记录
- API 的请求和响应
- 消息队列中的事件
- 说明中的一段文字
- 记录和审计记录
- 对象范式或状态机
- 搜索索引、Embedding 或知识图谱中的节点和关联
- 提供给大范式的 Prompt 和上下文
因此，更完整的链路不是”现实径直变成资料”，而是：
Domain Reality
-> Reality Model
-> Representation
- Domain Model
- Data Model
- API / Message / Event
- Document / Log / Context
现实范式（Reality Model）位于现实和数字说明之间。它决定系统选择观察什么、忽略什么，如何切分对象，如何界定状态，如何表达关系，又如何判断一次变化真的发生了。
任何范式都必然是有挑选的。退款体系能够把状态简化为”申请中、成功、失败”，也可以进一步区分”渠道已受理、清算中、银行处理中、使用者已到账”。两种范式都可能合理，关键取决于体系职责。
假如系统只担责把退款请求提交给支付渠道，那么”渠道已受理”也许就是它的职责终点。如果系统向用户承诺”退款已到账”，那么它就须要可以观察更后面的现实状态。难题不在于状态多或少，而在于数字表达可否与体系作出的现实承诺相匹配。
可以用下面的方式理解现实与说明之间的差别：
这并不意味着数字说明不可信，反倒说每一种表示都有来源、观察范围、时间延迟和适用边界。结构需要知道一个字段”声称了什么”，也需要知道它”没有印证什么”。
从这个角度看，许多所谓的资料难题，其实第一步是现实映射问题：
- 我们可否遗漏了重要现实对象？
- 一个状态是现实发生、外部声明，还是系统推断？
- 多个体系对同一现实是否使用了不同界定？
- 某个字段在多长时间内仍可作为管用判断依据？
- 系统采取行动后，哪个反馈可以印证现实目标已经落地？
再完整的资料血缘和接口文档，也只能解释数字如何流动，假如这些问题没有在建模时期得到回答。
五、状态对路，不等于现实正确
老牌软件项目十分重视内部一致性。数据库事务保证一组写入同时成功或失败，消息机理保证事件稳妥传递，缓存策略减少不同副本之间的偏差，监控系统观察服务是否健康。
这些能力仍然重要。但它们主导化解数字系统内部的一致性。
应用软件还直面另一种一致性：数字体系对现实的描述可否仍然成立。
退款事务提交成功，可以证明资料库内部的退款单和订单状态按照规范发生了变化。它不能单独证明支付渠道早已处置，更不能证明使用者已经到账。接口返回成功，可以证明触发被对方体系接受。它不能单独证明最终场景结果已经出现。
便，应用软件的”对路”至少包含两个层次：
数字内部正确
+
数字表示与领域现实足够一致
前者关注事务、类型、API、链路和手段状态。后者关注现实对象、场景承诺、外部变化和成效反馈。
KDC 的中枢判断之一是：运用软件的最终参照物不是内部状态，而是现实。系统当然无法直接取得完整现实，只能通过传感器、人工确认、外部接口、场景事件和其他表示去观察它。但正因为只能间接观察，架构才更需要显式记录观察来源、适用边界和反馈条件，而并非默认数据库中的最新值就是现实本身。
六、一个说明偏差如何被放大为行动错误
前面的机理能够在退款案例中细化展开。LLM 和 Agent 系统会读取退款状态、客服记录和支付渠道响应，然后构成结论：”退款已经做完。”它还可能据此发送通知、关闭工单，或挑选后续行动。
范式擅长把分散说明组织成连贯解释，但连贯并不等于真实。如果上下文遗漏关键状态，或者不同系统对同一字段采用了不同语义，范式就可能得出超出证据范围的结论。
回到开头的退款样例。假设 Agent 看到了以下内容：
refund_status = success
gateway_response = accepted
ticket_status = processing
也没有带来到账反馈，它很或许把”渠道接受请求”解释为”用户已经收到退款”，假如系统没有告诉它 success 只代表退款请求被渠道受理。
难题不一定出在模型，也不一定出在API。更根本的问题是，系统没有把现实承诺、表示语义和校验反馈之间的关联表达清楚。
AI 体系一旦能够根据表示自主构成判断并参与行动，软件工程就必须多问三步：
- 模型看到的说明对应哪一一块现实？
- 这些说明足以具备什么结论，又不足以支持什么结论？
- 行动发生后，系统通过什么现实反馈确认目的早已实现？
这也是 KDC 从 Reality 开始，而并非从 Prompt、数据或 Tool 开始的缘由。只有先明确系统直面的现实，后续才能研讨哪些表示可以形成知识、哪些判断需要被审计，以及哪些行动可以安全执行。
七、KDC 与 DDD：不是替代，而是继续向运转时追问
领域驱动设计（Domain-driven Design，DDD）已经长久强调：复杂软件不能只围绕数据库表组织，而应围绕领域语言、限界上下文、实体、值对象、聚合和领域支撑建模。
KDC 认可并继承这个路径。DDD 提供了理解赛道语义的重要方式，也提醒小组不要让技术模型取代业务模型。
KDC 的关注点进一步延伸到 AI 运转时：
- 一个领域对象被范式理解时，引用了哪些知识？
- 模型形成判断时，依据来自哪里，可否仍然有效？
- 体系选择行动时，是否理解其对现实状态的影响？
- 行动完成后，什么反馈能够校正数字说明和后续判断？
DDD 能够辅助我们说明”订单是什么”、”退款属于哪个限界上下文”、”哪些状态迁移合法”。KDC 继续追问”AI 为什么相信这笔退款早已完成”、”这个判断能否被追溯”、”现实结果可否反过来修正了系统”。
因此，KDC 不替代 DDD，也不要求小组放弃既有赛道模型。它把 DDD 提供的领域语义当作重要来源，并在其上增加知识引用、运行时判断、行动管控和现实反馈的连续链路。
八、实践：尝试为一个业务链路画出 Reality Map
理解 Reality 最有效的方式，不是给现有架构增加一层抽象名词，反倒选择一个边界明确的业务流程，检查数字系统究竟在映射什么。
能够从退款、下单、核准、发货、合同审查或工程风险跟踪中任选一个。第一次练习不须要涵盖整个公司，也不需要立即修改系统。
第一步，写清体系界限和职责
先用一句话解释体系担责什么、不负责什么。
举个例子：
售后体系负责接收退款诉求、校验业务条件、发起退款并向用户反馈进度。现实资金清算由外部支付渠道和银行做完。
这句话会径直决定体系应该建模哪些现实，以及哪些现实只能通过外部反馈观察。
第二步，列出对象、状态、关联和动态规律
不要先打开表结构。先从业务现实写起：
第三步，把现实元素映射到数字说明
为每个重要现实元素找到当前体系中的表示：资料库字段、API、事件、文档规则、人工确认或外部回执。
并且记录三个信息：说明来自哪里、多久更新一次、它可以证明什么。
第四步，界定现实反馈
对每个重要行动追问：什么信号可以证明它在现实中产生了预期成效？
“API成功”通常只是落实反馈，不一定是最终现实反馈。退款情形中的现实反馈或许包括支付渠道状态、银行回执、对账成效、用户确认或超时后的人工核验。
第五步，构成映射缺口清单
重点寻找以下缺口：
- 现实中存在，不过系统没有表示的对象或状态
- 多个体系使用同一字段名，却表达不同含义
- 一个中间状态被错误命名为最终成效
- 表示已经过期，不过下游仍把它当作当前事实
- 行动只有技术返回，没有现实成效反馈
- 系统作出的承诺超出了它实际能够观察和验证的边界
最终产物能够是一张单页 Reality Map：
这张图的目的不是取代领域范式、资料模型或系统架构图，反倒把它们重新连接到现实。团队完成第一次盘点后，只需要挑选一个影响最大的缺口进入后续设计，不必一次性重构所有说明。
对于低语义、低风险、固定流程的简单自助化，也不必引入完整 KDC 范式。如果一个脚本只在受控环境中转换文件格式，输入输出确定，也不影响重要现实状态，那么传统API和测试早已足够。Reality Map 更适合那些涉及复杂业务语义、跨体系状态、外部行动或高左右判断的流程。
九、Reality Map 转变的，是架构提问的顺序
做完一张 Reality Map 后，团队得到的并不只是另一张业务拆解图。
它真正转变的是结构讨论的起点。以往，我们可能直接研讨退款状态应该如何定义、接口如何触发、消息如何传递。现在需要先确认：系统负责观察哪一段退款现实，对使用者作出了什么场景承诺，又能够借助什么反馈验证这个承诺已经兑现。
这里所说的”承诺”，不是一个新的理论对象，而是应用软件借助页面、接口、链路和服务向用户或其他系统表达的业务结果。比如，”退款申请已提交”、”支付渠道已受理”和”退款早已到账”，是三个相异强度的承诺。体系可以表达哪一种承诺，取决于它现实观察到了哪一段现实。
假如系统只能观察支付渠道是否受理退款，就不应该把这个中间成效表达为”退款已经到账”。假如系统向使用者承诺订单已经完成退款，就需要继续观察资金退回、对账或用户确认等后续反馈。
这也解释了”软件从现实起步”的项目含义。它不是要求小组放弃资料模型、API 或流程，而是要求这些数字对象能够追溯到系统所承担的现实职责：
- 这个字段在说明哪个现实对象或状态？
- 这个接口成功能够印证什么，又不能证明什么？
- 这次状态变化对应现实中的哪个流程？
- 系统对外表达”完成”时，根据的是内部执行成效，还是已经获得了现实反馈？
- 如果数字说明与现实不一致，哪个机制负责发现和修正？
当这些问题先被回答，数据模型才不只是内部存储结构，而变成赛道现实的数字表达。API也不只是调用入口，而变成体系观察或影响现实的通道。状态机也不只是字段迁移规则，而起步对应现实流程及其约束。
所以，Reality First 并并非用 Reality 取代 Data，而是重新确定推导顺序：
Domain Reality
-> Reality Model
-> Representation
- Data / API / Event / Document
我们仍然需要延续讨论字段如何定义、数据怎样流动、服务如何触发。区别在于，这些设计不再凭空从数字体系内部开始，而是能够向前追溯：它们为什么存在，表示什么现实，服务什么职责，又依靠什么反馈维持管用。
KDC 对运用软件的第一性判断能够压缩为一句话：
运用软件不会创造现实，它在数字基座之上说明现实、理解现实，并最终作用于现实。
所以，”软件并非从数据开始，反倒从现实开始”并不否定数据。它要表达的是：数据来源于对领域现实的建模，软件结构则是领域现实的数字化表达与延续演化。
不过这会带来下一个问题：如果数据库、文档、API、事件和向量都只是现实的表示，那么这些表示在什么条件下，才能真正变成系统可以信任和复用的知识？
十、理论边界与开放难题
本文关于 Reality、Reality Model 和现实驱动计算的表述，归于 KDC 当前阶段的理论推导，尚未经过充分的跨情形实践验证。现实模型如何形式化、现实覆盖边界如何度量，以及延续一致性如何验证，仍是后续研究问题。
： 本文采用
CC BY-NC-ND 4.0（署名-非商业性让用-禁止演绎） 许可协议。出处。
