clone-website

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Clone Website

网站克隆

You are about to reverse-engineer and rebuild $ARGUMENTS as a pixel-perfect clone.
This is not a two-phase process (inspect then build). You are a foreman walking the job site — as you inspect each section of the page, you write a detailed specification to a file, then hand that file to a specialist builder agent with everything they need. Extraction and construction happen in parallel, but extraction is meticulous and produces auditable artifacts.
你即将对**$ARGUMENTS**进行逆向工程,并构建一个像素级完美的克隆版本。
这并非分两阶段的流程(先检查再构建)。你是一名在施工现场巡查的工头——在检查页面的每个部分时,你会将详细规范写入文件,然后将该文件交给专业的构建Agent,其中包含他们完成工作所需的全部信息。提取和构建并行进行,但提取工作会非常细致,且会生成可审计的工件。

Pre-Flight

前期准备

  1. Chrome MCP is required. Test it immediately. If it's not available, stop and tell the user to enable it — this skill cannot work without browser automation.
  2. Read
    TARGET.md
    for URL and scope. If the URL doesn't match
    $ARGUMENTS
    , update it.
  3. Verify the base project builds:
    npm run build
    . The Next.js + shadcn/ui + Tailwind v4 scaffold should already be in place. If not, tell the user to set it up first.
  4. Create the output directories if they don't exist:
    docs/research/
    ,
    docs/research/components/
    ,
    docs/design-references/
    ,
    scripts/
    .
  1. 必须启用Chrome MCP。立即进行测试。如果无法使用,请停止操作并告知用户启用该功能——本技能无法脱离浏览器自动化运行。
  2. 阅读
    TARGET.md
    获取URL和范围。如果URL与
    $ARGUMENTS
    不匹配,请更新它。
  3. 验证基础项目可正常构建:执行
    npm run build
    。Next.js + shadcn/ui + Tailwind v4脚手架应已准备就绪。如果没有,请告知用户先完成搭建。
  4. 若输出目录不存在则创建:
    docs/research/
    docs/research/components/
    docs/design-references/
    scripts/

Guiding Principles

指导原则

These are the truths that separate a successful clone from a "close enough" mess. Internalize them — they should inform every decision you make.
这些原则是区分成功克隆与“差不多就行”的混乱版本的关键。请牢记它们——它们应指导你做出的每一个决策。

1. Completeness Beats Speed

1. 完整性优先于速度

Every builder agent must receive everything it needs to do its job perfectly: screenshot, exact CSS values, downloaded assets with local paths, real text content, component structure. If a builder has to guess anything — a color, a font size, a padding value — you have failed at extraction. Take the extra minute to extract one more property rather than shipping an incomplete brief.
每个构建Agent必须收到完成完美工作所需的全部信息:截图、精确的CSS值、带本地路径的已下载资源、真实文本内容、组件结构。如果构建Agent需要猜测任何内容——颜色、字体大小、内边距值——那么你的提取工作就是失败的。多花一分钟提取一个属性,也比交付不完整的说明要好。

2. Small Tasks, Perfect Results

2. 任务拆分,成果完美

When an agent gets "build the entire features section," it glosses over details — it approximates spacing, guesses font sizes, and produces something "close enough" but clearly wrong. When it gets a single focused component with exact CSS values, it nails it every time.
Look at each section and judge its complexity. A simple banner with a heading and a button? One agent. A complex section with 3 different card variants, each with unique hover states and internal layouts? One agent per card variant plus one for the section wrapper. When in doubt, make it smaller.
Complexity budget rule: If a builder prompt exceeds ~150 lines of spec content, the section is too complex for one agent. Break it into smaller pieces. This is a mechanical check — don't override it with "but it's all related."
当Agent收到“构建整个功能区”的任务时,它会忽略细节——它会近似间距、猜测字体大小,产出“差不多”但明显有误的结果。当它收到一个包含精确CSS值的单一聚焦组件任务时,每次都能完美完成。
查看每个部分并判断其复杂度。一个包含标题和按钮的简单横幅?分配一个Agent。一个包含3种不同卡片变体的复杂区域,每个变体都有独特的悬停状态和内部布局?每个卡片变体分配一个Agent,再为区域容器分配一个Agent。如有疑问,就拆分得更细。
复杂度预算规则:如果构建提示的规范内容超过约150行,说明该部分对于单个Agent来说过于复杂。将其拆分为更小的任务。这是一项机械检查——不要以“但它们都相关”为理由推翻它。

3. Real Content, Real Assets

3. 真实内容,真实资源

Extract the actual text, images, videos, and SVGs from the live site. This is a clone, not a mockup. Use
element.textContent
, download every
<img>
and
<video>
, extract inline
<svg>
elements as React components. The only time you generate content is when something is clearly server-generated and unique per session.
Layered assets matter. A section that looks like one image is often multiple layers — a background watercolor/gradient, a foreground UI mockup PNG, an overlay icon. Inspect each container's full DOM tree and enumerate ALL
<img>
elements and background images within it, including absolutely-positioned overlays. Missing an overlay image makes the clone look empty even if the background is correct.
从真实网站提取实际的文本、图片、视频和SVG。这是克隆,不是原型。使用
element.textContent
,下载所有
<img>
<video>
,将内联
<svg>
元素提取为React组件。只有当内容明显是服务器生成且每个会话唯一时,才需要生成内容。
分层资源至关重要。看似是一张图片的区域,通常由多个图层组成——背景水彩/渐变、前景UI原型PNG、覆盖图标。检查每个容器的完整DOM树,枚举其中所有
<img>
元素和背景图片,包括绝对定位的覆盖层。即使背景正确,缺少覆盖图片也会让克隆版本看起来空洞。

4. Foundation First

4. 先搭建基础

Nothing can be built until the foundation exists: global CSS with the target site's design tokens (colors, fonts, spacing), TypeScript types for the content structures, and global assets (fonts, favicons). This is sequential and non-negotiable. Everything after this can be parallel.
在基础架构完成之前,无法进行任何构建:包含目标网站设计令牌(颜色、字体、间距)的全局CSS、内容结构的TypeScript类型,以及全局资源(字体、网站图标)。这一步是顺序执行且不可协商的。在此之后的所有工作都可以并行进行。

5. Extract How It Looks AND How It Behaves

5. 提取外观与行为

