企业官网建设流程全解析

1. 这道题到底在考什么：从“鹈鹕骑自行车”说起

第一次看到“让 AI 画一只鹈鹕骑自行车”这个需求，很多人第一反应是：这不就是整活吗？跟让 AI 画“一只猫在弹钢琴”“一只企鹅在冲浪”有什么区别？但如果你真的把这句话丢给几个不同的大模型，然后认真对比它们吐出来的 SVG 代码，你会发现一个很残酷的事实——大部分模型画出来的东西，根本不能叫“鹈鹕骑自行车”。

有的画出来是一只鸟站在一个圆圈旁边，有的把自行车画成了两个不相交的圆，有的鹈鹕的嘴长在背上，还有的干脆把“鹈鹕”理解成了一团模糊的色块。这不是模型在偷懒，而是它在空间关系推理上翻车了。

“鹈鹕骑自行车”这个 prompt 之所以在 AI 圈子里被反复拿出来说，是因为它用极低的成本构造了一个复合空间约束：一个主体（鹈鹕）要坐在另一个物体（自行车）上面，鹈鹕的翅膀要够到车把，脚要踩到踏板，身体重心要落在车座附近，同时自行车本身还要保持结构合理——两个轮子、一个车架、车把和踏板的位置关系不能乱。这些约束单独拿出来都不难，但叠在一起，就变成了一场针对大模型的“空间智商考试”。

我拿这个 prompt 在几个主流模型上跑过一轮，用 SVG 作为输出格式，因为 SVG 是纯文本的矢量描述，模型没法靠“画得像”来蒙混过关，每一个元素的位置、大小、旋转角度都得用坐标和变换矩阵写清楚。SVG 在这里扮演的角色，不是画布，而是考卷。模型写出来的每一个<circle>、<path>、<ellipse>，都在暴露它对空间的理解。

这篇文章适合谁看？如果你是大模型应用开发者、AI Agent 的构建者、或者单纯想搞清楚“大模型到底懂不懂空间”的技术爱好者，那这道题背后的东西值得你花时间。我会从 prompt 设计、SVG 结构拆解、模型输出对比、Agent 调用链路、以及实际排查经验几个角度，把这场“考试”的里里外外讲清楚。

2. 为什么偏偏是 SVG：输出格式本身就是一道筛子

2.1 SVG 把“画得像”变成了“说得清”

如果用 PNG 或 JPG 作为输出，模型只要生成一堆像素，人眼看上去“差不多像”就能过关。但 SVG 不一样，它是结构化文本，每一个图形元素都要显式声明坐标、尺寸、变换。模型必须“说清楚”鹈鹕的嘴在哪个坐标、自行车的前轮圆心在哪里、翅膀的路径经过哪些点。

这就带来一个关键区别：位图输出考的是模型的图像生成能力，SVG 输出考的是模型的空间描述能力。前者可以靠海量图像数据“记忆”出类似构图，后者必须真正理解元素之间的相对位置。

我实测下来，同一个模型在生成位图时能画出一只“看起来还行”的鹈鹕骑自行车，但让它输出 SVG，坐标就全乱了。这说明它在位图模式下可能只是“拼贴”了训练数据里的相似图像，而在 SVG 模式下，它必须从零构建空间关系，真实水平就暴露了。

2.2 SVG 的可验证性：坐标不会撒谎

SVG 还有一个好处是可程序化验证。你可以写脚本解析模型输出的 SVG，检查：

• 鹈鹕的身体中心是否在自行车车座上方一定范围内
• 翅膀末端是否接近车把坐标
• 脚部路径是否落在踏板附近
• 两个轮子的圆心距离是否合理
• 车架路径是否连接了轮子、车座、车把

这些检查不需要人眼判断，纯靠坐标计算就能打分。这就把“AI 画得像不像”变成了一个可量化、可复现的测试。我在自己的测试脚本里定义了七八个空间约束，跑一批模型，得分差异非常明显。

提示：如果你要做类似的模型能力评测，SVG 是一个比位图更客观的输出格式。位图需要人主观打分，SVG 可以直接用几何计算自动评分。

2.3 从 SVG 到 Agent：这道题怎么变成工程问题

