ONTAO 理论体系 · 第零篇：痛点缘起
为什么建立这套体系——不是从概念出发，是从实战的痛出发。
这一篇是整个体系的"根"：后面六篇理论，都是对症这些痛点的药方。
一、体系的起点：不是 Palantir，是五洲的痛
我们接触到 Palantir 本体论时，正确的第一反应不是"这个概念很酷，值得研究"，而是：
"我过去在五洲开发中反复撞上的那些问题，原来有一个体系性的解法。"
痛点驱动，不是概念驱动。先有痛，后有理论——这是 ONTAO 的立身原则，也是它与"空中楼阁"式 AI 战略的根本区别。
二、七个真实痛点（来自五洲开发实战）
| # | 痛点 | 症状 | 不解决的后果 |
|---|---|---|---|
| 1 | AI 没有全局上下文 | 本马每次会话靠拼凑碎片（memory/skills/历史检索）理解五洲，从来没有一次看到整张图 | AI 永远"半懂"，新场景靠猜，老坑反复踩 |
| 2 | AI 无法安全行动 | 商用系统，AI 改错就是事故；红线靠文档约束，但文档管不住边界 | AI 只能看、只能建议，永远推不动业务 |
| 3 | 隐性规则在老板脑子里 | "新上游接不接、供应商停不停、客户争议怎么判"只有老潘能拍板 | 决策瓶颈在人，体系没有"判断能力" |
| 4 | 含糊问题没有答案 | "重要客户""已成交""异常"各团队理解不一，从没被逼出可判定的定义 | 再聪明的 AI 也只能在混乱的管理体系上加速 |
| 5 | 经验靠人传 | 五洲的知识散在 memory/skills/方案文档/人脑里，换人=重来 | 组织能力无法沉淀，永远依赖个别核心人 |
| 6 | 多项目不沉淀 | 每个新项目从零开始，能力不跨项目复用 | 重复造轮子，规模不产生复利 |
| 7 | AI 答案要人搬运 | AI 查得到数据、给得出答案，但员工仍要复制到群里确认、开会审批、手动操作 | AI 只是聊天助手，不是协作者 |
三、痛点的共同根源：三重分散
七个痛点背后是同一个病根——分散：
信息分散 数据/规则散在 CRM、ERP、Excel、微信群、老员工脑子里
（Palantir 插单案例：客户/回款/毛利/原料/产线/赔偿/审批各在各处）
认知分散 AI 的记忆是碎片化的，没有全局视图
（本马知道"三率是什么"，不知道"三率在系统里处于什么位置"）
能力分散 规则和拍板权在老板脑子里，AI 无法执行，体系没有判断能力
本体论就是对症"分散"的药方：把分散的信息拼接成地图（信息层）、把碎片认知组织成全局视图（认知层）、把隐性规则显性化为可执行能力（能力层）。
四、对症的药方（六篇预览）
| 痛点 | 药方 | 对应篇章 |
|---|---|---|
| 1 AI 无全局上下文 | 本体=结构化全局地图，碎片锚定到节点 | 02 核心概念模型 |
| 2 AI 无法安全行动 | 权限四层 + 地图+按钮 | 04 人机协作理论 |
| 3 隐性规则在脑子里 | 决策链建模 + 规则显性化 | 03 决策链理论 |
| 4 含糊问题没答案 | 含糊问题清单（每条链逼出可判定定义） | 03 决策链理论 |
| 5 经验靠人传 | 版本化 + 回填 + 组织认知投影 | 05 演化与沉淀理论 |
| 6 多项目不沉淀 | 飞轮模型 + 模板反哺 | 05 演化与沉淀理论 |
| 7 AI 答案要人搬运 | 最小闭环 + 验收标准 | 03/04 理论 |
五、第零篇立论
一句话：ONTAO 不是为了赶 AI 浪潮而建的体系，是为了解决我在五洲开发中亲身经历的七个痛点——本体论只是找到的对症药方。
验证方式（对应实施标准）：每个痛点都是可打分的（0-5），实施前后对比分数——痛不痛，实施标准说了算。
接下来：01 本体论基础——药方的原理