企业官网建设流程全解析

1. 这套“可直接复制”的工作台，复制的是什么

先说结论：我花了接近两周，把平时做内容要用到的写稿、绘图、剪视频、配音、排版，全部塞进了一套可以一键恢复的“AI 创作工作台”里。也就是说，换了新电脑、新服务器，只要按一个恢复脚本，整套环境连同提示词资产、工作流配置、模型参数就全部回来了。不用从零搭建，也不是给你一个“建议”，是直接把我的手搓版本给你。

1.1 为什么我不建议从零搭

这两年 AI 工具爆发到什么程度，大家应该有感觉。今天冒出个新模型，明天又多个新平台。如果你每次想做点东西，都是“先去注册个账号、配一下 API、再琢磨怎么调用”，那你会发现真正花在创作上的时间没多少，全耗在接线上了。我身边很多朋友就是卡在这一步——工具试了一大堆，落地的成品一个没有。

从零搭建还有一个隐藏成本：环境依赖。比如要跑本地的绘画模型，CUDA、PyTorch、模型权重、LoRA、ControlNet 插件，但凡版本对不上，报错能把你心态搞崩。这些跟“创作”本身毫无关系，纯粹是基建。我搭工作台的初衷就是想把这些基建固化下来，让它变成一份可以随时恢复的存档，而不是每次都要重新踩一遍。

1.2 可复制内容的边界

我所说的“整套工作台可以复制”，不是只复制某个软件，而是复制四类东西：

• 环境镜像：用 Docker 把编排平台、数据库、中间件都容器化，宿主机只要装了 Docker 就能起。
• 提示词资产库：所有调好的提示词模板，按用途分类存放，随时导入导出。
• 工作流定义：从“输入一个主题”到“输出一篇文章/一组图片/一段视频脚本”的自动化流程，全部是可视化节点，可以用配置文件导出。
• 模型接入配置：统一网关，把所有大模型 API 的密钥、地址、模型名称集中管理，切模型只改配置不改代码。

只要把这四样打包，换环境之后大概 20 分钟就能恢复到一个能跑通的状态。这就是“可以直接复制”的真实含义。

1.3 这套方案适合谁

如果你满足下面任意一条，这套东西能帮你省不少事：

• 一个人要同时维护公众号、短视频、小红书好几个账号，内容产出压力大；
• 小团队想用 AI 批量做图、做视频，但不想养专门的后端工程师；
• 你已经在用 AI 工具，但总感觉“单次生成”不够用，想要一条流程化、可重复的产线；
• 想学习大模型工作流、AI Agent 原理，但又没有从零手写代码的基础。

反过来，如果你只是偶尔用 AI 写个文案，那没必要搭工作台，直接用在线工具就行。工作台的价值在于“高频、批量、稳定”，它是一套增产装置，不是一次性玩具。

2. 工作台的内部骨架：四层结构，缺一不可

我搭的时候把整个工作台拆成了四层，每一层各管一摊事。这个分层逻辑是我跑了一个月之后反复调整得出的，少了哪层都会出问题。

2.1 模型接入层：别把模型写死在流程里

第一层是模型接入层，负责统一管理所有大模型接口。我把它比作路由器——你不需要知道每个模型背后的接口地址长什么样，只需要告诉它“我要调用一个擅长写长文的模型”，它会自动路由到对应的服务。

这层最大的坑是：很多人做工作流的时候，直接把某个模型写死在节点里。比如某个节点填了“deepseek-chat”，下次想换更强的模型，得一个一个节点去改。我改成了统一网关之后，所有节点只引用一个逻辑模型名，比如“writing_model”“image_model”“video_model”，真正用的是哪个后端，在网关配置文件里统一指定。

实际配置里我同时接了三类模型：

这样设计的好处很明显：某类模型效果不行了，我只需要改网关里的一个参数，不用动工作流。有段时间某个模型半夜经常限流，我就是通过网关把流量切到备用模型，整个过程没中断任务。

2.2 工作流编排层：把单次生成串成产线

