frontend-art-direction

前端艺术指导

在不增加流程成本、不让流程变得含糊或流于形式的前提下，改善产品的可见部分。默认交付成果应是可用的 UI，具备鲜明的设计主张、完整的状态、实用的动效和直观的视觉呈现。

执行准则

• 在选择风格、库、字体、动画或首屏布局之前，先检查项目。
• 将用户的工作流、内容、设备和现有系统视为事实依据。外部参考用于填补明确指出的空缺；不能取代对产品的理解。
• 当内容或媒体表现不足时，采用克制的表面设计。鲜明的表现力必须以真实主体、原创素材、有意义的数据、媒体或空间关系为基础；不必因此套用产品模板。
• 资源优先级为：用户提供 -> 现有/官方 -> 搜索到的高质量资源 -> 生成 -> 精心设计的无资源构图。绝不交付占位符、低分辨率填充图、随意选用的图库素材，或存在明显瑕疵的生成媒体。
• 根据预期阅读距离下实际可见的主体来判断媒体，而不只看文件尺寸或来源声望。大图也可能让主体显得很小或难以辨认。核实每个文件的具体记录和署名；归档名称不能说明其器材、作者或权利信息。
• 对每个重要表面都进行高级质感打磨：灰度层级、视觉对齐、字号上限、材质层次、具体文案，以及一个克制的原创细节。“高级”不等于渐变、玻璃层、超大标题或空旷留白。
• 优先复用和修复本地基础组件。对于常见控件，使用成熟组件，并调整其设计令牌、密度和状态，而不是直接采用其默认外观。
• 不要为了营造氛围而添加依赖。明确缺少的功能，检查现有库/文档，再选择最轻量且兼容的资源，然后再安装。
• 每次重要调整都至少包含一个有意义的状态转换，以及减少动态效果或静态回退方案。
• 编写代码之前，先给出视觉方向约定：构图规则、各区域的位置/文本对齐/尺寸及相邻关系、占用比例、视口场域、表面边界、停顿目的、几何令牌、主导元素/平衡元素、字号上限、间距节奏、表面预算、边缘特征、圆角层级、分隔与线条规则、视觉处理方式、标志性设计手法、权威依据，以及 AI 默认倾向的审查项。解析器必须生成核心区域和可舍弃的可选候选方案，并在没有原创布局图时，生成 3 个可替换的结构假设；每个假设都要有可渲染的区域图、构图预算、空间预算、空间用途，以及宽屏/中等/窄屏决策。空间预算须明确有用的平衡空间、自然占用率、窄边距，以及连续全出血区域的风险。将这些视为可替换的可渲染候选方案，而非页面模板。在选定真正针对具体主体的设计主张之前，本地设计方向记录都只能视为候选方案。对于重要布局工作，请阅读 references/visual-composition.md；局部对齐轴不能决定整个页面。
• 将硬性不变量与视觉偏好区分开来。无障碍性、相关任务/状态或原创体验的完整性、响应式可用性、资源真实性、动态效果回退方案、运行时完整性，以及渲染效果的验证，都是硬性要求；本地反 AI 检查仅供参考，可以由项目自有的 DESIGN.md、经过检查的参考、已接受的概念、用户明确指示，或带有覆盖记录的有力模型提案覆盖。
• 实施前进行创意差异化检查：对于重要且开放的工作，根据真实对象、内容和任务构思 2-3 个结构不同的概念；比较它们的阅读顺序、主导对象、轮廓、文字与媒体的关系、交互模型和响应式可行性；选出最连贯有力的设计主张，而不是为了保持一致而保留本地候选方案。
• 对于重要工作，执行 references/design-production-loop.md，并将全部 20 个检查点作为决策和证据完成，而非盲目重写。
• 针对渲染后的界面进行迭代：核实截图条件，检查可见缺陷，修改代码或资源，然后重新截图并比较。检查真实内容和完整连续的工作流，而不只是默认截图。当操作改变视觉状态时，让发生变化的对象或结果保持在视野内，并从最相关的深层滚动位置测试该操作。在接受截图前，先确定字体、图像和入场动效。将实际迭代次数与 20 个工作流检查点分开统计；静态代码或成功构建不代表视觉验收。使用可用的连接浏览器，或目标项目的 Playwright/Puppeteer，在宽屏、普通、中等和窄屏宽度下获取几何证据；references/verification.md 中的快照流程无需额外浏览器依赖。检查溢出、局部表面内边距、受限的阅读宽度和局部对齐方式的搭配；将审查结果视为截图评估的线索，而非审美判决。
• 明确陈述事实、假设、缺失的证据和阻碍。不要将用户的 token 预算浪费在泛泛的赞美或冗长的设计论述上。

