跨 三个代码仓、两朵云、四家模型供应商，每天凌晨自动跑，人只剩「审片」一件事。 这页先讲清楚为什么这样选、什么情况走哪条路、每一步凭什么放行，再展开谁在跑、坏了长什么样、去哪查、改哪里。
三仓复核 2026-08-26
Akke 线上 @45dc69e
store-workbench 线上 @6c22f47
Workflow main @e60d666
快照 · 非实时看板
下面继续把“代码里有什么”“设计上推荐什么”“真单实际走了什么”分开。2026-08-26 最新 33 秒真单留下了快车道六步、3 格真实素材、0 格 H3 的运行日志；这能证明这条单走了新路径，但不能反推所有门店的运行时 env 都相同。
PRODUCER_ENGINE 的运行时值仍未直接读取，不把单条行为证据夸成所有任务的默认配置。
prod 45dc69evideo-material-digestmaterial-feed/api/status 实测顶层、Vercel、Worker、Supabase 全部健康prod=main 6c22f47auto-submitrunner/daemon.pyrunner/express/main e60d666video-worker fb81e82*pipeline/orchestrator.pyscripts/broll-library/deploy-broll-harvester.yml* worker SHA 是上次可验证值，不能拿 main SHA冒充已重部署适合：稳定日更、门店批量出片、主题相似但不要求逐镜复刻。
逻辑：一次写稿 → 一次配音 → 规则排画面 → 只给主播格对口型 → ffmpeg 合成。
为什么选：约 6 分钟/条，调用面窄，失败可按步骤重做；成本几乎只随主播秒数变化。
适合：用户明确给出参考视频，并要求复刻结构、节奏或镜头组织。
代价：14 节点、需要多轮看图与工具调用，链更长，任何弱模型或输入缺失都可能整单失败。
边界：返修不得自动掉回老线；否则快车道修过的 B-roll 规则会全部失效。是否现为线上默认：没验成。
方案1：先查已审核真实素材；工序、主体、动作和安全闸都通过才用。
方案2：后台每天 02:00 从明确授权来源补库；生产任务不在现场等采集。
方案3：前两层没货时，最多补 1 格 H3；参考图和动作都来自当前任务原素材。
最终兜底：任一层没验成或预算不足，直接回主播镜，整条继续完成。
触发：必须先有真实 B-roll 缺口，且方案1/2都没有合格匹配。
代价：H3 固定生成 5 秒，5 × $0.225 = $1.125；整条最多 1 格。
选择原则：真实素材优先；没有才生成；生成失败回主播。不是“先退主播、最后才生成”。
EXPRESS_SCRIPT_MODEL输入：昨日视频与评论
产物：有版本号的选题台账
闸：四项分数齐全
输入：选题 + 品牌约束
产物：口播句 + 画面话
闸：结构、禁词、时长可用
输入：最终口播
产物：音频 + 真实时长
闸：可播、时长不过线
输入：画面话 + 素材标签
产物：A/B-roll 时间轴
闸：工序、动作、覆盖率
输入：主播格 + 音频
产物：口型片段、字幕、成片
闸：时长、帧数、黑帧
输入：成片 + 逐句声画表
产物：交付 / 定点返修
闸：人批准后才入发布队列
先讲业务结果，再讲系统分工；先讲正常路径，再讲异常怎么兜。下面每格就是一段讲稿提纲。
系统不是为了“自动做视频”，而是把同行爆款变成本店能用、能审、能追账的短视频。
Akke 管数据和选题；Store 管任务、快车道和审片；Workflow 管老线、素材库、收割机与工厂镜像。
抓视频评论 → 打分 → 挑选题 → 自动提单 → 唤醒机器 → 六步出片 → 人审 → 国内云电脑发布。
写稿 → 配音定尺 → 排画面 → 只给主播格对口型 → ffmpeg 合成 → 待审交付。
方案1真实库存 → 方案2夜间补库 → 方案3原素材参考生成 → 主播兜底。
方案1边际 API $0；方案2是后台机时/VL/存储；方案3一格 $1.125；主播口型约 $0.0833/秒。
33 秒成片用了 3 格真实素材、0 格 H3；总体对题，地砖/墙砖仍有轻微偏差。
先真实、后生成、再主播；任何增强失败都不能拖垮主流程；最终效果必须看成片，不看开关名。
这十个词在下面反复出现。看不懂它们，后面每张图都会卡住。
真人对着镜头说话的那几秒。嘴型是花钱对出来的（$5/分钟）。
声音继续，画面换成素材库里的施工镜头。不花口型钱，但可能配错。
成片被切成的一段一段，每段几秒。要么是主播格，要么是素材格。
写稿时给每句配的一句「这一句该看到什么」，只拿去素材库搜画面，不念出来。
素材被标成九类之一（拆除/水电/贴砖/腻子/油漆/美缝/木工/墙纸/柜类）。
工厂机领走一条任务时拿的号牌。付了钱的记录挂在号牌上，手工改库会把它弄坏。
干活的机器每 60 秒报一次「我还活着」。5 分钟没动静判死。活着 ≠ 在干活。
现在这条产线：六步，全程只调一次大模型。2026-08-15 上线。
上一代产线：14 个节点，为「复刻爆款」设计。B-roll 是另一套实现。
Fly 上做片子的那台机器。没活时自动停机——停着不是故障。
Akke 仓 管数据 · store-workbench 仓 管屏、调度与快车道 · Workflow 仓 / 外部服务 管老线、素材库与工厂机镜像。颜色下面全篇通用。
号源账号的新视频、视频下的评论。
判断这条评论是不是真有装修意向、是不是在要资料。
昨日新入库的视频里按统一分排序，推飞书卡 + 落台账。
把榜上前几条变成制作任务，一天目标 3 条。
有活就把停着的机器 start 起来。
出稿→配音→排画面→对口型→烧字幕→交付。
从头看一遍。只有人能点「交付」。
批准后由国内那台云电脑按时间发。
这一节是理解所有画面类故障的支点。文档此前漏了它。
上一节说了「画面对不上」只发生在素材格。这一节把素材格背后那座库掀开：一段镜头进库要盖哪些标签、生产如何按方案1/2/3递进，以及方案2现在怎样补库。大盘数字仍是 2026-08-24 的 broll-latest.db 历史快照；2026-08-26 首轮授权采集另列实测，不能混成同一时点。
一段 3–6 秒的镜头切出来后，会被盖上三组标签。三组各管一件事——语义决定「能不能配某句话」，安全决定「敢不敢用」，质量决定「清不清楚」。三关全过才进「可用池」。
stage 工序（贴砖/封边/柜体安装…）· subject 主体 · action 动作 · visible_elements 可见元素 · visual_fact 画面事实
另有机器视觉四列（最干净的检索词）：vl_subject · vl_action · vl_objects · vl_scene
has_face 有没有人脸 · has_text 有没有字幕 · has_brand 有没有品牌 · has_watermark 有没有水印
四个必须全为 0 才进可用池——别人视频里的脸、字、logo、水印一旦混进我们的成片，就是事故。
quality_sharpness 清晰度 · quality_stability 稳定度 · quality_lighting 光照 · narration_confidence 原声可信度
再加一个 needs_human：机器拿不准的，标出来等人复核。
clips / segments 两张表上。「可用」= approved=1 且安全四列全 0 且有 R2 文件——三个条件缺一不可。
TransNetV2 把长视频按镜头切成一段段。便宜、跑得快。
判 A/B 型、OCR 认出原字幕位置，为后面去字幕做准备。
把镜头切成 3–6 秒的可用镜头单元。
qwen3-vl-235b 逐段看画面，产出上面所有语义标签。整条线唯一按段计费的一步。
盖 has_face/text/brand/watermark 四个安全标签。
过关的传 R2、写进 segments，approved=1。
haystack）= 可见元素 + 动作 + 画面事实 + VL 四列 + 工序词表 + 主体词表，拼在一起做字面匹配。宁缺毋滥：任一道闸不过就退回主播镜，绝不硬配一个不对题的空镜（对应上一节第三条）。
codex-v6 同款 schema 逐段标。按干净生料 72% 的历史可用率估算，可能新增 约 8,000 个可用镜头；这是容量估算，不是已完成结果。成本会随切片数、VL 调用和重试变化，需用小批实付再决定全量，页面不再展示会快速过期的账户余额。feed_limit=10、source_limit=10。它只唤醒既有 Fly 收割机，不每晚重新部署；上一轮仍在运行就跳过，队列为空快速收工，完成后自动停机。GitHub 定时器已回读为 active，但高峰期可能延迟，不承诺 02:00:00 秒级准点。
src/lib/material-digest/unified-score.ts；改权重必须同时 bump 版本号，否则历史数据对不上账。
先分仓、再看模型：快车道写稿和老线生产大脑由 store runner 发起；Workflow 提供老线节点、素材 VL 与 fal 客户端；工作台里的分析/面客模型是另一组配置。表里的“默认”只代表代码回退值，env 是否覆盖要以运行时为准。
| 用在哪 | 模型 | 配在哪 | 换的时候要注意 |
|---|---|---|---|
| 出稿（快车道唯一一次调模型） | 默认 qwen/qwen3.7-flash | store · EXPRESS_SCRIPT_MODEL | env 可覆盖；要同步补价格表，否则大脑费记 null。线上值本轮没验成 |
| 老线的「大脑」 | qwen/qwen3.7-plus | store · daemon.py 常量 | 必须同步改三处，漏一处整条部署直接红 |
| 拆参考视频结构（第 06 屏） | deepseek/deepseek-v4-flash | LLM_ANALYSIS_MODEL | 推理模型，会先想再出 JSON，token 上限别给太小 |
| 面客文案：标题、5 个标签 | qwen/qwen3-235b-a22b-2507 | LLM_CHAT_MODEL | 与抖音私信通道同款，两仓刻意一致 |
| 看图：海报解析等 | qwen/qwen3-vl-32b-instruct | RECALL_CAMPAIGN_VISION_MODEL | 文案模型只接文字，喂图直接 404 |
| 配音 | fal · minimax/speech-02-hd | $0.10/千字 | — |
| 音色克隆 | fal · minimax/voice-clone | $1.50/次 | 登记出镜人时一次性，参考音频 ≥10 秒 |
| 对口型 | fal · sync-lipsync v2 pro | $5.00/分钟 | 最贵；标准档会嘴部涂抹，生产默认必须 pro |
| 方案3参考生成 | minimax h3 ref2v | $1.125 / 5秒 | 参考来自当前原素材；前两层未命中才调用；整条最多 1 格 |
| 日期 | 动作 | 为什么 |
|---|---|---|
| ～08-08 | kimi-k3 | 每条片大脑费约 $9，成本大头 |
| 08-09 | 换 deepseek-v4-flash | 同为 1M 窗口、同样支持工具调用，入价便宜 33 倍 |
| 08-10 | 换回 qwen 家 | v4-flash 不支持图像输入，而老线到处要看图，当晚首条真单就死在这。选模型时「能不能看图」和「窗口多大」同等重要 |
| 08-11 | 升到 qwen3.7-plus | flash 工具调用不稳。刻意只换档不换厂——好把「flash 太弱」和「qwen 不行」分开验 |
| 画面出口 | 什么时候花钱 | 当前可证明的单价 | 怎么控 |
|---|---|---|---|
| 方案1 · 库存命中 | 本地检索 + R2 读取 | 边际 API $0 | 命中的秒数不用做主播口型，约少花 $0.0833/秒 |
| 方案2 · 夜间补库 | Fly 运行机时 + VL 标注 + 存储 | VL 代码估算约 $0.0005/张；20GB 卷约 $3/月 | 10×10 上限、授权闸、去重、上一轮未完不并发、跑完自停 |
| 方案3 · H3 ref2v | 前两层无合格素材且存在关键缺口 | 5秒 × $0.225 = $1.125 | 整条最多 1 格；参考绑定幂等；预算不足不调用 |
| 主播兜底 | 该格需要做口型 | $5/分钟 ≈ $0.0833/秒 | 任何 B-roll 分支失败都能退回，不拖垮整条视频 |
每个字幕格只走到第一个成功出口，不是三个方案各收一遍钱。方案2每晚实付暂时不能给固定数：首轮没有留下独立的 OpenRouter 余额差值账，下面只写可以证明的单价与上限，不把估算冒充实付。
| 账 | 是什么 | 记在哪 | 受预算拦截吗 |
|---|---|---|---|
| 生成费 | fal 的配音 / 口型 / 生图 / 图生视频 | cost_usd | 是 超线 409 |
| 大脑费 | 模型自己想事情 + 审片闸门 | llm_cost_usd | 否 只记账 |
混成一本账的后果不是「数字大一点」：一单还没开始做画面，就先被自己的思考费打爆 $6 预算，然后连锁 409。
先看 2026-08-24 怎么定位根因，再看 2026-08-26 新三级递进上线后的第一条真单是否改善。两次证据连起来，才是完整验收。
alignment 来源记录又没有成功写回。因此能证明“真实素材池命中 3 段、方案3没调用”，但不能证明其中哪段来自旧库存、哪段来自当晚新补库。下一步必须把素材 asset_id / source / scheme 写入逐句声画表，才能按方案追账。
pick() 复现，不是推测。| 画面话 | 匹配分 | 实际配上的画面 |
|---|---|---|
| 板材封边收边 | 1.00 | 安装灯槽周边的吊顶板 |
| 柜门封边压实 | 0.67 | 电钻固定柜体顶部构件 |
| 抽屉滑轨安装 | 1.00 | 依次开合高柜柜门 |
| 橱柜台面安装 | 1.00 | 调整木纹柜体隔板 |
| 柜门把手安装 | 0.67 | 摆弄绿色线材和橙色小工具 |
满分不等于对题。「封边」这个动作有没有真的出现在画面里，判据里一个字都没查。
| 你看到的现象 | 第几站 | 怎么查 | 改哪个仓 |
|---|---|---|---|
| 选题列表空的 / 还是昨天的 | 1–3 | 直接 curl 那条 feed（不用钥匙）。有数据＝上游没断 | Akke |
| 今天一条都没自动提 | 4 | 体检 daily_submit。常见真因：僵尸单占满并行额度 | 看门狗 |
| 单子一直 queued | 5 | 工厂机没起来：看 n8n autoscaler、Fly 机器状态 | n8n |
| running 很久最后判死 | 6 | 逐单日志看死在哪步。心跳只证明进程活着，不等于在干活 | runner |
| 一批单子全失败 | 6 | 多半是同一个 bug。近例：写稿撞 429 一秒判死，占一周失败 71% | runner |
| 说的和画面不一样 | 6 · 排画面 | 先看审片页的逐句对照表，找出是哪一句、分多少 | express/broll |
| 片子后半黑屏但有人声 | 6 · 合成 | 容器时长 ≠ 视频轨时长，自检要同时查时长和帧数 | express/io |
| 出了片但大脑费是 0 | 记账 | 看 warnings 是空还是有话——「缺价格表」和「压根没查表」是两件事 | usage_meter |
| 成片堆着没人审 | 7 | 体检 review_backlog。最大的钱漏，不是技术故障 | 人 |
| 批准发布了但抖音上没有 | 8 | 发布由国内云电脑拉走（Fly 东京 IP 被抖音挡着），先确认那台机在线 | 发布队列 |
# 上游今天出没出选题？（不需要任何密钥，本机就能跑） curl -s "https://akke-material-upload.softieaiorg.workers.dev/api/feed?days=3" \ -H "X-Store-Code: demo-2026" -H "User-Agent: akke-workbench/1.0" | head -c 400 # 产线现状一把梭（钥匙从 fly secrets / GitHub secret 取，别手抄） curl -sS -H "X-Producer-Key: $WB_PRODUCER_KEY" \ "https://store-workbench.fly.dev/api/runner/pipeline-health?window_hours=720" \ | jq '{level, checks: [.checks[] | select(.level != "ok")], stuck}'
| 仓 | 负责 | 怎么上线 |
|---|---|---|
| Akke | 抓视频与评论、意向打分、每日选题、素材 feed | PR → 合 main → Vercel |
| store-workbench | 店长看得见的一切、提单/审核台/看板/队列，以及快车道出片步骤 | 只能走 CI：push main → CI 绿 → fly-deploy |
| Workflow | 老线 14 节点、共享 B-roll 库与向量检索、fal 客户端、工厂机镜像、n8n 工作流 | push main → CI → deploy-video-worker |
判据一句话：抓取打分与选题 feed → Akke；页面/队列/审片/发布与快车道 → store-workbench；老线节点/共享素材库/工厂机镜像 → Workflow。
“片子本身变了”还要再问一句：这单实际走的是 express 还是 orchestrator，两条线不在同一个仓。
三仓共用同一个 Supabase，DDL 一律回 Akke 提（唯一例外是 video_jobs 这张队列表）。