大模型生成的前端界面往往充斥着千篇一律的卡片堆叠、无语义渐变，呈现出明显的同质化“AI 味”。Impeccable Skill 通过持久化设计上下文、动词化指令集与 AST 检测钩子，将模糊的主观设计诉求转化为确定性工程约束，在编码阶段规范智能体的布局决策与状态覆盖。

官方技术规范与源码参考：Impeccable 官方网站 与 Impeccable 开源仓库。

前端代码的模式化缺陷与收敛机理

大语言模型在生成前端界面代码时，由于预训练语料中通用开源模板与展示型代码样例占据较高概率权重，在缺乏显式设计约束的前提下，极易表现出统计学层面的模式收敛（即业界常称的模板化“AI 味”或 AI Slop）。这种收敛使得生成的界面充斥着脱离业务事实的空泛组件与千篇一律的装饰。

预训练分布引发的三大视觉模式惯例

在 Impeccable 的核心技术规约中，明确记录了大语言模型在未加约束时，由于训练数据概率分布集中而高频收敛的三大预训练惯例（Training-Data Ruts）：

• 暖色奶油杂志风（Warm Editorial）：米白或暖奶油色底色，搭配高对比度的衬线展示字体，点缀陶土红或深橙色调。
• 暗黑霓虹边缘光（Dark Neon Glow）：高纯度深黑背景搭配单色霓虹强调色，容器边缘叠加发光阴影或径向渐变光晕。
• 宽幅报刊排版风（Broadsheet Wireframe）：全宽发丝细线网格分割，搭配斜体衬线标题与无功能意义的等宽字符标签。

当提示词缺乏结构化的项目事实与设计系统约束时，模型容易退化到上述模式之一，习惯性采用装饰性渐变、空洞卡片与占位组件填充界面留白。

前端生成中的反模式与 Craft Floor 质量底线规约

为阻断无约束的模板化生成，Impeccable 在其质量底线规约（Craft Floor）中对前端高频出现的“AI 味”反模式设立了硬性拒绝清单：

• 布局结构反模式：频繁使用等宽等高的“图标 + 粗体标题 + 描述文字”卡片作为主体框架；在卡片内部继续嵌套小卡片（Cards in cards）；在主标题上方附加无实质语义的胶囊状药丸标签或眉标（Kickers / Eyebrows）；在非阻断性流程中滥用弹窗（Modal）。
• 表面装饰反模式：滥用文字渐变裁剪（Gradient Text）；使用无模糊扩散的硬块投影（box-shadow: 4px 4px 0）；滥用无业务含义的磨砂毛玻璃（Glassmorphism）；使用 Emoji 或 Unicode 字符替代规范的矢量图标组件；将等宽字体作为装饰标签而非用于真实代码与遥测度量。
• 原生细节忽视：未对文本高亮选区（::selection）、输入光标颜色（caret-color）、原生滚动条以及键盘聚焦环（Focus Rings）进行定制，直接暴露浏览器底层默认样式。
• 交互状态缺失：通常仅生成静态展示态，遗漏悬停、聚焦、激活、禁用、骨架屏加载与错误恢复等动态交互分支。

设计规约向工程约束的转化机制

传统的提示工程通常依赖主观的自然语言修饰词（如“提高美感”、“设计要现代优雅”），缺乏客观标准且难以在多轮迭代中稳定维持。Impeccable 将设计知识转化为工程可执行架构：

• 显式规约约束：通过持久化的结构化文档建立单一事实来源（Single Source of Truth），强制模型遵循既定设计规范。
• 动词化操作指令：为智能体注入明确的工程操作指令（如 distill、polish、harden），替代模糊宽泛的自然语言修改请求。
• 确定性静态分析：借助 AST 解析与文件监听机制对组件源码与样式规则进行实时验证，阻断违规代码合并入库。

核心设计法则与产品界面的评测基准

消除界面中的拼凑痕迹，核心在于将认知成本控制在合理区间，确保信息主次分明且每一次交互均符合操作预期。Impeccable 在底层确立了四项核心工程设计准则：

面向操作界面的可用性质检基准（The Product Slop Test）

在面向操作形态的软件界面（Operate Mode，如控制台、编辑器与数据表）中，熟悉的通用模式是保障操作效率的关键。Impeccable 针对此类界面提出了可用性质检基准：

