ai-website-cloner-template
对世界上的一切学问与知识的掌握也并非难事,只要持之以恒地学习,努力掌握规律,达到熟悉的境地,就能融会贯通,运用自如了。——高士其
https://github.com/JCodesMore/ai-website-cloner-template
当网站遇见镜子:AI Website Cloner Template 如何用一条命令,把网页“请”进你的 Next.js 项目里
有些项目一出现,就像工具箱里突然多了一把特别顺手的瑞士军刀。
你原本还在为网站重构发愁:旧站点在跑,源码却散了;设计明明在线上活得好好的,技术栈却老得像一台不肯退休的机器;想学习一个优秀网站的布局、响应式细节和交互节奏,却只能一边开 DevTools 一边手抄“作业”。这时候,ai-website-cloner-template 站了出来,像个穿着工程师外套的侦探,对你说:
“把网址给我,我去看看它是怎么长成这样的。”
这不是一句夸张的宣传语,而是这个项目最核心的气质。
ai-website-cloner-template 是一个可复用模板,用来借助 AI 编码代理,把任意网站逆向拆解并重建为一个干净、现代的 Next.js 代码库。仓库的 description 说得非常直接:
Clone any website with one command using AI coding agents
翻译成人话就是:给它一个目标网站,再运行一条命令,它就会带着 AI 代理去观察、提取、分析、拆分、组装,最后尽可能把那个网站“搬”进一个现代前端项目里。
如果说传统网站重构像是拿着卷尺和草图一点点手工复刻,那么这个项目更像是给你雇了一支数字施工队。侦察员先拍照量尺寸,设计师整理色彩和字体,文档员写组件规范,工人们再分头开工,最后质检员还会把成品和原网站摆在一起做视觉比对。整个过程,不再是“盯着页面猜怎么写”,而是“让 AI 带着流程去复建”。
这个项目到底是什么
AI Website Cloner Template 本质上是一个为网站复刻场景准备好的现代化模板仓库。
它不是一个花哨的演示玩具,也不是一句“AI 可帮你生成页面”的轻飘飘口号,而是一套围绕“网站逆向重建”设计好的工程骨架。它把你从零搭建项目、配置技术栈、整理规范、思考代理协作方式的时间,全都提前省掉了。
它做的事情可以概括成一句话:
把一个现成网站,重建成一个清晰、现代、可继续开发的 Next.js 项目。
更妙的是,它并不是让 AI 凭空“脑补”页面,而是让 AI 先去认真观察目标站点,再动手写代码。这种感觉很像一个靠谱的建筑师,不会看一眼大楼照片就开始画施工图,而是会先去现场勘测、记录尺寸、确认材质、观察动线,然后才开工。
它为什么让人眼前一亮
因为它把很多人心里那个模糊的愿望,变成了一个相对成体系的流程。
我们经常会遇到这些场景:
- 公司老站还在线上,但原始仓库不见了
- 原来用 WordPress、Webflow、Squarespace 搭的网站,想迁移到现代前端栈
- 想学习一个生产级网站到底怎么做布局、动效、断点和组件拆分
- 接手历史项目时,只能从线上页面“考古”
过去这些事,往往意味着漫长的人工拆解。页面截图、颜色提取、字体比对、间距测量、组件拆分、交互记录、资源下载、结构重写,每一步都像拿着小锤子敲墙,看哪里是承重结构、哪里只是装饰板。
而这个项目最吸引人的地方在于,它试图把这些繁琐动作,交给一组会协作的 AI 代理来完成。
它不是在说“AI 帮你生成一个差不多的网站”,而是在说:
AI 先研究网站,再有组织地重建网站。
这两句话之间,差的是工程味,也是结果质量。
它推荐谁来搭档
README 里明确推荐:
Claude Code 搭配 Opus 4.7,效果最佳。
但它并不排外。这个模板支持多种 AI 编码代理平台,包括:
- Claude Code
- Codex CLI
- OpenCode
- GitHub Copilot
- Cursor
- Windsurf
- Gemini CLI
- Cline
- Roo Code
- Continue
- Amazon Q
- Augment Code
- Aider
这点很有意思,它像一个见多识广的项目管家,不会执着于“只有某一位代理才能配合我工作”,而是保持开放姿态:你常用谁,就带谁来;如果你愿意听建议,那 Claude Code 是它眼里最默契的拍档。
它的工作方式,不是魔法,而是一条多阶段流水线
这个项目最值得写进博客的,不只是“它能克隆网站”,而是“它怎么克隆网站”。
README 里把 /clone-website 这项技能拆成了一个多阶段流程,读起来像一部小型施工纪录片。
第一阶段:侦察
AI 代理会先进行侦察工作,包括:
- 截图
- 提取设计令牌
- 交互扫描
- 滚动、点击、悬停
- 响应式检查
这一步像什么呢?
像网页刚推开门,AI 就拿着笔记本走进去,先不急着搬家具,而是四处看看:墙是什么颜色,按钮在 hover 时会不会变脸,屏幕变窄之后布局是收紧了还是换排了,滚到下一屏时有没有动画埋伏在那里。
一个真正像样的复刻,绝不是“截图照着画”,而是要把网页的脾气也一起摸清。
第二阶段:地基
侦察结束后,AI 会更新:
- 字体
- 颜色
- 全局样式
- 下载所有资源
这一步像是把房子的骨架、墙漆、地板、门窗都先统一处理好。网站不是孤零零的一堆组件堆叠出来的,它的气质往往来自全局:字体系统、配色体系、图像资产、基础样式变量。
如果这些东西先没站稳,后面每一个组件都只是在飘。
第三阶段:组件规范编写
然后它会在 docs/research/components/ 下编写详细的组件规范文件,内容包含:
- 精确的计算后 CSS 值
- 状态
- 行为
- 内容
这一步是我特别喜欢的地方。因为它不是急着写代码,而是先写“施工说明书”。
很多开发工作一旦进入多人协作,最怕的就是“你以为的按钮”和“我理解的按钮”根本不是同一个按钮。这个项目在真正构建组件之前,就先把组件的长相、状态、内容和行为写清楚,相当于给每个组件都发了一张身份证。
第四阶段:并行构建
接下来,构建代理会在 git worktrees 中并行工作,每个 section 或组件由独立 builder 负责。
这就很像总包工程队分工施工:有人去做 Hero 区,有人做导航,有人做卡片列表,有人处理底部区域。每个人拿着完整规范埋头建,最后再汇总。
当一个项目开始学会把工作拆给多个执行者,而不是让一个“全能工人”从头做到尾,它的效率和可控性通常都会上一个台阶。
第五阶段:组装和质检
最后就是组装页面,合并 worktrees,并对照原网站做视觉 diff。
这一步像收尾验收。不是“看起来差不多就算了”,而是拿原图对比成品,看哪里还没对齐、哪里细节跑偏、哪里节奏没跟上。
所以你会发现,这个项目真正迷人的地方,不是它喊出了“克隆网站”这四个字,而是它把“克隆”这件事做得像一个严肃的软件工程任务。
它为什么适合现代前端团队
因为它搭在一个非常干净的现代技术栈上。
README 给出的技术栈包括:
- Next.js 16
- App Router
- React 19
- TypeScript strict
- shadcn/ui
- Tailwind CSS v4
- Lucide React
这意味着什么?
意味着它不是把页面临时“糊”出来,而是把产出放在一个今天依然非常主流、非常适合继续开发的栈里。
Next.js 16 和 App Router
这让整个项目天然适合现代 React 应用的组织方式。路由、页面结构、服务端能力和未来扩展空间都比较清晰。
React 19
前端这位老搭档还在持续进化,而这个模板没有停留在旧时代的写法里。
TypeScript strict
这四个字就像一个严谨的项目经理,站在旁边盯着你说:“别糊弄,类型给我写清楚。”
对于后续维护来说,严格类型是很重要的。尤其是这种复刻型项目,组件多、结构细、资源杂,如果没有类型约束,后期非常容易乱。
shadcn/ui + Tailwind CSS v4
这一对组合有种现代前端“施工标准件”的感觉。既灵活,又足够利于组件化和风格统一。再加上 Tailwind CSS v4 使用设计令牌,对还原颜色、间距、风格系统也非常友好。
Lucide React
默认图标库先顶上,等到真正克隆过程中提取出原站 SVG 时,再把它们替换掉。很实用,也很符合工程节奏。
它最适合哪些人使用
README 给出的使用场景很明确,我想把它扩展讲得更有画面感一点。
1. 平台迁移的人
如果你手里有一个 WordPress、Webflow、Squarespace 上跑得还不错的网站,想把它迁移到 Next.js,这个项目就像一辆搬家车。
它不只是帮你把家具一件件装箱,还尽量帮你按原来的生活习惯重新摆进新房子里。你保留原网站的视觉语言、结构感觉和内容组织方式,同时把底层技术栈换成更现代、更容易维护的体系。
2. 丢了源码的人
这是一个很现实、也很无奈的场景。
网站还活着,域名还在,页面还能打开,但代码仓库不见了。也许开发者离职了,也许历史太久远了,也许原来的技术栈已经像一块长满青苔的石头,没人愿意继续碰。
这时候,这个模板像个数字考古学家。它不会真的把过去那套源码原封不动地挖出来,但它能根据线上网站,把“现在看得见的东西”重建成一个现代可维护的代码库。
这对业务延续来说,已经非常有价值。
3. 想学习优秀网站的人
有时候我们并不是想复制什么,而是想学习。
一个成熟网站为什么排版舒服?为什么按钮 hover 的节奏恰到好处?为什么响应式切换后仍然自然?为什么区块间距让人觉得透气?
过去你可能会自己截图、记笔记、抄样式。现在,你可以借这个模板,把分析和拆解工程化。它像一个耐心的老师,把生产级网站拆开给你看:这里是结构,这里是样式,这里是行为,这里是状态。
这种学习方式,远比只看截图更立体。
它也很清楚自己不该做什么
一个成熟项目,除了知道自己能做什么,也必须知道自己不该做什么。
README 明确写了这些不适用场景:
- 不用于钓鱼或冒充
- 不用于把别人的设计当成自己的
- 不用于违反服务条款的抓取或复制行为
这一段我很喜欢,因为它让这个项目显得更像一个有边界感的工程工具,而不是一个只会炫技的“万能复制器”。
工具本身可以很强,但边界不能糊。
你可以把它用在合法合规的迁移、学习、重建和恢复工作上,但不能把它变成一副伪装面具。项目作者把这条线画得很清楚,这反而让人更放心。
快速启动真的很直接
这个项目的 Quick Start 非常清晰,几乎没有多余绕路。
第一件事不是直接 clone 仓库,而是:
使用 GitHub 的 Use this template 按钮,先创建你自己的仓库副本。
这很重要。因为这个仓库本身是模板,你应该把它变成自己的项目,而不是直接在模板仓库上动刀动斧。
创建好自己的仓库后,再把它拉到本地:
1 | git clone https://github.com/YOUR-USERNAME/YOUR-NEW-REPOSITORY.git |
安装依赖:
1 | npm install |
启动 AI 代理,README 推荐的是 Claude Code:
1 | claude --chrome |
然后运行核心技能:
1 | /clone-website <target-url1> [<target-url2> ...] |
看到这里时,这个项目会给人一种很爽的感觉:前面的工程设计很复杂,但真正交到用户手上的入口却很简洁。像一台结构精密的机器,外面只露出一个清楚好按的按钮。
如果你想更有代入感,可以这样想象整个过程
你打开 AI 代理,对它说:
“去把这个网站研究一下,然后帮我重建出来。”
它点点头,先跑去侦察,把页面拍下来;接着蹲在颜色、字体、间距和资源旁边做笔记;然后回到工作台,把每个组件的尺寸、状态和行为写成规范;再把一群 builder 分发出去,各自去造导航、造卡片、造 Hero、造页脚;最后把这些部分运回主工程,拼装、对齐、比对,直到尽量还原。
整个过程里,AI 不再像一个“一次性输出答案”的聊天机器人,而更像一个组织有序的数字团队。
这也是这个项目特别符合当下 AI 编程趋势的一点:
它不是让 AI 单枪匹马写一坨代码,而是让 AI 在有流程、有规范、有分工的框架里干活。
这比“来,直接生成个首页”高级得多,也实用得多。
目录结构也很有“项目感”
一个模板是否靠谱,看看它的目录结构,往往就能感受到七八分。
这个仓库的结构非常清晰:
1 | src/ |
这里面最打动我的,不是某个单独的文件夹,而是它整体体现出的“可维护性”。
src/负责代码本体public/负责从目标站点下载下来的资源docs/research/留存研究过程和组件规范docs/design-references/保存截图参考scripts/管理多平台代理规则同步
也就是说,这个项目不仅关心“最后写出什么代码”,还关心“中间研究了什么、依据是什么、规范在哪里、平台间怎么同步”。
这是一种很成熟的思路。
它知道复刻网站并不是单纯生成几个组件,而是一项有过程资产的工作。研究文档、设计参考、规则同步,这些看似周边的东西,其实才是真正让项目变得能长期使用的原因。
命令行也安排得很工整
除了核心的 /clone-website 技能,README 里也给出了常规开发命令。
1 | npm run dev |
如果要更直白地解释这些命令,它们像是项目里的几位值班同事:
npm run dev是接待员,负责把开发服务器先开起来npm run build是验收员,看看生产构建能不能顺利通过npm run lint是语法巡检员,专门盯代码风格和潜在问题npm run typecheck是类型审计员,把 TypeScript 约束挨个过一遍npm run check则像总巡查,把 lint、typecheck 和 build 一起拉出来列队点名
如果你使用 Docker,README 还提供了命令:
1 | docker compose up app --build |
一个用于构建并运行应用,一个用于在 3001 端口以开发模式运行。
这说明作者考虑得很周到,不是只为某一种开发习惯准备入口,而是给不同工作流都留了门。
它不仅是模板,还是一套多平台代理规则的“总控台”
README 里还有一个挺有意思的部分:Updating for Other Platforms。
这个仓库里有两个“事实来源”文件:
AGENTS.md负责项目指令.claude/skills/clone-website/SKILL.md负责/clone-website技能
对应的同步命令分别是:
1 | bash scripts/sync-agent-rules.sh |
这意味着什么?
意味着作者没有把不同平台的代理配置各写各的、互相漂移,而是试图建立统一源头,再自动生成平台专属副本。
这非常像一个管理多个分店的总部。总部负责制定统一标准,各家门店按照标准刷新自己的执行手册。这样做的好处是,一旦核心规则更新,不需要人工到处改,直接同步就行。
对于一个面向多种 AI 编码代理的平台模板来说,这种设计很聪明。它降低了维护成本,也让整个项目更像一个真正长期打磨的工具,而不只是一个短期爆火的示范仓库。
它最大的魅力,是把“克隆”这件事从粗活变成细活
说到底,网页复刻最怕的不是慢,而是粗。
粗在哪?
- 粗在只抄结构,不抄细节
- 粗在只看桌面端,不看响应式
- 粗在只做静态,不管状态
- 粗在只拉图片,不整理设计系统
- 粗在只拼组件,不做验证
而这个模板想做的,恰恰是把这些粗糙感一点点磨平。
它希望 builder agent 拿到的不是一句模糊描述,而是完整的组件规范;
它希望构建不是串行死磕,而是并行分工;
它希望最终结果不是“味道差不多”,而是“尽可能贴近原站,并且站在现代代码结构里”。
这也是为什么我会觉得它不是一个简单的“网站克隆器”,而更像一个复刻工程框架。
“克隆”在这里不是复印机式的粗暴复制,而更像一位懂结构、懂审美、懂前端工程的数字工匠,在原站旁边搭起另一座新房子。
如果你准备上手,推荐这样开始
你完全可以照着 README 的路径来,不需要额外绕弯。
第一步:用模板创建自己的仓库
先点 GitHub 上的 Use this template,生成自己的仓库副本。别直接在模板仓库上开工。
第二步:拉到本地并安装依赖
1 | git clone https://github.com/YOUR-USERNAME/YOUR-NEW-REPOSITORY.git |
第三步:启动 AI 代理
如果你用 Claude Code:
1 | claude --chrome |
第四步:让它开始工作
1 | /clone-website https://example.com |
如果你要观察多个目标地址,也可以按 README 的格式传多个 URL:
1 | /clone-website <target-url1> [<target-url2> ...] |
第五步:在克隆结果上继续定制
README 也写得很坦诚:基础克隆完成之后,你可以继续按需修改。这点非常现实,因为再优秀的流程,也不代表每个像素都能自动替你做最终决策。它更像是帮你把最重、最繁琐、最需要耐心的基础工程先搭完,让你把精力放在真正有价值的取舍和优化上。
这个项目最适合什么样的心态
我觉得是两种心态。
第一种,是恢复者的心态。
你不是为了炫技去“复制一个网站”,而是为了把已有的线上成果,迁移、恢复、重建到更现代的系统里。你看重的是效率、工程质量和后续维护能力。
第二种,是学习者的心态。
你想知道成熟网站是如何组织设计与代码的,想理解真实生产项目里的页面、组件、交互和响应式是怎么协作的。你不是拿它当偷懒工具,而是拿它当放大镜和实验室。
如果带着这两种心态之一来用它,这个模板会非常有价值。
写在最后
ai-website-cloner-template 最让人喜欢的地方,不只是“它能做什么”,而是“它把复杂任务安排得很像回事”。
它没有把网站复刻浪漫化成一句空洞的 AI 宣言,而是脚踏实地地把流程拆开:
- 先侦察
- 再提取
- 再写规范
- 再并行构建
- 最后组装和质检
它像一个会排兵布阵的项目总工,把原本依赖耐心、人肉和经验的大量工作,交给 AI 编码代理去协同完成。
更重要的是,它把这一切落在一个现代、清晰、可延续的 Next.js 技术栈上,让结果不仅“像”,而且“能继续做下去”。
如果你正在经历网站迁移、源码遗失、设计复建,或者只是想更认真地学习一个优秀网站到底是怎样被做出来的,那么这个仓库就像一个非常会干活的数字搭档。你把网址递给它,它会抬头看你一眼,然后卷起袖子说:
“好,现场我先去勘一遍,代码我们一块把它重新盖起来。”
有些项目解决的是功能问题。
而有些项目,解决的是那种开发者一想到就头大的复杂问题。
ai-website-cloner-template 显然属于后者。
