UI 界面精修 是做什么的？
一个屏幕即使组织得再好，也可能感觉不完整：两列字段偏差了 17px、390px 手机屏幕上放着 88px 的盒子、每个字段后面跟着单位词、一个你用拇指点不到的链接。人们瞬间就能感觉到这些问题；而审查截图的人工智能模型却很少能发现它们。本技能先测量、再评判，只有在测量值达到标准时，才认为缺陷已修复。
输入
只询问缺失的信息。
- 目标。 一个 URL，或一个 HTML 文件，或仓库中的组件加上其渲染的 URL。你需要一种渲染方式；如果无法渲染任何内容，请如实说明，并仅依靠精修标准，将所有已测量的检查标记为“未测量”。
- 范围（可选）。一个 CSS 选择器，用于指定要打磨的页面部分，例如表单或
main。默认值：main，否则为body。 - 参考（可选）。用户认为更好的屏幕（URL、文件或截图）。同样对其进行测量，并将其作为外观的方向；切勿复制其品牌、内容或声明。
工作流程
1. 测量当前屏幕
运行捆绑脚本（需要 Node.js 和带 Chromium 的 Playwright；如果项目中没有，请使用 npm i -D playwright && npx playwright install chromium 安装）：
node <skill-dir>/scripts/measure.cjs <文件或URL> --out ui-polish/before [--scope "<选择器>"] [--primary "<选择器>"] [--hide "<选择器>,…"] [--profile form|content]
- 它在手机（390×844）和桌面（1366×900）宽度下渲染（存在错误发现时退出码为 1，用法错误时为 2，运行本身失败时为 3），将
measure.json写入--out目录（相对于当前目录解析），每个视口有两个截图：<视口>.png（第一个屏幕）和<视口>-scope.png（整个范围，包括首屏以下的部分），并打印每个发现及其选择器。共享同一原因的元素算作一个发现，带有计数和示例选择器；在手机和桌面相同的发现只打印一次，viewports中列出两者（在按视口过滤合并的发现时，使用viewports而不是viewport）。 - 默认情况下关闭脚本，以便测量静态布局；对于仅需 JavaScript 才能渲染的页面，请添加
--js。--offline会阻止除目标页面之外的所有网络请求（封闭环境）；--assets-only还允许远程字体、样式表和图像加载，适用于需要字体的本地副本，并会联系这些主机。 --hide在测量和截取截图前，对覆盖层（如 cookie 横幅或聊天启动器）设置display: none，以便它们既不遮挡截图，也不添加发现。一个--hide选择器如果没有匹配到任何元素，会打印一条警告。--profile content适用于文章和其他长文页面：它会跳过为表单步骤设计的检查（type-scale、action-distance、action-below-fold、dead-space）。默认为form。- 一次运行多个目标（
measure.cjs <页面1> <页面2> … --out 目录），每个目标放入目录/<slug>/，目录/summary.json会将跨页面重复的发现合并为一行，列出涉及的页面；一次性修复共享组件。逐页比较（--compare before/<slug>/measure.json after/<slug>/measure.json）。 - 检查项、阈值及其常规修复方法，请参考
reference/checks.md。错误会导致运行失败；警告需要修复或给出理由。 - 理由只需陈述一次，不必每次运行都重复：当前目录下的
ui-polish.config.json（或--config <文件>）列出了已接受的决策，例如{ "ignore": [{ "check": "text-size", "selector": ".eyebrow", "reason": "品牌副标题标签" }] }。匹配的发现会移至accepted并附上理由，会在自己的部分打印，且不影响退出码。只记录所有者做出的决策；切勿为了通过数字而添加。
如果提供了参考，则以相同方式将其测量到 ui-polish/reference。
2. 查看屏幕
打开截图（-scope.png 截图显示了整个范围），并逐一检查 reference/rubric.md 中的十点。编写一个评判表格，每个点一行（以及第 10 点的每个子检查一行）：通过、失败或不适用，定位的问题，以及修复方法。仅评判屏幕上的内容。测量值是精修标准的证据，而非替代品：零测量发现的屏幕仍可能在层次结构、标签和单位、分组或可信度上失败，而这些通常是人们最先注意到的失败。
3. 规划修复
列出每个测量发现和每个失败的精修标准点及其修复方法，按其所影响的元素分组。优先选择能一次性消除多个发现的结构性修复（例如，在双列网格中将标签置于字段上方可同时修复对齐、等宽、字段填充、标签位置和可访问名称），而不是逐个修补。按对屏幕使用者影响的大小排序。
4. 在源码中应用修复
编辑真实源码：仓库中的组件及其样式，或 HTML 文件。规则：
- 保留工作和内容。 相同的问题、相同的输入和单位、相同的操作、相同的品牌。不要为了通过检查而移除功能。
- 不编造任何内容。 不要添加屏幕未用文字说明的事实：步骤数、时间、价格、临床、法律或隐私声明。即便你从代码中推算出的值（进度条的
aria-valuenow、CSS 宽度、路由名称）也仍未明确说明；也应括起来。如果设计需要此类文案，请使用方括号占位符（问题 [n]/[N]、[~3] 分钟、[为何询问：…]），并列出供所有者填写。 - 使用现有系统。 复用项目已有的设计令牌、组件和间距比例；仅当没有匹配项时才添加新值。
- 保持功能正常。 每个控件必须仍能执行其原有功能（如果之前有损坏，则修复）。保持键盘焦点可见。
5. 重新测量直至通过
node <skill-dir>/scripts/measure.cjs <文件或URL> --out ui-polish/after [相同选项]
node <skill-dir>/scripts/measure.cjs --compare ui-polish/before/measure.json ui-polish/after/measure.json
比较步骤还会列出需要所有者审查的每段新文案，如果新文案包含 [方括号] 之外的数字（例如“第 2 步，共 [5] 步”：其中的 2 从未被声明过），则会以 invented-number 失败。
重复第 4–5 步，直到没有错误、所有剩余警告均已修复或给出理由，并且所有失败的精修标准点均已修复或给出理由，最多三轮。每轮都要在新截图上重新检查精修标准。零错误不代表完成：像 36px 触摸目标或尾部标签这样的警告，正是本技能存在要完成的细节。每轮都要打开新的截图：一项检查可能通过，但屏幕看起来更差，这算作回归。
6. 报告
- 手机和桌面尺寸下的前后对比截图。
- 比较输出：已修复、剩余（附理由）、新增和已接受（附配置文件中的理由）。
- 精修标准评判表的前后对比，对任何仍为失败的部分说明原因。
- 每个需要所有者填写的方括号占位符。
- 任何需要产品决策而非打磨的事项（将其交由设计评审或所有者处理）。
注意事项
- 截图会隐藏几何细节。 17px 的列偏移或 390px 屏幕上的 88px 字段，人在实际使用时一眼就能察觉，但在缩小的截图中不可见。信任数字来判断几何，用你的眼睛来判断平衡和层次。
- 尾部单位词通常是列不对齐的原因。 “英尺”和“英石”宽度不同，导致其后的所有内容偏移。应将标签放在字段上方。
- 对大文件进行小幅编辑，保持改动量小。 当源码是大型生成文件时，应将表单的标记和样式作为一个整体进行编辑，而不是逐个属性修补，否则布局永远不会改变。
- 数字通过就停止是经典错误。 几何只是精修的一半；另一半是精修标准（真正的标题、一个模式切换按钮而不是每个字段一个链接、询问敏感问题的原因、方向性）。
- 一个标记，多处发现。 在多个页面上重复出现的文本大小或触摸目标发现，通常来自一个设计系统标记或组件。在那里修复它，或者将所有者的决定记录在
ui-polish.config.json中，而不是逐页处理。 - 通过检查不是目标。 一个聚焦的屏幕，有一个清晰的标题、分组明确的字段和靠近的主要操作按钮，这才是目标。使用检查来证明你已经实现了这一点。
由 aictrl.dev 构建。 此技能教授工作流程；aictrl 将其落地——基于你的待办事项、团队标准和代码库知识图谱。了解详情 →