【More Than Coding】用 SOLO 网页 + 桌面客户端 成功复现“方杯头”动漫明星运动会

SOLO挑战赛专区
1

1.摘要：

使用 SOLO 网页端的 AI 编程能力完成需求梳理与代码生成，结合 SOLO 桌面端（MTC Windows 客户端）直接操作本地 Unity 项目进行实时调试，通过"Web 端规划 + 桌面端执行"的协同模式，从零完成了一款 Unity 2D 动漫奥运会游戏的完整开发。最终产出 42 个 C# 源文件，涵盖角色系统、5 个比赛项目、AI 对手、道具系统等完整游戏框架，并在本地 Windows 11 电脑上成功运行调试，最终打包生成了独立运行的 Windows exe 可执行文件。

2.背景：

我是一名游戏开发爱好者，一直想开发一款以经典动漫角色（如猫和老鼠的 Tom & Jerry、乐一通的 Wile E. Coyote & Road Runner）为主角的奥运会游戏，风格仿造《茶杯头》的复古手绘动画。但 Unity 游戏开发涉及角色系统、比赛逻辑、AI、UI、存档等多个子系统，代码量大、架构复杂，个人从零开始需要数周时间。我希望借助 AI 工具大幅缩短开发周期，验证游戏创意的可行性。

3.实践过程：

（1）任务拆解与需求梳理

首先使用 SOLO 的 brainstorming 技能进行需求梳理，通过多轮交互问答明确了以下关键决策：

  • 游戏引擎：Unity 2022.3 LTS（2D 模式）
  • 视觉风格：逐帧手绘动画，仿造《茶杯头》
  • MVP 角色：Tom、Jerry、Wile E. Coyote、Road Runner（4 角色，2 组食物链关系）
  • MVP 比赛项目：100 米短跑、跳远、游泳、花样滑冰、滑雪大回转（5 个项目）
  • 核心玩法：街机体育（每个项目独立操作方式）
  • 游戏模式：离线单人，含角色成长系统

然后提出了 3 种动画技术方案（逐帧手绘 / Spine 骨骼 / Live2D 混合），最终选定逐帧手绘方案以最忠实还原《茶杯头》风格。整个设计过程经过 5 轮分部分展示和用户确认，最终输出完整设计文档。

（2）实施计划制定

设计确认后，使用 writing-plans 技能制定了包含 29 个 Task、6 个 Phase 的详细实施计划，每个 Task 包含完整的代码实现、文件路径和提交命令。

（3）代码生成与并行执行

使用 subagent-driven 模式，并行分派 3 个子代理同时生成代码：

  • 子代理 1：核心框架（11 个文件）— Singleton、EventManager、GameManager、SaveSystem、AudioManager 等
  • 子代理 2：UI 系统（7 个文件）— MainMenuUI、CharacterSelectUI、EventSelectUI、HUDUI、ResultUI 等
  • 子代理 3：角色 + 比赛 + AI + 道具系统（23 个文件）— CharacterBase、5 个比赛项目、AI 系统、技能/服装系统

三个子代理并行执行，一次性生成全部 42 个 C# 文件。

（4）关键 Prompt 示例

需求梳理阶段的 Prompt：
“开发一个 Windows 游戏，人物来自经典动漫人物，比如猫和老鼠的 Tom 和 Jerry，人物要逼真还原原始形象，游戏可以选择喜欢的动漫人物，并且能添加人物的道具（选不同的服装和技能），游戏场景是全明星奥运会比赛，运动项目的名称和规则、地点都参考现实的夏季和冬季奥运会。场景风格仿造游戏《茶杯头》，每个比赛项目要有运动员和人物的出场展示环节，动作要诙谐有趣符合动漫人物自身的特点。”

代码生成阶段的 Prompt（子代理任务描述）：
“你是一个 Unity C# 游戏开发者。请在指定目录下创建以下角色系统、比赛系统、AI 系统和道具系统的代码文件。请严格按照提供的代码内容创建所有文件，不要修改任何代码。”

（5）踩过的坑与解决过程（Web 端远程调试阶段）

