从0→1 AI游戏实战演练
Pac-Man 实战：从最小可玩原型，到机制修正、玩法扩充、图片素材与完整 UI
概述
本篇文档将引导你亲历一次使用 Pink Agent 从 0 到 1 开发小游戏的完整过程。你会从一个空白 Cocos 2D 项目开始，先用最短 Prompt 做出只有移动、吃豆和计分的最小可玩版本；再通过真实试玩发现问题，让 Agent 修正移动、速度和墙体碰撞；基础机制稳定后，继续加入能量豆、幽灵、生命与胜负等玩法；最后让 Agent 创作图片素材、接入资源并完成整体 UI 美化。
过程中，你还会学习如何在同一项目和同一对话中持续迭代，以及如何把 Preview 截图交给 Agent，准确指出文字溢出、布局或素材等局部问题，而不必重新描述或重做整个游戏。
整个过程遵循一个简单原则：先让游戏跑起来，再逐层提高要求；每次修改后都进入 Preview 亲自验证。
你会经历什么
| 阶段 | 开发目标 | Pink Agent 展示的能力 | 你需要学会的交互方式 |
|---|---|---|---|
| 1. Quick Start | 从空白项目得到最小可玩版本 | 创建 Scene、脚本和基础玩法，并启动 Preview | 用一句话描述最小可玩目标 |
| 2. 修正机制 | 解决移动、停止、速度和碰撞问题 | 理解并继续修改已有工程 | 用明确规则和数值描述问题 |
| 3. 扩充玩法 | 加入能量豆、幽灵、生命和胜负 | 在现有逻辑上增加状态和碰撞分支 | 同时说明新增内容和保留内容 |
| 4. 美化界面 | 生成图片素材并完成三栏 UI | 创作素材、接入资源、重排界面和绑定状态 | 描述视觉目标，但保留玩法不变量 |
| 续接修改 | 根据实际画面修正局部问题 | 读取截图并继续当前上下文 | 用“截图＋位置＋现象＋期望”反馈 |
开始前准备
你只需要：
- Pink IDE；
- 一个空白 Cocos 2D 项目。
你可以使用如下命令创建并打开项目：
cocos create -j pacman-minimal -t 2d
pink pacman-minimal第一步：Quick Start——先做出能玩的版本
本步目标
第一次请求不追求完整 Pac-Man，也不处理图片和复杂 UI。只需要玩家能移动、豆子能被吃掉、分数会变化，并能在 Preview 中看到结果。
这一轮让你亲历从空白项目到第一个可玩 Demo：先用最少需求换取第一次成功，再通过试玩决定下一步改什么。
提交 Prompt
复制下面的 Prompt：
请在当前空白 Cocos 2D 项目中做一个最小 Pac-Man 原型，只实现三件事：方向键控制黄色圆形角色在简单迷宫中移动且不能穿墙；吃到白色豆子后豆子消失、分数 +1；吃完所有豆子后显示“YOU WIN”。仅使用一个 Scene 和 Cocos 基础图形，不要添加幽灵、能量豆、生命、音频、图片或其他玩法。完成后请打开预览。这个 Prompt 有意保持简单，直接描述玩家最终能做什么。你无需先理解 Scene、Node、Component 或脚本应该怎样组织。
观察 Agent 工作，但不要急着追加功能
Pink Agent 会分析空白项目、创建场景和脚本、保存资源，并尝试构建或打开 Preview。这个阶段先让 Agent 完成，不要在它工作途中继续加入幽灵、素材或菜单。
在预览中亲自试玩
至少完成以下验证：
- 方向键可以控制黄色角色；
- 玩家经过白色豆子后，豆子消失；
- 分数随吃豆增加；
- 游戏可以持续运行，没有阻塞操作的错误。
第一版出现手感粗糙、碰撞不稳定或角色继续滑行并不意外。Quick Start 的成功标准是获得第一条可玩的循环，这些机制问题留到下一步集中修正。
第二步：不要重做——修正已有游戏的机制
Quick Start 证明了项目能跑，但“能跑”不等于“操作正确”。现在要让 Agent 理解已有实现，并只修正移动、停止、速度、墙体和豆子规则。
这一轮让你亲历 Agent 如何继续已有工程：不重新生成游戏，只针对真实试玩中发现的机制问题做局部修改。
提交 Prompt
请继续修改当前 Pac-Man，不要重做项目。这一步只完善基础移动和碰撞：
- 墙体要真正阻挡玩家，玩家只能沿迷宫通道四方向移动；
- 只有按住方向键时玩家才移动，松开按键后立即停止，不要继续滑行；
- 将玩家移动速度设为 2 格/秒；
- 豆子只放在可行走区域，并且每颗只消失和计分一次。
保留现有基础图形、分数和吃完豆子获胜逻辑。不要添加额外资源或其他玩法。完成后请打开预览。与 Quick Start 相比，这一轮有三个关键变化：
- 明确告诉 Agent 继续当前项目，不要重做；
- 将“移动慢一点”改成可验证的 2 格/秒；
- 同时写清需要修改的规则和必须保留的旧功能。
用真实输入验证修改
在 Preview 中依次检查：
- 按住方向键时移动；
- 松开按键后立即停止；
- 持续移动一秒，距离约为两个网格；
- 撞墙后停在墙外，不会穿墙；
- 豆子只出现在道路上；
- 同一颗豆子只消失和计分一次；
- 吃完豆子仍能进入胜利状态。
这一步学到什么
修改已有项目时，一个有效 Prompt 通常由四部分组成：
继续哪个项目
＋ 要修正的具体行为
＋ 可以验证的数值或边界
＋ 必须保留的已有功能这比重新描述整个游戏更可靠，也更能发挥 Agent 阅读现有工程和局部修改的能力。
第三步：扩充玩法——从单一机制变成完整游戏循环
基础操作稳定后，再增加彼此相关的一组玩法：能量豆改变玩家状态，幽灵根据状态改变行为，碰撞影响生命，生命耗尽产生失败。
这一阶段仍使用基础形状和颜色。先验证玩法，后续再承担图片和 UI 的复杂度。
这一轮让你亲历一个小游戏如何从单一机制逐渐形成挑战、状态变化和胜负闭环，同时保留前两步已经验证的操作基础。
提交 Prompt
请继续当前 Pac-Man，不要重做项目，并保留已验证的按住移动、松开立即停止、2 格/秒速度、墙体碰撞和吃豆计分。
适当扩展迷宫并保持道路连通，加入左右隧道；把四个角落的豆子改为更大的能量豆。玩家吃到能量豆后进入 8 秒能量状态，并用玩家颜色变化表示状态，结束后恢复。
增加幽灵模式：用红色基础图形表示幽灵：正常状态下沿通道追逐玩家；玩家处于能量状态时，幽灵变为蓝色并逃离；能量状态下被玩家碰到后，幽灵返回出生点并恢复。幽灵出生点位于画面中心封闭的 3x3 区块内。
玩家初始 3 条生命，正常状态碰到幽灵时失去 1 条生命并回到左上角出生点，生命为 0 时显示“GAME OVER”；吃完豆子仍显示“YOU WIN”。
幽灵和其他新增内容使用基础形状和颜色替代即可；只保留必要状态文字，不制作菜单、按钮、正式 HUD、动画或音频。完成后请打开预览。验证各个游戏状态
不要只确认“画面里出现了幽灵”。需要实际覆盖以下状态转换：
- 从左右隧道穿越；
- 吃到能量豆后进入 8 秒特殊状态；
- 特殊状态结束后恢复；
- 正常状态碰到幽灵会失去生命并重生；
- 特殊状态碰到幽灵时，结果变为吃掉幽灵；
- 生命降到 0 后显示红色
GAME OVER； - 吃完豆子仍然可以获胜。
这一步学到什么
- 复杂需求也应建立在已验证的旧版本上；
- 新增规则要写出“触发条件→状态变化→结果”；
- 用颜色和基础图形可以低成本验证状态机；
- 图片素材、UI 和音效应等到玩法稳定后再加入；
- 每增加一组机制，都要回归前面已经通过的移动、碰撞和计分。
第四步：创作图片素材并完成整体 UI
前三步解决的是“游戏怎么玩”，第四步才解决“游戏看起来怎么样”。这一轮让 Pink Agent 为关键对象创作图片，并将现有画面重排为顶部标题、左侧信息、中央迷宫、右侧状态和底部结果区。
这一轮让你亲历 Agent 如何在玩法稳定后生成素材、接入资源并调整 UI，同时确保视觉升级不会破坏已有游戏机制。
提交 Prompt
请继续当前 Pac-Man，在保留现有玩法的基础上完成图片素材创作和整体 UI 美化。
为 Pac-Man、当前游戏中的幽灵和迷宫墙砖生成一套统一风格、有质感的 2D 图片素材，并直接接入当前场景。Pac-Man 和幽灵使用透明背景 PNG，墙砖适合连续铺设；图片中不包含文字。豆子和其他 UI 元素继续使用 Cocos 基础图形、颜色和文字即可。
整体画面使用黑色背景。顶部居中显示黄色 `PAC-MAN` 标题；标题下方分为三栏，中央迷宫是最大的主体区域，左右两栏用于信息展示：
- 左栏是记分栏，依次显示总得分、生命值、普通豆数量、能量豆数量和开始/重新开始按钮；按钮下方紧接一段简短的游戏玩法介绍，说明文字统一使用 `secondary` 辅助文字色。
- 中栏显示完整游戏迷宫，保持当前迷宫结构、对象位置和碰撞关系。
- 右栏罗列幽灵状态和特殊状态：显示当前每个幽灵的状态，以及 Pac-Man 当前的特殊状态和剩余时间。所有内容读取真实运行状态，不使用固定演示数据。
画面最底部预留约 1.5 行文字高度作为结果区。正常游戏时保持留白；游戏成功时在这里显示绿色成功文字，游戏结束时显示红色失败文字。
开始/重新开始按钮需要真实可用。保留当前工程已验证的 2 格/秒移动、松开停止、墙体碰撞、隧道、吃豆计分、能量状态、幽灵行为、生命和胜负规则。图片与布局调整不改变这些玩法结果。完成后请打开预览。这条 Prompt 没有规定具体节点或脚本结构，但给出了四类清晰约束：
- 素材范围：只生成 Pac-Man、幽灵和墙砖；
- 布局结构：顶部标题、下方三栏、底部结果区；
- 数据来源：分数、豆子、生命、状态和倒计时都读取真实游戏数据；
- 玩法不变量：视觉修改不改变移动、碰撞和状态逻辑。
检查第一版视觉结果
第一版已经可以看到明显的视觉跃迁：
- 顶部出现黄色
PAC-MAN标题； - 左侧形成游戏信息和按钮区域；
- 中央迷宫成为主要视觉区域；
- 右侧显示幽灵与 Pac-Man 状态；
- 资源目录中出现 Pac-Man、普通幽灵、受惊幽灵和墙砖图片；
- 基础几何角色被图片素材替换。
第一版仍可能出现文字越界、边距不统一、颜色不协调或素材质感不符合预期。此时可以继续当前对话，针对具体问题追加局部修改。
用截图续接对话：告诉 Agent 具体哪里需要改
截图是一种非常有效的上下文。它能帮助 Agent 理解“哪个区域有问题”，但仍应配合简短、具体的文字，说明现象和期望结果。
本次实际检查发现两个问题：左右信息栏的文字向左溢出边框，墙体材质也不够符合预期。于是直接在同一对话中附上当前 Preview 截图，并发送：
可复制的截图续接 Prompt
GAME INFO 和 LIVE STATUS 中的文字向左溢出边框了，请调整面板内的布局、对齐和留白，确保所有文字完整显示在边框内；另外，把墙体素材改成红砖质感。
只修改这些视觉问题，保留当前已经完成的三栏布局、图片角色和全部玩法。完成后请重新打开预览。从截图中可以看到，墙体已经变为红砖素材，左右栏文字重新排布，之前完成的三栏结构和游戏玩法仍被保留。
推荐的截图反馈模板
请继续当前项目，并查看我附上的 Preview 截图，只修改下面的问题：
- 位置：<问题在画面的哪个区域>
- 现象：<现在实际看到了什么>
- 期望：<希望修改成什么效果>
保留：<不希望被回退或重做的已有结果>。
完成后重新 Preview，并给出修改后的截图。截图反馈尤其适合：
- 文字溢出、遮挡和对齐问题；
- 间距、尺寸和层级不合理；
- 图片素材风格或颜色不符合预期；
- 某个状态下显示了错误的 UI；
- 只想修改局部，不希望 Agent 重做整个场景。
它不应替代可验证的信息。遇到操作或逻辑 Bug 时，还要补充输入步骤、实际结果和期望结果。
最终验收：不要止步于“Agent 已完成”
完成前面几步后，至少重新走一遍下面的核心链路：
玩法验收
- 按住方向键时移动，松开立即停止；
- 移动速度仍为 2 格/秒；
- 墙体继续阻挡玩家，隧道仍可通过；
- 普通豆和能量豆数量随游戏变化；
- 特殊状态和剩余时间正确变化；
- 幽灵状态与真实行为一致；
- 生命、胜利和失败逻辑没有回归；
- 开始/重新开始按钮真实可用。
视觉验收
- Pac-Man、幽灵和墙砖图片正常加载；
- 角色透明背景正确，没有方形底色；
- 左右栏文字不溢出、不遮挡；
- 中央迷宫仍是视觉主体；
- 成功文字为绿色，失败文字为红色；
- UI 数字和状态来自真实游戏数据；
- Console 没有新增 error 或资源加载警告。
构建成功、脚本保存成功或 Agent 回复“已完成”都不能单独证明游戏已经完成。最终结论来自 Preview 中的真实操作与画面。
四步走完后，你已经掌握了什么
这次实战会带你逐步学习五种协作方式：
- 从零创建：用最小目标快速换来第一次可玩结果；
- 局部修正：让 Agent 阅读已有项目，用精确规则解决机制问题；
- 渐进扩充：在稳定基线上增加相互关联的玩法状态；
- 表现升级：生成图片、接入素材、重排 UI，同时保护玩法；
- 视觉续接：附上真实截图，只指出需要修改的局部区域。
以后开发其他小游戏时，也可以复用相同节奏：
先定义一个最小可玩机制
→ 让 Agent 创建并 Preview
→ 用真实操作找出机制问题
→ 用明确数值和边界局部修正
→ 一次扩充一组相关玩法
→ 玩法稳定后再加入图片和 UI
→ 用截图反馈视觉问题
→ 每轮都回归已有功能给开发者的 Prompt 检查表
发送下一条需求前，可以快速确认：
- 我是否说明了“继续当前项目”？
- 我是否只聚焦当前阶段的目标？
- 行为、数值和边界是否足够明确？
- 哪些已有功能必须保留？
- Agent 完成后需要打开哪个 Preview？
- 我准备怎样亲自验证结果？
- 如果是视觉问题，我是否提供了截图、位置、现象和期望？
做到这些，你不需要先成为 Cocos 工程专家，也能与 Pink Agent 一起从一个空白项目逐步完成真实小游戏。
Agent 能力边界
Pink Agent 可以帮助你理解需求、修改工程和迭代游戏，但能否完成一项任务，还取决于当前开放的工具、项目环境和你提供的信息。使用时，记住以下几点：
- 操作范围受工具和权限限制。 能修改当前 Cocos 项目，不代表能操作任意软件、访问其他项目或管理外部服务。涉及新的操作范围时，先让 Agent 说明需要哪些工具、环境和权限，以及目前能完成哪部分。
- 上下文需要明确提供。 不要默认 Agent 已经看到你正在看的画面、试玩过程或另一段对话。继续修改时说明当前项目和要保留的结果；遇到问题时补充截图、复现步骤或报错信息。
- 复杂目标需要分步完成。 本文跑通了一个小游戏的开发流程，并不代表任意规模、任意类型的游戏都能一次生成。新增复杂玩法或接入陌生系统时，先做最小验证，再逐步扩展。
- 代码和素材都可能需要返工。 Agent 可能误解规则、遗漏状态，生成的图片也可能出现细节或风格偏差。用具体反馈继续修正；如果反复失败，先缩小问题范围，并让 Agent 说明已尝试的方法和当前阻碍。
- Preview 的结果有适用范围。 当前 Preview 能运行，不代表在所有设备上都表现一致，也不代表已经完成打包、部署或上线。涉及其他平台和外部服务时，需要在对应环境中另行验证。
遇到暂时无法完成的需求，可以这样继续对话：
请说明当前限制、还缺少什么条件，以及现在可以先完成的最小步骤。