polish

polish 技能概览

polish 的作用

polish 技能是一套用于 UI 最终审查的工作流，专门用来抓出那些会让作品“看起来快完成了，但还不够能交付”的问题。它关注对齐、间距、一致性、token 使用、视觉节奏、交互细节，以及通用提示词经常漏掉的那些轻微实现偏移。

polish 技能适合谁

如果你已经有一个能正常工作的界面，并希望在评审、发布或交接前再把质量往上提一档，就适合用这个 polish 技能。它适用于设计师、前端工程师，以及借助 AI 开发页面、流程或组件的人，尤其是那些界面已经“差不多了，但总觉得哪里不对”的场景；当设计系统或现有产品规范应该主导最终呈现时，它尤其合适。

安装前最重要的事

polish 最关键的采用前提是：它不是为了从零凭空发明设计方向。它默认你已经有可检查、可改进的对象。它还依赖 $impeccable：这个技能明确要求先运行那个更宽泛的技能，以完成上下文收集、原则确认和反模式检查。如果还没有设计上下文，工作流会要求先执行 $impeccable teach，再使用 polish。

为什么不直接用普通提示词

单纯一句“把这个做得更好看”通常只会得到空泛建议，或者带有随机性的重设计。polish 更适合在真实体系下做系统性检查：识别设计规范，发现 token、组件、模式上的偏移，并在不必要改动产品的前提下做有针对性的修正。这让它在上线前清理和 UI 设计一致性工作中更实用。

如何使用 polish 技能

安装上下文与先读哪些文件

从 pbakaus/impeccable 仓库安装这个技能，并先阅读 SKILL.md，因为真正的运行规则都写在里面。最重要的一条是强制性的：先调用 $impeccable。如果你在做 polish install 决策，就意味着这个技能最好作为更大范围 impeccable 工作流的一部分使用，而不是一个独立的一次性提示词。

polish 要有效运作，需要什么输入

polish 技能在以下输入齐全时表现最好：

• 目标屏幕、流程或组件
• 当前实现或截图
• 设计系统、组件库或 token 约定（如果有）
• 质量标准：MVP 或 flagship
• 已知痛点，例如“间距看起来不均匀”或“按钮风格不统一”

一个较弱的请求是：Polish this settings page.
一个更强的 polish usage 提示词是：Use polish on the settings page. Quality bar: flagship. Match our existing design system. Check spacing scale, token usage, component consistency, alignment, and interaction details. Avoid redesigning layout unless needed.

一个实用的 polish 工作流

一个可靠的流程是：

1. 先运行 $impeccable，收集上下文和原则。
2. 识别设计系统；如果没有，就从邻近产品区域归纳现有规范。
3. 评估当前 UI 是否存在偏移：硬编码数值、间距不一致、自定义模式重复、层级不均衡、视觉噪音过多。
4. 先做小而高置信度的修改。
5. 再整体复查页面，确保局部修正不会制造新的不一致。

这才是最好的 polish guide 心法：不要一上来就直接改。仓库强调的是，在动细节之前，先弄清楚这个产品里“精致”到底意味着什么。

面向 UI Design 的 polish 提示技巧

如果你是做 polish for UI Design，最好要求结构化输出。可以加入这些提示：

• List issues by severity before proposing changes.
• Prefer system alignment over novelty.
• Call out where tokens or shared components should replace custom styling.
• Separate must-fix launch blockers from nice-to-have refinements.

这样能提升输出质量，因为这个技能最擅长的是系统性检查，而不是大开大合的创意探索。如果你想先做探索，应该先用概念设计或重设计导向的技能，再在最后把 polish 接上。

polish 技能常见问题

polish 适合新手吗？

适合，前提是你已经有一个明确的 UI 可以改。polish 技能能给新手一份比通用提示词更好的检查清单，尤其是在间距、一致性和设计系统对齐方面。但如果你还不了解产品规范，它就没那么新手友好，因为这个工作流默认上下文已经存在，或者需要通过 $impeccable 先教会它。

什么时候不该用 polish？

当问题本质上是策略、信息架构或缺少 UX 方向时，不要用 polish。它也不适合从零开始的空白画布设计。如果这个页面从根本上就错了，polish 不能替代真正的重设计；它负责的是收尾和质量提升，不是发明产品核心方案。

polish 和代码审查有什么区别？

代码审查可能会发现可维护性或正确性问题；polish 技能更聚焦于已交付体验：视觉一致性、系统偏移、微观细节质量，以及界面是否整体协调。两者当然有重叠，但 polish usage 主要是在做 UI 质量评估，而不是工程架构审查。

polish 需要设计系统吗？

不需要，但有设计系统时效果会更好。如果没有正式系统，这个技能仍然会要求你朝着可见的产品规范去打磨。也就是说，它在“临时拼装型”产品里依然有用，只是如果有可复用的 token、组件或既有模式可以对齐，输出会更强。

如何改进 polish 技能

给 polish 更明确的目标

提升 polish 结果最快的方法，是把目标说清楚：是 MVP 还是 flagship，要检查哪个界面，以及目标是统一性、高级感、上线就绪，还是符合设计系统。没有这些信息，技能可能会过度修复小问题，或者把精力花在质量并不重要的地方。

提供更强的证据，而不只是意见

更好的输入会带来更好的 polish。请提供截图、组件代码、相邻页面、token 文件，或者“我们希望达到这个水平”的参考样例。这样技能才能区分真实的不一致和有意的变化。如果你只说“让它更好看”，它就只能猜标准。

注意常见失败模式

最常见的失败模式包括：

• 过度重设计，而不是精修
• 修好了局部细节，却破坏了整页节奏
• 引入新的自定义样式，而不是对齐共享组件
• 把所有不一致都当成 bug，但其中有些其实是刻意为之

可以要求技能默认保留产品既有模式，除非某个偏离确实损害质量。

在第一轮之后继续迭代

现实中提升 polish 技能效果的最佳方式，是基于反馈再来第二轮。拿到第一版输出后，可以直接回应：too aggressive、keep layout unchanged、focus only on spacing and typography，或者 prioritize design-token cleanup。这样能把泛化精修收窄到你团队真正期望的标准。