剪映把草稿加密了，你的自动化脚本还活着吗

做视频批量产线的人大概率踩过这样一个坑：网上教程说剪映的草稿就是一个 draft_content.json，用 Python 读出来改改时间线、塞几个素材路径，存回去就能自动生成视频。代码写好了，本地环境也搭好了，结果跑起来发现根本读不懂——文件打开是一堆乱码二进制。

这不是你代码的问题。剪映从 6.0 起对草稿文件做了加密处理，而且这个变化在中文技术社区里几乎没有正式公告，大量 2023、2024 年写的教程到今天仍然在被搜索引擎推到前排。本文基于一次在自己机器上的实测（macOS 剪映专业版 11.6.0），把"哪些版本还能明文读写、加密之后还有哪些合规的替代路线"讲清楚，帮你决定是继续投人力做注入方案，还是换路。

先说结论

如果你的自动化依赖"直接改草稿 JSON"这条路线，需要按剪映版本分三种情况处理：

1. 5.x 时代的老版本：draft_content.json 仍是明文，注入路线成立。有开发者公开建议降级到旧版本客户端来保住这条路线（见下文 issue 记录）。代价是你放弃了新版本的功能和模板生态。
2. 6.0/7.0 到 10.x 的加密版本：草稿被加密，但加解密方案已被社区逆向出来。开源项目 pyJianYingDraft 的一个 fork 提供了可逆的编解码器，思路是调用本机剪映安装目录里的原生库完成加解密，不分发该库本身。
3. 11.x 及以后：结构进一步变化，实测 macOS 11.6.0 上明文入口彻底消失，手改文件的路线不再可行，应转向引擎 API 或 RPA。

判断自己处于哪种情况有个简单办法：看草稿目录里有没有 Timelines/<UUID>/ 子目录、其中的 draft_info.json 是不是二进制。是的话就是密文化版本，不要在 JSON 层继续投入。

一次实测：11.6.0 的草稿目录长什么样

在自己的机器上（macOS，剪映专业版 11.6.0）拿一个真实草稿目录做了完整探测。实验全程遵守两条纪律：动手前先把整个草稿目录完整备份；实验结束后用 diff -rq 对比备份和现场，逐字节一致才算干净退出。

探测结果：

