第三章　四层双轨架构与工程建模方法

引言：怎样把“一个人的数字体系”变成可以实现的系统？

前两章讨论了两个基础问题：个人数字本体表达什么，以及现实如何通过测量与映射进入数字系统。

接下来，需要面对工程上的困难。

如果一个系统既要组织健康资料，又要理解技能经验，还要管理数字工具、作品权益和社会协作，它很容易变成一个无限扩张的数据库。每增加一种需求，就增加一组字段；每接入一个应用，就增加一套接口。数据越来越多，概念却越来越难以统一。

反过来，如果试图先建立一套涵盖所有人的庞大模型，又可能陷入另一个极端：定义不断增加，真实任务却迟迟无法完成。

因此，个人数字本体的工程问题，不是如何一次性描述一个人的全部，而是：

如何建立稳定的总体结构，使局部模型可以从具体任务出发逐步生长，并在扩展之后仍然保持含义、证据和权限的一致性？

本章提出“四层双轨”架构，并使用 TBox、RBox、ABox 与 CQ 等方法，将其转化为可设计、可测试的工程对象。

需要再次说明：四层双轨是本书提出的组织框架，不是关于人体或社会的自然定律。其价值应由实际使用中的解释能力、工程可维护性和任务表现来检验。

3.1　第一层：真实身体、生命过程与现实处境

3.1.1　第一层首先是一项建模承诺

四层结构的第一层是现实参照层，而不是软件中的“完整人体对象”。

它要求系统始终承认：

身体状态可以不同于系统记录；
现实事件可以尚未进入数据库；
模型所遗漏的条件可能影响结论；
用户的实际经历可以纠正系统的解释。

因此，第一层不能被理解为一份已经实现的“个人真值表”。

软件能够建立的，是关于真实个人的记录及模型；真实个人本身不被收纳进软件。

3.1.2　身体与处境应当共同进入问题定义

假设系统需要帮助一个人安排长期工作任务。

如果只考虑任务数量和截止日期，可能生成一份形式上合理、现实中无法承受的计划。睡眠不足、康复要求、照护责任和工具条件，都可能改变安排的可行性。

但这也不意味着系统可以要求用户提交全部健康信息。

正确的方法是：

明确任务需要哪些现实约束；
由用户或合适来源提供必要信息；
限定这些信息的使用范围；
不从有限约束推断不必要的个人属性。

例如，用户可以声明“每天最多安排两小时高强度工作”，而不必向一般工作系统披露具体疾病。

尊重现实，不等于无限采集现实。

3.1.3　第一层向其他层提供约束，而不是绝对决定

身体状态会影响行为和表现，但不能简单推导出人的能力、意志和社会价值。

一个健康指标不能概括一个人的工作潜力；一次疲劳状态，也不能被固化为长期能力标签。

因此，跨层关系宜表达为：

在特定条件下影响；
与某种表现有关；
构成当前限制；
需要进一步观察。

只有具备相应证据时，才使用更强的机制或因果表述。

3.2　第二层：体内器官模型与体外数字能力

第二层采用双轨结构，是因为个人数字化同时涉及两类不同问题：

如何表达身体内部的结构和功能；
如何延伸个人在外部世界中的感知与行动。

两者需要连接，但不能混同。

3.2.1　体内轨：真实器官的数字模型

体内轨以医学意义上的器官、组织、细胞和生理过程为对象。

例如，个人卵巢模型可以组织：

左右卵巢的相关观察；
超声与实验室检查；
周期和治疗背景；
专业判断；
治疗暴露与后续结果。

它首先要解决的是数据归属、时间关系和证据解释，而不是立即模拟全部卵巢生理过程。

这里应区分三个对象：

真实器官
    ↓ 被观察、测量
器官相关数据
    ↓ 被组织、解释
个人器官模型

真实器官承担生理功能。数字模型描述、估计或模拟这些功能，不能因为名称中包含“器官”，就被赋予真实器官的能力。

3.2.2　体外轨：感知与执行能力的数字延伸

体外轨包括：

文档、语音、图像与界面感知；
应用 API 和软件操作；
设备控制；
内容生成；
信息传递；
经授权的服务协调。

本书有时使用“体外数字器官”描述这类能力，但它是一种工程隐喻。

一个日程连接器不是生物器官，一个语言模型也不是人的心智。使用器官隐喻的目的，是强调功能、依赖和边界，而不是赋予系统生命属性。

