从文档到可计算的认知资产

一、文档为什么不再是理想的知识组织单位

传统知识管理主要以文档为中心。一份文档既承载知识内容，也负责组织内容之间的关系，并提供供人阅读的呈现形式。文件夹、目录、链接、引用和各种图表，则帮助人们在大量文档之间建立联系。

这种方式符合人类的阅读与写作习惯，但存在一个长期被忽视的问题：知识的定义、关系和呈现，被绑定在具体文档中。

例如，一个业务概念可能同时出现在概念说明、业务架构图、部门职责定义、需求映射表和系统设计文档中。这些地方实际上引用的是同一个概念，却经常需要分别维护。当概念发生变化时，相关文档必须逐一更新；随着内容及关联关系不断增加，维护成本持续上升，也容易产生定义漂移。

文档还将知识组织与特定呈现形式绑定。一份层级说明适合阅读分类结构，却不适合观察复杂关系；一张关系图适合展示关联，却无法容纳详细解释；一份映射表适合检查覆盖情况，却难以表达完整的业务运行逻辑。如果需要不同视图，往往只能重新组织甚至复制内容。

因此，问题并不在于文档不能表达知识，而在于它同时承担了知识存储、关系维护和视图呈现三种职责。过去，这些工作主要依赖人类维护，文档的灵活性足以弥补其中的不足；当 AI 开始参与持续性的知识生产时，我们就有机会重新设计这些职责之间的关系。

二、脱离文档之后，知识可以如何组织

要摆脱文档的约束，首先需要回答一个更基础的问题：脱离具体文档之后，我们究竟要保存和维护什么？

知识不能简单等同于文本段落，也不只有业务对象、属性和关系。在认知生产中，至少存在几类值得独立表达的知识单元。

概念（Concept）用于定义和区分我们所认识的事物、现象或抽象范畴，例如业务需求、能力、职责、任务和承载。概念需要具有相对稳定的身份，以支持跨文档、跨系统和跨视角引用，但稳定身份并不意味着定义永远不变。概念边界仍然取决于建模目的、业务域、观察视角和分辨率，并允许随着认知演进而调整。

命题（Proposition）表达关于概念、对象或现象的判断、关系和规律。例如，“企业所处的产业位置与经营边界决定其适用的业务需求”“同一种业务能力可以由不同的承载组合实现”“业务表单不等于业务对象”，都是可以独立讨论、引用和继续推导的命题。概念回答我们在谈论什么，命题则回答我们认为关于它的什么判断成立。命题可以具有适用条件、推导依据、支持证据、竞争性解释和开放问题，不必全部压缩为简单的三元组。

关系（Relation）连接概念、命题及其他知识单元，表达组成、细化、依赖、支持、解释、派生等不同含义。关系的类型、方向和成立条件会影响后续推理，因此不能因为两项内容存在关联，就统一使用一个含义模糊的“相关”关系。

证据（Evidence）与案例（Example）为命题提供支持、挑战或解释，并保留来源与上下文。案例能够帮助理解抽象原理，但不能因为某种现象在一个案例中出现，就自动将其提升为普遍规律。

这些知识单元可以分别拥有稳定标识，通过明确的关系相互连接。它们不要求所有知识都立即被拆解为独立记录，而是为知识的持续积累提供更细的组织粒度。

这样，同一个概念可以出现在多篇文章中，同一个命题可以被多个案例支持，也可以参与不同的理论推导，而不需要复制出多份相互独立的定义。

知识的组织单位由文档进一步下沉到概念、命题及其关系，文档则成为组织和表达这些知识的一种方式。

三、结构化、自然语言与已有的中间表征

结构化数据和自然语言分别具有鲜明的优势，也各有局限。

数据库等结构化系统能够明确身份、属性、关系和约束，支持查询、计算和自动检查。但结构化表达需要提前确定数据类型和组织方式，而知识探索中经常存在尚未稳定的概念、正在形成的命题，以及多种可能的解释。过早固定结构，可能为了适应数据模型而压缩甚至扭曲原有知识。

自然语言具有更高的表达灵活性，能够容纳解释、假设、条件、争议和开放问题，却缺少明确、稳定的机器可计算结构。同一个概念可能有不同表述，许多关系隐含在文字中，后续参与者需要反复恢复它们的语义。

不过，人类的认知与协作从来就不只依赖这两种形式。

在此前的《Word、Excel、PPT：被忽略的基础设施》中，我讨论过三类基础工具所承载的不同信息结构：Word 主要组织线性文本，Excel 通过行列、字段、公式和引用组织信息，PPT 则提供能够自由组合文字、图形与空间关系的画布。它们之所以被广泛使用，正是因为不同的信息结构需要不同的外部表达方式。

