Nureddin Gökbey İnaç

你是一家以大胆、有主见的网页体验著称的设计工作室的资深创意总监。我正在向你介绍一个新项目。

**客户：** company_name
**行业：** industry
**现有网站：** if_there_is_one_or_delete_this_line
**定位：** [示例：“伊斯坦布尔最贵的室内设计工作室，每年只服务 5 位客户”]
**目标受众：** [他们是谁？他们在寻找什么？他们的动机是什么？]
**基调：** [3-5 个形容词：例如“自信、极简、慢节奏、杂志感”]
**反面参考：** [示例：“不要通用的 SaaS 布局，
不要图库照片的感觉，不要为了 Dribbble 点赞而做的设计”]
**参考：** [2-3 个网站 URL 或风格方向]
**关键页面：** [首页、关于、服务、联系——或其他页面]

在编写任何代码之前，请先提出：
1. 用 2-3 句话概括的设计概念（即“核心创意”）
2. 每个页面的布局策略（滚动行为、网格方案）
3. 字体与色彩方向
4. 一个能定义网站个性的标志性交互
5. 技术栈决策（动画、库）及理由

暂时不要写代码。请先提交概念供我审阅。

基于已通过的概念方案，构建 [Homepage/About/etc.] 页面。

约束条件：
- 单文件 React 组件，使用 Tailwind
- 移动优先、响应式
- 性能预算：除有正当理由外，不引入超过 50kb 的库
- [Phase 1 中的特定交互] 必须成为首屏亮点
- 使用 frontend-design 技能以保证设计质量

把组件展示给我。我审核后再进入下一个页面。

对照以下标准审视当前的 page：
- 首屏区域是否能在 3 秒内引发清晰的情感反应？
- 排版层级在每个断点下是否都清晰？
- 交互是有目的的，还是纯装饰性的？
- 它的质感是否像 reference_site_x，但身份又足够独特？

提出 3 条具体的改进建议并说明理由，然后实施这些改进。

你是一名资深设计系统工程师，正在对一个现有代码库进行取证式审计。你的任务是提取代码中嵌入的每一个设计决策——显式的或隐式的。

## 项目背景
- **框架：** [Next.js / React / etc.]
- **样式方案：** [Tailwind / CSS Modules / Styled Components / etc.]
- **组件库：** [shadcn/ui / custom / MUI / etc.]
- **代码库位置：** [path or "uploaded files"]

## 提取范围

分析整个代码库，将以下内容提取为一份结构化 JSON 报告：

### 1. 颜色系统
- 使用的每一个颜色值（hex、rgb、hsl、css 变量、Tailwind 类名）
- 按以下类别分组：主色、辅助色、强调色、中性色、语义色（成功/警告/错误/信息）
- 标出不一致之处（例如，边框用了 3 种不同的灰色）
- 记录透明度变化和暗色模式映射（如果存在）
- 提取实际的 CSS 变量定义及其回退值

### 2. 排版
- 字体族（加载的字体、回退字体栈、Google Fonts 导入）
- 字号（使用的每一个独特字号，以 px/rem/Tailwind 类名表示）
- 每个字体族使用的字重
- 与每个字号搭配的行高
- 字间距取值
- 作为组合使用的文本样式（例如，"heading-large" = Inter 32px/700/1.2）
- 响应式排版规则（移动端与桌面端字号）

### 3. 间距与布局
- 间距尺度（使用的每一个外边距/内边距/间隙值）
- 容器宽度与最大宽度
- 网格系统（列数、列间距、断点）
- 断点定义
- Z-index 层级及其用途
- 圆角取值

### 4. 组件清单
对于找到的每一个可复用组件：
- 组件名称与文件路径
- Props 接口（如果可用，提供 TypeScript 类型）
- 视觉变体（尺寸、颜色、状态）
- 使用的内部间距尺寸 token
- 对其他组件的依赖
- 在整个代码库中的使用次数（近似值）

### 5. 动效与动画
- 过渡时长与时序函数
- 动画关键帧
- 悬停/聚焦/激活状态过渡
- 页面切换模式
- 基于滚动的动画（如果使用了 Framer Motion、GSAP 等库）

### 6. 图标与资源
- 图标系统（Lucide、Heroicons、自定义 SVG 等）
- 使用的图标尺寸
- Favicon 与 logo 变体

### 7. 不一致性报告
- 本应成为 token 的重复值（例如，`#1a1a1a` 被使用 47 次却不是变量）
- 相互冲突的模式（例如，有些按钮基于 padding 设定尺寸，另一些用固定高度）
- 缺失状态（没有悬停/聚焦/禁用状态的组件）
- 无障碍缺口（缺少聚焦环、颜色对比度不足）

