impeccable 技能 Operate 模式深度指南：让 AI 为应用 UI、后台与数据密集界面做出真正可用的设计

本文是开源项目 impeccable（"让 AI 具备更好的设计能力"的设计语言）中 Operate 模式深度参考 的完整导读与扩展解读。当用户要求 AI 设计 应用型产品界面——App UI、管理后台、设置面板、数据表格、工具类界面、任何需要登录、用户正处于"完成任务"状态的面——impeccable 会进入 Operate 模式；阅读型界面（文档、指南、长文）则由 Read 模式接管。读完本文，你将掌握 impeccable 针对这两类界面给出的排版、色彩、布局、组件、动效决策准则与红线清单，并理解这些规则如何被项目源码与测试固化为可自动执行的检查。

一、背景：Design Mode 系统里的 Operate 与 Read

在开始谈细节前，先明确 Operate 在 impeccable 中的位置。impeccable 的核心入口 SKILL.md 用"模式（Mode）"来命名"访问者在当前界面上的成功形态"：

模式	访问者的成功形态	典型表面
Persuade	访问者做决定并采取行动，设计即产品	落地页、营销活动、定价页
Operate	访问者完成任务	App UI、仪表盘、编辑器、管理后台、设置页、工具
Read	访问者理解某事	文档、文章、指南、帮助中心、变更日志
Experience	访问者置身于作品本身	作品集、画廊、展示页

模式的选取取决于"被请求的表面（surface）"，而非"产品类别本身"。例如某个工具的落地页仍然是 Persuade，某时装屋的文档仍然是 Read。每个模式只在对应表面的 brief 中持久化，见 SKILL.md 模式章节。

operate.md 正是这份分级体系里的 Operate 深度层：它开宗明义地指出，本文件专为 Operate 表面而写，是 SKILL.md 模式与 craft-floor.md（质量底线）之外的"扩展深度"。同时，Read 表面（文档、指南、长文）在 SKILL.md 的 Read 模式基础上，也要复用本文件的排版与一致性规则——区别在于"散文的栏宽与导航"比"组件密度"更重要。需要新建表面或替换视觉世界时，先走 new-work.md 流程。

二、产品界面翻车的根源：The Product Slop Test

operate.md 给产品界面立了一条核心判据，不妨称为 "产品馊饭测试"（product slop test）：

熟悉感（familiarity）在这里常常就是特性。测试的标准是：一个对所在品类很熟练的用户，能否立即信任这个界面，还是会因为每个细节微微不对而被迫停下来。

这条标准最值得玩味的推论是：产品 UI 的失败模式不是"太平"，而是"没有目的的怪异"——过度装饰的按钮、彼此不匹配的表单控件、无缘无故的动效、本该是标签的位置却用了展示字体、为标准任务凭空发明的"假意符"（invented affordances）。这类界面的基准线应当是"挣得的熟悉感"（earned familiarity）：工具应当消失在任务里，用户只记得自己办成了什么事，而不记得界面长什么样。

对照整个 impeccable 体系，这条判断与 craft-floor.md 的哲学一致：质量底线（floor）只管机制、从不替你决定方向；而"无目的的怪异"恰恰是机制之外的自我表演。若一个产品界面上同时出现多种按钮形状、多种表单控件语言，用户产生的信任损耗正是 slop 的直接来源。

三、排版（Typography）：产品 UI 的字体纪律

产品界面的排版目标与品牌落地页完全不同：用户要在稳定、可扫读、可预测的环境里完成重复性任务。operate.md 给出四条铁律：

• 一个字体家族往往就是正确答案。 产品 UI 通常不需要"展示体 + 正文本"的双家族搭配。一套调校良好的无衬线字体应当同时承担标题、按钮、标签、正文与数据——这是与 Persuade 表面（允许展示字体承载语气）最本质的区别。
• 固定 rem 字号阶梯，而不是流式字号。 clamp() 控制的流式标题不服务产品 UI。用户通常在一致 DPI 下查看产品，一个在侧栏里缩小、看起来更糟的流式 h1 是负资产。产品 UI 要求的是跨屏幕可重复的角色阶梯。
• 更紧凑的阶梯比率。 相邻字号步进之间典型比值为 1.125–1.2。产品界面的排版元素比品牌表面更多；夸张的对比只会制造噪声。
• 散文仍受栏宽约束（65–75ch）。数据与紧凑 UI 可以更密：表格到 120ch+ 也没问题。

这与 typeset.md 中 Operate + Read 的访客模式互相印证："稳定、可扫读与度量优先；一个调校良好的家族与固定角色阶梯常常是对的"，同时正文底线保持 1rem / 16px、散文控制在 45–75ch，行高随栏宽反向调整（栏越宽通常行距越大）。craft-floor.md 则把排版验收写成可执行的清单：正文章宽 65–75ch、展示字号上限 6rem、字距下限 -0.04em、标题视觉平衡、字号与字重阶梯清晰可辨。

四、色彩（Color）：Restrained 是底线，Committed 要"挣得"

产品界面的色彩基调在 operate.md 中被一句话钉死：