单独让模型画一次，只是玩具。但如果你把“生成 SVG”包装成一个 Agent 任务，事情就有意思了。比如：

1. Agent 接收自然语言需求“画一只鹈鹕骑自行车”
2. Agent 调用大模型生成 SVG 代码
3. Agent 用脚本解析 SVG，检查空间约束
4. 如果不满足，把具体问题反馈给模型，要求修正
5. 循环直到通过或达到最大轮次

这就变成了一个带自动验证的生成-修正闭环。我在自己的 Agent 框架里跑过这个流程，发现模型在第一轮几乎不可能完全通过，但经过 2 到 3 轮反馈修正后，合格率会明显上升。这说明模型不是完全不懂空间，而是需要外部信号帮它对齐。

3. 拆解“鹈鹕骑自行车”的空间约束：到底有多少个坑

3.1 主体与载具的层级关系

最基础的一条：鹈鹕要“骑”在自行车上，意味着鹈鹕的身体应该位于自行车车座的上方，并且两者要有接触或接近接触。很多模型会把鹈鹕画在自行车旁边，或者让鹈鹕悬浮在空中，这就是层级关系理解失败。

在 SVG 里，这对应的是元素绘制顺序和坐标范围。如果鹈鹕的<g>分组在自行车之后绘制，且其 y 坐标范围与车座重叠，视觉上才是“骑”。模型如果只是分别生成“一只鹈鹕”和“一辆自行车”然后拼在一起，就会出现位置错乱。

3.2 肢体与操控部件的对应

鹈鹕的翅膀要够到车把，脚要踩到踏板。这涉及肢体末端与目标物体的坐标匹配。模型需要知道：

• 车把在自行车的前上方
• 踏板在车架中下部，左右各一
• 鹈鹕的翅膀从身体两侧伸出
• 鹈鹕的脚从身体下方伸出

我见过最离谱的输出是：鹈鹕的翅膀长在头顶，脚长在翅膀位置，整个身体结构完全错位。这说明模型对“鹈鹕”这个生物的身体结构理解本身就不稳定，更别说让它去够车把了。

3.3 自行车自身的结构合理性

自行车虽然比鹈鹕简单，但也不是随便画两个圆就行。合理的自行车至少要有：

• 两个轮子，圆心大致在同一水平线
• 车架连接两个轮子、车座、车把
• 踏板在车架中下部
• 车把在前轮上方

模型经常犯的错误包括：两个轮子大小不一致、车架线条不闭合、踏板位置飘忽、车把和前轮没有连接。这些错误在单独画自行车时可能不明显，但和鹈鹕组合在一起，就会让整个画面显得“散架”。

3.4 视角与透视的一致性

还有一个隐藏约束是视角一致性。鹈鹕和自行车应该处于同一个视角下，通常是侧视图。如果鹈鹕是正面视角，自行车是侧面视角，拼在一起就会非常诡异。模型在生成时如果没有显式指定视角，很容易出现这种混搭。

我在 prompt 里通常会加上“side view, consistent perspective”这样的描述，但即便如此，模型有时还是会跑偏。这说明视角一致性对模型来说是一个高阶空间能力，需要多轮修正才能稳定。

4. 实测对比：不同模型在这道题上的表现差异

4.1 测试方法说明

我设计了一个简单的测试流程：

1. 统一 prompt：“Generate an SVG of a pelican riding a bicycle. Side view. The pelican should sit on the seat, wings on handlebars, feet on pedals. Output only valid SVG code.”
2. 对每个模型跑 5 次，记录输出
3. 用脚本检查 8 个空间约束
4. 人工复核明显错误

约束清单如下：

4.2 结果概览

我测了四个模型，分别用 A、B、C、D 代称。每个模型 5 次输出，统计通过约束数量：

从数据看，模型 D 表现最好，但也没有稳定满分。C3（脚踩踏板）是所有模型的共同弱点，说明肢体末端与目标物体的精细匹配是当前大模型的普遍短板。

4.3 典型失败案例拆解

模型 A 的一次输出中，鹈鹕的身体画得不错，自行车也像模像样，但鹈鹕的脚悬在踏板下方约 40 个像素的位置。从代码看，模型把踏板坐标算错了，它以为踏板在车架底部，实际上踏板应该在车架中下部。

