polish

polish 技能概览

polish 是做什么的

polish 技能是一套面向 UI 的最终检查流程，用来捕捉那些看似细小、却会让成品显得不一致、不够完整，或整体质感低于预期的问题。它适合在界面功能已经完成之后使用，帮助你在发布前进一步优化对齐、间距、交互状态、文案一致性、边界情况以及视觉流畅度。

谁适合使用 polish

这个 polish 技能最适合设计师、前端工程师，以及借助 AI 搭建产品界面的开发者。前提是你已经有一个可运行的界面，现在需要一轮有结构的质量检查。尤其当你的需求更接近“补一下收尾细节”“总觉得哪里不对”“把它做到可上线”“从还不错提升到更好”时，它会很有用。

它真正要解决的问题

用户安装 polish，并不是为了拿到泛泛而谈的设计建议，而是为了执行一次系统化的上线前检查，避免漏掉那些明显却常见的微小问题：

• 间距不一致
• 对齐没有落在统一网格上
• 缺少 hover、focus、loading 或 error 状态
• 文案语气或标签命名不统一
• 过渡和交互细节显得生硬

这个 polish 技能的差异点

polish 最大的区别在于，它明确是一个最后一步技能，而不是通用型重设计工具。它还依赖上游设计上下文：仓库要求你先调用 /frontend-design，如果还没有建立设计上下文，则要先运行 /teach-impeccable，然后再使用 polish。这个依赖很关键，因为该技能默认你已经有明确的设计方向和质量标准，才能据此进行评估。

什么情况下 polish 很适合

在以下情况使用 polish 比较合适：

• UI 在功能上已经完成
• 你需要在上线前做最后一轮质量检查
• 当前主要问题是不一致，而不是产品策略本身
• 你可以提供明确的目标页面、组件或流程
• 你已经清楚目标标准是 MVP 还是 flagship

什么情况下不该用 polish

如果出现以下情况，不要一开始就用 polish：

• 功能本身还在定义中
• 核心流程仍然有缺陷或未完成
• 你需要的是大幅度 UX 重构
• 还没有任何设计上下文
• 团队还没决定结果需要精细到什么程度

如何使用 polish 技能

在你的 skills 环境中安装 polish

这个仓库没有在 SKILL.md 里提供专门的安装命令，所以大多数用户会通过自己的 skills manager 从源仓库添加该技能。常见方式是：

npx skills add pbakaus/impeccable --skill polish

如果你的环境使用别的安装方式，也可以从这里添加：

https://github.com/pbakaus/impeccable/tree/main/.agents/skills/polish

先看这个文件

先从这里开始：

• SKILL.md

这个技能是自包含的。技能目录下没有额外暴露的 resources/、rules/ 或辅助脚本，因此大部分可执行工作流都集中在这一个文件里。

遵守必须的依赖链

在调用 polish 之前，仓库说明要求你先执行：

• /frontend-design

如果还没有现成的设计上下文，则必须先运行：

• /teach-impeccable

这是采用这个技能时最重要的一点。没有这些上下文，polish 往往只能给出类似“让间距更一致”这类比较浅层的建议，而无法基于真实设计原则提供高可信度的收尾检查。

了解 polish 需要什么输入

polish 在以下输入齐全时效果最好：

• 明确目标：页面、组件或流程
• 当前截图或代码上下文
• 预期质量标准：MVP 或 flagship
• 已知缺陷是要现在修复，还是保留为 TODO
• 发版时间线，或这次 polish 可投入的时间预算

这些输入会实质性改变输出结果。一个旗舰级营销页，和一个 MVP 内部工具，理应得到完全不同深度的 polish 检查。

把模糊需求改写成可用的 polish 提示词

弱提示词：

Polish this UI.

更强的提示词：

Use polish on the checkout flow. The flow is functionally complete. Quality bar is flagship. Keep the current structure, do not redesign the information architecture. Focus on alignment, spacing consistency, interaction states, error handling, and copy consistency. We have one day before ship, so prioritize high-visibility issues first.

这样写之所以更有效，是因为它：

• 明确说明已经具备检查前提
• 设定了范围
• 避免技能误做重设计
• 给出了现实的时间约束
• 告诉技能应该检查到什么深度

先把 polish 用在小范围目标上

参数提示是 [target]，这其实是个很实用的信号：尽量传入明确目标，而不是让它对整个产品泛泛点评。好的例子包括：

• polish pricing page
• polish onboarding modal
• polish dashboard table states
• polish mobile settings flow

相比“polish the whole app”这种大而化之的请求，聚焦的目标通常能得到更可执行的输出。

按照推荐工作流来用

一个实用的 polish 使用流程是：

1. 先确认 UI 在功能上已经完成。
2. 通过 /frontend-design 获取设计上下文。
3. 如果还没有设计上下文，先运行 /teach-impeccable。
4. 明确质量标准和时间预算。
5. 让 polish 检查一个具体目标。
6. 按问题类别逐类修复，而不是零散处理。
7. 修完之后再次运行 polish，做最后一轮验证。

这和仓库强调的做法一致：在动细节之前，先完成 pre-polish assessment。

polish 通常会检查哪些内容

根据源码信息，polish 会系统检查以下几个方面：

• 视觉对齐
• 间距一致性
• 交互状态覆盖
• 文案一致性
• 边界情况与错误状态
• loading 与过渡的流畅度

这点很重要，因为它也反过来告诉你该提供什么材料。如果你只贴静态 UI markup，就很可能拿不到关于 loading、过渡和状态的有效反馈。