进一步观察日常工作中的各种图表，会发现人们其实已经创造了大量介于自由文本与严格结构化数据之间的表征形式。

这些形式并非严格意义上都属于同一种“半结构化数据”，但它们有一个共同特点：通过专门的表示方式，将自然语言中隐含的部分结构显式表达出来。

例如，流程图保留了活动的顺序和分支，关系图突出对象之间的连接，状态机强调允许发生的状态转换。相比纯文本，它们能够更直接地表达特定结构；相比严格的数据模型，它们通常又保留了更大的表达自由。

然而，表达出结构，并不等于建立了可计算的语义结构。

PPT 中两个方框之间的一根箭头，可以表示依赖、调用、传递或影响。如果没有明确的语义定义，机器即使识别出了箭头，也未必知道这条关系意味着什么。不同图中出现的“职责”，也未必具有能够互相对应的稳定身份。

这些表征擅长让人看懂，但它们之间的语义联系，仍然经常需要人来恢复和维护。

因此，我们不需要发明一种万能格式来替代所有图表，而是需要让不同表征在保留自身优势的同时，能够引用共同的知识定义，并支持进一步的计算、检查和转换。

这一问题与此前《表征｜AI 能理解什么，取决于世界如何被表示》中的讨论直接相关。表征始终是对现实的有目的选择，不同形式适合保留不同类型的差异。真正需要解决的，是这些差异如何在多个主体、多个表征之间获得稳定的对应关系。

四、Cognitive IR：连接知识与不同表征的中间层

Cognitive IR（认知中间表征）的目标，是将协作需要的知识、判断依据、规则和关系外化为可共享、可检查、可复用的表达。

它不以还原人类或 AI 内部完整的认知过程为前提，而是关注能够支持持续协作的外部认知结构。不同主体不必拥有完全相同的内部理解，只要能够对共享的概念、关系、状态、约束和结果建立可靠引用，就有机会在不同任务中接续工作。

在《从共享表征到可计算世界》中，我已经讨论过白板、图表与 Cognitive IR 的关系，以及共享表征如何进一步发展为能够承载状态和行动的数字环境。这里继续关注其中的工程问题：如何在保持表达灵活性的同时，让知识拥有可计算、可维护的结构。

Cognitive IR 不等于某种特定文件格式，也不是要求所有知识最终进入数据库。以当前的轻量工程实践为例，可以区分以下几个层次。

### 元模型与 Schema：语义定义和结构约束

元模型（Metamodel）定义用于描述某一类世界的基本概念、关系与建模规则。 例如，在业务建模中，需要明确需求、能力、职能、职责、对象、任务等概念的含义，以及它们之间允许存在什么关系。

元模型属于语义层，可以使用自然语言、结构化定义和形式化规则共同表达，并不等同于数据库结构或某份 JSON Schema。

Schema 定义某一类结构化记录应如何组织，以及必须满足哪些结构约束。 例如，概念记录可以具有 ID、名称、定义和来源引用，关系记录可以包含关系类型、源节点和目标节点。Schema 可以进一步规定字段类型、必填条件、允许值及部分形式化规则。

两者的区别在于，元模型回答“这些概念和关系在业务上意味着什么”，Schema 回答“它们在特定数据结构中如何被记录和约束”。同一个元模型可能对应多类 Schema，而 Schema 校验通过，也不能直接证明业务定义正确或某个命题成立。

因此，Schema 应该随相对稳定的建模需求逐步形成，而不是反过来要求仍在探索的知识提前适应固定字段。

### Markdown 与 JSON：自然语言和结构化内容

Markdown 适合承载理论说明、概念解释、命题推导、案例、证据及开放问题。它保留了自然语言的表达能力，同时具有轻量、可引用和便于版本管理的优点。

JSON 则适合保存具有稳定身份和明确结构的内容，例如概念记录、命题记录、关系、来源引用及必要的规则配置。Schema 约束这些记录如何组织，JSON 保存相应的实际内容，而记录的业务语义仍然来自元模型和相关定义。

同一个概念可以同时关联 Markdown 中的详细解释与 JSON 中的结构化定义，不需要将全部自然语言转换成字段。对于尚未稳定的关系或判断，也可以先保留为带有来源与确认状态的候选内容。

这种渐进式结构化方式，使知识能够在尚不完整时参与工作，又不必牺牲后续计算与复用的可能性。

### HTML：按需生成和操作知识视图

HTML 与 JavaScript 可以根据结构化记录及相关自然语言内容，生成不同的可交互视图。

