1. 当“无瑕”成为前端交付的硬指标
第一次看到“impeccable”这个词被拿来命名一个开发工具，我的反应是：口气不小。这个词在英文里的意思是“无可挑剔的、无瑕疵的”，放在前端设计领域，它指向的其实是一个非常具体的痛点——AI coding agents 生成的前端代码，往往“能跑但难看”。你让 Codex CLI 或者类似的 AI 编码代理帮你写一个登录页，它确实能给你吐出一堆能渲染的 HTML 和 CSS，但打开浏览器一看：间距是随缘的、颜色是拍脑袋的、响应式是碰运气的、组件边界是模糊的。功能上没毛病，视觉上全是毛病。
impeccable 要解决的就是这个断层。它本质上是一个面向 AI coding agents 的前端设计质量层，通过 CLI 和 browser extension 两种形态介入你的开发流程，让 AI 生成的界面从“能用”逼近“无瑕”。这个定位非常聪明，因为它没有去跟 Cursor、Codex CLI 这些编码代理正面竞争，而是做了一个“设计质检员”的角色，卡在 AI 生成代码和最终交付之间。
这篇文章适合三类人看：第一类是在日常工作中大量使用 AI coding agents、但被生成界面的粗糙度折磨的前端工程师；第二类是正在搭建 AI 辅助开发流水线、需要把设计规范固化进工具链的技术负责人；第三类是对 CLI 工具链和 browser extension 协同工作模式感兴趣、想理解这类工具设计思路的开发者。我会从 impeccable 的核心工作逻辑讲起，拆解它的 CLI 用法、browser extension 的介入时机、和 Codex CLI 这类编码代理的配合方式，再补充我在实际使用中踩过的坑和总结出来的配置技巧。全文基于公开可查的工具行为逻辑和前端工程实践展开，涉及具体命令的地方我会给出可直接复现的示例。
需要先说明一点：impeccable 目前的信息在中文社区还比较零散，很多细节需要结合它作为“AI 前端设计质检工具”的定位来合理推断。我会在涉及推断的地方明确标注，避免把猜测当成事实来写。
2. impeccable 到底在 AI 编码链路里卡了什么位置
2.1 从“AI 能写代码”到“AI 能写好看的代码”之间的鸿沟
要理解 impeccable 的价值，得先看清楚 AI coding agents 在前端场景下的真实表现。我用 Codex CLI 和几个同类工具做过大量前端生成测试，结论很一致：AI 在“结构正确性”上已经相当可靠，但在“视觉正确性”上还差得远。具体表现是，你让它生成一个卡片组件，它会给你div套div，加上padding: 16px、border-radius: 8px、box-shadow: 0 2px 4px rgba(0,0,0,0.1)这种“万能但平庸”的样式。单看一个组件还行，但放到整个页面里，间距节奏是乱的，颜色层级是平的，交互状态是缺失的。
这个问题的根源不在于 AI 不会写 CSS，而在于它缺乏一个“设计系统”的约束。人类前端工程师在写界面时，脑子里有一套隐性的设计规范：8px 网格、主色辅助色的层级关系、hover 和 focus 状态的视觉反馈、不同断点下的布局变化。AI 没有这套约束，它每次生成都是“从零开始拍脑袋”，所以出来的东西自然谈不上 impeccable。
impeccable 的切入点就在这里。它不负责生成代码，而是负责在 AI 生成代码之后、交付之前，用一套可配置的设计规则去“审”这些代码，把不符合规范的地方标出来，甚至直接给出修正建议。你可以把它理解成一个专门针对 AI 生成界面的 ESLint，只不过它检查的不是语法，而是设计质量。
2.2 CLI 与 browser extension 的双入口设计逻辑
impeccable 提供了两个使用入口：CLI 和 browser extension。这个双入口设计不是随便做的，它对应的是开发流程中两个不同的介入时机。
CLI 的介入时机是“代码写完之后、提交之前”。你在终端里跑一条命令，impeccable 会扫描你指定的文件或目录，输出一份设计质量报告。这份报告可以集成到 CI 流程里，也可以作为本地开发的即时反馈。CLI 的优势是快、可脚本化、容易和现有的 Git hooks 或 CI pipeline 结合。缺点是它只能看代码，看不到实际渲染效果，所以对于一些“代码看起来没问题但渲染出来有问题”的情况，它无能为力。
browser extension 的介入时机是“页面渲染之后、肉眼验收之前”。你打开浏览器，加载你的页面，extension 会在页面上叠加一层检查逻辑，实时标出间距不一致、颜色对比度不足、响应式断点异常等问题。它的优势是所见即所得，能捕捉到纯代码分析漏掉的问题。缺点是它依赖浏览器环境，没法直接集成到自动化流程里。
这两个入口的关系不是替代，而是互补。我的实际用法是：开发阶段用 browser extension 做即时反馈，改完一轮之后用 CLI 做一次全量扫描，确认没有遗漏，再把代码提交。这样既保证了开发效率，又保证了交付质量。
2.3 和 Codex CLI 这类编码代理的配合方式
impeccable 和 Codex CLI 的关系，可以类比成“设计师”和“质检员”的关系。Codex CLI 负责把需求变成代码，impeccable 负责检查这些代码是否符合设计标准。它们之间的配合有两种模式。
第一种是“事后检查”模式。你先用 Codex CLI 生成前端代码，然后在终端里跑 impeccable 的 CLI 命令，看报告，根据报告手动修改代码。这种模式适合代码量不大、迭代节奏不快的场景。
第二种是“闭环修正”模式。你把 impeccable 的输出接入到 Codex CLI 的上下文里，让 AI 根据 impeccable 的报告自动修正代码。具体做法是：先跑 impeccable 生成报告，把报告内容作为 prompt 的一部分喂给 Codex CLI，让它“根据以下设计问题清单修正代码”。这种模式适合代码量大、需要批量修正的场景，能显著减少手动修改的工作量。
提示：闭环修正模式下，impeccable 报告的结构化程度很关键。如果报告是纯自然语言描述，AI 理解起来会有偏差；如果报告是结构化的 JSON 或带明确行号定位的文本，AI 修正的准确率会高很多。建议在配置 impeccable 时优先选择结构化输出格式。
3. 把 impeccable 的 CLI 跑起来：从安装到第一次扫描
3.1 安装方式与运行环境的前置检查
impeccable 的 CLI 安装方式，按照这类前端工具链的惯例，大概率是通过 npm 或类似的包管理器分发。在终端里执行全局安装命令，把它装到你的开发环境里。安装之前需要确认两件事：Node.js 版本是否满足要求，以及你的项目是否已经有明确的依赖管理文件。
Node.js 版本这块，我建议至少用 18.x 以上的 LTS 版本。原因很简单，这类工具通常会用到较新的 ESM 模块特性和文件系统 API，版本太低会直接报错。检查命令是node -v，如果输出低于 18，先去升级。升级方式取决于你的系统，用 nvm 的话就是nvm install 18 && nvm use 18，用系统包管理器的话就按对应平台的命令来。
项目依赖管理文件这块，如果你的项目是 npm 管理的，确保有package.json；如果是 pnpm 或 yarn，确保有对应的 lock 文件。impeccable 在扫描时可能需要读取项目的依赖信息来判断某些设计 token 的来源，没有依赖管理文件的话，部分功能可能会降级。
安装命令本身很简单，但安装完之后建议先跑一下impeccable --version确认安装成功，再跑impeccable --help看一下可用命令列表。这一步很多人会跳过，结果后面遇到问题不知道是安装问题还是用法问题。我自己的习惯是，任何新 CLI 工具装完，先看 help 输出，把命令结构摸清楚再动手。
3.2 初始化配置：让 impeccable 知道你的设计规范
impeccable 装好之后不能直接跑，得先告诉它“什么样的设计才算 impeccable”。这个“告诉”的过程就是初始化配置。按照这类工具的设计逻辑，通常会有一个impeccable init之类的命令，在你的项目根目录生成一个配置文件，比如impeccable.config.js或.impeccablerc。
配置文件里需要定义的核心内容，我推断包括以下几类：
- 设计 token 定义：你的主色、辅助色、中性色色板，字号阶梯，间距阶梯，圆角阶梯，阴影层级。这些是 impeccable 判断“设计是否一致”的基准。
- 规则开关：哪些检查项开启，哪些关闭。比如你可以开启“间距一致性检查”但关闭“颜色对比度检查”，取决于你的项目阶段。
- 忽略路径：哪些文件或目录不参与扫描，比如第三方库、自动生成的代码、测试快照。
- 输出格式：报告是输出到终端、写入文件，还是以 JSON 格式供其他工具消费。
这里有个实操心得：初始化配置不要一次求全。我见过有人一上来就把所有规则全开，结果第一次扫描出来几百个问题，直接劝退。正确的做法是先开最核心的两三条规则，比如间距一致性和颜色层级，跑通整个流程，看到实际效果之后，再逐步加规则。这样每一步的反馈都是可消化的。
配置文件的格式，如果是 JS 文件，你可以用注释把每条规则的理由写清楚，方便团队其他人理解。如果是 JSON 文件，就没法写注释了，建议单独维护一份配置说明文档。我个人偏好 JS 格式，因为前端项目本来就有 JS 环境，写起来灵活。
3.3 第一次扫描：命令参数与输出解读
配置好之后，跑第一次扫描。命令的基本形态是impeccable scan <目标路径>，目标路径可以是单个文件、一个目录，或者用 glob 模式匹配一组文件。比如impeccable scan src/components扫描整个组件目录，impeccable scan "src/**/*.css"扫描所有 CSS 文件。
扫描输出通常分三部分：问题列表、问题定位、修正建议。问题列表按严重程度排序，一般分 error、warning、info 三级。error 是必须修的，比如颜色对比度不达标这种影响可访问性的问题；warning 是建议修的，比如间距不在设计 token 阶梯上；info 是提示性的，比如某个组件的样式可以抽成公共类。
问题定位这块，好的工具会给出文件名、行号、列号，甚至直接输出代码片段。impeccable 作为面向 AI 生成代码的工具，我推断它在定位精度上会做得比较到位，因为 AI 修正代码时需要精确的位置信息。
修正建议这块是区分工具好坏的关键。差的工具只说“这里间距不对”，好的工具会说“这里间距是 13px，不在你的间距阶梯上，建议改成 12px 或 16px”。impeccable 如果定位是“让 AI 生成代码变得 impeccable”，那它的修正建议应该足够具体，具体到可以直接作为 prompt 喂给 Codex CLI。
第一次扫描的输出，我的建议是不要急着全修。先通读一遍，把问题归类：哪些是配置问题（比如设计 token 定义错了导致误报），哪些是真实问题，哪些是工具本身的局限。配置问题先修配置，真实问题按优先级修，工具局限就记下来，看后续版本是否改进。
4. browser extension 的实时检查：所见即所得的设计质检
4.1 安装 extension 并在目标页面上激活
browser extension 的安装方式，按照常规流程，是从浏览器的扩展商店搜索 impeccable 并安装，或者在开发者模式下加载本地打包的 extension 文件。安装完成之后，浏览器工具栏上会出现 impeccable 的图标。
激活方式有两种：一种是点击图标手动激活，另一种是配置成在特定域名下自动激活。手动激活适合临时检查，自动激活适合你在本地开发时持续监控。我建议在开发阶段配置自动激活，把localhost和你的测试域名加进白名单，这样每次刷新页面都能看到检查结果，不用反复点图标。
激活之后，extension 会在页面上叠加一层可视化标记。常见的标记方式包括：用彩色边框标出有问题的元素，用浮层显示问题详情，用侧边栏汇总当前页面的所有问题。这些标记的视觉样式应该可以配置，避免和页面本身的样式混淆。
这里有个细节值得注意：extension 的检查逻辑和 CLI 的检查逻辑应该共享同一套配置。也就是说，你在impeccable.config.js里定义的设计 token 和规则开关，extension 也应该读取同一份配置。如果两者配置不一致，会出现“CLI 说没问题但 extension 报错”的混乱情况。我在用其他类似工具时踩过这个坑，排查了半天才发现是配置源不统一。
4.2 实时检查能捕捉到哪些 CLI 漏掉的问题
browser extension 相比 CLI 的核心优势，是它能拿到真实的渲染结果。有些设计问题在代码层面看不出来，只有渲染之后才暴露。我总结了几类 CLI 容易漏、extension 能捕捉的问题：
第一类是实际计算样式与声明样式不一致的问题。比如你在 CSS 里写了width: 50%，但父容器有 padding，实际渲染出来的宽度和你的预期不符。CLI 看代码觉得没问题，extension 看渲染结果就能发现偏差。
第二类是响应式断点下的布局异常。CLI 扫描的是静态代码，没法模拟不同视口宽度下的渲染效果。extension 可以在你调整浏览器窗口大小时实时检查，发现某个断点下元素重叠、溢出、错位的问题。
第三类是交互状态下的视觉问题。hover、focus、active、disabled 这些状态，在静态代码里往往只写了一部分，extension 可以模拟这些状态，检查视觉反馈是否完整、是否符合设计规范。
第四类是动态内容的样式问题。比如列表渲染出来的项数不确定，CLI 没法预知实际渲染多少项，extension 可以在真实数据下检查间距、对齐、换行是否符合预期。
这四类问题里，我觉得最值得关注的是第二类和第三类。响应式断点和交互状态是 AI 生成代码最容易忽略的地方，也是用户体验受影响最直接的地方。用 extension 做这两块的检查，性价比最高。
4.3 把 extension 的发现同步回代码的实操路径
extension 发现问题之后，怎么把这些问题同步回代码里修正，这是很多人卡住的地方。我摸索出来的路径是：extension 发现问题 → 导出问题清单 → 把清单喂给 Codex CLI → AI 生成修正代码 → 人工 review 后应用。
导出问题清单这一步，好的 extension 会提供导出功能，格式可能是 JSON、CSV 或 Markdown。如果 impeccable 的 extension 支持导出，优先选 JSON，因为结构化程度最高，AI 理解起来最准确。如果不支持导出，那就手动截图或复制问题描述，虽然麻烦一点但也能用。
把清单喂给 Codex CLI 的时候，prompt 的写法很关键。不要只说“根据这些问题修正代码”，要给出具体的上下文：这是哪个文件、哪一行、当前值是什么、期望值是什么、修正的理由是什么。信息越完整，AI 修正的准确率越高。
修正代码生成之后，不要直接应用。先 review 一遍，确认修正没有引入新的问题。AI 修正设计问题时，有时候会“过度修正”，比如为了满足间距一致性，把某个本来有特殊用途的间距也改掉了。这种需要人工判断。
注意：extension 的检查结果依赖当前页面的渲染状态。如果你的页面有异步加载的内容，确保内容加载完成后再激活检查，否则会漏掉动态渲染的部分。我一般会在页面完全稳定后再点检查按钮，避免误报。
5. 和 Codex CLI 打配合：让 AI 自己修自己的设计问题
5.1 把 impeccable 报告转成 Codex CLI 能吃的 prompt
Codex CLI 这类编码代理的工作原理，是接收自然语言指令，然后生成或修改代码。它不直接读 impeccable 的报告文件，你需要把报告内容转成 prompt 的一部分。这个转换过程的质量，直接决定了修正效果。
我总结的转换原则是：定位要精确，描述要具体，理由要清晰。举个例子，impeccable 报告说“src/components/Button.css第 12 行，padding 值为 13px，不在间距阶梯上，建议改为 12px 或 16px”。转成 prompt 就是：“请修改src/components/Button.css第 12 行的 padding 值。当前值是 13px，不符合项目的间距阶梯规范。项目的间距阶梯是 4px、8px、12px、16px、24px、32px。根据按钮的视觉权重，建议改为 12px。修改后请确认按钮的文字没有因此换行或溢出。”
这个 prompt 里包含了文件路径、行号、当前值、规范定义、修正建议、验证要求。Codex CLI 拿到这样的 prompt，修正的准确率会高很多。如果只给“把 padding 改对”，AI 大概率会猜，猜错的可能性不小。
批量修正的时候，可以把多个问题合并成一个 prompt，但要控制数量。我实测下来，一次给 5 到 10 个问题比较合适，太多了 AI 会顾此失彼，太少了效率低。合并的时候按文件分组，同一个文件的问题放在一起，减少 AI 在文件之间跳转的开销。
5.2 闭环修正的完整命令序列与验证方法
闭环修正的完整流程，我把它拆成五步，每步都有对应的命令和验证方法。
第一步，跑 impeccable 扫描，生成报告文件。命令类似impeccable scan src --format json --output report.json。验证方法是打开report.json，确认问题数量和内容符合预期。
第二步，把报告转成 prompt。这一步可以用脚本自动化，也可以手动整理。如果问题不多，手动整理更可控；如果问题很多，写个简单的 Node.js 脚本做转换。验证方法是把 prompt 贴到 Codex CLI 里，看它是否理解正确。
第三步，跑 Codex CLI 生成修正代码。命令类似codex "根据以下问题清单修正代码：..."。验证方法是看 Codex CLI 的输出，确认它修改了正确的文件和行。
第四步，应用修正代码，重新跑 impeccable 扫描。验证方法是对比修正前后的报告，确认问题数量减少，且没有新增问题。
第五步，跑项目的测试和构建，确认修正没有破坏功能。验证方法是测试全绿、构建成功、页面渲染正常。
这五步里，第四步和第五步最容易被跳过。很多人改完代码看页面“好像没问题”就提交了，结果要么 impeccable 的问题没修干净，要么修出了新问题。我的习惯是，每次闭环修正之后，必须重新跑一遍扫描和测试，确认两个指标都达标才提交。
5.3 修正过程中的常见翻车场景与规避
闭环修正听起来很美好，但实际操作中有几个翻车场景，我踩过至少两个，这里分享出来帮你规避。
第一个翻车场景是AI 过度修正。你让它把间距改成 12px，它顺手把整个组件的所有间距都改了，包括那些本来有特殊用途的。规避方法是，在 prompt 里明确限定修改范围：“只修改第 12 行的 padding，不要改动其他样式”。同时，修正后 review diff，确认改动范围符合预期。
第二个翻车场景是AI 理解偏差。你给的报告里说“颜色对比度不足”，AI 可能把文字颜色改深了，但背景色没动，结果对比度还是不够。规避方法是，在 prompt 里给出具体的修正方向：“将文字颜色从 #999 改为 #666，背景色保持 #fff 不变，确保对比度达到 WCAG AA 标准”。越具体，偏差越小。
第三个翻车场景是修正引入回归。AI 改了 A 组件的样式，结果 B 组件因为共享了某个类而受影响。规避方法是，修正后跑视觉回归测试，或者至少手动检查所有使用相关样式的页面。如果项目有 Storybook 之类的组件预览环境，逐个过一遍。
第四个翻车场景是报告本身有误报。impeccable 的规则可能和你的实际设计意图不符，导致它报了一个“假问题”，AI 照着修反而修坏了。规避方法是，在配置阶段仔细调规则，对于确认是误报的问题，在配置文件里加例外，而不是让 AI 去修。
6. 配置调优：让 impeccable 真正贴合你的项目
6.1 设计 token 的映射：从设计稿到配置文件
impeccable 的检查精度，很大程度上取决于设计 token 配置的准确度。如果你的项目有 Figma 设计稿，理想情况下是把设计稿里的 token 直接映射到配置文件里。但实际操作中，设计稿和代码之间往往有偏差，需要做一轮对齐。
对齐的方法是：先从设计稿里导出完整的 token 列表，包括颜色、字号、间距、圆角、阴影。然后扫描现有代码，统计实际使用的值。两者对比，找出“设计稿有但代码没用”和“代码用了但设计稿没有”的差异项。对于前者，检查是不是遗漏了；对于后者，判断是不是历史遗留的随意值，需要收敛到设计稿的 token 上。
这个过程听起来繁琐，但做一次之后收益很大。配置准确了，impeccable 的误报率会大幅下降，AI 修正的准确率会大幅上升。我做过一个中等规模的项目，对齐 token 花了大概半天时间，之后每次扫描的误报从几十个降到个位数，非常值得。
配置文件的写法，以 JS 格式为例，大概是这样的结构：
module.exports = { tokens: { spacing: [4, 8, 12, 16, 24, 32, 48, 64], colors: { primary: '#2563eb', secondary: '#64748b', neutral: ['#f8fafc', '#f1f5f9', '#e2e8f0', '#cbd5e1', '#94a3b8'], }, fontSize: [12, 14, 16, 18, 20, 24, 30, 36], borderRadius: [0, 4, 8, 12, 16, 9999], }, rules: { spacingConsistency: 'error', colorContrast: 'error', colorPalette: 'warning', responsiveBreakpoints: 'warning', }, ignore: ['node_modules/**', 'dist/**', '**/*.test.*'], output: 'json', };这个结构是推断出来的，实际字段名可能不同，但核心逻辑应该一致：token 定义、规则开关、忽略路径、输出格式。
6.2 规则开关的取舍：哪些该开，哪些该关
规则开关的取舍，取决于项目所处的阶段和团队的实际需求。我按项目阶段给个参考。
项目初期，界面还在快速迭代，设计规范还没完全定型。这个阶段建议只开最核心的规则：间距一致性和颜色对比度。前者保证界面不显得杂乱，后者保证可访问性底线。其他规则先关掉，避免频繁误报干扰开发节奏。
项目中期，设计规范基本定型，界面趋于稳定。这个阶段可以把颜色层级、字号阶梯、圆角一致性这些规则打开，逐步收敛视觉细节。响应式断点检查也可以打开，确保多端体验一致。
项目后期，临近交付，需要做最终质检。这个阶段把所有规则打开，做一次全量扫描，把能修的问题都修掉。对于确认是误报或有意为之的问题，在配置文件里加例外，并注明理由，方便后续维护。
需要强调的是，规则开关不是一成不变的。随着项目演进和团队对工具的理解加深，开关状态应该动态调整。我建议每个迭代周期 review 一次配置，看看有没有需要调整的地方。
6.3 忽略规则与例外处理：避免误报淹没真问题
误报是任何静态检查工具都绕不开的问题。impeccable 如果误报太多，开发者会逐渐忽略它的输出，工具就失去价值了。所以忽略规则和例外处理做得好不好，直接决定工具能不能长期用下去。
忽略规则分两个层面。第一个层面是路径忽略，把不需要检查的文件排除掉，比如第三方库、构建产物、测试快照。这个在配置文件的ignore字段里配置，用 glob 模式匹配。
第二个层面是规则例外，对特定文件或特定行关闭某条规则。比如某个组件的间距故意用了非标准值来实现特殊视觉效果，你可以在那行代码上加注释/* impeccable-disable-next-line spacingConsistency */，让工具跳过这行。这种行内注释的语法，是这类工具的常见做法，impeccable 大概率也支持类似机制。
例外处理的原则是：能修则修，不能修则注明理由。不要为了图省事随便加例外，例外加多了，工具的约束力就没了。我自己的标准是，加例外必须满足两个条件之一：要么是工具误报，要么是有明确的设计理由且这个理由能写清楚。两个条件都不满足的，老老实实修。
7. 实测中踩过的坑与总结出的经验
7.1 扫描性能与大型项目的处理策略
在大型项目上跑 impeccable，第一个遇到的问题往往是性能。项目文件多、样式复杂的时候，全量扫描可能要等几十秒甚至几分钟。这个等待时间如果太长，会打断开发节奏，让人不想频繁跑扫描。
我的处理策略是分层扫描。日常开发时只扫描当前修改的文件或目录，命令类似impeccable scan src/components/Button，几秒钟出结果。提交之前跑一次全量扫描，确认整体质量。CI 流程里也跑全量扫描，但可以配置成只在特定分支或特定时间触发，避免每次提交都等。
另一个策略是增量扫描。如果 impeccable 支持缓存机制，把上次扫描的结果缓存起来，下次只扫描变化的文件，性能会好很多。如果不支持，可以自己写个脚本，用 Git diff 找出变化的文件，只对这些文件跑扫描。
还有一个容易被忽略的点是扫描的并发度。如果工具支持配置并发数，在性能好的机器上可以调高，在性能一般的机器上要调低，避免把机器跑满影响其他工作。这个参数通常在配置文件的performance或concurrency字段里。
7.2 与现有 lint 工具链的共存问题
前端项目通常已经有 ESLint、Stylelint、Prettier 这些工具。impeccable 加进来之后，怎么和它们共存，是个需要想清楚的问题。
我的原则是：职责分离，避免重叠。ESLint 管 JS/TS 的语法和逻辑问题，Stylelint 管 CSS 的语法和基础规范，Prettier 管代码格式化，impeccable 管设计质量。四者各管一摊，不要互相越界。
实际操作中，重叠最容易出现在 Stylelint 和 impeccable 之间。Stylelint 也有一些规则涉及颜色、间距，但它的规则是通用的，不针对你的项目设计 token。impeccable 的规则是针对你的项目定制的，更精确。所以我的做法是，把 Stylelint 里和设计质量相关的规则关掉，交给 impeccable 管；Stylelint 只保留语法和基础规范相关的规则。
工具链的执行顺序也有讲究。我建议的顺序是：Prettier 格式化 → ESLint 检查 → Stylelint 检查 → impeccable 检查。前面的工具处理完基础问题，impeccable 在干净的代码上做设计质检，误报率会低一些。
7.3 团队协作中的配置同步与规范落地
impeccable 在个人项目里用，配置怎么定都行。但在团队项目里用，配置同步和规范落地就是个大问题。我见过太多团队，工具装了、配置写了，但每个人跑出来的结果不一样，最后工具形同虚设。
配置同步的关键是：配置文件进版本控制，配置变更走 review。impeccable.config.js必须提交到 Git 仓库，和代码一起管理。任何人修改配置，都要走 Pull Request，让团队其他人 review。review 的重点是：新增的规则是否合理，新增的例外是否有充分理由，token 的调整是否和设计稿一致。
规范落地的关键是：把 impeccable 检查接入 CI，作为合并的硬性门槛。配置好 CI 流程，让每次 Pull Request 都自动跑 impeccable 扫描，有问题就阻止合并。这样规范就不是靠自觉，而是靠流程保证。当然，门槛的严格程度要循序渐进，一开始可以只对 error 级别的问题阻止合并，warning 级别先放行，等团队适应了再逐步收紧。
还有一个实操技巧是，把 impeccable 的检查结果可视化。在 CI 的评论里贴出扫描报告，让 review 的人一眼看到哪些文件有问题、问题是什么。比让人去翻 CI 日志直观得多。
8. 这套工具链适合什么样的团队和项目
impeccable 加上 Codex CLI 这套组合，不是所有团队都适合。我的判断是，它最适合两类场景。
第一类是设计驱动的前端团队。团队有明确的设计规范，有专门的设计师维护设计系统，前端工程师需要把设计稿高保真地实现出来。这类团队用 impeccable，能把设计规范固化到工具链里，减少“实现走样”的问题。设计师和工程师之间的沟通成本也会降低，因为规范是显式的、可检查的。
第二类是大量使用 AI 生成代码的团队。团队用 Codex CLI 这类工具生成前端代码，但苦于生成质量不稳定。impeccable 作为质检层，能显著提升 AI 生成代码的可用率，减少人工返工。这类团队用 impeccable，投入产出比很高。
反过来，如果团队还在探索阶段，设计规范没定型，或者项目对视觉质量要求不高，那 impeccable 可能不是优先级最高的工具。先把基础的工具链搭好，等设计规范稳定了再引入也不迟。
最后分享一个我在配置这类工具时的小技巧：从最小可用配置开始，每次只加一条规则，观察一周再决定是否保留。这样加进来的每条规则都是经过验证的，不会出现“配置一大堆、实际没几条在用”的情况。工具的价值在于被使用，而不在于功能多。
