GPT-5.6 Sol + Codex 做电影感网站：这 12 个技巧比模型本身重要

我见过太多用 AI 生成的网站了。

不是说它们丑——有些确实挺好看的。但它们都有一种说不清道不明的"同质感"。字体是那几个字体，配色是那几种渐变，动效是那几种粒子飘浮或者文字淡入。你看第一眼觉得"哇 AI 好厉害"，看第十眼就觉得"又是这个味儿"。

直到我看了 Viktor Oddy 这段 21 分钟的视频。

他用 GPT-5.6 Sol 搭配 Codex 做了一个电影感的 Web Design Agency 网站。整个过程最让我震撼的不是最终成片——而是他把**参考收集、图片生成、视频动效、前端实现、性能优化串成了一条完整流水线**，而且每一步都有明确的输入约束和验收标准。

这篇文章是我对着视频逐帧记笔记之后整理出来的。12 个关键技能，每一個都是我之前不知道或者一直在错误使用的东西。

## 为什么大多数人的 AI 建站都长得像模板

先说一个可能有点得罪人的观察。

大部分人用 AI 建站的方式是这样的：打开 ChatGPT 或者 Cursor，输入"帮我做一个高级的电影感网站首页"，然后拿到一段代码，贴进去，完事。

出来的东西不能说不能用。但它缺了一样东西——**决策链条**。

一个真正好的设计作品背后有一连串人为选择：为什么是这个比例而不是那个？为什么字体用这个字重？为什么这里留这么多白那里却塞得很满？为什么动效是这个节奏而不是快一倍？

当你只给 AI 一句模糊指令时，所有这些选择都被模型用"最大概率平均值"替你做了。结果就是——**永远正确，但也永远平庸**。

Viktor 的方法完全不同。他不是丢一句需求等结果。他是先把每一个审美和技术决策都想清楚，然后把这些决策翻译成 AI 能执行的精确约束。

区别就在这儿。

## 参考阶段：90% 的人第一步就错了

### 技巧 1：先找参考，再让 AI 动手

视频开头做的第一件事不是打开任何 AI 工具，而是去 **Pinterest、SeeSaw、Land-book** 这些设计灵感网站逛。

听起来很基础对吧？但你想想自己上次建站的时候是不是跳过了这一步。我承认我自己经常跳——总觉得"我跟 AI 说清楚不就行了"。

问题是，"高级""电影感""未来感"这些词在不同人甚至不同模型眼里完全是两回事。你说"电影感"，AI 可能理解成暗色调；另一个模型可能理解成宽银幕比例；还有一个可能给你加一堆光晕特效。

有了参考图就不一样了。版式比例是可见的、留白方式是可见的、色彩关系是可见的。这些东西从主观形容词变成了客观约束。

**实操建议：每次准备三类参考——一张管布局、一张管装饰元素、一张管配色。不要让一张图承担所有要求。**

### 技巧 2：把参考图拆成独立设计变量

这是我觉得整段视频里**最有方法论价值的一个操作**。

Viktor 没有找一张喜欢的网站然后让 AI "照着这个做"。他找了三张不同的图：
- 第一张 → 只取它的 Hero 区域结构
- 第二张 → 只取它的圆形轨道装饰元素
- 第三张 → 只取它的色板

然后在自己的项目里重新组合。

为什么这么做？因为他不想让 AI 猜。"这张图哪些要保留、哪些要替换"这个问题一旦交给模型，结果就是不可控的。但如果你的指令是"布局参考 A，装饰参考 B，颜色参考 C"，AI 的任务边界就清晰多了。

我测试了一下这个方法。同样的需求，"照着这张图做"和"分别参考这三张图的三个方面来做"，后者的输出质量和可控性明显更高。临摹感大幅降低。

### 技巧 3：像给初级设计师写 Brief 一样写图像提示词

视频里 Viktor 上传参考图到 ChatGPT Images 时的提示词写法值得逐字学习。他不是写一句"生成一个高级网站 Hero"。他是这样说的：

