frontend-craft

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Frontend Craft

前端精细化设计

AI-generated frontends look alike because models reach for statistically safe defaults: the same fonts, the same purple CTA, the same three identical feature cards. People recognize the result instantly and call it slop. This skill is the countermeasure.
Three facts drive everything below.
Slop is the absence of decisions, not a particular style. Every visual choice should be one you can explain in terms of this product and this audience. A choice you cannot explain is a default someone else set.
The tells migrate. The 2022 default was purple gradients, glassmorphism, and neon glows on near-black. The 2026 default is warm cream, an editorial serif, and tasteful restraint. Both read as generated for the same reason: nobody decided. Avoiding a fixed list is not the goal. Deciding is.
Density is the signal. Automated slop detectors score a page by counting tells: 1-2 is treated as a pass, 3-4 reads as templated, 5 or more is heavy slop. One purple button is not a crime. A purple button plus glass cards plus a stat row plus an eyebrow pill plus a FAQ accordion is a template.
AI生成的前端千篇一律,因为模型会选择统计上安全的默认选项:相同的字体、相同的紫色CTA、相同的三张功能卡片。人们一眼就能认出这种结果,并称之为slop。本技能就是应对这种情况的对策。
以下所有内容都基于三个事实。
Slop是缺乏决策的产物,而非特定风格。 每一个视觉选择都应该能结合产品和受众给出解释。无法解释的选择就是他人设定的默认选项。
识别特征会不断变化。 2022年的默认特征是紫色渐变、毛玻璃效果和近黑色背景上的霓虹光效。2026年的默认特征是暖米色、衬线排版和克制的风格。两者都会被识别为AI生成,原因相同:没有人为之做出决策。我们的目标不是避开固定的特征列表,而是主动做出决策。
特征密度是判断信号。 自动化slop检测工具会通过统计特征数量给页面打分:1-2个特征视为合格,3-4个特征看起来像模板,5个及以上则属于重度slop。一个紫色按钮不算问题,但紫色按钮+毛玻璃卡片+统计数据行+眉形标签+FAQ折叠面板就是模板化设计。

Workflow

工作流程

Two entry points, same rules underneath. A blank page needs a direction decided from scratch; a live codebase already has one (good, bad, or accidental) that has to be found before it can be fixed. Pick the path that matches the task.
有两个切入点,底层规则一致。空白页面需要从头确定设计方向;已有的代码库已经有了一套设计(好的、坏的或偶然形成的),需要先找到这套设计才能进行修复。选择与任务匹配的路径。

Building from scratch

从零开始构建

1. Read the brief

1. 研读需求 brief

Work out three things before any code:
  • Purpose and audience. Who uses this, to do what? A procurement panel, a design-conscious consumer, and a developer skimming docs need different things. The audience picks the aesthetic, not your taste.
  • Surface type. Brand surface (landing page, portfolio, campaign): the impression is the product, so distinctive type and bold moves earn their keep. Product surface (app UI, dashboard, admin): design serves the task, so density, semantic states, and repeatable components matter more than flourish. Landing-page decoration on a dashboard is its own kind of slop.
  • Constraints. Existing brand assets, framework, accessibility needs, regulated or trust-first contexts (government, finance, health). These override aesthetic preference.
在编写任何代码前,先明确三件事:
  • 用途与受众。 谁会使用这个产品,用来做什么?采购小组、注重设计的消费者和浏览文档的开发者有不同的需求。受众决定审美,而非你的个人喜好。
  • 界面类型。 品牌界面(着陆页、作品集、活动页面):印象就是产品本身,独特的排版和大胆的设计是合理的。产品界面(应用UI、仪表盘、后台):设计为任务服务,因此密度、语义状态和可复用组件比装饰更重要。在仪表盘上使用着陆页的装饰风格本身就是一种slop。
  • 约束条件。 现有品牌资产、框架、可访问性需求、受监管或注重信任的场景(政府、金融、医疗)。这些条件优先于审美偏好。

2. Commit to a direction and say it

2. 确定并明确设计方向

