让 agent 做一个落地页，brief 写得挺正经：现代、简洁、专业、有质感。跑完打开浏览器，奶油色背景，细衬线大标题，斜体点缀，两个胶囊按钮，卡片里塞圆角矢量插画。换一个模型，换个项目，东西长得还是差不多。
我一开始以为是 prompt 没写清楚。后来发现写清楚也没用，因为"现代简洁专业"这几个词本身没有指向性，它只是把选择权交回给了模型的默认分布。
模型不是没审美，是把方向信息扔了
impeccable 的 README 里有一段把话说得很直：不加引导地让 agent 做页面，下面这些会反复出现，跨模型、跨项目都一样。
- Inter 一把梭，所有文字都用它
- 紫到蓝的渐变
- 卡片里再套卡片
- 彩色背景上放灰字
- 每个小标题上面顶一个圆角方形图标块
这几个东西凑在一起，就是大家说的 AI 味。它跟模型聪明不聪明关系不大。你给的 brief 里没有任何排除这些选项的信息，那采样回来的自然就是训练数据里最密集的那一块。要求"专业"，等于没要求。
impeccable：给每个动作起名字，把检查写成代码
作者是 Paul Bakaus，Apache 2.0，起点是 Anthropic 的 frontend-design skill。装完之后它给你 24 个命令，按用途归一下：
| 用途 | 命令 |
|---|---|
| 调方向 | bolder 把太保守的做狠一点，quieter 收一收，distill 删掉不该有的，colorize 给灰界面加颜色，typeset 修字体和层级，layout 修间距节奏 |
| 做评审 | critique 按可用性启发式打分并排优先级，audit 查无障碍、性能、主题、响应式，问题分 P0 到 P3 |
| 收尾 | polish 交付前最后一轮，harden 补错误态、i18n、溢出、边界，clarify 重写含混文案，adapt 处理屏幕尺寸，optimize 修加载和渲染 |
| 前置 | shape 先规划 UX 再写代码，document 把现有视觉系统写进 DESIGN.md |
命令多不是重点。重点在于每个命令都对应一个具体的移动。“让它好看一点"给不了模型任何可执行的东西，“bolder 定价卡片"能，它加载的是专门为这一个动作写的 playbook，目标也限定死了，就那几张卡片。
真正硬的部件是那个 slop 检测器：62 条确定性规则，不用 LLM，不要 API key。同一份代码扫两遍结果一样，而且能进 CI。
npx impeccable detect src/ # 扫源码
npx impeccable detect http://localhost:5173 # 扫渲染后的页面
npx impeccable detect --json src/ > out.json # 机器可读
退出码 0 是没发现问题，2 是有主要问题，1 是目标扫不了。advisory 这类附注不影响退出码，放在 GitHub Actions 里，2 就该拦。
源码扫描和 URL 扫描查的东西不一样。JSX、TSX 这些文件只能过模式规则，对比度太低、字号太小这类必须看渲染结果，所以得把 dev server 的地址也给它。默认视口 1280x800，查手机布局要自己指定 --viewport 390x844。
有条规则挺能说明这套东西的粒度。CSS 里用 background-clip: text 加渐变做文字，会被 gradient-text 拦下，它不说"这个丑”，只说建议用纯色，先想清楚这个渐变在你的设计里承担什么作用。判断权留给人，它只负责让这个决定从"顺手写上去"变成"必须解释”。
还有一个机制我觉得设计得挺对：品牌例外要显式登记。
npx impeccable ignores add-value overused-font Inter --reason "Brand font"
Inter 在过度使用的字体名单里，但如果它就是你的品牌字体，你得写一行命令说明理由，而且豁免只对 Inter 生效，别的字体照查。它不给你一个开关把整条规则关掉。
效果差别有多大？README 里放了一组对照：同一个模型（Fable 5.1），同一份 brief，利古里亚海岸一家十四间房的家庭旅馆。没装的时候出来的是标准的体面默认页；装了之后整页围绕一件事展开，夜里从海面上看那栋悬崖上的房子，版画质感，标题用压缩体的奶油色和朱红。差别在于有没有一个明确的构图决定，跟配色好不好看关系不大。
taste-skill：先给方向，再给真素材，最后逼它看自己的截图
另一条路完全不一样。taste-skill 是 MIT 协议，作者 Leonxlnx，底子是对 247 个精选网站做的研究。README 把一次构建拆成六步：
- 读 brief，先列出只有这个客户才有的东西
- 脚本从 20 个研究方向里发三张牌，agent 挑一张
- 找那句"想法"：一句话，把这个客户自己的材料和研究方向绑在一起
- 用开放馆藏里的真实照片和影像来搭，并且署名
- 在真浏览器里按三个宽度检查，slop 直接判失败
- 看自己的截图，修掉最严重的三个问题，最多修三轮
最后两步是关键。它没有把审美写成规则表，它让 agent 去看自己产出的图，然后回来改。代价也写得很清楚：一次构建 30 到 45 分钟，几十万 token。
素材那块挺讲究。图片来自 Wikimedia Commons、Openverse、大都会博物馆这类开放馆藏，只用公有领域、CC0、CC BY、CC BY-SA 的文件，署名打在页面上。所以出来的页面里有真的照片，而不是又一层渐变占位块。它自己的示例里，咖啡店页面用一张手绘店面当 hero，techno 演出的日期直接排进一张档案照片。
v2.1 加了仪表盘和应用界面，规则换了一套：面板安静、数字对齐、颜色只花在数据上、手机端导航收起来。页面框架也单独查，首屏要有清楚的标题，左右边距要相等，不能有内容被挤到一边，不能有莫名其妙的空白。动效的参照物是最新 100 个 Awwwards Site of the Day。
两条路的分工
| 确定性检测 | 浏览器自检循环 | |
|---|---|---|
| 成本 | 秒级，零 API 花费 | 30 到 45 分钟，几十万 token |
| 能抓 | 可判定的坏，低对比、溢出、渐变文字、千篇一律的字体 | 构图、素材、节奏、整页有没有一个决定 |
| 抓不到 | 好想法 | 某条 CSS 的具体错误 |
| 放哪 | CI、提交前、agent 的 hook | 关键页面，人盯着 |
我的建议是分两层用。日常改 UI，把 detect 挂进 CI，当 lint 跑，成本几乎为零，能拦住大部分敷衍。轮到落地页、作品集、活动页这种一眼定生死的页面，再上带参考图和截图自检的重流程。别一上来就上重流程，30 分钟一轮的迭代对个人项目太贵。
两条路有个共同点：都要求把审美从形容词变成名词和动词。形容词没法执行，名词和动词可以。
该冷静的地方
规则好用，但会收敛。所有人都装上同一套 62 条，两年之后可能出现一种"合规的雷同"，大家从紫蓝渐变逃到另一种整齐。impeccable 那个别墅例子的价值，恰恰在于"整页围绕一张夜间海景版画重建"这个决定，这种东西任何规则都生不出来。检测器能拦住烂，生不出好。
单条规则都是启发式。Inter 可能真的是你的品牌字体，大圆角可能是产品性格，这时候要写显式豁免和理由，而不是把规则关掉。区别在于三个月后你还记不记得自己为什么这么选。
还有一点跟审美无关但更要紧：这类工具靠 hook 挂在 agent 编辑完成的节点上，在 Claude Code 里，命令 hook 会在你拒绝模型执行的命令时照样运行。无人值守跑长任务之前，先把装进来的 hook 看一遍。
我的判断
模型缺的从来不是品味，是验收标准。同一句 brief 下它给你奶油底加胶囊按钮，是因为没人告诉它这几个选项排除掉，也没人给它看一眼结果。
所以"给 agent 装审美"这个说法，我听了一半就不太信。装进去的是词汇表、检查清单、参考图库和一条闭环，审美本身还是你自己的事。真正会变的是设计评审被拆成两段，可判定的部分交给 CI，剩下那些要一个人做决定的，才回到人手上。
对独立开发者来说，比换模型更划算的动作是先写两个文件：一个说清楚这产品给谁用、解决什么，一个把现有的字体、颜色、圆角、字号层级记下来。这两份东西写出来，模型的表现立刻不一样，因为它终于有了可以对齐的东西，不用每次从均值重新猜。