taste-skill：AI 编程时代，前端开发最缺的不是代码，而是品味
TL;DR
- 场景：AI 编程工具（Codex / Claude Code / Cursor / v0 / Lovable）已能批量生成前端代码，但产出普遍陷入"紫色渐变 + 三列卡片 + 玻璃拟态"的模板化套路，即所谓 AI Slop。
- 结论：AI 前端真正的问题不是丑，而是"默认"——模型在不确定时滑向训练语料的平均值。taste-skill 通过把审美判断沉淀为 Agent Skill（SKILL.md），改变 AI 写页面前的默认脑回路，从而把"生成代码"推进到"生成质量"。
- 产出：一套可在 Codex / Claude Code / Cursor 中复用的反 Slop 前端约束层，包含 Brief 读取、设计方向推断、反模板化清单与交付检查。
版本矩阵
| 功能 | 状态 | 说明 |
|---|---|---|
| Brief 读取与设计方向推断 | ✅ 已验证 | 官方 SKILL.md 明确要求 agent 先读 brief 再生成 |
| 设计系统调用（成熟设计系统） | ✅ 已验证 | 官方支持在合适场景下调用成熟设计系统 |
| 反 Slop 清单（避免紫色渐变 / 三列卡片 / 假 UI 等） | ✅ 已验证 | 项目内置 anti-slop checklist |
| 交付前自检（防 TODO / placeholder / 假数据） | ✅ 已验证 | 预检查与反懒惰规则已写入 SKILL.md |
| 跨工具兼容：Codex / Claude Code / Cursor | ✅ 已验证 | 多篇 2026-06 测评文章确认可移植 |
| 自动产出"有产品气质的视觉" | ⚠️ 待验证 | 受 brief 质量影响，无法凭空生成 |
| 替代专业设计团队 | ⚠️ 待验证 | 官方明确表示不能替代产品设计与用户研究 |
taste-skill：AI 编程时代，前端开发最缺的不是代码，而是品味
为什么 taste-skill 值得关注
AI 编程工具正在把"能不能做出来"这个问题快速推向廉价化。
以前做一个落地页，需要设计稿、切图、组件拆分、响应式适配、动画实现和样式调试。现在只要给 Codex、Claude Code、Cursor、v0 或 Lovable 一段需求，它们很快就能生成一个页面。按钮有了，卡片有了，图标有了，响应式也大概有了。
但问题也随之暴露出来：页面越来越容易生成，也越来越容易长得一样。
一个典型 AI 生成 SaaS 官网，很可能是这样的结构：顶部导航，中间大标题，副标题，两个按钮，下面三张功能卡片，再往下是 Pricing、FAQ、CTA。背景经常是紫色渐变、模糊光斑、玻璃拟态、悬浮卡片。字体安全但无个性，间距规整但没有节奏，动效存在但没有理由。
它不是不能用，而是没有记忆点。它完成了页面，却没有完成表达。
这就是 taste-skill 想解决的问题。
官方把 taste-skill 定位为 Anti-Slop Frontend Framework for AI Agents。这个说法很准确：它不是另一个组件库，而是一套给 AI Agent 使用的前端审美约束层。它让 AI 在生成界面之前，先停止默认套路，先理解 brief，先判断产品气质，先选择设计方向，先规避最常见的 AI 味。
这件事的意义不只是"让网页更好看"。更深一层，它代表 AI 编程从"生成代码"进入"生成质量"的阶段。
AI 前端真正的问题不是丑，而是默认
很多人会把 AI 生成前端的问题概括成"丑"。这个说法不准确。
AI 生成的页面通常并不是真的丑。它们往往挺干净，按钮圆润，卡片整齐，颜色柔和，视觉上没有明显错误。真正的问题是默认。
它不是因为理解了产品才这样设计，而是因为训练语料里大量相似模板都这样设计。它不是选择了紫色渐变，而是滑向了紫色渐变。它不是判断三列卡片适合这个产品，而是因为三列卡片是最安全的输出。
默认不是设计。默认只是模型在不确定时选择的平均值。
这也是为什么大量 AI 生成页面看起来像"演示稿里的产品"，而不像真实产品。它们有完整结构，但缺少动机。每一块都合理，但组合起来没有性格。它们经常用视觉装饰掩盖信息贫乏，用动画掩盖层级混乱，用统一组件掩盖叙事薄弱。
真正的前端质量不是"页面元素都在"，而是每个元素为什么在这里。
标题为什么这样写？CTA 为什么放在这个位置？首屏为什么要这么重？配色为什么要克制？圆角为什么是这个尺度？动效为什么发生在这里？滚动为什么这样展开？
这些判断无法只靠 Tailwind 类名堆出来，也无法只靠组件库解决。
AI 最大的问题不是不会写 CSS，而是它默认不知道什么该避免。
taste-skill 不是组件库，而是审美约束层
很多人看到 taste-skill，可能会误以为它是一个新的 UI 框架，类似 shadcn/ui、Material UI、Ant Design 或 Radix。这个理解不对。
组件库解决的是"元素如何实现"。taste-skill 解决的是"生成时应该遵守什么判断"。
它更像一种 Agent Skill。它不是给你一套现成组件，而是给 AI 编程工具一套行为规则：写前端之前先读 brief；根据产品类型、受众、语气和品牌资产推断设计方向；根据不同场景选择布局密度、动效强度和视觉变化；必要时使用成熟设计系统；避免 AI 生成界面里最常见的模板化痕迹。
这比组件库更靠上层。
普通 prompt 是一次性的。你可以在对话里告诉 AI：“不要做得太 AI 味”“设计得高级一点”“不要三张卡片”“动效自然一点”。但这些要求太模糊，也太容易在长任务中丢失。
Skill 则把偏好、约束、禁用项和检查清单沉淀成可复用上下文。它让 AI 每次处理前端任务时，都能自动加载同一套审美标准。
换句话说，taste-skill 不是帮你写一个页面，而是改变 AI 写页面时的默认脑回路。
为什么"品味"突然变成核心技能
过去的软件工程里，最硬的能力是实现能力。你能不能写出功能，能不能调通接口，能不能解决性能问题，能不能把系统稳定上线。
这些能力仍然重要，但 AI 正在快速压低它们的边际稀缺性。
当 AI 能生成代码，能补全样式，能修复 bug，能读文档，能跑测试，能改组件，工程师的角色会自然上移。你不再只是生产代码的人，你开始变成定义标准、分配任务、审查结果、判断方向的人。
这时，真正稀缺的是判断。
什么值得做，什么不值得做。什么能上线，什么只是看起来能上线。什么是好设计，什么只是模板。什么是产品表达，什么是视觉噪音。什么是可维护组件，什么是一次性堆砌。什么是清晰信息架构，什么是漂亮但无用的装饰。
这些判断合在一起，就是 taste。
taste 不是玄学，也不是"我喜欢所以好"。真正的品味是一种经过长期训练的压缩能力。它能把大量经验压缩成快速判断：这里太满了，那里没有层级，这个按钮不该这么抢，这个动效没有服务任务，这个布局不像 B2B 工具，更像设计作品集。
AI 可以生成大量候选项，但它不会自动知道哪个最适合你的产品目标。至少在当前阶段，AI 更像执行器和扩展器，而人必须承担方向盘的角色。
所以 taste-skill 的出现很合理。既然 AI 能快速生成大量前端，下一步最重要的不是继续提高生成速度，而是提高筛选标准和输出约束。
没有品味的 AI 编程，只会把低质量页面从"手写低质量"升级成"高速生成低质量"。
它解决的是前端 AI Slop
AI Slop 可以理解为 AI 批量生产出来的低辨识度内容。它不一定错误，但廉价、模板化、缺少意图、缺少上下文。
放在前端里，AI Slop 有几个典型特征。
第一，结构高度同质化。首屏大标题加副标题加两个按钮，下方三列功能卡片，再下方客户评价和价格表。所有产品都像同一个 SaaS 模板换了文案。
第二，视觉元素没有真实功能。渐变光斑、漂浮标签、假仪表盘、假终端、假任务列表大量出现，只是为了让页面看起来"有科技感"，但并不承载真实信息。
第三，动效没有设计目的。滚动时淡入、卡片上浮、按钮 hover，所有东西都在动，但没有形成叙事节奏，也没有帮助用户理解信息。
第四，配色和形状缺少一致性。前面是温和中性色，后面突然出现蓝色 CTA；一块是大圆角，一块是胶囊按钮，一块又变成锐利边框。页面不是一个系统，而是一组拼贴。
第五，文案也有 AI 味。比如大量抽象词：“释放潜能”“重新定义体验”“面向未来”“赋能团队”。这些词单独看都没错，但组合起来没有具体含义。
taste-skill 的反模板化清单，本质上是在对这些 AI Slop 痕迹做截断。它要求 AI 避免常见套路，避免无意义装饰，避免三等分卡片默认布局，避免不必要的滚动提示，避免假产品 UI，避免一眼 AI 的紫色网格渐变。
这不是形式主义。禁用清单的价值在于，它让 AI 不再走最低阻力路径。
优秀设计很多时候不是"加什么"，而是"不加什么"。不加多余装饰，不加无意义状态点，不加伪高级的编号眉标，不加不服务内容的动效，不加为了填充画面而生成的假 UI。
AI 缺少这种克制，所以需要规则替它克制。
从 prompt 到 Skill：AI 工作流正在工程化
早期使用 AI 编程，很多人依赖 prompt。写一段长提示词，告诉模型项目技术栈、代码风格、UI 风格、不要做什么、要注意什么。短任务可以有效，但长期项目很快失控。
原因很简单：prompt 是临时指令，不是工程资产。
一个项目真正需要的是稳定规则。比如：所有页面使用同一套圆角系统；暗色模式不能纯黑；首屏 CTA 必须可见；重设计不能悄悄改 URL 结构；表单字段名不能随便换；组件不能留下 TODO；不要用假数据伪装完成；不要为了视觉效果引入不可维护的滚动监听。
这些规则不应该每次重复口述，而应该沉淀到项目中，成为 AI Agent 的工作边界。
这就是 Skill 的意义。Skill 把经验变成文件，把偏好变成规则，把审查标准变成上下文。它让 AI 不只是"听你这次怎么说"，而是"在这个项目里一直按这套标准工作"。
对独立开发者尤其重要。独立开发者通常没有完整设计团队、前端团队、QA 团队和代码评审流程。AI 可以补足执行力，但如果没有规则，AI 也会放大混乱。taste-skill 这类项目的价值，就是让个人开发者也能拥有一层轻量审美审查机制。
它不会让你立刻变成优秀设计师，但能降低最常见的错误率。它不保证每个页面都惊艳，但能减少默认模板。它不替代设计系统，但能在没有设计系统时提供最低限度的方向约束。
这就是 AI 时代工具进化的方向：不是只要更强模型，而是需要更好的上下文、更稳定的规则、更工程化的审查。
对 Codex、Claude Code、Cursor 的实际价值
在 Codex、Claude Code、Cursor 这类工具里，AI 的能力已经足够写出大量前端代码。真正的问题变成：如何让它不要乱写，如何让它保持一致，如何让它知道当前任务的边界。
taste-skill 的实际价值主要体现在四个方面。
第一，减少返工。没有约束时，AI 经常先生成一个看起来完整但风格普通的页面，然后你再不断追问：“高级一点”“不要这么模板”“卡片不要三列”“颜色换一下”“首屏太满了”。Skill 把这些要求前置，减少低级返工。
第二，提高一致性。一个项目如果分多次让 AI 改页面，很容易出现风格漂移。今天圆角 12px，明天 24px；今天主色是蓝色，明天变紫色；今天是极简，明天又变成玻璃拟态。taste-skill 的一致性锁能强制 AI 维护色彩、形状、主题和组件语气。
第三，提升审查意识。AI 很容易为了"完成任务"而输出半成品，比如 placeholder、TODO、假 UI、未接真实数据的组件。Skill 里的预检查和反懒惰规则，能让 AI 在交付前主动检查是否真的完成。
第四，形成设计语言。一个产品不是靠单个页面建立质感，而是靠持续一致的设计语言。字体、间距、色彩、圆角、动效、信息密度、组件语气，这些东西一旦稳定，产品就会有自己的识别度。
对程序员来说，这类工具还有一个隐性价值：它会训练你的审美注意力。
你以前可能只关注"功能能不能跑"。用了 taste-skill 之后，你会开始注意：为什么三列卡片很廉价？为什么假仪表盘会降低可信度？为什么首屏 CTA 必须不用滚动就看到？为什么主题不能中途跳变？为什么暗色模式不能纯黑？
这些规则本身就是一种审美教育。
独立开发者怎么用
对独立开发者来说，taste-skill 最适合用在三类场景。
第一类是个人产品官网。比如工具站、SaaS、开源项目、API 服务，需要快速做 landing page。AI 很容易生成一套普通模板，taste-skill 可以帮你在首屏、布局、配色和组件节奏上提升一个档次。
第二类是已有项目改版。很多网站长期迭代后会变得混乱：旧页面、旧组件、旧颜色、旧间距混在一起。直接让 AI 重构风险很高，因为它可能悄悄改导航、改字段、改结构。taste-skill 的 redesign 思路强调先审计，再判断保留还是重做，这对真实项目更安全。
第三类是内容型工具站。工具站常见问题是功能可用，但页面廉价。它们不需要复杂视觉，但需要清晰层级、稳定布局、可信感和低干扰体验。taste-skill 的克制规则比花哨模板更适合这类页面。
实际工作流可以很简单：
- 先写 brief，不要只写"帮我美化页面"。
- 让 AI 先出设计判断，而不是直接写代码。
- 再让 AI 实现，要求它复用现有结构，不引入无意义依赖。
- 最后人工审查首屏、移动端、CTA、文案、暗色模式和是否还有 AI 味。
这套流程比"直接让 AI 写页面"慢一点，但最终更快。因为少了大量返工，少了风格漂移，也少了上线后再推倒重来的成本。
它不是万能药
taste-skill 不能替代真正的产品设计。
它能减少 AI 味，但不能自动产生深刻的产品理解。它能限制常见坏习惯，但不能保证业务表达准确。它能提升视觉一致性，但不能替你完成用户研究、信息架构、品牌策略、转化路径和可用性测试。
如果 brief 本身很空，输出依然会空。你只写"做一个高级的 AI 工具官网"，AI 仍然只能围绕抽象词生成。taste-skill 可以阻止一部分模板化，但不能凭空知道你的用户是谁、痛点是什么、产品差异在哪里、核心转化动作是什么。
所以它的正确用法不是"安装后让 AI 自由发挥"，而是"用更清楚的 brief 驱动更有约束的生成"。
另外，taste-skill 的审美规则也不是绝对真理。紫色不是原罪，三列卡片不是永远不能用，装饰性视觉也不是必然低级。问题不在元素本身，而在是否有明确动机。
taste-skill 更适合作为默认约束，而不是最终裁判。它帮你挡住 80% 的低级模板，但最后仍然需要人判断：这个页面是否符合产品，是否清晰，是否可信，是否有记忆点，是否服务转化。
我的判断
taste-skill 最有价值的地方，不只是它提供了一套前端规则，而是它展示了一种新的 AI 协作方法：把隐性判断显性化，把审美经验规则化，把交付标准工程化。
这套方法可以迁移到很多领域。写博客可以有 writing-skill，做 SEO 可以有 seo-skill，做后端可以有 architecture-skill，做 Agent 可以有 agent-skill。
核心逻辑都是一样的：AI 时代真正的资产，不只是代码，而是你的判断系统。
你越能把自己的判断系统写成规则，AI 就越能放大你。你没有判断系统，AI 只会放大平均值。你有清晰标准，AI 才能成为执行力。你没有清晰标准，AI 只会成为噪音制造机。
taste-skill 是一个前端项目，但它背后的趋势比前端更大。
过去，程序员最重要的是会写。现在，程序员越来越需要会看。看出哪里不对，看出哪里平庸，看出哪里只是完成了形式但没有完成目标。
未来，AI 会继续提高生成能力，但人的价值不会自然消失。人的价值会从"亲手生产每一行代码"，转向"定义什么值得生产，判断什么可以留下"。
真正的核心能力，不是让 AI 多写一点，而是让 AI 少写那些不该写的东西。
这就是品味。
参考资料
- taste-skill 官方站点
- taste-skill GitHub
错误速查卡
| 症状 | 根因 | 定位 | 修复 |
|---|---|---|---|
| AI 生成的落地页千篇一律（紫色渐变 + 三列卡片 + 玻璃拟态） | 模型在不确定时滑向训练语料的平均值，缺少审美约束 | 检查 brief 是否明确产品气质、受众、避免项 | 接入 taste-skill，在 prompt 前置"读 brief → 推断设计方向 → 反 Slop 清单" |
| 同一项目多次 AI 改版后风格漂移（圆角、配色、组件语气不一致） | 缺少可复用的项目级规则上下文 | 对比两次改版的圆角 / 颜色 token / 组件风格 | 用 Skill 把设计系统（圆角、间距、配色、字体）固化为可加载规则 |
| 页面里有 placeholder、TODO、假仪表盘、假终端 | AI 为"完成任务"而输出半成品 | 在交付前 grepTODO|placeholder|Lorem|fake等关键字 | 启用 taste-skill 的预检查与反懒惰规则，要求交付前自检 |
| 让 AI 改版后导航 / 字段 / URL 悄悄变化 | 重构任务边界不清，AI 自主扩大改动范围 | 对照改版前后的路由与表单字段 diff | 强制要求"先审计，再判断保留还是重做"，明确禁止改 URL 与字段名 |
| 暗色模式下页面纯黑或颜色跳变 | 主题 token 缺失或被中途覆盖 | 用浏览器 DevTools 切换 prefers-color-scheme，对比颜色值 | 在 Skill 里规定暗色模式色板，禁止中途切换主题 |
| 动效堆砌（滚动淡入 / 卡片上浮 / hover 全开） | 动效没有服务信息层级 | 录屏回看动效是否形成叙事节奏 | 约束动效只为强化层级与转化，移除无目的的过渡 |
| 抽象词堆砌（释放潜能 / 重新定义体验 / 赋能团队） | 文案缺少具体业务语境 | 通读首屏、Pricing、FAQ 三处核心文案 | 在 brief 里写明用户画像、痛点、转化动作，让 AI 用具体词替换抽象词 |
| 装上 taste-skill 之后输出仍然空泛 | brief 本身就空，Skill 只是约束层不是生成器 | 检查 brief 是否包含：产品类型 / 用户 / 痛点 / 差异点 / 转化动作 | 升级 brief 模板，再让 AI 跑一次设计判断 |
作者：武子康的个人博客
