WhoDB 的 Impeccable 设计技能：`delight` 命令如何把“产品个性“注入用户界面-育师

数据库客户端
后端
前端
CLI
桌面应用
数据可视化
AI 应用

【免费下载链接】whodb

Where data access meets operational intelligence

项目地址：https://gitcode.com/gh_mirrors/wh/whodb

本文以 WhoDB 仓库中.agents目录下 Impeccable 设计技能的delight参考文档为核心，拆解这套为 AI 编码代理编写的前端体验方法论：它如何定义"delight（愉悦感）"、如何为一次交互机会确立单一 thesis、如何围绕六种情感时刻构建响应，以及它的验证清单与边界保护规则。读完后你能掌握一套可复用的"克制型愉悦设计"工作流，并理解 WhoDB 自己的设计系统（PRODUCT.md / DESIGN.md）是如何为这类增强提供品牌输入的。

delight 是什么：不是随机撒糖，而是产品性格的显形

delight [target]是 Impeccable 技能 Enhance（增强）类别下的子命令，其定位在技能元数据中表述为：

Add moments of joy, personality, and unexpected touches that make interfaces memorable and enjoyable to use. Elevates functional to delightful. —— command-metadata.json

而参考文档 delight.md 开篇（L3）给出了一条比元数据更严格的定义：

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.

即：愉悦感不是覆盖在界面上层的一层"通用俏皮"，而是产品性格通过一次有用的交互、一个得体的响应、一个出人意料但深思熟虑的细节显露出来。这一整篇 playbook 本质上是一份写给编码代理的约束文档：文档第一行还声明了执行前缺失的上下文——Additional context needed: the brand's emotional range（品牌情感幅度），只有当品牌情感幅度或风险等级无法从项目上下文推断时，才向用户提问（L23）。这与同目录其他 playbook（如 clarify.md 需要"audience knowledge and emotional state"、animate.md 需要"performance constraints"）采用完全一致的结构：声明前置上下文 → 分节给出操作规则 → 收尾给出 Verify 清单与交接指令。

在 Impeccable 技能中的位置

从 SKILL.md 的 Commands 表看，delight与animate（动画）、colorize（配色）、typeset（排版）、layout（布局）同属 Enhance 类，而bolder/quieter/distill属于 Refine 类（放大/收敛/精简既有设计）。文档结尾（L70）规定：当个性"感觉是被赢得的"（the personality feels earned）时，交接给$impeccable polish做最终打磨。也就是说 delight 在流水线中的位置是：

context.mjs加载 PRODUCT.md / DESIGN.md / 表面简报（SKILL.md Setup 节要求每个会话运行一次）；
按 Commands 表路由到delight.md并按其规则修改 UI；
编辑 UI 前需加载 craft-floor.md（质量底线与绝对禁令）；
完成并自检后交给polish。

此外，pin.mjs 支持将delight固化为独立快捷命令（$delight）：

node .agents/skills/impeccable/scripts/pin.mjs pin delight # 移除 node .agents/skills/impeccable/scripts/pin.mjs unpin delight

该脚本会在项目根目录下探测所有已安装 Impeccable 的 harness 目录（.claude、.cursor、.codex、.agents等，见 L23-L26 的HARNESS_DIRS）并创建/移除对应的 pin 标记文件。在 live.md 的浏览器实时变体模式中，delight也是一个 action，其变体维度被限定为"不同风味的人格（micro-interaction / typographic surprise / illustrated accent / sonic-or-haptic / easter egg）"（L172）。

Visitor mode：同一份 delight 规则在两类界面上的不同浓度

文档 L7-L10 将规则按 visitor mode 分叉，mode 概念定义在 SKILL.md 的 Modes 节（Persuade / Operate / Read / Experience 四种）：

Persuade + Experience（落地页、作品集、展示型界面）：个性可以贯穿 voice（语气）、composition（构图）、motion（动效）与 discovery（发现感），前提是工件（artifact）本身仍是焦点；
Operate + Read（App UI、仪表盘、编辑器、文档）：把愉悦感集中在有意义的时刻——首次使用、完成、恢复、精通；其余一切由可靠性（reliability）承载。

这与 WhoDB 自身的定位完全吻合。PRODUCT.md 将用户定义为"管理多个数据库系统、常在事故或维护期间工作的 DBA / DevOps 工程师"，设计原则第一条就是"Speed is the feature"，品牌人格是"Confident, clean, capable…clarity and speed ARE the personality"。DESIGN.md 的 Creative North Star 是"Quiet Confidence"，并明确拒绝了"过度俏皮的 SaaS"（illustration-heavy、rounded pastels、startup energy）——这正是 delight playbook 警告的 generic whimsy 的具象。因此对 WhoDB 前端而言，delight 落在 Operate 分支：可靠性承载一切，愉悦感只出现在值得的时刻。operate.md L61 对此有近乎同义的表述："Consistency over surprise…delight is saved for moments, not pages."（一致性优先于惊喜：愉悦留给时刻，而非页面。）

