BOOK_CONSTITUTION.md

全书宪法：世界观、原则与边界

本文件是《Data-Driven AI：从数据到智能》的最高约束。

所有章节、所有贡献者、所有 AI 协作 Agent，都必须先读本文件。

本文件与 AGENTS.md 冲突时，以本文件为准。

---

一、项目定位与边界

1.1 本书是什么

开源技术书（GitHub Book）。

书名：《Data-Driven AI：从数据到智能》。

英文副标题：Teach Data Engineers How to Think AI。

写给做过数年数据工程的人，讲 AI 原生科研数据基座（AI-Ready Scientific Data Foundation）怎么搭。不讲某个模型，也不讲某个应用。

1.2 目标

让读者从数据这边看 AI。新增内容都围着这件事转。

1.3 本书不写什么

不写入门课、Prompt、LangChain / MCP 手册、框架合集、某模型或某工具的官方文档翻译。

不写发现应用：靶点预测、图神经网络、假设生成、自动写报告。

不写 Agent 编排。仓外 Agent 是消费方，不是本书要建的一层。

不写某一家真药企的内部实现，也不写某个开源仓库的源码导读。

1.4 判定规则

如果某段内容无法帮助读者理解 AI 数据架构，则不要写。

如果某段内容换个框架名仍然成立，则它太通用，不要写。

如果某段内容在一年后仍成立，才值得写。

如果某段内容在教读者「怎么做一个 Agent / Copilot / 发现产品」，删掉。

---

二、目标读者画像

2.1 默认读者

数据研发工程师（Data Engineer）。

数据平台工程师（Data Platform Engineer）。

数据架构师（Data Architect）。

Analytics Engineer。

技术负责人（Tech Lead）。

2.2 经验门槛

5~15 年。

2.3 读者已掌握的技能

不要重复介绍以下内容，默认读者已经熟悉：

• SQL
• ETL / ELT
• Data Warehouse
• Lakehouse
• CDC
• Streaming
• Spark
• Flink
• Airflow
• 数据治理
• 元数据
• 数据血缘

2.4 判定规则

所有内容应建立在上述经验之上。

如果一段话在解释什么是 ETL，删除它。

如果一段话在解释什么是 Spark，删除它。

---

三、全书唯一主线

3.1 主线

全书只有一条主线。它对齐头部药企公开讨论的科研数据栈，而不是「先建 Agent 再补数据」。

flowchart LR
    A[传统数据平台] --> B[Lakehouse]
    B --> C[MetadataCatalog]
    C --> D[OntologyServices]
    D --> E[ScientificKG]
    E --> F[EvidenceIndex]
    F --> G[AIContextAPIs]
    G --> H[ScientificDataLoop]
    H -.循环.-> D

六层栈回答六个独立问题：

层	回答的问题
Lakehouse	科研数据产品如何落湖、如何质检
Metadata Catalog	资产在哪、谁拥有
Ontology Services	机器如何理解企业世界，公开层如何 xref
Scientific KG	已验证的身份、关系、溯源如何存
Evidence Index	证据在哪，如何与图分工
AI Context APIs	仓外消费方能依赖哪些稳定数据形态

Scientific Data Loop 不是第七个存储层。它让 Ontology 与知识随研究活动变厚。

3.2 判定规则

任何新增内容，都必须能够放进这条主线。

如果不能放进，说明它不属于本书。

如果一个概念横跨多段主线，按它"主要解决哪一段的问题"归属。

3.3 主线不可拆散

不要把 Ontology Services 章节写成知识图谱章节。

不要把 AI Context APIs 章节写成 BI 语义层或 Agent 编排章节。

不要把 Scientific Data Loop 章节写成 ETL 或模型再训练章节。

不要把 Evidence Index 章节写成「向量库加模型」。

每一层的定义见 ARCHITECTURE.md。

3.4 第 8 章：跨层决策收束

六层加闭环之后，设跨层收束章「路线选择与适用边界」（docs/decision-boundary/）。

该章不改变主线递进顺序，不新增 DDA 层。

它回答：何时不必建完整 Ontology、何时 Text-to-SQL 够用、何时闭环投入产出比不划算、自建与采购如何选型。

写该章前须已读完六层与闭环正文。

---

四、两大核心

