# LumenX Studio 侧边栏与二级导航重构 — 决策回顾与第一性原理

> 一次"边栏失衡"问题的完整复盘：从问题定义、候选方案系统比较、决策反转，到可复用的第一性原理。
> 适用读者：未来的自己、Tasty Sam、以及任何接手 Studio 前端导航的人。

---

## 0. 起点：最初为什么成立

左侧边栏最初采用完整宽栏（w-56）作为全站视觉锚点，纵向排布 **Logo + 字标 + Slogan + 主导航**（工作区 / 主体库 / 创作台 / 设置）。功能简单的阶段，这一设计成立：字号小、信息密度可控，既完整传达品牌（LumenX 定位是"创作者的驾驶舱"而非管理后台），又不过度侵占主面板。

## 1. 失衡：问题浮现

2026 年 6 月的一次前端重构让主面板功能迭代得愈发丰富，这一设计开始失衡。以设置页为例，左侧同时出现了**两条边栏**：

1. **全局边栏（w-56）** — 全站视觉锚点 + 一级导航；
2. **功能/筛选边栏（w-220）** — 当前页面的二级导航（设置分类 / 资产筛选 / 系列导航）。

两条并置宽栏带来三重问题：

- **层级辨识混乱**：两条等宽、等视觉权重的竖栏并排，用户难以瞬间区分"全站导航"与"页面内导航"；
- **空间挤压**：两栏合计约 476px 被导航占据，主面板被压缩，违背"内容为王"；
- **重复累赘**：全局栏的"设置"高亮 + 二级栏的"设置"大标题 + 主面板的"设置"页标题，**同一语义一屏出现三次**。

## 2. 先把问题定义准：这不是"空间"问题，是"层级辨识"问题

**专业角度：** 这套界面其实有**三层导航**，但目前只用**两种视觉语言**承载：

- **L0 — 产品/品牌层**（Logo + Slogan，未来还要承载 Studio ↔ Atelier 的产品切换）；
- **L1 — 顶级 section**（工作区 / 主体库 / 创作台 / 设置）；
- **L2 — section 内部的子导航**（设置里的 通用/模型/默认Prompt/…）。

当 **L1 和 L2 都用"等宽、等视觉权重的竖向边栏"**来表达时，就触发了 **navigation level collision（导航层级撞车）**——两个并排、长得差不多的竖条，大脑无法瞬间判断谁包含谁。

> **格式塔铁律：嵌套关系必须在至少一个显著维度上拉开差异**（方向 / 权重 / 表面材质 / 信息密度），否则会被读成"并列"而非"父子"。
> 现在两根栏都是竖的、都是暗玻璃、字号接近——**四个维度全都一样**，所以"奇怪"。

**通俗角度：** 就像一本书的"目录"和"章节标题"用了一模一样的字号、一模一样的位置、并排放在一起——你会愣一下，分不清哪个管哪个。**不是它们占地方，是它们"撞脸"了。**

> **一个关键观察（它会改变结论）：** 主面板右侧其实留了**大片空白**——主体库的网格靠左对齐、设置的内容卡也只占一半多。也就是说**你并不真的缺横向空间**。这意味着"省地方"对 LumenX 是**次要**收益；真正要解决的是**层级清晰度**。
> ——这一点至关重要：**它让"最优解"的定义完全不同**。若目标是"省像素"，答案是压缩导航；若目标是"层级清晰"，答案是让两层"长得不一样"。**后者才是对的。**

## 3. 一个更深的切分：L2 里混着两个"物种"——导航 vs 视图控件

把 L2 当成铁板一块，是找不到好解的。它其实是**两种不同的东西**：

| | 设置的 L2 | 资产库/工作区的 L2 |
|---|---|---|
| 本质 | **页面切换导航**（page-switching） | **分面筛选 = 视图控件**（faceted view-control；facet = 可独立筛选的维度） |
| 用户心智 | "我要去哪个设置页" | "我要怎么切当前这堆内容" |
| 该在哪 | 可以是栏/Tab | **贴着内容**（横向工具条），不该是和全局导航并列的栏 |

> **范畴错误（category error）：** 把"视图控件"误当成了"导航"。
> *通俗：* 一个是"换房间的门"（挂墙上），一个是"桌上的筛子"（放桌上）。把筛子也挂墙上当门，就长出了第二条竖栏。