路由请求

使用能够满足请求的最小模式，然后将当前界面归类为 Persuade、Operate、Read 或 Experience；分类针对单条路由，而非整个产品。

1. 快速润色：涉及一个组件、一种状态，或一个局部间距／字体／颜色问题。检查局部模式，进行最小的可见改动，并验证该状态。
2. 产品 UI：应用、仪表板、编辑器、设置、商业、电商、开发者工具或嵌入式界面。优先优化任务清晰度、信息密度、信任感、状态覆盖范围和响应式输入行为。
3. 媒体主导：落地页、作品集、发布页、产品故事、模型查看器或空间界面。让真实媒体或有意义的对象承担首屏的视觉重点；如果两者都不适用，则探索以字体、材质或内容为主导的构图，以满足相同的访客意图。
4. 参考驱动的构建：用户说“像／类似／参考某个网站”，或提供 URL 并期待可用的结果。将其视为实现工作，而非情绪板需求。
5. 仅提供方向：用户只要求选项、计划或分析，不要求实现。给出简洁的方向决策和实现约定。

当工作量较大、需求模糊或可能影响多个屏幕时，阅读 references/operating-modes.md。使用 surface-mode 和 design-operation，将页面意图和反馈转化为明确的下一步行动。

四个阶段

1. 检查

对于每个前端请求，都从决策流程开始。对于微小的局部修复，扫描和回复应保持简洁，但不得跳过能力检查。<skill-root> 指包含此 SKILL.md 的目录；如果安装程序未直接提供该目录，请在运行命令前先确定其位置：

node <skill-root>/scripts/audit.mjs <project-root> \
  --query "<product, screen, or implementation question>" --format md

每次重要检查都会运行完整的本地流程：本地证据、依赖关系图、确定性视觉 lint、设计智能、所有已保存的参考视角、资源来源、参考／构建约定、内部 Transitions.dev 动效审查，以及精简的 Decision / Changed / Proof / Open 约定。动效默认开启；仅当必须避免刷新私有动效缓存时，才添加 --offline。

如需进行范围更窄的读取，可直接运行本地扫描器：

node <skill-root>/scripts/inspect-project.mjs <project-root> --format md

当代码库规模较大或问题较具体时，先查询本地映射，再广泛阅读：

node <skill-root>/scripts/project-map.mjs <project-root> \
  --query "where is the settings form and its validation state?" \
  --format md

只记录有证据支持的内容：框架和脚本、路由、组件、设计令牌、资源、现有设计记忆、薄弱的基础组件和约束。阅读根目录中的 PRODUCT.md，了解长期受众、主题和目标；另行阅读 DESIGN.md，了解视觉方向。当前页面需求优先；可选设置记录在 references/design-system.md 中。如果项目无法运行，请说明这一点，并仅进行静态扫描。

当文件之间的关系很重要时，查询代码库图谱，不要仅凭路径名称推断：

node <skill-root>/scripts/project-graph.mjs <project-root> \
  --query "where is the settings form and its validation state?" \
  --format md

若要借鉴外部灵感，先完成扫描，再加载完整的本地参考清单，然后按不同用途选择至多 2-4 个实现视角。具体的设计说明除领域／组件／动效视角外，还必须包含整页构图和响应式候选方案。所有参考都会纳入考量；只应用有依据且互不冗余的决策。写明要借鉴、舍弃和转化的内容：

node <skill-root>/scripts/reference-composition.mjs \
  --query "<product, screen, or implementation question>" \
  --profile "<product profile>" --style "<candidate stance>" \
  --motion "<motion intent>" --format md

