企业官网建设流程全解析

写文章配图这件事，我以前一直是“懒人模式”：凡是要配图，就直接丢给那种按张收云端大模型 API 的画面生成服务。直到上个月我算了一笔账，发现自己光给文章配图就花掉的钱，足够买一台二手的低功耗显卡了。那笔账单直接促使我下决心把整套配图流程改成“本地显卡 + Claude Code 辅助出提示词”的本地管线。

先说结论：这套方案不需要完全脱离付费服务，但能做到“边际成本趋近于零”。Claude Code 不是用来直接画图的，它是用来把文章拆成结构化的视觉提示词、自动生成批量配置、替你把杂活收拾干净的编排工具。而本地显卡负责真正的图像推理，从文生图到批量出图，一篇文章配 20 张图，电费算下来可能还没有一杯奶茶贵。

这篇文章默认你有一定折腾精神，但不要求你多精通 AI。我会把为什么要这么干、硬件最低要求、一键包怎么搭、踩过的坑全部按实际操作顺序讲清楚。

1. 为什么要把配图从云端搬到本地

1.1 按张计费的钱包痛点

大多数商用图像生成接口是按生成张数计费的，不同分辨率、不同生成次数的隐藏成本还不一样。我自己的使用习惯是每篇文章配图不止生成一次，经常要连续抽卡好几次才能选出一张满意的。一张文章头图的最终生成成本，往往是表面价的 5 到 10 倍。

如果你做内容运营或者自媒体，一天生产 3 到 5 篇文章，每篇配 5 到 10 张图，一个月的图像生成费用叠加起来是很可观的。更离谱的是，这些费用是“沉没成本”，因为你也不知道这张图到底能不能用，你只是在给每一次试错买单。

本地方案的核心思路就是把“试错”的成本转移到自己可控的设备上。显卡电费、硬件折旧这些当然是成本，但一旦机器已经买回来了，跑 10 张图花的电费和跑 1 张图几乎没差别。这就让“批量抽卡”变成了一件零压力的事情。

1.2 本地显卡 + 开源模型的替代能力

可能有人担心本地开源模型的画质打不过云端付费服务。这个话题得分场景。单纯从“出图精致程度”来看，目前主流的开源文生图模型在写实、插画、二次元、产品渲染这些常见文章配图场景上，已经非常接近付费服务了。特别是配合一些社区优化模型和适当的高分辨率放大技术，画质差距对文章阅读场景来说几乎没人能看得出来。

另外一个容易被忽视的点是隐私。很多文章在发稿前都有保密需求，草稿、数据图表、内部产品截图都不适合拿到云端服务里做风格化处理。本地推理相当于所有图片数据都在你机器内部流转，没有外部上传这一环节，光这一点对很多小团队来说就是刚需。

还有可控性。开源模型搭配本地推理引擎以后，你可以彻底固定一套风格参数，同一个系列的文章能保持高度统一的视觉调性。而云端服务经常会有“产品升级”导致出图风格漂移的问题，一觉醒来同一个提示词出图风格完全变了，这种失控感我用过一次就再也不想体验。

2. 核心工具链拆解：Claude Code 的角色不是生成图片，而是管好提示词与流程

2.1 Claude Code 能做什么、不该做什么

先说清楚，Claude Code 不是一个画图工具，它是一个跑在终端里的 AI 编程与自动化助手。它擅长的是读文件、改代码、写脚本、执行命令、根据你的自然语言要求整理结构化的输出。

在我这套方案里，它承担三件事：

1. 把文章正文或章节标题读进去，拆解出这篇文章需要的配图清单。
2. 为每一张配图写出符合本地图像模型语法的提示词，包括主体、场景、光线、镜头、风格限定词和负面提示词。
3. 生成或维护一个自动化脚本，让本地图像引擎可以批量处理这些提示词并输出成品。

它不该做什么也很明确：不该承担真正的图像渲染推理。那部分交给本地显卡的推理引擎，因为 Claude Code 本身并不带本地图片生成能力，如果让它去调用远程绘图服务的 API，那就等于又绕回了“按张计费”的老路。