- 以第一张图为布局参考
- 把主题改成网页设计机构
- 将原有花朵元素替换为圆形视觉
- 让装饰自然处于文字后方
- 采用另一张参考图的色彩方案
- 把品牌文字替换为目标项目名称

看到了吗？每一条都是一个**明确的操作指令**，而不是模糊的形容词。参考关系说清楚了、替换规则说清楚了、图层关系说清楚了、最终用途也说清楚了。

而且他会一次生成多个方案然后从中挑选。不是拿第一个结果当成品。

**这比大多数人写提示词的方式高效太多了。** 大多数人的提示词是一堆华丽辞藻的堆砌："惊艳的、沉浸式的、具有未来感的、令人印象深刻的……"AI 听了一脸茫然。 Viktor 的方式是告诉它做什么、怎么做、用什么材料做。

### 技巧 4：先把带文字的设计稿清理成纯背景

这一步太重要了但我之前从来没想过。

当 AI 生成的设计稿里包含了标题文字、按钮、Logo 的时候——**不要直接把它当成网页背景图用**。

原因很简单：网页上的文字应该由 HTML 和 CSS 渲染。这样才能保证清晰度（矢量 vs 位图）、响应式（文字大小随屏幕变化）、可访问性（屏幕阅读器能识别）、SEO（搜索引擎能索引）。如果文字已经烘焙进了背景图片，你再在上面叠一层真实的 HTML 文字，就会出现重复、错位、移动端溢出等一系列问题。

Viktor 的做法是继续要求图像模型：**输出同样构图的 8K 背景，移除所有文字按钮 Logo，保持物体位置不变。**

提示词骨架我都帮你整理好了：

> 保留当前构图、颜色和物体位置，移除所有文字、按钮与 Logo，输出干净的网页背景。不要改变镜头距离，不要放大或裁切主体。

## 从静态图到动态背景：动效生成的正确姿势

### 技巧 5：用参考视频定义运动，别只说"让它动起来"

拿到干净的背景图之后，下一步是让它动起来。

视频里用的是 **Higgsfield 平台的 Seedance 2.0**，也提到 Kling AI 作为备选。但工具选择不是重点——重点是**怎么描述你想要的运动**。

Viktor 的做法不是简单地输入"Animate this image"。他是：
1. 先尝试简单动画看看基础效果
2. 然后加入一段参考视频，要求新画面的运动方式与参考一致
3. 特别强调：不要缩放镜头、不要推进、保持原有构图

参考视频的作用是**缩小随机性的范围**。生成式视频模型的输出天生不稳定——同样的提示词跑十次可能得到十种完全不同的运动轨迹。有了参考视频，至少运动的方向感和节奏感能被锚定住。

但视频也很诚实地展示了局限性：**即使给了参考视频，结果仍然可能不符合预期**。Viktor 就当场放弃了一个不合适的版本。

所以这里的实操建议是：**每个项目生成至少 3-4 个短版本**，逐一检查四个指标——运动方向自然吗？循环接缝平滑吗？主体稳定不变形？镜头有没有意外推进？任何一个不过关就直接换，别试图通过修改提示词挽救一个方向就错的素材。

## 给 Codex 下指令：减少歧义比增加细节更重要

### 技巧 6：交给 Codex 之前先清理设计稿

进入编码阶段之前，Viktor 做了一个很多人会忽略的操作：他在 **Figma 里把设计稿中不需要实现的装饰元素隐藏或删除了**，然后再导出 PNG 交给 Codex。

理由很直接：**输入越复杂，Codex 越要花精力猜测"哪些要实现、哪些只是参考"**。

我之前犯过这个错。丢一张复杂的全屏设计稿给 AI，里面既有必须实现的导航栏结构，也有仅供参考的光效装饰，还有只是示意用的占位图标。结果 AI 要么全部试图实现（产出过度工程化的代码），要么搞混了优先级（把装饰当成了核心功能）。

把设计稿清理到只剩当前要实现的结构，相当于给开发任务建立了一份**最小可执行规格**。这个习惯能省掉大量后续返工的时间。

### 技巧 7：锁定字体、颜色和背景，拒绝默认值

