做产品页别急着交付，7,489 星流程会追问这 6 类问题

产品页做完，最常听到的一句反馈大概是「看着不错」。

这句话很危险，不是因为它错，而是它太容易让交付在表面上结束。鼠标点起来没事，不等于键盘能走完。桌面端排得齐，不等于窄屏不会挤掉按钮。错误提示写出来了，也不等于用户知道下一步该怎么办。

今天看到一个叫 better-interface 的开源工作流。截至 10 月 6 日，它所属的 jakubkrehel/skills 仓库有 7,489 个 Star，当天还有新的推送。

它最打动我的地方，不是又发明了一套「高级审美」。恰好相反，它把界面复查里最容易互相打架的意见拆开了。无障碍、布局、文案、排版、颜色、视觉细节，各自归各自的规则，再用同一把尺子排优先级。

好家伙，终于有人把「这个按钮感觉怪怪的」往可复核的方向拉了一步。

先把边界说在前面。我没有拿真实项目完整跑过这套流程，不能给你编一个改完转化率起飞的故事。下面的安装方法、六个检查域和高优先级触发条件，都来自它的官方公开说明。文中的交付前示例，是根据该说明整理的检查路径，不是仓库作者承诺的自动修复效果。

它不是美化器，更像一次 UI 体检的总调度

仓库给出的安装入口很直接。

npx skills add jakubkrehel/skills

装好后，在你的 AI 编程工具里指定 better-interface 做一次完整界面审查。不同客户端唤起技能的写法不一样，别为了复制一条看上去很酷的命令，把不存在的参数塞进终端。仓库的 README 只明确给出了安装方式，具体怎么调用，跟着你当前工具的技能入口走就行。

它会先问一个非常朴素的问题，你到底让我看哪一段。

是一张注册页，一个付款流程，还是整个后台？如果范围大到没法认真看，它要求缩到一条完整路径，并且把没覆盖的状态写出来。空状态、加载状态、报错状态、窄屏状态，能看到就看，没看就老老实实写没看。

这个习惯比想象中值钱。很多评审报告把主页面说得头头是道，弹窗一打开，焦点丢了，移动端一缩，底部操作条没了。报告依旧能写得很漂亮，用户照样会卡住。厉害了，文档把这个漏洞直接堵在第一步。

本文根据官方工作流整理的六域复查路径，不代表一次真实项目的审查结果。

六条检查线，分别抓不同的漏网之鱼

第一条是无障碍。它看的不是代码里有没有堆 ARIA，而是控件有没有可访问名称，键盘能不能到，焦点能不能看见，动效会不会在用户选择减少动态效果后继续乱跑。

第二条是布局。阅读顺序有没有被视觉花活打乱，屏幕变窄后文字和操作会不会互相抢位置，翻译成更长的语言后还能不能撑住。你大概见过那种桌面端一切正常，手机上主按钮被底部浮层压住的页面。用户不会夸你布局复杂，他只会退出。

第三条是文案。一个报错如果只写「失败了」，用户要怎么回来？一个删除按钮如果和普通保存按钮长得差不多，用户怎么判断风险？这类问题不靠多一层阴影解决，得让标签、状态和恢复路径自己说清楚。

第四条是排版。字号、层级、断行、截断、数字和中英文混排，平时看着都是小事。可信息一长，最先崩的往往就是这些小事。被截断的值若没有办法看全，在这套规则里不是小瑕疵，而是必须上报的问题。

第五条是颜色。这里不只是问配色顺不顺眼，还要看文字对比度够不够，状态是否只靠红绿区分。一个提示只换颜色、不加图标或文字，屏幕再漂亮，也是在把理解成本塞给用户。

收尾看 UI 打磨，图标、表面、阴影、对齐、动效这些更接近大家口中的精致感。把它放在收尾，不是说它不重要，而是不要让一颗漂亮圆角把前面五类问题遮住。

把「看着不对」落成位置、用户影响、证据和修复方向，讨论才有落点。

交付前，拿它替换那句「看着不错」

假设你刚做完一个包含主操作、次操作和删除入口的设置页。传统复查很容易只留下几句感受，间距可不可以再松一点，按钮颜色能不能更亮一点。

这套流程要求的结果不太一样。它会优先追问，删除入口是否有明确区分和确认或撤销路径。主操作能否被键盘依次到达。焦点环有没有被自定义样式抹掉。320 像素宽度或 200% 缩放下，三个操作会不会重叠。报错出现后，用户有没有明确的恢复动作。

你会发现，前一种讨论可以无限拉长，后一种讨论能落到文件、组件、状态和验收动作上。官方工作流还要求每条发现带上 路径:行号，运行时问题要看渲染结果，不能拿源码猜视觉。这个要求有点子牛逼，因为它切断了最常见的偷懒方式，截图证明不了代码问题，代码也不能替你证明窄屏没溢出。

它对修复顺序也很克制。能删除的先删除，原生控件能完成的就别手搓一套，项目已有令牌和组件能复用就别新增一串数值，实在不行再加新包装层或新属性。很多 UI 问题之所以越改越臃肿，不是没人会写 CSS，而是第一反应永远是多包一层。

可以把这张检查卡放进设计评审或合并前的验收流程。

不过，它也不是万能遥控器。

如果你要审的是一组未提交改动、某个分支或一个 PR，官方建议转去 interface-review，不要拿这个总调度去猜差异范围。如果页面没有真正跑起来，就不要下视觉结论，报告里该写「未验证」就写「未验证」。它更不能替产品决定该不该做一个功能，或者替设计师给品牌气质拍板。

我自己的判断是，适合把它放在页面已经能跑、准备交付的那一刻。别等反馈变成「感觉哪里不对」，才开始满屏找像素。先把范围锁住，再让六条检查线过一遍，把修复集中在那些能解释清楚用户损失的地方。

页面不一定因此马上变得惊艳，但至少不会把最隐蔽的门槛留给用户去撞。

你们团队交付页面时，最常漏的是窄屏、键盘操作、错误状态，还是那句谁也说不清的「感觉不对」？