Impeccable `delight` 指南：为界面注入产品个性、打造值得记忆的时刻

本指南以 impeccable 技能体系中的 delight 参考文档（delight 命令的核心操作手册）为主体，结合仓库中 SKILL.src.md、animate.md、polish.md 与 DESIGN.md 等源码与配置证据展开。读完你将掌握：如何判断一个界面"值得"哪些愉悦时刻、如何写出单句 delight thesis、如何为成功/等待/空状态/错误恢复等情绪节点设计方案，以及如何用一条"保护清单"防止个性变成干扰。这套方法适用于你使用 impeccable 处理前端界面时的一切"让它更有趣、更有个性、更令人难忘"的诉求。

---

Impeccable 的核心定位是 "The design language that makes your AI harness better at design"，其技能体系把界面工作划分为 Build / Evaluate / Refine / Enhance / Fix / Iterate 六类命令，其中 delight 归属于 Enhance（增强） 类别。在技能命令总表中，它的定位是一句话："Add personality and memorable touches"（添加个性与令人难忘的细节）。delight.md 这份参考文档则回答了更深一层的问题：什么时候应该加个性、加在哪个时刻、用什么原则来保证它不伤害可用性。

在开始成文前，需要先交代本文所依据的文档结构。delight.md 以一条元信息开头：

Additional context needed: the brand's emotional range.

这是 impeccable 参考文档体系的固定开场（animate.md、adapt.md、clarify.md 等都有同类条目，只是各自索取的上下文不同）。它意味着：在执行 delight 任务前，操作者必须额外获取"品牌的情绪区间"（the brand's emotional range）这一上下文——即这个产品能允许、且应该呈现出多大范围的情感表达。这是整个 delight 工作的前提：脱离品牌情绪区间去发挥个性，等于脱离产品世界去堆砌装饰。

在 command-metadata.json 中，该命令被进一步展开为供 Agent 判断调用意图的说明：

• Add moments of joy, personality, and unexpected touches that make interfaces memorable and enjoyable to use.
• Elevates functional to delightful.
• Use when the user asks to add polish, personality, animations, micro-interactions, delight, or make an interface feel fun or memorable.

也就是说，当用户提出"让界面更有趣/更有个性/更令人难忘/加一点微交互与愉悦感"时，Agent 应路由到 delight.md 并按本文档的方法执行。

总纲：Delight 不是一层面具

delight.md 开篇给出了一条必须贯穿全程的定义，它同时是"能做什么"和"不能做什么"的边界：

Delight is not a layer of generic whimsy; it is product character revealed through a useful interaction, a humane response, or an unexpectedly considered detail.

Delight 不是一层"通用的俏皮装饰"；它是通过一次有用的交互、一个有人情味的回应、或一个出人意料却经过考量的细节，所显露出来的产品性格。

这句话隐含了三个判断标准：

1. 必须"挣来的"（moments that earn it）：只有值得记住的时刻才值得被设计成 memorable；
2. 必须"产品化的"：个性来源于产品机制与视觉世界，而非一套可以套在任何产品上的库存套路；
3. 必须"有用的"：一个愉悦时刻至少要承担一次交互、一种回应或一个细节的功能。

这条定义与仓库中 SKILL.src.md 反复强调的原则一致："Go all out. No hedging" 与 "the brief wins" 并不矛盾——delight 要求大胆，但大胆必须锚定在品牌与产品的既定世界上，而不是脱离 brief 去炫技。

第一步：按访问者模式决定个性浓度

delight 首先不是无差别加戏，而是先要回答"这个表面属于哪种访问者模式"。文档给出两种典型的个性浓度分派：

• Persuade + Experience（说服 + 体验型表面）：个性可以贯穿 voice（文案语调）、composition（构图）、motion（动效）与 discovery（发现感），前提是作品本身始终是焦点——说服型页面的主角是产品/服务，体验型页面的主角是内容本身，界面必须退后。
• Operate + Read（操作 + 阅读型表面）：把 delight 集中在有意义的时刻，例如首次使用、任务完成、错误恢复、掌握熟练之时；其余一切由可靠性（reliability）兜底。工具界面、仪表盘、编辑器、文档站里，扫描性、一致性、原生预期与真实使用场景的优先级高于表达。

