第一版游戏的交付物应当很具体。玩家能进入游戏、理解目标、完成一次核心循环、触发成功或失败，并重新开始。仓库还应留下 PLAN.md、素材提示、运行命令和浏览器验收记录。只看到精美首页或一段能动的角色，仍不能证明玩法成立。
把创意压成一轮能玩完的规则
先把游戏做小。开始前确定玩家目标、核心动作、输入方式、胜负条件、难度变化与视觉方向。第一版只选一个核心循环，例如移动并收集、躲避直到终点或在限定步骤内解谜。排行榜、联网匹配、账户和复杂剧情可以先列入后续，避免基础操作还未稳定就引入后端状态。
让 Codex 先写 PLAN.md，按依赖顺序列出场景骨架、输入、规则、状态界面、素材和验收。每个里程碑都要有玩家可见结果与浏览器检查。再用 AGENTS.md 保存长期约束，包括完成切片后立即构建、依据计划推进、把决定记入日志、通过真实浏览器检查画面，以及保存每批素材的生成提示。
规则先行。把规则写到能用纸笔演算。玩家每次操作改变哪些状态，碰撞在哪一帧判断，得分何时增加，胜负是否还能同时触发，都要有唯一答案。先处理这些边界，后面替换渲染库或视觉素材时，核心玩法仍可用纯逻辑测试保护。
准备目标浏览器、桌面与移动端尺寸、键盘或触控要求、素材许可和声音策略。框架与渲染库应服从玩法规模。简单棋盘或点击游戏可以用常规 DOM，持续动画和精灵较多时再考虑专用渲染层。
先用占位素材跑通循环
先试玩。Codex 搭建最小场景和状态机。开始、进行、暂停、胜利、失败和重开要有明确转换。输入处理应集中管理，防止多个组件重复监听。完成后立即在浏览器里操作，从开始画面进入游戏，触发一次成功和一次失败，再重开。可见结果是一条完整但视觉简朴的玩法链。
这一步优先检查规则。角色是否越界，碰撞是否稳定，分数是否在重开后归零，切换标签页后计时是否异常，输入焦点是否被按钮抢走。修复时一次只改一个问题，并把复现动作与结果写进日志。单元测试适合保护纯规则，真实操作负责发现节奏、焦点和画面问题。
使用独立工作树能隔离游戏迭代产生的大量素材与代码变化。长时间运行时，计划和日志提供恢复坐标。每完成一个里程碑都收束文件与决定，避免聊天上下文成为唯一记录。
浏览器检查要固定初始条件。随机地图可以保存种子，计时玩法可以提供暂停或测试模式，输入动作则按同一顺序重放。这样修复碰撞以后能再次触发原场景，也能判断新问题来自规则变化还是一次随机布局。
再生成并接入一致的视觉素材
素材后换。玩法稳定后再确定素材清单。背景、角色、障碍、图标和状态界面分别写清尺寸、透明背景、视角、光线与色彩。使用图像生成功能时保存原始提示和本批次约束，后续补图才能维持风格。生成结果要逐张检查边缘、文字、方向和可读性，不能直接整批接入。
Codex 支持把图片作为输入理解界面，也能使用图像生成能力制作或修改素材。生成文件进入项目以前，先按用途裁切和压缩，保持命名稳定。素材替换完成后再次在真实浏览器运行，观察加载时间、碰撞区域与实际图形是否一致，以及低对比场景是否看得清。
视觉效果不能遮住游戏状态。玩家受伤、得分、暂停和结束应有清楚反馈。动画较多时提供减少动态效果的处理，声音则考虑浏览器自动播放限制和静音入口。触控版本还要检查手指遮挡、按钮尺寸与横竖屏变化。
用一份操作脚本完成验收
写出从刷新页面开始的操作脚本，包含开始、移动或点击、达成目标、失败、暂停、重开和改变窗口尺寸。桌面端启用 Computer Use 后可以调用 @Browser 执行，官方游戏用例也可安装并调用 $playwright interactive Skill。两者都不可用时，由人按同一脚本完成验收。失败时记录当时状态与截图，最后重开一次。构建通过、控制台没有阻断错误、脚本可重复完成，才进入交付。
后端状态、多人同步与生成式玩法会增加认证、成本、内容安全和网络故障面。第一版若没有这些需求，就保持本地确定性。确实需要时，另开里程碑并为离线、重连、重复请求和资源上限设计验证。
风险与限制
自动浏览器需要桌面端能力、网站许可或已安装的浏览器 Skill，也只能覆盖预设路径，无法替代不同玩家的手感反馈。速度、难度和提示清晰度仍需要人工试玩。图像生成结果也存在不一致与版权审查需求，发布前应确认素材来源、授权和平台规则。
交付清单
PLAN.md写明核心循环、控制、胜负与里程碑- 占位素材阶段已经跑通开始、完成、失败和重开
- 素材提示与生成约束已经保存
- 桌面、窄屏、键盘或触控按目标完成检查
- 构建命令、浏览器操作脚本和结果可以复查
- 后续功能、已知手感问题与素材风险已经列明