web-design-workflow-zh

name	web-design-workflow-zh
description	中文 Web Design 与 Vibe Coding 总控工作流：按新建网站、现有页面改版、图像先行和正式产品交付选择最少必要 skill，执行需求规格化、DESIGN.md、审美批判、纵向切片、工程实现、真实浏览器验收和上线门禁。Use when: 做网站、设计页面、landing page、portfolio、产品页、网站高级感、页面太丑、改版前端、生成 DESIGN.md、image-to-code、Vibe Coding、Web UI 验收、避免 AI 味、前端审美工作流。

Web Design Workflow Zh

Project structure gate / 文件树结构门禁

只要本工作流将初始化或重组项目，或新建、移动应用、服务、包、模块、页面、API、研究步骤、实验、流水线、测试、文档或多文件产物树，必须先使用 project-structure-architect。

1. 开始前：读取适用的 AGENTS.md、PROJECT_STRUCTURE.md、.project-structure.yaml 和现有文件树，锁定项目类型、蓝图及唯一合理路径。
2. 运行中：每次新增或移动文件前先判断职责、所有者、复用范围和对应测试；禁止同义目录、根目录堆放、跨层混放及无关重组。
3. 阶段收口：纵向切片或阶段完成后检查结构漂移；新项目或重大重组更新结构文档，最终运行结构审计。出现 BLOCK 时停止结构性写入并先修正或询问用户。

纯内容编辑且目标路径已由用户或现有规范唯一确定时，可不重复调用。

目标

用一个总控入口编排 Web 设计和前端交付：

需求边界 -> 选择任务分支 -> DESIGN.md -> 视觉纵向切片 -> 工程实现 -> 浏览器验收 -> 按需上线

该技能只负责路由和阶段门禁。不要一次性加载全部外部 skills；每个阶段只加载 1 个主 skill，最多追加 2 个辅助 skill。

启动检查

先读取当前项目的真实材料：

• PRD.md / SPEC.md / README / 用户提示词
• 现有 DESIGN.md、截图、Figma、参考 URL、品牌素材
• package.json、样式方案、组件库、路由和测试配置

再判断交付级别：

• 快速原型：课程项目、Demo、比赛原型、MVP、单页展示。
• 正式产品：真实上线、商业站点、SaaS、数据平台、长期维护项目。

详细步骤见 references/workflow-modes.md。

统一硬门槛模板

Web 任务在以下节点必须使用全局硬门槛模板：新建整站进入编码、现有页面大改、图像方向转代码、正式产品上线、真实浏览器验收前后。

硬门槛：
- 触发门槛：为什么不能直接全量编码或交付。
- 前置证据：PRD/brief、现有 DESIGN.md、截图/Figma/参考 URL、项目技术栈、浏览器验证结果。
- 禁止越界：不能破坏现有业务行为、不能跳过纵向切片、不能用漂亮图替代响应式和交互验证。
- 判定结果：PASS / CAUTION / BLOCK。
- 下一步动作：进入纵向切片、补 DESIGN.md、修视觉方向、补浏览器验证或暂停询问。

没有 DESIGN.md 或纵向切片的新建整站不能 PASS 进入全量实现；现有项目未列出保留项时不能 PASS 大改。

任务分支

A. 新建网站 / 新页面

使用顺序：

web-design 规则 -> frontend-design 批判 -> 本技能 Taste Gate
-> frontend-ui-engineering -> browser-testing-with-devtools -> Vercel Guidelines

产出项目根目录 DESIGN.md，再做一个代表全站质量的纵向切片，不要直接生成整站。

B. 现有页面改版

使用顺序：

redesign-existing-projects 审计 -> 更新 DESIGN.md
-> frontend-ui-engineering 定点修改 -> browser-testing-with-devtools 回归

先扫描、诊断、列出保留项，再修改。不得为了视觉重写框架、破坏业务行为或删除用户现有功能。

C. 图像先行

仅在以下情况启用：

• 用户明确要求先出视觉稿、参考图或 image-to-code。
• 视觉辨识度是核心目标，文字规范不足以消除方向分歧。
• 当前环境有图像生成能力。

使用顺序：

imagegen-frontend-web -> 选定视觉方向 -> image-to-code
-> DESIGN.md 反向固化 -> frontend-ui-engineering -> 浏览器验收

图像 skills 很长，只能放在独立设计阶段按需加载，不与完整 taste-skill 同时加载。

D. 局部 UI Bug

沿用现有 DESIGN.md 或项目样式，不启动完整工作流。直接使用：

frontend-ui-engineering -> browser-testing-with-devtools

E. 单文件视觉产物

只有用户要单文件 HTML、浏览器演示、可交互视觉稿或 slide-like artifact 时，才考虑 web-design-engineer。普通产品前端不使用它替代项目工程流程。

Phase 1: 规格化需求

至少锁定：

• 页面对象和唯一目标
• 目标用户与主要任务
• 页面/信息结构
• 真实内容和素材来源
• 现有技术栈或新项目最小技术选择
• 响应式、可访问性和验收范围

简单任务用一页 brief 即可；正式产品再扩展 PRD、用户流和页面结构。不要默认强制 Next.js、Tailwind 或 shadcn/ui，已有项目必须沿用现有栈。

Phase 1.5: 上下文参考路由

