LibTV CLI：把网页视频工作流搬进命令行，1.1.1 的自动化承诺还缺复现数据
精读孙军师的 LibTV CLI 1.1.1 使用指南，拆解画布、节点、模型 schema、参考素材和下载链路，并指出版本漂移、命令可复制性与自动化稳定性仍缺实测证据。
先看结论
孙军师这篇「LibTV CLI 实战指南」把 LibTV 的产品对象从网页画布往命令行推进了一步：开发者可以用脚本创建画布、添加节点、接入参考素材、查询模型参数、触发生成，再把结果下载到本地。对 AI 视频团队来说，这比又增加一个模型入口更有用，因为它试图把脚本、分镜、图片、视频和成片交付放进一条可重复执行的生产链。
但这篇文章证明的是「命令和工作流已经被整理出来」，还没有证明「这条工作流在不同账号、不同项目和不同模型版本上足够稳定」。文章明确说明，它依据的是作者本地安装的 LibTV CLI 1.1.1 及当时的模型 schema，并提醒执行前重新查看帮助和参数。1
原文信息
- 标题：不打开网页，也能搭好 AI 视频流水线：LibTV CLI 实战指南
- 来源：微信公众号「孙军师」
- 发布时间：2026 年 7 月 22 日 16:21
- 作者：孙军师
- 文章类型：独立使用指南，覆盖安装、登录、画布、节点、模型 schema、生成和下载
- 原文立场：作者在结尾特别说明，文章不代表 LibTV 官方，命令依据 LibTV CLI 1.1.1 的本地帮助和实时模型 schema 整理。1
全文速读
文章先把 CLI 的对象拆成三层：workspace 用来归档多张画布，project 是真正承载节点和连线的画布，node 则是脚本、图片、视频、音频等生产单元。作者给出的基本链路是「创意文本 → 脚本/分镜 → 参考图 → 视频生成 → 下载成片」。
接着，文章按一次真实使用顺序往下写：先用
libtv --version 和 libtv --help 检查安装，再通过网页或手机验证码登录；创建画布后，用 project use 把当前工作目录绑定到某一张画布。绑定关系会写入 .libtv/project.json，后续命令可以省略画布参数。中段是全文的技术重点。作者建议先用
libtv model search 查看图片和视频模型，再用 libtv model <模型Key> 查询具体 schema。这里要区分两个字段：生成参数里的 model 接收模型名称，查询命令则可以使用 modelKey；比例、分辨率、时长、声音开关和参考素材数量，都应该以当时的 schema 为准。在生产流程上，文章分别演示了五件事：创建写实参考图、上传真实产品图、用图生视频、用文本直接生成视频，以及把长视频拆成脚本、分镜和多个镜头节点。之后再用
--set 修改生成器参数，用 --update 修改节点自身的数据，通过 --left 连接上游素材，最后用 --run 等待任务完成，并用 libtv download 下载结果。结尾把 CLI 的适用规模收窄到一个很具体的建议：先做一个 15 至 30 秒的小项目，包含 3 个镜头、1 组统一参考图和 1 个视频模型，跑通后再扩展到分组批量生成、模型对比和自动下载。这个收束比「一条命令做完整电影」更可信，因为它承认了视频生产仍需要拆镜头、保资产和逐段复核。1
这张图能说明这篇指南的核心对象是「项目工作流」，但不能证明图中界面就是 CLI 直接生成的结果；图片与命令证据仍要分开看。
功能细节拆解
1. CLI 管的是画布结构，不只是生成按钮
这篇文章最有产品含义的地方，是把 CLI 的基本单位定成了 project 和 node，而不是一次生成任务。开发者可以在一张画布里保存脚本、分镜、参考图和多个视频镜头，再通过节点关系追踪素材从哪里来、被谁使用、下一步要送往哪里。
这让 LibTV 的工作流更接近一个可编辑项目文件。一个镜头失败时，理论上可以只重跑对应节点；一个角色或产品需要更新时，也可以替换参考素材，而不是把整段提示词和前置工作重新做一遍。这里的「理论上」不能省掉，因为原文没有提供失败重跑日志、节点复用记录或局部修改后的成片对比。
2. schema 查询是开发者入口，也是版本风险
普通网页工具会把比例、时长和模型选项放在下拉菜单里，CLI 则需要调用者自己处理这些字段。孙军师把
modelName 与 modelKey 的区别单独拎出来，说明 CLI 并非只把网页按钮换成了文字命令，它要求用户理解模型标识、模式和参数校验。这套设计有一个优点：模型更新后，调用者可以先查询当前 schema，再决定命令怎么写。缺点也很明显，旧脚本可能因为模型名称、模式字段或输入素材数量变化而失效。文章提到的
star-video2-mini 参数，只能当作 1.1.1 版本下的示例，不能当成永久接口。LibTV 官方 CLI 页面目前使用的是
latest 安装脚本，并推荐通过 libtv login web 完成登录，还把 CLI 放在 Kimi Code/Claw、MiniMax Agent、Trae 等 Agent 工具的连接入口里。官方页面的「latest」与原文固定的 1.1.1，已经提示出版本管理会成为实际使用中的第一道门槛。23. 参考图把工作流和资产管理接在了一起
文章没有把图生视频写成一句提示词的魔法，而是建议先上传产品图、人物图或场景图，再把它们作为视频节点的输入。对于产品广告，这个顺序很关键：用户需要保住包装、标签、颜色和比例，参考图比重新描述一遍产品更接近可检查的资产锚点。
这也是 CLI 与纯文本调用的差别之一。命令行可以把参考素材路径、节点名称、生成参数和输出目录写进脚本，但它并不能替用户判断产品外观是否真的保持一致。原文给出了「产品参考图 → 视频节点 → 下载」的操作链，却没有跨多次生成记录一致性成功率，也没有统计参考素材失效时的重试成本。1
4. --set 与 --update 体现了节点数据模型
这是文章里最值得开发者注意的一组区分：
--set 改的是生成器如何工作，写入 data.params；--update 改的是节点自身承载的数据，例如分镜行、标题和海报。前者面向模型参数，后者面向项目内容。如果这个边界在实际 CLI 中保持稳定，团队就能把「生产逻辑」与「项目数据」分开维护：模型换了，参数脚本改；分镜内容换了，节点数据改。对版本控制和批量任务来说，这比把所有内容塞进一段不可拆分的提示词更容易审查。
5. 官方公开的 Agent Skill 是另一条接口证据
LibTV 的公开
libtv-skills 仓库把能力描述为一组面向 AI Agent 的技能包，通过 OpenAPI 提供生图、生视频、会话创建、进度查询、文件上传和结果下载。它证明 LibTV 在命令行之外，也在建设面向 Agent 的程序化调用路径。3但这不能直接替代 CLI 的验证。仓库 README 展示的是会话式 API 和 Python 脚本，孙军师文章展示的是本地
libtv 命令对画布和节点的操作。两者都属于「程序化接入」，对象、鉴权和错误处理是否完全一致，需要看各自的版本文档和实际调用结果。目标用户场景
适合把视频生产做成脚本的开发者
如果用户需要反复创建同类型项目，或者想让 Agent 自动新建画布、上传素材、生成镜头并下载结果，CLI 比手动点击更容易接入现有脚本和任务调度。尤其是产品广告、批量短视频和多版本素材生产，项目结构比单条成片更值得保存。
适合需要保留人工审核的团队
原文的节点设计没有消灭人工判断，反而把人工审核点暴露出来：脚本要不要改，分镜是否合理，参考图是否锁住主体，生成结果是否值得进入下一节点，都可以在节点之间停下来检查。它适合「机器执行重复步骤，人负责做取舍」的团队，不适合期待全程无人值守的用户。
不太适合只想快速试一个镜头的人
安装、登录、绑定画布、查 schema、处理模型参数，对只想生成一段 5 秒视频的用户来说都增加了负担。官方 CLI 页面也把它放在 Agent 工具连接和本地开发场景中，而不是把它描述成比网页更简单的入口。2
竞品坐标
这篇文章没有做横向模型 benchmark，它真正把 LibTV 放到了三种产品形态之间：
| 产品形态 | 用户得到的东西 | 主要优势 | 需要付出的代价 |
|---|---|---|---|
| LibTV 网页画布 | 可视化的项目、节点和素材关系 | 上手时能直接看见全流程，适合人工调整 | 批量执行和外部自动化需要额外操作 |
| LibTV CLI / Agent 接入 | 可脚本化的画布、节点和生成任务 | 能接进开发环境、任务调度和批量流程 | 要处理版本、schema、鉴权和错误恢复 |
| 纯模型 API 或 SDK | 直接调用某个模型的生成能力 | 接口边界通常更集中，便于针对单项能力开发 | 还要自己补项目管理、素材组织、分镜和交付环节 |
| 一键式视频工具 | 低配置的单次生成体验 | 适合快速试错和轻量创作 | 工作流、资产复用和批量控制未必是核心能力 |
这不是功能排名。对个人创作者，网页入口可能更省心；对开发者和团队，CLI 的价值在于把一个项目变成可保存、可复用、可接管的对象。LibTV 是否能因此减少返工，要看同一项目里局部重跑、素材复用和失败恢复的真实记录。
行业影响
LibTV CLI 让「Agent-first 视频平台」这句话多了一个更具体的落点：Agent 不只是通过对话框发一条生成指令，也可以操作项目、组织节点、查询模型参数和拿回文件。这样一来，平台竞争的单位会从单个模型效果扩展到工作流是否能被外部系统接管。
这对 LibTV 的好处是，模型接入、Skill、画布和命令行可以互相导流。用户先在网页里搭好项目，再用 CLI 批量运行；开发者先在 Agent 里调用能力，再回到画布检查结果。公开 Skill 仓库已经展示了会话、进度、上传和下载等接口，说明这种程序化使用并非只停留在宣传口径。3
风险也同样清楚。上游模型、平台权限和计费规则一旦变化，CLI 脚本就可能失效；如果平台没有清楚记录版本、失败原因、积分消耗和重试结果，自动化只会把人工点击变成更难排查的黑箱。原文提醒用户实时查询 schema，这个提醒既是开发建议，也是产品接口尚未完全稳定的侧面证据。
待验证点
- 1.1.1 与 latest 的关系：原文以本地 CLI 1.1.1 为基础，官方页面则提供 latest 安装脚本。两者的命令、模型字段和兼容范围是否一致，需要用版本号、更新日志和实际
--help输出对照。12 - 命令示例能否直接复制：原文部分代码在网页抓取后出现连续排版，例如
libtv project libtv node list这一段需要按上下文拆成独立命令，再以当前 CLI 帮助核对，不能把排版结果当成可执行脚本。 - 模型参数是否真能被 schema 驱动：需要记录同一模型在不同时间返回的 modelKey、modelName、modeType、分辨率、时长和参考素材限制，观察旧脚本失效的频率。
- 局部重跑有没有实际收益：只重跑一个视频节点时，是否会重新扣除前置节点成本，是否会牵连下游节点，失败结果能否被保留，文章没有给出运行记录。
--run的终态处理：文章说--run会等待任务进入终态，但没有展示超时、取消、失败、重试和网络中断后的行为。自动化生产最怕的不是一次失败，而是失败后无法判断该不该继续。- 成本和稳定性：文章没有给出单个 15 至 30 秒项目的积分、等待时间、成功率和人工复核分钟数。没有这些数据，CLI 只能被确认「能操作」，还不能被确认「更省钱」或「更高效」。
- CLI 与公开 Skill 的边界：
libtv-skillsREADME 展示了 API 会话和文件操作，CLI 指南展示了画布和节点命令。两套接口的鉴权、项目绑定、限流和错误码是否共享，需要官方文档进一步说明。3 - 真正的团队复用：下一次实测应固定一个项目模板，连续替换 3 组脚本和参考素材，记录首稿通过率、重试次数、下载结果、人工修改时间和最终可交付片段数量。只有这样，才能判断节点工作流是可复用资产，还是一套需要经常人工救火的命令集合。
原文关键句
这句话把文章的可信边界说得很清楚：它是一份可供上手的版本化指南，不是一份永久有效的接口规范。
「LibTV CLI 的价值不是把网页按钮换成命令，而是把 AI 视频生产变成一套可以检查、复用和自动化的节点流程。」1
这句话是全文最值得检验的产品判断。要验证它，下一步不是再看一遍命令清单，而是拿同一套角色、场景和脚本重复跑几轮，测出它到底替用户省下了多少重复劳动。
「建议从一个 15 至 30 秒的小项目开始：3 个镜头、1 组统一参考图、1 个视频模型。」1
这是目前比「全自动批量出片」更适合复测的最小实验单元。它足够小，能观察节点和参数；也足够完整，能把参考图、视频生成和下载串起来。
官方 CLI 入口：LibTV CLI；公开 Agent 技能仓库：libtv-labs/libtv-skills。
References
- 1不打开网页，也能搭好 AI 视频流水线：LibTV CLI 实战指南
mp.weixin.qq.com
- 2LibTV CLI 官方页面
liblib.tv
- 3libtv-labs/libtv-skills
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.