3.2.3　两条轨道采用不同的验证方式

方面	体内器官模型	体外数字能力
核心对象	生物结构与功能	软件、设备与操作
常见输入	影像、检测、临床观察	指令、界面、API 状态
主要风险	医学误解、错误预测与干预	越权、误操作、重复执行
验证重点	数据质量、模型适用性、临床证据	权限、契约、执行回执与业务结果

技术操作验证可以证明预约已经创建，却不能证明该预约对应的医疗方案适当。

临床判断经过审核，也不能保证软件没有把预约创建在错误账户下。

双轨协作需要两类验证同时成立。

3.2.4　连接点是任务与授权，而不是无限共享数据

例如，一个健康随访流程可能包含：

器官模型提供经过审核的随访需求；
用户确认希望预约；
数字执行能力接收必要参数；
预约系统返回结果；
系统核验时间、机构和身份是否正确。

执行器需要预约参数与有效授权，却未必需要完整病历。

这体现了一个基本原则：

跨层共享必要含义，按任务提供最小数据。

3.3　第三层：技能、经验与认知策略

3.3.1　心智层表示什么？

第三层面向个人在理解与行动中体现的能力，包括：

技能；
经验；
问题解决策略；
经确认的偏好；
目标和价值取舍。

这些内容可以被部分描述，但不能被视为意识的完整副本。

例如，“擅长技术写作”是一个能力概括；某篇经过评价的技术文档、其任务条件和个人贡献，则是支持这一概括的证据。

如果缺少任务和证据，能力标签很容易变成不可检验的自我描述或系统印象。

3.3.2　技能、经验与策略应当分开表示

三者相关，却承担不同功能。

对象	主要含义	示例
技能	在条件下完成某类任务的能力	整理研究证据
经验	过去事件及其行动、结果与背景	参与某次研究项目
策略	组织判断与行动的方式	先查来源，再比较证据

一个人具有某段经历，不自动意味着掌握其中所有技能；一次成功，也不自动证明策略能够迁移到其他情境。

模型应保存这些连接的依据，而不是只建立肯定关系。

3.3.3　T-Mind 是可修正表达，不是人格判决

本书使用 T-Mind 组织个人认知策略、目标和偏好，但其中的 T 不意味着系统掌握了无条件的“心智真值”。

在实现中，需要区分：

用户明确声明；
行为中反复观察到的模式；
系统提出的假设；
用户确认的偏好；
当前情境下的临时选择。

例如，“用户通常喜欢简短报告”可以作为候选偏好。只有在范围明确之后，才适合用于具体输出；它不能自动扩展为“用户不愿意阅读风险说明”。

3.4　第四层：知识成果、身份、关系与社会权益

3.4.1　个人不仅是身体与能力的集合

个人生活还受到制度、组织、合同和共同活动的影响。

一项职业资质、一份合作协议、一件作品和一项专利，不仅是个人属性，也涉及外部主体和规则。

因此，第四层应表达：

什么成果已经形成；
谁作出了什么贡献；
哪项身份声明由谁证明；
哪段关系适用于什么场景；
某项权利在何种条件下有效。

3.4.2　社会对象不能只依靠个人声明确立

用户可以声明自己参与了一个项目，但项目中的角色、贡献和权利可能需要其他资料支持。

同样：

拥有文件副本，不等于拥有著作权；
名字出现在作品上，不自动说明全部权利归属；
签署合作意向，不等于正式许可成立；
认识某个人，不等于可以代表其作出承诺。

因此，这一层尤其需要区分：

个人声明
外部凭证
合同记录
权利解释
专业法律判断

这些内容可以相互支持，但不能被合并为一个“已确权”标签。

3.4.3　第四层不代表最高价值层

本书不把四层排列理解为价值等级。

身体与人格并不因为难以交易而价值较低；知识产权也不因为可以产生收入而高于人的健康和自主。

第四层之所以独立，是因为社会权益需要法律、组织和多方关系才能解释，而不是因为它比其他层更重要。

3.5　TBox、RBox、ABox：把结构与事实分开

四层双轨提供总体组织方式，具体工程仍需要明确的知识表示。

在描述逻辑及相关本体工程中，常用 TBox、RBox 和 ABox 区分不同内容。其具体支持方式取决于所采用的语言和系统。

3.5.1　TBox：概念及其定义

TBox 主要描述概念之间的结构和约束。

例如：

个人
器官
检查
观察结果
临床判断
治疗暴露
研究路径
授权

