前端 Skill 不是越多越好，这四个还经常互相打架

同一个前端页面，先后交给四个 Skill，会发生什么？

答案并不是越来越好看。

更常见的场面是，一个让你把留白拉大，一个让你把信息密度补回来，一个嫌三张卡片太像 AI 模板，另一个打开浏览器后冷冷告诉你，移动端已经横向滚出屏幕了。

好家伙，四位设计总监坐一桌了。

为了写这篇，我把本机 Claude Code 的安装记录和历史任务翻了一遍。真正反复出现在前端工作里的，大致是四类东西，frontend-design、ui-ux-pro-max、design-taste-frontend，再加一个负责浏览器验收的 playwright-cli。

它们都和前端有关，却完全不是同一种药。

Claude Code 的官方文档里有个很关键的细节，Skill 被调用后，完整内容会进入当前会话。多装几个没什么，多调用几个可就不一样了。每份 Skill 都带着自己的偏好、检查项和上下文成本。描述互相重叠时，Claude 还可能加载错，或者在几套规则之间摇摆。

所以我现在的判断很直接，Skill 不是滤镜，不能指望一层层叠上去就自动高级。它更像工位，得先分工，再开工。

frontend-design 负责把方向定得足够狠

我最早用得比较多的是 Anthropic 的 frontend-design。它解决的不是按钮圆角该用 8 还是 12，而是页面为什么看起来像模板，以及这个产品到底该长成什么样。

它会逼着 Claude 先把产品、受众和页面唯一任务钉住，再从题材自己的材料里找设计语言。金融产品可以从研报、行情纸带、精密刻度和票据里找秩序，音乐产品可以从唱片、波形和舞台灯光里找记忆点。比起又来一套深色背景加紫色渐变，这个思路确实有点子牛逼。

我实际拿它改过金融研报工作区。中间是 Markdown 报告展示区，已有预览、编辑和导出，功能不能动，只想把长文本的专业感拉起来。另一次是充值页，金额和计费明细用了 tabular-nums，让数字像表格一样对齐；大阴影被换成 1px 细线；支付中的反馈也从大遮罩改成按钮内部的轻量进度。

这种任务很适合它。功能已经在，页面缺的是一句清楚的审美判断。

我的调用方式通常不会只写一句「帮我变好看」，而是把四件事塞进同一份 brief。

/frontend-design
页面任务，用户要在这里完成什么
保留项，哪些功能、路由和数据逻辑不能动
视觉方向，给参考图、品牌词和明确禁区
验收项，桌面端、移动端、键盘操作和截图都要过

它不好用的地方，也来自这股狠劲。

我有一轮改金融 SaaS 的 landing 页，先让它围绕雕塑背景、数据卡片和金融权威感重建骨架。做完一版，页面还是被我打回去了，太空，太白，中间没有视觉桥梁。后来又把搜索框找回来，把散落卡片收成一组，再压低蓝色占比。

这事我也踩过坑。方向型 Skill 最怕 brief 只有形容词。 你只给「高级」「炫酷」「有质感」，它会认真地替你发明一个世界，可那个世界不一定是你的产品。

参考图、现有品牌资产、必须保留的主路径、页面里最重要的一个动作，最好一次交代清楚。否则它不是没能力，而是能力太足，跑偏时也能跑得很漂亮。

ui-ux-pro-max 负责把模糊的不舒服翻成检查项

frontend-design 像创意总监，ui-ux-pro-max 更像拿着清单进场的设计系统审查员。

我在 Next.js、Tailwind CSS、shadcn/ui 的金融分析 SaaS 里用过它做微优化。当时的要求很明确，不大面积重构，只做 review + improve。先生成一份金融 SaaS 设计系统基准，然后按优先级去看 focus、对比度、键盘导航、prefers-reduced-motion、正文行宽、移动端字号、hover 过渡、响应式断点、z-index、Next Image 和 Canvas 动画降级。

它最擅长解决那种很磨人的反馈，页面不算丑，但就是不够专业。

这句话交给自由发挥的模型，往往会换一套颜色、加一层玻璃、再给卡片补点阴影。交给 ui-ux-pro-max，它至少会问更具体的问题。普通文字对比度有没有到 4.5 比 1，按钮异步时有没有禁用，移动端正文是不是小于 16px，动画是不是在改 width 和 height，低端设备有没有降级。

先生成设计系统，再按领域补查，是我觉得比较稳的用法。

python3 .claude/skills/ui-ux-pro-max/scripts/search.py \
  "fintech financial analysis SaaS professional" \
  --design-system -p "Project"

python3 .claude/skills/ui-ux-pro-max/scripts/search.py \
  "animation accessibility reduced-motion focus-ring" \
  --domain ux

然后在 prompt 里加一句，只输出实际需要改动的项，按严重程度排序，已经做对的别复读。

不加这句，麻烦就来了。

它的知识库很大，建议也很多。一个只想修三个按钮的任务，很容易被扩成一场无障碍、性能、动画、字体、图表和暗色模式的全身体检。厉害了，按钮还没改，体检报告先写了两页。

更现实的坑是版本与项目会冲突。我本机这份 Skill 的部分流程一度写着项目只用 React Native，可我眼前明明是 Next.js。Skill 终究是说明书，不是项目事实。package.json、现有组件库、设计 token 和仓库规则，优先级必须更高。

