Impeccable Operate 模式设计指南：让产品界面从"可用"走向"值得信任"

导读

当用户进入界面是为了完成一项任务——填写表单、配置设置、检索数据、操作系统——设计必须让位给任务本身。本文是 Impeccable 设计技能体系中面向 Operate（操作）模式 的深度参考解读，覆盖此类产品界面（应用 UI、管理后台、设置面板、数据表格、工具、鉴权界面）的排版、色彩、布局、组件与动效准则，并补充 Read（阅读）表面适用的排版与一致性规则。读完本文，你将掌握一套可判定的产品界面设计红线与权限清单，知道如何识别"看似正常实则处处别扭"的 AI 产品界面，并能在设计评审中给出有依据的判断。

---

1. 先定位：Operate 模式在 Impeccable 四种模式中的位置

Impeccable 在 SKILL.md 中把表面（surface）按"访客成功的样子"划分为四种模式：

模式	访客的成功形态	典型表面
Persuade	决定并行动，设计本身就是产品	落地页、营销页、活动、定价
Operate	完成任务	应用 UI、看板、编辑器、后台、设置、工具
Read	理解某事	文档、文章、指南、帮助、变更日志
Experience	沉浸于作品本身	作品集、画廊、展示

本参考文件 operate.md 专门服务 Operate 表面，并顺带给出 Read 表面的排版与一致性规则。它的定位非常明确：当设计服务于产品时——应用 UI、管理后台、设置面板、数据表格、工具、鉴权表面，任何"用户处于任务中"的地方。文件正文第一句即点明边界：基础要点在 SKILL.md 的模式定义和 craft-floor.md 中，本文件提供的是面向 Operate 表面的扩展深度。

关键取景：一个工具的落地页仍是 Persuade，一家时装屋的文档页仍是 Read，文档索引页是 Read 而非 Persuade——模式由请求的表面决定，而不是由产品品类决定。

---

2. 产品模板痕迹测试（The Product Slop Test）

在开始逐条设计规则前，先理解 Operate 模式要对抗的核心失效模式。熟悉感在这里通常是特性而非缺陷。检验标准是：一位熟悉该类产品的用户，是否能立刻信任这个界面，而不是在每一个"微妙地不对劲"的组件上停顿。

产品 UI 的失败形态不是扁平、朴素，而是 "没有目的的陌生感"（strangeness without purpose）：

• 过度装饰的按钮；
• 互相不匹配的表单控件；
• 无意义的动效；
• 在标签位置上使用了展示字体；
• 为标准任务发明了不存在的交互暗示（affordance）。

操作的基准线是 "挣来的熟悉感"（earned familiarity）：工具应当消失在任务之中。用户在完成任务的路径上不应该"看到设计"，只应该"用得很顺"。所有后续规则——排版克制、色彩收敛、组件状态完备——都在为这一目标服务。

---

3. 排版：一套字体、固定 rem 阶梯、更紧的比例

3.1 一套字体族常常就是正确答案

产品 UI 通常不需要展示字体 + 正文字体的双字体配对。一款调校良好的无衬线字体可以同时承担标题、按钮、标签、正文和数据。双字体配对的叙事张力属于 Persuade 表面；在产品界面里，多余的字体切换本身就是噪音。这与 Impeccable 自有品牌（Neo Kinpaku，见 DESIGN.md）的"两套字体 + 字重倒置"策略并不矛盾——那是 Persuade 语境下的品牌选择，而 Operate 表面默认走单字体路线。

3.2 固定 rem 阶梯，而非流体排版

不要用 clamp() 做流体标题。 产品用户通常在一致的 DPI 下查看界面，一个在侧边栏里缩小到失态的流体 h1，看起来更糟而不是更好。正确的做法是维护一张固定的 rem 字号阶梯，让所有字号都落在明确的档位上。

3.3 更紧的缩放比例

相邻字阶的比例通常为 1.125–1.2。产品表面的文字元素比品牌表面更多，夸张的对比度制造的是噪音而不是层次。举例说，若正文为 16px，一个 1.2 的比率意味着下一级约为 19–20px，上一级约为 13px——层级靠"邻近且清晰"的阶梯建立，而非"跳级"。

3.4 行宽规则依然适用，但分语境

• 散文类文本（Read 表面、产品内的长文案）：每行 65–75 字符（craft-floor 中同样要求 body measure 65–75ch，见 craft-floor.md）。
• 数据与紧凑 UI：可以更密；表格 120ch+ 完全可接受。

Read 表面备注：文档、指南、长文表面采用 SKILL.md 的 Read 模式，再加上本文件的排版与一致性规则；它们的散文行长与导航比组件密度更重要。这解释了为什么 docs 类页面应该优先被排版节奏和内容架构约束。

---

4. 色彩：默认 Restrained，语义先于装饰

Operate 表面默认采用 Restrained（克制） 色彩策略。在 new-work.md 中，色彩策略被明确定义为四种：Restrained（中性色 + 一个强调色；当访客是为 operate 或 read 而来时的默认选择）、Committed（一个高饱和色承载表面 30–60%）、Full palette（3–4 个命名角色）、Drenched（表面本身就是颜色）。色彩以页面尺度提交——是拥有整片区域的字段，而不是散落在中性地面上的点缀。

