【学习笔记】Table-VideoSOP 深度拆解：一个人带一群 Agent 做视频的「生产协议栈」——总控分段、机器可读 DESIGN 与「未验证」文化

整理日期：2026-09-28 调研方式：对 duoduoler-ops/Table-VideoSOP 做浅克隆后逐文件精读——53 个文件、46 个文本文件约 3800 行全部读完（含全部模板、提示词、双语 README 和唯一的 PowerShell 脚本）；star 数、创建时间、许可证以 GitHub API 当日实测为准；仓库声称引用的 5 个上游项目逐一核实过存在性与许可证。仓库截图保留所有权利，本文未复制任何图片，引文按 CC BY 4.0 署名引用。 写作动机：上周刚拆完 Hypit（给 Agent 造一门视频 DSL 加编译器的「全自动」路线），这个仓库是同一问题的反面解法——不写一行制作代码，把「人和一群 Agent 协作做视频」这件事本身协议化。它和我自己那条 HyperFrames 生产线关注的是同一类问题（人机分工、验收、返工），docs 里甚至点名「HyperFrames 等可作为替代制作路线」，值得对照着看。

一、太长不看

Table-VideoSOP（GitHub duoduoler-ops/Table-VideoSOP）是 B 站／抖音 UP 主「一只桌子」2026-09-20 开源的 AI 视频制作 SOP 资料包：SOP、规则、模板、提示词与经验正文，外加一个 123 行的动态自检脚本。定位一句话（README 原话）：

你负责内容、风格与采用决定；Agent 负责规划、任务准备、动画与后期、检查和记录。生图、生视频由你在选定工具中手动完成。

最值得带走的七件事：

1. 它是「协议栈」，不是工具——AGENTS.md（任务路由）+ 9 篇 docs（流程正文）+ 12 个 templates（控制表格）+ 9 组 prompts（可复制指令）+ 5 篇 experience（工艺经验）+ 1 个自检脚本。默认制作路线 Remotion＋FFmpeg（生视频以 Google Flow 为示例工具），但仓库里一行制作代码都没有，明说「本包是文档工作流，不自带运行环境或生成账户」。
2. 核心架构是「总控—分段」多会话并行：第一次对话当总控，管整期规划、中央表和总装；每个制作大段开独立对话，任务书规定「专属写入范围」，只能写自己的目录，中央表只读——用文件系统边界实现多 Agent 隔离，且「不自动派子 Agent、不启动高负载渲染或安装依赖」。
3. 三本账分离：本期说明记输入、制作大段表记「采用与进度」、QA 表记「检查结论」，互不越界。配套两条铁律：「新文件不是自动采用版，『允许制作』也不是『成片通过』」；QA 栏目只允许 通过／未通过／未验证／不适用（原因）四个值。
4. 「未验证」是一等公民状态：最终验收要求「以 1× 完整审看、审听最终合成文件。无法完成的项目标未验证；参数、波形、抽帧或解码不代替主观检查」。全仓库处处是防幻觉条款——「不猜正式时间码」「没有的写待补，不创建空文件冒充输入」「不按修改时间挑最新版」。
5. 三个反直觉的工艺规则：出设计图前先交「镜头剧本」（写观众怎么看，你审一次再出图，防止「会动的幻灯片」）；「同类型对标已确认片，新类型才做样片」——本质是给视觉质量建回归测试；「看着太快、太突然时，先查时长再调曲线：曲线补不了总时长不够」。
6. DESIGN.md 是机器可读的视觉规范：JSON front matter + 自创 x-video 扩展（五类运动曲线、校准样本的帧数／位移／跟随延迟、证据字段），格式上游是 google-labs-code/design.md（28k★，Apache-2.0，已核实）。
7. 罕见的诚实：README 专设「验证与许可状态」一节，自曝整套流程只验证过一段约 18 秒的测试片、窗口框规则是测试后补的尚未复测、全新电脑安装与完整成片复现「仍未验证」；许可证三层拆分——正文 CC BY 4.0、脚本 MIT、截图（含「黑蛋」形象）保留所有权利。