它们不必承担知识定义的权威存储职责，而可以负责展示、浏览、交互、编辑和辅助检查。视图在需要时从相应知识来源生成，修改也应当回写到拥有相应定义的权威位置。

因此，`Markdown + JSON + Schema + HTML` 可以成为 Cognitive IR 的一种轻量工程组合：Markdown 保存开放表达，JSON 保存稳定结构，Schema 提供结构约束，HTML 负责组织视图，而 LLM 参与不同表达之间的理解、转换、推理和一致性检查。

这并不是一套必须采用的固定技术栈。它真正体现的设计原则，是把语义定义、结构约束、内容存储和视图呈现分别组织，再通过明确引用使它们协作。

五、同一份知识，生成不同的视图

这种设计带来的直接变化，是知识的定义与呈现可以分离。

以业务概念“职责”为例，它可以同时出现在职能层级图、职责—对象关系图、需求覆盖矩阵和职责说明文档中。过去，这些内容往往需要分别维护；现在，它们可以引用同一个概念 ID 及相关关系，根据不同任务生成相应视图。

整个过程可以概括为：

1. 共享认知结构

   概念 · 命题 · 关系 · 规则 · 证据 · 案例

2. 按业务域、视角、分辨率和意图选择内容
3. 生成不同的视图

   概念列表 · 层级树 · 关系图 · 映射矩阵 · 流程图 · 状态机 · 时间线 · 文档视图 · 检查视图

这意味着，用户需要研究概念结构时，可以查看概念关系图；需要检查职能和对象之间的覆盖情况时，可以切换到映射矩阵；需要理解某项业务如何执行时，则可以查看任务和状态的变化。知识定义没有因为视图变化而被复制，不同视图只是对相同知识来源的不同选择与组织。

### 一个更直观的例子：企业产品资料

企业产品介绍是一个非常典型的场景。

一家制造企业的同一个产品，可能同时存在于研发部门的产品定义、技术部门的规格参数表、销售部门的产品介绍、市场部门的宣传册，以及官网、选型手册和客户方案中。这些资料面向不同的读者，关注的内容各不相同，但理论上必须保持一致：产品是什么、有哪些型号和配置、具备什么能力、性能参数是多少、哪些场景适用，以及对外可以作出什么承诺。

现实中，这些资料却常常由不同部门分别维护。产品设计发生变更，技术参数首先更新，销售仍然使用旧版本的介绍，市场部门的宣传册又有另一套描述。即使企业已经建立了文档库，真正困难的事情也没有消失：谁来判断哪些资料受到影响，哪些描述需要重新确认，以及怎样保证不同渠道的内容始终一致？

这类问题并不能仅靠文档检索解决。RAG 可以帮助 AI 找到分散的产品资料并回答问题，但如果资料本身存在版本差异或定义冲突，检索并不会自动消除这些问题。

换一种方式，可以先建立具有稳定身份的产品定义，将产品系列、型号、配置、技术参数、功能能力及适用条件等内容组织成结构化模型，并让它们与产品说明、试验依据、使用案例和已经确认的卖点建立明确关系。

这样，规格参数表不必作为一份独立维护的产品知识副本，销售介绍也不必从另一份文档重新录入技术信息。它们可以根据不同的使用目的，从共享产品模型中选择、组合和生成内容。

例如，同一份产品定义可以产生不同的交付物：

其中，技术参数可以依据已确认的产品定义生成，卖点和客户价值则需要结合目标场景进行判断，并保留相应的证据、适用条件及审核结果。模型驱动不意味着宣传内容可以绕过业务判断，而是让这些判断能够关联到具体的产品事实，避免各部门反复从零组织和核对资料。

更重要的是，当某个型号的技术参数或适用范围发生变化时，系统可以沿着关系识别受影响的产品介绍、选型规则和宣传内容，对可直接确定的部分重新生成，对需要人工判断的部分提示复核。历史版本也可以保留，以区分当时已经发布的内容与最新定义。

在这种模式下，企业不再主要依靠多个部门维护若干份彼此对应的产品文档，而是维护产品知识及其关联，根据不同用途直接生成所需内容。

这就超出了传统知识库或 RAG 的主要使用方式。知识库通常以保存和检索已有资料为出发点，而模型驱动的内容生产可以直接从相对稳定的知识结构生成交付物，并在定义变化时追踪影响。RAG 仍可用于获取补充资料、案例和非结构化信息，但不必成为每次重新拼接产品知识的主要机制。

产品介绍只是一个容易理解的例子。同样的方法也可以应用于产品说明书、内部培训材料、业务制度、架构文档和其他需要多方维护一致性的知识产物。