这一步切分，直接决定了最终方案：**设置 L2 走横向 Tab；资产库/工作区 L2 横向化、收进内容头部——根本不该有第二条竖栏。**

## 4. 候选方案的系统比较

### 方案 A：QoderWake 的图标栏（收缩 L1 + 表现力图标 + hover 文字）—— 好答案，但不是"无条件最优"

QoderWake 的前端工程师建议：把左侧收缩为**图标栏**，用有表现力的图标 Logo + **hover 显示文字**来表达侧边栏的功能含义。

**它为什么有效（专业）：** 把 L1 收成图标栏，等于用"**极小宽度 + 纯图标**"这种独特视觉语言，让 L1 一眼就是 **app chrome**（界面框架件），和带文字的 L2 拉开权重差。VS Code、Linear、Slack、Discord 全这么干——是经过验证的工业级答案。

**但它对 LumenX 有两个真实代价：**

1. **它杀掉了品牌时刻。** "Render Noise into Narrative" 是写明的品牌资产，LumenX 定位是"创作者的驾驶舱"而非管理后台。图标栏一上，Logo 缩成一个"L"、Slogan 直接消失——**每一屏都在为省那点根本不缺的宽度，付出品牌人格的代价**。
2. **四项导航用纯图标会有歧义。** 工作区 / 创作台 / 主体库——"workspace" 和 "studio/创作台" 在图标语义上很难区分，你会被迫依赖 hover tooltip 才能确认，而 **hover-to-reveal 是有 discoverability（可发现性）税的**，尤其对低频项。

> **结论：** 图标栏是**安全、稳妥、不会错**的选择，但它是"**用品牌换确定性**"。对一个强调人格的创作工具，这笔交易**不是非做不可**。

### 方案 B：按页自适应展开 / 收缩 —— 否

"无筛选栏时展开成文字栏、有筛选栏时收缩成图标"——听起来两全。但核对四个主页面 mockup，**几乎每页都带第二条边栏**。于是条件规则的**实际效果 ≈ 永远收缩**：付出全部跨页布局抖动（layout jitter）的代价，却几乎换不到展开态收益，还会让主导航宽度跳变、**摧毁它作为空间锚点的肌肉记忆**。否。

### 方案 C（实际曾短暂落地）：固定 60px 图标轨

这是方案 A 的"固定版"——直接承诺一条稳定的 60px 窄栏（避开 B 的抖动），表意缺口用三层手段补：更具表达力的图标 + VSCode 活动栏式 hover 浮出全称标签（绝对定位、零布局抖动）+ 每项 `aria-label`/`title`/active 强调条。Tasty Sam 一度据此落地。

> 但 A、B、C 都默认了一个**隐藏前提："我们必须保留第二条竖向筛选栏"**。一旦质疑这个前提，整盘棋就翻了。

## 5. 决策反转：第三条路 —— 移除 L2 竖栏本身

关键一问：**那条 60px 图标轨，到底是为了什么？** 答案是——**为了给第二条竖向筛选栏腾地方**。它本质是一个**权宜之计（workaround）**。

而第 3 节的切分告诉我们：第二条筛选栏（视图控件）**根本就不该是竖栏**。于是我们**直接把它横向化、移除了**。

> **肇事者一除，权宜之计的理由就消失了。** 既然不再有第二条竖栏抢地方，把全局栏压成"省地方却牺牲品牌与可读性"的图标轨，就完全没必要——方案 A 的两个代价、方案 B 的抖动，**同时不复存在**。
> 于是全局栏**退回成完整的标签式品牌侧栏**（w-52）：Logo + 字标 + Slogan 常驻、图标 + 文字（零歧义、**无 hover 认知负担**）、设置与版本固定底部。

注意这条曲线：我们**既没选 A（牺牲品牌），也没选 B（抖动），更没停在 C**，而是找到了**第三条路——移除 L2 竖栏本身**，让原本好用的完整侧栏自动复活。**这是整件事最值得记住的转折：最优解往往不在给定选项里，而在"取消造成两难的那个前提"。**

## 6. 最终落地（5 块，均逐块验证 + 原子提交）