产品默认 Restrained（克制）。 单个表面可以"挣得"Committed（投入）——例如某个仪表盘里一种分类色贯穿整份报表、某个引导流程里一屏被浸染的欢迎页——但 Restrained 是底线。

这两档属于 impeccable 统一的色彩策略词汇。在 new-work.md 里定义得更完整：Restrained（中性色加一个强调色，访问者来"操作或阅读"时的默认档）、Committed（一种饱和色承担 30–60% 的表面）、Full palette（3–4 个具名角色）、Drenched（表面即颜色）。色彩按"页面尺度"提交：是拥有整片区域的字段，而不是散布在中性地面上的零碎强调。文档还特别要求：深浅色永远不是默认值，必须写一句物理场景（谁用、在哪、什么光线下）让答案自然涌现。这一色板策略在 live.md 的变体主轴 #4 中被复用为可对比的变体维度。

在 Restrained 的基础上，operate.md 对产品色彩补充了三条操作性规则：

1. 建立"状态丰富"的语义词汇：hover、focus、active、disabled、selected、loading、error、warning、success、info——把这些状态标准化。它们是产品界面的状态字母表，不允许临时发明。
2. 强调色只用于三件事：主要操作、当前选中项、状态指示。不做装饰。
3. 第二中性层给侧栏、工具栏与面板：比内容表面略微偏冷或偏暖即可，用来区分"工作区"与"支撑区"。

这种"中性面 + 语义状态 + 强调克制"的结构，可以对照仓库根目录 DESIGN.md 中 kinpaku 体系的 token 化写法：从 lacquer-black、raised-lacquer、graphite（面板与输入框）、到文本灰阶 text-muted、text-faint、text-mute-deep，再到底层 neutral-100…neutral-22 的中性色阶梯。整个配色被表达为一组具名 token 而非散落的十六进制值，正是"状态词汇标准化 + 中性层可预测"落到工程上的形态。

五、布局（Layout）：响应式是结构问题

产品界面的响应式与营销页的响应式有完全不同的含义。operate.md 的要点极短却极狠：

响应式行为是结构性的（折叠侧栏、响应式表格、断点驱动的列数），而不是流式排版。

也就是说：宽度变化应当改变的是信息结构（侧栏收起、表格列重排、栅格列数切换），而不是让标题字号跟着视口"呼吸"。这与排版节"固定 rem 阶梯"呼应——产品 UI 的两大感知维度（字号与结构）中，只有结构被允许随视口变化。

这条原则的实际验证负担集中在 audit.md 的响应式维度里：检查固定宽度、触控目标 < 44×44px、窄视口横向溢出、字号放大后布局是否崩坏、缺少移动端/平板断点等，每条都对应真实实现缺陷而非审美偏好。

六、组件（Components）：状态完整性是交付底线

operate.md 对交互组件的要求堪称苛刻：

每个交互组件都必须具备：default、hover、focus、active、disabled、loading、error。不要带着其中一半就交付。

四条补充细则：

• 加载用骨架屏（skeleton），而不是内容区中央的 spinner。 spinner 告诉用户"在等"，骨架屏告诉用户"即将看到什么"——后者更符合产品 UI"消失进任务"的气质。
• 空状态要"教人用界面"，而不是一句干巴巴的 "nothing here"。首用与空状态有专门的纵深命令，见 onboard.md（设计首启流程、空状态与激活路径）。
• 整个表面的"假意符"必须一致：按钮同一形状、表单控件同一套词汇、图标同一风格。一处不一致就等于一处错误。
• 浮层必须逃逸容器。 绝对定位的下拉若放在带 overflow: hidden 或 overflow: auto 的祖先里会被裁切；应改用 <dialog>、popover API、position: fixed 或 portal。

最后一条在仓库测试中能找到对应的反模式样本：clipped-overflow-container.html。这组 fixtures 存在的目的，就是让检测器有确定的"应报错样本"可用。craft-floor.md 同时把状态项（hover、disabled、loading、error、empty + 真实内容、可用控件、响应式构图、键盘焦点）列为批次验收的一部分——这些组件状态检查是产品 UI 与"一次性营销页"在质量维度上最大的分野。

七、动效（Motion）：150–250ms，只表状态不搞演出

产品界面的动效基调由三个数字与三条禁令构成：

• 多数过渡控制在 150–250ms。 用户正处于心流中，不要让他们等一场编排好的 choreography。
• 动效传达状态，而非装饰。 允许的用途只有四种：状态变化、反馈、加载、揭示。除此之外没有别的。
• 没有编排化的页面加载序列。 产品要直接"载入进任务"，用户不想看着它加载。

这套节制的动效观在 craft-floor.md 的机制清单里被进一步硬化：一次作者化的瞬间（one authored moment），而非分散的效果、也不是每个区块千篇一律的同一入场；从已可见的默认态出发用指数缓出；色阶手段可以越过 transform/opacity 走向 blur、backdrop-filter、clip-path、mask 与阴影，前提是保持流畅。而 audit.md 从无障碍侧补上了另一半：动效敏感（prefers-reduced-motion）需要一套有意的替代方案，它仍要保留状态变化与层级；同时警示全局 0.01ms 式的一刀切关闭（会毁掉有用的反馈）、越过闪烁阈值的动效、以及阻塞焦点/阅读/任务完成的动画。

