Taste-Skill 深读：给编码代理装上审美过滤层

它解决的不是生成问题，是品味问题

编码代理会写页面，但写出来的页面往往像同一个模板印出来的：居中大标题、三张卡片、一个渐变按钮。Taste-Skill 的切入点不是让代理生成得更多或更快，而是在生成之后加一层审美判断，让输出摆脱「通用 AI 页面」的气质。

它给自己下的定义是一个 Agent Skill，而不是一个库或框架。这意味着它寄生在已有的编码代理工作流里，通过注入规则、脚本和检查步骤来改变代理的行为。安装命令只有一行，但它做的事情远比安装复杂。

它的典型用法是接入写作或内容生成 workflow，在 prompt 之后加一层品味过滤。文档没有说明它如何与具体代理的 prompt 工程交互，但从六步构建流程看，它实际是在代理的生成循环里插入了决策点和验证点。

六步构建流程：把审美拆成可执行的裁决

Taste-Skill 的 v2 构建流程来自对 247 个精选站点的研究。这个数字本身不重要，重要的是它说明了一个设计取向：审美规则不是拍脑袋写的，而是从样本中归纳出来的。

第一步是读取需求简报，列出「只有这个客户才有的东西」。这一步在对抗通用性——代理最容易忽略的恰恰是客户独有的素材，因为通用模板不需要它们。第二步从 20 个经过研究的设计方向中随机发三张牌，让代理选一个。随机性在这里是刻意的：它防止代理每次都走最熟悉的那条路。

第三步要求用一个句子把客户的独有素材和所选方向绑在一起。这是整个流程里最接近「创意」的一步，但它被压缩成了一句话的产出，避免代理在概念阶段无限发散。第四步用开放图库的真实照片和影像来构建页面，并强制署名。

第五步是浏览器自检：在三种宽度下检查页面，发现「slop」就判失败。slop 这个词在文档里没有精确定义，但从上下文看，它指的是视觉上的敷衍——布局失衡、留白混乱、元素对不齐这类问题。第六步让代理看自己的截图，每轮修复三个最严重的问题，最多三轮。

这个流程的代价是时间和 token。文档明确说一次构建大约需要 30 到 45 分钟，消耗几十万 token。这不是一个轻量工具，而是一个用计算资源换审美质量的方案。

v2.1 的路线分叉：页面和应用界面走不同的规则

v2.1 引入了一个关键判断：页面和应用界面不是一回事。文档说「skill 能区分页面和应用界面」，然后给仪表盘、管理后台、设置页走了自己的构建路线。

应用界面的构建从研究真实产品截图中提炼出的风格中随机发一张牌，然后按照那个风格构建外壳、数据、图表和表格。检查规则是「安静的面板、对齐的数字、颜色花在数据上、手机布局里导航折叠起来」。这些规则比页面规则更具体，因为它们针对的是信息密度和可读性，而不是视觉冲击力。

一个值得注意的设计是：产品的落地页构建它展示的应用时，走同一条应用构建路线。这样落地页上的应用截图看起来像一个真的能用的产品，而不是一张装饰性 mockup。这个细节解决了 AI 生成落地页时常见的「截图假感」问题。

v2.1 还增加了页面框架检查：首屏有清晰的标题、边距相等、没有区块被挤到一边、没有随机的空白拉伸。移动方式则参照最新的 100 个 Awwwards Sites of the Day。这里文档没有说明「移动方式」具体指什么，但结合上下文，应该是指页面滚动或动效的节奏感。

图片策略：用开放图库对抗 AI 图片的塑料感

Taste-Skill 明确要求用真实照片和影像来构建页面，图片来源是 Wikimedia Commons、Openverse 和 Met 这类开放收藏。它只提供公共领域、CC0、CC BY 和 CC BY-SA 的文件，并且把署名放在页面上。

这个选择有两层含义。第一层是对抗 AI 生成图片的「塑料感」——真实照片带有不可预测的纹理、光线和构图，这些是扩散模型很难稳定复现的。第二层是版权安全：开放图库的授权条款明确，代理不会在不知情的情况下把受版权保护的图片嵌进页面。

代价是网络依赖。文档说「找图片需要网络访问」，而且图片来自开放图库，意味着素材质量参差不齐。文档没有说明如果找不到合适的图片会发生什么，但可以推测代理需要在这种情况下做出替代决策。

安装形态：寄生在代理生态里，而不是独立存在

Taste-Skill 支持多种安装方式：npx skills CLI、Claude Code 插件市场、Codex 插件市场，以及从克隆仓库 symlink 安装。它被命名空间化在 taste-skill: 下，避免与其他 skill 冲突。

这种设计意味着它没有自己的运行时，而是依赖宿主代理的 skill 机制。它的脚本需要 Node 22+ 和 Chrome、Edge 或 Chromium，但「不安装任何东西，也不需要 API key」。这个约束很聪明：它把自己定位成一个规则和脚本的集合，而不是一个需要维护的服务。

从 Moved skills 一节可以看到，这个仓库曾经包含多个 skill，现在只保留 design-taste-frontend 一个。其他的被拆到了 taste-skill-classics 和 imagegen-skills 两个仓库。这个拆分说明作者在收敛范围——一个仓库只解决一个具体问题，而不是做一个大而全的设计 skill 集合。

边界与判断

Taste-Skill 的价值在于它把「审美」这个模糊概念拆成了可执行的步骤和可检查的规则。它不试图教代理什么是美，而是给它一套从真实站点研究中提炼出来的决策流程和验证标准。

它的边界也很清楚。第一，它只解决视觉品味问题，不解决内容策略或信息架构问题。第二，它的成本不低——30 到 45 分钟和几十万 token 意味着它不适合快速迭代的场景。第三，它依赖开放图库的图片质量，如果找不到合适的素材，输出质量会受影响。

如果你的工作流里编码代理生成的页面总是「能用但不好看」，Taste-Skill 值得一试。如果你需要的是快速原型或内容优先的页面，它的时间成本可能会让你不耐烦。先在一个对视觉质量有真实要求的项目上跑一次，看看它给出的页面是否对得起那几十分钟的等待。