关于"访问者模式"的更完整定义可参见 SKILL.src.md 的 Modes 一节——它把表面划分为 Persuade（访问者做决定并行动，设计即产品）、Operate（访问者完成任务）、Read（访问者理解内容）、Experience（访问者置身作品内部）四类，并强调模式由请求的表面而非整个产品决定：一个工具类产品的落地页仍是 Persuade，一个时尚品牌的文档仍是 Read。

第二步：寻找真正值得愉悦的机会点

在没有机会的地方强造惊喜是 delight 最常见的失败方式。文档要求先检查：目标本身、DESIGN.md（既定视觉世界）、产品 voice、重复使用频率、情绪上下文，然后专门寻找以下六类机会：

• 值得被认可的努力（effort worth acknowledging）：用户付出了真实成本，例如一次复杂配置的完成；
• 可以变成"有信息量"的等待（waiting that can become informative）：加载是客观存在的，关键是如何让等待不说废话；
• 可以承担"指引方向"功能的空状态或首次使用态（an empty or first-use state that can orient）：新用户第一眼需要被引导；
• 需要共情的错误或恢复时刻（an error or recovery moment that needs empathy）：出问题时用户正处于低情绪点；
• 其物理或语言反馈能表达品牌的交互（an interaction whose physical or verbal response could express the brand）：如开关、滑块、按钮反馈这类"产品可以说一句话"的地方；
• 值得被用户发现的实用能力（a useful capability people might enjoy discovering）：把真实功能藏在可被好奇发现的入口里。

配套红线：不要为一次普通点击制造庆祝（Do not manufacture a celebration for an ordinary click）。只有当品牌的情绪区间或利害关系（stakes）无法从上下文推断时，才需要向用户提问。

第三步：定义单条 delight thesis（愉悦命题）

与其散点式加彩蛋，文档要求收敛为一句话的愉悦命题：

State in one sentence what the user should feel and why that feeling belongs to this product.

即：一句话说清"用户应该感到什么 + 这种感觉为什么属于这个产品"。命题成立后，再选择能承载它的最小系统（the smallest system）。文档给出五条可选的最小载体：

• 对某个有意义动作给出一个有辨识度的响应；
• 使用产品专属语言——既澄清信息、又承载 voice 的文案；
• 一个具有可识别材质行为的交互或转场（material behavior）；
• 一个扎根于产品世界的插画、声音、触觉或环境细节；
• 一个揭示真实实用价值的发现奖励（discovery reward that reveals real utility）。

硬性约束：treatment 必须源自产品机制与视觉世界，而不是来自"素材库存目录"（a stock catalog）。若脱离产品世界，再精巧的动效也只是外贴的皮。

第四步：为六类情绪时刻分别建造

文档把"建造情绪时刻"拆成六个具体场景，每个场景都有明确的设计策略：

• 成功（Success）：让反馈的规模与付出、后果成正比。重大里程碑（milestone）可以展开庆祝；常规保存只需让人感到"确定"（simply feel certain）——不必每次都放烟花。
• 等待（Waiting）：展示真实的进度、有用的上下文、或产品专属的活动。绝对禁止伪造工作（fake work）或故意拖慢完成来导演一场表演。
• 空状态与首次使用（Empty and first use）：先让下一步动作清晰可见，再谈个性。个性永远排在可操作性之后。
• 错误与恢复（Error and recovery）：先呈现问题与恢复路径。温暖可以降低压力，但玩笑绝不能轻描淡写地对待损失、金钱、隐私或被阻断的工作。
• 重复交互（Repeated interaction）：让反馈在第一百次使用时依然令人满意。变化只有在其仍然连贯、可预期、值得信任时才有价值——为变而变反而破坏信任。
• 发现（Discovery）：奖励好奇心，但不能把必需功能藏在发现里（reward curiosity without hiding required functionality）。

贯穿始终的文案铁律：Copy must use the product's language. Generic whimsy is worse than neutral clarity.（文案必须使用产品自己的语言。通用的油腔滑调不如中性的清晰。）这与仓库中 clarify.md（改进 UX 文案）的原则彼此呼应——delight 文案若失去清晰度，就沦为噪音。

第五步：保护体验——Delight 的红线清单

