KDC（Knowledge-driven Computing）系列文章来到第二篇。vivo 工程师肖博用「活动订单取消」场景指出：RAG 链路全程无故障，系统仍因一份过期政策给出错误答复——因为「材料可以被找到」与「系统知道了什么」，从来不是同一个问题。
用户向售后 Agent 提问：「我在活动期间购买的商品还没有发货，现在取消订单会收手续费吗？」
系统从企业知识库中检索到一段高度相关的退款政策——「活动订单取消时，需要收取一定比例的服务费」。检索得分很高，引用片段与问题直接相关，模型也忠实地依据片段生成了回答。
但答案是错的。
被检索到的是半年前的旧版政策。新政策早已取消这笔费用，只是旧文件仍保留在共享目录里，也仍然存在于向量索引中。新旧政策标题相似，旧版文字与用户问题的语义匹配甚至更高。
从 RAG 链路看，这次处理没有明显故障。但「系统找到了相关材料」与「系统获得了当前可用的知识」之间，隔着一整套被省略的责任。
注：这是 KDC 反复强调的一个区分——召回系统完成了自己的职责，真正缺失的是知识治理环节。
在给知识下定义之前，更可靠的方法是先检查那些经常被叫做「知识」的对象——为什么它们不能直接等同于知识？
它们都以不同方式编码现实，但都缺少同样一组东西：来源、证据、版本、有效性与适用边界。这些才是让表示升级为知识的工程条件。
KDC 当前给出的定义是：
知识（Knowledge）是已经验证、可复用，并能够降低预测、推理、决策或行动不确定性的认知成果。
这个定义包含四个不可省略的部分——它不是对「知识」的哲学竞逐，而是给 AI 应用软件一个可以进入工程设计的操作性边界。
不是现实本身，不是原始数据，而是对事实、规律、方法、经验、约束形成的认知性把握。「订单金额 1000 元」是记录；「该订单满足无手续费取消条件」是认知。
获得证据、实践、规则、共识或人工确认的支持。模型说得流畅不是验证，相似度得分高不是验证，被很多人转发也不是验证。
在明确条件下被未来任务再次引用。可复用不意味着无限泛化——没有边界边界的「知识」最容易被错误场景复用。
知识之所以有价值，是它让后续判断少一些不确定。若内容被保存、检索、展示，却不能帮助任何后续判断，称它为知识对工程没有帮助。
注：KDC 明确说明这是当前阶段的理论定义，成熟度为 Derived，目标不是解决认识论问题，而是给出工程设计边界。
要求所有内容在进入系统前就达到最终确定状态，并不现实；把所有模型输出直接写入知识库，同样危险。KDC 因此引入知识成熟度（Knowledge Maturity）：
这不是单向升级。新证据可能让已验证知识回退为候选，证据被推翻就会回到假设，现实变化会让知识过期。成熟度真正重要的地方在于：它能够改变系统行为。
触发搜索与验证——尚未形成可复用认知，但值得投入探索。
进入低风险推理——有初步支撑，但还不能支撑关键决策。
支撑稳定决策——经过证据、规则或实践确认。
高风险行动仍需更强证据与人工确认——正式制度与权威经验可以进入高影响链路。
在开头的退款案例中，旧政策并没有「从世界上消失」。它仍是历史材料，可以用于解释过去的订单；但对于当前退款判断，它应被标记为过期或被新版本替代，而不是与现行政策以相同权重进入上下文。
知识进入软件，还需要成为可管理的对象。
KDC 把这种对象化表达称为知识对象（Knowledge Object）。它不是一种固定数据库 Schema，而是一组不能继续隐含的工程责任。一个可被运行时引用的知识对象，至少需要考虑：
在退款场景中，系统不应只把「活动订单取消需收取服务费」作为一段文本保存。它还应该知道：这是哪个版本的规则、谁发布、何时生效、适用于哪些活动、与哪条新政策冲突、当前是否仍有效。
明确知识边界，并不会削弱 RAG 的价值。恰恰相反，它能让我们更准确地使用 RAG。
在 KDC 中，RAG 更适合被定位为知识流或知识运行时的局部机制——它负责材料召回和上下文装配，可以与知识图谱、规则系统、文档管理协作，但不必独自承担整个知识生命周期。
开头的错误因此有了更准确的归因：不是「向量检索完全没用」，而是系统只按相似度召回片段，没有在检索前后加入版本、有效期、冲突和适用范围过滤。修复方式也不只是继续调切块大小和相似度阈值。
团队不需要先建设完整知识平台，也不应把所有数据「知识化」。更现实的起点，是选一条会被重复使用、可能影响重要判断、一旦错误就产生明显风险的内容——它可以是一条退款规则、一项审批条件、一份合同风险判断，或一个客户偏好。
先检查六个问题：
完成后，不要默认它一定要成为知识对象。团队应做出三个明确判断之一：
高价值、可复用或高风险，值得进入知识生命周期。
材料有价值，但尚未形成稳定认知成果，先留作底档。
噪声高、边界模糊，治理成本大于复用收益。
Knowledge Card 的价值不在于表格本身，而在于把「我们有这份文件」改写为「系统知道什么、为什么相信、什么时候可以使用」。
如果团队发现来源、证据、适用边界和成熟度大多无法填写——这不是要求立刻补齐字段，而是在提醒：当前系统管理的可能仍然只是材料和表示，尚未形成可以进入重要判断的知识。
RAG 最大的风险不是「找不到」，而是让团队误以为「找到了就等于懂了」。
当旧政策进入上下文并成为回答的依据，错的不在向量，而在于系统给「版本」和「来源」留的位置太少。AI 应用工程化的下一站，不是更大的知识库，而是让每条高价值认知都拥有证据、边界与失效时间。
不需要搭建新的知识平台。复制上面的六问，拿一条业务规则作试点——
如果连「谁发布、何时生效、当前是否有效、适用于谁」都答不上，
它暂时只是材料；答得上来，它才开始接近知识。