AI 有一个特别烦人的倾向：喜欢用最安全最常见的选项。

字体？默认用 Inter 或系统无衬线体。颜色？默认给个蓝紫渐变。背景？来点微妙的灰色或者浅色 pattern。

Viktor 的应对方式是在第一轮指令里就把这些**设计令牌全部锁定**：

- **Typography**：明确字体名称（比如从 Google Font 选定的具体字体）、字重和使用位置
- **Color**：给出精确的十六进制值（#00FF88 这种），不说"亮绿色"
- **Surface**：明确是纯黑 #000000 还是深灰 #111111，不让模型自己加渐变
- **Contrast**：说明正文、辅助文字和按钮之间的对比关系

只要这几项在首屏阶段锁死，后续扩展页面时视觉一致性就会好很多。否则你可能遇到这种情况：Hero 区域看着挺有感觉，往下滚到 Features 区域突然感觉换了一个人做的。

### 技巧 8：先做 Hero，通过了再做剩下的

又一个反直觉的习惯。

很多人给 Codex 的指令是"帮我做一个完整的网站首页"。Viktor 不这么干。他的第一轮任务是：**只实现 Hero Section，只做首屏**。

等首屏的结构、字体、视觉方向确认没问题了，才要求继续增加 4-5 个区域（Features、Testimonials、Cards、About、Process）。

这是一种极低成本的试错机制。如果首屏方向错了——只需要修改一个区块。如果一次性生成整站之后才发现字体不对、间距奇怪、整体风格跑偏——模型往往需要大范围返工，而且在修改过程中还可能破坏已经可用的部分。

推荐的 Codex 交互节奏：**首屏结构 → 首屏视觉细节 → 视频背景集成 → 其余内容区块 → 独立内页 → 移动端适配检查**。每轮只引入一个新的主要变量。

### 技巧 9：告诉 Codex "不要做什么"

当 Viktor 把生成的视频加入 Hero 背景时，他在指令里明确写了：**不要添加任何 Overlay（遮罩层）**。

为什么？因为开发模型有一个"好心办坏事"的习惯——检测到你用了视频做背景，为了确保上面文字可读，自动给你加一层半透明黑色遮罩。问题是这层黑幕会严重削弱原本精心设计的色彩和光感。

正确的做法是：**重要的视觉决策不能留给模型猜**。画面本身已经为文字预留了空间？那就禁止遮罩。对比度真的不够？那你明确指定遮罩的颜色、透明度和作用区域——而不是接受一层默认的黑幕。

## 分阶段交付：别一次让 AI 生成整个网站

前面已经提到了"先 Hero 后整站"的原则。这里补充一些视频中的具体细节。

### 视觉融合的技巧

当需要在功能卡片里嵌入视频素材时，Viktor 遇到了一个问题：视频底色和卡片背景不协调。他的解决路径很有意思——**先在 Figma 里快速试验各种 CSS 混合模式**，确认 `mix-blend-mode: exclusion` 效果合适之后，再把参数写给 Codex 实现：

.capability-video {
width: 150%;
height: auto;
object-fit: contain;
mix-blend-mode: exclusion;
}

注意这里的思维顺序：不是先写代码再看效果，而是先在可视化工具里验证效果再写代码。exclusion 不是万能的——不同素材可能需要 screen、multiply、lighten 甚至普通的 opacity。先试后写的流程能省掉大量盲猜的时间。

工程深水区：Canvas 帧缓存实现丝滑倒放

技巧 11：用 Canvas 缓存帧，告别卡顿的 Boomerang 倒放

这是整段视频技术含量最高的部分，也是我觉得最值得单独拎出来讲的东西。

需求很简单：视频正向播放完毕后反向播放回去，形成类似 Instagram Boomerang 的循环效果。

第一种方案——直接不断修改 video.currentTime 来倒放。失败了，明显卡顿。

为什么会卡？视频编解码依赖关键帧和差分帧的结构。正向播放时解码器按顺序读取很顺畅；但频繁向后跳转（seek）会触发反复的定位和解码操作，远不像播放一组连续图片那样稳定。