在本地 Windows 11（团结引擎 1.6.10）调试过程中，遇到了一系列问题，均通过 SOLO 网页端分析日志/截图后快速定位并修复：

问题 根因 修复方案
manifest.json 包解析失败 手动声明了已废弃的内置模块（input、wind、vehicles） 移除无效包声明
CS0506 override 错误 SprintAI 用表达式体 override 带 protected set 的属性 改为完整属性块
FilmGrain 类型找不到 使用旧版 PostProcessing 命名空间，不兼容 URP 迁移到 UnityEngine.Rendering.Universal
AIDifficulty 找不到 枚举定义在有依赖的文件中，级联编译失败 将枚举独立到单独文件
Singleton 泛型转换错误 _instance = this 无法隐式转换 改为 (T)(object)this
TMP 显示小方块 默认字体不支持中文和 Emoji 所有 UI 文字替换为英文 ASCII
按钮无法点击 代码创建 Canvas 时缺少 EventSystem 添加 EventSystem + StandaloneInputModule
EventSystem 被销毁 Destroy 循环误删 DontDestroyOnLoad 对象 添加场景名称检查跳过
No camera rendering Destroy 延迟执行导致旧相机干扰新相机 对 Camera 使用 DestroyImmediate
NullReferenceException Camera.main 在场景切换时返回 null 用 GameObject.Find 替代，显式设置标签

每个问题都是上传 Unity 编辑器截图或 Console 日志到 SOLO 网页端，AI 在 1-2 分钟内分析出根因并给出修复代码。

（6）MTC 桌面端 + Web 端协同调试（核心亮点）

在 Web 端远程调试解决了编译错误和基础 UI 问题后，项目进入了更复杂的运行时视觉调试阶段——角色不显示、出场动画缺失、坐标系错位等需要反复"修改代码 → 运行验证"的问题。此时切换到 MTC Windows 桌面端，利用其直接读写本地文件的能力，形成了高效的协同调试工作流：

协同调试工作流：

┌─────────────────────────────────────────────────────────┐
│  Web 端（规划 + 分析）          桌面端（执行 + 验证）      │
│                                                         │
│  1. 需求梳理 / 设计文档         ← 规划阶段仅 Web 端      │
│  2. 实施计划制定                ← 规划阶段仅 Web 端      │
│  3. 代码批量生成                ← 规划阶段仅 Web 端      │
│  4. 编译错误修复                ← 截图/日志上传分析       │
│         ↓                                              │
│  5. 运行时视觉调试 ───────────→ 桌面端直接修改代码       │
│     - 角色不显示                 桌面端实时写入文件       │
│     - 出场动画缺失               Unity 自动热重载        │
│     - 坐标系错位                 截图回传 Web 端分析     │
│     - 相机视角调整               或桌面端直接继续修改     │
│     - Canvas 层级问题                                    │
│         ↓                                              │
│  6. 迭代验证（8轮快速修复）     桌面端截图 + 日志回传    │
│         ↓                                              │
│  7. 最终验证通过                桌面端确认运行效果        │
└─────────────────────────────────────────────────────────┘

桌面端协同调试实战记录（8 轮迭代）：

轮次 问题 端 分析与修复 耗时
R1 赛道和角色不显示 Web UI 元素缺少 Canvas 父级，创建 WorldSpace Canvas ~3min
R2 出场倒计时 READY/SET/GO 不显示 Web CreateUILabel 传入 null 父级，添加 CountdownCanvas ~2min
R3 缺少角色出场动画 Web 重写 CreateSprintScene，加入完整 4 阶段出场流程 ~10min
R4 角色描述中文乱码 Web Unity 默认字体不支持中文，改为英文描述 ~1min
R5 比赛中角色消失 Web SetActive(false) 后 GameObject.Find 找不到对象，改用引用缓存 ~5min
R6 CanvasRenderer 缺失 Web 所有 Image 组件需要 CanvasRenderer 才能渲染 ~3min
R7 变量名重复编译错误 Web scaler 变量名作用域冲突，重命名为 entranceScaler ~1min
R8 第 4 个角色超出屏幕 桌面 相机 orthographicSize 和位置调整，赛道线对齐 ~3min

