企业官网建设流程全解析

4个小时，让AI帮我从0开发了一个AI漫剧生成平台。不是标题党，是真事。所谓AI漫剧，就是基于漫画分镜画面，配上台词、旁白、音效，生成一段带有运镜和动态效果的短视频，现在短视频平台上这种内容密度很高，一套剧本几十个分镜，自动合成一条两三分钟的视频，看起来就像动态漫画。我做的这个平台，核心能力是：输入一个故事主题，自动生成剧本、分镜描述、文生图提示词、配音文本，然后调用API批量生成画面和语音，最后用FFmpeg把所有素材拼成一条完整的漫剧视频。最关键是，整个系统的代码有九成以上是AI辅助生成的，从后端接口到前端操作页，从数据表设计到视频合成脚本，全部在4小时内完成。这篇文章就记录整个开发过程的思路、步骤、工具选择、踩坑实录，以及我对“AI辅助编程”这件事的实际感受，适合想用AI快速做内容工具、AI应用产品的朋友参考。

1. 项目拆解：AI漫剧生成平台到底需要什么

1.1 一条漫剧视频是怎么生产出来的

先想清楚一件事：漫剧不是简单的“图片+音频”拼接，它是一条有叙事节奏的视频产品。常规的漫剧视频大约包含七个环节：故事策划、剧本撰写、分镜设计、画面生成、配音录制、字幕制作、最终合成。如果人工来做，光分镜绘制就够画几个星期，更别提配音、剪辑。AI漫剧的意义在于把这条流水线全部自动化：剧情由大模型生成，分镜用文生图模型出图，配音用语音合成，最后用视频处理工具自动剪辑。

平台要做的就是把这条流水线封装成一个完整的系统。用户只需要输入一个主题，比如“一个程序员穿越到古代靠写代码逆袭”，系统就能自动产出：一份带有对白和旁白的分镜脚本、一批对应分镜的漫画风格图片、每张图对应的配音音频、以及一条字幕压制好的视频。这个过程中，最难的不是画面生成，也不是语音合成，而是如何把一堆独立环节可靠地串起来，处理好中间状态和失败重试。这也是我决定用AI辅助开发时第一个考虑的问题。

1.2 平台的功能需求与模块划分

在设计阶段，我把平台拆成五个模块：

• 剧本生成模块：接收主题，返回分镜列表，每个分镜包含镜头描述、画面提示词、对白文本、旁白文本。
• 画面生成模块：根据分镜描述，调用图像生成API产出漫画风格的图片，并统一尺寸。
• 语音合成模块：将每个分镜的对白和旁白合成为音频文件，支持语速、音色调整。
• 视频合成模块：将图片、音频按顺序拼接，加入镜头缩放、平移、淡入淡出等效果，生成带字幕的视频。
• 前端操作台：一个简单的Web页面，输入主题、选择风格和时长，点击生成，然后展示任务状态和最终视频。

模块之间通过任务队列解耦。用户提交一个生成任务后，后端按照“剧本→画面→语音→合成”的顺序逐步执行，每完成一步都把中间结果存到磁盘，遇到失败可以断点重试。这个设计虽然简单，但很实用，后面开发时AI帮我省了不少事。

1.3 为什么选择AI辅助编程而不是传统开发

说实话，我刚接到这个想法时也有点犹豫：一个完整的平台，涉及后端、前端、第三方API对接、视频处理，正常开发至少要一两个星期。但这次我刻意只给自己4小时，就是想验证一下“AI编程”在当前这个阶段到底能深入到什么程度。我的策略是：人负责架构和决策，AI负责生成代码和排查问题。具体来说，我先用自然语言把模块和接口定义清楚，然后把需求逐条发给AI，让它给出实现代码，我审查修改后直接跑。这种模式下，人的角色是“产品经理+架构师+测试工程师”，AI的角色是“写代码的初级工程师”，它的产出通常能直接用，偶尔需要调试。

这个选择背后还有一个现实原因：我对视频合成API和图像生成API的参数记得并不全，与其翻文档，不如让AI根据公开资料帮我写出正确调用姿势。事实证明，在4小时内能够完成，正是这种分工方式的胜利。

2. 技术选型与AI工具配合方案

2.1 后端、前端与视频合成的选型

技术栈上我选了最不折腾的一套：后端用Python FastAPI，前端用Vue 3 + Element Plus，数据库用一个SQLite文件，视频合成用FFmpeg命令行。这样一个单体应用跑在我自己的服务器上，够用也没负担。

