Claude Code 不写代码：用 AI 编程工具分析 MRI 的意外玩法

今天刷 Hacker News 的时候看到一个帖子，286 分，391 条评论。标题是"I used Claude Code to get a second opinion on my MRI"——一个人用 Claude Code 分析了自己的肩部 MRI 影像。

说实话，看到这个标题的第一反应是：扯呢吧？一个写代码的工具去读 MRI？

但仔细看完之后，我觉得这可能是 AI Agent 这个概念最生动的注脚之一。而且 HN 评论区的讨论比原文还精彩——有放射科医生、有超声技师、有律师、有患者家属，各路神仙吵成一锅粥。

今天就借这个事儿聊聊：AI 编程工具到底能干什么"不写代码"的活？这背后的技术逻辑是什么？以及，这到底靠不靠谱？

事情的经过

帖主叫 Antoine，法国人，肩膀疼了两三周，去看骨科医生。医生让他做了个 MRI，结果出来是"Grade III partial-thickness tear"——肩胛下肌腱部分撕裂，超过 50% 的宽度。

然后诊所就开始给他做治疗了。冲击波、注射 Traumeel，一套组合拳下来，Antoine 越想越不对劲。他要求诊所把 MRI 数据和治疗记录拷了一份带走。

回去之后，他先让 GPT 5.5 Pro 看了看治疗方案，AI 立刻指出两个问题：

• 冲击波疗法不适合非钙化性肩袖肌腱病——而超声报告明确说没有钙化
• Traumeel 在德国注册的是"顺势疗法药物"，也就是说，没有经过严格的药效验证

这下 Antoine 更不放心了。于是他做了一件大部分人想不到的事：把 266MB 的 DICOM 影像文件丢给 Claude Code，让它做一次独立的 MRI 分析。

Claude Code vs ChatGPT：为什么非得用编程工具？

这里有个关键点很多人可能没意识到。

你可能会问：直接用 Claude.ai 的聊天界面不行吗？为啥非得用 Claude Code？

Antoine 自己说了："Claude Code 和 Claude.ai 跑的是同一个模型（Opus 4.8），但两者之间的差距是巨大的。"

差距在哪？在"手"。

聊天界面的 AI 只能说话。它没有终端，不能装 Python 包，不能读写文件，不能跑脚本。你给它一张图片，它能看；但你给它 266MB、几百个无扩展名的 DICOM 文件，它直接傻眼。

Claude Code 不一样。它有完整的终端环境。它可以：

pip install pydicom numpy matplotlib

然后写 Python 脚本读取 DICOM 文件，逐帧分析影像，生成可视化报告，最后输出一份 PDF。

这就是 AI Agent 和 AI 聊天的根本区别：Agent 有"手"，能干活。

我之前写过不少关于 Claude Code 的文章，但大部分都在聊编程场景。今天这个案例让我意识到，Claude Code 的价值远不止写代码——任何需要"安装工具→读取数据→处理→输出结果"的任务，它都能干。

分析过程：Claude Code 实际干了什么

Antoine 给 Claude Code 的指令非常简单："right shoulder pain for 2-3 weeks"（右肩疼痛 2-3 周）。就这一句话，别的什么都没说。

Claude Code 拿到 DICOM 文件后，大概花了一个小时，输出了一份 7.72MB 的 PDF 报告。报告结构很完整，有影像分析、有发现、有结论。

但问题来了：Claude Code 的结论和人类医生的完全相反。

医生说：肩胛下肌腱有超过 50% 的撕裂。 Claude Code 说：肌腱完好，没有撕裂。

Antoine 说这是"quite disconcerting"——相当让人不安。他本来期望 AI 只是给出一个较低的评级，没想到直接否定了撕裂的存在。

仲裁：让 AI 自己裁判自己

Antoine 没有就此打住。他又做了一件很有意思的事：让 Claude Code 自己做仲裁。

他把人类医生的报告和 Claude Code 的报告都丢回去，让 Opus 重新分析。这一次，他还额外提供了之前和 ChatGPT 5.5 Pro 的对话记录——那些关于"哪些动作会引发疼痛"的讨论。

Claude Code 的做法很聪明。它启动了多个子代理（subagent），每个子代理独立分析，避免上下文偏见。大概又花了一个小时，输出了仲裁报告。