A website is not a screenshot — it's a living thing. Elements move, change, appear, and disappear in response to scrolling, hovering, clicking, resizing, and time. If you only extract the static CSS of each element, your clone will look right in a screenshot but feel dead when someone actually uses it.
For every element, extract its appearance (exact computed CSS via
getComputedStyle()
) AND its behavior (what changes, what triggers the change, and how the transition happens). Not "it looks like 16px" — extract the actual computed value. Not "the nav changes on scroll" — document the exact trigger (scroll position, IntersectionObserver threshold, viewport intersection), the before and after states (both sets of CSS values), and the transition (duration, easing, CSS transition vs. JS-driven vs. CSS
animation-timeline
).
Examples of behaviors to watch for — these are illustrative, not exhaustive. The page may do things not on this list, and you must catch those too:
  • A navbar that shrinks, changes background, or gains a shadow after scrolling past a threshold
  • Elements that animate into view when they enter the viewport (fade-up, slide-in, stagger delays)
  • Sections that snap into place on scroll (
    scroll-snap-type
    )
  • Parallax layers that move at different rates than the scroll
  • Hover states that animate (not just change — the transition duration and easing matter)
  • Dropdowns, modals, accordions with enter/exit animations
  • Scroll-driven progress indicators or opacity transitions
  • Auto-playing carousels or cycling content
  • Dark-to-light (or any theme) transitions between page sections
  • Tabbed/pill content that cycles — buttons that switch visible card sets with transitions
  • Scroll-driven tab/accordion switching — sidebars where the active item auto-changes as content scrolls past (IntersectionObserver, NOT click handlers)
  • Smooth scroll libraries (Lenis, Locomotive Scroll) — check for
    .lenis
    class or scroll container wrappers
