老板不该当 AI 的人肉测试员

做 Game Copilot 的前期，多次出现同一种低效循环。

代码看起来没问题。

APK 发给我。我装到手机上，闪退或者无反应才暴露出来。

我能说回去的，主要是口头反馈。这样的来回，前期出现过多次。

 

一、10月9日，执行端第一次自己做真运行检查

站在使用者的角度，我能说的往往只是出现了闪退或无反应。

前一晚，我让执行端自己下载了模拟器。2026年10月9日，Windows 笔记本上补齐了 Android Emulator 和 WHPX 运行环境。

这一天，执行端第一次自己做真运行检查。安装、启动、logcat、MediaProjection、FakeGame、HUD，都在这次检查里。

以前这些步骤不是它自己完成的。代码看起来没问题，APK 到了我这边，闪退和无反应才出来，我再用口头反馈把现象说回去。

这条真机链路一跑，马上抓出了三个缺陷。三个缺陷此前都靠我的口头反馈，很难定位。

 

二、第一个问题：只投递了一帧

第一个缺陷出在 `CaptureService`。

它只投递一帧，导致 `frameId` 不再推进。

识别器事实上不会持续工作。

帧只出去了一帧，`frameId` 就停住了。没有后续的帧，识别器也就不会持续工作。

 

三、第二个问题：安全确认写了，但实际上没有确认

`SceneRecognizer` 有一层二级确认，但它拿当前帧和当前帧自己比较，距离恒为 0。

代码里确实存在“二级确认”这套结构。

可一旦比较对象就是自己，距离恒为 0，确认就失去了意义，安全确认实际上形同虚设。

这个缺陷，此前靠我的口头反馈很难定位。这次程序实际跑起来，才看到它拿当前帧和自己比。

 

四、第三个问题：崩溃前先打出“显示 fixture”

第三个缺陷来自 FakeGame。

FakeGame 自身每次启动都会崩。

但旧日志在崩溃前，先打印了一句“显示 fixture”。

这句打印造成了假象，让过程看起来像端到端已经成功。FakeGame 自身的运行结果仍然是：每次启动都会崩。

 

五、模拟器的价值，不只是省下一台手机

这次经历之后，我们把问题提炼成了一句话：老板不该做人肉测试员。

这不是我一开始就设计好的方法论。我的原始判断更直接：如果前一晚没有让它自己下载模拟器，这些问题可能都会落到我的手机上，而我也不一定能反馈清楚。

复盘时，我们才把这次经历整理成“自验证闭环”：AI 开发需要自己的运行环境，也需要可观测的运行证据。

讨论后的关键认识，不是“模拟器很好用”。没有自己的运行环境，也没有可观测证据，大量本该由执行端自己发现的问题就会转嫁给 Owner，最后形成一种荒唐的组织结构：AI 写代码，老板做人肉测试员。

没有这两样东西，很多运行问题就会被转嫁给 Owner。至于装上以后会不会崩、服务有没有持续工作，它只能等老板试。

于是，老板的手机成了它的运行环境，老板的眼睛成了它的监控工具，老板的口头描述成了它的日志系统。很多本该由执行端先发现的问题，就这样被推到了最后一个人身上。

六、老板不是不测试，而是只守最后一道门

这并不意味着真实设备不重要。模拟器不能替代最终的 Real Environment Gate。

但真实设备应该是最后一道门，而不是日常开发的第一块试验田。

这次复盘后整理出的顺序是：

开发 → 自己运行 → 自己抓日志 → 自己定位 → 自己修复 → 自己回归 → Gate 通过 → Owner 做最终 Real Environment Gate。

顺序是讨论之后才整理出来的。

自己运行，是要执行端自己有运行环境。这次补上的，是 Windows 笔记本上的 Android Emulator 和 WHPX。

自己抓日志、自己定位，是要有可观测的证据。这次分开的三处是：只投递一帧而且 `frameId` 不推进，二级确认距离恒为 0，以及 FakeGame 崩溃前那句“显示 fixture”。

自己修复、自己回归放在 Gate 前面。Gate 通过，才交给 Owner 做最终的 Real Environment Gate。

执行端先把自己能够发现的问题消化掉，再把经过验证的结果交给 Owner。Owner 要判断的是：它在真实环境里是否可用。闪退和无反应如果还要我来发现，我也不一定能反馈清楚。

我把这条闭环再说成一句人话：代码写完，先在执行端自己的环境里跑起来，自己看日志，自己定位，自己修复，自己回归。Gate 通过之后，我再做最终的 Real Environment Gate。

七、这次可以直接带走的四条检查法

这四条是这次经历整理出来的用法。运行环境，就是 2026 年 10 月 9 日 Windows 笔记本上的 Android Emulator 和 WHPX。执行端自己做完的，是安装、启动、logcat、MediaProjection、FakeGame 和 HUD。Owner 最后仍要做的，是 Real Environment Gate。

第一，交任务前先问：执行端有没有可运行环境？没有，就不要把“代码看起来没问题”当成交付。

第二，看日志不要只搜成功关键词。成功日志之后有没有崩溃，状态有没有继续推进，要一起看。

第三，把“中间信号”和“最终结果”分开。“显示 fixture”发生过，不等于 FakeGame 端到端成功。

第四，把真实设备留给最终 Gate。日常能由执行端完成的安装、启动、日志检查和回归，不要先压到 Owner 身上。

我现在越来越觉得，AI 开发真正要减少的，不只是写代码的时间。

它还应该减少老板在低层故障之间来回传话的时间。

如果每一个 APK 都要等老板亲手点一下，AI 才知道自己写的东西能不能跑，那它只是把敲键盘自动化了，并没有形成真正的开发闭环。

老板可以做最后的真实验收，但不该成为 AI 唯一的运行环境。

说明：以上是基于2026年10月9日 Game Copilot 阶段性工程实践整理的公众号草稿。文中三个缺陷均按素材所载的运行检查结果表述，不代表其后续修复与最终真实设备验收已经完成；未经用户逐句审定，不代表已公开发表。