单个表面可以通过 earned 理由升级到 Committed：

• 一个"用一种品类色承载整份报表"的看板；
• 一个拥有沉浸式欢迎屏（drenched）的引导流程。

但 Restrained 是底线（the floor），不是可选项。

具体规则：

1. 建立状态丰富的语义色词汇：hover、focus、active、disabled、selected、loading、error、warning、success、info——并把这些状态标准化。状态色是产品 UI 的色彩骨架。
2. 强调色只用于主操作、当前选中项与状态指示，绝不用于装饰。若一个强调色出现在按钮、选中态之外的地方，基本可以判定为违规。
3. 为侧边栏、工具栏、面板准备第二中性层，它应比内容表面略微偏冷或偏暖，用来建立"层级感"而不是引入彩色噪音。

补充：craft-floor 要求正文与占位文字对比度 ≥ 4.5:1、大文本 ≥ 3:1；在彩色表面上，次要文字应从该色相的深色衍生（tint），绝不要用纯灰（quiet 场景同样禁止"灰文字压在彩色上"，见 quieter.md 的 "Never gray on color" 规则）。这与 Operate 的语义色词汇完全一致：禁用状态与次要信息应该是"主色的降级"，而不是凭空插入的灰色。

---

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

产品界面的响应式行为是结构性的，与流体字体无关：

• 侧边栏的折叠（collapse sidebar）；
• 表格在小屏上转为可横向滚动或卡片式堆叠；
• 由断点驱动的栅格列数（breakpoint-driven columns）。

判断一个产品布局是否健康的简单办法：把断点都拆掉，所有"响应式"都发生在容器、列与表格结构上，而标题字号始终保持同一档 rem。这样的小型团队最容易忽略的一点是——clamp() 标题看起来像是在做响应式，实际上它只是把排版的确定性还给了浏览器。

---

6. 组件：状态完备是硬性门槛

6.1 每个交互组件都要有完整状态

每个可交互组件都必须具备：default、hover、focus、active、disabled、loading、error——不要只做其中一半就发布。 这直接呼应 craft-floor 的核对项："States: hover, disabled, loading, error, empty. Plus real content, working controls, responsive composition, keyboard focus."（craft-floor.md）在 Operate 表面，状态缺失是最常见的"半成品感"来源——一个没有 loading 的提交按钮、一个没有 error 语义的表单，都是让用户迟疑的裂缝。

6.2 用骨架屏承载加载，而不是内容中央的 spinner

加载反馈用 skeleton（骨架屏），而不是把 spinner 丢在内容正中间。骨架屏保持了布局稳定，让用户知道"结构还在、数据在来"；内容中央的 spinner 则让整个区域闪变，打断任务流。

6.3 空状态要教学，而不是"nothing here"

空状态（empty state）应该教用户如何使用界面：引导创建第一条数据、说明功能入口在哪。设计目标绝不该是打印一句"这里空空如也"。

6.4 全表面一致的 affordance 词汇

同一表面上必须保持一致的交互暗示：相同的按钮形态、相同的表单控件词汇、相同的图标风格。在不同页面看到两种不同样子的"保存"按钮，其中必有一处是错的（见第 7 节红线）。一致性在此是美德——它可以被量化检查，也是 craft-floor "read the computed values"（读计算值而非意图）哲学在组件层的体现。

6.5 覆盖层必须逃离它的容器

绝对定位的下拉菜单放在 overflow: hidden 或 overflow: auto 的祖先里会被裁剪。 正确的逃生通道依次是：<dialog> 元素、Popover API、position: fixed、或 React Portal 这类传送门。这是本文件中最容易被代码审查放过、却真实损坏产品信任度的实现细节之一——下拉被裁剪看起来像"界面 bug"，实际上源于对层叠上下文的误判。

---

7. 动效：快、克制、只表达状态

产品界面里用户在流动状态（in flow），动效的三条硬规则：

1. 绝大多数过渡控制在 150–250 ms。用户不希望为编排好的动效等待；这个区间刚好让过渡"被感知到但不被等待"。
2. 动效传达状态，而不是装饰。允许动效的场景只有四种：状态变化（state change）、操作反馈（feedback）、加载（loading）、揭示（reveal）——除此之外的动效都是多余的。craft-floor 更精细地要求"one authored moment"（一个经设计的时刻，而非零散特效），并提醒动效调色板可以延伸到 transform/opacity 之外（blur、backdrop-filter、clip-path、mask、shadow），前提是保持平滑（craft-floor.md）。
3. 禁止编排页面加载序列。产品直接"载入任务"，用户不想看它表演加载过程。页面入场动效是 Persuade 表面的特权。

---

8. 产品红线：这六类情况直接判负

Operate 模式明确禁止以下设计（原文档中"constraints"一节，措辞多为强否定）：