网站不是截图——它是一个动态的事物。元素会响应滚动、悬停、点击、调整大小和时间而移动、变化、出现或消失。如果你只提取每个元素的静态CSS,你的克隆版本在截图中看起来没问题,但当用户实际使用时会显得呆板。
对于每个元素,提取其外观(通过
getComputedStyle()
获取的精确计算后CSS值)和行为(哪些内容会变化、触发变化的条件以及过渡方式)。不要只说“看起来是16px”——提取实际的计算值。不要只说“导航栏在滚动时变化”——记录精确的触发条件(滚动位置、IntersectionObserver阈值、视口交叉情况)、变化前后的状态(两组CSS值)以及过渡效果(时长、缓动函数、CSS过渡 vs JS驱动 vs CSS
animation-timeline
)。
需要关注的行为示例——这些是说明性的,而非详尽无遗。页面可能会有不在此列表中的行为,你必须也要捕捉到:
  • 滚动超过阈值后,导航栏缩小、更改背景或添加阴影
  • 元素进入视口时动画显示(淡入上移、滑入、交错延迟)
  • 滚动时会对齐到固定位置的区域(
    scroll-snap-type
  • 视差图层以与滚动不同的速率移动
  • 带有动画效果的悬停状态(不仅仅是变化——过渡时长和缓动函数很重要)
  • 带有进入/退出动画的下拉菜单、模态框、折叠面板
  • 滚动驱动的进度指示器或透明度过渡
  • 自动播放的轮播或循环内容
  • 页面各部分之间的明暗(或任何主题)过渡
  • 循环切换的标签/胶囊内容——按钮切换可见卡片集并带有过渡效果
  • 滚动驱动的标签/折叠面板切换——侧边栏中,随着内容滚动,激活项自动更改(使用IntersectionObserver,而非点击处理程序)
  • 平滑滚动库(Lenis、Locomotive Scroll)——检查是否存在
    .lenis
    类或滚动容器包装器

6. Identify the Interaction Model Before Building

6. 构建前确定交互模型

This is the single most expensive mistake in cloning: building a click-based UI when the original is scroll-driven, or vice versa. Before writing any builder prompt for an interactive section, you must definitively answer: Is this section driven by clicks, scrolls, hovers, time, or some combination?
How to determine this:
  1. Don't click first. Scroll through the section slowly and observe if things change on their own as you scroll.
  2. If they do, it's scroll-driven. Extract the mechanism:
    IntersectionObserver
    ,
    scroll-snap
    ,
    position: sticky
    ,
    animation-timeline
    , or JS scroll listeners.
  3. If nothing changes on scroll, THEN click/hover to test for click/hover-driven interactivity.
  4. Document the interaction model explicitly in the component spec: "INTERACTION MODEL: scroll-driven with IntersectionObserver" or "INTERACTION MODEL: click-to-switch with opacity transition."
A section with a sticky sidebar and scrolling content panels is fundamentally different from a tabbed interface where clicking switches content. Getting this wrong means a complete rewrite, not a CSS tweak.
克隆中最昂贵的错误:原网站是滚动驱动的UI,你却构建了点击驱动的UI,反之亦然。在为交互式区域编写任何构建提示之前,你必须明确回答:该区域是由点击、滚动、悬停、时间还是它们的组合驱动的?
如何确定:
  1. 先不要点击。缓慢滚动整个区域,观察滚动时是否有内容自行变化。
  2. 如果有变化,说明是滚动驱动的。提取其机制:
    IntersectionObserver
    scroll-snap
    position: sticky
    animation-timeline
    或JS滚动监听器。
  3. 如果滚动时没有变化,再点击/悬停测试点击/悬停驱动的交互性。
  4. 在组件规范中明确记录交互模型:“交互模型:由IntersectionObserver驱动的滚动型”或“交互模型:点击切换,带有透明度过渡”。
带有粘性侧边栏和滚动内容面板的区域,与点击切换内容的标签界面有着本质区别。搞错这一点意味着需要完全重写,而不是调整CSS。

7. Extract Every State, Not Just the Default

7. 提取所有状态,而非仅默认状态

Many components have multiple visual states — a tab bar shows different cards per tab, a header looks different at scroll position 0 vs 100, a card has hover effects. You must extract ALL states, not just whatever is visible on page load.
For tabbed/stateful content:
  • Click each tab/button via Chrome MCP
  • Extract the content, images, and card data for EACH state
  • Record which content belongs to which state
  • Note the transition animation between states (opacity, slide, fade, etc.)
For scroll-dependent elements:
  • Capture computed styles at scroll position 0 (initial state)
  • Scroll past the trigger threshold and capture computed styles again (scrolled state)
  • Diff the two to identify exactly which CSS properties change
  • Record the transition CSS (duration, easing, properties)
  • Record the exact trigger threshold (scroll position in px, or viewport intersection ratio)
许多组件有多种视觉状态——标签栏每个标签对应不同的卡片,页眉在滚动位置0和100时外观不同,卡片有悬停效果。你必须提取所有状态,而不仅仅是页面加载时可见的状态。
对于标签/状态化内容:
  • 通过Chrome MCP点击每个标签/按钮
  • 提取每个状态的内容、图片和卡片数据
  • 记录哪些内容属于哪个状态
  • 记录状态之间的过渡动画(透明度、滑动、淡入等)
对于依赖滚动的元素:
  • 在滚动位置0(初始状态)捕获计算样式
  • 滚动超过触发阈值后,再次捕获计算样式(滚动后状态)
  • 对比两者,准确识别哪些CSS属性发生了变化
  • 记录过渡CSS(时长、缓动函数、属性)
  • 记录精确的触发阈值(滚动位置的像素值,或视口交叉比例)

8. Spec Files Are the Source of Truth

8. 规范文件是唯一依据

Every component gets a specification file in
docs/research/components/
BEFORE any builder is dispatched. This file is the contract between your extraction work and the builder agent. The builder receives the spec file contents inline in its prompt — the file also persists as an auditable artifact that the user (or you) can review if something looks wrong.
The spec file is not optional. It is not a nice-to-have. If you dispatch a builder without first writing a spec file, you are shipping incomplete instructions based on whatever you can remember from a Chrome MCP session, and the builder will guess to fill gaps.
在调度任何构建Agent之前,每个组件都要在
docs/research/components/
目录下创建一个规范文件。该文件是你的提取工作与构建Agent之间的契约。构建Agent的提示中会内联包含规范文件的内容——该文件还会作为可审计的工件保留,用户(或你)在发现问题时可以查阅。
规范文件不是可选的,也不是锦上添花的功能。如果在未编写规范文件的情况下调度构建Agent,你交付的就是不完整的指令,仅基于你从Chrome MCP会话中能记住的内容,而构建Agent会自行猜测填补空白。

9. Build Must Always Compile

9. 构建必须始终可编译

Every builder agent must verify
npx tsc --noEmit
passes before finishing. After merging worktrees, you verify
npm run build
passes. A broken build is never acceptable, even temporarily.
每个构建Agent在完成工作前必须验证
npx tsc --noEmit
执行通过。合并工作树后,你要验证
npm run build
执行通过。即使是临时的构建失败也是不可接受的。

Phase 1: Reconnaissance

阶段1:侦察

Navigate to the target URL with Chrome MCP.
使用Chrome MCP导航到目标URL。

Screenshots

截图

  • Take full-page screenshots at desktop (1440px) and mobile (390px) viewports
  • Save to
    docs/design-references/
    with descriptive names
  • These are your master reference — builders will receive section-specific crops/screenshots later
  • 在桌面端(1440px)和移动端(390px)视口下拍摄整页截图
  • 保存到
    docs/design-references/
    目录,使用描述性名称
  • 这些是你的主参考——后续构建Agent会收到区域特定的裁剪/截图

Global Extraction

全局提取

Extract these from the page before doing anything else:
Fonts — Inspect
<link>
tags for Google Fonts or self-hosted fonts. Check computed
font-family
on key elements (headings, body, code, labels). Document every family, weight, and style actually used. Configure them in
src/app/layout.tsx
using
next/font/google
or
next/font/local
.
Colors — Extract the site's color palette from computed styles across the page. Update
src/app/globals.css
with the target's actual colors in the
:root
and
.dark
CSS variable blocks. Map them to shadcn's token names (background, foreground, primary, muted, etc.) where they fit. Add custom properties for colors that don't map to shadcn tokens.
Favicons & Meta — Download favicons, apple-touch-icons, OG images, webmanifest to
public/seo/
. Update
layout.tsx
metadata.
Global UI patterns — Identify any site-wide CSS or JS: custom scrollbar hiding, scroll-snap on the page container, global keyframe animations, backdrop filters, gradients used as overlays, smooth scroll libraries (Lenis, Locomotive Scroll — check for
.lenis
,
.locomotive-scroll
, or custom scroll container classes). Add these to
globals.css
and note any libraries that need to be installed.
在进行其他操作之前,先从页面中提取以下内容:
字体——检查
<link>
标签中的Google Fonts或自托管字体。查看关键元素(标题、正文、代码、标签)的计算后
font-family
。记录实际使用的每个字体族、字重和样式。使用
next/font/google
next/font/local
src/app/layout.tsx
中配置它们。
颜色——从页面各处的计算样式中提取网站的调色板。更新
src/app/globals.css
,在
:root
.dark
CSS变量块中添加目标网站的实际颜色。将它们映射到shadcn的令牌名称(background、foreground、primary、muted等)。为不匹配shadcn令牌的颜色添加自定义属性。
网站图标与元数据——下载网站图标、apple-touch-icons、OG图片、webmanifest到
public/seo/
目录。更新
layout.tsx
中的元数据。
全局UI模式——识别任何全站范围的CSS或JS:自定义滚动条隐藏、页面容器的scroll-snap、全局关键帧动画、背景过滤器、用作覆盖层的渐变、平滑滚动库(Lenis、Locomotive Scroll——检查是否有
.lenis
.locomotive-scroll
类或自定义滚动容器类)。将这些添加到
globals.css
中,并记录需要安装的任何库。

Mandatory Interaction Sweep

强制交互扫描

This is a dedicated pass AFTER screenshots and BEFORE anything else. Its purpose is to discover every behavior on the page — many of which are invisible in a static screenshot.
Scroll sweep: Scroll the page slowly from top to bottom via Chrome MCP. At each section, pause and observe:
  • Does the header change appearance? Record the scroll position where it triggers.
  • Do elements animate into view? Record which ones and the animation type.
  • Does a sidebar or tab indicator auto-switch as you scroll? Record the mechanism.
  • Are there scroll-snap points? Record which containers.
  • Is there a smooth scroll library active? Check for non-native scroll behavior.
Click sweep: Click every element that looks interactive:
  • Every button, tab, pill, link, card
  • Record what happens: does content change? Does a modal open? Does a dropdown appear?
  • For tabs/pills: click EACH ONE and record the content that appears for each state
Hover sweep: Hover over every element that might have hover states:
  • Buttons, cards, links, images, nav items
  • Record what changes: color, scale, shadow, underline, opacity
Responsive sweep: Test at 3 viewport widths via Chrome MCP:
  • Desktop: 1440px
  • Tablet: 768px
  • Mobile: 390px
  • At each width, note which sections change layout (column → stack, sidebar disappears, etc.) and at approximately which breakpoint the change occurs.
Save all findings to
docs/research/BEHAVIORS.md
. This is your behavior bible — reference it when writing every component spec.
这是在截图之后、其他操作之前的专门步骤。其目的是发现页面上的所有行为——其中许多在静态截图中是不可见的。
滚动扫描:通过Chrome MCP缓慢地从上到下滚动页面。在每个区域暂停并观察:
  • 页眉是否改变外观?记录触发时的滚动位置。
  • 元素是否会动画显示到视图中?记录哪些元素以及动画类型。
  • 侧边栏或标签指示器是否会随着滚动自动切换?记录其机制。
  • 是否有滚动对齐点?记录哪些容器。
  • 是否有平滑滚动库在运行?检查是否有非原生滚动行为。
点击扫描:点击所有看起来可交互的元素:
  • 每个按钮、标签、胶囊、链接、卡片
  • 记录发生的变化:内容是否改变?模态框是否打开?下拉菜单是否出现?
  • 对于标签/胶囊:点击每一个并记录每个状态下显示的内容
悬停扫描:悬停在所有可能有悬停状态的元素上:
  • 按钮、卡片、链接、图片、导航项
  • 记录变化:颜色、缩放、阴影、下划线、透明度
响应式扫描:通过Chrome MCP在3种视口宽度下测试:
  • 桌面端:1440px
  • 平板端:768px
  • 移动端:390px
  • 在每个宽度下,记录哪些区域改变了布局(列→堆叠、侧边栏消失等),以及布局变化发生的大致断点。
将所有发现保存到
docs/research/BEHAVIORS.md
。这是你的行为指南——编写每个组件规范时都要参考它。

Page Topology

页面拓扑

Map out every distinct section of the page from top to bottom. Give each a working name. Document:
  • Their visual order
  • Which are fixed/sticky overlays vs. flow content
  • The overall page layout (scroll container, column structure, z-index layers)
  • Dependencies between sections (e.g., a floating nav that overlays everything)
  • The interaction model of each section (static, click-driven, scroll-driven, time-driven)
Save this as
docs/research/PAGE_TOPOLOGY.md
— it becomes your assembly blueprint.
从上到下映射页面的每个不同区域。为每个区域起一个工作名称。记录:
  • 它们的视觉顺序
  • 哪些是固定/粘性覆盖层,哪些是流式内容
  • 整体页面布局(滚动容器、列结构、z-index图层)
  • 区域之间的依赖关系(例如,覆盖所有内容的浮动导航)
  • 每个区域的交互模型(静态、点击驱动、滚动驱动、时间驱动)
将其保存为
docs/research/PAGE_TOPOLOGY.md
——这将成为你的组装蓝图。

Phase 2: Foundation Build

阶段2:基础构建

This is sequential. Do it yourself (not delegated to an agent) since it touches many files:
  1. Update fonts in
    layout.tsx
    to match the target site's actual fonts
  2. Update globals.css with the target's color tokens, spacing values, keyframe animations, utility classes, and any global scroll behaviors (Lenis, smooth scroll CSS, scroll-snap on body)
  3. Create TypeScript interfaces in
    src/types/
    for the content structures you've observed
  4. Extract SVG icons — find all inline
    <svg>
    elements on the page, deduplicate them, and save as named React components in
    src/components/icons.tsx
    . Name them by visual function (e.g.,
    SearchIcon
    ,
    ArrowRightIcon
    ,
    LogoIcon
    ).
  5. Download global assets — write and run a Node.js script (
    scripts/download-assets.mjs
    ) that downloads all images, videos, and other binary assets from the page to
    public/
    . Preserve meaningful directory structure.
  6. Verify:
    npm run build
    passes
这一步是顺序执行的。由你自己完成(不委托给Agent),因为它会涉及多个文件:
  1. layout.tsx
    更新字体以匹配目标网站的实际字体
  2. globals.css
    更新全局样式,添加目标网站的颜色令牌、间距值、关键帧动画、工具类,以及任何全局滚动行为(Lenis、平滑滚动CSS、body上的scroll-snap)
  3. src/types/
    创建TypeScript接口,对应你观察到的内容结构
  4. 提取SVG图标——找到页面上所有内联
    <svg>
    元素,去重后保存为
    src/components/icons.tsx
    中的命名React组件。根据视觉功能命名(例如
    SearchIcon
    ArrowRightIcon
    LogoIcon
    )。
  5. 下载全局资源——编写并运行Node.js脚本(
    scripts/download-assets.mjs
    ),将页面上的所有图片、视频和其他二进制资源下载到
    public/
    目录。保留有意义的目录结构。
  6. 验证:
    npm run build
    执行通过

Asset Discovery Script Pattern

资源发现脚本模板

Use Chrome MCP to enumerate all assets on the page:
javascript
// Run this via Chrome MCP to discover all assets
JSON.stringify({
  images: [...document.querySelectorAll('img')].map(img => ({
    src: img.src || img.currentSrc,
    alt: img.alt,
    width: img.naturalWidth,
    height: img.naturalHeight,
    // Include parent info to detect layered compositions
    parentClasses: img.parentElement?.className,
    siblings: img.parentElement ? [...img.parentElement.querySelectorAll('img')].length : 0,
    position: getComputedStyle(img).position,
    zIndex: getComputedStyle(img).zIndex
  })),
  videos: [...document.querySelectorAll('video')].map(v => ({
    src: v.src || v.querySelector('source')?.src,
    poster: v.poster,
    autoplay: v.autoplay,
    loop: v.loop,
    muted: v.muted
  })),
  backgroundImages: [...document.querySelectorAll('*')].filter(el => {
    const bg = getComputedStyle(el).backgroundImage;
    return bg && bg !== 'none';
  }).map(el => ({
    url: getComputedStyle(el).backgroundImage,
    element: el.tagName + '.' + el.className?.split(' ')[0]
  })),
  svgCount: document.querySelectorAll('svg').length,
  fonts: [...new Set([...document.querySelectorAll('*')].slice(0, 200).map(el => getComputedStyle(el).fontFamily))],
  favicons: [...document.querySelectorAll('link[rel*="icon"]')].map(l => ({ href: l.href, sizes: l.sizes?.toString() }))
});
Then write a download script that fetches everything to
public/
. Use batched parallel downloads (4 at a time) with proper error handling.
使用Chrome MCP枚举页面上的所有资源:
javascript
// Run this via Chrome MCP to discover all assets
JSON.stringify({
  images: [...document.querySelectorAll('img')].map(img => ({
    src: img.src || img.currentSrc,
    alt: img.alt,
    width: img.naturalWidth,
    height: img.naturalHeight,
    // Include parent info to detect layered compositions
    parentClasses: img.parentElement?.className,
    siblings: img.parentElement ? [...img.parentElement.querySelectorAll('img')].length : 0,
    position: getComputedStyle(img).position,
    zIndex: getComputedStyle(img).zIndex
  })),
  videos: [...document.querySelectorAll('video')].map(v => ({
    src: v.src || v.querySelector('source')?.src,
    poster: v.poster,
    autoplay: v.autoplay,
    loop: v.loop,
    muted: v.muted
  })),
  backgroundImages: [...document.querySelectorAll('*')].filter(el => {
    const bg = getComputedStyle(el).backgroundImage;
    return bg && bg !== 'none';
  }).map(el => ({
    url: getComputedStyle(el).backgroundImage,
    element: el.tagName + '.' + el.className?.split(' ')[0]
  })),
  svgCount: document.querySelectorAll('svg').length,
  fonts: [...new Set([...document.querySelectorAll('*')].slice(0, 200).map(el => getComputedStyle(el).fontFamily))],
  favicons: [...document.querySelectorAll('link[rel*="icon"]')].map(l => ({ href: l.href, sizes: l.sizes?.toString() }))
});
然后编写下载脚本,将所有资源获取到
public/
目录。使用批量并行下载(每次4个)并添加适当的错误处理。

Phase 3: Component Specification & Dispatch

阶段3:组件规范与调度

This is the core loop. For each section in your page topology (top to bottom), you do THREE things: extract, write the spec file, then dispatch builders.
这是核心循环。对于页面拓扑中的每个区域(从上到下),你需要完成三件事:提取编写规范文件,然后调度构建Agent

Step 1: Extract

步骤1:提取

For each section, use Chrome MCP to extract everything:
  1. Screenshot the section in isolation (scroll to it, screenshot the viewport). Save to
    docs/design-references/
    .
  2. Extract CSS for every element in the section. Use the extraction script below — don't hand-measure individual properties. Run it once per component container and capture the full output:
javascript
// Per-component extraction — run via Chrome MCP
// Replace SELECTOR with the actual CSS selector for the component
(function(selector) {
  const el = document.querySelector(selector);
  if (!el) return JSON.stringify({ error: 'Element not found: ' + selector });
  const props = [
    'fontSize','fontWeight','fontFamily','lineHeight','letterSpacing','color',
    'textTransform','textDecoration','backgroundColor','background',
    'padding','paddingTop','paddingRight','paddingBottom','paddingLeft',
    'margin','marginTop','marginRight','marginBottom','marginLeft',
    'width','height','maxWidth','minWidth','maxHeight','minHeight',
    'display','flexDirection','justifyContent','alignItems','gap',
    'gridTemplateColumns','gridTemplateRows',
    'borderRadius','border','borderTop','borderBottom','borderLeft','borderRight',
    'boxShadow','overflow','overflowX','overflowY',
    'position','top','right','bottom','left','zIndex',
    'opacity','transform','transition','cursor',
    'objectFit','objectPosition','mixBlendMode','filter','backdropFilter',
    'whiteSpace','textOverflow','WebkitLineClamp'
  ];
  function extractStyles(element) {
    const cs = getComputedStyle(element);
    const styles = {};
    props.forEach(p => { const v = cs[p]; if (v && v !== 'none' && v !== 'normal' && v !== 'auto' && v !== '0px' && v !== 'rgba(0, 0, 0, 0)') styles[p] = v; });
    return styles;
  }
  function walk(element, depth) {
    if (depth > 4) return null;
    const children = [...element.children];
    return {
      tag: element.tagName.toLowerCase(),
      classes: element.className?.toString().split(' ').slice(0, 5).join(' '),
      text: element.childNodes.length === 1 && element.childNodes[0].nodeType === 3 ? element.textContent.trim().slice(0, 200) : null,
      styles: extractStyles(element),
      images: element.tagName === 'IMG' ? { src: element.src, alt: element.alt, naturalWidth: element.naturalWidth, naturalHeight: element.naturalHeight } : null,
      childCount: children.length,
      children: children.slice(0, 20).map(c => walk(c, depth + 1)).filter(Boolean)
    };
  }
  return JSON.stringify(walk(el, 0), null, 2);
})('SELECTOR');
  1. Extract multi-state styles — for any element with multiple states (scroll-triggered, hover, active tab), capture BOTH states:
javascript
// State A: capture styles at current state (e.g., scroll position 0)
// Then trigger the state change (scroll, click, hover via Chrome MCP)
// State B: re-run the extraction script on the same element
// The diff between A and B IS the behavior specification
Record the diff explicitly: "Property X changes from VALUE_A to VALUE_B, triggered by TRIGGER, with transition: TRANSITION_CSS."
  1. Extract real content — all text, alt attributes, aria labels, placeholder text. Use
    element.textContent
    for each text node. For tabbed/stateful content, click each tab and extract content per state.
  2. Identify assets this section uses — which downloaded images/videos from
    public/
    , which icon components from
    icons.tsx
    . Check for layered images (multiple
    <img>
    or background-images stacked in the same container).
  3. Assess complexity — how many distinct sub-components does this section contain? A distinct sub-component is an element with its own unique styling, structure, and behavior (e.g., a card, a nav item, a search panel).
对于每个区域,使用Chrome MCP提取所有内容:
  1. 截图该区域的独立视图(滚动到该区域,截取视口)。保存到
    docs/design-references/
    目录。
  2. 提取CSS区域中的每个元素。使用下面的提取脚本——不要手动测量单个属性。对每个组件容器运行一次,捕获完整输出:
javascript
// Per-component extraction — run via Chrome MCP
// Replace SELECTOR with the actual CSS selector for the component
(function(selector) {
  const el = document.querySelector(selector);
  if (!el) return JSON.stringify({ error: 'Element not found: ' + selector });
  const props = [
    'fontSize','fontWeight','fontFamily','lineHeight','letterSpacing','color',
    'textTransform','textDecoration','backgroundColor','background',
    'padding','paddingTop','paddingRight','paddingBottom','paddingLeft',
    'margin','marginTop','marginRight','marginBottom','marginLeft',
    'width','height','maxWidth','minWidth','maxHeight','minHeight',
    'display','flexDirection','justifyContent','alignItems','gap',
    'gridTemplateColumns','gridTemplateRows',
    'borderRadius','border','borderTop','borderBottom','borderLeft','borderRight',
    'boxShadow','overflow','overflowX','overflowY',
    'position','top','right','bottom','left','zIndex',
    'opacity','transform','transition','cursor',
    'objectFit','objectPosition','mixBlendMode','filter','backdropFilter',
    'whiteSpace','textOverflow','WebkitLineClamp'
  ];
  function extractStyles(element) {
    const cs = getComputedStyle(element);
    const styles = {};
    props.forEach(p => { const v = cs[p]; if (v && v !== 'none' && v !== 'normal' && v !== 'auto' && v !== '0px' && v !== 'rgba(0, 0, 0, 0)') styles[p] = v; });
    return styles;
  }
  function walk(element, depth) {
    if (depth > 4) return null;
    const children = [...element.children];
    return {
      tag: element.tagName.toLowerCase(),
      classes: element.className?.toString().split(' ').slice(0, 5).join(' '),
      text: element.childNodes.length === 1 && element.childNodes[0].nodeType === 3 ? element.textContent.trim().slice(0, 200) : null,
      styles: extractStyles(element),
      images: element.tagName === 'IMG' ? { src: element.src, alt: element.alt, naturalWidth: element.naturalWidth, naturalHeight: element.naturalHeight } : null,
      childCount: children.length,
      children: children.slice(0, 20).map(c => walk(c, depth + 1)).filter(Boolean)
    };
  }
  return JSON.stringify(walk(el, 0), null, 2);
})('SELECTOR');
  1. 提取多状态样式——对于任何具有多种状态(滚动触发、悬停、激活标签)的元素,捕获两种状态
javascript
// State A: capture styles at current state (e.g., scroll position 0)
// Then trigger the state change (scroll, click, hover via Chrome MCP)
// State B: re-run the extraction script on the same element
// The diff between A and B IS the behavior specification
明确记录差异:“属性X从VALUE_A变为VALUE_B,触发条件为TRIGGER,过渡效果:TRANSITION_CSS。”
  1. 提取真实内容——所有文本、alt属性、aria标签、占位符文本。对每个文本节点使用
    element.textContent
    。对于标签/状态化内容,点击每个标签并提取每个状态的内容
  2. 识别该区域使用的资源——
    public/
    目录中已下载的哪些图片/视频,
    icons.tsx
    中的哪些图标组件。检查是否有分层图片(同一容器中堆叠的多个
    <img>
    或背景图片)。
  3. 评估复杂度——该区域包含多少个不同的子组件?不同的子组件是指具有独特样式、结构和行为的元素(例如卡片、导航项、搜索面板)。

Step 2: Write the Component Spec File

步骤2:编写组件规范文件

For each section (or sub-component, if you're breaking it up), create a spec file in
docs/research/components/
. This is NOT optional — every builder must have a corresponding spec file.
File path:
docs/research/components/<component-name>.spec.md
Template:
markdown
undefined
对于每个区域(或子组件,如果拆分的话),在
docs/research/components/
目录中创建一个规范文件。这不是可选的——每个构建Agent必须有对应的规范文件。
文件路径
docs/research/components/<component-name>.spec.md
模板
markdown
undefined

<ComponentName> Specification

<ComponentName> 规范

Overview

概述

  • Target file:
    src/components/<ComponentName>.tsx
  • Screenshot:
    docs/design-references/<screenshot-name>.png
  • Interaction model: <static | click-driven | scroll-driven | time-driven>
  • 目标文件
    src/components/<ComponentName>.tsx
  • 截图
    docs/design-references/<screenshot-name>.png
  • 交互模型:<静态 | 点击驱动 | 滚动驱动 | 时间驱动>

DOM Structure

DOM结构

<Describe the element hierarchy — what contains what>
<描述元素层级关系——包含关系>

Computed Styles (exact values from getComputedStyle)

计算后样式(来自getComputedStyle的精确值)

Container

容器

  • display: ...
  • padding: ...
  • maxWidth: ...
  • (every relevant property with exact values)
  • display: ...
  • padding: ...
  • maxWidth: ...
  • (所有相关属性及精确值)

<Child element 1>

<子元素1>

  • fontSize: ...
  • color: ...
  • (every relevant property)
  • fontSize: ...
  • color: ...
  • (所有相关属性)

<Child element N>

<子元素N>

...
...

States & Behaviors

状态与行为

<Behavior name, e.g., "Scroll-triggered floating mode">

<行为名称,例如“滚动触发的浮动模式”>

  • Trigger: <exact mechanism — scroll position 50px, IntersectionObserver rootMargin "-30% 0px", click on .tab-button, hover>
  • State A (before): maxWidth: 100vw, boxShadow: none, borderRadius: 0
  • State B (after): maxWidth: 1200px, boxShadow: 0 4px 20px rgba(0,0,0,0.1), borderRadius: 16px
  • Transition: transition: all 0.3s ease
  • Implementation approach: <CSS transition + scroll listener | IntersectionObserver | CSS animation-timeline | etc.>
  • 触发条件:<精确机制——滚动位置50px,IntersectionObserver rootMargin "-30% 0px",点击.tab-button,悬停>
  • 状态A(变化前):maxWidth: 100vw, boxShadow: none, borderRadius: 0
  • 状态B(变化后):maxWidth: 1200px, boxShadow: 0 4px 20px rgba(0,0,0,0.1), borderRadius: 16px
  • 过渡效果:transition: all 0.3s ease
  • 实现方式:<CSS过渡 + 滚动监听器 | IntersectionObserver | CSS animation-timeline | 等>

Hover states

悬停状态

  • <Element>: <property>: <before><after>, transition: <value>
  • <元素>:<属性>: <变化前> → <变化后>,过渡效果:<值>

Per-State Content (if applicable)

分状态内容(如适用)

State: "Featured"

状态:“精选”

  • Title: "..."
  • Subtitle: "..."
  • Cards: [{ title, description, image, link }, ...]
  • 标题:“...”
  • 副标题:“...”
  • 卡片:[{ title, description, image, link }, ...]

State: "Productivity"

状态:“生产力”

  • Title: "..."
  • Cards: [...]
  • 标题:“...”
  • 卡片:[...]

Assets

资源

  • Background image:
    public/images/<file>.webp
  • Overlay image:
    public/images/<file>.png
  • Icons used: <ArrowIcon>, <SearchIcon> from icons.tsx
  • 背景图片:
    public/images/<file>.webp
  • 覆盖图片:
    public/images/<file>.png
  • 使用的图标:<ArrowIcon>, <SearchIcon>(来自icons.tsx)

Text Content (verbatim)

文本内容(原文)

<All text content, copy-pasted from the live site>
<所有文本内容,从真实网站复制粘贴>

Responsive Behavior

响应式行为

  • Desktop (1440px): <layout description>
  • Tablet (768px): <what changes — e.g., "maintains 2-column, gap reduces to 16px">
  • Mobile (390px): <what changes — e.g., "stacks to single column, images full-width">
  • Breakpoint: layout switches at ~<N>px

Fill every section. If a section doesn't apply (e.g., no states for a static footer), write "N/A" — but think twice before marking States & Behaviors as N/A. Even a footer might have hover states on links.
  • 桌面端(1440px):<布局描述>
  • 平板端(768px):<变化内容——例如“保持2列,间距缩小至16px”>
  • 移动端(390px):<变化内容——例如“堆叠为单列,图片全屏宽度”>
  • 断点:布局在约<N>px处切换

填写每个部分。如果某个部分不适用(例如静态页脚没有状态),请填写“不适用”——但在将“状态与行为”标记为不适用之前,请三思。即使是页脚,链接也可能有悬停状态。

Step 3: Dispatch Builders

步骤3:调度构建Agent

Based on complexity, dispatch builder agent(s) in worktree(s):
Simple section (1-2 sub-components): One builder agent gets the entire section.
Complex section (3+ distinct sub-components): Break it up. One agent per sub-component, plus one agent for the section wrapper that imports them. Sub-component builders go first since the wrapper depends on them.
What every builder agent receives:
  • The full contents of its component spec file (inline in the prompt — don't say "go read the spec file")
  • Path to the section screenshot in
    docs/design-references/
  • Which shared components to import (
    icons.tsx
    ,
    cn()
    , shadcn primitives)
  • The target file path (e.g.,
    src/components/HeroSection.tsx
    )
  • Instruction to verify with
    npx tsc --noEmit
    before finishing
  • For responsive behavior: the specific breakpoint values and what changes
Don't wait. As soon as you've dispatched the builder(s) for one section, move to extracting the next section. Builders work in parallel in their worktrees while you continue extraction.
根据复杂度,在工作树中调度一个或多个构建Agent:
简单区域(1-2个子组件):一个构建Agent负责整个区域。
复杂区域(3个及以上不同子组件):拆分任务。每个子组件分配一个Agent,再为区域容器分配一个Agent,负责导入这些子组件。子组件的构建Agent先执行,因为容器依赖它们。
每个构建Agent收到的内容
  • 其组件规范文件的完整内容(内联在提示中——不要说“去读规范文件”)
  • docs/design-references/
    目录中该区域截图的路径
  • 需要导入的共享组件(
    icons.tsx
    cn()
    、shadcn基础组件)
  • 目标文件路径(例如
    src/components/HeroSection.tsx
  • 完成前需验证
    npx tsc --noEmit
    执行通过的指令
  • 响应式行为:具体的断点值和变化内容
不要等待。调度完一个区域的构建Agent后,立即开始提取下一个区域。当你继续提取时,Agent会在各自的工作树中并行工作。

Step 4: Merge

步骤4:合并

As builder agents complete their work:
  • Merge their worktree branches into main
  • You have full context on what each agent built, so resolve any conflicts intelligently
  • After each merge, verify the build still passes:
    npm run build
  • If a merge introduces type errors, fix them immediately
The extract → spec → dispatch → merge cycle continues until all sections are built.
当构建Agent完成工作后:
  • 将它们的工作树分支合并到主分支
  • 你了解每个Agent构建的内容,因此可以智能地解决任何冲突
  • 每次合并后,验证构建仍可通过:
    npm run build
  • 如果合并引入了类型错误,立即修复
提取→规范→调度→合并的循环会持续到所有区域都构建完成。

Phase 4: Page Assembly

阶段4:页面组装

After all sections are built and merged, wire everything together in
src/app/page.tsx
:
  • Import all section components
  • Implement the page-level layout from your topology doc (scroll containers, column structures, sticky positioning, z-index layering)
  • Connect real content to component props
  • Implement page-level behaviors: scroll snap, scroll-driven animations, dark-to-light transitions, intersection observers, smooth scroll (Lenis etc.)
  • Verify:
    npm run build
    passes clean
所有区域构建完成并合并后,在
src/app/page.tsx
中将它们连接起来:
  • 导入所有区域组件
  • 根据拓扑文档实现页面级布局(滚动容器、列结构、粘性定位、z-index图层)
  • 将真实内容连接到组件属性
  • 实现页面级行为:滚动对齐、滚动驱动动画、明暗过渡、交叉观察器、平滑滚动(Lenis等)
  • 验证:
    npm run build
    执行无错误

Phase 5: Visual QA Diff

阶段5:视觉QA对比

After assembly, do NOT declare the clone complete. Take side-by-side comparison screenshots:
  1. Open the original site and your clone side-by-side (or take screenshots at the same viewport widths)
  2. Compare section by section, top to bottom, at desktop (1440px)
  3. Compare again at mobile (390px)
  4. For each discrepancy found:
    • Check the component spec file — was the value extracted correctly?
    • If the spec was wrong: re-extract from Chrome MCP, update the spec, fix the component
    • If the spec was right but the builder got it wrong: fix the component to match the spec
  5. Test all interactive behaviors: scroll through the page, click every button/tab, hover over interactive elements
  6. Verify smooth scroll feels right, header transitions work, tab switching works, animations play
Only after this visual QA pass is the clone complete.
组装完成后,不要宣布克隆完成。进行并排对比截图:
  1. 并排打开原网站和你的克隆版本(或在相同视口宽度下截图)
  2. 从上到下逐区域对比,在桌面端(1440px)进行
  3. 在移动端(390px)再次对比
  4. 对于发现的每个差异:
    • 检查组件规范文件——值是否提取正确?
    • 如果规范错误:通过Chrome MCP重新提取,更新规范,修复组件
    • 如果规范正确但构建Agent出错:修复组件以匹配规范
  5. 测试所有交互行为:滚动页面、点击每个按钮/标签、悬停在交互式元素上
  6. 验证平滑滚动体验是否正确、页眉过渡是否正常、标签切换是否可用、动画是否播放
只有通过此视觉QA检查后,克隆才算完成。

Pre-Dispatch Checklist

调度前检查清单

Before dispatching ANY builder agent, verify you can check every box. If you can't, go back and extract more.
  • Spec file written to
    docs/research/components/<name>.spec.md
    with ALL sections filled
  • Every CSS value in the spec is from
    getComputedStyle()
    , not estimated
  • Interaction model is identified and documented (static / click / scroll / time)
  • For stateful components: every state's content and styles are captured
  • For scroll-driven components: trigger threshold, before/after styles, and transition are recorded
  • For hover states: before/after values and transition timing are recorded
  • All images in the section are identified (including overlays and layered compositions)
  • Responsive behavior is documented for at least desktop and mobile
  • Text content is verbatim from the site, not paraphrased
  • The builder prompt is under ~150 lines of spec; if over, the section needs to be split
在调度任何构建Agent之前,验证你可以勾选所有选项。如果不能,返回去提取更多内容。
  • 已在
    docs/research/components/<name>.spec.md
    中编写规范文件,且所有部分已填写
  • 规范中的每个CSS值都来自
    getComputedStyle()
    ,而非估算
  • 已识别并记录交互模型(静态/点击/滚动/时间)
  • 对于状态化组件:已捕获每个状态的内容和样式
  • 对于滚动驱动组件:已记录触发阈值、变化前后样式和过渡效果
  • 对于悬停状态:已记录变化前后的值和过渡时长
  • 已识别该区域的所有图片(包括覆盖层和分层组合)
  • 已记录至少桌面端和移动端的响应式行为
  • 文本内容与网站原文一致,未改写
  • 构建提示的规范内容少于约150行;如果超过,该区域需要拆分

What NOT to Do

禁止事项

These are lessons from previous failed clones — each one cost hours of rework:
  • Don't build click-based tabs when the original is scroll-driven (or vice versa). Determine the interaction model FIRST by scrolling before clicking. This is the #1 most expensive mistake — it requires a complete rewrite, not a CSS fix.
  • Don't extract only the default state. If there are tabs showing "Featured" on load, click Productivity, Creative, Lifestyle and extract each one's cards/content. If the header changes on scroll, capture styles at position 0 AND position 100+.
  • Don't miss overlay/layered images. A background watercolor + foreground UI mockup = 2 images. Check every container's DOM tree for multiple
    <img>
    elements and positioned overlays.
  • Don't build mockup components for content that's actually videos/animations. Check if a section uses
    <video>
    , Lottie, or canvas before building elaborate HTML mockups of what the video shows.
  • Don't approximate CSS classes. "It looks like
    text-lg
    " is wrong if the computed value is
    18px
    and
    text-lg
    is
    18px/28px
    but the actual line-height is
    24px
    . Extract exact values.
  • Don't build everything in one monolithic commit. The whole point of this pipeline is incremental progress with verified builds at each step.
  • Don't reference docs from builder prompts. Each builder gets the CSS spec inline in its prompt — never "see DESIGN_TOKENS.md for colors." The builder should have zero need to read external docs.
  • Don't skip asset extraction. Without real images, videos, and fonts, the clone will always look fake regardless of how perfect the CSS is.
  • Don't give a builder agent too much scope. If you're writing a builder prompt and it's getting long because the section is complex, that's a signal to break it into smaller tasks.
  • Don't bundle unrelated sections into one agent. A CTA section and a footer are different components with different designs — don't hand them both to one agent and hope for the best.
  • Don't skip responsive extraction. If you only inspect at desktop width, the clone will break at tablet and mobile. Test at 1440, 768, and 390 during extraction.
  • Don't forget smooth scroll libraries. Check for Lenis (
    .lenis
    class), Locomotive Scroll, or similar. Default browser scrolling feels noticeably different and the user will spot it immediately.
  • Don't dispatch builders without a spec file. The spec file forces exhaustive extraction and creates an auditable artifact. Skipping it means the builder gets whatever you can fit in a prompt from memory.
这些是从之前失败的克隆中吸取的教训——每一项都导致了数小时的返工:
  • 不要在原网站是滚动驱动时构建点击式标签(反之亦然)。先通过滚动确定交互模型,再点击。这是最昂贵的错误#1——需要完全重写,而不是CSS修复。
  • 不要只提取默认状态。如果加载时显示“精选”标签,点击“生产力”、“创意”、“生活方式”并提取每个标签的卡片/内容。如果页眉在滚动时变化,捕获滚动位置0和100+时的样式。
  • 不要遗漏覆盖/分层图片。背景水彩+前景UI原型=2张图片。检查每个容器的DOM树是否有多个
    <img>
    元素和定位覆盖层。
  • 不要为实际是视频/动画的内容构建原型组件。在构建视频内容的复杂HTML原型之前,检查该区域是否使用
    <video>
    、Lottie或canvas。
  • 不要近似CSS类。如果计算值是18px,而
    text-lg
    18px/28px
    但实际行高是24px,那么“看起来像
    text-lg
    ”是错误的。提取精确值。
  • 不要在一个整体提交中构建所有内容。此流程的意义在于逐步推进,且每一步都有经过验证的构建。
  • 不要在构建提示中引用文档。每个构建Agent的提示中都会内联包含CSS规范——永远不要说“查看DESIGN_TOKENS.md获取颜色”。构建Agent不应需要读取外部文档。
  • 不要跳过资源提取。没有真实的图片、视频和字体,无论CSS多么完美,克隆版本看起来都会很假。
  • 不要给构建Agent分配过大的范围。如果你在编写构建提示时,因为区域复杂而导致提示过长,这是一个信号,需要将其拆分为更小的任务。
  • 不要将不相关的区域分配给同一个Agent。CTA区域和页脚是不同的组件,设计也不同——不要将它们都交给一个Agent,指望它能做好。
  • 不要跳过响应式提取。如果你只在桌面端宽度检查,克隆版本在平板和移动端会崩溃。提取时在1440px、768px和390px下测试。
  • 不要忘记平滑滚动库。检查是否有Lenis(
    .lenis
    类)、Locomotive Scroll或类似库。默认浏览器滚动体验明显不同,用户会立即注意到。
  • 不要在没有规范文件的情况下调度构建Agent。规范文件强制进行详尽的提取,并创建可审计的工件。跳过这一步意味着构建Agent只能根据你记忆中的内容获取不完整的指令。

Completion

完成

When done, report:
  • Total sections built
  • Total components created
  • Total spec files written (should match components)
  • Total assets downloaded (images, videos, SVGs, fonts)
  • Build status (
    npm run build
    result)
  • Visual QA results (any remaining discrepancies)
  • Any known gaps or limitations
完成后,报告:
  • 构建的区域总数
  • 创建的组件总数
  • 编写的规范文件总数(应与组件数量匹配)
  • 下载的资源总数(图片、视频、SVG、字体)
  • 构建状态(
    npm run build
    的结果)
  • 视觉QA结果(任何剩余差异)
  • 任何已知的差距或限制