2.2 和本地推理管线的协作方式

整体协作模型可以理解成一条流水线：

• 第一站：你写好的文章 Markdown 文件放在项目目录里。
• 第二站：Claude Code 读取文章，按段落和章节结构输出一张“配图规划表”，格式可以是 JSON 或者 YAML，里面包含每张图的描述、尺寸建议、风格标签。
• 第三站：一个本地图像推理引擎（我在用的方案是基于开源模型的 WebUI 或 ComfyUI）把这些结构化输入解析成真正的出图请求。
• 第四站：跑完的图片自动保存到项目的 assets 目录里，命名规则带文章名和序号。

这样做的好处是，Claude Code 只需要处理文本逻辑，完全不消耗显卡资源；显卡只需要闷头算图，不需要理解文章含义。各干各的，互补干扰，任何一个环节换掉都不影响另一个环节。

2.3 为什么不是直接用云端大模型一张张画

有人会问：既然有 Claude Code，为什么不直接让它把配图提示词喂给云端绘图服务，一步到位？

答案还是成本。Claude Code 的订阅或 API 额度是按文本量计算的，处理几千字的文章和几十个提示词，费用极低，几乎可以忽略。但图像生成是按张数计算的，成本高出一个量级。用 Claude Code 做低成本的“大脑”，用本地显卡做高成本的“手脚”，这两者结合才把成本真正降下来。

3. 从零搭建：环境准备、显存要求与模型选择

3.1 硬件清单与跑得动的最低配置

这里直接给结论。本地跑文章配图级别的内容，建议显存不低于 6GB。6GB 属于“能跑但紧巴巴”的水平，可以出 512x512 到 768x768 的图，适合公众号和网页配图。8GB 显存舒服很多，能跑主流开源模型的常见变体。12GB 以上基本可以无脑冲高分辨率加各种放大脚本。

纯 CPU 方案也可以跑，但我不推荐直接用。CPU 出一张 768x768 的图可能要 5 到 10 分钟，批量文章的配图效率太低了。如果你的机器只有核显，我更建议你用云端按量计费的 GPU 实例，也不要用 CPU 硬扛。

我自己的主力机是一张老旧的 8GB 显卡，跑通这套流程完全没问题。所以不要被“AI 必须顶级显卡”的说法吓到，文章配图这个需求真没那么夸张。

3.2 安装推理引擎与模型

本地推理引擎我推荐从 Stable Diffusion WebUI 开始，因为它自带 API 模式，写脚本接入非常简单。安装流程网上资料很多，核心步骤就这几步：

1. 安装 Python 环境并创建虚拟环境。
2. 拉取项目代码，安装依赖。
3. 启动时加--api参数，让引擎开放本地接口。
4. 下载一个主模型文件放入模型的合适目录。

模型选型建议优先选择基于 1.5 架构的写实或插画模型，因为它们在低显存设备上的优化最好，出图稳定，社区配件多。追求更高画质可以尝试基于 SDXL 架构的模型，但显存建议 8GB 以上。

启动命令长这样：

python webui.py --api --listen 127.0.0.1 --port 7860

看到终端输出里有Uvicorn running on http://127.0.0.1:7860就说明接口起来了。先手动在网页界面试一次生成，确认模型加载没问题，再进入下一步。

3.3 让 Claude Code 看到本地引擎的 API

Claude Code 不需要直接调用绘图接口，但我们需要让它可以操作一个自动化脚本，这个脚本内部会去请求本地 API。所以真正要做的是：把绘图引擎的接口地址和参数写成一个配置文件，让脚本可以读取。

我用的配置片段是这样：

engine: api_url: "http://127.0.0.1:7860/sdapi/v1/txt2img" default_size: [768, 512] steps: 28

这个配置文件交给 Claude Code 维护。以后想改采样步数、出图尺寸，直接跟它说“把默认尺寸改一下”，剩下的事情它自己处理。

3.4 显存不够时的降级方案

如果你的显卡只有 4GB 显存，也可以通过开启内存交换和低显存优化模式来跑，但要接受两个代价：速度变慢，以及高分辨率下容易崩。我的建议是可以作为临时方案，不建议长期用。

