AI辅助开发放置游戏全流程实践：从代码生成到批量测试

PostScript: Idle Frontier —— 用 AI 辅助开发放置游戏的完整实践思路

这次我们来看一个比较特别的游戏开发项目：PostScript: Idle Frontier。从标题可以看出，这是一个围绕放置类游戏（Idle Game）展开的项目，同时重点强调了“developing games with AI”—— 也就是把 AI 工具链真正塞进游戏开发流程，而不是停留在“用 AI 写个 Hello World”的层面。

项目本身的定位更像是一份“边做边写”的游戏开发工程记录：玩家在游戏里经营边界、积累资源、解锁升级；开发者在幕后用 AI 完成数值设计、代码生成、美术素材、批量测试甚至存档系统设计。如果你是游戏开发爱好者，或者正在纠结“AI 到底能不能帮我做点真东西”，这个项目值得拆开看一看。

这篇文章会按照“项目定位 -> 适用边界 -> 环境准备 -> 项目结构 -> AI 协作流程 -> 功能测试 -> 性能观察 -> 排错 -> 最佳实践”的顺序展开。没有素材能覆盖到的具体参数，我会明确标注为待测试项，不会替作者编造数据。读者可以把它当成一套“最小可落地的 AI 游戏开发工作流参考”。

1. 核心能力速览

需要先说明一点：这个项目标题里的PostScript，不要只理解为 Adobe 的页面描述语言。在游戏开发语境里，它更接近“写在项目末尾的后记/复盘”，同时也可以被当作一种“带完整编程能力的脚本语言”来玩。实际落地方案有两种：一种是把它当作项目复盘日志的命名延续，另一种是在游戏脚本、存档系统、事件触发中借鉴 PostScript 的“指令栈 + 过程定义”思路。下面会给出两种思路的实现方向。

2. 适用场景与使用边界

2.1 这个项目适合谁

如果你是下面几类人，这个项目会比较对胃口：

• 独立游戏开发者：想用 AI 减少重复劳动，但不知道从哪里切入手。项目给出了“需求拆解 -> AI 生成 -> 人工审查 -> 迭代测试”的完整闭环，可以直接照着搭。
• AI 应用开发者：想验证大模型在游戏策划、数值平衡、代码生成、美术素材生产等环节的真实效果，而不是只做聊天机器人。
• 放置游戏爱好者：关心 Idle Game 的核心机制设计，比如离线收益、自动战斗、里程碑解锁、数值曲线等。
• 编程学习者：希望通过一个“真项目”把前后端、存档、日志、测试这些工程概念串起来，同时体验 AI 辅助编程。

2.2 能解决什么问题

• 降低游戏原型开发门槛。过去从零搭一个放置游戏需要 3-5 天，用 AI 辅助可以把最小可玩版本压缩到几个小时。
• 把 AI 从“玩具”变成“工程工具”。项目关注的是 AI 生成后的审查、集成、测试，而不是只展示 AI 能写多少行代码。
• 提供一条可复制的协作链路：策划文档、代码模块、美术素材、测试用例，每个环节都能看到 AI 的介入方式和人工把关点。

2.3 不适合什么场景

• 追求 3A 级画面和复杂物理引擎的重度游戏开发。
• 需要严格版权确权的商业美术资源生产。AI 生成素材的版权归属、训练集合规性存在不确定性，商用前要重点确认。
• 对完全自动化有幻想的团队。AI 生成的代码和数值仍然需要人工审查，后期调试成本不一定比手写低。

2.4 版权与合规边界

项目涉及 AI 生成代码、素材、文案，这些环节必须注意：

• 美术素材训练集的授权范围。部分模型训练数据包含受版权保护的图片，生成的图片在商业项目中使用时需要确认授权边界。
• 使用公开人物肖像、特定风格美术做素材时，要获得合法授权。
• AI 生成的代码，在发布或商用前应做一轮人工审查，尤其是涉及第三方库许可协议的部分。
• 放置游戏的存档系统和网络交互，如果涉及用户数据，要遵守隐私保护要求，本地测试时不要加载真实用户数据。

