这个 UI 收尾 Skill 8.7 万次安装，修的是上线前最后 10%

页面已经能点，接口也接上了，产品说今天必须上线。

可你盯着它看了十秒，总觉得哪里不对。按钮差半格，空状态像临时贴上去的，手机一窄就挤成一团，加载失败以后只剩一块白板。单独拎出哪一个都不像大 bug，合在一起却很像四个字，还没做完。

我在 skills.sh 的 polish 页面 看到一组挺夸张的数字，87,140 次安装，背后的 Impeccable 仓库 有 64,163 Star。它干的正是这件熟悉的小事，给已经能用的页面做上线前最后一遍收尾。

安装命令只有一行。

npx skills add https://github.com/pbakaus/impeccable --skill polish

装完以后，可以直接把任务说清楚。

用 polish 检查这个结算页的上线质量。
保留现有信息架构和视觉方向，不做重设计。
质量目标是正式产品，优先修阻断任务、缺失状态和跨断点问题。

熟悉任务、公开热度、安装命令和调用方式，开头这几分钟都齐了。好家伙，听着像一个很会收拾烂摊子的 Skill。

不过边界先摆在桌上。我没有拿它跑一套完整生产项目，所以这里不编一组漂亮的 Before/After，也不假装亲测提升了多少。下面的判断来自它的 官方公开指令、仓库结构和公开安装数据。真实效果仍取决于你的代码库、设计系统、浏览器环境，以及你愿不愿意做最终验收。

它不是美颜，是一条修复队列

很多人看到 polish，第一反应大概是让 AI 把阴影调柔一点，圆角改顺眼一点，再加两段动画。

官方规则正好反着来。

它开头就写得很硬，收尾不是偷偷重做。现有视觉、内容和行为应该被保留。概念方向真错了，就明说需要重新设计，别借着收尾的名义把整页换掉。

我挺喜欢这条。AI 做 UI 最容易犯的毛病，不是不会画，而是每次都想证明自己来过。颜色换一套，布局挪一遍，动画塞三个，提交记录很热闹，产品的心智模型也被它顺手埋了。

polish 要求先找 DESIGN.md、设计 token、共享组件和相邻流程。没有正式设计系统，就看代码库已经形成的约定。然后把问题分成四类，缺少可复用 token、重复造组件、概念与相邻区域不一致，以及单纯没做完的局部缺陷。

这一步很工程。

因为同样是一个 14px 的间距，修法可能完全不同。它可能只是写错了，也可能说明页面没有复用 spacing token，还可能暴露整个流程跟产品别处不是一种语言。只改眼前的数值，截图会好看，下一页还会继续长歪。

真正有价值的地方，是它给修复排了顺序。

1. 先修被阻断的任务、数据丢失、误导状态和不可访问路径。
2. 再补加载、空、错误、成功、禁用和权限状态。
3. 然后处理流程、层级、响应式和设计系统偏移。
4. 接着才轮到视觉与动效不一致。
5. 收尾清掉死代码、废弃样式、未使用资源和重复实现。

页面看起来不够精致，可能只是第四级问题。用户点了付款却不知道成功没有，才是第一级。

厉害了，这个排序看上去朴素，却比很多 UI 优化提示词靠谱。它不让 Agent 在一个卡片的阴影上磨半小时，同时把错误页和键盘焦点留在废墟里。

规则层面的 Before/After

这里说的 Before/After 是公开规则能推导出的工作方式变化，不是我跑出来的实测效果。

Before 是盯着一张桌面截图找不好看的地方。After 是把整条用户路径在桌面、手机和中间宽度重新走一遍。

Before 是默认按钮有样式就算完。After 是连 hover、focus、active、disabled、loading、error 和 success 都有明确反馈，键盘 Tab 顺序也得走得通。

Before 是英文短文案刚好塞下。After 是长内容、本地化膨胀、缩放、慢网、离线和权限受限都不能把布局顶穿。

Before 是检测器没报错，于是宣布棒棒的。After 是承认检测结果只能证明发现或没发现某类缺陷，不能替代真实渲染和交互判断。

你想想看，这才是 UI 最后 10% 难的地方。前 90% 容易被截图展示，最后 10% 经常藏在用户刚好没网、只用键盘、名字特别长、权限又不够的那一分钟里。

这套要求跟公开的 Web 质量标准也能对上。像 WCAG 2.2 会盯键盘、焦点、对比度和可操作性，Core Web Vitals 会盯布局偏移和交互响应。polish 没有发明一套玄学审美，它只是把这些容易在 deadline 前被忘掉的事情，重新塞回 Agent 的任务单。

怎么把它接进真实工作

我的建议是别把 polish 当生成页面的第一条命令。页面功能还没通、产品方向还在摇的时候，用它只会让一块临时木板被打磨得很亮。

更合适的位置，是功能完成以后、代码审查以前。

先给它三个约束，目标范围、质量档位、上线时间。比如只看结算流程，不改导航结构；这是正式产品，不是 MVP；今天还有两小时。范围越清楚，它越不容易顺手改掉不该碰的东西。

再要求它留下证据。每个问题要带页面、状态、视口和代码位置。改完以后重走完整路径，跑现有测试，再看源码 diff。没有截图、控制台记录、测试输出或明确复现路径的「已优化」，先当成一句愿望。

然后让问题按优先级落地。阻断支付的错误和少了 2px 的圆角不能在同一层排队。P0、P1 先清，纯视觉细节根据时间预算决定。坦率讲，这比要求 AI「整体高级一点」有效得多，后者十有八九会得到更多渐变和更大的标题。

如果项目已经有设计系统，要求它复用 token 和共享组件。项目没有正式文档，也别让它现场发明一套宇宙真理，沿用相邻页面已经稳定的约定就够了。

最后由人看一遍真实页面。鼠标、键盘、手机宽度、长文案、加载失败，各走一轮。自动扫描干净不等于可以交付，官方指令自己也反复强调这一点。

哪些场景别用

这个 Skill 有三个很清楚的限制。

产品方向错了，别用。登录流程要砍成一步，polish 不该偷偷帮你重画成另一个产品。

功能没做完，别用。接口还在返回 mock，错误处理都没有，先把路径补齐，别急着调动效曲线。

没有验证环境，也别把结果当结论。Agent 能改 CSS，不代表它真的在每个断点、浏览器和输入方式里走过。说实话，这块最容易自嗨，代码 diff 很满，真实用户一按 Tab 就迷路。

它也不会替代设计师的方向判断。视觉层级、品牌气质、信息取舍，这些仍需要人下判断。polish 更像上线前的总检，它能把松动的螺丝、没亮的警示灯和漏掉的应急出口找出来，但它不会替你决定这辆车该开去哪里。

我自己的感受是，这类 Skill 值得关注，不是因为它能让页面一键变漂亮，而是因为它在压住 Agent 最爱发作的冲动。

少重画，先补坏状态。少堆动画，先走完整路径。少宣布完成，先拿证据。

页面「可以上线」和「用户遇到意外也不会被丢下」，中间隔着的，正是那最后 10%。