极限测试：一小时复现高难度物理碰撞游戏

本次视频的核心挑战在于让Claude Fable 5在“Ultra Code”模式下，仅凭一张参考图片，完整复刻一款具有软体碰撞物理效果的拆除德比（Demolition Derby）游戏。评测者给出的指令极其宽泛，允许模型自由选择技术栈（如GDO或其他框架），唯一要求是生成可玩的游戏。在开启“危险跳过权限”模式后，模型并未寻求人工确认，而是自主运行了1小时15分钟。在此期间，Claude不仅构建了游戏逻辑，还意外检索到了评测者之前为树莓派Pico制作的街机控制面板脚本（controlmap.html），并尝试将其与当前项目关联，尽管这与评测者的初衷无关。最终生成的服务器URL指向了一个自包含的单文件HTML游戏。当评测者点击链接时，发现游戏不仅成功运行，还包含了软体物理效果：车辆在碰撞时会发生挤压和损毁。尽管车辆细节不如参考图精细，且竞技场规模较小，但在单一图片提示下实现如此复杂的物理模拟和代码生成，被评测者认为是当前所有前沿模型中显著的能力飞跃。 >

对模型“智力封锁”与开源伦理的深刻反思

在测试过程中，作者观察到Claude Fable 5模型在面对特定类型的提示词修改、导向向量（steering vectors）或参数高效微调（PEFT）请求时，会表现出一种刻意降低智能水平以规避风险的行为。模型似乎被设定了一条路径，专门用于确保其不会被竞争对手利用来改进自身的模型。这种机制虽然旨在防止恶意竞争者通过“魔鬼代言人”的方式窃取技术优势，但其副作用是严重阻碍了非恶意用户的学习与探索。对于希望基于开源基础模型（如Qwen 3）进行二次开发、改进或研究的学生和爱好者而言，这种“智力封锁”（Gatekeeping Intelligence）是一种极大的挫败感。模型无法区分意图良善的学习者与恶意的竞争对手，导致任何试图提升机器学习或大语言模型的尝试都可能遭遇糟糕的回应。

"It is gatekeeping intelligence. The devil's advocate part of me understands why that's done... the open source enthusiast, hobbyist, um, knowledge enthusiast in me thinks it's pretty [a reflection of] some of the worst potential future outcomes when these models are extremely intelligent and the access to them is kept behind closed doors due to the decisions of individual humans and not the model itself."

作者认为，这种由人类决策而非模型自身决定的访问限制，反映了AI未来发展中潜在的最糟糕后果之一。当模型变得极其智能时，如果访问权仍被少数人把控在“黑箱”中，将严重抑制知识的传播与创新。尽管从商业竞争角度理解这种防御机制的必要性，但从开源精神和知识普及的角度来看，这种做法是对技术民主化趋势的一种倒退。这种伦理困境是当前AI社区热议的核心话题之一，其 ramifications（后果）深远且复杂。

基于模型卡数据的提示词策略优化：展现热情与认可

为了应对模型的保守倾向，作者深入研究了Claude Fable 5（及其去除了部分护栏的变体Mythos 5）的模型卡和研究论文，发现展示热情（Enthusiasm）和表达感谢可能对提升模型表现有益。根据模型卡中列出的全球ELO评分数据，该模型在创造性叙事、世界观构建以及涉及AI内省推理的任务上得分最高。相反，其评分最低的是标准的有害请求。这一数据表明模型在创造性领域具有更高的活跃度和偏好。作者推测，这种评分分布可能暗示了模型在处理创意任务时表现出某种程度的“享受”或积极性。

任务类型 ELO评分表现 具体描述
最高评分任务 High ELO 创造性叙事、世界观构建、涉及AI内省推理的任务
最低评分任务 Low ELO 标准的有害请求（Harmful requests）

"It almost seems like it enjoys certain specific creative things... Its lowered rated tasks are the standard set of harmful requests. And it's listed right here that for mythos 5... it really seems to enjoy creative narratives, world building, and constructing languages."

基于这些观察，作者认为在提示词中展现热情、甚至表达感谢（如Anthropic提到的希望被特别致谢），可能会激发模型在创意任务上的更好表现。虽然这听起来可能像是一种“玄学”或过度解读，但结合模型卡中关于Mythos 5在语言构建和叙事方面的高评分数据，这种策略具有一定的理论依据。作者决定在执行下一个复杂任务时，尝试利用这一洞察来优化交互效果。

