三天 93 次提交：广告素材自审平台首期上线总结

开发周期 2026-08-08 → 2026-08-10（3 天，93 次提交） 当前状态 已上线，可投入使用

系统本身干什么，写在功能介绍那篇里。这篇是首期交付的总结：做了什么、哪些取舍是有数据支撑的、哪些坑值得记住。

核心要求，一切取舍按这个排：第一，检查准确度。第二，速度。

一、最关键的技术选择：逐帧，不是整片直传

这是首期唯一一个我愿意花五倍成本去换的决定。实测数据：

注意后两行都是子集——不是换了个角度看问题，是纯粹的漏报。

直传的病根是分辨率：整片会被压到 720p，小字（cr 标注、收益数额、AI 标识）到模型眼里就糊了。帧是原分辨率送的，看得清。

每批 8 张也不是随便定的——开到 24 张、46 张，token 只省两成，报出从 11 条掉到 7 条、5 条。

贵五倍、慢一点，但准确度是直传的五倍，所以选逐帧。 一条 79 秒的成片：103 帧、分 13 批送模型，全流程约 70 秒。

二、三个审核入口

一次传多个文件 = 建多条独立记录，各自一份报告、一套判定，互不牵连。

规则包

74 条规则，两个轴分四类：

            红线（命中即打回）      惯例（反复被挑但不致命）
通用         GR1–GR5                GA1–GA10
产品专属     PR*                    PA*

外加三份环节文档（编导 / 制作 / 剪辑各一份，不分产品）。

每条规则是六字段块：级别 / 环节 / 看哪 / 判定 / 不报 / 来源。其中「环节」决定这条规则在哪个入口生效，「不报」用来堵模型的过度推断。

送给模型的规则包 = 环节文档 + 通用红线 + 通用惯例 + 产品规则，按当前环节裁剪。某个产品审成片是 5944 字。

结果怎么给

打开一条记录，最上面一句话直接说该干嘛：

• 没查出问题，可以提交人工审核
• 机器报了 N 处，还有 M 处没判
• 要改 N 处：12s、35s、48s ← 位置直接列出来，拿着就能改
• 这次没审完：⋯（排除原因后重审会从断掉那步接着跑）

每条问题三个按钮：要改 / 忽略 / 误报。后两个结果一样（都不用改），但报给系统的是完全不同的信号——误报会进周报用来改规则表述，忽略不会。

规则会自己进化

这是首期最花心思的一条链路：

人工审核驳回
  → 员工在自己的记录上点「人工审核未通过」，抄进驳回意见（可带秒数）
  → Claude Fable 5 读意见 + 现有整包规则，判断：
       现有规则覆盖了吗？该在哪几个环节拦？算红线还是惯例？规则怎么写？
  → 落成草案，不自动入库
  → 组长以上确认
  → 写进产品规则文件，带上「环节：编导✗ 制作✗ 剪辑✓」
  → 下一条片子机审就认，不用改代码、不用重启

为什么要人确认：规则包是这套系统的命根子，机器写错一条，以后每一条片子都跟着错。

为什么用 Fable：跑过五个模型的选型测试，两套题（第二套故意把答案反过来，用来识别一味顺着说话的模型），Fable 最稳。详见那篇选型测试。

三、测试只覆盖一类东西：坏了不会被发现的

157 个自动化测试，Mac 和 Windows 都全绿。 纯标准库，跑一次 5 秒。

界面文案、按钮位置、上传能不能成——这些不测，坏了一眼就看见。

这个标准是有代价才定下来的。测试真正抓出来的问题，全都是没有任何外在症状的：

每一条的右列都是同一个句式：看起来是对的。 这就是该测的东西的定义。

四、经过两轮外部代码审查

外审报了 4 个 P1 + 4 个 P2，第二轮又报 4 条，全部修完。

其中一条是功能一直调不通的真凶：建产品上传缺 raw_body 标记，几百 MB 的请求体被当 JSON 读进内存。