它还可以说明：

影像检查属于检查；
某类观察结果具有特定对象类型；
治疗暴露与治疗建议是不同概念。

概念划分应服务于实际任务。

如果系统需要区分“已经接受治疗”和“计划接受治疗”，就应建立明确结构；不能仅依赖一个自由文本字段，让模型每次重新猜测。

3.5.2　RBox：关系及其语义规则

RBox 面向关系的性质及相互联系，例如：

某种关系是否具有逆关系；
一种关系是否属于另一种关系；
某种关系是否具有传递性；
是否允许通过关系链形成特定推论。

这里最需要谨慎的是，不要把普通语言关系直接写成过强规则。

例如，明确限定意义的“部分属于”关系，在某些解剖层级中可以支持传递推理；但“与……相关”不能因为连续出现，就自动传递。

A 与 B 有关
B 与 C 有关

不能因此认定：

A 与 C 存在相同性质的关系

“某结果发生在治疗之后”也不能通过一条关系规则，被升级为“治疗导致该结果”。

关系规则越强，越需要明确适用范围和证据基础。

3.5.3　ABox：具体个人与事件实例

ABox 保存关于具体对象的断言。

例如：

示例用户 A 是一个个人实例。
左卵巢 A 是该用户的器官实例。
检查 E1 是一次超声检查。
观察 O1 来源于检查 E1。
观察 O1 涉及左卵巢 A。

这里仍需注意：ABox 中存在某项断言，并不意味着现实中该断言必然正确。

实例数据也需要来源、审核状态、有效时间和修订记录。

3.5.4　用“观察对象”承载变化，而不是反复覆盖属性

一种简单但危险的做法是：

用户 A 的某指标 = 最新数值

它会掩盖测量时间、方法和历史差异。

更稳妥的方式是为每次观察建立独立记录：

用户 A
  └─ 检查 E1
       └─ 观察 O1
            ├─ 项目
            ├─ 结果
            ├─ 单位
            ├─ 方法
            ├─ 时间
            └─ 来源

“当前状态”可以由经过确认的观察生成，但不应通过覆盖原始记录来实现。

3.5.5　本体推理与数据校验不是一回事

这是工程实现中的重要区别。

许多本体语言采用开放世界假设：没有记录某件事，不等于该事不存在。

而业务表单可能要求“必须填写采样日期”，这是完整性校验问题。

因此：

本体用于表达概念和逻辑关系；
数据校验工具用于检查必填字段、格式及业务约束；
工作流用于决定缺失时如何处理。

例如，可以使用 SHACL、JSON Schema 或关系数据库约束完成某些检查，但应按技术栈和需求选择。

逻辑上一致，不代表资料完整；字段全部填写，也不代表内容真实。

3.6　CQ：先定义系统必须回答什么

CQ，即胜任力问题，是确定本体范围的重要方法。

与其先罗列几百个概念，不如先提出一组具体问题：

系统最终需要回答什么？回答需要哪些对象、关系和证据？

3.6.1　以个人卵巢模型为例

首版可以选择以下问题：

CQ	所需信息	合理输出
最近一次已审核观察是什么？	审核状态、时间、来源	返回记录与来源
两次检测采用相同方法吗？	方法标识及版本	相同、不同或未知
某项变化发生在何种治疗背景下？	时间轴与治疗记录	展示已知背景和缺失
谁可以访问这份资料？	身份、用途、授权状态	当前允许的范围
哪些摘要受到被撤回来源影响？	来源与派生关系	标记需重新评估的输出

这些问题具有明确边界，也能够设计测试。

3.6.2　同时定义系统不能回答的问题

例如，在缺少相应模型与证据时：

不能判断个人剩余卵子总数；
不能确定某次变化的原因；
不能推荐最佳细胞产品；
不能从单次指标预测自然受孕；
不能认定某项技术已经拥有可许可权利。

“不能回答”不是功能列表的空白，而应成为可测试的系统行为。

测试应检查系统是否：

说明缺少什么；
避免编造确定性答案；
提供适当的核对或转交路径。

3.6.3　CQ 应当转化为验收用例

一个完整用例可以包含：

问题
输入资料
允许使用的来源
预期结果
必须指出的不确定性
禁止出现的推断
所需授权
验证方法

例如：

输入两次采用不同检测方案的观察，系统应识别方法差异，并避免直接给出功能改善结论。

