LobeHub 自学习域详情页 UX 审计实录：三层评审、模式评分与检查清单回灌闭环

本篇基于 LobeHub 仓库中 ux-audit 技能自带的样例审计记录 self-learning-domain.md，完整拆解「自学习域详情（成长画像）」这一页面是如何被逐模式评分、亮点与体验缺口如何锚定到 file:line 证据、以及审计结论如何通过 Skill feedback 回灌到 ux 检查清单，形成可复用的「证据而非感觉」式 UX 评审方法论。读完你可以掌握：如何对一个具体界面做分层（静态/视觉/动态）UX 审计、如何用《Designing Interfaces》模式语言给页面逐项评级，以及如何把审计发现沉淀为团队级的检查清单。

审计对象：自学习的「域详情」页面

被审计的表面是 Self-Learning（自进化能力）模块中的域详情页：进入单个能力域后，用户看到的是该域的「成长画像」——习惯（lessons）按层（layers）组织，附带做对率趋势、覆盖率云图、Top 5 习惯与锚定（anchoring）状态。

从当前仓库源码结构看，这一页面落在 src/features/SelfLearning/index.tsx 中。该文件顶部的注释（L42-L48）直接说明了产品意图：

成长画像 —— 自进化的 L0，也是单方向时的全部。感知单位是「习惯 + 它靠不靠谱」，不是「学到几条」……带 :domainId 进来时就是同一张画像收窄到一个方向。

即「域详情」并非独立页面，而是同一张画像按 domainId 路由参数收窄到单一能力域。配套实现分布在 Portrait 子目录（DomainList.tsx、LayerProfile.tsx、HabitList.tsx、TierBar.tsx、GrowthCharts.tsx 等组件）与 ExperienceList 中。注意：审计记录中引用的 Detail/index.tsx、CoverageCloud.tsx 是审计撰写时的代码路径；当前仓库已完成重构，下文中凡涉及这两处，均以「审计引用 + 当前对应实现」双标注处理。

三层审计：结论必须来自「看得见它的那一层」

审计记录首行声明了本次运行的层级覆盖：

Layers: L1 ✅ · L2 desktop dark/zero-run/mature ✅ · L3 drill-down ✅.

三层定义与分工详见 SKILL.md：

层级	做什么	能抓住什么	成本
L1 Static	读代码	缺失的空/错误/重试分支、无草稿持久化、缺失的模式、结构性问题	低，离线，每次必跑
L2 Visual	渲染后截图	真实视觉层级与主导控件、间距/对比度/对齐、空/加载/错误的实际样子、响应式断点、深色/浅色	中，需要可渲染环境
L3 Dynamic	用 acceptance 驱动真实用户旅程 + 插桩	进行中/锁定态、强制触发的错误/空态、步骤衔接、焦点/键盘、CLS/LCP/INP 等量化指标	高，需要运行环境与登录态

本条样例的 L2 覆盖了 desktop / dark / zero-run / mature 四种渲染形态——也就是说「零练习」和「成熟数据」两种极端状态都被真实截图验证过；L3 则实际走通了 drill-down（从 Top 5 列表下钻到全部规则与单条规则）旅程。这正对应后文 Overview + Detail 模式被评为 ✅ 的取证方式：下钻结论不能从代码推断，必须由 L3 实际点一遍。

覆盖矩阵的核心规则是：一条结论必须由能够看见它的层级给出——不能从代码里的 variant 属性勾选「有一个主按钮」，也不能从代码推断空态「渲染出来是什么样」。这也是为什么审计记录里每条证据都标注了来源层级。

Patterns in use：五类模式的逐项评分（原文表格完整继承）

评分基准是 Jenifer Tidwell《Designing Interfaces》的模式语言，目录见 pattern-catalog.md。审计记录对域详情页的五类模式评级如下：

Pattern	Rating	Evidence
Center Stage	⚠️	Fit statement/chart dominate; action-relevant gaps are secondary.
Titled Sections	✅	Trend, metrics, coverage, Top 5 and anchoring are separated.
Overview + Detail	✅	Top 5 drills into all rules and individual rules.
Failure + Retry	⚠️	Domain fetch is covered; independent lessons fetch is not.
Forward Momentum	—	No-practice and anomaly states explain but offer no action.