第二层是最核心的编排层，负责把“输入、处理、输出”串起来。我选了支持可视化编排的开源平台，节点之间用连线表示数据流向。比如一个典型的“文章生成”流，大概是这样的链路：

触发节点（输入主题） → 大纲生成 → 分段生成 → 内容安全检测 → 格式排版 → 输出

视觉上就是一个个卡片连成一条线，每个卡片是一个节点，可以配置模型、提示词模板、输入输出字段。我强烈建议不要用代码硬写这种流程，因为代码写的流程改起来太痛苦——今天想加一个“自动配图”节点，代码版本可能要改几十处，可视化版本拖个节点进去就行。

2.3 资产管理层：提示词和时间成本都在这

第三层是资产管理层。很多人忽略这个，但我认为这是工作台能“越用越顺手”的关键。

我建了一个叫做prompts的目录，按场景分文件夹，比如：

prompts/ ├── writing/ │ ├── article_outline.md │ ├── article_expand.md │ └── title_generator.md ├── video/ │ ├── subplot_script.md │ ├── scene_describe.md │ └── voice_director.md ├── image/ │ ├── portrait_style.md │ ├── scene_style.md │ └── negative_prompt_default.md

每个文件就是一个已经调好的提示词模板，里面用占位符表示变量。工作流节点引用的是模板文件路径，而不是直接把提示词写死在节点里。这样改提示词不用进工作流编辑器，直接改 md 文件即可，保存后下次运行自动生效。

这层还放了一个简易知识库，用来存常用素材：拍摄风格参考、角色设定、固定话术。做 RAG 检索的时候可以用上，但不是必须。前期别急着上向量数据库，先把提示词模板管理好，性价比高得多。

2.4 输出适配层：别让格式吃掉你的时间

第四层是输出适配层，做的是“统一生成、多端分发”的转换工作。因为不同平台的格式要求不一样：公众号要 HTML、知乎要 Markdown、短视频平台要按竖屏比例裁剪、小红书要加话题标签。如果每发一个平台都手动调一遍，前面省的时间又全赔回去了。

我在这层做了一组转换节点：

• 文本统一输出为 Markdown，再转成各平台需要的格式；
• 图片统一输出 16:9、1:1、3:4 三种比例，分别对应横屏视频封面、图文帖、短视频封面；
• 视频统一生成竖屏 1080×1920，配好字幕文件再导出。

这套适配层看起来不起眼，但它是“从能用变成好用”的分水岭。

3. 上手复制：从一台空服务器到跑通首个工作流

真正复制这套系统，不需要高深的编程能力，但需要能看懂配置文件、会用命令行。下面一步步走，我尽量把容易出错的地方标出来。

3.1 环境准备与一键部署

先说硬件。纯文本类工作流，一台 4核8G 的云服务器就够了。如果要跑本地图片生成，建议至少 32G 内存加一张 8G 显存的显卡，或者干脆把图片生成接到云 API，服务器只做调度。

我自己的部署环境是 Docker Compose，因为几条命令就能把整套环境拉起来。项目目录结构大致如下：

ai-workbench/ ├── docker-compose.yml ├── .env ├── workbench/ │ ├── apps/ # 编排平台配置 │ ├── prompts/ # 提示词库 │ └── storage/ # 生成文件、素材 └── restore.sh # 一键恢复脚本

部署命令很简单：

cd ai-workbench docker compose pull docker compose up -d

第一次启动大概要下载近两个 G 的镜像，之后每次换环境就这三条命令。我把这段写成了restore.sh，恢复环境时执行bash restore.sh就行。

3.2 模型网关配置：最容易被轻视的一步

网关配置是整个工作台能否稳定运行的命门。我在.env文件里集中管理所有密钥和模型映射：

