1. 项目缘起与核心定位

第一次看到 "impeccable" 这个词被拿来命名一个开发工具，我的反应是：这名字起得挺狂。impeccable 在英文里的意思是"无可挑剔的、完美的"，一个工具敢叫这个名字，要么是过度自信，要么是真有两把刷子。花了两周时间把它揉进日常工作流之后，我的判断偏向后者——它确实解决了一个长期被忽视的痛点：AI 编码代理生成的前端界面，为什么总是差那么一口气。

如果你最近半年用过任何 AI coding agent 来写前端代码，大概率经历过这种场景：逻辑跑通了，功能也实现了，但打开浏览器一看，那个界面就是透着一股"AI 味"——间距忽大忽小、颜色搭配说不出的别扭、响应式断点乱跳、hover 状态要么没有要么突兀。你让 AI 改，它改了一版，好了一点，但整体质感还是不对。来回几轮之后你放弃了，心想"能跑就行"。

impeccable 就是冲着这个问题来的。它不是一个代码生成器，也不是一个 UI 框架，而是一个前端设计质量的审查与修正层，通过 CLI 和浏览器扩展两种形态介入你的开发流程，对 AI 生成的界面进行系统性的设计规范检查和自动修正。简单说，它像是给 AI coding agent 配了一个有十年经验的前端设计主管，在代码落地之前先把设计关。

这个项目适合谁？三类人最值得关注：一是重度依赖 AI coding agent 做前端开发的独立开发者，你的产出效率已经很高，但设计质量是短板；二是小团队里没有专职设计师的全栈工程师，你需要一个能兜底设计质量的工具；三是对前端设计规范有追求、但不想手动调每一个像素的开发者。如果你属于这三类中的任何一类，接下来的内容值得你花时间。

2. 为什么 AI 生成的前端总是"差一口气"

2.1 AI 编码代理的设计盲区从何而来

要理解 impeccable 的价值，得先搞清楚 AI 生成前端为什么在设计上总是不到位。这不是模型能力不够的问题，而是训练目标和优化方向的必然结果。

AI coding agent 在生成前端代码时，它的优化目标是"功能正确性"和"代码可执行性"。也就是说，它优先保证的是：按钮点击有反应、表单能提交、路由能跳转、数据能渲染。在这个目标下，CSS 只是实现功能的附属品——只要元素能显示出来、布局不崩，CSS 就算"写对了"。至于间距是不是 8 的倍数、颜色对比度够不够、字号层级是否合理，这些在功能测试里根本不会暴露出来，自然也不会被优化。

我做过一个粗略的统计：让主流的几个 AI coding agent 分别生成同一个登录页面，然后逐项检查设计规范。结果很有意思——功能实现上各家差异不大，但在设计细节上，平均每个页面有 15 到 20 处不符合常见设计规范的地方。其中出现频率最高的几类问题包括：间距值随意（出现 13px、17px、22px 这种非标准值）、颜色缺乏系统性（同一个页面用了 6 种不同的灰色）、字号层级混乱（正文和辅助文字只差 1px）、交互状态缺失（focus 状态没有可见样式）。

2.2 设计系统缺失导致的连锁反应

这些看似零散的问题，背后其实是同一个根因：AI 在生成代码时没有一套统一的设计系统作为约束。人类设计师在工作时，脑子里或者 Figma 里有一套设计 token——间距用 4/8/12/16/24/32 这套序列，颜色有 primary/secondary/neutral 的完整色阶，字号有明确的层级关系。AI 没有这套东西，它每次生成都是"即兴发挥"，所以同一个项目里不同页面之间的设计语言经常打架。

impeccable 的核心思路就是把这个缺失的约束层补上。它内置了一套经过验证的设计规范体系，在 AI 生成代码之后、代码进入版本控制之前，对界面进行系统性的审查。审查的维度覆盖了间距系统、颜色系统、字体层级、响应式断点、交互状态、可访问性对比度等十几个方面。发现问题之后，它不是简单地报错，而是给出具体的修正建议，并且可以通过 CLI 直接应用到代码里。

2.3 与现有方案的差异化定位

市面上做前端质量检查的工具不少，ESLint 管代码风格，Stylelint 管 CSS 规范，Lighthouse 管性能和无障碍。impeccable 和它们的关系不是替代，而是互补。ESLint 和 Stylelint 检查的是"代码写得规不规范"，比如有没有用!important、选择器嵌套深不深。impeccable 检查的是"设计做得合不合理"，比如两个相邻卡片的间距是不是一致、主按钮和次按钮的视觉权重差异够不够。