阅读 references/reference-composition.md，了解角色模型。Siteinspire、Awwwards、MUUUUU、Behance、Dribbble、Mobbin、Pinterest、Huaban、Muzli 和 Eagle Blog 是用于探索整页构图、材质、组件、工作流和响应式决策的视角；借鉴之前，请追溯到原始页面。Rare UI、Rewamp UI、Beautiful UI、beUI、Magic UI、React Bits、Aceternity UI 和 Obsidian UI 是视觉或样例视角；Rewamp UI 是专注于组件的工作台视角。Bencho 和 Design Spells 用于微交互研究；Transitions.dev 用于动效规范；shadcn/ui 是由源码所有者维护的基础。由选择器判断哪些视角适用于当前任务，而不是强制使用固定组合。

当用户只提供产品类型而没有具体案例时，根据查询和本地证据推断临时概况，启用整页和响应式探索，标明置信度和待补充证据，并将领域和组件视角作为补充。当请求只有“做一个网站”或类似表述时，采用自适应默认方案，不要推断为电商、仪表盘或编辑类结构。不要从已保存的示例中臆造视觉风格。

对于任何没有指定案例的实质性工作，都要运行 scripts/reference-scout.mjs 并阅读 references/reference-discovery.md。它会根据缺失的决策提供探索渠道，并在主题不在本地目录中时继续开放探索。追踪图库候选项，找到其原始网站或完整项目；借鉴之前，先检查构图、完整范围和响应式行为。根据任务契合度和已展现的质量进行选择，而非依据地域、知名度或固定的页面类型。只有当硬件确实是主题时，硬件候选项才有用。在选定整页各部分的关系后，再使用组件和动效视角处理具体需求。

对于以视觉为主的界面，请阅读 references/creative-direction.md 和 references/visual-iteration.md。在编写代码之前，使用可用的图像生成工具探索尚未确定的构图或媒介；如果首次渲染效果平淡，则编辑检查过的浏览器截图。使用 image-proposal 记录方案，明确选择该方案，将视觉差异转化为代码和可用素材，然后对比新生成的真实渲染结果。对于局部修复或方向已确定的设计，可跳过生成；概念方案也可以完全取代本地设计方向。

只要可见媒体很重要，就阅读 references/assets.md。用户提供的素材具有权威性；否则，请寻找高质量且来源可追溯的素材，或生成针对目标设计的媒体。如果没有素材达到质量标准，请采用完整的无素材构图，或说明阻碍因素，不要插入占位符。

当请求中指定了参考网站，或说“做一个类似这样的”时，请在编辑前生成实现契约：

node <skill-root>/scripts/reference-build.mjs \
  --query "<one-sentence request>" --project <project-root> --format md

阅读 references/reference-build.md。该契约是构建依据，包含视觉基因、首屏视口、页面规划、核心／可选区域、构图与空间预算、组件语法、状态／动效契约、响应式重新布局、素材备用方案、构建顺序和验收关卡。继续检查目标项目代码并在浏览器中验证；视觉验收前运行 layout-audit，获取页面外壳节奏、视口分段、窄边距和局部锚点方面的证据。

对于实质性请求，请创建简短的框架：

Goal / workflow:
Surface / device / input:
Density / frequency:
Real content, data, and media:
Critical states:
Top visible problems:
Risk if wrong:

2. 选择

使用本地简报生成器获取候选方案，而非将其视为权威：

node <skill-root>/scripts/design-brief.mjs \
  --query "<product and screen>" \
  --project <project-root> \
  --format md

在选择字体、颜色、组件形态、内容准备情况或持久化的 DESIGN.md 时，请阅读 references/design-system.md。简报必须明确说明：

• 产品概况、访客界面模式和设计操作
• 设计立场和一个标志性设计手法
• 字体上限和字体角色
• 组件形态语言、几何层级和卡片预算
• 视觉方向契约：首屏构图、各区域的位置／文本对齐方式／尺寸、相邻关系、宽窄屏重排方式、主次关系、间距节奏、表面预算、边缘特征、圆角层级、分隔线／线条策略、视觉立场／标志性手法、权威来源，以及 AI 默认值的参考检查项
• 动效目的和回退方案
• 明确不采用的内容
• 置信度和证据缺口
• 场景调节项、质量门槛、反模式检查清单和实现检查项
• 基于角色的参考构图，以及借鉴、舍弃和转化的决策

