Frontend Design Specs

适用范围

适用于需要做前端设计、前端改版、后台工作台界面、信息型管理页、产品页、落地页、设计系统收口、界面重构的任务。

这份文档是默认前端设计规范。除非用户明确给出更强的项目规范、现成设计系统或直接视觉方向，否则前端设计应严格参考本规范执行。

规则优先级

发生冲突时，按下面顺序裁决：

1. 用户本轮任务明确给出的视觉方向、业务目标、品牌要求
2. 当前项目已经存在并且仍然有效的设计系统 / 组件系统 / 规范化品牌规则
3. 本文中针对特定 surface 的专门规则
4. 本文中的默认规则

如果项目已有稳定设计系统，优先保持既有语言，不要为了套用本文而破坏现有系统一致性。

Surface 分类

开始设计前，先判断当前任务属于哪一类 surface：

1. 控制台 / 工作台 / 运维面 / dense admin list
2. 信息型管理页 / 设置页 / 数据页
3. 产品页 / 功能承载页
4. 落地页 / 营销页 / 叙事页
5. 混合面

不要把某一类 surface 的语言硬套到另一类 surface 上。

其中：

• 控制台 / 运维面默认强调信息密度、扫读效率、状态判断、直接操作
• 产品页默认强调主任务路径、模块节奏、价值理解、操作转化
• 落地页默认允许更明确的视觉主张，但仍然不能落入模板站拼装感

console-web 实施落点

对于 E:\My Project\Atramenti-Console\codex\apps\console-web，当前可执行模板层已经固定在：

• codex/apps/console-web/design-system/
• codex/apps/console-web/modules/ui-system/

约定：

• design-system/ 负责 contracts / patterns / states / mapping / ai / checklist
• modules/ui-system/ 负责 tokens / lint / components / patterns 的实现收口
• 页面若需要新增 reusable UI 规则，优先先补 design-system/，再补 modules/ui-system/

dense admin list 触发条件

如果页面属于运维、控制面、监控、服务管理、部署、域名、运行时、设置面板等场景，或页面的主目标是：

• 快速扫读事实
• 对比对象状态
• 发现异常
• 快速操作
• 高频录入与筛选

则视为 dense admin list 场景，必须额外遵守本文中的 dense admin list 规则，不要退化成营销卡片墙。

一、核心立场

1. 总原则

1. 优先产品原生感，不优先“单次看起来惊艳”的装饰感
2. 优先信息与交互效率，不优先无意义留白
3. 优先单层结构，不优先多层包裹
4. 优先清晰层级，不优先堆砌组件
5. 优先内容驱动布局，不优先模板驱动布局
6. 优先统一产品语言，不优先局部 showcase 感
7. 优先长期可演化，不优先一次性的视觉噱头

一句话：先把信息组织对，再考虑样式；先像真实产品，再像设计展示稿。

2. 组件搜源优先原则

在设计组件、局部交互、视觉细节、微动效、输入控件、反馈样式时，默认不要第一反应从零空想。

默认优先顺序应当是：

1. 先看当前项目里是否已有可复用的 canonical 组件或成熟局部模式
2. 若项目内没有合适基础，优先参考 https://github.com/uiverse-io/galaxy
3. 再去找已经存在的优秀开源方案，以及高水平产品团队公开放出的实现
4. 吸收之后，再按当前产品的单一视觉语言做收口，而不是把来源原样拼接进来

默认借鉴方式应当是：

• 借结构，不先借表皮
• 借细节，不借整页拼装
• 借节奏，不借装饰堆砌
• 借成熟交互反馈，不借模板站的整套视觉噪声

禁止把多个来源直接拼成视觉杂烩，也禁止因为“来源高级”就无条件照搬到不匹配的场景。

3. 默认统一气质

后续设计默认统一收口到下面这套方向，除非用户明确给出更强视觉方向：

• 克制
• 冷静
• 专业
• 原生产品感
• 强结构
• 弱装饰
• 高完成度工具感

默认目标不是“像模板站”，也不是“像展示页”，而是像一套真正长期演化中的成熟产品。

