声明本文为桌游移植项目复盘规则源自桌游《Philosophy》版权归原作者和出版社所有Unity零基础全免费AI工具0花费从8月初到9月底中途因为身体健康原因我断断续续投入了约38天把一款名为 Philosophy哲思漫谈的抽象策略桌游做成了电子版。项目累计产出了约4.8万行 C# 代码、5.6万行 Unity 场景与界面相关内容以及近万行设计文档。AI深度参与了绝大部分代码实现我主要负责前期基础框架的实现、以及后续需求与架构设计、方案审核以及最终的功能验收。很多人看到这样的数字第一反应可能是是不是又要讲哪个AI有多厉害如何一键生成、躺着开发其实不是。这篇文章更想记录的是一个实际问题当AI越来越擅长编写代码、实现功能甚至参与架构设计时开发者的核心工作究竟发生了什么变化先列数据✅ 185 个代码文件共计 47,715 行代码✅ 17 个 Unity 场景/UI 文件56,068 行内容✅ 20设计文档9,593 行文字✅ 支持2-3人对局✅ 支持不同难度的AI对手✅ 支持局域网对战广域网待做✅ 包含完整的新手引导教学体系✅ 100单人谜题关卡✅ 对局记录和回放系统✅ 多语言支持完整I18N框架和中英双语本地化输出✅ 角色语录系统36张角色头像、1080条角色语录✅ 十几个定制辅助开发自动化脚本和工具代码、界面、设计文档全部汇总整体工作量约11.3 万行。以上统计包含代码、Unity 序列化场景与界面文件以及设计文档均按原始文本行数统计并不代表等量的人工开发工作。这里主要是为了展示整个项目的产出规模而不是用行数衡量开发效率。其中不到10%左右的代码和部分设计文档为我纯手写剩余90%以上均由AI深度参与完成。引擎和工具选型之所以选择Unity作为引擎是因为我想做一款真正能够商业化的游戏真实感受一下个人开发游戏的全流程。而不是仅仅满足于各种一键生成看似复杂但仅能作为Demo玩具的网页游戏毕竟我是来学习开发游戏的不是来宣传谁家AI更强的。而选择Philosophy这个桌游则是因为这个冷门的抽象棋类桌游规则足够简单但又相对完备且有一定的对局难度和思考空间实现起来也并非容易。规模小但五脏俱全非常适合作为一款开发练手用的游戏。此外因为冷门日后如果真的要上架Steam之类找出版商授权也存在一定的可能性毕竟他们的实体桌游也卖不了几份应该不会想要自己开发电子版。那么这是怎样一款桌游呢它是一款棋盘只有7X7大小的抽象策略对战棋类游戏对局双方轮流打出手中的棋子游戏中称为「观点板块」三枚己方棋子连成一线即可取得胜利。你可以简单粗暴的理解为一款加强版的井字棋但是每个观点板块都有自己的特殊能力可以用各种方式移动对方的板块也能连锁触发场上已有板块的能力可谓一步落子牵动全局。套用原游戏的说法就是双方轮流抛出自己的观点来影响和改变对方的思想谁先完成三段式的结论就取得胜利可以预见这个游戏的核心交互界面不会很复杂也不需要大量的图像素材而它的规则又足够严谨涉及到不同棋子的能力各异加上触发条件连锁反应等所以实现起来又不会太简单会有一定的难度。涉及的工具AI Agent 平台 WorkBuddy 之所以没用Codex或者Claude的原因也很简单够用就行能省钱就省呗 整个开发过程全程仅使用WorkBuddy免费赠送的积分开发强度不大捡便宜的引擎用的话差不多够用AI编程引擎主要使用WorkBuddy内置的DeepSeek V4 以及腾讯自己的混元Hy3/Hy4至于好不好用后文会简单总结一下游戏背景音乐生成即梦Suno加工处理 Adobe Audition界面音效https://elevenlabs.io/https://freesound.org/加工处理 Adobe Audition玩家头像素材生成即梦GPT加工处理剪映PSAI编写的工具等开场视频生成 SeeDanceVidu剪辑加工剪映其它各类素材https://itch.io/Photoshop自制等等以上大体用的都是免费的版本也有少量视频素材是用即梦的付费会员版本生成的。不过一次性播放的开场视频只是锦上添花有没有对游戏整体影响不大加上即梦的会员我本来就有不是专门为开发这个游戏买的所以也勉强可以称之为全免费吧。整体开发回顾人机协作4个阶段从手写代码到只做决策阶段一基础框架构建 自主代码开发 AI辅助学习 不少人使用AI开发的误区是一上来就0帧起手全权托付恨不得一句提示词就完成所有工作。当然这也是很多网传AI模型多么多么厉害的案例所宣导的。但我自己觉得我在开发全程中最关键的判断是在让AI写第一行代码前我先自己动手写完了占总代码不到10%左右的基础框架核心代码。不是不信任AI而是我不信任自己原因很简单此前我完全没有接触过UnityC#语言虽然不能说没有基础毕竟十几年前也写过几年C但总体来说还是一门不同的语言。对Unity的开发模式模块功能游戏构建逻辑乃至业界最佳实践也基本没有概念。所以如果没有动手实践的体感完全交给AI来做的话我大概只能看个“能跑就行”根本没有判断对错、取舍和甄别隐患的能力。对于在古法编程环境下成长起来的一代是很难放心自己完全没有掌控项目代码的能力的。所以我花了大概十天的时间自己搭建了游戏的基本框架雏形一来熟悉一下Unity的开发环境构建逻辑和基本功能模块二来熟悉一下C#语言本身这阶段我完成的工作主要包括最基本的项目场景的搭建MVC模式的代码框架的构建棋盘与棋子的核心数据结构的构建棋子能力的标准化可拓展框架的初步构建那么这个过程中是不是完全没有借助AI的能力呢当然也不是。毕竟Unity和C# 我都不熟而Unity本身对C# 也有一些语法糖拓展。所以这一阶段我主要是向AI问问题借鉴经验比如Unity的各种功能模块的能力有哪些如果要开发一个什么功能Unity引擎有什么可用的模块可以使用业界的常见实践是什么有没有成熟的社区库或者插件Plugin帮我写两个Demo代码示范一下如何使用之类。总体来说是为了尽可能避免走不必要的弯路。换在以前我的学习路径大概会是先找本《C# 从入门到精通》读一遍然后再看两本《Unity游戏开发之道》之类等到真的动手开发游戏的可能两三个月已经过去了。这一次当然还是学习了几个Unity自带的教程案例但有了AI作为基础知识灌输和能力兜底心里不慌前期的学习准备时间也确实大大缩短了。至于手工编写部分基础核心代码事实证明这样做也是完全有必要的因为Unity游戏的开发除了代码以外本身还有大量的工作是需要在Unity的可视化环境里手工构建界面和场景和代码需要结合在一起才能工作你得理解基本的工作原理。另外我用的是Unity6.5国际版的版本不是国内专用的Unity团结引擎的版本基于6.0之前的Unity引擎分叉的6.0之后的引擎很多API和核心功能模块都进行了更新换代AI学习过的代码很多都是老版本的实现虽然能用但毕竟不是最优解。也需要甄别。这部分工作完成以后虽然整体游戏只是有一个基本的雏形框架大多数功能都还未实现但我对后续的工作转移向使用AI哪怕是完全使用国内的AI 引擎和开发平台而不是如Codex这样的当前最强方案我也有了足够的信心因为即使后续AI生成的方案和代码不靠谱最坏的结果我也能自己接手过来。阶段二游戏核心关键模块功能开发 我写设计文档AI细化设计并1落地代码我重度审核文档和代码少量介入修改框架搭建练手完毕进入核心功能开发这部分工作主要是把Philosophy桌游的规则设定变成游戏的功能逻辑虽然规则是确定的但是如何实现却有很大的自由性作为老派的程序员我当然还是希望整体的功能实现是足够通用具备可拓展性核心逻辑具备较好的模块化能力和可读可理解性比如每个棋子的能力是独立自洽的和其它逻辑解耦能以最低代价添加新的种类的棋子能力。无论人下棋还是AI下棋还是回放对局又或者是远程对战不同的对局操作路径是可插拔替换的总的来说这部分模块因为其设计对架构影响面较大属于核心能力层所以我大体上是先手写一份功能核心需求以及架构方面的约束限定要求然后让AI根据需求和架构的限定约束写完整的功能模块设计文档然后我审核设计文档针对架构提改进要求反复让AI重写设计文档直到我满意为止。之后再让AI根据设计文档落地代码开发工作主要的核心模块我可能还会重度Review代码有时候一些代码我也会直接做一些简单的修改和调整找Bug倒是其次主要还是为了确定自己掌握了这部分代码的核心逻辑不要和设计文档有较大的出入偏差说到底还是让自己放心。这部分的模块再举两个例子比如游戏核心流程的全程指令化构建所有的操作都以Request和Command的形式抽象出来用一个抽象的Player类承载Request的执行和Command的生成只所以要经过两层中转而不是从界面操作直接导向结果是因为这样无论Player是具体的玩家AI还是回放又或者是远程玩家的Remote代理都可以用一个具体的实现进行标准化的替换而Command的形式也确保每一步操作都可以被持久化记录和回放。静默推演和动画调度框架的实现棋类游戏没有动画比如棋子从A点移动到B点表现层肯定是不行的而动画和音效的执行是穿插在游戏过程的各个角落的同时和游戏逻辑有很强的耦合性但这部分代码又不能写死因为不同的执行路径可能表现形式不一样比如AI在推演后续的下法的时候肯定是不能触碰场上局面也不能有任何视觉上的呈现的也就是需要具备静默推演的能力而如果涉及到回放远程remote操作之类也可能需要加速或者静默部分视觉动画效果。最终的设计我还是比较满意的整体是双路分离架构从架构上隔离 AI 推演与前台表现避免推演过程直接影响真实棋盘的表现状态真实棋盘演出层负责展示棋子、动画、音效、界面交互呈现玩家可见的所有对局效果。纯数据棋盘思考层仅运行坐标、方向、状态、规则逻辑不关联任何画面表现。AI的所有推演、试算、预判全部在纯数据后台完成遍历所有落子可能、模拟原作规则下的连锁反应、预判对手攻防、多步推演局势。当然前提是所有的核心数据和流程状态需要具备可快照拷贝的能力用于多步推演等这样才能做到整套AI推演过程完全独立不会干扰前台动画、音效、缓存不会造成画面卡顿、逻辑混乱。当AI完成最优决策后仅将最终的指令同步给前台真实棋盘完成一次完整的对局操作。这部分核心模块大概只占整体20%左右的代码但开发工作量和开发周期大概占了60%阶段三游戏完备性和增强性模块功能开发 我提需求AI输出方案我仅审核文档基本不介入代码这部分的模块比如I18n多语言的支持音乐和音效定义和播放系统可编排的教学系统角色和语录系统网络远程对战模式支持等等。代码总体大概占40%以上但开发工作量和开发周期大概只占20%之所以要审核文档是因为这些模块多半还是涉及到最终玩家的交互体验所以无论从功能需求还是实现逻辑上还是需要一定的把控好不好用顺不顺畅还是得由人来决定。又或者我自己作为重度用户比如我需要用可编排的教学系统来完成Tutorial向导教程的编写我需要用I18N框架来做多语言支持需要使用因此需要明确应用逻辑是否满足我的需求。但从代码实现层面上来说这些模块的逻辑相对明确固定自身功能也相对模块化影响面小实现的好坏从结果上容易判断所以我基本上也就不再关心代码的具体实现好坏是否优雅是否易于拓展等等。举个例子网络对战模块是我在整体游戏都基本开发完毕后期才让AI添加的功能。直觉上这会是一个开发量比较大的模块。因为内容上涉及网络数据协议定义数据传输编解码创建远程对局广播地址局域网和广域网兼容监听和维护连接保持心跳检测掉线双端数据一致性校验远程Remote玩家代理远程命令回放状态对齐等等工作但事实上因为前期有游戏整体指令化构建和Player抽象接口承接的工作为基础这部分功能的实现并没有很大的难度纯粹只是工作量大但实现逻辑其实非常确定。所以尽管本地对战功能的实现最后涉及到了差不多5000行代码但方案设计加整体核心开发工作不到一天就完成了。我从头到尾没有看过一行代码核心联机逻辑在初次集成时基本跑通后续主要花时间处理网络环境、连接发现与跨设备验收阶段四游戏辅助功能模块和开发提效工具的开发 我提需求AI完成所有工作我既不审核文档也不介入代码这部分模块比如开场视频播放对局入场动画呈现角色语录的模仿生成模仿哲学家的语录还有十几个各种辅助开发提效用的工具列举几个比如开发者模式后门用于调试游戏比如重置游戏状态录制游戏过程和回放等等I18N多语言翻译查错同步完备性检查工具Puzzle关卡生成工具包括自动批量对局寻找适合作为谜题的残局局面记录并输出备选局面从备选局面按规则要求过滤并筛选生成Puzzle备选将局面转换为Puzzle关卡登记资产整理校验核对等一系列链路辅助工具。整体工具链涉及的代码约1万行。这个工具我还比较满意原来以为这个游戏设计Puzzle会比较困难但是通过这一些系列工具两三天就跑了几十万次对局完成了大量Puzzle关卡的设计虽然Puzzle质量好坏可能最终还是要人工验证Windows安装包配置文件生成Inno Setup配置文件编自动编译流程工具各种资产配置和一致性检查工具这类功能有一个共性效果直观、风险可控。因为属于外围模块加上代码量太大很多又是一次性或过程性工具所以基本上我只提需求然后验证结果结果不满意提bug再修改。Puzzle相关工具I18N国际化和本地化维护相关工具关卡编辑工具这部分代码因为很繁杂特别是辅助工具方面完全不会在最终游戏中呈现只是开发过程提效用放在过去我即使开发也一定不会随随便便就开发那么多的。整体代码大概占30%-40%但开发工作量和开发周期大概只占5-10%最后附所有主要模块代码分类统计仅C#代码不含可视化界面构建和配置文件经验和体感小结游戏好做不嗯不是太好做 其实这个游戏的核心模块工作量并不算大毕竟只是一个棋盘游戏要能玩很容易。但是周边各种菜单动画玩家头像设置存档教程PC和移动端兼容I18N国际化框架和本地化翻译界面布局美化素材和音效的生成和适配等等工作都要做完备的话工作量就要翻好几倍。而这些做完也只是能玩和好不好玩没有直接关系毕竟冷门抽象棋类游戏受众就很小之所以做Puzzle关卡也是因为想要增加一些游戏的挑战性和趣味性原桌游并没有提供Puzzle模式的内容完全靠自己设计。不过我也是当做练手所以认真的把这些模块都做一遍倒也是兴趣盎然。这些模块的框架可能也是能够在别的项目中复用的。说到底做游戏创意才是根源AI只是加速了产出但并不能降低创意本身的门槛。国产AI工具和引擎能用不好用不该怎么用这部分纯个人体感仅供参考这个项目全程用的腾讯的WorkBuddy 内置的国内AI引擎。我总体的感觉是如果能够明确的定义好需求控制好功能模块的规模大小约束好一些规范红线而不是希望一键脱手完成一个你自己都不知道该怎么定义需求的产品的话那么大部分大厂的最新模型基本上都是能较好的完成工作的。整体感觉 DeepSeek V4 干活废话少一点简洁一些加上消耗积分少所以我其实大部分的代码都是用它生成的。然后腾讯的Hy4和智谱的GLM5用的不多试了几个模块没有太大的差异感觉。甚至即使落后如腾讯的Hy3复杂一点的功能模块是做不了的但是写一些确定性的简单小模块也没有问题。那么和国外最强的编程模型的差距在哪里呢 我整体的感觉最大的差距是在宏观架构设计和代码的通用性和可拓展性方面。虽然没有直接对比同一个模块的代码实现但是前期核心模块的方案设计我都是让DeepSeek或者Hy4产出文档然后交给GPT去review的能很明显的看到GPT给出的方案修改意见考虑得更加周全更像一个有经验的架构师模块的划分层级的抽象业界最佳实践经验的应用潜在风险的规避后续工作的兼顾都有模有样我很少需要再提改进意见。而DS和Hy有时候则更偏向能用就行暴力求解的思路需要适当的加以引导和约束。另外注意不要让AI死磕一个问题比如如果有一个BUG AI修了2次还没有修好那么在没有其它信息的情况下我的经验体感是再修也很难修好了甚至会越修越糟糕因为AI找不到原因思路就会越来越发散越修越离谱。。。 这时候应该及时介入手动辅助做一些分析或调试工作。否则如果只是反复让AI尝试修一遍你再跑一遍那就不是AI替你打工而是你替AI打工了。因为也少量用AI做了一些图片素材包括UI菜单设计所以也比较一下这块的能力。整体感觉即使即梦的图像理解输出能力和GPT比也是有比较大的差距的倒不是说美感和艺术性方面而是在于语义的结合理解方面毕竟不是纯画美女可以天马行空而是需要结合游戏本身的内容构思理解游戏的背景并落地到图像素材上。这一点GPT给出的图像虽然后来我也很少使用主要还是人工处理了但往往有很好的参考价值而即梦给的图像基本和游戏本身的结合八竿子打不到一起去。另外有个很无语的例子UI素材往往需要使用透明背景的PNG图GPT能够按要求正常生成透明背景而即梦生成的图片我一开始也以为是透明PNG图因为背景里有那种深浅交错的网格多数看图软件用来表示是透明背景的地方后来才发现那根本不是透明背景而是即梦自己模仿看图软件画出来的网格有些网格画的还是歪的。。。妙啊这一招根本想不到安全方面还是要做好代码和文件安全防御及时上推Git。WorkBuddy整个过程中我遇到的误操作其实并不多但很明显权限控制的并不好经常会越出项目给定的目录范围操作文件。比如Unity开发中通常是把Assets目录作为Agent开发的项目根目录来用但是我写项目设计文档的习惯是放在Docs目录下和Assets目录平级WorkBuddy基本无障碍的能够读写Docs目录。也经常会写一些Python脚本来操作文件包括Assets之外的虽然这都是完成工作必要的但还是有一定的风险。整个项目过程我遇到过两次Agent写的Python脚本有问题误删了文件的情况虽然影响都很小还都挺诚实的告诉我它惹祸了。有一次误删了一个最新的还没提交的代码文件Agent默默地花了大量的token去下载各种工具反编译输出二进制文件企图复原文件我也是服了。。。先输出设计文档再输出代码但凡有可能先让AI写方案设计文档再写代码。其实在古法编程时代这也是一个优秀的软件工程师应该养成的习惯何况现在让AI写设计文档并保持与代码同步更新这也是之前很多人不写文档的原因的代价几乎可以忽略不计。有时候同步更新的太勤快我还嫌它费Token改一行代码以为很快就完事结果设计文档代码内注释引用注释等等修改了一大串。。。从人的角度来说审核文档的代价远低于review代码的代价这也是你能快速把控AI产出的有效途径。事实上因为我是Unity新手很多业界实践也没有概念我从AI的设计文档中也学习到了很多经验知识。从AI的角度来看虽然现在很多Agent平台都有各种memory记忆机制但这并不能代替一份条理清晰内容完整的设计文档。设计文档对于精确控制AI行为对齐逻辑多引擎交叉验证乃至后期维护人工结果验证功能补缺查漏等等都有着不可替代的作用。所以哪怕后期第四阶段的工作我实际上已经完全放手既不看文档也不看代码但依然让AI保持设计文档先行代码输出在后的习惯无它有备无患。事实上这已经不是我的习惯而是成为我的WorkBuddy记忆中明确落地的规范要求了。不是我写的是WorkBuddy自己记录和更新的模糊的需求只会带来无限返工清晰的标准才是AI高效产出的前提。工具成本很低高频重复工作甚至一次性的工作也可以考虑工具化把时间留给方案设计、体验打磨这类核心工作AI有多厉害不重要你能如何把控它才重要。上架以前做开源项目和欧美程序员打交道没有太多体感感觉多数项目的维护者和参与者工作都还挺有效率的。这次因为做这个桌游的电子化虽然是自娱自乐但为了真实体验还是想如果能上架就一直做到上架为止。所以尝试联系了一下德国那边的出版商想问一下版权问题。结果一个多月过去了至今对方只回过我一封邮件还是告诉我说哦你的邮件我收到了感谢你有兴趣我就是先告诉你我收到了哈至于具体问题以后再回你哈然后就再也没动静。。。 问了一下和他们打过交道的国内桌游出版业从业者说是能以月为单位回邮件的已经是佼佼者了甚至有以年为单位回邮件的。。。遥遥无期等待版权方回复中不过Steam上架也需要做一些SDK的接入开发最关键是还需要花100美刀的上架费还需要打磨一下谜题关卡的设计如果要做广域网对战功能还得配域名和服务器作为联机的中转服务。。。。作为一个大概率卖不出去的冷门游戏这些开销估计也是肉包子打狗有去无回了。。。好吧自娱自乐自己开心就好。在此之前 有想试玩的朋友可以私下找我。代码和文档因为这个游戏本身是有版权方的所以代码估计是不能开源了。不过相关的设计文档我觉得还是有一些有一点点价值的主要是各个和具体游戏无关相对通用的模块比如i18N框架的构建和使用其实Unity自己有国际化框架但是比较复杂动画系统的设计音频音效系统的设计Command系统可编排式教程系统头像语录系统AI推演系统之类的设计虽然这些模块在这个游戏中的设计也比较简单毕竟游戏规模不大不需要很强很完整的能力但确实是我实践过可行的方案用起来感觉也还算舒坦。没有做过相关工作的初学者有兴趣的话可以参考一下。结语AI写代码人守住创造回头看这38天我最大的感受不是AI能写多少代码而是它改变了我完成一项工作的方式。更重要的是降低了我开始一个新的尝试的心理门槛。以前有些事觉得太费力成本太高拖延很久也不会真正动手但现在不一样了。有人说这是最差的时代也有人说这是最好的时代怎么说都对一切都看你自己如果你也在用AI辅助开发你会把哪些工作交给AI又有哪些事情一定要亲自把控欢迎聊聊你的经验。