三次鹈鹕骑车实验：一次失败，能说明模型不行吗？

我最初只是想做一张鹈鹕骑自行车的动图，结果连续做了三次：GPT-5.6-Sol Medium 第一次交付的动画有明显错误，切到 GPT-6-Astra Medium 后修好了，再切回 Sol，它也做出了具备基本踩踏动作的版本。

这让我开始追问：第一次失败，到底能在多大程度上说明模型能力不够？

回看完整过程，我能确定的是三次交付的差异，以及第一版为什么会出错。至于 Sol 和 Astra 谁更强，这个实验还不足以下结论。模型之外，反馈、实现方法、检查方式和可见上下文也都发生了变化。

先明确：我在检查什么

一张好看的静态插画，并不等于一段合格的骑行动画。第一次看到问题之后，我把关注点具体化为三个方面，下面也用它们回看三版作品。

• 踩踏关系：双脚随踏板运动，两个踏板相差半圈，腿部随位置变化屈伸。
• 结构关系：辐条围绕轮轴转动，前叉和车架保持连接，不能被当成图片的一部分一起旋转。
• 时间连续性：播放中动作持续变化，循环接回起点时没有明显跳变。

这里的“通过”只指这些基本关系得到实现，不代表画面毫无瑕疵，也不代表通过了完整的生物力学或自行车动力学检验。羽毛纹理、配色和线条风格可以另外欣赏，但不能替代对动作的检查。

三次制作：结果改善时，条件也在变化

第一次 Sol：旋转裁片带来了结构错误

第一版先由 Sol 调用内置图像生成工具，得到一张海岸骑行插画，再用 FFmpeg 裁出车轮附近的两个圆形区域，旋转后导出为 WebP。

实际播放时，鹈鹕、双脚和踏板都没有动；圆形裁片却带着前叉、部分车架和背景一起转，导致固定结构错位、连接断开。这两处正是我随后指出的问题。

从实现可以直接解释失败：裁片没有把辐条与前叉、车架分开，双脚和踏板也没有各自的动画。这个方法可以制造局部转动，却没有建立骑车所需的部件关系。

当时的检查只查看了首帧，并确认博客可以构建，没能发现播放中的错误。这说明交付验证不充分。不过，选择方法和检查结果本身也是模型完成任务的一部分，不能因为找到了实现错误，就把它与模型能力完全分开。

第二次 Astra：得到反馈后改用分层动画

我指出问题后，切换到 GPT-6-Astra Medium 重做。它改用代码绘制 SVG，把固定的车架、旋转的辐条以及移动的双腿和踏板分别处理。

新版双脚随相反的踏板运动，腿部屈伸，身体轻微起伏；辐条与反光片绕轮轴旋转，前叉和车架保持连接。这次还检查了多个姿态，并在浏览器中采样动画随时间的变化。

相对于第一版，交付结果明显改善。但此时同时改变了模型、可用反馈、制作方法和验证方式，无法只把改善归因于切换模型。

第三次 Sol：带着已有上下文再次制作

接着我切回 GPT-5.6-Sol Medium，希望看看要求更明确后，它能否完成这项任务。Sol 整理了机械约束和验收要求，随后也生成了一版分层 SVG 动画。

这次双脚随相反的踏板换位，腿部和身体有动作，前叉与车架也没有跟着辐条旋转。制作过程检查了四个静态相位，并在浏览器中采样 0、0.2、0.4、0.8 和 1.6 秒的实际路径。程序还检查了 65 个姿态采样点中的踏板对向关系，以及腿、脚和曲柄路径的首尾一致性。

这些证据支持一个有限的判断：第三版实现了这里关注的基本踩踏和结构关系。它们不能单独证明整个动画没有其他问题，或者所有中间时刻都满足真实机械约束。

尤其需要说明，第三次仍在同一段对话中进行。前两版的失败分析、Astra 的实现方案、代码和验证过程都已经出现在上下文里。即使第三次另写了脚本，也不能据此称为“没有参考答案的独立复测”。

哪些结论成立，哪些还不成立

把结果和条件放在一起，三次制作可以概括为：

关于这次交付，可以判断质量确实改善了。 第一版存在可观察的错误，后两版修复了这些问题。第一版失败的直接机制也能从裁片旋转和缺少腿部动画中找到。

关于模型能力，只能说 Sol 在已有上下文和更具体要求下也完成了这些基本动作。 这说明它并非在这些条件下做不出来，却不能证明它与 Astra 的首次完成能力、可靠性或总体能力相同。

关于改善的原因，这次没有分离各因素的作用。 提示更明确、方案换成 SVG、增加浏览器检查，以及获得前一版的代码示例，都可能影响结果。我们既不能只凭第一次失败断定 Sol 整体更弱，也不能只凭第三次成功断定问题“主要就是提示词”，或认为模型差异已经被排除。

原文强调要求同样明确、复测独立，并把第三次成功用于反驳对模型差异的判断，结论下得过重。这次重新梳理后，我把它定位为一份有连续反馈的制作记录，而不是公平的模型排名。