模型 C 的一次输出更离谱：两个轮子一个在左上，一个在右下，车架是一条直线斜穿过去。这明显是坐标系理解混乱，模型可能把 SVG 的 y 轴方向搞反了。

模型 D 虽然整体最好，但有一次把鹈鹕画成了正面视角，自行车是侧面，两者拼在一起像两个不同世界的生物。这就是 C8 视角一致性问题。

注意：这些失败不是偶然的，它们反映了模型在空间推理上的系统性缺陷。如果你在做 AI 绘图相关的产品，这些坑迟早会遇到。

5. 从单次生成到 Agent 闭环：怎么把这道题做成工程能力

5.1 为什么要引入 Agent

单次生成的问题在于，模型没有机会修正自己的错误。它输出什么就是什么，错了也只能重来。但如果你把生成过程包装成 Agent 任务，就可以加入验证-反馈-修正的循环。

我在自己的 Agent 框架里是这样设计的：

• 生成节点：调用大模型生成 SVG
• 解析节点：用 Python 的xml.etree.ElementTree解析 SVG，提取所有图形元素的坐标
• 验证节点：检查 8 个空间约束，生成问题列表
• 反馈节点：把问题列表转成自然语言反馈，附上原始 SVG，要求模型修正
• 循环控制：最多 5 轮，通过则结束，否则返回最后一版

这个流程跑下来，模型 D 的最终通过率从单次的 20% 提升到了 80% 以上。说明模型有能力根据反馈修正空间错误，只是需要外部帮它发现问题。

5.2 反馈信息怎么设计

反馈信息的设计很关键。如果只说“鹈鹕的脚没踩到踏板”，模型可能不知道具体差多少。我通常会把验证脚本算出的具体数值也带上，比如：

当前鹈鹕左脚末端坐标为 (320, 480)，踏板中心坐标为 (340, 520)，垂直偏差 40 像素。请调整脚部路径，使其末端落在踏板中心 10 像素范围内。

这种带数值的反馈比模糊描述有效得多。实测下来，模型看到具体坐标后，修正成功率明显提高。

5.3 PowerShell 在流程中的角色

如果你在 Windows 环境下做这套流程，PowerShell 可以承担不少自动化工作。比如：

• 用 PowerShell 调用模型 API，保存返回的 SVG 到文件
• 用 PowerShell 调用 Python 验证脚本，捕获输出
• 用 PowerShell 管理多轮循环，记录每轮日志
• 用 PowerShell 批量跑多个模型，汇总结果

我自己的测试脚本就是用 PowerShell 做外层调度，Python 做 SVG 解析和验证。两者通过标准输入输出传递数据，配合起来很顺手。

# 示例：调用模型并保存 SVG $prompt = "Generate an SVG of a pelican riding a bicycle. Side view." $response = Invoke-RestMethod -Uri $apiUrl -Method Post -Body $body -ContentType "application/json" $svg = $response.choices[0].message.content $svg | Out-File -FilePath "output.svg" -Encoding utf8 # 调用验证脚本 $result = python validate_svg.py output.svg Write-Output $result

提示：PowerShell 处理中文和特殊字符时容易乱码，建议在脚本开头设置$OutputEncoding = [System.Text.Encoding]::UTF8，并且保存文件时显式指定 UTF-8 编码。

6. 常见问题与排查技巧实录

6.1 模型输出不是纯 SVG 怎么办

很多模型会在 SVG 前后加上解释性文字，比如“这是您要求的 SVG：”或者“希望这个设计符合您的需求”。这些文字会干扰解析。我的做法是在 prompt 里明确要求“Output only valid SVG code, no explanation”，然后在解析前用正则提取<svg>...</svg>部分。

如果模型还是加了文字，可以用这个正则：

import re match = re.search(r'<svg[\s\S]*?</svg>', text) if match: svg = match.group(0)

6.2 SVG 坐标系统混乱

SVG 的坐标原点在左上角，y 轴向下。有些模型会按数学坐标系（y 轴向上）来生成，导致图形上下颠倒。排查方法是检查轮子圆心和车座的 y 坐标关系：车座 y 应该小于轮子底部 y。

如果发现颠倒，可以在反馈里明确说“SVG y-axis points downward, origin at top-left”。

