企业官网建设流程全解析

Impeccable 实战：/impeccable delight命令如何为界面注入“产品性格”

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

Impeccable 是一个“让 AI 编码助手更懂设计”的技能包，其delight子命令专门解决一个高频但易踩坑的问题：如何在不伤害可用性、不堆砌“通用俏皮感”的前提下，让产品在关键情绪节点上令人难忘。本文以 reference/delight.md 这份官方玩法手册为骨架，逐节展开它的完整工作流（机会发现 → 单一 delight 命题 → 情绪时刻构建 → 体验保护红线 → 验收清单），并结合仓库中的技能定义与配套文档，说明每条规则在 Impeccable 体系中的落点。读完后，你应当能独立完成一次有纪律的“ delight 工程”：找到值得庆祝的时刻、写出一个可验证的 delight 命题、在六个情绪场景中落地最小系统，并用验收清单确认“性格是被挣来的”。

1. delight 命令在 Impeccable 中的位置

Impeccable 技能通过 SKILL.md 定义了一套 23 个命令的设计工作流，按 Build / Evaluate / Refine / Enhance / Fix / Iterate 六类组织。delight属于Enhance类：

在 command-metadata.json 中，delight的触发语义被写得更具体：当用户要求“add polish, personality, animations, micro-interactions, delight, or make an interface feel fun or memorable”时使用。参数只有一个可选的[target]，指向要增色的页面、组件或流程。

这份手册开篇第一行就声明了执行前置条件：

Additional context needed: the brand's emotional range.（需要的额外上下文：品牌的情绪范围）

这不是客套话。手册要求执行者先审视目标代码、DESIGN.md、产品语气（product voice）、重复使用频率与情绪语境，再动手。在 Impeccable 的工作流里，这些上下文的来源是明确的：SKILL.md 的 Setup 一节要求每个会话先运行node <skill-base-dir>/scripts/context.mjs，它会加载 PRODUCT.md（战略层：用户、品牌、原则）、DESIGN.md（视觉层：色彩、字体、组件）以及对应表面的 brief。也就是说，delight命令假设你已经通过init捕获过产品语境——这正是“品牌的情绪范围”能否被推断的前提。

核心定义只有一句话，但值得完整引用：

Make the experience memorable at moments that earn it. 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 不是铺在界面上的一层“通用俏皮”，而是产品性格通过一次有用的交互、一次人性化的回应、或一个意料之外被考虑到的细节显现出来。它必须在“挣得了”（earned）的时刻才出现。

2. 按访客模式决定 delight 的剂量

手册第一节Visitor mode把 delight 的浓度与 Impeccable 的四类访客模式（SKILL.md 的 Modes 一节定义了 Persuade / Operate / Read / Experience 四种模式，模式名回答的是“访客在这个表面上如何算成功”）绑定：

• Persuade + Experience（营销页、落地页、作品集、画廊）：性格可以贯穿 voice、构图、动效与发现感——前提是作品/内容本身仍然是焦点。
• Operate + Read（应用 UI、仪表盘、编辑器、文档、指南）：把 delight集中在少数有意义的时刻，例如首次使用、完成、恢复或精通（mastery）。其余时间，可靠性（reliability）承载一切。

这条规则的工程含义是明确的剂量控制：同样是“加个性”，落地页可以整页布设性格，而仪表盘只在关键节点释放它。SKILL.md 还强调模式由“请求的表面”而非“产品”决定——工具的落地页仍是 Persuade，时尚品牌的文档站仍是 Read。做 delight 之前先定模式，避免把 Operate 界面做成 Persuade 语气。

3. 发现机会：六个候选时刻的排查清单

Find the opportunity一节给出一个结构化的排查动作。先检查四个输入：目标实现、DESIGN.md、产品语气、重复使用频率、情绪语境；然后在以下六类候选中寻找落点：

1. 值得被承认的努力（effort worth acknowledging）——用户付出了显著操作成本的时刻；
2. 可以变成信息展示的等待（waiting that can become informative）——加载、异步处理等待；
3. 可以完成导引的空状态或首次使用状态（an empty or first-use state that can orient）；
4. 需要同理的错误或恢复时刻（an error or recovery moment that needs empathy）；
5. 其物理或语言回应能表达品牌的交互（an interaction whose physical or verbal response could express the brand）；
6. 人们会乐于发现的有用能力（a useful capability people might enjoy discovering）。

清单之后紧跟一条反模式禁令：

Do not manufacture a celebration for an ordinary click. Ask only when the brand's emotional range or the stakes cannot be inferred.

不要为一次普通点击编造庆祝动效；只有当品牌情绪范围或赌注（stakes）无法从现有上下文推断时，才向用户提问。这条规则与 routing.md 的整体风格一致：基于信号推理、避免无谓打扰。它把 delight 从“随手加彩蛋”变成了“先找值得投资的情绪节点，再谈怎么庆祝”。

4. 定义单一的 delight 命题（one delight thesis）

Define one delight thesis一节要求先写出一句话：用户应该感受到什么，以及为什么这种感觉属于这个产品。然后选择能交付这个感受的最小系统，手册列出五种形态：

• 对有意义动作的标志性回应（a distinctive response to a meaningful action）；
• 既能澄清又能承载语气的产品专属语言（product-specific language）；
• 具有可辨识材质行为的交互或转场（a transition with a recognizable material behavior）；
• 扎根于产品世界的插画、声音、触感或环境细节（illustration, sound, haptic, or environmental detail）；
• 揭示真实实用价值的发现奖励（a discovery reward that reveals real utility）。

结尾的约束同样关键：

Derive the treatment from product mechanism and visual world, not a stock catalog.