在进行大规模通用构建前，或收到结果过于方正、僵硬、分隔过多或过于尖锐的反馈时，请阅读 references/geometry-language.md。默认采用柔和的结构性几何形态和非边框分组，而不是到处使用圆角卡片；如果产品本身或更有力的权威来源有依据，则保留锐利的几何形态。

当项目包含 DESIGN.md、用户提供了明确的视觉方向，或参考内容与本地默认方案冲突时，请阅读 references/constraint-authority.md。对于开放式重新设计和有主创意图的方案，请阅读 references/creative-direction.md。以证据最充分的方向为准，并使用本地数据集填补空缺，而非让设计趋于同质化。

当用户要求高端、优质、精致、奢华、高级、质感，或首轮渲染显得平庸时，请阅读 references/premium-finish.md。在添加其他参考或依赖前，先完成润色环节。若要强化字体／图像关系、阅读节奏、材质、信息编排或表现力动效，请阅读 references/design-methods.md；其中标注来源的方法可围绕目标组合、扩展或替换，也可在匹配器没有结果时独立提出方案。

只有在方向确实模糊且返工代价高时，才暂停并确认设计方向。否则，记录方向假设并继续。提出备选方案时，应确保它们在结构上有所不同；绝不能把同一种通用风格的三种表面变化当作备选方案。

3. 构建

对于较大规模的工作，请阅读 references/implementation.md。先构建布局和交互模型，再添加装饰性样式：

• 先遵循 references/product-prototype.md：为当前工作选择合适的验证模式。功能型产品需要提供可用的垂直切片；叙事型、艺术指导型和实验型作品则需要一个主题、核心论点、注意力路径、精心设计的证明，以及明确的结尾。当具体请求返回 needs-target-proposal 或通用目的字段时，请通过 references/creative-direction.md 在内部撰写其 productSignal、视觉论点和完整范围，然后实施。不要让用户补全模式定义，也不要停留在提案阶段。这里没有规定页面类型。

• 润色之前，先声明完整的完成范围。首屏是验收锚点，而不是完成的定义；请完成所有计划区域、状态、响应式布局、资源、目标页面和结尾。

• 首次阅读、主要操作、信息层级和响应式重排

• 使用本地或成熟的基础组件，并在相关情况下完善悬停、聚焦、按下、禁用、加载、空、错误、成功、已选中和部分数据状态

• 使用真实的文案与数据；如果所选模式包含具体主题、产品、作品或工作流对象，则使用实际对象

• 一个与真实状态关联的标志性交互，而非装饰性循环

• 无障碍键盘/触控行为以及减少动态效果的行为

对于以参考为导向的构建，如果目标作品包含内容、创作者信息和工作流，请予以保留，同时借鉴参考作品的视觉语法。不要复制徽标、品牌名称、专有资源、源代码、完全相同的文案，也不要制作难以区分的整页克隆。“相似”是指将类似的层级、质感、节奏、示例行为、顺序和动态效果意图转化到目标作品中。

添加组件、动态效果、图表、图标、媒体或 3D 依赖项之前，请阅读 references/resources.md。使用可执行目录缩小选择范围。除非源码、许可证和实现证据另有说明，否则 Bencho 和 Design Spells 仅供启发；Rewamp UI、Magic UI、React Bits、Aceternity UI 和 Obsidian UI 可作为复制并调整的候选项，绝不可作为默认皮肤：

node <skill-root>/scripts/resource-catalog.mjs \
  --query "<missing technical job>" --stack <detected-stack> --format md

完整审查始终会打开内部动态效果桥接流程。如果实现需要动态效果、滚动、路由连续性、GSAP、3D 或模型行为的详细规则，请阅读 references/motion.md；如果经审查后认为状态关系不适合加入动画，最终界面仍可保持静态。

每次进行较大规模的修改时，即使最终决定保持状态静态，也要在编辑前运行内部 Transitions.dev 桥接流程。需要时，它会将固定版本的上游 Skill 获取到私有缓存，并返回配方源码以及 Review -> Apply -> Polish 流程；用户无需安装或调用其他 Skill：

node <skill-root>/scripts/transitions-adapter.mjs \
  --intent "<state or relationship>" --project <project-root> --phase all --format md

