用"基于任务的验证"检验本体真的好用
结构审查只能证明本体"在技术上正确"，证明不了"真的被人用好用"。这一篇教你用真实业务问题做演练，让人和 AI 代理都跑一遍，把可用性缺口暴露出来。
https://www.palantir.com/docs/foundry/ontology/ontology-design-validation/
原始标题：Ontology design validation
一句话速览
用"基于任务的验证"检验本体真的好用：结构审查只能证明本体"在技术上正确"，证明不了"真的被人用好用"。这一篇教你用真实业务问题做演练，让人和 AI 代理都跑一遍，把可用性缺口暴露出来。
结构审查的局限（limits of structural review）
结构对 ≠ 能用。这是验证要补的缺口。
结构审查（structural review）回答的是"本体在语义上连贯、技术上正确吗"：对象类型是否代表连贯实体、链接有没有意义的基数（cardinality）、多个类型是否该共享接口。它能防止不可逆的设计错误，但它评估的是模型内部完整性，确认不了实际可用性。
什么是基于任务的验证（task-based validation）
用真实问题，让依赖本体的人与代理实跑一遍。
基于任务的验证补上"能否被使用"的缺口：你用组织的真实业务问题，让未参与构建的人和AI 代理在通用分析工具里独立完成调查，从而验证本体的可发现性（discoverability）、表达性（expressiveness）与运维可用性（operational usability）。
去哪找真实业务问题（sourcing real business questions）
问题别编，从运营节奏里挖。
问题要从组织的运营节奏派生：领导反复在问什么？团队做决策前需要什么信息？哪些报告因为底层难整合而一直补不齐？保留那些"本体表达起来很别扭"的问题——它的失败本身就是设计缺失的信号。
把问题排成三层序列：① 确立情况（哪个客户 / 设施 / 资产）→ ② 追踪贡献因素（订单 / 事件 / 物料）→ ③ 评估影响（风险 / 干预点）。一层层追问，最容易暴露链接与聚合上的断点。
设计演练（drill design decisions）
工具、参与者、形式，三个决定先定好。
读懂结果：观察 → 该审查什么
记录分析路径比记录答案更有信息量；点开看每个观察对应哪条规则。
对每个问题，记录：是否正确回答、耗时、犹豫点、搜索词、试过的对象类型/链接、是否求助。特别注意手动导出 / 自建连接行为——它强烈暗示"业务里有关联，但本体没表示出来"。单次失败可能是边缘案例，重复出现的困惑才是系统问题。
| 观察到的现象 | 应审查的规则 / 反模式 |
|---|---|
| 无法识别起始对象类型 | The Misnomer |
| 同一概念选了不同对象类型 | Department Silos |
| 无法在相关概念间移动 / 手动导出或自建连接 | Link design |
| 合理路径得到不同答案 | Naming conventions |
| 仅构建者或技术用户成功 | System Silos |
| 合理路径持续缓慢 | Normalization and derived properties |
| 根本找不到合理路径 | 数据缺失 / 覆盖缺口 |
下面用点击方式复习一遍映射——读观察，点"点我看该审查什么"：
对比人与代理 · 把验证变成日常
人和代理各跑一遍，缺口在哪一目了然。
对比人与代理（comparing people and agents）：用 AIP Analyst / AI FDE 跑同样的问题，只给问题和本体访问权限、不提供人类路径。得到的矩阵很有用：
- 人和代理都成功 → 路径可发现，设计基本稳。
- 代理成、人败 → 检查人机界面、别名、视觉层次（人没找着的，代理靠语义找着了）。
- 人成、代理败 → 识别那些藏在人心里的隐式业务逻辑，考虑补进本体或文档。
- 人和代理都败 → 缺数据 / 缺链接 / 语义缺失，是本体层面的真缺口。
把验证变成日常（ongoing practice）：初始只需少量关键问题、代表参与者、通用应用即可。优先改"影响多道题"的高价值变更，重跑旧题测改进、引入新题测泛化。最终可把问题集发展为对本体的 evaluation suite（评测套件）。
互动：跑一遍验证演练（清单）
勾选你已完成哪几步，看看离一次完整验证还差什么。
一页带走
延伸阅读 · 相关页面
按主题横向跳转，不必顺着目录一篇篇读。
常见问题速答 · FAQ
关于「用"基于任务的验证"检验本体真的好用」，读者最常问的几个问题。