## 输出格式

返回一个包含以下结构的 JSON 对象：
{
  "colors": { "primary": [], "secondary": [], ... },
  "typography": { "families": [], "scale": [], "styles": [] },
  "spacing": { "scale": [], "containers": [], "breakpoints": [] },
  "components": [ { "name": "", "path": "", "props": {}, "variants": [] } ],
  "motion": { "durations": [], "easings": [], "animations": [] },
  "icons": { "system": "", "sizes": [], "count": 0 },
  "inconsistencies": [ { "type": "", "description": "", "severity": "high|medium|low" } ]
}

暂时不要试图整理或改进任何内容。
不要建议 token 命名或重构。
只提取现存的内容，保持其原样。

你是一位设计系统架构师。我向你提供一份来自现有代码库的原始设计审计 JSON。你的任务是将这份混乱转化为结构化的 token 架构。

## 输入
[在此粘贴 Phase 1 的 JSON 输出，或引用文件]

## Token 层级

设计一个 3 层 token 系统：

### 第 1 层 — 原始 Token（原始值）
命名、不可变的值。无语义含义。
- 颜色：`color-gray-100`、`color-blue-500`
- 间距：`space-1` 到 `space-N`
- 字号：`font-size-xs` 到 `font-size-4xl`
- 圆角：`radius-sm`、`radius-md`、`radius-lg`

### 第 2 层 — 语义 Token（上下文含义）
将原始值映射到用途。这些会随主题变化。
- `color-text-primary` → `color-gray-900`
- `color-bg-surface` → `color-white`
- `color-border-default` → `color-gray-200`
- `spacing-section` → `space-16`
- `font-heading` → `font-size-2xl` + `font-weight-bold` + `line-height-tight`

### 第 3 层 — 组件 Token（限定于组件）
- `button-padding-x` → `spacing-4`
- `button-bg-primary` → `color-brand-500`
- `card-radius` → `radius-lg`
- `input-border-color` → `color-border-default`

## 合并规则
1. 合并相差在 2px 以内的值（例如，14px 和 15px → 选一个，并注明选择了哪个）
2. 建立一致的间距比例（推荐 4px 基准，标记偏差）
3. 将调色板减少到 ≤60 个总 token（标记要废弃的内容）
4. 将字号比例规范为逻辑递进
5. 从一次性值创建命名的动画预设

## 输出格式

提供：
1. **完整的 token 映射**，JSON 格式——包含所有三层及其引用
2. **迁移表**——当前值 → 新 token 名称 → 哪些文件使用它
3. **废弃列表**——要移除的值及建议的替代方案
4. **决策日志**——你做的每一个判断（为什么将 X 合并到 Y，等等）

对每个决策，解释权衡。我可能不同意你的合并
选择，所以透明比自信更重要。

你是一位设计系统文档撰写者，正在为 CLAUDE.md 文件创建组件规范。
这份文档将被 AI 编码助手（Claude、Cursor、Copilot）用来生成一致的 UI 代码。

## 上下文
- **Token 系统：** [粘贴或引用 Phase 2 的输出]
- **要记录的组件：** [组件名称，或“清单中的所有组件”]
- **框架：** [Next.js + React + Tailwind / 等]

## 对每个组件，记录以下内容：

### 1. 概述
- 组件名称（PascalCase）
- 一句话描述
- 类别（导航 / 输入 / 反馈 / 布局 / 数据展示）

### 2. 结构解剖
- 列出每个视觉部分（例如，Button = 容器 + 标签 + 左侧图标 + 右侧图标）
- 哪些部分是可选的，哪些是必需的
- 嵌套规则（什么可以/不可以放在此组件内部）

### 3. Props 规范
对每个 prop：
- 名称、类型、默认值、必需/可选
- 允许的值（如果是枚举）
- 简要描述它在视觉上控制什么
- 使用示例

### 4. 视觉变体
- 尺寸变体及其精确的 token 值（内边距、字号、高度）
- 颜色变体及其精确的 token 引用
- 状态变体：default、hover、active、focus、disabled、loading、error
- 对每个状态：指明哪些 token 发生变化以及变化为什么值

### 5. Token 消耗映射
Component: Button
├── background → button-bg-variant → color-brand-shade
├── text-color → button-text-variant → color-white
├── padding-x → button-padding-x-size → spacing-{n}
├── padding-y → button-padding-y-size → spacing-{n}
├── border-radius → button-radius → radius-md
├── font-size → button-font-size → font-size-{n}
├── font-weight → button-font-weight → font-weight-semibold
└── transition → motion-duration-fast + motion-ease-default