#	红线	典型表现
1	不传达状态的装饰性动效	纯为好看而动的按钮、悬浮光晕
2	跨屏幕组件词汇不一致	同一操作两处形态不一（"保存"按钮在不同页面长得不同）
3	在 UI 标签、按钮、数据上用展示字体	display font 被用在功能性文字上
4	为"风味"重造标准 affordance	自定义滚动条、奇怪的表单控件、非标准模态框
5	非激活状态使用重色或全饱和强调色	disabled 按钮仍然浓墨重彩
6	模态框作为第一反应	看到交互需求就上 modal——"模态框通常是懒惰"，应先把内联（inline）/渐进式（progressive）替代方案用尽

第 6 条值得展开：模态框打断了任务流并抢占了焦点保护，只有在确实需要"中断 + 受保护焦点"时才配使用。craft-floor 更直接地把"不需要中断也不需要焦点保护的任务却用了模态框"列入 Refuse 清单。这也是 onboard、clarify、quieter 等命令的审查视角之一——修复方向通常是先问"能否内联、能否分步展开、能否渐进披露"。

---

9. 产品权限：Operate 可以拥有而品牌表面不能的东西

反向看，Operate 表面也有品牌表面（Persuade）承担不起的自由——这些不是妥协，而是任务优先性的结果：

• 系统字体与熟悉的无衬线默认值：产品 UI 不需要自定义字体来证明存在感；用户越熟悉、认知负担越低越好。
• 标准导航模式：顶栏 + 侧边导航、面包屑、页签、命令面板（command palette）——这些都是被验证过的产品导航词汇，直接用，不要发明。
• 密度：需要时，多行多列的表格、多标签的面板、高密度信息都是合理且必要的。产品信息密度上限由"用户是否需要"决定，而非"视觉是否好看"。
• 一致性优先于惊喜：屏幕到屏幕保持同一套视觉词汇是美德；delight（愉悦时刻）要留给特定时刻，而不是每一页都来一下。这与 delight 命令的适用语境一致——惊喜是精确定点的奖励，不是默认背景。

---

10. 如何落地：与 craft-floor、工作流与检测器配合

本文件是 Operate/Read 表面的扩展深度参考，而非独立工作流。在 Impeccable 的实际使用中，它按以下顺序进入工作流（依据 SKILL.md 与 craft-floor.md）：

1. 定位表面 → 选模式：按访客成功形态从四种模式中选择（Operate 对应任务表面）；请求没有明确命令时先读 routing 参考，切勿自动执行命令。
2. 确认方向：确认目标与既有视觉真相后，才进入编辑。
3. 编辑前加载 craft-floor：craft-floor 携带质量底线与绝对禁令——包括对比度 ≥ 4.5:1、阴影必须带偏移和柔和模糊、正文 65–75ch、动效只保留一个设计时刻、状态齐全（hover/disabled/loading/error/empty）等可量化检查（craft-floor.md）。它强调：这些检查是对构建结果的核对，不是意图——应成批检查（batched inspection rounds），共享一次渲染，而不是逐条开截图。
4. 在本文件的规则内发挥：Operate 的许可边界（第 9 节）与红线（第 8 节）决定"在哪里自由、在哪里禁止"，方向取舍仍交给 brief 与场景。

值得注意：本文件内联的 rule:product-* 标记（如 product-typo-fixed-rem-scale、product-color-restrained-default、product-components-all-states、product-motion-quick-transitions）在源仓库 skill/reference/operate.md 中以 HTML 注释形式存在，为该文档的可校验规范提供了稳定的规则标识——这意味着每条设计准则都拥有可被工具化追踪的稳定 ID，方便检测器、测试与审查流程引用。此外，同一份参考文件在仓库中为多种 AI 编码环境各保留一份副本（如 .kiro/skills/impeccable/reference/operate.md、.claude/、.gemini/、plugin/skills/impeccable/ 等同名路径），确保不同 Agent 读取到一致的规范文本。

---

11. 一页速查：把 Operate 准则带进下次评审

• 总判断：用户能否立刻信任界面、顺利完成任务？还是每个组件都让他停顿一下？→ 停顿时长就是产品 slop 的度量。
• 排版：一套无衬线字体；固定 rem 阶梯（无 clamp 标题）；相邻字阶 1.125–1.2；散文 65–75ch，数据表格 120ch+ 没问题。
• 色彩：默认 Restrained（中性 + 单强调色）；语义状态词汇齐全；强调色只服务主操作 / 选中 / 状态；侧栏与面板用第二中性层；正文对比度 ≥ 4.5:1。
• 布局：响应式 = 结构折叠（侧栏、表格、断点列），而不是流体字号。
• 组件：每个交互组件 7 态齐全；加载用骨架屏；空状态教用法；affordance 词汇全局一致；下拉等覆盖层用 <dialog> / Popover / fixed / portal 逃出裁剪祖先。
• 动效：150–250ms；只表达状态（变化 / 反馈 / 加载 / 揭示）；禁止编排式页面加载序列。
• 红线：装饰动效、跨屏不一致、展示字体进功能文字、重造标准控件、非激活态重色、以及"模态框优先"。
• 权限：系统字体、标准导航模式、合理的密度、跨屏一致优先于逐页惊喜。