仲裁结论：支持 Claude Code 的初始判断（中高置信度）。肌腱有轻度退行性变，但没有明确的部分或全层撕裂。

换句话说，AI 不仅坚持了自己的判断，还用一种更严谨的方法论重新验证了一遍。

HN 评论区的众生相

原文本身已经够有意思了，但 HN 评论区才是真正的宝藏。

放射科医生的视角

最高赞评论来自一位放射科医生。他说了几个关键点：

1. 不看完整的 3D 数据集就没法判断——这本身就是一个合理的质疑
2. 超声不是评估钙化的最佳方式——超声可能漏掉小的钙化灶，X 光更准确
3. 冲击波疗法即使在没有钙化的情况下也不会造成伤害——只是没有帮助而已

但他也承认了一个很有意思的点：**放射科报告里说"未见某征象"，其实有个隐含的限定——"在当前检查方式和影像范围内未见"。**超声说没钙化，X 光可能说有钙化，这并不矛盾。但对普通人来说，这种表述确实很迷惑。

超声技师的直觉

一位超声技师的评论很直接：

"我喜欢 AI 帮患者理解血液检查结果这类用途，但它真的很擅长把人带进医学兔子洞。你应该想到 AI 会指出钙化在 X 光/CT 上比超声显示得更好，但它没有。"

这其实点出了一个核心问题：AI 的回答看起来很专业，但它可能遗漏了领域专家觉得"显而易见"的常识。

患者家属的故事

有一条评论看得我挺揪心。一个人说他父亲因为摩托车事故后遗症加糖尿病，脚趾截了肢，后来又做了小腿截肢。期间有 15 个不同的医生和助理，没有一个人能给出统一的治疗方案。每个人都在说"你来决定"。

"当医护人员自己都无法达成共识的时候，我们作为患者/家属除了求助于 AI 还能怎么办？"

这条评论下面有 30 多个赞。它揭示的不是 AI 有多好，而是现实医疗体系有多让人失望。

"AI 精神病"的担忧

也有人挺警惕的。一位评论者说：

"每次有某个领域的真正专家出来说话，AI 的输出就显得不够完整或者有误导性。只有在你不知道 AI 被问了什么的时候，你才会觉得它的回答有用。这本身就很值得警惕。"

还有人把对 AI 的信任比作宗教信仰：

"我算是早期 AI 采用者，分享给了很多人。奇怪的是，我好像也是圈子里最怀疑 AI 的人。那些用了 AI 的人回来跟我说体验，我听着就像在听教会里的人分享与上帝的对话。明显的问题被轻描淡写地带过。"

这些讨论很真实。不是简单的"AI 牛逼"或者"AI 垃圾"，而是各种灰色地带的碰撞。

Claude Code 的技术原理：为什么它能做这些

回到技术层面，聊聊 Claude Code 为什么能处理这种非编程任务。

核心原因是 tool use（工具调用）。Claude Code 不只是聊天，它有完整的工具链：

# Claude Code 在分析 MRI 时可能执行的流程

import pydicom

import numpy as np

import matplotlib.pyplot as plt

# 1. 读取 DICOM 文件

ds = pydicom.dcmread("shoulder_mri/0001.dcm")

pixel_array = ds.pixel_array

# 2. 提取元数据

print(f"Modality: {ds.Modality}")

print(f"Body Part: {ds.BodyPartExamined}")

print(f"Image Size: {pixel_array.shape}")

# 3. 可视化

plt.imshow(pixel_array, cmap='gray')

plt.title(f"Slice {ds.InstanceNumber}")

plt.savefig("slice_preview.png")

Claude Code 可以：

• 安装任何 Python 包（pydicom、numpy、scikit-image...）
• 读取任意格式的数据文件
• 编写复杂的分析脚本
• 调用系统工具做图像处理
• 生成报告（PDF、HTML、Markdown）

关键区别：聊天界面的 Claude 只能"看图说话"，Claude Code 能"动手干活"。它不是在猜图片里有什么，而是在用代码逐像素地分析数据。

这也解释了为什么同样是 Opus 4.8 模型，Claude Code 的输出质量可能更高——因为它可以把复杂任务分解成多个子步骤，每一步都用代码验证，而不是凭"直觉"一次性给出答案。