# 密钥管理 DEEPSEEK_API_KEY=sk-xxx DASHSCOPE_API_KEY=sk-xxx AI_GATEWAY_BASE_URL=http://gateway:8080 # 逻辑模型映射 WRITING_MODEL_NAME=deepseek-chat SCRIPT_MODEL_NAME=qwen-plus QUICK_MODEL_NAME=deepseek-turbo IMAGE_MODEL_NAME=cogview VIDEO_MODEL_NAME=wan2.1-1b

为什么强调这个？因为如果你不建网关，每个工作流节点直接填模型名，就会出现同一个模型地址在十几个节点里重复出现的情况。某天模型服务商改了接口版本，你要跑进去逐个节点改。而网关模式下，只改一处映射。

Gateway 本身我用的是开源 API 网关容器，支持 OpenAI 兼容格式，配置一次就能统一路由到不同厂商。所有节点请求统一发到网关地址，由网关做模型选择、负载均衡和失败重试。

3.3 创建第一个文本工作流：文章生成器

先跑通一个最简单的“输入主题，输出文章”流程，验证整体链路。

可视化编排平台上创建一个空白工作流，加上四个节点。第一个节点是触发器，我用 HTTP 请求模拟，传入参数topic和style。第二个节点是大纲生成，提示词模板长这样：

你是一位资深编辑。用户会提供一个主题，请生成一个 6 到 8 个小节的文章大纲。 要求： 1. 每个小节要有具体信息量，禁止空洞标题； 2. 逻辑上层层递进； 3. 输出 JSON 数组，每项包含 section_title 和 section_keywords。 主题：{{topic}} 文风：{{style}}

注意这里的占位符变量{{topic}}，来自上一个节点的输出或触发参数。第三个节点是分段生成，它接收大纲数组，逐个小节生成正文。这里有一个关键细节：第四个节点是内容安全检测。很多人会省这一步，但我强烈不建议。生成的内容先过一次关键词过滤和自检提示词，有问题就自动打回重新生成，避免不可控输出。

整个流程跑通后，在编辑器里把它设为“启用”，以后调 API 接口就能直接触发。

3.4 给工作流加图片节点

文本流程稳定后，我加了配图节点。图片生成的调用方式跟文本不太一样，通常需要异步等待，所以我加了两个节点：一个是“提交生成任务”，另一个是“轮询任务状态”。

工作流里的提交节点会这么做：

把一段画面描述发送给图像生成 API，拿到 task_id； 等待 10 秒后，查询 task_id 的状态； 如果完成，下载图片并存入 storage/images；如果失败，重试一次。

这个看似简单的逻辑，其实是后面处理视频批量生成的基础。编辑好画面描述提示词，一个“文章配图”自动化就完成了。整体流程：输入主题 → 生成大纲 → 展开正文 → 安全检测 → 配图生成 → 打包输出。从触发到完成，一篇带图长文大概 3 到 4 分钟。

4. 实战效果：一条从小说到 AI 短剧的完整流水线

我要重点说说这条流水线，因为这是整套工作台里最复杂也最有成就感的部分——从一部小说的一个片段出发，直接生成一段多镜头 AI 短剧，包括分镜脚本、画面素材、配音和字幕。

4.1 剧本结构化：把“好看”变成机器能理解的参数

AI 短剧和传统剪辑不同点在于：机器不理解“气氛”“情绪”这种模糊概念，你必须把每个镜头拆成清晰指令。我在提示词库里专门写了一个“分镜脚本”模板，要求模型按固定 JSON 格式输出每一镜：

{ "scene_id": "S01", "location": "夜色下的城市天台", "time_range": "夜晚", "characters": ["阿城", "小雨"], "action": "阿城靠在栏杆上，小雨站在他身后三米处", "dialogue": [ {"speaker": "阿城", "line": "你真的决定了？"}, {"speaker": "小雨", "line": "没有回头路了。"} ], "camera": "中景，缓慢推近", "visual_style": "冷色调，霓虹光晕，轻度胶片颗粒" }

