企业官网建设流程全解析

如果让你用 AI 画一张“七海去找星瞳玩，但是路上太晒了”的静态画面，你会怎么处理那个“太晒了”？直接把这句话原样丢给绘图模型，大概率会得到一张构图不错、但人物和光照完全失控的图：要么太阳打在脸上导致五官糊成一片，要么影子方向乱七八糟，根本看不出是正午。这个场景虽然只是个脑洞，但它把 AI 创作里最麻烦的问题暴露出来了——AI 能画得好看，却不代表你能控制它画得“符合预期”，尤其是光照、角色和场景三者需要同时稳定的时候。

这篇文章想聊的，不是把一句话丢给 AI 生成一张随便看看的图，而是把“AI 生成静态视觉内容”这件事做成一条可复用的工程链路。这里的“静态”和你平时在 Linux 网络配置里看到的静态 IP、静态路由，或者在 Java 里遇到的 static 关键字不是一回事，它指的不是“不能变”的变量，而是静态图片、静态资源和静态网页：AI 产出静态图，再通过静态站点生成器包装成一组任何人都能打开、打开就能看完、看完还能收藏的网页。读完这篇文章，你会得到一条从“一句话脑洞”到“一个在线 AI 静态作品站”的完整路径，同时知道每一环的坑在哪里。

这个链路比很多人想象中更适合普通开发者来做。它的门槛主要在工具链和环境，不在算法。你不需要自己训练模型，也不需要精通前端框架，只要会写提示词、会跑一条优化脚本、会用 Markdown 写页面，就能把 AI 生成的静态内容变成真正可交付的作品。下面，我们从最核心的痛点开始拆。

1. 这个选题背后的真实痛点

AI 图像生成工具这几年发展得很快，但大部分人的用法仍然停留在“单张生成、选一张能看的、发朋友圈”的阶段。真正到了想做一个 AI 静态作品站、一套系列插画或者一个带文案展示的静态相册时，问题会一个一个冒出来。

第一个痛点是一致性差。同一个角色，你让 AI 画十次，能画出十张不同的人脸，这是模型采样随机性决定的。如果要做系列场景，比如“七海去找星瞳玩”，今天在烈日下，明天在下雨天，角色必须长得像同一个人，光照风格也要统一，这就不是简单的“多试几次”能解决的。

第二个痛点是可复现性差。很多绘图工具默认不保存你的完整参数，等你生成了一张满意的图，想再改一版的时候，却想不起来当时用的种子、采样器和 CFG 值。生成静态图本身可以很快，但“可复现的静态图生产”才是工程问题。

第三个痛点是分享形态单一。一张 PNG 图发出去，别人只能看到一张图，看不到你写背景故事时想表达的氛围。如果搭一个静态网页，用文字、大图和相册结构来承载，体验完全不一样。而且静态站点生成出的 HTML 和图片可以直接扔到对象存储或 CDN 上，打开速度远快于动态网站。

第四个痛点是资源太乱。AI 生成的原图通常很大，动辄几 MB，格式可能是 PNG 或高码率 JPG。直接放到网页里会导致首屏慢、流量费高、加载卡顿。这个问题必须在发布前通过批量优化解决。

这四个痛点合在一起，就是“AI 静态”这个方向值得做的原因：AI 负责生成静态内容，工程化手段负责让静态内容可控、可复现、可分发。真正稀缺的不是生成能力，而是把生成结果规范化、产品化的能力。

2. AI 静态内容生产链路与核心概念

2.1 一条完整的 AI 静态生产链路

我们可以把从脑洞到线上站点拆成六个环节：

1. 提示词设计：把自然语言描述变成结构化指令，明确角色、场景、光照、画风。
2. 模型生成：在支持静态图的 AI 绘图工具中跑采样，记录种子和参数。
3. 筛选与修复：选图，用局部重绘修复手、脸、过曝等问题。
4. 资源优化：批量压缩、转格式、生成缩略图和元数据。
5. 静态建站：用 VitePress、Hugo 或 Hexo 等静态站点生成器把图片和文案组合成网页。
6. 部署分发：构建产物上传到静态托管平台或对象存储，配上 CDN 提高访问速度。

