impeccable Operate 模式设计指南：让产品型 UI 消失在任务之中

导读

本文档围绕 impeccable 技能体系中的 Operate mode（操作模式） 深度准则展开，面向一切"用户处于任务流中"的界面——应用 UI、管理后台、设置面板、数据表格、工具与登录态页面。文章从"产品 slop 测试"这一判定标准出发，系统讲解这类表面在排版、色彩、布局、组件、动效上应当遵守的规则与边界，并结合仓库内的源码、测试夹具与打包副本给出可验证依据。读完你将掌握一套可直接用于产品型界面评审与设计的纪律清单，理解为何"熟悉感本身就是一种特性"。

Operate 模式在整个技能体系中的位置

impeccable 将每个设计请求按其"访客的成功形态"划分为四种模式（见 .hermes/skills/impeccable/SKILL.md）：

• Persuade：访客做决定并行动，设计即产品——落地页、营销、定价页。
• Operate：访客完成任务——应用 UI、仪表盘、编辑器、管理后台、设置页、工具。本指南主角。
• Read：访客理解内容——文档、文章、帮助、变更日志。
• Experience：访客身处作品之中——作品集、画廊、展示站。

其中一条重要原则是：模式由请求的表面决定，而非由产品类型决定——工具类产品的落地页依然是 Persuade，时装屋的文档依然是 Read，文档首页是 Read 而非 Persuade。Operate 的基础要义记录在 SKILL.md 的模式章节与 craft-floor.md（质量底线、绝对禁令与检测器无法发现的"本能反应"清单）中；本文（operate.md）则是为 Operate 表面补充的延伸深度，聚焦扫描效率、一致性、原生预期与真实使用场景优先于自我表达的细节纪律。

值得一提的还有 Read 表面：文档、指南、长文内容沿用 SKILL.md 的 Read 模式，但要叠加本文档的排版与一致性规则——它们的散文行长与导航层级比组件密度更重要。

产品 slop 测试：奇怪的失败比扁平更危险

文档提出的核心检验标准可以概括为一次"一分钟信任测试"：

一个对该品类足够熟悉的用户，能否立刻信任这个界面，还是会在每一个细节略微失调的组件上停顿？

在 Operate 面上，熟悉感本身就是特性。设计师常常误以为产品 UI 的失败形态是"太平坦"，因此去加装饰；而 impeccable 明确指出，产品 UI 真正的失败形态是 "没有目的的陌生感（strangeness without purpose）"：

• 过度装饰的按钮；
• 错配的表单控件；
• 无意义的动效；
• 在标签位置上使用了展示字体；
• 为标准任务凭空发明的手势/交互隐喻（invented affordances）。

判定合格的境界被总结为一句口号：earned familiarity（挣得的熟悉感）——工具应消失在任务之中。界面不是被注视的对象，而是完成任务时应该透明化掉的载体。该思路在源码侧同样被固化为可检测规则：文档中的每一条要点都携带机器可读的 rule: 注释标识（例如 product-typo-one-family、product-ban-modal-first-thought），供设计检测器在编辑后自动扫描比对。

排版：一个字体族、固定 rem 阶梯、更紧的倍率

Operate 表面的排版规则与前卫的品牌落地页截然不同，四条核心纪律如下（均可在 skill/reference/operate.md 中找到带规则 ID 的原文）：

一个字体族往往就是对的。 产品 UI 不需要"展示字体 + 正文字体"的配对。一套调校良好的无衬线字体即可承载标题、按钮、标签、正文与数据。多字体配对是品牌面追求个性表达的手段，在任务面上只会制造噪音。

固定 rem 字号阶梯，而非流式（fluid）。 产品 UI 不适用 clamp 缩放的响应式标题。用户基本在稳定 DPI 下工作，一个会随侧边栏变窄而缩小的流式 h1 只会更糟，不会更好。字号阶梯用 rem 固定下来，让系统密度在任何断点下都可预期。

更紧的字号比例。 相邻阶梯字号比通常在 1.125–1.2 之间。产品面上存在的文本元素种类远多于品牌面（标签、表格表头、按钮、工具提示……），夸张的对比度反差只会制造噪音。可用下表快速换算出一个 16px 基准下的典型阶梯：

用途建议	计算	示例 rem	像素（16px 根）
页面标题	1.2 × h2	2.488 rem	≈ 40px
区块标题	1.2 × h3	2.074 rem	≈ 33px
小节标题	1.2 × 正文大	1.728 rem	≈ 28px
加粗正文/面板标题	1.2 × 正文	1.44 rem	≈ 23px
正文	基准	1 rem	16px
元信息/标签	约 0.875	0.875 rem	≈ 14px

（表内为 1.2 等比放大演示，1.125 倍率可据此下推一档；具体以设计系统 token 为准。）

