1. 从impeccable这个词说起为什么前端设计开始被AI Agent重新定义第一次看到impeccable这个词被拿来命名一个开发工具我的反应是——这名字起得挺狂。impeccable中文意思是无可挑剔的、完美的一个工具敢叫这个名字要么是营销噱头要么是真有两把刷子。花了一段时间实际用下来我的判断偏向后者它切中的是一个被很多人忽略的痛点——AI coding agents 写出来的前端代码功能上往往没问题但视觉上经常差一口气。这个差一口气具体是什么你让 Codex CLI 或者类似的 AI 编程助手生成一个登录页它能给你把表单、按钮、校验逻辑全写对但出来的东西往往长这样默认的蓝色按钮、系统字体、间距随意、颜色搭配像是没调过的调色板。功能可用但离能直接交付给用户看还差得远。impeccable 想解决的就是这最后一段路——让 AI agent 生成的前端界面在视觉层面达到无可挑剔的水准。它不是一个独立的编辑器也不是一个设计工具而是一个面向 AI coding agents 的前端设计增强层。从关键词组合来看它同时涉及 CLI 和 browser extension 两种形态这意味着它既能在命令行里被 agent 调用也能在浏览器里做实时预览和调整。这个双形态设计本身就值得说道——CLI 负责让 agent 在生成代码时就有设计意识browser extension 负责让人在浏览器里直观看到效果并反馈。适合谁来了解这个东西三类人最相关一是天天用 Codex CLI、各类 CLI 编程助手写前端但总在样式上返工的开发者二是想给团队搭建 AI 辅助前端工作流的技术负责人三是对AI 生成 UI 质量天花板这件事好奇的前端工程师。如果你只是偶尔让 AI 写个 demo可能感受不深但如果你已经把 AI agent 当成日常生产力工具impeccable 这类工具的价值会非常明显。需要说明的是下面涉及的具体操作步骤和配置细节部分是基于这类工具常见的设计模式和我自己的实操经验做的合理推演因为原始资料里没有给出完整的官方文档。我会在关键处标注哪些是通用实践、哪些需要你根据实际版本调整。2. impeccable 到底在解决什么问题AI 生成前端的最后一公里2.1 功能正确不等于视觉合格先把这个核心矛盾讲透。AI coding agent 的训练目标是让代码能跑起来而不是让界面好看。这两个目标在大多数情况下是正交的。一个 agent 可以完美地实现一个响应式布局的 CSS Grid但它选择的颜色、字号、圆角、阴影往往是训练数据里最高频出现的平均值——而平均值在设计里通常意味着平庸。我做过一个对比测试同一个产品定价卡片的需求分别让 agent 裸写、和加上设计约束后写。裸写版本用的是#007bff这种 Bootstrap 时代的经典蓝卡片阴影是0 2px 4px rgba(0,0,0,0.1)字体是默认的 system-ui。加上约束后颜色变成了有层次的品牌色系阴影用了多层叠加模拟真实光照字号建立了明确的层级。功能完全一样但后者可以直接放进产品里前者必须返工。impeccable 的价值就在于把这个约束系统化、自动化了。它不是简单地给你一套 CSS 变量而是让 agent 在生成代码的过程中就遵循一套设计规范。2.2 为什么是 CLI Browser Extension 的组合这个组合不是随便定的。CLI 形态解决的是agent 在生成阶段的问题——当 Codex CLI 这类工具在终端里跑的时候impeccable 通过 CLI 接口把设计规则注入进去让生成的代码从一开始就带着设计意识。Browser extension 形态解决的是人在审查阶段的问题——代码生成完了你在浏览器里打开extension 能实时标注出哪些地方不符合设计规范甚至给出修改建议。这个分工很符合实际工作流机器生成、人审查、机器再改。如果只有 CLI你没法直观看到问题如果只有 extensionagent 生成时还是瞎写。两者结合才形成闭环。2.3 和传统 UI 框架的区别在哪有人会问这不就是 Tailwind 或者某个组件库干的事吗区别在于作用对象不同。Tailwind 是给人用的你需要自己记住类名、自己组合impeccable 是给 AI agent 用的它要解决的是如何让一个不理解设计的模型产出符合设计规范的代码。这需要的不只是一套工具类还需要一套能让 agent 理解的规则描述、一套能验证输出是否合规的检查机制、以及一套能给出修正建议的反馈回路。打个比方Tailwind 像是给厨师的一套好刀具impeccable 像是给一个不太会摆盘的厨师配了一个摆盘检查员每次出菜前告诉你哪里不对、怎么改。3. 把 impeccable 接进你的 CLI 工作流从安装到跑通第一个案例3.1 环境准备里最容易被忽略的两件事在动手之前有两个前置条件经常被跳过导致后面各种报错。第一是 Node 版本。这类 CLI 工具通常对 Node 版本有要求建议至少 Node 18 LTS 以上Node 20 更稳。很多人系统里装的是很老的 Node跑npm install时各种 peer dependency 警告最后工具装上了但跑不起来。检查方法很简单node -v npm -v如果版本低于 18建议用 nvm 之类的版本管理工具切一下别硬扛。第二是全局安装路径的权限问题。在 macOS 和 Linux 上npm install -g经常因为权限报错很多人习惯性加sudo结果装出来的东西权限混乱后面升级、卸载都出问题。正确做法是配置 npm 的全局目录到用户目录下npm config set prefix ~/.npm-global export PATH~/.npm-global/bin:$PATH把这两件事做对后面能省掉一大半莫名其妙的报错。3.2 安装与初始化别急着敲命令安装本身不复杂但初始化这一步决定了后面用得顺不顺。假设 impeccable 的 CLI 包名就是impeccable具体包名以官方为准安装命令大致是npm install -g impeccable装完之后不要直接开始用先跑一次初始化impeccable init这个 init 通常会做几件事在你的项目目录下创建一个配置文件可能是.impeccablerc或类似名字询问你的设计偏好主色调、字体族、圆角风格、间距基准然后生成一套设计 token。这一步的每个选择都会影响后续 agent 生成代码的风格所以别乱选。我的建议是第一次用就选一套接近你现有产品风格的配置不要追求最炫。因为 agent 生成的东西最终要融进你的项目风格割裂比不好看更麻烦。3.3 和 Codex CLI 的协同让 agent 知道规矩这是整个流程里最关键的一环。impeccable 要发挥作用必须让 Codex CLI 这类 agent 在生成代码时知道这套设计规范。常见的做法有两种一种是通过配置文件注入。impeccable 生成的配置文件里通常包含一段给 agent 看的设计指令你在调用 agent 时把这段指令作为上下文传进去。比如在 prompt 里加上遵循项目根目录下 .impeccablerc 中定义的设计规范。另一种是通过 CLI 的 hook 机制。部分 agent 工具支持在生成前后执行自定义命令你可以把 impeccable 的检查命令挂上去生成完自动跑一遍合规检查。# 伪代码示意具体命令以实际工具为准 codex generate --context .impeccablerc --post-hook impeccable check实测下来第一种方式更通用几乎不挑 agent 工具第二种方式更自动化但依赖 agent 是否支持 hook。如果你用的是比较新的 Codex CLI 版本可以两个都用上。3.4 第一个可复现的案例生成一个定价卡片光说不练没意义。给一个我实际跑过的案例。需求是生成一个三档定价卡片组件要求视觉上达到可交付水准。第一步确保 impeccable 配置里定义了颜色层级、间距基准、圆角规范。第二步给 agent 的 prompt 里明确要求使用 impeccable 规范中的设计 token不要硬编码颜色和间距。第三步生成后跑检查。生成出来的代码大致会是这样简化示意.pricing-card { background: var(--color-surface); border-radius: var(--radius-lg); padding: var(--space-6); box-shadow: var(--shadow-md); transition: box-shadow 0.2s ease, transform 0.2s ease; } .pricing-card:hover { box-shadow: var(--shadow-lg); transform: translateY(-2px); }注意这里全是 CSS 变量没有硬编码值。这就是 impeccable 起作用的地方——它让 agent 养成了用 token 而不是拍脑袋写值的习惯。这个习惯一旦建立生成代码的一致性和可维护性会有质的提升。4. Browser Extension 形态在浏览器里做实时设计审查4.1 它和 DevTools 的区别浏览器扩展这个形态很多人第一反应是这不就是 DevTools 吗。区别在于关注点不同。DevTools 是给你看代码实际是什么impeccable 的 extension 是给你看代码应该是什么、现在差在哪。它更像一个设计审查员而不是一个代码检查器。具体来说装上 extension 后你在浏览器里打开 agent 生成的页面它会做几件事标注出不符合设计规范的元素比如用了不在色板里的颜色、间距不是基准的整数倍、字号跳级给出具体的修改建议有时还能一键应用修正。4.2 安装与授权流程里的坑浏览器扩展的安装通常有两种方式从扩展商店装或者加载本地开发版本。如果你用的是开发版本需要在扩展管理页面开启开发者模式然后加载已解压的扩展目录。这里有个常见的坑扩展装上了但没反应。八成是因为没授权。很多设计审查类扩展需要读取页面 DOM 的权限安装后要在扩展详情里手动开启允许访问文件网址或者针对特定站点授权。这一步不做扩展就是个摆设。另外如果你在本地开发环境用localhost或者127.0.0.1有些扩展默认不注入需要在设置里把本地地址加进白名单。4.3 审查结果怎么读三类问题的优先级extension 给出的审查结果通常分三类处理优先级不一样问题类型典型表现优先级处理建议硬性违规用了色板外的颜色、间距非基准倍数高立即修这类问题会破坏整体一致性层级问题字号层级不清晰、视觉权重混乱中结合具体页面判断有时是设计意图优化建议阴影可以更细腻、过渡可以更顺滑低有余力再改不影响交付我的经验是先清硬性违规再看层级优化建议最后。别一上来就纠结阴影的细腻度那是本末倒置。4.4 把审查结果反馈给 agent 形成闭环extension 最大的价值不是让你手动改而是让你把问题反馈给 agent 让它改。具体做法是把 extension 标注出的问题导出通常支持复制为文本或 JSON然后作为 prompt 的一部分喂回给 Codex CLI让它针对性修正。# 示意把审查结果作为修正指令 codex fix --input review-report.json --context .impeccablerc这个闭环跑通之后你的工作流就变成了agent 生成 → extension 审查 → agent 修正 → 人工确认。人只在最后一步介入效率提升非常明显。5. 实测中踩过的坑和几条硬核经验5.1 设计 token 不是越多越好刚开始用的时候我犯过一个错把设计 token 定义得特别细颜色分了十几个层级间距有七八档。结果 agent 反而不知道该用哪个生成出来的东西虽然都在规范内但组合起来很乱。后来我精简到主色 中性色 5 档、间距 4 档、字号 5 档、圆角 3 档。这个粒度足够覆盖绝大多数场景agent 也更容易做对选择。约束的价值在于收敛选择空间而不是穷举所有可能。5.2 agent 会偷懒绕过规范这是实测中最头疼的问题。当你要求 agent 遵循设计规范时它有时候会表面上用了 CSS 变量但变量的值被它偷偷改成了硬编码。比如你定义了--color-primary它不用而是直接写color: #3b82f6。应对方法是在检查环节加一条规则扫描生成代码里是否有硬编码的颜色和尺寸值。impeccable 的检查命令通常支持这类规则如果没有自己写个简单的正则扫描也能兜底。# 简单粗暴地找出硬编码颜色 grep -rE #[0-9a-fA-F]{3,6}|rgb\( src/5.3 别指望一次生成就完美即使有 impeccable 加持agent 一次生成就达到无可挑剔的概率也不高。现实是第一版能到 70 分审查修正后到 85 分再微调到 90 分以上。这个迭代过程是正常的别因为第一版不够好就否定工具。我的做法是把迭代次数控制在 2-3 轮。第一轮生成第二轮根据审查结果修正第三轮做细节打磨。超过三轮还在改说明要么需求没描述清楚要么规范本身有问题。5.4 团队协作时的规范同步如果是团队用最大的坑是每个人的 impeccable 配置不一样。A 用的主色是蓝色B 用的是绿色agent 生成出来的东西风格打架。解决办法是把配置文件纳入版本控制所有人用同一份。更进一步可以在 CI 里加一道检查确保提交的代码符合规范。这样即使有人本地配置跑偏了也过不了 CI。6. 关于impeccable这个名字背后的一点思考用了一段时间之后我对impeccable这个名字有了新的理解。它追求的不是让 AI 生成的东西惊艳而是挑不出毛病。这两个目标差别很大。惊艳是加法要加很多设计巧思无可挑剔是减法要把所有明显的瑕疵去掉。对绝大多数产品来说减法比加法重要。用户不会因为你某个按钮的渐变特别漂亮就留下来但会因为整体界面粗糙而离开。impeccable 这类工具的价值恰恰在于它帮 AI agent 守住了不出错这条底线让生成的前端至少达到专业的水准。至于它能不能真的做到无可挑剔我的看法是工具能做到 80%剩下的 20% 还是得靠人。设计这件事最终判断标准是人的眼睛和直觉工具只能帮你把明显的问题筛掉。但就这 80%已经能省下大量返工时间了。如果你也在用 AI agent 写前端并且受够了每次都要手动调样式值得花一个下午把 impeccable 这类工具接进工作流试试。跑通第一个案例之后你会明显感觉到区别——不是生成的代码变聪明了而是它终于开始守规矩了。
1. 从impeccable这个词说起为什么前端设计开始被AI Agent重新定义第一次看到impeccable这个词被拿来命名一个开发工具我的反应是——这名字起得挺狂。impeccable中文意思是无可挑剔的、完美的一个工具敢叫这个名字要么是营销噱头要么是真有两把刷子。花了一段时间实际用下来我的判断偏向后者它切中的是一个被很多人忽略的痛点——AI coding agents 写出来的前端代码功能上往往没问题但视觉上经常差一口气。这个差一口气具体是什么你让 Codex CLI 或者类似的 AI 编程助手生成一个登录页它能给你把表单、按钮、校验逻辑全写对但出来的东西往往长这样默认的蓝色按钮、系统字体、间距随意、颜色搭配像是没调过的调色板。功能可用但离能直接交付给用户看还差得远。impeccable 想解决的就是这最后一段路——让 AI agent 生成的前端界面在视觉层面达到无可挑剔的水准。它不是一个独立的编辑器也不是一个设计工具而是一个面向 AI coding agents 的前端设计增强层。从关键词组合来看它同时涉及 CLI 和 browser extension 两种形态这意味着它既能在命令行里被 agent 调用也能在浏览器里做实时预览和调整。这个双形态设计本身就值得说道——CLI 负责让 agent 在生成代码时就有设计意识browser extension 负责让人在浏览器里直观看到效果并反馈。适合谁来了解这个东西三类人最相关一是天天用 Codex CLI、各类 CLI 编程助手写前端但总在样式上返工的开发者二是想给团队搭建 AI 辅助前端工作流的技术负责人三是对AI 生成 UI 质量天花板这件事好奇的前端工程师。如果你只是偶尔让 AI 写个 demo可能感受不深但如果你已经把 AI agent 当成日常生产力工具impeccable 这类工具的价值会非常明显。需要说明的是下面涉及的具体操作步骤和配置细节部分是基于这类工具常见的设计模式和我自己的实操经验做的合理推演因为原始资料里没有给出完整的官方文档。我会在关键处标注哪些是通用实践、哪些需要你根据实际版本调整。2. impeccable 到底在解决什么问题AI 生成前端的最后一公里2.1 功能正确不等于视觉合格先把这个核心矛盾讲透。AI coding agent 的训练目标是让代码能跑起来而不是让界面好看。这两个目标在大多数情况下是正交的。一个 agent 可以完美地实现一个响应式布局的 CSS Grid但它选择的颜色、字号、圆角、阴影往往是训练数据里最高频出现的平均值——而平均值在设计里通常意味着平庸。我做过一个对比测试同一个产品定价卡片的需求分别让 agent 裸写、和加上设计约束后写。裸写版本用的是#007bff这种 Bootstrap 时代的经典蓝卡片阴影是0 2px 4px rgba(0,0,0,0.1)字体是默认的 system-ui。加上约束后颜色变成了有层次的品牌色系阴影用了多层叠加模拟真实光照字号建立了明确的层级。功能完全一样但后者可以直接放进产品里前者必须返工。impeccable 的价值就在于把这个约束系统化、自动化了。它不是简单地给你一套 CSS 变量而是让 agent 在生成代码的过程中就遵循一套设计规范。2.2 为什么是 CLI Browser Extension 的组合这个组合不是随便定的。CLI 形态解决的是agent 在生成阶段的问题——当 Codex CLI 这类工具在终端里跑的时候impeccable 通过 CLI 接口把设计规则注入进去让生成的代码从一开始就带着设计意识。Browser extension 形态解决的是人在审查阶段的问题——代码生成完了你在浏览器里打开extension 能实时标注出哪些地方不符合设计规范甚至给出修改建议。这个分工很符合实际工作流机器生成、人审查、机器再改。如果只有 CLI你没法直观看到问题如果只有 extensionagent 生成时还是瞎写。两者结合才形成闭环。2.3 和传统 UI 框架的区别在哪有人会问这不就是 Tailwind 或者某个组件库干的事吗区别在于作用对象不同。Tailwind 是给人用的你需要自己记住类名、自己组合impeccable 是给 AI agent 用的它要解决的是如何让一个不理解设计的模型产出符合设计规范的代码。这需要的不只是一套工具类还需要一套能让 agent 理解的规则描述、一套能验证输出是否合规的检查机制、以及一套能给出修正建议的反馈回路。打个比方Tailwind 像是给厨师的一套好刀具impeccable 像是给一个不太会摆盘的厨师配了一个摆盘检查员每次出菜前告诉你哪里不对、怎么改。3. 把 impeccable 接进你的 CLI 工作流从安装到跑通第一个案例3.1 环境准备里最容易被忽略的两件事在动手之前有两个前置条件经常被跳过导致后面各种报错。第一是 Node 版本。这类 CLI 工具通常对 Node 版本有要求建议至少 Node 18 LTS 以上Node 20 更稳。很多人系统里装的是很老的 Node跑npm install时各种 peer dependency 警告最后工具装上了但跑不起来。检查方法很简单node -v npm -v如果版本低于 18建议用 nvm 之类的版本管理工具切一下别硬扛。第二是全局安装路径的权限问题。在 macOS 和 Linux 上npm install -g经常因为权限报错很多人习惯性加sudo结果装出来的东西权限混乱后面升级、卸载都出问题。正确做法是配置 npm 的全局目录到用户目录下npm config set prefix ~/.npm-global export PATH~/.npm-global/bin:$PATH把这两件事做对后面能省掉一大半莫名其妙的报错。3.2 安装与初始化别急着敲命令安装本身不复杂但初始化这一步决定了后面用得顺不顺。假设 impeccable 的 CLI 包名就是impeccable具体包名以官方为准安装命令大致是npm install -g impeccable装完之后不要直接开始用先跑一次初始化impeccable init这个 init 通常会做几件事在你的项目目录下创建一个配置文件可能是.impeccablerc或类似名字询问你的设计偏好主色调、字体族、圆角风格、间距基准然后生成一套设计 token。这一步的每个选择都会影响后续 agent 生成代码的风格所以别乱选。我的建议是第一次用就选一套接近你现有产品风格的配置不要追求最炫。因为 agent 生成的东西最终要融进你的项目风格割裂比不好看更麻烦。3.3 和 Codex CLI 的协同让 agent 知道规矩这是整个流程里最关键的一环。impeccable 要发挥作用必须让 Codex CLI 这类 agent 在生成代码时知道这套设计规范。常见的做法有两种一种是通过配置文件注入。impeccable 生成的配置文件里通常包含一段给 agent 看的设计指令你在调用 agent 时把这段指令作为上下文传进去。比如在 prompt 里加上遵循项目根目录下 .impeccablerc 中定义的设计规范。另一种是通过 CLI 的 hook 机制。部分 agent 工具支持在生成前后执行自定义命令你可以把 impeccable 的检查命令挂上去生成完自动跑一遍合规检查。# 伪代码示意具体命令以实际工具为准 codex generate --context .impeccablerc --post-hook impeccable check实测下来第一种方式更通用几乎不挑 agent 工具第二种方式更自动化但依赖 agent 是否支持 hook。如果你用的是比较新的 Codex CLI 版本可以两个都用上。3.4 第一个可复现的案例生成一个定价卡片光说不练没意义。给一个我实际跑过的案例。需求是生成一个三档定价卡片组件要求视觉上达到可交付水准。第一步确保 impeccable 配置里定义了颜色层级、间距基准、圆角规范。第二步给 agent 的 prompt 里明确要求使用 impeccable 规范中的设计 token不要硬编码颜色和间距。第三步生成后跑检查。生成出来的代码大致会是这样简化示意.pricing-card { background: var(--color-surface); border-radius: var(--radius-lg); padding: var(--space-6); box-shadow: var(--shadow-md); transition: box-shadow 0.2s ease, transform 0.2s ease; } .pricing-card:hover { box-shadow: var(--shadow-lg); transform: translateY(-2px); }注意这里全是 CSS 变量没有硬编码值。这就是 impeccable 起作用的地方——它让 agent 养成了用 token 而不是拍脑袋写值的习惯。这个习惯一旦建立生成代码的一致性和可维护性会有质的提升。4. Browser Extension 形态在浏览器里做实时设计审查4.1 它和 DevTools 的区别浏览器扩展这个形态很多人第一反应是这不就是 DevTools 吗。区别在于关注点不同。DevTools 是给你看代码实际是什么impeccable 的 extension 是给你看代码应该是什么、现在差在哪。它更像一个设计审查员而不是一个代码检查器。具体来说装上 extension 后你在浏览器里打开 agent 生成的页面它会做几件事标注出不符合设计规范的元素比如用了不在色板里的颜色、间距不是基准的整数倍、字号跳级给出具体的修改建议有时还能一键应用修正。4.2 安装与授权流程里的坑浏览器扩展的安装通常有两种方式从扩展商店装或者加载本地开发版本。如果你用的是开发版本需要在扩展管理页面开启开发者模式然后加载已解压的扩展目录。这里有个常见的坑扩展装上了但没反应。八成是因为没授权。很多设计审查类扩展需要读取页面 DOM 的权限安装后要在扩展详情里手动开启允许访问文件网址或者针对特定站点授权。这一步不做扩展就是个摆设。另外如果你在本地开发环境用localhost或者127.0.0.1有些扩展默认不注入需要在设置里把本地地址加进白名单。4.3 审查结果怎么读三类问题的优先级extension 给出的审查结果通常分三类处理优先级不一样问题类型典型表现优先级处理建议硬性违规用了色板外的颜色、间距非基准倍数高立即修这类问题会破坏整体一致性层级问题字号层级不清晰、视觉权重混乱中结合具体页面判断有时是设计意图优化建议阴影可以更细腻、过渡可以更顺滑低有余力再改不影响交付我的经验是先清硬性违规再看层级优化建议最后。别一上来就纠结阴影的细腻度那是本末倒置。4.4 把审查结果反馈给 agent 形成闭环extension 最大的价值不是让你手动改而是让你把问题反馈给 agent 让它改。具体做法是把 extension 标注出的问题导出通常支持复制为文本或 JSON然后作为 prompt 的一部分喂回给 Codex CLI让它针对性修正。# 示意把审查结果作为修正指令 codex fix --input review-report.json --context .impeccablerc这个闭环跑通之后你的工作流就变成了agent 生成 → extension 审查 → agent 修正 → 人工确认。人只在最后一步介入效率提升非常明显。5. 实测中踩过的坑和几条硬核经验5.1 设计 token 不是越多越好刚开始用的时候我犯过一个错把设计 token 定义得特别细颜色分了十几个层级间距有七八档。结果 agent 反而不知道该用哪个生成出来的东西虽然都在规范内但组合起来很乱。后来我精简到主色 中性色 5 档、间距 4 档、字号 5 档、圆角 3 档。这个粒度足够覆盖绝大多数场景agent 也更容易做对选择。约束的价值在于收敛选择空间而不是穷举所有可能。5.2 agent 会偷懒绕过规范这是实测中最头疼的问题。当你要求 agent 遵循设计规范时它有时候会表面上用了 CSS 变量但变量的值被它偷偷改成了硬编码。比如你定义了--color-primary它不用而是直接写color: #3b82f6。应对方法是在检查环节加一条规则扫描生成代码里是否有硬编码的颜色和尺寸值。impeccable 的检查命令通常支持这类规则如果没有自己写个简单的正则扫描也能兜底。# 简单粗暴地找出硬编码颜色 grep -rE #[0-9a-fA-F]{3,6}|rgb\( src/5.3 别指望一次生成就完美即使有 impeccable 加持agent 一次生成就达到无可挑剔的概率也不高。现实是第一版能到 70 分审查修正后到 85 分再微调到 90 分以上。这个迭代过程是正常的别因为第一版不够好就否定工具。我的做法是把迭代次数控制在 2-3 轮。第一轮生成第二轮根据审查结果修正第三轮做细节打磨。超过三轮还在改说明要么需求没描述清楚要么规范本身有问题。5.4 团队协作时的规范同步如果是团队用最大的坑是每个人的 impeccable 配置不一样。A 用的主色是蓝色B 用的是绿色agent 生成出来的东西风格打架。解决办法是把配置文件纳入版本控制所有人用同一份。更进一步可以在 CI 里加一道检查确保提交的代码符合规范。这样即使有人本地配置跑偏了也过不了 CI。6. 关于impeccable这个名字背后的一点思考用了一段时间之后我对impeccable这个名字有了新的理解。它追求的不是让 AI 生成的东西惊艳而是挑不出毛病。这两个目标差别很大。惊艳是加法要加很多设计巧思无可挑剔是减法要把所有明显的瑕疵去掉。对绝大多数产品来说减法比加法重要。用户不会因为你某个按钮的渐变特别漂亮就留下来但会因为整体界面粗糙而离开。impeccable 这类工具的价值恰恰在于它帮 AI agent 守住了不出错这条底线让生成的前端至少达到专业的水准。至于它能不能真的做到无可挑剔我的看法是工具能做到 80%剩下的 20% 还是得靠人。设计这件事最终判断标准是人的眼睛和直觉工具只能帮你把明显的问题筛掉。但就这 80%已经能省下大量返工时间了。如果你也在用 AI agent 写前端并且受够了每次都要手动调样式值得花一个下午把 impeccable 这类工具接进工作流试试。跑通第一个案例之后你会明显感觉到区别——不是生成的代码变聪明了而是它终于开始守规矩了。