4. 一键包：把整条链路封装成脚本

4.1 一键包的设计思路

所谓“一键包”，本质上是一个项目目录加两个脚本。它解决的痛点是：每次给新文章配图，都要手动启动引擎、手动复制提示词、手动保存图片，这一连串操作又烦又容易出错。把流程脚本化以后，只需要把文章丢进目录，跑一个命令，过一会儿去收图就行。

项目目录结构建议这么建：

article-image-studio/ ├── run.sh ├── generate.py ├── config.yaml ├── draft.md ├── prompts.json └── assets/ ├── cover.png └── inline/

• run.sh是整个流程的入口。
• generate.py负责读取prompts.json，逐个请求本地引擎并保存图片。
• config.yaml存放引擎地址、模型参数、保存路径。
• draft.md是你待配图的文章稿。
• prompts.json是 Claude Code 根据文章生成的结构化配图清单。

4.2 一键包的实际脚本骨架

run.sh的逻辑非常简单：

#!/usr/bin/env bash set -e python generate.py --config config.yaml --prompts prompts.json

generate.py的核心逻辑也不复杂，只要会调接口就行。这里给一个参数解析后真正发请求的片段：

import base64 import json import pathlib import time import requests def generate_image(api_url, payload, output_path): response = requests.post(api_url, json=payload, timeout=120) response.raise_for_status() data = response.json() images = data.get("images", []) for idx, image_base64 in enumerate(images): image_bytes = base64.b64decode(image_base64) save_path = output_path.with_name( f"{output_path.stem}_{idx}{output_path.suffix}" ) save_path.write_bytes(image_bytes) print(f"saved: {save_path}")

整个脚本调用的时候只需要把每一个提示词转换成 API 需要的 payload，循环调用generate_image就行了。最终输出的文件会带上序号，方便挑选。

4.3 关键参数与算力取舍

别小看参数配置，这里面坑不少。默认步数太高不会让画质无限变好，到 30 步以后收益就很低了，文章配图我一般固定在 24 到 28 步。采样器我优先选带 Karras 调度的 DPM 系列，出图干净而且风格稳定。

尺寸方面，文章封面图建议直接用 768x512，正文配图可以用 512x512 再放大。一次生成多张候选图可以提高命中率，我在generate.py里默认给每个提示词生成 4 张图，选起来不心疼，因为本地成本可以忽略。

注意事项：

本地引擎一旦开启 API 模式，不要把它暴露到公网。只监听 127.0.0.1 就足够了，否则会变成别人免费薅你显卡算力的资源池。

5. 实操流程：从一篇文章的配图需求到成品图

5.1 第一步：定义配图规划表

在项目目录里放好文章草稿后，打开终端进入 Claude Code 的交互模式，给它一条明确指令：

请阅读项目里的 draft.md，把这篇文章按照内容结构拆分为配图清单， 输出到 prompts.json，包含字段：序号、用途、描述、画面风格、尺寸、负面提示词。

Claude Code 会按照文章段落去理解哪里需要头图、哪里需要流程图示例图、哪里需要概念插画。它输出的 JSON 结构大概长这样：

[ { "id": "cover", "usage": "文章封面头图", "description": "一台开满编程文件的电脑屏幕前，从插口中不断抽出五颜六色的杂志图片", "style": "现代扁平插画，低饱和色调，留白充足", "width": 768, "height": 512, "negative_prompt": "文字，水印，模糊，杂乱背景" } ]

5.2 第二步：用 Claude Code 微调提示词语法

有时候 Claude Code 生成的描述很有画面感，但直接喂给本地模型出图却会跑偏。原因是它写的是“人话”，而图像模型需要精确的关键词结构。

遇到这种情况我会给它追加约束：

请把每个 description 改写成适用于开源图像模型的英文提示词， 开头写清楚主体材质和配色，中间写清楚环境光效，结尾统一加质量词。 保持 prompts.json 结构不变。