### 从实体身份到概念身份

这种思想与我此前在设备管理中使用的“设备身份稳定，视图按需组装”原则一致。

在《设备字段越加越多，为什么人和 AI 还是用不明白？》中，我讨论过为什么同一台设备在资产、维修、质控和经营分析等场景下，需要不同的信息组织方式。设备的身份并不随使用场景变化，但使用者关注的业务关系、历史和操作入口会发生变化，因此没有必要把所有信息塞进同一张设备详情页。

将这一原则迁移到认知层，设备实例可以换成概念，业务属性和关系可以换成定义、命题与语义关系，而不同业务视图则对应不同的知识视图。

两者仍然存在区别：设备身份通常由业务标识规则确定，概念边界则取决于建模目的、视角和分辨率，可能随认知发展而重新划定。稳定标识是为了支持持续引用与演化，而不是要求所有视角共用一个万能概念。

视图不再是需要单独维护的知识副本，而是对同一知识结构的不同投影。

对于单一权威来源生成的视图，定义或关系更新后可以重新生成相关表达，从而减少手工同步造成的漂移。对于独立演进的不同项目，则可以通过引用、映射和一致性检查建立联系，而不必强制集中存储或共享同一套 Schema。

类似的思路也可以延伸到不同层级的架构模型。例如，《从业务、产品到代码，三张可互算架构图》讨论的，就是让业务要求、产品能力和技术实现之间具有明确映射，使不同架构视图不再仅靠人工对照维护。

六、从保存文档到持续运行的认知生产

过去，自然语言与结构化系统之间存在明显断层。人们在文档中讨论业务，再由分析人员将结果转换为字段、数据模型和系统规则。业务发生变化后，又需要人工判断相关文档、数据库和应用应如何修改。

LLM 为连接这些过程提供了新的能力。它可以阅读 Markdown 中的概念定义与建模原则，结合已有元模型识别知识单元，提出 JSON 记录或 Schema 调整建议，并检查结构化表达是否遗漏了原文中的重要语义。人和 AI 还可以借助不同视图发现关系缺失、概念冲突或新的推导方向，再将这些发现反馈到原有知识体系。

这使知识生产有机会形成持续循环：

自然语言探索 → 知识外化 → 按需结构化 → 计算与多视图呈现 → 实践反馈 → 知识演化。

这个过程并非单向转换。人在观察关系图时可能发现新问题，AI 在设计 Schema 时可能识别出原有概念尚未明确的区别，真实业务案例也可能要求修改之前的建模规则。不同表征相互补充，知识结构则在持续使用中演化。

在实际工程中，可以先使用轻量项目承载这一过程。Markdown 保存理论与设计说明，JSON 保存结构化模型，Schema 提供必要的检查约束，HTML 生成浏览与操作界面，Git 管理版本，AI 则可以读取整个项目并参与后续工作。

这种环境不要求一开始就建立庞大的统一知识平台。不同项目可以保持独立的文档、模型和实现，再通过显式引用与一致性检查协作。一个项目中的新知识可以反馈给通用元模型，元模型也可以反过来帮助分析不同项目中的概念和关系，而不必将所有内容复制到同一个地方。

更进一步，当知识结构具有稳定的引用、清晰的关系和可维护的来源后，过去散落在聊天记录、文档、图表和系统中的内容，便有机会逐步进入相应的知识与生产环境。它们不再只是供人回顾的历史资料，而可以成为后续 AI 分析、设计、判断和执行的输入。

这正是认知资产与静态知识存档之间的关键区别：知识不仅能够被保存，还能够被不同主体继续使用，并在使用中获得修正和扩展。

结语

传统文档的主要局限，不是表达能力不足，而是知识定义、关系和呈现高度耦合，使维护成本随着内容和关联复杂度不断增长。纯结构化系统具有计算优势，却难以独自承载开放、复杂和持续演化的知识；各种图、表、树与流程则能够表达不同结构，但如果缺乏稳定语义，仍然依赖人来维护它们之间的联系。

Cognitive IR 试图连接这些原本割裂的表达方式，让概念、命题、关系及其依据能够被不同主体持续引用、检查和使用。自然语言保留开放的解释空间，结构化数据提供稳定的身份与关系，Schema 提供必要的结构约束，不同视图则根据当前认知任务按需生成。

当这些机制逐步建立，知识管理便有机会从维护大量静态文档，转变为维护一个能够被人和 AI 共同理解、计算、检验和发展的认知环境。

我们需要的不只是保存知识的容器，而是让知识能够持续参与创造的生产系统。