这是《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打开GDScriptAI编程独立工具负责所有新模块的骨架生成和大型重构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放大的是被你自己的判断力放大的。 一个人用AI编程做游戏：高效流程、踩坑记录与提示词实战
这是《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打开GDScriptAI编程独立工具负责所有新模块的骨架生成和大型重构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放大的是被你自己的判断力放大的。