这一步其实就是整个方案最值钱的地方。免费提示词工具给的是套话模板，而 Claude Code 能结合你的文章语境定制提示词，出图效果会自然很多。

5.3 第三步：批量生成与人工挑选

跑完脚本之后，assets目录下会出现按提示词序号命名的多张候选图。我的习惯是先打开文件夹快速浏览，看到风格不对的先看是不是负面提示词没写全，看到构图不对的再回到 prompt 上微调。

这里有几条实操心得：

• 如果几张图都歪了，大概率是提示词的主体顺序有问题，让 Claude Code 调整描述，而不是盲目增加步数。
• 想保持整篇文章配图风格统一，最有效的做法是在每个提示词末尾追加相同的“风格黏合词”，例如flat vector illustration, pastel palette, clean composition。
• 封面图和正文插图最好用不同的尺寸参数，不要一张模板走到黑。

5.4 第四步：把成品图尺寸和格式收尾

本地模型直接生成的 PNG 文件体积偏大，放到文章平台上一般建议先转成 WebP 或者适当压缩。我在一键包里加了一个小的后处理步骤：调用工具把 assets 里的 PNG 统一转成 WebP，并限制最长边不超过 1600 像素。

这一步可以手动做，也可以让 Claude Code 在脚本里加一段。后处理的意义不仅仅是省流量，更重要的是避免文章编辑器里因为超大原图导致排版卡死。

6. 常见问题排查与技术细节精选

6.1 出图速度极慢怎么办

如果你确认显卡已经正常加载，但出图速度还是慢得离谱，先看是不是模型加载到了 CPU。显存被别的进程占用、模型文件放在机械硬盘里导致加载缓慢，都可能造成错觉。建议先把引擎的启动日志翻出来，看加载模型的设备是device=cuda还是device=cpu再说。

6.2 显存溢出直接崩

这个问题常出现在切换到高分辨率模型或者开了过多放大选项时。可以先把批处理数量降到 1，停用放大插件，换一组低分辨率试跑。如果低分辨率正常，说明模型本身没问题，是你的配置超过了硬件极限。

常见报错和解决思路整理成了一张速查表：

6.3 本地模型能不能生成中文海报文字

市面上多数开源文生图模型的中文文字生成能力都比较弱，直接生成商品图里的中文标题经常出现乱码。我的处理方式是：让模型生成无字或者带占位图形的底图，再用设计工具把文字图层叠上去。规避模型短板，比硬调模型参数靠谱得多。

6.4 提示词稍微改动风格就跑偏

这个问题的根源是模型对描述性词汇的敏感度不一致。Claude Code 生成的提示词如果偏文学化，模型就很容易跑偏。解决办法是在进入批量生成之前，先抽一两张测试图确认风格，然后告诉 Claude Code“保持当前提示词骨架，只替换主体描述词语”。

7. 这套方案后续还能怎么扩展

7.1 给程序员的脚本扩展思路

有技术基础的人可以考虑把generate.py改成订阅式服务，比如用watchdog监听新文章文件出现，自动触发配图流程。这样连手动运行命令都省了，文章一丢进项目目录，配图自己就开始跑。

7.2 给普通写作者的使用建议

如果你完全不想碰脚本，也可以用 Claude Code 阶段性完成提示词整备，再把提示词手动复制进图像引擎的网页界面里出图。虽然没做到全自动，但核心的“零成本出图”依然成立。

7.3 下一步可以研究的方向

想真正把配图画质再拉高一个档次，建议研究 ControlNet 姿态控制、LoRA 风格固化、以及图生图的二遍重绘。这三个方向对文章配图场景的提升非常明显，而且都能在本地搭建起来。

我个人在实际使用中的体会是：本地出图的体验和云端最大的区别不是省钱，而是“敢试”。以前出一个提示词要在云端反复确认成本，现在我可以随便让 Claude Code 生成二十个不同风格版本，再让本地引擎一口气跑出来，最后选出最贴合文章调性的图。这种从容感用久了就回不去了。如果你手里正好有一张能跑的显卡，我建议今天就把这套流程搭起来，成本不高，但绝对值得。