面对每天2000条达人视频的审核压力，一套基于Dify和飞书多维表格的自动化系统应运而生。它不仅能识别主推套餐，还通过三套自动化协同，实现了批量处理、规则动态更新与结果自动反馈，将业务从繁琐的人工审核中解放出来。本文深入拆解了从需求分析到系统落地的全过程，展示了AI在真实业务场景中的高效应用。

第一次了解这个需求时，是别人做的半路需求流转过来的，业务跟我说的并不是“想做一套 AI 系统”，而是每天都在发生的具体问题：每天有2000条本地推达人视频需要审核，运营要逐条判断视频推广的是哪个品牌套餐。

我一开始理解成审核提效。2000条视频靠人逐条打开，听口播、看字幕、找价格和产品画面，工作量很大。如果AI能自动识别主推套餐，至少可以省下大量重复看片的时间。

但继续了解运营拿到结果后要做什么，我才发现“看片太慢”只是表面问题。识别出的套餐还要与视频的点赞量、转化金额对应起来，据此比较不同套餐的表现，再规划下一批达人重点推什么、哪些内容需要调整。

那么我要解决的事情已经不只是“让AI看完视频”。系统还要给出可追溯的判断，接住每天持续进入的任务，适应品牌套餐变化，并把处理结果交回运营。后来出现的失效视频、Prompt更新和批次通知，都是从这条业务链上长出来的问题。

这篇文章记录的，是我如何用Dify+飞书多维表格，把主推套餐识别需求逐步做成业务可以持续使用的自动化系统。实现“自动化识别视频主推品+自动更新产品规则+自动推送批次识别结果”。

从业务结果反推，AI 到底要交付什么

明确结果用途后，我开始重新看“识别主推套餐”这件事。品牌有自己的套餐资料，视频侧也有链接、发布时间等信息，缺的是把两边可靠连接起来的判断：这条视频具体推广了哪个套餐？

达人不会照着品牌提供的标准名称念套餐。有的人只说价格，有的人使用简称，有的人只拍包装，还有的人在同一条视频里带到多个产品。标题可能写着活动名，口播说的是价格，画面里出现的又是套餐组合。偶尔还会遇到视频被删除或链接过期，点进去什么也看不到。

这意味着AI不能看到一个价格就猜套餐，也不能只返回一个产品名。一次错误识别可能继续影响后面的统计结论。

我最终把单条结果确定为一组可以复核的信息：主推套餐、判断依据、置信度、是否需要人工复核、复核原因和失败原因。证据充分的结果进入后续统计；证据不足、多个套餐冲突或视频不可用的记录，则明确交给人工处理。

第一条视频跑通后，问题才刚刚开始

第一版并没有花太久。我用Dify串起视频链接解析、文件下载和多模态模型，让模型同时参考标题、口播、画面文字与价格信息，再从已有的品牌套餐中判断主推品。

单条测试结果不错。模型能够返回套餐名称，也能解释是从哪段口播、哪条字幕或哪个画面线索得出的判断。我当时觉得方向已经跑通，接下来无非是多处理一些视频。

准备给业务使用时，我才发现自己把需求想简单了。

单条视频可以手工放进工作流，但2000条视频怎么持续进入系统？其中一条链接失效，是让整次运行报错，还是只标记这一条失败？模型给出产品名以后，运营怎么判断这次结果是否可信？品牌下个月推出新套餐，是不是还要找我进入Dify修改Prompt？所有视频处理完以后，难道还要有人一直盯着飞书多维表格，手工统计还有多少条没结束？

这些都不是继续优化一段识别Prompt就能解决的问题。

我开始把飞书多维表格从“放输入和结果的表格”，改造成业务操作入口；Dify则负责在后台领取任务、处理视频和推进状态。运营只需要提交一个业务批次，系统自己把任务拆开执行，逐条写回结果，整批结束后再发通知。

2000条是业务规模，不应该变成一次工作流的负担

我没有让Dify在一次运行里硬扛2000条，也没有要求运营为了迁就系统，手工把任务拆成几十个小批次。

运营在飞书多维表格的“视频任务明细”中填写视频链接、待处理状态和批次编号。对业务来说，这些记录属于同一次提交，就是一个完整批次。Dify在后台分波领取：当前版本每波最多处理30条，并发执行10条；这一波结束后，下一次调度继续处理同一业务批次中剩余的视频。

这也是我在设计时坚持的一条边界：业务提交完整需求，系统自己消化内部限制。只有同一个业务批次里的记录全部进入成功或失败状态，这一批才算结束。

需要说明的是，业务每天约有 2000 条视频需要审核，不等于当前版本已经完成2000条/天的生产容量压测。现有系统采用跨波次持续处理的结构，但2000条容量、平台限流和长时间运行稳定性仍需要正式压力验证。业务规模和系统已经验证的性能，不能混为一谈。

一条视频失败，不应该拖住后面的1999条

最初遇到失效视频时，我下意识把它当成工作流异常：解析失败，就让节点报错。

