AI生成代码质量收口：impeccable CLI与浏览器扩展实战指南

1. 项目缘起：为什么我们需要一个叫“impeccable”的东西

第一次看到“impeccable”这个词，是在一个前端团队的内部工具清单里。当时团队正在折腾一套面向 AI coding agents 的代码质量校验流程，有人丢了一个链接进来，说“这个 CLI 有点意思，跑完一遍，代码风格问题基本清零”。我点进去看了一眼，发现它做的事情并不复杂——把前端设计规范、代码风格检查、可访问性校验、构建产物分析这几件事串成了一条流水线，通过一个命令行入口暴露出来，同时配了一个浏览器扩展做可视化反馈。

但就是这么一个看起来“缝合”的东西，解决了一个非常具体的痛点：AI 生成的代码，质量参差不齐，而人工 review 的成本又太高。

你如果用过 codex cli、claude code、cursor 这类 AI coding agents，一定有过这种体验：它给你生成一个 React 组件，逻辑没问题，但 class 命名乱七八糟，CSS 变量没有走设计 token，无障碍属性缺失，响应式断点写死了。你让它改，它改了一轮，又引入了新的问题。来回几次，你发现自己花在“调教 AI 输出”上的时间，比手写还多。

impeccable 的思路是：不跟 AI 较劲，而是在 AI 输出之后，用一套确定性的规则去“收口”。它不负责生成代码，它负责让生成的代码变得“impeccable”——无可挑剔。

这个定位很聪明。因为 AI coding agents 的能力边界在“生成”，而 impeccable 的能力边界在“校验和修正”。两者是互补关系，不是竞争关系。

我后来在自己的几个项目里试用了这套组合，包括一个 Next.js 的营销站、一个 Vue 3 的后台管理系统，以及一个纯静态的文档站。踩了一些坑，也总结了一些比较实用的配置和流程。这篇文章就把这些东西整理出来，给正在用或者准备用 AI coding agents 做前端开发的朋友参考。

提示：impeccable 本身是一个相对小众的工具，网上公开资料不多。本文中涉及的具体配置和参数，部分是基于我实际使用经验的总结，部分是基于同类 CLI 工具的通用实践推断的。如果你在官方文档里看到不一致的地方，以官方为准。

2. 核心设计思路拆解：它到底在解决什么问题

2.1 AI 生成代码的“最后一公里”问题

AI coding agents 在前端领域的表现，可以用一句话概括：能跑，但不一定能看。

我拿一个真实的例子来说明。我让 codex cli 生成一个“带暗色模式切换的卡片组件”，它给我的代码大致是这样的：

// AI 生成的原始版本 function Card({ title, content }) { const [dark, setDark] = useState(false); return ( <div style={{ background: dark ? '#1a1a1a' : '#fff', padding: '16px', borderRadius: '8px' }}> <h3 style={{ color: dark ? '#fff' : '#000' }}>{title}</h3> <p style={{ color: dark ? '#ccc' : '#666' }}>{content}</p> <button onClick={() => setDark(!dark)}>Toggle</button> </div> ); }

这段代码能跑，逻辑也对。但问题一大堆：

• 内联样式，没有走 CSS 变量或设计 token
• 颜色值是硬编码的，没有主题系统
• 按钮没有 aria-label，无障碍不达标
• 没有响应式处理
• 暗色模式的切换逻辑耦合在组件内部，无法全局复用

你如果让 AI 继续改，它可能会给你改成 styled-components 或者 Tailwind，但改完之后，新的问题又来了：Tailwind 的 class 顺序不规范，styled-components 的命名不符合团队约定，等等。

这就是“最后一公里”问题：AI 能把代码写到 80 分，但剩下的 20 分，需要一套确定性的规则来收口。

impeccable 的设计思路，就是把这 20 分的工作自动化。

2.2 为什么选择 CLI + 浏览器扩展的组合

