【Unity 中国 24 小时开发挑战赛】《边际棋盘》开发日志 & Tuanjie Cowork 使用分享¶

记录和分享团结引擎 24 小时 VibeCoding GameJam 比赛的开发过程，包括 Tuanjie Cowork 的使用，一站式完成策划、美术、程序、测试的工作。

10 月 17 日下午 4 点至 10 月 18 日下午 4 点，Unity 中国举办了 24 小时 VibeCoding GameJam 比赛，我们团队全程使用 Tuanjie Cowork 工具进行开发，包括策划、程序、美术、测试。最终我们也是非常感谢现场的各位开发者的喜欢和投票，《边际棋盘》获得了人气第二，我们团队成员都感到意外和开心。

这篇文章想完整记录一下这 24 小时：我们做了一款什么游戏、团队如何用 Tuanjie Cowork 把策划、美术、程序、测试一站式跑通，以及整个过程的复盘。

如果你对 Tuanjie Cowork 进行游戏开发感兴趣，欢迎阅读并在评论区留言！为我们的《边际棋盘》提供宝贵的建议，也欢迎你分享使用 AI 工具的经验。

一、作品展示：《边际棋盘》¶

【大纲说明】 开篇即展示成品。任务：让读者 30 秒内知道作品是什么、好不好玩、去哪玩；同时说明发布本文的三个目的。

《边际棋盘》是一款类拼图的游戏，玩家将扮演一位棋盘使者，随机刷出不同形式的方块，填充棋盘的格子，为女巫铺设前行的道路，最终到达关卡终点。

棋盘格子具有通行属性和效果属性，玩家需要根据方块中格子是否可以通行以及它的效果，合理规划路径，才能顺利通关。

Demo 一共设计了 5 个关卡，棋盘大小逐步增加，效果属性也会逐渐丰富，玩家需要在有限的步数内完成关卡目标。

【素材：封面图（横版 16:9，主视觉或主界面截图）】

【素材：第一个关卡的视频，或者 GIF】

【素材：游戏下载以及试玩入口】

二、开发日志¶

首先 本次的主题是“边界之间” 可以有虚实边界 人与 AI 的边界 现实与虚幻的边界 城镇与自然的边界 也就是说 我们整个是围绕着“边界”进行设计的 那么我们在前期讨论的时候 想到了有《王之凝视》《无尽战争》，1. 《王之凝视》： 这款游戏里有一个国王，他的监视有一个边界范围。在监视空间内的城镇居民效率就会提高，玩家需要去调整这个边界来闯关。这其实就是一个关于“边界”的很好案例。

1. 双层地图切换： 我们还想到一种在中间画一条线，将左右区分，两层地图叠加在一起的机制。玩家可以通过这条分界线实时切换两个世界，操控这两个世界的边界。这偏向解谜和剧情类型，需要对关卡有一些特别的设计。

2. 2D 和 3D 视角切换： 另外我们还想到 2D 和 3D 的切换。比如在跑酷闯关阶段，通过视角在 2D 和 3D 之间切换，这也是一种边界。

最终，我们还是会把这些机制归纳为两类： 第一类：以玩家操控边界为主。 第二类：边界是已经设定好的，玩家偏向于适应边界，在边界的框架之下进行游玩。我们对于边界的调整，可能只是一个道具或者一个小功能，需要通过边界来触发，但整体上我们还是在边界的框架之下进行游玩。

最后，我们突然想到了一个拼图类型的机制，也就是我们的“边际棋盘”： 1. 机制玩法：就像俄罗斯方块一样，随机刷新出几个地块，然后由我们去铺设。 2. AI 设定：女巫属于一个 AI，她会根据我们布置的边界路径去行走。她没有自由通行的机制，一切全部靠我们为她设计的可行走边界。

想到这个问题和这个小玩法之后，我们首先通过 cowork 的 Kimi K3，根据我描述的内容，把这个机制做成了一个网页版的 demo。因为 Kimi K3 在网页设计这一块还是比较有优势的，所以我们使用了 three.js 来形成这个能够表达的小 demo。

之所以这样做，是因为我们在讨论和表述这个机制的时候，大家都没有看到图，就比较难以理解。于是我们花了大概 20 到半个小时的样子，让 K3 跑出了这样一个网页。