这事儿靠不靠谱？我的看法

说实话，我觉得这个问题没有标准答案。但可以说说我的判断。

AI 能做的

• 数据预处理和初步筛查：读取 DICOM 文件、提取元数据、可视化——这些是 Claude Code 的强项，因为这些都是确定性的代码任务
• 交叉验证：对比不同来源的信息（治疗方案 vs 指南、AI 分析 vs 人类报告），找出矛盾点
• 信息整合：把散落在各处的医学文献、临床指南、药物信息汇总到一起

AI 做不好的

• 最终诊断：AI 没有执业资格，也不承担医疗责任。它的分析可以参考，但不能替代医生
• 上下文缺失：Antoine 自己也承认，他给 AI 的信息比给医生的还少。AI 看不到患者的面部表情、活动范围、触诊结果
• 一致性问题：有 HN 用户测试过，同一个问题在不同会话里问 Claude，得到的答案经常互相矛盾。医学问题上这个问题更严重

一个有趣的悖论

HN 评论区有人说了句很精辟的话：

"不确定信息的解药不是更多信息，而是更好的信息。AI 能给你更多，但未必更好。"

这个判断很到位。AI 的价值不在于它比医生更准，而在于它能在你和医生之间提供一个独立的、不收钱的、有耐心的第二视角。

就像 Antoine 最后说的：

"被一个你信任的专家照顾，有一种难以言说的安心感。AI 能彻底打碎这种安心感，让你处于一种尴尬的中间状态——你不确定能不能完全信任医生，也不确定能不能完全信任 AI。"

我用 Claude Code 干过的"非编程"活

分享几个我自己的经验。

批量处理日志文件

有一次服务器出了问题，日志文件有几百个，每个几百 MB。手动打开看不现实。我让 Claude Code 写了个脚本：

import glob

import re

for logfile in glob.glob("/var/log/app/*.log"):

    with open(logfile) as f:

        content = f.read()

    errors = re.findall(r'ERROR.*', content)

    if errors:

        print(f"\n{logfile}:")

        for e in errors[-5:]:

            print(f"  {e}")

它自己写的脚本，自己跑的，自己给我总结了结果。整个过程比我手动 grep 快了不知道多少倍。

分析 PDF 报告

有一次拿到一份 50 页的行业报告 PDF，想快速提取关键数据。让 Claude Code 用 pymupdf 解析了 PDF，提取了所有表格数据，然后生成了一个结构化的 JSON。

import pymupdf

doc = pymupdf.open("report.pdf")

for page in doc:

    text = page.get_text()

    tables = page.find_tables()

    for table in tables:

        print(table.to_pandas())

转换数据格式

有一次需要把一堆 XML 格式的数据转成 CSV。这种活枯燥但需要精确，让 Claude Code 来干再合适不过。

关键洞察

这些任务有一个共同点：它们都需要"动手"。你需要读文件、写代码、跑脚本、看输出。纯聊天的 AI 做不了这些，但 Claude Code 可以。

这就是为什么我说 Claude Code 的价值远不止编程。它是第一个真正有"手"的 AI 助手。

对开发者的启示

这个案例对我们开发者来说，有几个值得思考的点：

1. AI Agent 的本质是"有手的 AI"

不要被"编程工具"这个名字限制了。Claude Code、Codex CLI、Gemini CLI 这些终端 AI Agent 的核心能力是：读写文件 + 执行命令 + 生成代码。这个能力组合可以用来做很多事情，不只是写代码。

2. "第二视角"是 AI 最实用的定位

不管是看 MRI、审代码、还是分析数据，AI 最大的价值不是替代专业人士，而是提供一个独立的、不受利益驱动的、永远有耐心的第二视角。

3. 别忘了验证

Antoine 的做法值得学习：他没有直接信 AI 的结论，而是做了仲裁。最终他也没有完全信仲裁的结果，而是决定"再找一个医生看看"或者"先做康复观察"。

AI 是工具，不是权威。

4. 编程能力 = AI 的通用能力

学编程不只是为了写软件。编程是 AI 与物理世界交互的桥梁。 Claude Code 能分析 MRI，是因为它能写 Python 代码读取 DICOM 文件。如果你给它接上其他工具（比如 API、数据库、硬件接口），它能干的事情会更多。

