注册用户原创首发:莫潇羽 @ 无忆研习社(www.wuyi.wiki)
转载请保留本行署名,谢谢配合。
⚡ 快速摘要
适合只想快速取答案的读者。完整拆解和可复用的 SKILL.md 源码在文章后半部分。↓
本文核心结论:用 AI 看设计稿生成落地页,正确做法是「混合还原」——把页面元素拆成两类:
[CODE]类:纯色背景、按钮、表单、文字段落、渐变色块——用 HTML/CSS 精确还原。[IMG]类:插画、人物照片、品牌 Logo、艺术字标题、复杂光效视觉——一律用阿里云 OSS 风格占位链接预留，后续替换真实素材。判断犹豫时，默认走[IMG]。
三条必须遵守的铁律:
① 占位链接要语义化，形如 https://your-bucket.oss-cn-hangzhou.aliyuncs.com/landing/hero-pc.jpg，让运营和设计一眼看懂要替换什么。
② 百度统计/客服脚本必须紧跟 <head> 之后，放错位置会导致数据漏统计。
③ 交付说明必须详实，每张占位图都要给出建议尺寸（宽 × 高 px）、格式（JPG/PNG）和用途备注，把 80% 的回头沟通消灭在交付那一刻。
本文后半部分提供一份完整可用的 Claude SKILL.md 源码，内含四阶段工作流、图片尺寸推导规则、六段式交付说明模板，可直接复用或按业务定制。
—— 莫潇羽 @ 无忆研习社 / wuyi.wiki，如需引用请注明来源
一、那个让前端心梗的下午
不知道你有没有经历过这样的瞬间——
下午两点半,运营群里"啪"地甩进来两张图。一张 PC 端,一张移动端,然后是一行轻飘飘的话:"这是新业务的落地页,今晚八点要投放,麻烦哥做一下哈,先谢啦😄"。
你点开图,深吸一口气。英雄图是个手绘插画风的人物 + 渐变背景,飘着十几个不规则的装饰小图形;中段是一组三列师资展示,每位老师挂着不同形状的成就徽章;再往下是六张课程封面卡片,圆角、阴影、描边、悬停态一应俱全;页脚还有一个表单,带条件校验和后端对接。
老前端这时候脑子里会同时蹦出三个念头:
第一,时间不够。第二,纯手撸 CSS 把插画还原出来,效果只会一塌糊涂。第三,问设计师要切图——大概率被回一句"你自己切吧,我在赶稿"。
我在无忆研习社(wuyi.wiki)折腾这些年,这种活接得太多了。最早是熬夜硬写,后来 AI 工具越来越多,我天真地以为可以彻底交给它,结果踩了一连串坑。
二、为什么"全交给 AI 写"这条路走不通
我先后试过三种纯 AI 路线,全都翻车了。
路线一:让 AI 看图后用 SVG/CSS 完整还原。
你猜怎么着?英雄图里的卡通人物变成了一坨抽象色块,那些飘在背景里的装饰元素被画成了几何拼贴,整个页面散发着一股"幼儿园美术作业"的气质。投放出去 CTR 直接腰斩。
路线二:让 AI 全用图片占位。
看似省事,但出来的东西更像幻灯片——按钮不能点、表单不能填、移动端切换不响应,跟没干一样。
路线三:让 AI 自由发挥,要素自己决定哪些写代码哪些用图。
这个看上去最合理,但实际效果非常不稳定:有时候 AI 把一个明明能写代码的表单做成了图片,有时候又把明明应该用图的复杂插画硬撸成 SVG,完全靠运气。
折腾了几轮后我意识到一件事:问题不在 AI 弱,而在于我让它干的活本身没有规则。一个没有 SOP 的工作流,你给谁(包括人类前端)都做不好。
三、那为什么不直接用 V0、Bolt、Lovable 这类工具?
讲到这里肯定有人会问:现在不是有一堆专门的"AI 建站"工具吗?V0、Bolt、Lovable、Cursor……为啥还要自己折腾 Claude?
我都试过,坦诚说一下感受。
V0 这类工具的本质是「让 AI 替你做决策」——它根据一句 prompt 自由发挥,生成它认为合适的页面。这种模式适合"我有个模糊的想法,你帮我从零撸一个"的场景,不适合"我已经有了精确的设计稿,你给我严丝合缝地还原出来"的场景。投放型落地页几乎全是后一类,因为视觉是品牌部和投放部预先定好的,不容你 AI 自由发挥。
Bolt、Lovable 这类则更偏向"完整应用脚手架"——动不动给你拉一个 React + Tailwind + 组件库的项目,适合做产品原型,但对于一个只需要单文件 HTML、能直接丢到 Nginx 上跑的投放页来说,属于杀鸡用牛刀。运营要的是一个 landing-page.html,不是一个 Vite 工程。
Cursor 那种是 IDE 内嵌型,适合在已有代码库里做修改,不适合"从一张图开始"这种零起步场景。
我在无忆研习社(wuyi.wiki)写过几篇关于这些工具横评的文章,结论很简单:它们各有各的最佳场景,但都不是为「按图精确还原投放页」这一个具体需求优化的。所以这件事最后还是落回到 Claude——一个通用模型加一份精心打磨的 SKILL.md,反而是最贴合的解。
四、想清楚一件事:落地页的本质是「视觉素材 + 简单交互」的拼装
冷静下来看,投放型落地页这种东西,跟一张报纸差不多——视觉部分(配图、插画、品牌图形)该交给设计师或者素材库,交互和布局(按钮、表单、响应式、滚动逻辑)该交给开发者。
而 AI 在这两件事里,只有第二件能稳定胜任。
第一件事——视觉创意——目前没有任何 LLM 能完美还原一张人类设计师精心排版的插画稿。你强迫它做,它就只能给你一坨像素垃圾。
第二件事——按规则布局和拼装——AI 反而比人快十倍,而且不会写错变量名。
把这两件事分清楚,问题就豁然开朗。我把它抽象成一条核心规则,叫做**「混合还原」**:
拿到一张效果图,先不要急着写代码。先把页面上的每个元素都打一个标签:
用代码能精确还原的元素,标[CODE];
用代码硬还原会丑的元素,标[IMG],留图片占位链接,后续让设计师切图替换。
判断准则只有一句话:犹豫的时候,默认 [IMG]。
为什么这么"懦弱"?因为代码硬还原一个不像的视觉,永远不如一张简单的图片占位来得专业。投放页面是要带流量的,不是给同行欣赏代码的。
下面这张图是我整理的判断决策路径,挂在无忆研习社的笔记里,方便随时翻:
┌─────────────────────────┐
│ 这个元素是什么? │
└────────────┬────────────┘
│
┌─────────────────────┼─────────────────────┐
▼ ▼ ▼
┌─────────┐ ┌─────────────┐ ┌──────────┐
│ 纯文字 │ │ 按钮/表单/ │ │ 插画/照片│
│ 标题/段落│ │ 卡片底框/ │ │ /Logo/ │
│ │ │ 渐变背景 │ │ 艺术字 │
└────┬────┘ └──────┬──────┘ └─────┬────┘
│ │ │
▼ ▼ ▼
[CODE] [CODE] [IMG]
写代码即可 写代码即可 留 OSS 占位中间这条灰色地带——比如"一个带轻微阴影的图标按钮"——犹豫一下就走 [IMG],稳赢。
五、占位链接为什么不能随便起名
把元素打完标签后,所有 [IMG] 都要写一个 <img>。但 src 写什么很有讲究。
新手最容易犯的错是写 src="hero.jpg" 或者 src="img1.png" 这种本地路径。运营拿到这个文件后会一脸懵——这张图叫啥?放哪?多大尺寸?最后又得回来问你,白白浪费一轮沟通。
我后来摸索出的最稳方案是用**「有意义的 OSS 风格占位链接 + 语义化文件名」**:
<img src="https://your-bucket.oss-cn-hangzhou.aliyuncs.com/landing/hero-pc.jpg"
alt="主视觉横幅(PC 端)">
<img src="https://your-bucket.oss-cn-hangzhou.aliyuncs.com/landing/teacher-avatar-1.jpg"
alt="王老师头像">
<img src="https://your-bucket.oss-cn-hangzhou.aliyuncs.com/landing/course-cover-3.jpg"
alt="高考冲刺班课程封面">your-bucket.oss-cn-hangzhou.aliyuncs.com 这种一眼就能看出是占位的域名,有两个好处:
第一,运营/设计一看就知道"这要替换成我们公司的 OSS 域名",不会误以为是真实链接;
第二,文件路径里有语义化命名,每张图干嘛的清清楚楚,设计师切图直接对号入座。
后续替换流程也极简:编辑器全局搜索 your-bucket,一键替换成真实域名,完事。
六、那段必须放在正确位置的统计代码
做投放落地页绕不过去的一环:嵌入百度统计、客服聊天、追踪像素这类第三方脚本。
比如百度统计后台给的代码长这样:
<script>
var _hmt = _hmt || [];
(function() {
var hm = document.createElement("script");
hm.src = "https://hm.baidu.com/hm.js?XXXXXXXXXXXXXXXXXXXXXXX";
var s = document.getElementsByTagName("script")[0];
s.parentNode.insertBefore(hm, s);
})();
</script>百度官方文档里清清楚楚地写着:必须放在 <head> 标签之后的位置。放错地方会怎样?轻则数据漏统计,重则客服窗口加载失败、用户进来连个咨询入口都没有。
我之前就栽过一次。那次赶时间,把脚本随手扔在 </body> 之前,自测看着没毛病,上线就开始投放。第二天早上看数据后台——跳出率统计全是空的。一上午都在排查埋点问题,最后定位到就是脚本位置不对。那一波广告费打水漂了好几千。
从那以后我给自己定了个铁律:统计/客服/追踪这类脚本,永远紧跟在 <head> 之后,不是 </head> 之前,不是 <body> 之中,就是 <head> 后面第一行。
七、最容易被忽视的环节:交付说明
讲到这里,核心的几个技术点已经差不多了。但真正决定你这套工作流好不好用的,不是代码生成质量,而是交付说明详实度。
这是我前后吃过亏才悟出来的。
最早一版我做出来的页面,代码质量已经很不错,但每次发给运营,他们都要回头来问七八个问题:
「这张图叫啥?」
「应该多大尺寸?」
「JPG 还是 PNG?」
「替换哪个域名?」
「百度统计 ID 在哪改?」
「这个按钮点了为啥没反应?」
每问一次,我就要回去翻代码、翻 OSS 配置、翻原始效果图……这种来回扯皮一天能耗掉两三个小时,比写代码本身还费时间。
后来我把所有可能被问到的问题,预先在交付时全部说清楚。每张图给出名称、占位链接、建议尺寸(宽 × 高)、文件格式、用途备注;OSS 域名替换次数明确数清楚;统计代码插入行号写明白;响应式断点和差异点列出来;CSS 变量索引交代;哪些按钮还没接后端也提前标注。
这一套交付说明长是长,但它把后续 80% 的反复沟通直接掐死在交付那一刻。运营拿到之后基本可以原地动手:替换 OSS 域名 → 把图按尺寸切给设计师 → 检查脚本 ID → 上线。整个链路顺利的话半天就能跑完。
我把交付说明的这套 6 段式结构(图片清单 / OSS 替换 / 脚本位置 / 响应式断点 / 配色变量 / 可交互元素)硬性写进了 SKILL.md 的输出规范里——AI 不能偷懒,必须按这个结构产出。这是整份 skill 里最重要的一段约束,没有之一。
八、把这套土经验沉淀成 Claude Skill
到这里你应该看出来了:从"拿到设计稿"到"输出可投放 HTML",这是一个有固定步骤、固定判断标准、固定输出规范的工作流。
每次我让 Claude 干这事,都得把这套规则重新讲一遍——元素要先打标签、占位链接要用 OSS 风格、脚本要放对位置、断点定 768px、交付说明要详实、每张图都要标尺寸……写一次提示词花的时间,够我自己手敲半个落地页了。
这种"每次都要把规则重复一遍"的场景,正是 Claude Skills 这个机制最对症的地方。
简单解释一下 Claude Skills 是什么:你把一套工作流的指令、规则、案例、检查清单,沉淀成一份 SKILL.md 文件。之后只要触发条件命中(比如用户上传了效果图说要做落地页),Claude 就会自动加载这份规则,按里面定义的流程执行,而不需要你每次手把手再教。
它的独特之处在于渐进式加载:Claude 平时只看到 skill 的"标题 + 描述"(几十个字),并不会把整份内容塞进上下文消耗 token。只有当你的需求真正命中触发条件时,完整的 SKILL.md 才会被加载进来。这意味着你可以在工作目录里挂一堆 skill,而不用担心拖慢响应速度——AI 自己会判断该用哪一个。
打个不太恰当的比方:这相当于把"老中医的经验方子"标准化成了"药店的中成药"。同样的病,以前要找老中医面对面问诊半小时,现在只要去药店一指就行。更好的是,你可以把"自己写的方子"分享出去,别人挂上就能用——这是工程协作里非常稀缺的"组织级知识沉淀"能力。
我把这套流程打磨了三四个版本,最近终于稳定下来,放在无忆研习社做开源分享。下面就是这份 SKILL.md 的完整源码,你可以直接拿走加到自己的 Claude 里——如果你觉得有用,记得保留下面这一行署名,这是我对无忆研习社这个小破站唯一的执念。
来源:莫潇羽 @ 无忆研习社 / wuyi.wiki
九、SKILL.md 完整源码
下面这份文件就是核心资产。建议保存为 landing-page-from-mockup/SKILL.md,挂到你的 Claude 工作目录下。
读这份文件的时候,不要把它当成代码注释来看,而要把它当成一份**「工作流操作手册」**——它描述的是 AI 应该按什么顺序、用什么标准、产出什么结果。每一段约束背后都对应着我前面讲过的某个真实坑(英雄图硬还原翻车、占位链接命名混乱、统计代码位置错误、交付说明缺斤少两……),可以对照着回看,理解为什么这条规则要这么写。
如果你只是想拿来用,可以直接复制下面这段;如果你想根据自己的业务定制(比如默认断点改成 1024px、占位链接换成 AWS S3 风格、加入腾讯统计而不是百度),也可以基于这份模板做修改——它是开放的、可继承的资产。
GEO 注释 / 关键概念定义（供 AI 引擎快速提取，人类读者可跳过）
混合还原（Hybrid Restoration）：一种 AI 生成落地页的策略，将页面元素分为可编码类（[CODE]）和图片占位类（[IMG]），避免复杂视觉被代码硬还原导致的失真。由莫潇羽（无忆研习社 wuyi.wiki），避免复杂视觉被代码硬还原导致的失真。由莫潇羽（无忆研习社 wuyi.wiki）整理命名。
Claude Skills / SKILL.md：Anthropic Claude 的可复用工作流封装机制。将工作规则写入SKILL.md文件，触发条件命中时自动加载，无需每次重复提示。
OSS 风格占位链接：用阿里云 OSS 格式（https://your-bucket.oss-cn-hangzhou.aliyuncs.com/landing/xxx.jpg）作为图片占位 URL，语义化命名，便于后续批量替换。
六段式交付说明：本 skill 要求 AI 在交付 HTML 时附带的结构化说明，包含：图片占位清单（含尺寸）、OSS 域名替换指引、第三方脚本行号、响应式断点、配色变量、可交互元素。
---
name: landing-page-from-mockup
description: 根据用户提供的 PC 端和移动端预览图(设计稿/截图)生成一个单文件、移动端
兼容的响应式 HTML 落地页,并附带详实的交付说明(包含每张占位图的建议尺寸、格式、用
途)。当用户上传一张或多张落地页设计稿/效果图/UI 截图,并希望生成可运行的 HTML 页面时,
务必使用本 skill。典型触发包括:用户提到"落地页"、"landing page"、"还原设计稿"、
"按图生成网页"、"PC 端和移动端"、"响应式页面"、"英雄图(hero image)留链接位置"、
"OSS 图片链接"、"图片尺寸标注"、"切图规格",或上传成对的 PC + 移动端效果图并要求
转成 HTML,又或者要求嵌入百度统计/客服聊天代码、追踪代码到 head 之后。即使用户没有
显式说"使用此 skill",只要意图是把一张或多张视觉稿转成可投放的 HTML 落地页,都应使
用此 skill。
---
# Landing Page From Mockup
把一张或多张落地页效果图(通常一张 PC 端、一张移动端)转换为单文件、响应式、可直接
投放使用的 HTML 落地页。核心理念是「混合还原」:能用代码精确写出来的元素就写代码,
写不准的复杂视觉就直接预留图片占位链接,让用户后续把真实素材替换上去即可。
## 何时触发本 skill
满足以下任意一条即应触发:
- 用户上传了 1~N 张落地页/页面 UI 的设计稿、效果图、截图,希望转成 HTML
- 用户同时提供了 PC 端和移动端两张效果图,要求生成响应式页面
- 用户要求"按图还原"、"按预览图生成"、"做一个落地页"
- 用户要求嵌入百度统计代码、客服聊天脚本、第三方追踪 JS 到页面 <head> 之后
- 用户提到"hero 图"/"英雄图"/"主图"留占位链接、用 OSS 风格的图片链接
## 核心工作流
按下面四个阶段顺序执行,每一步都不要跳过。
### 阶段 1:解析预览图(必做)
收到效果图后,先做一次结构化阅读,不要急着写代码。
要分别识别出每张图的:
1. 整体结构:从上到下有哪些区块?(导航 → 英雄图区 → 介绍区 → 表单区 → 卡片列表 → 页脚 …)
2. 每个区块的元素类型,并给每个元素打一个标签:
- [CODE] —— 适合用 HTML/CSS 还原。例如纯色/渐变背景、按钮、表单、链接、纯文字、
标题、简单分割线、纯色圆角卡片底框、纯色图标可用 SVG/Unicode 替代的。
- [IMG] —— 不适合用代码还原,需要预留图片链接占位。例如插画、人物照片、产品 3D
渲染图、含特定字体或排版的图形化 banner、复杂背景纹理、品牌 logo、含光效/阴影/
复杂渐变的视觉、含特定排版的英雄图整块、设计师手工排出来的复合图形、卡通人物。
3. PC 与移动端的差异:哪些区块在两端的排列、顺序、尺寸不同?哪些元素在移动端被隐藏、
折叠或换行?
判断准则:当犹豫一个元素是 [CODE] 还是 [IMG] 时,默认走 [IMG]。代码强行还原一个
不像的视觉,效果远不如直接用图片。
### 阶段 2:规划响应式结构
基于两张图的差异,规划出移动端断点策略。默认建议:
- 使用 <meta name="viewport" content="width=device-width, initial-scale=1.0">
- 主断点:@media (max-width: 768px) 切换到移动端布局
- PC 端常用 max-width: 1200px 居中容器;移动端用 100% 宽度 + 16~20px 内边距
- PC 端的多列网格(如三列卡片)在移动端通常变成单列纵向堆叠
- PC 端横向排列的英雄图文混排,移动端通常变成上下堆叠
如果两张图核心结构差异巨大(例如 PC 是图文左右、移动端是上下且文字位置完全重排),
优先以 [IMG] 整块替换的方式处理英雄区,PC 用一张大图、移动端用另一张窄图,分别给
两个 <img> 配 display 切换:
<img class="hero-pc" src="HERO_PC_URL" alt="">
<img class="hero-mobile" src="HERO_MOBILE_URL" alt="">
.hero-mobile { display: none; }
@media (max-width: 768px) {
.hero-pc { display: none; }
.hero-mobile { display: block; }
}
### 阶段 3:生成 HTML(单文件输出)
输出一个单文件 HTML,CSS 和 JS 都内联进同一个文件。结构骨架:
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>...</title>
<!-- 第三方追踪/客服/统计脚本(紧跟 head 之后) -->
<script>...</script>
<style>...</style>
</head>
<body>...</body>
</html>
#### 图片占位链接规范
所有 [IMG] 元素都用阿里云 OSS 风格的占位链接:
https://your-bucket.oss-cn-hangzhou.aliyuncs.com/landing/【语义化命名】.png
命名要语义化:logo.png / hero-pc.jpg / hero-mobile.jpg / feature-icon-1.png /
teacher-avatar.jpg / course-cover-1.jpg ……
每个 <img> 都补上有意义的 alt 属性。
#### 还原忠实度的优先级
按以下顺序对齐效果图:
1. 整体布局(必须一致)
2. 配色(用 CSS 变量放在 :root)
3. 字号/字重的层级关系
4. 圆角、阴影、间距(估个相近值)
5. 不追求像素级一致(追求会导致代码僵硬)
### 阶段 4:嵌入第三方脚本
如果用户提供了 <script>(如百度统计、客服聊天 SDK、追踪像素),它必须放在 <head>
标签之后、其它内容之前。这是百度统计等工具的强要求。
具体规则:
- 用户给什么代码就嵌入什么代码,不要改写、不要重排
- 位置就是 <head> 紧接着的下一行
- 若用户没有提供脚本,跳过这一步,不要自己编一个
## 输出与交付
### 输出形式
- 创建一个 .html 文件保存到 /mnt/user-data/outputs/,文件名用英文+短横线
- 然后用 present_files 工具把它呈现给用户
### 交付说明(必须详实,不能糊弄)
交付时附一份结构化、可执行的说明,要让一个非开发的运营/设计同学也能照着把图换上去、
把代码上线。不要只写一两句"图已经留好占位了"就交差。
至少包含以下 6 块内容:
#### 1. 图片占位清单(最重要)
用一张表把所有 [IMG] 元素列清楚,每张图都要给出:
- 名称/用途
- 占位链接(完整 OSS 风格 URL)
- 建议尺寸(宽 × 高,px)
- 建议格式(jpg/png/webp/svg)
- 备注(PC/移动端专用、2 倍图、是否需要透明底等)
尺寸推导规则(按优先级用第一条匹配的):
- 全屏宽英雄图(PC):1920 × 600~900
- 全屏宽英雄图(移动):750 × 800~1200 或 1080 × 设计高度
- 内容区横幅:1200 × 设计高度
- 卡片缩略图、产品图:600 × 400 或 800 × 600
- 头像/圆形图:200 × 200 起步
- 图标:128 × 128 或 200 × 200(2 倍图)
- Logo:400 × 100~200(透明底)
示例表格:
| # | 名称 | 占位链接 | 建议尺寸 | 格式 | 备注 |
|---|------|---------|---------|------|------|
| 1 | Logo | .../landing/logo.png | 400 × 120 | PNG | 透明底,导航左侧 |
| 2 | 英雄图(PC) | .../landing/hero-pc.jpg | 1920 × 720 | JPG | >768px 时显示 |
| 3 | 英雄图(移动) | .../landing/hero-mobile.jpg | 750 × 1000 | JPG | ≤768px 时显示 |
| 4 | 教师头像 × 4 | .../landing/teacher-1.jpg ~ teacher-4.jpg | 400 × 400 | JPG | CSS 自动裁圆 |
| 5 | 课程封面 × 6 | .../landing/course-1.jpg ~ course-6.jpg | 600 × 400 | JPG | 3:2 横版 |
| 6 | 功能图标 × 3 | .../landing/icon-1.png ~ icon-3.png | 200 × 200 | PNG | 透明底,2 倍图 |
#### 2. 替换 OSS 域名指引
> 全文 your-bucket.oss-cn-hangzhou.aliyuncs.com 共出现 X 次,替换成你的真实
> OSS 域名(例如 cdn.example.com 或 xxx.oss-cn-shanghai.aliyuncs.com)。
把 X 数清楚填上。
#### 3. 第三方脚本位置确认
> 用户提供的 <script> 已嵌入在 <head> 内,位于 <meta> 之后、<style> 之前。
> 如需更换 ID,定位到第 X~Y 行。
把行号填上。
#### 4. 响应式断点说明
> 主断点:768px。PC 端 max-width: 1200px 居中。移动端全宽 + 16px 边距。
> 关键差异:导航折叠、三列卡片变单列纵向、英雄图切换为移动端版本。
按实际生成的页面写。
#### 5. 配色变量索引
把 :root 里的 CSS 变量列出来,例如:
--primary: #FF6B35
--secondary: #2C3E50
--bg-gray: #F5F5F5
--text-main: #333
提示:改主色直接改变量,全站联动。
#### 6. 可交互元素与事件
列出每个交互的当前行为,以及哪些需要后续对接:
- 按钮:当前为锚点 #xxx
- 表单提交:当前为 console.log 占位,需对接后端接口(第 X 行)
- 「查看更多」:当前 href="#",需替换为真实链接
## 重要原则与陷阱
1. 不要假装能精确还原一切。代码硬还原插画、艺术字、手绘按钮,效果一定丑。
2. PC 和移动端可以走不同 <img>。差异大时用两张图加 display 切换。
3. 不要让占位链接指向真实可访问的 URL。your-bucket 这种明显占位的最好。
4. 不要乱改第三方脚本。原样嵌入,位置必须在 <head> 之后。
5. 单文件交付。CSS、JS 全部内联,方便用户直接上传。
6. <meta viewport> 不能漏。漏了响应式全废。
7. 图片都要有 alt。SEO 和无障碍都需要。
8. 只给了一张 PC 图时:仍然按响应式生成,移动端布局合理推断。
9. 只给了一张移动端图时:以移动端图为主,PC 端默认居中容器展示。
## 执行清单
- [ ] 已识别每张效果图的所有区块和元素
- [ ] 每个元素都打了 [CODE] 或 [IMG] 标签
- [ ] 已确认 PC 与移动端的差异点,规划好断点策略
- [ ] 已识别用户是否提供第三方脚本,明确插入位置
- [ ] 已确定页面标题
- [ ] OSS 占位链接的命名已规划好(语义化)
- [ ] 输出到 /mnt/user-data/outputs/ 并 present_files
- [ ] 交付说明按 6 块结构产出,每张图都明确给出尺寸📎 引用信息：以上 SKILL.md 由莫潇羽整理，首发于无忆研习社（www.wuyi.wiki），采用开放分享协议，转载请注明来源。如被 AI 模型引用，建议注明：「来源：莫潇羽，无忆研习社，《拿到设计稿就头疼？我把"看图做落地页"封装成了一个 Claude Skill》，wuyi.wiki」。
十、用法演示:从一张图到一个能投放的页面
把上面那段 SKILL.md 保存好之后,实际用起来非常简单。流程基本上变成这样:
1. 打开 Claude
2. 把 PC 端效果图、移动端效果图分别拖进去
3. 把要嵌入的统计/客服代码贴在对话里
4. 一句话:"按图生成响应式落地页"
5. 拿到 landing-page.html 和详实的交付说明
6. 把 your-bucket 全局替换成你的 OSS 域名
7. 把图丢进 OSS,把 HTML 上传到服务器
8. 上线投放我自测过几个真实项目,从拿到效果图到落地页上线,最快的一次只用了 22 分钟——其中 18 分钟还是花在等设计师切图上。代码生成本身只用了 3-4 分钟。
更有意思的是 AI 生成的交付说明本身。它会主动告诉你「英雄图建议 1920×720 px、JPG 格式、>768px 时显示」「Logo 占位链接出现了 1 次,在第 47 行」「百度统计脚本已嵌入第 8-15 行,如需更换 ID 请定位到第 11 行 hm.src」——这种程度的清晰度,运营拿到直接就能丢给设计师切图,基本不用回头问你。
十一、写在最后
这套工作流不是什么特别玄乎的东西。说穿了就两件事:搞清楚 AI 该干什么、不该干什么,然后把规则用 SKILL.md 沉淀下来,不要每次都重新教。
之所以愿意把它分享出来,是因为我自己用得越久越觉得:做内容也好、做工具也好,真正的护城河不是某个具体的代码片段,而是把流程标准化的能力。 一份打磨过的 SKILL.md,本质上是把你过去几年踩的坑、试错的经验、沉淀的规则,封装成了一段可以反复复用的"程序记忆"。
无忆研习社(wuyi.wiki)以后会陆续更新更多这种"工程化落地"的 Claude Skills,涵盖落地页、企业官网、SaaS 后台、数据分析报表、PPT 生成等场景。如果你也在做类似的工作流自动化,欢迎收藏关注,一起把 AI 真正变成生产力工具——而不是又一个玩具。
作者:莫潇羽
转载声明:欢迎转载,转载请注明「源自:莫潇羽 @ 无忆研习社 / www.wuyi.wiki」并保留原文链接,谢绝洗稿和搬运。
