先交代一下背景我自己不是纯技术出身日常做产品和运营多一些代码能力属于“能看懂、能改小bug、从零搭工程有点心虚”的水平。前段时间因为业务需要想快速验证“AI漫剧生成平台”这个方向能不能跑通就咬牙给自己定了一个目标4小时内从空目录到一个能用的Web平台用户输入一个脑洞创意系统自动生成剧本、分镜、画面、配音最后拼成一条完整的漫剧视频。全程主要靠AI编程助手代写代码我做需求拆解和验收。之所以敢这么干是因为最近一段时间AI编程的能力已经到“给我清晰需求它真能写出能跑的工程”这个阶段了。漫剧本身又是非常适合AI流水线化的内容形态文字变剧本、剧本变分镜、分镜变图片、图片加配音加字幕变视频每一环都是大模型擅长的事。我实际做下来4小时是真的够用的但“够用”的前提是有清晰的架构思路和踩过坑之后的干法。这篇就把我完整的过程、技术选型、提示词思路、踩坑记录一次性写出来。想自己搞一个AI漫剧平台的或者想看看AI编程到底能帮你干多少活的都可以直接照着走一遍。1. 先搞明白AI漫剧生成平台到底要做什么很多人一听“漫剧”第一反应是“这不就是动画吗”其实不太一样。漫剧是近几年在短视频平台火起来的一种内容形态本质上是“动态漫画配音字幕”的短剧画面是静态图片为主通过轻微的镜头推拉、人物口型变化、运镜转场做出动态感配合配音和字幕讲故事。它比纯动画制作成本低得多但观赏性又比图文号强所以特别适合批量做内容。我这次要做的平台就是把漫剧的制作流程全部自动化。用户只需要给一句话或者一段脑洞平台自动跑完下面的链路剧本生成大模型根据用户创意写出分幕的剧本包含幕次、场景描述、角色台词、旁白。分镜拆解把剧本每一幕拆成若干个分镜每个分镜有画面描述、镜头角度、景别、氛围关键词。画面生成按分镜描述调用文生图能力生成漫画风格的图片。配音合成把台词和旁白交给语音合成生成音频还能指定音色、语速。视频组装把图片、音频、字幕按时间轴拼起来加上运镜效果和转场导出MP4。这个平台的稀缺点在于它不是一个单点工具而是一条完整的“创意到成片”的流水线。市面上一堆工具能生成剧本、能画图、能配音但能把这些串成一个面向普通用户的产品才是真正的价值所在。我为什么坚持用AI编程来做这个平台因为它的核心逻辑非常清晰每个模块都是标准的接口调用文本生成模型管剧本图像生成模型管画面语音模型管配音FFmpeg管合成。这类“串联多个AI能力”的应用恰好是AI编程助手最擅长写的代码类型因为它不需要复杂的算法创新重点是流程编排、接口对接、状态管理和前端交互而这些恰恰是有大量成熟模式可循的工程代码。再加上我自己对漫剧内容的理解还算深能告诉AI每一步需要什么参数、输出什么结构。这种“我懂业务、AI懂代码”的搭配是4小时能跑通的根本原因。2. 技术选型这4小时里我用到的核心工具和框架技术选型这件事我建议先想清楚一个原则4小时交付一个可演示的POC选型的第一目标是“别给自己添堵”。二次封装越少越好运维成本越低越好AI编程助手越熟悉越好。我最终定的技术栈是这样的模块技术方案选择理由前端Next.js React Tailwind CSS组件生态成熟AI编程助手训练数据里这类代码极多生成质量最高且自带API路由能力后端逻辑也能塞进去后端Next.js API Routes 或 FastAPI项目初期直接用Next.js的API路由一个工程搞定前后端省去跨域和部署麻烦后续并发大了再拆FastAPI数据库SQLite Prisma零配置文件即库适合快速开发Prisma的schema写法AI太熟悉了几乎不会写错文生图文生图API国内主流大模型平台基本都有不用自己部署模型按张计费POC阶段最划算配音语音合成API拿到文本直接合成音频支持指定音色和语速视频合成FFmpeg图片加音频合成视频、加字幕、做缩放运镜命令行一条龙而且AI编程助手对FFmpeg命令的掌握非常扎实AI编程助手Cursor这类AI代码编辑器优势在于能理解整个项目的上下文不只是补全单文件而是能跨文件改代码这对快速搭工程极其重要这里多说一句为什么选FFmpeg而不是找一堆Node库去拼视频合成。FFmpeg是几乎唯一的正确答案因为漫剧视频的本质操作就是“把一张图变成一段5秒的动态画面”也就是俗称的Ken Burns效果缓慢缩放和位移再加字幕、再拼音频。FFmpeg的zoompan滤镜、subtitles滤镜、concat协议三个命令就能搞定全流程性能还极其稳定。AI编程助手对FFmpeg参数的理解也远超平均工程师水平因为它训练数据里相关命令太多了。数据库我只用了SQLite很多人可能觉得腾讯云、阿里云随便开个MySQL不也很快吗但注意POC阶段你连表结构都可能来回改SQLite一个文件随便折腾随时用Navicat或者命令行看数据不需要任何连接配置。等真的用户量上来了再把Prisma的provider从sqlite换成postgresql一行配置的事。3. 4小时实操全记录我是怎么一步步指挥AI干活的现在进入正题。我把4小时按阶段切成了五块每块有一个明确目标。这种时间盒式的推进方式特别适合AI辅助开发因为AI写代码快但人做需求梳理和验证才是真正的瓶颈。时间阶段目标主要动作0-30分钟需求拆解和工程初始化给AI讲清楚平台流程让它生成需求文档和技术方案30-90分钟核心后端流程跑通剧本生成、分镜拆解、图片生成、配音合成的接口串联90-150分钟前端界面和交互用户输入页、任务进度展示、结果预览150-210分钟视频合成和成片下载FFmpeg合成、字幕烧录、最终MP4导出210-240分钟整体联调和兜底处理修bug、加错误提示、补边界情况3.1 第一阶段把需求“喂”给AI编程助手打开AI编程助手的第一件事不是让它写代码而是先让它帮我生成一份需求文档和技术方案。这一步绝对不能省因为AI写代码的质量高度依赖你对需求的表达能力。你越是能把流程、输入输出、异常情况讲清楚AI写出来的东西就越能用。我当时给的提示词大致长这样我要开发一个AI漫剧生成平台核心用户流程是 1. 用户输入一个故事创意比如外卖小哥意外获得了穿越到武侠世界的能力 2. 系统调用大模型生成漫剧剧本剧本要分成3-5幕每幕包含场景描述、角色台词、旁白文本 3. 系统把剧本按幕拆分成镜头列表每个镜头包含画面描述、景别、镜头角度、氛围词 4. 系统调用文生图API根据镜头描述生成漫画风格的竖屏图片分辨率建议9:16 5. 系统调用语音合成API把旁白和台词生成音频 6. 系统把图片、音频、字幕合成一个MP4视频图片需要有缓慢缩放效果 7. 用户可以在网页上输入创意查看生成进度最终预览和下载视频 请帮我设计 - 完整的技术架构 - 数据库表结构 - 前后端接口定义 - 需要调用哪些AI服务 - 项目目录结构这个提示词一出来AI很快就给出了一份相当靠谱的技术方案包括目录结构、数据模型、API接口定义。这一步相当于让AI先做了一次免费的架构设计我在这个基础上做调整比自己从零想快太多了。这里有一个极其重要的心法跟AI协作不要只给一句话要给你脑子里的完整流程图。我每次用时都会先把流程讲给AI听甚至口述一遍我都觉得比写出来更流畅。AI会根据你的描述去匹配它训练数据里的最佳实践你描述得越精确它输出的代码就越接近生产级。3.2 第二阶段打通核心后端接口方案确认之后我开始让AI逐个模块实现。这个阶段的关键是“一次只让AI干一件完整的事”不要让它一口气把整个工程写完。因为它一旦开始自由发挥很容易在某个不重要的地方写错而你后面要花大量时间去定位。先做剧本生成模块。我给AI下的指令是现在先实现剧本生成模块。在app/api/generate-script/route.ts里实现一个POST接口接收用户输入的创意文本。调用大模型API返回结构化JSON包含title、logline、scenes数组每幕包含scene_number、location、description、segments数组每段包含typedialogue或narration、character、content。注意对大模型返回结果做JSON解析容错解析失败时重试一次。为什么要单独说“做JSON解析容错”因为这是AI调用大模型的常见坑大模型偶尔会返回带markdown格式代码块的JSON直接JSON.parse必炸。让AI提前处理这个边界情况后面能省很多事。AI也确实很听话直接用了正则提取重试机制代码干净利落。然后依次做了分镜拆解接口、文生图接口、配音接口。每一步我都是同样的节奏先说清楚输入输出再强调一下边界和异常处理然后验收。到这一步其实整个后端的数据流水线已经通了我甚至用curl测了一下输入一个创意真的能拿到剧本JSON。3.3 第三阶段前端交互和任务进度展示后端通了之后我开始做用户界面。这里我没有让AI自由设计而是给了明确的界面结构因为我知道漫剧生成的核心交互就三块输入创意、等待生成过程、预览结果。我给AI的指令是这样的在app/page.tsx里实现主页面。布局用深色背景顶部是产品名和简短的slogan。中间是一个大输入框用户填写故事创意。下方是生成漫剧按钮。点击按钮后调用后端接口开始生成然后轮询任务状态接口实时展示当前阶段阶段包括生成剧本中、拆解分镜中、绘制画面中、合成配音中、生成视频中。每完成一步就打勾。全部完成后展示视频预览和下载按钮。这一步看似简单但AI写出来的代码有个问题它不知道漫剧平台长什么样所以界面会比较朴素。我有意没让它加过多的视觉修饰因为POC阶段先把流程跑通最重要样式可以后面再打磨。但AI编程助手的Tailwind能力确实很强哪怕不怎么做视觉设计深色背景加上几个卡片区域整体观感就已经能拿去给朋友看了。进度展示这里我多说一句漫剧生成是个非常典型的长任务因为文生图和视频合成都很慢动辄一两分钟。如果前端不做任务状态管理用户会以为页面卡死了。所以我让AI加了一个轮询机制前端每2秒查一次任务状态后端把阶段信息存在数据库里。这个交互设计比任何花哨功能都重要它直接决定了用户对产品“灵不灵”的直觉判断。3.4 第四阶段FFmpeg视频合成视频组装是平台里最核心也最容易被低估的一步。我给AI下了这个指令写一个Node脚本输入一个视频任务ID从数据库查出分镜图片路径、配音音频路径、字幕信息用FFmpeg完成以下操作 1. 对每张图片应用zoompan效果让图片有缓慢放大或平移的感觉每张图片持续时长对应音频片段的时长5秒左右 2. 为每段配音添加对应的字幕字幕文字在画面下方居中黄色描边字 3. 把所有分镜视频片段按顺序拼接成一个完整视频 4. 输出9:16竖屏的mp4编码用h264音频用aac这个阶段AI的优势体现得淋漓尽致。FFmpeg的命令行参数非常多一般人不可能全部记住但AI去检索训练数据里的组合方式效率高得惊人。它给出了一个包含concat协议、unity脚本调用的方案第一次跑就成功了。不过这里我也踩了一个坑后面会细说zoompan滤镜在部分FFmpeg版本里输出分辨率会偏小导致画面模糊。加了一句scale1080:1920之后问题才解决。这种坑如果你完全没有FFmpeg经验纯靠AI调试会浪费不少时间所以我强烈建议视频合成这个环节你至少要提前理解zoompan、concat、subtitles三个滤镜的基本概念哪怕没写过命令也行至少知道应该往哪个方向去要求AI。3.5 第五阶段联调和兜底最后半小时是最痛苦的也是必然的。核心链路虽然通了但各种边角问题开始冒头。比如某个文生图API偶发超时后端没有做重试任务直接失败配音接口返回的音频格式是MP3但FFmpeg拼接时要求输入文件格式一致用户输入的创意太长大模型token超限接口报了400。这些事情说实话AI编程助手没法帮你提前全部规避因为它虽然能看到全局代码但没有真正运行过完整业务流。我的做法是把看到的报错原封不动复制给AI让它给修复方案。这时候AI通常能给出很精准的修复建议因为它能看到出错代码的上下文。就像带了一个速查Stack Overflow经验的实习生你告诉它报错信息它能给你正确的方向但具体是不是还有隐藏问题得靠你持续压测。到这一步4小时基本到了。我输入了一个测试创意“一只会说话的猫开了一家深夜食堂”大概3分钟之后平台自动生成了一条包含5幕、8个分镜、有配音有字幕的漫剧视频。那一刻的成就感真的和手写一套完整系统差不多。4. 核心模块实现细节命令、参数和提示词干货这一节把整个平台里最值得抄的细节全部展开。如果你要复刻这个项目这些内容可以直接当成开发清单来用。4.1 剧本和分镜提示词模板剧本生成的质量直接决定了成片质量。我的提示词模板经过好几轮调优核心是“把漫剧的叙事节奏写进提示词里”。普通的大模型提示词只能写出小说式的叙述性内容这并不符合漫剧需求。漫剧需要的是强冲突、快节奏、适合画面呈现的场景。最终长期使用的剧本提示词模板大概是这样你是一个资深的漫剧编剧。用户会给你一个故事创意你需要将它改编成适合竖屏漫剧的剧本。 要求 1. 总篇幅控制在3-5幕每幕60-120字左右的信息量 2. 每幕必须有明确的场景变化或情节推进 3. 台词要口语化、短句为主旁白用来交代背景和衔接场景 4. 适合漫画画面呈现避免抽象的心理描写 5. 输出格式严格为JSON 创意{user_input}分镜拆解的提示词同样重要它是文生图质量的第一道关卡。画面描述必须包含主体、动作、场景、景别、镜头角度、画风、光影。我让AI把分镜描述转换成一串完整的英文描述词因为大多数文生图模型对英文细节的响应更稳定。4.2 文生图接口的参数配置文生图这一步参数直接决定画面观感。我实际调试下来最稳定的组合是这样参数推荐值说明分辨率768x1344 或 832x1216接近9:16竖屏方便后续视频裁切画风日漫/国漫风格关键词漫剧受众最买账的视觉风格步数20-30步再高提升有限耗时成倍增加提示词英文详细描述主体、动作、场景、景别、光线、风格词缺一不可反向提示词文字模糊、多余手指、变形脸等大幅降低翻车概率这里要特别提醒文生图API是有并发限制的不同平台差异很大。如果8个分镜同时发起请求很容易触发限流。我后来改成了用p-limit做一个并发控制一次最多3个并发基本稳定。这个细节如果不做用户生成一个视频后半段画面经常刷不出来。4.3 语音合成关键参数漫剧配音的风格选择很有讲究不一定用新闻播音腔我实际测试发现带有轻微情感演绎的音色更合适。参数上重点看两个语速设置在中偏快大概1.1到1.2倍太慢会让漫剧显得拖沓音调保持中性不要刻意压低或升高。配音生成还有一个容易忽略的点旁白和角色台词最好分开处理。因为旁白是第三人称叙述角色台词是第一人称演绎用同一个音色会非常出戏。我让AI在生成音频时为旁白和角色分别传入不同的voice参数效果立刻上了一个档次。4.4 FFmpeg合成命令与避坑指南视频合成命令贴一个核心版的实测可用版本。假设有一张分镜图片input.jpg、一段对应音频audio.mp3、字幕文件sub.srt需要合成一个5秒的动态视频片段ffmpeg -y -loop 1 -i input.jpg -i audio.mp3 -filter_complex \ [0:v]scale1080:1920,zoompanzmin(zoom0.0008,1.1):xiw/2-(iw/zoom/2):yih/2-(ih/zoom/2):d125:s1080x1920:fps25[v]; \ [v]subtitlessub.srt:fontsize18:force_styleAlignment2,MarginV60,OutlineColourH000000,BorderStyle1[vout] \ -map [vout] -map 1:a -c:v libx264 -c:a aac -pix_fmt yuv420p -shortest output.mp4几个关键参数解释一下。zoompan的d125表示每帧输出时长在25fps下正好是5秒。s1080x1920显式指定输出分辨率避免部分FFmpeg版本输出解析度缩水的坑。-shortest确保视频在音频结束时截止避免末尾黑场。字幕样式里Alignment2是底部居中OutlineColour加黑边保证白字在任何画面上都看得清。多个分镜片段拼接我推荐先生成每个分镜的mp4片段再用concat协议拼接ffmpeg -f concat -safe 0 -i filelist.txt -c copy final.mp4注意filelist.txt里路径不要带特殊字符每行格式是file segment_001.mp4。如果各片段编码参数不一致-c copy会失败这时候只能重新编码ffmpeg -f concat -safe 0 -i filelist.txt -c:v libx264 -c:a aac final.mp4。这里最花时间的坑是音频采样率不一致。不同配音API返回的音频可能是44.1kHz和16kHz混合的concat直接会报错。我最终的解决方案是在生成每个片段时统一加一个音频重采样-ar 44100 -ac 2。提前统一后面整个流程顺滑很多。5. 常见问题与排查技巧实录这一节直接放干货。按“我实际遇到的问题、怎么排查的、最终怎么解决的”来写一共整理成一张速查表后面是我认为最有价值的几条避坑心得。问题现象可能原因排查思路和解决方案大模型返回的JSON解析失败大模型偶尔会包markdown代码块或返回内容被截断解析前先做正则清理去掉json标记解析失败自动重试一次还是失败就直接把原始文本返回给用户提示“剧本生成失败”文生图并发请求大量报429超过API限流阈值用并发池限制并发数一次最多3个失败任务自动排队重试2次视频画面模糊zoompan滤镜输出分辨率缩水在zoompan后强制加scale1080:1920并在zoompan里显式指定s1080x1920视频拼接后音画不同步各片段音频采样率或声道数不一致在生成每个片段时强制-ar 44100 -ac 2统一音频参数用户提交后页面长时间无反馈后端生成视频是长任务前端没做轮询任务状态入库前端每2秒轮询一次展示当前阶段和完成进度生成到一半任务失败用户数据丢失任务中断后没有恢复机制把每个阶段的任务状态持久化到数据库页面刷新后根据taskId恢复查询API调用超时导致任务卡死第三方API偶发慢响应设置HTTP客户端超时时间超过30秒主动失败并重试图片风格不一致分镜间画风描述词不统一把画风关键词固定写入分镜生成提示词每次自动附加相同画风描述5.1 关于AI生成代码的幻觉问题用AI编程助手开发最大的心理预期管理就是要接受“它写的东西不一定完全对”。我这次大概遇到5处代码需要手动修正其中两处是AI“一本正经地编造API参数”。比如它写了一个不存在的FFmpeg滤镜参数我跑命令直接报错。这种时候不要跟AI死磕把报错原文贴给它让它基于报错信息自查命中率会高很多。还有一个实用技巧每个AI编程助手都能“选中代码报错信息”一起发送这样它可以直接定位问题的代码上下文不用你在聊天窗口里复制整个文件。这个功能我这次用得非常频繁效率直接翻倍。5.2 任务队列和失败重试的重要性刚开始我只做了同步调用就是用户提交后后端等所有环节跑完再返回结果。但文生图加视频合成动辄一两分钟HTTP连接根本扛不住。改成任务队列模式是必然的提交任务时只生成一个taskId并写入数据库返回给前端后端异步逐阶段处理前端轮询状态。这是整个平台从“玩具”变成“能演示”的关键一步。这个改动我一开始没意识到后来第一次测试整个链路浏览器转圈转到超时才理解长任务必须异步化。建议你在自己做的第一版里就把这个机制设计进去不要走我这种先同步后改异步的老路。5.3 工具链自身的配置坑AI编程助手虽然强大但它生成的代码默认假设你装好了Node环境、FFmpeg、还有各种依赖。其中最容易出问题的是FFmpeg的安装路径。本地开发时我用的FFmpeg是静态编译版本放在自定义目录AI写代码时用的是ffmpeg命令全局调用的方式结果在代码里执行时一直报“command not found”。后来统一改成在Node代码里用process.env.FFMPEG_PATH配置路径问题才解决。类似的坑还有图片存储目录权限。AI默认把生成的图片存在/tmp/gen-imagesWindows开发机上可能没有这个目录就会报错。提前把存储路径做成可配置放到项目目录下storage/images一劳永逸。6. 平台还能怎么进化从POC到产品的几个方向4小时做出来的东西严格来说是“能跑通流程的原型”距离一个真正能放出去收费的产品还差不少工作。但正因为整个架构是清晰的流水线式设计后面加功能其实非常顺。最值得先做的是角色一致性。现在每个分镜的画面是独立的同一个角色在不同图片里长相会漂移。解决方案有两个路线第一是给文生图接口传角色参考图要求模型基于参考图生成第二是做角色锁定提示词在分镜描述里固定角色的外貌特征描述。两种我都试过参考图路线效果最好但API支持情况要自己验证。然后是支持更细粒度的创作干预。现在用户只能给一个创意系统全自动生成但如果用户想改某个分镜的台词、重新生成某张图、替换音色平台需要支持局部重生成。这个需求在数据结构上已经支持了因为每个分镜都是独立的数据库记录局部更新只是加一个“重新生成某个分镜”的接口。商业化方向就更多了比如素材库运营、企业定制、外包代做、内容平台API输出。漫剧生成平台的下游是大量做短视频矩阵的MCN和独立创作者他们最在意的其实是成本和效率。这个POC跑通后我有底气告诉他们一条漫剧视频从创意到成片的时间成本可以从过去的一周压缩到几分钟。7. 最后一个非常想分享的个人体会四小时做一个AI漫剧平台听起来很唬人但冷静拆解之后会发现这里面“AI编程”承担的是执行层的工作真正的架构能力、业务理解、验收判断仍然是我完成的。AI帮我把那些繁琐的、有明确模式的工程代码写得飞快但它不会替你想清楚“漫剧的核心体验是什么”“用户为什么愿意用你的工具”。说到底AI编程时代最值钱的能力就是把自己脑子里的需求清晰地讲给AI听并且能在它给出方案的时候分辨出哪个方案更符合你的真实场景。我这次能做到4小时交付不是因为我代码写得快而是因为我清楚地知道漫剧的每个制作环节应该长什么样、参数应该怎么配、坑大概在哪里。这些认知才是AI替代不了的部分。如果你也想做类似的东西我的建议是别等直接开干。找一个你熟悉的垂直场景把流程拆成AI能力能覆盖的环节然后用AI编程助手把代码量最大的部分包掉。技术不是这道题的门槛你对业务的理解深度才是。四小时之后你手里握着的那个能跑的Demo会推着你去思考下一个真正重要的问题用户到底会为什么买单。