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态圆角是8pxhover态圆角变成了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服务传给CLICLI调用代理重新生成生成结果写回项目extension自动刷新。这个闭环一开始可能很粗糙但只要能跑通你就能感受到效率的提升。后面再逐步优化各个环节。7.5 第五步积累问题模式库跑一段时间之后你会发现代理犯的错误是有规律的圆角不一致、间距不统一、hover态缺失、颜色用错。把这些规律整理成一个问题模式库在prompt里提前告诉代理避免这些常见错误能显著减少返工。这个库是越用越值钱的。它记录的是你这个项目、你这个团队特有的问题模式比通用的最佳实践更有针对性。8. 关于impeccable这个方向我个人的几点判断第一这个方向的核心不是让AI生成更花哨的设计而是让AI生成更一致、更可控的设计。impeccable的意思是挑不出毛病不是惊艳。一致性比惊艳更难做到也更有价值。第二CLI和browser extension这两种形态短期内不会合并。它们覆盖的是工作流的不同阶段各有各的价值。真正好用的工具应该是两者配合而不是二选一。第三设计token体系是地基没有这个地基上面盖什么都是空中楼阁。如果你现在还没整理token先别急着上工具把token整理清楚再说。第四反馈闭环的长度是效率的关键。闭环越短迭代越快。Browser extension的价值很大程度上就在于它把闭环缩短到了点一下的程度。第五别指望工具能解决所有问题。审美这件事最终还是需要人来把关。工具能做的是把明显的问题自动化掉把人的精力释放出来去做那些真正需要判断力的决策。我自己现在的做法是用CLI做批量生成和提交前检查用browser extension做视觉验证和就地调整token体系作为两者的共同基础。这套流程跑下来前端设计的返工率比之前低了不少但离impeccable还有距离。这个距离可能正是这个方向接下来要填的坑。