实证

十二 · 反模式与落地判据

五种死法、六条判据、分阶段路线

本体项目失败的方式相当固定。它们极少死于技术选型错误，绝大多数死于四种非技术原因：建得太大、没有校验、没有维护预算、以及被当成 AI 项目立项。这一章给五种死法的识别特征、六条可以当场用的判据，以及一份分阶段路线。

五种死法

症状：项目名是「企业级知识模型」「统一语义平台」；第一个交付物是一张有两百个类的图；六个月后仍在讨论「客户的定义」。

机制：全量建模把「对齐分歧」放在了「产生价值」之前。而分歧的收敛速度与参与人数成反比，与是否有一个真实问题要解决成正比。没有具体问题的建模会议，本质是在用抽象讨论消耗预算。

识别：如果第一次评审的议题是「类怎么划分」，而不是「这个查询能不能跑出来」，已经在路上了。

解药：从一个小域开始，两周内跑通「一类对象 + 五条约束 + 一次被拒绝的动作 + 一张对账报表」的闭环。

症状：先选了一个图数据库/本体平台，然后开始找「用它能做什么」；选型依据是 benchmark 与 Gartner 象限。

机制：工具决定的是「上限」，需求决定的是「下限」。先定工具会导致模型被工具的表达力塑形——用属性图的人倾向于把语义压成属性，用 OWL 的人倾向于把约束写成公理。两者都会在半年后暴露：前者发现做不了推理，后者发现没人执行校验。

识别：技术选型文档里没有一节叫「我们不做什么」。

解药：先写 20 条 competency question，再从问句推出需要的表达力（第 3 章的决策树），最后才选工具。

症状：模型很完整、文档很漂亮、图很好看，但没有任何一条规则会让流水线变红。

机制：这是最常见的一种，也是最隐蔽的一种——因为它在交付时看起来完全成功。代价延迟 3–9 个月出现：下游开始出现「同一指标两个值」，此时已经无法定位是哪一次变更引入的。

识别：问一个问题就能判断——现在改一条约束，会不会有人被通知、会不会有构建失败？ 两个答案都是「不会」，就是缺位。

解药：把「有非零退出码的校验」作为第一期的验收条件，没有它不算交付。

症状：上线时隆重，上线后一个月无人提交；半年后有人想改，发现原作者已离职。

机制：本体的成本结构与软件不同——它的主要成本不在建设，在维护。一个 15 个类的模型，稳态每月需要约 0.2 人月（口径变更、豁免审批、违规处理）。拿不出这笔预算的项目，会在第 12–18 个月退化成「谁都不敢改」的遗留资产。

识别：项目章程里有没有「上线后每月 X 人月」这一行。没有，就是没有预算。

解药：在立项时把维护预算写进章程；如果拿不到，就只做第 10 章的 A 形态（不引入新存储与端点，纯生成物 + 校验流水线），它的维护成本接近于零。

症状：立项理由是「大模型需要企业知识」，KPI 是「问答准确率提升」；三个月后被要求证明「为什么不用向量库就行」。

机制：把本体绑在 AI 叙事上，会让它的价值随模型能力波动。模型越强，纯检索的效果越好，本体的边际收益越难证明——而本体真正不可替代的部分（拒绝非法写入、口径可对账、变更可审计）恰好不在这个叙事里。

识别：如果需求文档里出现「让模型理解我们的业务」而没有出现「让某个字段必须有值」，方向就偏了。

解药：把立项理由换成治理语言：口径统一、坏数据拦截、变更可审计。这三件事的验收可以当场演示，且不随模型能力变化。

这六条可以在一次会议上问完，用来判断「该不该做」与「做到什么程度」。

第 6 条最容易被跳过，也最能预测结局。一个不会再被修改的模型，无论建得多好，都只是文档。 而文档不需要本体工具链。

比「该不该做」更难的是「什么时候停」。三个明确的停止信号：

一、连续两个迭代，校验报告的违规数没有下降，且新增违规主要来自新增规则而非存量修复。 这说明规则在被不断放宽以适配现实，模型正在失去约束力。此时应该停下来，把规则数量减半、把豁免流程做起来，而不是继续加规则。

二、业务方连续两个月没有提出新的 competency question。 说明当前的表达力已经覆盖了他们的想象力，继续扩建是自我满足。

三、维护者的时间有 70% 以上花在「解释模型」而不是「修改模型」。 这是「表达力过剩」的明确信号：模型比使用者能理解的要复杂。此时应该做减法，而不是写更多文档。

如果判据都过了，按这个节奏走：

第 0–2 周：一个闭环 选一个域，12–18 个类，5 条必须为真的约束，100–500 条真实数据，一次可拒绝的动作，一张对账报表。验收标准：业务方能当场看到一条坏数据被挡住。

第 3–6 周：把校验接进流水线 校验进 CI，退出码非零；三档严重级别；带期限的豁免机制。验收标准：一个故意的坏提交会被拒绝合并。

第 7–12 周：第二个域，以及复用 第二个域接入，检验第一版的抽象是否成立。此时通常会发现 30% 的类需要重构——这是正常的，越早越好。验收标准：两个域共享同一份源模型，而不是两份。

第 4–6 月：治理与变更 变更影响面计算、弃用流程、查询日志。验收标准：能回答「上周的变更影响了哪些下游」。

第 7–12 月：表达力按需扩张 只有在出现「必须推出新事实」的真实需求时，才引入推理层。验收标准：推理层的引入有明确的、可测量的收益，而不是「架构上更完整」。

本体项目的成败，在写第一行模型之前就决定了 70%：取决于你有没有一个具体的错误要修、有没有人能裁决、有没有人会在三年后继续改它。剩下的 30% 才是技术与工具。