所以我现在只把它当审查器。范围先钉死，技术栈先钉死，允许改什么也钉死。它负责把「不舒服」翻译成能检查的项，不负责趁机把整个产品重做一遍。

design-taste-frontend 专门追杀那股 AI 模板味

如果一个页面功能没问题，规范也没明显硬伤，可你看一眼就知道是模型做的，我会想到 design-taste-frontend。

它对 AI 默认审美下手很重。紫色渐变、居中 Hero、三张等宽功能卡、满屏玻璃拟态、每段都来一个小标签、没有理由的无限动画，这些熟悉得像同一个装修队干遍全城的东西，它基本都盯着。

它还有三个旋钮，布局变化、动画强度、信息密度。这个设计挺聪明，因为「高级」不是一个固定皮肤。面向采购的 B2B 页面，和面向年轻用户的创意产品，不该共享同一个动效强度。作品集可以大胆一点，公共服务页就该老老实实把信任和可访问性放前面。

我实际把它用在管理员后台、Agent 库首页、业务详情页和多视频界面。回头看，最有价值的经验反而是，别把它到处用。

它自己的说明写得很坦率，主场是 landing、作品集和品牌型页面，不是密集 dashboard、数据表、多步骤表单。可我当时确实把它往后台里塞过。页面一旦追求大留白、强构图和视觉签名，业务信息就可能被挤走。操作台被改得像宣传页，看着挺贵，干活费劲。

这一下给我整明白了。

复杂后台里，我只借它做三件事，审查明显的 AI 套路，刷新字体与间距，检查现有品牌有没有被模型顺手洗掉。表格、筛选、批量操作、审批流程和字段顺序，交给成熟组件库和产品规则。它不该拥有这些东西的最终解释权。

安装倒是简单。

npx skills add https://github.com/Leonxlnx/taste-skill \
  --skill design-taste-frontend

真正的代价是上下文。这份 Skill 非常长，规则密度也高。一旦整份加载，模型容易盯着视觉禁令，忘了业务按钮不能少。任务越复杂，越要把路由、字段、埋点、已有图标库和不能修改的数据逻辑写在最前面。

说真的，品味规则再强，也不能替产品约束签字。

playwright-cli 负责把所有漂亮话拉回浏览器

前面三个 Skill 都有同一个盲区，它们很容易在代码层宣布完成。

组件写了，lint 过了，类型也没报错。棒棒的。

然后你打开页面，弹窗被 sticky header 盖住，按钮在 375px 宽度下折成两行，登录后的跳转丢了，暗色模式里次要文字几乎消失。前端最诚实的评委从来不是代码，是浏览器。

所以我把 Microsoft 的 playwright-cli 也算进前端 Skill 组合里。它能让 Claude 打开页面、拿元素快照、输入、点击、截图，还能把一段实际操作固化成测试。

我用它跑过一个本地金融分析页面。打开 home，没有登录就先完成登录，再点进一份行业研究报告。这个场景看着普通，却能同时验掉鉴权、导航、列表点击和详情页渲染。比「请检查页面是否正常」有用太多。

npm install -g @playwright/cli@latest
playwright-cli install --skills

playwright-cli open http://127.0.0.1:3002/home --headed
playwright-cli snapshot
playwright-cli screenshot

这里有个我真踩过的坑。playwright-cli 默认 headless，也就是不弹可见浏览器。我当时看别人演示会弹页面，自己这边没看到，还以为技能没工作。想看过程就显式加 --headed，别靠猜。

另一个坑更朴素。它会产生 .playwright-cli 之类的会话或临时内容，截图、快照和状态文件很容易混进仓库。需要的产物单独留，不需要的加入忽略。持久化登录态也一样，Cookie 和存储状态千万别顺手提交。

它也不能替你判断审美。快照很适合找元素和跑流程，页面到底有没有呼吸感，还是要看截图。我的做法是让它跑主路径，再固定几个视口截图，桌面端、375px 移动端、暗色模式各看一遍。

到这一步，前端工作才算从「代码看起来能跑」走到了「用户真的能用」。

我现在只让一个 Skill 当主驾驶

四个东西放在一起，我现在通常这样排。

新页面或大改，先让 frontend-design 定方向。产品任务、用户、品牌资产、参考图、保留项和禁区都写清楚。它给出视觉主张，但先别急着把全站改完。

方向稳定后，让 ui-ux-pro-max 做检查。只挑当前任务相关的 accessibility、responsive、interaction 和 performance，别把知识库整桶倒进来。

如果 landing 或品牌页仍然有明显模板味，再让 design-taste-frontend 做一次 audit。它负责删掉模型习惯，不负责重写后台业务。

实现完成，playwright-cli 接手。跑真实登录、真实点击、关键视口和截图。发现问题就回到对应工位，不要再把四个 Skill 同时叫醒。

怎么说呢，这套顺序并不神秘。它只是承认了一件经常被忽略的事，审美方向、设计规范、反模板化和浏览器验收，本来就是四种工作。

Skill 越多，能力上限确实可能越高，冲突机会也一起涨。真正省时间的不是收藏一百份说明书，而是知道眼前的问题该叫谁来。

别让四位设计总监继续抢方向盘了。