Dify平台美食探店推荐语生成实战

Dify平台美食探店推荐语生成实战

在内容为王的时代，一条生动有趣的探店文案，可能比千次广告投放更能撬动用户点击。尤其是在小红书、抖音等社交平台上，风格鲜明、信息密集的“种草文”已成为消费者决策的重要参考。然而，面对成百上千家新店上线，运营团队常常陷入“文案产能不足”的困境：写得慢、风格乱、缺乏真实感——这些问题正不断侵蚀内容营销的效率。

有没有一种方式，能让AI批量生成既有人情味又具专业性的美食推荐语？答案是肯定的。借助Dify这一开源的低代码AI应用开发平台，我们无需从零训练模型，也能快速搭建一个稳定可用的“智能文案助手”。最近在一个本地生活服务平台的项目中，我们就用它实现了秒级输出小红书风格探店文案的能力，准确率和可读性远超预期。

整个过程没有写一行后端代码，核心逻辑全部通过图形化界面完成。这背后的关键，并不是简单调用大模型API，而是巧妙结合了可视化流程编排、提示词工程与检索增强生成（RAG）三大技术模块。接下来，我就以这个真实案例为蓝本，拆解如何用Dify构建一套真正能落地的内容生成系统。

先来看一个实际效果对比。假设我们要为一家新开的日料店撰写推荐语：

• 人工撰写版本：
  “藏在静安寺商圈的小众日料店「樱之味」，主打新鲜三文鱼刺身拼盘，食材每日空运直达。店内原木装修搭配暖光灯笼，氛围安静治愈，适合闺蜜小聚或情侣约会。”

• Dify生成版本：
  “上海人私藏的日料清单+1！就在静安寺地铁旁的『樱之味』，一进门就被原木香和清酒气包围～主推的三文鱼刺身拼盘真的绝，入口即化还带奶香！人均不到200，环境温馨到想拍照发朋友圈📸 强烈建议约TA来吃个周末晚餐✨”

可以看到，AI生成的内容不仅保留了关键信息点，更具备明显的“社交平台语感”：使用emoji、口语化表达、情绪引导、行动号召……这些细节正是传统自动化工具难以企及的地方。

它是怎么做到的？

可视化AI应用编排：让复杂逻辑“看得见”

很多人以为AI应用就是调个模型接口返回结果，但真正的生产级系统远比这复杂。一次高质量的内容生成，往往需要经过输入处理、上下文检索、条件判断、多轮调用等多个步骤。如果全靠代码实现，维护成本极高。

Dify的核心突破在于提供了一个基于有向无环图（DAG）的可视化编排引擎。你可以把它想象成“AI版的流程图工具”，通过拖拽节点连接数据流，就能定义完整的执行逻辑。

比如在这个项目中，我们的工作流长这样：

graph TD A[用户输入] --> B{参数校验} B -->|有效| C[RAG检索] B -->|无效| D[返回错误提示] C --> E[构造Prompt] E --> F[调用LLM生成] F --> G[敏感词过滤] G --> H[输出推荐语]

每个节点都代表一个功能单元：
- 输入节点接收表单数据（如店铺名、位置、人均消费等）；
- RAG节点从知识库中查找相似场景下的优质评价；
- Prompt节点将变量注入预设模板；
- LLM节点调用通义千问或GPT-3.5生成初稿；
- 最后经过内容安全检查再返回前端。

这套流程完全可视化配置，产品经理也能参与设计。更重要的是，支持实时调试——点击任意节点即可查看其输入输出，极大提升了排查问题的效率。

底层上，Dify会将这个图形结构序列化为JSON格式的流程定义文件，便于版本管理和CI/CD集成。例如以下简化配置：

{ "nodes": [ { "id": "input_1", "type": "input", "config": { "label": "用户输入", "variable": "user_input" } }, { "id": "rag_1", "type": "retrieval", "config": { "dataset_id": "ds_001", "top_k": 3, "query_from": "user_input" } }, { "id": "llm_1", "type": "llm", "config": { "model": "qwen-turbo", "prompt_template": "根据以下信息生成一条小红书风格的美食探店推荐语：\n店铺名：{{shop_name}}\n特色菜：{{dish}}\n环境描述：{{env_desc}}\n参考评价：{{reviews}}" } } ], "edges": [ { "source": "input_1", "target": "rag_1" }, { "source": "rag_1", "target": "llm_1" } ] }

这种结构化的配置方式，使得整个AI流程不再是“黑箱”，而是可审计、可复用、可迁移的标准组件。

提示词工程：控制AI“说什么”和“怎么说”

很多人低估了提示词的作用，认为只要模型够强，随便写几句指令都能出好结果。但在实践中我们会发现，同样的模型，换一种提问方式，输出质量可能天差地别。

Dify把提示词工程做成了一个独立模块，支持模板管理、变量注入、上下文记忆和A/B测试。这才是保证生成内容风格统一的关键。

在这个项目中，我们并没有直接让模型“写一条推荐语”，而是精心设计了一套包含多个约束条件的提示模板：

请为一家位于{{location}}的{{cuisine_type}}餐厅撰写一条小红书风格的探店推荐语。 餐厅名为「{{shop_name}}」，主打菜品是{{dish}}，环境{{env_desc}}。 要求： - 使用口语化表达，像朋友聊天一样自然 - 加入1~2个合适的emoji表情 - 突出性价比或独特体验（任选其一） - 字数控制在120~150字之间 - 避免使用“强烈推荐”“必吃榜”等过度承诺词汇