热度很小：截至 2026-09-28 实测 20 star / 5 fork / 9 个 commit / 唯一一个 PR 是作者自己加宣传视频，全程一个作者。它不是 Hypit 那种现象级项目，但单位 star 的含金量可能是我在「Agent 做视频」方向上读过最高的——因为几乎每条规则都能追溯到一次真实返工，作者还把返工数字原样写进了文档。

二、它是什么：把一个人的返工史编成协议

时间线（GitHub API 与 git log 实测）：

作者「一只桌子」（Table，联系邮箱 duoduoler@gmail.com，GitHub 组织 duoduoler-ops），在抖音／YouTube／小红书／bilibili／X 多平台同名更新科普向视频；README 展示截图来自其第 4 期《工作边界》v08 成片（60fps，assets/README.md 把每张截图精确到秒点和帧号）。仓库名里的 Table 就是「桌子」——一只桌子的视频 SOP。

两个容易踩的误解：

• 它和 Tango／Guidde／DeepHow 那类「录屏自动生成操作 SOP」的 SaaS 毫无关系（用 “video SOP” 搜索会掉进那个品类）；
• 它也不是拿来就跑的模板工程——examples/ 里三个例子全是文字填写示例，明说「示意参数尚未通过视觉确认」，不含任何可运行的 Remotion 工程、素材包或角色包。

适用范围作者自己划得很清楚：以已确认配音为时基的科普、讲解、观点与演示视频。不是剧情片，不是口播数字人流水线（那条线见数字人调研），也不是自动混剪。

三、资料分层与九步主流程

53 个文件按六层职责组织，这本身就是设计：

九步主流程，每步一道确认门：环境检查 → 建 DESIGN（静态确认→动态确认→写规范，三段式，静态确认不能代替动态确认）→ 稿件与配音 → 制作大段表（确认划段／路线／分工）→ 分段设计（新对话并行）→ 全片视觉总览确认 → 总装锁画 → 声音字幕与最终 QA（1× 审看审听）→ 封面与发布。确认门不互代是反复强调的：确认大段表只放行设计与准备，不能替代视觉确认；样片通过不等于成片通过；「设计总览确认只覆盖实际展示的版本和方面，静态图不能证明动态效果」。

「总控—分段」的并行设计是全包最有工程味的地方。大段表确认后，总控自动建目录、填任务书，并为每段生成三行开工指令（所有路径解析成使用者机器上的真实绝对路径，「公开模板不预置作者路径」）：

在【系列根绝对路径】工作，负责【期名／大段 ID 与名称】。
读取【系列 AGENTS 绝对路径】和【本段开工任务绝对路径】，核对当前依据，按任务书允许阶段和写入范围直接开始。
将成果路径、验证和未解决项写到任务书指定的接入说明，完成本段后停止。

分段任务只能写自己的四个专属目录（设计／素材／分段工程／局部证据），中央表、公共资产、主工程一律只读，公共改动需求写进「接入说明」交总控统一处理；跨段转场写明归属，「避免双方重复制作或无人补缝」。单期目录规约本身也是一套信息架构：00_本期控制 到 08_发布素材 加 90_历史归档，每个目录只装一类事实。

（这一段和我 HyperFrames 生产线踩的是同一个坑：多会话／多 Agent 并行时，状态必须有唯一归属。HyperFrames 用渲染合同和时间轴解决，这里用三本账加写入边界解决，思路可以互相印证。）

四、含金量最高的六个机制

1. 制作大段表：中央状态三问

划段原则是「按叙事任务、视觉关系、技术路线或风险变化划段，不按固定秒数或一句一镜拆分」。每段必须回答三个问题：声音已经给了什么信息；画面新增什么关系、证据或情绪；哪些文字必须留下。还有一条很狠的验收标准：画面只把配音换成大字时，「先重新设计关系或证据」。出表自动附两张短表——重点审查（疑点／影响／验证办法／依赖）和生视频推荐（附替代路线，没有合适候选就说明原因，「不按比例凑数量」；且「真实产品行为和结果用可核验的材料，不用生成画面充当证明」）。