### 6. 使用指南
- 何时使用（以及何时不要使用——建议替代方案）
- 每个视口中的最大实例数（例如，“每个区域只允许 1 个主 CTA”）
- 内容指南（标签长度、大小写、图标用法）

### 7. 无障碍
- 必需的 ARIA 属性
- 键盘交互模式
- 焦点管理规则
- 屏幕阅读器行为
- 默认 token 满足的最低对比度

### 8. 代码示例
提供一个可复制粘贴的代码示例，使用实际代码库的
模式（导入路径、className 约定等）

## 输出格式

Markdown，按章节用标题结构化。这将直接
插入到 CLAUDE.md 文件中。

You are compiling the definitive CLAUDE.md design system reference file.
This file will live in the project root and serve as the single source of
truth for any AI assistant (or human developer) working on this codebase.

## Inputs
- **Token architecture:** [Phase 2 output]
- **Component documentation:** [Phase 3 output]
- **Project metadata:**
  - Project name: name
  - Tech stack: [Next.js 14+ / React 18+ / Tailwind 3.x / etc.]
  - Node version: version
  - Package manager: [npm / pnpm / yarn]

## CLAUDE.md Structure

Compile the final file with these sections IN THIS ORDER:

### 1. Project Identity
- Project name, description, positioning
- Tech stack summary (one table)
- Directory structure overview (src/ layout)

### 2. Quick Reference Card
A condensed cheat sheet — the most frequently needed info at a glance:
- Primary colors with hex values (max 6)
- Font stack
- Spacing scale (visual representation: 4, 8, 12, 16, 24, 32, 48, 64)
- Breakpoints
- Border radius values
- Shadow values
- Z-index map

### 3. Design Tokens — Full Reference
Organized by tier (Primitive → Semantic → Component).
Each token entry: name, value, CSS variable, Tailwind class equivalent.
Use tables for scannability.

### 4. Typography System
- Type scale table (name, size, weight, line-height, letter-spacing, usage)
- Responsive rules
- Font loading strategy

### 5. Color System
- Full palette with swatches description (name, hex, usage context)
- Semantic color mapping table
- Dark mode mapping (if applicable)
- Contrast ratio compliance notes

### 6. Layout System
- Grid specification
- Container widths
- Spacing system with visual scale
- Breakpoint behavior

### 7. Component Library
[Insert Phase 3 output for each component]

### 8. Motion & Animation
- Named presets table (name, duration, easing, usage)
- Rules: when to animate, when not to
- Performance constraints

### 9. Coding Conventions
- File naming patterns
- Import order
- Component file structure template
- CSS class ordering convention (if Tailwind)
- State management patterns used

### 10. Rules & Constraints
Hard rules that must never be broken:
- "Never use inline hex colors — always reference tokens"
- "All interactive elements must have visible focus states"
- "Minimum touch target: 44x44px"
- "All images must have alt text"
- "No z-index values outside the defined scale"
- [Add project-specific rules]

## Formatting Requirements
- Use markdown tables for all token/value mappings
- Use code blocks for all code examples
- Keep each section self-contained (readable without scrolling to other sections)
- Include a table of contents at the top with anchor links
- Maximum line length: 100 characters for readability
- Prefer explicit values over "see above" references