逐条展开：

• Center Stage（主舞台）⚠️：模式要求「最重要的东西占据视觉中心」。该页面让 fit 结论句与图表占据了主导地位，而与用户行动相关的缺口信息（哪些层是空的、哪些习惯没被锚定）被排在次要位置——视觉重心与决策重心错位，故评 ⚠️ 而非 ✅。
• Titled Sections（有标题的分节）✅：趋势（Trend）、指标（metrics）、覆盖率（coverage）、Top 5、锚定（anchoring）各自独立成节、边界清晰，符合「可分离的命名内容块」的定义。
• Overview + Detail（总览 + 详情）✅：Top 5 列表可以下钻到全部规则（all rules），也可以继续下钻到单条规则（individual rule），且下钻后不丢失当前位置——这一条正是靠 L3 drill-down 实际走通才得出的结论。
• Failure + Retry（失败 + 重试）⚠️：域（domain）数据拉取有完整的失败/重试覆盖，但习惯（lessons）拉取是独立的请求，却没有独立的失败处理——两个数据源共用一套状态，是典型的「多 fetch 只接了一个错误分支」问题。
• Forward Momentum（前进势能）—：无练习（no-practice）与异常（anomaly）状态只做了「解释为什么是这个状态」，没有给出下一步动作，属于「缺失但预期存在」，记作 —。

三个亮点（Strengths / good cases）：写进报告的「不许回退」清单

按 SKILL 的输出规范，亮点与缺口同属一等发现，必须标注「✅ 亮点」并给出 file:line。原记录列出三条：

1. ✅ 亮点 — 不可靠的 fit 不编造数字（Unreliable fits do not invent a number）。 页面会解释为什么不给投影值，而不是硬凑一个百分比。审计引用 Detail/index.tsx:263+（当前实现中该逻辑位于 src/features/SelfLearning/index.tsx 的投影/结论渲染分支中）。
2. ✅ 亮点 — 零练习不等于失败（Zero practice is not failure）。 一个专门的状态页替代了「无意义的首次图表」。审计引用 Detail/index.tsx:135-149。从当前源码结构看，这一设计仍然保留：index.tsx 中显式筛出 runCount === 0 && d.lessons.length === 0 的 freshDomains，为「从未练习」的域提供独立呈现，而不是渲染一条全零曲线。
3. ✅ 亮点 — 规范的缺口保持可见（Canonical gaps stay visible）。 空的层不会被过滤掉。审计引用 CoverageCloud.tsx。对比之下，当前的 LayerProfile.tsx 在域没有层或没有习惯时直接 return null，整块层画像被隐藏——从源码结构推断，「空层如何呈现」在后续重构中做了取舍变化，这正是审计记录作为「不许回退」基线存在的价值：下一次重构需要对照此条决定是刻意收敛还是无意丢失。

五个体验缺口（Experience gaps）：按严重度排序，逐条给出证据与整改方向

严重度标尺来自 SKILL.md 的共享规则：🔴 破坏信任（数据丢失、误导性「空」掩盖了失败、静默失败）；🟠 死路或误导（无前进路径、歧义状态、空态不是一个真正的页面）；🟡 摩擦/不一致/错失的惊喜（最容易漏报的一档）。原记录的五条缺口完整继承如下：

