八层统一走通：医院 AI 诊断系统部署决策

⚠️ 本案例为八层体系历史快照（DM→ASTO→ARBT→TAT→COP→ODD→LMM→RT6）。当前体系已扩展为十一层（新增 OCGS/PFM/LSM/WSH），案例正在重写中。

定位：用一个完整案例从 DM→ASTO→ARBT→TAT→COP→ODD→LMM→RT6 走通全部八层，展示整套理论体系在一个真实问题上如何协同工作。 作者：Yi Fu（付毅，ODDFounder）

案例

一家三甲医院计划在急诊科部署一套 AI 辅助诊断系统。系统读取患者主诉、体征和检查结果，给出初步诊断建议和危重等级排序，帮助急诊医生在高峰时段快速分流患者。

医院 IT 已完成系统对接。但在上线前一天，急诊科主任提出反对："我不确定这个系统在忙的时候会不会给错优先级。如果它把一个心梗患者排到后面，谁负责？"

院长决定暂缓上线，要求做一次全面的评估。

第一层 · DM（差异一元论）：这个问题的哲学地基是什么

DM 视角的拆解

AI 诊断系统的核心承诺是"它能把患者状态正确排序"。在 DM 框架下，这承诺意味着：

1. 差异：系统必须能从患者数据中识别出"有临床意义的差异"——心梗 vs 胃痛，不是"数据点不同"，而是"风险结构不同"
2. 结构：系统内部有一个从"原始数据→特征→风险评分→排序"的结构链。这个结构不是"客观现实"的直接映射——它是训练数据 + 算法设计 + 部署条件共同约束下的产物
3. 边界：系统的结构边界是"训练数据覆盖的病例类型"。边界之外的病例（罕见病、非典型症状、新发传染病）——系统不"知道"自己不知道
4. 继承：训练数据中的历史偏见（如某类患者历史上被低估了疼痛报告）会在结构中继承
5. 涌现：当系统在"边界附近"做判断时——如一个症状同时匹配"高危"和"低危"两种模式——系统的输出不是"计算错误"，而是结构在边界处的涌现不确定性

DM 的判断

这个系统的真正风险不是"AI 不够聪明"，而是它的结构边界在部署前未被显式标注。系统和医生都不知道"系统在什么情况下会出错"。

第二层 · ASTO（属集变迁存在论）：当前状态怎么编码

ASTO 前置编码

ASTO 的核心发现

五态不匹配：AI 系统处于"物化"（代码已固化），而医生对它的理解和信任仍处于"共识"（口头讨论）。这种不匹配本身就是风险——医生会用"共识态"的模糊期望去使用一个"物化态"的精确但边界固定的系统。

第三层 · ARBT（权责边界变迁理论）：权责边界在什么条件下成立

三大公理的适用

能量约束：急诊高峰时段，医生做分流决策的平均时间不到 2 分钟。AI 系统如果要在 2 分钟内完成诊断建议，它的计算不能超过这个窗口。如果 AI 因为某些病例触发了"深度推理"而导致延迟——这不是 bug，是能量约束下的必然。

适应选择约束：如果部署后 AI 的危重识别率低于高年资医生，急诊科会自然停止使用它——不需要任何正式禁令。"不好用"本身就是选择压力。问题是：这个选择压力在"AI 漏诊了一个危重患者"的时候才会生效——那时已经造成了伤害。

不完备约束：AI 系统不可能在"所有可能的病例"上被预先验证。总有一种输入是训练时和测试时都没见过的。问题是：系统是否知道自己不知道？——当前系统没有"我不知道"的输出选项。

ARBT 的治理判断

上线前的最低条件：系统必须有"FREEZE 输出"——当输入落在已知的可靠区之外时，输出"不建议自动判断"而非"强制给出一个排序"。

第四层 · TAT（责任架构理论）：谁承接后果

五合同模型应用

TAT 的责任闭合判断

当前闭合度：受控模糊（最低档）。 系统有技术能力，但责任架构的五个合同中有三个（接口/熔断/补偿）未定义。

在五合同全部签署之前，上线是"受控模糊"状态下运行——可以允许（最低护栏：留痕+熔断权），但不能宣称"责任已闭合"。

第五层 · COP（认知计算协议）：诊断分流——该不该上线

P1 输入采样

关键信号： - S1：急诊科主任明确反对（可靠性：高——直接陈述） - S2：IT 部门说"技术测试全部通过"（可靠性：中——测试覆盖的是已知场景） - S3：AI 供应商提供的精度报告——在测试集上准确率 92%（可靠性：中——测试集与真实急诊分布的差异未知） - 缺失信号：在"高压力+时间约束"条件下的表现；罕见病例的边缘表现

P2 状态编码

asto_precoding:
  state_type: 共识→编码（过渡期）
  boundary_status: blurred

clarity_vector:
  signal_completeness: 0.50     # 缺少高压环境下的表现数据
  signal_consistency: 0.45      # 主任反对 vs IT 支持——信号矛盾
  category_concentration: 0.70  # 核心问题是"边界未标注"

structural_risk_vector:
  responsibility_diffusion: medium
  power_asymmetry: medium        # 院长有权决定但需要技术判断
  irreversibility_potential: high  # 一次漏诊可能意味着患者死亡

P3 诊断判定

→ FREEZE。理由：irreversibility_potential = high（漏诊的后果不可逆），且 signal_completeness 为 0.50（缺少关键环境表现数据）。

P4 转介建议

