我先后试过七八种号称能“治好 AI 前端”的玩法——写超长系统提示词、把设计规范塞进项目说明、甚至用代码评审 Agent 二次把关——最后发现效果都不稳定。问题不在于模型能力，而在于大多数人缺了一个东西：taste。所以当我在开源社区刷到这个 8.2 万 Star 的 skill 时，第一反应不是又来了个“花架子”，而是它居然真把“品味”这件极其主观的事情，变成了一套可执行、可复用的规则。
这篇内容我会从“AI 前端 Slop 到底烂在哪”讲起，再拆解这个 skill 的核心原理和规则设计思路，最后给出一套完整的接入和定制方法。适合被 AI 写的页面丑到血压升高的人、正在用 Cursor / Claude / Codex 做前端开发的人，以及所有想搞清楚“AI 写代码为什么总有一股 AI 味”的同学。
1. 先确诊：什么是“AI 前端 Slop”，为什么你一眼就能看出来
Slop 这个词最早用来形容 AI 生成内容里那种“看似合理、实则空洞”的劣质产物。前端 Slop 就是 AI 写出来的页面——功能可能完全正常，代码也能跑通，但视觉、结构、交互细节里透着一股挥之不去的“模板味”。你不需要懂设计，只要看过足够多 AI 生成的页面，就能在 0.5 秒内认出它。
1.1 症状一：布局公式化，万物皆卡片
AI 写前端最常见的套路就是 Flex 居中 + 卡片堆叠。一个大标题居中，下面三张卡片，每张卡片一个图标、一个标题、一行描述，再配一个“了解更多”按钮。你要是让 AI 做一个“产品特性页”，十个模型里有九个会给你输出这种结构。
不是说卡片布局有问题，而是当“卡片+留白+居中”成为唯一答案时，问题就大了。真实的优秀前端是有节奏感的：有时候是错落的分栏，有时候是打破常规的网格，有时候是一张全宽大图直接压到底部。这些需要的是对内容层级、视觉动线的判断力，而判断力恰恰是大模型最稀缺的东西。
1.2 症状二：视觉质感廉价，默认值满天飞
AI 前端 Slop 的第二大特征是“默认值依赖”。颜色用#4F46E5（Indigo）或者#06B6D4（Cyan），圆角用8px或12px，阴影用三层叠加的box-shadow，背景用从#667eea到#764ba2的渐变。
这些数值单个拎出来都还行，但组合在一起就是灾难。就像一个人穿了一身名牌却完全不会搭配，每一件单品都认识，凑一块就是灾难现场。原因也简单：大模型训练数据里出现频率最高的颜色、圆角、阴影值就是这些，采样时概率优先，自然输出平均值。
1.3 症状三：文案和动效里的“AI 腔”
除了视觉，Slop 还体现在细节里。按钮文案永远是“点击开始”“了解更多”“立即体验”；空状态永远是“暂无数据，去看看别的吧”；Toast 提示永远是“操作成功”。动效方面则是凡入场必浮入、凡悬停必上浮，没有缓动曲线、没有节奏差异，所有动画时长都是 0.3 秒。
这些细节单看问题不大，但连在一起就会给用户一种“这个产品没用心做”的直觉。人的审美系统很奇怪，它不一定能说出来哪里不对，但一定会觉得不对。
1.4 症状四：代码层面的一股“AI 腔”
除了视觉，代码结构本身也有 Slop。组件拆得“过度合理”——每个功能都建一个文件，每个文件都只有十来行代码；注释写得像教程——“// 判断是否登录”，明明代码已经表现得很清楚了。命名要么是data、list、item这种万金油，要么是一长串getUserProfileDataWithRetry式的“缝合怪”。
这些代码问题在功能开发时影响不大，但一旦进入维护期就是灾难。而很多 AI 前端 skill 只管“代码规范”不管“视觉品味”，这个 skill 的聪明之处在于它两者都管，而且主攻后者。
2. 为什么“多写几行 Prompt”治不了 Slop，而这个 skill 能
你可能已经试过在 Prompt 里写“设计要美观、现代、高级”这种要求。结果呢？AI 会回你一个更精致的 Slop——深色模式、毛玻璃、渐变光晕，全都来了，但那种“模板感”反而更重。
2.1 根因：大模型在训练阶段就倾向输出“平均值的平均值”
这就要说到大模型的采样机制。模型在做预测时，计算的是“下一个 token 最可能是什么”。在训练数据里，#4F46E5这种颜色出现了成千上万次，而#2B4C3F（一种深松绿）可能只出现几十次。在没有任何额外约束的情况下，模型当然优先选择出现频率更高的值。
这就是所谓“低熵陷阱”：模型的输出总是会向训练数据的众数回归。你越不加约束，它就越倾向于安全、常见、平庸的答案。前端代码的“平均化”是所有领域中表现最明显的，因为前端设计在 GitHub 上的开源模板高度同质化，数据本身就已经是同质化的了。
2.2 关键认知：taste 是可以被“规则化”的
很多人觉得“审美/品味”没法写进代码里，只能意会不能言传。但这个 skill 做了一件反直觉的事：它把 taste 拆成了一组可以执行的负面清单。
什么是负面清单？就是“不要做什么”。与其告诉 AI “要做高级设计”（正面要求，很难量化），不如告诉它“不要使用紫色渐变作为首页主视觉”“不要所有卡片都用相同圆角”“不要使用系统默认字体”……一旦规则足够具体、数量足够多，模型输出的自由度反而被约束到了一个高质量的区间内。
这个思路本质上和“代码 lint 工具”很像：ESLint 不会告诉你代码该怎么写才算优雅，但它能确保你不会犯低级错误。这个 skill 就是前端视觉的 ESLint。
2.3 skill 机制本身的意义：把“一次性 Prompt”变成“可复用资产”
同样一份设计规则，写成 Prompt 你每次都要复制粘贴，而且容易遗漏；写成 skill（比如.claude/skills/frontend-taste/SKILL.md），Claude 会在合适的时机自动加载它，规则就成了模型行为的一部分。
这个 mechanism 的意义在于：它把“调教 AI 写前端”这件事，从“对话技巧”变成了“工程资产”。你写的不是一段话术，而是一份可以被团队共享、被不同项目复用、被版本管理的能力包。这才是 8.2 万 Star 背后的真正价值——不是这个 skill 里的每一条规则有多惊艳，而是它示范了一种更高效的 AI 工作流。
3. 拆解这个 8.2 万 Star skill 的核心规则组
根据我实际打开这个仓库（以及同类的几个高星 skill，比如 codex skill 大礼包和 taste skill）之后的理解，这个项目里最大的亮点是几组规则的设计。我把其中最有价值的几组总结如下，你在自己的 skill 里也可以参考。
3.1 视觉系统规则：色、字、形、迹四个维度
这个 skill 把视觉拆成了四个可检查的维度：
颜色维度的规则包括：禁止直接使用#4F46E5、#06B6D4等 AI 高频色；整站主色不超过两个，且要有明暗两套变体；文本色不能用纯黑#000，要在#111到#333之间选一个带一点点暖的色值。
字体维度的规则包括：不要使用默认字体栈完事，至少要定义--font-display和--font-body两套字体系统；如果使用自定义字体，要有font-display: swap；中文字体要单独指定，不能只写英文通用字体。
形状维度的规则包括：同一组件库中的圆角值必须是预设的 token，不能出现8.5px这种随机值；卡片堆叠不能超过两层，超过就要考虑错位或打破网格。
轨迹（动效）维度的规则包括：所有动效时长不能统一为0.3s，入场动效应该比悬停动效长 50% 左右；缓动曲线优先使用cubic-bezier(0.16, 1, 0.3, 1)而不是ease；动效必须是响应交互的结果，不能页面加载时一窝蜂全飞进来。
这四组规则组合起来，就能把模型从“低频审美区”拽出来。你可能会说：就这几条规则？不够吧。对，所以这个 skill 还配了第二步——正面的引导。
3.2 “先规划、再写码”：让模型扮演设计总监
这个 skill 里有一条非常关键的指令：在动手写代码之前，模型必须先输出一份设计简报，说明这个页面打算用怎样的视觉策略，比如“以大量留白和大号衬线体突出文档感，用一条红色竖线贯穿全局”，模型必须写清楚自己的创意方向。
这一步看着简单，但实际效果巨大。因为大模型的注意力机制决定了它“先说出来的话会影响后面生成的内容”。如果模型先写的是“以卡片为中心、居中布局、使用 Indigo 色”，那后面大概率就是一套标准 Slop；但如果它先写的是“错落网格、细线边框、等宽字体点缀”，后面生成的页面就会有明显的风格化倾向。
它是利用大模型长上下文的自注意力机制，让“设计意图”成为后续所有代码生成的隐式约束条件。这个机制比在 Prompt 里写一万遍“要美观”都管用。
3.3 代码卫生规则：给 AI 的代码瘦身
除了视觉规则，这个 skill 也对代码结构提出了具体要求。其中有一条我记得很清楚：单个组件文件不能超过 200 行。超过就要拆，但拆的时候不允许为拆而拆，必须基于“变更原因”来划分边界，而不是“一个函数一个文件”。
这条规则很精妙。它针对的是 AI 写代码时那种“过度的模块化强迫症”。很多 AI 生成的代码，把简单的数据格式化函数也单独拆出来，导致项目文件数量翻倍但复杂度没降低。这条规则就是反 Slop 的代码版。
另外，它还要求所有依赖的引入必须注明“为什么需要这个依赖”。如果一个图标库只是为了用三个图标，那不如直接写三个 SVG。这条规则直接扼杀了 AI 那种“默认引入 lodash”的行为习惯。
3.4 输入两个文档：让 AI 先“看懂”再动手
这个 skill 还有一个我觉得很聪明的机制：它要求模型在开始写代码前，先读取两个文档——TASTE.md（品味指南，包含项目要传达的视觉气质）和ARCHITECTURE.md（架构说明，包含技术栈约束和目录结构）。如果这两个文档不存在，模型应该先询问需求方，而不是直接开工。
这个设计的巧妙之处在于，它把“用户体验”和“技术选型”两个纬度变成了 AI 的必读输入。AI 第一次生成代码时能感知的信息越多，后续返工的成本就越低。这个 skill 实际上利用的正是“让 AI 把自己当作一个入职第一天但已经读完项目文档的工程师”，而不是“一个只看到需求描述就开始胡编的开发外包”。
4. 接入实操：从安装到跑通一个真实项目
接下来是我实际操作的接入过程。我用的是 Claude Code 配合这个 skill，但它也兼容 Codex 和 Cursor 等支持 Agent Skills 机制的编程工具。
4.1 安装：目录结构和初始化
目前的 skill 机制约定，skill 以目录形式放在项目的.claude/skills/下，每个 skill 目录里至少要有一个SKILL.md文件。这个 8.2 万 Star 的项目提供的是现成的 skill 包，直接拉取之后放到对应目录即可。
我安装时的目录结构大致是这样：
my-vite-project/ ├── .claude/ │ └── skills/ │ ├── frontend-slop/ │ │ ├── SKILL.md │ │ ├── TASTE.md │ │ └── examples/ │ └── taste-skill/ # 可选，与个别 model 一起使用效果更佳 ├── src/ └── index.html安装完成后，第一步是初始化项目的TASTE.md。在这个文件里，你需要描述项目的气质定位。如果你自己不太会写，可以让 AI 提供几个版本，你再挑一个最接近你想法的。不要太长，三五行能说清楚气质就行。
比如我做过一个数据可视化项目，写的是：
产品气质接近彭博终端和 Stripe 的混合体：信息密度可以高，但层级必须清晰；颜色克制，强调用数据和文字本身的力量来传达信息；拒绝任何无意义的装饰性元素。
这句描述很短，但它为后续 AI 的每一个设计决策定了调子。
4.2 实测：同样一个需求，有 skill 和无 skill 的差距
为了验证效果，我用同一个需求分别测了“加 skill”和“不加 skill”两组，需求是做一个加密货币价格追踪页面。
不加 skill 的版本：页面顶部一个居中的大标题，下面三列卡片（BTC、ETH、SOL），每张卡片一张币种图标、一个当前价格、一个涨跌幅徽章。背景是浅灰色，字体用的是默认系统字体。不能说错，但看一眼就关掉了。典型症状是布局公式化、颜色默认、动效缺失。
加了 skill 的版本：设计简报环节 AI 自己提出方案——把整个页面设计成“高密度信息表格”，左对齐、等宽字体展示价格，用红绿底色块（而不是文字徽章）作为涨跌标识，热力图作为背景。主色用的是深墨绿#0F3D2E搭配米白背景，整体居然有一种金融终端的气质。
第二个版本的代码量大约是第一个版本的一点八倍，但每一步设计决策都能在TASTE.md里找到依据。最关键的是，它没有给我堆动画，没有加一些乱跳的 hover 效果，整体是克制的。
这就是这个 skill 最让我惊喜的地方：它不是让 AI “变得更花哨”，而是让 AI “变得更克制”。
4.3 实测中的意外问题：规则过载和上下文消耗
当然，用了这个 skill 也踩了几个坑。最明显的是规则加载会占据大量上下文窗口。SKILL.md 加上 TASTE.md 加上示例代码，将近 6000 字的规则文本会被塞进上下文，在长对话场景下会压缩其他内容的注意力空间。
解决方法是：当项目进入稳定期后，可以删掉 skill 中的 examples 目录，只保留核心 SKILL.md；或者在开发中期手动关闭 skill 的自动加载，改用按需引用的方式。
另一个坑是：某些创意自由度要求高的页面（比如活动落地页），这个 skill 的规则反而会限制发挥。它太强调“克制”了，而对那些需要视觉冲击力的页面来说，克制就是无聊。我的做法是准备两套 skill：一套是默认的 anti-slop，一套是专门给活动页用的 “expressive-mode”，按需切换。
5. 进阶定制：把这套思路内化成你自己的 taste
最后说说怎么把这个 skill 改造成适合你自己项目的形态。毕竟每个项目的调性不同，同一套规则并不普适。
5.1 建立自己的“高频雷点清单”
我在实际使用中做了一个很有效的事情：每次 AI 生成的设计让我皱眉时，我会停下来想想为什么不喜欢，然后把这个原因写成一条规则，追加到项目的TASTE.md里。
比如我加过几条：
- 不要用大面积的灰色渐变作为页面背景，宁愿用纯色或者留白。
- 任何情况都不允许出现 “欢迎回来” 作为登录页文案。
- 卡片边框用
1px solid #E5E7EB的方案不允许，换成更淡的#F3F4F6并配合阴影使用。
这些规则积累多了之后，项目的 AI 生成质量会进入一个正向循环。每次不满意会变成一次“规则补充”，而不是一次“无效返工”。这个思路比任何现成 skill 都重要——它是你真正把 taste 沉淀进工作流的方式。
5.2 和其他 Agent Skill 的组合策略
我目前的生产环境里，同时启用了codex skill（官方大礼包，偏工程规范）和这个前端 anti-slop skill（偏视觉品味），二者并不冲突，反而互补。
codex skill关注的是“代码怎么组织”，比如仓库结构、依赖管理、测试策略；anti-slop skill 关注的是“页面长什么样”。一个管工程质量，一个管用户体验。它们在上下文中的协作方式也很简单：codex skill 主导代码生成流程，anti-slop skill 在进入视觉生成阶段时接管约束。
需要注意的是，不要同时加载超过三个 skill。上下文窗口总是有限的，每多一个 skill 就会稀释模型的注意力。我现在的推荐组合是：一个项目规范类（比如 codex skill）+ 一个审美约束类（比如这个 anti-slop skill），最多再来一个领域专用类（比如图表或表单）。
5.3 写给想自己造 skill 的人
如果你不想直接拿来用，想造一个适合自己的 skill，核心方法论也很简单：从负面清单开始，而不是从正面清单开始。
正面清单的问题是：你很难向机器描述什么是“优雅”“高级”“有质感”。但负面清单很容易写：你不想要什么，你一眼就能判断出来。
所以我的建议是：第一步，把过去三个月里所有让你皱眉的 AI 生成结果截图存下来；第二步，一张图写一条“为什么不喜欢”的规则；第三步，把规则去重、合并、整理成五个以内的类别；第四步，写成一个 50 行以内的SKILL.md文件，测试、迭代。
5.4 心态建议：skill 不是银弹
最后必须提醒一句：任何 skill 都不能替代人工审美判断。它能把 AI 输出从 40 分拉到 75 分，但 75 分到 95 分之间的差距，仍然需要人来把控。
我现在的用法是：让 AI 在 skill 约束下完成初版，然后我花 15 分钟做一次人工调整——改一两个颜色、调整一下间距节奏、改掉一个文案。这 15 分钟的投资回报率极高，因为 AI 生成的基础已经足够扎实，你只需要做提亮和润色。
我自己的体会是，这个 skill 最值钱的部分不是那几条规则，而是它展示了“怎么把主观喜好工程化”这件事是可行的。一旦你掌握了这个思路，你就能把这个 skill 拓展到任何领域——不止前端，包括文档风格、API 设计、甚至代码注释的语气。这才是 8.2 万 Star 背后真正值得学习的东西。
