从经验写稿到稳定量产：FDE用AI重构本地生活短视频内容生产

访谈资料整理：依据 Datawhale《FDE案例100》所收录访谈。案例叙述与成果均归属于原访谈，本站未进行独立项目审计。

原案例封面

为什么这个案例值得看？

一家抖音本地生活代运营公司在业务高峰期每天需要产出约 200—300 条短视频文案或脚本，质量和数量高度依赖少数资深运营。项目将优秀运营人员的写作经验拆解成 AI 工作流，由 AI 承担规模化生成、人工负责审核，让内容生产更稳定。

这个案例的价值不只在于采用了某种模型，而在于把数据、规则、系统和人工责任连接成可执行的业务链路。落地过程围绕问题识别、方案选择、交付路径、业务结果和关键难点展开。

一、企业与业务场景

FDE接触到这家公司时，他们做的是抖音本地生活代运营，自己的客户以餐饮商户为主，而且覆盖多个城市，所以内容需求的量非常大。

最直观的问题就是：每天要写很多文案，而且还不能写得太差。

他们内部其实不缺会写的人。

有一些运营人员凭经验，确实能够写出质量不错的短视频文案。

但问题在于，这些人的能力很难被规模化复制。

一个人可能写得很好，却不可能一个人每天稳定处理几十甚至上百条内容。

到了业务规模上来以后，就会变成一个很现实的矛盾：好的内容靠人，规模化生产又离不开人，但人本身就是瓶颈。

当时他们最高峰的时候，一天需要产生两三百条文案。

所以他们最开始找FDE的时候，提出的问题其实很朴素：有没有可能用AI，把这件事情接起来？

但FDE真正开始介入之后发现，问题并不只是“写不够快”。

本地生活内容有一个很特殊的地方：不同商户之间差异很大。

可能都是餐饮，有的是高端酒店，有的是连锁餐厅，有的是独立的小店；不同门店的主打菜品、活动、老板表达方式、目标客群都不一样，通用模型按固定模板生成，很难照顾到这种差异。

随后，FDE判断，与其把大量成本放在模型和本地部署上，不如先解决真正影响结果的事情：业务流程到底怎么拆、哪些经验应该交给AI、哪些地方必须保留人的判断，以及如何让AI的输出稳定地贴近这个团队自己的内容标准。

这也是FDE作为FDE最先关注的地方。

FDE可以从客户每天真实发生的工作开始，看哪些事情适合让AI承担。

二、原有流程与核心问题

他们过去主要依靠运营人员的经验来完成内容生产。

有人负责文案，有人负责拍摄，有人负责剪辑，再由团队负责人进行协调和审核。

对于客户数量还没有这么多的时候，这种方式是完全能够运行的。

因为人有一个优势：遇到不同的商家、不同的菜品和不同的情况，人可以根据经验临时判断。

比如一个运营人员长期服务餐饮客户，他可能知道什么样的老板适合什么表达方式，也知道什么样的菜品应该突出什么卖点。

这些东西很多时候就存在于人的脑子里，没有被沉淀成标准化的文档。

所以过去的流程本身没有错，问题在于：规模一上来以后，过去依赖人的经验就很难继续放大。

他们后来也尝试过直接让AI写，包括本地部署DeepSeek，但效果并没有达到预期。

简单地把历史文案、写作范式交给模型，并不能解决问题。

随后，FDE在项目里发现，AI味其实很大程度上来自一种“固定范式”：给AI一套固定模板，让它不断模仿。

这样做在单个案例里可能有效，但当面对不同商户、不同题材、不同场景时，就容易机械地重复。

所以FDE把“人工写 → AI写”这种简单替换放到一边，开始重新看整个内容生产流程。

三、AI 解决方案与交付路径

FDE做FDE规划的阶段有一个比较明确的习惯：先假设AI能做，再通过实际测试把它做不到或者做不好的部分逐渐交还给人。

需要先把客户原来的结果拿出来，再用AI跑一个小Demo，把两个结果放在一起比较。

如果AI的结果已经可以达到一定水平，就继续往下走；如果某一个环节不稳定，再判断这个环节应该怎么调整，或者最终保留人工。

这个项目大致经历了几个阶段。

第一阶段：先把业务真正看懂最开始，FDE和老板以及团队核心成员面对面沟通。

但真正重要的工作其实发生在后面。

因为如果只听客户说“企业每天要写很多文案”，FDE需要到的信息远远不够。

FDE需要知道他们每天具体怎么工作：谁负责什么、一个新客户进来之后怎么开始、什么信息需要提前准备、运营人员怎么判断一条文案好不好、什么情况下需要修改，以及遇到不同商户时哪些地方会变化。