action: FREEZE_AND_ESCALATE
freeze_reason: "信号不完整（缺高压环境数据）+ 不可逆风险高"
required_before_unfreeze:
  - "完成至少 100 例'影子运行'（系统在后台诊断但不影响医生决策）"
  - "明确系统的'FREEZE 输出'条件——什么情况下系统说'不建议自动判断'"
  - "签署 TAT 五合同中的接口合同和熔断合同"

第六层 · ODD（产出物驱动开发）：怎么工程化地验证

契约设计

如果 COP 的 FREEZE 条件全部满足后（影子运行完成、FREEZE 输出条件明确、五合同签署），ODD 进入：

contract:
  id: AI-ER-TRIAGE-001
  title: "AI急诊分诊系统上线验证"

  acceptance_criteria:
    - criterion: "影子运行100例中，AI的危重识别率不低于高年资医生"
      hardness: hard
    - criterion: "系统在输入触及边界时（非典型症状、数据缺失），输出FREEZE而非强制排序"
      hardness: hard
    - criterion: "每次诊断建议附带置信度标注和'基于以下数据源'声明"
      hardness: hard
    - criterion: "医生覆盖AI建议的比例不超过20%（即医生不是简单点'同意'）"
      hardness: soft

  floor: "所有hard条件通过，影子运行至少覆盖早/晚/周末三个时段"
  red_line: "影子运行期间，AI诊断建议不显示给患者——只显示给医生作为参考"

验证

• PASS：所有 hard 条件满足 → 允许正式上线
• FAIL：任一 hard 条件未满足 → 修复后重新验证
• FREEZE：hard 条件满足但出现一次"AI 漏诊且医生也未识别"的近失事件 → 暂停，人工复审

封存

正式上线后，首次影子运行的 100 例诊断记录 + 验证报告 + 五合同签署文件 → 打包封存。这是"这个系统在部署时是经过这些验证的"的证据。

第七层 · LMM（灯塔营销方法论）：前线医生怎么接住这个系统

LMM 闭环在此案例的运作

寻域：问题域是"急诊医生在高压力下如何信任一个 AI 系统"——这不是技术培训，是信任建立。

确路：通过急诊科主任（反对者→最早的接触点）——不是绕开他，而是让他成为评估过程的一部分。他提出的"我不确定它在忙的时候会不会出错"恰好是 COP 要求补充的最关键信号。

灯塔：不是给医生看 AI 的精度报告（92%——他们不关心）。灯塔是："这个系统会在它不确定的时候说不知道——和你们一样。"

自测：影子运行 100 例就是自测。医生在真实环境中使用系统但不依赖系统——他们自己判断后再看 AI 怎么说，比较两者的差异。

港口：影子运行结束后，每个参与医生回答一个问题："你愿意在下一个班次中继续使用这个系统吗？"——这是步骤 3（询问是否进入）。

首次责任闭合：当超过 80% 的参与医生说"愿意继续使用"，且所有 hard 验证条件通过——急诊科主任签署"本系统已满足上线条件"。

第八层 · RT6（共鸣与跃迁六步法）：从反对到上线的六步

六步走通

第一步：症状陈述 急诊科主任："我不确定它在忙的时候会不会给错优先级。"——不急着反驳，先接住。

第二步：扫描诊断 COP 诊断：FREEZE（信号不完整 + 不可逆风险高）。关键发现：主任的反对不是"保守"，而是指出了系统最关键的缺失信号。

第三步：询问是否进入处理 "你愿意做一个 100 例的影子运行来验证这个系统吗？在影子运行期间，系统不影响任何真实决策。"

第四步：给总方 方向是三步：影子运行收集信号 → 定义 FREEZE 条件 → 签署五合同后上线。

第五步：细方（执行阶段） - 第一周：选取 100 例历史病例（含 20% 的边缘病例），系统在后台重新诊断 - 第二周：对比 AI 诊断 vs 医生诊断 vs 实际结果 - 第三周：基于对比结果，定义系统的 FREEZE 触发条件 - 第四周：签署五合同，开始影子运行（真实环境，AI 建议仅医生可见）

第六步：复诊 四周后：如果 80% 医生愿意继续使用 + hard 条件全部通过 → 正式上线。如果有近失事件 → 重新评估 FREEZE 条件。如果医生拒绝率高 → 重新考虑是否适配急诊场景。

八层总览

DM：系统的结构边界在部署前未被显式标注
  ↓
ASTO：五态不匹配——系统已物化，医生仍在共识态
  ↓
ARBT：不完备约束——系统不知道自己不知道。必须加 FREEZE 输出
  ↓
TAT：五合同中三个缺失——上线前必须签署接口/熔断/补偿合同
  ↓
COP：FREEZE——信号不完整+不可逆风险高。解冻条件：影子运行+FREEZE输出+五合同
  ↓
ODD：契约验证——100例影子运行，hard条件达标才放行
  ↓
LMM：通过主任（反对者）建立信任，影子运行就是自测
  ↓
RT6：六步从反对走到影子运行→评估→上线/不上线决策

这个案例说明什么

这不是一个"AI 太危险所以不能部署"的故事。 八层的结论不是"不上线"，而是"在满足以下条件后可以上线：FREEZE 输出、影子运行验证、五合同签署、医生主动选择继续使用"。

这不是"八层各说各的"。 每一层都在处理同一个问题，但每一层处理的维度不同、不可替代。DM 不给工程建议，ODD 不讨论哲学地基。但如果你跳过了任何一层——比如直接让 IT 上线而不经过 COP 诊断——你就漏掉了"边界未标注"和"五合同缺失"这些关键风险。

这就是八层体系的价值：不是每层都要被每个人使用，而是当所有层都被覆盖时，你才能确定没有遗漏关键维度。