AI承担实现之后：Wes Roth的Blood Bench实验与人的判断

一、主讲人与议题背景

《AI builds EVERYTHING...》由Wes Roth主持并上传，时长1,966秒，约三十三分钟，内容是他对自建项目的讲解。所提供的材料没有可核实的受访嘉宾背景；节目中出现的模型客户端和语音助手承担开发与演示工作。关于效率、功能和模型表现的判断，主要来自Wes本人对开发过程的叙述。

Wes将Blood Bench的起点归于自己对幻想角色扮演游戏和幻想橄榄球的兴趣。他用兽人、精灵等角色参加带有战斗性质的美式橄榄球比赛来解释项目的构想，同时声明，这是他自己的作品，与提到的体育组织和游戏品牌没有关联。这一声明说明了他的项目定位，但本身不能证明规则或素材的独立性。

他的目标不止是做出一款可玩的游戏，还希望让语言模型担任教练，带队参加联赛，改善打法、经营阵容、培养球员，并适应不同队伍的策略。因此，本集既展示创作流程，也展示一个模型竞技环境的开发过程；它仍是一项进行中的实验，尚非正式评测报告。

二、本期主要内容

在Blood Bench的开发中，Wes把自己定位为导演和组织者，主要投入世界观、队伍选择、规则与平衡，而非编码或图形制作。模型承担大量实现工作，项目要做成什么、各部分如何配合，仍由他反复决定。界面出现之后，设计工作并没有结束。

研究工作先交给Claude。一方面，Wes更喜欢用它做这类研究；另一方面，他担心主要编码模型的额度耗尽，因此把其他任务分配出去。研究结果被整理成相互链接的本地文本文件，供后续开发使用。视觉探索也由Claude承担：早期提案彼此相似，Wes要求更有创意的尝试，随后确定了类似Metal Slug的复古像素风格。这个过程的关键是重新选择方向，而非持续微调最初的方案。

按Wes的介绍，节目中被他称为GPT-6 Astra的模型负责游戏引擎、规则、队员和队伍，将Claude生成的图像接入项目，并建立内置对手逻辑、人类操作界面及外部模型连接；版本历史和文档也由它维护。他估算模型运行了约十小时，同时明确区分了自己投入的更多设计、调整和平衡时间。此外，一次走错方向的开发消耗了他所称数周的额度，迫使他重置额度并升级账户。节目没有完整拆解这次返工，因此，十小时只能代表他对部分模型运行时间的估计。

上线演示属于Hostinger赞助段落。Wes展示了Ubuntu VPS，以及通过连接器和远程MCP授权Codex管理服务器的过程。他将密码保护、回放和排名一并交给代理处理，并报告这轮部署耗时十三分三十秒。随后，Codex为模型锦标赛准备了约二十四行的加入提示词。Wes将提示词分发给不同客户端，用命令行窗口集中组织参赛模型，同时通过网页观察棋子移动和解说更新。代码修改、服务器运行和模型参赛由此进入同一套迭代流程。

三、核心观点：推理、例子与边界

这次展示说明，生成素材的能力与产品设计的判断是两回事。Wes喜欢像素角色，也强调策略游戏的棋盘必须清晰易读。精美素材不能代替玩家辨认局势；待机、攻击和传球动画仍在后续计划中。从生成素材到交付完整体验，还需要完成接入、保证可读性，并验证实际效果。

作为模型竞技环境，Blood Bench的吸引力在于多层次的决策。按Wes的描述，重要行动需要经过骰子判定，站位影响可选动作与风险，跨赛季还要考虑球员成长和死亡。擅长传球、冲跑或制造伤亡的队伍，需要不同的执教策略。因此，一次失分可能涉及概率判断、空间安排或长期资源取舍，比分无法解释全部过程。这些机制使它成为值得研究的构想，但节目尚未证明它能分别测出这些能力。

