技术博客Hugging Face Blog·2 小时前

Amazing Digital Dentures：一个失败的项目

原标题：Amazing Digital Dentures (a failed project)

速览

本文记录了名为 Amazing Digital Dentures 的项目从启动到最终失败的全过程。作者通过回顾这一经历，探讨了项目失败的原因及背后的教训。该博客旨在分享技术产品开发中的真实案例与经验总结。

来源：Hugging Face Blog 发布日期：2026年6月7日作者：Team Article Published

这个项目的灵感来源于热门动画剧集《神奇数字马戏团》（The Amazing Digital Circus）。在该剧中，有一个名为 Caine 的 AI 假牙角色，它生活在一个虚拟马戏团中，身边围绕着一些真实人类的数字克隆体。Caine 每天为这些数字角色创造并派遣他们去执行各种冒险任务。

作者最初的想法既简单又复杂：构建一个“数字宠物”，它会引导用户进行一些冒险。这些冒险在概念上被设计为一种“过度工程化的待办事项列表”，旨在伪装成游戏的形式，从而提升用户在现实世界中的生产力。

作者详细记录了从最初构想走向项目转型（Pivot）的技术探索过程，主要围绕使用 Nemotron 30b 模型生成基于 Three.js 的完整游戏展开。

项目初期，作者试图让 AI 生成可运行的 Three.js 游戏。为了节省计算资源，作者最初为模型设置了较短的上下文窗口（Context Window）。然而，随着尝试的深入，遇到了以下技术瓶颈：

长提示词（Long Prompts）失败：作者首先尝试使用长提示词，详细解释模型需要做什么以及如何做。结果模型经常生成无法运行的游戏代码。
技能卡片（Skill Cards）失败：为了解决提示词效果不佳的问题，作者引入了 GitHub 提供的技能卡片（参考链接：github/awesome-copilot 中的 game-engine/SKILL.md）。
- 问题：这些技能卡片极大地增加了输入长度，导致原本为了节省算力而设置的短上下文窗口无法容纳，引发错误。
- 调整：作者被迫增加了模型的上下文窗口大小，但这并没有解决根本问题，生成结果依然失败。
RAG（检索增强生成）尝试：作者转而使用 Codex 将技能“蒸馏”（Distill）为单个文本文件，并在此基础上使用 RAG 技术。
- 结果：这种方法在一定程度上改善了代码的结构，但生成的游戏仍然无法完全运行。代码中总存在细微错误，导致最终呈现为空白屏幕。

鉴于生成完整游戏的尝试屡遭挫折，作者放弃了让 AI 生成复杂游戏的目标。项目最终转型为一个简单的 HTML 玩具制造器（HTML toymaker）。

目前，该项目已作为演示空间上线： Amazing Digital Pet Dentures Space

灵感来源：项目受《神奇数字马戏团》启发，旨在通过游戏化冒险提升现实生产力。
技术栈：主要使用 Nemotron 30b 模型，前端框架为 Three.js，辅助工具包括 Codex 和 RAG 技术。
工程挑战：
- 长上下文窗口与计算资源之间的权衡导致初始配置失败。
- 引入外部技能卡片（Skill Cards）导致上下文溢出。
- 即使使用 RAG 优化，生成的代码仍存在逻辑或语法错误，导致前端渲染为空白。
最终形态：从“生成完整游戏”降级为“生成简单 HTML 组件”，仅支持逻辑简单的应用（如时钟、贪吃蛇），无法处理复杂游戏逻辑（如俄罗斯方块）。
未来方向：作者表示已放弃当前方向，正在考虑新的项目切入点，并寻求社区建议。

这个项目虽然被作者自称为“失败的项目”，但它生动地展示了当前 AI 代码生成技术在复杂应用开发中的局限性：

上下文管理的复杂性：在利用大模型生成代码时，如何平衡技能库的丰富性（通过 Skill Cards 或 RAG 引入）与模型上下文窗口的限制，是一个典型的工程难题。盲目增加上下文长度并不总能解决语义理解或代码生成的准确性问题。
生成式 AI 的代码可靠性：即使使用了蒸馏和 RAG 等技术手段，AI 生成的代码仍可能存在细微但致命的错误（导致空白屏幕）。这表明在将 AI 生成的代码直接用于生产环境或复杂交互场景时，仍需大量的人工审查和调试。
敏捷迭代与转型（Pivot）：作者没有固守最初“生成完整游戏”的高难度目标，而是根据技术反馈迅速调整预期，将项目降级为“简单 HTML 生成器”。这种基于实际测试结果快速调整产品形态的做法，是开源开发和技术原型验证中的重要经验。

该项目为开发者提供了一个真实的案例，说明了在尝试用 LLM（大型语言模型）自动化复杂前端游戏开发时可能遇到的陷阱，以及如何在失败中寻找可行的最小可行性产品（MVP）。