当 AI 应用开始在运行时解释数据、选择工具并影响业务状态时，数据表示中的遗漏和歧义可能直接转化为行动风险。vivo 肖博提出 知识驱动计算（Knowledge-driven Computing, KDC），核心主张是：软件不是从数据开始，而是从它试图观察、表示和影响的 领域现实 开始。
退款接口返回 HTTP 200，数据库事务成功执行，订单状态更新为"已退款"，客服后台流程结束。三天后，用户再次联系客服：钱还没有到账。
从系统内部看，一切正常。从用户面对的现实看，退款没有完成。
这类问题通常被归入最终一致性、外部渠道延迟或对账异常。但在这些问题分类之前，还有一个更基础的问题：应用软件中的状态，究竟是不是现实本身？
refund_status = success、gateway_response = accepted、事务提交成功。传统系统并不是只依靠数据运行。程序员在设计阶段把数据的语义、适用条件和例外处理写进确定的执行路径。数据表示即使不完整，代码和人工流程仍可补上缺失的解释。
AI 应用改变的正是这个前提。
数据表示 → 预先编写的解释逻辑 → 固定条件分支 → API 调用。语义由开发者在设计阶段确定，路径固定。
多种表示 → 模型在当前上下文中解释 → 运行时判断 → 动态选择行动。语义解释和行动选择被移动到了运行时。
这里新增的风险不是"大模型可能读错一个字段"，而是：表示层中的问题会沿一条更短、更动态的路径进入现实行动。模型接收到的通常不是完整现实，而是多个系统留下的局部表示；它需要在运行时自行拼接这些表示，形成的解释可能直接影响下一步行动——而 Tool 调用成功还会制造一种额外的确定感。
注：表示偏差并非 AI 时代才有，传统系统也会遭遇脏数据和状态延迟。AI 带来的变化在于：系统开始动态解释更多异构表示，判断路径不再全部预先写死，且判断可以更快地转化为行动。
KDC 研究中所说的 Reality，是一个工程概念：在确定的系统边界和系统职责内，系统希望观察、建模、预测或影响的客观存在及其运行规律。
领域现实至少可以从四个维度理解：
注：四个维度的意义不是提供另一套画图术语，而是迫使架构回答一个经常被跳过的问题——我们准备编码的数据，到底在表示什么？
现实进入软件系统，需要经过建模和编码。KDC 把数字编码统称为表示（Representation）。完整的链路是：
数据库保存的是表示，不是现实。每一种表示都有来源、观察范围、时间延迟和适用边界。架构需要知道一个字段"声称了什么"，也需要知道它"没有证明什么"。
状态正确，不等于现实正确。
应用软件的"正确"至少包含两个层次：数字内部正确（事务、类型、接口、流程） + 数字表示与领域现实足够一致（现实对象、业务承诺、外部变化、结果反馈）。系统的最终参照物不是内部状态，而是现实。
理解 Reality 最有效的方法，不是给现有架构增加一层抽象名词，而是选择一个边界明确的业务流程，检查数字系统究竟在映射什么。KDC 提供了五步实践：
注：Reality Map 不取代领域模型、数据模型或系统架构图，而是把它们重新连接到现实。团队完成第一次盘点后，只需选择一个影响最大的缺口进入后续设计，不必一次性重构所有表示。
AI 应用时代，软件工程必须多问三步：模型看到的表示对应哪一部分现实？这些表示足以支持什么结论？行动发生后，通过什么现实反馈确认目标已经实现？——KDC 的价值不在于提供新术语，而在于把"表示与现实的关系"从隐性问题变成显式工程对象。
KDC 目前仍处于开放研究阶段，尚未经过充分的跨场景实践验证。现实模型如何形式化、现实覆盖范围如何度量、持续一致性如何验证，仍是后续研究问题。
研究团队正在围绕电商流程完成验证，后续将逐步公开更多实践细节与工具链。