Find the opportunity：六类"值得加码"的交互机会

文档 L12-L23 规定了机会发现的方法论。执行者应先检查五类输入：目标界面、DESIGN.md、产品语气、复用频率、情感上下文，然后只寻找以下六类机会：

机会类型	原文表述	在数据库工具中的对应场景
值得被承认的努力	effort worth acknowledging	一次大表导出、一次成功的批量迁移
可以变得有信息量的等待	waiting that can become informative	查询执行进度、连接建立过程
能"定向"的空/首次使用状态	an empty or first-use state that can orient	首次连接前的引导、无 schema 时的提示
需要同理心的错误或恢复时刻	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	隐藏的高级筛选、快捷键

随后是两条硬约束（L23）：不要为一次普通点击制造庆祝（Do not manufacture a celebration for an ordinary click）；只在品牌情感幅度或风险等级无法推断时才提问。这两条直接对抗最常见的反模式——把 confetti、bounce、"干得好！"式文案撒到每一次 hover 上。

Define one delight thesis：先立论，再选"最小系统"

L25-L35 是全篇的方法论核心。它要求：

用一句话陈述：用户应该感受到什么，以及为什么这种感受专属于这个产品；
然后选择能交付该感受的最小系统，候选形态共五类：
- 对一次有意义动作的有辨识度的响应（a distinctive response to a meaningful action）；
- 既能澄清又携带语气的产品专属语言（product-specific language）；
- 具有可辨识材质行为的交互或过渡（an interaction or transition with a recognizable material behavior）;
- 扎根于产品世界的插图、声音、触感或环境细节；
- 揭示真实工具价值的发现式奖励（a discovery reward that reveals real utility）。
最后一条原则：处理方案必须从产品机制与视觉世界中推导，而不是从"库存目录"（stock catalog）里挑一个现成的——禁止"凡是产品 UI 都能直接搬用"的通用特效。

这一节实际上把 delight 从"加特效"重新定义为一次设计决策：先有论点（thesis），再为论点选最便宜的实现。这与 WhoDB 的 token 驱动设计系统（DESIGN.md 要求一切样式经由var(--font-size-*)/var(--radius-*)/var(--spacing-*)与 CSS 自定义属性表达）天然兼容——任何 delight 细节如果想存活于密度切换（small/medium/large 档位）与双主题（Paper/Ink）之下，就必须落在 token 体系内，而不能是硬编码的一次性样式。

Build for the emotional moment：六种情感时刻的构建规则

L37-L46 把"情感时刻"拆成五个具体类别，每一类都有明确的"该做什么/不该做什么"：

Success（成功）：响应必须与付出的努力和后果匹配——重大里程碑可以展开（expand），例行保存只需"确定感"（simply feel certain）。对应到数据库工具：一条DELETE成功后不应有火箭升空，而一次跨库迁移完成则可以有一个值得记住的确认。
Waiting（等待）：展示真实的进度、有用的上下文或产品专属的活动；绝不伪造工作量、绝不为了"表演"而延迟完成。
Empty and first use（空与首次使用）：先让下一个动作清晰，再谈个性。顺序不能反。
Error and recovery（错误与恢复）：以问题和恢复路径开头；温度（warmth）可以降压，但玩笑绝不能轻视数据丢失、金钱、隐私或被阻塞的工作。
Repeated interaction（重复交互）：响应在第一百次使用时依然令人满意；变化（variation）只有在保持连贯且可预测到值得信任时才成立。
Discovery（发现）：奖励好奇心，但不隐藏必需功能。

L46 收了一记重锤："Copy must use the product's language. Generic whimsy is worse than neutral clarity."——文案必须使用产品自己的语言，通用的俏皮比中性的清晰更糟。

WhoDB 仓库中已经能看到这种方法的影子：例如 schema 视图的空状态不是"这里什么都没有"式的敷衍，而是明确指向"没有表"这一事实的No tables found，且这条文案在 schema-viewer.yaml 中随 30+ 种语言本地化维护——这正是"空状态先定向（orient）、再谈个性、且文案走产品语言"三条规则的落地形态。

Protect the experience：delight 的六条禁区

L48-L59 用一份禁止清单划出边界，任何 delight 实现都不得：