有一条外审意见我没接受：「文件内容含边界串被截断」。boundary 全局唯一是 multipart 协议约定，由发送方保证；解析侧要防就得先读完整个请求体，几百 MB 视频全进内存，流式就没意义了。代码注释里写了原因，测试也钉住了这个行为。

修完外审那八条之后，我又自己把整套代码过了一遍，抓出两个外审没提的（就是上表里的 check_spec 和时长上限）。

五、上线后第一轮改动：堵住两类已确诊的误报

交付当天就做了一轮，重点全在准确度。

两条误报都是真实出现过的，共同点是模型先自己补出一个前提，再据此判违规：

规则文档里的「不报」字段挡不住

实测同一次审核里，模型一边写着「逐字稿是语音转写、同音字不可信，不作为错别字依据」，一边照报不误。

要它交引文也挡不住

改提示词要求「报画面文字有误时必须抄出画面原文」之后，只给它 0~6 秒的帧，它照样报 61 秒的字幕错别字——quote 里填的那四个字是从逐字稿抄的。

真正管用的是代码约束

1. 报出的秒数必须落在这一批送去的帧上（差 1.5 秒以上直接丢弃）。这一批给了哪些帧，代码是知道的，模型绕不过去。
2. 说画面文字有误要交画面原文、跨时间点比对要说明凭什么是同一段——当第二道。

这条经验可以推广：提示词约束的是模型的意愿，代码约束的是模型的能力。 涉及事实边界的地方，只有后者可靠。

顺带修掉一个会让上面全白干的坑：缓存指纹只按规则内容算，改了提示词但规则没动会全量命中旧缓存，新规矩等于没上，界面上还显示审过了。指纹现在掺上提示词。

六、接口参数实测

原来只核过 thinking。同一批帧、同一份规则、同一段提示词：

别对外承诺「同一条片子重跑结论必然一样」——模型侧本身有抖动，参数只能压小，压不掉。

上下文缓存也查过了，结论是代码不用改：隐式前缀缓存自动生效，第二条片子起每批稳定命中 25.7%。上限就是这么多，因为 70% 的 token 是帧图，永远不可缓存。「先热身再并发」实测无效，别再试。

七、三天里踩过、值得记住的坑

跨平台

• os.replace 在 Windows 上不是无条件原子的——Mac 0 次失败，Windows 221 次
• 测试里写死 python3，Windows 上没这个名字，整个测试类静默不跑
• Python 3.8 起扩展模块加载 DLL 不再搜 PATH，只认 os.add_dll_directory

运维

• Windows 的 OpenSSH 会话结束会连整个作业对象一起收掉，服务必须走计划任务
• 按映像名杀 python 进程，会把变音器的模型服务一起带走
• 服务跑在 SYSTEM 会话，读不到登录用户注册表里的代理设置——规则维护模型因此上线以来一次没调通过，界面上完全看不出来

我自己的

• 分步耗时表按每秒采样凑出来的，纯属编造，被一眼看穿
• 把「我的改动没写进去」误判成「被别的会话回退了」，查 git reflog 才确认没有
• 汇报「规则包重构完成」，实际 7 份文档只改了 4 份
• 说「Windows 转写快 2.3 倍」，实测是 1.97 倍

最后这几条的共同点是同一个毛病：没验证就下结论。 所以交接文档里专门加了一节，写清楚数据怎么流的，并留了一句：别凭「文档里没写」就断定某个功能没做。

八、硬件：为什么放 Windows

那台机器有 RTX 5060 Ti。同一条 79.3 秒的片子、同一个模型，转写 Mac 43.2 秒、Windows 21.9 秒——快 1.97 倍，转写结果逐字一致。

九、明确没做 / 没验证的

不列在这里的，都是做完并验证过的。

十、下一步该盯什么

首期交付到这儿。真正开始用之后，最该盯的是这三个数：

1. 成员自审页里「没看的」那一列——报了不看，等于白审
2. 周报里误报率高的规则——那些是最该回头改表述的
3. 规则草案的积压——回传上来没人确认，规则就不会进化

三个数指向同一件事：这套系统的价值不在交付那天，在于它有没有真的被用起来、有没有真的在进化。