taste-skill 真正解决的不是 UI 美化，而是把审美规则工程化

AI 写前端不好看，通常不是因为它不会写 CSS，而是因为它没有稳定的产品判断。taste-skill 这类项目有价值，正是因为它把“审美”从一句模糊的 prompt，变成了 Agent 可以反复调用的设计规则。

很多人让 Codex、Claude Code、Cursor 做页面，第一轮结果能跑，但一眼模板味：大渐变、大圆角、大卡片、廉价阴影、层级松散、移动端只是桌面压缩版。问题不在代码量，而在判断标准缺失。

审美不是“做高级一点”

“高级一点”“好看一点”“像 Apple 一点”对人类设计师可能有语感，对模型来说却太空。模型会把这些词翻译成最常见的视觉套路：玻璃拟态、蓝紫渐变、巨型 hero、浮夸统计卡。

真正可复用的设计判断，应该更像工程约束：这个页面是什么产品类型，用户第一屏要完成什么，信息密度该多高，哪些元素是主操作，哪些装饰应该删掉，移动端是否同等可用。

Skill 的价值是让规则可复用

如果每次都靠 prompt 重新提醒，结果会非常不稳定。taste-skill 把这些判断沉淀成一套前端设计规则，让 Agent 在生成或重构页面之前先读一遍“该怎么判断”。

这和组件库不同。组件库解决“用什么零件”，设计 Skill 解决“为什么这样放、为什么不该那样放”。

适合放进哪些工作流

• 新页面生成前，先判断产品类型和首屏目标。
• 已有页面改造时，先审计布局、层级、间距、颜色、状态和响应式。
• 工具类产品优先信息密度和操作区，不盲目做大 hero。
• 后台系统优先长期使用效率，不做营销站视觉。
• 最终交付前检查是否仍有模板味和 AI 味。

它不能替代设计师，但能减少低级错误

taste-skill 不会让每个 Agent 都变成顶级设计师。它更像一套刹车和检查清单：少滥用装饰，少套默认模板，少把所有产品做成同一种 SaaS landing page。

对小团队来说，这已经很实用。真正贵的不是页面不好看，而是每次都要人类反复指出同一类问题。把这些问题写进 Skill，Agent 才有机会在下一次少犯。

结论

AI 前端的下一个提升点，不只是更强模型，而是更好的设计约束。taste-skill 代表的方向，是把产品审美、布局判断和交付标准工程化。以后真正好用的 Coding Agent，不应该只会写代码，也应该知道什么时候该少写一点、删掉一点、收敛一点。