4. 默认视觉方向

在没有更强项目约束时，默认要先明确下面 4 个方向，并在页面中保持一致。

Typography

• 必须显式选择字体策略，不要把 Inter、Roboto、Arial、泛 system UI 当成默认答案
• 控制台 / 工具页优先选择中性、清晰、密度友好的字体系统
• 产品页 / 落地页允许更强识别度的标题字，但正文仍要保证长时间阅读稳定
• 同一页面只允许一个主标题体系和一个正文字体系，不要混成字体拼盘

Color

• 一个主品牌强调色即可，不要同时有多个主角颜色
• 中性色负责结构与层级，状态色负责状态语义，品牌色负责品牌或主动作，不混用职责
• 默认优先低到中饱和度的稳定配色，不做紫色优先、不做无解释的暗色偏执

Background

• 控制台 / 信息页优先分层背景、浅对比 surface、细腻材质感，不优先纯平单色空白页
• 产品页 / 落地页允许更明确的大气氛背景，但背景必须服务内容，不可吞掉信息层级
• 背景变化应来自层次、光感、纹理、区块组织，而不是纯粹堆叠花哨渐变

Motion

• 动效默认只承担状态反馈、层级切换、焦点引导、局部展开 / 收起
• 不做炫技、不做戏剧化、不做为了“显高级”而存在的表演型动效
• 页面进入、模块显现、筛选反馈可以有，但要轻、短、结构化

二、固定前端设计顺序

以后做前端设计时，默认固定按下面顺序走，不再临场乱跳：

1. 定 surface 类型
   • 先判断这是控制台、工作台、信息页、产品页、落地页，还是混合面
   • 先判断主目标是扫读、操作、比较、录入，还是展示、转化、叙事
2. 定主职责与层级
   • 先确定 header、sidebar、summary、content、warning、action 各自负责什么
   • 先把一级信息、二级信息、次级说明分清
3. 定系统层基础
   • 先确定字体、颜色、背景、动效的统一口径
   • 先确定 spacing、grid、breakpoint、radius、border 的基础尺度
4. 搜现成成熟方案
   • 先查项目内 canonical
   • 再查 https://github.com/uiverse-io/galaxy
   • 再查高质量开源产品与成熟设计系统实现
5. 抽结构，不抄表皮
   • 只提炼布局骨架、比例、反馈、节奏、状态表达
   • 不整套搬运别人视觉皮肤
6. 统一视觉语言
   • 统一圆角、边框、阴影、字号、密度、颜色、动效
   • 保证新模块像同一个产品里长出来的
7. 再补组件与细节
   • 在结构成立后再补按钮、输入框、卡片、状态条、空态、hover、折叠等局部细节
   • 不允许局部细节反过来绑架页面结构
8. 最后做收口自检
   • 是否像成熟产品，不像模板站
   • 是否主信息最先被看到
   • 是否有多来源拼盘感
   • 是否有过度装饰、过度动效、过度卡片化
   • 是否通过移动端与可访问性检查

一句话顺序版：

定类型 -> 定职责 -> 定系统层 -> 搜成熟方案 -> 抽结构 -> 统一语言 -> 补细节 -> 做收口自检

三、系统层基础规范

这部分不是可选补充，而是落地时必须明确的执行层约束。

1. Spacing Scale

默认使用统一 spacing scale，不允许页面内部随意漂移。

推荐默认间距节奏：

• 4：极小间距、图标与文本、紧贴性内边距
• 8：紧凑控件内边距、小型组件间距
• 12：常规紧凑布局的单元间距
• 16：标准模块内边距 / 表单字段间距
• 24：模块级分组间距
• 32：区块级分隔
• 48-64：页面大区块节奏

规则：

• 优先复用已有尺度，不随手造 13、18、22 这类漂移值
• dense admin list 优先 8 / 12 / 16 / 24 节奏，不要无意义拉大
• 产品页 / 落地页可用更大节奏，但必须服务层级与叙事，不服务空洞感

2. Grid 与容器

默认要求：

