网页上线前怎么收尾？这个 8 万 Star Skill 把 UI 问题列清了

网页快上线时，最让人头疼的反馈通常不是“按钮离左边 8 像素”，而是“这里再高级一点”“怎么还是有点 AI 味”。

这两句话听起来像审美讨论，落到开发却很要命。你不知道该改层级、留白、字重、错误状态，还是把那一堆套着一堆的卡片拆掉。最后很容易进入一个循环，Agent 改一版，大家说“好一些了”，然后下一版又回到同一个模糊句子。

今天想记一个很实用的 Skill，开源项目 Impeccable。截至 10 月 13 日，它的 GitHub 仓库约有 8.05 万 Star。它不替你发明品牌，也不是把页面一键套进某个 SaaS 模板，而是给编程 Agent 一套能持续记住的设计语言，加上 24 个命令和 59 条确定性检查。

想先摸一遍，官方给的入口只有一条命令。

npx impeccable install

这篇不把官方材料写成亲测。安装后到底适不适合你的项目，仍要你自己跑一遍。但它解决的那个问题很具体，网页收尾时，别再只靠“看起来差不多”。

官方仓库截图。热度只说明很多人正在关注，不能代替你对项目的验收。

那句“再高级一点”，到底该改什么

AI 生成页面最容易出现的，不是明显坏掉，而是一种很熟悉的平庸。首屏有一团渐变，标题上面摆着圆角图标，下面是三个一样大的卡片，所有文字都礼貌地保持中号。

代码甚至没什么错。问题在于页面没有做选择，用户的眼睛也就不知道先看哪里。

Impeccable 把这类问题拆得比“审美”更细。它会盯字体选择、彩色背景上的文字对比度、卡片是不是被层层嵌套、布局节奏、窄屏适配、文本溢出、错误状态和动效。官方文档还把“灰字压在彩色底上”“所有东西都装进卡片”“过时的弹跳缓动”列成明确的反模式。

这里有个我觉得挺值钱的转变。你不必对 Agent 说“做得像一个资深设计师”，这种话信息量基本等于零。你可以说清楚“先看结算页的主操作是否唯一，再看价格、错误提示和优惠信息的阅读顺序；最后检查 390px 宽度会不会挤坏”。

前一句是在许愿，后一句是在交付任务。

设计收尾不是多加几个装饰，而是把用户看见、读懂和操作的路径逐项核对。

它不像一份设计稿，更像一份交接协议

这个项目最有意思的地方，不是命令多，而是先把“这个产品到底是什么”留下来。

/impeccable init 会建立 PRODUCT.md，记录受众、产品目的、运行环境、约束和已经确认的事实。已有项目可以用 document 归档当前设计，再用 extract 把可复用的组件和设计 token 整理出来。

这听起来有一点文档味，可它刚好碰到 Agent 协作最常见的失忆。今天你说“给管理后台做克制一点”，明天它可能又给你端出一个蓝紫渐变加玻璃卡。不是模型故意气人，是“克制”没有变成一份可复用的项目约束。

PRODUCT.md 管事实，DESIGN.md 管视觉系统。把这两层分开，后面再让 Agent 做页面时，讨论会少一点玄学。你仍然可以换方向，但至少每次换都知道自己推翻了什么。

官方把常用动作做成了很直白的一组词，shape 先把 UX 和 UI 的问题讲清楚，craft 做构建与视觉迭代，critique 看层级和清晰度，audit 盯可访问性、性能与响应式，polish 放在最终交付前做一致性检查。

别把它理解成固定流水线。一个刚起步的落地页，也许只需要 shape 和 craft。一个已经跑了半年的后台，更适合先 document，再从一个总被吐槽的页面开始 critique。

一个 20 分钟可走通的页面收尾流程

如果你手上正好有一页要交付，我会建议先挑一个具体表面，不要一上来让它审整个站。比如结算页、设置页，或者产品首页的首屏。

第一步，安装后在你的 Agent 里运行下面这句，把人、任务和边界说完整。

/impeccable shape 结算页。保留现有品牌色，先确认主操作、价格、优惠与报错的阅读顺序；390px 窄屏优先，不新增营销模块。

第二步，让它按这个方向构建或调整。页面已经存在时，别让它顺手大改所有组件。把范围钉在“结算页的信息层级和提交前状态”，比一句“把页面设计得更好”更容易得到可审的改动。

第三步，临近合并时跑 audit 和 polish。前者适合抓响应式、可访问性和技术层的问题，后者更像出门前照镜子，看看间距、字号、组件语言有没有各说各话。官方的 59 条确定性检查在这里很有用，因为它会把一部分肉眼烦躁但说不出的东西变成具体项。

最后别忘了留一道人工关。拿 375px 和 390px 两个宽度看首屏、表单、错误提示、图片和结尾。检测规则能指出典型问题，却不知道你的用户是不是赶着付款，也不知道一句文案会不会让人误解。那部分还是得由做产品的人负责。

你可以把下面这张小清单贴进 PR 描述里，够用就好。

• 主操作是不是比次要操作更早被看见
• 首次阅读时，用户能不能说出这一页要完成什么
• 错误、加载和空状态有没有把下一步说清楚
• 390px 宽度下，长文字、按钮和价格有没有互相挤压

这不是设计教条。它只是把“好不好看”先还原成几件能做、能看、能讨论的事。

先别急着装，三种情况收益不高

如果只是临时改一个静态活动页，设计本来就由 Figma 稿严格约束，或者团队已经有很成熟的组件库和验收机制，这个 Skill 的上下文初始化可能不划算。先把眼前那几个 CSS 问题修掉，反而更快。

它也不是可访问性测试的替代品。自动规则可以提醒对比度、触控尺寸或标题层级，但键盘流程、读屏体验、真实文案和业务风险仍需要人工检查。

还有一个小提醒。官方安装程序会识别本机的 Agent 环境并询问安装范围，首次调用可能下载运行引擎。对 Codex 来说，项目级安装还可能带来需要单独审阅的 Hook。先看清它要写进哪个项目、Hook 做什么，再决定是否批准。设计工具很好用，默默改了你不理解的工程配置就不那么浪漫了。

Impeccable 最适合的不是“帮我凭空做一张漂亮页面”，而是你已经有页面、有用户任务、有一点设计债，想把最后那段模糊的收尾工作说清楚。

你团队里最常出现的设计反馈，是“再高级一点”，还是另一句更让人抓狂的话？

小岛 AI

记录一线实战、踩坑与成长