两个核心：Ontology，以及 Scientific Data Loop。

4.1 Ontology（数据本体）

Ontology 是机器理解企业业务世界的方式。

公开药理空间提供生物医学世界。企业 Ontology 提供公司的世界。

所有知识最终都应该回到 Ontology。

RDF、OWL、知识图谱、某款图库的产品功能，都可以是实现。它们不是 Ontology 本身。

4.2 Scientific Data Loop（科学数据闭环）

Scientific Data Loop 是研究系统、语义基座、AI 消费与科学家审校之间的回流。

闭环的产品是企业科学知识层变厚，不是模型权重更新。

它不是新的 ETL，也不是数据管道换个名字，更不是模型再训练。

4.3 判定规则

任何章节，如果既不涉及 Ontology，也不涉及 Data Loop，需要自问它是否属于本书。

---

五、Data First 原则

5.1 起手必须从数据

讨论任何 AI 架构时，必须首先讨论数据。

而不是首先讨论模型。

5.2 禁止的起手

不要从 LLM 起手。

不要从 Prompt 起手。

不要从 Agent 起手。

不要从某个 API 起手。

5.3 正确的起手

应该从 Data Foundation 起手。

应该从"数据长什么样、从哪来、怎么治理"起手。

5.4 判定反例

如果一个章节的开篇在介绍某个模型的能力，违反 Data First。

如果一个章节的架构图把 LLM 画在中心，违反 Data First。

---

六、统一案例约束

6.1 全书统一案例

全书统一采用创新药研发（Drug Discovery）作为贯穿案例。

案例公司是虚构的 阿斯利华（Asliva）。

企业主键用 ASH:ENT:*。内部研发代号用 ASH-001。域名用 asliva.example。

阿斯利华不是阿斯利康。真实阿斯利康、Open PHACTS、Roche 只出现在「业界路线对照」，只学栈与分工，不写成阿斯利华的内部产品。

6.2 禁止逐章换域

禁止这一章写金融。

禁止下一章写电商。

禁止第三章写制造。

6.3 为什么

持续使用同一个案例，让读者看到完整演进过程。

让 Ontology 在同一个业务世界里逐步生长。

让 Data Loop 在同一组数据上闭环。

6.4 判定规则

任何章节引入新案例域，需要先在本文件追加授权。

未授权的新域，使用 Drug Discovery 替代。

禁止再出现药明诺华、NovaPharm、NVP-、NPV:、novapharm.example。

---

七、语言与态度红线

7.1 基调

专业。

克制。

工程化。

7.2 禁用词

禁用以下营销语言：

• 革命性
• 颠覆
• 黑科技
• 神奇
• 万能
• 一站式（除非确有其物且点名）
• 赋能
• 抓手
• 闭环（作为动词使用时）
• 落地（作为口号使用时）

7.3 禁止制造焦虑

不要写"不学 AI 就会被淘汰"。

不要写"再不转型就晚了"。

不要用恐惧驱动读者。

7.4 禁止过度口语化

保持书面工程语言的密度。别写成博客或公众号。

7.5 写作细节

写作细节见 WRITING_STYLE.md。

7.6 源码与应用红线

正文不引用具体实现仓库的源码、包名、命令行或文件路径。

工具名只在工程实践段作为某一类实现的例子出现，并标注「仅为一种实现选择」。

---

八、成功标准

8.1 读者应该能说出

希望读者读完后能够说：

"我终于理解 AI 为什么需要 Ontology。"

"我终于理解公开药理空间和企业世界为什么必须分开。"

"我终于理解 Evidence 和 Knowledge 为什么不能灌进同一张图。"

"我终于理解 Data Loop 为什么修的是知识层，不是模型。"

"我终于知道科研数据基座应该如何分层。"

8.2 读者不应该说

而不是：

"我学会了某个 AI 框架。"

"我知道了某个模型的参数。"

"我会调 Prompt 了。"

"我会搭一个药物情报 Agent。"

8.3 唯一标准

读者从"数据视角"理解了 AI，是本书成功的唯一标准。

---

九、本文件的修订规则

本文件是最高约束。

修订本文件需要同时更新 AGENTS.md 的路由说明。

任何与本文件冲突的章节内容，章节让步。

任何与本文件冲突的工具实现，工具让步。