delight

delight skill 概览

delight 是做什么的

delight skill 用来帮助智能体在 UI 工作中加入恰到好处的愉悦感、个性和细微打磨，而不是把界面做成噱头。它真正要解决的，并不是抽象地“让产品更好玩”，而是判断哪些位置适合加入小而有情绪价值的设计触点，尤其是在成功状态、空状态、加载过程、引导流程和轻量交互里，让体验更顺滑、更有记忆点。

谁适合使用 delight

这个 delight skill 特别适合做产品 UI、引导流程、dashboard、消费级应用、创意工具以及重视品牌调性的体验设计团队。尤其当团队提出“再精致一点”“更有个性一点”或“希望更让人记住”，同时又要求结果必须可用、符合品牌时，它会很有帮助。

适合用于 UI Design 的 delight 场景

如果你想把 delight 用于 UI Design，这个 skill 比泛泛的“加点动画”提示词更靠谱，因为它关注的是放在哪里、是否合适、以及克制程度。它的目标是让 delight 去增强产品体验，而不是干扰用户完成任务。

最大差异点

它最核心的差异在于判断力：这个 skill 会明确寻找自然适合加入 delight 的时刻，并进一步追问当前产品语境是否适合偏 playful、elegant、quirky 或 professional 的表达方式。这让它比一类“一键视觉润色”的建议更有实际价值。

采用前必须知道的限制

delight skill 并不是完全独立可用的。它自己的说明明确要求先有设计上下文，包括先调用 /frontend-design；如果当前还没有设计上下文，还需要先运行 /teach-impeccable。如果跳过这些准备，输出质量会明显下降，因为“delight”高度依赖品牌语气、目标用户和产品本身的严肃程度。

如何使用 delight skill

在你的 skills 环境中安装 delight

在常见的 GitHub skills 环境里，可以这样安装：

npx skills add pbakaus/impeccable --skill delight

如果你的环境已经同步了 pbakaus/impeccable 仓库，请确认该 skill 位于 .agents/skills/delight。

先读这个文件

先从这里开始：

• SKILL.md

这份仓库快照里，和这个 skill 相关、真正有信息量的文件只有这一个，所以你对它的大部分理解都要来自这份文档，而不是辅助脚本或参考资料。

调用 delight 前先理解必需的准备工作

在使用 delight 之前，先把设计上下文准备好：

1. 调用 /frontend-design
2. 按它的 Context Gathering Protocol 执行
3. 如果还没有任何设计上下文，先运行 /teach-impeccable
4. 收集领域调性信息：例如 playful、professional、quirky、elegant 等

这些步骤不是可有可无的形式工作。delight skill 会对“是否合适”做价值判断，因此它必须知道产品和受众的上下文，才能避免产出那种浅层的“加点亮点”式建议。

明确 delight 需要什么输入

当你提供以下信息时，delight skill 的效果最好：

• 目标页面、流程或组件
• 产品类型和目标受众
• 品牌个性
• 当前任务的严肃程度
• 任何 motion、accessibility 或 performance 约束
• 当前问题，例如“感觉太冷”“成功状态太平”

弱输入：

• “Make this screen more delightful.”

更强的输入：

• “Use delight on our invoicing app’s payment success screen. Audience is small-business owners, tone is calm and trustworthy, not playful. We want a brief rewarding moment after payment confirmation without slowing users who need the receipt immediately. Avoid heavy animation.”

delight 通常最适合用在哪些位置

根据这个 skill 的说明，比较适合加入 delight 的位置包括：

• 成功状态
• 空状态
• 加载状态
• 成就与里程碑
• hover、click、drag 等交互
• 错误恢复时刻
• 可选的 Easter eggs

这点很实用，因为它能帮助你把精力集中在“delight 出现得理所当然”的时刻，而不是把它平均撒在整个界面上。

哪些场景不适合用 delight

如果一个界面的核心诉求是紧迫性、安全性、合规性，或者高密度任务吞吐，就不该优先考虑 delight。例如：

