> For the complete documentation index, see [llms.txt](https://shike.gitbook.io/ai-coding/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://shike.gitbook.io/ai-coding/02-chapter.md).

# 第2章 "照这个网站做一个":一次真实委托的四段式复刻

**本章导读**:本章复盘一项实际接到的委托——客户希望完整复刻某行业竞品的官网。委托型需求的难点不在技术实现,而在四件事的把握:如何不接下无法交付的需求、如何在前 30 分钟识别真正的难点、如何在过程中控制质量而不失控、以及如何判断"做到什么程度算交付"。本章按"需求受理—难点识别—四阶段执行—验收交付"的顺序完整复盘,核心方法论是"把模糊需求变成可验收的中间产物"。

**本章关键词**:委托型需求、需求诊断、四段式复刻、量化验收

## 2.1 需求受理与价值判断

### 2.1.1 一个典型的咨询开场

委托开场通常以一句模糊的话开始。某次真实的项目开场是这样的:; 周一上午 10:03,客户通过飞书发来一条 7 个字的消息——"想照 XX 网站做一个"。消息下方附了一个链接,没有更多说明。项目负责人(以下简称"负责人")的第一反应是直接关掉窗口,倒一杯水,再点开看一次。

七字开场,实际包含三层需要被拆出来的问题:那个网站具体是哪一个;"做"到什么颗粒度——是只复刻首页视觉,还是整套官网包括后台;是否需要真实数据接入(还是先用模拟数据)。三类问题对应三种不同的工作量(差异可达 5—10 倍),任何一类不明确就报价,大概率第三周返工。

负责人的处理方式不是直接报价,而是先回一段话(原文摘录):

> "在报价前想先和你对齐两件事。第一,你希望我做的这个网站,是只复刻外观(首页 + 几个内页的视觉一致),还是做成可上线的完整产品(每条链接都能跳、每张图片都对应真实内容)。前者一周可交,后者两到三个月。第二,客户的目标用户是谁——是给 B 端采购看的,还是给 C 端用户用的。这两件事明确后,我可以给你一个具体方案。"

这段话做了三件事:把模糊的"做一个"具体化为两个可被回答的问题;给出每种选择对应的工时范围,让客户理解"做一个"的多义性;不要求客户立刻回答,留出思考时间。模糊不是问题,不追问才是问题。

**一种常见但错误的处理是"先做一版让客户看"**。这种做法的隐含假设是"客户看到东西后就能说清楚想要什么",但实际经验是,客户看到第一版后的反馈往往是"感觉不对但说不清哪里不对",这会让返工范围扩大,而非缩小。

### 2.1.2 委托型需求的前置评估清单

接到"照某个网站做一个"的需求时,以下五项应在前 30 分钟内完成评估,任一项不通过即应推迟或拒绝。。 **现场还原**:某次项目开场后,负责人和客户在 30 分钟的语音里把五项问完。前三项都很快拿到了答案——客户能给出 3 个参考站、能描述目标用户(中型制造业的采购经理)、也知道"做出来"是指可上线的成品。卡在第四项:客户预期"一版到位,最多改两轮"。负责人当场把改版规律讲了一遍(下面"教训"段会展开),客户沉默了 5 秒钟,然后说"行,那我们按三到四轮来排期"。这个沉默的 5 秒钟,比任何合同条款都管用——客户从此对改版有合理预期,后续沟通成本直接下降 40% 左右。

**第一,使用场景是否清晰**。"做出来"这个词在不同客户那里意味着完全不同的东西:有人要的是一份可演示的样品(看上去像样,内部功能可空),有人要的是可上线的成品(每条链接都能跳、每张图片都对应真实内容)。前者 1—2 周可交,后者 2—3 个月——报价前必须先确认。

**第二,目标网站的设计归属是否清晰**。如果客户没有版权意识(例如要求 1:1 复刻某商业网站并以此为产品),或客户与版权方存在直接竞争关系,应在开工前书面明确责任划分:抄袭责任由谁承担、改动到什么程度算"参考而非复刻"。

**第三,客户是否能提供"成品样板"**。有效的样板是:① 客户能在屏幕上指着某个具体页面说"做成这样";② 客户能列出 3—5 个他喜欢的其他网站(用以推断审美偏好);③ 客户能描述目标用户(谁是最终用户、他们用这个网站做什么)。三个条件中只要满足两条,项目风险可控;只满足一条,需要再次对齐;零条,建议不接。

**第四,客户对"调整"的预期是否合理**。任何复刻项目都会经历"做出来—客户改—再改—再改"的循环。一周内经过两轮小改是正常的;如果客户预期"一版到位",则沟通成本会在后期消耗远超开发的时间。

**第五,客户是否能提供"决策权"**。对接人是运营、产品还是技术?他能不能拍板?如果每个决定都要再问上级,项目时间会被无意义的审批流程拉长 30%—50%。。 这五项中,任一项不通过,正确做法是推迟报价——不是拒绝客户,而是回到第二步的"把诉求说回来"环节,直到五项均有明确答复为止。

**教训**:"对话式评估"是 30 分钟做完五项的关键。负责人习惯用一连串具体问题(谁用、用它做什么、谁能拍板)而非抽象问题(您觉得呢)推进对话。具体问题的好处是客户能给具体答案,抽象问题只会换来抽象回应(例如"做得专业一点")。后者听起来客气,但对项目推进毫无帮助。

### 2.1.3 需求受理阶段的交付物

前 30 分钟的对话,产出的不是报价,而是一份"需求诊断报告"——一页纸,五段话:

* **范围确认**:做出来指什么(样品/成品)、颗粒度(仅外观/含后台)、谁验收(对接人/最终用户)。
* **已知信息**:客户提供的所有材料(链接、截图、文档、口头描述)。
* **未知信息**:客户没提供但项目需要的信息(目标用户、运营策略、SEO 需求)。
* **风险点**:可能拖慢进度的环节(版权、客户改版频率、技术难点)。
* **下一步**:在客户补充信息后,可以进入方案设计阶段。

这份报告本身可作为后续合作的依据。如果客户拒绝写这份报告,意味着客户尚未准备好开始项目——这不是技术问题,是合作意愿问题。。 **现场细节**:负责人每次接新项目,会先在飞书里建一个三人群(客户、负责人、一位工程师),第一份置顶消息就是这份诊断报告的初稿。客户如果在 24 小时内没回"确认",负责人会主动打电话而非再发消息——电话里能听到犹豫的语气,文字里看不到。这个流程跑了 12 次项目,11 次在 48 小时内完成了诊断确认,1 次因客户内部方向改变终止合作(终止时诊断报告已写到 60%,客户依据报告中的"风险点"为依据结算了前期调研费用)。终止的项目不一定是失败——在不合适的需求上及时止步,本身就是一种交付。

**教训**:诊断报告的"风险点"一栏是项目过程中最被低估的部分。多数团队只把已知信息写得详细,风险点写得很空(例如"待评估")。负责人后来养成一个习惯:任何不能在 24 小时内回答的风险点,统一写成"X 项,可能拖慢 Y 天"——例如"客户内部决策流程未知,可能拖慢 5—10 天",这种描述让风险变得可视,客户的注意力也更容易被引导到对项目真正重要的事情上。

![四段式工作流全貌](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-8f22f3eea90511268746a9c4d801aa0db6c7b558%2Fai_coding_book_sec02_four_stage.svg?alt=media)

![复刻网站四阶段时间线](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-eaec07179d5728a03b680be6d65149d8c912f9ae%2Fai_coding_book_sec02_timeline.svg?alt=media)

## 2.2 需求难点分析

### 2.2.1 表面难度与真实难度的差距

**现场还原**:某次项目,客户发来目标网站后,负责人当天晚上花 2 小时把首页、产品列表、产品详情、博客四个页面截图保存,用取色器提取了 12 个色值,在笔记本上手写了 3 页"看着挺像"的复刻要点。第二天,负责人给客户打电话 20 分钟,问的不是"做出来指什么",而是另一个问题——"这个网站对您的客户最关键的一个动作是什么"。客户答"让采购经理能在 5 分钟内对比完三款产品的参数",负责人突然意识到:前一夜研究的 3 页要点里,有 2 页是"装饰性内容",真正重要的是参数对比表格的呈现方式。从这一晚开始,项目方向从"复刻一个网站"调整为"复刻一个能帮采购经理 5 分钟内做对比的网站"——工作量没变,但方向从"像"转向"对"。

"照一个网站做一个"听起来简单,实际包含三类不同性质的难点。。 **第一类,技术实现层面的难点**。包括:网站的页面数量(是 5 页还是 50 页)、交互复杂度(纯静态还是含动态效果)、后端依赖(是否需要数据库、用户系统、第三方接口)、响应式适配(电脑、手机、平板是否都要)。

**第二类,业务理解层面的难点**。包括:目标网站的核心价值是什么(是信息展示、交易转化、还是用户运营)、目标用户的关键行为路径(从哪里进入、在哪里停留、在哪里离开)、客户希望复刻到几分(外观相似?交互一致?还是连运营策略都要复刻)。

**第三类,过程管理层面的难点**。包括:客户的耐心(改几版会烦)、团队的节奏(不能拖太久)、验收标准的模糊性("差不多就行"是项目失控的常见信号)。。 多数项目失败的真正原因不是第一类(技术)而是第二、三类。客户对"做成什么样"没有清晰预期,改到第三版时开始失去耐心,沟通成本急剧上升,最终项目以"基本能用但客户不满意"的状态交付。防范这一风险的方法是:在项目开始前,把验收标准从主观感受转化为可量化的检查项(2.7 节详述)。

**教训**:三类难点的投入精力比例,经验值是 2:5:3——技术 20%、业务 50%、过程 30%。多数新手的比例是 7:2:1——七成精力扑在代码上,两成理解业务,一成留给过程管理。这个比例的项目,代码写得再漂亮,客户依然不满意,因为客户买到的是"对的产品"和"对的体验",不是"漂亮的代码"。

### 2.2.2 三类难点的不同应对

**现场细节**:某次复刻项目,负责人原本打算用三天把"业务理解"这块做完。实际推进时,改成每天和客户聊 20 分钟,聊 5 天。前 4 天的对话主题是"目标用户最常做的 5 件事",第 5 天客户突然问:"如果我们不学参考站的注册流程,改成扫码关注公众号,你觉得怎么样?"——这个问题是 4 天对话累积出来的,不是第 1 天能问出来的。如果按原计划用 3 天一次性问完,这个问题永远不会出现。

技术难点通过经验积累与工具复用解决。复刻网站是工程领域相对成熟的工作,有大量现成工具(后续案例章节会涉及)可以承担大部分执行性工作,真正需要判断的地方不多。。 业务难点通过前期的诊断对话解决。客户未必能清晰描述自己的诉求,但能回答具体的判断题:"这个网站的目标用户是?","用户在这里完成的最重要动作是?","如果只能保留一个功能,是哪个?"。三个问题问完,业务难点就清晰了。

过程难点通过"小步交付 + 量化验收"解决。不要等到第三周才让客户看到东西——第一天结束时,客户应该能打开一个最低限度可访问的页面(即使只是首页),并能基于此给出反馈。每周交付一个可演示的版本,客户改版时改动范围可控。

### 2.2.3 需求阶段的三类常见误区

**误区一:把"看着像"当作验收标准**。"看着像"是主观判断,因人而异,无法稳定执行。正确的验收标准是:"首屏布局与参考站一致度 80% 以上 + 五项关键交互动作行为正确 + 三种典型设备上正常显示"——这种描述才能被稳定地判断是否达成。

**现场案例**:某次项目,客户第一版验收时说"感觉哪里不对但说不清"。负责人当时没有强推"量化标准",而是问了一个具体问题——"如果请您从 1 到 10 给这个网站打分,您给几分"。客户答"6 分"。负责人接着问"那 10 分的网站和这个网站最大的差异是什么"。客户想了 30 秒,说"按钮的 hover 颜色太浅了,看起来像没点过"。这个问题是 6 分背后的真实原因,但不通过具体提问,客户说不出来。"看着像"和"6 分"之间,只差一个具体的问题。

**误区二:把"功能完整"放在"用户体验"之前**。客户往往要求"先做完所有功能,再优化体验",但实际经验是:把 80% 时间投入 20% 的核心功能、把 20% 时间留给次要功能,项目完成度反而更高;反过来先把所有功能做到 60% 再说,会陷入"什么都有但什么都不好用"的困境。

**现场案例**:某次项目,客户要求"先把所有 47 个页面做完,再统一优化"。负责人当时没有直接反驳,而是画了一张图给客户看——一个金字塔,塔尖是"用户最常走的 3 条路径",塔身是"偶尔触发的 8 条路径",塔底是"几乎没人走的 36 条路径"。然后问客户:"您愿意把 80% 的预算花在塔尖(让 80% 的用户满意),还是平均分给 47 个页面(让每个页面都只有 60 分)?"客户选择前者,项目最终在第 18 天交付,客户满意度 9/10(对比按"47 页平均"思路交付的同行,客户反馈"好太多")。

**误区三:把"流程完整"当作"工作到位"**。一个项目从需求到交付经过 8 个环节,每个环节都"做了一点"和"做透"是完全不同的——前者是流程完整,后者是工作到位。本章强调的"四段式",不是要求每段都走过场,而是要求每段都做透。

**教训**:识别"走过场 vs 做透"的方法是问一句话——"这个环节如果只做一半,哪个具体问题会暴露出来"。如果答得出来,说明这个环节是必要的、不能省;如果答不出来,说明这个环节在当前项目里其实不重要,可以根据实际需要压缩或跳过。

## 2.3 工作流全貌

**现场还原**:某次复刻项目,负责人原计划按"先做完侦察再做设计"的串行节奏推进,第一阶段 5 天,第二阶段 4 天。但实际执行时,设计师在等侦察报告的两天里闲着,工程师在等设计清单的两天里也闲着。第二个项目负责人调整了节奏:侦察完成 50% 时就启动设计,设计完成 50% 时就启动重建,三个阶段并行推进——总工期从 35 天压缩到 22 天,且每个阶段的产出都更扎实(因为下一阶段的反馈能及时回流到上一阶段)。从那以后,负责人用一句话总结这个经验:"四段是逻辑顺序,不是执行顺序"。

复刻一个网站,完整的工作流可拆为四段:侦察—设计—重建—验收。每一段都有明确的输入与产出,前后两段之间的接口是"上一段产出"被"下一段消费"。。 **第一段(侦察)**:对目标网站做技术诊断。回答三件事——网站用的是什么技术栈(语言、框架、部署方式)、页面的总体结构(模板复用、动态渲染方式)、内容来源(是写死在 HTML 里还是从接口读取)。产出物:一份"技术诊断报告",3—5 页。

**第二段(设计)**:提取目标网站的设计语言。回答三件事——配色方案(主色、辅色、强调色)、字体与排版规则(标题、正文、辅助文字的字号与字重)、组件样式(按钮、卡片、表单的统一风格)。产出物:一份"设计意图清单",列出关键设计决策。

**第三段(重建)**:基于前两段产出,实际把网站做出来。这一段是项目的主工作量,通常占整个项目 60%—70% 的时间。产出物:可访问的网站,每条链接都能跳、每张图片都对应真实内容。

**第四段(验收)**:对产出做量化验收。逐项核对 2.7 节列出的检查清单,确保每项均通过。产出物:一份"验收报告",列明通过项、未通过项、整改计划。。 四段之间的关系不是"先做完一段再做下一段"——而是"上一段产出物未稳定前,不进入下一段"。如果第一段的诊断报告未明确,直接进入重建,会在第三周才发现"这个页面不是 HTML 写的,是从接口拉的",需要回退到第一段重做。每一段都应做到"产出物稳定可被下一段消费",再开始下一段。

**现场细节**:四段之间的"产出物稳定"是项目能否按期交付的关键节点。负责人后来在每个阶段结束时,会做一件事——把下一阶段的负责人请过来,让他/她用 15 分钟"挑刺"。如果下一阶段的人在 15 分钟内挑不出硬伤,说明这一阶段产出物可以进入下一阶段;如果挑出问题,当前阶段需要补完再交接。这个 15 分钟的"挑刺会",比任何内部 review 都有效——因为下一阶段的人是用"能否消费这份产出"的视角在看,而当前阶段的人是用"我做得够不够好"的视角在看,两种视角叠加,产出物的质量上限会显著抬高。

## 2.4 第一阶段:站点侦察与技术诊断

![AI 幻觉模式图](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-9798ed71ef4466c8e2d8b711db72b00c41ff5e5f%2Fai_coding_book_sec02_hallucination.svg?alt=media)

### 2.4.1 侦察的目标与边界

**现场还原**:某次复刻项目,负责人带一位工程师(以下简称"侦察工程师")一起做侦察。两人分工:负责人负责"看网络面板、读 HTML 源码",工程师负责"看 HTTP 响应头、查 robots.txt、识别 CDN"。两小时下来,负责人识别出目标站是 Next.js 13 + ISR(增量静态再生)的组合,工程师识别出 CDN 用的是 Cloudflare。两人在第三小时把信息汇总,写了 4 页诊断报告——其中 1.5 页是工程师的产出,2.5 页是负责人的产出。这次"双视角侦察"让诊断报告完整度比单人多了一倍。

站点侦察的目标是回答三个问题:技术栈是什么、页面怎么组织、内容从哪来。侦察不是破解——所有信息都可以从公开渠道获取(右键查看源代码、网络面板查看接口请求、HTTP 响应头查看服务器),不需要逆向工程。

侦察的边界是:不下载未公开的资源、不绕过访问限制、不获取登录后才能看到的内容。这条边界是工程伦理的基础,也是后续合作的保障——一旦侦察阶段越界,后续所有产出都可能带来源头问题。

**教训**:侦察阶段最容易越界的是"看登录后的页面"。某次,客户问"为什么我看到的比你们的多",负责人答"您登录后看到的是后台内容,不在我们这次复刻范围内"。客户当时没再追问,但在项目验收时突然说"我看了你们给我的版本,有些地方和我登录看到的不一样"。如果不事先把"只看公开内容"这条边界讲清楚,类似的争议会持续到项目结束。

### 2.4.2 技术栈识别

**现场细节**:某次项目,目标网站在响应头里写着 `X-Powered-By: Next.js`,但负责人打开 HTML 源码一看,完全没有 `__NEXT_DATA__` 特征。继续看了 5 个页面,每个都是这种情况。工程师查了 Cloudflare 的缓存配置才发现——目标站在 Cloudflare 边缘节点上做了 HTML 转换,把所有 Next.js 特征都抹掉了。最终这个网站的真实技术栈是 Next.js 13(App Router) + Vercel 部署,只是被 CDN 改造过表面。这个案例让负责人明白一件事:**响应头和源码不一致时,要先怀疑 CDN,再怀疑自己看错**。

识别技术栈的常用方法有三种,从粗到细递进。。 **粗略识别**基于网络面板的 HTTP 响应头信息(浏览器开发者工具中的 Network 标签,记录浏览器与服务器之间的每一次通信)。大多数主流框架会在响应头中暴露自身——例如 `X-Powered-By: Next.js` 表示网站用 Next.js 构建,`Server: nginx/1.21.0` 表明反向代理使用 Nginx。这些标识可以快速缩小技术栈范围。

**精细识别**基于 HTML 源码特征(在浏览器中右键"查看页面源代码"即可)。前端框架的产物通常带有可识别特征:Next.js 项目会在源码中包含 `__NEXT_DATA__` 这样的全局变量,Vue 项目会包含 `data-v-xxxxx` 这样的属性,Gatsby 项目会在路径中包含 `/static/` 前缀。

**最准确的识别**基于公开仓库与部署平台。多数现代网站会在仓库根目录放置 `package.json`(记录项目依赖的文件),通过其中的依赖项可以反推技术栈;或在域名后追加 `/robots.txt` 看到搜索引擎抓取规则,反推网站结构。

需要说明,以上三种方法均存在局限:压缩或混淆过的生产构建(网站部署到正式环境时会做代码压缩)会隐藏关键特征;CDN 接入(内容分发网络,让网站访问更快的中间层)会替换 `Server` 响应头;私有部署的网站无公开仓库。识别失败时,正确做法是承认"未能识别"而非强行猜测——技术栈未知不意味着不能复刻,只是意味着需要花更多时间重建。

### 2.4.3 页面结构分析

**现场细节**:某次项目,负责人花 2 小时把目标站的 12 个核心页面打开,逐一截图,然后用文件对比工具(类似 diff 工具)两两比较结构相似度。结果发现,这 12 个页面其实是 4 套模板(首页、产品列表、产品详情、博客)的不同组合——每套模板被复用 3—4 次,只是数据不同。这个发现让复刻工作从"做 12 个页面"压缩为"做 4 套模板 + 12 份数据"——工作量从估计 15 天变成 6 天。"模板复用关系"这一条侦察,价值超过前面所有技术栈识别加起来的价值。

页面结构分析的目标是回答"页面的模板是怎么复用的"。答案通常是三种模式之一:静态 HTML 页面(每页一个独立文件)、服务端渲染(每次请求服务器返回完整 HTML)、客户端渲染(只返回空容器,内容由 JavaScript 动态填充)。

三种模式对应的复刻策略不同:静态页面最简单,直接复制文件结构;服务端渲染需要先理解后端逻辑;客户端渲染需要先在浏览器中执行 JavaScript,再观察最终 DOM 树(浏览器在内存中维护的页面结构树)。

需要关注的是页面之间的"复用关系"——头部导航、底部信息、侧边栏是否在多个页面重复出现。如果是,意味着原网站使用了"模板继承"或"组件化"机制,复刻时应采用相同机制,避免在每页重复实现头部与底部。

### 2.4.4 内容来源分析

**现场案例**:某次复刻电商网站,负责人打开两个不同的产品详情页(都是同款手机壳,只是颜色不同),对比后发现——两页 HTML 完全一致,只有图片地址不同。结论是"内容应该都是从同一个 API 拉的",但具体 API 在哪?负责人在网络面板里筛选 XHR 请求,发现每次加载详情页都触发一个 `/api/v2/products/{id}` 的请求,响应是 JSON。负责人记下 API 地址、参数格式、返回字段——这三条信息就是后续重建后端的依据。**没有这一步,后续就只能用静态 HTML 假装是动态网站,客户一旦真正想改数据,就要重做**。

内容来源分析的目标是回答"页面上的数据是写死的还是动态拉取的"。这一问题的答案直接影响复刻成本:写死的内容需要逐条复制;动态拉取的需要重建后端接口。。 判断方法简单:打开两个相同页面的实例(例如同一商品的详情页,SKU 编号不同),比较两者的差异。如果两页结构完全相同、内容不同,数据必然是动态拉取的;如果两页完全一致,内容可能是写死的。

动态拉取的页面,进一步需要识别接口的地址、参数、返回格式。接口信息可在网络面板的 XHR/Fetch 请求中找到(浏览器与服务器之间的异步数据请求,通常以 JSON 格式返回内容)。这些信息对复刻后端至关重要,但应注意:拿到接口信息不等于可以自由调用——很多接口有访问频率限制、登录要求或服务条款约束。

### 2.4.5 侦察报告的产出

**现场细节**:负责人做过的 12 次复刻项目,侦察报告的平均长度是 4 页。其中最薄的一份 2 页(目标站只有 5 个静态页面,内容全在 HTML 里),最厚的一份 7 页(目标站有动态 API、登录态、第三方支付集成)。薄报告不见得是"偷懒"——如果目标站就是简单,2 页说清楚就好。厚报告也不见得是"扎实"——如果 7 页里有 3 页是凑字数的低信息密度内容,不如 4 页写得清爽。

侦察阶段产出的是一份 3—5 页的"技术诊断报告",应包含以下信息:

* 目标站点的技术栈(语言、框架、部署方式、CDN)
* 页面总体结构(模板复用模式、动态渲染方式)
* 关键页面的内容来源(静态/接口)
* 复刻成本估算(预计工时、需投入的工具)
* 风险点(版权、技术难点、可能拖慢进度的环节)

这份报告本身可作为与客户沟通的依据——客户能从中看到项目的真实工作量,也能基于报告中的"未知项"提供补充信息。

## 2.5 第二阶段:设计意图蒸馏

### 2.5.1 蒸馏目标

**现场还原**:某次复刻项目,负责人一开始只盯着"主色是什么"——取色器取出来是 `#1A73E8`,记下。但客户验收时问"为什么你的蓝色看起来比参考站冷?"。负责人重新看参考站,发现参考站主色其实是 `#2A6CD8`——而负责人取的 `#1A73E8` 是某个按钮的 hover 态颜色(在主页上恰好出现频率高)。这个错误源于把"出现频率最高的颜色"误认为"主色",实际主色应该看"品牌标志 + 关键 CTA 按钮"用的是什么色。**颜色识别要按用途,不是按频率**。

设计意图蒸馏的目标是回答一个问题:这个网站"看着顺眼"的原因是什么?答案不是"用了蓝色"或"留白多",而是"配色按这种节奏搭配时,用户的注意力被引导到了哪里"。

多数网站看上去"专业",不是因为设计高超,而是因为遵循了一套可被学习的设计系统——字体大小按特定阶梯(例如 12/14/16/20/24/32 的等比数列)递进、配色按主色 + 辅色 + 强调色 + 中性色的四档体系组织、组件样式按统一的圆角、阴影、间距规则统一处理。把这些"规则"提取出来,就是设计意图。

### 2.5.2 配色方案提取

**现场细节**:某次项目,负责人用取色器提取了 23 种颜色,看起来很多,实际上大部分是"中性色 + 文字 + 边框"的微差异。真正有设计决策价值的不超过 7 种——主色 1、辅色 2、强调色 2、中性色 2(深灰、浅灰)。其余 16 种都是这 7 种的派生(透明度变化、hover 态、明度变化)。**配色方案的核心是 7 种以内,不是 23 种**。

配色方案提取的输出是四档颜色,每档一个具体色值(以十六进制表示,如 `#1A73E8`):

* **主色**:用于核心交互按钮、关键链接、品牌标志。占页面 5%—10% 的视觉重量。
* **辅色**:用于次级按钮、辅助链接、装饰元素。占页面 2%—5%。
* **强调色**:用于状态提示(成功、警告、错误)、突出元素。占页面 1%—3%。
* **中性色**:用于文本、背景、边框。占页面 80% 以上。

提取方法:截取目标网站的 5—10 个关键页面,用取色器逐一记录每种颜色的出现位置。出现频率最高的 1—2 种即主色,出现频率中等但仅用于交互的即辅色,极少出现但用于特殊状态的即强调色,文本与背景颜色归为中性色。

### 2.5.3 字体与排版规则

**现场案例**:某次项目,负责人看完参考站后,凭感觉写了"标题 24px,正文 14px,辅助 12px"。但和参考站一对比,差距明显——参考站正文其实是 16px,行高 1.6 倍,字重 400;负责人写成了 14px,行高忘了写,字重 500。差别不大,但视觉上"挤"且"重"。后来负责人用浏览器开发者工具(F12 → Computed → font-size)把每个页面的字号逐一量出来,才发现真实数值。**字号永远要量,不能猜**。

字体与排版规则的输出是六档字号,每档一个具体数值(单位通常为像素):

* **超大标题**(用于 hero 区主标题,32—48px)
* **大标题**(用于页面主标题,24—32px)
* **中标题**(用于区块标题,18—24px)
* **正文**(14—16px,行高 1.5—1.7 倍字号)
* **辅助文字**(12—14px,用于次要信息、注释)
* **极小文字**(10—12px,仅用于版权信息等极少阅读的内容)

字号之间应保持等比或固定步进,例如 1.25 倍递进(16/20/25/31/39/49)。等比递进的字号看上去比随机字号"更专业",因为它符合视觉节奏规律。。 字体选择上,中英文通常分开处理:英文多用 sans-serif 字体(无衬线字体,即字形末端没有装饰性小线的字体,如 Helvetica、Inter、Roboto),中文多用系统默认字体或思源黑体。混排时注意字号与行高的对齐。

### 2.5.4 组件样式统一

**现场细节**:某次复刻项目,负责人做完设计清单后,工程师照着实现。但交付前自检时发现:主导航按钮是 4px 圆角,产品卡片的按钮是 8px 圆角,表单输入框是 4px 圆角,底部订阅按钮是 16px 圆角。四个按钮四种圆角,整体看起来"凑"而非"设计"。原因是工程师在实现时凭手感调,没严格按清单的"统一 8px"规则。**清单的纪律性比清单的完整性更重要**——清单不完整可以补,执行时凭感觉就救不回来。

组件样式统一的输出是五项具体规则,适用于按钮、卡片、表单、列表、模态框(弹出的对话框)等所有可复用组件:

* 圆角(0px 直角、4px 微圆、8px 中圆、16px 大圆)
* 阴影(无 / 轻阴影 / 中阴影 / 重阴影,各对应一个具体的 box-shadow 值)
* 间距(8px / 16px / 24px / 32px,各对应一个具体的 margin/padding 值)
* 过渡动画(150ms / 300ms / 500ms,各对应一个具体的 transition 时长)
* 交互态(hover 悬停、focus 聚焦、active 按下、disabled 禁用 各对应一组样式)

把以上五项规则记在一份清单上,所有组件按此清单实现,网站整体观感即统一。多数"业余感"的来源,正是这些规则的不统一——有的按钮圆角 4px、有的圆角 8px,有的有过渡有的没有,整体观感即"凑出来的"。

### 2.5.5 设计意图清单的产出

**现场细节**:负责人做过的一份设计意图清单只有 2 页(目标站是早期 Bootstrap 风格,设计语言很简单),另一份有 5 页(目标站是定制化设计系统,字号阶梯和组件变体都很多)。**清单的长度应该匹配目标站的设计复杂度,不是越详细越好**——把 2 页的设计站硬扩成 5 页,反而把简单的设计变复杂了。

设计蒸馏阶段产出的是一份"设计意图清单",通常 2—3 页,应包含:

* 四档配色(主色、辅色、强调色、中性色,各带具体色值)
* 六档字号(各带具体数值与适用场景)
* 字体方案(英文/中文各 1—2 款,带使用规则)
* 组件样式规则(圆角、阴影、间距、过渡、交互态,各档对应具体值)
* 关键设计决策的说明(为什么选这种主色、为什么这种字号阶梯)

这份清单是后续重建阶段的工作依据——所有实现细节都应能追溯到清单中的某条规则,不应在实现时凭感觉调整。

## 2.6 第三阶段:站点重建

### 2.6.1 重建的目标

**现场还原**:某次项目,客户在第三周验收时,说"看起来不太像"。负责人打开目标站和复刻站并排截图,发现首屏 80% 像,但底部 footer 颜色深了 5%,产品卡片的图片比例从 4:3 变成了 16:9。"看着不太像"的具体原因,是这两处 1—2 像素级别的差异,加上整站被这两处"焦点"拉低了整体观感。**"看着不太像"通常不是整体问题,是 2—3 处具体差异被放大**——找到这 2—3 处,问题就解了。

重建阶段的目标不是"做出一个看上去差不多的网站",而是"做出一个在所有验收项上与目标一致的网站"。"看上去差不多"是最低要求,真正的验收标准是 2.7 节列出的量化检查清单。

重建阶段的工作量通常占整个项目 60%—70% 的时间。在这一阶段,工程团队需要做大量决策:用什么语言实现、用什么框架搭建、是否需要后端、数据库怎么选、部署到哪里。这些决策中,只有少数真正影响业务结果;多数决策对最终用户无感,只影响工程团队的开发效率。

### 2.6.2 技术选型的原则

**现场案例**:某次复刻项目,工程师想用 Astro(较新的静态网站生成器)做,理由是"更快、更现代"。负责人问"你用过 Astro 吗",工程师答"用过,做过 1 个 demo 项目"。负责人接着问"用 Astro 调过 Tailwind + MDX 组合吗",工程师说"没有,只用了基础组件"。最终这个项目没用 Astro,改用 Next.js(工程师团队用过 8 个 Next.js 项目)——工期比预计的 Astro 方案少 2 天,bug 数也少 60%。**新工具的优势在学习成本面前不值一提**。

技术选型没有标准答案,但有三条原则:; **原则一,选团队熟悉的而非选最新的**。一个新框架比老框架多 20% 的功能,但团队学习成本可能多 100% 的时间。一个项目最贵的成本是"做错了重做",而"做错了"的最大来源是"用了不熟悉的技术"。

**原则二,选社区活跃的而非选功能最全的**。一个框架即使功能稍弱,但社区活跃意味着遇到问题时能搜到答案、有现成的插件可用、维护者仍在更新。一个功能极全但社区冷清的框架,半年后可能因无人维护而被迫迁移。

**原则三,选可被替换的而非选最完美的**。任何技术选型都是阶段性选择——技术会过时,需求会变化,当初的最优解五年后可能变成束缚。选型时应问"如果未来要换,迁移成本有多高",而非只看"当前能解决的问题有多完美"。

### 2.6.3 重建过程的几个决策点

**现场细节**:某次项目,负责人和工程师在"决策点三(是否需要后端)"上卡了 2 小时。原因是没有 CMS(内容管理系统),所有产品信息、客户案例都写死在代码里,客户每次想改文案都要找工程师。负责人最后在群里问客户一句:"您这边有没有同事懂 markdown 或 HTML?"客户答"我助理会用 WordPress 改文章"。于是项目加了"轻量 CMS + 后台"的方案,工期增加 4 天,但客户后续改文案的效率提升 10 倍——值。**看似技术的决策点,本质是"客户的工作方式"**。

**决策点一:静态还是动态**。如果目标网站内容更新不频繁(每周或更低的更新频率),且无个性化推荐、无用户登录、无实时数据,纯静态网站即可。静态网站部署简单、成本低、安全性高。如果内容更新频繁或需要个性化,再考虑动态方案。

**决策点二:自建还是用现成平台**。对于内容型网站(博客、企业官网),使用现成平台(Wix、Webflow、WordPress 等)比自建快 10 倍。对于复杂业务系统(电商、CRM 等),自建是唯一可行方案,因为现成平台无法满足业务定制需求。

**决策点三:是否需要后端**。如果仅展示静态内容,不需要后端;如果涉及表单提交、用户数据、订单处理,需要后端。后端是项目复杂度的主要来源,能不引入就不引入。。 **决策点四:部署在哪**。小流量(每日 1000 访问以下)使用静态托管(Vercel、Netlify、Cloudflare Pages)免费且简单。中等流量(每日 1000—10000)考虑云函数 + 数据库的组合。大流量(每日 10000 以上)需要专业运维,通常不会出现在复刻一个网站这类项目里。

### 2.6.4 重建中的常见问题

重建过程中,负责人踩过几个具体的坑,值得记下来。。 **坑一:纠结"从零写还是用开源",耽误了 2 天**。负责人一开始想"用 Next.js + Tailwind 从零搭",理由是"完全可控"。但他/她花了一整天搭基础工程之后,回头看产品列表页和详情页的代码,发现已经写了 600 多行,进展却很慢。第三天,他/她改用 Next.js Commerce 开源项目作为起点,把已有的 47 个页面逐一替换为自己的内容,只用了 4 天就完成了原本估计 18—22 天的工作。

教训:对通用型页面(列表、详情、博客这类),现成开源项目比从零写快 5—10 倍;判断标准是"这个页面是否有强定制",如果 80% 是通用模式、20% 是个性,就用开源作为起点。

**坑二:在复刻中"顺手优化",让验收变难**。重建到第三周时,负责人看原网站的某个交互逻辑不顺眼(下拉菜单的关闭时机不对,鼠标移出 0.5 秒就立即关闭,实际体验中常常误关),想"顺手改一下"。改完后客户验收时问"这个交互和参考站不一样,为什么?"。负责人答"我优化了一下",客户说"我没让你优化,请改回去"。

教训:**复刻就是复刻,改造是另一个项目**。任何在复刻中"顺手优化"的改动,都会让验收标准变得模糊——客户会问"这个和参考站不一样,是不是你偷懒了?"。改造的请求要单独提出、单独报价、单独排期。

**坑三:测试覆盖到 100%,时间翻倍**。负责人一开始想"既然要交付,就把测试写全"。写了 3 天测试,发现单元测试覆盖到 70% 时已经写了 200 多个用例,后续每加一个功能都要补 5—10 个测试。最后他/她和客户重新对齐:关键路径(用户最常走的 3—5 条流程:浏览首页→点击产品→查看详情→联系咨询)的测试必须写,长尾功能(管理员后台、内容搜索)用人工验证代替自动化测试。这样总测试数降到 50 个以内,完成时间回到预期范围。

教训:对复刻项目,关键路径必须有测试,长尾路径可以手工验证;追求 100% 覆盖会让项目时间翻倍,追求 0% 覆盖会让后期维护灾难,关键是**识别关键路径**。

## 2.7 第四阶段:量化验收

![视觉差异比对示意](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-b3950bfb2860d72654b2d9637be36f716cfe7c91%2Fai_coding_book_sec02_diff.svg?alt=media)

### 2.7.1 验收标准的三种形态

**现场还原**:某次复刻项目,客户验收时第一句话是"感觉不太像"。负责人当时没反驳,而是问"您能指给我看,哪里最不像吗?"客户点开首页,鼠标先滑到顶部导航,然后停在了主图下方的"立即咨询"按钮上——"这个按钮的颜色感觉怪怪的,不像参考站那么显眼"。负责人这才意识到,"感觉不太像"不是 80% 的问题,是这一个按钮的问题。**模糊反馈的背后通常只有 1—2 个具体差异**。

复刻项目的验收标准有三种形态,质量依次提升:; **形态一:主观验收**。客户打开网站,说"还行/不太行/完全不对"。这种验收方式因客户心情、当天状态、对项目的期待不同而波动,无法稳定执行。

**形态二:对比验收**。客户将产出网站与目标网站并排,逐项指出差异。这种方式比主观验收更稳定,但仍受客户审美与耐心影响,且容易陷入"这 1 像素的差异"。。 **形态三:量化验收**。事先定义可量化的检查项,逐项核对并记录是否通过。量化验收是项目可控的基础——所有争议都可以回到检查项的具体条目上。

### 2.7.2 量化验收的检查清单

**现场细节**:负责人用的检查清单 12 次复刻下来迭代了 4 版,目前的最新版是 28 项(2.7.2 节列出的 7 大类,每类拆 3—5 个子项)。这个清单的好处是——客户验收时不需要懂技术,只需要能说出"这条通过 / 不通过"。不通过的具体内容,工程团队按子项定位。

复刻一个网站的量化验收清单应包含以下七类检查项:; **第一类:布局一致性**。首屏布局与目标网站一致度 80% 以上(可使用视觉对比工具)。关键区块(导航、主体、底部)的位置一致。

**第二类:交互行为**。五项关键交互动作行为正确——点击主导航跳转、点击主按钮触发对应流程、表单输入与提交、登录与登出、移动端菜单展开与收起。。 **第三类:响应式适配**。三种典型设备(桌面 1440px、平板 768px、手机 375px)上均正常显示,无内容溢出、无元素错位。

**第四类:性能指标**。首屏加载时间(从用户点击到主要内容显示)在 3 秒以内。页面对搜索引擎友好(标题、描述、关键词设置正确)。。 **第五类:内容完整性**。所有目标页面均有对应内容,无空白页、无 404 错误、无图片缺失。

**第六类:链接有效性**。站内所有链接均可正常跳转,无死链。。 **第七类:数据正确性**。所有动态数据(价格、库存、文章列表)与目标网站当前状态一致。

### 2.7.3 验收流程

**现场案例**:某次项目,客户验收时发现产品详情页的图片加载不出来。工程团队检查后,发现是图片 URL 写错了——参考站用的是相对路径(`/products/001.jpg`),复刻站写成了绝对路径(直接复制参考站的 CDN 地址,这个地址在客户的域名下不可用)。这个问题是"数据正确性"检查项中的一条,但工程团队自检时漏掉了。**自检不能省,自检漏掉的恰恰是客户最容易发现的**。

验收分三步:第一步,工程团队自检——按清单逐项核对,发现的问题整改完成后再交付客户。第二步,客户验收——客户按清单逐项核对,记录未通过项。第三步,争议处理——未通过项中,如果有"目标网站本身不一致"或"验收标准描述不清"等特殊情况,由双方协商处理。

验收过程的纪律:不放过任何"差不多就行"。项目失控的常见起点就是"这个细节 80% 一样,先这样吧"——一旦开了这个口子,后续每一个细节都会被"先这样吧",最终交付物与目标网站差异巨大。

**教训**:验收流程最容易出问题的是第二步——客户验收时往往不愿意逐项核对,而是说"我大概看了一下,挺像的,通过吧"。这时候负责人会做一件事:把清单的 28 项按优先级重新排,前 5 项是"必须通过"(布局、5 项关键交互、响应式),其余 23 项是"应该通过"。客户至少要把前 5 项逐项过一遍。这个折中让验收既不流于形式,也不让客户负担过重。

### 2.7.4 验收报告

**现场细节**:负责人做的 12 次项目中,有 2 次在验收报告签字后,客户又提了 5—8 个修改请求。其中 1 次是"这个蓝色我再想想",另 1 次是"底部链接帮我加两个"。这两次都是"签字后修改",按合同应该作为新需求处理——但负责人当时没坚持,直接做了。后果是,客户养成习惯——"反正再加一两个改动,他会帮我做"。后续每次项目结束,客户都会"再提 5—10 个改动",负责人被这种隐性需求消耗了很多时间。**签字后修改必须重新计费,这条纪律不能破**。

验收阶段的产出是"验收报告",列明:

* 通过项(清单上的每项是否通过,附证据——截图、测试结果)
* 未通过项(未通过的具体项,附原因)
* 整改计划(未通过项的预计整改时间)
* 双方签字(确认验收结果)

报告的最后一栏"双方签字"是项目收尾的正式依据。客户在验收报告上签字,即代表客户认可当前交付物达到验收标准;签字后提出的任何修改,应作为新需求处理(可能涉及额外费用)。

## 2.8 交付与收尾

### 2.8.1 交付物清单

**现场还原**:某次项目交付时,负责人按清单把 5 份材料(源代码、部署说明、维护说明、设计文件、验收报告)打包到一个飞书文件夹,链接发给客户。客户当时只下载了源代码,没看其他材料。两周后客户来问"我这个怎么部署到正式环境?",负责人答"部署说明就在飞书文件夹里"。客户翻出来看,说"我之前没注意"。**交付不是"给了就完",是"客户能用到"**——交付时最好和客户逐项过一遍清单,确认每项都被点开看过。

项目交付时,应提供以下材料:

* 完整源代码(可托管在 GitHub、GitLab 等代码托管平台,客户可随时拉取)
* 部署说明(如何将代码部署到生产环境,通常是一份 Markdown 文档)
* 维护说明(常见问题、修改方法、联系支持的方式)
* 设计文件(配色、字体、组件样式的清单,见 2.5 节)
* 验收报告(2.7 节)

### 2.8.2 后续合作的可能性

**现场细节**:某次项目交付 3 个月后,客户来找负责人——"我们想加个新功能,大概要多少钱"。负责人当时报价 1.5 万,客户说"这么贵,我以前找的那个工程师 5000 就能做"。负责人答"5000 做出来的,可能您还要再花 1 万修他做的"。客户后来还是选了负责人。**报价贵不贵,看的是"后续会不会再花一次"**——短期最便宜的方案,长期往往最贵。

交付后,客户可能有两种后续需求:一,小修改(文案修改、图片替换、小幅样式调整)——这类应在 1—2 天内响应,通常包含在原合同中。二,二次开发(新功能、性能优化、二次设计)——这类是新项目,应按新需求评估与报价。

工程伦理:交付后的代码所有权应明确。多数情况下,代码所有权属于客户(客户已为开发付费);但在某些合作模式中,工程团队保留代码作为方法论资产的权利(例如"我们开发的这个通用模板,可以在其他项目中使用")。这一约定应在合同中明确。

## 2.9 方法论提炼与可复用资产

**现场还原**:本章方法论的五个原则不是一次性总结出来的,而是负责人在 12 次复刻项目里逐步沉淀的。前 3 个项目结束时,负责人写的是"心得体会";第 4 个项目时,他/她开始把"踩过的坑"和"教训"对应起来;到第 8 个项目时,五个原则已经基本成型;第 9—12 个项目就是用这五个原则去验证——能用就用,不能用就改。**方法论是项目经验的浓缩,不是项目开始前的预设**。

本章的方法论可提炼为五个原则,适用所有委托型项目。。 **原则一:用一段话把对方的真实诉求说回来**。在动手之前,先用自己的语言把客户的需求复述一遍,确认双方理解一致。这一步省下的时间,远大于它本身花费的时间。

**原则二:把模糊需求变成可验收的中间产物**。客户说"差不多就行"是项目失控的起点;把"差不多"翻译成"五项关键交互行为正确 + 80% 布局一致"等可量化标准,争议即可消除。

**原则三:小步交付,每一步都可被验收**。不要等到第三周才让客户看到东西——每天或每周都应有一个可访问的中间产物。每一步都让客户有机会给出反馈,避免最后一周集中爆发修改。

**原则四:用过程工具代替直觉判断**。"看上去对"是不可靠的判断,"清单上的 28 项均通过"是可靠的判断。所有重要决策都应有可追溯的依据——技术栈选了什么、为什么、依据来自哪。

**原则五:边界清晰,争议可追溯**。每一阶段都有明确的输入与产出,争议可定位到具体阶段。验收报告上的双方签字,是项目收尾的正式依据。。 **可复用资产:本节的可复用资产是一张"需求诊断报告"模板**——任何委托型项目开工前,均应产出此报告。

**可复用资产二:量化验收检查清单**——本节 2.7.2 列出的七类检查项,可作为所有网站复刻项目的验收模板。

### 2.10.1 本章思考题

1. 如果你的复刻目标站有付费墙,你怎么处理?1)寻找替代源 2)客户授权 3)缩减范围 — 哪个更适合你?
2. 你团队的"侦察报告"平均页数是多少?少于 4 页说明什么问题?多于 7 页说明什么?
3. 客户给的"参考站"如果用了你们不熟悉的技术栈(如 Astro + Solid),是接活还是婉拒?判断标准是什么?
4. 2.7 节的验收标准是"首屏布局一致度 80% + 五项关键交互 + 三种设备"。你能在客户签字前用一句话复述出这三个数字吗?如果不能,说明验收标准还需要再具体。
5. 2.2.3 列了三个误区:"看着像"当标准、功能完整优先于体验、流程完整当作工作到位。你过去的项目踩过哪个?怎么改的?

