AI 前端页面有一种熟悉的“油腻感”：圆角卡片堆满屏幕，标题像宣传语，图像只负责装饰，按钮没有真实动作。taste-skill 的 anti-slop 规则不是审美口号，它把这些常见坏习惯写成禁区，让 Agent 在生成界面时先避开廉价感。

anti-slop 管的是什么

Docs 里有一组 Anti-Slop Ban System，直接点名禁用 em dash、章节编号眉题、hero 版本标签、把图片署名当装饰等做法。它背后的判断是：页面要像真实产品，不像 AI 为了显得完整而塞进去的拼贴。失败场景也很明显，如果业务确实需要版本标签或摄影署名，就要在 brief 里说明原因，不能让规则机械覆盖事实。

为什么这些规则有用

前端审美不是只看颜色。一个 B2B 工具页需要密度、扫描性和清楚层级；一个作品集页面需要人物和作品先出现；一个 AI 工具官网需要把输入、输出、成功状态讲明。taste-skill 通过规则逼 Agent 先问页面属于哪类，再决定布局。没有这个步骤，Agent 很容易把所有站点都做成同一种 hero 加三I张卡片。

README 里的使用重点

GitHub README 强调 taste-skill 面向 Cursor、Claude Code、Codex、Gemini CLI、v0、Lovable 等 Agent，核心不是生成花哨 UI，而是阻止 boring generic slop。使用时最好把约束写进 prompt：产品类型、目标用户、首屏动作、必须避开的视觉套路。只写“做得高级一点”，Agent 仍然会走模板。

适合前端审查吗

适合，但要用在正确阶段。第一轮生成后，可以让 Agent 按 taste-skill 检查首屏、按钮、文案、图片、组件层级。它特别适合发现“看着还行但没有重点”的页面。它不适合替代人工品牌判断，比如某个行业为什么必须保守，某个产品为什么要强调可信度，这些仍要靠 brief。

我会把 anti-slop 当成一次审稿清单：先截首屏，再逐项问是否存在无意义渐变、孤立图标、空泛价值主张、重复卡片和不必要动效。发现问题后让 Agent 改具体块，而不是让它“整体更高级”。后者太宽，通常只会换颜色、加阴影。

我的审稿方式

它还有一个好处：让设计讨论变得可复盘。团队不再只说“像 AI 做的”，而是能指出违反了哪条页面纪律，比如 CTA 不可见、导航太高、hero 文案过长。规则越具体，返工越少。

我通常还会看一个移动端截屏。很多模板味在桌面端被大留白盖住，到了手机上就暴露出来：标题换行太长、按钮挤在一起、卡片一张接一张像信息流。anti-slop 规则若只在桌面验收，容易漏掉这些问题，也容易误判页面已经合格。

我会把页面分成四个点看：首屏有没有明确任务，是否有无关装饰，组件是否重复，移动端是否还能读。每个问题都要落到具体元素，例如按钮、导航、标题、图片比例。taste-skill 的价值就在这里，它让审美讨论从“好不好看”变成“哪里像模板，哪里阻碍操作”。