delight

delight 技能概览

delight 最擅长什么

delight 技能适合在不把产品做成“花活”的前提下，为 UI 加入恰到好处的愉悦感。它面向设计师、前端开发者，以及已经有可用界面的 AI 协作产品团队，帮助你通过微交互、俏皮但克制的文案、加载态、空状态、成功反馈和细微惊喜，提升产品的情绪质感。

delight 用于 UI Design 的最佳适用场景

在 UI Design 场景里，delight 适合解决的不是“把整个应用重做一遍”，而是“让这段体验更令人记住、更温暖、更精致，或更有回报感”。当你已经明确想优化的页面、流程或交互，只是需要判断哪些地方适合自然地加入 delight 时，它的价值最大。

delight 技能的差异化在哪里

和泛泛的“让它更好看一点”提示词不同，delight 的方法重点在于“放在哪里”和“收得住”。源文件里的指导明确强调：先找到自然的 delight 时机，再检查它是否符合品牌和受众，最后确保 delight 是在强化任务，而不是妨碍任务。相比只有灵感发散的泛用提示，这种结构对真实产品工作更有用。

上手前最需要知道的限制

delight 不是一个可以单独承担设计判断的全能设计脑。它自己的说明要求先有来自 /frontend-design 的设计上下文；如果这部分上下文还不存在，就必须先跑 /teach-impeccable。如果跳过这一步，输出会明显更依赖猜测，也更难贴合你的产品语气。

如何使用 delight 技能

调用 delight 之前，先把上下文装好

这个 GitHub skill 位于 pbakaus/impeccable 仓库的 .claude/skills/delight。从当前仓库片段来看，SKILL.md 里没有提供内置的 delight install 命令，所以更适合把它视为一个 Claude skill，按你当前环境的方式添加或复制到本地 skills 配置中。实际关键不在于“包怎么装”，而在于调用顺序：先运行 /frontend-design 完成上下文收集。

先读这个文件

从这里开始：

• SKILL.md

因为这个 skill 目录里只暴露了 SKILL.md，没有配套规则、参考文件或脚本来说明边界行为，所以输出质量会非常依赖你提供的产品上下文是否充分。

想把 delight 用好，必须先准备这些前置信息

在使用 delight 技能前，先收集：

• 要优化的页面或流程
• 产品所属领域
• 品牌个性
• 用户成熟度 / 专业程度
• 这个时刻更应该偏 playful、professional、quirky 还是 elegant
• 在可访问性、性能和信任感上的限制
• 希望 delight 是明显可见、轻微克制，还是尽量隐藏

如果当前还没有设计上下文，请按它自己的前置路径先执行 /teach-impeccable，再执行 /frontend-design。

delight 需要什么样的输入

高质量的 delight usage，起点一定是具体目标，而不是含糊愿景。有效输入通常包括：

• 一个明确的 UI 场景：如“settings save flow”“empty project dashboard”“file upload step”
• 当前的情绪问题：如“feels cold”“waiting feels dead”“success feels anticlimactic”
• 用户背景：如“B2B finance admins”“teens on mobile”“creative pros on desktop”
• 语气边界：如“confident, not silly”
• 实现约束：如“CSS only”“no sound”“must support reduced motion”

把模糊目标改写成可执行的 delight 提示词

弱一点的写法：

• “Make this app more delightful.”

更强的写法：

• “Use the delight skill on the onboarding empty state for a project management app. Audience is busy startup teams. Brand tone is optimistic and competent, not quirky. Add 3 subtle delight opportunities in copy, motion, or interaction that improve first-use confidence without slowing setup.”

之所以更好，是因为它明确给出了位置、受众、语气上限和成功标准。

delight 通常在哪些位置最能创造价值

这个 skill 会明确把你引向一些天然适合加入 delight 的时刻，比如：

• 成功状态
• 空状态
• 加载状态
• 成就达成
• 交互反馈
• 令人沮丧的报错时刻
• 可选的 Easter eggs

从安装决策角度看，这点很重要：delight 最擅长的是增强用户旅程中的关键时刻，而不是直接生成一整套设计系统。

delight 技能的推荐工作流

1. 先用 /frontend-design 收集产品和品牌上下文。
2. 选定一个具体的目标体验。
3. 让 delight 识别候选的 delight 时机。
4. 按领域适配度和用户预期筛选想法。
5. 只保留那些能增强清晰度、信任感或回报感的方案。
6. 再把选中的想法转成 UI 文案、动效规范或实现任务。

这个流程能避免 delight 产出随机噱头。

如何给 delight 控制范围，保证它持续有用

一个常见错误，是让它面向“整个应用”去做 delight。更好的方式是按事件缩小范围，例如：

• 保存后
• 第一次出现空状态时
• 等待上传时
• 完成 streak 后
• 主操作 hover 时
• 从错误中恢复时

这个 skill 的逻辑本质上是事件驱动的。事件越窄，输出越容易落地。

一个能明显提升输出质量的实用提示词结构

可以按这样的结构来写：

• 目标界面 / 场景
• 用户当前情绪
• 改动后希望达到的情绪
• 品牌语气
• 目标受众
• 风险容忍度
• 实现约束
• 需要避开的示例

示例：
“Apply the delight skill to the publish success state in a creator tool. Users currently feel uncertain whether publish succeeded. We want relief plus a sense of accomplishment. Tone is polished and creative, not playful. Suggest microcopy, motion, and one optional surprise detail. Avoid confetti and cartoon language.”

delight 不应该做什么

源文件里明确把 delight 定义为“增强体验，而不是分散注意力”。在实际使用里，以下想法应该直接淘汰：

• 拖慢任务完成
• 隐藏关键信息
• 削弱专业可信度
• 给用户塞过多动效
• 带来可访问性问题
• 在严肃领域里明显不符合品牌调性

这条边界，正是你应该优先用 delight skill 而不是泛用创意提示词的重要原因之一。

delight 技能 FAQ

delight 只适合偏 playful 的产品吗？

不是。delight 技能同样适用于严肃型产品，只是表达方式会不同。在金融、医疗或企业软件语境里，delight 往往体现为更安心的反馈、更优雅的过渡、更有人味的空状态，或更平静的成功提示，而不是显眼的俏皮感。

delight 对新手友好吗？

友好，前提是你已经知道哪个页面或流程需要优化。对新手最大的阻碍不是复杂度，而是上下文缺失。如果你不提供受众、语气或产品约束，它依然会产出想法，但这些想法会更难让人信服，也更难放心采用。

delight 和普通 prompting 有什么不同？

普通 prompting 往往会生成停留在表层修饰的点子。delight 更偏决策辅助：它会追问 delight 应该放在哪里、是否符合品牌、怎样避免喧宾夺主。最终通常是点子更少，但更容易真正上线。

什么时候不该用 delight 技能？

如果你还在处理核心 UX 结构、IA 或任务流设计，就先不要用 delight。它是打磨型技能，不是用来替代可用性问题的解决方案。如果用户连任务都无法清楚完成，那现在谈 delight 还太早。

delight 会帮助到实现细节吗？

会，但属于间接帮助。这个 skill 以概念为先，不过你可以要求它把想法表达成 UI 文案、动效行为、交互说明或前端任务。如果你需要真正的组件或代码，应该在概念确认后，再把输出接入你的 frontend workflow。

如何改进 delight 技能的使用效果

给 delight 喂更完整的产品上下文

想提升 delight 结果，最快的方法就是