企业官网建设流程全解析

Impeccable 的 Craft Floor：方向落定后、动手写 UI 前，AI 必须照做的品质底线与反模式清单

【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable

Craft floor 是 impeccable 设计技能中的一份「底线文档」：它在设计方向被批准之后、模型真正编辑界面之前被加载，用一套可验证的品质检查（Verify）和一份反模式清单（Refuse）约束模型的产出，防止 AI 界面落入千篇一律的模板与廉价特效。本文将以 .claude/skills/impeccable/reference/craft-floor.md（其源文件为 skill/reference/craft-floor.md）为骨架，结合仓库内 SKILL.md、钩子（hooks）、live 模式、收尾评审 Agent 与检测夹具等实现证据，逐条拆解这份清单的每一项检查、每一条禁令，以及它们如何被机械地落实进编辑循环。

craft-floor 的定位：什么时候加载，加载后起什么作用

在理解具体检查项之前，先要搞清楚这份文档在 impeccable 技能里的加载时机与优先级，因为它的全部内容都建立在「方向已经定好」这个前提之上。

它在流程中的位置：Setup 第三步

impeccable 的单一技能入口 skill/SKILL.src.md 把工作流程分成了若干步骤。其中 Setup 第 3 步明确规定：

分析和方向都已解决之后，在编辑 UI 之前立即加载 reference/craft-floor.md（即以skill/reference/craft-floor.md为源生成到各宿主目录的那份文档）。它承载品质底线、绝对禁令以及任何探测器都抓不到的「反射」。仅做规划的工作不要加载它。

这一段信息量很大，它回答了两个问题：

1. 加载时机：craft floor 只在方向（direction）被批准、马上要动代码时加载。规划阶段（还在探索方向、写文档、访谈需求）加载它是错的，因为那会儿还不存在「待检验的构建结果」。
2. 它的性质：它包含「品质底线」（quality floor）、「绝对禁令」（absolute bans）和「探测器抓不到的反射」（reflexes no detector catches）三样东西。底线与禁令是白纸黑字的规则，而「反射」是模型在逐条编辑中应自动养成的习惯，不依赖工具提示。

同样的规则在宿主目录生成的 .claude/skills/impeccable/SKILL.md 中被原样保留（生成产物由构建系统从skill/源同步，见 CLAUDE.md 中关于bun run build:release与生成产物策略的说明）。在其它引用点上也能看到一致约定：live 模式要求「在编写全新标记之前加载 craft-floor.md」（见 skill/reference/live.md），Operate 模式的深度指南则把它列为该模式的核心前提之一（见 skill/reference/operate.md）。

优先级：谁压过谁

craft-floor 文档的开头两句话给出了三条硬性优先级，用来决定「底线规则」与「具体项目」冲突时听谁的：

• 已固定的简报（pinned brief）或已提交的视觉世界（committed visual world）优先于这里的一切。也就是说，floor 是通用底线，不是审美裁判；当客户简报明确要求某个方向时，floor 不会拦它。
• 模型自己的习惯没有优先权。模型的「个人口味」永远不能让一条通用禁令退让。
• 当设计钩子（design hook）处于激活状态时，它会在编辑过程中自动强制执行下面这些机械检查；此时模型的职责是针对其发现采取行动，而不是把每条规则再重新审计一遍。

关于最后一点，skill/reference/hooks.md 的措辞可以互相印证：钩子每次都是机械扫描，而「没有任何扫描器能抓到的反射」正是存放在 craft-floor.md 里的，因此无论钩子是否接线，这些规则都适用——即它们是编辑前必须内化的行为准则，而非可选的静态检查。

Verify：针对「构建结果」的九类检查，而不是「意图」

craft-floor 的 Verify 小节一开始就给出方法论：

下面每一项都是对已构建结果（built result）的检查，而不是对意图的检查。要在批量检查轮次（batched inspection rounds）中一起跑完，而不是分多次独立的截图往返——这些检查共享同一次渲染。

这句话有两点核心要求：

1. 看结果，不看代码意图：检查对象是页面实际渲染出来的样子（对比度是否达标、阴影是否真实、间距是否读得出来），凡是只能靠「我当时想表达什么」来辩护的东西都不算数。
2. 批量共享渲染：桌面与移动端在同一次截图轮里一起检查，所有规则共用同一份渲染结果，禁止为每一条规则单独截一张图、单独往返一次——这正是 skill/SKILL.src.md 核心原则中「有界通过式验证」（Verify in bounded passes）在具体规则层面的体现。

