每次向别人展示我们的游戏项目——Rust + Bevy 做引擎层、Lua 写玩法、AI agent 负责开发、素材由 Floniks 生成——对方的第一个问题几乎总是同一个：
"挺有意思。可是……编辑器呢？"
说实话，我们也动摇过。过去二十年，"游戏引擎"在多数人心里就是那幅固定的画面：左边场景树、中间视口、右边 Inspector、下面资源浏览器。Unity 是这样，Godot 是这样，Unreal 和 Cocos 也是这样。没有那幅画面，你好意思自称引擎吗？
直到真的用 agent 做完了八个小游戏——AI 生成的 sprite、背景和 UI 素材通过 Floniks 的 MCP 服务源源不断地流进项目——答案才变得清晰：对我们这种开发方式来说，编辑器不是还没建好的基础设施，而是一个负资产。"没有编辑器"不是我们的欠账，是我们的地基。
这篇文章是一次反思：解释为什么——更重要的是，完整盘点我们为美术与视觉配备了什么来取而代之。下面每一条主张都有开源仓库里的真实文件背书，不是路线图上的空话。
编辑器到底是什么
剥掉情怀，游戏编辑器的本质是一个 I/O 适配器：把人类的手——鼠标、拖拽、滑块——接到场景数据上。
它优化的是人类的输入带宽。人没法在脑子里想象 position: (312.5, -87.0) 长什么样，所以需要拖一下、看一眼；人记不住四千个 API，所以需要 Inspector 把所有属性铺在面板里；人凭感觉对不准颜色，所以需要取色器。编辑器的每一个控件，都是对人类感官与肌肉的一次迁就。五十年来这些迁就无比正确——因为操作者一直是人。
但代价也一直记在账上，只是我们不再去看：
- 场景文件是写给机器的，不是写给人的。 二进制或半可读的
.unity/.prefab/.tscn，diff 不可读、merge 靠祈祷、code review 变成"你打开编辑器自己看一眼"。 - 视口会说谎。 编辑器里的光照、导入设置、缩放和最终 build 永远差着一层。"在我的编辑器里是好的"是全行业的老梗。
- 一致性靠纪律，不靠构造。 风格指南躺在 wiki 里，三个美术画出三种描边粗细。编辑器约束得了坐标，约束不了审美。
当操作者从人换成 agent，这本账就翻转了。agent 没有需要迁就的眼睛和手——它的原生 I/O 是文本。给 agent 一个 GUI，等于给鱼一辆自行车；而上面那三项隐性代价，恰恰全部打在 agent 工作流的死穴上。
所以我们的选择很简单：不去造一个 agent 用不了的界面，而是把编辑器的每一项职能，替换成 agent 原生的形态。
我们为美术与视觉配备了什么
编辑器有五项核心职能：定风格、管资产、摆内容、调参数、看效果。下面逐项对照它们各自被什么取代了。
1. 定风格：一份可执行的风格圣经
传统流程里，美术总监的风格指南是一份 PDF；两周后有人在外包邮件里转述它，色板就开始漂移。我们把风格圣经写成了代码（tools/style_bible.py）。它的文件头写明了这套哲学：
"风格圣经唯一的职责，是让未来的每一张素材看起来出自同一只手。它的失败模式是漂移……把锁定的风格 token 编码成数据 + 一个小小的拼装器，就在构造上消灭了漂移——共享的 DNA 每次都是同一个字符串，唯一变化的只有每个素材的主体槽位。"
色板、描边规则、镜头视角、构图——全部是锁死的常量。每个素材只填一个槽位：它的主体（"a cute shiny red apple with a small glossy green leaf"）。想给整个游戏换风格？拨一个色板开关，全部重新生成。风格一致性从美术的自觉变成了程序的保证——这是任何编辑器都给不了的东西，因为编辑器约束的是坐标，不是审美。
2. 管资产：一份声明式清单
美术在这里是有源代码的。tools/floniks_manifest.json 里的一行，就是一个素材的全部真相：
{"name": "gem", "w": 16, "h": 16, "bg": "alpha",
"subject": "a cute glowing teal diamond gem, faceted, glossy"}
名字、精确像素尺寸、抠底模式（透明裁切 / 纯蓝键控 / 保留辉光的纯黑 / 满幅贴图）、主体描述。素材不是"某次生成跑出来的产物"，而是"随时可以从清单重放的结果"。 文件丢了？重跑。整套素材升到 2 倍分辨率？改 w/h 重跑。这就是游戏美术的 Infrastructure-as-Code。
3. 造资产：Floniks 管线
清单的执行者是一条骑在 Floniks 上的自动化管线，通过 MCP 调用：
风格圣经拼装 prompt → Floniks 文生图
→ 下载 → 按模式抠掉底色（每种模式有标定好的容差）
→ 精确缩放到目标像素 → 落入 assets/textures/
→ 同时输出 8 倍最近邻放大的预览图供人眼抽检
序列帧走切片器：生成一张 sprite sheet，切成 walk_0.png … walk_7.png，Lua 里十行的帧计时器就是动画系统。管线踩过的坑都沉淀在代码注释里——哪个模型真正尊重什么底色、哪个 API 要什么参数形状——伤疤成了管线的一部分，而不是某个人的记忆。
这一切之下还有一张安全网：纯标准库的程序化生成器零依赖地产出全套占位素材。游戏在任何时刻都是可运行的。 AI 美术是升级，永远不是依赖。
4. 摆内容与调参数：契约加热重载
场景树和 Inspector 被两样东西取代：
- 契约。 一页纸（
ART_REQUESTS.md）声明：任何素材只要同名同像素尺寸放进来，零代码改动直接生效。另一页纸（PACK_SPEC.md）定义一个完整的游戏包：一个工厂函数、一张自注册表、可用贴图清单，以及"必须暴露DEBUG表供无头测试驱动"的要求。菜单从注册表自动生成。任何一步都不需要在 GUI 里点。 - 热重载。 所有摆放和调参就是 Lua 源码里的数字——而 Lua、贴图、甚至 WGSL shader 都走引擎的资产管线，桌面端保存即生效。想让苹果掉得快一点？改数字，保存，看效果。Inspector 的滑块变成了"文本 + 秒级反馈"——对人不差，对 agent 是唯一可用的形态。
5. 看效果：运行中的游戏就是视口
我们没有编辑器视口，因为预览窗口就是正在运行的游戏进程本身——所见即所得的最终形态。没有导入设置的偏差，没有编辑器光照与 build 光照之别；你看到的每一帧就是玩家将看到的那一帧。运行时视觉 API 保证了表现力：可染色的灰度 sprite（一张贴图变出一族颜色）、旋转、缩放、换帧，一块随玩法真实起舞的全屏 WGSL 极光 shader——每个游戏的震屏反馈同时驱动着背景的能量——外加 trauma 衰减的镜头震动、四档触觉反馈和合成音效。
验收也不靠眼睛盯：677 行的无头不变量套件驱动每个游戏跑上几万帧，断言"手感契约"——不穿模、不瞬移、速度有上限、命中必有反馈。编辑器让人看见，测试让 agent 看见。
为什么这超越了编辑器
把五件东西拼起来，会得到编辑器在原理上给不了的能力：
- 美术可以整体重生成。 改一个风格 token → 重放清单 → 一小时内得到一整套彼此一致的新素材。在编辑器流程里，这叫"美术返工三周"。
- 美术可以被 code review。 一次美术改动的 PR = 清单 diff + 预览图——可以回滚、可以 blame、可以在评论区争论描边是不是太粗了。二进制场景文件永远做不到。
- 一致性是构造出来的，不是要求出来的。 同一条 prompt DNA、同一张容差表、同一道像素化工序。不存在"新来的美术不知道规范"。
- 玩法与美术在同一个循环里。 同一个 agent、同一次会话：调 Lua、发现缺素材、调 Floniks、按契约落位、热重载、跑测试、提交。在传统管线里，这是两个部门、一道导入流程加一场会议。
- 对话即编辑器。 "把苹果画得更红一点、高光更亮一点"——这句话就是一次完整的编辑操作：agent 改清单里的主体词、重放管线、热重载给你看。编辑器把意图映射到鼠标轨迹，我们把意图映射到自然语言。后者的上限显然更高。
也要诚实地写下代价：这套流程假设操作者是"一个人加一个 agent"。 不通过 agent 工作的传统美术或关卡策划，今天在这里没有明显的落脚点；需要人手精摆几百个物件的关卡类型也还没有顺手的工具（可能的答案——关卡即数据、agent 生成、不变量测试——在我们的路线图里，不在仓库里）。编辑器五十年的人体工学积累是真实的。我们不是说编辑器错了，而是说它所优化的东西——人类的手——已经不再是我们循环里的瓶颈。
我们今天能输出什么
| 形式 | 管线 | 状态 |
|---|---|---|
| 透明底 sprite | Floniks 生成 → 抠底 → 精确像素缩放 | ✅ 生产中（仓库约 60 张） |
| 可染色灰度贴图 | 同上 + 运行时染色 | ✅ 生产中 |
| 序列帧动画 | sprite sheet → 切片器 → 换帧 | ✅ 管线已通 |
| 全屏背景 / 竞技场 | 竖幅生成，满幅模式 | ✅ 生产中 |
| UI 素材（按钮、装饰） | 同 sprite 管线 | ✅ 生产中 |
| 程序化动态背景 | 手写 WGSL，随玩法起舞 | ✅ 生产中，可热重载 |
| 音效 / 循环音乐 | 今天是合成 WAV；下一步接 Floniks 文生音乐 | ✅ / 🔶 |
| 字体 | TTF 直接进包 | ✅ |
| 营销素材 | 截图已入库；图生视频预告片 | 🔶 |
尚未支持：骨骼（Spine 式）动画、粒子、tilemap。每一项都有具体计划，而且"编辑器"依然是数据加 AIGC——骨骼 rig 是一份 agent 可写的 JSON，部件由 Floniks 分层生成；tileset 按风格圣经出图集。与主流引擎的完整对比表和四阶段路线图在仓库的 docs 目录里。
跨平台吗？
分三层回答，不含糊：
素材层：100% 可迁移，零锁定。 一切都是 PNG、WAV、TTF、WGSL、Lua、JSON——没有私有场景格式，没有编辑器工程文件，没有导入数据库。WGSL 可编译到 Metal / Vulkan / DX12 / WebGPU。哪怕明天决定放弃我们这套栈，每一份素材都能原封不动地带走。 这份自由正是"没有编辑器"的副产品。
引擎层（Bevy）： 三大桌面系统、Android、iOS、Web（WASM/WebGPU）上游全部支持。Lua 与引擎之间的命令队列桥与平台无关。
本项目今天已接通的： macOS 开发环境（带热重载）和 iOS 模拟器与真机——Metal、120 Hz ProMotion、自动签名、TestFlight 管线。一个 Rust crate 编出两端。Android 和 Web 是路线图上的打包工作，不是架构风险。
你可能想问的问题
我的游戏不是这套技术栈，也能用这条素材管线吗？
能。这套模式——锁定 prompt token 的风格圣经、声明每个素材名字/尺寸/抠底模式的清单、经 Floniks 生成再后处理到精确像素的脚本——适用于任何从文件夹加载 PNG 的引擎。仓库里的工具是几个小 Python 文件，一个下午就能改造成你自己的。
生成素材要花积分吗？
要。每次经 Floniks 的生成调用按所用模型扣积分，失败的任务会自动退款。agent 可以在批量执行前调用 get_credit_balance 确认预算够用。
生成的素材不符合风格怎么办？
低成本重摇。因为每个素材都声明在清单里，重新生成一张——或者一整套——只是重放一份配方，不是重做一遍工作。风格圣经把每一次尝试都锁在同一套色板和构图规则之内，重试再多也不会积累漂移。
我需要手写提示词吗？
不需要。风格圣经自动拼装共享的风格 DNA，每个素材只声明它的主体。在 agent 工作流里，连主体那一句通常也是 agent 根据你的一句话需求写出来的。
编辑器没有死，它换了形态
| 编辑器的职能 | 我们的形态 |
|---|---|
| 风格指南 PDF | 可执行的风格圣经（锁死的 prompt DNA） |
| 资源浏览器 / 导入设置 | 声明式清单 + 可重放的管线 |
| 场景树 / 拖拽摆放 | 契约 + 自注册 |
| Inspector 滑块 | 热重载的 Lua 源码 |
| 编辑器视口 | 运行中的游戏 + 无头测试 |
| 鼠标操作 | 自然语言对话 |
五十年来，游戏工具的每一次进步都在回答同一个问题：创作者的意图如何更快地变成像素？当创作者身边多了一个 agent，最短路径就不再经过 GUI。我们不是没来得及做编辑器——我们把那份力气花在了让"说一句话"成为最短路径上。
这个赌注对不对，仓库里的八个游戏、树里的六十张 AI 生成素材、和一台以 120 Hz 跑着它们的 iPhone，会继续替我们回答。
文中提到的一切都可以在开源仓库验证：maweis1981/rust_bevy_lua_game——见 tools/style_bible.py、tools/floniks_manifest.json、tools/floniks_build.py、tools/PACK_SPEC.md，完整系列文章在 docs/ 目录。想把 Floniks 接进你自己的 agent，从 MCP 开发者指南开始。