行长（measure）对散文依然适用：正文段落保持 65–75 字符；数据与紧凑 UI 可以更密集，表格行长到 120+ 字符也完全没问题——这是"排版规则服务于可读性，而非教条"的典型体现。

色彩：Restrained 是地板，语义状态词汇要标准化

Operate 表面的色彩默认进入 Restrained（克制） 档位，其概念与配色档位体系可参见 new-work.md 与 quieter.md（其中同样讨论了 Restrained/Committed 的取舍）。个别表面可以"挣得" Committed——例如由一个品类色撑起整个报表的仪表盘、用一个沉浸式欢迎屏开启的 onboarding 流程——但 Restrained 永远是底线。在此基础上，色彩纪律有三条：

1. 语义状态词汇必须丰富且标准化：hover、focus、active、disabled、selected、loading、error、warning、success、info——这些状态的色彩表达在整套产品内保持一致，而不是每次新写一套。
2. 强调色（accent）只用于三类用途：主操作、当前选中项、状态指示器——绝不用于装饰。
3. 要有第二层中性色：侧边栏、工具栏、面板使用比内容表面略微偏冷或偏暖的第二中性色层，以此建立层级的空间暗示，而不是依赖阴影去"硬挤"出前后关系。

这条"状态词汇标准化"纪律正是 slop 界面的重灾区：许多产品 hover 色随意、focus 环缺失、disabled 状态对比不足，用户只能靠猜。impeccable 的要求是让这十种状态成为一套可复用的语汇，而非每次重复发明。

布局：响应式是结构性行为

Operate 布局只有一条总纲，但含义极深：

响应式行为是结构性的（structural），而不是流式排版。

意思是：响应式应通过折叠侧边栏、表格改为可横滚/卡片化、按断点重排栅格列这些结构手段完成；而字号不随视口缩放。这与排版纪律中的"固定 rem 阶梯"互为犄角——结构性响应 + 固定排版密度才是产品 UI 的适配方式。密度是操作面的正当需求：多行表格、多标签面板、需要密集信息时就给足密度，不必为"呼吸感"牺牲操作效率。

组件：每个可交互组件都要有完整的 7 状态

组件纪律的第一句是硬性要求：每一个可交互组件都必须具备 default、hover、focus、active、disabled、loading、error 七个状态，"不要只交付一半就上线"。这与 craft-floor 的 States 检查（hover、disabled、loading、error、empty）同源互补。

在此基础上还有四条操作建议：

• 加载用骨架屏（skeleton），而不是内容中央转圈。 spinner 出现在内容中间是最常见的"敷衍加载"信号；骨架屏让用户感知结构即将到来。
• 空状态要"教"用户使用界面，而不是写一句 "nothing here"。 空状态是第一次使用的教学时刻，应给出下一步动作指引。
• 跨表面一致的可供性（affordance）：同样的按钮形状、同一套表单控件语汇、同一风格的图标。SaaS 里"保存按钮在两处长得不一样，其中必有一个是错的"。
• 浮层必须逃出容器：绝对定位的下拉层若挂在 overflow: hidden 或 overflow: auto 的祖先内部会被裁切——应改用 <dialog>、Popover API、position: fixed 或 portal。

最后一条在仓库中有精确的测试对应：夹具 clipped-overflow-container.html 专门构造了 overflow: hidden / overflow: clip 容器内逃逸定位子元素的命中用例（flag-overflow-hidden、flag-overflow-clip 等），同时给出通过侧样本：overflow: visible、真正的滚动区域 overflow: auto、以及完全包含在裁剪盒内的合法装饰。这说明"浮层逃逸"不是一句口头建议，而是被写成可自动检测的规则。

动效：150–250ms，只表状态，不表演编排

Operate 用户的动效预期与品牌展示页完全不同——用户在任务流里，不该等待编排演出。三条准则：

• 大多数过渡控制在 150–250ms。 用户正处于心流中，不要让他们等"编舞"完成。
• 动效传达状态，而非装饰。 只有状态变化、反馈、加载、揭示（reveal）四类用途是被允许的；"别的都没有"。
• 禁止编排化的页面加载序列。 产品是加载出来给用户干活的，用户不想看它加载的过程。

这条与 craft-floor 的 Motion 检查（一个手写的关键时刻，而非散落的效果、更非每个区块相同的入场动画）一致，也呼应了"动效的调色板不止 transform/opacity，还包括 blur、backdrop-filter、clip-path、mask、shadow"的进阶用法——但前提始终是"服务于状态传达且保持顺滑"。

产品约束（Product constraints）：六条禁令

下面的清单是操作面的默认禁令——不是不可破，而是默认成立，除非有明确理由挣得豁免：