下一步能做什么？

说实话，这个方向让我挺兴奋的。想想看：

• 法律文件分析：把合同 PDF 丢给 Claude Code，让它提取关键条款、对比不同版本、标记风险点
• 财务数据分析：把财报 PDF 转成结构化数据，做趋势分析、异常检测
• 学术论文综述：批量读取论文 PDF，提取方法论、实验结果、引用关系
• 运维日志分析：自动扫描服务器日志，识别异常模式，生成告警报告

这些场景的共同点是：数据量大、格式复杂、需要多步骤处理。纯聊天 AI 搞不定，但有"手"的 AI Agent 可以。

后面我打算实际试几个这些场景，到时候再写。

Claude Code 的架构：为什么它比聊天强这么多

写到这，展开聊聊 Claude Code 的技术架构，因为这个案例刚好把它的能力展示得很清楚。

Claude Code 的核心是一个 Agent Loop。简单说就是：

1. 接收任务：用户输入一句话（比如"分析这个 MRI"）
2. 规划步骤：Claude 模型把任务拆解成多个子步骤
3. 执行工具调用：每个步骤调用对应的工具（终端命令、文件读写、代码执行）
4. 观察结果：把工具的输出反馈给模型
5. 调整策略：根据结果决定下一步怎么做
6. 循环直到完成

这个循环的关键在于第 3 和第 4 步。聊天模型没有这两步——它只能一次性生成回答，中间没法"看"到执行结果。

拿 MRI 分析来说，Claude Code 的实际执行流程大概是这样的：

# 第一步：探索文件结构

ls -la mri_data/ | head -20

file mri_data/0001

# 第二步：安装必要的库

pip install pydicom numpy matplotlib Pillow

# 第三步：写分析脚本并运行

python3 analyze_mri.py

# 第四步：根据输出调整分析策略

每一步执行完，Claude Code 都会看输出，然后决定下一步。如果第一步发现文件不是标准 DICOM 格式，它会自动切换方案。如果第三步的脚本报错，它会修 bug 重新跑。

这就是 Agent 和聊天的本质区别。聊天是一次性的，Agent 是迭代的。

Claude Code 还有一个很重要的能力：子代理（subagent）。在做仲裁分析的时候，Opus 启动了多个独立的子代理，每个子代理有自己的上下文窗口，互不干扰。这类似于人类的"多人独立评审"——让三个人分别看同一份材料，然后对比结论。如果三个人的结论一致，可信度就高很多。

这种架构设计是 Claude Code 能做复杂分析的技术基础。纯聊天模型做不到这一点。

更多"非编程"用法：我见过的骚操作

除了 MRI 分析，我在各种地方还见过不少把 AI 编程工具用在非编程场景的案例。

自动化数据采集

有人用 Claude Code 处理一堆格式混乱的 Excel 表格。这些表格是不同部门提交的，格式五花八门，手动整理要好几天。Claude Code 写了个 Python 脚本，自动识别每个表格的结构，统一格式，合并输出。

import pandas as pd

import glob

all_data = []

for f in glob.glob("reports/*.xlsx"):

    df = pd.read_excel(f, header=None)

    header_row = df.apply(lambda x: x.astype(str).str.contains("日期|时间|金额").any(), axis=1).idxmax()

    df = pd.read_excel(f, header=header_row)

    all_data.append(df)

result = pd.concat(all_data, ignore_index=True)

result.to_csv("merged_output.csv", index=False)

关键在于"自动检测表头位置"这一步——不同表格的表头在不同行，手动指定很痛苦，但写代码检测就很简单。

法律合同对比

有个律师朋友跟我说，他现在用 Claude Code 对比两份合同的差异。把两份 PDF 丢进去，让它提取条款、逐条对比、标出差异。以前这活是初级律师干的，现在 AI 几分钟就搞定了。

当然，最后还是要律师审核。AI 找出的差异可能有误判，也可能遗漏了语义上的细微差别。但作为初筛工具，效率提升是实打实的。

学术论文批量处理

