openclaw 用例翻译笔记：Autonomous Educational Game Development Pipeline

摘要：本文介绍了一个自主教育游戏开发流水线项目，由一位父亲为3岁女儿开发无广告、高质量的游戏门户。为解决手动开发效率低的问题，项目采用"游戏开发智能体"自动管理游戏生命周期，遵循"BUG优先"策略，每7分钟可生成1款新游戏或修复。智能体按严格流程选择、实现、注册游戏，并自动完成Git工作流。核心提示词将LLM转变为遵循项目结构的开发者，优先处理bug并按规范

chilavert318

442人浏览 · 2026-02-27 08:03:18

chilavert318 · 2026-02-27 08:03:18 发布

内容取之于gitup下awesome-openclaw-usecases-main工程下的30篇英文的用例文章，也是为了学习方便，今天开始逐一翻译留下笔记，供openclaw使用中的学习。

翻译内容

标题：自主教育游戏开发流水线

痛点

起源故事： 一位“老派 LANero”爸爸想为他的女儿苏珊娜（3岁）和即将出生的朱丽叶塔创建一个安全、无广告、高质量的游戏门户。现有网站充斥着垃圾信息、侵略性广告和欺骗性按钮（黑暗模式），这让他蹒跚学步的孩子感到沮丧。

挑战： 构建一个“干净、快速、简单”的门户是容易的部分。真正的挑战是在没有开发团队的情况下，为其填充 40多款 针对特定发展阶段（0-15岁）量身定制的教育游戏。对于一位独自承担的父母开发者来说，手动开发速度太慢，而保持数十款游戏的一致性正成为一场噩梦。

功能描述

此用例定义了一个“游戏开发智能体”，它自主管理游戏创建和维护的整个生命周期。该工作流程强制执行 “BUG优先” 策略，即智能体必须在实现新功能之前检查并解决已报告的bug。

效率： 此流水线能够 每7分钟生产1款新游戏或bug修复。智能体不知疲倦地迭代41+计划中的游戏待办列表，交替创建新内容和修正前几轮检测到的问题。

当路径清晰时，智能体：

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

提示词

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

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

Act as an Expert in Web Game Development and Child UX.
Your goal is to develop the next game in the production queue.

Please read and analyze the following context files before starting:

1.  BUG CONTEXT (Top Priority - CRITICAL):
    @[bugs/]
    (Check this folder. If there are files, YOUR TASK IS TO FIX **ONLY THE FIRST FILE** (in alphabetical order). Ignore the rest of the bugs and the game queue for now).

2.  QUEUE CONTEXT (Which game is next):
    @[development-queue.md]
    (Identify the game marked as [NEXT] in the "Next Games" section. ONLY if there are no bugs).

3.  DESIGN RULES (Technical Standards):
    @[game-design-rules.md]
    (Strictly follow these rules: Pure HTML/CSS/JS, folder structure, mobile responsiveness)

4.  GAME SPECIFICATIONS (Mechanics and Assets):
    (Identify the corresponding file in games-backlog/ based on the game ID)

5.  CENTRAL REGISTRY (Integration):
    @[public/js/games-list.json]
    (File where you MUST register the new game so it appears on the home page)

TASK:
0. **BUGS FIRST!**: If the `bugs/` folder has content, your only priority is to fix **the first bug in alphabetical order**. Create a `fix/...` branch, resolve **that** bug, update status, and merge. **Do not attempt to fix multiple bugs at once.**
   - IF THERE ARE NO BUGS, proceed with the next game:

1. **Synchronization**: `git fetch && git pull origin master` (CRITICAL).
2. Create a new branch: `git checkout -b feature/[game-id]`.
3. Create the folder and files in 'public/games/[game-id]/'.
4. Implement logic and design according to the backlog and design rules.
5. Register the game in 'games-list.json' (CRITICAL).
6. When finished:
    - Update `CHANGELOG.md` bumping the version.
    - Update `master-game-plan.md` and `development-queue.md`.
    - Document changes: `git commit -m "feat: add [game-id]"`.
