一、背景：写在前面
最近半年我一直在做电影解说类的短视频内容，从最早一条片子手工剪三个小时，到中间用过几款桌面型 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 受限。按 Ctrl+C 终止，改走手动方案：
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 python@3.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_tospeech 发给后端，后端返回一个 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_id=xxx 轮询拿到生成好的文案稿，你可以在这一步手动审阅、修改、甚至完全重写——这是分步调用相对一次性调用的最大优势。文案满意之后再往下调 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 字幕文件。这是个很体贴的设计——因为合成音频的语速、停顿、断句和原文本不是一对一的，后端在合成音频的同时把每句话精确的起止时间记录下来生成 SRT，CLI 把这两个文件拉到本地，之后直接压进视频里，不用再做一次强制对齐。
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 和语音克隆两个接口都支持一个非常硬核的特性——SSE（Server-Sent Events）实时状态推送。在请求头里加上 Accept: text/event-stream：
curl --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 模式，后端异步处理，调用方需要自己轮询任务状态。两种模式并存，开发者可以根据自己的应用场景选。
十、把电影解说交给 Agent：Skill 的加载与使用
CLI 会用之后，下一步是让 Agent 来替你发命令。这一步的存在意义在于——你最终要追求的不是「能用命令行做电影解说」，而是「连命令行都不用打开，对着 AI 说一句中文就能出片」。
核心动作只有一个：把 narrator-ai-cli-skill 仓库里的 SKILL.md 文件装进你的 Agent
https://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.md
Windsurf 把 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。