1. 不传达状态的装饰性动效。
2. 跨屏幕不一致的组件语汇。"保存按钮在两处不一样，其中一个就是错的。"
3. 展示字体用在 UI 标签、按钮、数据上。那是品牌面的声音，不是任务面的声音。
4. 为标准可供性重造轮子：自定义滚动条、猎奇表单控件、非标准模态框——一律是减分项。
5. 非激活/非活跃状态上使用重色或全饱和强调色。它们会与真正的状态色抢注意力。
6. 把模态框当第一反应。"模态框通常是懒惰的产物。先穷尽内联（inline）/渐进式（progressive）的替代方案。"

第 6 条值得展开：impeccable 并非禁止 modal，而是要求把它当作最后手段——先问能否用内联展开、就地编辑、抽屉、渐进披露等不打断任务流的方式解决；只有当任务确实需要中断或受保护焦点时（craft-floor 措辞），模态框才被允许。

产品权限（Product permissions）：品牌面做不到的，产品面可以

Operate 表面比品牌表面拥有更多"免费许可"——这正是它能达到高密度的原因：

• 系统字体与熟悉的默认无衬线字体。不需要为了"品牌感"自托管一套展示字体。
• 标准导航范式：顶栏 + 侧边导航、面包屑、标签页、命令面板（command palette）。这些是用户已经内化的交互词汇，直接使用就是最好的可用性。
• 密度：需要时，多行表格、多标签面板、密集信息都是正当的。低密度并不自动等于高级。
• 一致性优先于惊喜：屏幕与屏幕之间使用同一套视觉语汇是美德；delight 被保留给"时刻"，而不是"整页"。

最后一句是整个权限章节的题眼：产品面的一致性是信任的基础设施，惊喜是稀缺资源，必须花在关键时刻（成功完成的瞬间、空状态的教学时刻）而不是均匀撒在整个界面上。

从文档到检测：这条纪律在仓库里如何被固化

"operate 纪律"在 impeccable 仓库里不只是一份阅读材料，它已经进入工程化的检测链路：

• 规则 ID 注释：skill/reference/operate.md 中的每一条规则都以 <!-- rule:product-* --> 或 <!-- rule:skill-* --> 的机器可读注释收尾（如 rule:product-typo-one-family、rule:product-color-restrained-default、rule:skill-interaction-dropdown-clipping），使文本规则能被程序稳定索引与对齐。
• hooks 机制：通过 /impeccable hooks 可开关本项目的设计检测器（详见 hooks.md），它在每次 UI 文件编辑后自动扫描并呈现发现项，相当于在编码循环中实时执行本指南的机械检查。
• 测试夹具：tests/fixtures/antipatterns/ 下存在大量与 Operate 规则一一对应的正反样本，例如 clipped-overflow-container.html（浮层裁切）、undersized-ui-text.html（UI 文本过小）、overused-font.html（字体滥用）等，每个 FLAG 用例都对应一类 slop。
• 分发副本：本指南随技能一起分发到各 Agent 运行时目录（如 .hermes/skills/impeccable/reference/operate.md），并被打包进插件形态的 plugin/skills/impeccable/reference/operate.md，保证不同宿主下读到同一套纪律。

落地检查清单

把本文整理成一份可直接用于评审的检查单（编号对应 skill/reference/operate.md 中的规则 ID）：

• [ ] product-typo-one-family：整套 UI 是否一套字体族打底？
• [ ] product-typo-fixed-rem-scale：字号是否固定 rem 阶梯、无 clamp 流式？
• [ ] product-typo-tighter-ratio：相邻字号比是否落在 1.125–1.2？
• [ ] product-color-restrained-default：色彩是否默认 Restrained、强调色是否只用于主操作/选中/状态指示？
• [ ] product-color-state-vocab：十种语义状态（hover…info）是否全局标准化？
• [ ] product-layout-responsive-structural：响应式是否靠结构手段而非流式排版？
• [ ] product-components-all-states：每个组件是否七个状态齐备、无半成品？
• [ ] product-components-skeleton-loading：加载是骨架屏还是内容中央转圈？
• [ ] skill-interaction-dropdown-clipping：浮层是否被 overflow: hidden/auto 祖先裁切？
• [ ] product-motion-quick-transitions：过渡是否 150–250ms？
• [ ] product-motion-state-not-decoration + product-motion-no-page-load-sequence：动效是否只表状态、无整页加载演出？
• [ ] product-ban-*：六条禁令是否全部未触犯（尤其"modal 是不是第一反应"）？
• [ ] 最后把 craft-floor.md 的 Verify/Refuse 清单再过一遍——地板守住了力学，天花板留给已被挣得的视觉世界。

一句话收尾：在 Operate 面上，最专业的技巧是让用户在完成任务时完全注意不到设计的技巧。 规则之外若有分歧，先问"这个界面消失进任务了吗"——答案会替你裁决。