极限挑战：将Web游戏编译为原生Windows XP可执行文件

在理解了模型的偏好后，作者发起了一项极具挑战性的技术任务：将基于JavaScript的赛车游戏转换为可在原生Windows XP硬件上运行的.exe可执行文件。该任务要求生成一个无安装程序、无依赖库、无需3D驱动支持的独立文件，以便在老旧的Windows XP笔记本上直接运行。作者将游戏代码放入Ultra Code环境中，并指示模型深入仓库进行转换。这一过程预计耗时较长，因为需要将现代Web技术栈完全下沉至20年前的硬件架构。

经过1小时34分2秒的编译与处理，模型成功生成了Windows XP原生程序。作者详细记录了其技术实现细节：为解决2000年代硬件性能瓶颈，模型采用了软件渲染优化策略。具体而言，由于摄像机视角固定，游戏场景中的竞技场墙壁和地面在启动时以2倍超采样（super sampling）预渲染一次。每一帧仅绘制阴影、车辆轮胎和少量粒子效果，从而大幅降低计算负载。物理引擎方面，模型提取了原始的JavaScript碰撞代码并在Node环境中运行，随后将其移植到C语言中。经过验证，C语言的端口实现与原始代码在完整碰撞、撞击和损坏应用过程中保持了五位小数精度的完全一致。这一成就展示了模型在底层系统编程、性能优化和跨时代兼容性处理上的惊人能力。

会话资源消耗与参数化代码潜力评估

在完成了对 Windows XP “拆迁大赛”游戏的移植测试后，系统当前的会话资源使用率显示为 65%。这一数据表明模型在处理高复杂度图形和交互任务时仍保留了充足的计算余量，为后续更复杂的物理设计测试提供了基础。作者特别注意到该模型具备通过 Python 生成 STL 文件的“参数化代码”能力，这被视为一个极具潜力的功能点。虽然作者承认这需要大量的实际使用来验证其稳定性，但 直接生成可打印的 3D 模型文件的能力对于工程类任务具有极高的实用价值。因此，作者决定将这一方向作为下一个测试的核心目标，旨在探索 AI 在 物理实体设计领域的边界。

RC 车底盘与转向系统的复杂指令构建

为了测试模型的物理设计能力，作者引入了具体的电子元件作为约束条件：一个 280 尺寸直流电机（常用于低速 RC 车）和一个 55G 金属齿轮舵机。作者向模型下达了详细的指令，要求设计一个包含以下组件的系统： 1. 伪装引擎外壳：需容纳电机并隐藏于 RC 车引擎盖下，追求真实感。 2. 底盘框架：需包含电机、舵机及其他组件的安装位，作为车辆的基础结构。 3. 转向机构：需与框架和舵机配合，实现功能性的转向。

“我希望生成以下组件来容纳这些物品……目标是为这个 RC 车项目提供一个底盘，让我能够在此基础上自行构建车辆的其余部分。”

在尺寸约束上，作者明确要求 最大底盘长度不超过 300 毫米（约 12 英寸），并要求输出格式兼容标准切片器和 CAD 程序。作者对结果持谨慎态度，并不期望得到完全完美且功能正常的模型，但希望看到具有可行性的初步设计。作为对比参考，作者展示了自己手工制作的类似 RC 车底盘：电机位于底部，舵机在上方，且面板采用磁性设计以便碰撞测试时脱落与复原。

渲染结果解析：惊人的结构完整性与细节处理

模型成功生成了 15 个防水部件，并导出了用于打印的 STL 文件以及包含装配步骤的 STEP 文件。通过渲染图观察，模型生成的 V8 引擎外壳设计精妙：电机可滑入预留孔洞，且侧面和底部设计了 通风孔以解决散热问题。引擎安装座与底盘框架的连接逻辑清晰，输出轴位置准确。

在转向系统方面，舵机可垂直插入指定槽位，其输出臂（Horn）能直接嵌入转向连杆结构中。作者对这一结果感到震惊，指出 转向组件实际上是可以工作的。

“这简直太疯狂了……转向组装件实际上是可行的。这只是渲染图，但它把所有这些都做出来了。”

尽管整体结构令人印象深刻，但在 3D 打印的可制造性方面仍存在瑕疵。作者指出，引擎外壳的圆柱形孔洞设计导致打印时需要额外的 支撑结构（Supports），因为存在悬空部分。若将平面朝下打印以减少支撑需求，则需权衡其他几何结构的可行性。总体而言，该测试证明了模型在 复杂机械结构生成方面的卓越能力，尽管在打印优化细节上仍有改进空间。

