深入 · 落地力
流水线与成本真跑通过,并且算得清账
这一块证明两件事:我搭得出来并跑通了,以及我知道钱花在哪。
n8n 流水线的三个设计判断
| 判断 | 为什么 |
| 用飞书多维表格的状态字段当队列 | 三个工作流各管一段,独立失败、可单独开关;任何一段崩了不拖垮整条链路 |
| LLM 输出必须结构化 + 兜底 | 解析节点带 try/catch,解析失败不阻断整条链路 |
| 发布环节刻意不做全自动 | 批量秒发会触发平台风控——把平台约束当产品约束来设计,而不是当技术的偷懒 |
实测调用结构(逐节点核对,不是估算)
| 环节 | 每轮次数 | 输入 tokens | 输出 tokens |
| 选题生成 | 1 | 140 | ~400 |
| 脚本生成 | 5(每选题 1 次) | 183 | ~600 |
| 合计 | 6 次 | 1,055 | 3,400 |
16 个节点里只有 2 个调用模型;实测还发现三处与设计文档不一致(无评分重试节点、知识库原文未进 prompt、每选题恰好 1 次)。
两条链路的成本(实测单价 × 实测用量)
| 链路 | 成本主体 | 量级 |
| 选题与脚本(文字) | 模型 token | 单篇约 ¥0.0015,日更 10 篇月成本约 ¥0.5——可忽略 |
| 画面上成 | 生视频按次 | 720P/4 秒 = ¥1;49 秒成片 = 13 片段,单条下限 ¥13 |
结论:两条链路差三个数量级——文字侧几乎可忽略,成本压力全在画面上成。
而单价是平台给定的外部约束,唯一有效的杠杆是首次通过率。
已知局限
- WF2 / WF3 仍是节点规划,未产出 JSON(WF1 已跑通)
- 首次通过率、生成失败是否计费:均未实测,留空而不是估算
- 成片时长 49 秒由音频文件实测(原文件头采样率不可靠,已用文件大小反推校正)