这六个环节里，1 和 3 依赖人的审美判断，2 和 4 依赖工具操作，5 和 6 是标准的 Web 工程流程。所谓“AI 静态”，在我的定义里就是把 AI 生成的静态图，通过静态站点体系变成一个长期可维护的数字资产库。

2.2 静态图片、静态资源与静态站点

先澄清几个容易混的概念：

• 静态图片：像素已经固定的图片文件，比如 PNG、JPG、WebP。AI 绘图的输出本质上是静态图片，除非你去做视频或交互动画，否则它没有“运行时”变化。
• 静态资源：Web 项目中的 HTML、CSS、JavaScript、图片、字体等不依赖服务器动态生成的文件。部署时直接上传即可使用。
• 静态站点生成器（SSG）：在构建阶段把 Markdown、模板和资源编译成完整 HTML。用户访问时服务器只返回静态文件，不需要执行后端逻辑。

很多开发者会把静态站点和“纯静态页面”画等号，认为它只能做个人简历或文档。实际上，现代的静态站点生成器已经支持组件化、国际化、SEO 优化和构建时数据注入，完全够用。

下面是三种常见 Web 渲染方式的对比：

对 AI 静态作品集来说，SSG 是最合适的方案：图多、内容更新不频繁、以阅读和展示为主，不需要复杂的动态交互。

2.3 为什么“静态”思维在 AI 时代依然重要

你会看到热搜词里同时有“静态代理”“静态路由”“static 修饰符”“静态库”这些概念。它们各自出现在不同技术领域，但底层思路一致：把经常用、不频繁变化的东西固定下来，减少运行时计算和不确定性。

在我们这个场景里，同样适用：AI 图像生成是不确定的过程，但你最终交付给用户的必须是确定的静态资产。把不确定留在生成环节，把确定留给发布环节，这正是工程意义上的“AI 静态”。

3. 环境准备与前置条件

3.1 硬件与基础软件

AI 图像生成可以本地运行，也可以使用在线服务。本文以本地离线生成为主，因为本地方案对隐私和参数控制更有优势，且不依赖在线接口稳定性。

硬件方面，建议使用 NVIDIA 显卡，显存 8GB 以上会比较流畅。如果你没有独立显卡，可以选用在线绘图接口或云端 GPU 实例，但操作路径会有所不同。更稳妥的判断是：先确认自己的实际硬件条件，再决定本地还是云端，不要盲目下载大模型。

基础软件清单如下：

3.2 项目目录规划

我不建议把素材、脚本和站点文件混在一个目录里。下面这个结构比较清晰：

ai-static-gallery/ ├─ prompt/ │ ├─ scene-noon.md │ └─ params.json ├─ raw-images/ # AI 生成的原图，保持只读 ├─ scripts/ │ └─ optimize.js # 批量压缩与转格式脚本 ├─ docs/ # VitePress 站点目录 │ ├─ index.md │ ├─ photos.md │ └─ images/ # 优化后的图片产物 ├─ package.json └─ .gitignore

这个目录设计有一个原则：原始素材和发布素材分离。raw-images 里的原图只作为备份，docs/images 里的是经过优化、可以发布到网页的产物。脚本可以从原图生成产物，但绝不会反过来覆盖原图，这样能避免误操作把高分辨率文件搞坏。

3.3 确认工具已就绪

安装完成后，建议在终端里做一次快速检查：

python --version node -v git --version

只有当这三个命令都能正常输出版本号时，再进入下一步。这里真正容易踩坑的地方是 Python 环境混乱，多个版本冲突会导致绘图工具依赖装不上。更稳妥的做法是使用虚拟环境，比如venv或conda，把绘图工具的依赖隔离起来。

4. 用 AI 生成“路上太晒了”场景静态图

4.1 从一句话到结构化提示词

原始的“七海去找星瞳玩，但是路上太晒了”是一句口语化描述，直接给模型不够用。我们需要把它拆成：角色数量、角色关系、场景地点、时间、天气、光照方向、画风、镜头角度。

我从这个脑洞里提取出的正向提示词示例如下：

(masterpiece, best quality:1.2), two anime girls walking on a rural road at noon, harsh summer sunlight, strong cast shadow underfoot, short shadow, sun flare from upper left, heat haze on the road, bright sky with thin clouds, white highlight on hair, casual summer dress, detailed face, clean expression

