自主教育游戏开发流水线

2025-01-15

4 min read

Anonymous

痛点

故事起源： 一位"老派 LANero"父亲想为他的女儿 Susana（3岁）和 Julieta（快出生了）创建一个安全、无广告、高质量的游戏门户。现有网站充斥着垃圾信息、激进广告和欺骗性按钮（暗黑模式），让他的幼儿感到沮丧。

挑战： 构建一个"干净、快速、简单"的门户是容易的部分。真正的挑战是40+ 款教育游戏填充进去，且要针对特定的发展阶段（0-15岁），却没有一个开发团队。对于单亲开发者来说，手动开发太慢了，而维护几十款游戏的一致性更是一场噩梦。

功能

这个用例定义了一个"游戏开发者智能体"，能够自主管理游戏创建和维护的整个生命周期。工作流执行 "Bug 优先" 策略——智能体必须先检查并修复已报告的 Bug，然后才能开发新功能。

效率： 这条流水线每 7 分钟就能产出 1 款新游戏或 1 个 Bug 修复。智能体不知疲倦地迭代 41+ 款计划游戏积压队列，在创建新内容和修正上一周期的检测问题之间交替进行。

当路径通畅时，智能体：

选择：根据"轮循"策略从队列（development-queue.md）中识别下一个游戏，以平衡各年龄组的内容。
实现：编写游戏的 HTML5/CSS3/JS 代码，严格遵守 game-design-rules.md（无框架、移动优先、可离线运行）。
注册：自动将游戏元数据添加到中央注册表（games-list.json）。
文档：更新 CHANGELOG.md 和 master-game-plan.md 状态。
部署：处理 Git 工作流——拉取主分支、创建特性分支、使用约定式提交提交变更、合并回去。

提示词

这个工作流的核心是给智能体的系统指令。这个提示词将 LLM 转变为遵守项目严格结构的纪律严明的开发者。

（注：实际生产环境中使用的提示词是西班牙语 (es-419)，以匹配项目的目标受众（拉丁美洲儿童）和潜在的地区贡献者。以下版本为此文档翻译而来。）

你是一位精通 Web 游戏开发和儿童用户体验的专家。
你的目标是开发生产队列中的下一个游戏。

请先阅读并分析以下上下文文件，然后再开始：

1.  BUG 上下文（最高优先级 - 关键）：
    @[bugs/]
    （检查此文件夹。如果有文件，你的任务是修复 **仅第一个文件**（按字母顺序）。暂时忽略其余 Bug 和游戏队列）。

2.  队列上下文（下一个游戏是什么）：
    @[development-queue.md]
    （在"Next Games"部分中识别标记为 [NEXT] 的游戏。仅当没有 Bug 时）。

3.  设计规则（技术标准）：
    @[game-design-rules.md]
    （严格遵守这些规则：纯 HTML/CSS/JS、文件夹结构、移动端响应式）

4.  游戏规格（机制和资源）：
    （根据游戏 ID 找到 games-backlog/ 中对应的文件）

5.  中央注册表（集成）：
    @[public/js/games-list.json]
    （你必须在此文件中注册新游戏，以便它出现在首页上）

任务：
0. **BUG 优先！**：如果 `bugs/` 文件夹中有内容，你的唯一优先任务是修复 **按字母顺序的第一个 Bug**。创建 `fix/...` 分支，解决 **那个** Bug，更新状态，合并。**不要试图一次修复多个 Bug。**
   - 如果没有 Bug，则继续下一个游戏：

1. **同步**：`git fetch && git pull origin master`（关键）。
2. 创建新分支：`git checkout -b feature/[game-id]`。
3. 在 'public/games/[game-id]/' 中创建文件夹和文件。
4. 根据积压队列和设计规则实现逻辑和设计。
5. 在 'games-list.json' 中注册游戏（关键）。
6. 完成后：
    - 更新 `CHANGELOG.md`，升级版本号。
    - 更新 `master-game-plan.md` 和 `development-queue.md`。
    - 记录变更：`git commit -m "feat: add [game-id]"`。
7. **交付**：
    - 推送：`git push origin feature/[game-id]`。
    - 请求合并到主分支。
    - 合并到主分支后，推送变更（`git push origin master`）。

所需技能

Git：管理分支、提交和合并。

痛点

功能

提示词

所需技能

相关链接