模型生成 JSON 的能力直接决定了后续流程能不能走下去。为了保证它稳定输出结构化剧本，我在系统提示词里加了一句“只输出 JSON，不要输出任何解释”。但第一次跑的时候，模型还是会在 JSON 前后加说明文字，导致解析报错。后来我在下一层加了解析容错：用正则或者裁剪标记提取 JSON 区域，再交给解析器。这一步就叫“模型输出后处理”，在批量生产的场景里几乎必备。

4.2 画面一致性问题：AI 出图最让人崩溃的环节

如果你直接让模型为每个分镜生成独立图片，出来的角色大概率每张脸长得都不一样。这问题我踩了很久，最后靠三层机制才解决：

• 角色锚定：先为每个主要角色生成一张标准形象图，存到storage/characters/。后续所有画面生成提示词里都引用这张图作为参考，而不是全靠文字描述。
• 参考图叠加：生成场景时把角色参考图作为输入，让模型基于参考图重构，而不是从零随机生成。
• 固定镜头模板：同一个场景的多个镜头，保持风格描述不变，只改动作和角度。

举个具体例子。生成“阿城站在天台”这张图时，画面描述模板会拼出这样的提示词：

基于参考图 character_acheng.png，人物保持面部特征一致。 场景：城市天台，夜晚，冷色调霓虹光。 动作：靠栏杆，侧脸，双手插兜。 镜头：中景。 负面提示：手指畸形，面部扭曲，多只手臂，模糊。

加了参考图之后，连续镜头的角色一致性明显提升。虽然偶尔还会有细节瑕疵，但至少不会出现“换一个人”的灾难场面。

4.3 配音与声音设计：不要小看“声音”

短剧配音比文本生成更容易被忽视。我第一次做的时候直接用单一 TTS 读所有台词，结果听感非常奇怪——男女角色、老人小孩全是一个音色。后面我改了策略：每个角色固定一个音色 ID，配音节点按剧本里的dialogue.speaker字段自动挑选音色。

对白节奏也要控制。我加过一个“呼吸感”参数，在每句台词后面强制留 0.3 到 0.5 秒静音间隔，避免连读感。后来发现这个静音间隔对观感影响极大，尤其是情绪戏。你也可以在提示词里让模型先标注每句台词的语气标签（平静/激动/哽咽/低沉），配音节点再根据语气调整语速和音调。

4.4 组装合成：所有素材怎么自动拼成视频

从剧本到成品，工作流的最后一段是把图片、配音、字幕组装成视频文件。这个环节以前是最费人工的，步骤琐碎：导入图片、设置时长、加字幕、配音轨、加转场。我在工作台里写了几个自动打包脚本，流程如下：

1. 每张画面按对应台词时长生成静态镜头，最长不超过 5 秒；
2. 配上轻微推拉效果，模拟镜头的“呼吸感”；
3. 字幕文本从剧本的对话字段自动提取，按说话人分色；
4. 背景音乐选用无版权曲库，按场景情绪标签匹配；
5. 统一导出 MP4，编码参数固定。

实测下来，一个 15 镜的短剧片段，从输入小说片段到出片，大概 40 分钟。这个速度虽然不算夸张，但它是全自动的——我晚上提交一批任务，早上起来素材都备好了。

5. 连续跑了一个月，我踩过的四个真实坑

这套工作台不是一次成型的，跑了一个多月，翻过不少车。我挑四个代表性强的记录一下，基本属于“文档上不会写、但实操必遇到”的典型问题。

5.1 模型输出解析的坑：不稳定的 JSON

最频繁遇到的问题就是模型“不听话”，明明要求输出 JSON，它偏偏在开头加一段“好的，我来生成”，结尾又加一句“以上就是我的回答”。如果工作流直接把输出交给解析器，十次有十次报错。

我的解决办法是在后处理节点里做两件事：

• 先用“裁剪规则”定位 JSON 的起始标记和结束标记，比如从第一个{或[开始，到最后一个}或]结束；
• 再用“重试机制”兜底——如果解析失败，把错误信息连同原文一起回填给模型，让它重新格式化输出。

重试的提示词我写得很直接：

