Codex 生成更好看的前端：taste-skill 使用方法解析

Codex 写前端时，最容易出问题的地方不是语法，而是审美默认值：首屏一排大字，下面三I张功能卡，再加一点紫蓝渐变。业务明明是招聘后台、开发者工具或本地知识库，页面却像同一套模板换了标题。taste-skill 的价值在这里，它让 Codex 动代码前先做一次设计读题，再按页面任务调布局、字体、动效和信息密度。

它改的是 Codex 的开工顺序

taste-skill 不是一个 UI 组件库，也不是让 Codex 套某个固定主题。它的主技能名是 design-taste-frontend，官方仓库把它写成面向 AI Agent 的 Anti-Slop Frontend Framework。放到 Codex 里看，它更像一份前端审校规程：先判断页面该服务谁，再决定视觉语言，接着才写 React、CSS、动画和响应式细节。

这点很适合解决“AI 味”。普通提示词说“做得更好看”，Codex 只能用自己熟悉的默认组合补空白。换成 taste-skill 的任务写法，Codex 必须先交代 Design Read，比如这是开发者工具、目标用户是工程团队、页面需要高信息密度、动效要克制、首屏要直接展示核心工作区。读法不对，开发前就能改。

在 Codex 里怎么写任务

新项目可以这样下任务：

请使用 design-taste-frontend。
先输出 Design Read，再实现首页。
产品是一个面向开发者的 API 调试工具。
页面目标：让新用户在 10 秒内看懂请求构造、响应预览和历史记录。
视觉要求：不要 AI 紫蓝渐变，不要三I张等宽功能卡，信息密度偏高，动效只服务状态变化。

已有项目改版时，把“实现首页”换成“审查当前页面并改造”。让 Codex 先指出页面里哪些地方像模板：标题层级是否过大，卡片是否占据太多屏幕，按钮是否没有主次，空白是否压过内容。它给出 Design Read 后，再让它动文件。这样做比一句“帮我优化 UI”更稳，因为你能在代码生成前卡住方向。

三项参数怎么用

DESIGN_VARIANCE 适合控制“敢不敢跳出默认模板”。企业后台、支付控制台、表单工具可以低一点，作品集、品牌页、活动页可以高一点。MOTION_INTENSITY 管动效强度，业务工具一般让它服务 hover、展开、加载和状态反馈，别让动画抢走读者对内容的注意力。VISUAL_DENSITY 管信息密度，SaaS 控制台和开发者工具通常要更高，个人作品集和发布页可以留出更多呼吸感。

把这三项写进提示词，比单纯说“高级”“精致”更有用。Codex 看到明确刻度后，会更容易在字号、间距、卡片数量、滚动节奏和移动端布局上做取舍。验收时也有抓手：页面不够像产品，就提高密度；页面太吵，就降低动效；页面仍像模板，就提高变化度并要求它换掉默认首屏结构。

验收时盯住这些痕迹

taste-skill 的文档把常见 AI 前端套路列得很直白。你验收 Codex 输出时，不要只看“有没有渐变、圆角、阴影”。更重要的是看页面第一屏有没有真实任务，交互控件有没有主次，移动端文字会不会挤出按钮，卡片是不是只在堆形容词。一个页面看起来更好，通常不是装饰更多，而是每块区域都在替产品完成一个判断。

哪些任务最值得用

taste-skill 更适合落地页、作品集、品牌页、官网首屏、已有页面改版。复杂后台、审批系统、表格密集型产品还要补清楚业务流程、字段、权限和异常状态。它能提高 Codex 的视觉判断力，但不会替你补产品需求。

实际工作里，我会把它固定成四步：写清页面目标，要求 Codex 给 Design Read，按三项参数约束风格，跑桌面和移动端截图验收。只要这四步进入提示词，Codex 生成前端的稳定性会明显好一截，至少不会每次都回到那套熟悉的模板脸。