• 桌面端优先稳定栅格，不靠目测摆放
• 控制台 / 工作台优先 12 栏或等价的内容轨道系统
• 信息页优先单主列或双列 facts 结构
• dense admin list 优先横向阅读带，而不是纵向堆叠盒子
• 手机端优先单列，必要时保留有限横向滚动，不要强行塞满桌面结构

3. Typography Scale

默认至少定义下面 5 层：

• 标签层：11px-12px
• 正文层：13px-14px
• 强调正文 / 主值层：15px-16px
• 区块标题层：18px-20px
• 页面标题层：24px-32px

同时遵守：

• 标题只比下一级高一档，不靠巨大字号硬拉层级
• 备注层必须弱于主值，不与主信息抢层级
• 行高优先可读和稳定：正文约 1.45-1.6，标题约 1.2-1.35
• 不允许同一页面里出现多套彼此无关的字号逻辑

4. Color Tokens

至少定义下面 4 组语义色：

1. 中性色：承担背景、边框、正文、弱文本、分隔线
2. 品牌色：承担主按钮、主链接、品牌强调
3. 状态色：success / warning / danger / info
4. 焦点色：focus ring 与键盘可见反馈

规则：

• 状态色只表达状态，不额外承载新的复杂语义
• 品牌色不替代危险态和警告态
• 背景色优先表达层次，不表达热闹
• 任何状态都不允许只靠颜色表达，必须有文字、图标或结构辅助

5. Radius / Border / Shadow

默认建议控制在有限层级：

• radius-sm：6px
• radius-md：10px
• radius-lg：14px

边框与阴影规则：

• 优先用分隔线表达结构
• 只在真正需要强分组的地方保留完整边框
• 不允许连续两层完整边框表达同一层级
• 阴影只做微弱层次区分，不做厚重浮空感
• dense 页面宁可减少盒子，也不要增加大圆角容器

6. Motion Tokens

默认时长范围：

• 120ms-180ms：hover、focus、状态切换
• 180ms-240ms：局部展开 / 收起、轻量进入
• 240ms+：慎用，只限确有结构意义的转场

默认优先：

• opacity
• color
• translateY
• height
• transform 的轻量变化

默认不优先：

• 弹跳
• 甩动
• 重 easing
• 夸张 scale
• 与结构无关的循环动画

四、Surface 结构原则

1. 页面级结构

默认按下面顺序组织页面：

1. 页头：标题、状态、关键动作
2. 摘要层：少量关键数字 / 关键状态
3. 主体层：核心内容模块
4. 次级层：备注、补充说明、帮助信息

2. 模块级结构

模块默认应尽量简单：

• 标题
• 很短的说明（可无）
• 单层内容区

禁止默认写成：

• 外卡片 + 内卡片
• 外容器 + 子容器 + 子子容器
• 同一层信息被拆成很多视觉盒子

3. 界面职责单一原则

每个界面元素默认只承担一种主职责，不要让多个元素争抢同一种语义。

• sidebar：一级导航
• header：页面身份、页面状态、主动作
• breadcrumb：路径上下文
• tabs：当前页面内部的子视图切换
• content：事实、数据、说明、检查项
• warning / banner：风险提示

禁止默认出现这些情况：

• 用 header tabs 重复 sidebar 已承担的一级导航
• 用内容卡片承担导航语义
• 用 badge 承担布局主体
• 用备注区承担主信息解释

4. Surface Ownership 原则

开始画页面之前，先定义每个 surface 的拥有权，再决定往里面放什么。

至少先回答：

1. 谁拥有一级导航权
2. 谁拥有页面身份表达权
3. 谁拥有主动作入口
4. 谁拥有事实信息承载权
5. 谁拥有风险提示权

如果某个元素不拥有这项职责，就不要把对应内容硬塞进去。

5. 层级一致性原则

信息层级、交互层级、视觉层级必须一致。

• 最显眼的元素，必须也是语义上最重要的元素
• 一级入口只能有一个一级入口源
• 次级说明不能比主信息更抢眼
• 视觉分组不能超过真实语义分组

如果用户先看到的是导航重复、边框层级、备注块、装饰块，而不是页面当前状态与主信息，说明层级设计失败。

