`ce-frontend-design`

构建具有真正设计质量的 Web 界面，而不是 AI 废话。检测现有的设计系统，有意规划，构建，然后进行视觉验证。

ce-frontend-design 是设计质量技能。 AI 倾向于通用的 SaaS 美学——白底紫色、Inter 字体、卡片网格英雄、装饰渐变、听起来像是提示语言渗入 UI 的文案。此技能抵消了用户（或现有设计系统）可以覆盖的明确默认值、强制视觉论文和在宣布完成之前进行视觉验证的结构化预构建规划。它适用于对现有应用程序的新建和修改；它会自动检测现有的设计系统，并在存在时使用它。

TL;DR

问题	回答
它有什么作用？	检测现有的设计系统，用视觉论文规划设计，用有意的默认值构建，用视觉验证
何时使用它	任何前端工作 - 登陆页面、网络应用程序、仪表板、管理面板、组件、交互式体验
它生产什么	前端代码匹配现有的设计系统（模块 C）或独特的绿地美学（模块 A 或 B）
权限等级	现有系统 > 用户说明 > 技能默认值

＃＃问题

人工智能生成的前端会折叠成可识别的形状：

通用 SaaS 美学 — 白底紫色、Inter 字体、卡片网格英雄，每个仪表板看起来都像相同的教程模板
卡片无处不在，即使布局不需要它们 - 错误地将默认设置为“结构”
英雄部分杂乱无章，包含统计数据、时间表、药丸簇、徽标云 - 太多的东西引人注目
装饰渐变代表真实的视觉内容
提示语言泄漏到用户界面中——“体验无缝集成”
模式偏差 — 白底紫色默认；深色模式默认；永不变异
一无所获——代理要么忽略现有的设计系统，要么推倒它
无验证 - 构建页面，声明完成，从不检查它看起来是否正确

解决方案

ce-frontend-design 将前端工作作为具有显式默认值和验证的结构化通道运行：

第 0 层：上下文检测 — 扫描现有设计标记、组件库、CSS 框架、版式、调色板、动画库；分类为现有系统、部分系统、新建系统或模糊系统
第 1 层：预构建规划 — 任何代码之前的三个简短陈述（视觉论文、内容计划、交互计划）；用户可以在编写代码之前重定向
第 2 层：设计指导核心 — 排版、颜色、构图、动作、可访问性、图像的固执己见的默认值；每个都会屈服于现有系统
上下文模块 — 模块 A（登陆页面）、模块 B（应用程序和仪表板）、模块 C（现有应用程序中的组件；现有应用程序工作的默认值）
硬规则和反模式 — 可重写的默认值加上真正的质量底线（对比度破坏、焦点状态缺失、语义 div 汤）
视觉验证 — 使用项目现有的浏览器工具或 agent-browser 进行一次检查，以根据视觉论文进行评估

是什么让它如此新颖

1. 权限层次结构——屈服于现有系统

技能中的每条规则都是默认规则，而不是强制规则。优先事项：

现有设计系统/代码库模式 - 最高优先级，始终受到尊重
用户的明确指示 — 覆盖技能默认值
技能默认值 — 适用于新手工作或用户请求指导时

当使用具有既定模式的现有代码库时，请遵循这些模式。当用户指定相反的方向时，跟随用户。该技能的意见仅在其他任何事情都不适用时才适用。

2. 第 0 层：上下文检测 — 显式信号

在进行任何设计工作之前，该技能会扫描代码库以查找设计信号：

设计标记/CSS变量（--color-*、--spacing-*、--font-*）
组件库（shadcn、MUI、Chakra、Radix、Ant Design、项目特定目录）
CSS 框架（tailwind.config.*、样式组件主题、CSS 模块）
版式（@font-face，Google 字体链接）
调色板（定义的比例、品牌颜色文件、设计令牌导出）
动画库（Framer Motion、GSAP、anime.js、Motion One、Vue Transition）
间距/布局模式（一致的比例使用、网格系统）

根据信号，分类为 现有系统（4 个以上信号；遵循它；产生审美意见）、部分系统（1-3 个信号；遵循现有信号，对间隙应用默认值）、未开发（无信号；适用完整指导）或 不明确（询问用户）。

3. 第 1 层：预构建规划 — 需要视觉论文

在编写代码之前，该技能会编写三个简短的语句：

视觉论文 - 一句话描述情绪、材料和能量（“干净的编辑感觉，大量的空白，衬线标题，柔和的大地色调”）
内容计划 — 页面上显示的内容以及顺序（用于着陆的英雄/支持/详细信息/CTA；用于应用程序的主工作区/导航/检查器；组件的状态）
交互计划 - 2-3 个特定的动作创意（“英雄加载时交错淡入、各部分之间滚动时的视差、卡片悬停时放大” - 不是含糊的“添加动画”）

