---
title: 11 天 240 次提交：一个人的「AI 团队」
date: 2026-11-05
summary: 从空目录到 TapTap 过审，11 天、240 次提交、2.4 万行 Lua。一个人是怎么带着一群 agent 冲刺的，以及哪里翻了车。
tags: [AI 协作, 复盘, 游戏开发]
draft: false
---

《小光头勇闯修真界》从空目录到 TapTap 过审，用了 **11 天**。

数据先放这：**240 次提交**（feat 46、qa 21、release 23、merge 24），
55 个 Lua 文件、约 2.4 万行脚本，412 个资源文件，115 张验收截图。

## 分工：人定方向，AI 交付切片

「产品方」只做不可逆的决定：游戏是什么、手感往哪调、哪些能砍。
AI 执行组按阶段交付**可测的切片**——不是一个功能列表，而是一个能跑、能验收的版本。

阶段推进用「唯一产物」控制：每个阶段只允许一个合法产物。
AI 不能跳步，也不能一次把整套策划写完。

## 哪里翻车了：AI 会往巨石里堆

测试主文件 `TestLab` 一度长到 8629 行，我们把它拆到 7499 行；
结果几轮迭代之后，它又长回 **12864 行**。

AI 天然倾向于「往现有文件里加」，很少主动说「这个该拆了」。
所以审计不能只做一次——我是定期跑代码库审计、盯着行数曲线，超阈值就再拆。

## 美术流水线：生成成功 ≠ 能用

美术资源生成写了 29 个脚本、3559 行、92 份 prompt。

最反直觉的一条：**生成成功不代表能用**。分镜结构合格、但脸和手崩掉的图，
依然要走 KEEP / REFINE / KILL 三档判断，用 alpha 边界、安全边距、sha256
这些量化指标筛，而不是靠感觉。

还有一次更隐蔽的坑：多行 prompt 被 PowerShell 截断成一行，服务端照样返回成功。
从此规则是——**服务端成功必须校验回显**，不能只看返回码。

## 11 天里真正稀缺的是什么

不是生成速度，是**判断**：

- 哪个阶段该停
- 哪张图该 KILL
- 哪次改动值得跑全量回归
- 哪个问题可以留到上架前再修

## 现在的状态

v1.0.23，测试包 55MB，已通过 TapTap 审核；预约于 11 月 7 日（周六）开启。
待办很明确：真机验收、替换正式美术、广告开通（卡小游戏备案，约 20 个工作日）、
以及合规整改——这一条差点被当成小事，其实是上架前的硬门槛。