但运营并不关心Dify后台抛出了什么错误。他看到的只是一条迟迟没有结果、甚至长时间停留在“处理中”的飞书多维表格记录。他不知道应该继续等，还是检查链接后重新提交。

后来我把失败也当成一种需要正式交付的业务结果。系统在解析阶段已经明确知道视频不存在、被删除或无法访问，就应该立即把该条记录写成失败，并留下业务能理解的原因，例如“视频已失效或无法访问，请检查视频链接后重新提交”。

一条失败也不能阻塞同批其他视频。每天约2000条任务中出现失效链接很正常，如果一个坏链接能让整个批次停下来，这套系统就没有实际使用价值。

于是，成功和失败都被设计为终态。单条视频处理结束后立即回写，其他任务继续运行；只有卡在中间、系统迟迟无法确认状态的记录，才交给超时机制回收。运营最终看到的不只是主推套餐，还包括判断依据、置信度、人工复核建议和失败原因。

这个设计看起来没有模型识别那么亮眼，却决定了业务是否敢一次提交一整批视频。

新套餐上线后，Prompt不能继续写死在工作流里

第一版Prompt直接写入了当时所有候选套餐。产品数量少、规则稳定时，这是最快的做法。交付时，业务问了一个很自然的问题：“下次上新套餐，是不是还要找你改工作流？”

如果答案是“对”，那这套自动化只是把人工从看片转移到了维护 Prompt。每次新品上市、价格调整或者套餐下架，都需要技术人员进入 Dify 改节点、重新发布。时间一长，业务也很难确认工作流使用的到底是哪一版套餐规则。

我后来在飞书多维表格中单独建立“产品套餐表”和“prompt版本表”。运营填写套餐名称、组合和价格，将状态改成待发布，再点击“发布本批次”。系统检查产品名、价格和必要格式，每次处理1到5个产品。校验通过后，自动更新当前候选品规则并生成新的完整Prompt；校验失败则保留上一版，不影响视频分析继续运行。

这里我没有让AI每次重新生成整份Prompt，而是把它拆成两部分：

完整prompt=主推品变量章节+固定章节

业务上新只更新变量章节。判断原则、特殊分类和输出结构属于固定合同，不允许在产品发布时被顺手改写。为了避免飞书多维表格中的规则读取异常导致视频分析停摆，Dify中还保留了一份经过验证的静态版本作为回退。

产品资料怎样维护，终于从Dify节点配置中拿了出来，回到业务可以操作的位置。

三套自动化，组成了一条完整业务链

做到这里，系统已经不再是一条从左到右的工作流，而是三套彼此配合的自动化。

第一套负责批量分析视频。运营在飞书多维表格提交视频批次，Dify定时领取任务，解析并下载视频，提取标题、口播和画面证据，读取当前Prompt判断主推品，再把成功或失败结果逐条写回。

第二套负责维护套餐规则。运营在飞书多维表格录入并发布新品，由多维表格自动化校验资料、生成候选品规则、更新当前Prompt，并保留版本快照。

第三套负责反馈批次结果。Dify持续统计同一批次的待处理、处理中、成功和失败数量，整批进入终态后，向飞书外部群发送完成通知，并把通知状态写回多维表格。

套餐发布自动化与视频分析自动化通过“当前已发布Prompt”连接。新品发布不会让已经成功的视频重新分析，只影响后续尚未开始的处理波次。每一波在进入视频迭代前读取一次规则，让同一波视频使用同一份判断标准。

完整业务架构如下：

架构图里有不少模块，但业务人员日常只需要做两类操作：在飞书多维表格提交视频；有新套餐时发布产品资料。任务领取、识别、状态写回、规则读取和完成通知都由系统处理。

具体搭建时，我用了哪些表、字段和节点

下面拆解一下我做三套自动化的核心配置。

1. Dify：视频批量分析自动化

这套自动化的任务入口是飞书多维表格中的“视频任务明细”。业务主要填写三个字段：“视频链接”、“处理状态”、“批次编号”；其余字段由Dify写回。

结果字段包括：“主推品”、“判断依据”、“置信度”、“是否人工审核”、“复合原因”、“失败原因”。为了追踪任务状态，我还增加“开始时间”、“完成时间”与“通知状态”。

Dify中最关键的节点可以分成四段：

1. 任务调度：定时触发器、查询活动批次、查询本波待处理任务、筛选最多30条记录。
2. 逐条执行：迭代节点并发10，先把记录标记“处理中”，再进入单视频处理链。
3. 视频分析：视频链接解析、视频下载、文件提取、多模态内容证据提取、主推品识别、结果字段校验。
4. 状态写回：成功分支写回完整识别结果；解析、下载或模型异常进入失败聚合，再写回失败原因和完成时间。其中，迭代节点使用单条失败不终止整批的错误策略。否则一条失效链接就可能让后面的任务全部拿不到结果。

2. 飞书多维表格：套餐新增与Prompt发布更新自动化