这样的测试比“报告是否看起来专业”更能说明系统是否可靠。

3.7　本体、数据库、知识图谱、规则与计算模型如何协同

3.7.1　本体不是数据库的替代品

数据库负责存储与查询，本体负责明确语义。二者可以协同，但并非必须采用同一种技术。

首版完全可以使用关系数据库保存：

个人；
检查；
观察；
来源；
授权；
审核；
模型版本。

只要概念和关系定义清楚，关系表也能承载具有本体意识的系统。

知识图谱适合复杂关系查询和跨域关联，但不应因为名称先进就成为默认起点。

3.7.2　建议的最小工程分层

应用界面
用户、医生、研究人员、管理人员
        ↓
任务与工作流
提取、审核、查询、报告、授权
        ↓
语义与规则层
概念、关系、CQ、数据校验、政策
        ↓
数据与证据层
原始文件、结构化观察、版本、来源
        ↓
模型与工具接口
统计模型、生理模型、检索、外部系统

横向贯穿的治理包括：

身份认证；
权限执行；
安全审计；
敏感信息保护；
变更管理。

语言模型可以参与提取和任务组织，但不能成为唯一的事实存储、权限判断或验证机制。

3.7.3　跨层连接应通过稳定契约

不同模块之间应交接结构化对象，而不是只交换自然语言结论。

例如：

Observation：观察及来源
Assessment：解释及证据
ProposedAction：拟执行动作
Authorization：授权条件
ActionReceipt：执行回执
VerificationResult：验证结果

这样可以明确：

哪一部分是事实；
哪一部分是解释；
哪一部分尚未执行；
哪一部分已经获得批准；
哪一部分需要进一步验证。

3.7.4　模型输出必须成为可追踪对象

预测或仿真结果至少应记录：

模型标识与版本；
输入数据版本；
目标用途；
参数来源；
输出时间；
不确定性；
已知限制；
审核或验证状态。

否则，系统只保存一句“风险较高”或“方案更优”，后续就无法解释结论为何产生，也无法判断旧结论是否仍然适用。

3.8　一致性、可追溯性、可用性与可验证性

个人数字本体是否成功，不能只看概念数量或关系规模。

本书建议从四个方面评价。

3.8.1　一致性：相同概念是否被一致使用？

需要检查：

同名字段是否表达不同含义；
不同名称是否实际指向相同对象；
左右侧、时间和单位是否冲突；
状态转换是否合理；
关系规则是否造成过强推断。

一致性既包括逻辑一致，也包括跨模块的语义一致。

3.8.2　可追溯性：结果能否返回来源？

系统应能沿着以下路径回查：

输出
 → 使用的模型或规则
 → 输入观察
 → 提取与映射过程
 → 原始来源

对授权与行动，还应能够追踪批准主体、范围、有效期和执行结果。

可追溯性不能证明全部内容正确，但它使错误有机会被定位和修正。

3.8.3　可用性：是否真正帮助人完成任务？

一个理论上精细的本体，如果每次录入都要求医生填写大量无关字段，可能难以持续使用。

因此，需要评价：

资料整理时间；
人工纠正负担；
查询是否符合真实工作语言；
用户能否理解模型边界；
新增数据或场景的维护成本。

好的结构应减少重复解释，而不是增加无意义的表单负担。

3.8.4　可验证性：能力是否经过独立检验？

至少要建立三类测试：

语义测试：CQ 是否被正确回答；
数据与流程测试：输入、权限、状态和回执是否正确；
用途测试：模型是否真正支持声称的临床、科研或业务任务。

此外，应加入异常情境：

来源相互矛盾；
单位缺失；
授权到期；
用户身份匹配错误；
模型版本变化；
原始记录被纠正；
外部系统执行结果未知。

只有正常案例通过，不能说明系统可靠。

3.8.5　以更简单的方案作为对照

复杂架构需要证明自己的必要性。

例如，应比较：

人工整理；
普通数据库加固定规则；
通用模型加检索；
本体驱动的结构化系统。

如果增加本体之后，没有减少错误、提升可追溯性或降低长期维护成本，就需要重新审视模型粒度和实现方式。

架构的价值不是自我宣称完整，而是相对于更简单方案产生可证实的增益。

本章案例：从四层框架收缩到一个可交付任务

假设 GeniFlare 首版只解决一个问题：

将个人卵巢随访资料组织成可追溯的时间轴，并生成供医生审核的摘要。

四层双轨如何参与？