愉悦必须永远为任务让路。文档给出"Delight must not（愉悦不得）"清单，共六条禁令：

• 不得拖延、阻塞或遮蔽主任务（delay, block, or obscure the primary task）；
• 不得覆盖平台惯例或可访问性（override platform conventions or accessibility）；
• 不得添加未经要求的陈述性主张（add unrequested factual claims）——例如给产品编造不存在的能力；
• 不得未经同意播放声音或无视静音设置（play sound without consent or ignore mute settings）；
• 不得在重复使用时变得强制、不可跳过、令人疲惫（become mandatory, unskippable, or exhausting on repeat）；
• 不得为某一瞬间添加不成比例的依赖或资产成本（add a dependency or asset cost disproportionate to the moment）。

同时，文档要求：

• 凡是涉及亲手创作动效（authored motion）的部分，必须加载 animate.md——那是动效专题的操作手册，定义了 100–800ms 的时长分级、cubic-bezier(0.16, 1, 0.3, 1) 等缓动建议、CSS transitions / Web Animations API / View Transitions 的实现取舍，以及 prefers-reduced-motion 的降级路径；
• 尊重屏幕阅读器、键盘、触控、本地化与文化语境；
• 非必要的循环动画在隐藏时必须停止；
• 庆祝的强度要与使用频率和后果成正比（make celebration intensity proportional to frequency and consequence）——低频、高后果的时刻可以有更盛的庆祝，高频低后果的时刻必须克制。

这条"强度与频率成正比"的定律，正好回扣了仓库中 DESIGN.md 里 "Neo Kinpaku"（新金箔）视觉世界的实践——金箔高光与铜绿质感只出现在承载品牌重量的时刻（hero 接缝、CTA 填充、分隔线），而普通卡片保持扁平克制，就是"庆祝强度与时刻分量匹配"的落地样本。

第六步：验证清单与收尾移交

delight.md 以一份六项验证清单收尾，每一条都可作为 Agent 自检的判据：

1. 唯一性：这个时刻是否足够具体，以至于相邻产品无法原样挪用？（The moment is specific enough that a neighboring product could not use it unchanged.）
2. 有效性：它是否改善了用户的理解、信心、动机或情绪恢复？
3. 独立性：去掉华丽之后，界面是否依然快速、显而易见？（The interface remains fast and obvious without the flourish.）
4. 耐久性：重复使用是否没有把魅力变成摩擦？（Repetition does not turn charm into friction.）
5. 可达性：静音（muted）、键盘、触控、本地化路径是否都正常工作？
6. 世界一致性：最终效果是否像"被选定的那个世界"，而不是一套通用的 "delight" 处理？

文档最后给出了移交建议：当这份个性真正"挣得了自己的位置"时，交给 /impeccable polish 做最终润色。这与 polish.md 的定位（ship 前的最终质量关卡，负责检查动效一致性、键盘焦点、控制状态、DESIGN.md 吻合度等）构成流水线闭环：delight 负责"加对"，polish 负责"加得干净、收得完整"。

仓库中的落地形态：一份多副本、被路由的增强命令

最后说明该文档在仓库中的实际组织方式，这有助于 Agent 与读者理解它的"生态位"：

• delight.md 以多副本形式存在于各类 Agent 运行时目录（.rovodev/、.claude/、.cursor/、.gemini/、.agent/ 等，以及 plugin/skills/impeccable/reference/delight.md、skill/reference/delight.md），供不同工具链按需加载，主体与 SKILL.src.md 中"Commands"总表的 Enhance 类别一致；
• 它与 animate.md（动效专项）、polish.md（最终润色）、routing.md（无参数时的上下文路由，决定何时推荐某条命令）是协同引用关系，任何 delight 任务都可能顺带触发其中一条；
• command-metadata.json 是该文档的"机器可读入口"，Agent 据此把"make it fun / memorable / add personality"类请求路由到 delight 命令，再载入本文档执行。

换言之，delight.md 不是一份孤立的设计随笔，而是 impeccable 命令路由链中"Enhance → delight"环节的操作准则：上承 SKILL 的命令总表与 routing 判断，旁通 animate 的动效实现，下接 polish 的最终质检。理解这一点，你就能在正确的时机、正确的节点，用这条文档的方法论为界面注入恰到好处的产品个性。