impeccable 的 delight 命令全解：识别值得注入的瞬间，为 AI 界面建立克制而难忘的产品个性

impeccable 的 delight 命令全解：识别值得注入的瞬间，为 AI 界面建立克制而难忘的产品个性

【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable

delight是 impeccable skill 中负责"为界面增加个性与难忘细节"的 Enhance 类命令。它反对把趣味当成一层通用的可爱外壳，主张让"产品角色（product character）"在真正配得上的时刻里被用户感受到。本指南以delight.md参考文档 为骨架，结合仓库中SKILL.src.md、animate.md、polish.md等配套参考，完整讲解 delight 的工作流程：如何发现情绪机会、定义一句"愉悦论点"、为成功/等待/空态/错误/重复/发现六类情感时刻做设计，以及如何守住不动摇任务、无障碍与平台惯例的底线。读完你可以在自己的前端项目里直接运行这套方法论，让 AI 助手产出的界面既有品牌情绪又不牺牲可靠性与效率。

delight 在 impeccable 体系中的定位

impeccable 是一套面向 AI 前端设计助手的技能体系，覆盖"设计、重塑、精修、动效、色彩、文案、无障碍、反模式、设计系统"等能力，其命令按功能分族（Build / Evaluate / Refine / Enhance / Fix / Iterate）。在 skill 主文档的命令表中，delight [target]被归入Enhance类别，描述为"Add personality and memorable touches"（添加个性与难忘细节）。

这意味着 delight 处于一条明确的调色带上：

• 需要更大胆的表达时，系统建议走bolder（放大保守/平淡的设计）；
• 需要降噪时走quieter（克制过激、过度刺激的设计）；
• 需要补足"人与产品的情感连接"时，才轮到delight；
• 完成个性注入之后，收尾交给polish（发布前的最终质量关）。

仓库把同一份技能参考以镜像形式分发到各 AI 运行时目录（如.opencode/skills/impeccable/reference/delight.md、.claude/skills/...、.cursor/skills/...、.gemini/skills/...等），并打包进plugin/skills/impeccable/reference/delight.md，供 Claude Code、OpenCode、Cursor、Gemini CLI、Trae 等不同 harness 加载；其中skill/reference/delight.md是带{{command_prefix}}占位符的模板原稿。因此你在任意受支持的运行环境里输入impeccable delight或等效前缀命令，都会命中同一份方法论。

参考文档的开头标注了一行元信息：Additional context needed: the brand's emotional range（额外上下文需求：品牌的情感范围）。它提醒执行 agent：在无法从项目材料推断品牌情绪尺度时必须向用户提问，而不是闭眼乱加情绪——这一点在正文里被反复强调为"仅在品牌情感范围或利害关系无法推断时才提问"。

一条总原则：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. （愉悦不是一层通用的俏皮装饰；它是通过一次有用的交互、一次有人情味的回应，或一个出乎意料的用心细节所显现出来的产品角色。）

据此可以确立三个判断标准：

1. 愉悦必须挣得（earned）出现的机会——只在值得的时刻出现；
2. 愉悦必须来自产品自身——源自产品机制与视觉世界，而非素材库里的现成套路；
3. 愉悦必须保持任务可用——界面的核心职责永远不能被情绪表演掩盖。

文档还给出一个非常尖锐的取舍："Generic whimsy is worse than neutral clarity."（通用的俏皮话比中性的清晰更糟。）文案必须使用产品自己的语言；当没有把握时，保持中性清晰的表达反而更安全。

先看访问者模式：把个性放到对的地方

impeccable 的每个表面（surface）都有对应的 visitor mode。主文档 SKILL.src.md 定义了四种模式，其判定依据是"这个表面上访客的成功形态"，而不是产品类型本身（工具类产品的落地页仍是 Persuade，时尚品牌的文档站仍是 Read）：

delight.md据此给出两种截然不同的投放策略：

• Persuade + Experience：个性可以贯穿语音（voice）、版式（composition）、动效（motion）与发现（discovery），前提是作品/产品本身仍是焦点。
• Operate + Read：把愉悦集中在真正有意义的时刻——首次使用、完成、恢复、精通（first use, completion, recovery, mastery）；其余一切都由可靠性来承载。

