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

发布时间:2026/9/8 22:29:46
Impeccable 的 Craft Floor:方向落定后、动手写 UI 前,AI 必须照做的品质底线与反模式清单 Impeccable 的 Craft Floor方向落定后、动手写 UI 前AI 必须照做的品质底线与反模式清单【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccableCraft 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为源生成到各宿主目录的那份文档。它承载品质底线、绝对禁令以及任何探测器都抓不到的「反射」。仅做规划的工作不要加载它。这一段信息量很大它回答了两个问题加载时机craft floor 只在方向direction被批准、马上要动代码时加载。规划阶段还在探索方向、写文档、访谈需求加载它是错的因为那会儿还不存在「待检验的构建结果」。它的性质它包含「品质底线」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.mdOperate 模式的深度指南则把它列为该模式的核心前提之一见 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中一起跑完而不是分多次独立的截图往返——这些检查共享同一次渲染。这句话有两点核心要求看结果不看代码意图检查对象是页面实际渲染出来的样子对比度是否达标、阴影是否真实、间距是否读得出来凡是只能靠「我当时想表达什么」来辩护的东西都不算数。批量共享渲染桌面与移动端在同一次截图轮里一起检查所有规则共用同一份渲染结果禁止为每一条规则单独截一张图、单独往返一次——这正是 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-outexponential ease-out from an already-visible default避免元素从不可见状态猛冲进来。调色板要超越 transform 与 opacityblur、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 会话产出了五个自创 kickerdocumenter 把它们写进了 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 中收尾评审 Agentimpeccable-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 reviewers floor check is the only slop gate。这说明在 HTML/CSS 不可读的原生代码上floor 的文本规则成了唯一的人工防线——floor 不是装饰性文档而是每种交付路径上都会被点名引用的最终把关项。把 floor 变成你的编辑前检查表综合原文与仓库配套可以用一张表把 floor 落到可执行的编辑动作上。它在方向批准、准备动手改 UI 时作为「加载即内化」的检查表逐项对照构建结果层面底线检查Verify禁止默认Refuse对比度正文/占位 ≥4.5:1大字 ≥3:1彩色面上从色相派生次文本禁用灰渐变文字强调靠字重/字号纵深阴影有偏移 柔和模糊零偏移光晕新粗野主义世界外的4px 4px 0硬阴影间距组内紧、组间松标题上方比下方多空读计算值嵌套卡片排版行长 65–75ch、display ≤6rem、tracking ≥ -0.04em断点跑真实文案系统展示字体等宽字体当戏服kicker/eyebrow绝对禁令动效一个编排时刻从可见默认指数 ease-out可用 blur/filter/clip-path/mask/shadow玻璃与模糊当装饰每区同款入场状态hover/disabled/loading/error/empty 键盘焦点 真内容 可用控件打断式或非焦点保护的模态原生表面选区、光标、滚动条、焦点环、下划线偏移、tabular 数字全部主题化emoji/字形顶替图标几何蒙版抠有机轮廓文案控件说动作报错给问题与恢复路径数字营销模板hero-metric做正文结构覆盖每项简报需求几秒内可找到01/02/03 章节编号除非有信息量明暗从使用场景挑谁、在哪、什么环境光按「类别」默认挑明或暗结语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创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询