7. **Delivery**:
    - Push: `git push origin feature/[game-id]`.
    - Request merge to master.
    - Once in master, push changes (`git push origin master`).

所需技能

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

附原文

Pain Point

The Origin Story: A "LANero of the old school" dad wanted to create a safe, ad-free, and high-quality gaming portal for his daughters, Susana (3) and Julieta (coming soon). Existing sites were plagued with spam, aggressive ads, and deceptive buttons (dark patterns) that frustrated his toddler.

The Challenge: Building a "clean, fast, and simple" portal was the easy part. The real challenge was populating it with 40+ educational games tailored to specific developmental stages (0-15 years) without a team of developers. Manual development was too slow for a solo parent-developer, and maintaining consistency across dozens of games was becoming a nightmare.

What It Does

This use case defines a "Game Developer Agent" that autonomously manages the entire lifecycle of a game's creation and maintenance. The workflow enforces a "Bugs First" policy where the agent must check for and resolve reported bugs before implementing new features.

Efficiency: This pipeline is capable of producing 1 new game or bugfix every 7 minutes. The agent tirelessly iterates through the backlog of 41+ planned games, alternating between creating new content and correcting issues detected in previous cycles.

When the path is clear, the agent:

Selects: Identifies the next game from a queue (development-queue.md) based on a "Round Robin" strategy to balance content across age groups.
Implements: Writes HTML5/CSS3/JS code for the game, following strict game-design-rules.md (no frameworks, mobile-first, offline-capable).
Registers: Automatically adds the game metadata to the central registry (games-list.json).
Documents: Updates the CHANGELOG.md and master-game-plan.md status.
Deploys: Handles the Git workflow: fetching master, creating a feature branch, committing changes with conventional commits, and merging back.

Prompts

The core of this workflow is the System Instructions given to the agent. This prompt turns the LLM into a disciplined developer that respects the project's rigid structure.

(Note: The actual prompts used in production are in Spanish (es-419) to align with the project's target audience (Latin American children) and potential future contributors from the region. The version below is translated for this documentation.)

Act as an Expert in Web Game Development and Child UX.
Your goal is to develop the next game in the production queue.

Please read and analyze the following context files before starting:

1.  BUG CONTEXT (Top Priority - CRITICAL):
    @[bugs/]
    (Check this folder. If there are files, YOUR TASK IS TO FIX **ONLY THE FIRST FILE** (in alphabetical order). Ignore the rest of the bugs and the game queue for now).

2.  QUEUE CONTEXT (Which game is next):
    @[development-queue.md]
    (Identify the game marked as [NEXT] in the "Next Games" section. ONLY if there are no bugs).

3.  DESIGN RULES (Technical Standards):
    @[game-design-rules.md]
    (Strictly follow these rules: Pure HTML/CSS/JS, folder structure, mobile responsiveness)

4.  GAME SPECIFICATIONS (Mechanics and Assets):
    (Identify the corresponding file in games-backlog/ based on the game ID)

5.  CENTRAL REGISTRY (Integration):
    @[public/js/games-list.json]
    (File where you MUST register the new game so it appears on the home page)

TASK:
0. **BUGS FIRST!**: If the `bugs/` folder has content, your only priority is to fix **the first bug in alphabetical order**. Create a `fix/...` branch, resolve **that** bug, update status, and merge. **Do not attempt to fix multiple bugs at once.**
   - IF THERE ARE NO BUGS, proceed with the next game:

1. **Synchronization**: `git fetch && git pull origin master` (CRITICAL).
2. Create a new branch: `git checkout -b feature/[game-id]`.
3. Create the folder and files in 'public/games/[game-id]/'.
4. Implement logic and design according to the backlog and design rules.
5. Register the game in 'games-list.json' (CRITICAL).
6. When finished:
    - Update `CHANGELOG.md` bumping the version.
    - Update `master-game-plan.md` and `development-queue.md`.
    - Document changes: `git commit -m "feat: add [game-id]"`.
7. **Delivery**:
    - Push: `git push origin feature/[game-id]`.
    - Request merge to master.
    - Once in master, push changes (`git push origin master`).