• 关键的医疗或金融操作
• 高压场景下的运营控制台
• 安全确认流程
• 速度和清晰度明显比个性更重要的工作流

在这些情况下，即便要用 delight，也应该非常克制，并优先传达平静、可靠的安心感，而不是新奇感。

把模糊目标变成高质量的 delight 提示词

一个好用的 delight 提示词，通常应包含五个要素：

1. 目标界面
2. 用户前后情绪变化
3. 品牌语气
4. 约束条件
5. 输出格式

示例：

Apply the delight skill to our empty dashboard state for first-time users.
Context: B2B analytics product, audience is marketers, tone is smart and optimistic.
Goal: reduce the cold, intimidating feel of an empty workspace.
Constraints: keep copy concise, no cartoon tone, minimal motion, accessible by default.
Output: propose 5 delight opportunities ranked by impact, then rewrite the empty state copy and describe one subtle interaction.

这种结构能给 skill 足够的信息，让它去选择合适的 delight，而不是默认产出千篇一律的 micro-interactions。

要求给出排序方案，而不是只要一个点子

在实际使用 delight 时，建议让智能体按以下维度给想法排序：

• 对用户情绪的影响
• 实现复杂度
• 品牌契合度
• 分散注意力的风险

这很重要，因为 delight 本身就是主观的。排好序的方案更方便评审，也能降低“第一个想法太卖萌、太贵、或太不符合品牌”的风险。

在基础 UX 已经成立之后再用 delight

delight skill 在核心流程已经清晰可理解的前提下最有效。如果你的页面仍然存在 IA、文案或可用性问题，delight 只会掩盖问题，而不是解决问题。更稳妥的工作流是：

1. 先把基础 UX 建好
2. 收集设计上下文
3. 运行 delight
4. 检查语气和 accessibility
5. 优先实现那些投入小、价值高的细节

好的 delight 输出应该包含什么

一个有用的 delight 指南，应该远不止“加点动画”。你应该期待输出中明确说明：

• 具体该强化哪个 UI 时刻
• 为什么这个时刻值得加入 delight
• 表达强度应该到什么程度
• 如何兼顾清晰度和效率
• 在这个领域里哪些做法要避免

如果输出过于宽泛，就让智能体收窄到一个页面和一种情绪结果。

用 delight 做概念发散，再为生产落地收紧

一种很实用的工作方式是：先让 delight 生成几个高层概念，然后再做一次更严格的生产化收敛：

• 减少 motion
• 缩短文案
• 去掉装饰性多余元素
• 验证 accessibility
• 检查 performance 成本

这种两步法可以保留 delight 的创意收益，同时避免把不必要的花哨设计直接上线。

delight skill 常见问题

delight 只适合偏 playful 的产品吗

不是。delight skill 同样适用于更 professional 的产品，只是表达方式会不同。在严肃型产品里，delight 往往体现为松一口气、顺滑、温暖、反馈精致，而不是幽默感或夸张动画。

delight 为什么比普通提示词更好

普通提示词通常会直接跳到效果层面。delight skill 更强的地方在于它围绕“上下文”和“机会点选择”来组织：哪里适合用 delight，哪里不适合，以及对当前用户和品牌来说，呈现强度应该到什么程度。

delight 对新手友好吗

友好，前提是你已经知道自己要优化的是哪个页面或流程。新手最容易漏掉的是上下文。如果你不提供产品语气、目标受众或约束条件，delight skill 可能会给出听起来不错、但很难真正上线的建议。

我需要先用其他 impeccable skills 吗

通常需要，至少要走完设计上下文这条路径。delight skill 明确依赖 /frontend-design，而在上下文还不存在时，可能还需要 /teach-impeccable。把 delight 理解成建立在设计理解之上的专项增强层，而不是设计工作的第一步工具，会更准确。

delight 能帮忙处理 copy、motion 和 interactions 吗

