方法论与洞察

2026-07-31 Codex 教程实战六 · 自动化录屏 19 段复盘

事实记录（不可修改区）

• 项目：《Codex 保姆级教学》实战六「自动化口播剪辑」的教学素材录屏（不是剪片，是录教程演示画面）
• 日期：2026-07-31
• 预期目标：按 录制任务书_给同事.md 完成清单内全部镜头（19 项，含选录的 05D）
• 最终结果：19/19 产出，总时长 21.7 分钟，0.98 GB，全部 1920×1080 / 60fps
• 验收状态：
  • 机器校验 19/19 通过（ffprobe 时长区间）
  • 抽帧目视 19/19 通过（AI 逐段抽帧确认关键画面）
  • 人工观看：用户抽查若干条完整看过，反馈无问题；19 条逐条完整终审未完成
• 数据来源：ffprobe 实测、脚本 stdout、OBS StopRecord 返回的落盘路径
• 前置事实：本项目此前有一次自动录制尝试，产出 3 个 mp4 后被整体废弃（录屏原片/_作废_Claude自动录制/）。本次立项动机就是”避免返工”。
• 副产物：开源工具 humancast（MIT，github.com/Mr-Salticidae/humancast，17 文件 / 1838 行 Python）+ 项目内录制脚本 8 个
• 工作区：{Codex教程录屏}/06_实战六_自动化口播剪辑（视频文件不进知识库）

Codex 真实运行数据（非摆拍）

一、作品回顾

1. 起点

起点只是一个能力问题：能否模拟人手移动鼠标（丝滑而非瞬移）、模拟打字过程（非粘贴）。背景是同事商议后决定由本人录制，以避免返工。

2. 三个被解决的真问题

录制闭环靠 obs-websocket v5（零依赖手写 WebSocket）：开录 → 演示 → 停录 → ffprobe 校验 → 不合格自动重录，废片不删只加 .FAILED。

二、结果分析

做到的

• 19/19 镜头产出，无缺失
• 任务书点名最易出岔的两段远超警戒线：段 11 实测 305.5s（线 120s）、段 13 实测 319.7s（线 240s）
• 成对素材时长严格一致（08A/08B = 16.3/16.2s，09A/09B = 22.2/22.2s），便于左右并排剪辑
• Codex 全程真实运行

没有一次做对的

• 段 01 录 3 次、段 02 录 4 次、段 12 录 3 次才通过
• 段 05C 只有 10.1 秒（低于自设下限）。选择接受而非重录——重录意味着往对话里再发一遍「确认，开始渲染」，会污染上下文。这是权衡后的妥协，不是成功。
• 误点 GitHub 链接打开了浏览器。幸而 Chrome 开在主屏（不被录制），抽帧确认未进画面，那条仍判废。
• 中途产生 455MB 废片一条（检测器超时空转）
• 19 条逐条完整人工终审未完成；段 04A（254s）和段 13（320s）的中间过程无人逐帧看过

最有价值的数据点：4 条”时长合格但内容错误”

四条全部通过机器校验。只验时长的话，这四条都会进成片。

三、方法论沉淀

[出片不等于合格：机器验参数，人眼验内容]

核心：自动化产出的素材，“文件存在且参数正确”和”内容正确”是两件独立的事，必须分别验。

来源：本次 4 条时长合格但内容错误的素材；以及本项目上一次自动录制产出 3 个 mp4 后被整体废弃。

验证状态：⭐⭐ 二次验证（跨两次独立尝试成立）

已单独提炼为原子律：自动化产出双重验收_机器验参数人眼验内容_v1

[判断”AI 跑完没有”，用应用自己的状态指示器]

核心：不要用画面变化/静止推断 AI 是否完成，用 UI 里那个明确表示运行状态的元素。

来源：排练时静止检测在 Codex 显示「正在思考」期间就判定”输出完了”——那四个字是静止的，画面确实没变化，检测器如实报告，但结论完全错误。

验证状态：⚠️ 首次（仅 Codex 桌面端）

操作规则：

1. 先找运行状态指示器（Codex 是发送按钮：方块/箭头）
2. 用亮度这类与内容无关的判据识别状态，不要拿参考图比对——视图切换会让比对失效
3. 等待分两拍：先等它变”在跑”，再等它变回”空闲”并持续 N 秒
4. 图像锚点比对在 AI 场景根本不适用——每次回复内容都不同

边界：若应用没有这类指示器，退回”先等变化再等静止”，但要给足 start_timeout（Codex 实测有 7 秒完全静止的思考期）。

[观察行为本身会干扰被观察对象]

核心：高频屏幕抓取会拖慢被观察的应用，GPU 合成的 Electron/Chromium 应用尤其严重。