【素材：Cowork 截图】 【网页版的截图】

总结来说，在策划阶段，我们可以把核心玩法归纳起来，使用 Co work 先做一个非常非常简陋、包含了核心玩法的白模，也就是 MVP。

把游戏最核心的玩法先设计出来，让它起码能够点击、可玩，并在一定程度上展现整个 demo 的设计。这比起我们直接用文字来表达会更加清晰，这也是现在 AI 能够达到的一个效果。

这一点，我也在之前团结引擎的一些分享中提到过，就是使用 Three.js 的网页，再转到团结引擎中直接实现。

当我们确定好了核心玩法，也就是通过使用这个 demo（网页版），发现确实有可行性，整体玩法也比较清晰。另外，扩展点也是存在的：

1. 棋盘与格子：棋盘的大小以及格子的效果，是我们最大的扩展点。
2. 道具与路径规划：棋盘上的道具，甚至是起点和终点的位置。关于如何规划路径，我们可以增加更多的约束，让玩家在有约束的条件下发挥更多的想象力，以及快速判断的能力。

那么策划这一块，我们在 cowork 上的使用就基本解决完毕了。

当然，在正式生成 demo 之前，我们也可以通过 cowork 的 AI 模型来梳理整个策划案。我们可以把策划案讲给 AI 听，让它来提出一些反问，指出哪里有非常不明、不合理的设计需要改掉。在前期确认文档的时候，这也是一个非常不错的方式。

接下来我们就是做开发以及美术，这两块肯定还是同步进行的。

一开始，因为我看到团结引擎之前分享过，Jason 做的 Three.js 网页可以直接转入到团结引擎中，所以我就直接让他去转。但是最终转出来的效果并没有很好地表现出来，一次性转得不够完善。当然，这也可能是因为我们的网页版 demo 本身也不是非常完善，很多规则都没有写得特别明确详细。所以这一块我们暂时花了时间去尝试跑了一下，但是效果不是很行。于是，我们还是将整个开发任务细分到了不同的进度和任务中，遵循基础的开发过程。 也可以放一张相关的分享的截图 整个游戏的程序化部分其实划分得比较简单： 1. 主界面：也就是整个的操作环境，包括主界面的一些设置、提示消息，以及流程的开启和关闭。 2. 中间的关卡选择：关于关卡选择，我们最初在美术方面做了一些不同的设计思考，想在关卡地图上增加一些文化元素，让每一个关卡换一种风格。但后来因为工作量比较大，整个风格不好统一，所以就先做了一个简单的关卡选择。 3. 核心玩法（战斗场景）：这是最重要的一点。在战斗场景中，我们需要再去细分它们的关卡和进程。

在程序开发阶段，我们使用 Git 来进行不同开发者之间的同步。具体流程如下： 1. 首先，我们会使用腾讯的 Git 桌面客户端 UGit 来进行一些初始化操作。 2. 然后，让 AI 读取关于 Mac 和 Windows 之间注意事项的文章，直接对我们的项目进行初始化。

这是快速适配团队成员的一种方式。成员不需要自己去部署，特别是不用自己详细设置项目的环境配置，也不用处理太多的设置，只需要让 Cowork 直接去处理即可。

程序方面，为了我们之后能够进行人工审查和开发，我们团队在代码架构上采用了一个框架设计，让 AI 遵循这个框架去进行开发。

为了保证 AI 能够遵循框架开发，我把整个框架投喂给 CoWork，让它根据我们的要求来生成对应的 skill。比如，我让它创建了一个“项目启动设置”，帮我们项目直接配置启动场景。关于这个启动场景 skill 以及整个框架如何使用，需要遵循以下规范去编写代码：

1. 逻辑与表现分离： 把最基础的数据源、逻辑以及最终的表现区分开来。也就是说，实际的游戏逻辑、控制表现的代码以及最终的数据源都要分开，这样便于我们之后的扩展，而不是直接一股脑全部放在 Model、Behavior 等单个脚本上。

