capcut-cli：Agent 直接写你的剪映草稿库，交出的是一份还能继续改的工程 (2026)

capcut-cli 是一个独立、非官方的命令行工具，MIT 许可，作者是 Rene Zander，2026 年 4 月 13 日建仓。1 2 它做的事一句话能说完：直接读你本机那份剪映 / CapCut 的草稿，按命令改完再原子写回去，你在剪映里打开就能接着剪。3 到 2026 年 9 月 24 日，仓库有 709 star、76 fork、267 次提交、3 个未关闭的 issue；1 npm 上的包最新是 0.25.0（2026 年 9 月 18 日），从最早一版到现在共 41 个版本，过去一周被下载 2,493 次，过去一个月 11,259 次。4

它跟前面九期讲过的东西最大的区别在交付物上：它不给你一条 mp4，它给你一份工程。README 里那两句写得很直白——「JSON in, JSON out」：不起 MCP 服务、不开 HTTP 端口、不上传任何工程文件（唯一的例外是后面会讲的那组实验性只读 Wasm 工具）；跑完之后，「在剪映或剪映国际版里打开它，检查、调整、导出」，发布那一下仍然由人按。3

capcut-cli 仓库首页 — 仓库首页（2026-09-24 采集）：About 栏写的是「Independent, unofficial CLI to edit CapCut and JianYing (剪映) projects」，右栏标着 MIT license 与 Fork 76、Star 709；文件列表里能看到 `skills/capcut-edit`、`.claude-plugin`、`wasm/capcut-core`、`python` 几个目录，顶部那行提交是「README.zh-CN: add the commercial work section (#127)」，显示 267 Commits、20 Branches、38 Tags。1

它在链条上站在哪一层

前面九期各自换掉链条上的一环：kinocut 把 FFmpeg 包成有类型的工具，5 FableCut 把整条时间线写成一份自己的 JSON，6 OpenStoryline 是一条自带 Agent 的成片产线，7 video-use 是装进编码 Agent 的剪辑技能包，8 上一期的 Comfy MCP 管的是素材从哪来，9 再上一期的 Nomi 是一台本机工作台。10

这一期落在另一层。前面那些方案里，画面要么由它们自己渲染（kinocut 走 FFmpeg、Nomi 导出 MP4），要么由它们自己的编辑器承接（FableCut 的浏览器时间线）。capcut-cli 既不渲染也不提供编辑器，它做的是把剪辑意图写成剪映 / CapCut 认得的工程文件：视频分段、多轨、变速、音量、字幕、转场、关键帧，落进应用自己的那套 JSON 结构里，然后交回应用去打开、播放、导出。3 用配置里那三个层级来说，它不在渲染底座，也不在编排层，它站在「剪辑工程的描述语言」这一层——这一层交付的不是画面，是一份别人（或你自己）还能继续动刀的工程。

同一层上已经有好几种形态，选哪一个开始取决于你手上是什么：

pyJianYingDraft 是这一层里体量最大的一个：Python 库，Apache-2.0，4,421 star、670 fork，2024 年 7 月 17 日建仓，最后一次提交是 2026 年 7 月 8 日，最新一版 0.3.0 也在同一天发布，仓库里挂着 50 个未关闭的 issue。11 它是一套库，不是一个给 Agent 用的入口——仓库里至今还有人开着「增加 MCP 功能」的请求。
capcut-mate 把它做成了服务端：FastAPI 起一个 REST 接口（默认 30000 端口）管理草稿、加素材、云渲染，还配了一个扣子插件，1,855 star、Apache-2.0，2025 年 8 月 31 日建仓，最后一次推送 2026 年 9 月 21 日，9 个未关闭的 issue。12 它要你把服务跑起来、把工作流接进扣子或 n8n。
jianying-headless 走的是最窄的一条路：只面向 macOS 26 以上、只适配剪映 11.5.0（兼容 11.4.2），靠本机已装的剪映引擎导出，仓库自述是「私有源码预览」，许可也没有被 GitHub 认成某个标准许可。它 2026 年 9 月 15 日才建仓，2,479 star。13
cutcli 是闭源的那一种：一个单文件 CLI 负责生成剪映 / CapCut 草稿，另外提供云端渲染；公开的只有它的 cookbook 仓库（MIT，197 star）和文档站。14

比这几条更靠下游的一类项目也在用它：OpenChatCut 把 Agent 改过的时间线、素材、音频和字幕导出成真的剪映 / CapCut 草稿，用的就是 capcut-cli。15

capcut-cli 相对同层这几个的差别也是三件事：它是 CLI（任何能跑 shell 的 Agent 都能驱动，不需要起服务端），JSON in／JSON out（每一步的输入输出都是可检查的结构），以及零依赖（只用 Node 内建模块，不装原生包、不需要编译）。3

它在这一层怎么做事

一个剪映 / CapCut 工程在本机就是一组 JSON 文件。capcut-cli 会去认这些候选：draft_content.json、draft_info.json、draft_meta_info.json、template-2.tmp；时间线可能就在根上，也可能包在一层浅的对象或字符串信封里。CapCut 8.7 及以后，可读的 template-2.tmp / draft_meta_info.json 优先，更早的版本则仍然优先 content/info 那一对；一次原子保存会把所有可读的时间线目标一起同步。16

写的时候有两层保护。落盘走同目录临时文件加 fsync 再 rename；提交之前，如果目标在加载之后被别的程序改过，它拒绝写；检测到剪映 / CapCut 桌面端在运行时，它也会保护托管的草稿路径，--force-write 是显式覆盖而不是默认的补救手段。16 写之前还有一道版本闸门：剪映的有效版本 ≥ 6.0 直接拒绝，CapCut 超出已知范围（大于 9.x）拒绝，顶层 schema 整数大于 360000 也拒绝，其余情况警告后照写。16

用法有四种，从最省事到最克制：

CLI——npm install -g capcut-cli 之后就是 capcut <命令> <工程>；不想装就 npx capcut-cli。3
库——把它当 TypeScript 模块用，loadDraft / lintDraft / saveDraft 三个入口，零依赖。3
队列——capcut serve 从 stdin 读 JSONL 任务，一条一条跑，是给 n8n、Make、扣子这类编排器准备的入口。3
只读的 Wasm 组件（实验性）——wasm/capcut-core 把 inspect、diff、lint-portable 三个 JSON-in/JSON-out 函数编成一个 WebAssembly Component，没有文件系统、网络、环境变量、时钟、随机、stdio 或进程导入，通过 Wassette 走 MCP；它的定位是「让 AI 看，不让它碰」。3 17

给 Agent 的装法有两条现成的：npx skills add renezander030/capcut-cli 会把 capcut-edit 这个技能装进 Claude Code、Codex、Cursor、OpenCode 以及 skills 安装器支持的其他客户端；18 Claude Code 还可以当插件装（/plugin marketplace add renezander030/capcut-cli 之后 /plugin install capcut-cli@capcut-cli）。技能里写的是每条命令、草稿库在 macOS 与 Windows 上的位置、以及「先查看再动手」的习惯（先 inspect，别把整份草稿倒出来），触发词中英文都认——剪映、字幕、草稿。3 19

命令面按用途分组，直接照搬仓库里的分法：查看有 info、tracks、materials、version、lint；往下钻有 segments、texts、segment、material；创建有 init、quickstart、compile（从一份 JSON 规格搭草稿）；预览有 render；添加有 add-video、add-audio、add-text；编辑有 trim、speed、volume、转场、蒙版、文字与图片动画、缓动曲线；模板有套用与提取、make-preset；字幕有 caption、import-srt、export-srt、translate；效果有 sfx、chroma、matting；长转短有 cut、detect-scenes、detect-silence、detect-retakes；自动化有 serve、migrate、doctor、sync-timelines。3 20

docs/version-support.md 的版本支持矩阵 — 版本支持矩阵（2026-09-24 采集）：文档开头先定义了五档证据——fixture-tested、synthetic-tested、reported、expected-compatible、known-broken，然后逐行给出每个 CapCut 版本处在哪一档。表里只有 6.2.8 是 fixture-tested，6.5–8.0 写着「expected-compatible / unverified」，7.9 与 8.9 那一行是「reported / one field measured」，8.4.0 那行记着「root → nested on first open」。16

你要给什么，它交回什么

它要的东西不多，但有几样是硬条件：

Node ≥ 18，只用内建模块，不装原生包；3
一份本机剪映 / CapCut 草稿库，以及一个它认识的版本（这就是下一节「会卡住的地方」的主要来源）；16
可选的四样，缺了只是少几条命令：Whisper 给 caption 用，FFmpeg 给 render 用，ffprobe 给自动读媒体元数据用，ANTHROPIC_API_KEY 给 translate 用。3

Python 用户不用绕到 Node 里：仓库里有一个薄客户端，pip install capcut，纯 Python、无依赖、Python ≥ 3.9，2026 年 9 月 19 日随那一轮改动发出去，PyPI 上现在是 0.1.0。21 22 它本身不实现任何剪辑，只是按参数去调同一个二进制，把返回的 JSON 交回给你。

它交回这几样：一份还带着可编辑轨道的真工程（视频与字幕都在各自的轨道上，不是压平的成片）；一份 JSON 读数（info、tracks、segments、materials 都可以只读）；一张低分辨率的 ffmpeg 代理片，用来快速看时间线对不对；lint / diagnose / version 的报告；以及一个用 export-srt 或 translate 换出来的字幕文件。3 20 成片和发布都不在它这里。

最短的上手路径与花费

四条命令能走到第一份能打开的草稿：

npm install -g capcut-cli（或者任何一条命令前面加 npx capcut-cli，不装也能跑）。3
capcut doctor——它会告诉你本机草稿库在哪、里面每份工程是可读的、缺标记的、加密的还是读不出来的。这条命令在 2026 年 9 月 19 日那一轮改动中加上了 --drafts <dir>，让你在没有装应用的机器和 CI 里也能跑。23
capcut quickstart my-first --video clip.mp4 --srt captions.srt——它建一份新草稿，把视频和字幕放上轨道。3
打开剪映 / CapCut，那份草稿已经在列表里；回头用 capcut info ./my-first/ -H 把结构读回来。3

如果你只是想让编码 Agent 会用它，路径更短：npx skills add renezander030/capcut-cli，然后问它「把这条素材剪成 9:16 的字幕短片」这一类的需求。3

验收信号项目自己给了几个：capcut doctor 通过；capcut info 读得回你刚写的东西；capcut lint 不报警；capcut version <project> 报出 schema 标记；capcut diagnose <project> -H 报出它选了哪个文件当权威、时间线有没有分叉。16

这一层的花费是零：不要账号、不要 API key、不要额度，跑在你自己的机器和磁盘上。要花钱的部分——whisper 的算力、translate 的 token、以及你可能想给的赞助——都在下一节里说。

会卡住的地方

剪映 6.0 及以后的草稿是加密的，它只检测不解密

症状：命令读你已有的工程时报加密或读不出来，想让它改一份旧工程改不动。 触发条件：你的草稿是剪映 6.0 及以后由应用自己写的——draft_content.json 不再是明文 JSON，而是 AES 加密的二进制负载。现状：项目把这个决定单写成了一份文档，标题就是「decided — detect, do not decrypt」。三条理由写在里面：发布一个专门拆厂商加密的例程属于另一类风险（社区已知的算法是逆向来的，没有许可）；密钥与算法在剪映的点版本之间移动过（文档引了 pyJianYingDraft 的 #142/#169/#174 三条）；以及一个会随剪映更新静默失效的解密器，比一句诚实的「不做」更糟。24 对应到代码里就是上面那道写前闸门：剪映有效版本 ≥ 6.0 的改动请求被拒绝。16 你能怎么办：文档按优先级给了三条替代路——把剪映钉在 5.9.x 并阻止自动升级（最后一条被广泛使用的明文线，矩阵里标的是 community-reported 的 expected-compatible）；改用国际版 CapCut，它不加密；已经是加密草稿就交给社区工具（文档点了 pyJianYingDraft 与 duoec/duo-video，并明说它们在这个工具之外）。16 24

剪映 6.0+ 草稿加密的决策文档 — 决策文档（2026-09-24 采集）：标题「Decision: JianYing 6.0+ draft encryption」，状态一行写着「decided — detect, do not decrypt (revisit gated, see below)」。下面「What encryption does and does not block」一节记的是 2026 年 9 月的证据：加密挡的是读应用写的草稿，不挡写一份新草稿——剪映 11.4（macOS）上写明文的 `draft_info.json` 会被应用打开、就地升级成加密格式并补齐 `Timelines/`。24

草稿库里全是加密工程时，新草稿没有可播种的模板

症状：init、quickstart、compile 看起来成功了，stderr 上却多一条 WARNING，JSON 里 template.store 说没有可读的工程可以拿来当模板。 触发条件：你的草稿库是剪映 6.0+ 的——应用写进去的每一份都是加密的，工具没法从里面挑一份当底。现状：v0.24.0 起，这三条命令会报告草稿库里有多少工程是可读的、缺标记的、加密的、读不出来的，并在「一份都播不了种」时明说；lint 对这类草稿报 template-unverified-store，意思是这份草稿没被那个版本的任何真工程验证过。23 你能怎么办：把它当成「能生成、但没有被你这个应用版本验证过」的草稿，生成后先打开看一眼再批量跑。

内置模板造的草稿会被现代版本拒开

症状：草稿生成了，剪映 / CapCut 打开时报「来自非常规路径，暂时不支持」，有的版本还会把它列在 00:00。 触发条件：用仓库内置那个盖着 CapCut 6.5.0 的模板造草稿（v0.23 之前这是默认行为）。现状：这是仓库最老的一条线索。#67 记的是内置模板盖着版本 7 且 new_version 为空，8.5.0 拒开；#111 是真机验证——内置模板造出的草稿（连 quickstart 在内）被真实的 8.7.0 Windows 拒开，register --materials、relink、sync-timelines 都没用，因为原因是模板里的旧标记，不是路径；换用从已安装应用里捕获的模板之后，同一条流水线在 9.3.0 上跑通了「打开、编辑、保存、关闭、重开」的往返。16 25 26 你能怎么办：v0.23 起默认改成「从草稿库里最新的应用自产工程播种」，已经造好的草稿用 migrate --from-store 重新盖章。16 但如果你库里的工程全是加密的（上一条），播种会退回内置模板，也就是退回这个问题。

写成功，应用开出来还是旧的

症状：命令返回成功，根文件里也确实改了，剪映打开看到的还是旧内容。 触发条件：你的 CapCut 把活动工程放在 Timelines/<main_timeline_id>/draft_info.json 下（7.x 就是这样），或者 8.7 及以后改以 template-2.tmp / draft_meta_info.json 为准。现状：#50 把这条写得很细（2026-08-01 开单，仍是 open）：7.7 的真实工程里，根目录那份 draft_info.json 只是派生镜像，应用下次打开会用它自己的嵌套时间线重新生成，把写入覆盖掉；复现步骤是改一条已知 id 的文本片段，然后依次看到「CLI 返回成功」「根文件里是新文本」「Timelines/<active-id>/draft_info.json 里还是旧的」「打开显示旧字幕」「应用重写根镜像」。8.7+ 的清单优先级来自 #35。27 28 你能怎么办：动手前后各跑一次 capcut diagnose <project> -H，它报出权威文件的选择与时间线分叉；已经分叉的用 sync-timelines --apply 修；写的时候别开着编辑器（工具会保护托管路径，--force-write 才绕得过）。16

issue #50 页面 — 这条问题单（2026-09-24 采集）：标题「CapCut 7.x edits are discarded when the active draft lives under Timelines/」，状态 Open，开单者是 jaecho1001，日期 Aug 1；右侧 Development 一栏挂着修它的分支。正文把复现写成四步，最后一步是「CapCut rewrites the root mirror, removing the CLI edit」。27

版本适配是一张分档表，只有一档被自动化测试压过

症状：README 上说支持，你的版本打开就是不对。 触发条件：把「支持 CapCut / 剪映」读成「你手上那个版本一定行」。现状：矩阵把证据分成五档，每行都标出处。CapCut 一侧：6.2.8 是 fixture-tested，有提交进仓库的测试夹具、跑全套命令；6.5–8.0 是 expected-compatible 且备注写着「没有提交过应用生成的真实夹具」；7.9 / 8.9 只测过一个字段——在一台机器上扫了 38 份应用自产草稿，定下 materials.texts[].content 的 range 存的是 UTF-16 code unit 而不是字节，这个结论修掉了 0.19.1 里的一个真实写入 bug，但文档自己说明这只是「一个字段的测量，不是一轮套件」；8.4.0 记的是「首次打开后从根转成嵌套」；8.7 Windows 是「适配器已发，从草稿库播种」；9.2.8-beta4 是「嵌套文档才是权威」；9.3.0 用捕获来的模板跑通一次真机往返。16 29 剪映一侧只有三行：5.9.x 是 community-reported 的 expected-compatible，6.0+ 是 known-broken（加密），11.4.0 是「明文草稿能被打开、生成不受阻」。16 你能怎么办：把这张表当口径而不是承诺——先 capcut version <project> 看 schema 标记、capcut doctor 看草稿库，再决定要不要往生产工程上写。列表里另有一条 #52（open，2026-08-02）在问 6.2.8 的安装包，报的正是 6.3.0 与 9.1.0 打开自己草稿时报「来自非常规路径」。30

0.17.2 及以前的旧版本有两条安全记录

症状：你照着文档跑 capcut fixture，「脱敏」包里还带着稳定的设备标识。 触发条件：装的是旧版本。现状：#59（2026-08-08 开、2026-08-09 关）写得很具体：脱敏清单只有路径与邮箱形状的五项，而 CapCut 在每份时间线文件里都存着 device_id、mac_address、hard_disk_id，它们原样留在包里，SANITIZE_REPORT.json 还把原始绝对路径写了回去——作者当时的原话是「任何照着文档做的人都会在以为自己已经脱敏的情况下把设备标识发到公开 issue 里」。31 README 顶部那条 IMPORTANT 另外写着：0.17.0 及以前的版本里有本地命令 / 过滤注入路径与不安全的临时文件、凭据输出行为，分别修在 0.17.1 与 0.18.0。3 你能怎么办：直接用 0.25.0 或更新；要拿 fixture 包去提版本兼容的 issue，用 0.18.0 之后生成的包——#44 里也重申了这一点。32

蒙版几何还不能上关键帧

症状：想让蒙版跟着画面里的人或产品走，写不出来。 触发条件：把「有关键帧」理解成「什么都能做关键帧」。现状：#44（open，2026-07-03 开）把边界写清楚了：mask 只写静态的蒙版几何，keyframe 目前只动片段的位移、缩放、旋转、透明度和音量，蒙版自身的位置、宽高、旋转、羽化都还不在可关键帧的属性里；接受标准里还写着，插值曲线要以「剪映实际渲染出来的结果」为准，而不只是自己的写入器能往返。32 你能怎么办：静态蒙版、色度抠图、智能抠像这些今天就能用；要动画蒙版，要么等这一条落地，要么把这一笔留给人在应用里补。

它不做最终渲染

症状：以为让它跑完就能拿到成片。 触发条件：把 render 当成导出。现状：README 把这件事写得很明白：render 是低分辨率的 ffmpeg 代理片，不是剪映的最终渲染；成片要在剪映或剪映国际版里打开、调整、导出，「the publish click stays human」。3 你能怎么办：把这条链路定位成「前面全自动、最后一公里交给人」；要无人值守成片，就得换到渲染底座那一层去（kinocut 把 FFmpeg 包起来、HyperFrames 是浏览器里的渲染底座，都是前几期写过的那一类）。5 33

许可与真实成本

许可这一层最干净：MIT，版权署名是 Rene Zander，README 里那句原话是「capcut-cli is MIT and free forever」。2 3

钱的部分有三笔，分成三节写在 README 里，别把它们混起来：

赞助是自愿的，分三档：$5/月给资助者专属的发版说明并在 BACKERS.md 里留名；$25/月进 capcut-cli-pro 私有仓库，拿到高级模板与字幕样式包、完整的 Claude 短视频管线、可直接跑的 compile 规格与提前构建，外加优先分诊；$100/月是给最多 5 人的团队版，含一份书面的商用确认、README 上的 logo 与优先排期。作者给的用途说明是「资助换来更快的发版与对新版剪映 / CapCut 的当周支持」——它是资助，不是许可的替代品。3 34
商业集成另算：把 capcut-cli 嵌进你的产品、或要它做它今天不做的事，作者接少量这类活。3
本机侧才是日常开销：Node ≥ 18 很轻；caption 走 Whisper、render 走 FFmpeg、translate 走你的 ANTHROPIC_API_KEY，这三样各按自己的许可与计费，跟这个项目无关。3

还有一笔关于谁在维护的账。267 次提交里 244 次来自作者本人，dependabot 10 次，其余九个账号合计 13 次；仓库有 20 个分支、38 个 tag、0 个待合的 PR，以及 3 个未关闭的 issue。1 发版节奏很密：v0.25.0 发于 2026 年 9 月 18 日，同一天还发了 v0.24.0，往前每周一版；主分支最后一次推送是 2026 年 9 月 23 日。1 35

releases 列表页 — 发版列表（2026-09-24 采集）：最上面是标着 Latest 的 v0.25.0，说明文字写的是「caption follows the transcript's script」——Whisper 给中日文切出来的词本身就是单字或短 token，拉丁默认的「四词一屏、空格连接」把中文切成了带空格的碎片，这一版改成按字符连写并按字符数断行（中文 16 字、日文 13 字）。左侧列表连着 v0.24.0、v0.23.0……可以看出发版密度。35

最后一个常被忽略的口径：项目自己在 README 里声明与字节跳动无关，剪映 / CapCut 是字节跳动的商标，这里只是用它来说明互操作性。3

和之前几期放在一起看

方案	你给它什么	它给你什么	它在这一层	许可与公开体量
本期：capcut-cli	Node ≥ 18 和一份本机草稿库	一份还能在剪映里改的工程、JSON 读数、代理片	剪辑工程的读写层，不起服务	MIT，709 star1
pyJianYingDraft	一个 Python 环境	用代码拼出来的剪映草稿	同一层的库版本	Apache-2.0，4,421 star11
capcut-mate	一台常驻的机器、接进扣子或 n8n	REST 接口管草稿、云渲染	同一层的服务端版本	Apache-2.0，1,855 star12
jianying-headless	macOS 26+ 与剪映 11.5.0	本机剪映引擎导出的 MP4	同一层，只走 macOS 那条窄路	许可未被 GitHub 识别，2,479 star13
FableCut	一个浏览器	一条 JSON 时间线和 MCP / REST 入口	自带编辑器的浏览器端	MIT，690 star6
kinocut	FFmpeg 和 Python 环境	196 个 MCP 工具与一张渲染回执	FFmpeg 的执行与验证层	Apache-2.0，166 star5
FireRed-OpenStoryline	一份 config.toml 和几个模型 key	18 个工具节点串起的成片产线	自带 Agent 的成片流水线	Apache-2.0，3,434 star7
video-use	一堆原始素材和转写额度	读着词级转写稿剪出的 final.mp4	装进编码 Agent 的剪辑技能包	MIT，26,475 star8
Nomi	一台机器和外部模型来源	一份本地工程：画布、分镜、时间线、MP4	本机工作台，自带编辑器	AGPL-3.0，522 star10
Comfy MCP	一个 Comfy 账号，或一台跑着 ComfyUI 的机器	Agent 自己建图、跑渲染、批量出素材	生成引擎的 Agent 接口	AGPL-3.0-or-later 或商用许可，233 star9
HyperFrames	HTML 和组件代码	浏览器里的渲染底座	渲染底座	Apache-2.0，52,664 star33
hypit	一份需求描述	一条从脚本到成片的流程	编排层	自订许可，15,389 star36

表里每个数字都是 2026-09-24 当天重新取过的值。

今天该不该动手

今天就动手：你在用编码 Agent 做中文短视频的批量或半自动生产，出口本来就是剪映 / CapCut，缺的正好是「让 Agent 直接写工程」这一段。装完到打开第一份草稿是四条命令，不用注册、不用给账号、不用 API key，许可也干净。批量改字幕、批量长转短的活同样成立——caption、import-srt、export-srt、translate、cut、detect-silence 这些命令就是为这类活准备的。3

先收藏：你库里已有的草稿都是剪映 6.0 及以后写的，而你想改的正是那些旧工程——加密这道门今天只检测不解密。24 你要的是无人值守的成片也一样，最后一公里仍然在应用里，成片和发布都得人按。3 你的目标应用版本落在「只被报告过」和「预期兼容」那两档时也先别急，先拿一份测试草稿把「生成 → 打开 → 保存 → 重开」跑通再谈接进流程。16

跳过：你机器上不打算装剪映 / CapCut——这一层所有方案的出口都是那个应用；11 13 你要的是自己控制渲染底座、或者要把成片直接发出去——那是前几期里另外两层的事。5 33

不管走哪条，第一天就做一件事：拿你自己草稿库里一份真的工程当试验品，不要拿模板造的草稿试。这一层的坑几乎全在「你机器上那份文件到底是不是应用认的那一份」上。

References

1
renezander030/capcut-cli
github.com
2
LICENSE · capcut-cli
github.com
3
capcut-cli README
github.com
4
capcut-cli - npm
npmjs.com
5
KyaniteLabs/kinocut
github.com
6
ronak-create/FableCut
github.com
7
FireRedTeam/FireRed-OpenStoryline
github.com
8
browser-use/video-use
github.com
9
Comfy-Org/comfy-mcp
github.com
10
aqm857886159/Nomi
github.com
11
GuanYixuan/pyJianYingDraft
github.com
12
Hommy-master/capcut-mate
github.com
13
mcncarl/jianying-headless
github.com
14
xuliang2024/cutcli-cookbook
github.com
15
0xsline/OpenChatCut
github.com
16
docs/version-support.md · capcut-cli
github.com
17
wasm/capcut-core · capcut-cli
github.com
18
skills.sh
skills.sh
19
skills/capcut-edit · capcut-cli
github.com
20
docs/command-reference.md · capcut-cli
github.com
21
python · capcut-cli
github.com
22
capcut · PyPI
pypi.org
23
CHANGELOG · capcut-cli
github.com
24
docs/jianying-encryption.md · capcut-cli
github.com
25
issue #67 · capcut-cli
github.com
26
issue #111 · capcut-cli
github.com
27
issue #50 · capcut-cli
github.com
28
issue #35 · capcut-cli
github.com
29
issue #85 · capcut-cli
github.com
30
issue #52 · capcut-cli
github.com
31
issue #59 · capcut-cli
github.com
32
issue #44 · capcut-cli
github.com
33
heygen-com/hyperframes
github.com
34
Sponsor @renezander030
github.com
35
Releases · capcut-cli
github.com
36
hypit-ai/hypit\
github.com