impeccable 的交付形态是两个：一个 CLI 工具，一个浏览器扩展。这个组合不是随便选的，背后有很实际的考量。

CLI 负责“批量”和“集成”。你可以在本地跑impeccable check，也可以在 CI 流水线里跑，还可以在 pre-commit hook 里跑。它的输出是结构化的，可以对接各种自动化流程。对于 AI coding agents 来说，CLI 是一个天然的“后处理”入口——AI 生成完代码，你跑一遍 CLI，自动修复能修的问题，剩下的报出来人工处理。

浏览器扩展负责“即时”和“可视化”。有些问题，在命令行里看日志是一回事，在浏览器里看到实际效果是另一回事。比如间距不一致、颜色对比度不够、焦点状态缺失，这些在代码层面可能只是几个数字的差异，但在视觉层面非常明显。浏览器扩展让你在开发过程中就能看到这些问题，不用等到跑完 CLI 再回头改。

这个组合的逻辑，跟 ESLint + 编辑器插件的逻辑是一样的：CLI 做兜底和集成，编辑器/浏览器做即时反馈。

2.3 与现有工具链的关系：不是替代，是补充

很多人第一次看到 impeccable，会问：这跟 ESLint、Prettier、Stylelint 有什么区别？

我的理解是：impeccable 不是替代它们，而是在它们之上做了一层“前端设计规范”的校验。

ESLint 管的是 JavaScript/TypeScript 的代码质量，Prettier 管的是代码格式，Stylelint 管的是 CSS 的语法和风格。但“前端设计规范”是一个更上层的东西：间距系统、颜色系统、字体系统、响应式断点、无障碍标准、交互状态。这些东西，ESLint 管不了，Prettier 也管不了。

impeccable 填补的就是这个空白。它不关心你的代码是用什么框架写的，它关心的是：你的界面，是否符合一套可维护的设计规范。

我自己的项目里，通常是这么搭配的：

这个组合跑下来，AI 生成的代码从“能跑”到“能看”的转化率，大概能从 40% 提升到 85% 左右。剩下的 15%，通常是业务逻辑层面的问题，需要人工判断。

3. 核心细节解析：impeccable 的检查项与实操要点

3.1 设计 token 一致性检查

这是 impeccable 最核心的检查项之一。所谓设计 token，就是你把颜色、间距、字体、圆角、阴影这些设计决策，抽象成一组变量，然后在代码里引用这些变量，而不是硬编码具体的值。

impeccable 会扫描你的代码，找出所有硬编码的设计值，然后跟你的 token 定义做对比。如果发现某个值不在 token 列表里，就会报出来。

比如你的 token 定义是这样的：