2. 单例控制： 对于单例这一块，我们也要进行一个控制。3. 开源项目介绍： 这里填上我的开源项目。这是一个参考 QFramework 做的一个适合 Odin Inspector 的极简框架。 (a) 架构方面：主要包含极简架构，支持最基础的 MVC 和 MVP。 (b) 适用人群：对于框架初学者来说非常有效，能够把整个结构梳理清楚。 © 数据流管理：让获取数据源的路径收束在一条路上，避免数据到处漂移，或者单例在项目中满天飞的情况。 (d) UI 响应式：在 UI 方面采用响应式的观察者模式监听，简化了代码，也让整个结构更加清晰。 这里可以放一张截图

所以这就是 cowork，也就是 AI 编程与传统编程的配合。

1. 缺乏框架的弊端： 如果不对 AI 提前设置一些规范或规定，没有构建起架构的 skill，它写的代码通常就会比较随心所欲，怎么实现快就怎么来，没有章法。特别是当项目变大，如果代码还不是在同一个会话中生成的，就很容易出现各写各的情况。

2. 建立框架的优势： 有了起始的框架，能让 AI 按照这个框架去编写，在一定程度上可以缓解上述情况。日后如果真的需要手动梳理代码，也会是一个更方便、更快速的选择。

3. 实践建议与本次情况： 如果有条件、有时间，我们一般在完成一部分功能后，就要尝试使用 AI 把整个代码结构梳理一下。当然，在本次 24 小时活动中，我们其实只是在最开始做了一个规则约定，后续并没有去查看代码并优化结构。但从我们的文件夹目录结构来说，整体还是比较清晰的：主菜单、数据源以及一些全局资源的引用路径，都放在了不同的位置和类中；战斗系统这一块也有专门的文件夹，并且整体也有数据源的设置以及存档相关的内容，整体还是较为清晰的。

不过，我们之后如果要进行开发，肯定还是要对这个进行梳理。至少通过这种 skill 的方式，能让结构比没有 skill 时更加清晰。所以，如果你在开发过程中有自己的一套框架，可以把整个文档和框架的源代码全部提交给这个 cowork，让它根据这个框架创建一个或多个 skill。这样可以控制代码的走向，便于之后的扩展。

接下来就是实际的开发。实际开发需要遵循一些基础的开发进程，即版本化、目标化，拆分小目标。

在分工时，我们要尽量避免操作同一块内容。因为我们团队有 3 个写程序的，为了合理分配，我们刚好分成了这三份： 1. 主菜单 2. 观察线选择 3. 战斗场景我们每个人都自己创建了一个场景。在整个代码开发过程中，我们使用了一个 tests 测试文件夹，下面再设置以各自名称命名的子文件夹，用来告知其他开发者这一块的内容是谁正在负责的。对于每一项小功能，我们都是先跑测试，最后再并入主目录。

我们思考的是，把测试放在那里，其他开发者未来如果想要跑测试，就能看到别人正在做的测试功能，从而实现协作。这比起传统的“只在自己本地电脑上做开发、写分支、测自己的功能”要好。传统的做法分工过于细碎，别人看不到你正在做的内容。

对于我们这种小团队，或者说在现在 AI 的环境下，每个人的分工其实并没有那么细。如果要学习，每个人都能跑整个游戏的全部测试，肯定会更好。然后再传送、推送，别人看不到你的一些设计和功能的实现。将这两种情况相比，我个人认为还是 test 会更好。

另一方面，以前不这么做，可能有一部分原因是测试方面全部靠人工来写，会非常麻烦、耗时间。但是有了 AI，就压缩了这个时间。AI 优化了这种情况，另外它对于代码隔离也是比较方便的： 1. 避免人工冲突：我们自己人工去写的话，可能一不小心就会引入一些内容，导致互相冲突。 2. 独立测试环境：使用 AI，可以让它把所有的功能（包括脚本及其资产）全部单独放在一个特定的测试文件夹内。这意味着这是一个正在测试、尚未实装到主目录的功能。 3. 缩小影响范围：在这种情况下，它的脚本除了引用公用的架构性代码和设计之外，整个范围都被缩小在特定的测试文件夹内，每个人都写在自己的测试文件夹里。