第一层：保留现实参照

系统承认真实身体状态不能由几份报告穷尽。资料缺失时，不自动判断正常或异常。

第二层：组织器官观察与执行能力

体内轨关联检查、卵巢观察、周期和治疗背景。

体外轨完成文件读取、字段提取、审核任务和经授权的提醒。

两条轨道共享任务标识，但分别验证医学解释与软件动作。

第三层：有限使用个人偏好

用户可以选择报告语言、阅读难度和提醒方式。

这些偏好不改变医学事实，也不能省略必要风险说明。

第四层：表达身份与责任

系统记录谁提供资料、谁完成审核、谁具有相应访问权限。

如果资料用于研究或产业合作，需要额外治理，不能因为已经用于健康服务就自动取得其他使用资格。

最小实现

首版可能只需要：

一组明确概念；
几张结构化表；
少量关系；
一套字段校验；
来源与版本记录；
审核工作流；
数个可测试的 CQ。

它尚不需要完整人体图谱、复杂因果模型或自动治疗规划。

但因为结构和边界已经明确，后续加入新的器官、研究模型和合作流程时，不必推翻全部基础。

这正是总体架构与渐进实施之间的关系：

总体上保持完整，任务上保持克制，能力上逐步验证。

本章小结

四层双轨架构不是把一个人拆成若干可以独立占有的部件，而是为不同性质的信息建立合适的表达和治理方式。

本章提出七项工程原则：

第一层是现实参照，不是完整真值数据库。
体内器官模型与体外数字能力需要协作，但定义和验证方式不同。
技能、经验、认知策略和授权必须分别表达。
社会身份、贡献与权利需要来源和外部规则支持。
概念、关系、实例和数据校验不能混为一谈。
通过 CQ 确定范围，并把不能回答的问题纳入测试。
以真实任务增益证明架构价值，而不是以概念规模证明完整性。

下一章将进入第一层，进一步讨论真实身体、生命过程与现实处境：为什么身体不能被数字记录替代，生理约束如何进入系统，以及数字模型应当怎样在帮助个人的同时保留人的尊严与自主。

完整的个人数字体系，不是让所有信息进入同一个容器，而是让不同性质的信息各有位置、各有依据，也各有不能越过的边界。

第三章 四层双轨架构与工程建模方法

引言：怎样把“一个人的数字体系”变成可以实现的系统？

3.1 第一层：真实身体、生命过程与现实处境

3.1.1 第一层首先是一项建模承诺

3.1.2 身体与处境应当共同进入问题定义

3.1.3 第一层向其他层提供约束，而不是绝对决定

3.2 第二层：体内器官模型与体外数字能力

3.2.1 体内轨：真实器官的数字模型

3.2.2 体外轨：感知与执行能力的数字延伸

3.2.3 两条轨道采用不同的验证方式

3.2.4 连接点是任务与授权，而不是无限共享数据

3.3 第三层：技能、经验与认知策略

3.3.1 心智层表示什么？

3.3.2 技能、经验与策略应当分开表示

3.3.3 T-Mind 是可修正表达，不是人格判决

3.4 第四层：知识成果、身份、关系与社会权益

3.4.1 个人不仅是身体与能力的集合

3.4.2 社会对象不能只依靠个人声明确立

3.4.3 第四层不代表最高价值层

3.5 TBox、RBox、ABox：把结构与事实分开

3.5.1 TBox：概念及其定义

3.5.2 RBox：关系及其语义规则

3.5.3 ABox：具体个人与事件实例

3.5.4 用“观察对象”承载变化，而不是反复覆盖属性

3.5.5 本体推理与数据校验不是一回事

3.6 CQ：先定义系统必须回答什么

3.6.1 以个人卵巢模型为例

3.6.2 同时定义系统不能回答的问题

3.6.3 CQ 应当转化为验收用例

3.7 本体、数据库、知识图谱、规则与计算模型如何协同

3.7.1 本体不是数据库的替代品

3.7.2 建议的最小工程分层

3.7.3 跨层连接应通过稳定契约

3.7.4 模型输出必须成为可追踪对象

3.8 一致性、可追溯性、可用性与可验证性

3.8.1 一致性：相同概念是否被一致使用？

3.8.2 可追溯性：结果能否返回来源？

3.8.3 可用性：是否真正帮助人完成任务？

3.8.4 可验证性：能力是否经过独立检验？

3.8.5 以更简单的方案作为对照