研究知识库的候选路线 · 不是当前个人计划
候选学习地图（讨论稿，不是已确认计划）
候选学习地图（讨论稿，不是已确认计划）
本章只提供一条可修订的阅读与实验顺序，便于后续做互动站和严师。不规定每天学多久，不设截止日期，也不把任何章节标为用户已确认。 是否采用、如何拆课，仍待用户决定。
建议的问题主线
先分清“说清楚概念”和“让规则在运行中被一致执行”，再进入身份、动作、安全和证据边界，最后用虚构制造案例做对照。不要从“先建全企业本体平台”或“先接云模型”开始。
候选章节
| 编号 | 候选章节 | 要搞清的问题 | 主要资料 | 建议产出 |
|---|---|---|---|---|
| C0 | 怎么读这份知识库 | 来源如何分级？哪些是产品能力，哪些是论文自限，哪些是本地推演？ | README、sources.md | 能按类型引用，不把宣传当成效 |
| C1 | 产品本体与概念库存 | 二者各解决什么？为什么术语表不能代替运行中的本体？ | Why/Overview/Core concepts、最佳实践、2023 论文、笔记 01 | 用自己的话区分两层，并举一个“定义清楚但执行不一致”的例子 |
| C2 | 对象、身份、关系与时间状态 | 对象如何标识？设计清单、实际装配和维修更换如何分开？设备与传感器如何分开？ | 对象/关系类型、时间序列、最佳实践、笔记 02/04 | 画一张最小对象关系草图（虚构数据） |
| C3 | 动作、函数与写回限制 | 建议、批准、执行有何不同？部分写回和冲突时什么必须保持？ | 动作/函数及相关冲突页、笔记 02、微实验 2 | 能说明为什么不能假设通用回滚 |
| C4 | 安全、治理与数据边界 | 强制控制与读取过滤有何不同？为何“有权限接口”仍不能把敏感字段送进云模型？ | 安全/OSDK、平台摘要、笔记 03 | 写下本项目红线，并指出产品能力中哪些架构不能直接用 |
| C5 | 开发接口 | OSDK 与 Ontology API 能读什么、写什么，权限在哪一层生效？ | OSDK、API v2 基础页 | 能解释读取时强制与下游再处理的差别 |
| C6 | 血缘与可观测 | 管道血缘、执行追踪、决策血缘各能回答什么、不能回答什么？ | Data/Workflow Lineage、Why Ontology | 对同一“复盘”问题，说明三者各自的缺口 |
| C7 | 自动化 | 何时可以把动作交给 Automate，必须先具备什么？ | Automate、动作冲突页 | 列出自动执行前的审核与补救条件，而不是默认开启 |
| C8 | 证据、效益与文档冲突 | 如何处理官方口径不一致？如何验收过程价值而不承诺利润？ | sources.md 冲突清单、笔记 03 | 会写“事实 / 产品主张 / 待验证” |
| C9 | 与 OWL、OBDA、知识图谱对照 | 哪些可借鉴，哪些不能换牌子使用？ | OWL Primer、OBDA 综述、Hogan 综述 | 用一张对照表，避免混名 |
| C10 | 制造业工作域推演 | 主动服务、质量范围、备件保障如何拆开，又不一次铺开整条链？ | 笔记 04、时间序列 | 选定一个虚构失效模式，填工作域边界（仍是练习） |
| C11 | 微实验 | 能否在合成数据上走通规则与反例？ | interactive-spec.md | 手工跑完三个实验并记录与预期的差异 |
一条可选的阅读顺序
若从零开始深入理解产品 Ontology，可先读 C0 → C1 → C2 → C3 → C4，再按需要进入 C5–C7。C8 贯穿全程。C9 用于防止把开放标准与产品混为一谈。C10–C11 用虚构案例把讨论落到可检查的规则上。
也可以先做 C11 的微实验，再用 C1–C4 解释自己踩到的反例。两种顺序都只是候选。
最适合作为第一课讨论的问题
产品文档里的 Ontology，和 2023 年论文里的“概念库存”，各自解决什么问题？为什么把术语和定义登记清楚，并不等于已经有一套可执行的业务本体？
这个问题能直接带出运营层、动作与安全，也能避免一上来就堆对象清单或讨论平台选型。它不是本库替用户确认的学习计划，只是最合适的开场问题。
可选：让这台浏览器记住打开过的门户页面。默认关闭。清除后就没有了。它不代表导师认定的掌握。