eatfish · 方法论实验笔记

这是用《用 AI 做游戏 · 通用方法论》做的一个小项目。

目的不是做完游戏，是验证方法论在小项目下管不管用。

记录时间：2026-10-13

一、项目概况

• 名称：eatfish（大鱼吃小鱼）
• 规模：小项目
• 对话数：一个程序对话（不拆）
• 技术栈：原生 JS（ES Module）+ Canvas 2D，无框架无构建
• 控制：Pointer Events（鼠标 + 触屏天然兼容）

已完成阶段：

• 第一阶段：跟随指针 + 吃饲料长大
• 第二阶段：AI 鱼 + 大小判定 + 通关 / 游戏结束

二、方法论管用的地方

1. "先复述理解 + 分批建议"

每次新任务，B 都先复述理解、给分批建议，用户确认后才写代码。

效果：两阶段下来，没有出现"理解偏了就动手"的情况。任务定义的准确性明显高于"直接开工"。

2. "顺手改先声明"

B 真的每次都声明了。两阶段共声明了约 9 条顺手改，用户全部或部分接受。

效果：没有出现"AI 悄悄夹带了什么"的情况。

3. 明确数字 > 模糊表述

第一阶段失败：说"一份极简交接文档——半页"，B 写了 350 行。
第二阶段成功：明确"80~100 行上限"，B 写了 96 行。

教训：文档篇幅这类约束，必须给具体数字。"半页""简洁"这类词，AI 会按"覆盖所有可想到的维度"理解。

4. Bug 单独文件

第一阶段：两次修复都详细记录了根因 / 失误说明 / 教训，非常有价值。

第二阶段：没有可修的 bug，但记录了 10 条关键决策——防止"后续改动改坏"。

效果：BUGFIX.md 成了"实际踩过的坑 + 判断过程"的档案，比 HANDOFF 更细，但读它是有针对性的（查历史，不是启动必读）。

5. "初始化顺序"这条坑被抽象出来了

第一阶段两次 bug 都是"初始化顺序"问题。第二次（Bug 2）时 B 主动写了完整的依赖顺序图，进入 HANDOFF。第二阶段又引用了一次。

效果：这是"从具体 bug 抽象成规则"的典型案例——两次同类 bug 后，第三次不会再犯。

三、方法论没覆盖 / 需要补充

1. "死局类 bug"——脚本抓不到，人工要玩到才遇到

第二阶段最大的问题：玩家长到某个 size 后彻底卡住——能吃的吃掉不涨，永远吃不了的大鱼挂在屏幕上。

为什么方法论没覆盖：

• 校验脚本抓的是"加载对不对、数据一致不对"
• "死局"是"游戏能跑，但玩到某个阶段卡住"——脚本完全抓不到
• 只有人工玩到那个阶段才发现

可能要补充的：

• 任务讨论时要问"这个玩法有没有明确的目标 / 结束条件"
• 人工验证清单要包含"通关 / 失败 / 卡住的边界场景"

2. AI 排查 bug 时的"表面现象"陷阱

第二次的死局 bug：B 诊断了两轮才找到根因。

• 第一、二轮：改 AI 生成比例、可吃 / 危险颜色、保底可吃数——都指向 AI 侧
• 第三轮：才发现锅在玩家自己涨不动（第一阶段残留的 SIZE_MAX = 56 硬上限 + 收敛公式把玩家钉死了）

教训：AI 排查时容易被"最显眼的现象"带偏。先检查最基础的东西（玩家自己的状态 / 数值），再看外围。

方法论的补充建议：AI 排查 bug 时要先问一句"最基础的部分是活的吗"，再往下推。

3. "试错后回滚"这类决策

第二阶段的 AI 大小方案：

• 试过一版"绝对三档"（小 / 中 / 大固定值）
• 发现"和玩家进度脱节，画面断层"
• 回滚到"相对玩家 size 取比例"

