构建或编辑任何 UI 时，用反 AI 套路规则消除默认渐变…

在构建或编辑网站、Web 应用、仪表盘或任何界面时，与 antislop.md 核心一起使用，审查颜色、布局、组件、装饰、结构流程、App 状态和动效，避免一眼 AI 生成感。

适用场景

解决思路

1. 当任务是构建或编辑网站、Web 应用或任何界面时，将本技能与 antislop.md 一起加载；核心提供机制（purpose test、three tiers、Delivery Gate），本技能提供 UI/视觉深度。
2. 每个 UI 问题按 Tell（模式）、Why（为何像 slop）、Fix（替代做法）记录，并引用核心规则编号 R-XX，不重复或重新编号核心规则。
3. 把核心中的 Delivery Gate 作为最终门槛，并在 UI 任务中同时运行文末的 UI Skill Checklist 作为 UI 特定补充。
4. 遇到蓝紫、蓝青或紫粉渐变作为主色处理，或全页彩色光晕时：从 DESIGN.md 或产品自身品牌身份取调色板；只有渐变承担层级功能并写下理由时才保留渐变；禁止把强/彩虹渐变、紫黑配色、霓虹/粉彩、hero 后方模糊径向光球作为无目的默认。
5. 遇到 navbar、cards、modals、sidebar 同时使用 blur/backdrop-filter 时：把玻璃效果当强调而非特征；剂量上限最多 1-2 个元素；需要吸引注意的表面用玻璃，其余保持实色。
6. 遇到按钮、输入、卡片、徽章、模态都做成 pill 形时：在设计系统中设定一小组圆角并有意应用；只在主 CTA 使用一个大圆角可读作有意，所有元素同一圆角则像默认。
7. 遇到每个组件都带大阴影导致整页漂浮时：阴影只作为 elevation 标记并写下 elevation 理由；大多数元素应平放，只有一两个需要高出页面的元素带阴影。
8. 遇到 cards、buttons、icons、badges、backgrounds、borders 同时发光时：把 glow 保留给最多 1-2 个重要元素作为焦点强调；其余保持哑光。
9. 遇到内容后面有网格方块、蓝图线、方格纸、点阵或重复细线时：只有在纹理/图案真正支持产品身份并写下理由时才用；优先使用真实身份 motif，而不是库存网格。
10. 遇到无品牌理由的整页暗色模式时：根据品牌身份、产品类型和受众选择主题；开发者/创意工具有合理暗色理由，内容优先产品通常没有；如果没有固定主题的强理由，构建可用的 light/dark toggle。
11. 遇到一页 5-7 种颜色且无清晰设计系统时：活跃调色板上限 2-3 个核心色 + 1 个强调色，让一个核心色作为中性基底；用克制让强调色落地。
12. 遇到同一强调色出现在按钮、图标、徽章、链接、线条、背景和 glow 上时：强调色只在关键时刻使用；一个有意强调色最好；零强调色会无菌，处处强调色是 slop；选择一两个真正重要的位置。
13. 遇到平白/近白、细灰边框、小圆角、无纹理、通用字体、无身份的 sterile 默认时：这是方向问题不是过滤问题；添加 DESIGN.md 或完成 Design Read，然后提高 liveliness dials；不要增加更多禁令，而是陈述目的并加入能量。
14. 遇到 hero、subtitle、2 CTA、screenshot、feature grid、testimonials、FAQ、CTA、footer 的固定模板时：围绕实际内容需求构建结构；没有 testimonials 就不要该 section；section 顺序跟随产品故事；匹配 RHYTHM dial，如果为 3，section 要明显变化。
15. 遇到所有 feature cards 尺寸、高度、图标、布局、padding 完全一致时：创建反映内容层级的差异并写下理由；不是每个 feature 都要做成 card；旗舰 feature 可全宽，辅助 feature 可用列表。
16. 遇到用不同尺寸卡片拼成 bento grid、部分跨两列或两行、像仪表盘铺满时：只在内容真的有不同尺寸元素要展示时使用 bento；如果每个单元格大致相同，用简单 grid 或 list 更诚实；由 RHYTHM dial 决定 section 是否变化。
17. 遇到 padding、margin、gap 在每个 section 完全相同、间距统一时：把 whitespace 当结构，并按 RHYTHM dial 变化；建立 spacing scale，用不同层级分隔和连接；只有 dial 允许时才用统一节奏。
18. 遇到 How It Works 永远是圆形图标 + 数字 1、2、3 + 短文的三步时：按真实流程呈现过程；如果真实就是三步圆形图标也可以，否则用真实工作流形状，包括两步或五步。
19. 遇到 hero 下方一排通用公司 logo 的 Trusted By 时：只展示真实、可验证的 logo；如果还没有这类客户，不要伪造 logo bar；真实社会证明胜过通用。
20. 遇到中间定价档总用胶囊徽章高亮 Most Popular 时：高亮真正服务产品目标的档位并写下原因；如果没有档位值得强调，就不高亮。
21. 遇到无论真实结构如何都把 pricing 做成三列且中间高亮时：使用产品真实拥有的档位数，并高亮服务产品的那个档位；三列加中间高亮是默认，不是决策。
22. 遇到页面售卖从未展示可运行的产品、没有真实 demo、没有 Terms of Service、没有 Privacy Policy、只有承诺时：展示真实产品运行，或诚实说明尚未发布；如果页面要求注册或付款，Terms of Service 和 Privacy Policy 必须存在；诚实的 coming soon 胜过有说服力的 demo。
23. 遇到 Product / Company / Resources / Legal 四列无变化模板 footer 时：按产品实际链接内容构建 footer；单列链接可能比四个半空列更有用。
24. 遇到每个 section 都是居中标题 + 副标题 + 相同卡片网格、无变化时：按 RHYTHM dial 变化构图；交替文本重/视觉重、非对称/对称布局；每个 section 同模板的页面就是模板设计的页面。
25. 遇到 sparkle、star、magic、lightning、diamond、cube、robot 或 AI orb 作为 feature 图标时：使用与内容真正相关的图标，并在图标通用时写下相关性；如果没有合适图标，就不用图标，让 feature label 承担表达。
26. 遇到所有图标来自同一细描边、圆角库（Lucide 或视觉克隆）导致统一库外观时：图标集是视觉选择不是默认；先按相关性选图标，再决定该库的 weight 和 stroke 是否适合产品性格；两个看起来相似的图标只要整套是决策而非导入，仍可读作你的。
27. 遇到 copy、headings、badges、buttons 中散落 literal emoji（标题 🚀、每条 feature 旁 ✅、CTA 上 🔥、图表标题上方 📈）时：从 UI 文本中移除 emoji；如果概念需要标记，使用真实相关图标并写下理由，或完全不用标记；让文案承载含义。
28. 遇到几乎每个按钮都放 → 或 ↗ 作为纯装饰时：箭头不是按钮的默认身份；只保留给真正受益于方向提示的动作，按比例调整大小并写下目的。
29. 遇到卡片、列表行、section 标题左边缘有细彩色竖条作为装饰时：竖条是装饰，必须携带信息否则去掉；标记真实状态（active、warning、new）的左边缘是信号；仅为看起来经过设计的竖条是默认。
30. 遇到胶囊形、细边框、glow、小点、大写、含 AI Powered、Beta、New 的徽章时：只在功能需要时使用 badge，写下需要，并绝不用完整组合；真实状态标签可以，装饰性 AI Powered pill 不可以。
31. 遇到 H1 正上方小 pill，常带点和细边框，包含标题下已说的分类标签时：删掉它，让 headline 做工作；如果该标签携带 headline 没有的信息，把它折进 headline 或 subheadline，使其读作内容而非装饰；fold 上方的 badge 需要像其他 badge 一样写下理由，其中的点需要真实状态可标记。
32. 遇到 heading、eyebrow、nav item 或 label 旁小彩色点，通常发光并无尽脉动，却不标记任何状态时：点必须标记真实状态（active、live、recording、warning）；如果是，保留一个点，去掉 glow，去掉无尽脉动；如果不标记任何东西，移除它；heading 不需要 indicator 才是 heading。
33. 遇到大号 monospace 标题，或大写标签配极端 letter-spacing（HOW IT WORKS、FEATURES）时：根据品牌性格选择 typeface，而非模型默认，并写下理由；字体必须提升可读性并反映产品；有理由的字体选择胜过趋势。
34. 遇到默认字体 roster：sans 用 Inter、Geist、Space Grotesk；mono 用 Geist Mono、JetBrains Mono、Fira Code 时：它们都不被禁止，但每个都需要品牌理由；出现因为它是默认而不是因为它合适，就是 tell。
35. 遇到带 traffic-light 点、prompt 行和打字命令的 styled terminal window 作为 hero 或 feature visual 时：如果产品真的是 terminal 或 CLI，真实可工作的截图是证据；否则展示实际产品 UI，不要 costume；monospace 作为 aesthetic 已由 R-06 覆盖，fake terminal 是该模式的组件化。
36. 遇到 Undraw、Storyset 或通用 3D blob 角色且与产品无真实连接时：插画必须与产品有直接连接并写下连接；如果没有，使用真实截图或不用插画。
37. 遇到 navbar 链接到不存在的页面或 section 时：每个 navigation item 必须有真实目的地；如果功能未构建，省略它，或清楚标 Coming soon；navbar 反映实际存在的内容。
38. 遇到按钮无反应、下拉打不开、表单不能提交时：每个交互元素必须有真实行为，否则移除；如果元素确实不能有目的地，交付清晰 `// TODO` 加可见 Coming soon 标签，或不要上线。
39. 遇到 section 存在只是因为每个 AI landing page 都有，而不是内容需要时：每个 section 必须从产品内容赢得位置；移除只为填充模板的 section；更少但有目的的 section 比包含所有默认 section 的页面更强。
40. 遇到左 sidebar、top bar、四个 stat cards、一个 chart、一个 table 的默认 dashboard shell，且无论管理发票、患者还是服务器都一样时：命名屏幕的工作和用户在该屏幕做的一个决策，围绕它构建层级；如果工作是发现失败 job 并重试，失败 job 是页面，stat row 是脚注；只因为 dashboard 通常有而保留的 section 要删。
41. 遇到一排四张卡片显示 12,483 / 94.2% / $48.2K / 1,204，每张带绿色 +12% this week delta 的发明数字时：显示真实数字或没有；把卡片接到真实数据，或只交付一个真实 metric；只有比较周期真实且命名时 delta 才出现；如果屏幕是 prototype，在用户可见处标注数值为 placeholder。
42. 遇到 Sarah Chen updated a document, 2 hours ago 这种轮换名字和头像的填充 activity feed 时：feed 展示真实事件或不上线；诚实 empty state 胜过伪造 feed，并告诉用户先做什么。
43. 遇到因为空间空而放 line 或 donut chart，标题通用（Overview、Performance），没有读者可行动的 axis 时：画图前写下 chart 要回答的问题，并把问题放进标题（Failed jobs per hour, last 24h）；如果一句话能更好回答，就写句子；chart segments 仍需与相邻色有 3:1 对比。
44. 遇到 Name、Status、Date、Actions 等通用表格列，每行有三点菜单，无论行实际是什么时：从用户在此表要做的决策选择列，把决定字段放前面；行菜单只放存在的动作，不起作用的移出。
45. 遇到空表单字段和表格列填充像 John Doe、johndoe@example.com、Let's build something、不属于任何人的电话和日期这种假但合理数据时：空单元格保持空，或用明确说明放什么的 placeholder：Your Name、email@example.com、Drop your message here... 或值预期时用 [REAL DATA]；真实数据存在时才放入；像 Let's build something 的通用填充文案是 buzzword slop，不属于数据列。
46. 遇到 No data available 加插画、裸 spinner，或模拟真实数据从不会填满的布局的全页 skeleton 这类 placeholder empty/loading states 时：empty state 说明为什么为空并给出填充它的一个动作（No jobs yet. Run a sync to see results here）；loading state 说明正在加载什么；error state 说明什么失败以及下一步做什么；首次运行、过滤为空、权限拒绝是不同屏幕，读法不同。
47. 遇到元素永远 pulse、bounce、float 且无用户触发时：motion 必须有清晰 UX 目的并写下；动画引导注意到某个时刻，不循环；如果 MOTION dial 是 1（仅 hover states），无尽循环违反声明 dial，判 FAIL。
48. 遇到每个元素同时使用 Fade Up + Fade In + Floating + Scale + Bounce 的模板动画堆叠时：按目的和 MOTION dial 编排 motion；不是所有东西都动；hero 说话，支持元素保持安静；声称 cinematic 的页面必须真的动，声称 static 的页面必须不动。
49. 运行 UI Skill Checklist，所有答案必须为 yes：调色板来自 DESIGN.md 或写下的品牌身份，不是默认渐变集。
50. 检查强调色只在关键时刻使用，不散布到每个元素。
51. 检查文案没有装饰性 emoji 散落在标题、项目符号和按钮中。
52. 检查 section 构图按声明的 RHYTHM dial 变化，而不是重复一个模板。
53. 检查布局没有默认 AI 形状：bento-grid mosaic、fake terminal window、three pricing columns、无意义的左边缘色条。
54. 检查 H1 上方没有 pill badge 承载 headline 已说的标签。
55. 检查每个 navigation item 和 interactive element 都有真实目的地或行为，或有可见 Coming soon 标签。
56. 检查 motion 遵循声明的 MOTION dial 并服务写下的目的，没有无尽循环。
57. 检查 glass、glow、shadow、radius 使用在剂量上限内，不是页面级默认。
58. 检查每个彩色点和状态灯都标记真实状态，没有装饰性 glow 或无尽 pulse。
59. 在 app 屏幕上，检查布局围绕用户在该屏做的决策，而不是 sidebar + stat row + chart + table 默认。
60. 检查每个数字、delta、feed entry、table row 都是真实或标注 placeholder，没有发明 metrics。
61. 检查空表单字段和表格单元格保持为空或带诚实 placeholder（Your Name、email@example.com），而不是假数据（John Doe、johndoe@example.com）。
62. 检查 empty、loading、error states 说明原因和下一步动作，而不是只说 No data。
63. 检查页面在每个 breakpoint、theme、state 都成立，并通过 keyboard-only 使用。

适用边界 · 注意事项

• 非 UI/视觉任务（纯后端、数据管道、CLI 逻辑等）不需要加载本技能。
• 如果项目已有明确、经过验证且不依赖 AI 默认套路的品牌设计系统，不要为了反套路而强行替换，把它当审查清单而非重写指令。
• 如果任务只是明确标注的内部占位原型，仍可参考这些规则，但不要把它当成面向用户生产界面的同等发布门槛。