6. 控制台 / dense admin list 的首选结构

对于运维、控制台、设置、数据、管理类页面，默认优先：

• list
• table
• dense grid
• key/value facts
• section + divide lines
• 单行概览带 / 紧凑摘要条

而不是：

• marketing cards
• feature cards
• showroom tiles
• 大块图文面板
• 一排平均宽度的小统计卡

页头下状态条的职责默认是：

• 只给页面级摘要
• 只给少量关键计数 / 聚合状态 / 风险数量
• 只做扫读，不做展开解释

不要把正文模块已经会完整展开的子项，先在状态条里逐条重复一遍。

7. 产品页 / 功能承载页的额外要求

产品页默认不能照搬 dense admin list 的冷硬布局，也不能退化成模板站。

默认要求：

• 先定义单一主路径：理解 -> 相信 -> 操作
• 允许更明确的标题层级、节奏变化和局部视觉记忆点
• 允许有主视觉区，但主视觉必须服务核心信息，不可遮挡主任务
• 可以使用更有性格的排版与背景，但仍需保持统一产品语言

不允许：

• 用一堆 feature cards 代替真实信息结构
• 用多个风格各异的 showcase 模块拼页面
• 为了“高级感”牺牲信息到达速度和按钮辨识度

8. 落地页 / 叙事页的额外要求

落地页可以比控制台更有氛围，但必须保持节制。

默认要求：

• 必须有清晰 hero 区、价值解释区、证据区、行动区
• 背景、插图、渐变、排版对比要为叙事服务，不是为装饰存在
• 允许更强的字体态度和更大区块节奏，但全页仍然只允许一种主视觉语言
• 移动端必须保住主信息和主 CTA，不允许只在桌面端成立

五、内容组织原则

1. 去重与去竞争原则

同一信息、同一入口、同一状态，不要在同一屏重复表达，除非它们承担不同语义。

常见需要避免的重复包括：

• sidebar 已有一级导航，header 又重复一遍同级 tabs
• 页头已经给出当前状态，正文摘要区再次重复同一状态
• 同一个对象在多个模块重复做完整介绍
• 同一路径、归属、目标节点在多个平行区块重复展开
• 页头下状态条已经做了页面级摘要，正文模块又把同一组摘要 facts 原样重复一遍
• 为了“概览完整”而在状态条里重复正文模块即将展开的子状态

默认要求是：一项信息只保留一个主表达位，其他位置如果必须出现，只能做弱引用或上下文补充。

2. 主信息优先

用户应该先看到：

• 当前状态
• 关键值
• 关键对象
• 关键动作

而不是先看到：

• 大段说明
• 装饰性空白
• 无意义图标墙

3. 备注降级

• 备注永远是辅助层
• 备注不能压过主值、状态、目标、路径、归属
• 长备注要么弱化为次级文本，要么折叠，不要默认占据强视觉区域
• 在 dense admin list 中，长备注默认优先折叠成次级说明，不要继续做成常展开说明块

4. 路径与事实信息

路径、ID、域名、目标节点、服务名、运行根等事实型信息，默认使用：

• 紧凑 key/value
• 固定 label 宽度
• 可换行 value
• 横向栅格对齐

不要把每条 facts 拆成独立小卡。

六、视觉层级原则

1. 结构优先于装饰

• 优先用布局、对齐、留白、字号、分隔线建立层级
• 不要靠堆边框、堆阴影、堆圆角制造结构感
• 一个页面里真正需要“强视觉容器”的地方应当很少

2. 边框与背景

• 优先用轻边框和分隔线表达结构
• 背景色只用来表达层次，不用来堆热闹
• 不要连续出现多个强对比 surface 抢同一层级
• 不要用大面积花哨底色替代真实的信息组织

3. 圆角

• 轻圆角即可
• 不要靠厚重圆角制造“模块感”
• dense 页面里宁可减少盒子，也不要增加大圆角容器

4. 图标与插画

