用 Claude Code 给 MRI 报告找第二意见:从个人实测到 DICOM 子 agent 仲裁

一、起因

HN 上一位工程师(antoine.fi)用 Opus 4.8 在 Claude Code 里读自己的肩部 MRI 影像,跟诊所医生给的结论矛盾 —— 医生说"肩胛下肌腱 III 级 (>50% 宽度) 部分撕裂",Opus 看完所有 DICOM 后给出"肌腱完整,仅轻度插入性肌腱病"的判断。两份报告相差太大,他让 Claude 用 subagent 跑了一次对抗式仲裁,最终 verdict 是"证据倾向 Reader A(中-高置信度),支持 Opus 的'未见撕裂'结论"(原文 P14)。

这件案例在 HN 拿了 288 分 / 392 条评论,评论区罕见地分成了四派:工程师觉得"模型在新领域看起来神,在我擅长的领域会犯傻"(@jrockway 1623 字符那条);真实放射科医生 @sxg 直接出来说"没有完整 3D MRI 没法判断,但超声评估钙化本身就不可靠";有人分享了自己父亲(退休神经科学家)被 LLM 误导延误癌症治疗的 NYT 报道(@js2 引用);还有患者分享了 ChatGPT Deep Research 帮他理清慢性鼻窦炎的真实病因(@linsomniac)。一条主线把"AI 能不能当医学第二意见"撕开了。

本文做的事情:把作者的实测流程复盘一遍,对照 HN 评论区里不同立场的论点,最后给出"Claude Code 当医学第二意见"的工程可行性边界。这不是医疗建议,是工程文章。

二、复现流程:从 DICOM 到 subagent 仲裁

2.1 输入物料

作者把诊所的 MRI 结果 + 3 页治疗方案完整文本传给 GPT 5.5 Pro,后者立刻识别出两个直接冲突的细节:

  1. 医生建议的冲击波治疗(shockwave therapy)
  2. 但临床指南明确说"无钙化的肩袖肌腱病不应使用冲击波治疗"
  3. 而超声检查显示没有钙化

GPT 5.5 Pro 在没有看过 DICOM 的情况下,从文本里就抓住了这条矛盾 —— 这是后续让 Opus 4.8 读 DICOM 的动机。

2.2 DICOM 数据

作者拿到的是"标准 DICOM 导出包,几百个无后缀文件,总大小约 266 MB"。这是 MRI / CT 影像的标准交换格式,每个文件带 patient / study / series / instance 四级 UID,内部是 16-bit 灰度像素 + 各种 metadata(切片厚度、TR/TE 序列参数、设备型号等)。

# 把 DICOM 喂给 Claude Code 的标准做法(作者原文 P8)
# 1. 把文件夹整体 cd 进 Claude Code 工作目录
# 2. 第一条 prompt:"请安装你可能需要的分析包"
# 3. 第二条 prompt:"right shoulder pain for 2–3 weeks"
#    (只给 2-3 周的病史,作者后来说"比真人医生收到的还少")

Claude Code 自动安装了 pydicom + numpy + 可能还有 SimpleITK,Opus 4.8 (xhigh 推理强度)开始工作。注意:作者明确说"Claude Code vs Claude.ai chat 的差别巨大,即使跑同一个模型" —— 因为前者能跑代码、安装包、生成中间分析文件,后者只能基于纯文本对话。这是 LLM 当 domain expert 的关键分水岭。

2.3 subagent 仲裁流程

读到报告后的矛盾太大(撕裂 vs 完整),作者决定让 Claude 自我仲裁:

  • 把医生的报告当 Reader A
  • 把 Opus 之前的报告当 Reader B
  • 给两个 subagent 同样的 DICOM + 两份待裁决的报告
  • 让它们各自给出"证据倾向哪一方"的判断 + 置信度

P13 提到"用了多个 subagent,作为拿到不受既有 context 偏见影响的新分析"。这是 LLM-as-judge 的工程化做法:让独立 context 跑独立判断,避免一个 session 里的 self-consistency 偏差。最终 P14 的 verdict 字符串是模型直接吐出的:

Arbiter's verdict: Evidence favours Reader A (moderate-to-high confidence). Mild insertional tendinosis; NO discrete partial- or full-ickness tear identified, including at the apical insertion.

