DemoForge——已经建成的视频流水线
这不是一个计划：它是 FlexMesh 仓库里一套已经建成的、agent 原生的视频生产系统。它取用应用的E2E（端到端）测试屏幕录像，产出打磨过的逐功能演示视频。15 集已经渲染并存放在磁盘上（ep01–ep15，日期跨 2026 年 3 月至 7 月）；24 个 E2E 集成测试（j01–j23 这些 journey）对应到这 15 个功能演示。
架构（被理论化过的循环，已经落地实现）
awareness 专栏在理论上推导出的那条生产线（video-production-pipeline；context-derives-from-the-sop）在这里已经写成了代码，其中两个需要判断的阶段由Claude Code 充当循环体：
- 录像分析（agent）——读取测试的
.log，提取其中的[E2E]步骤标记和时间戳；ffmpeg在步骤边界处抽取关键帧；多模态视觉模型读取每一帧以理解屏幕内容；写出analysis.json（步骤、时间区间、屏幕描述）。E2E 日志自带的标记就是切分的基准真值——测试的埋点同时充当了视频的剪辑单。 - 脚本撰写（agent）——为每个步骤配旁白，分配节奏（0.5×–3× 变速 / 定格 / 停留 / 跳过），字幕按 5–10 个词切分。输出
script.json。 - 配音（本地、免费）——通过
mlx-audio使用 Chatterbox TTS（文本转语音），配合mlx-whisper得到词级时间戳：跑在 Apple Silicon 上，每次渲染的 API 成本为零（胜过通用 Route-B 方案默认假设的 ElevenLabs 级别 $22/月）。 - 合成——
cut-segments.py把录像切成变速后的片段；build-props.mjs把每一份中间产物组装成remotion-props.json。 - 渲染——
npx remotion render FeatureDemo --props …→output/{episode}.mp4。
文件流：recording.mp4 + .log → analysis.json → script.json → voice.wav → word-timestamps.json → segments/*.mp4 → remotion-props.json → FeatureDemo render。
打磨是写进代码的，不是点出来的（"细节"这道悬案，已经解决）
DESIGN.md 这套设计系统，把原始 E2E 录像所欠缺的打磨，编码成了一组 Remotion 原语——awareness 笔记留作待定工程决策的那一项（video-editor-selection，方案 (b)）在这里已经拍板并实现：iPhone-15 风格的设备边框、卡拉OK 式逐词高亮字幕、UI 元素上的缩放高亮（平滑缩放 + 边框发光）、坐标处的点击涟漪、分段进度条、品牌配色、Inter 字号体系，以及节奏原语（关键交互慢动作、加载快进、旁白处定格）。光标/缩放强调这类打磨在合成层里只写一次，之后每一集都继承它。
对 awareness 用例而言的承重缺口
输出是 1920×1080 横版（16:9）。这适合网站首图、App Store 预览、YouTube 功能演示、应用内引导——不适合短视频这个战场，那里要的是竖版 9:16（short-video-sop）。所以 DemoForge 按目前的建法，服务的是深思熟虑型工具 / 时长偏长的演示这个需求，而还不是它看起来像的那个"第一天就能跑的短视频探针细胞"：要打到短视频战场，需要给 FeatureDemo 合成做一个 9:16 的变体（这是 Remotion 里的一次布局替换，不是新建一条流水线——片段、配音、脚本这几层都与画幅无关）。这是从"流水线已经存在"走到"短视频细胞能跑起来"之间唯一具体的一步建造工作。
老实交代现状
两次 git 提交（初始 + 一次配置修复），2026 年 2–4 月建成，渲染工作持续到 7 月——这是一个个人用的工具，不是一个有人在维护的产品面。资产是真实的，架构是站得住的；只是还没有把它对准分发这件事。
面试原型题："给我看一个你做出来后连自己都没想到规模会这么大的东西"——一条 agent 在环的视频流水线：E2E 测试套件同时充当素材来源和剪辑单，本地模型把配音/转写的成本清零，视觉打磨则活在代码里。
近邻：measurement-stack（那套经过 E2E 测试的埋点，其录像正是这里的输入）· video-production-pipeline（awareness 专栏对这件事本身的理论）· cal-ai-the-screen-is-the-ad（"屏幕即素材"的教义，在这里被机械化实现）。