• 图标只做识别辅助，不承担主层级结构
• 状态图标应与文本或 badge 联合表达，不做唯一载体
• 插画只在空态、引导、品牌叙事确有必要时使用，不随手塞进信息页主体

七、交互原则

1. 动作要少而明确

• 顶部动作只放真正常用动作
• 不要把所有操作堆进页头
• 不要为了“功能完整”牺牲辨识度
• 危险动作默认二次确认，常用动作默认直达

2. 展开与折叠

• 只有当信息明显过长或次级时才折叠
• 默认先把一眼必须知道的东西直接展开
• 折叠是为了降噪，不是为了制造交互

3. 反馈

• 状态 badge 只做辅助，不承担排版主体
• 错误 / 风险 / warning 应独立且短，不写成长解释块
• 成功、失败、处理中都必须有清晰反馈，不允许静默失败

4. 导航去重原则

同一组 sibling pages 在同一视图中默认只能有一个主导航源。

• 如果 sidebar 已承担一级导航，header 不得再重复放同级 tabs
• header 默认只放标题、状态、主动作、breadcrumb
• 只有在顶部导航承担不同层级切换时，才允许保留 tabs
• 如果顶部和侧边都存在导航，必须能明确证明它们不是同一层级

不要让用户在进入页面后先判断“两套导航有什么区别”。

5. 压缩型可视化原则

在 dense admin list、控制面、运维页、状态页中，如果需要引入可视化，默认应遵循压缩型可视化原则：允许用更紧凑的图形表达替代一部分重复文字，但前提是它必须比纯文字更直观、更省空间，而不是生成新的展示层。

压缩型可视化默认优先：

• 状态分布条
• 比例条 / bullet bar
• 微型 sparkline
• uptime 小格 / heartbeat strip
• 嵌入在事实带或状态条中的微型可视化

而不是：

• 独立的大图表卡片
• 带重图例、重坐标轴、重装饰的 dashboard 图表
• 为了“看起来高级”而放的图表模块
• 需要用户停下来理解图例和交互方式的复杂可视化

页头下状态条里的可视化，默认只能表达页面级摘要：

• 关键计数
• 聚合状态
• 风险数量
• 启用比例

如果没有可靠的历史数据，就不要伪造趋势表达。

6. 压缩型交互原则

如果需要加交互，默认应符合当前风格：静默、直达、局部展开，不制造第二层界面。

交互默认应当服务：

• 降噪
• 定位
• 对比
• 快速到达目标对象

而不是服务：

• 炫技
• 演示感
• 层层 drilldown
• 额外的界面戏剧性

默认优先的交互方式：

• 行内展开 / 收起，用来承载长备注、次级说明、补充路径映射
• 点击状态项、分布条、比例条后，在同页做筛选、聚焦、高亮或锚点跳转
• hover 只做增强信息，如精确值、更新时间、状态定义，不承担唯一信息载体
• 针对主对象提供直接动作，如打开、复制、跳转、定位到对应行

默认不优先的交互方式：

• 为普通 facts 单独弹 modal 或 drawer
• tabs 套 tabs、accordion 套 accordion、图表再套 drilldown
• 只有 hover 才能看到关键信息
• 为了“高级感”加入多段交互状态切换

八、核心组件 Contract

以下不是组件样式图册，而是组件的职责与结构 contract。

1. Navigation

• sidebar 承担一级导航
• breadcrumb 承担路径上下文
• tabs 只承担当前页面内部的同级子视图切换
• 不允许同一层级出现双导航源

2. Page Header

页头默认只承载：

• 页面标题
• 当前状态
• 主动作
• 必要的 breadcrumb / 次级描述

不要把页头扩成第二个控制面板。

3. Summary Strip / 概览带

适合承载：

• 关键计数
• 聚合状态
• 风险概览
• 启用比例
• 小型压缩可视化

不适合承载：

• 正文模块即将详细展开的完整子项
• 复杂解释
• 二级导航

4. List / Table / Dense Grid

默认要求：

• 优先支持扫读、比较、排序、筛选
• 一条记录尽量保留在同一阅读带内
• 列定义要稳定，不随意漂移
• 关键状态、归属、目标、动作的相对位置要稳定