八、产品界面的禁令清单（Product Constraints）

operate.md 用"反例清单"直接标注了产品 UI 上常见的扣分项，逐条列出：

1. 不传达状态的装饰性动效（见第七节，动效只允许表状态）。
2. 跨屏不一致的组件词汇。"save 按钮在两个地方长得不一样，其中一个就是错的"。
3. 在 UI 标签、按钮、数据里用展示字体。展示字体留给品牌时刻，不该出现在操作密集区。
4. 为"风味"重造标准假意符：自定义滚动条、猎奇的表单控件、非标准 modal。
5. 非激活状态使用重色或全饱和强调色——会与"可交互/选中"信号打架。
6. Modal 作为第一反应。 Modals 通常是懒惰的表现。先穷尽内联与渐进式替代方案（展开面板、行内编辑、渐进披露、独立页）再考虑 modal。

第 6 条与 craft-floor.md 的 Refuse 清单里"为一个既不需要打断、也不需要受保护焦点的任务开一个 modal"形成双重封堵；craft-floor 还进一步禁止了产品 UI 的另一批俗套：作为页面结构的"等尺寸图标+标题+正文卡片"（嵌套卡片永远错）、hero-metric 大数字模板、标题上方的 kicker/eyebrow（这是"ban"级禁令：标题自带分量，删掉标签让标题说话）、以及只在序列本身携带信息时才允许的章节编号 01/02/03。

九、产品界面的自由度（Product Permissions）

"限制清单"的对面，operate.md 强调产品界面能负担品牌表面负担不起的东西——这些不是放纵，而是对"可识别性与任务效率"的合理让渡：

• 系统字体与熟悉的无衬线默认值。 不需要为产品 UI 自托管一套展示字体；系统字体栈在工具界面是性能与熟悉感的双重收益。
• 标准导航模式：顶栏 + 侧边导航、面包屑、标签页、命令面板。用户已经会用了，别重新发明。
• 密度（Density）：多行表格、多标签面板、用户需要时的密集信息。产品界面有权做密。
• 一致性胜过惊喜：同一套视觉词汇跨屏一致是美德；delight（愉悦）只留给"时刻"，不给"页面"。

十、把原则变成可执行工具：这套深度如何在仓库中落地

operate.md 是准则文本，而 impeccable 的价值在于这些准则并非停留在文档层——仓库里有完整的执行链：

• 模式与命令路由：SKILL.md 的 Commands 表把请求路由到具体参考文件，如 critique（启发式 UX 评审）、audit（技术质量检查）、polish（发布前终审）、onboard（首启与空状态）、harden（错误态、i18n、边界情况）等，均与 operate.md 的组件状态、空状态教学、语义词汇要求一一对应。
• 质量底线文件：开工改 UI 前按流程加载 craft-floor.md，其中的 Verify / Refuse 清单把本文多数规则固化为"渲染后必查项"。
• 检测器与钩子：当设计检测钩子开启后，会在每次编辑 UI 文件后自动运行并把发现抛给 AI，见 hooks.md 参考与 reference/craft-floor.md 中"钩子已激活时执行它替你强制的机械检查"的说明。audit / typeset 中运行的 node .rovodev/skills/impeccable/scripts/detect.mjs --json --scope type [target] 即这类机械扫描的真实命令形态。
• 反模式样本库：tests/fixtures/antipatterns/ 存放大量"应被拦截"的 HTML/CSS/JSX/Svelte/Vue 样本（含上述 clipped-overflow-container.html），与 typeset 反例、design-system 反例 等共同构成规则的确定性测试地基。

十一、快速落点：什么时候该翻出这份深度

由于 Operate/Read 深度会在模式确定后按需加载，这里给出一条可复用的判据：访问者进入界面是为了"办一件事"，就进 Operate（先读本文档 + craft-floor.md，重点是扫描性、一致性、原生预期与真实使用场景，品牌活在精确细节里）；访问者是来"理解某事"的，就进 Read（复用本文排版与一致性规则，但把散文栏宽与导航放第一位，组件密度退后）。若面对的是工具的落地页或某品牌的文档，模式不随产品类别走——落地页仍是 Persuade，文档站仍是 Read。

最后提醒：同一份 operate.md 深度文件以镜像方式存在于仓库多套 Agent 技能目录中（如 .claude/skills/impeccable/reference/operate.md、.cursor/skills/impeccable/reference/operate.md、.github/skills/impeccable/reference/operate.md、.gemini/skills/impeccable/reference/operate.md、.grok/skills/impeccable/reference/operate.md 等），并同步在 skill/reference/operate.md 与 plugin/skills/impeccable/reference/operate.md 中维护；本文引用的正文以其在 .rovodev 目录下的版本为准。无论从哪套目录加载，规则的语义完全一致——这正是 impeccable 作为"让 AI 的做工配得上"的技能所强调的：规则要能跨会话、跨工具、跨项目被稳定执行。