为什么不用重量级的Spring Boot？因为FastAPI对异步任务、文件上传下载都非常友好，代码量小，AI也特别擅长生成FastAPI的示例代码。前端用Vue是因为组件生态丰富，Element Plus的按钮、表单、进度条直接拿来就拼出一个操作台，省去手写CSS的时间。FFmpeg是视频合成的老牌神器，几乎所有AI生成视频的工具底层都在调它，支持缩放、淡入淡出、字幕烧录，堪称万能。

这里有一个选型经验：如果你的目的是快速验证一个想法，不要追求“先进”和“专业”，选你身边案例最多的技术栈。AI训练数据里，FastAPI和Vue的示例代码比其他冷门框架多得多，意味着生成的代码质量更高、幻觉更少。

2.2 大模型API：剧本生成与分镜提示词

剧本生成是大模型最擅长的任务，关键是设计好结构化输出的提示词。我让AI写了一个生成器，核心提示词类似这样：

你是一名漫剧编剧。请根据主题《{theme}》创作一个长度为{scene_count}个分镜的漫剧脚本。 输出要求： 1. 每行一个分镜，用JSON数组格式。 2. 每个分镜包含字段：scene_id, shot_description, image_prompt, dialogue, narration。 3. image_prompt需要是英文，且包含漫画风格关键词，如"Chinese comic, thick outlines, vibrant colors"。 4. dialogue是角色对白，narration是旁白，两者至少有一个。 5. 剧情要紧凑，每句话适合2-8秒朗读。

经过两轮调试，AI生成的脚本结构非常整齐，直接就能解析。这里最关键的技巧是：必须让AI返回严格的JSON格式，并且字段类型固定，否则后面代码解析会非常痛苦。如果你控制不住格式，可以增加一句“不要输出任何多余文字，只输出JSON数组”。

2.3 文生图模型与图片处理

画面生成我选择了通过API调用开源文生图模型。这里不特意提具体供应商的名字，只说思路：市面上又稳定又便宜的文生图API大多支持传入提示词、负面提示词、分辨率、采样步数等参数。我让AI生成了一个统一的调用函数，输入image_prompt，输出图片URL，然后下载到本地。

分镜图片生成有一个大的坑：不同分镜的人物长相要保持一致。简单起见，我在提示词里统一加入“same main character”以及人物外貌特征描述，比如“black hair, wearing a white shirt”。如果是更复杂的项目，需要引入LoRA或角色一致性模型，但对于验证平台来说，统一外貌描述已经够用。画面尺寸统一用竖屏的9:16，也就是720x1280，这样符合短视频平台的习惯。

2.4 语音合成与字幕生成

语音合成我用的是常见的TTS服务，输入文本返回音频文件。这里同样没有用特别复杂的方案，选一个支持中文、音色自然的API，把对白和旁白分别合成为独立的MP3文件。字幕生成我并没有单独调语音识别，而是在生成脚本时就拿到了对白文本，直接用FFmpeg的subtitles滤镜烧录到视频里。

经验是：如果你希望字幕和音频严格对齐，最好的办法不是在后期识别，而是在制作时就保存文本时间轴。因为语音是逐句合成的，每句音频的时长可以从文件信息里读出来，把累计时间算一下，就能生成一个精准的SRT字幕文件。这就是“从源头控制数据”的思路，比事后识别可靠得多。

3. 4小时实战：从0到1的完整开发记录

3.1 第0-30分钟：定义需求和接口

时间紧张，不能上来就写代码。我先把整个流程画在纸上（不是用工具画图，就是拿草稿纸撸），确定模块边界和调用顺序：用户输入主题后，任务进入后台队列，按顺序执行四个阶段。

然后我让AI根据这个需求生成一个接口设计文档。我给出的描述是：

请设计一个生成漫剧视频的后端接口，支持提交主题、查询任务状态、下载结果。用FastAPI实现，数据表包含任务ID、状态、阶段、参数、文件路径等字段。给出主要API列表和字段说明。

AI很快给出了几个接口，包括：

• POST /api/tasks —— 创建任务，参数是theme、style、scene_count
• GET /api/tasks/{id} —— 查询任务状态，返回当前阶段、进度
• GET /api/tasks/{id}/download —— 返回最终视频文件

这一步很关键，后面所有代码都围绕这份接口约定来写。因此，如果AI一开始生成的接口不满足需求，你一定要立刻纠正，否则后期改动成本会很高。

