posts/design-taste-frontend.md
做网页先定审美，47.96 万人装的 UI Skill 怎么用
做官网最尴尬的时刻，不是页面跑不起来。
是它能跑，甚至有渐变、有动效、有三张整齐的功能卡，可你一眼就知道，这又是一张 AI 默认页面。
现在有个叫 design-taste-frontend 的前端设计 Skill，累计安装 47.96 万次，过去 24 小时还新增约 3,700 次。它背后的 taste-skill 仓库 有 8.71 万 Star。好家伙，大家显然都被默认模板折腾过。
它最有用的地方，不是再塞给模型一包配色和圆角，而是先把一个常被跳过的问题放在代码前面，你到底在为谁做什么页面。
安装就一行：
npx skills add https://github.com/leonxlnx/taste-skill --skill design-taste-frontend它适合落地页、作品集和既有官网改版，不是仪表盘、数据表或多步骤产品后台的万能药。这个边界反而挺重要。拿错工具，再漂亮的规则也只会把错误方向包装得更精致。
先别选紫色，先读 Brief
很多 AI 做页面的路径很短，听到 SaaS 就给一个居中 Hero，听到高级就拿出米白底和黄铜色，听到科技就来一团紫蓝色光。模型没坏，它只是拿到了一个太空的 Brief，只好调用最常见的视觉记忆。
这个 Skill 要求先给出一句 Design Read，也就是把页面类型、受众、气质和设计基础说清。例如，面向技术采购的 B2B SaaS，和给招聘经理看的设计师作品集，都不该从同一张模板起跑。
这是 skills.sh 的真实产品页截图，热度数字与安装命令以页面当日显示为准。
这一步听着很朴素，实际会把后面很多选择拽回正轨。
页面是面向严肃采购的，动效就不能抢内容。已有品牌色和字标的改版，不能假装资产不存在。公共服务或强信任场景，优先级甚至要让给可访问性。厉害了，模型终于不是一上来就写 CSS，而是先交代自己准备做什么。
三个旋钮，专治一套模板走天下
它把设计判断压成三个可以显式写进 Brief 的旋钮。
| 旋钮 | 它在控制什么 | 落地页常用起点 |
|---|---|---|
| 设计变化度 | 对称还是更有构图张力 | 7 |
| 动效强度 | 静态说明还是带节奏的交互 | 6 |
| 视觉密度 | 留白画廊感还是信息更密 | 4 |
这三个值不是审美评分，更像给模型加上限和下限。
一家创意工作室可以把变化度和动效推高，页面需要更大胆的编排。一个开发者作品集则适合收一点，别让动效替项目说话。公共服务页面更该压低变化度和动效，把信息密度和可读性留出来。
把抽象的好看写成可讨论的三项输入，团队才知道该改哪一处。
你可以直接把下面这段塞进给 Coding Agent 的任务里：
页面类型：面向技术买家的 B2B SaaS 落地页
受众：需要快速判断是否值得试用的工程负责人
气质：克制、清楚、有一点工程感
设计变化度：7
动效强度：4
视觉密度：5
约束：首屏必须看见 CTA，移动端不依赖悬浮效果这段 Brief 不会让每个人的页面变好看，但会让讨论从「感觉不对」变成「动效是不是比受众需要的更重」「信息密度是不是被卡片吃掉了」。这才是它能省时间的地方。
它拦住的，正是模型最爱交付的东西
Skill 里有一串很具体的反默认规则。默认不堆紫蓝发光，不把页面拆成三张等宽功能卡，不把每个章节都做成左文右图的之字形，不让所有大标题上面都挂一行小号眉题。
这些都不是绝对禁令。产品真有紫色品牌，当然可以用。内容真只有三个并列能力，三张卡也完全合理。关键是每次都要能讲出原因，别因为模型最熟悉这套结构，就把它当成答案。
还有一条很适合团队项目，碰到 Microsoft、Google、IBM、Shopify、GitHub 或公共服务类界面时，优先接 Fluent、Material、Carbon、Polaris、Primer 或 GOV.UK 的官方系统。不要把官方设计系统的外表手搓一遍，再覆盖掉九成规则。那种操作，维护时是真的会让人沉默。
这里还有一个容易踩的坑。很多人看到设计系统，会立刻把项目里已有的组件全删掉，换一套完整的库。这个 Skill 的原意不是这样。它要你先判断页面属于哪种问题。
如果是在 Shopify Admin 里做功能，Polaris 是约束，不是灵感板。面向公共服务用户，GOV.UK 的可访问性和语言规范比视觉花样更优先。自己掌控的 SaaS 官网，则可以用 Tailwind 和一套克制的组件基础慢慢长出品牌感。
真正省事的顺序是，先选一个能承担场景的系统，再确定要不要偏离它。别一边说采用 Material，一边把颜色、间距、按钮和导航都改成另一种逻辑。代码看起来会有两套口音，设计评审也很难说清哪里不对。
这个判断对产品设计师也有用。你不必把 Brief 写成前端实现文档，只要明确哪些是品牌不可动的资产，哪些是用户必须完成的动作，哪些地方允许更大胆。剩下的技术选择，才有可讨论的边界。
交付前，花两分钟查这几件小事
这个 Skill 的清单很长，我更建议先盯住五项。
- Hero 的标题、说明和主按钮能否在首屏看完，还是要先滚一屏才能找到动作。
- 桌面端按钮文字有没有换成两行，尤其是英文 CTA。
- 选定的强调色有没有从头用到尾，还是第七屏突然冒出另一套蓝绿。
- 深浅背景上的按钮、输入框和帮助文案有没有足够对比度。
- 每个多栏区块在手机上怎么塌下来，别把这个问题留给浏览器祈祷。
前四项是视觉可信度，第五项是产品基本功。很多页面在 1440 像素截图里还挺精神，到了手机上就像行李箱塞不进登机口。棒棒的，最终还是用户替你验收。
它也解决不了所有事。没有真实品牌资产、没有用户场景、没有内容优先级，Skill 只能帮你避开几个常见坑，不能凭空发明一个有辨识度的品牌。官网改版还得先审现有颜色、组件和内容，而不是把旧站删光后重新抽一张漂亮海报。
如果你最近正让 AI 写落地页，不妨先试一次少写代码、多写六行 Brief。页面变好看的第一步，可能不是再加一个渐变，而是让模型别从它最熟悉的默认答案开始。
等第一版出来后，也别只问它能不能再高级一点。拿着三个旋钮回看一次，构图是不是太整齐，动效是不是太抢，信息是不是被留白藏起来了。这样改第二轮，意见会更具体，页面也更容易越改越像自己的产品。
你更想先拿它改一张老官网，还是给下个产品从零做一张落地页？