• 质检基准：具备该领域操作经验的用户能否即刻建立操作信任并顺畅流转，还是会在每一个设计失准或不合惯例的组件前产生操作迟疑。
• 缺陷剖析：此类界面的核心缺陷通常不是平整朴素，而是“缺乏明确目的的视觉违和（Strangeness without purpose）”——例如在紧凑表单中强行加入大圆角与渐变按钮、在密集数据表格中使用大字阶展示字体等。界面的视觉呈现应当服务于实际业务流，降低认知干扰。

业务需求优先与领域实体映射（The Brief Wins）

• 需求高于预设偏好：当业务需求明确指定了行业背景、视觉基调或特定调色板时，必须严格执行既定规约。模型不得脱离具体的业务事实而回退至通用公板设计。
• 提取具象领域语言：在构建新界面时，智能体须从目标用户熟悉的业务实体、行业工具、实体出版物或专业标准中提炼具象的视觉语言，而非套用空泛的通用模板。

交互组件全生命周期状态覆盖

在生产级前端工程中，交互式组件必须完整实现整个生命周期的反馈分支。Impeccable 要求组件完整覆盖以下 7 种状态分支：

• 常规态（Default）：无交互介入时的稳定基础状态。
• 悬停态（Hover）：指针设备悬停时的微交互视觉反馈。
• 聚焦态（Focus）：键盘导航到达时的清晰对比轮廓环，保障无障碍操作可感知。
• 激活态（Active）：按压或正在触发操作时的即时响应。
• 禁用态（Disabled）：业务规则受限时的低对比度弱化呈现与事件拦截。
• 加载态（Loading）：优先使用保持布局尺寸稳定的骨架屏（Skeleton），避免局部突兀的单点旋转加载动画引发页面重排（Layout Shift）。
• 错误态（Error）：操作失败时必须具备明确的问题说明与恢复动作入口，杜绝模糊技术报错或异常堆栈暴露。

单层级深度与原生细节样式控制

• 单层级深度原则（The Single-Elevation Rule）：每一个容器仅声明一种层级标识：要么使用 1px 细线边框，要么使用轻微位移阴影，避免同时叠加粗边框与大投影导致视觉层级混乱（Ghost Card）。
• 原生细节样式控制：未加修饰的浏览器底层样式会直接破坏界面的整体一致性。Impeccable 要求将文本高亮选区（::selection）、输入光标颜色（caret-color）、原生滚动条以及键盘聚焦轮廓等，统一纳入设计系统的样式控制体系中，消除视觉毛刺。

架构模型与核心规范

Impeccable 采用“持久化上下文 + 界面形态分类 + 概念种子探索 + 双层质量校验”的架构体系，确保设计决策与工程实现保持一致。

绘制核心架构与运行流程：

双设计规范上下文

Impeccable 依赖项目根目录下的两份轻量级 Markdown 文件维系智能体的设计约束：

• 产品上下文文件（PRODUCT.md）：记录产品定位、用户画像、目标场景、核心业务准则与无障碍要求。智能体在执行任何 UI 生成任务前，优先读取该文件以明确业务边界。
• 设计规范文件（DESIGN.md）：定义设计系统的核心设计 Token（调色板、字阶排版、间距梯度、圆角规范）以及命名设计规则（Named Rules）。

四种界面形态

针对不同业务场景的页面，用户目标存在本质差异。Impeccable 将页面划分为四类形态：

• Persuade（说服形态）：适用于产品落地页、营销活动与定价方案。核心目标是促成访客决策与行动转化，强调视觉表现力与主次动线。
• Operate（操作形态）：适用于管理控制台、仪表盘、代码编辑器与设置面板。核心目标是保障任务完成效率，以信息可扫读性、布局一致性与低认知负荷为首要指标，去除无用修饰。
• Read（阅读形态）：适用于技术文档、专栏文章与知识库。核心目标是促进长文本阅读与理解，控制单行文本长度（通常为 65–75 字符）并保持舒适的行高与段间距。
• Experience（体验形态）：适用于作品展示与数字展厅。弱化界面框架存在感，突出多媒体与内容载体本身。

概念种子生成机制（concept-seed 与风格原型碰撞）

大模型在无特定指向时往往偏向于统计中位数的通用设计方案。Impeccable 采用确定性的概念种子（Concept Seed）生成机制，提供可复现的设计探索分支：