你会发现，这条提示词不只是告诉模型“做什么”，更明确了语气、长度、禁忌词等细节。正是这些看似琐碎的要求，决定了最终输出是否符合运营需求。

为了验证效果，我们在Dify中做了几组对比实验：

差异非常明显。尤其在避免“AI腔”方面，具体指令起到了决定性作用。比如明确禁止使用“强烈推荐”，否则模型容易陷入套路化表达；要求加入emoji，则显著提升了社交传播潜力。

值得一提的是，Dify内部采用的是类似Jinja2的模板语法，这意味着你可以在外部系统中复用相同的渲染逻辑。例如用Python模拟提示词填充过程：

from jinja2 import Template prompt_template_str = """ 请为一家位于{{ location }}的{{ cuisine_type }}餐厅撰写一条小红书风格的探店推荐语。 餐厅名为「{{ shop_name }}」，主打菜品是{{ dish }}，环境{{ env_desc }}。 要求语气亲切自然，带有一定的种草感，字数控制在150字以内。 """ data = { "location": "上海静安寺", "cuisine_type": "日式料理", "shop_name": "樱之味", "dish": "三文鱼刺身拼盘", "env_desc": "温馨雅致，适合朋友聚餐" } template = Template(prompt_template_str) final_prompt = template.render(data) print(final_prompt)

这种方式特别适合需要与现有业务系统对接的场景，比如从CRM数据库自动提取门店信息并触发文案生成任务。

RAG增强：让AI“言之有物”

如果说提示词决定了AI“怎么说”，那么RAG（Retrieval-Augmented Generation）则解决了它“说什么”的问题。

很多AI生成内容之所以显得空洞，是因为模型只能依赖训练时学到的知识，无法获取最新的、特定领域的信息。而RAG机制的引入，相当于给大模型配了一个“实时资料库”。

在本项目中，我们上传了过去半年内收集的优质探店笔记、大众点评高分评论和品牌方提供的宣传素材，总计约2万条文本，构建成专属知识库。当新店铺信息输入时，系统会先进行语义搜索，找出最相关的3~5条历史内容作为上下文参考。

举个例子，当我们输入“适合情侣约会的日料店”时，RAG系统自动检索出以下片段：

【片段1】“灯光柔和，每桌间隔很宽，说话不用压低声音，非常适合情侣悄悄话。”
【片段2】“刺身新鲜度惊艳，尤其是三文鱼油脂分布均匀，入口即化。”
【片段3】“服务员会主动帮忙拍照，还会送一小杯清酒庆祝纪念日。”

这些真实的用户反馈被插入到Prompt中，成为生成推荐语的重要依据。相比纯凭模型“脑补”，这种方式大大减少了虚构信息的风险，也增强了文案的可信度。

Dify的RAG实现其实封装了完整的NLP流水线：
1. 文档分块（chunking）
2. 向量化（embedding，使用Sentence-BERT类模型）
3. 存入向量数据库（如Weaviate、Milvus）
4. 执行近似最近邻搜索（ANN）

虽然用户无需关心底层细节，但理解原理有助于优化效果。例如我们曾遇到一个问题：生成内容总是偏长。排查发现是RAG返回了太多段落，导致上下文膨胀。后来通过限制top_k=3并启用元数据过滤（只取近三个月的数据），问题迎刃而解。

如果你希望在本地复现类似能力，可以用LangChain + FAISS快速搭建原型：

from langchain.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.embeddings import HuggingFaceEmbeddings from langchain.vectorstores import FAISS loader = TextLoader("reviews.txt") documents = loader.load() text_splitter = RecursiveCharacterTextSplitter(chunk_size=200, chunk_overlap=20) texts = text_splitter.split_documents(documents) embeddings = HuggingFaceEmbeddings(model_name="all-MiniLM-L6-v2") db = FAISS.from_documents(texts, embeddings) query = "适合情侣约会的日料店推荐" retrieved_docs = db.similarity_search(query, k=3) for i, doc in enumerate(retrieved_docs): print(f"【片段{i+1}】: {doc.page_content}\n")

不过，在生产环境中还是建议使用Dify这类成熟平台，毕竟稳定性、权限控制、性能优化都不是小项目能轻易搞定的。

回到最初的问题：为什么选择Dify来做这件事？

因为它真正做到了把AI能力交到业务人员手中。在这个项目中，最初的流程是由运营同事提出设想，我们仅用了半天时间就在Dify上完成了搭建和调试。后续的迭代也不再依赖工程师，运营可以自行调整提示词、更换模型、更新知识库，甚至做A/B测试。

更深远的意义在于，这种模式打破了“技术驱动”与“业务需求”之间的鸿沟。过去，一个AI功能从提需到上线动辄数周；现在，几个小时就能跑通MVP。试错成本的降低，意味着更多创新想法可以被快速验证。

当然，Dify也不是万能药。它最适合的是中低复杂度、高重复性的文本生成任务。对于需要深度推理或多模态输出的场景，仍需定制开发。但就美食推荐语这类典型的内容自动化需求而言，它的表现已经足够出色。

未来，类似的架构完全可以迁移到酒店推荐、旅游攻略、商品详情页撰写等领域。同一套系统，换个知识库和提示词模板，就能服务于不同行业。这种“可复制性”，才是企业级AI落地的核心竞争力。

当内容生产的速度开始以秒计，而不是以小时计，我们或许正在见证一场静默的内容革命。而Dify这样的工具，正是这场变革中最值得信赖的加速器。