延迟、阻塞或遮蔽主任务；
覆盖平台惯例或可访问性；
添加未经请求的事实性声明；
未经同意播放声音，或无视静音设置；
变得强制、不可跳过、或在使用中令人疲惫；
为某个时刻添加与时刻不成比例的依赖或资产成本。

随后是对其他 playbook 的引用与通用要求：

凡涉及自作者动效（authored motion），加载 animate.md——它规定了 100–150ms 即时反馈 / 300–500ms 布局过渡等时长梯度、"退出快于进入"、以及不得为现有栈能表达的效果引入依赖；
尊重屏幕阅读器、键盘、触控、本地化与文化语境；
非必要的循环动效在不可见时必须停止；
庆祝的强度要与发生频率和后果成正比。

这条"不可见即停止"在 WhoDB 前端有真实对应物：index.css 中为加载标记（loader mark）的多个 SVG 部件定义了prefers-reduced-motion: reduce分支（约 L648-L661），当用户系统偏好减弱动效时，所有animation被置为none，仅保留静态形态；L803 还有一处同类媒体查询。这既是 PRODUCT.md 中"Respectprefers-reduced-motion"原则的实现，也是 delight 禁区第 2 条（不覆盖平台惯例与可访问性）的代码证据。

Verify：交付前的六问与 polish 交接

L61-L70 是自检清单，每一条都是可执行的验收标准：

这个时刻具体到邻近产品无法原样照搬（the moment is specific enough that a neighboring product could not use it unchanged）——这是"anti-stock-catalog"原则的验收形式；
它改善了理解、信心、动机或情绪恢复；
去掉这个装饰后，界面依然快速且显而易见（fast and obvious without the flourish）；
重复使用不会让"魅力"变成"摩擦"；
静音、键盘、触控与本地化路径全部可用；
结果感觉属于所选定的"世界"，而不是一套通用的"delight 处理"。

全部通过后，按 L70 的指令hand off to $impeccable polish for the final pass，进入 polish.md 的收尾流程（建立系统认知 → 收集证据 → 分诊 → 全路径打磨 → 再次走查）。

在 WhoDB 仓库中实操 delight 的完整路径

把上述文档放回它的运行环境，实际操作序列是：

# 1. 每个会话运行一次上下文加载（读入 PRODUCT.md、DESIGN.md、表面简报） node .agents/skills/impeccable/scripts/context.mjs --target frontend/src # 2. 在编码代理中调用 delight 子命令，target 指向具体表面 # （路由规则见 SKILL.md Commands 表：Enhance 类 → reference/delight.md） $impeccable delight frontend/src/pages/... # 3. （可选）把 delight 固定为独立快捷命令 node .agents/skills/impeccable/scripts/pin.mjs pin delight

几点前提与限制需要说明：

context.mjs的路径解析规则（其文件头注释 L11-L24）是"活动项目根 →.agents/context/→docs/→ 仓库根 →$IMPECCABLE_CONTEXT_DIR"依次回退；WhoDB 的 PRODUCT.md 与 DESIGN.md 都在仓库根目录，因此任意工作目录启动都会被正确解析。若找不到 PRODUCT.md，脚本会打印NO_PRODUCT_MD:，技能据此把请求导向 init 流程而非直接执行 delight。
delight 是纯 UI 工作：SKILL.md 明确声明该技能"Not for backend-only or non-UI tasks"，所以它的 target 应指向前端表面（如frontend/src/下的页面/组件），而不是 Go 后端或 CLI。
由于 WhoDB 采用 token 驱动样式（DESIGN.md 要求经@clidey/ux的 CSS 自定义属性扩展组件，禁止!important覆盖组件内部），delight 产出的任何视觉细节若要合规，也必须落在 token 与语义角色上——这既是 DESIGN.md 的 Density-Tier Rule，也是 delight "不成比例成本"禁区的工程化表达。

小结

delight.md的价值不在于提供一套"加特效"的清单，而在于提供一套反特效的方法论：先确定品牌情感幅度，再从六类机会中挑选真正"值得"的时刻，用一句话立住专属本产品的 thesis，选最小系统实现，用六条禁区守住主任务与可访问性，最后以"去掉它界面依然清晰"为验收线交给 polish。WhoDB 仓库中的 Quiet Confidence 设计体系——空状态的克制文案、本地化的状态语言、prefers-reduced-motion下的动效降级——正是这套方法论在 Operate 型产品上的实际落点：对一款以"快速、清晰、克制"为性格的数据库管理工具来说，最好的 delight 往往是不喧宾夺主的那一种。