1. 第七周的项目快照游戏没做完但终于敢给别人看了先说结论这是我用 AI 编程做独立游戏的第七周游戏还没有做完但已经能跑通一个完整的 demo 循环标题界面 → 选人 → 进关卡 → 打三波怪 → BOSS 战 → 结算 → 回到标题。画风还是那个丑萌的像素风代码量大概在 8500 行左右其中我手写的大概只有四成剩下的都是 AI 生成的——但我要强调的是AI 写代码这件事真正的难点从来不是让它写出代码而是让它别把代码写得让你后面没法改。这个系列前面几篇我聊过怎么选 AI 编程工具、怎么设计提示词、怎么让 AI 理解游戏的整体架构。这篇我想换个角度专门讲讲当项目从跑得起来走向玩得下去时你会遇到的那些破事。因为前六篇如果你照做了这时候你的处境应该和我一样游戏能玩但帧率忽高忽低内存像漏水的水桶同一个 UI 界面改了三遍还是不满意AI 修改一个 bug 的结果往往是引入两个新 bug。这期内容我打算用我自己的项目当解剖对象聊聊中途接手自己一个乱糟糟的代码库、用 AI 做性能优化、以及在AI 效率极高和AI 失控瞎改之间来回横跳的完整经历。不管你是准备用 AI 做游戏、做工具还是做网站这篇里的排查思路和踩坑清单应该都通用。先交代一下项目背景。我做的是一款 2D 像素风的轻量 Rogue 弹幕游戏玩法核心是躲弹幕 三选一强化给玩家的目标是一局控制在 15 分钟内。按照我的规划这类游戏是最适合一个人 AI 来做的类型美术素材可以用现成像素包玩法逻辑不复杂但足够有深度性能瓶颈非常明确弹幕数量、对象池、GC 分配每一项都特别适合让 AI 帮忙。但正是在这个阶段暴露出的问题让我意识到AI 编程项目的先甜后苦期到了。前几周 AI 生成代码的速度让我产生了一个人顶一个工作室的错觉第七周则是这种错觉破产、回归冷静的一周。所以这篇文章的标题叫AI 编程来了我决定一个人做一款游戏07——不是因为我终于做完了而是因为我终于开始理解AI 编程时代一个人做游戏真正的核心竞争力变成了什么。2. 亲手给自己埋的雷AI 生成的代码攒够 5000 行之后开始互相打架先说一个可能让你意外的事实AI 编程的第六周和第七周是完全不同的体验。第六周之前AI 就像一个 everything expert你问什么它答什么一整块功能从零实现几十行、几百行跑起来几乎没问题。到了第七周项目代码量上来之后AI 开始频繁翻车而且翻车方式极其统一——不知道项目其他地方长什么样于是在修改 A 模块时破坏了 B 模块或者在生成新功能时根本没有和已有系统对齐。这事儿的根源我得从人的角度先说透。一个人用 AI 做项目最危险的心理是代码不是我写的所以我不需要完全理解它。前几周我确实偷懒了AI 生成一大段代码后我跑通测试就满意地收工了根本没有认真读每一行。于是到第七周代码库的心智模型只有 AI 有我只有大概的印象——这就是一个巨大的坑。2.1 症状清单当 AI 代码库开始失控我先整理一下这个阶段的典型症状你如果也走到这一步应该会感到熟悉症状一反复出现的灵异 bug。某个敌人的子弹明明只在关卡 2 出现却在主菜单界面偶尔闪出来一帧。查了半天发现是 AI 早前生成一个全局限时管理器时把子弹池的初始化逻辑写得过度全局化结果所有场景都共享了它。症状二改一处崩三处。我让 AI 加一个拾取金币飘字效果它很听话地在 HUD 里加了一个飘字组件结果进入结算界面就报空引用。原因结算界面的 HUD 初始化顺序和主界面不同飘字组件在它引用的 UI 画布加载之前就被实例化了。症状三AI 开始遗忘以前的约定。项目的输入系统我早就统一成Config 配置按键 → InputManager 读取但 AI 为了省事在新生成的技能系统里直接写了Input.GetKeyDown(KeyCode.Space)。单看这一处没问题可我在把技能系统改成支持手柄时就蒙了因为硬编码按键完全绕开了我设计的输入映射层。症状四代码量膨胀到难以理解。有一回我让 AI 帮我重构一个敌人波次生成器它没有简化逻辑反而生成了一个 800 行的波次配置解释器读起来比原来的 200 行还难懂而且运行效率更差。2.2 病根排查AI 的局部最优和上下文窗口限制这些症状说到底根子在两点。第一AI 本质上是局部最优的生成器。它每次生成一个函数都倾向于在当前上下文范围内做最合理的实现但它并不知道全局架构你的系统里还有别的什么模块。如果你不提供全局信息它就会默认使用它的常识来填空——而这恰恰会破坏你项目早就定下的约定。第二上下文窗口限制。目前市面主流的 AI 编程助手单次能看到的代码上下文通常是整个文件少数能跨文件检索但它们毕竟不是人无法像你一样把项目几千个文件之间的关系烂熟于心。所以当你让它改一下那个 BOSS 的 AI 脚本时它可能只看得到 BOSS 的 AI 脚本根本不知道你的伤害数值系统里面有一套受伤无敌帧的逻辑。结果它把 BOSS 的受伤反应改完之后无敌帧失效玩家一碰到 BOSS 就掉血飞到屏幕外。2.3 对症下药给 AI 立全局规矩的确切做法发现问题以后我做的第一件事不是继续干活而是花了两天时间做了一件事给 AI 立规矩。具体操作如下你可以直接照抄。第一步我建立了一个GLOBAL_RULES.md放在项目根目录下然后在每个让 AI 执行任务的提示词开头都让 AI 先读这个文件。文件里写的内容包含项目的整体模块划分哪个目录管什么编码规范命名风格、接口约定、文件大小上限禁止做的事清单例如禁止硬编码输入、禁止在游戏逻辑脚本里直接操作 UI 对象、禁止在 Update 里分配新对象、禁止修改与本次需求无关的文件第二步要求 AI 在每次改动之前先用文字解释自己的方案说得通才允许动手。我之前太着急总让它直接改现在强制它先写方案再说。这条看起来费时间实际上省下的返工时间远多于多花的这点时间。第三步改到什么程度可以停必须定义清楚。我的规则是所有改动必须保持单一职责AI 不能在修 bug 的时候顺手优化了整个模块的代码风格。风格统一这件事可以之后专门开一个任务做混在一次改动里出问题都查不清是谁的责任。这一步很关键我们单独拿出来继续说。我平时在正常工作里也带过几个人我发现让 AI 和我带过的高级工程师有不少惊人的相似之处能力很强但正常发挥需要清晰的上下文、明确的范围限定、还有对全局架构的了解。这不纯粹是技术问题更是管理问题。个人经验给 AI 立规矩这件事越早做越好。我是在代码量到 5000 行才做晚了。如果你刚开始用 AI 写项目第一周就建GLOBAL_RULES.md后面至少能少走一半弯路。3. 用 AI 做性能优化一次手术式的 Unity 帧率排查实战第七周最重要的事情是给游戏做了一次系统性的性能体检。在这之前游戏在单位台式机AMD Ryzen 5 GTX 1660上能跑到 60 帧但一进弹幕密集的 BOSS 战就掉到 30 帧。更难看的是小内存机器上每 30 秒会卡顿一下那个卡顿的时间点非常规律跟弹幕密度无关就是纯粹的资源抖动。对独立开发者的游戏来说帧率不稳比平均帧率低更致命——玩家可以接受 45 帧恒定但绝对不能忍受 60→30→60 来回跳。因为帧时间波动直接反映到手感上而动作游戏的手感是命根子。3.1 第一步先量化再优化我一上来没有急着让 AI 改代码而是先给它一份性能报告的数据。Unity 的 Profiler 是我用的主要工具在Window Analysis Profiler打开然后在 BOSS 战场景中跑 3 分钟采集帧时间、CPU 耗时、GC 分配三个指标。不量化就没有优化的依据。如果你直接跟 AI 说帮我优化性能它给你的建议十有八九是洗稿级别的用对象池、合并 Draw Call、压缩贴图——这些泛泛之谈确实没毛病但解决不了你的具体问题。让数据说话之后我得到了一份比较详细的问题清单指标优化前数值问题粗略定位帧时间均值34ms约 29 FPS主要卡在 BOSS 弹幕施放逻辑帧时间峰值89ms大量瞬时的 GC Alloc平均 GC 分配每帧约 2.3MB弹幕发射器在 Update 里创建临时对象Draw Call 数量约 287每个子弹都是独立 SpriteRenderer内存峰值约 890MB加载了 16 个关卡场景从不卸载这份数据打给 AI它的分析就完全不一样了。它不再给泛泛的优化建议而是直接指出GC 分配每帧 2.3MB 是最大的性能杀手单帧 89ms 的尖刺就是 GC 收集引起的Draw Call 287 是另一个瓶颈但优先级略低内存峰值高是因为场景没有做按需卸载。3.2 第二步解决子弹海啸——对象池 缓存我按照优先级先从 GC Alloc 和弹幕对象池着手。我的弹幕系统一秒要发射 80~120 颗子弹每颗子弹都是一个EnemyBullet对象里面有 transform、sprite renderer、移动速度属性。优化前每发射一颗子弹就new一个对象子弹销毁时还要标记Destroy然后等 Unity 的卸载机制来收拾它。这里的高效做法是对象池。我把创建子弹的逻辑统一改成预创建 300 个EnemyBullet实例放进池子发射时不new而是从池子中取一个激活子弹出屏或碰撞后用SetActive(false)归还具体的代码如下这套代码是我让 AI 根据项目现有弹幕系统重构的但我在关键位置做了检查和微调确保它真能用public class BulletPool : MonoBehaviour { public GameObject bulletPrefab; public int poolSize 300; private QueueGameObject pool new QueueGameObject(); void Awake() { for (int i 0; i poolSize; i) { GameObject bullet Instantiate(bulletPrefab); bullet.SetActive(false); pool.Enqueue(bullet); } } public GameObject GetBullet(Vector3 position, Quaternion rotation) { if (pool.Count 0) { // 池子不够用临时扩容。实际开发中最好在 Loading 阶段就设好峰值。 GameObject extra Instantiate(bulletPrefab); pool.Enqueue(extra); } GameObject b pool.Dequeue(); b.transform.position position; b.transform.rotation rotation; b.SetActive(true); return b; } public void ReturnBullet(GameObject bullet) { bullet.SetActive(false); pool.Enqueue(bullet); } }千万别小看这几行它是 AI 最常写错的一个逻辑点。AI 默认的写法经常在GetBullet方法里Instantiate新的子弹、在ReturnBullet里写Destroy那就是一个披着对象池外衣的普通子弹生成器——没有任何优化效果。所以这个代码我验收时专门多看了两遍。另一个重要问题是如果池子里子弹不够怎么办我一开始设为 300但测到最高难度 BOSS 战时峰值一口气生成 450 颗子弹池子不够导致临时 Instantiate又出现了卡顿。所以最终我把池子预生成调到 600并且额外写了一段预警逻辑如果某次取用后剩余池中对象少于 10%就打印一条日志提醒后续要不要再加。3.3 第三步让 AI 重构子弹移动的 Update 循环对象池解决了对象创建的 GC 问题但还有一个问题每颗子弹自己的移动逻辑是在各自的Update()里做的。600 个子弹就有 600 个Update()调用虽然每帧加起来时间不长但 Unity 的MonoBehaviour.Update()调度成本会随着对象数量线性增长累计起来不可忽视。我让 AI 把这个移动逻辑重构成一个统一的BulletMovementManager用把子弹的 Transform 缓存到数组里在 Manager 的 Update 里统一遍历移动的方式。类似数据导向设计的思想把分散的逻辑集中管理。重构之后的效果同一场景下再跑 Profiler指标优化前优化后下降幅度平均 GC 分配每帧 2.3MB每帧 90KB96%帧时间均值34ms17ms50%Draw Call后文解决287146贴图合并后49%帧时间峰值89ms28ms68%数据明显向好了。但别着急高兴紧接着我发现原生问题解决之后新的瓶颈暴露出来了——Draw Call。这也印证了性能调优那条老路永远不会只改一处就万事大吉优化完 AB 就会变成主要矛盾。3.4 第四步动态合并 UI 和子弹的渲染批次UI 的优化其实不复杂。我的项目里 UI 元素非常多每个Image、Text都是一个独立的渲染单元如果字体的 atlas 分散或者 UI 上有大量需要频繁更新的文本合批会非常困难。我把所有 UI 做了三件事减少不必要的 Raycast Target给所有纯展示用的 Text 和 Image 关掉 Raycast Target。这样鼠标和触摸检测的命中测试就不用扫描这些对象省下不少 CPU。控画布重构频率UI 上如果每帧都有文本变化比如分数、血量这个 UI Canvas 就会每帧做一次重构。我把分数从每帧更新改成只在数值变化时更新直接在Text.text的 setter 入口判断如果值没变就跳过赋值。缩小 UI atlas一顿裁剪之后所有 UI 共用一张图集减少纹理切换的次数。至于场景中大量的子弹精灵方案其实是合并动态批次。思路是让同一种贴图的子弹尽量连续渲染避免频繁切换材质。我在子弹池的排序逻辑里做了一点小优化比如让所有同种子弹在数组里排在一起发射时也按类型批次取用。这个改动配合 Sprite Atlas 图集直接让 Draw Call 从 287 掉到 146。另外场景内存的问题我也顺手处理了Unity 的SceneManager.LoadScene默认把旧场景直接卸载但如果你用 Additive 方式加载或者有全局 DontDestroyOnLoad 对象没管好内存就会越涨越高。我审查后发现老版的关卡波次配置数据全都被我设成了static字段每进一关就在 static 列表里追加一份配置从不清理。这会直接导致内存随着游戏局数增长一局还好三局下来就逼近 1GB。修复方式在关卡开始时清空静态配置缓存只保留当前关卡的引用。3.5 性能优化的核心心得这一段优化做下来我对用 AI 做性能调优的体会是AI 是很好的执行者但你要当好架构师和验收者。性能问题本质上是数据问题你需要先通过 Profiler 定位出哪个数据不对GC、DrawCall、内存峰值然后让 AI 针对这个明确的数据动手。它不会自动发现每帧 2.3MB GC 分配来自子弹创建——它没有读你的全部代码更没法像人一样做全局判断。所以我的工作流变成拿 Profiler 数据 → 自己分析瓶颈归属 → 给 AI 明确的修改指令 → 跑 Profiler 验证 → 有提升则接受没提升则继续挖数据。这套流程和传统开发没有本质区别关键是 AI 能把从指令到修改的速度提高好几倍让你能在一个晚上迭代三轮优化方案。4. 越补越多的AI 修 bug循环我的排查链路与防退坡机制前面讲性能优化是一切顺利时的节奏。这一章我要讲讲最折磨人的事AI 改 bug改着改着把原本稳定的系统改崩了。这个环节里踩的坑我希望能帮你省下至少两天的无头绪时间。4.1 一次典型AI 连环翻车事件复盘我的技能系统里有一个很简单的需求玩家按 Q 键释放一个短距离冲刺冲刺时获得无敌帧持续 0.4 秒。这个功能两周前就做好了一直没出问题。第七周我想加一个冲刺后 1 秒内近战伤害 30%的 buff于是让 AI 改技能系统的代码。AI 的改动方案是读到了冲刺技能脚本在释放冲刺的方法里加了一个buffMgr.AddBuff(BuffType.Strength, 1f, 0.3f)调用。从局部逻辑看它没错。但我没想到的是这行代码直接让玩家的冲刺动作在 0.4 秒无敌帧期间多了一个力量 buff而力量 buff的实现逻辑里又读取了玩家的基础攻击力基础攻击力在冲刺状态下恰好被另一个 AI 早前写的 冲刺姿态改变攻击力回退 的脚本设置为 0于是玩家冲刺完 1 秒内的攻击力变成了 0伤害反而变低了。我刚开始完全没料到这个结果。第一次测试冲刺后平 A伤害从 12 变成 0我以为是自己手滑没打中。第二次测试还是 0我才意识到是 AI 改动引发了连锁反应。这个 bug 的排查过程极其痛苦因为断裂的链条跨越了四个文件技能释放脚本、buff 系统、属性系统、角色姿态系统。传统 IDE 里根本没法一眼看出它们的关联。我花了一个多小时逐文件读代码才最终定位到根源AI 加的那行代码没有做防御性检查也没有遵循获取当前实际攻击力应该走属性系统统一接口这个项目规则。4.2 排查链路从现象到根因的四步法我把这轮排查总结成了四步现在每次让 AI 改完代码、测试挂了我就按这套流程走效率高多了第一步复现并锁定触发条件。不要凭感觉改代码先把什么操作、什么状态、什么次序下会触发 bug记录清楚。我建了一个0_bug_repro.md文件每发现一个新 bug 就把复现步骤写进去。很多 bug 的触发条件是你没料到的写下来之后才能让 AI 也快速定位。第二步用版本控制快速定位改动范围。我每次让 AI 改完代码都会把改动单独提交到一个分支上分支名就叫feat/buff-attack-percent然后核心分支保持稳定。如果新改动一出问题我直接git diff看这个分支的改动比从头梳理代码快几个数量级。这一步极度关键——AI 改代码经常偷偷改到无关文件版本控制能让你立刻发现。第三步让 AI 解释自己的改动并追问接口约束。当 bug 定位到某个改动时把改动片段贴给 AI然后问它你这次改动依赖了哪些现有接口这些接口在什么情况下可能返回非预期值 这一步常常能直接让 AI 自己发现自己违规了。第四步在 AI 的修复之上加防退坡测试。修复 bug 后一定不要只验证能跑还要写一个最小化的单元测试或集成测试。哪怕只是一个极简的 sanity check冲刺后攻击力不应为 0。这样以后再有 AI 代码改动测出回归时你能立即发现。我称为防退坡测试——防止 AI 每次修改都把项目往坡下推一点最终把游戏改回一个不可玩的烂摊子。下面是这套流程可视化的关键节点我画图功力有限你能看懂就行发现 bug 现象 ↓ 记录复现步骤写进 0_bug_repro.md ↓ git diff 查看最新改动范围 ↓ 把改动片段贴给 AI让它解释依赖关系 ↓ 定位根因通常是接口约束或全局规则被破坏 ↓ 修复 写防退坡测试 ↓ 回归验证更新文档4.3 为什么 AI 最容易在这里翻车以及如何预防AI 修 bug 容易翻车的原因其实可以总结成一句话它默认改动是局部的而游戏代码天然是全局耦合的。任何牵一发而动全身的系统——属性、Buff、状态机、输入映射、UI 事件AI 改起来都容易出问题。预防方式我目前验证有效的有三个一是强制 AI 在改动前做依赖分析。我要求 AI 在提示词里回答一个问题你这次改动会影响哪些其他系统影响面是否可以控制在当前模块内 如果它不能明确回答就别让它动手。这一条可能让 AI 的回答速度变慢但正确率大幅提升。二是把高风险模块设计成窄接口。比如 Buff 系统我把它封装成只提供AddBuff(BuffType, duration, magnitude)这样一个入口内部逻辑不许外部直接访问。这样 AI 如果要调用 buff 系统只能走这个窄接口不容易意外耦合到内部状态。这和写后端服务的思路完全一样——降低模块间耦合AI 就不容易踩雷。三是永远保留一个能回滚的稳定分支。只要 AI 改动导致测试失败立刻把主分支切回上一版别跟 AI 在错误的代码上反复拉扯。很多时候我们就是太想修好这个错误却忘了直接把改动 revert 掉、重新换个提示词让 AI 生成反而更快。实战心得让 AI 修改问题的成本往往低于让它接着刚才的思路修复问题。如果一次改动失败我会立刻重置会话、换个思路重来而不是在同一个错误方案上继续要求修好它。因为 AI 在同一个会话里往往会固执地延续自己的方案而不自知。5. 提示词从写功能切换到填坑模式几种高价值提示词模板既然已经聊到 AI 怎么改 bug这一节就把我第七周摸索出来的几种填坑模式提示词分享给你。这和最初帮我实现一个功能的提示词完全是两种生物如果你还在用 Last 方式指挥 AI你很快就会遇到AI 越修越乱的崩溃感。5.1 面向现有代码做改动时的提示词结构先说底层逻辑AI 在已有代码上做改动时最关键的信息不是你想要什么效果而是你不知道但它必须知道的全局信息。所以我会把提示词拆成四段【任务】 修改文件Assets/Scripts/SkillSystem/DashSkill.cs 需求玩家使用冲刺后 0.4 秒无敌同时获得 1 秒的 30% 伤害加成 buff。 【项目规则强制阅读 GLOBAL_RULES.md】 - 所有战斗数值必须通过 AttributeSystem 统一获取和修改禁止直接操作 raw 字段。 - Buff 系统只能通过 BuffManager.AddBuff(BuffType type, float duration, float magnitude) 调用。 - 禁止修改与本任务无关的文件。 【你目前的计划先回答不要动手】 请说明 1. 你打算改哪几个文件各改什么 2. 这些改动会影响哪些现有系统是否有潜在风险 3. 你的方案如何保证不破坏冲刺无敌帧逻辑 【验证方式】 改完后执行 Unity Test Runner 里的 DashBuffSmokeTest确认冲刺后的平 A 伤害为 15.612 * 1.3。这段提示词有三个关键点。第一让 AI 先说计划再动手这能帮你在早期阶段就发现它打算跑偏的方向及时叫停。第二明确告诉它不能碰哪些文件杜绝 AI 擅自重构。第三给出明确的数值验证目标让 AI 自己判断改得对不对而不是靠你肉眼测试。5.2 专门用来排查的提示词模板当 bug 已经出现、但我不知道根因在哪时我用的提示词是这样的我在跑游戏时发现一个 bug 复现步骤 1. 进入第二关 2. 击杀第一个精英怪 3. 打开背包快捷键 I 4. 游戏报空引用错误NullReferenceException: Object reference not set to an instance of an object 报错堆栈已附在下面。 请根据堆栈和项目代码做根因分析 - 不急着给修复方案 - 先列出最可能的原因、次要可能原因、每一类原因的排查方法 - 要求你检查这个报错是否与最近的 5 次 git 提交有关 - 分析过程中如果需要查看其他文件请先列出文件名再继续这个模板的价值在于强制 AI 做根因分析而不是直接给修复。很多 AI 助手收到报错了帮我修就会立刻给一个局部补丁。但它可能完全没看堆栈、没看上下文补丁只是缓解了症状根因还在原地。所以我把先分析后修复写死了效果显著。5.3 专门用来重构的提示词模板第七周我还做了一次大重构把原来散落在各个脚本里的敌人 AI按状态机模式统一重写。给 AI 的重构类提示词需要额外强调保持行为不变。重构目标把 EnemyAIController.cs 里的 switch-case 敌人 AI 改为状态机模式。 约束 1. 行为必须完全等价。现在的 idel → chase → attack → hurt → die 流程不能变。 2. 不允许改变对外的公共方法名和字段名其他脚本依赖它们。 3. 重构后必须保证单测 EnemiesAITests 全部通过。 4. 不要顺手改其他文件。 下面是当前文件的全文 [贴代码] 请先分析状态划分是否合理如果有更优方案先说建议我再决定要不要调整。重构类任务的关键是等价性验证。让 AI 重构完你必须快速跑一遍原有的所有测试没有测试的话至少手动过一遍原有功能。我在这一阶段吃过一次大亏AI 重构完敌人生成器所有敌人类型都正常唯独精英怪死后不掉落了查了半天才发现重构时把掉落表的初始化放错了位置。防退坡测试如果当时有就不至于花两小时定位。5.4 AI 不知道的上下文你得喂给它最后必须强调AI 的上下文窗口是有限的。哪怕这个 AI 号称项目级上下文它一次能看的文件数量还是有限制的。所以当你要改一个高耦合模块时请把关联的接口定义或者关键函数签名贴给它而不是指望它自己搜。我的习惯是提问时直接附上这几样项目根目录GLOBAL_RULES.md的全文或关键段落所涉及模块的接口定义比如 AttributeSystem 的公开方法列表最近一次 git 提交的 diff让 AI 知道别人改了什么这条习惯让我的 AI 出错率下降得非常明显。6. 当 AI 从一个写码工具变成一个结对编程搭档第七周的收获与反思到了第七周我对 AI 编程的理解已经发生了很大的变化。差不多可以总结一下这个阶段真正的收获。6.1 从让 AI 干活到和 AI 一起做决策过去我做功能时是我提需求 → AI 生成代码 → 我测试验收。到了性能优化和 bug 修复阶段这个模式行不通了。因为很多问题你不能简单描述你得先分析数据、定位问题、想清楚方案然后才轮得到让 AI 执行。换句话说AI 编程的瓶颈不再在写代码那个环节而是在懂系统和做决策的环节。而这恰恰是人的价值所在。同样是改一个 BOSS 弹幕生成器AI 可以生成得很漂亮但是要不要引入对象池对象池的初始大小设多少弹幕的 Move 逻辑应不应该抽离这些设计决策AI 做不了——AB 测试的成本太高了只有你能拍板。这种分工的感觉有点像带了一个非常聪明但缺乏经验的实习生。你要把事情拆解成足够小的步骤给它它就能执行得飞快但如果你自己都没有全局思考清楚就抛给它它就会在错误的方向上疯狂输出然后浪费你更多的返工时间。6.2 一个人 AI 做游戏里程碑式的标记变得更重要独立开发者一个人做太容易迷失方向了有了 AI 之后这个风险更严重。因为 AI 一天就能生成一千行代码但其中真正有游戏性的验证还是需要你亲手玩、亲手调。在这周里我给自己建立了一个每天可玩的版本机制每天结束前主分支必须处于一个完整可玩的状态——哪怕只有一关哪怕只有 5 分钟的游戏内容。这不是为了给别人 demo而是为了让自己始终有完整体验的基准线。如果哪天 AI 改崩了即使当前任务没完成也要先回滚到上一个可玩版本。这个机制在 AI 编程时代尤其重要因为 AI 改崩的几率比你想象的高如果你不锁定可玩这条底线你会陷入一整个礼拜都在修一堆半成品功能的泥潭。6.3 给新手的一个建议别急着冲功能先冲稳定如果你正在用 AI 做项目我给你的第七周建议是在这个阶段稳定性的优先级应该高于新功能。相比于再加一个 Boss、再加一个道具更值得做的是把核心玩法的性能优化到流畅给关键系统写一套防退坡测试完整跑通一次从开始到通关的流程把 BUG 清单削到个位数把 GLOBAL_RULES.md 写得足够详细让 AI 后续只干活、不添乱这些基础工作听起来不酷炫也没有新功能那么让人开心。但它们才是从 Demo 走向可发布游戏最核心的一步。没有稳定性和性能底子功能越多游戏越像一栋地基不牢的危楼AI 每往上盖一层你睡得就越不安稳。就拿我自己的项目来说如果没有第七周的性能优化和规则治理第八周我其实可以再做 3 个新 Boss。但那些 Boss 可能在 60 帧的桌面上流畅在玩家入门级显卡上就变成 PPT。做游戏这行永远不是我做了多少内容算数而是玩家实际体验到多少内容才算数。如果让我总结第七周的一条核心经验那就是AI 可以把你的生产力放大十倍但同时它也能以同样的倍数放大你架构混乱的风险。代码是自己的架构更是自己的。AI 永远不会替你背这个锅。7. 给同样在用 AI 做项目的你一次真实的周复盘这周的结尾按照惯例分享一下项目整体的进度和一些个人反思。不算完整复盘更像是随手写的工作日记希望能给同行一些参照。7.1 本周完成清单核心功能完成了冲刺 Buff 联动和两个新敌人追踪弹型、散弹型性能优化完成对象池重构、Draw Call 降低至原来的 50%、GC Alloc 降低 96%工程质量建立GLOBAL_RULES.md、增加 8 个防退坡测试、重置了 2 次大分支回滚内容量当前可玩内容约 20~30 分钟一局5 种敌人、2 个 Boss、16 个强化选项7.2 下周计划实现第三个 Boss设计稿已完成机制是分阶段切换弹幕形态给 UI 界面增加手柄操作支持这需要先解决输入系统的硬编码问题做一次完整的 10 局试玩压力测试记录崩溃和卡顿日志7.3 个人反思三则第一则AI 的效率红利是有保质期的。项目初期你感觉自己在坐火箭项目中期就开始坐过山车。真正让项目活过中期的不是某个神奇的 AI 按钮而是你自己对项目架构和性能的掌控力。第二则独舞也有舞伴。AI 编程时代的独立开发者从来不是真的一个人。你带的 AI 搭档需要你用管理思路去对待目标分解、规则设定、结果验收、回归测试。这几个动作做到位AI 就是超级生产力做不好你就是一个人为核心的 bug 生产线。第三则游戏设计的灵魂AI 仍然碰不到。开发到第七周我做的最多的其实不是写代码而是玩游戏、调手感、感受节奏弹幕密度够不够刺激无敌帧给多了还是给少了拾取金币的飘字是不是太慢这些感受全凭人的直觉AI 无法替你决定。它能够帮你扫清技术难题让你把时间花在游戏好不好玩这个最根本的问题上这本身就是 AI 编程时代给独立开发者最好的礼物。所以呢一个人 AI 做游戏到底行不行目前的答案依然是行但你得先做好手里有一个半懂不懂的实习生的心理准备然后用管理者的思维去完成这个项目。第七周的经验就是这些下一周如果顺利我再来分享第三个 Boss 的完整实现和试玩压力测试的修复记录。未完待续。
AI编程第七周：一个人做独立游戏，如何驯服AI写出的代码库
1. 第七周的项目快照游戏没做完但终于敢给别人看了先说结论这是我用 AI 编程做独立游戏的第七周游戏还没有做完但已经能跑通一个完整的 demo 循环标题界面 → 选人 → 进关卡 → 打三波怪 → BOSS 战 → 结算 → 回到标题。画风还是那个丑萌的像素风代码量大概在 8500 行左右其中我手写的大概只有四成剩下的都是 AI 生成的——但我要强调的是AI 写代码这件事真正的难点从来不是让它写出代码而是让它别把代码写得让你后面没法改。这个系列前面几篇我聊过怎么选 AI 编程工具、怎么设计提示词、怎么让 AI 理解游戏的整体架构。这篇我想换个角度专门讲讲当项目从跑得起来走向玩得下去时你会遇到的那些破事。因为前六篇如果你照做了这时候你的处境应该和我一样游戏能玩但帧率忽高忽低内存像漏水的水桶同一个 UI 界面改了三遍还是不满意AI 修改一个 bug 的结果往往是引入两个新 bug。这期内容我打算用我自己的项目当解剖对象聊聊中途接手自己一个乱糟糟的代码库、用 AI 做性能优化、以及在AI 效率极高和AI 失控瞎改之间来回横跳的完整经历。不管你是准备用 AI 做游戏、做工具还是做网站这篇里的排查思路和踩坑清单应该都通用。先交代一下项目背景。我做的是一款 2D 像素风的轻量 Rogue 弹幕游戏玩法核心是躲弹幕 三选一强化给玩家的目标是一局控制在 15 分钟内。按照我的规划这类游戏是最适合一个人 AI 来做的类型美术素材可以用现成像素包玩法逻辑不复杂但足够有深度性能瓶颈非常明确弹幕数量、对象池、GC 分配每一项都特别适合让 AI 帮忙。但正是在这个阶段暴露出的问题让我意识到AI 编程项目的先甜后苦期到了。前几周 AI 生成代码的速度让我产生了一个人顶一个工作室的错觉第七周则是这种错觉破产、回归冷静的一周。所以这篇文章的标题叫AI 编程来了我决定一个人做一款游戏07——不是因为我终于做完了而是因为我终于开始理解AI 编程时代一个人做游戏真正的核心竞争力变成了什么。2. 亲手给自己埋的雷AI 生成的代码攒够 5000 行之后开始互相打架先说一个可能让你意外的事实AI 编程的第六周和第七周是完全不同的体验。第六周之前AI 就像一个 everything expert你问什么它答什么一整块功能从零实现几十行、几百行跑起来几乎没问题。到了第七周项目代码量上来之后AI 开始频繁翻车而且翻车方式极其统一——不知道项目其他地方长什么样于是在修改 A 模块时破坏了 B 模块或者在生成新功能时根本没有和已有系统对齐。这事儿的根源我得从人的角度先说透。一个人用 AI 做项目最危险的心理是代码不是我写的所以我不需要完全理解它。前几周我确实偷懒了AI 生成一大段代码后我跑通测试就满意地收工了根本没有认真读每一行。于是到第七周代码库的心智模型只有 AI 有我只有大概的印象——这就是一个巨大的坑。2.1 症状清单当 AI 代码库开始失控我先整理一下这个阶段的典型症状你如果也走到这一步应该会感到熟悉症状一反复出现的灵异 bug。某个敌人的子弹明明只在关卡 2 出现却在主菜单界面偶尔闪出来一帧。查了半天发现是 AI 早前生成一个全局限时管理器时把子弹池的初始化逻辑写得过度全局化结果所有场景都共享了它。症状二改一处崩三处。我让 AI 加一个拾取金币飘字效果它很听话地在 HUD 里加了一个飘字组件结果进入结算界面就报空引用。原因结算界面的 HUD 初始化顺序和主界面不同飘字组件在它引用的 UI 画布加载之前就被实例化了。症状三AI 开始遗忘以前的约定。项目的输入系统我早就统一成Config 配置按键 → InputManager 读取但 AI 为了省事在新生成的技能系统里直接写了Input.GetKeyDown(KeyCode.Space)。单看这一处没问题可我在把技能系统改成支持手柄时就蒙了因为硬编码按键完全绕开了我设计的输入映射层。症状四代码量膨胀到难以理解。有一回我让 AI 帮我重构一个敌人波次生成器它没有简化逻辑反而生成了一个 800 行的波次配置解释器读起来比原来的 200 行还难懂而且运行效率更差。2.2 病根排查AI 的局部最优和上下文窗口限制这些症状说到底根子在两点。第一AI 本质上是局部最优的生成器。它每次生成一个函数都倾向于在当前上下文范围内做最合理的实现但它并不知道全局架构你的系统里还有别的什么模块。如果你不提供全局信息它就会默认使用它的常识来填空——而这恰恰会破坏你项目早就定下的约定。第二上下文窗口限制。目前市面主流的 AI 编程助手单次能看到的代码上下文通常是整个文件少数能跨文件检索但它们毕竟不是人无法像你一样把项目几千个文件之间的关系烂熟于心。所以当你让它改一下那个 BOSS 的 AI 脚本时它可能只看得到 BOSS 的 AI 脚本根本不知道你的伤害数值系统里面有一套受伤无敌帧的逻辑。结果它把 BOSS 的受伤反应改完之后无敌帧失效玩家一碰到 BOSS 就掉血飞到屏幕外。2.3 对症下药给 AI 立全局规矩的确切做法发现问题以后我做的第一件事不是继续干活而是花了两天时间做了一件事给 AI 立规矩。具体操作如下你可以直接照抄。第一步我建立了一个GLOBAL_RULES.md放在项目根目录下然后在每个让 AI 执行任务的提示词开头都让 AI 先读这个文件。文件里写的内容包含项目的整体模块划分哪个目录管什么编码规范命名风格、接口约定、文件大小上限禁止做的事清单例如禁止硬编码输入、禁止在游戏逻辑脚本里直接操作 UI 对象、禁止在 Update 里分配新对象、禁止修改与本次需求无关的文件第二步要求 AI 在每次改动之前先用文字解释自己的方案说得通才允许动手。我之前太着急总让它直接改现在强制它先写方案再说。这条看起来费时间实际上省下的返工时间远多于多花的这点时间。第三步改到什么程度可以停必须定义清楚。我的规则是所有改动必须保持单一职责AI 不能在修 bug 的时候顺手优化了整个模块的代码风格。风格统一这件事可以之后专门开一个任务做混在一次改动里出问题都查不清是谁的责任。这一步很关键我们单独拿出来继续说。我平时在正常工作里也带过几个人我发现让 AI 和我带过的高级工程师有不少惊人的相似之处能力很强但正常发挥需要清晰的上下文、明确的范围限定、还有对全局架构的了解。这不纯粹是技术问题更是管理问题。个人经验给 AI 立规矩这件事越早做越好。我是在代码量到 5000 行才做晚了。如果你刚开始用 AI 写项目第一周就建GLOBAL_RULES.md后面至少能少走一半弯路。3. 用 AI 做性能优化一次手术式的 Unity 帧率排查实战第七周最重要的事情是给游戏做了一次系统性的性能体检。在这之前游戏在单位台式机AMD Ryzen 5 GTX 1660上能跑到 60 帧但一进弹幕密集的 BOSS 战就掉到 30 帧。更难看的是小内存机器上每 30 秒会卡顿一下那个卡顿的时间点非常规律跟弹幕密度无关就是纯粹的资源抖动。对独立开发者的游戏来说帧率不稳比平均帧率低更致命——玩家可以接受 45 帧恒定但绝对不能忍受 60→30→60 来回跳。因为帧时间波动直接反映到手感上而动作游戏的手感是命根子。3.1 第一步先量化再优化我一上来没有急着让 AI 改代码而是先给它一份性能报告的数据。Unity 的 Profiler 是我用的主要工具在Window Analysis Profiler打开然后在 BOSS 战场景中跑 3 分钟采集帧时间、CPU 耗时、GC 分配三个指标。不量化就没有优化的依据。如果你直接跟 AI 说帮我优化性能它给你的建议十有八九是洗稿级别的用对象池、合并 Draw Call、压缩贴图——这些泛泛之谈确实没毛病但解决不了你的具体问题。让数据说话之后我得到了一份比较详细的问题清单指标优化前数值问题粗略定位帧时间均值34ms约 29 FPS主要卡在 BOSS 弹幕施放逻辑帧时间峰值89ms大量瞬时的 GC Alloc平均 GC 分配每帧约 2.3MB弹幕发射器在 Update 里创建临时对象Draw Call 数量约 287每个子弹都是独立 SpriteRenderer内存峰值约 890MB加载了 16 个关卡场景从不卸载这份数据打给 AI它的分析就完全不一样了。它不再给泛泛的优化建议而是直接指出GC 分配每帧 2.3MB 是最大的性能杀手单帧 89ms 的尖刺就是 GC 收集引起的Draw Call 287 是另一个瓶颈但优先级略低内存峰值高是因为场景没有做按需卸载。3.2 第二步解决子弹海啸——对象池 缓存我按照优先级先从 GC Alloc 和弹幕对象池着手。我的弹幕系统一秒要发射 80~120 颗子弹每颗子弹都是一个EnemyBullet对象里面有 transform、sprite renderer、移动速度属性。优化前每发射一颗子弹就new一个对象子弹销毁时还要标记Destroy然后等 Unity 的卸载机制来收拾它。这里的高效做法是对象池。我把创建子弹的逻辑统一改成预创建 300 个EnemyBullet实例放进池子发射时不new而是从池子中取一个激活子弹出屏或碰撞后用SetActive(false)归还具体的代码如下这套代码是我让 AI 根据项目现有弹幕系统重构的但我在关键位置做了检查和微调确保它真能用public class BulletPool : MonoBehaviour { public GameObject bulletPrefab; public int poolSize 300; private QueueGameObject pool new QueueGameObject(); void Awake() { for (int i 0; i poolSize; i) { GameObject bullet Instantiate(bulletPrefab); bullet.SetActive(false); pool.Enqueue(bullet); } } public GameObject GetBullet(Vector3 position, Quaternion rotation) { if (pool.Count 0) { // 池子不够用临时扩容。实际开发中最好在 Loading 阶段就设好峰值。 GameObject extra Instantiate(bulletPrefab); pool.Enqueue(extra); } GameObject b pool.Dequeue(); b.transform.position position; b.transform.rotation rotation; b.SetActive(true); return b; } public void ReturnBullet(GameObject bullet) { bullet.SetActive(false); pool.Enqueue(bullet); } }千万别小看这几行它是 AI 最常写错的一个逻辑点。AI 默认的写法经常在GetBullet方法里Instantiate新的子弹、在ReturnBullet里写Destroy那就是一个披着对象池外衣的普通子弹生成器——没有任何优化效果。所以这个代码我验收时专门多看了两遍。另一个重要问题是如果池子里子弹不够怎么办我一开始设为 300但测到最高难度 BOSS 战时峰值一口气生成 450 颗子弹池子不够导致临时 Instantiate又出现了卡顿。所以最终我把池子预生成调到 600并且额外写了一段预警逻辑如果某次取用后剩余池中对象少于 10%就打印一条日志提醒后续要不要再加。3.3 第三步让 AI 重构子弹移动的 Update 循环对象池解决了对象创建的 GC 问题但还有一个问题每颗子弹自己的移动逻辑是在各自的Update()里做的。600 个子弹就有 600 个Update()调用虽然每帧加起来时间不长但 Unity 的MonoBehaviour.Update()调度成本会随着对象数量线性增长累计起来不可忽视。我让 AI 把这个移动逻辑重构成一个统一的BulletMovementManager用把子弹的 Transform 缓存到数组里在 Manager 的 Update 里统一遍历移动的方式。类似数据导向设计的思想把分散的逻辑集中管理。重构之后的效果同一场景下再跑 Profiler指标优化前优化后下降幅度平均 GC 分配每帧 2.3MB每帧 90KB96%帧时间均值34ms17ms50%Draw Call后文解决287146贴图合并后49%帧时间峰值89ms28ms68%数据明显向好了。但别着急高兴紧接着我发现原生问题解决之后新的瓶颈暴露出来了——Draw Call。这也印证了性能调优那条老路永远不会只改一处就万事大吉优化完 AB 就会变成主要矛盾。3.4 第四步动态合并 UI 和子弹的渲染批次UI 的优化其实不复杂。我的项目里 UI 元素非常多每个Image、Text都是一个独立的渲染单元如果字体的 atlas 分散或者 UI 上有大量需要频繁更新的文本合批会非常困难。我把所有 UI 做了三件事减少不必要的 Raycast Target给所有纯展示用的 Text 和 Image 关掉 Raycast Target。这样鼠标和触摸检测的命中测试就不用扫描这些对象省下不少 CPU。控画布重构频率UI 上如果每帧都有文本变化比如分数、血量这个 UI Canvas 就会每帧做一次重构。我把分数从每帧更新改成只在数值变化时更新直接在Text.text的 setter 入口判断如果值没变就跳过赋值。缩小 UI atlas一顿裁剪之后所有 UI 共用一张图集减少纹理切换的次数。至于场景中大量的子弹精灵方案其实是合并动态批次。思路是让同一种贴图的子弹尽量连续渲染避免频繁切换材质。我在子弹池的排序逻辑里做了一点小优化比如让所有同种子弹在数组里排在一起发射时也按类型批次取用。这个改动配合 Sprite Atlas 图集直接让 Draw Call 从 287 掉到 146。另外场景内存的问题我也顺手处理了Unity 的SceneManager.LoadScene默认把旧场景直接卸载但如果你用 Additive 方式加载或者有全局 DontDestroyOnLoad 对象没管好内存就会越涨越高。我审查后发现老版的关卡波次配置数据全都被我设成了static字段每进一关就在 static 列表里追加一份配置从不清理。这会直接导致内存随着游戏局数增长一局还好三局下来就逼近 1GB。修复方式在关卡开始时清空静态配置缓存只保留当前关卡的引用。3.5 性能优化的核心心得这一段优化做下来我对用 AI 做性能调优的体会是AI 是很好的执行者但你要当好架构师和验收者。性能问题本质上是数据问题你需要先通过 Profiler 定位出哪个数据不对GC、DrawCall、内存峰值然后让 AI 针对这个明确的数据动手。它不会自动发现每帧 2.3MB GC 分配来自子弹创建——它没有读你的全部代码更没法像人一样做全局判断。所以我的工作流变成拿 Profiler 数据 → 自己分析瓶颈归属 → 给 AI 明确的修改指令 → 跑 Profiler 验证 → 有提升则接受没提升则继续挖数据。这套流程和传统开发没有本质区别关键是 AI 能把从指令到修改的速度提高好几倍让你能在一个晚上迭代三轮优化方案。4. 越补越多的AI 修 bug循环我的排查链路与防退坡机制前面讲性能优化是一切顺利时的节奏。这一章我要讲讲最折磨人的事AI 改 bug改着改着把原本稳定的系统改崩了。这个环节里踩的坑我希望能帮你省下至少两天的无头绪时间。4.1 一次典型AI 连环翻车事件复盘我的技能系统里有一个很简单的需求玩家按 Q 键释放一个短距离冲刺冲刺时获得无敌帧持续 0.4 秒。这个功能两周前就做好了一直没出问题。第七周我想加一个冲刺后 1 秒内近战伤害 30%的 buff于是让 AI 改技能系统的代码。AI 的改动方案是读到了冲刺技能脚本在释放冲刺的方法里加了一个buffMgr.AddBuff(BuffType.Strength, 1f, 0.3f)调用。从局部逻辑看它没错。但我没想到的是这行代码直接让玩家的冲刺动作在 0.4 秒无敌帧期间多了一个力量 buff而力量 buff的实现逻辑里又读取了玩家的基础攻击力基础攻击力在冲刺状态下恰好被另一个 AI 早前写的 冲刺姿态改变攻击力回退 的脚本设置为 0于是玩家冲刺完 1 秒内的攻击力变成了 0伤害反而变低了。我刚开始完全没料到这个结果。第一次测试冲刺后平 A伤害从 12 变成 0我以为是自己手滑没打中。第二次测试还是 0我才意识到是 AI 改动引发了连锁反应。这个 bug 的排查过程极其痛苦因为断裂的链条跨越了四个文件技能释放脚本、buff 系统、属性系统、角色姿态系统。传统 IDE 里根本没法一眼看出它们的关联。我花了一个多小时逐文件读代码才最终定位到根源AI 加的那行代码没有做防御性检查也没有遵循获取当前实际攻击力应该走属性系统统一接口这个项目规则。4.2 排查链路从现象到根因的四步法我把这轮排查总结成了四步现在每次让 AI 改完代码、测试挂了我就按这套流程走效率高多了第一步复现并锁定触发条件。不要凭感觉改代码先把什么操作、什么状态、什么次序下会触发 bug记录清楚。我建了一个0_bug_repro.md文件每发现一个新 bug 就把复现步骤写进去。很多 bug 的触发条件是你没料到的写下来之后才能让 AI 也快速定位。第二步用版本控制快速定位改动范围。我每次让 AI 改完代码都会把改动单独提交到一个分支上分支名就叫feat/buff-attack-percent然后核心分支保持稳定。如果新改动一出问题我直接git diff看这个分支的改动比从头梳理代码快几个数量级。这一步极度关键——AI 改代码经常偷偷改到无关文件版本控制能让你立刻发现。第三步让 AI 解释自己的改动并追问接口约束。当 bug 定位到某个改动时把改动片段贴给 AI然后问它你这次改动依赖了哪些现有接口这些接口在什么情况下可能返回非预期值 这一步常常能直接让 AI 自己发现自己违规了。第四步在 AI 的修复之上加防退坡测试。修复 bug 后一定不要只验证能跑还要写一个最小化的单元测试或集成测试。哪怕只是一个极简的 sanity check冲刺后攻击力不应为 0。这样以后再有 AI 代码改动测出回归时你能立即发现。我称为防退坡测试——防止 AI 每次修改都把项目往坡下推一点最终把游戏改回一个不可玩的烂摊子。下面是这套流程可视化的关键节点我画图功力有限你能看懂就行发现 bug 现象 ↓ 记录复现步骤写进 0_bug_repro.md ↓ git diff 查看最新改动范围 ↓ 把改动片段贴给 AI让它解释依赖关系 ↓ 定位根因通常是接口约束或全局规则被破坏 ↓ 修复 写防退坡测试 ↓ 回归验证更新文档4.3 为什么 AI 最容易在这里翻车以及如何预防AI 修 bug 容易翻车的原因其实可以总结成一句话它默认改动是局部的而游戏代码天然是全局耦合的。任何牵一发而动全身的系统——属性、Buff、状态机、输入映射、UI 事件AI 改起来都容易出问题。预防方式我目前验证有效的有三个一是强制 AI 在改动前做依赖分析。我要求 AI 在提示词里回答一个问题你这次改动会影响哪些其他系统影响面是否可以控制在当前模块内 如果它不能明确回答就别让它动手。这一条可能让 AI 的回答速度变慢但正确率大幅提升。二是把高风险模块设计成窄接口。比如 Buff 系统我把它封装成只提供AddBuff(BuffType, duration, magnitude)这样一个入口内部逻辑不许外部直接访问。这样 AI 如果要调用 buff 系统只能走这个窄接口不容易意外耦合到内部状态。这和写后端服务的思路完全一样——降低模块间耦合AI 就不容易踩雷。三是永远保留一个能回滚的稳定分支。只要 AI 改动导致测试失败立刻把主分支切回上一版别跟 AI 在错误的代码上反复拉扯。很多时候我们就是太想修好这个错误却忘了直接把改动 revert 掉、重新换个提示词让 AI 生成反而更快。实战心得让 AI 修改问题的成本往往低于让它接着刚才的思路修复问题。如果一次改动失败我会立刻重置会话、换个思路重来而不是在同一个错误方案上继续要求修好它。因为 AI 在同一个会话里往往会固执地延续自己的方案而不自知。5. 提示词从写功能切换到填坑模式几种高价值提示词模板既然已经聊到 AI 怎么改 bug这一节就把我第七周摸索出来的几种填坑模式提示词分享给你。这和最初帮我实现一个功能的提示词完全是两种生物如果你还在用 Last 方式指挥 AI你很快就会遇到AI 越修越乱的崩溃感。5.1 面向现有代码做改动时的提示词结构先说底层逻辑AI 在已有代码上做改动时最关键的信息不是你想要什么效果而是你不知道但它必须知道的全局信息。所以我会把提示词拆成四段【任务】 修改文件Assets/Scripts/SkillSystem/DashSkill.cs 需求玩家使用冲刺后 0.4 秒无敌同时获得 1 秒的 30% 伤害加成 buff。 【项目规则强制阅读 GLOBAL_RULES.md】 - 所有战斗数值必须通过 AttributeSystem 统一获取和修改禁止直接操作 raw 字段。 - Buff 系统只能通过 BuffManager.AddBuff(BuffType type, float duration, float magnitude) 调用。 - 禁止修改与本任务无关的文件。 【你目前的计划先回答不要动手】 请说明 1. 你打算改哪几个文件各改什么 2. 这些改动会影响哪些现有系统是否有潜在风险 3. 你的方案如何保证不破坏冲刺无敌帧逻辑 【验证方式】 改完后执行 Unity Test Runner 里的 DashBuffSmokeTest确认冲刺后的平 A 伤害为 15.612 * 1.3。这段提示词有三个关键点。第一让 AI 先说计划再动手这能帮你在早期阶段就发现它打算跑偏的方向及时叫停。第二明确告诉它不能碰哪些文件杜绝 AI 擅自重构。第三给出明确的数值验证目标让 AI 自己判断改得对不对而不是靠你肉眼测试。5.2 专门用来排查的提示词模板当 bug 已经出现、但我不知道根因在哪时我用的提示词是这样的我在跑游戏时发现一个 bug 复现步骤 1. 进入第二关 2. 击杀第一个精英怪 3. 打开背包快捷键 I 4. 游戏报空引用错误NullReferenceException: Object reference not set to an instance of an object 报错堆栈已附在下面。 请根据堆栈和项目代码做根因分析 - 不急着给修复方案 - 先列出最可能的原因、次要可能原因、每一类原因的排查方法 - 要求你检查这个报错是否与最近的 5 次 git 提交有关 - 分析过程中如果需要查看其他文件请先列出文件名再继续这个模板的价值在于强制 AI 做根因分析而不是直接给修复。很多 AI 助手收到报错了帮我修就会立刻给一个局部补丁。但它可能完全没看堆栈、没看上下文补丁只是缓解了症状根因还在原地。所以我把先分析后修复写死了效果显著。5.3 专门用来重构的提示词模板第七周我还做了一次大重构把原来散落在各个脚本里的敌人 AI按状态机模式统一重写。给 AI 的重构类提示词需要额外强调保持行为不变。重构目标把 EnemyAIController.cs 里的 switch-case 敌人 AI 改为状态机模式。 约束 1. 行为必须完全等价。现在的 idel → chase → attack → hurt → die 流程不能变。 2. 不允许改变对外的公共方法名和字段名其他脚本依赖它们。 3. 重构后必须保证单测 EnemiesAITests 全部通过。 4. 不要顺手改其他文件。 下面是当前文件的全文 [贴代码] 请先分析状态划分是否合理如果有更优方案先说建议我再决定要不要调整。重构类任务的关键是等价性验证。让 AI 重构完你必须快速跑一遍原有的所有测试没有测试的话至少手动过一遍原有功能。我在这一阶段吃过一次大亏AI 重构完敌人生成器所有敌人类型都正常唯独精英怪死后不掉落了查了半天才发现重构时把掉落表的初始化放错了位置。防退坡测试如果当时有就不至于花两小时定位。5.4 AI 不知道的上下文你得喂给它最后必须强调AI 的上下文窗口是有限的。哪怕这个 AI 号称项目级上下文它一次能看的文件数量还是有限制的。所以当你要改一个高耦合模块时请把关联的接口定义或者关键函数签名贴给它而不是指望它自己搜。我的习惯是提问时直接附上这几样项目根目录GLOBAL_RULES.md的全文或关键段落所涉及模块的接口定义比如 AttributeSystem 的公开方法列表最近一次 git 提交的 diff让 AI 知道别人改了什么这条习惯让我的 AI 出错率下降得非常明显。6. 当 AI 从一个写码工具变成一个结对编程搭档第七周的收获与反思到了第七周我对 AI 编程的理解已经发生了很大的变化。差不多可以总结一下这个阶段真正的收获。6.1 从让 AI 干活到和 AI 一起做决策过去我做功能时是我提需求 → AI 生成代码 → 我测试验收。到了性能优化和 bug 修复阶段这个模式行不通了。因为很多问题你不能简单描述你得先分析数据、定位问题、想清楚方案然后才轮得到让 AI 执行。换句话说AI 编程的瓶颈不再在写代码那个环节而是在懂系统和做决策的环节。而这恰恰是人的价值所在。同样是改一个 BOSS 弹幕生成器AI 可以生成得很漂亮但是要不要引入对象池对象池的初始大小设多少弹幕的 Move 逻辑应不应该抽离这些设计决策AI 做不了——AB 测试的成本太高了只有你能拍板。这种分工的感觉有点像带了一个非常聪明但缺乏经验的实习生。你要把事情拆解成足够小的步骤给它它就能执行得飞快但如果你自己都没有全局思考清楚就抛给它它就会在错误的方向上疯狂输出然后浪费你更多的返工时间。6.2 一个人 AI 做游戏里程碑式的标记变得更重要独立开发者一个人做太容易迷失方向了有了 AI 之后这个风险更严重。因为 AI 一天就能生成一千行代码但其中真正有游戏性的验证还是需要你亲手玩、亲手调。在这周里我给自己建立了一个每天可玩的版本机制每天结束前主分支必须处于一个完整可玩的状态——哪怕只有一关哪怕只有 5 分钟的游戏内容。这不是为了给别人 demo而是为了让自己始终有完整体验的基准线。如果哪天 AI 改崩了即使当前任务没完成也要先回滚到上一个可玩版本。这个机制在 AI 编程时代尤其重要因为 AI 改崩的几率比你想象的高如果你不锁定可玩这条底线你会陷入一整个礼拜都在修一堆半成品功能的泥潭。6.3 给新手的一个建议别急着冲功能先冲稳定如果你正在用 AI 做项目我给你的第七周建议是在这个阶段稳定性的优先级应该高于新功能。相比于再加一个 Boss、再加一个道具更值得做的是把核心玩法的性能优化到流畅给关键系统写一套防退坡测试完整跑通一次从开始到通关的流程把 BUG 清单削到个位数把 GLOBAL_RULES.md 写得足够详细让 AI 后续只干活、不添乱这些基础工作听起来不酷炫也没有新功能那么让人开心。但它们才是从 Demo 走向可发布游戏最核心的一步。没有稳定性和性能底子功能越多游戏越像一栋地基不牢的危楼AI 每往上盖一层你睡得就越不安稳。就拿我自己的项目来说如果没有第七周的性能优化和规则治理第八周我其实可以再做 3 个新 Boss。但那些 Boss 可能在 60 帧的桌面上流畅在玩家入门级显卡上就变成 PPT。做游戏这行永远不是我做了多少内容算数而是玩家实际体验到多少内容才算数。如果让我总结第七周的一条核心经验那就是AI 可以把你的生产力放大十倍但同时它也能以同样的倍数放大你架构混乱的风险。代码是自己的架构更是自己的。AI 永远不会替你背这个锅。7. 给同样在用 AI 做项目的你一次真实的周复盘这周的结尾按照惯例分享一下项目整体的进度和一些个人反思。不算完整复盘更像是随手写的工作日记希望能给同行一些参照。7.1 本周完成清单核心功能完成了冲刺 Buff 联动和两个新敌人追踪弹型、散弹型性能优化完成对象池重构、Draw Call 降低至原来的 50%、GC Alloc 降低 96%工程质量建立GLOBAL_RULES.md、增加 8 个防退坡测试、重置了 2 次大分支回滚内容量当前可玩内容约 20~30 分钟一局5 种敌人、2 个 Boss、16 个强化选项7.2 下周计划实现第三个 Boss设计稿已完成机制是分阶段切换弹幕形态给 UI 界面增加手柄操作支持这需要先解决输入系统的硬编码问题做一次完整的 10 局试玩压力测试记录崩溃和卡顿日志7.3 个人反思三则第一则AI 的效率红利是有保质期的。项目初期你感觉自己在坐火箭项目中期就开始坐过山车。真正让项目活过中期的不是某个神奇的 AI 按钮而是你自己对项目架构和性能的掌控力。第二则独舞也有舞伴。AI 编程时代的独立开发者从来不是真的一个人。你带的 AI 搭档需要你用管理思路去对待目标分解、规则设定、结果验收、回归测试。这几个动作做到位AI 就是超级生产力做不好你就是一个人为核心的 bug 生产线。第三则游戏设计的灵魂AI 仍然碰不到。开发到第七周我做的最多的其实不是写代码而是玩游戏、调手感、感受节奏弹幕密度够不够刺激无敌帧给多了还是给少了拾取金币的飘字是不是太慢这些感受全凭人的直觉AI 无法替你决定。它能够帮你扫清技术难题让你把时间花在游戏好不好玩这个最根本的问题上这本身就是 AI 编程时代给独立开发者最好的礼物。所以呢一个人 AI 做游戏到底行不行目前的答案依然是行但你得先做好手里有一个半懂不懂的实习生的心理准备然后用管理者的思维去完成这个项目。第七周的经验就是这些下一周如果顺利我再来分享第三个 Boss 的完整实现和试玩压力测试的修复记录。未完待续。