第二种方案——用 Canvas 但思路还是不对。还是没完全解决问题。

第三种方案——最终的解决方案：

1. 视频挂载后先用 video.play() 正常正向播放
2. 使用 requestVideoFrameCallback API 捕获每一帧唯一画面（不支持时降级到 requestAnimationFrame）
3. 把每帧绘制到一个离屏 Canvas 上，同时将宽度缩放到约 960px 以控制内存
4. 把绘制好的 Canvas 帧依次存入数组
5. 正向播放结束后，不再碰 currentTime——而是反向遍历缓存帧数组并重新绘制到可见 Canvas

效果：顺滑。

但这个方案有代价。缓存帧会吃内存——视频越长、分辨率越高、帧率越大，内存开销越大。所以它更适合短时长（几秒到十几秒）、装饰性的网页动效。正式上线时还需要：

• 根据设备性能动态降低采样率
• 尊重 prefers-reduced-motion 媒体查询（为敏感用户提供静态后备图）
• 组件卸载时手动释放 Canvas 和帧数组防止内存泄漏
• 页面不可见时（切换 Tab）暂停处理节省资源

// 核心思路伪代码
const frames = [];

// 正向捕获阶段
function captureFrames() {
  video.play();
  const offscreen = document.createElement('canvas');
  const ctx = offscreen.getContext('2d');
  
  // 用 requestVideoFrameCallback 逐帧捕获
  video.requestVideoFrameCallback((now, metadata) => {
    ctx.drawImage(video, 0, 0, 960, ...); // 限宽控制内存
    frames.push(offscreen.transferToImageBitmap());
    
    if (!video.ended) {
      video.requestVideoFrameCallback(arguments.callee);
    } else {
      playBoomerang(); // 切换到倒放阶段
    }
  });
}

// 倒放阶段：反向绘制缓存帧
function playBoomerang() {
  let i = frames.length - 1;
  function drawReverse() {
    if (i >= 0) {
      ctx.drawImage(frames[i--], ...);
      requestAnimationFrame(drawReverse);
    } else {
      captureFrames(); // 循环
    }
  }
  drawReverse();
}

技巧 12：桌面端和移动端分别验收

最后一个技巧听起来最基本但被忽略得最多。

视频结尾处，Viktor 在确认桌面端效果之后立刻切换到移动端预览，检查布局压缩、文字大小、视频性能、交互元素的触控友好度。

"模型生成完成 ≠ 网站完成"。至少还要检查这些：

• 导航栏在小屏下有没有溢出或崩坏
• 视频背景是否拖垮了首屏加载速度
• 文字和动态背景之间对比度够不够
• 卡片和图片在不同 viewport 宽度下有没有变形
• 键盘用户能否正常操作所有交互元素
• 关闭动态效果之后页面内容是否仍可理解

另外注意到一个细节：制作 About 页面时，Viktor 把 Codex 的模型从 Medium 切换到了 Ultra（更高的推理强度）。说明不同复杂度的任务可能需要调整模型档位——这不是"一直用最强就对了"，而是根据任务特性做选择。

那三次失败教会我的事

这段视频最让我尊重的一点是：它保留了失败过程。

至少三处翻车现场没有被剪掉：

1. 参考视频引导生成的动效仍然不符合预期 → 放弃了
2. currentTime 倒放明显卡顿 → 换方案
3. 第一轮 Canvas 实现也没达到理想效果 → 继续迭代

这三段失败比最终成功的成片更有教育意义。它们揭示了 AI 辅助开发的真实形态：

第一，生成模型负责提出候选结果，不负责替你验收。 它不会告诉你"这个动效的节奏不对"——你得自己看出来。

第二，出现问题时要把"看起来不对"翻译成技术约束。 不是跟 AI 说"再好一点"，而是指出具体哪里不对、"不要用 currentTime 倒放"、"改用帧缓存方案"。

第三，每次只修一个问题。 同时调三个变量你永远不知道哪个改动起了作用。

