1. 从"impeccable"这个词说起：为什么前端审美正在成为AI编码代理的分水岭
第一次看到"impeccable"被拿来命名一个跟AI编码代理相关的项目时，我脑子里冒出来的第一个念头是：这词选得挺狂。impeccable，无瑕的、挑不出毛病的。放在前端设计语境里，它指向的是一种近乎苛刻的完成度——不是"能跑就行"，而是每一个间距、每一处对齐、每一层视觉层级都经得起放大镜看。
但真正让我觉得有意思的，是它出现的位置。它不是一个设计工具，也不是一个UI框架，而是跟AI coding agents、CLI、browser extension这些词绑在一起。这说明什么？说明有人在做一件很具体的事：让AI编码代理在生成前端代码的时候，输出质量从"能用"往"impeccable"这个方向靠。
我自己用AI编码代理写前端有大半年了，踩过的坑能写满一屏。最典型的一个场景：你让代理生成一个登录页，它给你吐出来的东西结构上没毛病，但视觉上就是"差点意思"——按钮的圆角和输入框的圆角不一致，卡片阴影的扩散半径随手写的，标题和正文的行高比例失衡，颜色用的是那种一眼就能认出来的"AI蓝"。你改吧，改完一处它下次又犯；你不改吧，交付出去自己都嫌丢人。
所以当我看到"impeccable"这个关键词跟AI coding agents、frontend design、CLI、browser extension这些词一起出现的时候，我大概能猜到它想解决的是什么问题：把前端设计的"审美标准"和"质量约束"前置到AI代理的工作流里，而不是等它生成完了再人工返工。
这篇东西我打算按我自己的理解，把"impeccable"这个方向拆开讲清楚。它背后涉及的核心技术点是什么，为什么CLI和browser extension这两个形态会同时出现，AI编码代理在前端设计上到底卡在哪，以及如果你现在就想在自己的工作流里落地类似的东西，应该从哪几个环节下手。不管你是刚接触AI编码代理的新手，还是已经在用codex cli、zcode cli这类工具干活的老手，我都尽量把话说透，让你看完能直接动手试。
2. AI编码代理做前端设计，到底卡在哪几个环节
2.1 代理的"视觉盲区"：它看不见自己生成的东西
这是最根本的问题。AI编码代理本质上是在文本空间里工作的，它生成的是代码字符串，不是像素。你让它写一个<div>，它知道这个div应该有什么属性，但它"看不见"这个div渲染出来之后长什么样。
我做过一个测试：让同一个代理分别生成"一个居中的卡片，带阴影和圆角"和"一个视觉上平衡、有呼吸感的卡片"。前者它秒出，后者它也能出，但出来的东西你得盯着看半天才能说出哪里不对——往往是内边距给得太紧，阴影太实，圆角跟卡片尺寸不匹配。
这个盲区带来的直接后果是：代理没有"自我校验"的能力。它不知道自己的输出好不好看，只能保证语法正确、结构合理。而前端设计恰恰是一个高度依赖视觉反馈的活儿。
2.2 设计token的缺失：每次生成都在重新发明轮子
第二个卡点更隐蔽。大部分AI编码代理在生成前端代码时，是"无状态"的——它不知道你项目里已经有一套设计系统，不知道你的主色是#2563eb还是#3b82f6，不知道你的间距基数是4px还是8px。
结果就是每次生成都在重新发明轮子。这次给你用border-radius: 8px，下次可能就变成12px；这次阴影是0 1px 3px rgba(0,0,0,0.1)，下次变成0 4px 6px rgba(0,0,0,0.15)。单看每一处都没问题，拼在一起就是"不协调"。
impeccable这个方向如果要落地，设计token的注入是绕不开的一环。你得让代理在生成之前就知道：这个项目的圆角体系是什么、间距体系是什么、颜色体系是什么、字体层级是什么。这些约束一旦前置，输出的稳定性会有质的提升。
2.3 反馈回路的断裂：改一处崩三处
第三个卡点是我个人最头疼的。你让代理改一个按钮的样式，它改完之后，跟这个按钮相关的hover态、focus态、disabled态可能就全乱了。因为代理在改的时候，视野是局部的，它没有"这个组件是一个整体"的意识。
前端设计里，组件是有状态的。一个按钮至少有default、hover、active、focus、disabled五种状态，一个输入框至少有default、focus、error、disabled四种。代理如果只盯着你指出的那一处改，其他状态就会失配。
要解决这个问题，要么在prompt里把状态矩阵写清楚，要么在工具层面做一个"组件级"的约束——你改这个组件，所有状态一起改。后者显然更靠谱，但实现难度也更大。
2.4 审美标准的不可言说性
最后一个卡点最玄，但也最真实。什么叫"好看"？这个东西很难用规则穷举。你说间距要一致，那什么时候该一致、什么时候该故意打破一致？你说颜色要克制，那什么时候该用高饱和度的强调色？
AI编码代理在处理这类"模糊约束"时，表现很不稳定。你给它一个明确的规则它能遵守，你给它一个"要好看"的指令，它就只能靠训练数据里的统计规律去猜。而统计规律给出的答案，往往是"平均意义上的安全"，不是"impeccable"。
所以impeccable这个方向，本质上是在做一件事：把那些"不可言说的审美标准"，尽可能转化成"可言说的工程约束"。这件事能做到什么程度，决定了这类工具的天花板在哪。
3. CLI和browser extension：两种形态各自解决了什么问题
3.1 CLI形态：把约束前置到生成环节
CLI这个形态，我理解它的核心价值是"在代理生成代码之前，把约束喂进去"。
你想想看，如果你在命令行里跑一个命令，这个命令做的事情是：读取你项目里的设计token配置文件，把当前组件的上下文（用了哪些已有的组件、遵循什么命名规范、依赖什么样式变量）提取出来，然后把这些信息作为system prompt的一部分，再交给AI代理去生成代码。这样代理在动手之前，就已经知道"这个项目的圆角只有4px、8px、12px三档"，它就不会随手写一个10px出来。
CLI的另一个优势是可组合。你可以把它串到现有的工作流里：git diff之后跑一下，检查新生成的代码有没有违反设计token；或者跟codex cli这类工具配合，在生成阶段就注入约束。
我实测下来，CLI形态最适合的场景是"批量生成"和"CI集成"。比如你有一批组件要生成，或者你想在代码合并之前做一道设计规范的检查，CLI是最高效的。
3.2 Browser extension形态：把反馈回路缩短到"所见即所得"
Browser extension这个形态解决的是另一个问题：视觉反馈。
前面说了，代理有"视觉盲区"，它看不见自己生成的东西。Browser extension的价值就在于，它可以在浏览器里实时渲染代理生成的代码，然后把渲染结果"翻译"成代理能理解的反馈。
具体怎么翻译？我想到几种可能：一是截图，把渲染结果截图之后交给多模态模型去评估；二是提取计算样式，把每个元素的computed style抓出来，跟设计token做比对；三是交互测试，模拟hover、focus这些状态，检查状态切换是否正常。
Browser extension的另一个好处是"就地修改"。你在浏览器里看到一个地方不对，可以直接在extension里调整参数，然后让代理重新生成那一部分。这个反馈回路比"改代码→刷新→看效果→再改代码"要短得多。
3.3 两种形态的配合逻辑
CLI和browser extension不是二选一的关系，它们覆盖的是工作流的不同阶段。
CLI管"生成前"和"生成中"——约束注入、规范检查、批量处理。Browser extension管"生成后"——视觉验证、交互测试、就地调整。
一个完整的工作流可能是这样的：你在CLI里跑一个命令，代理根据设计token生成组件代码；代码写进项目之后，你在浏览器里打开页面，extension自动检测这个组件的渲染结果，把不符合规范的地方标出来；你点一下"修复"，extension把问题反馈给代理，代理重新生成；你再刷新，确认没问题。
这个闭环一旦跑通，前端设计的迭代效率会有明显提升。当然，实现难度也不小，尤其是"把视觉问题翻译成代理能理解的文本"这一步，目前还没有特别成熟的方案。
4. 设计token体系：impeccable落地的地基
4.1 为什么token是地基而不是装饰
我见过不少团队做设计系统，token这一层做得很敷衍——颜色随便定几个，间距就写个"用8的倍数"，字体层级更是凭感觉。然后指望AI代理能生成"impeccable"的前端代码，这基本是不可能的。
token是代理能理解的"硬约束"。你告诉它"圆角用8px"，它就能用8px；你告诉它"圆角要看起来舒服"，它就只能猜。所以impeccable这个方向要落地，第一步一定是把token体系建起来，而且要建得足够细、足够明确。
细到什么程度？我建议至少覆盖这几类：
- 颜色：主色、辅助色、中性色、语义色（成功/警告/错误/信息），每一类要有明确的色值和用途说明
- 间距：基础间距单位，以及基于这个单位的派生值（比如4px基础，派生8/12/16/24/32）
- 圆角：至少三档（小/中/大），明确每档的适用场景
- 阴影：至少三档（低/中/高），明确每档的模糊半径、扩散半径、透明度
- 字体：字号阶梯、字重阶梯、行高比例
- 动效：时长、缓动曲线
这些token一旦定义清楚，代理在生成代码时就有了明确的"边界"。它不会写出border-radius: 10px这种不在体系内的值，因为它知道体系里只有4/8/12。
4.2 token的命名规范：让代理能"读懂"用途
光有值还不够，命名也很关键。--color-blue-500和--color-primary，代理理解起来是不一样的。前者是"这是什么颜色"，后者是"这个颜色用来干什么"。
我建议token命名采用"语义+层级"的方式。比如：
--color-primary: #2563eb; --color-primary-hover: #1d4ed8; --color-primary-active: #1e40af; --color-text-primary: #111827; --color-text-secondary: #6b7280; --color-bg-surface: #ffffff; --color-bg-subtle: #f9fafb; --space-xs: 4px; --space-sm: 8px; --space-md: 16px; --space-lg: 24px; --space-xl: 32px; --radius-sm: 4px; --radius-md: 8px; --radius-lg: 12px;这样代理在生成代码时，看到"按钮的hover态"，它就知道应该用--color-primary-hover，而不是自己算一个颜色出来。
4.3 把token注入到代理的上下文里
token定义好了，怎么让代理知道？这是CLI形态要解决的核心问题。
我试过几种方式。最简单的是在prompt里直接把token列表贴进去，但这样token一多，prompt就会变得很长，而且容易跟其他指令冲突。更好的方式是把token写成一个独立的配置文件，CLI在调用代理之前，先读取这个文件，把内容格式化成一段结构化的system prompt。
比如：
{ "designTokens": { "colors": { "primary": "#2563eb", "primaryHover": "#1d4ed8", "textPrimary": "#111827", "textSecondary": "#6b7280" }, "spacing": { "xs": "4px", "sm": "8px", "md": "16px", "lg": "24px" }, "radius": { "sm": "4px", "md": "8px", "lg": "12px" } } }CLI读取这个文件之后，生成一段类似"你正在为一个使用以下设计token的项目生成代码，所有颜色、间距、圆角必须从以下值中选择"的指令，再交给代理。这样代理的每一次生成，都带着明确的约束。
4.4 token的版本管理：别让代理用过期的东西
还有一个容易被忽略的点：token是会变的。今天主色是蓝色，明天可能就换成紫色了。如果代理用的还是旧token，生成出来的东西就跟项目对不上。
所以token配置文件应该纳入版本管理，跟代码一起走。CLI在调用代理之前，应该检查token文件的版本，确保用的是最新的。如果token有变更，最好能有一个"迁移"机制，把旧token映射到新token，避免代理生成出"半新半旧"的代码。
5. 把视觉反馈翻译成代理能理解的语言
5.1 为什么"截图给模型看"不够用
Browser extension形态最直觉的做法是：把渲染结果截图，交给多模态模型，让模型判断"好不好看"。我试过这个路子，效果不太稳定。
问题在于，多模态模型对"好看"的判断，跟人类设计师的判断有偏差。它可能会觉得一个间距不均匀的布局"看起来还行"，也可能会对一个其实很规整的布局挑刺。而且截图丢失了DOM结构信息，模型只能看到像素，看不到"这个元素用了什么样式"。
所以更靠谱的做法是"结构化反馈"：不是给模型看截图，而是把渲染结果的computed style提取出来，跟设计token做比对，把差异点列出来。
5.2 提取computed style做规范检查
浏览器提供了getComputedStyle这个API，可以拿到任意元素最终生效的样式。Browser extension可以用这个API，把代理生成的组件的样式抓出来，然后跟token做比对。
比如，extension检测到一个按钮的border-radius是10px，而token体系里只有4px/8px/12px，那它就可以标记出这个"违规"。再比如，检测到两个相邻元素的间距是12px，而token体系里12px不是一个标准间距值，那也可以标记出来。
这种检查是确定性的，不依赖模型的判断，所以更可靠。检查出来的问题，可以格式化成一段文本，反馈给代理："按钮的圆角用了10px，不在token体系内，请从4px/8px/12px中选择。"
5.3 交互状态的自动化测试
除了静态样式，交互状态也是重灾区。代理生成的组件，hover态、focus态经常是缺失或者不协调的。
Browser extension可以模拟这些交互：用dispatchEvent触发hover，然后抓取hover态的样式；用focus()触发focus，抓取focus态的样式。然后把各个状态的样式列出来，检查是否一致、是否符合token。
我实测下来，这个检查能抓出不少问题。比如一个按钮的default态圆角是8px，hover态圆角变成了6px——这种问题人工检查很容易漏，但自动化测试一抓一个准。
5.4 把反馈闭环做短
反馈闭环的长度，直接决定了迭代效率。理想情况下，应该是"发现问题→反馈→修复→验证"在一个界面里完成。
Browser extension可以做成一个侧边栏：左边是渲染结果，右边是检测到的问题列表。你点一个问题，它高亮对应的元素；你点"修复"，它把问题反馈给代理，代理重新生成那一部分代码；代码更新之后，extension自动重新渲染，你再确认。
这个闭环一旦跑通，前端设计的迭代就从"改代码→切窗口→刷新→看效果"变成了"点一下→看结果"，效率提升是数量级的。
6. 实测中踩过的坑和几条实用经验
6.1 代理会"过度设计"
我让代理生成一个简单的卡片组件，它给我加了一堆渐变、阴影、动画，看起来花里胡哨的。这就是"过度设计"——代理为了显得"设计感强"，堆了一堆不必要的样式。
解决办法是在prompt里明确"克制"的约束。比如"只使用token体系内的样式值""不要添加token体系外的视觉效果""优先使用简单的布局方案"。这些约束写进去之后，代理的输出会收敛很多。
6.2 token太多反而会干扰代理
我一开始把token定义得非常细，颜色有几十个，间距有十几档。结果代理在生成时反而不知道该用哪个，经常选错。
后来我精简了一下，颜色只保留最核心的十几个，间距只保留五档。代理的选择空间小了，输出的准确性反而高了。所以token不是越多越好，够用就行。
6.3 别指望代理一次生成就impeccable
即使有token约束、有反馈闭环，代理第一次生成的东西，大概率还是需要调整。impeccable是一个迭代的过程，不是一次性的结果。
我的做法是：第一轮让代理生成结构，第二轮用extension检查规范，第三轮针对具体问题做微调。三轮下来，基本能达到"挑不出大毛病"的程度。想一轮到位，不现实。
6.4 CLI的调用频率要控制
CLI形态虽然方便，但每次调用都要读token、拼prompt、调模型，有开销。如果每改一行代码就跑一次CLI，效率反而低。
我的经验是：CLI用在"批量生成"和"提交前检查"这两个节点上。日常的小修改，直接在编辑器里手动改，比跑CLI快。
6.5 browser extension的权限要最小化
Browser extension要读取页面样式、模拟交互，权限不小。我建议只申请必要的权限，而且只在开发环境的页面上启用。生产环境的页面，不要装这类extension，避免不必要的风险。
6.6 设计token的变更要有记录
前面提过token会变。我踩过一个坑：token改了之后，代理还在用旧的，生成出来的代码跟项目对不上，排查了半天才发现是token文件没更新。
后来我加了一个机制：token文件变更时，自动生成一个变更日志，CLI在调用代理之前先读这个日志，如果有变更，就在prompt里提醒代理"注意，以下token已更新"。这样代理就不会用错。
7. 如果你现在就想动手，从哪几个环节切入
7.1 第一步：把现有项目的设计token整理出来
不用一开始就追求完美，先把最核心的几类token整理出来：颜色、间距、圆角、字体。整理的方式可以是从现有的CSS里提取，也可以是重新定义一套。
整理的时候注意两点：一是值要明确，不要写"大概8px左右"；二是命名要有语义，不要用--color-1这种无意义的命名。
7.2 第二步：写一个最简单的CLI脚本，把token注入到prompt里
不用一上来就做完整的工具，先写一个脚本，读token文件，拼一段prompt，调用你常用的AI编码代理。跑通这个流程之后，再逐步加功能。
脚本可以用Node.js写，因为大部分AI编码代理的CLI都是Node生态的。核心逻辑就是读文件、拼字符串、调API。
7.3 第三步：做一个最简版的browser extension，只做规范检查
Extension不用做太复杂，先实现一个功能：抓取页面上所有元素的computed style，跟token比对，把不符合规范的标出来。
这个功能实现起来不难，用document.querySelectorAll('*')遍历所有元素，用getComputedStyle拿样式，跟token做比对。跑通之后，你就能看到代理生成的代码里有多少"违规"。
7.4 第四步：把反馈闭环串起来
前两步跑通之后，把CLI和extension串起来：extension检测到问题，把问题格式化，通过某种方式（比如本地HTTP服务）传给CLI，CLI调用代理重新生成，生成结果写回项目，extension自动刷新。
这个闭环一开始可能很粗糙，但只要能跑通，你就能感受到效率的提升。后面再逐步优化各个环节。
7.5 第五步：积累"问题模式库"
跑一段时间之后，你会发现代理犯的错误是有规律的：圆角不一致、间距不统一、hover态缺失、颜色用错。把这些规律整理成一个"问题模式库"，在prompt里提前告诉代理"避免这些常见错误"，能显著减少返工。
这个库是越用越值钱的。它记录的是你这个项目、你这个团队特有的问题模式，比通用的最佳实践更有针对性。
8. 关于impeccable这个方向，我个人的几点判断
第一，这个方向的核心不是"让AI生成更花哨的设计"，而是"让AI生成更一致、更可控的设计"。impeccable的意思是"挑不出毛病"，不是"惊艳"。一致性比惊艳更难做到，也更有价值。
第二，CLI和browser extension这两种形态，短期内不会合并。它们覆盖的是工作流的不同阶段，各有各的价值。真正好用的工具，应该是两者配合，而不是二选一。
第三，设计token体系是地基，没有这个地基，上面盖什么都是空中楼阁。如果你现在还没整理token，先别急着上工具，把token整理清楚再说。
第四，反馈闭环的长度是效率的关键。闭环越短，迭代越快。Browser extension的价值，很大程度上就在于它把闭环缩短到了"点一下"的程度。
第五，别指望工具能解决所有问题。审美这件事，最终还是需要人来把关。工具能做的是把"明显的问题"自动化掉，把人的精力释放出来，去做那些真正需要判断力的决策。
我自己现在的做法是：用CLI做批量生成和提交前检查，用browser extension做视觉验证和就地调整，token体系作为两者的共同基础。这套流程跑下来，前端设计的返工率比之前低了不少，但离"impeccable"还有距离。这个距离，可能正是这个方向接下来要填的坑。
