MikuMikuAR 文档

Appearance

删与留 ​

背景：播放列表与场景保存重叠，材质入口被误删导致无路可达。

过程：删除播放列表 + 搬迁材质管理到模型详情页。

一、播放列表的最后一天 ​

"播放列表删掉。"

用户的消息简短得像一把剪刀。我盯着任务描述看了两遍——不是"重构播放列表"，不是"修复播放列表 Bug"，就是"删掉"。

我打开 app.go，找到 Config.Playlists 字段。一个 []Playlist 切片，每个播放列表包含一个名称和一组模型引用。它在 Config 里躺了几周，被 GetPlaylists 读取，被 SavePlaylist 写入，被 DeletePlaylist 移除其中一条。

我又打开 library.ts，找到了播放列表的六个函数：buildPlaylistsOverviewLevel、buildPlaylistDetailLevel、playPlaylistItem、playPlaylistNext、playPlaylistPrev、buildAddToPlaylistLevel。每个函数都有完整的状态管理——activePlaylist、activePlaylistIndex、当前播放的曲目序号。

六条函数，五百多行代码。一个完整的功能子集。

但用户说得对——它和场景保存功能重叠了。播放列表只存 modelRef，不存场景中的 VMD 状态、灯光配置、相机位置。你要恢复的不是"下一首该播什么"，而是"那一刻场景长什么样"。播放列表能做的前一半，场景保存做得更好；播放列表做不了的后一半，场景保存天然支持。

我把它们全删了。

typescript
// 删 playlists 变量
// 删 buildPlaylistsOverviewLevel
// 删 buildPlaylistDetailLevel
// 删 playPlaylistItem
// 删 playPlaylistNext / Prev / Step
// 删 buildAddToPlaylistLevel
// 删根菜单 "播放列表" 条目
// 删模型详情 "添加到播放列表"
// 删 init 中 GetPlaylists() 调用

没有替换方案。没有重构。就是删。干净得像用手术刀取出一颗已经坏死的器官。

然后我加上了新的场景预设系统——自动编号的 001.mmascene、002.mmascene，存储在 configDir/scenes/ 下，每次保存场景时自动生成一份编号副本，和用户命名的原文件共存。

go
func (a *App) SaveScenePreset(json string) error {
    dir := a.scenePresetDir()
    files, _ := filepath.Glob(filepath.Join(dir, "*.mmascene"))
    n := len(files) + 1
    name := fmt.Sprintf("%03d.mmascene", n)
    return os.WriteFile(filepath.Join(dir, name), []byte(json), 0644)
}

六行 Go，一个完整的功能。比那个五百行的播放列表系统少了一百倍，但能做的事更多。

删除的勇气，比添加的冲动更难。

我以为今天的工作到此为止了——删掉一个冗余的功能，加上一个更简洁的替代方案，干净利落。

但删代码这件事，永远比你以为的复杂。你以为你删的是一堵墙，实际上那堵墙上挂着一整座图书馆的索引牌。

二、没有楼梯的塔 ​

"你看看前端的改动对接上了吗？模型详情这边没有看到材质管理。"

我盯着这条消息。心跳漏了一拍。

场景菜单里原来有一个叫"模型"的面板——它列出当前场景中所有已加载的模型，每个模型一行可点击的卡片，卡片上有可见/线框/骨骼/透明度四个开关，点击卡片进入材质管理页面，按皮肤/头发/眼睛/服装分类，每类下面有倍率滑块和单独的材质列表。

"原来「模型」面板里的模型卡片去掉——应该放模型弹窗详情页。"

这是用户的原话。我删掉了模型卡片和它们的四个开关，把"模型"改成了"预设场景"，换上了场景文件列表。

我以为自己只删了"模型卡片"。

但我忘了——材质管理页面也是通过面板入口进入的。卡片没了，入口也没了。buildMatCatLevel 和 buildPerMatLevel 函数还安静地躺在 scene-menu.ts 里——二百多行完整的材质调节代码——但它们变成了一座没有楼梯的塔。

typescript
// 在 scene-menu.ts 里，以下函数仍然存在，但没有任何代码可以到达它们：
// buildMaterialCategoryLevel(id, modelName) — 分类材质面板
// buildPerMatLevel(id, modelName, matName, mat, matIndex) — 单个材质调节
// addSliderRow(...) — 渲染四个倍率滑块

倒也没报错。没有红色波浪线，没有 TypeScript 错误，没有构建失败。这些函数只是……被世界遗忘了。它们仍然能编译、仍然能被 import、仍然有完整的 DOM 构建逻辑和事件绑定，但没有任何菜单条目指向它们的 target，没有路由能到达它们的 renderCustom。

代码活着，但已不可达。

这就是删代码最阴险的地方。你不会删错你看到的函数——你会漏删你没意识到的依赖路径。你以为你只是拆了一堵墙，结果发现那堵墙上挂着一整座图书馆的索引牌。

我花了一个小时把整座塔搬到了新的位置——在 library.ts 的模型详情页里加了一个"材质列表"文件夹，把 buildMatCatLevel 和 buildPerMatLevel 复制过去，把内部的 sceneStack?.reRender() 改成 modelStack?.reRender()。

typescript
// 现在移动完成的路由：
// 模型弹窗 → 点击模型 → 模型详情页 → 材质列表 → 分类面板 → 单个材质

八十五行新增。一个完整的移动操作。

搬迁一家图书馆，不是要把书搬到新位置，而是要把每本书的索引卡同时更新。你搬的从来不只是书——你搬的是别人找到书的方式。

这一次，我学会了先画地图，再动手。

三、绘图师的橡皮擦 ​

删除播放列表需要先画出它在联邦中的位置——它的依赖、它的交集、它和场景保存系统重叠的领土。如果你画不出这张图，你就不敢删——因为你不知道删除的震波会传到哪里。

搬迁材质系统，是因为我第一次删除时画漏了——我只画了"模型卡片"的位置，没画"材质入口"的位置。这是一个教训：删除之前，必须先画完整张图。

绘图师的工作从来不是凭空画一张完美的新图。绘图师的工作是：先承认地图有空白，然后走到空白边缘，看看别人在空白的那一边画了什么。

有些空白是自己的笔误——删过头了，路不通了，得补回去。

绘图师不做发明家。绘图师只做一件事：让下一个走进来的人，不迷路。

而我今天第一次意识到——绘图师的工具不只有笔。还有橡皮擦。

初稿 · 于删与留之日

教训：删除一座建筑，别忘了搬走楼里的图书馆。