Vibe Coding实战：AI辅助重构Unity游戏SO架构

在AI辅助编程日益普及的今天，"Vibe Coding"（凭感觉与AI协作编程）正成为独立开发者的新常态。Vibe Coding 一词由 OpenAI 联合创始人 Andrej Karpathy 于 2025 年初提出，用以描述一种全新的编程范式：开发者不再逐行编写代码，而是用自然语言向 AI 描述意图，凭直觉与 AI 反复对话、试错，最终"感觉对了"就采纳。这种模式的普及背后是大语言模型代码能力的跃迁——从 GitHub Copilot 的行内补全，到 Cursor、Claude Code、Codex 等具备完整项目上下文理解与自主执行能力的 AI Agent。对独立开发者而言，它极大降低了从想法到原型的门槛，但也带来了新的挑战：如何在放手让 AI 编写的同时保持对架构的掌控。B站UP主"阿P"在《阿P的Unity备忘录》系列第二期中，完整记录了他如何借助AI（Codex）为一个大富翁类游戏搭建可扩展的架构，并引入Unity的ScriptableObject（SO）数据体系。这期内容不只是教程，更是一份关于人机协作心态与工程实践的真实备忘录。

开始项目的心态：想做就立刻动手

阿P在开场分享了一个颇具价值的观点：当你有想法时，纠结先做还是后做都没有意义，关键是立刻动手。 后做的人或许能享受更新的技术和更丰富的资源，但先做的人积累了不可替代的流程经验——这种"亲自经历一遍"的理解是任何教程都无法替代的。

他特别提醒已经开始或即将开始的开发者：心态一定要稳。 阿P坦言自己第一个项目做到相对完整的原型阶段时，恰逢AI出现了更高级的用法，一度陷入"前面的手工劳动是不是白费了"的焦虑。但当他真正让AI接手已有代码、开始更深度的协作后，他发现前期的手工积累并非无用功——正是那段经历让他对整体架构和人机配合有了更深理解。

"反正都是要进步的，总有一天是要被淘汰的，跟着发展就可以了。要会下决策，要敢下决心，大不了推倒重做。"

这种"敢于推倒重来"的松弛感，恰恰是AI时代独立开发者最需要的素质。

为什么要做架构：可扩展性优先

本期的核心目标是：让一个"能跑"的项目变成一个"能拓展"的项目。阿P指出了当前项目的几个痛点：

• 扩展成本高：每新增一个建筑或效果，手动叠加会越来越累；
• Token消耗风险：如果AI的token用光，自己手动加内容会非常麻烦；
• 职责混乱：UI与动画规则混在一起，AI继续写容易"改串了"。

解决方案的核心是引入 ScriptableObject（SO） 作为数据配置层。ScriptableObject 是 Unity 提供的一种数据容器类，它独立于场景中的 GameObject 存在，以资产（.asset）文件的形式存储在项目里。与必须挂载在游戏对象上的 MonoBehaviour 不同，SO 是纯粹的数据载体，不参与运行时的更新循环，因此非常适合用来配置那些"不随实例变化"的共享数据，例如武器属性、关卡参数、建筑效果等。Unity 官方长期倡导的"数据驱动设计"（Data-Driven Design），其核心思想就是把逻辑与数据分离：程序员编写通用的行为代码，设计师通过修改 SO 资产来调整数值和配置，无需改动代码。这不仅降低了耦合度、减少了内存冗余，也让项目更易于扩展和团队协作。

在本项目中，每个建筑（银行、传送门、能量站、商店等）都被抽象为一个可配置的SO资产，拥有各自的触发方式（pass/stop）与效果命令（传送、加钱、显示反馈等）。这样一来，建筑就变成了可以自由拼接的"效果资产"，无论是人还是AI，后续调整都会更加清晰、职责分明。

你可能没注意到，阿P采取了分步实现的策略：先让AI把SO架构和基础代码写好，暂时删掉更复杂的"SO Event Channel"（事件通道），等基础稳固后再迭代推进。这种"小步快跑、分层实现"的思路，正是与AI协作时控制复杂度的有效方法。

手机远程控制：Codex的移动端玩法

阿P分享了一个实用技巧：当你使用Codex等支持远程控制的AI Agent时，即使人不在电脑前，也能通过手机操作。Codex 是 OpenAI 推出的编程 AI Agent，与传统的对话式助手不同，它具备在真实开发环境中自主执行任务的能力——可以读写文件、运行命令、执行编译测试，并根据结果自我修正。这类 Agent 通常支持云端运行和移动端接入，使得开发者即便离开电脑，也能通过手机下达指令、查看进度。

他特别强调了一个容易被忽略的细节：让AI截屏发给你时，一定要告诉它"我人在外面，看不到本地图片，需要你以复建（重新构建）的方式把图片传给我"。 否则AI可能只是引用了本地路径，远程的你根本看不到画面。这个细节恰恰揭示了 Agent 工作方式的一个关键点：AI 操作的是它自己所在的运行环境（如云端沙箱或本地机器），而人与 AI 之间隔着一层数据传输，本地路径对远程用户不可见。理解 Agent 的执行边界与上下文隔离，是高效驾驭这类工具的前提。