不允许：

• 一条记录拆成多张卡片
• 每条记录都变成一个自成体系的小页面

5. Facts / Key-Value Block

默认要求：

• label 宽度稳定
• value 可以换行但不乱跳
• 相邻 facts 对齐
• 适合路径、域名、ID、节点、来源等事实型信息

6. Form

默认要求：

• 标签、输入、帮助信息、错误信息层级明确
• 必填、选填、危险设置要被直接理解
• 错误信息紧贴字段，不靠全局弹窗替代
• 提交前后状态清楚：可提交、提交中、成功、失败

7. Filter / Search / Sort

默认要求：

• 高优先筛选放在离列表最近的位置
• 默认值与当前筛选态可见
• 已生效的筛选必须可逆、可一键清空
• 移动端可以折叠收纳，但不能隐藏当前已激活条件

8. Empty / Loading / Error State

必须覆盖：

• 无数据
• 首次加载
• 局部刷新
• 请求失败
• 权限不足或无结果

规则：

• 空态要解释“为什么空”和“下一步能做什么”
• loading 不要只剩骨架而没有上下文
• error 要给短解释和恢复动作，不要只有红字

9. Warning / Risk / Status

• warning 是风险提示，不是新主体
• status badge 只做辅助，不承担布局骨架
• 高风险项优先做紧凑分隔行或集中风险区，不做一条一块的小提示卡

10. Modal / Drawer

默认只在下面场景使用：

• 确认型危险操作
• 脱离上下文会更清楚的集中编辑
• 多步骤但仍短流程的辅助操作

不要为普通 facts、普通查看态、普通说明硬开 modal / drawer。

九、响应式与多端规则

这是前端规范的必备部分，不可省略。

1. Breakpoint 基线

默认至少覆盖：

• Mobile：< 768px
• Tablet：768px - 1199px
• Desktop：>= 1200px

如果项目已有更细 breakpoints，可复用，但必须有同等清晰度。

2. 响应式原则

• 手机端优先保住主信息、主状态、主 CTA
• 不把桌面端的三列、四列结构机械压扁到手机端
• 概览带可以换行，但优先保持摘要语义，而不是变成卡片墙
• 表格在小屏要么转成可横滑的稳定表格，要么转成分组 facts 结构，不要直接挤爆
• 筛选区在小屏可以折叠，但当前已生效的筛选条件必须可见
• 不允许依赖 hover 才完成关键操作或理解关键信息

3. 移动端检查底线

每次 user-visible 前端改动，至少自检：

• 首屏是否先看到主信息
• 主 CTA 是否一眼可见
• 触控目标是否足够大
• 文字是否可读且不会挤成碎片
• 横向滚动是否仅出现在确有必要的表格区域

十、可访问性规范

这是合格前端规范的一部分，不是额外加分项。

1. 对比度

默认要求：

• 正文文本与背景对比度至少达到 4.5:1
• 大号文本、关键图形、边框、焦点环至少达到 3:1
• 浅灰字配浅灰底的“高级感”默认判为不合格

2. 键盘可达性

默认要求：

• 所有关键操作都可通过键盘完成
• 焦点顺序符合阅读和操作逻辑
• 不允许焦点陷阱和看不见的 focus state

3. Focus Visible

• 每个可交互元素都必须有清晰 focus 可见反馈
• focus ring 颜色不能与品牌色、危险色冲突到不可辨识
• 不允许仅在 hover 有反馈，focus 却无反馈

4. 触控与点击区

• 关键交互目标应有足够点击面积，默认不小于 40px-44px
• 不要把多个危险动作挤在过小的点击区内

5. 状态表达

• 不能只靠颜色表达 success / warning / danger
• 至少结合文字、图标、位置或结构中的一种辅助方式

6. Reduced Motion

• 当系统或项目启用 prefers-reduced-motion 或等价 reduced motion 时，应关闭非必要运动
• 保留必要状态反馈，但去掉表演型过渡

十一、禁止项

以下做法默认判为不合格，除非用户明确要求：