### 2.10.2 本章延伸阅读

1. **\[书] 《设计中的设计》原研哉** — 复刻网站时,理解"设计意图"比像素级还原重要,建立"先蒸馏再动手"的产品视角 | 第 2 章
2. **\[工具文档] Firecrawl 官方文档** — 托管 API 型爬虫的代表,Map 先行、1 页 1 credit、stealth 5 倍价的计费口径 | 第 2 章
3. **\[工具文档] Google Stitch 2.0 介绍** — URL 逆向提取 Style Extraction 的官方资料,粘贴网址自动分析配色/间距/字体/组件样式 | 第 2 章
4. **\[文章] 蓝戒博客《让 AI 精准还原前端 UI 的新范式》** — 截图派失败模式清单:间距 24 写成 20、字号 16 写成 14 等 10 类常见错误 | 第 2 章
5. **\[文章] 5acxy《网站复制服务是什么?》** — 仿站行业工程验收六条:语义化、响应式四断点、首屏≤2 秒、多浏览器、交互还原、代码可维护性 | 第 2 章

## 2.10 完整提示词:复刻网站的全流程编排

以下提示词可直接复制到 Claude Code、Cursor、Cline 等支持 Agent 模式的工具中使用,适用于任何"复刻一个网站"的委托任务。提示词采用四件套结构——角色设定、任务描述、输入输出格式、边界约束——确保 AI 在执行时不会偏离方法论。

## 本章方法论:把模糊需求变成可验收的中间产物

复刻项目的本质是把客户的模糊诉求变成可验收的具体标准。本章的四个阶段(侦察—设计—重建—验收),每一段的核心工作都不是"执行",而是"把模糊变成具体"——把"照那个网站做一个"变成"5 个具体页面 + 80% 布局一致 + 5 项关键交互正确"的清单。客户的需求不会自己变清晰,工程团队的工作是主动推进这一转化。

下一章将进入"复刻一个 SaaS 系统"的复盘——把单个静态网站升级为带登录态的业务系统。技术复杂度上升,过程管理复杂度更高,但"把模糊变具体"的核心方法不变。