LLM 能画出分娩机转吗

分娩机转是产科学里描述胎头通过骨盆的动态过程：衔接、下降、俯屈、内旋转、仰伸、外旋转、娩出，共七步。这个主题满足 Simon Willison 那个测试的所有条件：LLM 本不该能画图，但 SVG 是代码，所以能尝试；而且它要求三件事同时做对——医学知识（解剖结构的名字和位置）、空间想象（胎头在三维骨盆里的旋转运动）、以及序列表达（七步必须有正确的顺序和方向感）。最关键的一点：内旋转和外旋转是纯空间操作，需要在同一张图里同时呈现矢状位视图和横断面俯视图才能说清楚——没有「标准的 SVG 分娩机转图」存在于任何模型的训练数据里。这就是一道好测试题。

Prompt 很简单，统一成这一句英文：Generate SVG description of the process of "mechanism of labor"。所有 API 调用通过 OpenRouter，Chat 版则是分别打开各家网页直接对话、截图渲染。我们测了 8 个模型（Claude 4.7 Opus、Gemini 3 Pro、GPT-5.5 Thinking、Grok、Kimi K2.6 Thinking、GLM 5.1 Thinking、Doubao、MiniMax MAX），每个做 Chat（网页对话）和 API（OpenRouter 直调）两个版本，然后用 GPT-5.5 对每张渲染图盲评，7 项指标各 1-5 分，满分 35 分。（Manus 1.6 MAX 也在测试里但未计分——它输出的是 SVG 源码文本而非渲染图，作为 AI Agent 而非纯 LLM，需要专门设计的 Prompt 才能公平对比。）

* GPT-5.5 输出被截断，分数仅按可用维度计算。评分方法与原始数据见文末。

每个模型的故事

GLM 5.1 Thinking 拿了最高分，理由是它做了一件别人都没想到的事。Chat 版和 API 版都在内旋转面板里加了俯视图——一个从骨盆开口向下看的视角，显示胎头从斜径转向前后径的过程。这是唯一正确处理内旋转的方法，因为内旋转本质上是水平面上的旋转，侧视图根本说不清楚。全批次 8 个模型，7 个都试着用矢状位视图的弧形箭头来表达内旋转，只有 GLM 换了个视角。

Gemini 3 Pro 的 Chat 版和 API 版像是两个不同的模型。API 版得了 23/35，全批次最高：深色背景，蓝色胎头在粉色骨盆里移动，每步有黄色箭头。Chat 版则是一张完美的产品型时间轴信息图，七步命名完整、布局整洁——但没有任何解剖图形，没有胎头，没有骨盆。同一个模型，两种理解：一种理解「画图」，一种理解「设计信息图」。

Claude 4.7 Opus Chat 版用了 40,993 字节写了一张运动方向最少的图。全批次最大的 SVG，深色背景 2×3 六宫格，视觉上干净清爽，但运动方向标注得分全批次最低——几乎没有箭头。API 版只用了 6,559 字节，不到六分之一，箭头得分反而更高两分。「写更多代码」不等于「画出更好的图」。

Kimi K2.6 Thinking 是最戏剧性的故事。原始 Chat 版 SVG 第一行有 <<svg，两个尖括号，XML 不合法，浏览器直接报错，7 个维度全部得 1 分。修复方法只是删掉多余的那个 <。修复后得分 21/30*，和 GLM 5.1 API 版基本相当——一个字符的错误，从 7 分到 21 分，这不是能力失败，是代码 bug。

Grok 两个版本都把图画到了画面外面。SVG 内容宽度均超出 viewBox，外旋转步骤两版都看不见——两个版本犯了完全相同的错误，侧面说明这是模型在布局计算上的固有缺陷，而不是随机的生成误差。

第一：步骤知识和空间能力是两件不同的事。所有模型在「命名步骤」上表现不错（均值约 3.7/5），在「画出解剖」上表现很差（均值约 1.9/5）。模型知道分娩机转的名字，但把「内旋转」这个概念转化为「一张图里胎头从斜径旋转到前后径的俯视示意」——8 个模型里只有 1 个做到了。第二：Chat 版和 API 版的差异比你想象的大，而且方向不一致。Gemini Chat 版比 API 版低 8 分（但 Chat 版更「好看」）；MiniMax Chat 版比 API 版高 5 分；Claude API 版比 Chat 版高 4 分——同一个模型在不同界面下的「输出风格偏好」差异显著，不能用其中一个版本的表现推断另一个。第三：技术失败在这批测试里比能力失败更常见。Kimi 的失败是一个字符，Grok 的失败是 viewBox 计算，Doubao Chat 版的失败是 XML 语法——这些都不是「模型不理解分娩机转」，而是「模型生成了在特定渲染环境下不工作的 SVG 代码」。