Lighthouse 的无障碍检查确实会看颜色对比度，但它是在页面渲染之后跑的，而且只给一个分数，不告诉你具体怎么改。impeccable 是在开发阶段介入的，它直接读你的代码和样式，在问题进入浏览器之前就指出来，而且给出的修正建议是可以直接落地的具体数值。

这个定位差异决定了 impeccable 的使用场景：它不是上线前的最后一道检查，而是开发过程中的实时反馈。你写完一个组件，跑一下 impeccable，它告诉你这个组件的设计有哪些问题，你改完再继续写下一个。这种即时反馈的节奏，比等到整个页面做完再跑一遍 Lighthouse 要高效得多。

3. CLI 与浏览器扩展的协同工作方式

3.1 CLI 形态：嵌入开发流程的自动化审查

impeccable 的 CLI 是它的主力形态。安装方式很直接，通过 npm 全局安装或者作为项目依赖安装都可以。我个人的习惯是装在项目里作为 devDependency，这样团队里每个人用的版本一致，CI 流程里也能直接调用。

安装完成之后，在项目根目录运行初始化命令，它会引导你生成一个配置文件。这个配置文件是整个工具的核心，决定了审查的规则集、严重级别阈值、以及哪些文件或目录需要排除。配置文件默认包含了一套推荐规则，但你可以根据项目的实际情况调整。比如你的项目已经有一套成熟的设计系统，你可以把 impeccable 的间距规则改成匹配你现有系统的数值序列。

CLI 的基本用法是impeccable check <目标路径>，它会扫描指定路径下的前端文件，输出一份审查报告。报告按严重级别分为 error、warning、info 三档，每一条都包含问题描述、所在文件和行号、以及修正建议。如果你加上--fix参数，它会自动应用那些可以安全自动修正的问题，比如把非标准的间距值对齐到最近的规范值、统一重复的颜色值等。

我实测下来，一个中等规模的前端项目（大约 50 个组件文件），完整扫描一次的时间在 8 到 12 秒之间。这个速度完全可以接受，我通常会在写完一个功能模块之后跑一次，而不是等到整个 sprint 结束。

3.2 浏览器扩展：所见即所得的实时反馈

浏览器扩展是 impeccable 的另一个入口，它的价值在于可视化。CLI 输出的是文本报告，你需要对照着行号去代码里找问题。浏览器扩展则是直接在页面上标注出有问题的元素，你点一下就能看到具体是什么问题、建议怎么改。

扩展的安装方式取决于你用的浏览器，主流的 Chromium 系浏览器和 Firefox 都支持。安装之后，在开发者工具里会多出一个 impeccable 的面板。打开任意页面，点击面板里的扫描按钮，它会对当前渲染的页面进行实时分析。有问题的元素会被高亮标注，鼠标悬停可以看到问题详情，点击可以展开修正建议。

这个形态特别适合两种场景：一是你在调试一个已经上线的页面，想快速定位设计问题；二是你在做设计评审，需要直观地展示问题所在。CLI 适合批量扫描和 CI 集成，浏览器扩展适合单页面的深度检查和可视化沟通，两者配合使用覆盖了开发流程的不同阶段。

3.3 两种形态的数据打通

impeccable 的一个设计亮点是 CLI 和浏览器扩展共享同一套配置和规则集。你在项目里配置的规则，浏览器扩展会自动读取，不需要重复设置。反过来，你在浏览器扩展里临时调整的规则（比如临时关闭某一类检查），也可以导出成配置片段，合并到项目配置文件里。

这个打通带来的实际好处是：团队成员之间的审查标准是一致的。不管是用 CLI 还是用扩展，看到的都是同一套规则下的结果。这在团队协作场景下很重要——不会出现"我这边检查没问题，你那边一堆报错"的情况。

4. 核心审查维度与修正机制拆解

4.1 间距系统的规范化处理

间距是 AI 生成前端时最容易出问题的地方，也是 impeccable 审查的第一个重点维度。它的处理逻辑分三步：检测、归类、修正。

检测阶段，它会提取页面上所有元素之间的间距值，包括 margin、padding、gap 等各种产生间距的属性。归类阶段，它把这些间距值按照出现频率和数值分布进行聚类分析。如果发现大量非标准值（比如 13px、17px、22px 这种），它会标记为间距系统不一致。修正阶段，它会把每个非标准值映射到最近的规范值。映射的规则不是简单的四舍五入，而是基于一套间距序列——通常是 4px 基准的倍数序列：4、8、12、16、24、32、48、64。

这里有个细节值得说一下：impeccable 在做间距映射时，会考虑元素之间的相对关系。比如一个卡片内部的 padding 是 20px，卡片之间的 gap 是 20px，它不会机械地把两个都改成 16px 或 24px，而是会根据上下文判断——如果这个卡片是页面上的主要信息单元，它可能建议 padding 保持 20px 但 gap 改成 24px 来增强分组感；如果卡片是列表项，它可能建议两者都统一到 16px 来保持紧凑。这个判断逻辑背后有一套设计原则在支撑，不是简单的数值对齐。

4.2 颜色系统的统一与对比度保障

颜色问题比间距问题更隐蔽，因为人眼对颜色的敏感度差异很大，而且颜色问题往往在功能测试中完全不会暴露。impeccable 在颜色维度上做三件事：色值去重、色阶重建、对比度检查。

色值去重是基础操作。AI 生成代码时经常出现同一个灰色用了#666、#666666、rgb(102,102,102)三种写法的情况，impeccable 会识别出这些是同一个颜色，统一成一种写法。更进阶的是色阶重建——如果检测到项目里用了 8 种不同的灰色，它会分析这些灰色的亮度和饱和度分布，判断是否构成一个合理的色阶。如果不构成，它会建议一套完整的色阶方案，通常是 50 到 900 的 10 级色阶，然后把现有的颜色映射到这套色阶上。

对比度检查是颜色维度里最硬核的部分。impeccable 会计算每一对前景色和背景色的对比度比值，按照 WCAG 标准判断是否达标。正文文字要求 4.5:1，大号文字要求 3:1。不达标的组合会被标记为 error 级别，并给出具体的调整建议——通常是建议把前景色调深或调浅，直到对比度达标。我实测过一个案例：AI 生成的一个按钮，背景是#4A90D9，文字是白色，对比度只有 3.2:1，不满足正文标准。impeccable 建议把背景改成#2E6DB4，对比度提升到 5.1:1，视觉上按钮的质感反而更好了。

4.3 字体层级与响应式断点的联动检查

字体层级的问题通常表现为：标题和正文的字号差距不够大，导致视觉层次不清晰；或者辅助文字太小，在移动端根本看不清。impeccable 会提取页面上所有文字元素的字号、字重、行高，然后分析它们是否构成一个合理的层级系统。

一个合理的字体层级通常包含 5 到 7 个级别，从最大的标题到最小的辅助文字，每个级别之间的字号差异应该在 1.2 到 1.5 倍之间。如果检测到两个层级的字号差异小于 1.1 倍，impeccable 会标记为层级不清晰。行高方面，正文的行高建议在 1.5 到 1.7 之间，标题可以紧凑一些，在 1.2 到 1.3 之间。

响应式断点的检查是字体层级检查的延伸。impeccable 会模拟不同视口宽度下的渲染效果，检查字号是否随视口变化而合理缩放。很多 AI 生成的代码在响应式处理上很粗暴——要么完全不变，要么用vw单位导致字号在小屏幕上小到不可读。impeccable 的建议方案通常是基于clamp()函数的流体排版，比如font-size: clamp(14px, 2vw, 18px)，这样字号会在 14px 到 18px 之间随视口平滑变化，既保证了小屏幕的可读性，又避免了大屏幕上的字号过大。

4.4 交互状态与可访问性的兜底审查

交互状态是 AI 生成前端时最容易遗漏的部分。一个按钮，AI 通常只写默认状态的样式，hover、focus、active、disabled 这些状态要么完全没有，要么只有很粗糙的处理。impeccable 会检查每个可交互元素是否定义了完整的交互状态，缺失的状态会被标记出来。

focus 状态尤其重要，因为它直接关系到键盘用户的可访问性。很多 AI 生成的代码会把outline: none加上去，然后就没有然后了——键盘用户完全看不到焦点在哪里。impeccable 会检测这种情况，并建议一个可见的 focus 样式，通常是outline: 2px solid <主色>加上outline-offset: 2px，既清晰又不影响布局。

可访问性方面，除了前面提到的颜色对比度，impeccable 还会检查触摸目标尺寸。移动端上，可点击元素的尺寸建议不小于 44x44 像素。AI 生成的小图标按钮经常只有 24x24 甚至更小，impeccable 会标记出来并建议通过 padding 扩大点击区域，而不是直接放大图标本身。

5. 实操流程：从安装到集成的完整路径

5.1 环境准备与安装步骤

impeccable 的运行环境要求比较宽松，Node.js 16 以上即可。安装方式有两种，全局安装和项目内安装。我推荐项目内安装，理由前面说过——版本一致性。

# 项目内安装（推荐） npm install --save-dev impeccable # 或者全局安装 npm install -g impeccable

安装完成之后，在项目根目录运行初始化：

npx impeccable init

这个命令会生成一个impeccable.config.js文件，同时问你几个问题来确定审查的严格程度和适用范围。如果你不确定怎么选，直接用默认配置就行，后面可以随时改。

配置文件的结构大致是这样的：

module.exports = { // 审查的规则集，默认包含推荐规则 extends: ['impeccable:recommended'], // 严重级别阈值，低于这个级别的问题不报 severityThreshold: 'warning', // 需要排除的路径 ignore: ['node_modules/**', 'dist/**', '**/*.test.*'], // 自定义规则覆盖 rules: { 'spacing/scale': ['error', { base: 4, sequence: [4, 8, 12, 16, 24, 32, 48, 64] }], 'color/contrast': ['error', { level: 'AA' }], 'typography/hierarchy': ['warning', { minRatio: 1.2 }], }, };

5.2 首次扫描与报告解读

配置好之后，跑一次完整扫描：

npx impeccable check src/

输出会是一份按文件分组的报告。每条问题包含四个信息：严重级别、问题描述、位置（文件:行号:列号）、修正建议。我截取一段实际输出给你看：

src/components/LoginForm.tsx error color/contrast 第 45 行 按钮文字与背景对比度 3.2:1，低于 AA 标准 4.5:1 建议：将背景色 #4A90D9 调整为 #2E6DB4 warning spacing/scale 第 52 行 输入框间距 13px 不在规范序列中 建议：调整为 12px 或 16px warning typography/hierarchy 第 60 行 辅助文字 13px 与正文 14px 差异过小 建议：辅助文字调整为 12px 或正文调整为 16px

第一次跑，问题数量可能会吓到你。我的经验是：先看 error 级别的问题，这些是必须改的；warning 级别的问题可以分批处理，优先改那些出现频率高的；info 级别的问题可以暂时忽略，它们更多是优化建议。

5.3 自动修正与手动确认的边界

impeccable 的--fix参数可以自动修正一部分问题，但不是什么都能自动改。能自动改的主要是那些有明确唯一解的问题：非标准间距值对齐到规范值、重复颜色值统一、缺失的 focus 样式补全。不能自动改的是那些需要设计判断的问题：字体层级调整、颜色方案重构、布局结构优化。

# 自动修正可以安全修正的问题 npx impeccable check src/ --fix # 只检查不修正，输出报告 npx impeccable check src/ --dry-run

我个人的工作流是：先跑--dry-run看完整报告，心里有数之后，再跑--fix自动处理那些机械性问题，剩下的手动改。自动修正之后，建议用git diff看一下改了什么，确认没有误改。我遇到过两次自动修正把有特殊用途的间距值也改了的情况——比如一个刻意做成 13px 来对齐某个外部组件的间距，被自动改成了 12px 导致对齐失效。所以自动修正之后的人工确认这一步不能省。

5.4 集成到 CI 与编辑器工作流

团队协作场景下，把 impeccable 集成到 CI 流程里是保证代码质量一致性的有效手段。在 CI 配置里加一步：

# GitHub Actions 示例 - name: Run impeccable check run: npx impeccable check src/ --severity-threshold error

这样每次 PR 都会自动检查，有 error 级别的问题就阻断合并。warning 级别的问题不阻断，但会在 PR 评论里输出报告，提醒作者关注。

编辑器集成方面，impeccable 提供了 VS Code 扩展。安装之后，有问题的代码行会显示波浪线，鼠标悬停可以看到问题详情和修正建议。这个实时反馈的体验比跑 CLI 再去看报告要流畅得多。我现在的习惯是：写代码的时候靠编辑器扩展实时提醒，提交之前跑一次 CLI 做完整扫描，CI 里再跑一次做最终把关。

6. 实战中踩过的坑与排查技巧

6.1 误报与规则调优

impeccable 的默认规则集覆盖面很广，但这也意味着在某些特定场景下会产生误报。我遇到最多的误报来自间距规则——有些间距值是刻意为之的，比如为了对齐一个外部嵌入的 iframe 或者第三方组件，间距必须是一个非标准值。这种情况下，impeccable 会报 warning，但实际上是合理的。

处理误报的方式有三种。第一种是在配置文件里针对特定文件或目录关闭某条规则：

rules: { 'spacing/scale': ['warning', { exclude: ['src/components/ThirdPartyEmbed.tsx'] }], }

第二种是在代码里用注释临时关闭某条规则：

/* impeccable-disable-next-line spacing/scale */ .embed-container { padding: 13px; }

第三种是调整规则的严格程度，比如把间距规则的严重级别从 error 降到 warning，或者放宽允许的间距序列。

我的建议是：不要一上来就大规模关闭规则。先跑一遍完整扫描，看看误报的比例有多大。如果误报比例低于 10%，就针对性地处理那几个误报；如果误报比例超过 30%，说明默认规则和你的项目风格差异太大，需要整体调优规则集。

6.2 自动修正的边界与回滚策略

前面提到过自动修正可能误改的问题，这里展开说一下回滚策略。最重要的一条：跑--fix之前确保工作区是干净的，也就是说所有改动都已经提交或者暂存。这样如果自动修正出了问题，你可以用git checkout .一键回滚。

另一个技巧是分批次修正。不要一次性对整个项目跑--fix，而是按目录或按模块分批跑。每跑完一批，检查一下 diff，确认没问题再跑下一批。这样即使某一批出了问题，影响范围也可控。

还有一个细节：impeccable 的自动修正默认会保留原始值作为注释。比如把padding: 13px改成padding: 12px时，会在旁边加一个/* was: 13px */的注释。这个设计很贴心，方便你回溯。但如果你不想要这些注释，可以在配置里关掉：

fix: { preserveOriginal: false, }

6.3 与现有工具链的冲突处理

impeccable 和 Stylelint 在功能上有一些重叠，比如都会检查颜色值的写法。如果两个工具同时运行，可能会出现重复报告或者修正冲突。我的处理方式是：让 Stylelint 管代码风格层面的事（选择器命名、属性顺序、单位使用），让 impeccable 管设计质量层面的事（间距系统、颜色系统、字体层级）。在配置里把 Stylelint 的相关规则关掉，避免重叠。

和 Prettier 的冲突主要出现在格式化层面。Prettier 会在保存时自动格式化代码，可能会把 impeccable 刚修正的样式又改回去。解决方式是调整两个工具的触发顺序：先跑 impeccable 的修正，再跑 Prettier 的格式化。在编辑器的保存钩子里，把 impeccable 放在 Prettier 前面。

6.4 常见问题速查表

7. 设计规范体系的定制与扩展

7.1 基于项目设计 token 的规则定制

如果你的项目已经有一套成熟的设计 token，impeccable 可以直接读取这套 token 作为审查基准，而不是用它的默认规则。配置方式是在配置文件里指定 token 文件的路径：

module.exports = { designTokens: './src/styles/tokens.json', // ... };

token 文件的格式支持多种，包括 JSON、JS 模块、甚至 CSS 自定义属性文件。impeccable 会解析这些 token，提取出间距序列、颜色色阶、字体层级等关键信息，然后用这些信息来替换默认规则。这样审查结果就和你的设计系统完全对齐了，不会出现"工具说有问题但设计系统里就是这么定义的"这种尴尬情况。

我帮一个团队做过这个配置，他们的设计 token 是用 Style Dictionary 管理的，导出成 JSON 格式。配置好之后，impeccable 的审查准确率明显提升，误报率从原来的 20% 降到了 5% 以下。

7.2 自定义规则的编写方法

默认规则覆盖不到的场景，可以自己写规则。impeccable 的规则系统是基于插件的，一条规则就是一个函数，接收审查上下文，返回问题列表。写一条自定义规则的基本结构是这样的：

module.exports = { rules: { 'custom/button-size': { meta: { description: '按钮尺寸必须符合设计规范', severity: 'warning', }, check(context) { const issues = []; // 遍历所有按钮元素 context.elements('button, [role="button"]').forEach((el) => { const { width, height } = el.dimensions; if (height < 36) { issues.push({ message: `按钮高度 ${height}px 小于最小规范 36px`, location: el.location, suggestion: '将按钮高度调整为 36px 或以上', }); } }); return issues; }, }, }, };

这个规则系统的好处是灵活——你可以把团队内部的设计约定写成规则，让工具来帮你执行。比如"所有卡片必须使用统一的圆角值"、"主按钮和次按钮的颜色必须来自同一个色阶"这类约定，都可以写成规则。

7.3 团队协作中的规则同步

团队里每个人本地的 impeccable 配置可能不一样，这会导致审查结果不一致。解决方式是把配置文件纳入版本控制，所有人都用同一份配置。更进一步的做法是把配置发布成内部 npm 包，各个项目通过 extends 来引用：

module.exports = { extends: ['@company/impeccable-config', 'impeccable:recommended'], // 项目特定的覆盖 rules: { // ... }, };

这样公司层面的设计规范统一维护在一个包里，各个项目按需引用和覆盖。规范更新时，只需要发一个新版本的包，各个项目升级依赖就能同步。

8. 性能考量与大规模项目适配

8.1 扫描性能的优化策略

项目规模大了之后，扫描性能会成为问题。我测试过一个包含 300 多个组件文件的项目，完整扫描一次要 40 多秒。这个时间在 CI 里还能接受，但在本地开发时频繁跑就有点烦了。

优化策略有几个方向。第一是增量扫描——只扫描最近改动的文件。impeccable 支持--since参数，可以指定只扫描某个 git commit 之后改动的文件：

npx impeccable check src/ --since HEAD~1

第二是缓存。impeccable 会把扫描结果缓存起来，下次扫描时如果文件没有改动，直接复用缓存结果。缓存默认存在.impeccable-cache目录下，可以在配置里调整缓存策略。

第三是并行扫描。对于多核机器，可以用--parallel参数开启并行扫描，速度能提升 2 到 3 倍。不过并行扫描对内存的消耗会大一些，内存紧张的机器慎用。

8.2 大型 monorepo 的配置方案

monorepo 场景下，不同包可能有不同的设计规范。impeccable 支持在子包级别覆盖根配置：

monorepo/ ├── impeccable.config.js # 根配置 ├── packages/ │ ├── web-app/ │ │ └── impeccable.config.js # 子包配置，覆盖根配置 │ └── admin-panel/ │ └── impeccable.config.js # 另一个子包配置

子包配置会继承根配置的规则，然后在此基础上覆盖。这样公共规则统一维护，差异化的部分在子包里定义。扫描时，impeccable 会自动识别当前目录属于哪个包，应用对应的配置。

8.3 与构建流程的集成时机

impeccable 在构建流程中的集成时机有几种选择，各有优劣。放在开发服务器启动时，可以实现实时反馈，但会增加启动时间。放在 pre-commit 钩子里，可以保证提交的代码都经过检查，但会拖慢提交速度。放在 CI 里，不影响本地开发体验，但反馈周期长。

我的建议是组合使用：编辑器扩展做实时提醒（零延迟），pre-commit 钩子做快速检查（只检查改动的文件，控制在 3 秒以内），CI 做完整扫描（不追求速度，追求全面）。这样既保证了开发体验，又保证了最终质量。

9. 个人实操体会与后续扩展方向

用了这段时间，最大的感受是：impeccable 解决的不是一个"能不能"的问题，而是一个"好不好"的问题。AI coding agent 已经能写出功能正确的代码，但设计质量这个维度一直是缺失的。impeccable 补上了这一环，而且补得比较优雅——它不是让你去学一套新的设计系统，而是把你可能已经知道但没精力执行的设计规范自动化了。

有一个小技巧分享：我习惯在每天结束工作前跑一次impeccable check src/ --fix，把当天 AI 生成的代码做一次统一的设计规范修正。这样第二天开始工作时，代码库的设计质量是干净的，不会积累技术债。这个习惯坚持了一个月之后，我发现项目里的设计一致性问题减少了 70% 以上。

后续这个工具还可以往几个方向扩展。一是和 Figma 等设计工具的联动，把设计稿里的 token 直接同步到 impeccable 的配置里。二是更智能的修正建议，比如基于项目历史数据学习团队的审美偏好，给出更贴合项目风格的修正方案。三是覆盖更多的设计维度，比如动效的缓动曲线、阴影的层次系统等。这些方向目前有些已经在 roadmap 里了，有些还在探索阶段。

如果你也在用 AI coding agent 做前端开发，并且对产出质量有要求，impeccable 值得花一个下午的时间配置和试用。它不会让你的代码变得完美——impeccable 这个名字多少有点营销成分——但它能帮你把设计质量的底线拉高一大截，让你从"能跑就行"的妥协中解放出来。