Taste Skill 的作用是给 AI 前端生成增加布局、字体、密度和交互上的审美约束。安装它时，最重要的是让客户端能发现 SKILL.md，并让项目任务真正触发该 Skill，而不是只把文件下载到任意目录。
安装前先读 SKILL.md
先查看 Skill 的名称、说明、适用任务和引用资源。把它当作工作流说明，不是可以随意复制到页面里的提示词。完整背景可看 Taste Skill 怎么用。
放置位置的原则
Claude Code、Codex 与不同桌面/CLI 版本的 Skills 发现目录可能不同，因此应以你正在使用的客户端文档和设置为准。一般有两种范围：
- 用户级目录：多个项目都能复用，适合通用设计约束。
- 项目级目录：只对当前仓库生效，适合品牌、组件库和设计系统相关约束。
复制时保留完整 Skill 目录结构，包括 SKILL.md 和它引用的 references、模板或脚本。只复制一个 Markdown 文件，可能导致引用资源找不到。
如何验证已被发现
重启或重新打开客户端后，检查其可用 Skills 列表、启动日志或任务说明。接着用一个小页面测试，例如“为已有表单调整信息层级和间距”，并明确要求遵循 Taste Skill。若输出仍完全忽略设计约束，先检查名称、目录和前置条件，而不是立即扩大提示词。
一个安全的迭代方式
- 用现有页面或小组件做试验，不直接重写整站 UI。
- 先约束一个维度，例如排版密度或按钮层级。
- 通过截图、设计规范或现有组件验收结果。
- 确认稳定后再扩展到动画、颜色和响应式细节。
Taste Skill 不能替代产品需求、无障碍要求和真实设计审核。它负责减少“模板感”，不保证页面自动符合品牌或业务目标。
若你准备编写自己的团队 Skill，可结合 Codex Skills 工作流写法整理可复用的触发条件和验收清单。
总结
安装 Taste Skill 的关键是正确目录、完整资源和可验证调用。先小范围试用，再把稳定的设计约束沉淀到项目级工作流，效果通常更可靠。
安装前检查清单
在复制之前，确认该 Skill 的来源可信、许可证满足项目要求、引用资源都能读取。一个可用的 Skill 至少应有清晰的名称与用途说明；如果它要求图片、模板或脚本，目录结构必须一起保留。不要只把 README 内容复制到项目里，就假设客户端能发现它。
对于用户级安装，适合“所有前端项目都希望减少模板感”的通用约束；对于项目级安装，适合绑定已有设计系统、颜色 token、组件目录和验收方式。团队项目优先使用项目级版本，并通过 Git 评审变更。
让任务真正触发 Taste Skill
Skill 被发现不代表每个任务都会使用它。写任务时应同时给出页面目标、保留范围和视觉约束，例如“保留现有组件 API，只调整信息层级、间距和移动端密度”。如果只说“做得好看”，模型缺少可验证标准，任何 Skill 都难以稳定发挥。
还可以把验收条件写进任务：
- 不改变关键交互和表单字段；
- 标题、正文、辅助信息的层级可区分；
- 窄屏下不出现横向溢出；
- 颜色对比、焦点状态和按钮文字仍可访问；
- 不新增未经审查的大型依赖。
一个前端改造示例
假设页面有标题、两段说明、一个搜索框和一组结果卡片。第一轮只要求调整阅读顺序和留白；第二轮再处理卡片密度和状态色；第三轮检查 320px 到桌面宽度。每轮只改一小块，并使用实际内容而不是空白占位符截图验收。
这种做法比“把整页重做成高级设计”更适合生产项目：差异小、回滚容易，也能看出 Taste Skill 的规则是否与现有组件库冲突。
常见失败原因
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| 客户端看不到 Skill | 目录或元数据不符合发现规则 | 核对客户端设置和 SKILL.md |
| 输出变化很小 | 任务没有触发条件或约束不明确 | 明确要求采用该 Skill 与验收项 |
| 输出破坏组件 | Skill 与项目规范冲突 | 增加“保留 API/仅改样式”限制 |
| 每次风格不同 | 缺少设计 token 和参考 | 在项目级资源中补充规范 |
FAQ：Taste Skill 能替代设计师吗？
不能。它可以让 AI 更好地遵守审美和版式约束，但品牌策略、内容优先级、无障碍和用户研究仍需由团队判断。
FAQ：可以和其他 Skill 一起用吗？
可以，但职责要分开：一个负责设计约束，一个负责测试、可访问性或框架规范。避免多个 Skill 同时重写同一层规则。