可以。源说明明确指向空状态、成功反馈、加载、成就节点和交互时刻等场景。这意味着 delight 不只是影响视觉，还会影响 microcopy、节奏、反馈反应以及小型 UI 行为。

什么时候不该使用 delight

如果主要问题是导航不清晰、信息层级混乱、缺乏产品策略，或 UX 基础本身就有缺陷，就先不要用 delight。另外，在必须保持中性表达，或者 playful 表达可能削弱信任感的领域，也应避免使用。

如何提升 delight skill 的效果

给 delight 一个更明确的情绪目标

提升效果最大的杠杆，是把情绪目标说具体。不要只说“make it delightful”，而要明确描述希望发生什么变化：

• 从焦虑到安心
• 从空荡到有邀请感
• 从例行公事到更有奖励感
• 从等待到被温和地占用注意力

这样能帮助 delight 更准确地选择时机和语气。

一开始就给出品牌边界

只要你明确哪些东西不能碰，delight skill 的表现通常会明显提升：

• 不要 mascots
• 不要 bounce animations
• 不要 jokes
• 不要 gamification
• 成功后不要额外增加等待时间

这些约束能避免最常见的失败模式：想法过度表达，最终损害产品信任感。

指明严肃程度和领域风险

因为 delight 很容易用力过猛，所以你最好直接告诉智能体，允许的情绪强度大概到哪里。例如：

• “fintech, medium trust sensitivity”
• “admin tool, low need for whimsy”
• “creative app, high tolerance for playful interaction”

这样生成出来的 delight 指南会更贴近真实产品环境。

让 delight 区分 must-have 和 nice-to-have

一个常见问题是，输出会把实现成本差异很大的点子混在一起。你可以通过下面这种要求让结果更好落地：

• 1 个高影响、低投入的想法
• 1 个中等投入的标志性时刻
• 2 个可选的延展想法

这样更符合真实产品团队的采用方式。

强制每个想法都说明理由

要求智能体针对每个 delight 建议都解释：

• 为什么这个时刻适合加入 delight
• 它支持的是哪种用户感受
• 为什么不会妨碍任务完成

这样可以筛掉纯装饰性的填充内容，让 delight 始终和 UX 价值绑定。

修正最常见的失败模式：delight 过多

如果第一版输出显得太吵、太满，可以直接要求第二轮收紧限制：

Revise the delight proposals to be 40% more restrained.
Keep only ideas that improve clarity, reward completion, or soften friction.
Remove anything that adds cognitive load, delay, or cartoonish tone.

这通常是让 delight 进入可上线状态的最快方法。

用单页面范围提升实现质量

不要一上来就让 delight 重塑整个产品。先选一个具体界面，例如：

• signup success
• first empty dashboard
• file upload loading state
• saved confirmation
• drag-and-drop feedback

范围越窄，给出的建议通常越可执行，也越容易评审。

从概念发散迭代到可上线细节

拿到第一轮 delight 输出后，继续追问更具体的问题：

• “Which idea has the best value-to-effort ratio?”
• “Rewrite this for an enterprise audience.”
• “Make the interaction accessible with reduced-motion fallback.”
• “Remove anything that could slow expert users.”

这一步才是 delight skill 真正变得有用、而不只是“有启发”的关键。

让 delight 与 accessibility 和 performance 评审一起进行

好的 delight for UI Design 仍然必须尊重 reduced motion、响应速度和快速完成任务的需求。一个看起来精致、却损害 accessibility 或速度的方案，并不能算成功的 delight。你可以要求智能体同时给出 fallback 行为，并标明任何有风险的 motion 或 timing 假设。

为团队建立可复用的 delight brief

如果你预计会持续使用 delight，最好整理一份可复用的简短 brief，包含：

• 品牌语气
• 目标受众
• 领域敏感度
• motion 限制
• copy 风格
• 可接受与不可接受的 delight 示例

每次都复用同一份 brief，可以让 delight skill 的输出更稳定，也能减少返工。