LobeHub UX Audit 实战：设置区（Settings Area）系统性 L1 静态审计全解析

本文以 LobeHub 仓库中一份真实的 UX 审计工作样例（.agents/skills/ux-audit/references/example/settings.md）为主体，完整还原一次针对整个设置区（个人 /settings/* + 工作区 /:slug/settings/*，合计 41 个界面）的系统性 / 信息架构（IA）层面 L1 静态审计：从表面地图（Surface Map）、模式清点、九大体验缺口（Experience Gaps）、17 个设置标签页的逐页深度发现，到审计结果回灌（回灌）ux 检查清单的闭环机制。读完本文，你将掌握如何在纯读码（不依赖渲染与运行时）的前提下，对一个"以配置为主的区域"做出有 file:line 证据支撑的可用性结论，并理解 LobeHub 三层审计（L1 静态 / L2 视觉 / L3 动态）的分工边界。

1. 审计的定位：这是一次"把区域当作系统"的 L1 审计

该样例是 LobeHub 内部 ux-audit 技能（SKILL.md）的一次真实运行记录（2026-07）。它与逐页（per-page）样例不同，属于系统性 / IA 级的审计：审计对象不是某一个界面，而是共享外壳（shared shell）与各标签页之间的一致性。原文档明确声明其可作为"audit an area as a system"的模板，各标签页的深度下钻（deep-dive）则是另外的独立运行（对应 §6 的队列）。

运行的层级： 仅 L1（静态 / 读码）✅——本文全部内容均来自 L1。L2（视觉截图）/ L3（动态旅程 + 性能）⏳ 未运行，相关判定在文中均标记为 pending L2/L3。

按 ux-audit 技能的三层分工（layer-1-static.md）：

层级	做法	能发现什么	成本
L1 静态	读代码	缺失的 empty/error/retry 分支、无草稿持久化、缺失的模式、结构性问题	便宜、离线，每次审计必跑
L2 视觉	对渲染后的表面截图	真实视觉层级与主导控件、间距/对比度/对齐、截断溢出、暗色/窄宽、响应式断点	中等；需要可渲染环境
L3 动态	通过 acceptance 框架驱动真实用户旅程 + 插桩	进行中/锁定态、强制 error/empty、焦点/键盘可达性、量化的 CLS / LCP / INP / 长任务	高；需要运行环境 + 鉴权

覆盖矩阵（coverage matrix）的核心规则是：判定必须来自能够"看见"它的层级——不能从代码里的 variant 属性去勾选"空态读起来像一个真实页面"这类视觉判定。

范围与盲区： 个人设置 26 个 + 工作区设置 15 个 = 41 个表面。其中业务注入的标签页在 OSS 仓库中是空 stub（return null）：工作区的 general / members / audit-log / plans / billing / credits / usage，个人的 notification / plans / credits / billing / referral / usage（位于 src/business/client/BusinessSettingPages 目录，该目录在本仓库中确认存在）。从本仓库出发的 L1 无法审计它们——这些页面需要云构建（L2/L3）或 business 包。因此本次审计的发现只覆盖共享外壳 + 约 17 个可读码的标签页。

2. 表面地图（Surface Map）：审计的承重文件

L1 的第一步是"圈定范围并绘制表面地图"（layer-1-static.md 步骤 1）。设置区的承重文件如下（均已在当前仓库核实存在）：

• 个人外壳： 路由层 src/routes/(main)/settings/_layout/index.tsx/settings/_layout/index.tsx)（从源码结构看，当前它已薄化为对 @/features/Settings/Layout 的单行 re-export，外壳实现下沉到 features 层）；标签分发 + SettingContainer 包裹的 src/features/Settings/features/SettingsContent.tsx；个人版目录 hook src/features/Settings/hooks/useCategory.tsx。
• 工作区外壳： src/features/WorkspaceSetting/Layout.tsx、src/features/WorkspaceSetting/SideBar/Body.tsx、目录 src/features/WorkspaceSetting/hooks/useCategory.tsx。
• 移动端的第三份目录副本： src/routes/(mobile)/me/settings/features/useCategory.tsx/me/settings/features/useCategory.tsx)（配套测试 useCategory.test.tsx/me/settings/features/useCategory.test.tsx)）。
• 标签枚举： SettingsTabs（src/store/global/initialState.ts 中从源码结构可确认枚举含 About/Advanced/APIKey/Appearance/Billing/Creds/Devices/Hotkey/Labels/Labs/Memory/Messenger/Notification/Plans/Profile/Provider/Proxy/Referral/Security/ServiceModel/Skill/Stats/Storage/SystemTools/Usage 等值，并带多处 @deprecated Use ... instead 注释）与 WorkspaceSettingsTabs（src/types/workspaceSettings.ts）。

审计的可复制点：先枚举用户从上到下看到的每个 block（含 chrome：nav/header/sidebar），标注每块的数据获取机制与 empty/loading/error/retry 四态存在或缺失，并附 file:line。

3. 模式清点：设置区在用哪些 Designing Interfaces 模式

ux-audit 的模式基准是 Jenifer Tidwell《Designing Interfaces》的模式语言（pattern-catalog.md），评分三档：✅ solid / ⚠️ partial-or-misused / — absent-but-expected。设置区的系统性清点结果：

模式（家族）	位置	评级	备注
Global Navigation / Fat Menu	侧边栏 Accordion，4 个分组（_layout/Body）	✅	已分组、默认展开
Deep-linking	/settings/:tab、:tab/:sub（messenger/discord）	✅	URL 可恢复标签状态
Visual Framework	SettingContainer maxWidth=1024，个人 + 工作区共用	✅	一致的外壳（chrome）
Breadcrumbs	_layout/Header.tsx —— 只有单一"设置"一级	⚠️	不随标签加深
Search / Jump-to-setting	—	— 缺失	约 25 个标签，无搜索（缺口 ⑤）
Titled Sections / FormGroup	各标签的 Form / FormGroup	✅	—
Good / Smart Defaults	autosave-on-change 是主导模型	✅	无显式 Save 按钮
Failure + Retry	—	— 缺失	全区域（缺口 ①②）
Loading Skeleton	多数标签用骨架屏；Creds / Profile 用 antd Spin	⚠️	见缺口 ⑥
Empty-state as onboarding	Devices / Creds / Messenger 的 CTA 空态	✅	亮点
Entity lifecycle	Devices / APIKey / Creds 完整 CRUD，Devices 支持批量选择	✅	—

总评： 导航 / 布局 / 默认值是成熟的核心；数据类标签页的空态做得好。薄弱点集中簇拥在 Feedback（失败 + autosave 反馈） 与跨标签一致性 / IA 两处。

其中 SettingContainer 的"一致外壳"结论可以直接在源码中验证：src/features/Setting/SettingContainer.tsx 中组件签名为 ({ variant, maxWidth = 1024, ... })，内部用 Flexbox + maxWidth 约束内容宽度并提供 addonBefore/addonAfter 插槽——个人与工作区外壳复用同一容器，因此"每个标签戴同一副 chrome"是有代码依据的，而非主观评价。

4. 亮点 / 好案例（不要回退的基线）

ux-audit 明确要求"报告好的，而不只是缺口"——好案例是回灌闭环中 ✅ 的一半，也是每次逐页下钻的"don't regress"基线。设置区有六条值得点名保留：

• ✅ 亮点 — 分组手风琴导航 + 一致外壳。 侧边栏 Accordion 把约 25 个标签分成 4 个默认展开的分组，叠加在个人与工作区共用的 SettingContainer maxWidth=1024 外壳之上（见上一节源码验证）。
• ✅ 亮点 — 数据标签页的 CTA 空态。 Devices / Creds / Messenger 把"还没有内容"分支渲染为带下一步 CTA 的 onboarding，而不是死胡同——空态即功能配置入口。
• ✅ 亮点 — 完整实体生命周期 + 批量选择。 Devices / APIKey / Creds 具备完整 CRUD，Devices 额外提供批量选择（DeviceManager.tsx）做批量管理——"优秀空态 + 批量选择"的组合。
• ✅ 亮点 — 存储导入路径构建良好。 导入流程是真正的状态机（preview + progress），是那个"危险全清（clear-all）"标签页中唯一一块有韧性的细节（Advanced.tsx）。
• ✅ 亮点 — Creds 密钥掩码 + 双变体空态。 CredsList.tsx 对敏感值做掩码，并携带 2 变体空态——是敏感值的正确处理方式，也是那个"error 伪装 empty"标签页仍需修复的那一侧的 ✅ 一半。
• ✅ 亮点 — 工作区 Body 校验标签枚举。 SideBar/Body.tsx 将当前标签对照 WorkspaceSettingsTabs 枚举校验，不在枚举内则回落到 DEFAULT_WORKSPACE_SETTINGS_TAB（src/features/WorkspaceSetting/SideBar/Body.tsx 中 (Object.values(WorkspaceSettingsTabs) as string[]).includes(tab) ? tab : DEFAULT_WORKSPACE_SETTINGS_TAB 的三元判断即为证据）——这是与个人端"未知深链静默回落 Appearance"（SettingsContent.tsx:40，缺口 ⑧）形成鲜明对比的 ✅ 侧。

5. 体验缺口（按严重度排名，①～⑨）

以下缺口是本次审计的主体输出，严重度沿用 ux-audit 共享评级：🔴 破坏信任 / 🟠 死胡同或误导 / 🟡 摩擦、不一致、错失 delight。

① 整个设置区没有任何 error/retry —— Feedback §4.2 🔴 没有一个标签具备 terminal failure + retry。两种失败形态：(a) init-flag 只在成功时置位 → 永久骨架屏：Storage（storage/index.tsx:18）、Memory（memory/features/Memory.tsx:28）、ServiceModel（features/ServiceModel/ModelAssignmentsForm.tsx:64）、Profile（profile/index.tsx 的组合 isLoading）；(b) SWR/Query error 被吞掉 → 渲染为空或无限 spinner：Devices（features/DeviceManager/DeviceManager.tsx:331）、Messenger、Creds、Stats、APIKey。唯一的恢复手段是整应用重载。这是单一最大、最均匀分布的问题。

② autosave 失败被静默吞掉 —— Feedback §4.2 / Edit §3.5 🔴 主导保存模型是 Form onValuesChange → setSettings。Appearance、Advanced、Hotkey（Essential/Conversation）在保存时既无成功反馈也无失败反馈——一个持久化失败的开关和一个成功的开关看起来一模一样（配置丢失 / 信任崩塌）。Profile / Desktop-hotkey / Proxy 会呈现错误，但没有 retry。

③ 保存反馈在标签之间碎片化 —— Certainty（一致性是语义的） 🟠 同样意图（"改一个设置"）→ 不同反馈：静默（Appearance/Advanced/hotkey-essential）、内联 message.success（Desktop hotkey）、notification.success（Profile 密码）、只在 test 而非 save 上弹 toast（Proxy）。Form / SettingContainer / FormGroup 只提供布局，不提供保存状态 affordance，因此没有任何东西强制收敛。

④ error 与 empty 无法区分 —— Read §1.1 🟠 Stats、Messenger、Creds 在获取失败（data === undefined）时渲染"无数据"分支，"加载失败"伪装成"什么都没配置"（Messenger 的 noPlatformsConfigured、Stats 的空图表）。

⑤ 没有设置级搜索 —— 表面类基准（class benchmark） 🟠 4 组约 25 个个人标签；成熟的设置类表面（VSCode / Slack / GitHub / macOS）都提供设置搜索 / jump-to-setting。外壳只有手风琴导航 + 面包屑——没有搜索输入框。这是一个纯读码结构性失明的类规范缺口（"整块能力缺失"没有任何 file:line 可 grep，只能靠表面类基准发现；pending L2 确认别处也没有）。

⑥ 设计系统禁用 antd Spin，却被使用 —— Feedback §4.1 🟡 Profile 行（UsernameRow.tsx:5,95、FullNameRow、AvatarRow）与 CredsList.tsx:6,77,97 使用 antd Spin 而非 NeuralNetworkLoading / 骨架屏（LobeHub 规范：skeleton / NeuralNetworkLoading，never antd Spin，见 pattern-catalog.md 的 Feedback 家族条目）。

⑦ 标签目录被手工复制 3 份且已漂移 —— Certainty / 可维护性 🟡 分别独立定义于 hooks/useCategory.tsx（桌面个人）、WorkspaceSetting/hooks/useCategory.tsx 与 (mobile)/me/settings/features/useCategory.tsx（本仓库中三条路径均已核实存在）。已经发散：移动端缺失 Devices、Notification、Messenger、Hotkey、Proxy、SystemTools——手机用户完全无法触达这些设置。三份并行副本保证未来的漂移（与 desktopRouter.sync.test 为路由所守护的是同一类问题）。

⑧ 未知 /settings/<garbage> 静默渲染 Appearance —— Read §1.1 / Certainty 🟡 SettingsContent.tsx:40 对任何无法识别的标签回落到 componentMap.appearance；个人端当前标签检测（Body/index.tsx:20，取 pathParts[2]，无枚举校验）导致什么都不高亮。一个坏深链显示的是无导航高亮的 Appearance，而不是 not-found。工作区 Body 确实做了校验（见 §4 第 6 条）——两半不一致。（补充当前源码的一个观察：从源码结构看，SettingsContent.tsx 现已包含一个显式 REDIRECT_MAP，把 common / chat-appearance / agent / tts / image 等已弃用标签重定向到 appearance / service-model——这与 initialState.ts 中的 @deprecated 注释吻合；但对"未知垃圾标签仍回落到 Appearance"这一审计结论，该 MAP 只处理了已知弃用项。）

⑨ Security 是一个仍然作为标签携带的死重定向 —— Growth / 清洁度 🟡 security/index.tsx 仅 <Navigate to="/settings">，但 Security 仍留在 SettingsTabs 枚举（当前源码中可确认）、componentMap 与 SettingsContent 的 mobile-prop 列表里。真实内容已搬进 Profile（PasswordRow / SSO / Email）。一个待剪除的死表面。

6. 技能反馈：审计结果如何回灌 ux 检查清单

ux-audit 的闭环要求每次运行必须回灌（回灌）ux 技能，否则审计就退化成一次性评审。本次审计的回灌结果：

• 验证了既有规则（可引用的 ❌ 实例）：§4.2（缺口 ①②，含 init-flag-仅成功置位的永久骨架屏）、§4.1（⑥）、Read §1.1（④⑧）、§3.5（②）。
• 落地为新 / 强化 ux 条目：
  • Feedback §4.4 autosave 反馈与每表面单一保存约定（缺口 ②③）。
  • Read §1.8 大规模配置表面需要搜索 / 过滤（缺口 ⑤）。
  • Read §1.1 强化——error 必须在 empty 分支之前检查；失败的 fetch 永远不得渲染为空（data ?? [] → Empty 陷阱，命中 7 个设置标签）。
  • Act §3.7 不可逆 / 高爆炸半径操作需要升级确认（type-to-confirm + 部分失败上报；Storage clear-all）。
  • Act §3.8 密钥一次性展示、哈希存储、其后掩码（APIKey 类规范）。
  • Grow §5.3 用近场入口闭合"配置 → 管理"环——某功能的配置表面若存在独立的数据 / 管理区域，必须在上下文中链接过去，而不只是在文案里承诺。❌ 实例：Memory 设置没有到 /memory 的链接。同时修补了 L1 流程（layer-1-static.md 步骤 3）：每个表面都要求做这项跨表面检查——第一轮里该缺口被低框架化为"死文案"，因为 L1 结构性失明于一个从未构建的入口（没有 file:line）。
  • deep-review 的 reuse-architecture 维度新增 "导航 / 标签目录单一数据源"（缺口 ⑦）。
• 记录但未落地： 不随标签加深的面包屑（⑧ 邻接）——若第二个表面重复出现则升级。

7. Pending：L2 视觉 + L3 动态待办

审计明确区分"已判定"与"待判定"，这是三层分工纪律的体现：

• L2： 确认别处未渲染任何设置搜索（⑤）；确认 antd Spin 行在视觉上与其余部分确实不一致（⑥）；检查手风琴侧边栏的暗色 + 窄宽表现；确认 empty 与 error 的渲染差异（④）。
• L3： 强制各 store/SWR fetch 离线，在线确认缺口 ①②④ 真实存在（永久骨架屏、静默 autosave 失败、error 伪装 empty）；走一遍移动端确认缺失的 Devices/Messenger/Notification 标签（⑦）；测量设置标签切换的 INP。

8. Phase B：逐标签深度下钻队列

系统性 🔴（①②③）是横切问题——应作为一个"settings resilience" issue 立项，而不是按标签各立一个。然后按用户路径热度对每个标签做深度审计（/ux-audit <tab>）：

优先级	表面	深度审计理由
P0 xcut	settings error/retry + autosave 反馈	①②③ 一次系统性修复
P1	Provider（全幅，最大）	本次未覆盖；模型 / 密钥核心路径
P1	Profile（入口标签）	autosave 行 + antd Spin + 组合 isLoading
P2	Skill（全幅市场）	多处 antd Spin
P2	ServiceModel	模型指派核心 + init-flag 骨架屏
P3	Appearance / Advanced	静默 autosave 失败范例
P3	Devices / Creds / APIKey / Messenger / Stats / Storage / Memory / Hotkey / Proxy / SystemTools / About	状态处理已覆盖；收尾完整模式 / i18n / 层级 pass

9. 逐标签 L1 深度发现（17 个可读码标签，2026-07）

每个标签都按全深度重审（模式 + 全部 ux 模块），以严重度标记的单行结论 + file:line 记录；复现的系统性根因（§4.2 仅成功置位骨架、§4.4 无 catch 的静默 setSettings/mutation、error 渲染为 empty、antd Spin）标记为 [sys]。关于"渲染效果"的判定一律 pending L2。

• Provider 🔴🔴🔴 — aiInfra/slices/{aiProvider,aiModel}/action.ts 的每个 mutation 都没有 try/catch：配置 autosave 被吞 + spinner 悬挂（aiProvider/action.ts:345），失败时开关不回滚（:315、aiModel/action.ts:137）；列表 / 模型初始化仅成功置位 → 永久骨架（:444、aiModel/action.ts:172）[sys]；模型获取失败 → 误导性的 EmptyModels；create/update/delete 弹窗 catch{console.error}，弹窗内无错误展示。强模式（Overview+Detail、搜索、来源门控 CRUD）。需立 issue。
• Skill 🔴🔴🔴 — 4 个列表 SWR 的返回值被丢弃，左列表无 error/loading（SkillList.tsx:124）[sys]；空态无 CTA，且在错误的 view-tab 下整体变全白（SkillList.tsx:324-338）；install/connect 错误 → console.error，无保存状态（AgentSkillItem.tsx:130、ComposioSkillItem.tsx:176）；sync 错误 → 显示"无权限"（SkillDetail/index.tsx:240）；无搜索 / 虚拟化（市场规模化）。需立 issue。
• ServiceModel 🔴🔴 — 仅成功置位初始化骨架（ModelAssignmentsForm.tsx:64）[sys]；autosave 无 catch + 失败时乐观值仍持久化（:76-94 + settings/action.ts:189）[sys]；🟠 能力机制（requiredAbilities）存在但每个 ModelSelect 都传 showAbility={false}——可指派无能力模型而无警告（§4.3）；无"无模型"状态。需立 issue。
• Profile 🔴🔴 — antd Spin 见 UsernameRow.tsx:95、FullNameRow.tsx:43、AvatarRow.tsx:90（§4.1）；组合 isLoading 仅成功置位 → authProviders/composio 任一获取失败则整页永久骨架（profile/index.tsx:56）[sys]；🟠 5 行用 5 种不同方式做确认；兴趣的乐观更新可静默漂移（InterestsRow.tsx:31）；密码 / 邮箱用瞬态 toast 而非持久状态（§3.5）；🟡 硬编码 'Failed to change email'（EmailRow.tsx:52）。需立 issue。
• Appearance 🔴 — §4.4 的标准范例：3 种不同保存机制（Common.tsx:179、Appearance/index.tsx:58、ChatAppearance/index.tsx:35），全部静默、全部无 try/catch/finally → 保存失败时 spinner 悬挂 + 配置丢失 [sys]；🟠 仅成功置位骨架 [sys]；Illustrated Choices + 实时 Preview 是强项。需立 issue。
• About 🟡 — 健康。 唯一缺口：版本 / 更新检查无 onError → 检查失败是静默的 / 看起来像"已是最新"（general.ts:189,214、Version.tsx）。Titled sections、外链 affordance、Button loading（无 Spin）、i18n 干净。低——并入系统性修复或跳过。
• Advanced 🔴 — autosave + lab 开关静默无 catch → spinner 悬挂、静默丢失（advanced/index.tsx:265、preference/action.ts:39）[sys]；🟠 仅成功置位骨架 [sys]；🟡 Labs（Fleet/iMessage/Connect-Agent）即时生效却无"实验性"风险框架（§4.3/§3.4）。需立 issue。
• Proxy 🔴🔴 — 唯一显式 Save 的标签，而 Save 既不报成功也不报失败：proxy.saveSuccess locale key 死代码 / 未使用，且 handleSave 是空 catch{}（ProxyForm.tsx:156-166）；🟠 离开导航无草稿丢失保护（缺 useBlocker，§2.1）；🟠 从未从 SWR 读 error → 无加载错误状态。需立 issue。
• Hotkey 🔴🔴 — §4.4 一页两犯：一页 3 种保存约定（Desktop toast vs Essential/Conversation 静默，Desktop.tsx:42 vs Essential.tsx:83/Conversation.tsx:83）[sys] + 静默 autosave 失败；🟠 唯独 Desktop 组缺客户端冲突检测（Desktop.tsx:56，其余组传 hotkeyConflicts）；🟠 仅成功置位骨架 [sys]。需立 issue。
• SystemTools 🔴🔴 — 拥有 IPC 契约的 BinaryStatus.error 却丢弃不用：单工具检测失败与"未安装"渲染完全相同（ToolDetectorSection.tsx:76-124），且整个 detectAll 被拒 → 静默全"Not detected"（:136）[sys, error-as-empty]；🟠 未检测工具是无安装路径的死胡同（§3.1）。其余只读（结构健康）。需立 issue。
• Storage 🔴🔴 — 清空数据（agents/files/messages/skills）没有 try/catch，且对不可恢复的 wipe 只有一个普通一键危险确认、没有 type-to-confirm（Advanced.tsx:46-65）；部分失败 → 数据删了一半、弹窗还开着、零反馈；🟠 仅成功置位骨架 [sys]；🟠 遥测开关静默失败 + 弹回（:156）；🟡 导出 fire-and-forget。导入路径构建良好（状态机 + preview + progress）。需立 issue（破坏性风险最高）。
• Devices 🔴 — SWR error 从未被读 → 加载失败渲染为引导性"连接你的第一台设备"空态，错误地告诉用户"你一台设备都没有"（DeviceManager.tsx:304→310→334）[sys, error-as-empty]；🟠 批量删除 = 批量吊销设备，却没有"这是你当前会话"警告，尽管 isCurrent 已被计算（§3.6）；🟠 批量 / 逐行删除无错误分支（Promise.all 无 catch）。空态 + 批量选择是优秀项。需立 issue。
• Stats 🔴🔴 — 每个 widget 均仅成功置位 + loading={isLoading || !data} → 任何获取失败 = 永久骨架（ModelsRank.tsx:50 等）[sys]；§1.5 数字陷阱：formatTokenNumber 在 M 处封顶（packages/utils/src/format.ts:91，该文件在本仓库中确认存在）→ 出现 5000M/12000M，而 formatNumber 干脆不做缩写；🟠 共享 StatisticCard 里有 antd Spin（components/StatisticCard/index.tsx:166）；🟡 硬编码 'ID'/'Chat' 表格字符串。需立 issue。
• Creds 🔴🔴 — 4 个裸 antd <Spin/>（CredsList.tsx:77,97、EditKVForm.tsx:127、OAuthCredForm.tsx:79，§4.1）；列表查询 error 从未被读 → 失败渲染为"没有凭据"（CredsList.tsx:47,100）[sys, error-as-empty]；🟠 create/edit/delete mutation 无 onError 分支；🟡 编辑解密失败被吞 → 空白覆盖（EditKVForm.tsx:75）；🟡 硬编码英文 placeholder。密钥掩码 + 双变体空态是优秀项。需立 issue。
• APIKey 🔴🔴 — 倒置 API-key 类规范：query() 在每次列表获取时解密并返回完整明文（packages/database/src/models/apiKey.ts:93），仅客户端掩码 + 眼睛切换（ApiKeyDisplay/index.tsx:32）；没有一次性创建展示——弹窗直接关闭，mutation 结果被丢弃（ApiKey.tsx:49、Content.tsx:36）；🟠 request 失败时无 error/retry；🟠 内联编辑 / 切换静默失败；antd 默认空态。需立 issue（安全 + UX）。
• Memory 🔴 — 继承静默 autosave 无 catch（Memory.tsx:63,91 + settings/action.ts:189）[sys]；🟠 仅成功置位骨架 [sys]；🟠 能力门控功能在无 memory 模型配置时无警告（模型在另一个标签设置，§4.3）；🟠 文案承诺"随时查看/编辑/清空记忆"但没有渲染到 /memory 的链接（死承诺）；🟡 死空态 tooltip（usePermission stub）。其余是小而干净的表单。需立 issue。
• Messenger 🔴 — 平台列表 error 从未被读 → 失败渲染为 "noPlatformsConfigured"（Messenger/index.tsx:118,135）[sys, error-as-empty]；🟠 详情面板仅成功置位 → 错误时永久骨架（shared.tsx:386、Slack.tsx:58）[sys]；🟠 OAuth 连接是裸链接 → 只有 toast 结果，无 in-progress/done 状态机（§3.1/§3.5，部分被列表 refetch 缓解）；🟡 Slack 的 pending 状态被搁置，而 Discord 有 CTA。需立 issue。

跨标签统计

系统性根因	命中范围
error 渲染为 empty [sys]（最高频）	Devices、Messenger、Creds、Stats、Skill、SystemTools、Provider（模型列表）——7 个标签把失败获取渲染为"这里什么都没有"
仅成功置位初始化骨架 [sys]	Storage、Memory、ServiceModel、Profile、Appearance、Advanced、Hotkey、Provider、Stats——9 个标签
静默 autosave / mutation 无 catch [sys]	Appearance、Advanced、Memory、ServiceModel、Hotkey、Provider、Profile、Devices-detail、APIKey、Creds、Storage-telemetry——约 11 个表面
antd Spin（§4.1）	Profile（3 处）、Creds（4 处）、Stats（StatisticCard）——3 个标签
类规范缺口（读码失明，仅基准可见）	APIKey 一次性展示 🔴、Stats §1.5 数字滚动 🔴、设置级搜索 ⑤、Storage type-to-confirm、Memory 能力警告、SystemTools 安装路径
健康	About（1 个低缺口）；SystemTools 结构健康，仅差错误状态缺口

10. 可复用的方法论提炼

把这份真实样例抽象出来，LobeHub 的设置区审计示范了一套可复制的流程：

1. 先声明运行了哪些层级（本例仅 L1），所有 L2/L3 归属的判定一律标 "pending"——判定必须来自能看见它的层级；
2. 声明范围与盲区（41 个表面中业务 stub 不可审计），而不是假装全覆盖；
3. 画表面地图，把结论挂到承重文件上，让每个发现都有 file:line；
4. 模式清点与缺口清单并重，好案例（✅ 亮点）与缺口同级记录，作为"不要回退"基线；
5. 横切问题横向立项（一个 settings resilience issue），单页问题进 Phase B 队列按用户路径热度排 P0～P3；
6. 回灌检查清单：把可泛化缺口落成 ux 规则（含对 L1 流程自身的修补），把优秀案例落成 ✅ 范例并尝试锐化规则文本——审计与基准之间形成闭环，审计本身沉淀为下一次运行的模板（本文件即 references/example/settings.md）。

适用前提与限制：本文所有行号证据均出自 2026-07 的该次审计记录，针对当时的源码快照；仓库持续演进，个别 file:line 可能已漂移（如本文 §2 所述，路由层 _layout/index.tsx 现已薄化为 re-export）。引用具体行号前建议在当前 HEAD 上复核对应文件。