来源：10Hz 抓两个区域时，一个本该 4 秒返回的 Codex 回复被拖到 4 分钟以上；换成 2Hz 抓一个小区域后 4.1 秒完成。差两个数量级。

验证状态：⚠️ 首次（单次测量，但对照明确：同一提示词、仅改轮询参数）

操作规则：poll 不低于 0.4s；观察区域尽量小。调小 poll 不会让你更快知道结果，只会让结果更晚发生。

[判据的隐含前提必须写进注释]

核心：任何阈值判据都有成立前提，前提不写下来，就会在没预料到的状态下静默翻车。

来源：完成判定用「按钮区最暗像素 < 100 = 在跑」，隐含前提是输入框为空。框里一有内容，发送按钮从浅灰变深色，和停止方块一样暗。段 13 因此连着两次没跑起来——Codex 自己往新任务里塞了个 Skill Creator 建议 chip。

验证状态：⚠️ 首次

操作规则：写判据时把”在什么状态下成立”写进注释；失效时优先怀疑前提被破坏，而不是加大容差；能消除前提依赖的（如先清空输入框再检测）就消除它。

[人写给人的任务书，自动化时有系统性失配]

核心：任务书描述的是”人怎么操作”，自动化执行时至少三类内容会失配。

来源：本次三处偏离——

• 交互路径：任务书写”点回答里蓝色的文件名 → 右边渲染出文档”，但 Codex 现在把内容内联渲染，很多回答根本没有那个链接
• 操作手法：任务书写”双击画面全屏”，实测双击和 F11 都无效，Enter 才是这个播放器的开关
• 时长估算：按人手速度估的（段 02 估 ~20 秒），脚本跑只要 10.4 秒，需要刻意放慢

验证状态：⚠️ 首次（单份任务书，但三类失配各自独立出现）

操作规则：自动化前先按任务书排练一遍不录制；时长估算当参考不当验收标准，但要意识到”太快”对教程片是缺陷；偏离任务书时明确记录并告知，不静默改掉。

[混合 DPI 下永远读回真实矩形]

核心：SetWindowPos 请求的尺寸不等于实际生效的尺寸。

来源：125% 缩放的副屏上，请求 1320×840 实得 1056×672（正好 /1.25），位置却原样生效；且只在窗口首次跨屏移动时发生，第二次就准了。本次跨 4 个不同应用重复出现（Codex / 播放器 / 记事本 / 资源管理器）。

验证状态：⭐⭐ 二次验证（同会话内跨 4 个应用重复）

操作规则：摆完窗口一律 GetWindowRect 读回；需要精确尺寸就摆两次；关键坐标（如进度条）按显示器推算而非窗口——最大化窗口会溢出显示器边界。

四、下次改进

如果重来，最想改哪一步

在写第一个录制脚本之前，先花 10 分钟把整套任务书排练一遍（不录制）。

本次是边录边发现失配，段 01/02/12 各重录 2~3 次。这些问题在一次完整排练里就能全部暴露，代价远低于反复重录。

下次同类型任务的行动清单

1. 先排练，后录制：全部镜头空跑一遍，记录真实交互路径和实际耗时
2. 先定验收标准，再定预期时长：区间用排练实测值，不用任务书估算值
3. 每段录完立刻抽帧看，不要攒到最后
4. 副作用段落单独标注：会改真实项目状态的段落（本次是 02/03/05C/11/13）不做自动重录，失败先人工确认现场
5. 长素材（>3min）安排逐条终审，抽帧不够
6. 判据写注释时把成立前提一起写

五、一句话结论

自动化能保证”每次都按同样的方式做完”，但保证不了”做对”——机器验参数，人眼验内容，这道关卡本次拦下了 4 条参数全对、内容全错的素材。

关联文档

• 自动化产出双重验收_机器验参数人眼验内容_v1（本复盘提炼出的一句话律；后续两批共拦下 6 条，已升 ⭐⭐⭐ 铁律）
• 2026-08-01_Codex教程清单2-4_三项目19段录屏复盘（下一批：同工具零改动录清单 2/3/4 三个真实项目 19 段）
• UI自动化的固定坐标必须绑前提断言_v1（本篇「判据的隐含前提必须写进注释」那一节的成律版本，首验案例就是本批）
• 2026-07-16_Codex保姆级教学_代码化口播剪辑完整复盘（同一项目上游：那篇讲怎么剪这条片，本篇讲怎么自动化录教学素材）
• 素材审片也能蒙眼_盲选靠标题定案靠眼睛_v1（同构原则的素材域版本：机器只配盲选，定案靠眼睛）
• 蒙眼剪辑法_方法论笔记（本次录制演示的正是这套方法）
• 代码资产索引（工具 humancast 登记处）
• 04_方法论与洞察索引