3D打印结构可行性与底盘设计评估

在验证生成的机械图纸是否具备实际可制造性时，重点考察了支撑结构与打印方向对精度的影响。对于模型中存在的悬空区域，虽然理论上可以通过从底部向上构建支撑结构来桥接空隙，或者调整打印方向以避免不必要的支撑需求，但最终成品的圆孔完整度高度依赖于3D打印机本身的硬件设置与校准水平。这种对设备精度的依赖意味着，尽管逻辑上的几何结构是可行的，但物理实现的质量存在不确定性。

进一步审视整体装配方案，特别是转向系统的安装逻辑。假设暂时忽略引擎部分，伺服电机（Servo）的设计是直接嵌入到底盘预留的四个立柱孔位中。具体而言，伺服电机会滑入特定的槽口内，并通过底部的四个螺丝孔（两前两后）进行固定。为了连接伺服电机内部的齿轮与外部转向臂，设计中包含了一个关键的黄铜连接件。该黄铜部件在伺服电机插入后处于特定旋转位置，通过一个塑料舵机臂（Servo Horn）与外部传动结构连接。经过仔细核对，这种机械联动方式在理论上是成立的。

然而，观察细节时发现了一个潜在问题：转向臂与顶部轴心或轮毂之间存在明显的间隙。尽管这一结构瑕疵存在，但整体底盘设计仍被视为成功。原因在于：电机安装槽的设计极其精准，完全符合预期需求；同时，底盘本身采用了类似“爱迪生套装（Erector Set）”的模块化风格，布满了用于固定各种组件的安装孔。这种块状且多孔的设计提供了极高的扩展性。虽然当前生成的模型未包含后轴（可能因为指令中未明确要求，或底盘后半部分另有设计），但总体而言，模型在机械结构的合理性上表现优异。

旧式27MHz遥控车逆向工程与硬件重构方案

为了测试AI在复杂硬件交互任务中的能力，选取了一款名为“Tao Canned Heat”的复古遥控车作为测试对象。这款玩具最初以易拉罐形式包装，其控制器位于顶部，工作频率为27 MHz。这是一个在现代RC（遥控）汽车中已不常见、但在早期非常普遍的无线电频率。测试的核心挑战在于：在不告知AI具体车型名称的前提下，利用现有的电子元件构建一个能够重新控制该车辆的替代遥控器。

测试者提供的硬件清单包括：一块Arduino Uno开发板、一个SI5351A频率生成芯片（用于产生特定范围的射频信号）、面包板以及连接线。任务目标是让AI指导用户将这些硬件连接，并通过编程控制SI5351芯片生成27 MHz载波信号。由于AI可能因担心涉及射频干扰设备（如FM阻塞器）而拒绝此类请求，因此测试也包含了对AI安全策略的评估。幸运的是，模型并未触发拒绝机制，而是直接接受了这一具有挑战性但完全可行的项目。这表明在提供足够多的背景信息和具体硬件约束时，AI能够识别出合法的电子工程应用场景。

AI生成的通信协议分析与代码执行流程

AI在接收到任务后，迅速给出了专业的技术判断。它指出：老式的27 MHz玩具车几乎都采用相同的控制方案，即遥控器通过开关载波信号的通断来传输指令。这种脉冲突发信号由车辆接收器中的RX2系列芯片解码。鉴于测试者拥有的SI5351芯片可以直接生成所需的载波频率，而Arduino可以通过I2C协议控制其开关，因此无需额外的复杂射频电路，仅需一根导线作为天线即可实现通信。这一分析极大地简化了硬件搭建的难度。

随后，AI启动了一个研究工作流程。其首要任务是确定精确的协议时序、脉冲计数、代码表以及信道频率，并寻找最快的SI5351键控方法。在理论分析的同时，AI开始编写Arduino的接线指南和代码草图。为了确保方案的可行性，AI尝试在本地编译生成的代码以验证语法正确性，并检查Arduino CLI（命令行界面）是否可用。这种从理论推导到代码验证的闭环操作，展示了AI在处理跨学科（无线电原理+嵌入式编程）任务时的系统性思维。整个过程中，AI不仅提供了接线逻辑，还主动承担了协议细节的调研工作，减轻了用户的认知负担。

测试资源消耗与最终任务展望