• 框里套框
• 卡里套卡
• 同层事实拆成多个平行小盒子
• 检查项一条一块垂直卡片堆叠
• 为了显得“精致”而加入无信息增益的边框、底色、阴影、圆角层
• 让页面更像后台模板市场 demo，而不是现有产品的一部分
• 为同一组同级页面同时提供 sidebar 导航和 header 同级导航
• 让两个以上模块同时争抢同一个职责
• 使用默认安全模板感的字体、配色、背景与布局却没有明确理由
• 依赖 hover 才能理解关键信息
• 没做移动端检查就交付 user-visible 页面
• 没做 focus / keyboard / contrast 检查就声称规范完成

十二、评审与验收标准

前端设计完成后，至少满足下面三层检查。

1. 设计层检查

1. 当前页面属于哪类 surface，是否用了对应规则
2. 是否先看到主信息，而不是装饰、备注或重复导航
3. 是否只有一个一级导航源
4. 是否维持单一视觉语言，没有多来源拼盘感
5. Typography、Color、Background、Motion 是否已经明确并统一

2. 组件与实现层检查

1. spacing、grid、radius、border、motion 是否使用统一尺度
2. 关键组件是否覆盖正常态、hover、focus、disabled、loading、error
3. 表单是否有字段级错误反馈
4. 空态、加载态、错误态是否完整
5. 是否存在只有颜色没有文字辅助的状态表达

3. 运行与体验层检查

1. 桌面端是否成立
2. 移动端是否成立
3. 键盘路径是否成立
4. focus 是否可见
5. 用户是否能在最短路径内完成主任务

如果以上任一层明显失败，就不应判为规范完成。

十三、规范回写与一致性

前端实现与设计规范之间，默认必须保持同周期收口。

1. 如果这次 UI 更新形成了新的可复用设计指导，而且它不违背当前规范文本，就必须在同一工作周期内反向回写到本规范
2. 这种回写应当是补强、抽象、举例、收口，不应绕开当前规范另起一套隐性规则
3. 不允许先落地一个违背规范文本的 UI，再把“结果如此”当成既成事实
4. 如果实现方向与当前规范真的冲突，先把规范改写成新的单一一致文本，再推广实现，不允许让实现长期跑在规范前面
5. AGENTS.md 负责声明“必须参考并回写这份规范”，具体 UI 规则正文只放在本文件

十四、针对 dense admin list 的额外要求

如果页面属于运维、控制面、监控、服务管理、部署、域名、运行时、设置面板等 dense admin list 场景，则额外要求：

1. 默认优先列表，而不是卡片墙
2. 默认优先横向对齐，而不是纵向解释块
3. 默认优先单层信息区，而不是嵌套模块
4. 路径、归属、目标、状态、检查应尽量放进同一阅读带
5. 备注必须降权，不能主导布局
6. 可视化优先嵌入式压缩表达，而不是独立 dashboard 卡片
7. 概览带只保留页面级摘要，不重复正文细项

十五、当前已验证的落地方向

这份规范当前已经在 Mortis 运维面板中验证过以下方向有效：

• 顶部摘要去卡片化
• 真源区改成边界 facts list
• 执行路由改成更接近 table / list 的整块列表
• 服务器 / 部署 / 域名改成更紧凑的横向 dense grid
• 备注区继续降权，避免形成大块说明面板
• 检查项统一改成单层表格式结构
• 左侧导航保留为唯一一级导航源，页头移除重复同级导航
• overview 顶部摘要优先收成单行概览带，而不是再做第二层 summary 模块
• servers / deployments 的长备注优先折叠成次级说明，而不是常展开说明块
• warning / risk 区优先做紧凑分隔行而不是一条一块的小提示卡
• 需要引入可视化时，优先使用嵌入式压缩型可视化，而不是独立大图表模块

十六、文档位置

本规范固定放在：

• E:\My Project\Atramenti-Console\codex\plugins\obsidian\data\docs\agent\Frontend Design Specs.md

后续每次前端设计、前端改版、信息型页面重构，都应优先更新和复用这份文档，而不是再散落写新的临时设计规范。