方法论里的"分批推进"隐含了"错了就改"，但没明说"试错也是正常的路径"。

可能要补充的：说清"试错成本"——小项目里试错改回的成本低，可以大胆试；大项目要慎重。

4. 用户是唯一"能玩到"的人

B 看不到实际效果——它只能改代码。用户是唯一能"打开浏览器玩一下"的角色。

这层在方法论里说过（"人工清单"），但这次的"死局 bug"和"贴脸生成"都是用户玩出来发现的。

强化建议：任务讨论时，让用户明确"这次要怎么玩到才算过"——不只是"能打开"，是"玩到某个状态"。

四、项目本身的技术发现（可复用）

1. 初始化顺序是这类小游戏的最易翻车点

两次 bug 都是这个。核心规则：

• "读取全局尺寸 / 状态"的初始化函数（spawn / layout / 物理），必须排在"设定全局尺寸 / 状态"之后
• 判断依赖时，既要看它用了谁，也要看谁用了它的产物

可复用：任何 Canvas / 游戏循环项目都该记这条。

2. "Math.max(1, ...)" 这类兜底会掩盖错误

Bug 2 的直接来源。兜底让程序不崩，但把"报错"降级成"看起来怪但找不出原因"。

可复用：给尺寸 / 数值相关的兜底配上日志（console.warn），比默默兜底好。

3. 帧率无关物理

• dt 上限 50ms（防切后台跳变）
• 阻尼用指数形式 Math.pow(DRAG, dt) 而非 v *= 0.98
• 60Hz / 120Hz 手感一致

可复用：任何 Canvas 游戏通用。

4. 碰撞用半径系数修正视觉偏差

玩家和 AI 都是"圆身体 + 三角尾巴"，用满圆判定偏大，看起来没贴上也判死。乘 HIT_SCALE = 0.78 修正。

可复用：图形和判定不一致时的常用手法。

5. 结束态用 DOM 而非 Canvas

<div> + <h1> + <button> + CSS 覆盖在 Canvas 上。中文排版 / 居中 / 按钮 hover 靠浏览器原生能力，省事。

可复用：游戏 UI（菜单 / 结束 / 设置）优先用 DOM，Canvas 只管画世界。

6. Pointer Events 天然兼容触屏

pointermove / pointerdown 通吃鼠标 / 触屏 / 触控笔，代码量和 Mouse Events 一样。

可复用：所有"要将来支持触屏"的项目，一开始就用 Pointer Events。

7. touch-action: pinch-zoom 兼顾单指操作和双指缩放

• touch-action: auto 会让单指拖动被识别成页面滚动，打断游戏
• touch-action: none 会禁用双指缩放
• touch-action: pinch-zoom 只放行双指缩放，单指仍是游戏输入

可复用：移动端 Canvas 游戏的标准做法。

五、方法论改进建议（汇总）

建议加到方法论文档：

1. 文档篇幅给具体数字——"半页"这类模糊表述会失控，要给"XX 行上限"
2. 人工验证要包含"卡住 / 通关 / 失败"——不只验证"能打开"，要验证"玩到边界"
3. AI 排查 bug 先检查最基础的——不要被最显眼的现象带偏
4. 试错是正常路径——小项目试错成本低，可以大胆试；大项目要慎重
5. 明确"这次要怎么玩到才算过"——任务讨论时把验证方式说清

建议保留并强调：

• "先复述理解 + 分批建议" —— 有效
• "顺手改先声明" —— 有效
• "Bug 单独文件" —— 有效
• "初始化顺序"这类"两次同类 bug 后抽象成规则" —— 有效

六、下一步

eatfish 可以继续做（加菜单 / 音效 / 存档 / 更多 AI 行为），也可以到此为止。

如果继续：观察"试错回滚"和"死局类 bug"会不会再出现，验证本轮补充的建议是否有效。

如果停止：可以整理一份"eatfish 完整开发日志"，作为方法论实践的公开案例。