3. 环境准备与前置条件

从项目标题和通用放置游戏开发经验来看，环境准备可以分为两层：游戏运行环境和AI 辅助开发环境。

3.1 游戏运行环境

如果按 Web 版实现，要求很低：

如果按 Python 终端版实现：

# 建议使用虚拟环境 python -m venv idle_env source idle_env/bin/activate # Windows 下执行 idle_env\Scripts\activate # 安装基础依赖 pip install pygame requests

其中pygame用于做简单的图形界面或音频反馈，requests用于调用 AI API 做素材生成或测试脚本。

3.2 AI 辅助开发环境

项目标题强调 “developing games with AI”，所以 AI 环境是重头。常见方案有两种：

方案一：调用云端大模型 API

• 需要注册一个模型服务平台的 API Key。
• 代码补全、对话式需求拆解、文案生成都走 API。
• 优点是不需要高端显卡；缺点是按量计费，长对话要控制 token 消耗。

方案二：本地部署开源模型

• 可选 Codestral、DeepSeek-Coder、Qwen2.5-Coder 等模型作代码生成，具体以本机环境为准。
• 显存要求因模型大小而异，7B 级模型通常建议 8GB 以上显存，量化版本可适当降低，但效果需实测。
• 调用方式可以是 Ollama、LM Studio 或 vLLM，读者需要根据自己机器选择。

启动本地模型服务的通用命令模板：

ollama run qwen2.5-coder:7b

# 如果使用 vLLM 部署，命令类似： python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-Coder-7B-Instruct \ --host 127.0.0.1 \ --port 8000

这里强调一点：本地模型的具体显存占用和生成速度，需要在自己的机器上跑一遍才知道，不建议照搬别人的数字。模型量化、上下文长度、并发请求都会影响实际占用。

3.3 端口和资源检查

• 游戏 Web 服务默认可以选7860端口，AI API 服务常用8000，如果启动报端口占用，换一个即可。
• 如果同时跑本地模型和游戏服务，确认内存不低于 16GB，避免 OOM。

# 检查端口占用（macOS / Linux） lsof -i :7860 # Windows netstat -ano | findstr :7860

4. 项目结构与 AI 协作工作流

4.1 建议的目录结构

一个可维护的 AI 游戏开发项目，建议按下面结构组织：

idle_frontier/ ├── docs/ │ ├── design.md # 策划文档 │ ├── ai_prompts/ # 存放给 AI 的提示词 │ └── postscript/ # 项目复盘与后记 ├── src/ │ ├── core/ │ │ ├── game.py # 游戏主逻辑 │ │ ├── resources.py # 资源产出计算 │ │ └── upgrade.py # 升级系统 │ ├── systems/ │ │ ├── save.py # 存档 │ │ ├── event.py # 随机事件 │ │ └── batch_test.py # 批量测试脚本 │ └── web/ │ ├── index.html # Web 前端 │ └── style.css ├── assets/ │ ├── images/ # AI 生成的美术素材 │ └── audio/ # 音效 ├── tests/ │ └── test_game.py # 单元测试 ├── scripts/ │ ├── ai_generate_code.py # AI 生成代码脚本 │ └── ai_generate_assets.py └── requirements.txt

4.2 AI 协作的四个阶段

阶段一：需求拆解

不要把“帮我写个放置游戏”这样的大需求直接丢给 AI。先把游戏拆成小模块，每个模块单独描述。例如：

需要实现一个放置游戏资源系统。规则：每秒自动产生金币，金币数量 = 基础产量 x 等级加成 x 速度倍率。升级按钮每点击一次，等级 +1，基础产量提升至 1.15 倍。输出一个 Python 类，包含 update(seconds)、click_upgrade() 两个方法，并提供简单测试。

先给 AI 做上下文注入，要求它先列出实现思路，再输出代码。这样比一次性生成长代码更稳定。

阶段二：代码生成

用 AI 生成的代码，一定要放进项目目录里做版本管理。不要直接复制到生产代码。建议把 AI 输出先放到ai_output/目录，人工审查通过后再合并。这样既能追溯生成过程，也能避免 AI 幻觉代码进入主项目。

阶段三：批量素材生成

放置游戏需要的素材通常包括：按钮图标、背景图、资源图标。可以写一个批量生成脚本，把提示词列表循环提交给绘图模型：

import requests prompts = [ "a small gold coin icon, game asset, flat style, transparent background", "a wooden button texture, game UI, cartoon style", "a wide desert background for idle game, 16:9, low detail" ] api_key = "your-api-key" url = "https://api.example.com/v1/images/generations" for i, prompt in enumerate(prompts): resp = requests.post( url, headers={"Authorization": f"Bearer {api_key}"}, json={ "prompt": prompt, "size": "512x512", "n": 1 }, timeout=60 ) data = resp.json() # 把返回图片保存到 assets/images 目录 # 具体解析方式取决于服务商返回格式 print(f"done: {i}")

注意：生成素材的提示词要明确风格、尺寸、透明背景，并在生成后人工筛选，避免版权和风格不一致问题。

阶段四：测试与调试

把 Bug 描述、报错堆栈、相关代码片段一起发给 AI，让 AI 给定位建议。但不要直接采用 AI 给出的修复代码，要看懂修改逻辑再合并。例如：

以下代码在离线收益计算时出现负数，请分析原因并给出修复建议。 [贴代码片段] [贴报错信息]

4.3 PostScript 风格的脚本设计

既然标题里有 PostScript，我们可以借鉴它的设计思想来实现游戏内的事件脚本。PostScript 语言的特点是：逆波兰表达式、过程定义、栈操作。我们可以设计一个简单的基于栈的游戏事件脚本：

/on_milestone { /level exch def level 10 eq { /unlock_building (sawmill) def /notification (New building unlocked: Sawmill) def } if } def

上面这段是 PostScript 语法，放到游戏项目里可以当作“事件触发脚本”的参考。如果要在 Python 里实现类似机制，可以用 AST 解析或直接实现一个小的栈式解释器。核心价值在于：把游戏事件逻辑从主程序里解耦，让策划人员可以不改代码就调整事件。这种“脚本化”思路，和 AI 辅助生成脚本内容天然匹配。让 AI 生成 PostScript 格式的事件定义，再人工审查后加载到游戏里。

5. 功能测试与游戏验证

放置游戏的核心验证点，不只是“游戏能不能打开”，而是三个维度：资源产出是否线性正确、升级数值是否符合预期、存档/离线收益是否准确。

5.1 基础资源产出测试

测试目的：验证每秒金币产出是否正确。

操作步骤：

1. 初始金币设为 0。
2. 基础产量设为 10/秒。
3. 运行游戏模拟 10 秒。
4. 检查金币是否为 100（允许浮点误差）。

def test_resource_generation(): game = Game() game.initialize(base_production=10) game.update(seconds=10) assert abs(game.gold - 100) < 0.01

5.2 升级数值测试

测试目的：验证升级后产出倍率是否正确。

def test_upgrade_multiplier(): game = Game() game.initialize(base_production=10) game.click_upgrade() # 1.15 倍提升后的期望值 expected = 10 * 1.15 assert abs(game.current_production - expected) < 0.001

这里注意：数值设计中的浮点误差会随升级次数累积，建议用Decimal或者固定小数位处理，避免后期数值漂移。

5.3 存档与离线收益测试

离线收益是放置游戏的标志性功能。常见实现逻辑是：记录玩家退出时间戳，下次进入时计算时间差，再按产出速率结算奖励。

import time def test_offline_earnings(): game = Game() game.initialize(base_production=10) game.save() # 模拟离线 1 小时 offline_seconds = 3600 merged = game.load_with_offline(offline_seconds) # 期望获得约等于 3600 * 10 的金币 # 具体是否要打折，取决于策划设计 assert merged.gold >= 36000 * 0.5

测试判断标准：

• 资源产出在长时间运行后没有指数爆炸。
• 升级到高阶后，数值仍然在可控范围内。
• 存档读取后，状态完全一致。
• 离线收益结算不出现负数或无穷大。

5.4 AI 生成代码的质量测试

AI 生成的每个模块，都应该有配套的单元测试。不要因为“AI 写的”就跳过测试。可以专门写一个脚本，把 AI 生成的所有函数批量导入，并跑一遍基础测试：

import importlib import inspect def test_all_ai_modules(): module = importlib.import_module("src.ai_generated.mod1") funcs = inspect.getmembers(module, inspect.isfunction) for name, func in funcs: if name.startswith("ai_"): result = func() assert result is not None, f"{name} returned None"

6. AI 代码生成与批量任务

6.1 AI 生成代码的工程化落地

AI 辅助开发游戏最容易踩的坑，是把 AI 生成的代码当成“黑盒”。建议的做法是：

1. 每个 AI 生成模块，必须附带一条“功能说明注释”，写清楚输入、输出、依赖。
2. 代码生成后，立即用pylint或ruff做静态检查。
3. 注册到测试套件，跑一次单元测试，通过后再进入主分支。

用本地模型辅助生成的代码，需要额外注意上下文长度。一次生成的代码量不宜超过 200 行，太长容易出现中途丢失逻辑的问题。可以把大模块拆成多个小函数，分多次生成再人工拼接。

6.2 批量任务的典型场景

游戏开发中的批量任务主要有三类：

批量数值验证

用脚本遍历所有升级等级的消耗、产出，检查数值曲线是否平滑：

for level in range(1, 100): cost = upgrade_cost(level) production = production_at(level) # 检查是否存在无意义升级点 if production / cost < 0.001: print(f"warning: level {level} efficiency too low")

批量素材命名与归档

AI 生成的素材文件名可能是随机字符串，需要批量重命名，并按用途归档。这时用一个脚本扫描assets/raw/目录，将图片按批次移动。

批量对话测试

如果游戏里有 AI NPC 或对话系统，需要对同一提示词做多轮测试，观察生成内容是否稳定。注意，涉及公开人物、版权角色时，应避免生成或使用相关内容。

6.3 通用 API 调用示例

如果项目打开了一个内部 AI 辅助接口，比如“根据输入需求生成游戏事件配置”，可以用下面的模板做调用测试。需要说明的是，具体路径和返回格式以项目实际接口为准，这里只是一个通用占位模板。

import requests url = "http://127.0.0.1:8000/api/generate_event" payload = { "feature": "unlock_building", "level": 10, "player_id": "test_user" } resp = requests.post(url, json=payload, timeout=120) print(resp.status_code) print(resp.json())

curl -X POST "http://127.0.0.1:8000/api/generate_event" \ -H "Content-Type: application/json" \ -d '{"feature": "unlock_building", "level": 10, "player_id": "test_user"}'

7. 资源占用与性能观察

7.1 游戏本体占用

放置游戏的本体运行成本很低。如果是 Web 版，浏览器内存占用通常在 100MB 以内；如果是 Python + Pygame 版，逻辑更新频率建议控制在 10-20 帧，因为放置游戏不需要 60 帧实时渲染，降低刷新频率能显著减少 CPU 占用。

7.2 本地 AI 模型占用

这部分需要重点区分：游戏运行不占显存，但本地 AI 辅助开发会占显存。以常见的 7B 模型量化版本为例，具体显存占用和推理速度会因量化倍数、上下文长度、请求并发数发生变化，不能用别处的数据代替实测。

观察方式：

• Windows 上用nvidia-smi查看显存占用。
• macOS 上用top -o mem看统一内存占用。
• 同时跑游戏和模型服务时，建议先启动模型，等显存稳定后再开游戏。

一个可行的经验是：本地模型服务占用显存高、游戏本体几乎不占显存，因此独立游戏开发场景下，不建议把本地模型和重型编辑工具同时开太久，避免内存溢出。

nvidia-smi --query-gpu=name,memory.used,memory.total,utilization.gpu \ --format=csv -l 2

7.3 性能优化方向