处理方式必须从产品机制与既有视觉世界推导，而不是从素材库/模板目录里挑一个现成特效。这与 SKILL.md 中“Refinement preserves; redesign replaces”“视觉权威是证据而非文件名”的原则一脉相承——delight 不是替换旧身份，而是在既有世界内长出细节。

5. 为情绪时刻构建：六个场景的落地规则

Build for the emotional moment一节按六类情绪时刻给出具体规则，这是手册中最接近“实施规范”的部分：

表格之后是一条关于文案的总原则：

Copy must use the product's language. Generic whimsy is worse than neutral clarity.

delight 文案必须使用产品的语言；通用的俏皮比中性的清晰更糟糕。这句判断标准可以直接用于验收任何一句彩蛋文案。

6. 保护体验：六条红线与配套引用

Protect the experience一节列出 delight不得做的事，这是手册中最硬的约束清单：

• 不得延迟、阻塞或遮蔽主任务；
• 不得覆盖平台惯例或可访问性约定；
• 不得添加未被要求的事实性声明（factual claims）；
• 不得在未经同意时播放声音，或无视静音设置；
• 不得成为强制、不可跳过、或重复使用令人疲惫的存在；
• 不得为某个时刻引入与它不成比例的依赖或资源成本。

随后手册给出三条操作性注记：

1. 自创动效时加载 animate.md。这份姊妹文档是 delight 在“动效”维度上的实施细则：它要求先写 motion thesis（焦点时刻/连续性/反馈/预算四项），给出了时长表（100–150 ms 即时反馈、150–300 ms 例行状态变化、300–500 ms 布局/视图转场、500–800 ms 精心编排的焦点入场），规定“出场快于入场”“不要用弹跳/弹性曲线做反射性默认”，并要求每个 Web 动效都有prefers-reduced-motion路径。delight 文档把动效的“怎么做”整体委托给它，自己只保留“何时值得做”的判断权。
2. 尊重屏幕阅读器、键盘操作、触控、本地化与文化语境；非必需的循环动画在不可见时必须停止。
3. 庆祝强度要与频率和后果成比例（celebration intensity proportional to frequency and consequence）——高频出现的交互配更克制的回应。

这三条注记实际上把 delight 纳入了 polish.md 验收范围：polish 的交互与状态检查项包含“motion coherent, interruptible, and performant”“preserve visible keyboard focus, logical tab order, labels”等，意味着 delight 引入的动效与文案最终都要通过 polish 的统一质量闸门。

7. 验收清单：delight 是否“挣得了”

Verify一节给出六个可独立核查的验收点，建议作为交付前的自测清单逐条打勾：

1. 该时刻足够具体——相邻产品无法原样搬走（the moment is specific enough that a neighboring product could not use it unchanged）；
2. 它切实改善了理解、信心、动机或情绪恢复之一；
3. 去掉这个 flourish，界面依然快且明显；
4. 重复使用不会把魅力变成摩擦；
5. 静音、键盘、触控、本地化路径都正常工作；
6. 结果“像所选的那个世界”，而不是一个通用的“delight 处理”。

六个检查点共同指向同一个判据：delight 必须是产品专属的、可移除而不伤筋动骨的、且在降级输入方式下依然成立的。任何一条不满足，都说明当前实现更可能是装饰而非性格。

全部通过后，手册给出的收尾动作是移交：

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

即把最终质量通读交给polish命令（reference/polish.md 的 triage 顺序为：功能缺陷 → 状态缺失 → 流程/层级/系统漂移 → 视觉与动效不一致 → 代码清理）。SKILL.md 的命令表也确认polish [target]是 Refine 类的“final quality pass before shipping”。delight 与 polish 因此形成清晰分工：delight 负责注入性格，polish 负责保证整体质量不被性格伤害。

8. 实操串联：从调用到交付

把上述手册内容放回 Impeccable 的运行时语境，一次完整的 delight 工作大致是：

1. 准备上下文：确保项目已有PRODUCT.md/DESIGN.md（可分别通过init与document命令生成）；会话开始按 Setup 要求运行一次node <skill-base-dir>/scripts/context.mjs，它会按--target <path>加载产品与表面上下文。没有品牌情绪范围时，delight手册的第一行“Additional context needed”就是在提示你：此时应停下来询问，而不是猜测。
2. 调用命令：/impeccable delight [target]，target 为具体的页面、组件或流程。技能会加载本手册作为执行剧本（playbook）。
3. 按节执行：定模式（第 2 节）→ 排查六类机会（第 3 节）→ 写出一句话 delight 命题并选最小系统（第 4 节）→ 按六个情绪场景落地（第 5 节）→ 自查六条红线（第 6 节）。
4. 验收与移交：过六个验收点（第 7 节），然后移交/impeccable polish。

一个值得了解的仓库事实：这套技能按 harness 分发——同一份reference/delight.md在 .agent/skills/impeccable/reference/、.claude/、.cursor/、.gemini/、.grok/、.opencode/等各 harness 目录中各有一份对应拷贝（技能源文件位于 skill/reference/delight.md）。各拷贝内容一致，差异仅在于命令前缀这类模板占位符是否已按 harness 解析。无论你在哪种编码助手里触发/impeccable delight，读到的纪律与上面完全相同。

小结

delight.md的价值不在于教“怎么做一个漂亮的微交互”，而在于给出了一套可审计的决策流程：先用访客模式控制剂量，再用六类时刻找机会，用一句话命题收敛方案，用六个情绪场景规范实现，用六条红线保护主任务与可访问性，最后用六个验收点确认这个时刻确实是“这个产品”的。结合 animate.md 的动效细则与 polish.md 的收尾闸门，delight 在 Impeccable 工作流中是一个边界清晰、可复用的增强命令——它让“加个性”从一句模糊的需求，变成一组可以逐条回答是/否的检查项。

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