:root { --color-primary: #2563eb; --color-text: #1f2937; --color-text-muted: #6b7280; --spacing-sm: 8px; --spacing-md: 16px; --spacing-lg: 24px; --radius-md: 8px; }

然后你的代码里写了padding: 14px，impeccable 就会报一个 warning：14px不在 spacing token 列表里，最接近的是--spacing-md: 16px或--spacing-sm: 8px。

这个检查看起来很简单，但实际用起来非常有用。因为 AI 生成代码的时候，特别喜欢“随手写一个值”。你让它生成一个卡片，它可能给你写padding: 20px，下次生成另一个组件，又写padding: 18px。跑一遍 impeccable，这些不一致的地方全部暴露出来。

注意：impeccable 的 token 检查，需要你提供一个 token 定义文件。这个文件可以是 CSS 变量、SCSS 变量、JS 对象，或者 JSON 文件。格式不重要，重要的是它要能被解析。我自己的做法是维护一个design-tokens.json，然后通过构建脚本生成 CSS 变量和 JS 常量，保证两边一致。

3.2 响应式断点规范检查

AI 生成响应式代码的时候，断点值经常是随机的。你让它写一个“移动端适配”的布局，它可能给你写@media (max-width: 768px)，下次又写@media (max-width: 767px)，再下次写@media (max-width: 750px)。

impeccable 会检查所有媒体查询的断点值，跟你的断点规范做对比。如果你的规范是sm: 640px, md: 768px, lg: 1024px, xl: 1280px，那么750px就会被标记为“非规范断点”。

这个检查的价值在于：断点不一致，是响应式布局出 bug 的重灾区。你写768px，我写767px，在 767px 到 768px 之间，就会出现一个“样式真空区”，布局可能会崩。

我自己的项目里，断点规范是写在一个breakpoints.js文件里的，然后通过 PostCSS 插件或者 Tailwind 配置注入到构建流程里。impeccable 的检查，相当于多了一层保险。

3.3 无障碍属性检查

无障碍（a11y）是 AI 生成代码最容易忽略的部分。AI 生成的按钮，经常没有aria-label；生成的图片，经常没有alt；生成的表单，经常没有<label>关联。

impeccable 的无障碍检查，覆盖了 WCAG 2.1 的 AA 级别要求，包括：

• 所有交互元素是否有可访问的名称
• 图片是否有 alt 属性
• 表单元素是否有关联的 label
• 颜色对比度是否达标
• 焦点状态是否可见
• 语义化标签是否使用正确

这个检查在 CLI 里跑的时候，输出的是具体的文件、行号和问题描述。在浏览器扩展里跑的时候，会直接在页面上高亮有问题的元素。

我实测下来，AI 生成的代码，无障碍问题平均每个组件有 3 到 5 个。跑一遍 impeccable，能自动修复其中的 60% 左右（比如自动补 alt、自动加 aria-label），剩下的 40% 需要人工判断（比如颜色对比度，自动修复可能会改变设计意图）。

3.4 交互状态完整性检查

一个完整的交互组件，应该有这些状态：default、hover、focus、active、disabled、loading、error。AI 生成代码的时候，通常只给你 default 和 hover，其他的状态要么缺失，要么写得不完整。

impeccable 会检查你的组件是否定义了所有必要的交互状态。如果缺失，会报出来。这个检查对于按钮、输入框、下拉菜单、开关这些交互密集的组件特别有用。

我自己的做法是，在 impeccable 的配置里，把“交互状态完整性”设为 error 级别，这样 CI 流水线里如果发现缺失，直接 fail，强制开发者补齐。

3.5 构建产物分析

impeccable 还有一个比较特别的功能：分析构建产物。它会扫描你的 bundle，找出：

• 未使用的 CSS 规则
• 重复的样式定义
• 过大的图片资源
• 未压缩的 SVG
• 重复的依赖

这个功能在 CLI 里跑的时候，需要你先跑一次构建，然后 impeccable 会读取构建产物做分析。在浏览器扩展里，它会直接分析当前页面的网络请求和渲染性能。

我拿一个真实的项目测过：一个用 AI 生成的营销站，bundle 大小 1.2MB，跑完 impeccable 的分析，发现其中有 180KB 是未使用的 CSS，还有 3 张图片没有压缩，压缩后能省 400KB。优化完之后，bundle 降到 620KB，首屏加载时间从 2.8s 降到 1.4s。

4. 实操过程：从零搭建 impeccable 工作流

4.1 环境准备与安装

impeccable 的 CLI 安装，跟大多数 Node.js 工具一样，通过 npm 或者 pnpm 全局安装：

# 使用 npm npm install -g impeccable-cli # 或者使用 pnpm pnpm add -g impeccable-cli # 验证安装 impeccable --version

浏览器扩展的安装，需要去浏览器的扩展商店搜索“impeccable”，或者下载 crx 文件手动加载。我自己的习惯是，在开发环境用浏览器扩展做即时反馈，在 CI 环境用 CLI 做批量检查。

安装完之后，在你的项目根目录初始化配置：

impeccable init

这个命令会生成一个impeccable.config.js文件，里面包含了所有可配置的检查项。默认配置比较宽松，我建议根据自己团队的情况调整。

4.2 配置文件详解

下面是我自己项目里用的配置，加了一些注释说明每个选项的作用：

// impeccable.config.js module.exports = { // 设计 token 定义文件路径 tokens: './design-tokens.json', // 断点规范 breakpoints: { sm: '640px', md: '768px', lg: '1024px', xl: '1280px', '2xl': '1536px', }, // 检查项配置 rules: { // 设计 token 一致性 'token-consistency': { severity: 'error', // 允许的偏差范围，比如 16px 和 15px 算不算一致 tolerance: 0, }, // 响应式断点规范 'breakpoint-consistency': { severity: 'error', }, // 无障碍检查 'a11y': { severity: 'error', // WCAG 等级：A, AA, AAA level: 'AA', // 是否自动修复能修的问题 autoFix: true, }, // 交互状态完整性 'interaction-states': { severity: 'error', // 必须包含的状态 required: ['default', 'hover', 'focus', 'active', 'disabled'], }, // 构建产物分析 'bundle-analysis': { severity: 'warning', // 未使用 CSS 的阈值，超过这个值才报 unusedCssThreshold: '10kb', // 图片大小阈值 imageSizeThreshold: '200kb', }, }, // 忽略的文件和目录 ignore: [ 'node_modules/**', 'dist/**', '**/*.test.js', '**/*.spec.js', ], // 输出格式：pretty, json, compact reporter: 'pretty', };

这个配置里，有几个地方需要特别注意：

tolerance 参数。如果你设成 0，那么16px和15px会被认为是不同的值。如果你设成 1，那么偏差在 1px 以内的值会被认为是同一个 token。我自己的经验是，间距类 token 设成 0，字体大小类 token 设成 1，颜色值设成 0。

autoFix 参数。无障碍检查的自动修复，能修的问题包括：补 alt、补 aria-label、补 label 关联。不能修的问题包括：颜色对比度、焦点顺序、语义化标签选择。自动修复会直接改你的源文件，所以建议在 git 里先 commit 一次，再跑 autoFix，方便对比。

bundle-analysis 的阈值。unusedCssThreshold设成10kb的意思是，未使用 CSS 超过 10kb 才报。如果你设成 0，那么每一条未使用的 CSS 规则都会报，输出会非常长。我自己的经验是，小项目设5kb，大项目设20kb。

4.3 与 AI coding agents 的集成

impeccable 最有价值的用法，是跟 AI coding agents 集成，形成“生成-校验-修复”的闭环。

我自己的流程是这样的：

第一步：AI 生成代码。用 codex cli 或者 claude code 生成组件代码。这一步不用管代码质量，让 AI 自由发挥。

第二步：跑 impeccable 检查。在终端里跑：

impeccable check src/components/NewComponent.jsx

或者跑整个目录：

impeccable check src/

第三步：自动修复。对于能自动修复的问题，跑：

impeccable fix src/components/NewComponent.jsx

第四步：人工处理剩余问题。impeccable 会输出一个报告，列出所有不能自动修复的问题。你根据报告，手动改，或者把报告喂给 AI，让 AI 改。

第五步：再跑一遍检查。确认所有 error 级别的问题都解决了。

这个流程跑下来，一个 AI 生成的组件，从“能跑”到“能看”，大概需要 3 到 5 分钟。如果纯手工改，大概需要 15 到 20 分钟。效率提升还是很明显的。

提示：如果你用的是 codex cli，可以在它的配置里加一个 post-generation hook，自动跑 impeccable check。这样 AI 生成完代码，你直接就能看到检查结果，不用手动跑。

4.4 在 CI 流水线里集成

impeccable 的 CLI 输出是结构化的，可以很方便地集成到 CI 流水线里。我自己的 GitLab CI 配置是这样的：

# .gitlab-ci.yml stages: - lint - test - build impeccable-check: stage: lint image: node:20 script: - npm install -g impeccable-cli - impeccable check src/ --reporter json > impeccable-report.json - | if [ $(jq '.errors | length' impeccable-report.json) -gt 0 ]; then echo "impeccable 检查发现 error 级别问题" jq '.errors' impeccable-report.json exit 1 fi artifacts: when: always paths: - impeccable-report.json

这个配置的逻辑是：跑 impeccable check，输出 JSON 格式的报告，然后用 jq 解析报告，如果 error 数量大于 0，就 fail 流水线。

warning 级别的问题不会 fail 流水线，但会记录在报告里，方便后续跟进。

4.5 浏览器扩展的使用技巧

浏览器扩展的安装很简单，但用起来有一些技巧。

技巧一：只在开发环境启用。浏览器扩展会注入一些脚本到页面里，可能会影响生产环境的性能。我自己的做法是，只在localhost和staging环境启用扩展，生产环境禁用。

技巧二：用“高亮模式”快速定位问题。扩展有一个“高亮模式”，会把所有有问题的元素用不同颜色框出来。红色是 error，黄色是 warning，蓝色是 info。这个模式在 review 页面的时候特别有用，一眼就能看出哪些地方需要改。

技巧三：结合 DevTools 使用。扩展的检查结果，可以导出成 JSON，然后导入到 DevTools 里做进一步分析。我自己的做法是，把扩展的检查结果跟 Lighthouse 的报告做对比，两边都报的问题，优先级最高。

技巧四：自定义检查规则。扩展支持自定义检查规则，你可以根据自己的设计规范，添加一些项目特有的检查项。比如我们团队有一个规则：所有卡片的圆角必须是--radius-md，不能是其他值。这个规则在 CLI 里配置比较麻烦，但在扩展里可以快速添加。

5. 常见问题与排查技巧实录

5.1 检查结果太多，不知道从哪下手

这是新手最常见的问题。第一次跑 impeccable，输出几百条问题，直接懵了。

我的建议是：按 severity 排序，先处理 error，再处理 warning，最后处理 info。error 级别的问题，通常是会导致功能或体验缺陷的，必须改。warning 级别的问题，是规范性的，建议改。info 级别的问题，是优化建议，可以后面再说。

另外，可以用--rule参数，只跑某一个检查项：

# 只跑无障碍检查 impeccable check src/ --rule a11y # 只跑 token 一致性检查 impeccable check src/ --rule token-consistency

这样可以把大问题拆成小问题，逐个击破。

5.2 自动修复改坏了代码

自动修复不是万能的。我遇到过几次 autoFix 改坏代码的情况：

• 自动补alt的时候，把装饰性图片也补了alt，导致屏幕阅读器读出无意义的内容
• 自动补aria-label的时候，用了组件的id作为 label，但id是随机生成的，没有意义
• 自动调整颜色对比度的时候，把品牌色改成了另一个颜色，设计不认

所以我的建议是：autoFix 之前，先 commit 一次。这样如果改坏了，可以随时回滚。另外，autoFix 之后，要人工 review 一遍改动，确认没有问题再提交。

5.3 跟现有 ESLint/Prettier 配置冲突

impeccable 的检查，有时候会跟 ESLint 或 Prettier 的规则冲突。比如 Prettier 要求所有字符串用单引号，但 impeccable 的某个检查项要求用双引号。

解决方法是：在 impeccable 的配置里，把冲突的规则关掉，或者调整优先级。我自己的做法是，impeccable 只负责“设计规范”层面的检查，代码风格层面的检查，全部交给 ESLint 和 Prettier。两边职责清晰，不重叠。

5.4 浏览器扩展不生效

浏览器扩展不生效，通常有几个原因：

• 扩展没有启用。去浏览器的扩展管理页面，确认 impeccable 是启用状态。
• 页面是 HTTPS，但扩展只支持 HTTP。有些扩展在 HTTPS 页面上会有权限问题，需要在扩展设置里手动允许。
• 页面用了 CSP（内容安全策略），阻止了扩展注入脚本。这种情况需要在 CSP 里加白名单，或者用扩展的“开发者模式”绕过。

我自己的经验是，Chrome 和 Edge 的兼容性最好，Firefox 偶尔会有问题。如果遇到问题，先换浏览器试试。

5.5 检查速度太慢

impeccable 的检查速度，取决于项目大小和检查项数量。一个中型项目（大概 200 个组件），全量检查大概需要 30 到 60 秒。如果觉得慢，可以：

• 用--incremental参数，只检查上次检查后修改过的文件
• 用--rule参数，只跑必要的检查项
• 在 CI 里用缓存，避免每次全量检查

我自己的做法是，本地开发用--incremental，CI 用全量检查。这样本地反馈快，CI 覆盖全。

5.6 常见问题速查表

5.7 几个我踩过的坑

坑一：token 文件路径写错。impeccable 的 token 检查，依赖 token 定义文件。如果路径写错，它会静默失败，不报任何 token 相关的问题。我一开始以为是没有 token 问题，后来发现是路径写错了。所以配置完之后，一定要跑一次impeccable check --verbose，确认 token 文件被正确加载。

坑二：断点单位混用。impeccable 的断点检查，默认只认 px 单位。如果你的项目里用了 em 或 rem 做断点，会被误报。解决方法是在配置里加breakpointUnit: 'px'，或者在代码里统一用 px。

坑三：autoFix 改了 node_modules 里的文件。impeccable 的 autoFix，默认会扫描所有文件，包括 node_modules。如果你不小心跑了impeccable fix .，它可能会改 node_modules 里的文件。所以一定要在配置里加 ignore 规则，把 node_modules 排除掉。

坑四：CI 里没有装浏览器。impeccable 的某些检查项，依赖浏览器环境（比如颜色对比度检查）。在 CI 里跑的时候，如果没有装浏览器，这些检查项会跳过。解决方法是在 CI 镜像里装一个 headless Chrome，或者在配置里关掉这些检查项。

坑五：跟 AI coding agent 的版本不兼容。impeccable 的某些功能，依赖 AI coding agent 的输出格式。如果 AI coding agent 升级了，输出格式变了，impeccable 可能会解析失败。我自己的做法是，锁定 AI coding agent 的版本，等 impeccable 更新后再升级。

6. 进阶用法：把 impeccable 变成团队规范的一部分

6.1 自定义检查规则

impeccable 支持自定义检查规则。你可以写一个 JS 文件，导出一个函数，然后在配置里引用。

比如我们团队有一个规则：所有页面的主标题，必须用<h1>，且每个页面只能有一个<h1>。这个规则在 impeccable 里可以这样写：

// custom-rules/single-h1.js module.exports = { name: 'single-h1', severity: 'error', check: (ast, filePath) => { const h1Count = ast.querySelectorAll('h1').length; if (h1Count > 1) { return { message: `页面 ${filePath} 有 ${h1Count} 个 <h1>，应该只有一个`, line: ast.querySelector('h1').loc.start.line, }; } return null; }, };

然后在impeccable.config.js里引用：

module.exports = { // ... customRules: [ './custom-rules/single-h1.js', ], };

这个功能对于有特定设计规范的团队特别有用。你可以把团队的“设计决策”写成检查规则，让 impeccable 自动执行。

6.2 生成设计规范文档

impeccable 有一个docs命令，可以根据你的 token 定义和检查规则，自动生成一份设计规范文档：

impeccable docs --output docs/design-system.md

生成的文档包括：颜色系统、间距系统、字体系统、断点系统、交互状态规范、无障碍规范。这份文档可以直接给新加入的成员看，也可以作为设计 review 的参考。

我自己的做法是，把这份文档跟 Storybook 集成，每个组件的文档页面上，都附上 impeccable 的检查结果。这样开发者在写组件的时候，就能看到规范要求。

6.3 跟设计工具联动

impeccable 支持从 Figma 或 Sketch 导入设计 token。如果你的设计团队用 Figma，可以导出 token 文件，然后直接喂给 impeccable。

impeccable import-tokens --from figma --file design-tokens.json

这个功能的价值在于：设计和开发的 token 来源统一了。设计改了颜色，导出 token，开发这边跑一遍 import，所有硬编码的颜色值都会被标记出来，提醒你更新。

我自己的项目里，设计和开发的 token 同步，之前是靠人工维护，经常出现不一致。用了 impeccable 的 import 功能之后，同步频率从“每周一次”变成“每次设计更新后自动同步”。

6.4 性能优化建议

impeccable 的 bundle-analysis 功能，除了报问题，还会给优化建议。比如：

• 某个 CSS 文件有 30% 的规则未使用，建议用 PurgeCSS 清理
• 某张图片是 PNG 格式，建议转成 WebP，能省 60% 大小
• 某个依赖被重复打包了 3 次，建议用 dedupe 去重

这些建议在 CLI 里跑的时候，会输出具体的文件路径和优化后的预期大小。我自己的经验是，按照这些建议优化一遍，bundle 大小平均能减少 30% 到 40%。

6.5 跟 codex cli 的深度集成

如果你用 codex cli 做主力开发工具，可以把 impeccable 集成到 codex cli 的工作流里。

我自己的做法是，在 codex cli 的配置里加一个 alias：

# ~/.codex/config alias gen-check="codex generate && impeccable check src/ && impeccable fix src/"

这样每次生成完代码，自动跑检查和修复。另外，codex cli 支持自定义命令，你可以写一个impeccable命令，直接在 codex cli 里调用：

# codex cli 自定义命令 codex command add impeccable "impeccable check src/ --reporter pretty"

这样在 codex cli 的交互界面里，直接输入impeccable就能跑检查。

7. 一些个人体会

impeccable 这个工具，我用了大概三个月，跑了四个项目。最大的感受是：它把“代码质量”这件事，从“靠人”变成了“靠流程”。

以前用 AI coding agents，代码质量全靠 review 的人的经验和责任心。review 的人认真，代码质量就好；review 的人赶时间，代码质量就崩。现在有了 impeccable，代码质量有了一个确定性的底线。不管 review 的人是谁，跑一遍 impeccable，error 级别的问题必须解决，warning 级别的问题记录在案。这个底线，不会因为人的状态而波动。

另一个感受是：impeccable 让 AI coding agents 变得更好用了。以前用 AI 生成代码，总是要反复调教，改了一轮又一轮。现在生成完，跑一遍 impeccable，自动修复能修的问题，剩下的问题列出来，一次性喂给 AI，让它改。来回次数从 5 到 6 次，降到 2 到 3 次。效率提升很明显。

当然，impeccable 也不是银弹。它管不了业务逻辑的正确性，管不了架构设计的合理性，管不了性能的极致优化。它管的只是“前端设计规范”这一层。但就是这一层，恰恰是 AI 生成代码最薄弱、人工 review 最耗时的地方。

如果你也在用 AI coding agents 做前端开发，我建议你试试 impeccable。不用一上来就全量接入，可以先在一个小项目里跑一遍，看看它的检查结果，感受一下它能帮你发现多少问题。然后再决定要不要集成到你的工作流里。

最后分享一个小技巧：impeccable 的检查结果，可以导出成 CSV，然后导入到 Excel 或者 Google Sheets 里，做趋势分析。我自己的做法是，每周跑一次全量检查，把结果存下来，看 error 数量的变化趋势。如果 error 数量在下降，说明团队在进步；如果 error 数量在上升，说明最近代码质量在滑坡，需要关注。这个趋势分析，比单次的检查结果更有价值。