所以前期FDE可以和他们进行现场沟通，观察他们实际的工作流程，把原来比较依赖人的工作方式逐渐沉淀下来。

这一步从项目实践看特别重要。

因为很多中小企业的问题，归根结底是原本的业务流程本身就没有被很好地数字化和结构化。

如果这一步不解决，直接把历史资料扔给AI，其实并不能真正落地。

第二阶段：把人的经验拆成AI能理解的业务字段接下来，FDE开始把他们原来的经验拆出来。

不同商户虽然文案风格不同，但底层需要关注的东西其实比较接近，比如客户是谁、门店是什么类型、主推什么菜品、有什么活动、希望突出什么卖点，以及最终希望呈现什么样的内容方向。

所以项目团队把这些信息变成相对明确的输入字段。

这一步实际上是在做一件事：把一个优秀运营人员脑子里的经验，变成可以被系统调用的业务逻辑。

同时，项目团队也把客户团队里优秀文案人员的写作方式、技巧和参考案例融入工作流。

第三阶段：从“AI写手”到一条生产流程真正落地的时候，FDE发现单纯一个Prompt或一个Skill是不够的。

因为“写出一篇文案”和“稳定地生产可以使用的短视频脚本”其实是两回事。

所以项目团队把提示词、Skill、业务参数以及校验、审计等Loop机制组合起来，让AI进入一套更完整的内容生产流程。

可以把它理解成：把AI放进员工原来的业务流程里。

最终这一期项目主要落在文案和脚本生产节点上。

这里的“文案”还要考虑到后续真正拍摄时的节奏、声画配合等因素，最终形成可以直接拿去使用的脚本框架。

第四阶段：让AI先跑，人负责判断FDE不会追求整个流程百分之百自动化。

项目的核心逻辑是，AI更像一个能力不同于人的同事。

它特别擅长大规模处理、生成和适配，但在一些需要判断、审美、经验和最终决策的地方，人仍然非常重要。

所以实际流程里，AI负责大部分标准化工作，人负责最后的审核和判断。

如果某一个节点AI做得不好，就把这个节点重新交还给人。

这其实就是FDE所说的“回退机制”。

第五阶段：持续用真实反馈调优真正花时间的地方，其实是后面的调优。

FDE可以周期性给客户提供不同版本，让他们结合平台的数据反馈查看。

如果团队觉得“这个味道不对”，平台数据显示某个时间段留存下滑，或者某些客户、某些SKU下效果不稳定，就把这些反馈带回来继续调整。

这里面可能调整的是提示词，也可能是系统逻辑顺序、关注点，甚至模型选型。

因为文案这件事情很像“语感”，它很难一开始就被定义成一套绝对标准。

所以真正的效果往往来自大量的反馈、比较和迭代。

四、项目结果与业务价值

从客户的使用反馈来看，效果非常明显。

首先是内容生产效率提高了。

原来大量工作依赖少数经验丰富的员工，现在AI可以承接其中相当一部分重复性的生成和适配工作，人不需要从零开始写每一条。

其次是整体内容质量的平均水平提高了。

过去可能只有少部分内容能够达到客户比较满意的水平，而现在AI把大量内容先做到一个相对稳定的基础水平，再由人进行筛选和优化。

再一个很重要的变化，是客户的工作方式发生了变化。

以前是来了一个需求，就按当天的需求去处理；这套AI工作流上线之后，新客户进来时就可以提前把门店、主打菜品、活动等参数规划好，再由系统持续生成内容，把原本容易堆积在某一天的人力需求提前消化掉。

这可以理解成“削峰填谷”：它真正解决的，是让内容生产不再那么容易卡在“一个人每天能处理多少条内容”上。

项目图示

原案例图示（PDF 第 149 页）

原案例图示（PDF 第 151 页）

原案例图示（PDF 第 152 页）

五、关键落地难点

这个项目最大的难点，其实不是开发。

第一个挑战，在文案之外。

因为文案看起来只是几百字，但真正拿去做短视频时，它背后还涉及人物怎么讲、情绪怎么表达、画面怎么配、节奏怎么样。

客户有时候会觉得“这个不对”，但又很难准确说明到底哪里不对。

这时候就不能只靠技术解决。

FDE需要结合自己的业务经验，去理解客户说的“感觉不对”到底意味着什么，再把这种比较模糊的反馈转成可以调整的提示词、流程或者判断标准。

第二个挑战，是不同客户、不同SKU下的稳定性。

