OpenGame Web 控制中心设计：从提示词到可试玩游戏的任务化流水线
背景 上一篇文章整理了 OpenGame 的基本概念：它可以把自然语言提示词转成一个可运行的 Web 游戏工程。但如果只在命令行里执行 opengame -p "..." --yolo，很快会遇到几个工程问题： 生成任务耗时长，需要队列和状态追踪。 Agent 输出很多日志，需要实时可视化。 游戏不是“一次生成就结束”，需要 GDD 审核、分阶段实现、失败修复、版本迭代。 生成结果需要可预览、可试玩、可换皮，而不是只留在本地目录。 失败原因需要结构化，否则很难知道是 API 中断、构建失败、资源缺失，还是画面质量不过关。 所以我设计了一个 opengame-web-console：它不是简单包一层按钮，而是把 OpenGame SDK 放进一个任务化、可观察、可修复、可迭代的控制中心。 结论 这个控制中心的核心设计可以概括为一句话： 前端只负责提交需求和观察状态，后端把每一次游戏生成封装成任务，任务运行时负责规划、调用 SDK、执行门禁、自动修复、沉淀版本。 整体链路如下： 用户提示词 ↓ Web Console ↓ POST /api/tasks ↓ TaskService 创建任务记录与 workspace ↓ TaskQueue 串行调度 ↓ TaskRunner 调用 @opengame/sdk ↓ OpenGame Agent 在 workspace 中生成游戏 ↓ Playable / Visual Gate ↓ 成功：保存 previewEntry，可预览、试玩、迭代、换皮 失败：记录 failureReason，生成修复 prompt，可重试 为什么不是直接调用 CLI 直接调用 CLI 适合本地实验，但不适合做“控制中心”。控制中心需要解决的是长期运行问题： ...