下面逐类展开。

对比度（Contrast）

• 正文与占位文本（placeholder）的对比度必须 ≥ 4.5:1，大号文本 ≥ 3:1（对应 WCAG AA 级别）。
• 在彩色表面上，次要文本要从该色相（hue）或前景色中派生色调，绝不能用灰色。

后一句是针对 AI 界面最常见的偷懒手段：把次要文字直接涂成 #999。正确做法是取色相的加深/减淡变体，或直接沿用前景色降低不透明度，让文字与所在表面同源而不发灰。

纵深（Depth）

• 阴影必须同时携带偏移（offset）与柔和的模糊（soft blur）。
• 零偏移的彩色光晕（zero-offset colored halo）只是装饰，不构成纵深。

换句话说，没有方向与衰减的「发光」不是纵深系统，它读起来像装饰贴纸。真阴影要能指示光源方向与表面高度。

间距（Spacing）

• 组内紧凑、组间宽松（tight groups, generous separation）。
• 标题上方的空间要多于标题下方的空间——这是版面层级里成本最低也最常被违反的节奏规则。
• 读取计算后的真实数值（computed values），而不是相信你在 CSS 里写的值——意味着要用浏览器计算样式或等价手段核实最终生效的间距。

排版（Type）

• 正文行长（measure）在 65–75ch 之间。
• 展示级（display）字号上限 6rem。
• 字距（tracking）下限为 -0.04em，即负字距不能无限收紧。
• 标题层级要平衡，字号与字重要有清晰的阶梯（obvious scale and weight steps）。
• 在每个断点运行真实文案，修复任何溢出（overflow）——用 lorem ipsum 验证是无效的，因为真实文案的长度、换行与断词才是排版压力的来源。

与排版底线互相印证的还有两个相邻参考：skill/reference/typeset.md 以 1rem/16px 作为普通 Web 正文的下限，skill/reference/harden.md 进一步说明 iOS Safari 会对小于 16px 的聚焦输入框强制放大，从而破坏表单布局——这就是为什么 14px 只允许出现在真正次要的文本上。

动效（Motion）

• 一个被精心编排的时刻（one authored moment），而不是到处散落的特效，更不是每个区块都用同一个入场动画。
• 缓动采用从已经可见的默认状态出发的指数级 ease-out（exponential ease-out from an already-visible default），避免元素从不可见状态猛冲进来。
• 调色板要超越 transform 与 opacity：blur、backdrop-filter、clip-path、mask 与 shadow 在保持流畅的前提下都属于可选素材。

这一条把「动效」从「给每个元素加个 transition」提升为「整页只有一个戏剧性时刻」，其余元素保持克制。

状态（States）

• 必须覆盖：hover、disabled、loading、error、empty。
• 此外还要有：真实内容、可用的控件（working controls）、响应式布局、键盘焦点（keyboard focus）。

键盘焦点出现在这里意味深长：它是「状态」的一等公民，不是可选项。empty 与 error 状态被明确点名，说明只做好「理想态」的页面是不完整的。

浏览器原生表面（Browser surfaces）

这是 Verify 里最长、也是 AI 模型最常漏掉的一条：

你没有画的那部分仍然要承载设计。文本选区（text selection）、光标（caret）、自定义滚动条（custom scrollbars）、焦点环（focus rings）、下划线偏移（underline offset）、以及表格数据中的数字（numerals in tabular data），全都带着不属于任何设计系统的浏览器默认样式。要用调色板把它们主题化。这是判断一个页面是「被构建出来的」还是「被拼装出来的」最便宜的信号，也是模型最稳定跳过的那个信号。

原文用了一个非常尖锐的定性：这是「built vs assembled」的最廉价判据。默认选区蓝、默认滚动条灰、表格数字没有 tabular-nums——这些细节正是模板化 AI 界面与手工打磨界面在放大镜下最明显的分野。

文案（Copy）

• 使用产品自己的语言。
• 控件要说出自己的动作（controls name their action）。
• 错误要说出问题与恢复办法（errors name the problem and the recovery）。

也就是说，一个按钮不能只写「确定」，一个报错不能只说「出错了」。文案检查在相邻技能中也有对应入口，即 UX 文案专项命令 skill/reference/clarify.md 的职责范围。

覆盖（Coverage）

• 简报里的每一项需求都要存在且能在几秒内被找到（present and findable within seconds）。

它不是「功能都存在」这种弱断言，而是可发现性断言：用户或评审者在几秒内找不到的功能等于没做。