1. 🔴 Lessons 失败伪装成「零 lessons」。 代码只读取了域请求的 error/loading 状态；独立的 lessons 拉取失败后，数据被 lessons ?? [] 兜底成空数组，界面上呈现为「这个域什么都没学到」——一个把失败伪装成空态的误导性空态，因此按「misleading empty hides a failure」直接定 🔴。证据：Detail/index.tsx:77-78（?? [] 兜底）、:224-230（只读域级错误分支）。这与「Failure + Retry ⚠️」的评级是同一枚硬币的两面。
2. 🟠 无练习是死路。 零练习状态只解释不引导：没有「开始匹配一个 Topic」、没有「查看可能的匹配项」、也没有「编辑边界」这类出口动作。
3. 🟠 检测到的缺口没有纠正动作。 空层、未被使用的习惯、未被锚定的习惯全部是只读展示，检测能力与干预能力脱节。
4. 🟠 专长（expertise）生命周期是只读的。 审计时点不存在编辑、暂停、归档、删除操作。这一点在当前仓库已有变化迹象：从源码结构看，src/features/SelfLearning/index.tsx 顶部已引入 Trash2Icon 与 confirmModal（L7-L5 依赖区），可以推断审计之后该页面已经补上了删除类生命周期操作——恰好演示了「审计 → 落地整改 → 下次审计复验」的循环。
5. 🟡 实现指标抢在决策之前。 页面先呈现一堆指标（做对率、覆盖率等），却没有一等的「What needs attention / what next」区块——用户看完数据仍然不知道下一步该做什么。

Skill feedback：审计不是终点，回灌检查清单才是

记录最后一节是闭环机制：

• Validates Read §1.1 multi-fetch failure and Act §3.4 lifecycle completeness.

含义是：本次审计发现的两个可泛化缺口，分别验证了 ux 技能中两条既有清单规则的真实存在——Read §1.1（多 fetch 场景的失败处理：多个独立数据源时，每个都要有各自的 error/loading 分支，而不是只接第一个）与 Act §3.4（生命周期完整性：一类可管理实体应当具备编辑/暂停/归档/删除的完整动作集）。

完整闭环在 SKILL.md 的「Land the findings」一节定义：具体 bug 修掉顶部 🔴 或立项为子任务；可泛化的缺口必须回灌 ux（补强对应清单条目，并把被审计页面作为 ❌ 示例引用）；示范性亮点也要回灌（把 ✅ 案例写进规则的正例，必要时从中提炼新的子规则）；最后把整份审计保存为 references/example/<page>.md 作为下一次的模板。ux-audit 与 ux 技能构成闭环：ux 是审计的标尺，审计是让标尺持续变准的机制。本篇引用的样例文件本身，就是这个闭环的产物之一——同目录下还有 self-learning-overview.md、self-learning-lesson.md 等姊妹篇，可对照查看同一模块不同表面的审计差异。

如何复用这套方法：一份可执行的检查指引

如果你想在自己的页面上复刻这篇样例的审计方式，可以按以下顺序走：

1. 读审计技能定义：.agents/skills/ux-audit/SKILL.md 给出三层分工、覆盖矩阵（哪类结论只能由哪一层得出）、严重度标尺与输出模板；
2. 走模式目录：.agents/skills/ux-audit/references/pattern-catalog.md 按「导航 / 布局 / 输入 / 命令与动作 / 复杂数据 / 反馈 / 上手 / 视觉」八个家族列出要检查的模式名，并对每个模式标注「✅ solid / ⚠️ partial-or-misused / — absent-but-expected」三档记法。目录末尾还提示了该代码库历史上最薄弱的两个家族：Feedback（failure/retry 缺失）与 Input（草稿安全、placeholder 误用）——本样例的 🔴 缺口恰好落在 Feedback 家族，印证了这一观察；
3. 按层取证：L1 读代码给出 file:line（对应 layer-1-static.md），L2 截图验证渲染态（视觉层级、深色、窄屏），L3 用真实旅程下钻并强制空/错误态；
4. 按模板输出：Patterns in use 表 → 独立 Strengths 小节（✅ 亮点 + 证据）→ 按严重度排序的 Experience gaps（每条注明违反的清单条目、来源层级与证据、一行整改建议）→ Skill feedback（验证了哪些既有规则 / 新增了哪些可泛化缺口）；
5. 回灌并存档：把可泛化结论写回 ux 检查清单，把报告存入 references/example/，使下一次审计有模板可比对。

最后需要说明适用前提：本篇解读以当前仓库代码为准。审计记录中的 Detail/index.tsx、CoverageCloud.tsx 等路径属于撰写时点，当前仓库中该表面已重构到 src/features/SelfLearning/ 目录；引用行号以审计原文为准，涉及当前实现的论断均已标注对应文件与可查行号。