Studio Loop 是一个面向 Remotion Studio 的持续改进循环工作流，核心思路是“通过真实使用来改进产品”：一边用 Studio 制作一支真实的 YouTube 视频（结合 NLE 剪辑与动态图形），一边把工作流中遇到的真实体验与性能问题记录下来并修复。
用途与目标
该工作流的目标是让 Studio 保持快速、响应灵敏和可靠。它要求每次实现改动都应用 studio-dev 规范，并在实际编辑任务中发现常见工作流的问题，例如导入与预览媒体、排列/裁剪/分割片段、编辑文字与变换、添加动效图形和音频、拖动与播放、撤销重做、保存与重载，以及渲染并审阅导出视频。
使用方式与流程
首先恢复既有工作：查找已有的工作树、分支或 PR、技术栈、本地视频项目、正在运行的 Studio、浏览器会话和交接记录，继续原项目而不是每轮新开演示；不提交视频项目和导出文件，除非用户要求。必要时检查 Git 状态和安装说明，但应先使用 Studio 再分析实现；只有确认工作树和 URL 归属时才复用服务器，否则从 packages/example 用 bunx remotion studio --no-open 启动并使用其打印的 URL，不假定 3000 端口属于当前检出。
它通过点击、键盘输入、拖放、文件上传和截图来操作真实 UI，使用已注册的 WebMCP 工具进行状态读取和受支持操作，不以源码检查或模拟行为替代 UI 验证。浏览器执行失败时应诊断无头环境并报告验证缺口，不能把自动化失败当成 Studio 的缺陷。
发现问题时，先记录可复现的交互和预期结果，再查看相关实现；改代码前采集相关性能基线，关注反馈缓慢、缺少乐观路径、闪烁、文案或错误信息混乱、布局错误、codemod 失败、竞态和不必要的工作，并检查持久化源码与可见结果是否一致。修复允许内部重构，但须保持有非实验性文档的公共 API 签名稳定，遵循 Studio 既有设计、乐观/历史路径、CSS reset、iframe hover 处理和模式能力；代码可编辑的操作已提供智能体访问，不应新增冗余 WebMCP 包装。修复后在重建的 UI 中重复原交互，验证即时反馈、持久化/HMR、相关失败/导航竞态和撤销重做，覆盖适用的 Studio 模式，并用可比较的项目、视口、交互和播放状态复测性能。
检查点与审查
当用户说“checkpoint”“让我审查这个 PR”或“堆叠下一批”时，视为要求交出稳定审查边界并继续工作，除非用户同时要求暂停或停止。此时完成当前有界修复及其验证，不扩大批次；只暂存预期的生产改动片段，检查暂存差异，保留未完成或无关工作留给下一层；提交推送后更新 PR 描述（行为、验证、性能结果和已知限制），若为草稿则用 gh pr ready 标记就绪，并分享 PR 链接和确切的检查点提交。未完成的 CI 要如实报告，不能在检查结束前称为通过。随后冻结该 PR 的范围用于审查，按 gh-stack 基于检查点分支创建下一层，新层 PR 只显示后续工作。
父 PR 合并后，需核实 GitHub 实际状态并在现有子 PR 继续；保留工作树改动后再更换基线。gh stack sync 会变基并推送，stack push/submit 可能强制推送，未经明确授权不得用它们重写已发布的子分支；保历史的做法是 fetch 并合并更新后的主干到子分支、正常推送、重定向 PR，并重建剩余层的跟踪。未经授权不得合并 PR 或强制推送。
持续性与交接
在 PR 之外维护一份简短的本地交接记录，包含项目和资源路径、工作树/分支/栈与 PR 链接、检查点头、服务器 URL 与启动命令、浏览器连接信息、复现步骤、基线与修复后证据、测试、导出、已知限制和下一个有用的编辑任务；凭据和完整渲染请求/环境载荷不得写入日志和交接记录。上下文变化后从该记录恢复，而不是重新发现或重复已完成的工作。
适用场景与限制
适用于维护和改进 Remotion Studio 本身，不适合把它当作普通视频编辑教程。该工作流依赖 Remotion 仓库、Node/Bun 环境、Playwright 无头浏览器和 GitHub PR 流程；资料未提供独立安装包、版本要求、收费信息或支持的平台范围。