当使用 /impeccable 描述内容时，会走到普通的 new-work 请求，其内部会运行概念种子发想命令：

# 针对新建界面运行设计方向探索
.agents/skills/impeccable/scripts/impeccable concept-seed --scope direction --mode <mode>

算法运作流程：

• 领域候选集推导：从目标业务实体、行业标准、历史出版物或专业工具中，提炼出 7 组具象的视觉系统候选方向。
• 引入预设风格原型（Catalog Challengers）：系统随机分配探索方向，并从内置目录中引入预设的成熟设计原型（如瑞士平面设计、工业仪器排版等风格原型作为挑战者）。风格原型提供严谨的结构框架与排版语法，结合产品的实际业务需求，在用户认同度与信息清晰度两个维度上展开对比评估（评定为 wins、competitive 或 declined）。
• 设计特征借鉴与吸收（Design Discipline Donation）：未完全入选的风格原型并不会被简单废弃，其具备的规范化设计特征（例如严格限定的色彩收敛度、紧凑高效的排版密度，以及真实反映数据层级的直观结构骨架）会被作为借鉴项，吸收注入最终的设计方案中。
• 风格倾向档位调节（Style Registers）：提供 plain（平实均衡）、safer（稳健保守）与 bolder（鲜明突出）三档风格倾向供开发者按需调节。

执行契约：视觉图主导与代码主导路径

Impeccable 区分了两种执行契约模式（由 .impeccable/config.json 中的 buildPath 决定）：

• Comp-led（视觉效果图主导）：当开发环境中具备图像生成工具时，在编码前先行生成高精度的首屏视觉设计图（Comp）。该视觉图作为明确的布局与空间约束契约，后续编写的代码必须对照该图进行视觉审查，防止大模型在还原布局时随意发散。
• Code-led（代码规范主导）：在无图像生成环境时，直接通过设计概要（Surface Brief）确立首屏视口布局（FIRST VIEWPORT）、字阶比例与特征动效等文本规范，后续代码审查直接对照该行为契约进行检验。

动词化指令体系与工作流编排

Impeccable 将设计工作流解构为具备明确工程语义的动作动词，避免模糊对话导致的生成偏离：

构建与规划阶段

• /impeccable shape [feature]：在正式编写 UI 代码前，先行梳理信息架构、交互状态分支与组件拆解结构。
• /impeccable init：扫描项目现有业务代码与文档，自动交互式引导生成初始 PRODUCT.md。
• /impeccable document：解析项目现有 CSS/Tailwind 配置与已有组件样式，提炼并输出 DESIGN.md。
• /impeccable extract [target]：从现存的特定页面实现中解耦可复用的设计 Token 与基础原子组件。

审查与审计阶段：双独立子智能体评审与五维代码审计

双独立子智能体并行评审（critique）

在执行 /impeccable critique [target] 指令时，宿主环境派生两个相互隔离的子智能体（Assessment A 与 Assessment B）并行执行，规避单上下文串行分析造成的思维锚定：

• Assessment A（宏观设计评审子智能体）：从专业设计角度评估设计的业务特异性（Design Specificity，检验界面是否专属于当前业务场景，还是换个 Logo 也能套用）、认知负荷（检查核心可视操作是否过多导致决策迟疑）、核心路径体验与整体布局。
• Assessment B（确定性规则检测子智能体）：运行 AST 扫描引擎，输出明确的代码规则违规清单。
• 隔离审查机制：Assessment A 在完全不接触 Assessment B 静态检测结果的前提下独立完成主观设计审查，防止客观规则数据过早介入干扰宏观视觉与交互逻辑层面的评估。

五维代码级技术审计（audit）

与偏向主观设计体验的 critique 不同，/impeccable audit [target] 针对代码实现进行客观量化评分（0–4 分），涵盖五个标准技术维度：

• 无障碍性（A11y）：常规文本对比度不低于 4.5:1、适配 prefers-reduced-motion 动效偏好、ARIA 语义标签完整、键盘焦点指示清晰并排查焦点陷阱（Focus Trap）。
• 渲染性能（Performance）：排查连续读写引发的强制同步重排（Layout Thrashing）、will-change 属性滥用、无节制的模糊滤镜与未优化的大图加载。
• 主题一致性（Theming）：排查代码中脱离 Token 的硬编码颜色值、暗色模式对比度失效与主题切换响应异常。
• 响应式交互（Responsive）：移动端触控热区是否达到 44x44px、横向溢出排查、手势交互完整性。
• 实现完整度（Implementation Integrity）：验证组件是否遵循项目设计系统的基础规则与约束。