3.2 第30-90分钟：后台核心代码生成

这60分钟是产出最密集的阶段。我让AI生成一个完整的工作流脚本，包含：调用大模型生成剧本、解析剧本JSON、逐条生成图片、逐条合成语音、最后生成视频。由于这个脚本承担核心流程，我拆成了几个文件，逐文件让AI生成。

第一个文件是config.py，存放API密钥、基础URL、存储路径。第二个是story_generator.py，封装剧本生成。第三个是image_gen.py，封装图片生成。第四个是tts_gen.py，封装语音合成。最后一个是video_composer.py，负责用FFmpeg合成视频。AI生成的代码质量相当不错，有个别地方需要小改，比如路径分隔符、环境变量读取方式。

核心合成部分，AI生成的FFmpeg命令大概长这样：

ffmpeg -i image_001.png -i audio_001.mp3 \ -filter_complex "[0:v]scale=720:1280,zoompan=z='min(zoom+0.001,1.08)':d=125:s=720x1280[v0];[v0]subtitles=subtitle_001.srt:force_style='FontSize=16'[v]" \ -map "[v]" -map 1:a -c:v libx264 -c:a aac -shortest output_001.mp4

这里有个细节：zoompan滤镜可以在图片上模拟缓慢放大效果，让静态画面产生镜头推近的感觉。AI直接生成了正确的参数，省了我去查文档的时间。多个分镜片段生成后，再用concat协议把所有片段拼成一个完整视频。

3.3 第90-150分钟：前端页面与联调

前端部分，我让AI生成一个Vue 3单页应用，包含一个表单、一个任务列表和一个视频播放器。说实话，这块AI生成得更快，因为UI代码非常套路化。表单有主题输入、风格选择、分镜数量滑块，点击生成后轮询后端接口获取进度，刷新到进度条上，完成后显示视频地址。

写到这里，我插一句：很多人说AI写前端容易“生成一堆垃圾”，其实问题往往出在需求描述太模糊。我让AI写代码前，先给了它后端的完整接口定义，这样AI生成的前端代码会直接调用真实接口，而不是虚构mock接口。比如：

根据以上后端接口，生成Vue 3+Element Plus页面。请求POST /api/tasks时传入{theme, style, scene_count}，返回task_id。每2秒轮询GET /api/tasks/{id}，将progress字段显示在el-progress组件上。

这样联调时几乎没有跨域问题。我还让AI在FastAPI后台加了一个CORSMiddleware，前端开发服务器直接访问后端端口，整个过程很顺。

3.4 第150-240分钟：视频合成流水线、测试与修复

视频合成流水线是最后一块硬骨头。第一版跑通时，我遇到了三个问题：生成的图片尺寸不一致、音频时长和分镜时长对不上、字幕文字位置偏移。前两个问题用FFmpeg的scale参数和-shortest标志解决，字幕问题则是我在生成SRT文件时，把时间轴计算错误。在让AI修复时，我直接把出错的SRT文件样例贴给它，它一眼看出我的时间戳累加逻辑少算了一句音频的间隔，马上修正并写好了对应的调试脚本。

到第210分钟左右，一条完整视频成功输出。里面包含12个分镜、30秒左右的时长，画面是漫画风，有对白、旁白，字幕也烧录在上面。随后我又跑了两个不同主题的任务，确认平台具备一定的稳定性，4小时目标完成。

4. 实战中遇到的坑与排查方法

4.1 AI生成代码的通病：幻觉参数与过时API

AI非常容易编造一些看起来合理但实际不存在的函数参数。比如它曾给我生成一个调用图像生成API的代码，里面用了一个自定义参数名“img_style”，结果API直接报错。排查时，我把错误信息原样发给AI，让它对照官方文档修正，它才意识到那个参数不存在。

我的解决办法是：让AI在生成调用外部API的代码时，额外要求它“只使用官方文档中明确给出的参数，不要添加不存在的参数”。同时我在代码里加了一个输入参数校验层，把固定参数预先定义好，减少AI自由发挥的空间。

4.2 FFmpeg视频合成：分辨率不一致导致报错

第一批图片生成回来时，有几张是1024x1024，有几张是768x1024，FFmpeg合成时直接报错“Width not divisible by 2”。这不是分辨率不一致的错，是滤镜要求宽高必须是偶数。解决方案是统一先scale到720x1280，并且在scale后面加上“force_original_aspect_ratio=decrease,pad=720:1280:(ow-720)/2:(oh-1280)/2”，保证画面居中且尺寸严格符合要求。