所谓高质量的 AI 建站，从来不是提示词写得越长越好。而是你能否把模糊的审美判断逐步转化成可验证的对象：图像构图、布局参数、十六进制颜色值、CSS 属性、播放逻辑、内存预算。

四组拿来就能用的提示词骨架

我从视频里提取了四组核心提示词模板，你可以直接复制改改就用：

首屏 Hero 实现

根据附图只实现首页 Hero Section，不要继续生成其他区块。

要求：
1. 保留参考图的版式比例和主要留白；
2. 使用我提供的 Google Font 与指定字重；
3. 页面背景使用纯黑色；
4. 强调色固定为 #你的颜色值；
5. 文字、按钮和导航必须使用真实 HTML，不要把它们做进背景图；
6. 同时适配桌面端和移动端。

图片转网页背景视频

让第一张图片按照所附参考视频的运动方式产生动画。
保持原有构图和主体位置，运动应平滑、克制，适合用作网页背景。
不要推进镜头，不要放大或缩小，不要新增文字和 Logo。
输出短时长、16:9 的网页背景视频。

视频集成到 Hero

将提供的视频作为 Hero 的全尺寸背景。
不要添加任何颜色遮罩或黑色 Overlay。
保持正文层级位于视频之上，并确保移动端不溢出。
视频自动播放、静音、循环，并提供静态 poster 作为后备。

Boomerang 播放优化

不要通过频繁修改 video.currentTime 实现倒放。

视频正向播放时，优先使用 requestVideoFrameCallback 捕获唯一帧，
不支持时使用 requestAnimationFrame。把帧绘制到离屏 Canvas，
最大宽度限制在 960 像素以控制内存，并缓存到数组。
正向播放结束后，按相反顺序绘制缓存帧，形成平滑的 Boomerang 效果。

同时：
- 避免重复捕获同一帧
- 组件卸载时释放 Canvas 和帧数组
- 页面不可见时暂停处理
- 对 prefers-reduced-motion 用户显示静态图
- 移动设备内存不足时自动降低采样率

这套方法适合什么、不适合什么

适合的项目类型：

• 设计机构 / 创意工作室官网（强视觉冲击是核心竞争力）
• 个人作品集 / Portfolio（需要展现审美品味）
• 产品发布页 / 活动专题页（短期存在、视觉效果优先）
• 品牌概念站 / Microsite（实验性强的项目）

不适合的项目类型：

• 资讯站 / 内容型网站（信息密度 > 视觉表现）
• 后台管理系统 / SaaS Dashboard（功能性 > 装饰性）
• 文档站点 / Wiki（可读性和加载速度至上）
• 电商详情页（转化漏斗优化比花哨动效重要一万倍）

即使是品牌类网站，正式上线前也别忘了这些基本功：版权确认（生成的图和视频有没有侵权风险）、视频压缩（原始输出文件通常大得离谱）、Core Web Vitals 检测、无障碍审计、跨浏览器兼容测试、以及真实内容的校对替换（AI 生成的 Lorem Ipsum 最终都要换成真文案）。

最后说句实在话

看完这段视频最大的感受是什么？

拉开差距的从来不是模型名字，是导演能力。

GPT-5.6 Sol 强、Codex 也强。它们能把视觉参考快速转化为可运行页面，能在明确指令下处理响应式布局和工程优化。但最终成品的质量取决于一连串人为决策：

• 选了哪个参考、放弃了哪个参考
• 把设计拆成了哪些变量、分别映射到哪里
• 锁定了哪种字体和配色、拒绝了模型的哪个默认值
• 哪版动画该留、哪版该扔
• 先做了哪个区块、什么时候切的移动端预览
• 倒放卡顿的时候选择了换方案而不是死磕

这些事情模型替不了你。

最值得复用的不是某一条神奇提示词，而是这条链路：

参考收集 → 变量拆分 → 干净素材 → 参考动效 → 单区块实现 → 分阶段扩展 → 工程优化 → 多端验收

当每一步都有清晰的输入和明确的验收标准时，Codex 就不再是一个随机生成页面的黑盒——而是一个真正能和你协作的开发者。

原视频在这里：