Before writing code, state the direction in one or two sentences: the aesthetic, the typeface, the palette anchor, and one thing you are deliberately avoiding. For example: "Developer-tool landing page for a technical audience: IBM Plex Mono paired with a grotesque, paper-white background, one saturated signal color, dense and editorial. No gradients, no glass."
Stating it forces a real decision and makes the choice inspectable. If the brief genuinely splits between two directions, ask one question. Otherwise decide and proceed.
Draw the direction from the product's own world: a terminal, a lab notebook, a transit map, a specific era, an IDE theme, a cultural aesthetic. Not from "SaaS landing page" as a genre. And vary between generations: if your last design was cream-and-serif editorial, reaching for it again is the same reflex as reaching for purple.
编写代码前,用一两句话说明设计方向:审美风格、字体、主色调,以及刻意避开的一个元素。例如:“面向技术受众的开发者工具着陆页:IBM Plex Mono搭配无衬线字体,纸白色背景,一种饱和的标志性颜色,排版紧凑且具有编辑感。不使用渐变,不使用毛玻璃效果。”
明确设计方向能迫使你做出真实决策,也让选择可被检验。如果需求brief确实存在两个方向的分歧,就提出一个问题来确认。否则就做出决定并推进。
从产品自身的场景中汲取设计灵感:终端、实验记录本、交通地图、特定时代风格、IDE主题、文化审美。不要从“SaaS着陆页”这类通用品类中找灵感。还要注意风格轮换:如果你的上一个设计是米色+衬线的编辑风格,再次选择这种风格就和选择紫色一样是惯性行为。

3. Define the system before the pages

3. 先定义系统,再设计页面

Set tokens as CSS variables first: palette, type scale, spacing scale, radius scale, shadow scale. Consistent tokens read as intent; ad hoc values read as generated. Read
references/design-foundations.md
for how to build each scale and the visual principles behind them (hierarchy, balance, contrast, Gestalt grouping).
首先将设计标记设置为CSS变量:调色板、字体层级、间距层级、圆角层级、阴影层级。一致的标记体现设计意图;临时设置的值看起来像AI生成的。阅读
references/design-foundations.md
了解如何构建每个层级及其背后的视觉原则(层级、平衡、对比、格式塔分组)。

4. Implement with craft

4. 精细化实现

Interfaces succeed because of hundreds of small choices: focus states, hit targets, loading timing, form behavior, motion physics. Read
references/craft-checklist.md
before building anything interactive and treat it as the implementation bar.
界面的成功源于数百个微小的选择:焦点状态、点击区域、加载时机、表单行为、动效物理特性。在构建任何交互元素前阅读
references/craft-checklist.md
,并以此作为实现标准。

5. Audit before delivering

5. 交付前审计

Sweep the result against
references/slop-tells.md
and the quick check below. Then check the things code never shows you: you do not see your own render, so composition bugs (borders dying at rounded corners, non-concentric nested radii, monotone spacing) are invisible in source and glaring on screen. If you can render a screenshot, look at it. Subtract before you polish: slop is what piles up, so remove elements until everything left has to be there.
对照
references/slop-tells.md
和下面的快速检查清单检查结果。还要检查代码无法显示的问题:你看不到自己的渲染效果,因此构图问题(圆角处边框断裂、非同心嵌套圆角、单调的间距)在源码中不可见,但在屏幕上十分显眼。如果能生成截图,就查看截图。在优化前先做减法:slop是堆积出来的,所以移除元素直到剩下的所有内容都是必需的。

Unslopping an existing frontend

整改现有前端

Different failure mode than a blank canvas: there is already a live codebase with real content, real functionality, and existing patterns, some deliberate and some accidental. A full rebuild wastes the parts that already work and risks breaking what does. Work with what's there instead of replacing it.
与空白画布不同,现有代码库已有真实内容、真实功能和现有模式,有些是刻意设计的,有些是偶然形成的。完全重建会浪费已有的有效部分,还可能破坏正常功能。要利用现有内容,而非全盘替换。

1. Inventory before touching anything

1. 先梳理现有内容,再进行修改

Find the existing tokens (CSS variables, Tailwind config, theme file), the component library, and whatever conventions are already in use. Read enough to know which pattern is dominant, so a fix reinforces it instead of forking a second design language next to the first.
找到现有的设计标记(CSS变量、Tailwind配置、主题文件)、组件库和已有的任何约定。充分了解主导模式,确保修复能强化现有模式,而非在原有设计语言旁新增一套。

2. Audit against the same catalog, screen by screen

2. 逐屏对照相同清单进行审计