注意仲裁结论支持的是 Opus(Reader A 在这里是 Opus 给的"未见撕裂"那份),而不是医生。这跟初看 DICOM 时的判断是一致的。

三、HN 评论区拆解:四个工程角度

3.1 真实放射科医生 @sxg 的视角(1290 字符)

@sxg 自我介绍"I'm a radiologist"然后直接给了三条技术性反驳:

  1. 超声不是评估钙化的好方法:会漏掉小钙化,平片更可靠,MRI 也能看到
  2. 没有完整 3D MRI 数据集没法判断:作者只用 Claude 看 DICOM,没看到医生看的那套完整序列
  3. 冲击波治疗对肌腱病(无钙化)的实际指征比指南写的更宽:指南不是绝对禁忌

这是评论区最有含金量的一条。判断标准:任何"AI vs 医生"的对比,如果不区分"看的输入数据是不是同一份",结论都不可靠。

3.2 工程师 @jrockway 的"Dunning-Kruger for domains"(1623 字符)

@jrockway 提出了一个反复被验证的工程观察:"AI is magical when I apply it to something I know nothing about. It far exceeds my expectations every single time. In fields where I'm an expert... it makes a lot of silly mistakes"。作者对 MRI 一无所知,所以 Opus 看起来神;但放射科医生看 Opus 的输出会立刻发现基础错误。

这条对应到工程领域就是:用 LLM 当未知领域的探索工具很合适(快速建立心智模型),但当已知领域的判断工具很危险(容易过度自信)。博客园读者画像(后端/全栈/老程序员)在用 LLM 写非本职代码时同样适用这条规律。

3.3 患者 @linsomniac 的"deep research 找病因"案例(1570 字符)

@linsomniac 分享了 3 年慢性鼻窦炎的真实故事:

  • 看了 3 个 GP + 3 次 ENT
  • ENT 视觉看到了过敏反应迹象,但过敏测试阴性,结论"无法用过敏药治疗",始终没回答为什么
  • ChatGPT deep research 翻到一个 NIH 研究:20% 人群有"isolated local allergic reaction",过敏测试阴性但局部仍有反应
  • ENT 看了 AI 给的论文后改口,换药方案 2 周见效

这条说明 AI 当第二意见最有价值的场景,不是"替代医生判断",而是"找医生遗漏的文献 / 提出医生没时间看的假设"。AI 不会疲劳,不会"今天的第 15 个病人就按常规处理",但也不会"看到完整 3D MRI 的物理直觉"。

3.4 失败案例 @js2 引用 NYT 报道(1707 字符)

@js2 引用了 NYT 2026-04-13 的报道:一位退休神经科学家因为自己用 AI 做的研究,深信自己被误诊,延误了癌症治疗。这条跟作者的成功案例形成镜像:AI 第二意见的反面,是对 AI 的过度信任 + 自我确认偏差。

Ben Riley was already writing about the risks of chatbots when his dad started trusting A.I. over his doctor.

四、Claude Code 当医学工具的工程含义

4.1 Claude Code 的差异化能力

评论区 @idopmstuff(1334 字符)对比了 Claude Code vs Claude.ai 的实际用途:

  • Claude Code = 写代码、跑任务、装包、生成中间分析文件 → 适合执行层
  • Claude.ai = 分析、规划、对话、spec → 适合规划层

给 MRI 第二意见这个场景,两者都得用:Claude.ai 跑规划(让医生先看 + AI 后看的整体流程),Claude Code 跑执行(读 DICOM、装 pydicom、生成分析中间产物)。@idopmstuff 自己说"对一个新项目,我开始用后者做初始规划,然后给 Claude Code 跑"。

4.2 LLM-as-judge 仲裁的工程可行性

作者用的"subagent 独立 context 仲裁"模式,本质上是 LLM-as-judge 的 multi-instance 变体。为什么有效:subagent 的 context 是独立的,不会继承主 session 的 prior 倾向(就像换一个人看病)。为什么有限:底层的 Opus 4.8 仍然是同一个模型,如果它的 DICOM 视觉理解有系统偏差,subagent 仲裁只会收敛到同一个偏差 —— 不会跨越模型自身的边界。