不要只给 happy path，要提供完整状态覆盖

polish 效果不佳的常见原因之一，就是缺少状态上下文。尽可能补充这些状态：

• 默认状态
• hover / focus / active 状态
• 校验错误
• 空状态
• loading 状态
• disabled 状态
• 成功确认状态

这样 polish 才更容易发现那些“看起来快做完了，但上线后用户一定会注意到”的问题。

让输出按可见性和修复成本排序

如果离上线已经很近，可以要求 polish 将发现的问题分成：

• 上线前必须修
• 有最好
• 可以延后

这样一来，polish 的输出会比一股脑的泛泛评论更实用，尤其是在质量要求高、时间又紧的时候。

实用的仓库阅读路径

因为这个目录只暴露了 SKILL.md，最省时间的阅读路径是：

1. 先看 description 和 argument-hint
2. 再看 MANDATORY PREPARATION
3. 接着读 Pre-Polish Assessment
4. 最后把系统化的 polish 分类当作你的检查清单

按照这个顺序阅读，基本就足以判断它适不适合你，并开始实际使用，而不用把整个仓库过度通读一遍。

polish 技能 FAQ

polish 比普通提示词更好吗？

通常是的，前提是你的问题属于最后一轮的质量把关。普通提示词往往会给出比较宽泛的主观意见，或者直接给出重设计建议。而 polish 更聚焦：它默认你的东西已经做出来了，重点是检查那些在项目后期最容易被忽略的微观细节。

polish 只适用于 UI Design 吗？

基本上是，尤其适合 polish for UI Design 和前端体验质量场景。源码重点强调的是对齐、间距、交互状态、边界情况和流畅度，因此它明显更适合界面类问题，而不是后端架构或产品策略。

新手也能用 polish 技能吗？

可以，但新手需要提供更多上下文。如果你还不清楚自己项目里的“quality bar”或“design context”具体意味着什么，就先运行它要求的上游设计技能。否则输出可能看起来没错，但会比较空泛。

使用 polish 之前必须有完整代码吗？

你至少需要有足够完整的实现或原型。仓库写得很明确：polish 是最后一步，不是第一步。如果核心行为还在变化中，那反馈会很不稳定，价值也会明显下降。

采用 polish 最大的阻碍是什么？

最大的阻碍通常是跳过了强制准备步骤。如果你安装好 polish 后，没带 /frontend-design 上下文就直接调用，就会错过这个技能之所以可靠的大部分基础。

做 MVP 时适合用 polish 吗？

适合，但要明确告诉它质量标准是 MVP。这会直接改变检查深度。对于 MVP，polish 最好的用法是抓出最显眼的不一致和状态缺口，而不是把时间花在过度追求完美上。

什么情况下不该用 polish？

如果你需要的是下面这些，就跳过 polish：

• 完整重设计
• 产品探索
• 用户研究总结
• 架构变更
• 尚未完成的核心功能

在这些情况下，更合适的第一步应该是别的技能，或者直接进入设计 / 工程工作流。

如何改进 polish 技能的使用效果

给出更明确的目标

提升 polish 输出质量最快的方法，就是把目标说具体。对比一下：

弱：
Use polish on my app.

更好：
Use polish on the mobile checkout summary card and payment error state.

目标越具体，输出越不容易流于泛泛建议，也越容易直接转化成修复项。

明确写出质量标准

源码特别提到 MVP vs flagship 是有原因的。如果你不写清楚，polish 可能会对一个简单内部工具审得过深，也可能对一个关键上线页面审得不够。最好始终明确你要的是哪一档标准。

告诉 polish 哪些内容必须保持不变

如果结构、布局或品牌元素不能改，务必提前说明。比如：

Polish this settings page without changing the information architecture or component library.

这样可以让技能把重点放在收尾质量上，而不是慢慢偏向重设计。

把需要保留为 TODO 的已知问题提前说明

这个技能会询问是否有需要保留的已知问题。对于真实团队协作，这一点很重要。如果某些缺陷是有意延期处理的，最好一开始就说清楚，避免来回审查时浪费时间。

要求按类别输出发现的问题

一个强提示词格式可以是：

Use polish on [target]. Group findings into spacing/alignment, interaction states, copy consistency, edge cases, and motion/loading. For each item, say why it matters and whether it is must-fix or nice-to-have.

这和仓库的系统化方法一致，也能让后续落地更容易。

提供截图或 UI 状态，而不只是抽象目标

如果你希望 polish 真正改善上线体验，就要给它可观察的材料。高质量输入包括：

• 截图
• 组件代码
• 状态说明
• 验收标准
• 品牌或 design-system 约束

它看到的真实证据越多，就越不需要依赖泛化假设。

留意常见失败模式

在以下情况下，polish 的结果通常会明显变差：

• 功能实际上还没完成
• 目标范围过大
• 没有设计上下文
• 只展示了 happy path
• 团队还没定义“done”到底意味着什么

很多所谓“polish 输出不好”，本质上其实都是输入或时机问题。

修完后再跑一次 polish

更好的工作流不是只跑一轮，而是两轮：

1. 第一轮找问题
2. 实施修复
3. 第二轮检查回归问题和新暴露出的不一致

特别是在你跨多个页面调整间距尺度、组件状态或文案模式之后，这一步很有价值。

把 polish 当成上线检查清单，而不只是点评工具

想让 polish 发挥最大价值，可以让它产出一份简短、可执行的上线前检查清单。这样一来，polish 就不再只是主观反馈工具，而会变成真正的执行辅助，这也是这个 polish 技能最有价值的使用方式。