一个黑客松小项目，失败得很有用。

Hugging Face Build Small Hackathon 里，一位开发者想做一个“数字宠物”：它会把现实待办事项包装成冒险任务。灵感来自动画《The Amazing Digital Circus》里的 Caine，一个会制造冒险的 AI 角色。

这个设想很像今天很多 AI 产品原型：把无聊任务套进游戏壳，让 todo list 看起来像一次冒险。好玩，也危险。因为一旦进入“让模型直接生成可玩的游戏”，事情就从创意变成工程。

开发者后来放弃了待办事项逻辑，转向更硬的部分：用 Nemotron 30B 生成 Three.js 游戏。结果一路撞墙。最后，项目降级成一个简单 HTML toymaker，可以生成时钟、待办、贪吃蛇、打砖块等小玩具；复杂到 Tetris 级别，就开始崩。

失败点不玄学：代码像样，运行不稳

这不是 Hugging Face 官方项目翻车。也不能据此说 Nemotron 30B 普遍不会写代码。

更准确的说法是：在这位开发者的任务设定、上下文组织和验证方式下，模型没能稳定生成可运行的 Three.js 游戏。

环节做法结果
初始设想数字宠物把待办事项变成冒险游戏后来放弃 todo 逻辑，专攻“生成冒险”
代码生成用 Nemotron 30B 生成 Three.js 游戏常见结果是不能运行
提示增强写长提示词，解释需求和实现方式稳定性没有解决
技能卡引入游戏引擎相关 skill cards上下文窗口被挤占
扩上下文增大上下文窗口没有解决根本问题
RAG 尝试用 Codex 蒸馏技能文本，再配合 RAG有改善，但游戏仍常见空白屏
最终降级改成 HTML toymaker能生成时钟、待办、贪吃蛇、打砖块；到 Tetris 复杂度就崩

这个表最有价值的地方，是它把“AI 编程失败”从一句模糊抱怨拆开了。

不是模型完全不会写。它能写出一些局部代码，也能做简单玩具。问题出在端到端交付：生成、依赖、运行、交互、调试、修复，这些环节没有形成闭环。

对关注 AI 编程工具的开发者，这意味着评估模型时不能只看一次 prompt 的输出。要看它在白屏之后能不能定位错误、修改代码、保持状态一致，并把同一个项目连续推进几轮。

对想快速做游戏原型的独立开发者，这意味着选型要保守一点。时钟、todo、Snake、Breakout 可以让模型一口气试。Tetris、Three.js 冒险游戏、带状态和资源的交互产品，最好拆成小模块，让模型逐段写、逐段跑、逐段测。

真正的沟在验证，不在提示词长度

AI 编程最容易骗人的地方，是 demo 太顺。

它能吐出完整文件。变量名像回事。函数结构也像回事。屏幕上代码滚得很快，人会自然以为：差一点就成了。

可软件不是“像代码的文本”。软件是约束、依赖、运行时、边界条件、测试、调试和回滚。少一个环节，用户看到的就是空白屏。

这次失败里的几个变量都很典型。

上下文窗口不是越大越聪明。塞进更多技能卡，可能补了知识，也可能挤掉任务本身。RAG 能把资料递到模型面前，却不能保证模型把资料组织成可运行结构。

这不是说技能卡或 RAG 没用。更像是任务复杂度、上下文管理和验证闭环同时没跟上。资料给到了，模型也写了，但没有足够强的运行反馈把它拉回正确轨道。

这里可以做一个老对照：早期网页时代，很多人以为会写 HTML 就会做网站。后来才发现，真正麻烦的是浏览器兼容、表单、状态、权限、部署和维护。今天 AI 写代码也在重演这件事，只是文本生成把第一步变得太漂亮。

“差之毫厘，谬以千里。”放在代码里更狠。一个对象没挂上，一个事件没绑定，一个资源没加载，结果不是差一点体验，而是直接白屏。

Tetris 是个好分界线。

简单 HTML 小玩具状态少、依赖少、交互路径短。Tetris 已经需要稳定的状态管理、碰撞逻辑、旋转规则、行消除、节奏控制。Three.js 游戏还要处理渲染、对象生命周期、输入、资源、相机和浏览器运行环境。

难度不是线性增加。它是在换工种。

独立开发者该改的不是热情，是工作流

我更在意这篇复盘的原因，是它比很多成功 demo 更接近真实开发。

成功展示通常只给你看开花那一秒。失败复盘会告诉你土、温度、水和虫害。做产品的人更需要后者。

如果你正在用大模型做游戏或产品原型，比较现实的做法不是继续堆长提示词，而是改工作流。

目标不建议的做法更稳的做法
快速做原型一次 prompt 生成完整游戏先生成最小可运行版本，再逐步加功能
做复杂交互让模型同时处理渲染、状态、输入、规则拆成渲染、逻辑、输入、测试几个模块
降低白屏率只看生成代码是否完整每步运行，记录错误，把报错反馈给模型
评估模型能力看一次 demo 是否惊艳看连续修复能力、上下文保持能力、回归错误
使用 RAG / 技能卡把资料塞满上下文只喂当前模块需要的约束和 API

这对 AI 编程工具开发者也有影响。

如果工具只强调“从一句话生成应用”，很容易把用户带进 demo 幻觉。更有价值的方向，是把运行、报错、测试、版本回滚和任务拆解做进产品里。模型负责写，工具负责管。

对独立开发者来说，动作更简单：把模型当成很能写的初级合作者，不要当成完整工程师。让它写局部，让测试给结果，让运行反馈约束它。不要把一个完整 3D 游戏交给一次生成。

接下来真正该观察的也不是某个模型能不能再做出一个漂亮 demo，而是三件事：

  • 它能不能在同一个项目里连续修复错误；
  • 它能不能在上下文变长后保持规则一致；
  • 它能不能把运行反馈转成正确修改，而不是换一种方式继续白屏。

这些指标不如 demo 好看，但更接近交付。

这次项目最终降级成 HTML 小玩具生成器，反而是一个清醒选择。能跑的小游戏，比跑不起来的宏大冒险更有产品意义。

AI 编程现在最缺的不是想象力。想象力已经太便宜了。真正贵的是收敛能力：把一堆看似正确的代码，压成一个稳定可用的东西。

这也是这次失败的价值。它没有证明某个模型不行，只是提醒开发者：从想法到产品，中间不只差一个 prompt。中间还差测试、调试、拆解、运行反馈，以及愿意降级的判断力。