新建网站、视觉改版、图像先行、Dashboard、Web 用户流程，或需要改进信息层级、响应式、用户体验和产品展示逻辑的任务，在需求、受众、行业、技术栈和保留项锁定后，进入 DESIGN.md 前条件调用 contextual-reference-router：

规格化需求 → contextual-reference-router → reference-brief.md
→ DESIGN.md / Taste Gate

• 参考阶段只选 2–5 个互补来源，打开具体案例，记录采用/不采用规则、项目转译、访问和许可限制。
• 将 Reference Brief 的可执行规律写入 DESIGN.md 的“参考依据”，不能只列网站名。
• 局部 UI Bug、用户给出完整参考并要求严格局部复刻、用户明确禁止外部参考时跳过。
• BLOCK：没有具体案例、没有转译或许可不明时，不得进入 DESIGN.md；CAUTION：只能做最小切片并明确访问限制。
• Reference Brief 形成后退出该辅助 Skill，仍由本工作流和 frontend-ui-engineering 负责实现与浏览器验收。

Phase 2: DESIGN.md 与审美门

先输出一行 Design Read：

Reading this as: [页面类型] for [目标用户], with a [风格语言], leaning toward [设计系统/审美家族].

再确定：

• DESIGN_VARIANCE: 1-10，布局变化度。
• MOTION_INTENSITY: 1-10，动效强度。
• VISUAL_DENSITY: 1-10，信息密度。

创建或修订 DESIGN.md。契约见 references/design-md-contract.md。

Taste Gate

在写代码前检查：

• 设计是否来自具体受众、内容和品牌，而不是“高级感”空话？
• 是否落入紫蓝渐变、米色奢华、黑底酸绿色、三等分卡片等默认模板？
• Hero 是否表达页面核心，而不是固定的 H1 + 副标题 + 双 CTA？
• 是否只有一个可解释的 signature moment，并让其余页面保持克制？
• 文案是否真实、具体、可操作？
• 触发参考路由时，规律是否来自具体案例、已转译到当前项目且没有直接复制？

未通过时先改 DESIGN.md，不要进入构建。

Taste Gate 判定：

• PASS：设计方向、内容、受众、响应式范围和 signature moment 清楚，可进入纵向切片。
• CAUTION：方向基本可用，但缺素材、状态、响应式或可访问性证据；只能做最小切片，不做整站扩展。
• BLOCK：仍是模板化视觉、目标用户不清、现有业务保留项不明或关键内容缺失；先修 DESIGN.md。

Phase 3: 纵向切片

先实现一个能代表最终质量的完整片段，例如：

• Landing Page：导航 + Hero + 首个内容区。
• Dashboard：导航 + 一个真实数据区 + loading/empty/error。
• 表单流程：输入 + 校验 + 提交 + 成功/失败反馈。

切片必须同时覆盖真实内容、核心视觉、响应式和交互状态。方向错误时只返工切片，不返工整站。

协作模式下可展示切片让用户确认；用户要求自主端到端完成时，记录决策后继续，不停在等待确认。

Phase 4: 工程实现

• 沿用项目框架、路由、样式方案和组件库。
• 新依赖前检查依赖文件，不假设库已安装。
• 颜色、字体、间距、圆角和动效来自 DESIGN.md。
• 组件保持单一职责，数据获取和展示分离。
• 覆盖 loading、empty、error、hover、focus、active 和 disabled。
• 按可验证切片推进，不一次生成整个复杂项目。
• 前端应用完成后启动 dev server，并提供本地 URL。

Phase 5: 验收与交付

执行项目已有的 lint、typecheck、test、build，并做真实浏览器检查。至少覆盖桌面和移动端截图、控制台、网络、键盘导航、溢出和遮挡。

联网时读取最新 Vercel Web Interface Guidelines：

https://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md

无法联网时使用 references/acceptance-checklist.md。发现问题要直接修正并复验。

正式产品再追加 code review、Preview Deployment、性能、SEO、安全和发布回滚门禁；快速原型不强制完整上线链。

压缩包技能读取

按 references/source-map.md 选择来源，并用脚本读取指定 entry：

& .\scripts\Read-ZipSkill.ps1 -ZipPath C:\Users\zbh\.agents\skills-main.zip `
  -EntryPath skills-main/skills/frontend-design/SKILL.md

不得仅凭压缩包文件名推断内容。无效或下载不完整的 zip 不进入工作流。

输出要求

交付时说明：

• 使用了哪个任务分支和交付级别。
• PRD/brief、DESIGN.md、纵向切片和实现文件路径。
• 触发参考路由时，reference-brief.md 路径、Gate 状态、核心案例与实际落实位置。
• 执行过的验证命令、浏览器视口和结果。
• 本地预览或 Preview URL。
• 未覆盖风险、缺失素材和正式上线前待办。

失败红线

• 不做任务分支判断就加载所有设计 skills。
• 新建整站时没有 DESIGN.md 或纵向切片就全面编码。
• 现有项目改版时先重写框架，再谈视觉。
• 把外部 skill 的固定字体、图标、技术栈当成高于项目约束的规则。
• 图像先行只生成漂亮图，不反向固化 token、组件状态和响应式规则。
• 只检查代码，不做真实浏览器截图和交互验证。