送达真伪校验
HTTP 200 + success:true 不等于送达——传输成功和业务送达是两回事。真校验要看回执里的业务状态码，不看 HTTP 层。
抖音获客
与短视频产线
从公开评论里找到高意向客户，人审后真的发出去；再把成交话术做成门店自己的口播视频。
// 本文为公开版，具体标识已替换为占位符，成本数字改为相对倍数 · 架构与数据流口径 · 不含凭据、客户数据与门店身份
NEXT.JS · VERCEL
POSTGRES · RLS 多租户
FASTAPI · PYTHON
线索识别 WORKER
分通道 LLM 路由
69 CRONS
LANGFUSE 全链路记账
0
条定时任务串起主链路
无常驻队列服务
0
条触达通道共用一套派单原语
0
步内容快车道全程只调一次大模型
0×
老线单条均摊成本是快车道的倍数31.6 秒 · 6 分钟出片
SCROLL / 向下滚动
01
Two Lines, One Source of Truth
获客线与内容线，只在库里相遇
获客线管「把人找来」，内容线管「把人喂住」。两条线不互相调用，全部经同一个数据库交接。
Line A◈ 获客
抖音获客与线索生产
评论 → 意向分 → 草稿 → 人审 → 合规通道发出
对公开评论做评论线索识别，把「看起来像要装修的人」变成一条带上下文的线索，交给销售。
Next.js · Postgres · Python worker
Line B✦ 内容
门店口播短视频产线
选题 → 出稿 → 配音 → 对口型 → 字幕 → 终审
用门店自己的出镜人做 40 秒口播。素材来自获客线沉淀的真实问题，成片回到抖音继续拉评论。
确定性流水线 · 单次 LLM 出稿
Shared▲ 数据库
唯一事实源
315 个迁移文件 · 行级安全
schema 全在迁移文件里，多品牌靠 Postgres 行级安全（RLS）硬隔离，不在应用层写 WHERE 兜底。
全组织唯一 DDL 来源
Design
两条线唯一的耦合点是库。任一条停机，另一条照跑——这是能分开交付、分开谈合作的前提。
02
Lead Pipeline · Comment to Conversation
一条评论怎么变成一条线索
六段，段间靠表 ＋ 状态机交接，天然可重试、可断点续。
CRON
入队 定时任务按数据源生成识别作业，落作业表
入队 定时任务按数据源生成识别作业，落作业表
WORKER
识别 worker 认领作业 → 读取公开评论数据 → 落线索库
识别 worker 认领作业 → 读取公开评论数据 → 落线索库
LLM
打分拟稿 给评论打购买意向分；高意向自动生成一条触达草稿，状态
打分拟稿 给评论打购买意向分；高意向自动生成一条触达草稿，状态
pending_approval
HUMAN
审批 运营逐条审，改或放行 → 队列行翻
审批 运营逐条审，改或放行 → 队列行翻
approved。没审过的一条都发不出去
执行端
发送 执行端认领
发送 执行端认领
approved → 通过合规渠道触达，与人工协同把消息发出去
回执
校验 校验回执断言真实送达；回复轮询写回库，成为下一轮的上下文
校验 校验回执断言真实送达；回复轮询写回库，成为下一轮的上下文
// 关键设计：每一棒都落库再交接——任何一段崩了都能从库里的状态捡起来重跑，不重发、不丢单。
03
Division of Labour
哪一步是机器干的，哪一步是人
机器负责识别与起草，人负责放行，执行端负责真的发出去。三行分开画，是因为这三件事失败的方式完全不同。
人机交接图 · 获客主链路
行 = 角色 · 列 = 阶段 · 序号即阅读顺序
识别
判定
审批
触达
机器
自动
自动
01定时入队 ＋ 评论线索识别
02意向打分 ＋ 起草话术
06回执校验与回复轮询写回库
运营
人工
人工
03逐条审：改一改，或放行
执行端
通道
通道
04–05认领队列 → 经合规通道发出
// 序号跨行跳 = 一次交接：02→03 机器交人，03→04 人交执行端。
// 审批那一格永远是人的——把它去掉，整条线就变成群发。
04
Execution Boundary · The Hard Part
发出去，不等于送到了
Constraint
「发」这件事通过合规的官方通道与人工协同完成，服务端只负责派单、记账和校验，不直接对外发消息。系统的大部分复杂度都来自这条边界——以及怎么证明消息真的送到了。
四条触达通道
首次触达 · 评论回复 · 二次跟进 · 企微接待。共用同一套派单原语，节奏与频控各自独立。
对接方最该知道的一条
这套系统里最贵的不是模型，是「真的送到了没有」。任何号称打通触达的方案，先问它拿什么证明送达——HTTP 200 是最容易造出来的假绿灯。
05
Content Line · Why We Rebuilt the Pipeline
重型产线是手段，不是需求
老产线按多段分析 ＋ 多轮校验设计，链路长、闸门多。而门店真正要的只是本店出镜人 ＋ 一个选题 ＋ 一条 40 秒口播。
单条成片成本对比（相对倍数）
以快车道单条成本为 1× · 实测口径 2026-08-15 首条真单
// 更要紧的不是均价：老线在两天窗口内连续 10 单全部失败、成片 0 条——那段时间的钱全花在没交付的片子上。
ROOT三类结构性死因
- 语义闸一票否决：稿件没过闸，产线停在原地等人重写
- 闸开在付过钱之后：配音已扣费，才被语速判定整单失败
- 重排撞同一个操作 id，两次重试死在同一步
- 失败面来自老线的设计前提本身，不是某个 bug
CUT砍掉了什么
- 多段预处理与转写
- 镜头分析与一致性判定
- 多轮语义闸门
- 14 节点编排器（保留为逃生开关）
KEEP留下了什么
- 本店出镜人的真人底片
- 门店知识出稿（接企业大脑）
- 成片质检与出镜授权
- 店长终审后才发布
06
Express Line · Deterministic by Design
五步纯确定性，全程只调一次模型
模型只做它擅长的那一件事——写稿。其余每一步都是可复现、可重试、可对账的确定性流程。
01 · LLM出稿唯一一次模型调用，字数窗上下不对称
02 · TTS配音授权音色，按千字计价
03 · FFMPEG排画面真人底片 ＋ B-roll 兜底
04 · LIPSYNC对口型按分钟计价，全线最大单项成本
05 · 交付烧字幕 → 终审状态转待审，店长看过才发布
// 段色 = 角色色：蓝 = 服务端 · 青 = 确定性步骤 · 紫 = 付费外部服务 · 琥珀 = 人在环
付费幂等：id 由输入推导
操作 id ＝ sha256(输入绑定)，不是重试计数。换输入不换 id 会冲突，换 id 不换输入会重复付费。暂存签名链接必须落盘复用——重签一条新链接就是一次新付费。
只重试连接层，不重试 4xx/5xx
首条真单死在读到一半断线——那个异常不是超时异常的子类，一次网络抖动把整单送进失败终态。现在连接层抖动才退避重试，业务错误直接终止。
字数窗故意做成不对称
对称窗把三份好稿子全打回，走了兜底稿——是尺子画错了，不是稿子写坏了。写短了只是片子短一点、口型费还更便宜；写长了才线性烧钱。
正文碎片不许走到成片
模型在末尾多塞两条两字碎片，当时判据只查「非空」，于是配音念出两声孤零零的词、字幕还和片尾叠在一起。现在出稿层与时间轴层各一道闸。
四个坑的共同点
它们都不报错。产线绿灯、退出码 0、文件体积正常，只有人把片子看完才发现不对。所以质量只能靠生成端的断言，不能靠消费端抽查。
07
Stack & Interfaces
一页看全用了什么
| 层 | 技术 | 说明 / 口径 |
|---|---|---|
| 前端 / API | Next.js 16 · React 19 · TypeScript | 后台 UI ＋ 薄 API ＋ 定时任务触发器 |
| 数据库 | Supabase Postgres（RLS 多租户） | 315 个迁移文件 · 全组织唯一 DDL 来源 |
| Worker | Python · FastAPI | 线索识别 / 解析 |
| LLM 接入 | OpenRouter · 分通道路由 | 对话 / 分析分通道选型，环境变量覆盖，一行回滚 |
| · 对话 | Qwen3 235B 档（中国开源权重） | 开场白 / 养客对话 / 人设 |
| · 分析 | DeepSeek Flash 档 | 意向打分 / 决策信号 / 阶段分类 |
| 视频产线 | 确定性 runner · ffmpeg · 外部 TTS / Lipsync | 五步 · 单次 LLM · 付费幂等由输入哈希绑定 |
| 执行端 | 合规官方通道 · 人工协同 | 服务端只派单与校验，不直接对外发消息 |
| 可观测 | Langfuse trace ＋ 成本回填 | 上游返成本 0 时用本地定价表回算，可按人 / 按任务追账 |
| 调度 / CI | 平台 Cron ＋ GitHub Actions | 69 条定时任务 · 44 条工作流 · 高危路径强制走 PR |
一句话总括：获客线用评论线索识别 ＋ 打分把公开评论变成带上下文的线索，人审之后经合规通道发出并验证送达；内容线用一次模型调用 ＋ 四步确定性流程把门店知识做成本店出镜人的口播片。两条线的难点都不在模型，在边界——一边是送达验证，一边是不报错的坏。