一个人加上 AI，能不能组成游戏团队

在第 1 篇里，我们讨论了如何把一句想法变成可以验证的核心循环。接下来的问题是：把它做成游戏，谁来完成这些工作？

“一个人加上 AI，就是一支游戏团队”很容易被写成一句宣传语。但如果把它放进真实开发过程，这个判断需要更严格的前提。

以本文回顾阶段《Kibble Street TD》的开发规模来看，一个人和 AI 的确可以覆盖从设计、程序、美术、音频到测试的主要工作，并把项目从概念推进到首个版本准备阶段。但这不等于一个人突然拥有了五个专业岗位的经验，也不等于 AI 可以独立承担产品责任。

更准确的结论是：一个人加上 AI，可以形成一套小型生产系统；它是否称得上团队，取决于各项职责能否完成交接、验证和决策闭环。

团队规模变小，工作种类不会减少

一款游戏需要处理的工作，并不会因为开发者只有一个人而消失。

设计负责定义核心规则、内容边界和优先级；程序负责把规则变成稳定运行的系统；美术负责角色识别、界面层级和视觉反馈；音频负责场景氛围、操作响应和战斗节奏；测试负责发现错误，并确认结果是否符合原来的目标。

这些工作在《Kibble Street TD》中都有实际对应：战斗与经济规则需要持续整理，游戏运行逻辑和页面系统需要实现，角色、界面、背景与特效需要生产和接入，背景音乐与操作音效需要映射，配置、战斗、构建和设备表现还需要反复检查。

小团队真正困难的地方，不是完全缺少某一种能力，而是同一个人需要频繁切换视角。刚刚还在判断玩法节奏，下一步可能就要处理资源尺寸、程序错误或测试结果。AI 的价值首先体现在降低这些切换的启动成本，而不是让工作本身凭空消失。

真正的协作发生在交接闭环里

如果只是把一个宽泛需求交给 AI，再直接采用生成结果，这不是团队协作，只是一次没有验收的外包。

《Kibble Street TD》中更有效的工作方式，是让每一轮都有明确的输入、产物和责任人：

人先定义要解决的问题，并写清不能改变的边界与验收条件。AI 随后检查项目当前状态，把要求转换成文档、代码、配置、素材候选或测试入口。第一版完成后，自动检查负责暴露结构错误，人再通过阅读、试玩和视觉审查判断结果是否真正可用。

如果结果不符合目标，反馈不能只停留在“感觉不对”。它需要继续转化成下一轮约束，例如保持现有尺寸、只调整亮度，不改变战斗数值，只修正目标选择，或者保留原有流程、只重做表现层。

这套循环的重点不是 AI 一次做对，而是错误能够被发现、解释，并进入下一轮修正。

同一项工作，人与 AI 负责不同部分

在设计工作中，AI 可以整理规则、查找遗漏和识别冲突，但玩法方向、优先级和取舍仍由人决定。程序工作中，AI 可以阅读现有调用链、完成实现并运行回归检查，人则需要明确系统边界和什么结果才算通过。

美术工作尤其能说明这种差异。AI 可以制作候选、执行裁剪与尺寸处理，也可以检查透明边界和资源规格；但角色是否可信、界面是否协调、视觉是否符合产品定位，仍然需要人工确认。音频也类似：映射、接入和缺失检查可以被系统化，情绪、节奏与听感却不能只依靠文件存在来判断。

测试工作则形成互补。AI 擅长重复执行结构检查、规则回归和批量模拟，人更适合判断操作是否顺畅、信息是否清楚、战斗是否有节奏，以及真机和平台上的实际表现。

因此，合理的分工不是“AI 做执行，人只提需求”，而是：AI 扩大可覆盖的工作范围，人负责目标、判断和最终责任。

一次真实返工：技术合格，不等于视觉合格

项目中的广告加载按钮曾经出现过一个很典型的问题。第一版已经满足尺寸、九宫格拉伸和旋转加载图标等技术要求，也能正常进入运行时，但人工审查后认为整体过暗。

下一轮没有推翻整个组件，而是增加了更严格的限制：保持按钮与加载图标的结构、尺寸和拉伸方式不变，只提高可见度。调整后，按钮可见像素的中位亮度从 83 提高到 189，同时继续通过原有尺寸与边界检查。

自动检查能够证明“它确实变亮了”，却不能证明“它已经适合整个界面”。在本文所依据的记录中，较亮版本仍然停留在等待最终视觉确认的候选阶段，运行时继续使用已确认版本。

这个返工过程把职责边界表现得很清楚：人发现体验问题并决定修改范围，AI 把主观反馈转换成可执行约束并产出新版本，检查工具验证修改没有破坏规格，最终采用与否仍由人判断。

验证不是开发结束前的一次检查

当 AI 能够快速产出代码和资源时，验证必须进入每一轮工作，而不能留到版本结束时统一处理。

第一层是结构检查，确认文件、配置、资源标识和引用关系是否完整；第二层是运行检查，通过规则回归、批量模拟和构建确认系统能够按预期执行；第三层是人工验收，检查实际操作、视觉层级、节奏、真机表现和平台结果。

前两层通过，只能说明结果在既定规则下保持一致，不能自动证明游戏有趣、画面合适或产品已经可以发布。反过来，人工认为“看起来没问题”，也不能代替可重复的配置与程序验证。

一人项目能够持续推进，依靠的不是减少测试，而是把重复检查尽可能交给自动化，把有限的人工注意力留给机器无法替代的判断。

结论：成立的是生产闭环，不是人数等式

对于《Kibble Street TD》这样的独立项目，一个人加上 AI 已经能够形成覆盖多项职责的生产闭环：需求可以转化为实现，实现可以进入检查，检查结果可以回到下一轮约束，项目也能持续积累可运行内容。

但它仍然不等同于一支成熟工作室。专业深度、审美判断、真实用户研究、设备与平台权限、商业决策和最终责任，都不会因为生成速度提高而自动解决。一个人仍然是方向和验收的主要瓶颈，也必须承担错误决策带来的成本。

这个环节由谁负责

人在这套协作中是产品负责人：定义目标与优先级，确认不可改变的边界，审查体验，并对最终版本负责。

AI 是覆盖多个岗位的生产与检查助手：读取现状、转换要求、完成第一版、执行重复验证，并把问题整理成下一轮可以处理的输入。

自动化工具提供可重复的客观结果，但不替任何一方做产品决定。

如果准备采用这种方式

开始时需要先建立五条基本规则：

1. 每个任务只解决一个明确问题。
2. 修改前写清不可改变的边界和验收条件。
3. 要求 AI 先读取当前项目事实，再给出实现。
4. 每次非简单修改都留下最小可重复检查。
5. 视觉、手感、真机和发布结果必须由人最终确认。

这五条规则比不断增加提示词更重要。它们决定了 AI 的产出能否进入稳定开发流程，也决定了一个人是否真的拥有了“团队能力”，而不只是更快地产生文件。