1. **全局侧栏** — 图标轨 → 标签式品牌侧栏（Logo+字标+Slogan 常驻、图标+文字、无 hover、设置+版本固定底部）。
2. **设置页** — 竖向子栏 → 标题下横向 Tab + 切页，保留 6 分类（**竖 L1 × 横 L2，轴向正交，不撞脸**）。
3. **资产库** — 去竖向筛选栏；类型 pills 带计数 + 全部；★ 加星过滤；默认/名称排序；库专用富卡片；右侧 inspector 详情抽屉。
4. **加星后端** — Character/Scene/Prop 加 `starred` + 项目/系列两个 toggle 端点 + 前端 api（镜像现成 `toggle_lock`）。
5. **工作区** — 横向状态筛选 pills（复用导出的 `deriveStatus`，与卡片徽章一致）+ 接活搜索 + 筛选隐藏空组。

> "一眼看全计数"没丢：类型计数挂 pills、系列计数留分组标题——靠**内容自身的分组**承担，不需要竖栏。

## 7. 第一性原理沉淀（下次照这些想）

1. **层级必须可视区分**：相邻嵌套层级至少在 方向/权重/材质/密度 一维拉开，否则读成并列。**两条等权竖栏并排 = 危险信号。**
2. **先分"导航"还是"视图控件"**：去别处 = 导航（可竖可 Tab）；重塑当前内容（筛选/排序/分组/切视图）= 视图控件，**贴内容横排，别做成竖栏**。
3. **先验证真实约束，再定义"最优"**：别假设"是空间问题"。先量（留白/密度）。**目标错了，方案必错。**
4. **变味时撤掉肇事者，而非压受害者**：好设计迭代后失衡，优先找"是谁破坏了它"并移除/重定位，而不是给老元素打补丁。（原侧栏没问题，是第二条栏破坏了它。）
5. **最优解常在选项之外——取消造成两难的前提**：当所有候选方案都有真实代价时，回头检查它们**共享的隐藏前提**；推翻它，两难可能自动消失。
6. **权宜之计会自我固化，要追溯前提**：每个 workaround 都为某个问题而生。**根因一旦移除，回头重审所有为它而建的妥协**——别继续替一个消失的问题买单。
7. **数据现实是野心的闸门**：mockup 会画出后端没有的数据（视频/收藏/SEED/usedIn）。**砍到能撑的范围、明确标注取舍、绝不伪造。**
8. **同一语义不在一屏重复**：出现"设置×3"这类时，合并冗余的能指（signifier）。
9. **不同产品不同 chrome，别交叉绑架**：Studio（管线）与 Atelier（画布）外壳可不同；**警惕用"为产品 B 留余地"去伤害产品 A 的伪未来主义**。
10. **hover 浮出是有成本的**：用 hover 承载"必要信息"（标签/品牌）会带来可发现性与认知负担；空间允许时优先**常驻可见**。

## 8. 可复用判断流程（遇到"导航/边栏失衡"按此走）

```
1. 这是导航还是视图控件？            → 视图控件就横向贴内容，别做竖栏
2. 数清竖向层级，逐对确认"长得不一样"    → 否则在某一维度拉开差异
3. 真缺空间，还是缺清晰？(量一下)        → 别解错问题
4. 候选方案都有代价？找它们共享的隐藏前提  → 推翻前提，可能化解两难
5. 哪个新增元素破坏了原设计？          → 撤掉肇事者，而非压受害者
6. 我在维护哪些 workaround？根因还在吗？  → 根因没了就拆掉妥协
7. 这些数据/字段后端真有吗？          → 没有就砍+标注，不伪造
8. 留痕 + 客观验证                    → 写下取舍，跑门禁（typecheck/颜色守卫/健康）
```

## 9. 诚实缺口（没做完/没做）

- **有意取舍（非 bug，已标注）**：视频资产类型、SEED/MODEL/SIZE、用于N镜头（usedIn）、"最近"排序（scenes/props 无时间戳）、inspector 的"用于分镜/生成更多变体"（跨模块未接）、工作区"画廊/列表"切换（预存死控件）。
- **小债（清理进行了一半）**：`SettingsSidebar.tsx` 空壳类型已本地化、还差删文件；`page.tsx` 几处**预存**未用 import 清了一部分。
- **formal 多代理 review 未跑成** + 上述清理未收尾。代码每块都过了 typecheck + 颜色守卫（后端另加语法 + 实时健康）并已提交。

---

*决策日期：2026-06（前端重构期）。分支：`feat/atelier-pilot-20260611-161001`。*