桌面端的核心优势体现：

  • 直接文件操作：桌面端可以直接读写本地 Unity 项目文件（Assets/_Project/Scripts/Runtime/RuntimeSceneBuilder.cs），修改后 Unity 编辑器自动检测文件变化并重新编译，无需手动复制粘贴代码
  • 实时反馈循环：修改代码 → Unity 自动重载 → 运行游戏查看效果 → 截图/日志分析 → 继续修改，形成分钟级的快速迭代闭环
  • 智能上下文保持：桌面端会话保持完整的代码上下文和历史修改记录，每次迭代都能基于前一轮的分析结果继续优化，无需重复描述问题背景
  • 灵活切换策略：对于需要深度代码分析的问题（如坐标系计算、Canvas 渲染管线），在桌面端直接阅读和修改源码；对于需要全局搜索和理解的问题，利用 Explore 子代理并行搜索项目文件

Web 端 + 桌面端协同的关键模式：

场景 推荐端 原因
需求梳理、设计文档 Web 端 brainstorming 技能需要多轮交互，Web 端体验更佳
代码批量生成（42 个文件） Web 端 subagent 并行生成，Web 端更稳定
编译错误分析（日志/截图） Web 端或桌面端 均可上传分析，桌面端可直接修复
运行时视觉调试（反复迭代） 桌面端 直接修改文件 + 实时验证，效率最高
复杂代码重构 桌面端 保持完整上下文，避免重复解释
项目文档生成 桌面端 可直接写入项目目录

（7）运行时场景自动生成

由于没有美术资源和 Unity 场景文件，额外开发了 RuntimeSceneBuilder 脚本（约 1400 行），在游戏运行时通过代码自动创建所有 UI 界面、Cuphead 风格角色形象（大头、大眼睛、白手套等 UI 元素组合）、角色出场动画（每个角色独特入场效果）、比赛场景和 AI 模拟，实现了无需任何美术资源即可看到完整游戏流程的效果。

（8）Windows 可执行文件构建

完成代码调试和场景验证后，使用 Unity 编辑器将项目打包为 Windows 独立运行的 exe 文件：

构建流程：

  1. 创建构建脚本：在 Assets/_Project/Editor/BuildScript.cs 中编写自动化构建脚本，包含：

    • BuildWindows()：发布版本构建（64 位 Windows）
    • BuildWindowsDevelopment()：开发版本（含调试符号）
    • 自动添加场景到构建设置
    • 构建报告输出

  2. 配置构建设置：

    • 打开菜单 File → Build Settings
    • 添加主场景 Assets/scenes-start.unity 到 Scenes In Build
    • 选择 Platform：Windows, Mac, Linux
    • 选择 Architecture：x86_64

  3. 执行构建：

    • 点击 Build 按钮
    • 选择输出目录 Builds/Windows/
    • 等待构建完成（约 2-3 分钟）

  4. 构建输出：

    • AnimeStarOlympics.exe：主程序
    • AnimeStarOlympics_Data/：游戏数据文件夹（包含资源、脚本、场景等）
    • UnityCrashHandler64.exe：崩溃处理程序
    • UnityPlayer.dll：Unity 运行时库

  5. 验证运行：

    • 双击 AnimeStarOlympics.exe 启动游戏
    • 确认 4 个 Cuphead 风格动漫角色正常显示
    • 验证完整游戏流程：主菜单 → 角色选择 → 赛事选择 → 开场动画 → 角色入场 → 倒计时 → 比赛 → 结果

桌面端在构建阶段的优势：

  • 直接执行构建命令：桌面端可以直接调用 Unity 命令行进行 headless 构建
  • 本地文件访问：构建脚本直接读写项目文件，无需网络传输
  • 实时查看构建日志：Unity 构建过程中的日志实时输出，便于排查问题
  • 快速验证构建结果：构建完成后立即运行 exe 文件验证效果

4.成果展示：

