这是《AI编程来了，我决定一个人做一款游戏》系列的第七篇。对，还在用AI写代码，而且这个项目已经从“试试看”变成了认真在跑的一个长期计划。最近几期总有朋友私信问，一个人做游戏，AI编程到底靠不靠谱，是不是智商税，是不是拿来演示的爽片？这期我就围绕这些问题，把这段时间用AI做游戏开发的真实状态、踩坑记录，还有我整理出的一套“单人使用AI写游戏代码”的流程，一次性聊透。
先说结论：AI编程真的能把一个人开发的工作效率拉起来，但前提是你得先搞清楚它在你的工作流里到底扮演什么角色。我前几期的demo还是手写为主，到了中期开始全面引入AI，最大的感受是“上下文切换成本”被大幅砍掉了。做游戏的人应该都有这种体会——刚写了一半战斗逻辑，测试完马上又要调UI，调完UI又得去看数值配表，脑子的状态还没热起来就切走了，一天下来真正有效的产出可能只有三四个小时。AI编程信息密度高，写完一个功能马上让AI接下一个，中途基本不打断思路。
但AI不能替代的一件事，是游戏设计本身。它可以帮你写“玩家按下R键之后重新生成整张地图”的代码，但它不会告诉你“按R重开”这个机制放在当前关卡里好不好玩、会不会让玩家觉得挫败。真正决定一款游戏是否好玩的是手感、节奏、目标感这些没法量化的东西，这些判断必须我自己做。所以我给自己的定位是“项目经理 + 策划 + 测试 + 唯一背锅侠”，AI则是那个代码写得很麻利但偶尔会犯迷糊的实习生。这个定位想清楚了，很多选择题就变得简单。
1. 内容整体设计与思路拆解
1.1 一个人开发，为什么偏偏选AI编程这条路
我最早开始这个项目时，考虑过Unity、Unreal，也考虑过直接用网页三件套做个小游戏。最后选了Godot 4.x作为主力引擎，一个重要原因是它场景树和脚本的结构非常清晰，正好适合让AI理解“节点挂脚本、脚本控制行为”的模型。你给AI一个场景结构描述，它很容易顺着你的思路在对应节点上挂代码，这比Unity的Prefab加MonoBehaviour那一套要直观很多。
但真正让我确定“AI编程可以承担日常主力”的瞬间，是某次实现存档系统。以前手写的话，我至少要花两个小时处理存档路径、序列化格式、版本兼容、异常恢复这些琐碎的问题。那次我只是在提示词里描述清楚“用JSON存到user://save.dat，结构包含玩家位置、血量、背包数组，版本号单独一个字段”，AI在几分钟之内就把整套存档模块写出来了，而且直接通过了冒烟测试。从那一刻起我就知道，一个人的游戏开发流程可以换一种跑法了。
这种换法不是把AI当成自动补全工具，而是把它当成一个能理解“整个模块”的协作者。传统IDE的补全只能帮你少打几个字符，AI编程能帮你减少的是从需求到代码之间的翻译过程。对于一个没有大把时间写代码、但脑子里装满了设计和想法的独立开发者，这种翻译型工作的减少，恰恰是最值钱的。
1.2 AI编程带来了什么，又没带来什么
AI编程解决的是“怎么写”的问题，没有解决“写什么”和“为什么写”的问题。在单人开发里，“怎么写”占比其实很高，尤其是样板代码、事件处理、UI绑定、状态同步这些偏机械的部分，AI能替我节省掉七成以上的时间。但它不会告诉我，这个敌人要不要设计成两条血条，关卡里的奖励节奏什么时候该松、什么时候该紧，音效和震动的先后顺序怎么配合手感。
所以我的工作方式变成了：设计文档我来写，系统框架我来画，模块边界我来定，拿到AI生成的代码后，我来审查、测试、微调。这种分工比我想象中顺畅，因为Godot的GDScript语法本身比较简单，AI生成的代码可读性也高，出了问题我在十分钟之内基本能定位到原因。如果换成C++写Unreal，可能审查成本会高得多，这也是我建议新手尝试AI写游戏时从Godot入手的原因。
2. 用AI写游戏代码，先看清这五个事实
2.1 AI生成的代码“看起来对”，不一定真的对
我踩过最大的坑，就是默认AI给出的代码“能跑就说明没问题”。但实际接入时，出了很多只在边界情况下才触发的bug。举个我一直留着的例子：技能冷却管理系统。AI很顺利地给了一个CooldownManager类，接口完整，有start_cooldown、is_ready、get_remaining_time，看起来像模像样：
func _process(delta: float) -> void: if _is_cooling_down: _remaining = maxf(_remaining - delta, 0.0) if _remaining == 0.0: _is_cooling_down = false cooldown_finished.emit()单看这段代码没有任何问题，但如果游戏里有时间暂停机制，比如玩家释放“子弹时间”技能，全场节点的_process都会变慢，冷却时间也跟着变慢，技能整体节奏就全乱套了。AI是按“平均情况”写代码的，它默认游戏里的时间流速是稳定的，不会主动考虑玩家减速、暂停、Buff减CD这些特殊规则。从那以后我给自己立了一条规矩：让AI生成代码之前，先把项目里的“全局规则”写进提示词，如果涉及时间和数值，一定要单独列一节说明。规则类提示词我在下一章会详细讲。
2.2 长对话会让AI越改越糊涂
AI编程工具的上下文是有限度的。第一次对话时它能准确记住你的技能表，但当你连续修改五六轮之后，它就可能开始前后矛盾，或者无意识地把之前已经改好的部分弄坏。我遇到过最典型的情况是：本来只是想加一个“丢弃物品时弹出确认框”，结果AI顺手把背包里“右键使用物品”的逻辑也改了一遍，完全不是我想要的。
应对办法说起来很简单，但执行起来需要自律：每次进入一个独立的小任务，就新开一个对话，不要在一个超长会话里连着做好几个功能。新对话里没有上下文，所以我会维护一份“项目常驻说明”，把引擎版本、场景结构、编码风格、全局规则全部写进去，每次开新对话时先丢给它。这样既能避免上下文漂移，又能保证AI生成结果的一致性。这个习惯一开始有点麻烦，但习惯之后，返工率明显下降。
2.3 跨文件改动时，AI容易“改了东墙、漏了西墙”
AI擅长“添加”代码，不擅长“删除”代码。当你想用一套新系统替换掉旧系统时，AI往往会很顺利地在新文件里生成好新系统，但忘了清理由旧系统残留的调用，或者漏掉某个配置表里的相关项。我第一次遇到这个问题，是在某个旧功能替换成新事件系统的时候，游戏运行后点按钮没反应，排查了一个小时才发现有个场景文件里的信号连接还指着旧函数名。
后来我强制自己遵循一条流程：跨文件的重构，先让AI只输出一份“受影响文件清单”，不要直接写代码。清单里要明确列出每个文件大概要改什么，是新增、删改还是替换，涉及哪个函数和哪几行。等清单确认无误，再让AI动手写。虽然多了一步，但这一步恰恰是把“AI的盲区”拿到台面上来审视，比事后排查要省时得多。
2.4 AI生成的代码风格，会和你手写代码越来越割裂
还有一个很隐蔽、但后期会越来越疼的问题：代码风格分裂。AI生成的代码受训练数据影响，注释习惯、命名风格、常量写法基本上随机变化，可能这次生成出来的类用下划线命名，下次就是驼峰，再下次又混用在一起。我个人的习惯是常量尽量集中在同一个类里管理，但AI经常直接把magic number写在最深层的方法里。一两个文件还好，整个项目混着AI代码和手写代码，两个月后再看简直像三个人合写的一样。
我的解法是把“编码风格”写进项目常驻说明里，并且会在每个新对话的提示词里重复一遍。比如明确“常量全部放到Constants类里、使用JSDoc风格的块注释、不用单行if、函数命名用下划线”。AI对风格约束的遵守程度，比你想象中要好。只要你自己能坚持把规则写在前面，它就会一直在生成结果里贯彻。
2.5 AI会一本正经地“编”出错误API
这是最需要警惕的一点。AI在不确定某个引擎原生API该怎么调用时，会基于它对类似框架的“印象”编造一个看起来非常合理、但实际不存在的函数名或参数。尤其是碰到比较冷门的引擎模块，它很可能一本正经地胡说八道。我遇到过一次，它给了一个完全不存在的贴图压缩接口，编译直接报错，更麻烦的是它还会顺着你报错的方向继续圆，而不是承认自己给出了错误API。
针对这个问题的措施比较“笨”：凡是调用引擎原生API的地方，我会在提示词里要求AI在注释里标注“来源自哪个类或哪个官方文档示例”，然后我自己快速核验一遍。这个核验成本不高，但能把AI“合理编造”的风险压到最低。别嫌麻烦，这一步省不了。
3. 提示词工作台：让AI从“写不对”变成“写得对”
3.1 项目背景规则：每次对话都从同一份说明书开始
很多人用AI编程觉得效果不稳定，最核心的原因是每次对话都是“裸聊”——不给背景就直接提需求，AI只能从零猜起。我的做法是先写好一份项目背景规则，作为每次对话的第一条消息，然后再提具体需求。这份规则我会根据项目情况持续维护，大概长这样：
你是这个项目的主力开发助手。 项目类型：2D横版动作游戏。 引擎版本：Godot 4.2。 主要语言：GDScript。 场景结构：角色是CharacterBody2D，包含Sprite2D、AnimationPlayer、CollisionShape2D子节点。 编码风格：常量收拢到Constants.gd；使用块注释；函数命名用下划线；避免一行if。 全局规则：角色受击时有0.5秒无敌帧；时间暂停类效果不影响UI；所有外部资源统一走res://assets目录。 当前需求：……这段背景规则看起来简单，但它直接把AI生成结果的稳定性拉高了一个档次。因为对AI来说，它不需要猜你的项目是什么框架、什么命名习惯、节点挂在什么层级，直接顺着你给的规则生成代码就行了。
3.2 需求描述越具体，AI的代码越可用
经验不足的人让AI写功能时，最容易给出一句大白话：“写个背包系统”。这种需求扔给AI，它只能自由发挥，出来的结果十有八九跟你的项目结构合不上。我后来养成了习惯：需求描述必须包含四个要素——界面布局、核心数据结构、交互流程、边界条件。举一个我实际写过的例子：
做一个玩家背包面板，最多20格。 界面用PanelContainer嵌套GridContainer实现，每个格子是Button节点。 背包数据用数组存储，数组长度固定为20，元素为空或物品ID。 交互流程：点击格子时选中并高亮，再点另一个格子执行交换；右键当前格子弹出一个菜单，包含“使用”和“丢弃”按钮。 边界条件：背包已满时拾取物品弹提示；丢弃物品要二次确认。这种写法虽然啰嗦，但AI生成的代码基本可以直接跑，而且风格和项目结构高度契合。核心原因是AI不用替你做产品决策，你替它做了所有决策，它只负责翻译和实现。一个人做游戏最不缺的就是想法，缺的是把想法用提示词格式化出来的能力。
3.3 先让AI给方案，再让AI写代码
很多初学者拿到AI工具就像拿到自动炒菜机，菜谱都不看一眼就直接按启动，结果出来的菜难吃又难改。现在我给自己定了一条硬性规则：凡是比较大的功能模块，先让AI输出一份实现方案，确认无误后再让它进入编码模式。比如我会说：“先不要写代码。请先列出这个技能系统需要的类划分、每个类的主要职责、数据流是怎么走的。列出后我确认，你再逐个类实现。”
这一步的价值在于，它把“返工”成本降到了最低。AI直接写一个大模块时，很可能会把所有逻辑塞进一个类里，或者把多个职责混在一起，代码跑起来没问题，但后续改动非常痛苦。先方案后代码，相当于让AI先画图纸再盖楼，既然它理解能力强，那就利用好这个理解能力，别让它一上来就闷头写。
3.4 反向提示词：逼AI说出“我不建议”
这是我在实践里偷学到的一个技巧：在提示词末尾加一句“如果你认为这个方案在性能或可维护性上有风险，请直接说出来，不要为了实现而实现”。大多数时候AI倾向于顺着你的意思给出积极反馈，因为它受训练目标的影响，总想最大化用户满意度。但游戏开发里，“满意”不等于“正确”。
我现在会在需求比较模糊或涉及性能敏感区时，给AI一个“否决权”。比如我会说：“请分析这个方案在GC压力上的潜在风险，如果风险明显，在提示中先说‘不建议’，并给出替代方案，分低于7分不要写代码。”实测下来，这个方法能逼出大量AI本来会藏在细节里的隐患。它不是每次都对，但十次里至少有五六次能提前预警问题，这对一个人开发来说已经非常值了。
4. 工具不是越多越好，适合单人开发的就是最佳的
4.1 独立AI编程工具和IDE内置插件怎么选
网上关于AI编程工具的信息很杂，有人吹独立工具，有人吹IDE插件，其实两者解决的问题不一样。我目前的工作流里两类都在用，各管一段。IDE内置的AI辅助插件，比如JetBrains系列里的AI助手和GitHub Copilot，更适合“当前光标处的补全”、“对选中代码的解释”、“单函数级的小改”。它的优点是无感、快、集成度高，但缺点是上下文限制比较大，主要依赖当前打开的文件，对整个项目结构的理解比较弱。
独立AI编程工具，比如Cursor、Windsurf，能读取整个工作区的索引，体现在“跨文件修改”、“新模块生成”、“批量重构”这些场景里优势非常明显。尤其在做游戏时经常要一次性创建好场景、脚本、资源引用之类的一大堆文件，独立工具在这时候效率极高。我的习惯是：写新模块、做重构、批量生成这类任务时开独立工具；日常小改动、查报错、写单元测试时留在IDE里用插件。
4.2 我的实际搭配与一份“提交信息”私货
目前我做这个游戏项目的搭配是：主力编辑器用Godot自带的编辑器，写脚本时用外部IDE打开GDScript，AI编程独立工具负责所有新模块的骨架生成和大型重构，IDE里的AI插件负责日常的补全和小细节修正。这套组合看着不算酷，但很稳。工具不是越多越好，关键是每类工具负责它最擅长的环节，别让它们互相打架。
还有一个小私货分享给你们：我让AI在生成完代码之后，顺手根据git diff生成一条清晰的提交信息，比如“新增背包拖拽交换逻辑，修复物品丢弃后未刷新面板的问题”。一个人开发久了就会知道，提交信息写得好，回滚和排查问题时能省下大量时间，而AI做这件事几乎是零成本，何乐而不为。
5. 一个人开发，最缺的其实不是写码时间
5.1 给“游戏设计范围”设上限
接触AI编程之后，生产效率上去了，我的第一反应是想做更多的系统，追求更丰富的玩法。结果呢？每周目标排得太满，没有一项真正做完了，挫败感反而比纯手写时更强。后来我复盘发现，AI编程带来的不是“时间消失”，而是“时间被重新分配”，如果分配得不好，它会让你在两个月内做出十个半成品功能。
我现在给自己定了一条规矩：每周目标清单最多五个，而且每个目标必须有“完成标准”。比如“完成背包拖拽交换”比“完善背包系统”要好用得多。清单要精细到可以当验收标准用，做完一项划掉一项，过程中不临时加需求。当AI编程跑得快的时候，作为“唯一项目经理”，你要做的不是多接单，而是主动砍单。
5.2 把“不知道”变成“可验证的问题”
游戏开发里有很多“不知道”的时刻：这个怪物的移动方式会不会让玩家血压拉满？这个掉落概率到底是5%还是15%更有手感？这种问题不应该丢给AI去猜，AI给不了体感上的判断。我现在会把这类不确定的点写进一张“待验证清单”，每个清单项都带上一个验证手段。比如“敌人三连斩的第二段前摇调到0.4秒，请10个测试玩家感受是被迫躲开还是奶一口”，然后集中一个下午把这些小实验跑掉。
AI编程能帮你把这些问题变成可运行的版本，但设计决策还得靠你自己观察玩家反馈。一个人开发最忌讳的就是闭门造车，哪怕你做的只是自娱自乐的小品级游戏，也要逼自己用“小实验”的方式回答问题，而不是在脑内模拟。
5.3 故意不做某些功能，是一种主动选择
在AI编程效率变高之后，我反而开始“故意不做”某些功能。比如背包系统的“拆分堆叠”功能，我评估之后觉得测试成本太高，技能系统里最复杂的连招派生也暂时只做了三级。这些功能不是永远不做，而是这周不做、这个版本不做。AI编程确实让写代码变快了，但它没法替你决定什么事情值得做。主动砍掉不重要的功能，和因为能力不够而被迫放弃，虽然结果看起来一样，但对项目节奏的影响完全不同。
“这个功能后面再加”这句话，在我现在的工作流里不是拖延症的借口，而是范围管理的必要手段。我能确定的是：AI能把“写功能”的边际成本压得很低，但“想清楚要不要写这个功能”的决策成本一点都没有降低，甚至因为选择变多，反而更费神。
6. 下一个阶段的计划和一点个人体会
接下来两周的目标定得很清楚：战斗手感的调优、第一个可玩Boss的实装，以及把前期AI重构留下的几处技术债清掉。清债的方法也不用多复杂，就是回到那几个老文件，仔细读一遍，该拆的函数拆开，该删的死代码删掉。AI能帮我快速写新东西，但质量检查这件事没有捷径，必须自己把一道道关守好。
如果让我说这七期下来最重要的感受，那就是：AI编程改变的不是“你能不能做游戏”，而是“你可以把多少精力从写代码转移到做设计上”。但这件事的前提是，你仍然有能力读懂AI生成的代码，审核它的逻辑，并且在它给出“看起来对但实际有问题”的方案时站住脚。一个人做游戏的自由，不是被AI放大的，是被你自己的判断力放大的。
