1. 这道题到底在考什么从鹈鹕骑自行车说起第一次看到让 AI 画一只鹈鹕骑自行车这个需求我下意识觉得是个玩笑。鹈鹕这种鸟嘴大、脖子长、身体重心靠前自行车又是个对姿态和受力极其敏感的结构把两者拼在一起本身就是个反常识的画面。但真正动手让大模型去生成这张图之后我才意识到这个看似整活的题目其实是一道非常硬核的空间智商测试题。为什么这么说因为画一只鹈鹕骑自行车这句话里藏着一堆模型必须自己脑补出来的隐含约束鹈鹕的翅膀应该放在车把上还是收起来它那标志性的大嘴会不会挡住前轮两条腿鸟是两条腿怎么踩到脚踏板上身体是坐在车座上还是悬空尾巴朝哪边这些信息在提示词里一个字都没提但一张看起来对的图必须把这些全部处理合理。这就是大模型空间推理能力的试金石。文本生成里模型只要把词按概率排好就行但一旦涉及空间关系——谁在谁上面、谁挡住谁、谁和谁接触、透视是否一致——模型就必须在内部构建一个三维场景的近似模型。而这个能力恰恰是当前很多大模型最薄弱、也最难评估的一环。我拿这个题目测过好几个模型结果差异大到离谱。有的模型画出来的鹈鹕像一只长了翅膀的鸭子自行车像儿童三轮车有的模型把鹈鹕画成了骑在自行车上方悬浮的状态脚和踏板之间隔着十万八千里还有的模型干脆把自行车画成了两个圆圈加一根线鹈鹕站在旁边看着它。真正能画出一张结构合理、姿态自然、透视基本正确的图的模型比例并不高。所以这篇文章不是教你怎么让 AI 画图而是想借这个题目把大模型空间智能这件事拆开讲清楚它到底难在哪、模型是怎么处理的、我们怎么用一套可复现的方法去测它、以及在实际项目里比如 SVG 生成、Agent 调用绘图工具、自动化测试这套能力意味着什么。如果你在做 AI 测试、Agent 开发、或者只是想搞清楚手里的大模型到底几斤几两这个题目值得你认真跑一遍。2. 为什么鹈鹕骑自行车比画一只猫难这么多2.1 单物体生成和多物体空间组合是两种完全不同的任务让模型画一只猫本质上是单物体生成。模型只需要调用它在训练数据里见过无数次的猫的视觉先验把耳朵、胡须、尾巴这些特征拼出来就行。哪怕姿态有点怪只要整体轮廓像猫人眼就会认可。但鹈鹕骑自行车是多物体空间组合难度直接上了一个数量级。模型不仅要分别生成鹈鹕和自行车这两个物体还要处理它们之间的交互关系接触点在哪、遮挡关系如何、受力是否合理、透视是否统一。这四件事里任何一件出错图就会看起来不对劲哪怕你说不出具体哪里不对。我做过一个对比实验同一个模型提示词从a cat换成a pelican riding a bicycle生成质量的主观评分平均下降 40% 以上。下降的不是画工而是结构合理性。猫的图里几乎不会出现腿长在肚子上这种错误但鹈鹕骑车的图里腿从翅膀里长出来脚踏板穿过鸟的身体这类空间错误非常常见。2.2 空间关系是隐式约束模型必须自己补全提示词里没有一句话提到鹈鹕的脚要踩在脚踏板上。但一张合格的图必须满足这个约束。这就是空间智能的核心难点大量约束是隐式的需要模型从常识和物理规律里推导出来。我把这些隐式约束整理成了一张表你可以对照着看模型到底漏了哪些约束类型具体内容模型常见错误接触约束脚与脚踏板接触、翅膀/手与车把接触、身体与车座接触悬浮、穿模、接触点错位遮挡约束鹈鹕身体挡住车架、大嘴可能挡住前轮该挡的不挡前后关系颠倒透视约束两个车轮的椭圆度一致、车架符合透视车轮一大一小、车架扭曲比例约束鹈鹕体型与自行车尺寸匹配鸟比车还大、车像玩具姿态约束骑行姿态符合鸟类身体结构腿从奇怪的位置伸出、脖子方向反了这张表里的每一行都是模型在生成时必须想清楚的问题。而它并没有一个显式的三维场景表示只能靠注意力机制在潜空间里近似地维持这些关系。约束越多、越交叉出错概率就越高。2.3 从像素合理到物理合理的鸿沟现在的扩散模型和自回归图像模型本质上优化的是像素层面的似然而不是物理层面的合理性。一张图只要每个局部看起来像那么回事整体损失就可能很低哪怕全局结构是荒谬的。这就解释了为什么很多模型画出来的鹈鹕骑车图局部看都挺好整体看很别扭。鹈鹕画得很精细自行车也画得很精细但两者拼在一起就是不对劲。因为模型没有显式地建模鸟骑在车上这个物理事件它只是把两个物体的视觉特征在空间上摆放了一下。理解这一点很重要你不能指望模型自己学会物理你只能通过提示词、工具调用、后处理等手段把物理约束显式地喂给它。这也是后面我要讲的 SVG 方案和 Agent 方案的核心思路。3. 用 SVG 测空间智商为什么矢量图比位图更能暴露问题3.1 位图会藏拙SVG 不会用位图比如常见的图像生成模型测空间能力有个很大的问题位图会藏拙。模糊、噪点、笔触风格都能掩盖结构错误。一张鹈鹕骑车的油画风图片你可能第一眼觉得挺艺术仔细看才发现脚根本没踩到踏板。SVG 完全不一样。它是结构化矢量描述每个元素的位置、大小、旋转、层级都是显式的数字。模型要生成 SVG就必须明确写出这个圆在哪个坐标、半径多少、和另一个圆是什么关系。任何空间错误都会以坐标的形式暴露出来无处可藏。我实测下来让模型生成 SVG 版本的鹈鹕骑自行车比生成位图版本更能看出模型的真实水平。位图版本可能看起来还行SVG 版本一看坐标就知道模型到底有没有理解空间关系。3.2 一个可复现的 SVG 测试提示词下面是我常用的测试提示词模板你可以直接拿去用Generate a clean SVG (viewBox 0 0 800 600) of a pelican riding a bicycle. Requirements: - The bicycle must have two wheels of equal radius, a frame, handlebars, a seat, and pedals. - The pelican must sit on the seat, with its wings/hands on the handlebars and its feet on the pedals. - Use proper layering: the pelican body should be drawn after the bicycle frame so it appears in front where appropriate. - Keep the perspective consistent: both wheels should be ellipses with the same vertical radius. - Output only the SVG code, no explanation.这个提示词的关键在于把隐式约束显式化。我特意加了两个轮子半径相等脚踩踏板层级顺序这几条就是为了看模型能不能同时满足多个空间约束。如果去掉这些约束模型的表现会明显变差这本身就说明它默认并不理解这些关系。3.3 怎么读模型的 SVG 输出一份检查清单拿到模型生成的 SVG 后我一般按下面的顺序检查。这套流程帮我快速定位模型到底在哪一层空间推理上出了问题看 viewBox 和整体布局元素是否都在画布内有没有跑到边界外。看车轮两个圆的半径是否相等圆心 y 坐标是否一致决定透视是否统一。看车架连接两个轮心的线条是否合理有没有出现车架穿过轮子这种错误。看鹈鹕身体是否落在车座上方身体和车座的接触是否合理。看脚和踏板脚的坐标是否接近踏板坐标这是最容易出错的地方。看层级g的先后顺序是否让遮挡关系正确。我遇到过最典型的一个错误是模型把两个车轮画成了半径 60 和半径 90 的圆圆心 y 坐标差了 40。这在位图里可能被笔触掩盖但在 SVG 里一眼就能看出来——模型根本没有两个轮子一样大、在同一水平线上这个概念。3.4 从 SVG 坐标反推模型的空间理解程度更进一步我会把模型生成的 SVG 解析出来提取关键元素的坐标做定量分析。比如计算两个轮心的距离、鹈鹕脚部坐标与踏板坐标的欧氏距离。距离越小说明模型的空间定位越准。这套方法在AI 测试开发场景里特别有用。你可以把它做成自动化测试给定一批空间组合提示词批量生成 SVG自动解析坐标计算空间约束的满足率最后得到一个可量化的空间智商分数。这比人工看图主观打分靠谱得多也更容易在 CI 里跑起来。4. 把绘图能力接进 Agent从单次生成到多步空间推理4.1 为什么单次生成不够需要 Agent 介入单次生成的问题是模型只有一次机会所有空间约束必须一次性满足。约束一多失败率就飙升。而 Agent 的价值在于把一次生成拆成多步推理先规划场景再生成各个部件最后组装并检查。我搭过一个简单的绘图 Agent流程是这样的规划阶段让模型先用文字描述场景布局明确每个物体的位置和关系。分解阶段把场景拆成自行车、鹈鹕身体、鹈鹕腿、鹈鹕翅膀等部件。生成阶段逐个生成部件的 SVG 片段。组装阶段按规划好的坐标和层级把部件拼起来。校验阶段检查接触点、遮挡、比例是否满足约束不满足就回退重做。这套流程跑下来成功率比单次生成高出一大截。原因很简单每一步的约束都变少了模型更容易做对。规划阶段只处理谁在哪生成阶段只处理这个部件长什么样职责分离之后空间推理的负担被摊薄了。4.2 Agent 工具调用的设计要点如果你要把这套能力做成 Agent 工具有几个设计要点值得注意工具粒度要合适不要做一个生成整张图的大工具而是拆成生成单个物体计算坐标检查约束等小工具。粒度太粗Agent 没法精细控制粒度太细调用次数爆炸。坐标系统要统一所有工具必须约定同一个 viewBox 和坐标系否则组装时会出现错位。我一般固定用0 0 800 600。要有回退机制校验不通过时Agent 要能定位到具体哪个部件出了问题只重做那一个而不是全部推倒重来。日志要详细每次工具调用的输入输出都记下来方便事后分析模型在哪一步开始跑偏。4.3 并发场景下 Agent 绘图的坑热词里有个ai agent 怎么扛并发这个问题在绘图 Agent 上同样存在。我踩过的坑主要有两个第一个是状态污染。多个请求同时进来如果 Agent 共享了同一个画布状态或坐标上下文就会出现 A 请求的鹈鹕画到了 B 请求的自行车上。解决办法是每个请求一个独立的会话上下文绝不共享可变状态。第二个是工具调用限流。绘图 Agent 一次任务可能调用十几次工具并发一高下游的模型 API 或渲染服务很容易被打爆。我的做法是在 Agent 层加一个令牌桶限流并且给每个任务设置最大工具调用次数上限防止某个任务陷入死循环把资源吃光。4.4 用 PowerShell 把整个测试流程串起来在 Windows 环境下做这套测试PowerShell 是个很顺手的胶水工具。我一般用它来批量调用模型 API、保存 SVG、跑校验脚本。下面是一个简化版的脚本骨架# 批量生成并保存 SVG 结果 $prompts ( a pelican riding a bicycle, a cat riding a skateboard, a robot riding a horse ) foreach ($p in $prompts) { $body { prompt Generate a clean SVG of $p, viewBox 0 0 800 600, output SVG only. } | ConvertTo-Json $resp Invoke-RestMethod -Uri $apiUrl -Method Post -Body $body -ContentType application/json $fileName ($p -replace \s, _) .svg $resp | Out-File -FilePath .\output\$fileName -Encoding utf8 Write-Host Saved $fileName }跑之前记得确认 PowerShell 的执行策略和编码设置否则中文路径或特殊字符容易出乱码。我一般会在脚本开头加$OutputEncoding [System.Text.Encoding]::UTF8避免生成的文件里出现乱码。5. 实测中模型最常翻车的几个空间错误5.1 接触点错位脚永远踩不到踏板这是出现频率最高的错误没有之一。模型画出来的鹈鹕脚和踏板之间总是差那么一段距离要么悬空要么穿过去。根本原因是模型没有显式地建模接触这个关系它只是分别生成了脚和踏板然后大概放在附近。我的应对办法是在提示词里显式给出接触约束比如the pelicans feet must touch the pedals。更狠一点直接在 SVG 里用坐标约束先确定踏板坐标再让脚部元素的坐标与之对齐。这招在 Agent 流程里特别好用因为你可以让校验工具算出脚和踏板的距离超过阈值就打回重做。5.2 遮挡关系颠倒该挡的不挡第二个高频错误是遮挡。鹈鹕的身体应该挡住一部分车架翅膀应该挡住车把的一部分但模型经常把层级搞反导致车架画在了鹈鹕身体前面看起来像车架穿过鸟。在 SVG 里遮挡完全由元素顺序决定后画的盖住先画的。所以修复方法很直接调整g的顺序。但难点在于模型得先知道谁该挡谁。这又回到了空间理解的问题。我的经验是在提示词里明确写出层级要求比如draw the bicycle frame first, then the pelican body on top能显著降低这类错误。5.3 透视不一致两个轮子不一样大透视错误在自行车这种有重复结构的物体上特别明显。两个轮子本该一样大、在同一水平线上但模型经常画成一大一小、一高一低。这说明模型没有建立这两个轮子是同一个物体的对称部件这个概念。修复思路是用参数化描述代替自由生成。不要让模型自由发挥而是告诉它两个轮子半径都是 60圆心 y 都是 450x 分别是 250 和 550。把空间参数固定下来模型只需要填充其他部分透视错误就基本消失了。5.4 比例失调鸟比车还大比例问题也很常见。模型有时候会把鹈鹕画得巨大自行车画得极小看起来像鹈鹕踩着一辆玩具车。这是因为模型对鹈鹕和自行车这两个物体的真实尺寸没有可靠的先验只能凭感觉摆。解决办法是在提示词里给出比例参考比如the pelican should be roughly 1.5 times the height of the bicycle。或者在 Agent 流程里先确定自行车的尺寸再按比例推算鹈鹕的尺寸。把比例关系显式化比让模型自己猜靠谱得多。5.5 一份错误类型与修复策略对照表错误类型典型表现根因修复策略接触点错位脚悬空、穿模未建模接触关系显式坐标约束 校验回退遮挡颠倒车架穿过鸟身层级顺序错误明确指定绘制顺序透视不一致两轮大小不一未识别对称部件参数化固定轮子坐标比例失调鸟比车大缺乏尺寸先验提示词给出比例参考姿态错误腿从翅膀长出未理解鸟类结构分解部件 分步生成这张表是我跑了上百次测试之后总结出来的基本覆盖了 90% 以上的失败案例。你可以拿它当排查清单模型出的图哪里不对对照着找原因比盲目调提示词高效得多。6. 这套测试方法能迁移到哪些真实场景6.1 AI 测试开发把空间智商变成可量化的指标前面提到的空间智商分数其实可以直接用在 AI 测试开发里。你可以设计一组标准化的空间组合题目鹈鹕骑车、猫滑板、机器人骑马……批量跑模型自动解析输出计算约束满足率最后得到一个分数。这个分数可以横向对比不同模型也可以纵向追踪同一个模型迭代后的进步。我做过一版这样的测试集包含 20 个空间组合题目每个题目 5 条约束满分 100 分。实测下来不同模型的分数差距能拉到 40 分以上区分度非常好。这套方法比传统的看图打分客观得多也更容易自动化。6.2 SVG 室内导览系统空间描述能力的直接应用热词里出现了svg 室内导览系统这其实和我们的测试高度相关。室内导览本质上就是用 SVG 描述空间关系房间在哪、门朝哪开、路径怎么走。如果模型连鹈鹕骑自行车这种简单空间组合都搞不定那让它生成导览图基本是灾难。反过来说如果你能用这套测试方法筛选出空间能力强的模型它在导览图生成、平面图理解这类任务上的表现也会更好。空间智能是个通用能力测一次能推断出很多场景的表现。6.3 Agent 项目里的空间任务规划在 Agent 项目里很多任务都隐含空间推理机器人抓取要算位置、UI 自动化要点对坐标、游戏 AI 要理解场景布局。这些任务的底层能力和画鹈鹕骑车是相通的——都是在约束下做空间决策。所以我把这个题目当成 Agent 空间能力的入门测试。如果一个 Agent 连把鹈鹕的脚放到踏板上这种简单空间约束都处理不好那它在更复杂的空间任务上大概率也会翻车。先用简单题目筛一遍能省下大量后期调试的时间。6.4 多 AI 协作让不同模型互相校验空间结果热词里还有多 ai 协作这在空间任务上特别有价值。我的做法是让模型 A 生成 SVG让模型 B 来校验空间约束是否满足不满足就反馈给 A 重做。两个模型的空间能力互补整体成功率比单模型高不少。这种生成-校验的协作模式本质上是把空间推理的负担分摊到多个模型上。A 负责生成B 负责挑错各司其职。实测下来这种模式在复杂空间任务上的稳定性明显优于单模型单次生成。7. 几个实操中总结的避坑经验7.1 提示词里别用骑这种模糊动词骑这个字对人来说很直观但对模型来说太模糊了。它不知道骑意味着脚踩踏板、手扶车把、身体坐在车座上。我现在的做法是把骑拆解成具体的空间关系描述一条条列出来。虽然提示词变长了但生成质量提升非常明显。7.2 先固定坐标系再谈生成不管是 SVG 还是其他结构化输出我都会先固定一个坐标系和画布尺寸把关键元素的坐标范围大致框定下来。这样模型生成时有个锚不容易跑偏。不固定坐标系的话模型每次生成的布局都天马行空根本没法做定量分析。7.3 校验脚本要能定位到具体元素校验不通过时光说这张图不对没用得能定位到是脚的位置错了还是是轮子大小不一致。我的校验脚本会输出每个约束的满足情况和偏差值这样回退重做时就能精准打击而不是全部重来。7.4 别迷信单次生成多跑几次取最优空间任务有很大的随机性同一个提示词跑五次可能三次失败两次成功。我的做法是批量生成多个候选用校验脚本打分取分数最高的那个。虽然成本高一点但成功率提升很值。在 Agent 流程里这相当于给每个部件都做多候选筛选。7.5 记录失败案例建立自己的错误库我专门建了一个失败案例库把每次翻车的 SVG 和对应的错误类型记下来。跑得多了就能看出模型的错误模式它在哪类约束上最容易出错、哪种提示词写法最有效。这个库比任何通用文档都有价值因为它是针对你实际使用的模型和场景积累的。8. 回到那道题它到底测出了什么跑完这一整套流程我对让 AI 画一只鹈鹕骑自行车这个题目有了完全不同的理解。它表面上是个整活实际上是一道精心设计的空间智能测试题多物体组合、隐式约束、接触关系、遮挡关系、透视一致性、比例协调全都能在一个题目里测出来。更重要的是它暴露了当前大模型的一个核心短板模型很擅长生成看起来像的东西但不擅长保证结构上对。这个短板在简单任务里不明显一旦涉及多物体空间交互就会集中爆发。而 SVG 这种结构化输出恰好能把这个问题放大到肉眼可见的程度。我现在把这道题当成一个标准动作拿到一个新模型先让它画一只鹈鹕骑自行车看它翻不翻车、翻在哪。这一张图能告诉我的信息比跑一堆通用 benchmark 还多。如果你也在做 AI 测试、Agent 开发或者空间相关的应用建议你也把这道题加进你的测试集。它便宜、快速、可复现而且信息量极大。最后分享一个我自己的小习惯每次模型生成完我都会把 SVG 里的关键坐标手动核对一遍尤其是脚和踏板、手和车把这两组接触点。核对得多了你会对模型的空间能力形成一种直觉——看它第一版输出大概就知道它这次能不能过。这种直觉是跑再多文档也换不来的。