提炼与加固阶段

• /impeccable distill [target]：针对信息混乱或嵌套过多的复杂面板进行降噪重组，剥离冗余的边框与容器，梳理清晰的视觉主次骨架。
• /impeccable polish [target]：执行发布前的细节清理，识别并消除典型的 AI 模板化痕迹（如移除无用眉标、消除伪渐变、规范边框与圆角梯度）。
• /impeccable clarify [target]：优化表单项标签、辅助说明与错误提示文案，将模糊笼统的技术性报错转化为具有明确恢复指引的业务描述。
• /impeccable harden [target]：健全边缘场景处理逻辑，补齐空数据占位、网络请求中断、字符溢出省略及国际化支持。

浏览器实时协作与变体生成

• /impeccable live：启动浏览器 DOM 交互模式，允许开发者在真实运行环境中选择待优化节点，智能体通过注入脚本捕捉目标节点的真实样式并在本地完成迭代。
• /impeccable generate [n] [action] [element]：针对导航栏、卡片布局或操作栏等局部元素，批量生成多个设计风格迥异的备选方案，供工程团队快速横向比对。

检测钩子与规约漂移治理

在长期迭代过程中，频繁的代码变更容易导致实际组件与既定设计规约发生偏离。Impeccable 通过轻量级静态分析工具链提供防退化机制。

设计检测钩子工作原理

运行配置命令启用文件监听检测钩子：

# 开启项目级设计检测钩子
/impeccable hooks on

检测钩子常驻于智能体的操作上下文中。当智能体修改任意前端源文件（.tsx、.jsx、.css）后，钩子自动对修改内容执行静态 AST 与样式规则扫描：

• 色彩合规检测：扫描代码中是否硬编码了未在 DESIGN.md 中注册的 HEX/RGB 颜色值；
• 排版合规检测：检查标题类选择器中是否存在 bg-clip-text 渐变实现；
• 容器合规检测：识别是否存在嵌套卡片类名或同时声明了 border 与 shadow 的样式类组合；
• 反馈闭环：钩子直接将检测到的违规项（Findings）实时回传给智能体，触发其在单次变更中就地修正，防止设计违规项并入代码库。

规约漂移诊断

执行规约一致性检查：

# 诊断工程代码与设计规范间的漂移
/impeccable doctor

doctor 诊断工具会比对 PRODUCT.md、DESIGN.md、各路由页面以及检测钩子配置的生效状态。当发现页面新增了未定义的语义色彩、修改了核心断点或者组件库排版与规约脱节时，输出结构化的诊断差异报告，供工程团队核对并校准。

生产落地考量与分级选型策略

引入 Impeccable 规约体系在工程实践中需要综合考虑其生成风格与资源消耗，实行分级选型策略。

设计密度与算力成本权衡

• 信息密度与阅读负荷：Impeccable 倾向于生成排版紧凑、字号缩放比例较平缓（1.125–1.2）且包含较多度量与状态标签的高密度界面。这种风格适用于生产力工具与工程控制台，但对于大众消费类或内容展示类应用，首屏容易带来较高的阅读负荷，需要结合业务诉求适度加大字阶对比与页面留白。
• 算力与调用耗时开销：相较于单次 Prompt 在数秒至 2 分钟内输出简单原型，Impeccable 运行完整的规范提取（PRODUCT.md）、概念种子分配（concept-seed）、双独立子智能体评审（critique）以及静态检测钩子，需要进行多轮工具调用与子智能体派生，Token 消耗量与执行时长均有明显上升。

分级工程选型策略

工程团队应当依据页面在产品业务生命周期中的权重进行分级选型：

• 建议采用 Impeccable 体系的场景：
  • 核心品牌门面与官网首页：需要打破模板同质化、确立明确产品识别度的高权重页面。
  • 关键业务落地页与转化路径：承载产品商业价值交付与用户转化的首要页面。
  • 专业控制台与凭据凭证页：例如分布式运维监控控制台与合规发布审计存证页，对界面严谨度、数据可读性与专业性有明确要求的业务场景。