2. 镜头剧本与四种画面测试

出设计图前，总控先把每段「观众怎么看」写成一页镜头剧本——主角对象怎样变化、镜头怎样带人看、高潮与需要停下阅读的地方、对标哪段已确认的片——用户审一次再出图。README 的理由很直白：设计图是这条过程的关键帧，「避免先排好版面再让它动，做成会动的幻灯片」。验收侧配四种测试：删字测试（去掉解释性标题后主体关系仍可见）、静音测试（关掉声音仍能看出对象变化与因果）、合看测试（画面与配音协同，触发／阅读／停稳／转场合适）、对标测试（与已确认同类片连看，动态持续性、主体可读尺度和镜头推进不明显低于它）。

3. 同类型对标，新类型才做样片

这是我觉得全包最聪明的一条——把软件回归测试的思路搬进视觉质量：与已确认片同类型的段落不做样片，完成后与对标片连看；只有新镜头方式、新空间／三维处理、新互动、新转场、新技术路线才先做一段真正覆盖难点的带配音样片，确认后登记为范例，此后同类只对标。样片经济学也讲清楚了：「未解决的问题一旦扩展会导致较大返工时」才做，「不能用简单标题入场证明复杂接触或连续状态转换已经解决」。经验正文里还有一个教科书级正反例：同一段正文 MG 的 v01／v02 都因动态不足被否（v01 最长静止约 5 秒；v02 只用位移缩放代替「多轮处理与后果」，表述不准），v03 让同一对象经历「正常处理→逐步失真→影响后续→继续处理仍无改善→交接」才通过——作者由此提醒「只记『多动不等于表达成立』会丢掉动态不足那一半，下一期就可能做成少动、长停的幻灯片」。

4. 先查时长，再调曲线

experience/视觉叙事与连续MG.md 的「给运动和画面留足时间」一节，是我读过最实用的 MG 节奏诊断法。核心论断：曲线只改变时间在过程里怎么分布，补不了总时长不够。规则排布：按变化大小给时长（移动越远、同时变的元素越多、形变越大，时间越长，但不按距离成比例加）；同镜头里更大的变化不能比更小的变化时间还短；画面之间的过渡单独算一次变化，不拿配音词点之间剩下的零头凑；一次主要变化约 0.3 秒内完成一定太短。作者给了三组真实数字（并标明「数字只说明思路，不是默认值」）：按短距离校准的 0.77 秒标签传递放到约 2.5 倍距离上看着突然，曲线不动、只把时长加到约 1.15 秒就通过；另一处变形给 1.9 秒嫌拖、紧接着元素更多的让位只给 0.65 秒嫌突然，重新分配为约 1.45 秒和 1.1 秒后通过——「前几轮都在调速度曲线，没用」。

5. DESIGN.md：机器可读的视觉规范 + x-video 扩展

静态／动态测试确认后，由 Agent（不是用户）从真实样本提取参数写入根目录 DESIGN.md。通用 token 沿用上游 design.md 的标准字段（颜色角色、六级字体、圆角、间距、组件引用，均带单位），视频语义放自创的 x-video 扩展：五类运动曲线（reveal／anticipation／travel／settle／process，并警告「出现类曲线前段变化极快，用在变形上会让过程一闪而过」）、校准样本（fps、阶段帧数、位移像素、角度、跟随延迟帧数及适用范围，「没有证据的参数不虚构」）、证据字段（static／motion／confirmation 三个路径）、fixed／variables／exceptions 三分类。验证分三层：结构（可解析、引用存在、无未填必需项）→ 实现（代码真的取了这些值）→ 视觉（真实样片能证明构图、因果、阅读与衔接），并明确「通过结构校验不能代替后两层」。这套「设计 token＋视频运动参数＋确认证据」的格式，值得任何做程序化视频的人抄走。

6. 动态自检与复盘二分法