换言之，Operate/Read 场景里"彩蛋密度"应远低于营销页，任何对操作流程的打扰都要被视为缺陷。这套分流逻辑与 animate.md 的 visitor mode 保持一致（Persuade/Experience 中动效可以承载声音，Operate/Read 中动效只服务反馈、状态与连续性），说明整个技能体系共享同一套"情绪预算"哲学。

寻找机会：六个值得投入情绪的缝隙

开始动手前，先检查目标的实际情况。delight 要求检查的对象包括：目标本身（target）、DESIGN.md、产品语音、重复使用频率、情绪语境。在仓库根目录的DESIGN.md就是一个完整的"Neo Kinpaku"视觉系统导出（金箔金 + 铜绿蚀 + 黑漆表面、Alumni Sans/Albert Sans 双字重体系、oklch 颜色令牌等），它正是 agent 判断"这个世界里什么样的愉悦才成立"的素材。与之配套的PRODUCT.md（由init写入、context.mjs加载）则提供产品定位与语音上下文。

在完成这些勘察后，去寻找下列机会点：

• 值得被认可的努力（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）；
• 只有品牌情绪范围或利害关系无法推断时才提问——默认依据DESIGN.md、产品语音与项目证据自己判断。

定义一个愉悦论点（Delight Thesis）

找到一个机会点之后，先写一句话：用户在这个时刻应该感受到什么，以及为什么这种感受属于这个产品。

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

然后选择能承载它的最小系统。文档给出了五个候选载体：

1. 对某个有意义动作的独特回应（a distinctive response to a meaningful action）；
2. 产品专属的语言，在表达语音的同时澄清信息（product-specific language that clarifies while carrying voice）；
3. 具有可辨识材质行为的交互或转场（an interaction or transition with a recognizable material behavior）——例如"像纸一样翻动""像砝码一样落下"；
4. 扎根于产品世界的插画、声音、触觉或环境细节（an illustration, sound, haptic, or environmental detail grounded in the product world）；
5. 揭示真实用途的发现奖励（a discovery reward that reveals real utility）。

关键约束是：处理手法要从产品机制与视觉世界里推导出来，而不是从一个"库存目录"里挑选（Derive the treatment from product mechanism and visual world, not a stock catalog.）。这与 animate.md 的说法同构——那里同样要求"焦点动效必须来自本产品与本表面概念，通用 fade-and-rise、hover lift、视差层、滚动 reveal 不构成论点"。如果这次愉悦可以用在隔壁竞品上原封不动，那说明论点还不够具体。

为情感时刻而构建：六个时刻的取舍细则

delight.md用大量经验法则规定了每一类情感时刻该怎么处理：

Success（成功）

让响应的规模匹配努力与后果：重大里程碑可以展开（major milestones can expand），例行的保存只需"确定"（routine saves should simply feel certain）。把每一次点按都做成烟花，只会稀释真正里程碑的仪式感。这与 polish 中"完成、禁用、成功等状态要齐全"的 triage 顺序互补——状态先做全，情绪才谈得上恰到好处。

Waiting（等待）

展示真实的进度、有用的上下文，或产品专属的活动（truthful progress, useful context, or product-specific activity）。绝不能伪造工作或人为拖慢完成时间来表演一个华丽效果（Never fake work or delay completion to stage a flourish）。这是诚信底线：等待动画永远不得谎报任务状态。

Empty and first use（空态与首次使用）

在加入个性之前，先让下一步动作清晰（make the next action clear before adding personality）。空态的第一职责是引导，趣味只能排在第二位。仓库中onboard.md专门负责"首次运行流程、空态、激活"的设计，delight 在此只做叠加而非替代。

Error and recovery（错误与恢复）

先用问题与恢复路径开场（lead with the problem and recovery）。温暖可以缓解压力，但玩笑绝不能轻描淡写地对待损失、金钱、隐私或受阻的工作（jokes must not trivialize loss, money, privacy, or blocked work）。也就是说：文案先给确定性，情绪只做减震器。

Repeated interaction（重复交互）

