Impeccable Operate 模式深度指南：让工具界面隐入任务的产品级设计规范

当用户处于"完成任务"的心流中时，界面设计应当服务于任务本身——操作后台、设置面板、数据表格、编辑器这类 Operate（操作）型界面的首要目标不是让人赞叹，而是让人毫不迟疑地信任它。本指南基于 Impeccable 技能中负责此范畴的深度参考文档 operate.md 展开，系统讲解产品型界面（product UI）与品牌型界面（brand surface）在设计取向上的分野：从"产品 slop 测试"的验收标尺，到排版、色彩、布局、组件、动效的分支规范，再到"产品约束"与"产品权限"两张清单，并说明它如何与 SKILL.src.md 中的模式体系、craft-floor.md 中的质量底线形成"要点在手册、纵深在此文"的协同结构。读完你将获得一套可立即用于评审或构建 dashboard、管理后台、工具类 Web 应用的可操作标准。

Operate 模式在 Impeccable 模式体系中的定位

Impeccable 的技能入口 SKILL.src.md 将设计工作按"访客在这块表面的成功形态"切分为四种模式：

模式	访客目标	典型表面	设计优先级
Persuade	做出决定并行动	落地页、营销活动、定价页	设计本身即产品，赢得注意与行动
Operate	完成任务	App UI、仪表盘、编辑器、后台、设置、工具	可扫读性、一致性、原生预期与真实使用场景高于表现力
Read	理解某件事	文档、文章、指南、帮助、变更日志	先为理解而组织结构，再让阅读体验值得停留
Experience	沉浸于作品之中	作品集、画廊、展示页	让作品从第一屏引领，界面退居其次

模式从所请求的表面而非产品本身来选取：某个工具软件的落地页仍是 Persuade，时装屋的文档仍是 Read，文档索引页是 Read 而不是 Persuade。Operate/Read 的进一步深度指引即指向本指南所依托的 operate.md。

operate.md 的引言明确交代了它在文档体系中的分工：

• 基础要点存放在 SKILL.md 的 Modes 一节与 craft-floor.md（craft 底线：在动手编辑 UI 前必须加载的质量地板），本文档是写给 Operate 表面的扩展纵深；
• Read 表面（文档、指南、长篇内容）取 SKILL.md 的 Read 模式，并叠加本文的排版与一致性规则——对 Read 而言，正文行宽（measure）与导航的可理解性比组件密度更重要。

换言之：craft-floor 是"任何界面都不许跌破的地板"，operate.md 是"产品界面应该达到的房间标准"。值得注意的是，这份文档在仓库中以近乎相同的形式随技能分发到各 Agent 生态目录（如 .trae/skills/impeccable/、.claude/skills/、.cursor/skills/、plugin/skills/ 等），以 .trae/skills/impeccable/reference/operate.md 为代表的分发副本会剥离源版本（skill/reference/operate.md）中形如 <!-- rule:product-* --> 的规则标记注释，正文保持一致。

产品 slop 测试：熟悉感本身就是功能

Familiarity is often a feature here. The test is whether a category-fluent user can trust the interface immediately or must pause at every subtly-off component.

产品界面的失败模式不是"太平"，而是无目的的陌生感（strangeness without purpose）：过度装饰的按钮、风格错位的表单控件、无意义的动效、本该是标签的地方用了展示字体（display font）、为常规任务发明不存在的交互暗示（affordance）。评判的标尺是"挣来的熟悉感"（earned familiarity）——一个对该品类驾轻就熟的用户能否立刻信任这个界面，而不是在每个"差一点就不对"的组件前停顿。理想状态下，工具应当消失于任务之中。

这一"slop 测试"范式在整个技能中反复出现为品类级的验收标准：原生侧同样存在 iOS slop test 与 Android slop test，adapt.native.md 也把迁移后的 slop 测试作为接纳线，本文则是 Web 产品表面的版本。

排版：单一字族、固定 rem 阶梯、紧凑比例

产品界面中用户在完成任务，排版的首要原则是不喧哗：

• 单一字族往往就是正确答案。 产品 UI 通常不需要"展示体 + 正文体"的配对；一支调校得当的无衬线字体应能同时承担标题、按钮、标签、正文与数据。这与 Persuade 表面常见的 display/body 双字族策略形成对照。
• 固定 rem 字号阶梯，而非流式（fluid）字号。 clamp() 式标题并不服务产品 UI——用户在多数据看一致 DPI 下查看界面，一个会随侧边栏收缩而缩小的流式 h1 只会更糟。产品界面的字号应当以 rem 为单位、随断点走结构性布局，而不是随视口连续缩放。
• 更紧凑的缩放比例。 相邻字号层级间 1.125–1.2 是典型比值。产品界面的文字元素远多于品牌表面，夸张的对比只会制造噪声。
• 行宽规则对散文仍适用（65–75 字符）。 但数据与紧凑型 UI 可以更密：表格跑到 120 字符以上完全没问题。

这与 craft-floor.md 的排版底线互相咬合：正文 measure 65–75ch、展示文本上限 6rem、字距下限 -0.04em、字号与字重层级清晰、每个断点都要用真实文案检查是否溢出。产品排版要在此基础上更收敛——在 typeset.md 有更通用的排版层级操作指引。

色彩：Restrained 是默认的地板，而非上限下的妥协

产品表面默认走 Restrained（克制） 策略。它可以有少数表面"挣得"Committed（例如用单一品类色承载整份报表的 dashboard、用沉浸式欢迎屏铺色的 onboarding 流程），但 Restrained 是地板。

此处的色彩词汇与 new-work.md 中建立的四档色彩策略（Restrained / Committed / Full palette / Drenched）一致：Restrained = 中性色 + 一个强调色，是"访客来操作或阅读"时的默认；Committed = 一种高饱和色承载表面 30%–60% 的面积。Persuade 与 Experience 表面才有权限采用更大胆的策略。在 live.md 的可变体（variant）轴中，色彩策略同样被列为六大主轴之一。

具体到产品表面的三条色彩纪律：

1. 富状态的语义词汇表。 hover、focus、active、disabled、selected、loading、error、warning、success、info——这些状态的表达必须标准化，并全表面一致使用。
2. 强调色只用于主操作、当前选中态与状态指示器，绝不做装饰。
3. 第二中性层。 为侧边栏、工具栏与面板提供一个比内容表面略暖或略冷的中性层，让层级来自中性色之间的细微温差，而非反复堆强调色。

反例同样明确：不活跃状态上不应出现重色或全饱和的强调色（见下文"产品约束"清单）。

布局：响应式是结构性的，不是排版性的

产品界面同样要响应式，但响应式行为是结构性的——折叠侧边栏、响应式表格、按断点切换列数——而不是流式排版。换句话说：响应式布局应该发生在"布局拓扑"层（组件如何排列、如何收纳），而不是发生在"字号随视口蠕动"的层。桌面表格在小屏上应转为可横向滚动、可降级为卡片堆叠等结构手段，而非靠压缩字距硬塞。

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

产品界面的组件纪律可以用一句话概括：每个可交互组件都应具备 default、hover、focus、active、disabled、loading、error 全状态，不要让只有一半状态的组件上线。 craft-floor.md 的 Verify 列表要求同样的范围（hover、disabled、loading、error、empty，外加真实内容、可用控件、响应式布局与键盘焦点），并确认这些是对成品的检查而非意图。

在状态之上的四条具体规范：

• 加载用骨架屏（skeleton），而不是内容正中央的 spinner。 骨架屏保持布局稳定，暗示内容即将就位；spinner 只表达"在转"，且往往打断阅读流。
• 空状态要"教会"界面，而不是一句 "nothing here"。 空状态是第一课：告诉用户这里能放什么、如何开始。这与 onboard.md（首跑流程、空状态、激活）的命令职责呼应。
• 全表面一致的 affordance。 同样的按钮形态、同样的表单控件词汇、同样的图标风格。这也是下文"一致性高于惊喜"权限的具体化。
• 浮层必须逃出其容器。 绝对定位的下拉菜单若位于 overflow: hidden 或 overflow: auto 的祖先内部会被裁切。正确手段是改用 <dialog>、popover API、position: fixed 或 portal。这个剪裁问题正是仓库反模式夹具所演示的典型缺陷（参见 tests/fixtures/antipatterns/clipped-overflow-container.html、tests/fixtures/antipatterns/overlay-positioning.html）——这些夹具用于让设计检测器捕获真实项目里最常见的浮层错误。

动效：150–250ms、表达状态而非装饰

• 绝大多数过渡控制在 150–250ms。 用户正处于流程中，不要让他们等待编舞般的动画。
• 动效表达状态，而非装饰。 只有状态变化、反馈、加载、揭示这一类才有资格用动效——除此之外一概不用。
• 不要编排整页加载序列。 产品是"加载后直接进入任务"的，用户不想看它"演出加载过程"。

craft-floor 对动效的另一条底线与之互补：只保留一个作者化时刻（one authored moment），而不是零散效果或每个 section 都来一次雷同入场；从已可见的默认态做指数缓出。产品界面在这条底线上继续收敛——动效的职责被压缩到"状态"本身。

产品约束清单：明确的禁用反模式

文档列出六条产品界面不许做的事，可直接作为评审 checklist：

反模式	说明
不传达状态的装饰性动效	与"动效表达状态"原则直接冲突
跨屏组件词汇不一致	若"保存"按钮在两个地方长得不一样，其中一个是错的
在 UI 标签、按钮、数据中使用展示字体	展示字体留给品牌叙事，不进入操作元件
为了风味重造标准交互暗示	自定义滚动条、奇怪的表单控件、非标准模态框
非活跃状态上使用重色或全饱和强调色	强调色是有预算的，只在需要唤起的时刻使用
把模态框当第一反应	模态通常是懒惰；先穷尽内联/渐进式替代方案

最后一条与 craft-floor 的"拒绝列表"同源：craft-floor 规定"不需要打断与受保护焦点的任务不应使用模态框"（A modal for a task that needs neither interruption nor protected focus）。两条规则叠加意味着：产品界面里，模态框必须被证明是必要的，而不是默认选型。

产品权限清单：产品表面可以负担品牌表面负担不起的自由

约束之外，产品界面也拥有品牌表面往往没有的特权——文档用一整节强调这些"permissions"：

• 系统字体与熟悉的 sans 默认值。 产品界面不需要为字体本身冒险，一支调校好的 sans + 系统字体栈是合理默认。
• 标准导航模式。 顶栏 + 侧导航、面包屑、标签页、命令面板（command palette）——用户已经会用的东西直接使用。
• 密度。 用户需要数据时：多行表格、多标签面板、密集信息都是许可的，不必为了"透气"牺牲信息效率。
• 一致性高于惊喜。 屏幕与屏幕之间使用同一套视觉词汇是一种美德；惊喜（delight）留给关键时刻，而不是每一页。

把"约束"与"权限"并排看，产品设计的策略就很清楚了：在叙事与情感表达上收缩预算，把预算投入密度、一致性与状态完备性。delight 不是被禁止，而是被精确地定点投放。

Read 表面的延伸：正文行宽与导航优先于组件密度

operate.md 对 Read 表面（文档、指南、长篇内容）的态度值得单独强调：Read 复用本文的排版与一致性规则，但它的 prose measure（65–75ch）与导航的可理解性，比组件密度重要得多。也就是说，把本文的组件/密度章节用于 Read 时要降权，把排版章节（行宽、层级比例）用于 Read 时要升权。设计 Read 表面时，先保证读者能顺着导航无歧义地定位内容，再考虑阅读体验是否值得停留。

可执行的护栏：规则标记、设计 hook 与复审闭环

operate.md 的规范并不是停留在纸面上的建议。在源版本 skill/reference/operate.md 中，每条规则都内嵌了机器可读的规则标记（如 rule:product-color-restrained-default、rule:product-typo-one-family、rule:product-components-all-states、rule:product-ban-modal-first-thought、rule:product-motion-state-not-decoration 等），供设计检测器与 hook 消费。SKILL.src.md 的 Hooks 一节说明：impeccable hooks 命令可管理"UI 文件编辑后自动运行设计检测器并回报发现"的钩子（hooks.md 有完整参数），craft-floor 也要求"hook 激活时按其发现行事，而非逐条重复审计"。换言之，这份纵深文档最终会转化为编辑时实时触发的机械检查。

复审闭环的另一端是 impeccable-finish-reviewer.md 这一收尾复审代理：它以截图（.impeccable/review/ 下的 desktop.png/mobile.png 等）、方向契约与 hook 发现为输入做最终质量评审。而在文档侧，COMP-FIDELITY.md 也确认了与本文一致的取向：Operate 表面（dashboard、编辑器）很少有或没有"plate（版式分块）"，spec/diff 检查仍然适用。

小结：把 Operate 当成一种克制而完整的工艺

回到开篇的那句话——当设计服务于产品时，工具应消失于任务。Impeccable 的 Operate 纵深把这一目标拆解为可执行的分层标准：

1. 用"产品 slop 测试"做验收：品类熟练用户能否立即信任界面，而不会在每个微妙偏差前停顿；
2. 排版上收敛：单一字族、固定 rem 阶梯、1.125–1.2 紧凑比例、散文行宽 65–75ch、数据表格可更密；
3. 色彩上克制：Restrained 是地板，富语义状态词汇、强调色仅用于主操作/选中/状态、第二中性层做面板层级；
4. 组件上完整：每个交互组件都有 default→hover→focus→active→disabled→loading→error 的全状态，骨架屏而非居中 spinner，空状态教授界面，浮层用 <dialog>/popover/fixed/portal 逃出裁切容器；
5. 动效上克制：150–250ms、只表达状态、不编排页面加载；
6. 用约束清单守住底线、用权限清单放开该放开的地方：模态框不是第一反应、一致性高于惊喜、密度是特权而非过错。

当一位开发者在编写或评审 dashboard、管理后台、编辑器、设置面板时，这份参考（连同其 SKILL.src.md 模式体系与 craft-floor.md 质量底线）就是一套可以直接逐条对照的验收手册：先挣得熟悉，再谈完美；让每个组件都完整，再谈惊喜。