• 建议采用通用提示词快速原型的场景：
  • 内部临时管理看板：供内部运维或特定开发人员短期排查使用的数据视图。
  • 内部配置表单：以数据录入与基础 CRUD 操作为主，对定制化设计与品牌识别度要求较低的页面。
  • 早期探索性功能原型（PoC）：用于快速验证业务可行性的临时分支，使用通用模板快速跑通链路即可，避免在探索期投入过多的设计编排成本。

工程化接入与工作流建议

将 Impeccable 接入既有工程项目推荐遵循以下流程：

依赖安装与技能注入

在项目工程根目录执行依赖安装：

# 针对支持 Skills 规范的智能体环境进行安装
npx skills add https://github.com/pbakaus/impeccable --skill impeccable

若在本地环境配置了独立的 CLI 工具链，可直接克隆或链接官方脚本库，并将执行入口置于开发环境路径中。

渐进式接入步骤

在实际团队研发中，推荐分阶段实施落地：

1. 建立设计上下文：
   • 执行 /impeccable init 生成初步的 PRODUCT.md，明确产品的受众群与关键业务边界。
   • 执行 /impeccable document 分析项目现有样式代码，提炼并生成项目专有的 DESIGN.md。
2. 设定质量底线与审查机制：
   • 针对核心路由执行 /impeccable critique <path>，评估现有界面的可用性瓶颈。
   • 针对重点表单或数据面板执行 /impeccable audit <path>，校正对比度缺陷与响应式断点问题。
3. 启用动态检测防护：
   • 开启设计钩子 /impeccable hooks on，让智能体在每次编辑 UI 文件后自动校验规范符合度。
   • 定期运行 /impeccable doctor 检查全局代码与设计 Token 的一致性，保持长期迭代质量平稳。

综合实战：首页聚焦重构指南

参照 Impeccable 的界面改良工作流，优化现有首页通常遵循“从问题出发、针对性收敛、核对验收”的轻量化流程。

打开需要优化的首页文件，用自然语言直接描述问题，并明确声明必须保留的内容（如品牌标识、核心功能文案或转化动线）：

/impeccable 这个首页看起来过于拥挤，技术指标不突出，卡片嵌套过多。请在保留现有品牌色、核心功能文案与注册动线的前提下，优化信息层级与排版。

无需提前记忆所有子命令，智能体会分析当前页面代码并自主选择匹配的治理动词。

1. 发现问题（Find the problem）

若不确定具体该修改哪些细节，可以先请求设计评审：

/impeccable critique app/routes/home.tsx

智能体会输出结构化诊断报告（涵盖信息架构、视觉噪声、状态覆盖与排版规范），随后可根据诊断建议选择需要处理的具体项。critique 仅负责定位问题，不会自动修改源码。

2. 开展针对性改进（Make a focused improvement）

明确预期目标，或在清楚改动类型时直接使用对应的动词命令：

/impeccable polish app/routes/home.tsx。保留现有调色板、标题文案与主 CTA 按钮。

针对常见的首页重构场景，选择对应的动词命令：

若需要对比关键组件（如 Hero 区域卡片或核心展示区）的多种视觉排版，可使用 generate 生成备选方案：

/impeccable generate 3 bold variants of the hero feature cards

在浏览器中预览对比生成的方案，并将选定的样式采纳至代码中。

3. 决定是否需要全局重新设计（Decide whether you want a redesign）

聚焦改进（Focused improvement）适用于保留现有视觉体系的局部调优。如果需要更换整体视觉风格，则直接发起重设计请求：

/impeccable 重新设计官网落地页。保留产品业务事实与注册流程，但替换当前的视觉风格。

重设计会触发完整的新建工作流（New-work），包括重新选择视觉风格原型与契约决策；常规的首页修缮与降噪通常使用聚焦改进即可。

4. 检查与验收成果（Check the result）

重构完成后，在桌面端和移动端视口下核验页面的核心操作动线，并检查代码变更。向智能体提供明确的反馈以进行微调：

核心特性区域的层级比之前清晰。保持这一调整，但把指标卡片上方的切换按钮恢复原样。

在合并代码前，运行技术审计以核验无障碍性、性能与响应式表现：

/impeccable audit app/routes/home.tsx

若开启了自动检测钩子（/impeccable hooks on），智能体在后续编辑 UI 时会自动触发规则检查，防止反模式再次被引入。