一个开发者在Hacker News发了个Show HN帖子，介绍一个叫FableCut的视频编辑器。听起来不算新鲜，浏览器里剪视频的开源项目这两年冒出来不少。但它的设计有一点值得多看一眼：整条时间线就是一份project.json，人可以在UI里拖拽剪辑，AI agent（比如Claude Code、Claude Desktop）也能直接读写同一份文件来剪片子，改动大约150毫秒内就会同步回浏览器界面。零npm依赖，一行node server.js启动。
大多数"AI剪辑"工具是把编辑过程藏在一层API后面：你发指令，它吐出一段渲染好的成片，中间发生了什么你摸不到。FableCut反过来——project.json可读、可写、可对比，UI只是这份文件的一层实时渲染。我更在意的不是它功能列表有多长，而是它把"AI能不能直接操作应用状态"这个问题，做成了一个能跑起来的例子。
project.json 是接口，不是文档
这份JSON描述媒体、剪辑点、轨道、特效、关键帧、转场——任何能写JSON的进程都能剪视频。人类改UI、agent走MCP或REST、或者直接手写文件，三条路最终写的是同一份东西，谁改了都靠一个revision计数器对齐版本，冲突的一方会被拒绝写入而不是被静默覆盖。
这套机制对agent还刻意做了"省话"处理：不用整份JSON来回传，而是用小补丁（fablecut_patch_project）改时间线，读的时候拿一份压缩摘要，需要文档时只取对应章节——这是冲着token成本去优化的，说明作者不止想让agent能用，还想让它用得便宜。
功能列表说的是"认真"两个字
一个零依赖的周末项目，通常功能会很单薄。FableCut反而堆了不少东西：约25个属性支持关键帧动画、17种转场、色度抠像、基于MediaPipe的人像抠图、给参考视频提取BPM和镜头节奏的"blueprint"分析。
功能全不等于好用，但至少说明这不是拿一个demo糊弄发布——是真的按一款可日常用的NLE的标准在堆功能，包括导出走ffmpeg的CRF-18编码管线。
这条赛道上，FableCut站在哪
"用JSON描述时间线给AI操作"不是新鲜想法。Remotion、Editly几年前就干过：用代码或JSON生成时间线，离线跑ffmpeg渲染出片。它们的问题是人没法实时插手——你只能改代码重新渲染，看不到中间过程。商业化那一路是Shotstack式的REST渲染API，功能强，但是闭源黑盒，你依然摸不到中间状态。
FableCut真正想抢的位置，是"状态文件实时协作"这一支——同类直接对标的是OpenCut和video-editing-mcp，都在做浏览器编辑器+MCP的组合。FableCut的差异化主张是"人和AI能同时改同一条时间线"，靠revision计数防覆盖、靠SSE把改动实时推回界面。
接口退回一份文件，是少见的清醒选择
这套设计能成立的前提，是MCP协议把"agent直接读写应用状态"变成了一件标准化、可信赖的事。放在三年前，这条路根本没法走。
华丽的README之外，还缺什么
检索没能找到这个Show HN帖子在Hacker News上的实际讨论、也没有独立于README之外能验证的star数或使用反馈，只能确认作者自述的功能清单本身。这不代表项目造假，但意味着它目前处在发布即评测的早期阶段，社区检验还没跟上。
- 风险.零npm依赖、单文件启动是工程上的洁癖，但也意味着这么长的功能列表全靠一个开发者维护，出问题时没有插件生态和社区兜底。
真正值得盯的变量不是功能列表还能加多长，而是三件事：GitHub上的真实活跃度、有没有人用它实测过agent剪片子的效果、以及"人机同写一份文件"这套冲突处理机制在多人多agent同时写入时到底扛不扛得住。答案现在都还看不清。
FableCut给了一个干净的答案：AI操作软件，不一定要靠API，也可以靠一份大家都能读写的文件。这个判断本身站得住，能不能落地，还得看这个仓库能不能撑过第一批真实用户的折腾。