让响应在第 100 次使用时依然令人满意（keep the response satisfying after the hundredth use）。变化只有在保持连贯、可预测到足以被信任时才是有用的（Variation is useful only when it remains coherent and predictable enough to trust）。这与动效中的"中断与重复使用行为必须正确"呼应——需要重复观看的动效必须可跳过、可中断。

Discovery（发现）

奖励好奇心，但不得隐藏必需功能（reward curiosity without hiding required functionality）。彩蛋只能建立在功能完备之上，绝不能成为功能的唯一入口。

保护体验：delight 的九条禁区

delight.md明确列出愉悦不得触犯的边界。任何一条被违反，这个时刻就不该被实现：

• 不得延迟、阻塞或掩盖主要任务；
• 不得覆盖平台惯例或无障碍规则（platform conventions or accessibility）；
• 不得添加未经请求的事实性声明（unrequested factual claims）——涉及事实/数据的文案必须先经确认；
• 不得在未经同意时播放声音或无视静音设置；
• 不得变得强制、不可跳过，或在重复中令人疲惫；
• 不得增加与时刻不相称的依赖或资源成本。

若需要创作动效，delight 明确指引加载 animate.md（同目录的动效参考）；同时要尊重屏幕阅读器、键盘使用、触控、本地化与文化语境，非必要的循环动效在隐藏时必须停止，庆祝强度要与频率和后果成比例（Make celebration intensity proportional to frequency and consequence）。换言之：越常见、越低风险的时刻，庆祝就要越轻。

验证：交付前必须逐条过检

在把一个愉悦时刻提交之前，用下面的清单自检：

• 具体性：这个时刻是否足够具体，让相邻产品无法原样照搬？
• 价值：它是否改善了理解、信心、动机或情绪恢复（comprehension, confidence, motivation, or emotional recovery）？
• 降级可用：没有这个华丽效果时，界面是否仍然快速、明显（fast and obvious）？
• 重复耐受：重复使用不会把魅力变成摩擦（charm into friction）？
• 可及性：静音、键盘、触控与本地化路径是否都正常工作？
• 归属感：结果是否像"被选中的那个世界"的产物，而不是一份通用的 delight 处理？

最后一条尤其关键："The result feels like the selected world, not a generic 'delight' treatment."呼应了项目的核心信条——DESIGN.md里描述的 neo-kinpaku 系统（漆器黑、金箔金、铜绿蚀）就该只产生属于它的愉悦：克制的金线、真实的材质纹理、精密的测量感，而不是糖果色与弹性动画。

收尾交接：个性挣得之后，交给 polish

delight.md的收尾指令很短却很重要：

When the personality feels earned, hand off to/impeccable polishfor the final pass.

当个性表达"挣得了存在权"之后，不应当无限自我打磨（skill 核心原则之一就是"有界验证、拒绝开放式自 QA"），而是把成果交给 polish.md 做最终关。polish 会做的事情包括：区分功能缺陷与外观缺陷并分级修复、核对加载/空/错误/成功/禁用/权限状态、检查栅格与字距、验证语义色令牌与焦点对比度、清理调试输出与死代码，最后对照DESIGN.md与相邻功能核对一致性。

这两份文档的交接方式揭示了 impeccable 的设计哲学：delight 负责"想清楚情绪放在哪、为什么成立"，polish 负责"保证它落地的每一处都跟系统的其余部分一样精确"。情绪若没有系统级质量托底，就只是昙花一现的装饰；系统若没有情绪注入，就只是冰冷的可靠。

结合本指南你可以得到一条可直接执行的实战路径：先在DESIGN.md与产品语音里确定品牌情绪范围 → 判断当前表面的 visitor mode（Persuade/Experience 可放开、Operate/Read 要克制）→ 用六类缝隙寻找值得的时刻 → 写一句 delight thesis 并选择最小载体 → 按六个时刻细则实现 → 用九条禁区与最终清单验证 → 交给impeccable polish收官。这套流程既能让 AI 助手学会"什么时候该克制"，也能让它在真正值得的时刻给出有产品气质、经得起重复与无障碍检验的惊喜。

【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable