一句话克隆任意网站：AI Website Cloner 的原理拆解与上手全流程

本文由 辛梓煜@词元二号站（www.ciyuanerhao.com）撰写，转载请注明出处。

快速摘要

先给结论：现在你只要把一个网址丢给 AI 编程助手，跑一条 /clone-website 命令，几分钟后它就能把整站的字体、配色、间距、图片、动效连同交互逻辑一起"扒"下来，再用一套干净的 Next.js 代码重建出来。它的本质不是"截图让 AI 照着画"，而是一个开源模板 + 一个可复用的 Skill：AI 会真正打开浏览器，把页面从头到尾操作一遍，把每个区块的精确样式记进说明文件，然后分派好几个子任务并行搭建，最后拼装、跑一遍视觉比对再交付。 它连续冲上开源趋势榜，短时间内攒下两万六千多颗星，官方最推荐搭配 Claude Code 与 Opus 4.8，但十几种主流 AI 编程工具都能用。

这篇我不打算只停在"哇好厉害"，而是把它的目录结构、九条复刻铁律、五个执行阶段、安装到跑通的每一步，连带我自己踩过的坑，一次讲透。想看完整拆解，往下翻。

01 它到底解决了一个什么老大难问题

先说说我自己的经历。做前端这些年，最消耗耐心的活儿之一，就是"我在网上看到一个特别顺眼的站，想把那种质感搬到自己项目里"。

以前我的做法很原始：打开浏览器的开发者工具，一个元素一个元素地点，看它的颜色值是多少、字号是几像素、内边距怎么给的、阴影是几层。一个稍微讲究的落地页扒下来，半天就没了，而且抄回来的东西总差着一口气——因为静态样式我抄到了，可鼠标滑过按钮时的那点微妙过渡、往下滚时导航栏悄悄变窄这些"活"的部分，我根本来不及一个个记。

后来有了大模型，我换了个偷懒的姿势：直接截图，扔给 AI，让它照着复刻。结果更让人泄气。截图是死的，网站是活的。 AI 看着一张静态图，只能猜——它猜不出这个渐变到底是 #f5f5f7 还是 #f7f7f9，猜不出这块看似一张图的区域其实叠了三层（背景水彩 + 前景 UI 截图 + 一个浮在角上的图标），更猜不出那个侧边栏是点击切换还是随滚动自动切换。出来的东西"远看是它，近看全不是"。

这就是这个开源项目切进来的位置。它给自己的定位很干脆：一个可复用的模板，一个能装到各种 AI 编程助手上的 Skill。 你不需要自己写一长串提示词去哄 AI，把命令跑起来，它自带一整套"该怎么扒、扒哪些、扒完怎么重建"的方法论。

我把三种复刻方式摆在一起对比，差距一目了然：

它不是"更聪明地猜"，而是换了个根本思路：让 AI 别看图了，直接去操作真实页面。 这一步之差，决定了成败。

我第一次注意到它，是因为它连续冲上了开源趋势榜，短时间里就攒下两万六千多颗星，代码主体用 TypeScript 写成。星标数这东西不能全信，刷出来的项目也不少，但我扒开它的流程文件看完之后，得承认这波热度不虚——它不是那种"截图 + 一句提示词"的玩具，而是把复刻这件事当成一个正经工程问题来解，方法论扎实到几乎可以单独当教材看。我后面会带你一条一条过。

还有一个容易被忽略的细节：它自称"模板"，是有讲究的。它不是给你一个装好就能用的软件，而是给你一套可复用的起点——你基于它生成自己的项目，往里填自己的东西。这种"模板 + 方法论"的形态，比一个封闭的黑箱工具灵活得多，你甚至能打开它的流程文件，看它到底教 AI 怎么干活，看不顺眼还能自己改。对我这种喜欢刨根问底的人来说，这一点比"好用"更让我上头。

02 先把两个底层概念讲白：Skill 与浏览器自动化

很多人看这类工具，卡在"它凭什么这么强"上。其实拆到底，就靠两根柱子撑着。你把这两个概念吃透，后面所有流程都是水到渠成。

2.1 第一根柱子：什么是 Skill

Skill 你可以理解成给 AI 的一份"岗前手册"。

传统上我们让 AI 干专业活，是把一大坨说明一股脑塞进对话里。问题是这些说明会一直占着 AI 的"工作台"（也就是上下文窗口），塞得越多，AI 越容易分神，成本也越高。

Skill 换了个玩法，它靠一个叫**渐进式披露（progressive disclosure）**的设计。白话讲就是：别一上来把整本手册背下来，用到哪一章翻哪一章。

一个 Skill 说到底就是一个文件夹，里面有个核心文件 SKILL.md。它分三层，按需加载：

举个直观的例子：一个处理 PDF 的技能，开机时 AI 只知道"哦有个 PDF 技能，涉及 PDF 时用"，这一条才几十个 token；你真让它填个 PDF 表单，它才去读专门讲填表的那份文档，甚至直接跑一段写好的脚本来抽取表单字段——脚本跑起来又快又稳，还不占它的"工作台"。

这套机制的妙处在于：你可以给 AI 装几十上百个技能，平时几乎不占地方，用到才展开。 这也是为什么这类"一句话克隆"能做得这么克制——它把复刻网站的全部门道写进 SKILL.md，平时安安静静躺着，你喊 /clone-website，它才整套醒过来。

还有一点值得说：Skill 本质就是文本文件加脚本，并不死绑某一家模型。只要一个 AI 编程助手能读文件、能跑命令，理论上就能照着 SKILL.md 干活。这也解释了为什么这个克隆工具能同时兼容十几种编程助手。

2.2 第二根柱子：浏览器自动化

光有方法论还不够，AI 得有"手"去真正操作网页。这只手，就是浏览器自动化。

你可以把它想成：AI 不再是隔着玻璃看网页截图，而是拿到了一个真实浏览器的遥控器。它能命令浏览器打开网址、慢慢往下滚、把鼠标悬到某个按钮上、点开一个标签页、把窗口拉宽拉窄，还能在页面里执行一小段脚本，把某个元素当前真实生效的样式原封不动读出来。

这里的关键函数叫 getComputedStyle()——它返回的不是"看起来像 16 像素"，而是浏览器算完之后真正生效的那个值。字号、行高、字间距、内边距、阴影、圆角、过渡时长，全是确切数字，不用猜。

在这类工具里，这只"手"通过一套叫 MCP 的连接方式接进来（你就理解成 AI 和外部工具之间的一种标准插头）。它优先用 Chrome 的自动化通道，也支持 Playwright、Browserbase、Puppeteer 这些常见的浏览器控制方案。哪个可用就用哪个，都没有的话，它会停下来问你装了哪个、怎么连——因为没有这只手，整个技能根本转不起来。

这里顺带把 MCP 讲透一点，因为很多人被这三个字母唬住了。它全称是"模型上下文协议"，你完全可以忽略这个拗口的名字，只记一个类比：它是 AI 和外部工具之间的一种"标准插头"。 以前每接一个新工具，都得为它单独写一套对接；有了这个标准插头，浏览器控制、文件读写、各种服务，都能用同一种方式插到 AI 上。所以你会看到这个克隆工具能兼容 Chrome、Playwright、Browserbase、Puppeteer 好几种浏览器方案——因为它们都往同一个插座上插，谁在就用谁。

我再把"截图流为什么必然差"这件事掰得更细一点，因为它直接决定了这套方案为什么值。一张截图丢失了三类关键信息：第一，精确数值。截图里的颜色经过压缩、经过你屏幕的渲染，AI 只能反推个大概，#f5f5f7 和 #f6f6f8 在图上几乎没差别，但落到代码里就是两种质感。第二，时间维度。截图是某一瞬间的定格，可网页里大量的东西是"随时间/滚动/交互才发生"的——浮现动画、吸顶变形、轮播切换，静态图里它们根本不存在。第三，层次结构。截图把所有图层压成了一张平面图，AI 看不出这块是三层叠的还是一层平的。而让 AI 真去操作浏览器，这三类信息全都能拿回来：数值用 getComputedStyle 取确切值，时间维度靠"滚一滚点一点"亲自触发，层次结构靠遍历 DOM 树一层层看清。同样是"复刻"，信息完整度差了一个量级，成品自然天差地别。

两根柱子一合体，故事就顺了：Skill 提供"该怎么扒、扒完怎么建"的完整心法，浏览器自动化提供"真去把页面操作一遍、把精确数据取回来"的能力。 一个管脑子，一个管手。截图流之所以效果差，正是因为只有一张死图，既没脑子也没手。

顺便说个我挺喜欢的性质：因为 Skill 说到底就是文本 + 脚本，不死绑某一家模型，这套复刻方法论其实是可移植的。今天你用这个助手，明天换一个，只要它能读文件、能操作浏览器，同一套 SKILL.md 照样能指挥它干活。这也是它敢宣称兼容十几种编程助手的底气所在——它押的不是某个模型，而是一套通用的工作方式。

03 它的技术底座：为什么先给你搭好一个空架子

理解了两根柱子，再看它的工程设计就很好懂了。

这个项目最聪明的一点，是它没让 AI 从一张白纸开始建站，而是提前把一套现代前端脚手架铺好了。你拿到手就是一个能跑的空壳，AI 要做的只是往这个壳里"填正确的内容"。这样既省了 AI 反复配置环境的时间，也保证了产出的代码风格统一、规范。

它选的这套底座，是当下相当主流的组合：

• 框架：Next.js 16（App Router、React 19、TypeScript 严格模式）
• UI 组件：shadcn/ui（基于 Radix 无障碍组件 + Tailwind CSS v4）
• 图标：Lucide React 打底，后续会被从原站提取出来的 SVG 图标替换或补充

新手补一句：脚手架就是一个项目的"毛坯房"，水电管线（构建、类型检查、样式系统）都通好了，你直接进去装修就行，不用自己砌墙。

我把它的目录结构整理成一棵树，顺带标了每个目录是干嘛的：

src/
  app/                # Next.js 页面路由
  components/         # React 组件
    ui/               # shadcn/ui 基础组件
    icons.tsx         # 从原站提取的 SVG 图标
  lib/utils.ts        # cn() 等工具函数
  types/              # TypeScript 类型定义
  hooks/              # 自定义 React Hook
public/
  images/             # 从目标站下载下来的图片
  videos/             # 从目标站下载下来的视频
  seo/                # favicon、OG 图等
docs/
  research/           # 提取产物 & 组件规格说明
  design-references/  # 各区块的参考截图
scripts/              # 下载素材、同步配置的脚本
AGENTS.md             # 给各类 AI 助手的统一指令（唯一事实源）
CLAUDE.md             # Claude Code 的配置（引用 AGENTS.md）

这里我要特别点一下两个目录，它们是整个方案的灵魂：

• docs/research/ 存的是 AI 侦察阶段的产出——每个区块的详细规格说明文件。这些文件不是给人看着玩的，而是 AI 派活时递给"施工队"的施工图纸。
• docs/design-references/ 存的是各区块的参考截图，用来做最后的视觉比对。

你可能会问：为什么偏偏选这套技术栈？我琢磨了下，它选得挺有道理。用 Next.js 这类主流框架，是因为 AI 对它足够熟，产出的代码不容易跑偏；用带无障碍底子的组件库打底，是因为很多常见控件（下拉、弹窗、标签页）不用从零手搓，AI 只要往里填样式和内容；用工具类优先的样式方案，是因为它天然适合把"精确的间距、颜色"直接写成一个个确定的类，跟"提取精确值再落地"的整体思路严丝合缝。说白了，这套底座每一样都在为"让 AI 少出错、产出可维护"服务。 它没炫技，选的全是稳妥、AI 友好的成熟方案，这份克制我很欣赏。

一句话概括这套底座的设计哲学：把不确定的部分交给 AI 去填，把确定的工程规范提前焊死。 这样才能让"每一步都能编译通过"变成可能，而不是搭到一半整个塌掉。

04 九条复刻铁律：它把方法论写死进了流程

真正让我服气的，是它没有把"复刻"当成一句模糊的口号，而是提炼出九条几乎是用血泪换来的原则，写死在流程里。我按自己的理解把它们讲清楚，这九条你哪怕不用这个工具、单纯自己手动复刻网站，也照样用得上。

第一条，完整胜过速度。 每个"施工队"（子任务）拿到手的资料必须是齐全的：截图、精确到个位的 CSS 值、已经下载到本地的素材路径、真实的文案、组件结构。只要施工队还得靠猜——猜个颜色、猜个字号、猜个间距——那就说明前面的提取没做到位。宁可多花一分钟多抓一个属性，也不能递一份缺胳膊少腿的图纸出去。

第二条，小任务才有好结果。 这条特别反直觉但特别真。你给 AI 一个"把整个功能区搭出来"的大活，它就会偷懒——间距估一估、字号蒙一蒙，出来个"差不多但明显不对"的东西。可你给它一个单一的小组件，附上精确样式，它每次都能干得漂亮。所以这个工具有个很硬的机械规则：一份施工图纸的正文超过约 150 行，就说明这个区块太复杂，必须拆小。 不许用"可它们本来就是一起的呀"来抬杠。

第三条，真实内容配真实素材。 这是克隆，不是做样机。文案要用页面上真实的文字，图片、视频、内联 SVG 都要从原站抓下来。这里有个我以前常翻的车：一块看着像一张图的区域，往往是好几层叠出来的——底下一层背景渐变，上面压一张产品截图 PNG，角上再浮一个小图标。少抓一层浮层，克隆出来就会莫名其妙地"空一块"。

第四条，地基先行。 全局的东西必须先立起来：全站的设计变量（颜色、字体、间距）、内容结构的类型定义、字体和图标这些全局素材。这一步是串行的、不容跳过的，地基没打好，后面所有并行施工都是空中楼阁。

第五条，既要"长什么样"，也要"怎么动"。 前面反复强调过：网页是活的。每个元素都要同时记两样东西——外观（精确的计算样式）和行为（什么会变、被什么触发、怎么过渡）。不是"导航栏滚动时会变"，而是要写清楚：触发点在滚动到多少像素处、变之前是什么样、变之后是什么样、过渡用了多久、用的什么缓动曲线。

第六条，动手前先判定"交互模型"。 这是它反复强调的、代价最贵的一个坑：把一个"随滚动自动切换"的区块，错当成"点击切换的标签页"来做（或者反过来）。这俩看着像，底层机制天差地别，做错了不是改改 CSS 能补救的，得整块推倒重来。它给的判定口诀很实用：先别急着点，先慢慢往下滚，看东西会不会自己变；会变就是滚动驱动，不变再去点、去悬停试。

第七条，每个状态都要抓，不能只抓默认那一个。 一个标签栏在不同标签下显示不同卡片，一个头部在滚动前后长得不一样，一个卡片有悬停效果——这些"状态"都得逐一抓全。做法是：挨个点每个标签、把每种状态下的内容和样式都记下来；滚动相关的，就分别在"滚动前"和"滚动后"各取一次样式，两份一对比，差异就是行为规格。

第八条，规格文件是唯一的事实源。 每个组件在派活之前，都必须先写一份规格说明文件。这份文件是提取工作和施工队之间的合同。它不是可有可无的锦上添花——你要是不写就直接派活，那施工队拿到的就只是你脑子里能临时凑出来的一点残缺信息，剩下的它只能靠编。

第九条，构建必须始终能编译。 每个施工队收工前都要自检类型是否通过，各部分合并回主干后要保证整体能构建成功。哪怕是临时的、片刻的"编译不过"，也不接受。

我把这九条按"管什么"归了个类，方便你记：

为了让这九条不停留在口号，我举两个最容易出问题的具体场景，你体会下这套纪律的价值。

场景一，一个"看着像标签页"的功能区。 页面上有一排小圆按钮，下面跟着一组卡片。凭直觉你会当它是"点击切换"的标签——点第二个按钮，换一组卡片。但真相可能是：这排按钮压根不用点，你往下滚，它会随着内容滚动自动高亮、自动切换（背后是一种叫视口交叉观察的机制在盯着）。第六条铁律要求你"先滚后点"，就是专门防这个。要是判错了，你辛辛苦苦做出来的点击标签，用户一滚就露馅，只能整块重做。

场景二，一块"看着是一张图"的英雄区。 顶部大图看着就一张背景，你按第三条铁律去遍历它的 DOM，才发现里面叠了三样东西：一层柔和的背景渐变、一张悬浮的产品界面截图、右上角一个小小的装饰图标。少抓其中任何一层，克隆出来都会"缺一块、假一截"。这就是为什么它的素材枚举脚本连父级类名、定位方式、层级都要一并记下来——就是逼你把每一层都看见。

这九条我越用越觉得，它们真正约束的不是 AI，而是"想偷懒走捷径"的冲动。复刻这活儿，翻车几乎都翻在"我觉得差不多了"上，而这套铁律的每一条，都在跟"差不多"过不去。

05 全流程拆解：从一个网址到一个能跑的站

这一节是全文的重头戏。我把它的执行流程整个走一遍，你会发现它更像一个**"工头带着一群专业施工队"的项目管理流程**，而不是一段一次性生成代码的魔法。

先上一张整体流程图，心里有个地图：

flowchart TD
    A[预检 Pre-Flight<br/>确认浏览器自动化可用、校验网址、验证空壳能构建] --> B[阶段1 侦察<br/>截图 / 全局提取 / 强制交互扫描 / 页面拓扑]
    B --> C[阶段2 地基构建<br/>字体 颜色 类型 图标 素材，串行打底]
    C --> D[阶段3 组件规格化与派发<br/>提取 → 写规格 → 派施工队 → 合并]
    D -->|循环，直到所有区块建完| D
    D --> E[阶段4 页面组装<br/>把所有区块拼成完整页面]
    E --> F[阶段5 视觉 QA 比对<br/>原站与克隆并排比，逐处修差异]
    F --> G[交付：一个能跑、接近像素级还原的站]

下面逐个阶段讲。

5.1 阶段 0：预检（Pre-Flight）

正式开工前，它会先做几件事，缺一不可：

• 确认浏览器自动化能用。检测有没有可用的浏览器控制通道，优先用 Chrome 的，多个可选时按优先级挑，一个都没有就停下来问你。
• 解析并校验网址。支持一次丢进来好几个网址，会逐一规范化、验证可访问；有拼错的、打不开的，先让你改。
• 验证空壳能构建。先跑一遍构建命令，确认那套 Next.js 脚手架是好的，不然后面白忙。
• 建好产出目录。研究产物、组件规格、参考截图这些目录先准备好；多站点并行时，还会按域名给每个站单独开文件夹，避免互相串味。

5.2 阶段 1：侦察（Reconnaissance）

侦察是它最见功力的一步。目标只有一个：在动手之前，把这个页面从里到外摸透。

先拍全景照。 分别在桌面宽度（1440 像素）和手机宽度（390 像素）下，给整页拍长截图存好，作为后面比对的"标准答案"。

再做全局提取。 这一步把全站通用的东西先扒出来：

• 字体：查页面引了哪些字体、关键元素实际用的什么字重字号，全部记下来并配到项目里。
• 颜色：把全站的配色从计算样式里抠出来，写进全局样式变量，能对应上组件库标准命名的就对应，对不上的单独加自定义变量。
• 图标与元信息：favicon、苹果触摸图标、社交分享用的 OG 图、站点清单文件，统统下载归位。
• 全局 UI 套路：有没有自定义滚动条、整页滚动吸附、全局关键帧动画、背景滤镜、渐变遮罩，尤其要查有没有用平滑滚动库（这类库会让滚动手感和浏览器原生的明显不一样，漏了用户一眼就能察觉）。

接着是我最欣赏的一步——强制交互扫描。 很多行为在静态截图里是隐形的，必须真去操作一遍才能发现。它把这一步拆成三种"扫"：

除此之外还要做响应式扫描：分别在桌面 1440、平板 768、手机 390 三个宽度下看布局怎么变、大约在哪个断点变的。所有发现会汇总进一份"行为清单"，后面写每一份施工图纸时都要回来查它。

这一步千万别省。我见过太多复刻只在电脑宽度下扒，结果一到手机就整个散架——两栏没变成单栏、侧边栏该收起没收起、图片撑破了屏幕。原因很简单：你没在窄屏下看过，就不知道原站在那个宽度做了什么让步。它硬性要求在三个宽度下各走一遍、记清楚"在哪个宽度、哪个区块、发生了什么变化"，就是为了让克隆站在手机上也立得住。现在大半流量都在手机上，这一步的分量只会越来越重。同理，那个"平滑滚动库"的检查也别跳——原站要是用了平滑滚动，克隆站用浏览器默认滚动，手感会差出一截，用户滚两下就能觉出"哪里不对劲"，虽然说不上来。这些"说不清但能感觉到"的细节，恰恰是"神似"和"神还原"之间的那道坎。