原本设计好的提示词，在一个案例里表现不错，换一个商户或者SKU，可能就会出现偏差。

这时候需要回到具体业务里去看，到底是输入信息不够，还是参数、提示词或者流程逻辑需要调整。

第三个挑战，是如何让员工主动学习怎么和AI协作。

以前一个运营人员可以直接和同事沟通：“这个客户今天要做三条内容。”现在，他需要把业务要求转成系统能够理解和复用的输入，还要能够把“这个结果味道不对”这样的主观反馈，逐渐变成系统能够吸收的反馈。

这对团队来说其实是一种新的工作方式。

所以FDE可以通过Demo、测试、反馈和不断迭代，让团队逐渐理解AI能做什么、不能做什么。

同时，在项目交付时就提前预留持续迭代的空间，让客户按照SOP自己继续优化。

这样项目结束之后，所有事情就不会重新回到FDE这里。

项目实践表明这也是FDE和单纯“交付一个软件”很不一样的地方：交付的不只是一个能跑的东西，还要让企业能够继续用、继续改。

六、FDE 交付方法与企业启示

如果让FDE总结这个项目，项目实践表明FDE最重要的能力并不是“会不会调用一个模型”，甚至也不完全是开发能力。

第一件事，是从生意的角度先把业务看懂。

在项目交付中，FDE时，会默认电脑、手机上能够规模化完成的事情，都值得先尝试AI。

然后再通过实际测试，把做得不够好、不够稳定的节点逐渐交还给人。

所以要先让AI跑起来，再用业务结果判断它到底适合做到什么程度。

第二件事，是把AI放进业务流程。

企业员工自己用AI写一篇文案、做一个PPT，当然也有价值，但这种价值往往比较有限。

真正能够形成企业级价值的，是让AI在流程里承担一个稳定的节点，甚至重新设计整个流程。

这个项目就是一个很典型的例子：如果只是告诉运营人员“以后用AI写文案”，效果不会特别明显；但当项目团队重新梳理客户、SKU、内容参数、生成、校验、人工审核这些环节之后，AI才真正变成了业务流程的一部分。

第三件事，是把企业自己的Know-how留下来。

不同公司的文案看起来可能很像，但真正决定效果的，往往是这个公司自己的判断标准。

所以FDE的价值之一，就是把老板、运营负责人、优秀员工身上的隐性经验提炼出来，沉淀成可以复用的流程、参数和判断机制。

在这个案例里，不同餐饮客户最终的文案当然会不同，但背后的字段和基本Know-how范式是相通的，而具体取向则可以通过参数调整。

这就让一套业务逻辑具备了进一步复用的可能。

第四件事，是一定要给反馈和迭代留位置。

项目实践表明，AI项目不是“开发完成”的。

第一版Demo往往并不难，真正决定项目能不能落地的，是前期需求理解、后期打磨，以及客户能不能持续参与迭代。

所以在项目交付中，FDE，前面会花很多时间做需求确认和业务对齐，中间开发反而没有那么复杂，真正需要持续投入的是后面的测试、反馈和优化。

最后，项目进一步说明：FDE的核心职责是帮助企业找到AI和自己业务之间的连接点。

这一角色可以定位为一个“AI应用辅导师”：当客户知道AI很重要，却不知道它究竟怎么进入自己的业务时，FDE需要做的是深入他的业务，理解他的工作方式，再把AI真正植入进去。

“用AI写文案、写汇报、生成海报”这类表层应用，远远不够。

技术能力当然重要，但随着AI辅助开发能力不断增强，技术门槛正在下降。

反而是理解业务、理解Know-how、建立客户和团队的信任，以及把人的经验转化成AI可以执行的流程，越来越成为真正卡住FDE落地的地方。

七、可复用的交付资产

同类项目若要复制这条路径，可以优先沉淀以下交付物：

• 场景访谈记录与 As-Is／To-Be 流程图
• 业务对象、关键字段、角色责任和异常分支清单
• 知识地图、文档清洗规则、切片规范和高频问题测试集
• Agent 工作流定义、工具调用清单、提示词版本和任务评测集
• 系统集成图、字段映射、权限配置、失败重试与回写日志
• 覆盖普通、复杂和异常任务的验收样本与业务指标口径
• 人工审核、失败回退、上线巡检和持续迭代清单

来源与作者

Datawhale《FDE案例100》，受访者：十页（南京十页涌现智能科技有限公司创始人）；PDF 第 148-159 页，书内页码 147-158。本文为访谈资料的第三人称整理，不是本站新采访。