每一个前端工程师大概都动过这个念头：看到某个网站的动效、布局、交互爽到不行，想拆开看看它到底是怎么实现的。

以前的做法是打开 DevTools，一层一层扒 DOM，看 Network 面板猜请求顺序，对着 Elements 里的嵌套结构发呆。费时费力，而且很容易在「这个动画到底是 CSS 还是 JS 驱动的」这种问题上卡住半小时。

website-rebuild-skill 想做的事，是把这一整套流程自动化——给 AI 一个网址，它把网站完整复刻出来。

它到底做了什么

整个项目分三个阶段，顺序很讲究：

第一阶段：抓取只读镜像

先不动任何逻辑，把目标站点当作一个静态资源集合整体拉下来。这一步的目标不是「能用」，而是「完整」——HTML、CSS、JS、字体、图片、接口返回，全部落盘。只读镜像的意义在于，它为后续的代码还原提供了一个不会漂移的基准。目标站点随时可能改版，但镜像不会。

第二阶段：还原代码

有了镜像，才是真正的逆向工程。这一步要把压缩混淆过的产物还原成可读、可运行的源码工程——拆解构建产物、还原目录结构、恢复模块划分。这是整个项目里最耗心力的部分，也是它和普通「扒站工具」的分水岭：它要的不是能跑的产物，而是能读的源码。

第三阶段：四重对比验收

这是我认为这个项目最有价值的设计。复刻最怕的是「看起来差不多」——肉眼对比往往骗人，差几个像素、动效时长短了 50ms，你可能完全看不出来，但用户会隐约觉得「哪里不对」。

所以它用四个维度做交叉验证：

四个维度全部通过，才算真正复刻完成。这个标准相当严格，但也正是它区别于「手工扒站」的核心——DOM 正确不代表网络行为正确，网络正确不代表渲染一致，渲染一致也不代表几何精确。任何单一维度都可能漏掉问题。

用在什么地方

官方说明里提到两个方向，我觉得都挺实在：

一是研究网站结构与动画交互逻辑。 想搞清楚某个网站的路由是怎么设计的、动画是用什么驱动的、状态是怎么管理的，直接读它的源码比读完文档再猜要快得多。尤其是动画效果和交互逻辑——这些东西很少被写进文档，但恰恰是前端体验里最难抄的部分。

二是把复刻结果整理成可运行的源码工程。 这点对做前端的人来说很实用。你拿到的不是一堆压缩文件，而是一个结构清晰、可以 npm install 就跑起来的项目。想学某个布局方案怎么实现，或者想把某个交互搬到自己项目里，直接读、直接改。

一点看法

这类工具其实踩在一个挺微妙的位置上。

从正面看，它把前端学习里最枯燥的那部分——扒结构、猜实现、验证一致性——交给了自动化。尤其是「四重对比验收」这个设计，本质上是把前端复刻从一个手艺活变成了一个有客观标准的工程问题。这是很好的思路。

但也得说清楚边界：它是研究和学习工具，不是抄站工具。复刻别人网站用于研究结构、学习实现思路，是正常的技术学习路径；把复刻结果直接拿去商用，那就是另一回事了。项目本身是开源的技能包，用在哪，取决于用的人。

另外从工程角度想，这个流程对动态内容多、依赖后端接口的站点效果会打折扣——镜像能抓到静态资源，但拿不到后端逻辑。所以它更适合作为「前端实现研究」的工具，而不是「整站克隆」的方案。

项目地址

https://github.com/boyang-hu/website-rebuild-skill

如果你也在研究某个网站的动效实现，或者想找一个能自动化验证 UI 还原度的思路，这个项目值得翻一翻。尤其是那套四重对比的方法论，即使不用它的工具，自己搭验收流程时也可以借鉴。