最后画一张页面拓扑图。 从上到下把页面每一个区块列出来、起个名，标清楚谁是固定悬浮层、谁是正常流内容、层级怎么叠、区块之间有没有依赖，以及每个区块到底是静态、点击驱动、滚动驱动还是时间驱动。这张拓扑图，就是后面组装整页的施工蓝图。

5.3 阶段 2：地基构建（Foundation）

侦察完，先打地基。这一步是串行的、由工头亲自干（不外包给施工队），因为它牵动很多文件：更新字体、把全局颜色和动画写进样式、建好内容的类型定义、把页面里所有内联 SVG 去重后存成命名图标组件，最后写一段下载脚本，把整页的图片视频素材批量拉到本地。

关于"怎么发现页面上所有素材"，它的思路是先在浏览器里跑一段脚本，把图片、视频、背景图、图标、字体、favicon 全部枚举出来。核心逻辑简化后长这样，你感受下它有多细：

// 在浏览器里执行，枚举整页素材
JSON.stringify({
  images: [...document.querySelectorAll('img')].map(img => ({
    src: img.src || img.currentSrc,
    width: img.naturalWidth,
    height: img.naturalHeight,
    // 带上父级信息，用来识别"多层叠加"的组合
    parentClasses: img.parentElement?.className,
    position: getComputedStyle(img).position,
    zIndex: getComputedStyle(img).zIndex
  })),
  videos: [...document.querySelectorAll('video')].map(v => ({
    src: v.src || v.querySelector('source')?.src,
    autoplay: v.autoplay, loop: v.loop, muted: v.muted
  })),
  // 背景图也不放过
  backgroundImages: [...document.querySelectorAll('*')]
    .filter(el => getComputedStyle(el).backgroundImage !== 'none')
    .map(el => getComputedStyle(el).backgroundImage),
  svgCount: document.querySelectorAll('svg').length
});

注意它连父级类名、定位方式、层级都一并记下来，就是为了识别前面说过的"看似一张图、实则多层"的坑。枚举完再写下载脚本，分批并行拉取，带好错误处理。地基这步跑完，会再验证一次构建能过，才往下走。

5.4 阶段 3：组件规格化与派发（核心循环）

这是整套流程的心脏，一个不断重复的循环。对页面拓扑里的每一个区块，从上到下依次做三件事：提取 → 写规格 → 派施工队，再加一步合并。

先提取。 对每个区块，用浏览器把该抓的都抓齐：单独给这个区块截图；跑一段专门的脚本，把区块内每个元素的精确计算样式（字号、颜色、间距、圆角、阴影、定位、过渡等等，一长串属性）连同 DOM 结构一次性取出来，绝不靠手工目测；对有多种状态的元素，触发状态变化前后各取一次，两份一 diff，差异就是行为规格；文案逐字照抄，不许自己改写；把这个区块用到的素材和图标一一对上。

再写规格文件。 每个区块都要落一份规格说明到 docs/research/components/ 下，这就是那份"施工合同"。它有固定模板，我贴一份精简骨架给你看，直观感受它要求填多细：

# XxxSection 规格说明

## 概览
- 目标文件：src/components/XxxSection.tsx
- 参考截图：docs/design-references/xxx.png
- 交互模型：<静态 | 点击驱动 | 滚动驱动 | 时间驱动>

## DOM 结构
<谁包着谁的层级关系>

## 计算样式（getComputedStyle 取到的精确值）
### 容器
- display / padding / maxWidth ...（每个相关属性都写确切值）
### 子元素 1
- fontSize / color / lineHeight ...

## 状态与行为
### 滚动触发的悬浮态
- 触发点：滚动到 50px 处 / IntersectionObserver 阈值 ...
- 变化前：maxWidth 100vw，无阴影，圆角 0
- 变化后：maxWidth 1200px，阴影 0 4px 20px ...，圆角 16px
- 过渡：transition: all 0.3s ease

## 分状态内容（如有标签切换，逐个列全）
## 素材（背景图 / 浮层图 / 用到的图标）
## 文案（从原站逐字复制）
## 响应式表现（桌面 / 平板 / 手机各是什么布局，在哪断点切换）

模板里每一栏都要填，实在不适用的才写 N/A——但连页脚都可能有链接悬停态，所以"状态与行为"