这些为用户提供了一个检查点，可以在编写代码之前重定向，此时纠正成本很低。跳过这一步是 AI 最终交付通用 SaaS 模板的方式。

4. 三个上下文模块——不同表面的不同模式

模块	当	默认值
A：登陆和营销	格林菲尔德登陆页面	英雄（一篇作品，不是仪表板）、支持、细节、最终 CTA。品牌第一，标题第二。 ≤6节。文案：让标题承载；一个简短的支持句子。
B：应用程序和仪表板	Greenfield 应用程序/仪表板	平静的表面层次，强烈的排版和间距，很少的颜色，密集但可读，最少的镀铬。仅当卡是交互时才卡。文案：实用，而非营销。
C：组件和功能	现有应用程序（默认）	匹配现有的视觉语言。继承间距、半径、颜色标记、版式。关注交互质量（清晰的状态、平滑的过渡、明显的可供性）。不要从一个组件引入新的设计系统。

在现有应用程序中工作时，无论功能如何，都默认使用模块 C。重点不是要脱颖而出，而是要融入其中。

5.默认对抗（可覆盖）与始终避免（质量底线）

该技能将意见与质量缺陷区分开来：

默认反对（可覆盖）：

通用 SaaS 卡片网格作为第一印象
白底紫色，暗模式偏差
未开发环境中过度使用的字体（Inter、Roboto、Arial、Space Grotesk、系统默认值）
英雄部分充斥着统计数据/药丸/徽标
没有叙事目的的轮播
多种相互竞争的强调色
装饰渐变代表真实的视觉内容
文案听起来像设计评论（“体验无缝集成”）
分屏英雄，在图像繁忙的一侧带有文字

始终避免（优质地板）：

提示语言或人工智能评论泄漏到用户界面中
对比度不高——图像或背景上的文字无法辨认
没有可见焦点状态的交互元素
当存在正确的 HTML 元素时，语义 div 汤

用户可以覆盖第一个列表。第二个清单是不可协商的——这些都是用户不希望出现的质量问题。

6. 目视验证前的石蕊检查

在启动视觉验证之前，该技能会要求自己进行快速的自我审查：

品牌或产品在第一个屏幕上是否清晰可见？
有没有一个强大的视觉锚点？
仅扫描标题就能看懂页面吗？
每个部门都有一份工作吗？
在使用卡的地方真的有必要吗？
运动是否改善了层次或氛围，或者只是存在？
如果所有装饰性阴影都被移除，设计会不会感觉很高级？
文案听起来是否像产品，而不是提示？

这些是针对未通过基本易读性和意图测试的运输工作的大门。

7. 使用工具偏好级联进行视觉验证

实施后，该技能会进行视觉验证——健全性检查，而不是像素完美的审查。工具偏好：

现有项目浏览器工具 - Playwright、Puppeteer、Cypress 已在 deps 中；使用它
浏览器 MCP 工具 — 如果可用
agent-browser CLI — 后备；如果未安装，则显示“运行 /ce-setup”
心理审查 - 当无法通过浏览器访问时，应用试金石检查作为自我审查，并注意跳过视觉验证

一次迭代。截取屏幕截图，根据试金石进行评估，修复明显的问题，然后继续。对于多轮迭代细化，ce-design-iterator 代理可以处理该问题。

8. 创造力——大胆的方向而非公式

对于未开发的工作，该技能明确鼓励致力于大胆的美学方向。可能的色调：极简主义、极简主义、复古未来主义、有机/自然、奢华/精致、俏皮、社论、野兽派、装饰艺术、柔和/柔和、工业——或者发明一些东西。重点不是要变得奇怪；而是要变得奇怪。这是为了避免产生无差别人工智能输出的公式。

将实施复杂性与审美愿景相匹配。极繁主义设计需要带有大量动画的复杂代码。极简主义设计需要克制、精确，并仔细注意间距、排版和微妙的细节。

简单示例

您正在为新产品构建登陆页面，没有现有的存储库约定。您调用 /ce-frontend-design "build a landing page for a notion-style note-taking app"。

第 0 层：扫描空仓库。格林菲尔德。没有现有的系统可以屈服；完整的指导适用。

第1层：写三个语句：

视觉论文：“安静，深思熟虑，几乎像纸一样 - 温暖的奶油色背景，深墨黑色，衬线标题，柔和的淡入过渡。材质：纸，而不是玻璃。”
内容策划：英雄产品名称+一句承诺+软视觉；一项功能深入探讨；来自用户的一句话；最终号召性用语
交互计划：英雄文本加载时交错淡入、各部分之间的柔和视差、CTA 按钮上的悬停抬起