工程读者可以把这个模式抽象出来:任何"模型输出 vs 某个权威判断"冲突的场景,都可以用 subagent 仲裁拿一个二次意见。但前提是 subagent 用的底层模型不能跟原作者相同(否则独立性失效)。

4.3 DICOM 处理的当前局限

Opus 4.8 在 Claude Code 里能跑 pydicom 读 DICOM,但有几个当前局限(评论区 @sxg 跟作者自己的复盘都提到):

  1. 不能完整渲染 3D 体积:医生看 MRI 是多个平面 + 体积重建,LLM 只能拿到切片数组 + metadata
  2. 多序列融合能力弱:T1 / T2 / STIR / PD 等不同序列医生是同时看的,LLM 通常按单序列读
  3. 空间关系推理慢:肌腱撕裂的位置、形态、范围,医生一眼就能定位,LLM 需要逐切片分析
  4. 依赖 prompt 给出充分的临床信息:作者只给了"2-3 周疼痛",比真人医生收到的少很多,直接影响判断质量

五、目前还没完全搞清楚的几个点(局限与待验证项)

  • 作者本人的 case 是不是孤例(待验证) —— 一份 self-report,不能外推到一般情况。Claude 4.8 Opus 在 DICOM 上的真实精度需要公开 benchmark 验证,目前没有任何 peer-reviewed 数据
  • subagent 仲裁 vs 真人 second opinion 的实际一致性(待验证) —— 博客园读者可以做的小规模实验:让同一个 LLM 跑 100 个公开的 MRI 案例(有 ground truth 的),看 subagent 仲裁跟金标准的吻合率。这块目前没有公开数据
  • 作者没披露的关键参数(不足) —— Opus 4.8 的 xhigh 推理强度对应多少 token budget?Claude Code 跑这个分析花了多少时间?花了多少 API 费用?这些数字决定了这个流程能不能日常化
  • 诊所的 DICOM 导出对模型友好度(坑点) —— 不同厂商(Siemens / GE / Philips)的 DICOM metadata 差异、私有 tag 是否被 pydicom 识别、压缩格式是否需要转换,这些都会影响实际可用性
  • 不同模型的 DICOM 理解能力差异(待验证) —— Opus 4.8 / GPT-5.5 / Gemini 2.5 Pro 在同一份 DICOM 上会给出不同的判断吗?@linsomniac 的成功案例是 ChatGPT deep research(基于文献),不是医学影像理解,这两个能力不同
  • 医疗 AI 的法律责任边界(还在调研) —— 如果用户基于 AI 第二意见做出医疗决定,平台 / 模型方 / 诊所 / 用户之间的责任如何分配?目前没有任何司法判例,这条直接决定"AI 第二意见"能不能产品化
  • HN 评论区提到的 NYT 报道反映的失败模式(待验证) —— 退休神经科学家被 AI 误导延误治疗,这是 self-confirmation bias + 模型 overconfidence 的组合,作者这条案例没遇到,但模式上完全可能发生

六、适用场景建议

适合 Claude Code 当第二意见:

  1. 文本类报告(血检 / 病理 / 影像报告的纯文本)—— GPT-5.5 Pro 在这一步就已经很有效(@linsomniac 案例)
  2. 患者想搞清楚"医生说的术语到底什么意思" —— LLM 把医学黑话翻译成普通人能理解的语言
  3. 对医生建议提出"为什么"的问题 —— 慢性病管理的核心场景,作者这个案例就是典型
  4. 跨学科文献综合 —— 罕见病 / 多病共存时,LLM 横扫文献的能力远超单个医生的精力

不适合 / 有风险:

  1. 影像解读的金标准判断 —— 除非有公开 benchmark 验证,不要拿 LLM 的影像结论当最终决定(@sxg 视角)
  2. 急诊场景 —— 时间压力 + 严重后果,LLM 当下的速度不构成优势
  3. 用户已经倾向于某个诊断,想找 AI "确认" —— self-confirmation bias 会让任何模型输出都偏向用户预设(NYT 案例)

七、参考链接

posted @ 2026-06-29 07:08  Ninghg  阅读(9)  评论(0)    收藏  举报