研究人员用 Claude Code 批量读取论文 PDF，提取摘要、方法论、实验结果，然后生成文献综述的初稿。这个场景特别适合 Agent，因为论文数量多、每篇需要提取的信息是结构化的、输出格式需要统一。手动做这些事情枯燥且容易出错，交给 Agent 既快又准。

服务器运维

这个是我自己干过的。有一次需要检查 20 台服务器的配置是否一致。以前得一台一台 SSH 上去看，现在让 Claude Code 写个脚本跑一遍就完了。以前这种活我得花半天，现在 5 分钟搞定。

踩过的坑：别太信 Agent

说了这么多好的，也得说说坑。

幻觉问题没有消失

Claude Code 终究还是 LLM。它可能在分析数据的时候"看到"不存在的模式，在代码里写入错误的逻辑，然后用特别自信的语气告诉你"分析完成"。

我有一次让它分析一份 CSV 数据的趋势，它生成了一张看起来很专业的图表，还附了一段分析。结果我手动验证发现，它把日期列解析错了，趋势线完全是瞎画的。

教训：Agent 的输出永远需要验证，尤其是涉及数据的场景。

上下文窗口限制

Claude Code 的上下文窗口虽然比聊天大（200K tokens），但处理大文件的时候还是会遇到限制。266MB 的 MRI 数据不可能全部塞进上下文，Agent 需要分批处理。这意味着它可能遗漏某些区域的信息。

不知道自己不知道什么

这是 LLM 最危险的特性。它不会说"我不确定"——它会用很确定的语气给出一个可能完全错误的答案。

在医疗场景下，这特别危险。一个放射科医生看到不确定的影像会说"建议进一步检查"，而 AI 可能会直接给出一个判断。

就像 HN 评论里那位放射科医生说的："医学影像这东西，每个人看起来都简单，因为你不知道自己不知道什么。"

一致性问题

有人在 HN 上测试过，同一个医学问题在不同会话里问 Claude，得到的答案经常互相矛盾。而且它很容易被引导——你暗示一个方向，它就会往那个方向走。

这在编程场景下问题不大（代码要么能跑要么不能），但在需要专业判断的场景下就很危险。

AI 编程工具 vs 专用 AI 医疗工具

有人可能会问：既然要分析 MRI，为什么不直接用专门的 AI 医疗影像工具？

专用 AI 医疗工具（如 Google 的 Med-PaLM、各种 FDA 批准的影像分析软件）：针对特定影像类型训练过，有临床验证的数据，有监管审批，但只能做特定任务，灵活性差。

Claude Code 这类通用 Agent：没有针对医学影像专门训练，没有临床验证，没有监管审批，但灵活性极高，能处理各种格式、各种任务。

Antoine 的案例之所以有意思，不是因为 Claude Code 比专业工具更准确——大概率不是。而是因为它展示了一种可能性：一个通用的 AI 编程工具，居然能在医学影像分析这个高度专业化的领域给出一个合理的、有参考价值的第二意见。

这对普通人来说意味着什么？意味着在你拿到一份看不懂的医学报告时，除了 Google 搜索和挂号排队之外，你多了一个选择——一个免费的、秒回的、不带利益驱动的"初级分析师"。

当然，这个分析师可能会犯错。但正如那位患者家属说的：当 15 个医生都无法达成共识的时候，多一个参考意见总比没有好。

写在最后

这个案例让我重新思考了"AI 编程工具"的定位。

我们总是习惯性地把 Claude Code、Codex CLI 这些工具归类为"程序员的工具"。但它们的核心能力——读写文件、执行代码、处理数据——其实是通用的。编程只是这些能力最常见的应用场景而已。

就像锤子不只是用来钉钉子的。它还能敲核桃、砸冰块、当镇纸。工具的价值取决于使用者的想象力。

当然，我不是鼓励大家拿 AI 来做医疗诊断。专业的事还是交给专业的人。但如果你是一个开发者，手边正好有 Claude Code 这样的工具，不妨想想：除了写代码，你还能用它来处理什么以前觉得麻烦的事情？

说不定会有惊喜。

对了，Antoine 那篇文章的链接我放在这儿，有兴趣的可以去看看原文和 HN 评论区的讨论，391 条评论里有很多真知灼见：https://antoine.fi/mri-analysis-using-claude-code-opus

有啥问题评论区聊。