2026/9/6 5:28:17
FEATURED · 精选文章 
第六期了。上一期结尾我说背包系统写崩了正在调数据结构和 UI 的边界这期先把结果交代一下没崩但是经历了两次推翻重写一次是我推翻 AI 的一次是 AI 推翻我的。我做的是个卡牌构筑 轻度 Roguelike 的 2D 游戏全程一个人代码绝大部分靠 AI 编程工具生成。到现在这个阶段统计了一下我自己手敲的代码不到三成剩下七成都是 AI 写的——但这个数字一点都不值得高兴因为真正花时间的是不断跟 AI 说清楚“我要什么”。这期就把这个过程拆开聊聊为什么 AI 编程时代最卡脖子的反而变成了需求描述、项目规则和工作流的组织方式。1. 项目做到第六期的真实状态从跑得起来到有东西可玩先说项目本身。游戏暂名《余烬裂隙》核心玩法是爬塔 卡牌构筑目标平台是 PC技术栈选了 Unity 2022 LTS C#。理由很现实Unity 的 C# 语料在 AI 训练数据里极其充足不管是 Cursor 还是其他编程 AI对 Unity 相关 API 的理解都明显比对冷门引擎好。如果你打算一个人从零开始做游戏第一课就得学会选一个“AI 语料丰富”的技术栈这直接决定了后续产出的顺利程度。1.1 这 30 天里游戏里多出了哪些东西相比上一次连载游戏从“场景里能走动的方块”进化成了“勉强能玩 15 分钟的一层地牢”卡牌战斗系统抽牌、手牌、能量、格挡、抽牌堆与弃牌堆的循环逻辑目前有 18 张可用卡牌、5 个基础敌人、1 个 BOSS。地牢地图生成每层 9-12 个节点包含战斗、精英、篝火、商店、神秘事件五种类型节点之间有路径连接下一层会刷新难度。玩家状态系统生命值、金币、药水、临时增益/减益状态。背包与道具系统这期就是围绕这个展开重写的目前支持物品叠加、分类过滤、排序以及和卡牌池的联动效果。存档系统二进制序列化的本地存档能记录当前层数、卡牌收藏和已解锁内容。其中地牢生成、战斗结算这类逻辑相对独立的模块我直接用了 AI 生成初版再手工改细节。背包系统则反过来——我憋了两天没敢让 AI 碰最后决定让它写结果接连踩坑。1.2 哪些功能我敢交给 AI哪些碰都不敢碰这几周我给自己定了一个简单的评估原则如果功能出问题是“修起来容易、但定位问题难”还是“定位容易、修起来难”前者适合交给 AI。比如地牢生成算法跑出来的路径不对日志一打就看到了定位快让 AI 反复改也改不出大问题。战斗结算里的伤害计算、格挡抵扣、状态触发顺序也同理单元测试写清楚AI 改错了我能立刻发现。后者我暂时不敢放手。比如存档系统的版本兼容一旦旧档在新版本读不出来玩家数据就废了——这种错误在测试阶段不一定暴露让 AI 自由发挥是给自己埋雷。再比如涉及 UI 事件绑定的逻辑AI 特别喜欢“自动帮你把 UI 层也写了”但自动生成的界面和你的视觉效果、交互节奏很难匹配改起来比手写还痛苦。所以 UI 部分我基本自己写只让 AI 生成背后的数据接口。2. 我被 AI 逼着重新学习怎么提需求以前我总觉得写代码难现在发现把需求讲清楚比写代码难得多。这不是谦虚是被 AI 狠狠教训了几轮之后的体会。2.1 一次失败经历让 AI 写背包系统它给我套了个框架第一次让 AI 写背包我的提示词只有一句话“帮我写一个背包系统包含物品的添加、移除、叠加和 UI 显示。”AI 非常热情地生成了十几个文件ItemData、Inventory、InventoryUI、DragAndDrop、TooltipSystem……看起来结构完整、注释齐全编译也能过。但仔细一核对和我的项目完全不搭调我的物品数据用 ScriptableObject 定义它自作主张换成了 JSON 驱动我需要物品支持堆叠它实现了但堆叠上限写死成了 999我需要和卡牌系统联动获得某张卡牌时自动从背包里消耗对应道具它没做更头疼的是它把所有 UI 都在代码里 new 了一遍而我用的是 Canvas 预制体。那一刻我明白了AI 不是在编程它是在按概率续写一段“看起来像背包系统”的代码。你给它的信息越少它就越倾向于生成网上最常见的、最模板化的方案。问题在于我的项目从来就不是“最常见的方案”。2.2 从帮我写到业务背景 数据约束 输出边界我重新梳理了需求描述的方式现在我的提示词会尽量包含这些要素角色与项目背景我是一个 Unity 开发新手项目是卡牌 RoguelikeC# 脚本使用 ScriptableObject 存放物品定义现有依赖已有 InventoryManager 单例物品定义在 Scripts/Data/ItemData.cs 中UI 层用 Canvas 预制体不需要 AI 生成功能边界这次只做数据层接口不碰 UI不做存档、不做拖拽、不做右键使用约束条件堆叠上限 99物品类型包括卡牌、药水、遗物、碎片四类涉及现有类的回调事件必须列出来输出格式先给接口定义和关键方法的伪代码确认后再生成具体实现不要一次性全给。这是改进后的第二版提示词几乎把“写什么”“不写什么”“怎么写”全部框死了背景 - 项目卡牌 Roguelike《余烬裂隙》Unity 2022 LTS C# - 我使用 ScriptableObject 定义物品数据字段包括 itemId、itemName、itemType、maxStack - 已有单例 InventoryManager负责全局存取 - UI 层用 Canvas 预制体不需要你处理 任务 实现背包的数据层满足以下需求 1. 数据结构InventoryData 类内部用 ListItemStackItemStack 包含 itemData 引用和 count 字段 2. 功能AddItem 时自动叠加到同类型物品超过 maxStack 时拆成新的 ItemStackRemoveItem 指定 itemId 和数量QueryItem 返回当前持有数量 3. 事件物品变化时触发 InventoryChanged 事件参数为 itemId 和变化后的数量 4. 约束不修改现有单例之外的代码不引入第三方库不生成 UI 和存档相关代码 5. 输出先列出类结构与每个公开方法的签名我确认后再写完整实现。同样是让 AI 写背包这一版生成的代码和我项目里的现有结构严丝合缝错误率明显下降。不是 AI 变聪明了是它终于不用猜了。2.3 给 AI 提供边界条件比描述功能清单更重要功能清单说的是“要做什么”边界条件说的是“不能做什么、只能做什么”。AI 生成代码时尤其依赖后者。一个很典型的例子自动化测试。我让 AI 写“AddItem 在背包满时应该给人提示”它默认直接往 UI 层塞弹窗。我加了一句“背包满时打印警告日志不操作 UIUI 层由我自己监听 InventoryChanged 事件处理”它立马换成纯逻辑实现和我的架构对上了。另一个例子是命名。我的代码风格是私有字段用下划线开头、public 字段全部用 [SerializeField] 暴露、不使用 public 字段。AI 默认生成的风格是public int count;。经过我的规则文件约束后生成结果才符合我的习惯。这件事让我意识到AI 编程的提示词本质上是在给一个“能力很强但会自由发挥的外部开发者写需求文档”。你要求得越具体它的发挥空间越小产出反而越可控。3. Cursor 的几个关键设置把 AI 从聊天机器人变成结对程序员我主力用的工具是 Cursor里面挂的是 Claude 系列模型。说实话作为一个长期用 VSCode 的人Cursor 的上手成本几乎为零但用好它和随便用它差距极其明显。3.1 项目级规则文件让 AI 记住你的代码风格Cursor 支持项目级规则文件通常叫.cursorrules。这是我从踩坑里学到的“最值回票价”的设置。第一周我完全忽略了这个文件于是每次对话都要重新解释一遍项目背景AI 风格飘忽不定后来我花了半小时把规则文件写出来之后所有生成代码的风格就稳定了。我的.cursorrules内容大概长这样# 项目信息 项目:《余烬裂隙》卡牌 RoguelikeUnity 2022 LTS C# # 代码风格 - 私有字段统一使用 _camelCase 前缀 - 需要暴露给 Unity Inspector 的字段使用 [SerializeField] private不使用 public 字段 - 事件使用 C# event不使用 UnityEvent - 不加魔法数字超过一次使用的常量提取到 readonly 或 const - 日志使用 Debug.Log注释说明为什么而非是什么 # 目录约束 - 新增代码放在 Scripts/Features/功能名/ 目录 - 不要修改 Scripts/Core/ 目录下的代码除非我明确要求 # 输出约束 - 生成的代码必须可以直接放入 Unity 项目并编译通过 - 先给出核心类和接口概览再给出完整实现 - 尽量不要生成 UI 代码除非我特别要求这套规则文件让我在后续开发里少吵了很多架。AI 第一版生成出来的代码代码风格已经和我的项目高度一致手工改动量大幅下降。3.2 用 符号引用真实代码别让 AI 凭空想象另一个效率黑洞是AI 并不了解你的项目结构除非你主动告诉它。以前我让 AI 写“角色受到攻击掉血”它可能自己定义一个PlayerHealth类但我的项目里明明已经有一个RoguePlayer类了。后来我学乖了每次提问都会先用把相关文件引进来涉及战斗逻辑时引用Scripts/Features/Combat/CombatManager.cs问背包逻辑时把InventoryManager.cs和ItemData.cs拖进对话想让 AI 修 Bug 时直接引用报错堆栈里涉及的脚本和对应的报错信息。Cursor 的codebase索引也很关键。第一次用的时候它会花几分钟索引整个项目。之后我提问时只要说“在项目里找到处理敌人 AI 的文件”它就能从代码库里检索到。省下的是我手动翻目录的时间——那些时间攒起来半个月能多写两个系统。3.3 什么时候用 Tab 补全什么时候用对话生成Cursor 的 Tab 补全功能很出色但我花了一段时间才搞清楚它和对话生成的分工。Tab 补全适合“重复性的、模式已经确定的代码”——比如写一个新的ItemData定义前几个写完后面的基本结构一致这时候 Tab 补全几乎一键完成。它也适合在已有函数里补几行逻辑能让思路不被对话打断。对话生成适合“结构不确定的、需要讨论的设计型需求”。比如我想给地牢节点加事件分支自己拿不准是状态机还是直接 switch 实现这时候更适合在对话里把现有代码贴过去跟 AI 讨论方案确定后再让它写。我自己现在的节奏是能 Tab 就 Tab能小段生成就不大段对话只有需要设计决策时才用对话模式。这看起来是个很小的使用习惯但实际效率差距能达到两倍以上。4. 一个人的开发者怎么安排和 AI 协作的一天一个人做游戏的典型崩溃场景是白天上班或上课回来吃完晚饭坐到电脑前打开编辑器突然不知道今天要干嘛。刷一会儿视频改两行代码发现编译报错又不知道从何修起最后在凌晨一点陷入极度自我怀疑。AI 编程解决了一部分效率问题但解决不了“没有规划、随机开工”的问题。六期做下来我形成了一套相对稳定的三段式工作流。4.1 我的三段式工作流上午规划、下午生成、晚上审查因为我不是全职开发工作日每天只有晚上 2-3 小时能投入周末有整块时间。所以我把任务拆成两类规划型任务和执行型任务。规划型任务10-15 分钟建议放在开工前 写一个当天目标清单既不写得太空泛也不写得太具体。比如让 AI 把CombatManager里的敌人攻击逻辑重构一遍增加攻击动画回调给地牢节点增加“精英怪房间”的生成概率权重 20%修 Bug抽牌动画偶尔导致牌面渲染顺序错误。这个清单本身不需要写代码但要写到“AI 能看懂、我也知道该让 AI 干什么”的程度。执行型任务晚间 1.5-2 小时 按清单逐项和 AI 对话每完成一项就编译 运行测试确认无误后再进入下一项。如果一项超过 40 分钟还没跑通我会停下来要么重述需求要么缩小范围。这个“40 分钟红线”帮我避免了很多无效加班。审查型任务第二天早起 10-15 分钟 用 Cursor 的 Diff 视图快速翻阅前一晚 AI 生成的改动重点看注释、命名和没有被我验证到的边缘逻辑。有问题的标记留到晚上再修。4.2 用 AI 做代码审查我会重点问它三个问题一个人开发最大的问题是没有 code review。我现在会让 AI 扮演 review 角色专门挑刺。每生成一个模块我不会直接收工而是追问一句“这段代码有没有潜在的 bug如果不改以后会遇到什么问题”然后看它的回答。时间久了我发现三个问题问得最值这个脚本在对象销毁后事件回调会不会报错尤其在我的游戏里敌人死亡、玩家死亡、场景切换时最容易出空引用。这个循环在背包上百个物品时会不会卡帧单人开发的游戏性能瓶颈往往不在算法复杂度而在于频繁的查找和排序。如果两个事件在同一帧触发状态会不会不一致卡牌游戏里伤害、状态、遗物的触发顺序极其容易冲突。AI 对这些问题的判断不一定百分百准确但它能快速帮我梳理可疑点。真正的修复还是要靠我自己理解逻辑后动手但至少排查范围被大大缩小了。4.3 积累提示词笔记我给自己建了一个AI 指令弹药库这期最大的一个改变是我开始把写过的优质提示词沉淀成笔记按场景打标签背包系统-数据层.txt地牢生成-路径连接修复.txt战斗结算-稳定触发事件.txt每到新功能我先翻笔记库找到类似的提示词参考再用到新场景里。没什么高深的技巧就是把 AI 对话过程中反复调整出来的优秀提示词当成代码资产来管理。之前朋友圈里流行各种“提示词大全”说实话别人的提示词你用不上因为项目背景不同、代码风格不同、当前状态也不同。真正有用的模板一定来自你过去的成功对话。5. 六期连载之后我对一个人做游戏这件事的几个新认知写到这里必须说点不那么工具层面的体会。六期之前我觉得“一个人 AI 做游戏”是句口号现在我对这句话的理解更具体了。5.1 AI 把我从写代码的人变成了做决定的人以前写代码一小时里有一半时间是敲键盘另一半时间是在想“这个类叫什么名字”“这个方法放哪个文件”。AI 编程之后键盘时间压缩到 10 分钟以内但思考和决策时间没有减少反而变多了我应该让它写哪部分边界画在哪里它给的方案符不符合整体框架这个过程像极了带一个能力很强但完全不了解项目历史感的实习生你必须把上下文讲清楚必须能判断它建议的好坏,必须知道哪些坑要避开。当这些责任压上来的时候技术能力反而不是最稀缺的了稀缺的是“判断力”。5.2 创新的空间在取舍不在生成有很多人担心 AI 编程会让独立游戏变得同质化。我的感受是AI 生成出来的东西确实同质化——它默认给你的永远是“最大概率方案”。如果你全盘接受 AI 的默认输出、默认手感、默认数值那你确实只是在做别人做过的游戏。真正个性化、差异化的地方全在取舍敌人 AI 的巡逻逻辑我故意不做视觉检测而是用声音感知这是设计取舍卡牌数值我不让 AI 自动平衡而是按自己的节奏手调这是体验取舍UI 交互动效全手工磨不用 Cursor 生成这是观感取舍。AI 能帮你把 80% 的代码写出来但那 80% 只是基础款。最后拉开游戏差异的 20%依然需要人的判断。这话听起来像正确的废话但落到一个具体的功能决策上你就知道它有多重要了。5.3 关于一个人用 AI 做游戏的三个具体建议如果看这篇的你也有类似想法我的建议就三条第一先把技术栈固定下来再让 AI 写代码。千万别今天 Unity 明天 Godot 后天网页版AI 的上下文换一个技术栈就全作废。固定的技术栈会让你的提示词积累越来越值钱。第二每天提交一次代码哪怕只改了一行。我一个人开发最大的风险不是代码写不完而是某天 AI 帮我改了一个大模块状态全乱了回退都不知道退哪。Git 历史就是我的后悔药。第三每周至少手工写一次算法别全交给 AI。我做地牢生成时一开始让 AI 写它能写对但我看不懂。后来我花了一晚上手写了个简化版本理解了这个算法之后再让 AI 扩展效果好得多。看不懂 AI 代码不是说你不合格而是说明它正在做超出你掌控能力的事——这种情况千万要及时叫停。六期下来我最大的收获不是游戏推进了多少而是把“AI 编程”这件事从一次尝鲜变成了一套稳定可复用的工作方式。下个阶段要挑战的是引入技能树系统和更复杂的 BOSS 战机制到时候再回来记录。如果某天你也在深夜对着 AI 生成的一堆代码发呆记住一点就好AI 不会替你做决定它只是把你做决定的速度放大了很多倍。
AI编程实践：一个人做游戏，需求描述比写代码更重要
第六期了。上一期结尾我说背包系统写崩了正在调数据结构和 UI 的边界这期先把结果交代一下没崩但是经历了两次推翻重写一次是我推翻 AI 的一次是 AI 推翻我的。我做的是个卡牌构筑 轻度 Roguelike 的 2D 游戏全程一个人代码绝大部分靠 AI 编程工具生成。到现在这个阶段统计了一下我自己手敲的代码不到三成剩下七成都是 AI 写的——但这个数字一点都不值得高兴因为真正花时间的是不断跟 AI 说清楚“我要什么”。这期就把这个过程拆开聊聊为什么 AI 编程时代最卡脖子的反而变成了需求描述、项目规则和工作流的组织方式。1. 项目做到第六期的真实状态从跑得起来到有东西可玩先说项目本身。游戏暂名《余烬裂隙》核心玩法是爬塔 卡牌构筑目标平台是 PC技术栈选了 Unity 2022 LTS C#。理由很现实Unity 的 C# 语料在 AI 训练数据里极其充足不管是 Cursor 还是其他编程 AI对 Unity 相关 API 的理解都明显比对冷门引擎好。如果你打算一个人从零开始做游戏第一课就得学会选一个“AI 语料丰富”的技术栈这直接决定了后续产出的顺利程度。1.1 这 30 天里游戏里多出了哪些东西相比上一次连载游戏从“场景里能走动的方块”进化成了“勉强能玩 15 分钟的一层地牢”卡牌战斗系统抽牌、手牌、能量、格挡、抽牌堆与弃牌堆的循环逻辑目前有 18 张可用卡牌、5 个基础敌人、1 个 BOSS。地牢地图生成每层 9-12 个节点包含战斗、精英、篝火、商店、神秘事件五种类型节点之间有路径连接下一层会刷新难度。玩家状态系统生命值、金币、药水、临时增益/减益状态。背包与道具系统这期就是围绕这个展开重写的目前支持物品叠加、分类过滤、排序以及和卡牌池的联动效果。存档系统二进制序列化的本地存档能记录当前层数、卡牌收藏和已解锁内容。其中地牢生成、战斗结算这类逻辑相对独立的模块我直接用了 AI 生成初版再手工改细节。背包系统则反过来——我憋了两天没敢让 AI 碰最后决定让它写结果接连踩坑。1.2 哪些功能我敢交给 AI哪些碰都不敢碰这几周我给自己定了一个简单的评估原则如果功能出问题是“修起来容易、但定位问题难”还是“定位容易、修起来难”前者适合交给 AI。比如地牢生成算法跑出来的路径不对日志一打就看到了定位快让 AI 反复改也改不出大问题。战斗结算里的伤害计算、格挡抵扣、状态触发顺序也同理单元测试写清楚AI 改错了我能立刻发现。后者我暂时不敢放手。比如存档系统的版本兼容一旦旧档在新版本读不出来玩家数据就废了——这种错误在测试阶段不一定暴露让 AI 自由发挥是给自己埋雷。再比如涉及 UI 事件绑定的逻辑AI 特别喜欢“自动帮你把 UI 层也写了”但自动生成的界面和你的视觉效果、交互节奏很难匹配改起来比手写还痛苦。所以 UI 部分我基本自己写只让 AI 生成背后的数据接口。2. 我被 AI 逼着重新学习怎么提需求以前我总觉得写代码难现在发现把需求讲清楚比写代码难得多。这不是谦虚是被 AI 狠狠教训了几轮之后的体会。2.1 一次失败经历让 AI 写背包系统它给我套了个框架第一次让 AI 写背包我的提示词只有一句话“帮我写一个背包系统包含物品的添加、移除、叠加和 UI 显示。”AI 非常热情地生成了十几个文件ItemData、Inventory、InventoryUI、DragAndDrop、TooltipSystem……看起来结构完整、注释齐全编译也能过。但仔细一核对和我的项目完全不搭调我的物品数据用 ScriptableObject 定义它自作主张换成了 JSON 驱动我需要物品支持堆叠它实现了但堆叠上限写死成了 999我需要和卡牌系统联动获得某张卡牌时自动从背包里消耗对应道具它没做更头疼的是它把所有 UI 都在代码里 new 了一遍而我用的是 Canvas 预制体。那一刻我明白了AI 不是在编程它是在按概率续写一段“看起来像背包系统”的代码。你给它的信息越少它就越倾向于生成网上最常见的、最模板化的方案。问题在于我的项目从来就不是“最常见的方案”。2.2 从帮我写到业务背景 数据约束 输出边界我重新梳理了需求描述的方式现在我的提示词会尽量包含这些要素角色与项目背景我是一个 Unity 开发新手项目是卡牌 RoguelikeC# 脚本使用 ScriptableObject 存放物品定义现有依赖已有 InventoryManager 单例物品定义在 Scripts/Data/ItemData.cs 中UI 层用 Canvas 预制体不需要 AI 生成功能边界这次只做数据层接口不碰 UI不做存档、不做拖拽、不做右键使用约束条件堆叠上限 99物品类型包括卡牌、药水、遗物、碎片四类涉及现有类的回调事件必须列出来输出格式先给接口定义和关键方法的伪代码确认后再生成具体实现不要一次性全给。这是改进后的第二版提示词几乎把“写什么”“不写什么”“怎么写”全部框死了背景 - 项目卡牌 Roguelike《余烬裂隙》Unity 2022 LTS C# - 我使用 ScriptableObject 定义物品数据字段包括 itemId、itemName、itemType、maxStack - 已有单例 InventoryManager负责全局存取 - UI 层用 Canvas 预制体不需要你处理 任务 实现背包的数据层满足以下需求 1. 数据结构InventoryData 类内部用 ListItemStackItemStack 包含 itemData 引用和 count 字段 2. 功能AddItem 时自动叠加到同类型物品超过 maxStack 时拆成新的 ItemStackRemoveItem 指定 itemId 和数量QueryItem 返回当前持有数量 3. 事件物品变化时触发 InventoryChanged 事件参数为 itemId 和变化后的数量 4. 约束不修改现有单例之外的代码不引入第三方库不生成 UI 和存档相关代码 5. 输出先列出类结构与每个公开方法的签名我确认后再写完整实现。同样是让 AI 写背包这一版生成的代码和我项目里的现有结构严丝合缝错误率明显下降。不是 AI 变聪明了是它终于不用猜了。2.3 给 AI 提供边界条件比描述功能清单更重要功能清单说的是“要做什么”边界条件说的是“不能做什么、只能做什么”。AI 生成代码时尤其依赖后者。一个很典型的例子自动化测试。我让 AI 写“AddItem 在背包满时应该给人提示”它默认直接往 UI 层塞弹窗。我加了一句“背包满时打印警告日志不操作 UIUI 层由我自己监听 InventoryChanged 事件处理”它立马换成纯逻辑实现和我的架构对上了。另一个例子是命名。我的代码风格是私有字段用下划线开头、public 字段全部用 [SerializeField] 暴露、不使用 public 字段。AI 默认生成的风格是public int count;。经过我的规则文件约束后生成结果才符合我的习惯。这件事让我意识到AI 编程的提示词本质上是在给一个“能力很强但会自由发挥的外部开发者写需求文档”。你要求得越具体它的发挥空间越小产出反而越可控。3. Cursor 的几个关键设置把 AI 从聊天机器人变成结对程序员我主力用的工具是 Cursor里面挂的是 Claude 系列模型。说实话作为一个长期用 VSCode 的人Cursor 的上手成本几乎为零但用好它和随便用它差距极其明显。3.1 项目级规则文件让 AI 记住你的代码风格Cursor 支持项目级规则文件通常叫.cursorrules。这是我从踩坑里学到的“最值回票价”的设置。第一周我完全忽略了这个文件于是每次对话都要重新解释一遍项目背景AI 风格飘忽不定后来我花了半小时把规则文件写出来之后所有生成代码的风格就稳定了。我的.cursorrules内容大概长这样# 项目信息 项目:《余烬裂隙》卡牌 RoguelikeUnity 2022 LTS C# # 代码风格 - 私有字段统一使用 _camelCase 前缀 - 需要暴露给 Unity Inspector 的字段使用 [SerializeField] private不使用 public 字段 - 事件使用 C# event不使用 UnityEvent - 不加魔法数字超过一次使用的常量提取到 readonly 或 const - 日志使用 Debug.Log注释说明为什么而非是什么 # 目录约束 - 新增代码放在 Scripts/Features/功能名/ 目录 - 不要修改 Scripts/Core/ 目录下的代码除非我明确要求 # 输出约束 - 生成的代码必须可以直接放入 Unity 项目并编译通过 - 先给出核心类和接口概览再给出完整实现 - 尽量不要生成 UI 代码除非我特别要求这套规则文件让我在后续开发里少吵了很多架。AI 第一版生成出来的代码代码风格已经和我的项目高度一致手工改动量大幅下降。3.2 用 符号引用真实代码别让 AI 凭空想象另一个效率黑洞是AI 并不了解你的项目结构除非你主动告诉它。以前我让 AI 写“角色受到攻击掉血”它可能自己定义一个PlayerHealth类但我的项目里明明已经有一个RoguePlayer类了。后来我学乖了每次提问都会先用把相关文件引进来涉及战斗逻辑时引用Scripts/Features/Combat/CombatManager.cs问背包逻辑时把InventoryManager.cs和ItemData.cs拖进对话想让 AI 修 Bug 时直接引用报错堆栈里涉及的脚本和对应的报错信息。Cursor 的codebase索引也很关键。第一次用的时候它会花几分钟索引整个项目。之后我提问时只要说“在项目里找到处理敌人 AI 的文件”它就能从代码库里检索到。省下的是我手动翻目录的时间——那些时间攒起来半个月能多写两个系统。3.3 什么时候用 Tab 补全什么时候用对话生成Cursor 的 Tab 补全功能很出色但我花了一段时间才搞清楚它和对话生成的分工。Tab 补全适合“重复性的、模式已经确定的代码”——比如写一个新的ItemData定义前几个写完后面的基本结构一致这时候 Tab 补全几乎一键完成。它也适合在已有函数里补几行逻辑能让思路不被对话打断。对话生成适合“结构不确定的、需要讨论的设计型需求”。比如我想给地牢节点加事件分支自己拿不准是状态机还是直接 switch 实现这时候更适合在对话里把现有代码贴过去跟 AI 讨论方案确定后再让它写。我自己现在的节奏是能 Tab 就 Tab能小段生成就不大段对话只有需要设计决策时才用对话模式。这看起来是个很小的使用习惯但实际效率差距能达到两倍以上。4. 一个人的开发者怎么安排和 AI 协作的一天一个人做游戏的典型崩溃场景是白天上班或上课回来吃完晚饭坐到电脑前打开编辑器突然不知道今天要干嘛。刷一会儿视频改两行代码发现编译报错又不知道从何修起最后在凌晨一点陷入极度自我怀疑。AI 编程解决了一部分效率问题但解决不了“没有规划、随机开工”的问题。六期做下来我形成了一套相对稳定的三段式工作流。4.1 我的三段式工作流上午规划、下午生成、晚上审查因为我不是全职开发工作日每天只有晚上 2-3 小时能投入周末有整块时间。所以我把任务拆成两类规划型任务和执行型任务。规划型任务10-15 分钟建议放在开工前 写一个当天目标清单既不写得太空泛也不写得太具体。比如让 AI 把CombatManager里的敌人攻击逻辑重构一遍增加攻击动画回调给地牢节点增加“精英怪房间”的生成概率权重 20%修 Bug抽牌动画偶尔导致牌面渲染顺序错误。这个清单本身不需要写代码但要写到“AI 能看懂、我也知道该让 AI 干什么”的程度。执行型任务晚间 1.5-2 小时 按清单逐项和 AI 对话每完成一项就编译 运行测试确认无误后再进入下一项。如果一项超过 40 分钟还没跑通我会停下来要么重述需求要么缩小范围。这个“40 分钟红线”帮我避免了很多无效加班。审查型任务第二天早起 10-15 分钟 用 Cursor 的 Diff 视图快速翻阅前一晚 AI 生成的改动重点看注释、命名和没有被我验证到的边缘逻辑。有问题的标记留到晚上再修。4.2 用 AI 做代码审查我会重点问它三个问题一个人开发最大的问题是没有 code review。我现在会让 AI 扮演 review 角色专门挑刺。每生成一个模块我不会直接收工而是追问一句“这段代码有没有潜在的 bug如果不改以后会遇到什么问题”然后看它的回答。时间久了我发现三个问题问得最值这个脚本在对象销毁后事件回调会不会报错尤其在我的游戏里敌人死亡、玩家死亡、场景切换时最容易出空引用。这个循环在背包上百个物品时会不会卡帧单人开发的游戏性能瓶颈往往不在算法复杂度而在于频繁的查找和排序。如果两个事件在同一帧触发状态会不会不一致卡牌游戏里伤害、状态、遗物的触发顺序极其容易冲突。AI 对这些问题的判断不一定百分百准确但它能快速帮我梳理可疑点。真正的修复还是要靠我自己理解逻辑后动手但至少排查范围被大大缩小了。4.3 积累提示词笔记我给自己建了一个AI 指令弹药库这期最大的一个改变是我开始把写过的优质提示词沉淀成笔记按场景打标签背包系统-数据层.txt地牢生成-路径连接修复.txt战斗结算-稳定触发事件.txt每到新功能我先翻笔记库找到类似的提示词参考再用到新场景里。没什么高深的技巧就是把 AI 对话过程中反复调整出来的优秀提示词当成代码资产来管理。之前朋友圈里流行各种“提示词大全”说实话别人的提示词你用不上因为项目背景不同、代码风格不同、当前状态也不同。真正有用的模板一定来自你过去的成功对话。5. 六期连载之后我对一个人做游戏这件事的几个新认知写到这里必须说点不那么工具层面的体会。六期之前我觉得“一个人 AI 做游戏”是句口号现在我对这句话的理解更具体了。5.1 AI 把我从写代码的人变成了做决定的人以前写代码一小时里有一半时间是敲键盘另一半时间是在想“这个类叫什么名字”“这个方法放哪个文件”。AI 编程之后键盘时间压缩到 10 分钟以内但思考和决策时间没有减少反而变多了我应该让它写哪部分边界画在哪里它给的方案符不符合整体框架这个过程像极了带一个能力很强但完全不了解项目历史感的实习生你必须把上下文讲清楚必须能判断它建议的好坏,必须知道哪些坑要避开。当这些责任压上来的时候技术能力反而不是最稀缺的了稀缺的是“判断力”。5.2 创新的空间在取舍不在生成有很多人担心 AI 编程会让独立游戏变得同质化。我的感受是AI 生成出来的东西确实同质化——它默认给你的永远是“最大概率方案”。如果你全盘接受 AI 的默认输出、默认手感、默认数值那你确实只是在做别人做过的游戏。真正个性化、差异化的地方全在取舍敌人 AI 的巡逻逻辑我故意不做视觉检测而是用声音感知这是设计取舍卡牌数值我不让 AI 自动平衡而是按自己的节奏手调这是体验取舍UI 交互动效全手工磨不用 Cursor 生成这是观感取舍。AI 能帮你把 80% 的代码写出来但那 80% 只是基础款。最后拉开游戏差异的 20%依然需要人的判断。这话听起来像正确的废话但落到一个具体的功能决策上你就知道它有多重要了。5.3 关于一个人用 AI 做游戏的三个具体建议如果看这篇的你也有类似想法我的建议就三条第一先把技术栈固定下来再让 AI 写代码。千万别今天 Unity 明天 Godot 后天网页版AI 的上下文换一个技术栈就全作废。固定的技术栈会让你的提示词积累越来越值钱。第二每天提交一次代码哪怕只改了一行。我一个人开发最大的风险不是代码写不完而是某天 AI 帮我改了一个大模块状态全乱了回退都不知道退哪。Git 历史就是我的后悔药。第三每周至少手工写一次算法别全交给 AI。我做地牢生成时一开始让 AI 写它能写对但我看不懂。后来我花了一晚上手写了个简化版本理解了这个算法之后再让 AI 扩展效果好得多。看不懂 AI 代码不是说你不合格而是说明它正在做超出你掌控能力的事——这种情况千万要及时叫停。六期下来我最大的收获不是游戏推进了多少而是把“AI 编程”这件事从一次尝鲜变成了一套稳定可复用的工作方式。下个阶段要挑战的是引入技能树系统和更复杂的 BOSS 战机制到时候再回来记录。如果某天你也在深夜对着 AI 生成的一堆代码发呆记住一点就好AI 不会替你做决定它只是把你做决定的速度放大了很多倍。 
