游戏开发日志05 在 TapTap Maker 里造一个神：我们的工作流实录

4 小时前2 浏览综合

大家好，第五篇日志。前四篇聊了游戏本身，这篇聊"我们是怎么把它做出来的"——准确说，是我们和 TapTap Maker 一起，是怎么把它做出来的。

因为说实话，这个项目的开发方式，和传统写代码已经不太一样了。

先说结论：Maker 不是"帮我写代码"，是"帮我维持一个世界"

《穹顶：司天者》是一个 Lua 项目，跑在 Maker 内置的引擎上：世界模拟、天气、信仰、异兽、UI、配音、发布，全在一个工作区里。

最开始我们以为 Maker 的价值是"生成代码快"。做了两周发现不是。它真正的价值是上下文不断：设计文档、平衡表、素材清单、错误报告、构建产物，全都躺在同一个地方，任何一次对话都能接上三个月前的决定。

对一个小团队来说，这比快更重要。快解决的是体力，上下文解决的是记忆力。

我们的实际工作流

① 设计先行，文档是唯一真源。
我们有一份 design-final.md，四十多条决策，每条写着"为什么"。每次开工先改文档，再动代码。有几次我们直接在对话里说"接下来都是设计类工作，不写代码"——整个下午只产出文档。听起来奢侈，但它让后面每一次实现都有据可查，包括"为什么删掉时代系统"这种事，半年后不用考古。

② 概念图当合同。
界面不是边做边想的：先出概念图，社区投票，通过的图就是"合同"。之后所有 UI 工作都是履约——从图上取色、切图标、对版式。我们在日志 02 里写过那场手术：心形、闪电、祈祷手、十二个科技字形，全是从概念图上切下来的真实像素。合同制让"好不好看"的争论变成了"对不对得上"的检查。

③ 小步构建，错误报告兜底。
Maker 的构建是一键的，改完代码随手一打，预览页立刻刷新。而它最好的功能可能是错误报告：真机或预览里崩了，平台会把带堆栈的报告推给你。我们两个最隐蔽的 bug 都是它逮到的——一个是 string.format("%d") 喂了浮点数，每帧报一次；另一个是 WebGPU 的裁剪矩形比渲染目标宽了 1 像素，每秒报几百条。没有报告，这两个 bug 在本地根本看不见。

④ 生成类资产走平台管线，但人做终审。
配音是先试音三选一、确认后逐句生成；音乐、音效、概念图同理。但所有生成物都过人手：语速太慢就重切短句，图标裁歪了就重裁，风格不统一就整批重出。我们甚至给自己做了个素材审核台（游戏里按 F2）：131 项素材分类浏览、看原始尺寸、试听音频。工具负责产量，人负责品味。