Refuse：类别默认不是禁令，但识别到默认就说明你没在做决定

Verify 检查「做得对不对」，Refuse 则管「不该碰什么」。Refuse 小节的定位非常关键：

这些是该类别下的默认值（defaults），不是禁令（bans）：简报自己的措辞可以赢回其中任何一条。当某个轴完全自由而你却伸手去够默认值时，说明你没有在做决定；认识到这一点意味着要重写这个元素，而不是把它软化成无害的样子。

这段的原则是：大多数条目在方向上自由时可以因简报而正当化，但「默认伸手」本身就是失败——它意味着模型没思考，而是走了数据分布里最常见的路。它把问题分成两组：页面骨架（page scaffolds）与表面习惯（surface habits），外加一条特殊的硬性禁令。

页面骨架：卡片模板、数据英雄、眉毛文本等

• 同尺寸「图标 + 标题 + 文本」卡片铺满整页作为页面结构。原文定性尖锐：卡片是懒惰容器（the lazy container），嵌套卡片永远错。
• hero-metric 模板：大数字 + 小标签 + 佐证统计 + 强调色。这是营销页最泛滥的范式，floor 要求模型别默认搬它。
• 标题上方的 kicker / eyebrow（眉毛文本）：这一条不是默认而是禁令，任何简报都赢不回来。原文的理由是「标题自己扛得住自己的重量」（the heading carries its own weight）：删掉小标签，让标题直接说话。
• 章节编号（01 / 02 / 03）：除非序列本身携带读者需要的信息。
• 模态框：当任务既不需要打断、也不需要受保护的焦点时，不要上 modal。

关于 kicker 这一条，仓库里有可查证的工程配套：检测规则引擎中存在kicker-above-heading这类「以标题为锚点」的规则（见 CLAUDE.md 对规则引擎参考实现的说明），并在夹具目录里配有正反用例 tests/fixtures/antipatterns/kicker-above-heading.html 与相邻的 tests/fixtures/antipatterns/hero-eyebrow-chip.html。也就是说，floor 里的文字禁令在检测侧有对应的机械规则可验证。

表面习惯：渐变字、玻璃拟态、硬阴影、系统字体等

• 渐变文字（gradient text）：强调应该来自字重或字号，而不是渐变。
• 玻璃与模糊作为装饰，而不是作为某个具体效果（glass and blur as decoration rather than as a specific effect）。
• 在卡片、列表项、提示框、告警上的彩色border-left/border-right超过 1px。
• 硬偏移阴影（box-shadow: 4px 4px 0）：除非这个世界真的是新粗野主义（neobrutalist）。零模糊的块状阴影是戏服而不是纵深系统；一个没主动选择这种风格的世界永远不能把它当默认赢回去。
• 迷你走势图（sparklines）、进度环（progress rings）、柔影圆角矩形代替真实内容。
• 等宽字体（monospace）当作「技术感」的戏服，而不是用于代码、数据或度量。
• 系统展示字体（Impact、Arial Black、平台无衬线）当作自有世界页面的展示字体。应该引入并自托管一版与获批字体气质匹配的字体；「最接近的已安装字体」是失败，不是回退（the closest installed font is a failure, not a fallback）。
• 用 Unicode 字形或 emoji 顶替图标系统。图标要画出来，来自真实图标库或自绘 SVG，且笔画与字重统一。
• 用几何蒙版（圆形、多边形、径向渐变抠图）去近似有机轮廓。这是廉价版效果，读起来比干脆不做还差。应当从真实图片导出 alpha matte，或产出真正的抠图素材。
• 按类别挑选明暗（light/dark）：不能因为「暗色 = 高级」就选暗色，要从使用场景挑——谁在用、在哪用、环境光如何。

把这几条放在一起看，它们有共同的判断框架：区分「真实的设计决策」与「最省事的默认值」。渐变字、玻璃、硬阴影、emoji 图标、几何抠图，全部是模型输出分布里的高频默认——它们能瞬间把界面标记为「AI 拼装件」。

禁令与系统规则之间的纪律：不要反写进设计系统