您确认或重定向。一旦获得批准，技能就会建立。模式的模块 A（登陆和营销）。选择衬线显示字体（不是 Inter），使用受限调色板（奶油色、墨水、一种口音），使英雄保持单一构图。

实施后，该技能将通过石蕊检查，然后使用 agent-browser 进行目视验证。屏幕截图看起来连贯。英雄支持文案中的一句话读起来就像提示语言（“体验毫不费力的思想捕捉”）——违反质量底线。修复了“一款不会妨碍您的笔记应用程序”。重新截图。完毕。

何时去实现它

在以下情况下使用 ce-frontend-design：

您正在构建登陆页面、应用程序、仪表板或组件，并希望结果看起来与众不同（不是 AI 通用的）
您想要现有的设计系统检测 - 屈服于现有的，仅对差距应用默认值
你想要一个结构化的视觉论文优先计划，而不是深入代码
您需要石蕊检查和目视验证步骤

在以下情况下跳过 ce-frontend-design：

工作是非前端的（API、后端、脚本）——范围错误
您有固定的 Figma 规范并想要精确翻译 — ce-design-iterator 或设计同步代理更适合
改变是机械性的（文案中的拼写错误、单行 CSS 调整）——矫枉过正

用作工作流程的一部分

ce-frontend-design 通常在前端工作开始时直接调用，但与以下内容互锁：

/ce-work 第 2 阶段 — 实现前端功能时，此技能提供设计通道
/ce-polish — 用于功能发挥作用后的后期用户体验细化；互补而非替代
ce-design-iterator 代理 — 用于超越单次视觉验证过程的多轮迭代细化
ce-design-implementation-reviewer 代理 — 用于根据 Figma 设计验证 UI

技能的输出是前端代码；下游技能处理提交、公关、润色和审查。

使用独立版

直接调用：

绿地着陆 — /ce-frontend-design "build a landing page for X"
应用程序/仪表板 — /ce-frontend-design "build a settings dashboard"
组件 — /ce-frontend-design "build a NotificationToggle component"
修改 — /ce-frontend-design "redesign the pricing page"（现有应用程序；自动检测）

该技能会自动检测上下文。预构建规划（第 1 层）是用户在代码提交到某个方向之前重定向的检查点。

＃＃参考

层	目的
0	上下文检测——扫描设计信号；分类为现有/部分/新建/不明确
1	预建规划——视觉主题、内容计划、交互计划；用户重定向检查点
2	设计指导核心——排版、颜色、构图、动作、可访问性、图像默认值
模块	A（登陆）、B（应用程序/仪表板）、C（现有应用程序中的组件 - 现有应用程序工作的默认值）
验证	Litmus 检查 → 使用浏览器级联工具进行视觉验证

＃＃常问问题

为什么它会屈服于现有的设计系统？ 因为现有的系统是经过深思熟虑的选择，并且匹配它会产生适合的作品——比破坏一致性的最美丽的绿地设计更好。该技能的意见是为了新领域或填补空白，而不是为了推翻既定模式。

为什么要三个预构建语句？ 因为在编写代码之前*发现错误的方向比编写代码之后要便宜得多。三个陈述（论文、内容、互动）都很短——2 分钟内写完，几秒钟内即可重定向。跳过它们就是人工智能最终交付通用模板的方式。

为什么“默认反对”与“总是避免”？ 用户可以覆盖的默认值（白底紫色不是质量错误，只是技能在新手中抵抗的默认值）。始终避免的是质量地板（破坏对比度是一个错误，没有用户想要它）。这种分割使用户覆盖干净：用户可以要求白底紫色，但不能要求破坏对比度。

Figma 像素完美的作品怎么样？ 范围不同。该技能旨在实现具有自我验证功能的独特、生产级设计。对于像素完美的 Figma 匹配，ce-design-implementation-reviewer 代理或 ce-figma-design-sync 代理是正确的工具。

我可以进行多轮迭代吗？ 该技能可以通过一次视觉验证。对于多轮细化，ce-design-iterator 代理负责处理 — /ce-frontend-design 提供基础，迭代器进行完善。

如果项目有 1-3 个设计信号（部分）怎么办？ 遵循现有的事物；仅对未检测到约定的区域应用技能默认值。例如，Tailwind 已配置（遵循间距/颜色），但不存在组件库 - 应用技能组件结构指南。

另请参阅

/ce-work — 在前端实现期间调用此技能
/ce-polish — 功能发挥作用后的后期用户体验细化
/ce-test-browser — 验证设计通过后的实现工作
/ce-demo-reel — 捕获 PR 描述的视觉证据