在小团队或独立工作室做游戏的开发者，日常工作里策划、程序、美术、文案和社区运营都要兼顾，原型迭代时间紧。单元测试大家都知道重要，但写起来枯燥，边界条件也容易想不全。下面以游戏开发者的真实场景为例，演示用 AI 生成单元测试的完整流程：把函数代码和业务规则交给 AI，先让它列出测试场景清单，确认后再生成测试代码并运行。

典型场景

游戏开发者写了一个处理“测试反馈”数据的函数，比如按关卡汇总通关时长分钟。上线前需要补测试，但时间紧，而且担心漏掉空数据、异常值这类边界情况。尤其当制作人同时还在等“整理玩家测试反馈”的结果时，能把这部分工作提速，就能腾出精力处理更重要的判断。

推荐工具

编辑器内的编程助手（GitHub Copilot、Cursor、通义灵码、CodeGeeX 等）可以直接根据函数生成测试；也可以把代码贴给对话助手。

让 AI 生成测试后，一定要在本地运行，并检查断言是否真的验证了业务规则。

一个虚构的例子

我们用一个虚构人物把流程串起来：晓雯，游戏开发者，最近在忙“优化移动端性能”。一次版本评审会结束后，晓雯意识到需要尽快生成单元测试，可当天还要处理“整理玩家测试反馈”。于是晓雯把要求和背景一次性写进提示词，让 AI 先出一版，再花时间修改关键部分。最后交给制作人的版本，结构和措辞都是晓雯亲自把过关的。

分步操作

  1. 提供被测函数代码和业务规则说明
  2. 让 AI 先列出测试场景：正常、边界、异常
  3. 确认场景清单，补充业务特有的情况
  4. 生成测试代码并在本地运行
  5. 检查失败的用例是代码问题还是测试问题

提示词模板（可直接复制）

提示词的关键是把背景、要求和输出格式写清楚：

【背景】当前的难点是：美术资源外包进度慢，可能影响试玩版时间。
请为下面的 Python 函数编写 pytest 单元测试。

业务规则：按 category 汇总 amount；amount 为空的记录跳过；amount 为负数时抛出 ValueError。

```python
def summarize(records):
    result = {}
    for r in records:
        if r.get("amount") is None:
            continue
        if r["amount"] < 0:
            raise ValueError("amount must be non-negative")
        result[r["category"]] = result.get(r["category"], 0) + r["amount"]
    return result

要求：

  1. 先列出测试场景清单（正常、边界、异常）
  2. 再写测试代码，使用 parametrize 减少重复
  3. 每个测试函数名能看出测试意图

## 效果示例（虚构演示）

示例输出如下（虚构内容，仅演示 AI 大致会给出什么样的结果）：

> **测试场景**
> 1. 正常：多条记录、多个分组
> 2. 边界：空列表；amount 为 0；amount 为 None
> 3. 异常：amount 为负数
>
> ```python
> import pytest
> from summary import summarize
>
> def test_groups_and_sums_amount():
>     data = [{"category": "第一关", "amount": 10}, {"category": "第一关", "amount": 5},
>             {"category": "第二关", "amount": 3}]
>     assert summarize(data) == {"第一关": 15, "第二关": 3}
>
> @pytest.mark.parametrize("data,expected", [
>     ([], {}),
>     ([{"category": "第一关", "amount": 0}], {"第一关": 0}),
>     ([{"category": "第一关", "amount": None}], {}),
> ])
> def test_boundary_cases(data, expected):
>     assert summarize(data) == expected
>
> def test_negative_amount_raises():
>     with pytest.raises(ValueError):
>         summarize([{"category": "第一关", "amount": -1}])
> ```

这样的输出只是起点。真正用到“完成战斗系统原型”这类工作里之前，还需要对照原始资料逐条检查，并补上 AI 不知道的背景。

## 避坑指南

- 先确认场景清单再生成代码，比直接要测试代码更可靠。
- 缺少某个 key 的情况（比如没有 category）要和业务方确认预期。
- 生成的测试也要纳入代码评审。

### 给游戏开发者的特别提醒

用 AI 批量生成道具、角色和任务文案初稿，再统一世界观和语气。还有一点很关键：AI 生成的美术和文本在商业游戏中使用前，要确认工具的商用授权和平台政策。

再补充一条经验：写游戏逻辑时让 AI 给出伪代码和边界情况，再落实到具体引擎。

## 变体用法

- 补全覆盖率：把覆盖率报告中未覆盖的代码交给 AI，补充测试。
- 接口测试：根据接口文档生成请求用例和断言。

## 相关阅读

- [游戏开发者用 AI 写技术文档：从代码生成接口文档和说明](/posts/2026-10-16-game-developer-tech-doc/)
- [游戏开发者用 AI 头脑风暴：提示词与示例](/posts/2026-10-16-game-developer-brainstorming/)
- [程序员用 AI 生成单元测试：覆盖边界条件的测试用例](/posts/2026-10-16-programmer-unit-test/)
- 延伸：[编码 Agent 工作流：从需求拆解到合并请求的人机协作模式](/posts/2026-07-18-coding-agent-workflow/)
- 更多场景：[AI 使用示例合集](/categories/ai-examples/)，或按标签浏览[#游戏开发者](/tags/游戏开发者/)、[#单元测试](/tags/单元测试/)