• 时间线正文位于 Timelines/<UUID>/draft_info.json，file 命令识别为纯 data，即密文；
• 它与根级 draft_info.json 加上两处 template-2.tmp 一共构成四个加密镜像——这意味着即使你能伪造其中一份，另外三份互相对不上，草稿会损坏或被判定无效；
• draft_meta_info.json 和 .backup/*.save.bak 同样是密文；
• 唯一能解析成 JSON 的明文文件是一个模板临时件，内容是空骨架：tracks=[]、duration=0——没有任何可利用的时间线信息。

由此得出两个工程判断。第一，“grep 明文找不到某字段"不能证明"该数据不存在”，因为媒体注册表也在密文里，明文侧的阴性结果没有信息量。第二，确认密文后就不该再做任何写入尝试——手写伪造密文只会损坏用户草稿，正确动作是停手、换路线。这次实测中注入尝试次数为零，就是在确认密文那一刻决定的。

社区是怎么走到"加密"这一步的

这条路线的失效不是突然的，GitHub 上的讨论记录了整个过程。

在 JianYingProBatchKeyframe 项目的 issue #3 里，维护者 iHunterDev 早在 2024 年 6 月就给出了应对方案：“更换到旧版本的剪映，现在官网上提供 5.8.0 版本的剪映客户端，下载降级一下就可以用了”；并提醒"如果你的剪映草稿已经用新版本打开过被加密的话，可以上传到云空间，降级到旧版本再下载回来使用"。这说明加密是从某个版本开始强制生效的，且新旧草稿之间存在单向兼容问题——新版打开过的草稿，旧版未必能读回来。

同一个 issue 下，2025 年 10 月有人悬赏求 Windows 端 draft_content.json 的解码思路，维护者的回复是：“目前观察市面上的剪映草稿的商业化项目，是基于 6.0 以前没加密的草稿实现的。所以市面上大概率是没有破解方案（也许是没人敢做），同时目前剪映 6.0 之前的版本也可以满足商业生产使用需要。如果功能真的要使用新版本的功能，可以尝试使用 RPA 的方式来进行实现。”

这段回复里有三个值得记下的信号：一是商业化项目集体停留在旧版本，说明"锁版本"是行业里普遍采用的应对策略；二是"没人敢做"点出了逆向剪映加密的法律与商务风险——这是厂商主动部署的保护机制，和修复一个无主 bug 性质不同；三是给出的替代方向是 RPA（模拟界面操作），而不是继续硬啃文件格式。

后来事情有了进展。pyJianYingDraft 的一个 fork 实现了加密草稿的可逆读写，其 README 明确写了实现方式：“使用内置加密 codec 时，项目会通过本机剪映的 videoeditor.dll 完成加解密，不分发该 DLL”。也就是说它没有破解算法对外分发，而是借用用户自己机器上已授权的剪映安装来完成转换。该项目还致谢了 wenshui330/jy-draftc——高版本草稿 JSON 加解密方案的先行逆向项目。它的验证范围写得同样清楚：“加密草稿能力需要 Windows 64 位 Python 与本机剪映环境；当前参考实现已在剪映 10.3.0 到 10.6.5 范围内验证，其他版本不保证兼容。”

对照我们自己的实测：macOS 11.6.0 不在上述任何已验证范围内，明文入口为零。所以对个人产线来说，现实的选择不是"等社区逆向到我的版本"，而是下面三条路线里挑一条。

三条路线，怎么选

路线一：锁版本 + 明文注入。 把产线钉在 5.8/5.9 这类明文版本上，继续走"生成 JSON 即生成草稿"的最短路径。这是成本最低、确定性最高的方案，也是维护者观察到的商用批量剪辑项目普遍的做法。缺点很直白：用不了新版的模板、智能功能和新特效，而且每次剪映自动更新都可能让这套环境失效——需要禁用更新或做版本快照管理。适合"只要成片、不在乎编辑器版本"的纯量产场景。

路线二：本机授权加解密。 即 pyJianYingDraft fork 的思路：加解密借本机剪映自己的库完成，只处理你有合法访问权的本机草稿。这条路保留了新版本能力，但它有硬边界——当前公开实现验证于 Windows 平台的 10.3.0～10.6.5，macOS 和更高版本不保证可用；并且该 fork 自己也声明这套私有扩展"不是上游公开实现，也不应进入面向上游的 PR"。把它当工程参考可以，把它当基础设施依赖要谨慎：你要接受"版本一变就可能失效、上游不一定接住"的现实。

路线三：headless 引擎或 RPA。 不碰文件格式，走剪映进程自身的接口或界面自动化。社区维护者在 issue 里给的兜底建议就是 RPA；而专门做剪映无头驱动的 headless 引擎项目（公开仓库 README 自述）写明"11.6.0 已支持新建与编辑草稿（不含原生导出）"。我们自己的产线正在往这条路上走：已把运行时升级到 11.6.0 并检出了公开的 headless 引擎源码树。但要提前说清这类方案的隐性成本——它的构建验收很严格：README 规定"编译结果必须匹配固定哈希，否则停止"，且已验证的桥接工具链绑定特定版本（Apple clang 21.0.0 / macOS SDK 26.5）。我们在实际部署中就撞上过这个坑：本机工具链版本与 pin 不一致时产物哈希必然不命中，正确动作是走引擎自带的重验（verify-build/reverify）流程补齐环境和源码，而不是修改期望哈希强行绕过——改了哈希，整条供应链验收链就废了。

给产线负责人的检查清单

如果你正在维护或准备搭一套基于剪映草稿的自动化，按这个顺序过一遍：

1. 先花五分钟探测明文入口：草稿目录里找 Timelines/<UUID>/、file 判断 draft_info.json 是否二进制、试着解析唯一的明文临时件看是不是空骨架。这一步在任何写码之前做，能省掉整轮返工。
2. 确认密文后停止一切文件级写入。四个加密镜像互相对不上，改一个不够，只会损坏草稿。
3. 实验前先备份，退出后做 diff -rq 完整性校验，剪映进程退出后再复查一遍。用户的原始草稿永远只读。
4. 选型对齐需求：纯量产选锁版本；要新功能选 headless/RPA 并接受验收成本；Windows 10.3～10.6.5 区间内且愿意承担断供风险，才考虑本机 codec 方案。
5. 别信搜索前排的旧教程。2023 年前后写的"Python 改 draft_content.json"文章大多默认明文格式仍然存在，它们描述的是历史上的真实，不是你现在机器的真实。

这件事的更大一层

剪映草稿加密不是一个孤立事件，它是内容创作工具平台化的常见动作：当模板、素材、云端协作成为商业模式的一部分，本地工程文件就从"用户的数据"变成了"平台的资产载体"，加密只是时间问题。同类的事在剪辑、设计、笔记软件上一再发生。

对依赖工具做自动化的人来说，真正可迁移的经验只有一条：不要把产线建立在"文件格式恰好是可读的"这个偶然条件上。格式会变、版本会变、厂商意愿会变。给自己留一个"五分钟探测"的习惯，留一条不依赖格式的退路（API、RPA、或者干脆换工具链），比任何单点技巧都值钱。

最后交代一下边界：以上关于版本行为的描述来自一次自有环境的实测与公开项目文档，不同系统、不同小版本的剪映行为可能有差异，动手前请先在你自己的目标机器上复测。涉及他人设备的批量操作，务必在获得授权的前提下进行。