Codex 改旧页面怎么用 taste-skill？先审 UI 再动代码

拿 Codex 改旧页面时，最怕它把能用的东西全推倒：颜色换了、组件重写了、业务状态丢了，页面是新了，产品却不稳。taste-skill 的 redesign 思路不是直接美化，而是先审 UI，再决定保留什么、改什么。

改版前先让 Codex 审一遍

任务可以这样写：使用 redesign-existing-projects 或 design-taste-frontend 的 redesign protocol，先审当前页面，不改代码。列出层级、间距、字体、按钮状态、移动端、暗色模式的问题，再给出最小改动方案。这个提示能阻止 Codex 直接进入“重做一版”的冲动。

审查阶段要让 Codex 保留业务约束：路由不能换，表单字段不能少，接口调用不动，现有组件库优先。旧页面的价值在于已经跑过真实用户，不该被一轮审美改造破坏。

哪些地方最值得改

第一类是信息层级。标题、说明、按钮、次要链接如果权重差不多，用户会不知道下一步点哪里。第二类是空间关系。卡片边距、列表行高、表单分组如果混乱，页面会显得廉价。第三类是状态。hover、focus、loading、disabled、error 少一个，真实使用时就会露出粗糙感。

让 Codex 按这三类动手，比让它“美化 UI”靠谱。它会更倾向于修结构、间距、状态，而不是随手换一套背景和阴影。

一条更稳的 Codex 改版指令

可以把任务写成：先审查页面，不改代码；给出 6 条以内的问题；再做一次小范围改版，只动布局、字体、间距、按钮状态和响应式，不改接口和业务逻辑；改完跑测试并给我看 diff。这个流程慢一点，但更适合生产项目。

taste-skill 用在旧页面上，价值不是让 Codex 更敢改，而是让它改得有边界。边界清楚，页面才会变好看，项目也不会被一轮视觉重做拖乱。