这是《AI编程来了，我决定一个人做一款游戏》系列的第8期。第7期结束后，我的像素风模拟经营游戏已经跑起来了，地图编辑器能用了，背包系统能收物品了。但这期开局并不轻松：我想给游戏加入物品合成和任务链，却发现自己要处理大量重复的数据配置、异步加载和边界判断。还好AI编程已经深度嵌入我的工作流，它帮我扛下了很多枯燥的代码堆砌，让我一个人还能继续往前走。
这期我不聊愿景，只聊真实的协作细节：怎么用AI写核心系统、怎么让AI生成的异步代码真正可用、怎么用AI agent批量处理数据，以及我在调试AI生成代码时总结的排查套路。如果你也打算一个人做游戏，或者正在摸索AI辅助开发，这期应该有你想看的东西。
1. 一个人做游戏，AI到底帮我省了多少事
1.1 第八期的项目现状
先同步一下进度。这游戏用的是Godot 4，GDScript为主，再加少量C#做工具脚本。目前的完整模块有：可编辑的2D地图、基于瓦片的碰撞系统、背包和物品栏、NPC基础对话、战斗框架。第7期把地图编辑器接进来后，整个项目最大的痛点变了：不再是"功能做不出来"，而是"功能模块之间怎么稳定地捏合"。
这期我希望完成三件事：一是做个物品合成系统，能把背包里的材料合成为新道具；二是任务链系统，按顺序触发NPC对话、收集物和场景切换；三是把整个过程的异步加载理顺，不能让切换地图时卡顿或报错。这些活儿要把数据定义、代码逻辑、UI反馈串起来，一个人手工敲也能做，但周期至少两个星期。有了AI辅助，目标压缩到一周。
我实际用下来的感受是：AI编程不是替我思考，而是把我的精力从重复编码里解放出来。比如写配方表、生成任务节点、整理多语言文案，AI几秒钟就能给我可用的草稿。我真正的价值，是判断它写的对不对，以及把它生成的东西接进现有架构。
1.2 为什么一个人也要选全栈方向
很多朋友问我，为什么不找策划、美术、程序，三个人组队做游戏？我的答案很现实：凑齐一个稳定的小团队，比一个人做十个系统更难。一个人做游戏，其实是"超级个体"模式：策划的事要懂，美术的事要懂，程序的事要懂，音频的坑也得知道。AI编程最大的价值，就是让这个"超级个体"的短板不至于致命。
选Godot而不是Unity，我是故意的。Godot引擎轻量，启动快，编辑器对单文件脚本非常友好。更关键的是GDScript的语法接近Python，结构简单，AI模型对它的训练数据覆盖度已经很高。比起C++或者C#，用GDScript写游戏逻辑时，AI生成代码的出错率明显低一些。Unity虽然生态更强，但它的组件体系和C#复杂特性，会让AI生成代码时出现更多"看起来很对，运行就崩"的情况。
我用本地AI工具辅助代码生成，也用云端AI做代码解释和重构建议。实际工作流里，AI最擅长的事情是：把模糊需求变成初始代码、批量填充样板代码、解释一段别人写的老代码、给出一组测试用例。而我必须自己做的，是架构设计和最终验收。这两件事，AI目前替代不了，我也不希望被替代。
2. 用AI搭游戏核心系统：物品合成与任务链
2.1 需求拆解与提示词设计
我以前写提示词喜欢说"帮我写个物品合成系统"，结果AI给我一个200行的单体脚本，表面功能都有，但根本接不进项目。后来我学会了先把需求拆解成"数据、规则、UI、反馈"四层，再让AI逐层生成。
以物品合成为例，我实际给AI的提示词是这样的：
你是一名游戏后端开发者，使用GDScript实现一个物品合成系统。请先设计一个配方的数据模型，包含输入物品列表（物品ID、数量）、输出物品（物品ID、数量）、合成耗时。再提供合成系统的类设计，要求支持校验背包内材料是否足够、扣除材料、生成产物、返回成功或失败原因。最后给出一份示例配方数据，不要写在代码里，用JSON格式输出。
这段提示词里包含了角色设定、技术栈、功能边界、交付物格式。AI生成的结果比直接问要好很多，因为它知道了我要的是"数据模型+逻辑类+示例数据"，而不是一坨混在一起的代码。
生成出来之后，我会让它再提供一组边界测试用例：材料不足时如何返回、材料刚好够时如何成功、产物占背包格子满时如何处理。这一步非常关键，AI在生成正常逻辑时通常很流畅，但在边界条件上常常偷懒，必须主动让它补。
2.2 AI生成的代码为什么能跑但不能直接用
我让AI生成的合成系统初版，确实能在编辑器里跑起来，点击按钮能合成物品。但打开代码一看，三个问题立刻暴露出来：
第一是命名混乱。同一个物品ID，一会儿叫item_id，一会儿叫id，一会儿叫itemId，在GDScript这种动态类型语言里，这种混乱会导致排查问题时要靠眼睛盯很久。第二是配方表直接硬编码在脚本里，每加一个新配方就要改代码，这和我整个项目的数据驱动设计背道而驰。第三是错误处理太弱，当背包空间不足时，它随便返回个false，UI层根本不知道具体原因。
我的处理方式是：先不让AI直接改，而是自己画好边界。我要求AI把配方数据全部迁移到独立的JSON文件，脚本里只负责读取和逻辑执行。这样一来，以后加配方只需要编辑JSON，不用碰脚本。AI在数据迁移这种任务上效率极高，给它一个老文件和一个新格式示例，它几分钟就能整理完所有配方。
这里有个重要心得：AI生成的代码，至少要做一次"架构审查"。重点看有没有脱离项目的整体约定，比如命名规则、配置文件位置、错误处理规范。不审查就直接用，早晚会在某个深夜被它埋下的雷炸醒。
2.3 数据驱动设计让AI更顺手
物品合成和任务链这类系统，天然适合数据驱动。我把所有任务配置写成JSON，每个任务包含节点数组，每个节点有类型（对话、收集、移动、交付）、目标、完成条件、后续跳转。AI在生成这种结构化数据时非常稳定，因为模式固定，几乎没有歧义。
一个任务配置的节选：
{ "id": "quest_001", "title": "找回失落的种子", "nodes": [ { "type": "dialogue", "npc": "npc_farmer", "line": "你好，陌生人，我的种子袋不见了。" }, { "type": "collect", "item": "seed_bag", "count": 1, "target_scene": "farmhouse" }, { "type": "deliver", "npc": "npc_farmer", "item": "seed_bag", "reward": "basic_hoe" } ] }这套结构确定后，AI就能很稳定地帮我把几十个任务填充出来。我只需要在JSON里改文案，系统的解析逻辑不用动。之前很多人担心AI生成的数据不靠谱，但在我这套schema约束下，AI生成数据出错率极低。关键是先定义好"填空模板"，再让AI去填空，而不是让它自由发挥。
3. 让AI写异步逻辑，踩过的坑比预期多
3.1 为什么游戏里到处都是异步
非程序员可能不太理解"异步"这个词，我打个比方。你去餐厅点餐，如果服务员做好一道菜就站在你面前等，不做下一道，那就是同步；如果服务员给你一个号，让你坐着等，叫号再取餐，那就是异步。游戏里加载场景、加载图片、播放动画，都必须用"叫号取餐"的方式，否则游戏画面一卡，所有交互全停住。
Godot里处理异步主要靠协程和信号，GDScript里的await关键字就是为这个设计的。AI写普通逻辑时很靠谱，但一碰到异步，就开始频繁犯低级错误。这期开发过程中，我至少有两次被AI生成的异步代码坑到想砸键盘。
3.2 协程对话与场景切换的典型错误
第一个错误是忘了加await。AI生成一个NPC对话函数，里面写着dialog_box.show_line("你好")，后面又跟了一句dialog_box.close()。如果在show_line内部没有await用户点击，两行代码就会连续执行，玩家根本看不到对话内容。解决方法很简单：让show_line返回一个信号，然后外部用await等待。
第二个错误是信号连接错乱。AI生成代码时会用some_signal.connect(callback)，但多个角色共用同一个信号连接，导致A角色的对话回调被B角色触发。这个问题在调试时非常隐蔽，因为编辑器不报错。我的处理办法是让每个NPC实例持有独立的信号实例，而不用全局信号。
第三个错误是死循环等待。AI在处理场景异步加载时，写了一个类似while not scene_load_complete: await process_frame的循环，但load_complete这个变量永远不会被置真，因为真正的加载信号被放在循环外面了。结果游戏界面卡死。后来我要求AI：所有异步等待必须设置超时保护，最多等5秒就报错并跳转默认场景。
3.3 异步代码审查清单
被坑了几次之后，我列了一个异步代码审查清单，每次检查AI生成的相关代码都会过一遍：
| 检查项 | 具体问题 | 修复方向 |
|---|---|---|
| 是否真的await了 | 调用异步函数却没等待完成，后续逻辑提前执行 | 确认每个异步函数调用前都有await |
| 信号是否绑定正确 | 信号回调被多个实例抢占，导致逻辑串线 | 将信号改为独立实例或传入实例绑定 |
| 是否有超时保护 | 等待场景加载/资源加载卡死，用户无响应 | 使用await with timeout或手动计数器 |
| 是否存在竞态条件 | 两个异步任务同时修改同一个变量，结果不确定 | 用协程顺序执行关键操作，避免并发修改 |
| 是否处理取消 | 场景切换时旧异步任务还在运行，访问已释放节点 | 在_unrealize或_exit_tree中断开信号 |
这份清单现在是我项目里的"军规"。AI生成异步代码之后，我会先让AI自己按清单检查一遍，再人工复核。虽然多了一道工序，但省掉了无数次线上崩溃的排查时间。
4. 用AI agent批量处理重复劳动
4.1 什么是AI agent，我如何使用
最近"AI agent"这个词很火，简单说，它就是一个能自主理解目标、拆解步骤、调用工具来完成任务的AI程序。在我的游戏开发流程里，我把它用在了最枯燥的一环：批量数据整理和代码生成流水线。
比如我之前有100多个道具，每个道具需要：英文ID、中文名称、描述、图标路径、价格、叠加数量。人工整理这些要半天，而且容易出错。我让AI agent读取Excel导出表，自己分析表头，然后按我的代码风格生成一个GDScript常量文件，再把所有字符串抽离成JSON文案文件。
4.2 从设计表到多语言JSON的流水线
我的做法是用Python写一个调度脚本，把它当成AI agent的主控。脚本先读取设计表，把每一行清洗成标准格式；再调用AI接口，让它为每个道具生成一句话的中文描述和英文描述；最后把结果写入结构化数据文件。
核心逻辑示意：
import ai_client items = load_design_table("items.csv") for item in items: prompt = f"为道具{item['name']}写一句30字以内的中文游戏内描述，并给出英文翻译。只输出JSON。" result = ai_client.complete(prompt) parsed = parse_json(result) item["desc_zh"] = parsed["zh"] item["desc_en"] = parsed["en"] write_data_file("generated_items.gd", items) write_json_data("loc_items.json", items)这个流程跑一次，100个道具的文案和代码文件就能自动生成。不过我很快就补了一个必须的步骤：生成后自动检查字段是否齐全，比如描述为空或者价格小于0，都要标记出来。因为AI agent在自由生成时，偶尔会把某个字段填成空字符串，如果不检查，这些脏数据就会流进游戏里。
4.3 自动化流程中的人工验收
自动化不是"全自动"，一定要有人在关键节点验收。我踩过一次很痛的坑：AI agent批量生成任务配置时，把某个任务节点的物品数量从"1"改成了"0"，结果玩家在对话后不需要收集任何东西就能完成任务，任务链瞬间跳过了两关。当时游戏已经打包给几个朋友试玩，大家反馈"这任务怎么一下就完成了"，我才排查到是数量字段被AI写成了0。
从那以后，我在流水线末尾加了严格的数据校验：任务节点里，收集类目标数量必须大于0，交付类必须指定奖励，跳转的目标节点必须真实存在。任何不通过校验的数据，AI可以自动修正，但如果连续修改三次还不通过，就停下来等人处理。这个"三次规则"避免了AI agent在错误数据上空转，也让我保住了最后一道人的防线。
5. 调试实录：AI帮你写bug，你帮AI擦屁股
5.1 三个让人印象深刻的bug
这期开发中，AI生成的代码至少给我制造了三个难忘的bug。第一个是空引用：AI写的NPC对话脚本，假设玩家一定先进入了某个场景，直接访问了GlobalState.current_npc。当我在编辑器里直接运行对话测试场景时，这个变量是空的，游戏瞬间崩溃。错误提示还不是一行清晰的信息，而是"Attempt to call function on a null instance"，我第一次看到这个提示整个人愣住了。
第二个是硬编码坐标：AI生成一个摄像机跟随脚本，里面写死了一个位置(120, 80)，只适合某张地图。我换地图测试时，摄像机会自动瞬移到那个坐标。排查了半天，才发现AI为了省事，把本该从配置读取的初始坐标直接写进了代码。
第三个是逻辑顺序错误：合成系统里，AI先扣除了材料，再判断背包里材料是否足够。如果不够，材料已经被扣掉了，但产物没给，玩家背包白白少了一组物品。这类问题在单测里都不容易暴露，因为测试可能刚好材料足够。
5.2 排查思路与定位技巧
踩过这么多次坑后，我总结了一套排查AI生成代码问题的思路：先看日志，再看数据，最后看逻辑。Godot运行时会输出大量警告和错误信息，但AI写的代码往往吞掉异常，很多错误被隐藏了。所以我习惯先把AI生成的代码里的try-catch或guard子句删掉，让错误直接炸出来，这样定位更快。
第二步是看数据。游戏里很多"莫名其妙"的问题，最后都回到数据上：配方表ID写错、任务节点跳转目标不存在、物品描述字符串里多了个看不见的换行符。所以我用Python写了一个数据检查脚本，每次打包前跑一遍，扫描所有JSON里有没有空ID、负数量、缺失字段。
第三步才是看逻辑。如果是逻辑错误，我会用"二分注释法"：把AI生成的代码块从中间切开，注释掉下半部分，跑一次；再注释掉上半部分，跑一次。通过对比两次结果，能快速锁定问题出现在哪一半。这个方法朴实无华，但在排查AI写的长函数时效率极高。
5.3 常见问题速查表
下面这张表是我这个月处理AI生成代码时最常用的问题对照，直接贴在这里，希望对你有用：
| 现象 | 可能原因 | 快速修复 |
|---|---|---|
| 游戏启动直接崩溃 | 访问了未初始化的单例或节点 | 在函数开头确认引用非空，加guard处理 |
| 摄像机位置错乱 | 硬编码坐标，未使用配置值 | 搜索数值字面量，替换为配置读取 |
| 任务链条跳关 | 收集数量被改成0，或跳转目标不存在 | 增加数据校验，配置中目标ID做交叉验证 |
| 合成材料被扣除但没产物 | 扣材料和生成产物的顺序颠倒 | 先判断库存，足够后再执行扣除和生成 |
| 对话一闪而过 | 异步调用前缺少await | 检查所有异步调用，补上await |
| 多个NPC对话互相串线 | 全局信号被多个回调共享 | 为每个NPC实例创建独立信号 |
我曾经以为，用AI编程后就不用再学调试了，现实正好相反：AI生成代码的量越大，我需要的调试能力反而越高。以前我写一行代码调试一行，心里有数；现在AI哗啦啦给我一大片代码，我要是没有一套清晰的排查框架，很容易被它带进沟里。
6. 关于提示词和编程能力的关系，我的几点建议
6.1 提示词不是魔法
现在网上很多人教你"神奇提示词"，好像一句话AI就能做出完整项目。我的经验是，提示词确实重要，但它只是第一步。真正决定项目质量的，是你能不能看懂AI生成的代码，能不能发现它埋下的隐患，能不能把它接进自己的架构。提示词写得好，只是让AI初步输出更接近需求；如果我没有基本编程能力，AI生成的代码就是一堆随时会爆炸的积木。
所以如果你打算靠AI编程做游戏，请务必同时补一下最基本的编程概念：变量、函数、数组、字典、条件判断、循环，再加一点设计模式常识。这些知识花两三周就能入门，但能让你用AI的效率和安全性都翻好几倍。
6.2 用AI编程的三个习惯
我给自己定了三条规矩，现在也推荐给你。
第一，小步提交。AI生成的代码永远先放到特性分支，跑通一个功能后再合并进主目录。千万不要让AI一次生成几千行，直接覆盖掉原有代码，那样一旦出错，回滚都困难。
第二，单文件审查。每次AI生成代码后，我逐文件打开看，不跳过大段代码。看的时候主要找硬编码、空引用、命名混乱三类问题。虽然慢，但能避免以后好几倍的调试时间。
第三，测试先行。重要逻辑让AI先生成测试用例，比如合成系统的库存校验、任务链的跳转顺序。有了测试用例，改代码时就能自动验证有没有把已有功能弄坏。
6.3 我目前一个人团队的AI工具链组合
这一期做完，我个人的AI工具链也基本定下来了，可以给同样一个人做项目的朋友参考：
| 环节 | 工具/方式 | 用途说明 |
|---|---|---|
| 代码生成 | AI编辑器集成的代码补全和聊天 | 生成GDScript脚本、解释报错、补全样板代码 |
| 数据处理 | Python脚本+AI接口 | 读取表格、自动生成JSON配置、批量翻译文案 |
| AI agent | 基于大模型的自定义自动化流水线 | 执行多步骤数据清洗、批量生成任务文件 |
| 数据校验 | 自写Python检查脚本 | 扫描所有配置JSON，检查字段缺失与非法值 |
| 版本管理 | Git + 自动化测试 | 隔离AI改动，回滚问题版本 |
这套组合让我这个"一个人的团队"，拥有了一个不知疲倦的实习程序员：它效率极高，但需要我带脑子验收。我的日常就是：拆需求、指挥AI、写测试、审核代码、合并版本。听起来工作量也不小，但比起以前纯手写每一行代码，进度至少快了一倍。
最后再分享一个小技巧：让AI自己生成一份代码审查问题清单，每次AI提交代码后，你先把清单贴给它，让它自检一遍。我的清单包含"是否硬编码""是否有空引用""是否处理边界条件""是否遵循现有命名规范""是否缺少注释"。AI自检之后，虽不能保证100%没坑，但明显减少了我踩雷的次数。这个系列能做到第8期，也是靠着"AI干活、我来把关"这套模式，希望今天这些细节能帮你少走点弯路。