这段提示词的关键不是堆砌形容词，而是把“晒”落到视觉语言里。harsh summer sunlight 表示正午强光，short shadow 表示太阳几乎在头顶，sun flare 表示逆光光晕，heat haze 表示路面热浪。如果你只写“too sunny”，模型听到的是“晴天”，而不是“正午暴晒”。

反向提示词同样重要：

lowres, bad anatomy, bad hands, missing fingers, extra fingers, worst quality, low quality, jpeg artifacts, signature, watermark, username, blur, overexposure, under-exposure, inconsistent shadow, duplicated character

这里有一个容易忽略的细节：overexposure和under-exposure要同时写在反向提示词里。AI 模型经常在极端光照下走向两个极端，要么整张画面过曝发白，要么暗部死黑。把两个极端都排除，才能得到中间相对可控的光照。

4.2 参数设置建议

不同模型和采样器的搭配会影响效果，下面这组参数适合作为起点：

批量生成时，建议一次生成 4 到 6 张，然后从中挑 1 到 2 张作为候选。不要一张一张生成，那样效率太低，而且无法在多个结果之间比较光照是否自然。

4.3 筛选与局部修复

筛选时重点看三个地方：人物的手是否正常、五官是否崩坏、地面阴影方向是否一致。很多 AI 绘图工具支持局部重绘（Inpaint），选中脸部或手部区域，用局部提示词重新生成，可以修复最明显的瑕疵。

如果你是第一次做这个链路，不要追求一张完美的图。先用最低成本跑通流程，之后再慢慢优化画质。局部重绘选“仅肖像区域”之类的模式时，范围不要选太大，否则会把周围光照一并改掉，造成拼接痕迹。

4.4 关于角色二创的提醒

在这类创作中，如果使用现实中存在的虚拟主播或虚拟偶像角色，需要特别注意平台规则和角色二创协议。本文中“七海去找星瞳玩”只是作为技术演示的构图参考，实际发布作品时，建议使用原创角色或已获授权的主题。AI 生成内容的版权边界还在不断讨论中，稳妥的做法是记录生成参数、保留生成过程截图，并在公开页面说明用途。

5. 图片批量优化与静态资源化

5.1 为什么必须做资源优化

AI 绘图生成的 PNG 文件动辄 5MB 以上，直接放到网页里会带来两个问题：一是首屏加载慢，二是 CDN 流量成本高。静态图片要成为静态资源，必须经过压缩、裁切和格式转换。

WebP 格式是目前兼容性和压缩率比较平衡的选择，可以显著减小体积。缩略图则用于作品列表页，用户点击后再加载大图，体验更好。

5.2 用 Node.js 脚本一键优化

这里用sharp这个图像处理库来批量转换。在项目根目录安装依赖：

npm init -y npm install sharp

创建scripts/optimize.js：

// 文件路径：scripts/optimize.js const sharp = require('sharp'); const fs = require('fs'); const path = require('path'); const SRC = path.join(__dirname, '..', 'raw-images'); const DIST = path.join(__dirname, '..', 'docs', 'images'); const SUPPORT = ['.png', '.jpg', '.jpeg']; async function optimizeOne(file) { const input = path.join(SRC, file); const base = path.basename(file, path.extname(file)); const webpOut = path.join(DIST, base + '.webp'); const thumbOut = path.join(DIST, base + '-thumb.webp'); // 大图：最宽 1200px，输出 WebP，质量 82 await sharp(input) .resize({ width: 1200, withoutEnlargement: true }) .webp({ quality: 82 }) .toFile(webpOut); // 缩略图：宽 480px，适合列表页 await sharp(input) .resize({ width: 480 }) .webp({ quality: 75 }) .toFile(thumbOut); const meta = await sharp(webpOut).metadata(); return { name: base, width: meta.width, height: meta.height, webp: base + '.webp', thumb: base + '-thumb.webp' }; } (async () => { if (!fs.existsSync(DIST)) { fs.mkdirSync(DIST, { recursive: true }); } const files = fs.readdirSync(SRC).filter(f => SUPPORT.includes(path.extname(f).toLowerCase()) ); const list = []; for (const f of files) { list.push(await optimizeOne(f)); console.log('processed:', f); } const manifestPath = path.join(DIST, 'manifest.json'); fs.writeFileSync(manifestPath, JSON.stringify(list, null, 2)); console.log('done:', list.length, 'images'); })();