这套自动化主要使用两张表。

• “套餐明细表”保存业务事实，关键字段“套餐内容明细”、“套餐价格”、“状态”和按钮字段“发布本批次”。
• “prompt版本表”保存“规则编码”、“规则版本”、“当前候选品章节”、“固定后缀”、“完整 prompt”和“发布状态”。

运营点发布后，飞书多维表格自动化依次执行：检查是否已有发布中的批次、查找全部待发布产品、判断数量是否为1到5条、将本批产品标记为发布中、生成本批产品规则块、再次校验名称和价格等事实。只有结构与语义校验都通过，才创建版本快照并更新一次，失败则保留上一版 Prompt，并把本批产品标记为发布失败。

这部分是截图中看到的多维表格自动化。它承担的不是简单拼接文本，而是把并发发布、批次数量、重复产品、资料缺失和版本回滚都挡在正式Prompt之外。

3. Dify：批次完成通知自动化

最开始设计任务完成通知时，我想直接使用飞书多维表格机器人。但实际操作时发现，业务使用的是飞书外部群，而外部群无法添加多维表格机器人，这条方案走不通。

最后我把通知放回Dify：在飞书外部群添加群机器人，将Webhook作为Dify的环境变量保存。工作流在每波处理结束后查询当前批次的“待处理”、“处理中”、“成功”、“失败”和总数；只有待处理与处理中都归零，并且成功数加失败数等于总数，才进入通知节点。

关键节点包括：统计批次五类数量、判断批次是否终态、HTTP请求发送飞书外部群消息、校验 HTTP与飞书响应、最后写回结果。通知内容只保留业务最关心的信息：批次编号、总数、成功数和失败数。

为什么一定要做批次完成通知

在当前测试中，10条视频完成核心解析大约需要40-50秒。但2000条不是把10条任务简单复制 200次：实际运行还包含视频下载、模型分析、分波调度、平台排队和飞书多维表格写回。把这些开销算进去，完整批次预计需要约4-5个小时。

这么长的处理时间里，业务不可能时刻记着打开飞书多维表格看一眼，也不应该靠人工反复刷新来判断任务是否结束。因此，批次完成通知不是一个锦上添花的消息功能，而是异步处理链路中必要的结果反馈。

整批视频完成后，系统会统计这个批次的待处理、处理中、成功、失败和总数。只有待处理与处理中都归零，并且成功数加失败数等于总数，才向固定飞书外部群发送完成消息。运营只需要知道哪个批次已经完成、总共处理多少条、成功多少条、失败多少条。收到消息后，再进入飞书多维表格查看详细结果和需要人工复核的记录，不必守着表格反复刷新。

为了让系统知道“整批已经结束”，我没有新增一套复杂的进度字段，而是在发送通知时即时统计当前批次。只要还有一条待处理或处理中记录，就继续等待；当所有记录都进入成功或失败，系统再汇总数量并发送消息。

通知成功后，批次状态会被标记为已通知；如果发送失败，只重新处理通知，不会重新分析已经完成的视频。这样，视频处理和消息发送彼此分开，通知异常不会改动已经产生的分析结果。

识别完成后，数据才开始产生新的价值

系统最终增加的并不是一列孤立的“主推品”，而是一项可以参与后续分析的标准化标签。有了它，业务才有机会把原本分散的信息放在一起看：

主推套餐+视频数量+点赞量+转化金额

例如，一个套餐可能获得了较高点赞量，却没有带来相应转化；另一个套餐互动表现普通，但转化金额更稳定。前者可能需要调整内容表达，后者则可能值得在下一批视频中提高推广占比。新品被多少达人提及、哪些套餐经常被混淆，也有了进一步分析的基础。

主推品识别不会替业务做完决策，它补的是最依赖人工、也最难规模化的标签。当前工作流负责生成可追溯的主推品结果，为点赞量和转化金额按套餐归因提供基础；下游汇总和看板展示仍可继续在飞书多维表格中完成，我没有把它写成当前视频工作流已经自动实现的能力。

现在，运营的操作被压缩为两类：在飞书多维表格提交视频，等待完成通知并处理复核项；品牌套餐变化时，在产品套餐表录入资料并发布，让后续视频读取新规则。

写在最后

做这个项目之前，我理解的自动化，是让AI替人完成更多步骤。做下来以后，我发现最费时间的部分都发生在模型给出答案之后：答案怎样进入飞书多维表格，打不开的视频怎样解释，一条失败会不会拖住整批，套餐变化后谁来维护规则，以及2000条视频什么时候才算全部结束。

模型负责判断视频可能在推广什么套餐，系统负责把这个判断变成业务能够继续使用的结果。

当每条视频都能对应具体套餐，点赞量和转化金额才有了新的组织方式。运营关注的不再是“这条视频表现怎么样”，而是“什么套餐值得推、什么内容需要调整、下一批资源应该投向哪”。

AI替人看完视频只是起点。识别结果能够进入下一次推广决策，这条链路才有业务价值。