Sweep each screen against
references/slop-tells.md
and the quick tell check below. For a product surface (app, dashboard), also run
references/craft-checklist.md
: a live UI's problem is as often broken focus states, inconsistent hit targets, or missing loading states as it is a visual tell. Render it; don't just read the JSX or CSS, since composition bugs and tell density are invisible in source. List concrete hits (file, line, what it is), not general impressions, and count density per screen: 1-2 is fine, 5+ marks that screen as the priority.
逐屏对照
references/slop-tells.md
和下面的快速检查清单检查。对于产品界面(应用、仪表盘),还要运行
references/craft-checklist.md
:现有UI的问题往往是焦点状态损坏、点击区域不一致或缺少加载状态,而非视觉特征问题。渲染界面;不要只阅读JSX或CSS,因为构图问题和特征密度在源码中不可见。列出具体问题(文件、行号、问题内容),而非笼统的印象,并统计每屏的特征密度:1-2个没问题,5个及以上的屏幕是优先整改对象。

3. Diagnose the shape of the problem before fixing it

3. 先诊断问题类型,再进行修复

Usually one of:
  • A real direction exists but is applied inconsistently (three different card radii, two icon styles, a spacing scale that's almost followed). The common case: extend and enforce what's already there. Do not replace it with a new direction.
  • No real direction exists — the "system" is untouched framework defaults (default Tailwind palette, Inter, default shadow scale) applied everywhere. This is effectively a fresh call, so apply "Commit to a direction" and "Define the system" above, but retrofit the result onto the existing structure rather than rewriting the codebase around it.
  • Both at once. Fix one dimension at a time (color, then type, then spacing) rather than redeciding everything in a single sweeping edit.
通常分为以下几种情况:
  • 存在明确的设计方向,但应用不一致(三种不同的卡片圆角、两种图标样式、几乎被遵守的间距层级)。常见处理方式:扩展并强化现有设计方向,不要替换为新方向。
  • 没有明确的设计方向——“系统”是未修改的框架默认值(默认Tailwind调色板、Inter字体、默认阴影层级),且被应用到所有地方。这相当于重新决策,因此应用上面的“确定设计方向”和“定义系统”步骤,但要将结果适配到现有结构上,而非围绕新设计重写代码库。
  • 两种情况同时存在。一次只修复一个维度(色彩、然后排版、然后间距),而非一次性重新决定所有内容。

4. Fix at the root, not per instance

4. 从根源修复,而非逐个实例修改

If the same purple sits on twelve buttons, change the variable once, not twelve class names. Consolidate scattered ad hoc values into the token scale that already exists; only add a new token when the fix genuinely needs one.
如果12个按钮都使用相同的紫色,只需修改一次变量,而非修改12个类名。将零散的临时值整合到已有的标记层级中;只有当修复确实需要时才添加新标记。

5. Match the blast radius to the ask

5. 修复范围与需求匹配

"This card looks off" means fix that card and its siblings, not the app. "This looks generic, make it better" at the page or app level justifies a fuller pass. Don't turn a targeted fix into a redesign, and don't touch copy, structure, or functionality that wasn't part of the complaint.
“这个卡片看起来不对劲”意味着修复这个卡片及其同类,而非整个应用。“这个看起来太通用了,让它更好一些”针对页面或应用级别的需求,才需要更全面的整改。不要将针对性修复变成重新设计,也不要修改不属于需求范围内的文案、结构或功能。

6. Re-audit and verify nothing broke

6. 重新审计,确保没有破坏原有功能

Re-run the tell check on what changed. Confirm existing behavior, responsive breakpoints, and any tests still pass — a de-slop pass that regresses functionality is not a win.
重新检查修改后的内容是否符合特征清单。确认现有行为、响应式断点和所有测试仍然通过——如果整改导致功能退化,那就不算成功。

Rules by dimension

各维度规则

Typography. Pick the typeface the way you would pick a logo: deliberately, for this product, and be able to say why. Never default to Inter, Roboto, Arial, Open Sans, Lato, or system sans. Also do not "fix" that by grabbing the current trend rotation (Space Grotesk, Instrument Serif, Fraunces, Geist, Syne): those are good faces that became tells precisely because every generator reaches for them. Pair with contrast (display plus mono, serif plus geometric sans) and use extremes: weights 100-200 against 800-900 beat 400 against 600, display sizes 3x body beat 1.5x. Keep one voice per headline: no single word swapped to an italic serif or a different color. Body text at least 16px, line height 1.4-1.65, lines 45-75 characters.
Color. Commit to one palette and encode it in CSS variables. Dominant color plus a sharp accent beats an evenly distributed rainbow. Derive semantic colors (success, error, warning) from your palette instead of stock Tailwind blue/amber/green/red boxes. Text is always a solid color, never gradient-clipped. Meet contrast floors (4.5:1 body, 3:1 large text), temper pure black on pure white, and never encode meaning in color alone. Dark themes must be earned by the context, not the default, and dark-theme body text needs to stay readable, around 7:1, not mid-grey on black.
Layout and hierarchy. One thing is the most important thing: make it unmistakably biggest and place it deliberately. Use at most 3 sizes per composition and 2-3 type sizes for hierarchy. Group by proximity: related elements tight, unrelated groups far apart, with real jumps in the spacing scale. One shared gap everywhere means nothing belongs to anything. One surface per region: no cards inside cards, group with spacing and hairline dividers instead. Reading order must match visual order.
Components and effects. Decoration must carry information. An icon, badge, glow, callout, or glass panel earns its place by meaning something, or it goes. Keep one small radius scale and nest radii concentrically (inner radius = outer radius minus the gap). Shadows are neutral, layered, and smaller than the element casting them; a tinted glow is not depth. Put border and border-radius on the same element so the stroke follows the arc.
Motion. Motion is information: animate to show cause and effect, not to decorate. Transition only the properties that change (opacity, transform, color) at 120-200ms with an ease-out curve; never
transition: all
, and save springs for things that physically move. One well-orchestrated entrance with staggered reveals beats scattered hover tricks. Honor
prefers-reduced-motion
.
Copy. Specific beats loud. Real numbers are odd and checkable ("cuts build time 38%"); invented ones repeat everywhere ("10K+ users, 99.9% uptime, 24/7"). Ban the AI cadence: "It's not just X, it's Y", "Say goodbye to", punchy triads, buzzwords (streamline, empower, supercharge, world-class, enterprise-grade). No emoji as decoration. Error messages state the fix, not just the failure.
排版。 选择字体就像选择Logo:要结合产品刻意选择,并能说明原因。绝不要默认使用Inter、Roboto、Arial、Open Sans、Lato或系统无衬线字体。也不要用当前流行字体(Space Grotesk、Instrument Serif、Fraunces、Geist、Syne)来“修正”问题:这些字体本身不错,但正是因为每个AI生成器都会选择它们,才成为了识别特征。使用对比搭配(展示字体等宽字体、衬线字体几何无衬线字体),并使用极端值:100-200字重搭配800-900字重比400搭配600效果更好,展示字体大小为正文字体的3倍比1.5倍效果更好。每个标题保持一种风格:不要将单个单词换成斜体衬线字体或不同颜色。正文字体至少16px,行高1.4-1.65,每行45-75个字符。
色彩。 确定一套调色板,并将其编码为CSS变量。主色调搭配鲜明的强调色比均匀分布的彩虹色效果更好。从你的调色板中衍生语义颜色(成功、错误、警告),而非使用默认的Tailwind蓝/琥珀/绿/红框。文本始终使用纯色,不要使用渐变裁剪。满足对比度要求(正文4.5:1,大文本3:1),避免纯白纯黑对比,绝不要仅用颜色传递信息。深色主题必须符合场景需求,而非默认选项,且深色主题的正文字体需要保持可读性,对比度约为7:1,不要使用黑底灰字。
布局与层级。 有且只有一个最重要的元素:让它明显最大,并放置在合适的位置。每个构图最多使用3个尺寸,层级最多使用2-3种字体大小。通过邻近性分组:相关元素间距紧凑,不相关组间距较大,使用间距层级中的明显差值。所有元素使用相同间距意味着没有元素属于任何分组。每个区域使用一个界面:不要在卡片内嵌套卡片,而是用间距和细边框分组。阅读顺序必须与视觉顺序一致。
组件与效果。 装饰必须承载信息。图标、徽章、光效、标注或毛玻璃面板只有在有意义时才存在,否则就移除。使用一套统一的小圆角层级,并确保嵌套圆角同心(内圆角=外圆角-间距)。阴影是中性的、分层的,且比投射阴影的元素小;有色光效不是深度。将边框和圆角设置在同一个元素上,使边框跟随弧线。
动效。 动效是信息:用动画展示因果关系,而非装饰。只对变化的属性(透明度、变换、颜色)设置120-200ms的过渡,使用ease-out曲线;绝不要使用
transition: all
,只对物理移动的元素使用弹簧动画。一次精心编排的入场动画(带交错显示)比零散的悬停效果更好。尊重
prefers-reduced-motion
设置。
文案。 具体胜于空洞。真实的数字是奇数且可验证的(“减少38%的构建时间”);虚构的数字随处可见(“10K+用户、99.9%正常运行时间、24/7服务”)。禁止AI式语气:“这不只是X,更是Y”、“告别”、空洞的三连词、流行词(简化、赋能、升级、世界级、企业级)。不要用表情符号装饰。错误信息要说明解决方法,而非仅指出问题。

Quick tell check

快速特征检查清单

Frequencies from a deterministic scan of 1,590 Show HN landing pages. Run this list against every page you produce:
  1. Gradient backgrounds or gradient-clipped headline text (30% of sites)
  2. Permanent dark theme with muted grey body text (30%)
  3. One hero word set apart in a serif italic, second font, or accent color (22%)
  4. Numbered 1-2-3 "how it works" step cards (21%)
  5. Pill badge or uppercase eyebrow floating above the H1 (21%)
  6. Generic FAQ accordion at the bottom of the page (21%)
  7. Centered hero set in Inter or a generic system sans (19%)
  8. Trend display font as page default: Space Grotesk, Instrument Serif, Fraunces, Geist, Syne (12%)
  9. Glassmorphism panels as decoration (12%)
  10. Saturated colored glow box-shadows (7%)
  11. Indigo/violet default accent on CTAs (7%)
  12. Colored stripe on a card's left or top edge (6%, but called "almost as reliable a sign of AI design as em dashes in text")
  13. Invented stat banner row (6%)
  14. Emoji as nav or feature icons (3%)
A hit is not automatically a failure. It is a prompt to ask: did I choose this for a reason I can say out loud? If yes, keep it. If it is there because that is what landing pages look like, cut it. Full catalog with fixes:
references/slop-tells.md
.
基于对1590个Show HN着陆页的确定性扫描得出的特征出现频率。在交付每个页面前对照此清单检查:
  1. 渐变背景或渐变裁剪的标题文本(30%的网站)
  2. 永久深色主题搭配灰色正文(30%)
  3. 单个英雄词使用斜体衬线字体、第二种字体或强调色突出显示(22%)
  4. 编号为1-2-3的“工作原理”步骤卡片(21%)
  5. H1上方的标签徽章或大写眉形文本(21%)
  6. 页面底部的通用FAQ折叠面板(21%)
  7. 使用Inter或通用系统无衬线字体的居中英雄区(19%)
  8. 将流行展示字体设为页面默认:Space Grotesk、Instrument Serif、Fraunces、Geist、Syne(12%)
  9. 作为装饰的毛玻璃面板(12%)
  10. 饱和色发光阴影(7%)
  11. 靛蓝/紫色作为CTA的默认强调色(7%)
  12. 卡片左侧或顶部的彩色条纹(6%,被称为“几乎和文本中的破折号一样可靠的AI设计标志”)
  13. 虚构的统计数据横幅行(6%)
  14. 用表情符号作为导航或功能图标(3%)
出现特征并不一定意味着失败。它只是提醒你问自己:我选择这个元素是有明确原因的吗?如果是,就保留它;如果只是因为着陆页都这样,就删掉它。包含修复方案的完整清单:
references/slop-tells.md

References

参考资料

  • references/slop-tells.md
    : the full merged catalog of AI-design tells with fixes, organized by category. Read it for the pre-delivery audit and whenever asked to de-slop an existing design.
  • references/craft-checklist.md
    : interaction, form, motion, content, accessibility, and performance rules with exact values. Read it before implementing interactive UI, and as an audit checklist when unslopping an existing product surface.
  • references/design-foundations.md
    : visual design principles and how to build the type, color, spacing, and motion systems. Read it when establishing the design system for anything new, or reconstructing one that's missing or applied inconsistently in an existing codebase.
  • references/slop-tells.md
    :按类别整理的AI设计特征完整清单及修复方案。交付前审计或被要求整改现有设计时阅读。
  • references/craft-checklist.md
    :交互、表单、动效、内容、可访问性和性能规则,包含具体数值。实现交互UI前阅读,整改现有产品界面时作为审计清单使用。
  • references/design-foundations.md
    :视觉设计原则,以及如何构建字体、色彩、间距和动效系统。为新项目建立设计系统,或重构现有代码库中缺失或应用不一致的设计系统时阅读。