Refuse 清单还有一条重要的元规则，体现在收尾环节的文档中：skill/reference/degraded/documenter.md 明确规定——永远不要把 craft-floor 的拒绝项反写成系统规则：floor 禁止的元素（kickers/eyebrows、新粗野主义世界之外的硬偏移阴影、字形图标、系统展示字体）在收尾文档中要作为「构建所携带的缺陷」记录下来，而绝不能成为未来界面继承的「设计系统规则」。文档里记录过真实事故：一次 live 会话产出了五个自创 kicker，documenter 把它们写进了 DESIGN.md 的样式规则，于是一条违规变成了「家传风格」。这条纪律保护了 floor 的通用性——禁止项不该被某次具体产出固化下来。

floor 如何被机械地落实：探测器、钩子、live 与收尾评审

craft-floor 文档本身只是参考文本，它的效力来自仓库里一套围绕它的执行机制。这部分我们从源码与配套测试的证据出发，梳理 floor 被落实的几条路径。

路径一：设计钩子在编辑时自动强制执行

当设计钩子激活时，floor 的机械检查会在每次 UI 文件编辑后自动运行，模型「针对其发现采取行动，而不是逐条重新审计」。从 CLAUDE.md 可看到钩子的行为模型：它监听 UI 文件编辑并自动运行检测器、把发现返回给编辑者；而 skill/reference/hooks.md 进一步澄清分工——钩子是机械通道，任何扫描器都抓不到的反射存放在 craft-floor 中，钩子与 floor 覆盖的粒度不同：钩子管能规则化的，floor 管必须内化成编辑习惯的。无钩子的会话也会通过context.mjs收到一条MANUAL_DETECTOR_REQUIRED指令，要求在会话末尾手动跑一次探测器，确保机械检查不缺席。

路径二：live 模式「按构造」达标，全量验证只在 accept 一次

skill/reference/live.md 对变体生成的约束是：在你编写时就要按构造应用 craft-floor 的对比度、间距与排版底线（apply … floors by construction as you write），而全量验证只在 accept 时对选中的变体运行一次。这印证了 floor 的两种用法：构造期遵守 + 验证期抽查。live 的「insert」目标被要求在任何全新标记写出来之前先加载 craft-floor。

路径三：收尾评审 Agent 用 Refuse 清单对照截图

在 skill/reference/degraded/finish-reviewer.md 中，收尾评审 Agent（impeccable-finish-reviewer，仓库内定义见 skill/agents/impeccable-finish-reviewer.md）会「读取 craft floor 的 Refuse 清单并把截图按它过一遍」：kickers 与 eyebrows、新粗野主义世界之外的硬偏移阴影、字形图标、系统展示字体、渐变文字、侧边色条等等。文档特别强调：被禁止的元素即使与 comp 图完全一致也是实质缺陷——因为构建者写它之前加载的是同一条禁令，对 comp 的忠实度不能为 floor 拒绝的东西授权。这条兜底存在的现实原因是：无钩子的收尾链路可能没有任何机械发现，而最近的 live 会话里，就有五次把 kicker 送过了一个从不看 Refuse 清单的评审者。

路径四：新工作流的终检与交接

skill/reference/new-work.md 的收尾流程同样把检测与 floor 检查作为发货闸门：第二轮检查后，在 Web 上对改动目标运行一次探测器、修复机械问题，把剩余发现交给评审者；原生平台上探测器不适用，因此「评审者的 floor 检查是唯一的劣质品闸门」（the reviewer's floor check is the only slop gate）。这说明在 HTML/CSS 不可读的原生代码上，floor 的文本规则成了唯一的人工防线——floor 不是装饰性文档，而是每种交付路径上都会被点名引用的最终把关项。

把 floor 变成你的编辑前检查表

综合原文与仓库配套，可以用一张表把 floor 落到可执行的编辑动作上。它在方向批准、准备动手改 UI 时作为「加载即内化」的检查表，逐项对照构建结果：

结语：floor 管机制，从不替你选方向

craft-floor 的收尾段落值得原样强调：

底线只负责机制，它从不替你挑选方向。当所有检查都绿灯之后，把这一页的时间花在已提交的视觉世界上；当你在「精致」与「已提交」之间纠结时——提交（commit）。

这正是 floor 的哲学闭环：Verify 保证不劣质，Refuse 保证不像 AI 拼装件，但两者都不会替你决定「这个世界长什么样」。方向来自简报、DESIGN.md 与已提交的视觉世界；floor 只是保证你在执行那个方向时，机械品质不塌方、默认模板不上身，并在精致化与忠实提交之间选择后者。对使用者来说，这份文档最大的价值在于它把「AI 界面的廉价感」拆解成了可以逐条检查、逐条修复的具体缺陷——让品质成为可验证的工程条件，而不是模糊的品味问题。

【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable