AI Design Check：让编码 Agent 改完界面后跑一遍可解释的设计规则

先给结论：ai-design-check 是一个给 AI 编码工作流用的 Node.js 检查工具，尝试在代码审查和构建流程里发现界面生成后常见的无障碍、排版、文案、响应式和组件一致性问题。项目 README 列出 95 条规则，其中 57 条由 checker 自动检测，另外 38 条标为 review，留给人或 Agent 看屏判断。它适合作为 PR 前的设计卫生检查和提示线索，不是可以用一个分数替代设计评审的质量认证工具。

从报告到修复的工作流

最短试用是运行 npx @enmera/ai-design-check 扫描项目源码，输出文件、行号、严重级别、规则 ID 和修复方向；再安装仓库提供的 skill，让 Claude Code、Cursor 或 Codex 根据项目用途修正界面，并把修复前后 findings 数量对照。除了主检查器，它还提供 inventory 查看重复控件样式，narrow 用 Chrome 检查手机宽度的溢出和截断，system 从品牌参数生成设计 token，story 输出修复前后视频。后几项会用到本地 Chrome 或 ffmpeg，所以“零依赖”主要描述基础 checker 包，不等于所有命令都不需要环境准备。

规则例子包括文字不能在 320 像素视口被裁切、保留键盘焦点样式、按钮文字应说明动作、减少装饰性大写标签、遵守项目已有字阶与圆角尺度。配置文件可以指定 spacing 基础值、共享组件目录、例外列表和规则等级。v0.10.1 在 11 月 2 日发布，新增读取项目自身 spacing scale、更多手机浏览器约束，以及 stress 模式下长文本和大数字检查；适用于同时维护桌面与手机界面的团队。

规则怎样产生，不能说明什么

项目的 Research 文档记录了规则集与 16 个设计样例的对照：12 个 Dribbble dashboard 和 4 个 Behance 案例。作者说明这只是一次人工观察，不是有代表性的统计研究；规则来自设计团队在自有产品中遇到的问题，并参考了被评为较好的界面。因而有些项目规则带有明确风格判断，例如避免渐变按钮、过重阴影或大写小标题。它们可以帮助团队减少常见问题，但不适合当作跨产品的审美真理。建议根据品牌和用户测试设置 allowlist，而不是为了 CI 变绿机械删除功能。

自动检查也有边界：源代码中的 class 与规则匹配能发现一部分问题，但真实布局、阅读顺序、状态完整性仍需要渲染页面和人工判断。仓库 README 明确把 38 条规则交给 review；检查器不会自行证明修复没有破坏产品行为。对 Web 团队，建议先接入非阻塞报告，清理误报后再将 error 级规则加入 CI。SwiftUI 和 Jetpack Compose 检查可用于跨端复核，但也应在真实设备或模拟器上检查系统字体、深色模式和长文案。

结论：如果团队已经用 Agent 改 UI，ai-design-check 可以给“看起来差不多”的结果增加一轮具体、可定位的规则反馈，尤其是手机布局和可访问性问题。它的 200 个星与两天前的 v0.10.1 表明这是非常早期的工具；规则有效性仍需要在自己的组件库和实际设备上验证。项目采用 MIT 许可，使用方式轻量，但 Agent 修复出来的结果仍须由团队负责。

参考来源

1. enmerasoftware/ai-design-check repository
2. ai-design-check README
3. ai-design-check rules
4. Research behind ai-design-check rules
5. ai-design-check changelog
6. ai-design-check v0.10.1 release
7. ai-design-check npm package
8. ai-design-check MIT license