企业官网建设流程全解析

声明：本文为桌游移植项目复盘：规则源自桌游《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

  • 加工处理：剪映，PS，AI编写的工具等

• 开场视频

  • 生成 SeeDance，Vidu

  • 剪辑加工：剪映

• 其它各类素材

  • https://itch.io/

  • Photoshop自制等等

以上大体用的都是免费的版本，也有少量视频素材是用即梦的付费会员版本生成的。不过一次性播放的开场视频只是锦上添花，有没有对游戏整体影响不大，加上即梦的会员我本来就有，不是专门为开发这个游戏买的，所以也勉强可以称之为全免费吧。

整体开发回顾

人机协作4个阶段：从手写代码，到只做决策

阶段一，基础框架构建（ 自主代码开发 + AI辅助学习 ）

不少人使用AI开发的误区，是一上来就0帧起手，全权托付，恨不得一句提示词就完成所有工作。当然，这也是很多网传AI模型多么多么厉害的案例所宣导的。但我自己觉得，我在开发全程中最关键的判断：是在让AI写第一行代码前，我先自己动手写完了占总代码不到10%左右的基础框架核心代码。

不是不信任AI，而是我不信任自己

原因很简单，此前我完全没有接触过Unity，C#语言虽然不能说没有基础，毕竟十几年前也写过几年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，又有哪些事情一定要亲自把控？欢迎聊聊你的经验。