你上次的输出不是合法 JSON，请仅输出严格 JSON 格式，不要任何解释或包装。 错误信息：{{error}} 原内容：{{raw_output}}

加了重试之后，结构化流程的稳定性从八成的成功率提升到九成五以上。

5.2 成本失控：每次生成都在烧钱

工作台跑起来之后，API 费用隐隐有些失控。尤其是生成分镜脚本时，我把整个小说的章节一次性丢给模型，上下文动辄几万 token，光进一次上下文就要一块多钱。批量跑起来就是几十块。

我的对策是三层节流：

• 上下文精简：只把当前需要改编的情节片段传进去，而不是整本小说。为了让模型理解前因后果，我会先用一个精炼节点把前面的剧情压缩成 200 字背景摘要。
• 结果缓存：凡是相同输入触发的工作流，直接命中缓存，不再调用模型。这个对“改标题”“换风格”这种反复调试的场景特别有用——相同的主题不会重复烧钱。
• 便宜的模型干便宜活：标题生成、关键词提取这类低难度任务，全部指向轻量模型，只有长文、剧本这种硬骨头才动用高档模型。

5.3 角色一致性崩坏：越往后越离谱

前期用参考图解决了“同一个故事里角色稳定”问题，但跑多集之后出现了新问题——角色前后集穿越。比如第一集阿城穿黑色外套，第二集模型非要给他穿红色卫衣。单一参考图管得住脸，管不住服装和场景。

修复方式是在角色锚定图的基础上加“服装标签”：

角色_阿城_标准装束：黑色外套+深灰T恤+牛仔裤

把这些装束描述固定成一个字符串，在每次出图时拼进提示词。同时，我有意识地限制参考图使用时长，跑一段时间会人工核对一批输出，如果发现风格漂移就重新生成参考图。别指望一次设定终身不变，AI 生成的东西就是需要持续维护。

5.4 长时间任务超时：批量任务排队压垮服务器

工作流一旦批量跑，任务积压是避不开的问题。起初所有任务都是同步等待——提交图片生成请求后，工作流进程一直挂起等结果。结果任务一多，进程全部被卡住，新任务根本排不进去。

我把这里改成了“异步化”：每个任务提交后立刻返回一个task_id，后台通过队列系统处理，工作流节点定时轮询。这个架构听起来高大上，其实就是引入了一个消息队列，任务进来先入队，处理节点按顺序消费。配合前面说的轮询节点，整套批量生产能力才真正释放。

关键一点：异步系统的日志非常难排查，我建议从一开始就把任务状态持久化到数据库，每步都写日志。不然任务失败之后，你连它倒在哪一步都查不出来。

6. 把它变成“多 AI 协作”的智能体工作台

用完一段时间，你会发现固定工作流有个天花板：它只能执行“你已经想到的流程”，不能自主探索“你没想到的解法”。比如文章生成器只能按你预设的几种文风输出，不会判断这篇稿子适不适合改成长视频脚本。为了突破这个限制，我把工作台升成了多智能体协作系统。

6.1 为什么要做多智能体

单一工作流本质上是“把流程固化”，但内容创作有很强的发散性。一个好的创意可能需要来回试错、互相批评、持续迭代。我参考了最近公开的一些大模型智能体训练方法，核心思想其实就四个词：分工、反馈、记忆、迭代。把不同职能拆给不同智能体，让它们像团队一样协作，比单个智能体硬扛效果好得多。

我拆了几个基础角色：

• 策划智能体：负责选题、拆解策略、定目标受众；
• 创作智能体：负责产出正文、脚本、画面描述；
• 审核智能体：模拟目标读者，检查逻辑漏洞、语气问题、合规风险；
• 优化智能体：接收审核意见，修改并重写。

这套架构不用重新搭环境，还是复用原来的工作台，只是把节点之间的连接从“直线”改成了“有分支的回路”。

6.2 三种协作模式：串行、并行、审核环

多智能体的编排方式，我实际用下来发现三种模式就够覆盖绝大多数创作场景。