脚本做三件事：把原图缩放为 1200px 宽的 WebP 大图，生成 480px 宽的缩略图，最后输出一个manifest.json清单，记录每张图的文件名和尺寸。这个清单对后续做作品列表页非常有用。

运行方式：

node scripts/optimize.js

运行成功后，在docs/images/下应该能看到.webp和-thumb.webp两类文件。如果原图本身是竖构图且超过 1200px，脚本会等比缩小；如果原图本来就小于 1200px，则不会放大，避免画质损失。

6. 用 VitePress 搭建 AI 静态作品站

6.1 为什么选 VitePress

VitePress 是一个基于 Vite 的静态站点生成器，核心优势是轻量、启动快、用 Markdown 写内容，适合文档站和作品集。对于 AI 静态图片展示来说，它的默认主题已经很简洁，不需要额外写前端。

如果你更熟悉 Hugo 或 Hexo，选哪个都可以。本文以 VitePress 为例，因为它的配置直观，而且 Node 生态和前面的图片优化脚本是同一个技术栈。

6.2 初始化项目

最简单的方式是用脚手架创建：

npm create vitepress@latest

在交互面板中按需选择，创建完成后得到一个带docs目录的项目结构。如果不想用交互式命令，也可以手动创建，核心只需要package.json、docs/index.md、docs/.vitepress/config.mjs三个文件。

6.3 编写站点配置

把站点配置写入.vitepress/config.mjs：

// 文件路径：docs/.vitepress/config.mjs export default { title: 'AI 静态作品集', description: '用 AI 生成的静态图片构建的可视化作品站', base: '/', themeConfig: { nav: [ { text: '首页', link: '/' }, { text: '全部作品', link: '/photos' } ] } }

注意base字段。如果部署在域名根路径，写/；如果部署在https://user.github.io/project/这类子路径，则要写成/project/。这里的配置错误是最常见的“部署后图片 404”原因之一。

6.4 编写首页与作品页

在docs/index.md中写首页内容：

# AI 静态作品集 这个站点是用来演示“AI 生成静态内容 + 静态站点部署”的完整链路。 第一步：用 AI 绘图工具生成图片。 第二步：用 Node.js 脚本批量优化。 第三步：用 VitePress 构建成静态网页。 查看 [全部作品](./photos)。

在docs/photos.md中放图片：

# 全部作品 ## 七海去找星瞳玩，但是路上太晒了 ![烈日下的乡间小路](/images/noon.webp) 这张图的提示词重点放在正午强光、短阴影和逆光光晕上，目标是营造夏天中午的暴晒感。 ![缩略图示例](/images/noon-thumb.webp)

这里有个细节：图片路径写/images/noon.webp，对应项目里的docs/images/noon.webp，而不是./images/noon.webp。前者是站点根路径下的资源地址，在 VitePress 构建后会正确映射。

6.5 本地预览与构建

在package.json中配置脚本：

{ "scripts": { "docs:dev": "vitepress dev docs", "docs:build": "vitepress build docs", "docs:preview": "vitepress preview docs" } }

本地预览：

npm run docs:dev

浏览器访问终端提示的地址，例如http://localhost:5173，可以看到页面。确认图片能正常加载后，执行构建：

npm run docs:build

构建产物默认输出到docs/.vitepress/dist/。这个目录就是可以上传到任意静态托管服务的最终产物。

7. 部署到静态托管平台与效果验证

7.1 托管平台选择

VitePress 构建产物是纯静态文件，可以部署到几乎任何静态托管平台。常见选择包括 GitHub Pages、Vercel、Netlify，也可以上传到对象存储服务，例如阿里云 OSS、腾讯云 COS，再配置 CDN 加速。

考虑到不同网络环境的访问差异，建议根据目标读者分布选择部署位置。如果作品集主要面向国内用户，更推荐对象存储加 CDN 的方案，访问速度相对稳定；如果只是个人收藏或技术演示，使用习惯的平台即可。这类决策没有绝对正确答案，取决于你的访问场景。

7.2 直接上传静态目录

以手动上传为例，只需要把docs/.vitepress/dist/里的全部文件上传到托管服务指定的目录。上传完成后，站点就能通过域名访问。

关键验证点包括：