最终产出物：

  • 完整 Unity 项目：42 个 C# 源文件 + 项目配置 + 文档
  • Windows 可执行文件：AnimeStarOlympics.exe + AnimeStarOlympics_Data/ 文件夹
  • 设计文档：docs/superpowers/specs/2026-04-13-anime-star-olympics-design.md
  • 实施计划：docs/superpowers/plans/2026-04-13-anime-star-olympics-plan.md
  • 本地调试指南：docs/Windows11 本地调试指南.md
  • Trae + Unity 调试最佳实践指南：docs/Trae+Unity 调试最佳实践指南.md

游戏已实现的功能流程：

主菜单 → 角色选择（4 角色 + 属性展示）→ 赛事选择（5 个项目）→ 开场动画（Art Deco 风格标题卡）→ 角色逐一入场（独特出场动画 + 介绍卡片）→ READY/SET/GO 倒计时 → 100 米短跑（Cuphead 风格角色 + AI 模拟比赛 + 计时器 + 排名结果）→ 返回菜单

运行效果：

在 Windows 11 电脑上双击 AnimeStarOlympics.exe 即可独立运行游戏，无需安装 Unity 编辑器。游戏界面完整显示 4 个 Cuphead 风格的动漫角色（Tom、Jerry、Wile E. Coyote、Road Runner），包含完整的开场动画、角色入场展示、比赛模拟和结果展示。

项目文件已打包为 ZIP 供下载，包含：

  • Unity 项目源码（可在 Unity 2022.3 LTS / 团结引擎 1.6 中导入编辑）
  • Windows 可执行文件（可直接双击运行）

5.效果与总结：

（1）提效效果

  • 传统方式：从零搭建 Unity 游戏项目（42 个 C# 文件 + 架构设计 + 文档 + Windows 构建），预计需要 4-5 周
  • 使用 SOLO Web 端（规划 + 生成）：需求梳理 1 小时 + 代码生成 10 分钟 + Web 端调试 2 小时 = 约 3 小时
  • 使用 SOLO 桌面端（深度调试 + 构建）：运行时视觉调试 8 轮迭代约 1.5 小时 + Windows exe 构建约 10 分钟 = 约 1.7 小时
  • 总计约 4.7 小时完成 MVP（含 Cuphead 风格角色、出场动画和 Windows 可执行文件）
  • 提效约 25-35 倍

（2）SOLO 在流程中的角色

  • brainstorming 技能：结构化需求梳理，通过多轮问答消除歧义，输出专业设计文档
  • writing-plans 技能：将设计转化为 29 个可执行 Task 的详细实施计划
  • subagent 并行执行：3 个子代理同时生成不同模块代码，大幅缩短生成时间
  • 问题诊断：通过分析截图和日志快速定位 Unity 编译/运行时错误
  • 桌面端实时调试：直接操作本地文件，分钟级迭代修复运行时视觉问题
  • 桌面端构建支持：直接执行 Unity 构建命令，生成 Windows 可执行文件

（3）可复用的方法

  • "Web 端规划 → 桌面端执行"的协同开发模式：Web 端负责需求梳理、代码生成和全局分析，桌面端负责实时调试、迭代优化和最终构建，各取所长
  • "设计 → 计划 → 并行生成 → 迭代调试 → 打包构建"的五阶段工作流，适用于任何中大型软件项目
  • 上传截图/日志给 AI 分析的远程调试模式，有效解决网页端无法直接操作本地 IDE 的问题
  • 桌面端"修改 → 验证 → 构建"的分钟级闭环：直接写入文件 + Unity 自动重载 + 截图反馈 + 一键构建，将传统开发周期从周级压缩到小时级
  • RuntimeSceneBuilder 模式：用代码自动生成 UI 和场景，无需美术资源即可验证游戏逻辑
  • 引用缓存模式：用变量缓存替代 GameObject.Find，避免 Unity 对非激活对象的查找限制

~~~持续更新中~~~

2

诊断为 CC3 的迷弟

image
image960×702 174 KB

@CC3

1 个赞
3

你也是只鸽子吗

1 个赞
4

笑死我了哈哈哈哈哈

1 个赞
5

羡慕大佬，