串行模式适用于流水线作业。策划 → 创作 → 审核 → 优化，一步接一步。比如一篇科技评测文章，先让策划定角度，创作写初稿，审核补技术细节漏洞，优化再润色。这种模式效率高，但容错性低，任何一个环节拉了胯，后面全受影响。

并行模式适用于方案探索。让创作智能体同时产出 5 个不同风格的标题或封面方案，然后由一个筛选智能体投票挑最优的。之前做短视频封面的时候，我都是靠这个模式批量试不同的风格，选出的结果确实比单条生成的好很多。

审核环路主要用于质量敏感型内容。创作 → 审核 → 修改 → 再审，直到审核通过或达到最大迭代次数。我写技术教程时会用这个模式，确保代码示例没有明显错误。为了控制成本，我设置了最多迭代 3 轮，超过上限就降级人工处理。

6.3 智能体之间怎么说话：别用自然语言

多智能体协作最容易犯的错误，是让智能体之间用长段自然语言来回交流。这会导致上下文越滚越大、成本剧增，而且解析困难。我给每个智能体规定了统一的通信格式——JSON 消息。

例如创作智能体交付一份内容，消息结构是这样的：

{ "task_id": "task_001", "agent": "creator", "status": "completed", "draft": { "title": "...", "sections": [ {"heading": "...", "body": "..."} ], "suggested_tags": ["AI", "自动化"] }, "confidence": 0.86 }

审核智能体返回意见也按标准格式：

{ "agent": "reviewer", "issues": [ {"level": "error", "section": "2", "message": "技术概念描述不准确"}, {"level": "warning", "section": "5", "message": "例子可以更贴近实操"} ] }

有了这套“通信协议”，智能体之间的协作就稳定多了。现在去搜“大模型智能体训练”相关内容，你会发现很多团队都在强调“结构化输出”和“多智能体间的信息传递标准”，这确实是从单流程走向多智能体协作的核心一步。

7. 复制之前的最后清单：哪些照搬，哪些必须改

最后给你一份实用清单，免得你复制完发现部分内容并不适合自己，又绕弯子。

7.1 强烈建议照搬的部分

环境部署和恢复脚本是最值得原样拿走的。容器化部署没有业务逻辑，你能跑通，我这边也能跑通。提示词库的结构也是通用的——按用途分文件夹、用占位符传参、模板文件外置，这套组织方式几乎是零成本迁移。

统一模型网关的思路也建议照搬。别嫌一开始配置麻烦，等你接的模型超过三个，就会体会到统一网关的好处。我自己切模型现在只需要改一行映射，这习惯养成了，边际成本极低。

7.2 必须按你自己的场景改的部分

提示词内容必须改。我给文章、短剧、配音设计的提示词带很强的个人风格偏好。比如我的分镜模板偏冷色霓虹城市风，你要做田园治愈类内容，直接套用就会水土不服——但结构可以参考，把风格描述、角色设定、负面提示词换成你自己的偏好即可。

内容安全检测的规则也必须按你的受众和使用场景调整。哪些词必须拦截、哪些话题需要规避，这事没有统一标准，只能根据实际反馈迭代。

模型的选择和调度策略需要你自己测试。不同模型在不同任务上的表现差异很大，而且模型版本升级很快，我文中写的映射关系可能隔两个月就过时了。保持“逻辑模型名”的抽象层，就是为了方便你随时替换实际模型而不影响工作流。

7.3 我的个人体会

如果只留一句话，我想说：这套工作台最值钱的不是某个提示词，也不是某个工作流，而是那套“配置与流程分离”的思想。你拿到我这个版本后，先别急着折腾新功能，照着最小闭环跑一个星期，把文本生成和配图这两条链路跑稳，再往里加视频、加多智能体协作。我是从最简版本开始逐步迭代的，每一次只加一个模块，出了问题也容易定位。一次想全部部署到位，大概率只会收获一团乱麻。

动手吧。复制、跑通、然后改成你自己的东西。