应用配方前，请阅读返回的上游参考资料。只将所需配方复制到目标项目中，保留清理和重放行为，保留减少动态效果的保护机制，并提供静态/最终状态回退方案。切勿仅为复现配方而添加动态效果依赖项。

4. 验证

阅读 references/verification.md。运行目标，确认截图的实际视口、已加载的资源、已稳定的字体/动画、状态和滚动位置，然后在桌面端和目标移动设备视口中检查完整的声明范围。从实际控件位置触发相关的非默认状态或设计稿中的结尾；保持变更后的结果可见。在窄屏下保留完整的主路由路径；如果生成了已保存/下载的产物，请检查实际文件。检查控制台/构建输出。当目标已有 Playwright 或 Puppeteer 时，scripts/browser-capture.mjs 无需安装浏览器，即可保存可比较的本地截图和证明清单。将静态、运行时和视觉证据分开。

对于较大规模的工作，请遵循研究图谱、视觉迭代和 20 轮设计制作循环：启动会话，检查真实参考资料和截图，记录各区块的优胜方案与综合结果，修复实质性缺陷，并比较新截图。第 15–20 轮需要本地截图；第 16–19 轮需要前后截图、对比产物和最大差距修复记录；第 19 轮要求在条件允许时进行结构化的独立审视评议；较大规模的会话不得跳过轮次，第 20 轮则要求 CURRENT WINS。使用 critique 记录严重程度、区域、影响、证据、修复方案、置信度和结论；完整日志可作为第 19 轮的 --critique 传入，并会与该轮结论进行核对。design-loop start 会创建关联图谱；只有在质量、范围、无障碍、运行时和渲染证明关卡全部通过后，才能同时关闭两者。当视觉主张需要重做时，请围绕图像生成使用 image-proposal 日志：记录基线和提案，选择或拒绝提案，记录源文件转换，并且只有在实际生成修改后截图后才能关闭。生成的图像不能证明实现完整。当存在正在运行的开发目标时，使用 live start 和 live close 记录日志并检查基线、变体、验收、源文件差异和修改后截图证明。

对于此技能本身，请运行：

npm test

参考集成均可执行，而非仅为名称说明：设计智能（brief）、访客/操作路由（surface-mode、design-operation）、仅基于证据的源文件检查（visual-lint）、研究证据与区块综合（research-atlas）、20 轮制作规范与持久化质量关卡（design-loop）、视觉方向（direction）、代码库图谱（graph）、基于角色的参考资料组合（reference）、一句话实现规范（reference-build）、紧凑响应流程（audit）、精选资源（resource）、实时变体日志与证明关卡（live）、从图像提案到代码的日志（image-proposal）、结构化独立视觉评议（critique）以及内部动态桥接（motion）。

输出规范

默认使用简短、以决策为导向的回复：

Decision: <what changed and why>
Changed: <files or surface>
Proof: <commands, screenshots, states, or runtime evidence>
Open: <only real blockers or unverified claims>

只有在用户提出要求、方向风险较高，或产物将由其他 Agent 重复使用时，才使用较长的简报。请阅读 references/response-contract.md，了解简洁/深入模式。

硬性不变量与建议性偏好

硬性不变量绝不会为了风格而牺牲：保留语义可访问性、相关任务／状态或创作体验的完整性、响应式易用性、素材的真实性与使用权、动效清理／减少动效／回退方案、运行时完整性，以及真实可信的渲染结果证明。

以下内容属于建议性偏好检查，并非普遍适用的风格禁令：超大字号、等宽卡片墙、居中式首屏模板、默认库皮肤、效果堆叠、泛化的奢华配色、薄弱的媒体内容，以及装饰性动效。项目自有的 DESIGN.md、经过检查的参考、已接受的概念、明确的用户指示，或有证据支撑的模型提案，都可以有意覆盖这些偏好。在方向契约中记录来源、理由、证据、风险、保留的不变量，以及渲染结果证明。

如果反馈称结果难看、平淡、泛化、静态或昂贵，不要为上一轮结果辩护。重新执行 Inspect，替换薄弱的决策，并再次验证可见结果。

对于已设定的方向，使用 --direction-file <path> 搭配 direction、brief、reference-build 或 audit。JSON 是一份部分契约：已提供的构图、几何、处理方式和构建字段优先；省略的字段则根据本地证据补全。请参阅 references/creative-direction.md。