如果放置游戏运行一段时间后发现卡顿，优先排查这些点：

• 事件循环中是否重复执行了高耗时的资源计算。
• 存档是否在每帧都写入磁盘。正确做法是“定期自动保存 + 退出时保存”。
• UI 刷新是否全量更新，而不是只更新数值文本节点。
• 批量任务是否串行执行过长。可以给批量测试脚本加上进度条和超时控制。

from alive_progress import alive_bar items = list(range(100)) with alive_bar(len(items)) as bar: for item in items: run_test(item) bar()

8. 常见问题与排查方法

8.1 一个典型的排错路径

如果 AI 辅助生成的一段代码运行报错：

1. 把完整报错堆栈复制下来。
2. 定位到具体文件行号。
3. 把报错信息、相关代码、AI 的提示词一起发给 AI，要求先定位原因再给修复方案。
4. 人工审查修复代码，确认没有引入新的问题。
5. 补上对应的单元测试，防止回归。

这个流程适合所有 AI 辅助编程场景，不只是游戏开发。

9. 最佳实践与使用建议

9.1 开发流程建议

• 第一次先做一个“最小可玩版本”，只保留核心资源产出和升级按钮，不要一上来就堆功能。
• 保留一套最小可运行配置，包括依赖、启动命令、测试命令，并写进 README。
• 模型文件、输入素材、输出结果分目录管理，不要让 AI 生成的临时文件污染主项目。
• AI 生成的代码统一放在独立目录，经过审查后再合并到主代码库。
• 每次迭代后用 Git 打标签，方便回溯“哪一版数值是正常的”。

9.2 批量任务工程化建议

• 给批量测试脚本加入日志输出，每次任务记录开始时间、输入参数、结果状态、耗时。
• 给批量生成素材脚本加入“去重”逻辑，避免重复下载或重复请求 API。
• 批量处理中一定要有失败重试，但重试次数不宜超过 3 次，超过后标记失败并继续下一个任务。
• 如果调用第三方 API，注意控制并发数，避免触发限流。

9.3 合规与安全建议

• 涉及人脸、声音、版权素材时必须确认授权。AI 生成的游戏角色不宜使用真实公众人物肖像。
• AI 代码生成和 AI 绘图工具要关注平台服务条款，明确是否可以用于商业项目。
• 接口服务如果暴露到局域网，要设置访问限制，避免被外部机器批量调用。
• 素材归档时保留提示词记录，方便后续追踪版权来源和风格出处。

9.4 长期维护建议

放置游戏的核心是数值乐趣，AI 可以生成初始数值，但长期平衡需要人工调整。建议把每次数值调整记录到docs/postscript/目录，保留调整原因。这样既符合项目标题里的 “PostScript” 含义，也能让后续维护者理解设计意图。

10. 总结与下一步

这个项目最值得尝试的点，不是“用 AI 写代码”这一件事，而是把 AI 嵌入了游戏开发的全流程：从需求拆解、代码生成、素材生产、数值验证到测试排错，形成了一条可以反复迭代的链路。它的核心价值在于：AI 不是替代开发者，而是把重复劳动压缩到最小，让开发者把精力留给真正的设计决策。

最先应该验证的功能有三个：

• 资源自动产出和升级系统是否跑通。
• 存档/离线收益是否准确。
• AI 生成代码能否通过单元测试并合并进主项目。

最容易踩的坑，是盲目相信 AI 生成的代码，跳过测试直接上线。放置游戏虽然逻辑简单，但数值一旦爆炸，玩家体验会立刻崩溃。所以任何 AI 生成模块都要过一遍测试和人工审查。

后续可以继续扩展的方向，包括：接入更多 AI 能力做动态任务生成，把游戏事件脚本改造成 PostScript 风格的栈解释器，增加更完整的批量测试任务队列，以及把本地模型服务做成一个可复用的“游戏开发助手 API”。

把这个项目跑通后，你手里就不只是一个放置游戏了，而是一套可以套用到其他游戏类型的 AI 辅助开发工作流。建议收藏备用，下次开新坑时直接照抄这套流程。