Executable Taste
定义
Executable Taste 指把原本依赖资深设计工程师直觉的界面审美、交互手感与视觉修正经验，整理成 AI Agent 可以直接安装、调用和执行的 skill 包、规则集与检查清单。
在本文案例里，它的核心不是“给 AI 一段提示词，让它尽量做得更好看”，而是把“哪里看起来不对、为什么不对、应该怎么改、参数改到多少”写成可抄写、可复用、可审计的执行规则。典型形态就是 make-interfaces-feel-better 这样的可安装 skill，而不是一份静态设计文档。
本文中的语境
本文用 Jakub Krehel 发布的 make-interfaces-feel-better 来说明 Executable Taste 的实际落地方式。该 skill 可通过一行命令安装：
npx skills add jakubkrehel/make-interfaces-feel-better
安装后，可在 Claude Code 或 Cursor 中直接调用 /make-interfaces-feel-better。用户甚至只需说一句“这个界面感觉有点怪”或“这看起来有点怪”，Agent 就会自动套用这套规则检查并修复前端代码。
这正是“可执行品味”的关键特征：把原本只能由专家口头指出的模糊判断，转成 AI 能稳定触发的具体能力。
为什么“感觉不对”很难文档化
这类问题难写进传统文档，是因为它们往往不是功能错误，也不是几何错误，而是“几何上正确、视觉上失衡”。
典型例子是圆角与间距。一个卡片套一个按钮，外层圆角 12px、内层也是 12px，从数值上看没有问题，但视觉上会显得不协调。Jakub Krehel 给出的规则是：外层圆角 = 内层圆角 + 间距。也就是内层 12px、间距 8px 时，外层应为 20px。这类问题很常见，但如果只写“注意层级和圆角协调”，AI 几乎无法稳定执行；只有把它写成明确公式，才具备可操作性。
另一个典型例子是 光学对齐。按钮左右 padding 数值相同，并不意味着人眼感知也居中。图标一侧通常会看起来更重，因此图标侧 padding 应比文字侧少 2px；若是播放三角形这类不对称图标，还要在 SVG 内部继续微调。这里的问题在于，数学中心不等于视觉中心，所以仅靠几何规则无法得到“看起来对”的结果。
也就是说，“感觉不对”之所以难文档化，不是因为它玄学，而是因为它依赖大量细颗粒度、场景化、带参数的视觉修正规则。传统设计说明往往停留在原则层，无法让执行者逐条落地；Executable Taste 则试图把这些隐性判断写成可以照抄的条目。
关键机制：把品味写成可执行规则
Executable Taste 的关键，不是笼统地告诉 AI “做得现代一点”“更精致一点”“更有设计感一点”，而是提供一组可检查、可比对、可修复的规则参数。
本文提到的 make-interfaces-feel-better 将多年设计工程经验拆成了 16 条可执行规则，并且这些规则不是口号式建议，而是带有具体数值、实现方式和反例的检查项。skills 注册表显示其安装量达到 33.0K，并标注 16 项技术点全部审计通过。
这类规则至少包含以下几个层次：
- 问题识别：当前界面哪里“off”。
- 原因解释：为什么几何上没错但观感不对。
- 修复方案：该改哪个属性、用什么实现方式。
- 参数范围：精确到 px、透明度、时长、缩放值等。
- 例外边界：什么场景下不该机械套用。
只有这样，AI 才能把“品味”当成工程约束执行，而不是当成开放式发挥题。
规则包的具体形态
本文强调，Executable Taste 的落地形态不是抽象 prompt，而是“可安装的 skill 包 + 检查清单”。
在 make-interfaces-feel-better 里，规则不仅能在生成代码时使用，也能在 Code Review 时以“常见错误 → 修复方案”的格式输出 Before/After 对比。这说明它更像一个可运行的知识模块，而不是一段一次性提示词。
与传统设计文档相比，这种形态有几个明显差异：
- 可分发：通过安装命令即可在不同开发环境中复用。
- 可版本化：skill 可以持续迭代、增加新细节，而不是文档发出后长期失效。
- 可审计：注册表可显示技术项、通过状态等公开信号。
- 可团队共享：不依赖某个设计师亲自逐页点评，团队成员和 AI 都能调用同一套规则。
- 可嵌入执行流：它直接进入生成、修改、审查代码的过程，而不是停留在阅读层。
这也是本文所说“可执行的品味胜过静态的文档”的含义。传统文档常常“没人读，更没人对着写代码”；skill 包则把知识直接插入实现链路中。
代表性规则与可执行参数
本文列出的多个例子，展示了 Executable Taste 为什么必须依赖具体、可抄写的规则，而不能停留在审美建议层面。
同心圆边框规则
对于嵌套容器，不能让内外层使用相同圆角。更可靠的规则是：外层圆角 = 内层圆角 + 间距。文中示例为内层 12px、间距 8px，则外层应为 20px。作者将其称为最常导致界面“感觉 off”的问题之一。
光学对齐 规则
文字和图标混排时，图标侧 padding 应比文字侧少 2px；如果图标本身不对称，例如播放三角形，还要在 SVG 内部继续微调。这里强调的是视觉修正，而不是数值绝对对称。
用阴影替代硬边框
文中建议使用三层 box-shadow：第一层模拟 1px 边框，第二层制造轻微浮起感，第三层提供环境深度。这样卡片在不同背景上都更自适应；hover 时也只需加深阴影，无需再改边框颜色。这是一条实现策略，不是抽象审美口号。
图标切换动画参数
图标出现或切换时，不要直接切换显示隐藏，而应组合使用：
scale: 0.25 -> 1opacity: 0 -> 1blur: 4px -> 0
如果使用 framer-motion，推荐 spring 动画，且 bounce 必须为 0；若没有 motion 库，则让两个图标同时保留在 DOM 中，用绝对定位加 CSS 交叉淡入淡出。这里的重点在于：规则给的是可以直接照搬的参数与实现路径，因此 AI 才能稳定复现效果。
可打断动画 规则
交互状态变化，如 hover、toggle、开关抽屉，应优先使用 CSS transition，因为它能在用户中途改变意图时被平滑打断和切换方向。固定时间线的 keyframe 动画则更容易出现从头播放或硬切的问题。文中还指出 iOS 大量采用可打断动画，而 web 与桌面端常忽略这个细节。
进入与退出的节奏规则
元素进入时不要整个容器一起滑入，而应拆成标题、描述、按钮等独立块，以 80–100ms 的间隔依次出现。退出时应更轻：用较小的 translateY + opacity + blur 即可，不要整块滑出屏幕；退出时长也应短于进入，因为用户注意力已经转向下一个目标。
其他检查项
文中还列出多条更偏实现层的规则，包括：
- 文字排版使用
text-wrap: balance、pretty、antialiased。 - 数字使用
tabular-nums，减少数字变化引发的布局抖动。 - 图片增加极淡描边，如
outline: 1px solid rgba(0,0,0,0.1)。 - 最小点击区域保证 40×40px。
- 禁止使用
transition: all。 will-change只能谨慎使用。
这些条目共同说明，Executable Taste 不是抽象美学，而是一组跨视觉、排版、交互和实现细节的工程性约束。
工作流价值
本文特别强调这类 skill 的价值，不在于“偶尔帮忙润色一下”，而在于它能贯穿前端工作的多个阶段。
第一，写前端代码时自动套用规则。AI 生成组件、卡片、按钮、弹窗时，可以默认带上圆角层级、阴影、最小点击区域、排版与动画约束，而不只是把功能拼出来。
第二，做 Code Review 时执行审查清单。文中说明每条规则都带“常见错误 → 修复方案”对照表，Agent 审查时可以直接给出 Before/After 修改建议。这让审美经验首次以接近 lint 规则的方式进入审查流程。
第三，补动画时自动使用已有参数。例如图标切换的缩放、透明度、模糊值，进入时的 80–100ms 错开，退出更轻更短，或状态变化优先用可打断 transition。AI 不必凭空猜测，而是直接调用规则包。
因此，Executable Taste 的意义不是让 AI “会审美”，而是让 AI 在开发流程里重复执行一套稳定的界面打磨方法。
与传统设计文档的对比
传统设计文档当然也能写规范，但它常见的问题是：知识停留在页面里，不直接进入实现过程；规范写得原则化，执行时仍要依赖资深人员解释；一旦项目节奏快，很多细节就被跳过。
本文明确把这种 skill 视为第三条路：既不是完全靠个人脑中的经验，也不是把经验静态地放进文档，而是把它封装成 AI Agent 可调用的规则包。
它与传统文档的差异可概括为：
- 文档强调“阅读与理解”，skill 强调“调用与执行”。
- 文档常给原则，skill 更强调参数、示例和修复路径。
- 文档通常难追踪谁真的按规范做了，skill 更容易留下调用、审查和修改痕迹。
- 文档偏向单向发布，skill 更适合团队共享和持续迭代。
因此，Executable Taste 可被理解为设计工程知识的一种软件化、模块化与操作化表达。
分发、版本化与团队协作意义
本文将 npx skills add 视为一种 AI 原生开发中的知识分发机制。就像 npm 让代码库可以安装和复用，skill 则让设计/工程经验也能被安装和复用。
在这个模型下，某位设计工程师的个人品味不再只存在于脑子里，也不再只能通过设计评审口头传递，而可以形成：
- 团队统一使用的默认界面质量基线；
- 可升级的规则版本；
- 可公开传播的专业方法；
- 可被 AI 执行并复核的审查体系。
本文进一步推测，这种模式未来可扩展到无障碍审计、暗色模式迁移、性能预算检查、动画一致性审查等更多垂直 skill。这说明 Executable Taste 不只是一个界面案例，而是一种知识产品形态。
行业判断：AI 编码瓶颈已从功能转向观感质量
本文给出的核心行业判断是：在 AI 辅助编码时代，瓶颈已经不再主要是“能不能把功能生成出来”，而是“默认生成的东西看起来够不够好、用起来顺不顺手”。
很多 AI 产出的前端代码，功能是对的，但观感会显得廉价：圆角不协调、间距不匀、hover 状态缺失、动画生硬、图标切换突兀。这种问题很难靠单次 prompt 泛泛解决，却很适合用 Executable Taste 的方式沉淀为规则包。
所以，本文把 make-interfaces-feel-better 的 33.0K 安装量视为一个信号：开发者正在用安装行为为“更好的默认打磨”投票。哪怕这个数字放在更大的软件生态里不算巨大，放在“设计工程细节”这种极垂直领域，已经足以说明需求真实存在。
细节与边界
Executable Taste 并不意味着界面设计可以被几条规则完全替代，它更适合处理那些高频、可枚举、可参数化的细节问题。
它尤其擅长：
- 几何正确但视觉不顺的微调问题；
- 组件层面的动画、间距、阴影、排版与点击区域问题；
- 可以写成“错误模式 → 修复动作”的审查项；
- 团队希望形成统一默认质量时的基线约束。
但它并不自动等于完整产品设计。品牌调性、信息架构、复杂交互策略、跨页面叙事一致性，仍然需要更高层的人类判断。也就是说，Executable Taste 更像把“界面打磨”中最容易卡住、最难口传、却又最适合工程化的部分执行化。
另外，规则虽可执行，也不能脱离场景机械套用。例如某些图标库本身已做过光学修正，补 2px 前仍需核对；阴影替代边框虽然普遍有效，但也要考虑背景与层级关系；will-change 的使用更涉及性能边界，不能把优化建议当成默认配置无脑开启。
案例中的传播与验证信号
本文用多个公开数据说明这类概念并非纸面设想，而是已有可见的社区验证：
- 2026 年 6 月 21 日，Jakub Krehel 发帖庆祝该 skill 安装量突破 30000 次。
- 文中引用的注册表数据显示为 33.0K installs，16 项技术点审计全 PASS。
- 庆祝帖获得 6600+ 赞、1 万+ 收藏、340 万浏览。
- 对应仓库获得 1.5k+ stars。
- 用户反馈包括“每个前端任务都在用”“一句 this looks off 就能 one shot 修好”等。
这些事实说明，Executable Taste 不是抽象概念展示，而是已经以 skill 产品形态进入真实开发流程，并被反复复用。