• 打开首页，确认文字和标题正常显示。
• 打开作品页，确认.webp图片能加载。
• 刷新浏览器，确认没有 404 报错。
• 如果配置了子路径部署，确认base路径已经改对。

如果图片加载不出来，先在浏览器开发者工具里看 Network 面板，找到图片请求的实际 URL，再对比文件在服务器上的实际路径。大部分 404 问题都出在base配置或资源目录层级上。

7.3 自动化部署的思路

手动上传适合小规模作品集。如果每次更新图片都要手动上传，效率很低，可以引入 CI/CD 流程：本地触发构建，由云服务拉取代码、执行npm install和npm run docs:build，再把产物发布到托管平台。这个做法把“静态资源更新”变成一条自动流水线，后续只需要维护原图和提示词。

8. 常见问题与排查思路

每一条问题都有对应的排查路径。这个表里的经验最想强调的一点是：不要先猜原因，先看日志和 Network 面板。很多开发者遇到图片 404 第一反应是去改图片文件，但真正的原因往往是配错路径。

9. 最佳实践与工程建议

9.1 把提示词当代码管理

提示词不是一次性输入框里的临时文本，而是可以复用的资产。我建议每次生成都记录以下信息：

{ "name": "scene-noon", "prompt": "two anime girls walking on a rural road at noon...", "negative_prompt": "lowres...", "sampler": "DPM++ 2M Karras", "steps": 28, "cfg": 7.5, "seed": 20250101, "resolution": "768x1024" }

这些参数保存到prompt/params.json里，和图片放在同一个 Git 仓库。几个月后想复现一张图，只需要读取这个文件并重新填入工具，结果能大体重现。这也是“AI 静态”里“静态可复现”的含义。

9.2 图片命名与目录规范

原生 AI 生成的图片文件名通常是无意义字符串，比如00013-2983485712.png，不利于识别。建议建立一套命名规则：场景-编号-用途。例如noon-01.webp、noon-01-thumb.webp。命名清晰后，后续脚本和页面都好维护。

实体文件采用“一图三份”策略：原图保留在raw-images，WebP 大图作为页面主图，缩略图用于列表页。原图不要进入站点目录，控制仓库体积。

9.3 安全、版权与使用边界

这个环节不加其他工具或框架，但必须提醒三点：

第一，不要生成或存储侵犯他人肖像权、版权的素材。使用真实角色或商标形象前，务必了解相关平台的二创规则。第二，如果项目要公开上线，记录生成参数和模型来源，方便后续追溯。第三，不要用 AI 生成的内容伪造真实事件、欺骗读者，这是内容安全底线。

9.4 性能优化与 SEO

静态站点天然比动态站点快，但图片依然是流量大头。除了前面用 WebP 压缩，还可以对列表页开启懒加载，避免首屏请求过多图片。每张<img>必须写alt属性，这对 SEO 和无障碍访问都有帮助。

如果坚持每张图只有一个链接，可以考虑用 CDN 为图片资源增加缓存头，让浏览器在后续访问时直接使用本地缓存，减少重复下载。

9.5 引入自动化评测与更新流程

当作品数量增多后，可以用脚本检查docs/images里是否有未在 Markdown 中引用的废弃图片，也可以在 CI 里对新生成的图片执行尺寸和体积校验，超过阈值就构建失败。这样可以把“人工检查图片规范”变成“自动化流水线检查”，减少上线事故。

10. 总结与后续学习方向

这篇文章从一个“AI 画图”的脑洞场景出发，走完了 AI 静态内容生产的完整链路：用提示词设计控制光照和角色，用本地绘图工具生成静态图，用 Node.js 脚本压缩转格式，用 VitePress 构建成静态站点，最后把产物部署到托管平台。你可以把它的思路直接套用到自己的作品集、系列插画或团队素材库建设上。

下一步值得深入的方向有三个：一是多图一致性，研究同一角色在不同场景下的稳定生成方案；二是把静态站点接入持续集成，让更新图片变成一次自动发布；三是把这套流程扩展到 AI 短视频或交互动画，那时“静态”会升级到“多帧一致性”问题，但底层思维仍然相通。

建议你先把今天的示例最小闭环跑通，再逐步叠加功能。只要链路是清晰的，后续所有优化都能在一个稳定的结构上进行。