AI电影解说：基于narrator-ai-cli与 Skill工作流深度实操与解读

一、背景写在前面最近半年我一直在做电影解说类的短视频内容从最早一条片子手工剪三个小时到中间用过几款桌面型 AI 工具再到这次彻底把工作流搬到命令行加 Agent整条链路反复折腾过几轮。这一篇是写给和我一样的内容创作者、技术博主、或者要给团队做批量内容生产的开发者看的——把 narrator-ai最近开源的命令行工具narrator-ai-cli和它的 Agent 技能文件narrator-ai-cli-skill从安装、配置、单条出片、Agent 接入到团队配额管理完整跑一遍。文章会比较长全部是实操记录没有营销话术。我本人亲自跑过整条流程所以遇到的坑、能跳过的坑、值得在意的细节都会一并写清楚。如果你只是想知道怎么装、怎么跑、怎么把它接到自己的小龙虾openclaw或者 Windsurf 里用跳到第四节往后看就行。二、传统电影解说流程为什么慢做电影解说这件事的工序其实是固定的找素材、对齐字幕、写解说文案、配音、合 BGM、压字幕、导出成片。每一步都有现成工具但工具之间并不互通。你在剪映剪了粗版回到大模型对话框里让它改写文案再到另一款软件做字幕标题卡最后回到剪映对齐时间轴。做过这件事的人都清楚真正的瓶颈从来不在任何单点工具而在工序与工序之间的切换。每切换一次就要重新理解一遍上下文、重新对齐一次时间轴、重新导一次中间产物。一条十分钟的电影解说光是工具切换的时间成本就能吞掉一两个小时。narrator-ai过去的做法是把整条流水线打包到一款桌面软件里靠图形界面操作来控制成片。这条路径对完全不写代码的创作者很友好但对我这种习惯把每个动作脚本化的人来说反而别扭——每次都要打开界面点鼠标没法接到我已经在用的命令行工作流里。所以当他们在 2026 年把整条调用链以 CLI 加 Skill 的形式开源到 GitHub 上的时候我立刻就去试了。下面我将详细拆解这套电影解说工作流的全流程细节。三、CLI 与 Skill 的关系narrator-ai-cli是一个Python 命令行工具负责本地文件处理、素材调度以及和narrator-ai开放接口的通信。narrator-ai-cli-skill是一份SKILL.md文件用自然语言加结构化指令的方式写清了每个 CLI 子命令什么时候用、参数怎么传、前置依赖是什么——这份文件是写给 Agent 读的不是写给人读的。两者的关系最容易理解的类比是CLI 封装了「调用」这件事Skill 封装了「调用顺序」这件事。人或 Agent 通过 CLI 把命令发到后端Agent 之所以知道什么时候发什么命令、拿到返回结果之后怎么接下去靠的就是 Skill 里预先编排好的判断逻辑。一个是手一个是脑。CLI 和 Skill 负责本地调用与 Agent 协作视频理解、文案生成、语音合成这些模型能力通过 AI解说大师的开放接口docs.jieshuo.cn调用。这意味着你不需要本地有 GPU、不需要自己装大模型、也不需要折腾各种推理框架——本地只需要一个能跑 Python 的环境。四、环境要求与跨平台安装系统要求不复杂——Python 3.10 或更高版本、Git 最新版、操作系统 Windows 10 或 11、macOS 11 及以上。硬件上 CPU 4 核、内存 8G 是舒服的起步磁盘预留 5G 用于 CLI 本体和临时文件。网络方面国内用户建议先准备好 GitHub 加速镜像的访问方式下面会讲到。4.1 在 Windows 上装先装 Python。打开python.org的下载页页面顶部那个黄色的 Download Python 按钮点下去拿到安装包。安装程序启动之后最关键的一步是首屏最下方那个小复选框——务必勾上「Add python.exe to PATH」。很多人第一次装 Python 出问题问题都出在这里不勾的话后面所有终端命令都会提示「不是内部或外部命令」。勾好之后点 Install Now 等它跑完。Python 装完要把所有已经开着的命令提示符窗口全部关掉重开一个新窗口这一步经常被忽略导致新装的 Python 没被系统读到然后输入验证python --version看到Python 3.10.x或更高版本号就 OK。接着装 Git。去git-scm.com/download/win下载安装包安装过程一路 Next 即可默认设置不需要改。装完同样关终端重开输入git --version看到git version 2.x.x说明成功。现在装 CLI 本身。最快的方式是一条命令python -c import urllib.request; exec(urllib.request.urlopen(https://raw.githubusercontent.com/jieshuo-ai/narrator-ai-cli/main/install.py).read())这条命令会从仓库下载安装脚本并直接执行正常情况下 1 到 3 分钟跑完看到一串 successfully installed 的提示就完成了。如果 30 秒之内屏幕没有任何反应大概率是国内访问 GitHub 受限。按 CtrlC 终止改走手动方案git clone https://ghfast.top/https://github.com/jieshuo-ai/narrator-ai-cli.git cd narrator-ai-cli pip install -e .这里用的https://ghfast.top/是 GitHub 镜像加速前缀国内访问稳定。如果它也打不开把前缀换成https://mirror.ghproxy.com/再试一次两个前缀基本覆盖所有国内网络环境。装完关终端重开输入narrator-ai-cli --version看到版本号输出就全部搞定。4.2 在 macOS 上装macOS 上 Python 有两种装法。一是从python.org下.pkg双击安装二是通过 Homebrew 执行brew install python3.10。验证用python3 --version——注意 macOS 自带的python可能指向老版本你自己装的新版要用python3调用这是 macOS 一个很容易踩的坑。Git 最省事的装法是在终端执行xcode-select --install系统会弹出一个白色对话框点「安装」等它跑完。Xcode 命令行工具大约占 17G 磁盘空间如果空间紧张可以改用brew install git只占几百兆。CLI 的一键安装命令是curl -fsSL https://raw.githubusercontent.com/jieshuo-ai/narrator-ai-cli/main/install.py | python3手动备用方案和 Windows 一样git clone加镜像前缀、cd进目录、pip3 install -e .即可。安装后验证narrator-ai-cli --version。如果终端提示command not found先执行source ~/.zshrc刷新一下 shell 环境变量再试通常就通了。五、CLI 是怎么和服务端对话的CLI 装完之后它还不知道你是谁也不知道你的账户里有多少点数可以花。你需要先拿到一把Key。拿到之后在终端输入narrator-ai-cli config set app_key 你的API_Key这条命令会把 Key 写入本地配置文件默认在用户目录下的.narrator-ai-cli隐藏目录以后 CLI 所有调用都会自动带上这个鉴权信息。验证是否成功narrator-ai-cli user balance看到账户余额返回说明链路打通。这里值得多讲一层鉴权细节。CLI 在发请求时实际上是把 Key 放在 HTTP 头的app-key字段里。你去看docs.jieshuo.cn任何一个接口页的 cURL 示例都会看到这样一段curl --location --request POST /v2/task/commentary/create_generate_writing \ --header app-key: {{app_key}} \ --header Content-Type: application/json \ --data-raw {...}CLI 把这个头的拼装、每次调用的自动注入、以及响应里通用错误码的处理都封装好了你不用每次自己写。如果你某天要绕开 CLI 直接调 API知道这个机制就行。另外开放接口还支持子 Key 体系——主账号可以创建多个子 Key、给每把子 Key 单独配置额度、查询所有子 Key 列表。这套机制是为团队协作和多项目隔离设计的比如你的 MCN 团队里三个账号运营各用一把子 Key每把单独配额度用完互不干扰主账号统一结算。这一层在你扩到多人协作的阶段会非常有用。六、本地优先架构素材处理原则这一节讲的是 AI解说大师这套开源工具链在工程设计上最有特色的一块——本地优先local-first的素材处理架构。这一节比较长也是这套工具相比一般 SaaS 视频处理产品最有差异化的地方建议你别跳。6.1 分层处理本地做什么、云端做什么在传统的 SaaS 视频处理产品里流程通常是用户从网页上传视频文件到对象存储、后端从存储读取、处理、再把成片链接返回给用户。视频文件几百 MB 到几个 GB每次跑一条都要传一次。当你通过 CLI 加 Skill 把 narrator-ai接入一个本地 Agent小龙虾 OpenClaw、WorkBuddy、Claude Code、Windsurf、Cursor 这些的时候整条处理链路的结构是反过来的素材驻留本地、只有必要的轻量载荷跟云端往返、最终成片在本地合成。这套架构的核心是按数据体量和计算特性对任务做分层。本地执行的任务包括所有跟「文件搬运」和「音视频合成」直接相关的步骤文件寻址、字幕提取通过本地 FFmpeg 工具链完成原始字幕 OCR 或 ASR、关键帧抽取、片段切分、剪辑指令执行、音轨混合、字幕压制、最终视频编码导出。这些操作不需要云端算力放在本地做最省事——CPU 4 核加 8G 内存的配置完全能胜任速度甚至比走网络传输更快。云端执行的是所有依赖大模型能力的重计算任务爆款学习模型训练、解说文案生成、多模态视频理解、TTS 语音合成、语音克隆模型训练。这些任务用自有机器跑既不经济也跑不动必须走后端 API。两层之间的数据穿越点严格控制在轻量载荷字幕文本几十 KB 的 SRT 文件、关键帧序列几 MB 的 JPEG 图像、生成好的文案几 KB 文本、生成好的配音片段几 MB MP3、以及剪辑指令的 JSON。真正的大块头——那些几百 MB 到几个 GB 的视频源文件——从头到尾待在你的本地硬盘上不上传、不拷贝、不缓存到云端。6.2 在本地 Agent 里跑一次会发生什么举个具体场景让你感觉一下。假设你在本地硬盘~/Videos/feichi.mp4放了一部要解说的电影然后在小龙虾的对话框里说帮我用爆笑喜剧的风格给 ~/Videos/feichi.mp4 做一部电影解说输出到同目录。小龙虾openclaw读到这条指令之后通过 Skill 里的编排逻辑调起 CLI。CLI 在本地做的第一件事是读取本地视频文件——注意是读取不是上传——用内置的 FFmpeg 工具链抽出原始字幕轨道如果视频自带嵌入字幕或者通过 ASR 生成一份 SRT。这份 SRT 的大小通常在 20 KB 到 100 KB 之间。接下来 CLI 把这份 SRT 文本不是视频本体通过POST /v2/task/commentary/create_popular_learning发到后端请求学习一个爆笑喜剧风格的模型。后端处理完返回一个learning_model_id。CLI 拿着这个 ID 再调POST /v2/task/commentary/create_generate_writing拿到生成好的解说文案。文案到手之后进入配音阶段。CLI 把文案通过POST /v1/task/create/text_to_speech发给后端后端返回一个 MP3 下载链接和一个对齐好的 SRT 字幕文件CLI 把它们下载到本地临时目录。MP3 通常几百 KB 到几 MB。现在本地已经攒齐了所有必要素材原始视频在本地从未动过、后端生成的解说配音、对齐好的字幕文件、以及 CLI 根据后端返回的剪辑指令算出的时间轴。这时候 CLI 调起本地 FFmpeg做最后一步合成——把原始视频的画面、解说配音、BGM 音轨、字幕层叠在一起按时间轴对齐编码输出为~/Videos/feichi_解说.mp4。从头到尾那个几 GB 的 MP4 原片只在你的本地硬盘上被读取了若干次没有任何一次上传到云端。6.3 这个架构带来的三个实际好处第一个好处是数据驻留本地的隐私保证。影视素材、尤其是未公开发布的样片或者有版权限制的原片很多创作者不愿意上传到任何第三方服务器。本地优先架构让这件事不再是担心——素材在你硬盘上待着能上传到云端的只有字幕文本和生成物。对 MCN 团队、版权方、广告主这类对素材合规特别敏感的用户来说这一点就是选型的分水岭。第二个好处是带宽友好。一部 90 分钟的 1080P 电影大约 2 到 4 GB。如果走传统 OSS 上传流程光上传就是十几分钟网络不稳还会断。在本地优先架构下全程传输的轻量载荷加起来通常不超过 20 MB网络要求极低一个 4G 信号都能稳定跑完整条流程。第三个好处是任务可中断可续。因为大文件不用反复传输一次网络抖动最多影响当次的 API 调用重试一下就过。对比起来传统上传流程里一个大文件传到 70% 失败前面的 70% 就白费了。这对要跑批量脚本的使用者来说意义很大——你完全可以把 CLI 嵌在一个 bash 脚本里让它跑一晚上早上起来看结果不用担心半夜断网前功尽弃。七、开始制作电影解说现在进入最核心的一步——跑第一条电影解说。最简路径是用「通用爆款解说电影」这套一次性调用。CLI 里大致是这样一条命令narrator-ai-cli commentary create-movie \ --movie-file ~/Videos/feichi.mp4 \ --platform tiktok \ --dubbing male \ --bgm 轻快节奏 \ --task-count 1 \ --clone-voice false \ --output ~/Videos/feichi_解说.mp4具体参数名以你本地 CLI 版本narrator-ai-cli commentary --help的输出为准CLI 在迭代中会持续扩充参数--help永远是最新可用参数的真实来源。这条命令背后对应的 HTTP 请求是POST /v1/task/create/movie_narrator。让我们逐个参数讲清楚它们真实的意义。--movie-file指向本地视频文件路径。CLI 读取这个文件做预处理不会把视频上传到任何云端存储。--platform对应请求体的target_platform字段。这个参数会显著影响文案生成的节奏与用词风格——发抖音的解说需要前三秒出钩子、语速偏快、情绪张力大发小红书的文案更倾向生活化叙事发 B 站的可以更慢、更长、更注重信息密度。后端模型会根据target_platform调整文案策略这不是噱头是实打实的参数级控制。--dubbing对应dubbing字段取值male或female切换预置配音角色的性别。配合--clone-voice对应is_clone_voice字段你可以选择是否启用已克隆的专属声音。--bgm对应bgm字段从内置 BGM 库里按名称或标签检索背景音乐。--task-count对应task_count字段一次任务批量生成几个成片稿。比如传 3后端会用同一组素材在相似范围内生成 3 个不同变体方便你在几个候选里挑一个发布。这对做 A/B 测试和账号矩阵的人来说几乎是必用参数。--output指定最终成片的本地输出路径。CLI 完成所有后端调用之后用本地 FFmpeg 把素材、配音、字幕、BGM 合成到这个路径输出。命令回车之后 CLI 会先走一步「计算点数消耗」——这是 AI解说大师点数系统的透明保障。你会在终端看到类似这样的输出预估消耗 爆款学习点数0.00 文案生成点数140.00 视频合成点数165.55 总计305.55 点 当前余额XXXX.XX 点 是否继续(y/N)这组数字不是估算是POST /v2/task/commentary/create_popular_learning接口真实返回的viral_learning_points、commentary_generation_points、video_synthesis_points、total_consume_points四个字段。你可以在任务启动之前精确知道要花多少钱。你回复 y 确认之后CLI 开始轮询GET /v2/task/commentary/query_task接口终端每隔几秒刷新一次进度。云端任务跑完后 CLI 拉回生成好的文案与配音随后在本地完成成片合成最终输出路径会直接打印出来。八、文案生成的两步法学习模型 生成解说文案上面讲的是一次性调用。如果你想更精细控制文案的风格就需要走分步接口。这部分特别值得单独讲因为它解答了一个很多读者会问的问题——为什么 narrator-ai生成的解说文案是「有风格」的而不是大模型白开水答案藏在两个接口的协作里。8.1 第一步爆款学习模型接口是POST /v2/task/commentary/create_popular_learning。CLI 先从你本地的一段参考视频里抽出字幕 SRT把这段字幕文本提交给接口让后端学习这段参考文案的句式节奏、钩子结构、情绪节拍。学完返回一个learning_model_id形如narrator-20250929163803-MSBmuw。请求体是这样的{ video_srt_path: bf30f03eee4541708a5d059b27ee932e, narrator_type: 电影, model_version: advanced }narrator_type可以取「电影」或「短剧」决定用哪个领域训练过的基模。model_version可选basic或advanced前者快、后者精。返回体里的点数拆解告诉你整条后续流程预估要花多少{ code: 10000, message: success, data: { viral_learning_points: 0.00, commentary_generation_points: 140.00, video_synthesis_points: 165.55, total_consume_points: 305.55 } }注意viral_learning_points是 0.00——学习这一步本身不消耗点数真正花钱的是后面的文案生成和视频合成。这是一个非常友好的设计相当于「试学免费」你可以先拿参考素材学一下看适不适合这个风格适合再往下跑。8.2 第二步生成解说文案接口是POST /v2/task/commentary/create_generate_writing。把刚拿到的learning_model_id作为参数连同你要解说的电影素材的字幕和关键帧信息一起传进去{ learning_model_id: narrator-20250929163803-MSBmuw, episodes_data: [ { video_oss_key: 968bb7aadb154376ae2f1be9ae9e09cf, srt_oss_key: 46555bc7b9a144f99a5fc8beb4751bde, negative_oss_key: 968bb7aadb154376ae2f1be9ae9e09cf, num: 1 } ], playlet_name: 与神同行, playlet_num: 1, target_platform: tiktok, task_count: 1, target_character_name: , story_info: }这里episodes_data数组里的video_oss_key和srt_oss_key是 CLI 本地预处理后为这次任务临时注册的索引标识CLI 自动管理你不需要自己去做文件上传或 Key 维护。有三个业务参数特别值得解释。target_character_name是第一人称视角下的主角名——如果你希望解说以电影里某个角色的口吻展开比如「我是主角约翰那天早晨……」就把主角名传进去模型会自动把解说人称调整为这个角色。story_info是剧情背景补充如果你的参考素材和待解说电影在剧情结构上有相似点但模型不太可能自己联想到可以在这里手动提示。task_count和一次性调用里一样一次生成几稿。返回体依然是标准格式带一个task_id{ code: 10000, message: success, data: { task_id: 6daeda059326491d996cac6396e8a4dc } }之后 CLI 通过GET /v2/task/commentary/query_task?task_idxxx轮询拿到生成好的文案稿你可以在这一步手动审阅、修改、甚至完全重写——这是分步调用相对一次性调用的最大优势。文案满意之后再往下调POST /v2/task/commentary/create_compose_data合成剪辑数据和POST /v2/task/commentary/create_compose_video合成最终视频每一步都是独立任务、独立任务号、独立中间产物。为什么要有学习模型这一步因为解说文案的质量七成取决于风格模板。同样的素材给它一段「银河游侠」式的爆笑配音做参考、和给它一段严肃讲解式的参考生成的文案风格会完全不同。学习模型让用户的「想要的风格」被精确量化传给后端而不是用一堆模糊的自然语言描述去猜。九、配音层TTS、语音克隆与 SSE 实时流文案拿到了下一步是配音。AI解说大师的配音能力分两条路径直接用预置配音角色做 TTS或者先把一段参考音频克隆成你专属的声音模型再用它做配音。9.1 TTS 与一个非常实用的停顿语法接口是POST /v1/task/create/text_to_speech请求体结构{ clone_model: 3, voice_id: your_voice_id, audio_text: 欢迎来到本期电影解说#0.5#今天我们要聊的是飞驰人生 }voice_id是预置角色的 ID后端维护了一份覆盖多种语言的声音库具体 ID 通过一个查询接口获取。audio_text是要合成的文本。特别注意文本里那段#0.5#语法——这是 narrator-ai TTS 独有的停顿控制语法在任何需要停顿的地方插入#x#x 是秒数支持 0.01 到 99.99 秒后端会精确插入这段停顿。这对做电影解说来说是个非常实用的细节——你可以在钩子句后面加#1.2#制造悬念在转场处加#0.3#让节奏喘口气。返回体很有意思{ code: 10000, message: success, data: { task_id: 1457, consumed_points: 7.2, audio_file: https://download.jufenqian.top/temp/tts/.../minimax_audio_91.mp3, subtitle_file: https://download.jufenqian.top/temp/tts/.../minimax_subtitle_91.srt } }它不光返回 MP3 音频链接还同时返回一个时间轴对齐的 SRT 字幕文件。这是个很体贴的设计——因为合成音频的语速、停顿、断句和原文本不是一对一的后端在合成音频的同时把每句话精确的起止时间记录下来生成 SRTCLI 把这两个文件拉到本地之后直接压进视频里不用再做一次强制对齐。9.2 语音克隆接口是POST /v1/task/create/voice_clone请求体相当简洁{ clone_model: 3, audio_file_id: 你的参考音频本地引用 }你在本地准备一段 30 秒左右的清晰参考音频最好没有背景噪声、没有 BGM、发音连贯CLI 会为这段音频生成一个临时引用标识传给接口。后端训练一个专属于这段声音的克隆模型之后你在 TTS 接口的voice_id里指定这个克隆模型的 ID合成出来的音频就是这位说话人的声音。这对做账号矩阵的创作者来说几乎是刚需——你可以用同一个人的声音驱动多个账号的差异化内容。9.3 SSE 实时状态推送TTS 和语音克隆两个接口都支持一个非常硬核的特性——SSEServer-Sent Events实时状态推送。在请求头里加上Accept: text/event-streamcurl --location --request POST /v1/task/create/voice_clone \ --header app-key: {{app_key}} \ --header Accept: text/event-stream \ --header Content-Type: application/json \ --data-raw {...}后端返回的就不是一次性 JSON而是一个事件流。五个事件类型依次推送event_start连接建立、task_start任务开始、task_process处理中会多次推送带进度信息、task_completed完成带结果数据、event_close连接关闭。对前端应用或 Agent 来说SSE 的好处是不用自己写轮询逻辑状态更新实时推过来对 CLI 来说用 SSE 可以在终端里显示一条实时进度条而不是固定间隔的轮询刷新。不加这个头就是标准 JSON 模式后端异步处理调用方需要自己轮询任务状态。两种模式并存开发者可以根据自己的应用场景选。十、把电影解说交给 AgentSkill 的加载与使用CLI 会用之后下一步是让 Agent 来替你发命令。这一步的存在意义在于——你最终要追求的不是「能用命令行做电影解说」而是「连命令行都不用打开对着 AI 说一句中文就能出片」。核心动作只有一个把narrator-ai-cli-skill仓库里的SKILL.md文件装进你的 Agenthttps://github.com/jieshuo-ai/narrator-ai-cli-skill/blob/main/SKILL.md不同 Agent 加载这份文件的方式略有差异。小龙虾 OpenClaw原生支持 Markdown Skill在终端执行mkdir -p ~/.openclaw/skills/narrator-ai-cli cp SKILL.md ~/.openclaw/skills/narrator-ai-cli/SKILL.mdWindsurf把SKILL.md放到项目的.skills/narrator-ai-cli/目录下IDE 启动时自动读取。腾讯 QClaw 和 WorkBuddy在技能管理界面直接上传SKILL.md文件即可。有道龙虾、元气 AI、Claude Code、Cursor 以及其他所有支持 Markdown Skill 格式的 Agent方式大同小异——指向SKILL.md路径Agent 就能把里面的内容作为行为指南。如果你用的 Agent 找不到明确的 Skill 上传入口某些云端对话产品就是这样有一个稳定的通用兜底方案在对话框里分两步操作。先发第一条消息让它学会使用命令行工具内容是 CLI 仓库地址再发第二条消息让它学会调用策略内容是 Skill 仓库SKILL.md地址。分两步比一次性丢两个仓库进去成功率更高因为国内 Agent 一次消化一个仓库的理解稳定性明显更好。加载完成之后你可以直接对 Agent 说这样一句话帮我把 ~/Videos/feichi.mp4 做成一部爆笑喜剧风格的电影解说输出到同目录。Agent 接到指令之后会自动做下面这些事读取本地视频文件元信息、调用 CLI 做字幕提取与关键帧抽取、查询解说风格模板筛出爆笑喜剧类并选一个已训练好的学习模型 ID、查询配音角色列表选一个符合喜剧调性的男声、查询 BGM 列表选轻快节奏的曲目、调用「计算点数消耗」接口向你确认消耗、确认后依次发起文案生成与配音合成、本地轮询云端任务状态、拉回生成物到本地临时目录、调用本地 FFmpeg 完成最终合成、把成片落到你指定的输出路径。整个过程你唯一要做的是在它问「本次消耗 X 点数是否继续」时回复一个「确认」。这就是 CLI 加 Skill 这套组合最终想带给你的体验——你从此不需要打开任何软件、不需要记任何命令参数、不需要懂 OSS Key 和 learning model id 是什么只需要在 Agent 对话框里说一句中文素材还保留在你自己的硬盘上。十一、三种使用路径的分工用 API、用 CLI、用 Skill 这三条路共享同一个后端能力但面向的使用者完全不同。这一节我整理一下我自己用下来的判断你可以根据自己的角色对照选。直接打 API适合要把电影解说能力嵌入到自己产品或服务里的开发团队。比如你在做一款 SaaS 工具、要给用户提供「上传视频自动生成解说」的功能这时你会直接用 HTTP 去打docs.jieshuo.cn上的端点自己做文件上传、学习模型管理、轮询或 SSE、错误处理、用户配额管理。这条路最灵活、也最重——你要自己写 SDK、自己管并发、自己处理异常分支。用 CLI适合命令行熟悉的个人创作者、运维背景的使用者、或者要写自动化脚本做批量生产的运营团队。你不想每次都手写 HTTP 调用CLI 把细节都封装好了一条命令完成一类任务。你也可以把 CLI 嵌进 bash 脚本里跑循环一晚上产出五十条电影解说视频素材全程在本地。用 Skill适合不想碰命令行、但已经在用 Agent 的人。Skill 不要求你记任何参数、任何 ID自然语言直接表达意图Agent 自己完成规划和执行。适合影视博主、内容策划、非技术岗的决策者快速上手尝试。这三条路径之间不是替代关系是互补。一个团队里完全可能技术合伙人用 API 做产品集成、运营同事用 CLI 跑脚本、内容团队用 Skill 驱动日常创作——三边共用同一套账号和配额互不干扰。十二、值得再花一晚上玩的几件事如果你读到这里已经把 CLI 装好、成功跑出了第一条电影解说下面几件事值得试一下。试试语音克隆加 TTS 停顿语法的组合。录一段你欣赏的博主的 30 秒清晰音频通过 CLI 的语音克隆子命令上传完成克隆。然后写一段解说文案在关键的节奏点插入#0.5#停顿用这个克隆模型做 TTS 合成。你会发现效果跟「直接让大模型念出来」完全是两个层次。试试分步接口的学习模型机制。找两段风格完全不同的爆款电影解说短视频比如一段「悬疑沉稳」、一段「爆笑吐槽」分别创建两个 learning_model然后用同一部电影分别生成两份文案对比。你会直观看到「风格模板」这个参数在后端到底做了多少事。试试 SSE 模式。如果你在做一款自己的前端或 Agent 应用在调用 TTS 或语音克隆接口时加上Accept: text/event-stream请求头感受一下实时事件流跟传统轮询的体验差异。试试批量脚本。把 CLI 嵌进一段 bash 循环让它在一台本地机器上一晚上跑完十部电影的解说第二天起来挑选发布。这正是本地优先架构最值得发挥的场景——全程不上传大文件、网络抖动不影响整体进度。最后一件事如果使用过程中遇到任何问题、或者有想要的功能还没支持去两个仓库提 Issue。这是开源项目最值得玩的部分——你今天提的问题下一个版本就可能变成我们要解决的需求。十三、小结整篇文章其实只在讲一件事——电影解说这条工序正在从图形界面时代进入命令行加 Agent 时代。narrator-ai把整套调用能力开源成 CLI 和 Skill做的不是另一个剪辑软件而是一组可以接进任何技术工作流的能力组件。本地优先架构让大文件素材不必上传、隐私和带宽双重友好分步接口让风格控制精确到学习模型粒度SSE 实时流让 Agent 体验丝滑。如果你是创作者这套工具能让你把每条片子的产出时间从一两个小时压到几分钟如果你是开发者它能让你在自己的产品里直接接入一条完整的电影解说生产流水线如果你是 MCN 团队的技术负责人它能让你为整个团队搭一套既保素材合规又能批量产出的内容工厂。完整的相关链接放在文末喜欢的话欢迎到 GitHub 给两个仓库点个 Star遇到问题也欢迎提 Issue。