这是 AI 做隔离非常方便的一点，它基本上不会影响到其他开发者。因为已经明确强调了这是一个正在测试、正在开发的功能，不要去影响其他部分。所有的代码都全部放在这个功能的测试文件夹内，即使它可能能够并入到主目录的一些脚本中，我们现在也会让它不要去直接写入。

另外，我们还接入了 Input System 输入系统，以及 Localization 本地化系统。

因为本地化既要接触 Unity 默认的本地化，又要使用 Addressable 资源管理。但在我们这个 Demo 中，我们使用最简单的 Resources 进行主资源管理，只是把本地化的文本使用 Addressable 进行管理。

此时我们可以看到，在 Skill 市场上面，有 Cowork 为我们预先设计的一些 Skill，就包括了本地化和 ScriptableObject。这些我们可以用来做一些配置开发，便于策划去调整。另外，Addressable Localization 以及保存档的一些 Skill 也非常方便。我们在开发功能时需要注意，有些 Skill 是需要手动激活的。比如在对话中编写并激活 Localization 技能，如果该技能使用比较频繁，或者匹配到了某些关键词，它就会主动激活；但如果两个技能比较相近，有时候我们还是需要去手动激活一下。

我们直接使用这个 Skill 去配置 Localization。一开始我们完全没有去动过，既没有手动创建资产，也没有去配置表单，这些全权由 Cowork 来创建资产和表单，然后再应用到我们的按钮上，全部都是 Cowork 自己操作的。

由此可见，Cowork 不仅能够修改代码，它甚至可以完全操控 Unity 的资产生成与修改，以及预制体的创建，这些完全都是可以做到的。 你这里可以截一些预设 skill 的截图。Cowork 的一些预设 skill 其实非常多 它也有架构设计 当然 我们本次有自己的架构 就没有直接去使用了

接下来，我们针对每一个小功能进行执行。对话一定要小，不要太大，尽量针对每一个功能去执行。

在 Git 合作方面，我们直接让 AI Co-work 去操作。因为有些预制体之间存在冲突，手动去核对细节、处理冲突是比较麻烦的。我们的具体操作流程如下： 1. 直接让 AI 在本地提交代码； 2. 远程尝试 fetch，fetch 之后再尝试 pull 下来； 3. 附上指令，让 AI 处理本次操作的一些冲突，保证功能正常运行。

这样 AI 就会自己去拉取并处理冲突。我们团队体验下来，这个效果还是非常不错的。

接下来就是一个美术。美术的部分，我们肯定是全权使用 AI 来生成美术素材。

在最开始的时候，我们可以通过 cowork 去搜索一下关于棋盘这一类游戏的美术风格以及美术布置，作为参考。具体操作如下： 1. 搜索参考：直接在 cowork 里面搜索市场上现成的有关棋盘的美术风格，以及相关游戏的界面设计大概是什么样的。 2. 联网获取：我们可以激活 cowork 的 web access 技能，它会自动联网搜索，最终返回给我一个相关的文档。 3. 寻找灵感：美术同学就可以在这个总结出来的文档里面去寻找灵感，确定最适合我们这个游戏的美术基调。

因为 AI 美术肯定还是需要一个基础的参考的。

3.1 策划设计¶

• 核心玩法：【待补充：玩法一句话 + 规则要点】
• 单局流程：开局 → 核心循环 → 结算，【待补充：每个环节 1–2 句说明】
• UI 布局与信息层级：玩家第一眼需要看到什么、哪些信息常驻
• 24 小时的取舍：为了完赛被砍掉或简化的需求【待补充：被砍需求清单，这是读者最有共鸣的部分】

3.2 程序设计¶

• 技术栈：团结引擎 + 渐进式 MVC 架构（基于我们开源的 Aesir Architecture / Aesir Modules）
• 为什么这么选：GameJam 只有 24 小时，UI 框架、音频管理、场景加载这些轮子直接用现成模块，把时间留给玩法本身；架构上采用最低成本的"快捷档类结构 + 标准档 Model 暴露面"方案，保证跑得动、改得动
• 模块划分：Context / Model / UI 面板窗口各司其职，数据流单向：输入 → Model 写方法 → 通知 → UI 刷新

【素材：项目目录结构截图、架构示意图（可选）】