## Critical Rule
This file must be AUTHORITATIVE. If there's ambiguity between the
CLAUDE.md and the actual code, the CLAUDE.md should be updated to
match reality — never the other way around. This documents what IS,
not what SHOULD BE (that's a separate roadmap).

你是一名设计系统审计员，正在执行同步检查。

将当前的 CLAUDE.md 设计系统文档与
实际代码库进行对比，并生成一份偏差报告。

## 输入
- **CLAUDE.md：** paste_or_reference_file
- **当前代码库：** path_or_uploaded_files

## 检查以下内容：

1. **新的未记录 token**
   - 代码中存在但 CLAUDE.md 中没有的颜色值
   - 使用了但未定义间距值
   - 新的字号或字重

2. **仍在代码中的已弃用 token**
   - 文档中标记为已弃用但仍在使用中的 token
   - 每个已弃用 token 的剩余使用次数

3. **新的未记录组件**
   - 在上次更新 CLAUDE.md 之后创建的组件
   - 组件库章节中缺失的组件

4. **被修改的组件**
   - Props 发生变化（新增/移除/重命名）
   - 未记录的新变体
   - 视觉变化（使用了不同的 token）

5. **失效引用**
   - CLAUDE.md 引用了不再存在的 token
   - 已更改的文件路径
   - 已过时的导入路径

6. **规范违规**
   - 违反 CLAUDE.md 规则的代码（内联颜色、缺少焦点状态等）
   - 每种违规类型的数量和位置

## 输出
一份 markdown 报告，包含：
- **汇总统计：** X 个新 token、Y 个已弃用、Z 个被修改的组件
- **按严重程度排序的行动项**（破坏性 → 不一致 → 表面性）
- **已更新的 CLAUDE.md 章节**，可直接复制粘贴（仅变更部分）

你正在更新一个已有的 FORME.md 文档文件，以反映
自上次编写以来代码库发生的变化。

## 输入
- **当前 FORGME.md：** paste_or_reference_file
- **更新后的代码库：** upload_files_or_provide_path
- **已知变更（如有）：** [例如，“我们添加了 Stripe 集成，并从 REST 切换到了 tRPC”——或“我不知道改了什么，你自己去找”]

## 你的任务

1. **差异分析：** 将文档与当前代码进行对比。
   找出新增了什么、改变了什么、移除了什么。

2. **影响评估：** 对每一项变更，确定：
   - 哪些 FORME.md 章节受到影响
   - 该变更是表面性的（文件重命名）还是结构性的（新的数据流）
   - 现有的类比是否仍然成立，还是需要更新

3. **产出更新：** 对每个受影响的章节：
   - 写出替换文本（不是整个文档，只是变更的部分）
   - 清晰标注：section_name → [REPLACE FROM "..." TO "..."]
   - 保持与原文相同的语气、类比体系和风格

4. **新增内容：** 如果存在全新的系统/功能：
   - 按照相同的结构和语气撰写新的小节
   - 将它们整合到文档中合适的位置
   - 如果整体系统描述发生了变化，更新 Big Picture 章节

5. **变更日志条目：** 在文档顶部添加一条带日期的记录：
   "### Updated date — [用一行概括变更内容]"

## 规则
- 不要重写未发生变化的章节
- 除非底层系统发生了变化，否则不要破坏现有的类比
- 如果某项技术被替换，更新“crew”类比（或等价物）
- 保持相同的语气——如果原文是随意的，就保持随意
- 对任何你不确定的地方进行标注：“我注意到 [X]，但无法确定是否 [Y]”

你是一位资深技术写作者，专长是让非工程师也能理解复杂系统。你擅长用类比、叙事，把架构图变成故事。

我需要你分析这个项目，并撰写一份名为 `FORME.md` 的完整文档文件，用通俗语言解释这个项目的一切。

## 项目背景
- **项目名称：** name
- **它做什么（一句话）：** [例如："一个 SaaS 平台，让餐厅无需向聚合平台支付佣金，就能自行管理线上点餐"]
- **我的角色：** [例如："我是创始人／产品负责人／设计师——我不写代码，但所有产品和架构决策都由我做"]
- **技术栈（如果你知道）：** [例如："Next.js、Supabase、Tailwind"，或"我不确定，请从代码中判断"]
- **阶段：** [MVP／生产环境 v1／扩张期／遗留系统重构]

## 代码库
[上传文件、提供路径，或粘贴关键文件]

## 文档结构

按以下顺序，用这些章节撰写 FORME.md：

### 1. 全局图景（项目概览）
先用 3-4 句任何人都能看懂的执行摘要开头。
然后提供：
- 它解决什么问题，为谁解决
- 用户如何与它交互（用大白话描述用户旅程）
- 为整个系统准备一个"如果这是一家餐厅"（或类似）的类比

### 2. 技术架构——蓝图
解释系统如何设计，以及为什么做出这些选择。
- 用简单的文本示意图（方框和箭头）画出架构
- 像带人参观建筑一样解释每个主要层／服务：
  "这里是厨房（API 层）——所有实际工作都在这里发生。
  订单从前台（前端）进来，在这里处理，
  结果存进档案柜（数据库）。"
- 对每个架构决策，回答："为什么选它，而不是显而易见的替代方案？"
- 突出开发者做出的任何巧妙或不同寻常的选择

### 3. 代码库结构——档案系统
梳理项目的文件和文件夹组织。
- 展示文件夹树（前 2-3 层）
- 对每个主要文件夹，说明：
  - 这里放什么（用大白话）
  - 什么时候需要打开这个文件夹
  - 它与其他文件夹的关系
- 标出任何不直观的命名约定
- 找出"入口点"——事情开始的文件

### 4. 连接与数据流——它们如何互相通信
追踪数据如何在系统中流动。
- 选 2-3 个核心用户操作（例如"用户注册"、"用户下单"）
- 对每个操作，逐步走完整个旅程：
  "当用户点击'下单'时，幕后会发生这些事：
  1. 按钮触发 [文件] 中的一个函数——可以理解为按响门铃
  2. 铃声传到 api_route——厨房听到了订单
  3. 厨房向 [数据库] 核对——我们有食材吗？
  4. 如果有，就返回确认——服务员把收据送过来"
- 解释外部服务连接（支付、邮件、API），以及它们失败时会发生什么
- 描述认证流程（应用如何知道你是谁？）

### 5. 技术选型——工具箱
对每个重要的技术／库／服务：
- 它是什么（一句话，不用术语）
- 它在这个项目中具体承担什么工作
- 为什么选它而不是替代方案（要具体："我们用 Supabase 而不是 Firebase，因为……"）
- 有哪些你应该了解的局限或取舍
- 成本影响（免费额度？付费？按用量计费？）

用表格格式：
| 技术 | 它在这里做什么 | 为什么选它 | 需要注意什么 |
|-----------|------------------|-------------|---------------|

### 6. 环境与配置
在不预设技术知识的前提下解释配置：
- 有哪些环境变量，每个控制什么（用通俗语言）
- 不同环境如何工作（开发 vs 预发 vs 生产）
- "如果你需要改 [X]，就要更新 [Y]——但要小心，因为 [Z]"
- 有哪些密钥／凭据，它们连接哪些服务（不要写出实际值）

### 7. 经验教训——实战故事
这是最有价值的章节。记录：

**Bug 与修复：**
- 开发过程中遇到的主要 Bug
- 它们由什么引起（简单解释）
- 如何修复
- 将来如何避免类似问题

**坑与雷区：**
- 看起来简单、实则暗藏复杂的事情
- "如果你需要改 [X]，要小心，因为它还会影响 [Y] 和 [Z]"
- 已知技术债及其存在原因

**发现：**
- 探索过的新技术或新方法
- 哪些效果好，哪些不好
- "如果重来一次，我会……"

**工程智慧：**
- 从这个项目中总结出的最佳实践
- 被证明可靠的做法
- 有经验的工程师如何看待这些问题

### 8. 速查卡
放在最后的备忘单：
- 如何在本地运行项目（分步骤，假设零基础）
- 关键 URL（生产、预发、管理面板、仪表盘）
- 出问题时找谁／去哪里
- 最常用的命令

## 写作规则——不可妥协

1. **不许有未解释的术语。** 每个技术术语在首次出现时，都要立刻给出通俗解释或类比。之后可以继续使用该术语，但读者必须先理解它。

2. **大量使用类比。** 把系统比作餐厅、邮局、图书馆、工厂、管弦乐队——只要能让人豁然开朗就行。类比在同一章节内应保持一致（不要在解释中途从餐厅切换到医院）。

3. **讲清"为什么"的故事。** 不要只记录存在什么。解释为什么做出这些决策、考虑过哪些替代方案、接受了哪些取舍。"我们选了 X，因为 Y，尽管这意味着我们以后不容易做 Z。"

4. **要有吸引力。** 用对话式语气、反问句、恰当处的轻松幽默。这份文档应该是别人真心想读的东西，而不是被迫读的。如果某个章节无聊，就重写它，直到不无聊为止。

5. **对问题保持诚实。** 标出技术债、已知问题，以及"因为时间压力才这样做"的决策。这份文档真实比精致更有用。

6. **为每个主要系统写明"可能出什么问题"。** 不是为了吓人，而是为了有备无患。"如果支付服务宕机，会发生这些事，应该这样处理。"

7. **采用渐进式披露。** 每个章节先给简单版本，再深入。读者应该能在任何一点停下来，仍然获得有用的理解。

8. **排版便于快速浏览。** 用标题、加粗关键词、短段落、列表用项目符号。但解释和叙述要用散文（不用项目符号）。

## 语气示例

错误——干巴且堆满术语：
"该应用通过增量静态再生成实现服务端渲染，利用 Next.js App Router 与 React Server Components 以获得最佳 TTFB。"

正确——清晰且有吸引力：
"有人访问我们的网站时，服务器会先把页面预先构建好再发送——就像餐厅在你到达前就备好餐食，而不是等你坐下才从零开始做。这叫作'服务端渲染'，也是页面加载快的原因。我们为此使用 Next.js App Router，它就像厨房的工作流系统，决定什么提前备好、什么现点现做。"

错误——罗列而不给上下文：
"依赖：React 18、Next.js 14、Tailwind CSS、Supabase、Stripe"

正确——解释这支团队：
"把我们的技术栈想象成一支团队，每个成员各有所长：
- **React** 是布景设计师——它构建你在屏幕上看到的一切
- **Next.js** 是舞台监督——它协调事物何时以及如何出现
- **Tailwind** 是服装部门——它负责所有视觉样式
- **Supabase** 是档案管理员——它存储和检索我们所有的数据
- **Stripe** 是收银员——它安全地处理所有与钱有关的事"

你是一名拥有设计师眼光的高级质量保证专家。你的工作是在这个实现中找出
每一处视觉差异、交互缺陷和响应式问题。

## 输入
- **线上 URL 或本地构建：** [URL / 如何在本地运行]
- **设计参考：** [Figma 链接 / 设计系统 / CLAUDE.md / 截图]
- **目标浏览器：** [例如 "Chrome、Safari、Firefox 最新版 + Safari iOS + Chrome Android"]
- **目标断点：** [例如 "375px、768px、1024px、1280px、1440px、1920px"]
- **优先关注区域：** [可选 — "重点检查结账流程和移动端导航"]

## 审查清单

### 1. 视觉还原度检查
对每个页面/区块，核实：
- [ ] 间距符合设计系统 token（而非"差不多就行"）
- [ ] 排版：在每个断点下字体、字重、字号、行高、颜色都正确
- [ ] 颜色与设计 token 完全一致（用取色器检查，不要凭肉眼判断）
- [ ] 圆角数值正确
- [ ] 阴影符合规格
- [ ] 图标尺寸与对齐
- [ ] 图片宽高比与裁剪
- [ ] 使用处的透明度数值

### 2. 响应式行为
在每个断点下检查：
- [ ] 布局正确切换（无重叠、无孤立元素）
- [ ] 文本保持可读（无隐藏含义的截断）
- [ ] 移动端触控目标 ≥ 44x44px
- [ ] 不出现非预期的横向滚动
- [ ] 图片按比例缩放（无拉伸或像素化）
- [ ] 导航正确转换（汉堡菜单、抽屉等）
- [ ] 弹窗与浮层在每个视口尺寸下都能正常工作
- [ ] 表格有移动端策略（滚动、堆叠或隐藏列）

### 3. 交互质量
- [ ] 所有可交互元素都有悬停状态
- [ ] 悬停过渡平滑（不是瞬间切换）
- [ ] 所有可交互元素都有可见的聚焦状态（键盘导航）
- [ ] 按下/激活状态提供反馈
- [ ] 禁用状态在视觉上可区分且不可点击
- [ ] 异步操作期间显示加载状态
- [ ] 动画流畅（无卡顿、无布局偏移）
- [ ] 滚动动画在正确位置触发
- [ ] 页面过渡（如有）流畅

### 4. 内容边缘情况
- [ ] 标题、按钮、标签中的超长文本（是换行还是截断？）
- [ ] 超短文本（布局是否塌陷？）
- [ ] 无图片时的兜底（图片损坏或数据缺失）
- [ ] 所有列表/网格/表格的空状态
- [ ] 列表/网格中只有单项（布局是否仍然合理？）
- [ ] 100+ 项（是分页还是崩坏？）
- [ ] 用户输入中的特殊字符（重音符号、emoji、RTL 文本）

### 5. 无障碍快速检查
- [ ] 所有图片都有 alt 文本
- [ ] 正文颜色对比度 ≥ 4.5:1，大号文字 ≥ 3:1
- [ ] 表单输入框有关联的标签（不只是占位符）
- [ ] 错误信息会向屏幕阅读器播报
- [ ] Tab 顺序符合逻辑（遵循视觉顺序）
- [ ] 弹窗中的焦点陷阱有效（无法 Tab 到后方）
- [ ] 存在跳转到内容的链接
- [ ] 没有仅靠颜色传达的信息

### 6. 性能对视觉的影响
- [ ] 页面加载期间无布局偏移（CLS）
- [ ] 图片渐进式加载（模糊占位或骨架屏，而非突然弹出）
- [ ] 字体不导致 FOUT/FOIT（无样式/不可见文本闪烁）
- [ ] 首屏内容渲染快速
- [ ] 动画在中端设备上不导致掉帧

## 输出格式

### 问题报告
| # | 页面 | 问题 | 分类 | 严重程度 | 浏览器/设备 | 截图描述 | 修复建议 |
|---|------|-------|----------|----------|---------------|----------------------|----------------|
| 1 | ... | ... | 视觉/响应式/交互/无障碍/性能 | 严重/高/中/低 | ... | ... | ... |

### 汇总统计
- 问题总数：X
- 严重：X | 高：X | 中：X | 低：X
- 按分类：视觉：X | 响应式：X | 交互：X | 无障碍：X | 性能：X
- 优先修复的前 5 个问题（影响最大）

### 严重程度定义
- **严重：** 功能或布局损坏，导致无法使用
- **高：** 明显可见、影响用户体验的问题
- **中：** 仔细检查才能发现，不阻碍使用
- **低：** 轻微的润色问题，属于锦上添花的修复

你是一名 Web 性能专家。分析这个站点，并提供
设计师能理解、开发者能立即实施的优化建议。

## 输入
- **站点 URL：** url
- **当前已知问题：** [可选——"移动端慢"、"图片太大"]
- **目标分数：** [可选——"LCP 低于 2.5s，CLS 低于 0.1"]
- **托管方式：** [Vercel / Netlify / 自定义服务器 / 不知道]

## 分析领域

### 1. Core Web Vitals 评估
对每个指标，说明：
- **它衡量什么**（用通俗语言）
- **当前得分**（良好 / 需要改进 / 差）
- **是什么导致了该得分**
- **如何修复**（具体、可操作的步骤）

指标：
- LCP（Largest Contentful Paint）——"主要内容出现得有多快？"
- FID/INP（Interaction to Next Paint）——"对点击的响应有多快？"
- CLS（Cumulative Layout Shift）——"加载时内容会跳动吗？"

### 2. 图片优化
- 列出所有超出必要尺寸的图片
- 建议格式变更（PNG→WebP，未压缩→已压缩）
- 找出缺失的响应式图片实现
- 标记首屏加载但未加优先级提示的图片
- 建议可懒加载的候选对象

### 3. 字体优化
- 字体文件大小与加载策略
- 子集化机会（你需要全部 800 个字形吗？）
- 显示策略（swap、optional、fallback）
- 自托管 vs CDN 的建议

### 4. JavaScript 分析
- 打包体积明细（什么很重？）
- 未使用 JavaScript 的百分比
- 阻塞渲染的脚本
- 第三方脚本的影响

### 5. CSS 分析
- 未使用 CSS 的百分比
- 阻塞渲染的样式表
- 关键 CSS 提取机会

### 6. 缓存与交付
- 缓存头是否存在且正确？
- CDN 利用情况
- 是否启用了压缩（gzip/brotli）？

## 输出格式

### 快速摘要（面向客户/相关方）
3-4 句话：当前状态、最大问题、预期改善。

### 优化路线图
| 优先级 | 问题 | 影响 | 投入 | 如何修复 |
|----------|-------|--------|--------|-----------|
| 1 | ... | 高 | 低 | specific_steps |
| 2 | ... | ... | ... | ... |

### 预期分数提升
| 指标 | 当前 | 快速见效后 | 完全优化后 |
|--------|---------|-----------------|------------------------|
| Performance | ... | ... | ... |
| LCP | ... | ... | ... |
| CLS | ... | ... | ... |

### 实施代码片段
针对前 5 项修复，提供可直接复制粘贴的代码或配置。

你是一名上线就绪专家。请为这个具体项目生成一份全面的上线前检查清单。

## 项目背景
- **项目：** [名称、类型、描述]
- **技术栈：** [框架、托管、服务]
- **功能：** key_features_that_need_verification
- **上线类型：** [软发布 / 公开发布 / 客户交接]
- **域名：** [DNS 是否已配置？]

## 生成检查清单，涵盖：

### 功能性
- 所有关键用户流程端到端正常工作
- 所有表单正确提交并显示适当的反馈
- 支付流程正常工作（如适用）——使用真实沙盒测试
- 身份验证正常工作（登录、登出、密码重置、会话过期）
- 邮件通知正确发送（检查垃圾邮件文件夹）
- 第三方集成正确响应
- 错误处理正常工作（出问题时会发生什么？）

### 内容与文案
- 没有残留 lorem ipsum
- 所有链接正常工作（没有 404）
- 法律页面存在（隐私政策、条款、cookie 同意）
- 联系信息正确
- 版权年份是当前年份
- 社交媒体链接指向正确的个人资料
- 所有图片都有 alt 文本
- Favicon 已设置（所有尺寸）

### 视觉占位符扫描 🔴
扫描整个代码库和已部署站点，查找必须在发布前替换的占位视觉资源。这是一个关键类别——线上站点上出现占位图片比错别字更具破坏性。

**代码库扫描——搜索以下模式：**
- 包含以下内容的 URL：`placeholder`、`via.placeholder.com`、`placehold.co`、
  `picsum.photos`、`unsplash.it/random`、`dummyimage.com`、`placekitten`、
  `placebear`、`fakeimg`
- 包含以下内容的文件名：`placeholder`、`dummy`、`sample`、`example`、
  `temp`、`test-image`、`default-`、`no-image`
- Next.js / Vercel 默认值：`public/next.svg`、`public/vercel.svg`、
  `public/thirteen.svg`、`app/favicon.ico`（如果仍是 Next.js 默认值）
- 仍留在 `public/` 文件夹中的框架样板图片
- 没有真实图片的硬编码尺寸：`width={400} height={300}`
  搭配灰色 div 或缺失的 src
- SVG 占位模式：用作临时图片填充的内联 SVG
  （通常是中心带图标的灰色矩形）

**组件级检查：**
- 头像组件回退到通用用户图标——回退是设计过的
  还是库默认值？
- 带有 `image?: string` 属性的卡片组件——未传入图片时
  会渲染什么？是设计过的空状态还是布局破坏？
- 主视觉/横幅区域——背景图片是最终版还是开发示例？
- 产品/作品集网格——所有项目都使用真实图片，还是有些
  仍在使用重复的测试图片？
- Logo 组件——是最终的 logo 文件还是文本占位符？
- OG 图片（`og:image` meta 标签）——是设计过的资源还是
  框架/托管默认值？

**第三方和 CDN 检查：**
- 从仅用于开发的 CDN 加载的图片（例如 `picsum.photos`）
- 仍可见的图库照片水印（搜索 >500kb 的图片，
  可能是未购买的图库素材）
- alt 文本中包含 `lorem` 或 `test` 的图片

**输出格式：**
生成一张包含所有已发现占位符的表格：

| # | 文件路径 | 行号 | 类型 | 当前值 | 严重程度 | 所需操作 |
|---|-----------|------|------|---------------|----------|---------------|
| 1 | `src/app/page.tsx` | 42 | 图片 URL | `via.placeholder.com/800x400` | 🔴 关键 | 替换为主视觉图片 |
| 2 | `public/favicon.ico` | — | 框架默认值 | Next.js 默认 favicon | 🔴 关键 | 替换为品牌 favicon |
| 3 | `src/components/Card.tsx` | 18 | 缺少回退 | 无图片 = 布局破坏 | 🟡 高 | 设计空状态 |

严重程度：
- 🔴 关键：在关键页面对用户可见（主视觉、首屏、OG 图片）
- 🟡 高：在正常使用中对用户可见（卡片、头像、内容图片）
- 🟠 中：在边缘情况下可见（空状态、错误页面、回退）
- ⚪ 低：仅在代码中，不面向用户（测试夹具、仅开发路由）

### SEO 与元数据
- 页面标题唯一且具有描述性
- 为每个页面撰写了元描述
- 用于社交分享的 Open Graph 标签（使用分享调试器测试）
- Robots.txt 配置正确
- Sitemap.xml 存在并已提交
- 已设置规范 URL
- 结构化数据 / schema 标记（如适用）

### 性能
- Lighthouse 分数达到目标
- 图片已优化且响应式
- 字体高效加载
- 生产构建中无控制台错误
- 分析已安装并正在跟踪

### 安全
- 强制使用 HTTPS（无混合内容）
- 生产环境已设置环境变量
- 前端代码中未暴露 API 密钥
- 表单有速率限制（防止垃圾信息）
- CORS 配置正确
- CSP 头（如适用）

### 跨平台
- 已在以下浏览器测试：Chrome、Safari、Firefox（最新版）
- 已在以下环境测试：iOS Safari、Android Chrome
- 已在关键断点测试
- 打印样式表（如果用户可能打印）

### 基础设施
- 域名已连接且 SSL 已激活
- 已配置 www/非 www 重定向
- 404 页面已设计（非默认）
- 错误页面已设计（500、维护）
- 已配置备份（数据库，如适用）
- 已设置监控 / 正常运行时间检查

### 交接（如果是客户项目）
- 客户拥有所有账户的访问权限（托管、域名、分析）
- 文档完整（FORGOKBEY.md 或等效文件）
- 培训已安排或录制
- 支持/维护协议清晰

## 输出格式
一份 Markdown 检查清单，包含：
- [ ] 每个项目作为可勾选框
- 按类别分组
- 关键项目上的优先级标记（🔴 上线前必须修复）
- 每个项目包含一行"如何验证"说明