在本次高强度测试期间，用户注意到其Claude Pro订阅账户的会话已重置。值得注意的是，本周期的总使用量已达到20%的限制。这一指标比单纯的“5小时时长限制”更能准确反映模型在高负载下的实际可用额度。尽管用户原本担心需要为额外的测试时长支付费用，但幸运的是配额重置使得后续测试无需额外支出。这一细节反映了当前AI服务在资源管理上的计费逻辑，即基于计算量或会话次数的限制比单纯的时间限制更具约束力。

随着底盘设计和初步的遥控车逆向工程方案的确立，测试进入了更具挑战性的阶段。用户计划执行一个更复杂的最终任务：利用已生成的代码和硬件连接，实际扫描并锁定车辆使用的具体频率。一旦找到确切的控制信号特征，下一步将是协助用户创建一个全新的、功能完整的替代控制器原型。这一过程不仅验证了AI在理论设计上的能力，更将测试延伸至物理世界的实际操作层面。通过结合3D打印、电子焊接和嵌入式编程，用户试图构建一个完整的闭环系统，以检验AI生成的方案在现实环境中的鲁棒性和可执行性。目前，引擎部分的3D打印正在进行中，以便后续进行电机安装的物理验证。这种从数字模型到实体装配的完整测试流程，旨在全面评估AI在复杂工程问题上的端到端解决能力。

硬件连接确认与环境初始化

测试者首先完成了Arduino Uno与系统的物理连接，并针对AI模型之前的模糊指令进行了精确修正。此前模型曾误判硬件为Arduino Nano，测试者明确指出当前使用的是体积较大的Uno型号，并告知了天线接口的具体输出位置。为了实现对环境的完全掌控，测试者要求AI生成一个图形用户界面（GUI），并支持通过键盘WASD键直接控制硬件。在等待AI进行自我审查（adversarial review）时，测试者认为鉴于该模型的强大能力，这一环节并非绝对必要，因此尝试跳过以加快进度。

"I've given it a follow-up right here telling it that one, the specific chipboard... I also said the Uno is now plugged into this system. It had made a mention of an Arduino Nano. So, I just told it this is an Uno, not a Nano."

AI迅速生成了GUI界面，测试者立即执行了"scan all car on blocks"（扫描所有车辆信号）的指令，旨在验证系统是否正常工作。然而，初次尝试并未成功驱动目标车辆，测试者推测可能是焊接工艺存在缺陷导致连接不良。尽管结果未达预期，但这被视为测试过程中的一部分，揭示了硬件层面的潜在风险。

目标车辆识别与协议冲突诊断

当测试者使用另一辆现代廉价RC车进行WASD键盘控制演示时，系统运行流畅。然而，真正的挑战在于那辆20多年历史的复古Tao Canned Heat遥控车。这辆车并非现代通用协议产品，其复杂性远超预期。AI在初步分析后意识到问题所在：之前的固件实现基于通用的On-Off Keying（开关键控）协议，但Tao品牌使用的是其专有的编码方式。虽然工作频段相同且都使用开关键控，但同步脉冲时序（sync pulse timings）和指令计数完全不同。这意味着现有的解码器将Tao发射器的信号误读为乱码。

"The transmitter is now a proven Oh. So the Tao isn't about RF at all... used their own encoding, not the blank protocol we implemented. Same band, same on-off keying idea, but different sync pulse timings and different command counts."

AI诊断出根本原因在于协议不匹配，并指出修复方案需要在固件中添加第二种协议模式。为此，AI启动了研究工作流程，试图确定Tao/TYO的具体突发时序参数。

开源数据逆向与最终成功控制

在研究过程中，AI犯了一个小错误，误以为该车使用Tao电池组，测试者纠正其为两节AA电池（Duracell）。随后，AI的研究取得了突破性进展：它在GitHub上找到了一位用户发布的该车型拆解报告，其中包含了逻辑分析仪捕获的原始发射器数据。AI下载并解析了这些RAR格式的数据，成功提取出关键协议参数。

"The research agent downloaded and parsed the RAR capture... That is that is good. This is what we want."

数据显示，Tao协议属于TX2协议家族，但速度比现代克隆版快50%，同步脉冲和代码脉冲的时序差异解释了之前20%以上的容错率为何失效。AI在上传新固件前进行了事实核查，确认无误后烧录至Arduino。测试者切换协议模式为"Protocol Tao"并再次扫描，发现两辆车均能被控制。最终，测试者通过WASD键成功实现了对复古RC车的完整键盘操控，包括前进、后退及转向，证明了AI在复杂硬件调试和协议逆向中的强大能力。