tools/motion-check.ps1（MIT）解决一个真实痛点：多数 Agent 不能以正常速度观看自己渲染的视频，只能看静帧。它只调用本机 FFmpeg／FFprobe：用 freezedetect 做连续静止区间统计（默认 ≥0.75 秒、-55dB），输出约 48 格带时间码的总览图、文字／JSON 摘要和指定区间的密集帧条带（默认 10fps）。边界写得极清楚：「只定位，不判通过」——并附了一个反例：作者某版静止约 25%、最长静止 1.4 秒，指标不算差，「仍因动态不足、表述不准被否」，结论仍靠与对标片连看和用户 1× 观看。

复盘模板（prompts/09 + templates/复盘）把返工二分：规则没写还是写了没执行。前者先看能否改写现有条目、写入时保留正反两面；后者只改触发入口或任务书，「不新增条文」。用户看片意见按原话记进 QA（「不改写成规则语言」），期末复盘直接引用；满意的画面登记为今后的对标片。还有一条我一直想在自己流程里落地的规矩：每提议新增一条规则，至少同时检查一处能删减或合并。

五、独立核实：我查过什么

一个实操提醒：README 里那五张 MG 截图和两张生成场景图不在 CC BY 4.0 范围内（保留所有权利），二创或转载时不能顺手搬图；文字部分按 CC BY 4.0 署名引用即可。

六、批判性评估

1. 单作者、单系列的经验密度。所有工艺参数（0.3 秒下限、0.77→1.15 秒、静止 25% 被否）都来自一个人的返工史，样本量为一。作者对此有自知之明——反复写「数字只说明思路，不是默认值」「不把一次案例的秒数、构图或否决理由变成所有项目的强制规则」——但换个人、换个画风，参数仍需整体重新校准。
2. 流程重量与内容形态错配。12 个模板、九步流程、三本账，对一期十来分钟的成系列科普片是保险，对 30 秒短视频是杀鸡用牛刀。仓库内置了减压阀（「单段文字方案不补建整期控制表」「可选模块不影响主流程」），但整体仍是重流程取向。
3. 语言写给 LLM，不写给人。大量「不 X、不 Y、不把 A 当 B」式高密度否定约束，人类直接读会累；也只在 Windows + Codex 环境验证过路由执行，换模型能否同样稳定，未知。
4. 平台绑定。自检脚本是 PowerShell 7 专用，字体路径硬编码 C:/Windows/Fonts/arial.ttf（找不到会降级省略时间码）；macOS／Linux 用户要自己移植。
5. 「零代码」承诺的另一面：想直接获得一条能跑的生产线的人会空手而归——没有示例工程、没有 Remotion 模板、没有任何 CI。它赌的是「流程对了，工程是平凡的」，这个赌注对不对，要等社区验证。
6. 成熟度确实早期：9 个 commit、一周历史、无 issue 讨论；「完整视听成片的独立复现仍未验证」是作者自己写的。
7. 人仍是瓶颈：配音、生图、生视频、每一步确认都在人手上。这是设计选择（质量、版权与事实可控），不是缺陷；但别期待它像 Hypit 那样「一条命令 100 个变体」——两者方向完全相反。

七、对照与可迁移

把「Agent 做视频」这条线上的三个项目放在一起，恰好是三种工程化路线：

Table-VideoSOP 值得直接偷走的五件事：对标片回归测试（同类型连看不降低，新类型先做样片）；QA 四态（通过／未通过／未验证／不适用——「未验证」这个状态挡住了 LLM 最爱的「看起来通过了」）；先查时长再调曲线的诊断顺序；复盘二分法（规则没写 vs 写了没执行，后者改入口不加条文）；三本账分离（输入、采用、检查各有唯一归属）。这五条不限于视频，任何多 Agent 长流程都用得上——本质上，这个仓库演示的是在没有引擎、没有 DSL 的情况下，仅靠文档协议就把一群 Agent 的协作约束到可交付质量，这可能是它对整个「Agent 工作流」方向最有参考价值的样本。

本文对 Table-VideoSOP 的引文基于 duoduoler-ops/Table-VideoSOP（作者：一只桌子），CC BY 4.0，有摘选；仓库截图保留所有权利，本文未复制。