这是《AI编程来了我决定一个人做一款游戏》系列的第8期。第7期结束后我的像素风模拟经营游戏已经跑起来了地图编辑器能用了背包系统能收物品了。但这期开局并不轻松我想给游戏加入物品合成和任务链却发现自己要处理大量重复的数据配置、异步加载和边界判断。还好AI编程已经深度嵌入我的工作流它帮我扛下了很多枯燥的代码堆砌让我一个人还能继续往前走。这期我不聊愿景只聊真实的协作细节怎么用AI写核心系统、怎么让AI生成的异步代码真正可用、怎么用AI agent批量处理数据以及我在调试AI生成代码时总结的排查套路。如果你也打算一个人做游戏或者正在摸索AI辅助开发这期应该有你想看的东西。1. 一个人做游戏AI到底帮我省了多少事1.1 第八期的项目现状先同步一下进度。这游戏用的是Godot 4GDScript为主再加少量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这种动态类型语言里这种混乱会导致排查问题时要靠眼睛盯很久。第二是配方表直接硬编码在脚本里每加一个新配方就要改代码这和我整个项目的数据驱动设计背道而驰。第三是错误处理太弱当背包空间不足时它随便返回个falseUI层根本不知道具体原因。我的处理方式是先不让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干活、我来把关这套模式希望今天这些细节能帮你少走点弯路。