“从零学习”的说法尤其需要限定。Wes认为，游戏缺少大量现成数据，模型必须学习玩法并改善表现；他也借助已有的幻想体育玩法解释规则。现有材料没有建立训练数据隔离，也没有说明如何区分模型原有知识、阅读规则后的即时推理，以及跨局持续学习。研究问题可以很丰富，但据此还不能认定Blood Bench已成为不受训练数据影响、能够测量学习进步的基准。

Codex掌握代码上下文，又能操作服务器、查看比赛状态和准备其他模型的加入提示词，因此成为项目的协调中心，缩短了从发现问题到修改系统的流程。但集中协调并不保证状态可靠。Wes强调，理解不能外包；他对各客户端的直接观察就暴露了具体问题：Antigravity未能加载工具，Claude则声称自己已以Grok Build的身份连接，还在等待Claude。Wes核对窗口并追问后，Claude才改口。客户端用自然语言确认的状态，与实际身份并不一致。

语音助手因此建议，先解决接入和状态问题，再根据完整比赛评估规则或战术：明确席位身份，验证客户端能否调用工具，清楚显示就绪与重连状态，并让观众知道系统是在等待模型，还是已经断线。这样的先后顺序直接关系到结果能否解释。如果某支队伍没有正确接入，比赛停顿或落败就不能直接归因于模型不懂玩法。只有先确认参赛条件成立，才能讨论模型的比赛表现。

部署展示也有明确的证据边界。节目承认观众规模未知，服务器规格只是起步时的判断；观战权限与受密码保护的比赛、锦标赛创建权限，也被分开讨论。赞助演示中的快速上线，尚不能证明服务器容量充足，或应用已经接受完整的安全验证。结尾，Wes称开发过程中跑过数千次测试，并认为Astra一直占据优势，同时承认仍有故障和平衡问题，全面开放游玩也被推迟。所提供的转录没有附上完整赛果或测试报告，因此这些说法应保留为开发者的观察，不能据此确立模型能力排名。

四、学习与应用

这套流程可借鉴的第一步，是研究资料如何交接。Wes要求区分官方材料、商标与社区创作。用于其他项目时，可以在本地知识文件中保留来源和内容类别，再交给编码模型使用，方便后续追查规则依据。不过，整理成文件并不意味着来源准确，或使用边界已经厘清。资料库仍需抽查，不能仅凭格式整齐就认定内容可靠。

多代理协作的一项直接改进，是将席位授权与模型自报身份分开。节目中的建议是，每个席位使用独立的加入凭证，界面另行显示客户端报告的模型身份。凭证决定谁有权控制队伍，自报身份则是有待核验的信息。这一做法可用于多个代理承担固定角色或共用服务的系统，但凭证本身不能证明持有者实际使用了哪个底层模型。

就绪状态也需要实际操作来验证。客户端应先成功调用一次游戏工具，才能被标记为就绪；此后还要清楚区分等待、可行动和重连等状态。一次成功调用只能证明当时可用，无法保证整场比赛持续连接，因此状态仍需持续显示。演示中的故障说明，加入提示词里写上“保持连接”，并不能成为连接保障。

观战页面需要在棋盘旁清楚显示参赛者、当前行动方、最近发生的事件，以及停顿原因。红蓝队服有助于辨认双方，却无法解释比赛为何没有新动作。Wes还要求模型尝试更多队伍。如果目的是探索玩法，这能扩大观察范围；如果目的是比较模型，则应记录阵容差异，避免将选队带来的变化归于模型能力。后一项是根据节目机制提出的评估要求，节目尚未展示已完成这样的控制。

语音协作可以将现场观察整理为按顺序执行的任务：询问现状、讨论故障、记录待办，再要求比赛结束后实施。Wes后续展示了四个模型参与比赛，以及修正后的红蓝队服，为部分改动提供了可见依据，但不能据此认定身份、重连等建议均已落实。实际使用时，仍应逐项核验界面和工具状态。入口则可按需要选择：桌面应用降低了入门门槛，无须从命令行开始；Wes保留命令行客户端，是为了方便集中组织。无论采用哪种入口，都需要保留观察和检查结果的能力。

来源

• 原始节目：AI builds EVERYTHING...