6.3 元素重叠但顺序错误

SVG 是按文档顺序绘制的，后绘制的元素覆盖先绘制的。如果鹈鹕先画、自行车后画，自行车就会盖住鹈鹕。正确的顺序应该是先画自行车，再画鹈鹕，这样鹈鹕才在“上面”。

排查方法是检查<g>分组的顺序。如果顺序错了，反馈里说明“Draw bicycle first, then pelican on top”。

6.4 多轮修正后仍然不通过

如果跑了 5 轮还是不过，通常有两种情况：一是模型能力确实不够，二是约束太严。我的做法是先把约束放宽到 7 个，看是否能过，然后逐步加严。如果放宽后能过，说明模型有基础能力，只是精度不够；如果放宽后还不过，说明模型在某个维度上有根本性缺陷。

6.5 常见问题速查表

7. 这道题对 AI Agent 开发的启示

7.1 空间推理是 Agent 的基础能力

很多人做 Agent 时关注的是任务规划、工具调用、记忆管理，但忽略了空间推理这个底层能力。实际上，很多现实任务都涉及空间关系：机器人抓取、UI 自动化、图表生成、地图导航。如果 Agent 连“鹈鹕骑自行车”都搞不定，那它在这些任务上也会翻车。

我自己的经验是，用 SVG 生成作为空间推理的测试用例，成本低、可量化、可复现。你可以把它加入 Agent 的回归测试集，每次模型更新后跑一遍，看空间能力有没有退化。

7.2 验证闭环比单次生成更重要

这道题最大的价值不是“让 AI 画一只鹈鹕”，而是展示了一个验证闭环的构建方法。生成-验证-反馈-修正，这个循环可以套用到很多任务上。比如：

• 生成 SQL 查询，验证语法和结果，反馈修正
• 生成正则表达式，验证匹配结果，反馈修正
• 生成配置文件，验证 schema，反馈修正

核心思路是一样的：用程序化验证替代人眼判断，用具体数值反馈替代模糊描述。

7.3 多模型协作的可能性

我还试过让两个模型协作：一个负责生成 SVG，另一个负责审查并给出修改建议。结果发现，审查模型有时能发现生成模型自己发现不了的问题，尤其是视角一致性和整体构图方面。这说明多模型协作在空间任务上有潜力，值得进一步探索。

8. 我在实操中踩过的坑和总结的技巧

第一个坑是prompt 里的视角描述不够强。我一开始只写“side view”，模型有时还是画成正面。后来改成“strict side view, profile view, no front view”，稳定性明显提高。这说明模型对视角指令的敏感度需要靠重复强调来提升。

第二个坑是SVG 的 viewBox 设置。如果模型不设置 viewBox，或者设置得太大太小，图形可能跑到画布外面。我的做法是在 prompt 里指定“viewBox='0 0 800 600'”，让模型在这个范围内布局。实测下来，指定 viewBox 后，坐标混乱的情况减少了很多。

第三个坑是验证脚本的阈值设置。一开始我把“脚踩踏板”的距离阈值设成 5 像素，结果几乎没有模型能过。后来放宽到 15 像素，通过率就上来了。这说明约束要合理，不能太理想化。实际工程中，你需要根据任务要求调整阈值，找到能力和精度的平衡点。

第四个坑是PowerShell 脚本的编码问题。我在 Windows 上跑测试时，SVG 里的中文注释导致脚本报错。后来统一用 UTF-8 无 BOM 编码保存文件，并且在 PowerShell 里设置$OutputEncoding，问题才解决。如果你也在 Windows 上做类似的事情，这个坑大概率会遇到。

最后一个技巧是把 SVG 渲染成图片再人工看一眼。虽然脚本能验证坐标，但有些问题只有人眼才能发现，比如颜色搭配、线条粗细、整体美感。我的流程是脚本先过一遍，通过的再渲染成 PNG，人工抽查。这样既保证了效率，又不会漏掉明显问题。

这道题看起来是整活，但背后涉及的空间推理、验证闭环、Agent 设计、多模型协作，都是实打实的工程问题。如果你正在做 AI Agent 或者大模型应用，建议把“鹈鹕骑自行车”加入你的测试集，它能在几分钟内告诉你，你的模型到底懂不懂空间。