如果要比较模型本身，还需要怎样重测

这次经历仍然有价值：它让我看到了一个错误方案如何失败，也看到了补充反馈和更换实现后，作品怎样得到改善。但如果要回答“同样条件下哪个模型更可靠”，还需要另做一轮实验。

我会让两个模型分别从全新对话开始，使用完全相同的任务说明、工具权限、推理设置和尝试次数，不提供另一模型的方案或代码。验收规则也应在生成前写好，同时记录首轮结果和允许相同次数修正后的结果。

再用多个样本比较踩踏、连接、循环连续性和整体观感，才更有依据讨论差异。这是后续实验的设计，不是本次已经完成的测试。

对这三次制作，我更愿意留下这样的判断：作品能不能用，要看实际播放；失败发生在哪里，要看实现和检查；要把差异归因于模型，还得控制比较条件。这三个问题需要分别回答。

制作记录：参数与模型生成的提示词

以下保留复查所需的技术信息。三次使用的会话设置分别为 GPT-5.6-Sol Medium、GPT-6-Astra Medium 和 GPT-5.6-Sol Medium；Medium 指会话推理设置。第一版静态插画来自 Sol 调用的图像生成工具，工具没有返回底层模型 ID，不能把插画模型直接等同于 Sol。

两版 SVG 都有简化：链条没有模拟齿啮合，腿部采用卡通化处理，路面移动只是速度提示。

第一版：实际传给图像生成工具的提示词

这是 Sol 自行组织并提交给图像工具的文本。

Use case: illustration-story
Asset type: square blog feature illustration, intended as the source artwork for a short looping animation
Primary request: Create a playful, polished illustration of one pelican genuinely riding a bicycle, inspired by the current “pelican riding a bicycle” AI capability benchmark trend.
Scene/backdrop: sunny coastal road with a few simple clouds and distant sea; uncluttered background suitable for subtle motion effects.
Subject: one anatomically recognizable white pelican in full side profile, orange beak and webbed feet; wings naturally gripping the handlebars; both feet visibly and correctly placed on opposite bicycle pedals.
Style/medium: crisp editorial digital illustration with clean vector-like edges, cheerful internet-meme energy, subtle texture, not photorealistic.
Composition/framing: centered full-body side view; the entire bicycle and both wheels fully visible with generous margins; wheels perfectly circular; bicycle mechanically coherent with frame, fork, handlebars, crank, chain, pedals and saddle connected correctly.
Lighting/mood: bright, breezy, joyful.
Color palette: sea blue, warm cream, coral orange, dark navy.
Constraints: one pelican only; one bicycle only; no text; no logos; no watermark; no border; avoid extra limbs, disconnected parts, misshapen wheels, or feet that do not touch pedals.

第三版：模型自行整理的制作规格

下面的文本由 Sol 在第三次制作时写入脚本，描述画面、机械关系和检查要求。记录中没有显示它被单独提交给另一个模型执行，因此更准确地说，它是一份自生成的制作规格，不能作为两模型收到相同提示词的证据。

Create a polished, self-contained animated SVG of one pelican riding a mechanically coherent bicycle along a coastal road.

Canvas and style:
- Use an 900 × 560 viewBox and a clean editorial vector-illustration style.
- Show the pelican and the complete bicycle in side profile with both wheels fully visible.
- Use a restrained coastal palette, subtle depth, and no external image assets, libraries, logos, or watermarks.

Required motion:
- Animate the pelican actually pedaling: both feet must remain attached to two opposite pedals throughout the cycle; the knees must bend as the crank turns; the body may bob subtly.
- Keep the crank center fixed. The two pedals must stay 180 degrees apart and rotate around the crank center.
- Keep the bicycle frame, fork, hubs, rims, and tires fixed relative to each other. They must never rotate as a single cropped region or disconnect.
- Rotate only the spokes and small wheel reflectors around the fixed front and rear hubs.
- Add restrained backward road motion to communicate forward travel.
- Make the loop seamless.

Mechanical and visual constraints:
- The rear hub, crank, seat tube, head tube, front hub, fork, and frame endpoints must share consistent coordinates.
- Draw the frame as fixed vector paths. Put rotating spokes in separate groups centered exactly on the wheel hubs.
- Put each leg and foot in its own animated path. Generate enough intermediate poses that the feet track the pedals smoothly.
- Wings should reach the handlebars naturally. Avoid extra limbs, detached parts, oval wheels, text inside the artwork, and background elements crossing the bicycle.

Verification requirements:
- Programmatically verify that opposite pedal coordinates sum to twice the crank center at every sampled pose.
- Verify that the first and last pedal and leg paths are identical.
- Preview at least four phases of the cycle and test the final SVG in a browser at multiple timestamps.
- Deliver the final inline SVG and report the motion parameters and any remaining simplifications.

Astra 第二次直接编写 SVG 和运动代码，没有调用文生图工具，也没有记录一份可与上述规格逐字对照的独立绘图提示词。

三版动画直接嵌入本文。不支持 WebP 或 SVG 动画的阅读器可能只显示静态画面。