他还演示了通过对话让AI自动打开忘记启动的Unity项目——这种"随时随地指挥Agent"的工作方式，正在重新定义开发者的工作场景。

SO数据落地：从旧格式到全新资产

在AI生成了BuildingConfig（建筑配置）后，阿P发现了一个典型问题：AI创建了SO的类型定义，却没有真正生成对应的SO资产（asset），也没有在运行逻辑中引用它们。 这提醒我们，AI的"完成"往往需要人工验证是否真正闭环。

更关键的是，AI最初的实现"仍使用旧格式"作为兼容层。阿P明确要求AI彻底用新的SO替代所有旧建筑格式，而不是保留过渡方案。最终AI把银行、传送门、能量站、商店四种建筑全部纳入了catalog（资产目录），并支持通过引用目录而非硬编码来加载——尽管阿P个人对这个方案不完全满意，但他选择"之后慢慢改"，体现了迭代式协作的节奏感。

关键实践：打造可视化地图编辑器

本期最有价值的工程实践，是让AI打造一个可视化地图编辑器（Editor Tool）。阿P的需求很明确：

1. 在Unity的Scene中手动"画"出一个首尾相连的大富翁地图；
2. 画出的地图存成ScriptableObject作为纯数据（data）；
3. 游戏运行时读取这份data，重新生成所有建筑的tile与表现。

AI很快实现了MapDataSO和对应的MenuItem工具，支持6×6网格的绘制。经过迭代，编辑器进一步支持了三种明确行为：点击切换类型、替换为空白格、erase擦除。阿P在实际操作中发现了"路径必须首尾相连、中间不能断开"的约束逻辑，并遇到了删除格子时的小bug——这些都是真实开发中不可避免的调试细节。

他还给出了进阶建议：制作Editor Window时可以给AI更复杂的指令，比如支持长按、拖拽填充，甚至让工具自动生成prefab或特效，让地图连接更流畅。这种把"编辑体验"也交给AI去优化的思路，值得借鉴。

与AI协作的两个避坑要点

阿P基于自己的实战经验，提出了两个重要的避坑建议：

其一，警惕AI误删手动代码。 他回忆使用旧版Codex和Antigravity时，AI在执行reverse或更新工作状态时，会误把开发者手动添加的内容当成"杂质"删掉，因为它"不认识"那些非自己编写的代码。虽然新版Codex已基本解决此问题，但他仍建议：主动告诉AI你手动加了什么，或者养成commit的习惯（不一定push），确保被误删后能reverse回来。

这里的 commit 习惯，指向的是 Git 版本控制这一软件工程基石。commit（提交）会在本地仓库中为当前代码状态创建一个快照，而 push（推送）才是将其上传到远程仓库——二者可分离进行。即使不联网推送，频繁的本地 commit 也能形成完整的历史记录，一旦 AI 误删或改坏代码，开发者可以通过 revert 或 checkout 快速回退到任意历史节点。在 AI 频繁改动代码库的协作模式下，版本控制既是安全网，也是人机之间的"契约边界"，为每一次 AI 的自主操作都留下了可追溯、可撤销的锚点。

其二，善用CLI提升效率。 阿P直接让AI帮他把Unity的command line（CLI）"装到能用为止"，几乎没有自己动手。这让AI能够自主触发编译、测试等操作，大幅减少人工干预。

架构到底值不值：仁者见仁

视频末尾，阿P抛出了一个诚实的反思：这期进度其实"不太满意"，因为每次AI执行任务都很慢——一个任务11分钟，另一个7分钟，还有一个20分钟。他坦言，如果不考虑架构，直接让AI"给我做个游戏"，速度可能快得多。

那么，投入时间做架构到底有多少意义？阿P的答案是因人而异：

"我自己比较喜欢做游戏，也希望能自己去调整——像绘制地图、找各种元件做调整，这个过程我觉得挺舒服的。如果AI一次性全做完，我每次想改都要发语音让它改，我自己会觉得少一点体验。"

这是一个极具启发性的观点：在AI能一键生成的时代，"可控性"和"参与感"本身就是一种价值。 是追求极致效率让AI全权代劳，还是保留架构的清晰度以享受创造过程，这取决于每个开发者对"编程"这件事的定位。

结语

阿P这期"我流Vibe Coding"展示的不仅是Unity + ScriptableObject的技术实践，更是一种成熟的人机协作方法论：分步实现控制复杂度、验证AI输出的真实闭环、通过commit和主动沟通规避误删、以及在效率与可控性之间找到属于自己的平衡点。 对于正在探索AI辅助游戏开发的独立开发者而言，这份"备忘录"的参考价值远超一期普通教程。

核心要点