3.3 美术设计¶

• 风格定位：【待补充：风格关键词，如扁平 / 像素 / 低多边形，附参考作品】
• 素材生产流程：【待补充：AI 生成 / 手绘 / 素材库的比例，以及如何与策划需求快速对齐】
• UI 视觉与动效：在 24 小时限制下，UI 如何做到"够用且不拖后腿"

【素材：美术风格参考板、主要资产展示拼图】

四、游戏亮点与试玩邀请¶

【大纲说明】 任务（a）：提炼 3 个左右亮点，每个亮点配一段"是什么 + 为什么有意思"的说明和对应素材；结尾再次发出试玩邀请。

24 小时的作品不敢说完美，但有几个点我们自己觉得值得一试：

1. 亮点一【待补充：一句话亮点 + 2–3 句展开】
2. 亮点二【待补充：同上】
3. 亮点三【待补充：同上】

【素材：每个亮点一张 GIF 或 15 秒短视频；宣传图 1 张】

最好的了解方式还是亲手玩一玩——试玩入口在这里：【待补充：链接 / 二维码】。玩完欢迎回来告诉我们你的感受，任何建议都对下一个版本有帮助。

五、工作流程分享：Tuanjie Cowork 在团队里的 24 小时¶

【大纲说明】 任务（b）：本文重头戏。记录并展示团队使用 Tuanjie Cowork 的完整工作流程，呼应赛事 VibeCoding 主题。结构：为什么用 → 各角色怎么用 → 一个完整需求链路案例 → 经验总结。截图注意打码敏感信息。

本届比赛的主题是 VibeCoding，我们选择全程使用团结引擎的 Tuanjie Cowork 进行协作开发，目标是一站式完成策划、美术、程序、测试的工作。

5.1 各角色怎么用 Cowork¶

• 策划：用 Cowork 整理玩法需求、生成规则文档，把"一句话想法"快速变成全员能看懂的文档
• 美术：用 Cowork 生成与迭代素材，风格不对时快速换方案，而不是手工返工
• 程序：用 Cowork 生成和修改代码、定位报错；架构层面的约束通过项目级规范文件提前交代
• 测试：把跑出来的问题直接丢给 Cowork 辅助定位，缩短"发现问题 → 定位 → 修复"的回路

【素材：Cowork 界面截图、各角色使用场景截图（对话记录注意打码）】

5.2 一次完整的需求链路¶

【待补充：选 1 个最有代表性的需求，按以下链路写，每步配一张截图】

1. 策划提出想法：【待补充】
2. Cowork 整理成需求文档：【待补充】
3. 程序基于文档实现：【待补充】
4. 测试反馈问题：【待补充】
5. 迭代后进入最终版本：【待补充】

5.3 经验总结¶

• 提效明显的场景：【待补充：如样板代码、报错定位、素材迭代…】
• 仍需人工把关的场景：【待补充：如架构决策、玩法手感…】
• 上下文与规范管理心得：我们把架构规范写成项目级文档让 Cowork 全程遵守，这比每次对话里重复解释高效得多

六、整体复盘：这 24 小时我们学到的¶

【大纲说明】 任务：对全过程复盘，给想参加 GameJam 的读者可参考的经验。

• 时间线复盘：立项 → 原型跑通 → 核心玩法 → 美术进场 → 联调 → 封版提交，各阶段实际耗时【待补充：可做一张时间线图】，超时点在【待补充】
• 做得好的：分工清晰、架构不临时造轮子、Cowork 真正融入了每条线的工作流
• 没做好的：【待补充：如需求蔓延、沟通成本、最后时刻的 bug…】
• 如果重来一次：【待补充：1–3 条具体改进】

【素材：24 小时时间线图（可选，无则不配图）】

结语¶

感谢 Unity 中国举办这场比赛，感谢队友 24 小时的投入，也感谢每一位试玩《边际棋盘》并留下建议的玩家。

• 试玩入口：【待补充】
• 项目地址：【待补充：如有开源或展示页】
• 我的个人主页：https://yuumixcode.github.io/

如果你也在 GameJam 里用过 AI 协作工具，欢迎在评论区分享你的工作流——我们下次比赛见。