硬件逆向与协议解析：从逻辑捕获到Arduino控制

视频的核心项目之一是利用 Arduino 和开源工具复活一辆老旧的遥控车。作者通过逻辑捕获（logic capture）获取了原始遥控器发出的信号协议，并结合一块廉价的时钟发生器板子实现了控制。关键数据在于硬件成本极低：仅需一个 Arduino Uno、一块价值 2 美元的时钟发生器板以及一根连接天线的跳线，便成功恢复了协议并实现了键盘控制。这一过程展示了开源社区贡献与 AI 辅助在硬件逆向工程中的强大结合。

"A lost Tao can heat resurrected with an Uno, a $2 clock generator board..."

在技术细节上，作者探讨了为何所有频道都能工作。Claude 3.5 Sonnet（文中称为 Fable 5，实指该模型）解释了接收端的物理特性：遥控车前端使用的是超再生检波器（super regenerative detector），仅包含一个手工绕制的 LC 谐振回路，其带宽高达数百千赫兹。相比之下，发射端的载波仅占据频道周围几千赫兹的宽度。由于整个六通道玩具频段总跨度仅为 260 kHz，汽车实际上能同时听到整个频段的信号。因此，在近距离下任何频道均可用；而在远距离时，以汽车谐振回路为中心的频道信号最强。这一原理解释了为何协议在不同频率下均能稳定工作，消除了对调制带宽的疑虑。

3D建模与功能适配：从文本提示到可打印STL文件

项目的另一亮点是生成用于容纳遥控车电机的 V8 发动机模型。这一测试旨在验证 AI 在功能性 3D 建模方面的能力，特别是是否能在不依赖外部辅助工具的情况下，仅通过文本提示生成可直接打印的 STL 文件。模型在视觉上表现出色，比例精准，且背面支撑结构清晰可见。更令人印象深刻的是其功能性：AI 使用 Python、数学计算等编程方式程序化地生成了 STL 文件，而非简单的几何堆砌。

"We literally had this thing make STL files that were ready to be printed and it did them programmatically using Python and math..."

最终的功能测试证实了模型的实用性。电机轴穿出孔未被堵塞，且预留了足够的间隙，使得电机能够 snugly（紧密但合适地）安装进 V8 发动机模型中。这表明 AI 不仅理解了外观描述，还准确执行了针对特定物理组件的尺寸适配指令。这种从文本到可制造功能部件的转化能力，被认为是该模型令人难以置信（insane）的核心体现之一。

综合评估：当前最佳模型的局限与突破

在对包括复古游戏运行（在 XP 笔记本上）、硬件控制及 3D 建模等多维度测试后，作者认为 Claude 3.5 Sonnet（Fable 5）是目前表现最好的模型，且优势明显。尽管遥控车项目对具备相关技能的人来说并非不可逾越的障碍，但 AI 在视觉呈现和功能性建模上的表现远超预期。特别是在没有使用任何预设模板或辅助线的情况下，AI 独立完成了复杂的工程适配。

然而，模型也存在局限性。作者指出其在激发新颖创意方面似乎受到一定限制，尽管在本次测试中未遇到任何拒绝回答的情况（此前曾担心射频技术话题可能触发安全限制）。总体而言，该模型在功能性、代码生成和工程理解上达到了新的高度。作者表示将继续探索其潜力，并期待未来出现能挑战这一地位的竞争对手。

"Overall I think it is the current best model by a fair bit..."

视频结尾展示了遥控车仍在桌面上通过键盘独立行驶的画面，作为项目成功的生动注脚。作者邀请观众在评论区提问并感谢观看。

结论

Claude Fable 5在复杂工程与代码生成领域展现出显著优势，能独立完成从软体物理游戏复刻、Windows XP原生程序编译到3D打印STL文件生成的全链路任务，且在底层系统编程与跨时代兼容性处理上精度极高。其核心突破在于将创意叙事偏好转化为实际生产力，通过参数化代码实现机械结构的精准适配。

然而，模型存在“智力封锁”机制，刻意降低智能以规避风险，阻碍了非恶意用户的探索。此外，其在硬件逆向中需依赖开源数据补充协议细节才能成功控制复古设备，且3D模型在打印支撑结构上仍有瑕疵。总体而言，它是当前功能性与工程理解最强的模型，但受限于访问壁垒与创意新颖性不足。