这类问题很细碎，但非常典型。我的建议是：涉及图像视频处理时，先跑通一条最简单的流水线，哪怕只有一个分镜一条音频，全部验证通过后再增加复杂度。这样能最快定位问题出在哪一环。

4.3 任务卡死与长时间等待

生成图片和配音属于高延迟任务，单张图可能要几秒到几十秒，整个任务可能要好几分钟。用户提交后如果一直等待太久，体验很差。我在实现时加了一层简单的状态管理：每个任务在开始时记录当前阶段，每完成一步就更新数据库对应字段，前端根据阶段显示不同的提示文字。如果某个请求超时，就给一个“重新生成该阶段”的按钮，实际上就是重新调用对应模块的API。

这个功能用传统开发方式写，代码量不小，但AI生成得非常利索。我让AI写一个装饰器，为每个阶段函数加上超时处理和异常捕获，失败时自动重试一次，再失败就标记任务失败并保留日志。这样的“兜底设计”让平台在演示时显得成熟很多。

4.4 用AI排查问题的几条高效姿势

我的经验是：给AI报Bug时，不要只贴“报错了”。要附带：你做了什么操作、完整的错误信息、相关代码片段、以及当时的输入数据。AI在这种情况下定位问题比很多工程师都快。有一次生成SRT文件乱码，我贴了前几行内容和对应的音频时长表，AI很快就发现是因为中英文字节长度计算不一致，导致时间轴偏移。修复方式也很简单，直接按音频真实时长切分。

另一个技巧是：让AI写测试用例。我让它为解析剧本JSON这一块写了几个单元测试，包含正常样例、缺字段样例、空数组样例，果然发现了一个“剧本生成模型偶尔返回Markdown代码块导致解析失败”的问题。修复方式是让AI在剧本生成提示词里增加一句“严禁使用Markdown代码块包裹JSON”，同时在解析前做一次正则清洗。

5. 这套方案的延伸思考与个人建议

5.1 从“AI写代码”到“AI产品经理”

这4小时让我最大的感受是：AI不仅把我从重复编码里解放出来，还倒逼我把产品逻辑想得更清楚。因为要跟AI描述需求，我必须把每个模块的输入输出、异常情况、边界条件都写明白，这个思考过程本身就是一种高质量的产品设计。现在很多团队吐槽AI写代码不好用，根源在于他们自己没想清楚要什么。

我现在开发新功能时，会先花10分钟把需求写成“给AI看的文档”，包括背景、接口、数据结构、验收标准。然后让AI生成初版，我再做代码审查和测试。这和带一个入门级开发者的协作方式几乎一样，区别是AI不会抱怨需求改来改去。

5.2 如何快速验证一个AI应用的想法

如果你也想做类似的AI内容工具，我的建议是分三步：第一，先用最简单的脚本把核心链路跑通，不需要界面，比如在Python脚本里输入关键词，输出一条视频。第二，再让AI加上接口和界面，变成能给别人演示的Demo。第三，根据别人反馈决定是否投入更多时间优化。不要一上来就做完整平台，否则AI也救不了你的时间。

我这4小时其实是压缩了这三步：前60分钟做了脚本验证，第90分钟时有了接口，第150分钟时有了前端，后面全是在打磨稳定性。每个阶段的目标都很具体，所以不会迷路。AI编程时代，真正的核心竞争力是“拆解任务”和“定义清需求”的能力。

5.3 后续可以扩展的功能方向

这个平台虽然是个Demo，但骨架完全可以用到生产环境。如果想继续做，至少有这几个方向可以扩展：支持多角色一致性的画面生成、加入镜头级参数（如运镜方向、转场特效）、把字幕制作替换为自动配音后生成SRT、增加一键分发到主流短视频平台的配置。甚至可以让AI对整条视频做质量评估，不合格的分镜自动重新生成。这些升级基本不用重构主流程，只是在对应模块里加逻辑。

我个人的计划是把这个平台继续迭代成一个小型SaaS工具，让漫画作者、短剧创作者先试用。毕竟，能自动生成漫剧视频的平台，对内容创作者来说省的是几天的制作时间。这就是AI工具最大的价值：不是替代人，而是把人从繁琐的流水线里解放出来，去做更有创意的事情。