
> #DifyxEdgeOne最佳案例征集大赛
>
> 模板概述前缀：[Dify x EdgeOne] 会议记录助手 —— 一键生成结构化会议纪要，零运维部署到 EdgeOne Pages。

每个创业团队的会议室里，大概都有这样一个场景：白板写满了字、几个人对着手机敲文档、还有人在便利贴上潦草地划重点。会一散，**所有这些信息就开始以光速消失** —— 手写稿被夹回笔记本，临时文档散落在各自电脑，待办事项只剩"模糊的印象"。

我尝试过买 SaaS 纪要工具、强制指派记录员、推规范模板，**全部失败**。原因很简单：创业团队没有人愿意为"流程"额外花一分钟。

直到我用 **Dify 工作流** + **EdgeOne Pages** 做了一个会议助手 —— **整套方案前端零代码、Dify 6 个节点、半小时上线**：

- 主持人会议结束，把聊天记录/手写稿一贴
- 30 秒后，全员收到一份结构化 Markdown 会议纪要（含总览、决议、待办、风险、待澄清）
- 部署到 EdgeOne Pages，全球边缘节点访问，HTTPS 自动签发，**完全没写一行前端代码**

这篇文章会带你完整复现这套方案：从痛点到 Dify 工作流的每个节点配置（包括我踩过的 5 个真实报错），再到用 EdgeOne Pages 官方 `Dify Frontend Starter` 模板三步部署上线。**全文 3000 字，照着做半小时跑通。**

每个创业团队的会议室里，大概都有这样一个场景：白板写满了字、几个人对着手机敲文档、还有人在便利贴上潦草地划重点。会一散，**所有这些信息就开始以光速消失** —— 手写稿被夹回笔记本，临时文档散落在各自电脑，待办事项只剩"模糊的印象"。

我尝试过买 SaaS 纪要工具、强制指派记录员、推规范模板，**全部失败**。原因很简单：创业团队没有人愿意为"流程"额外花一分钟。

直到我用 **Dify 工作流** + **EdgeOne Pages** 做了一个会议助手 —— **整套方案前端零代码、Dify 6 个节点、半小时上线**：

- 主持人会议结束，把聊天记录/手写稿一贴
- 30 秒后，全员收到一份结构化 Markdown 会议纪要（含总览、决议、待办、风险、待澄清）
- 部署到 EdgeOne Pages，全球边缘节点访问，HTTPS 自动签发，**完全没写一行前端代码**

这篇文章会带你完整复现这套方案：从痛点到 Dify 工作流的每个节点配置（包括我踩过的 5 个真实报错），再到用 EdgeOne Pages 官方 `Dify Frontend Starter` 模板三步部署上线。**全文 3000 字，照着做半小时跑通。**
## 一、背景：创业公司的「会议黑洞」

我们是一家不到 30 人的创业互联网公司，节奏快、会议多。但「开会」这件事，长期处于一种很尴尬的状态：

- **记录方式极度随意**：有人用纸笔速记，有人临时新建一个 `腾讯文档/飞书文档`，会后就散落在各自的电脑和聊天窗口里。
- **只记「待办」，不记「上下文」**：文档里通常只有几条"张三跟进 A 项目""周五前出方案"，至于为什么这么决定、有哪些争论点、风险是什么，全靠记忆。
- **复盘几乎不可能**：两周后再回头看，没人说得清当初为什么砍掉某个功能。
- **新人接手成本极高**：跨部门同步基本靠口口相传。

一句话总结痛点：**会议开了很多，沉淀几乎为零**。

我们尝试过强制规范、指派记录员、买 SaaS 工具，但都败给了"创业团队没人愿意为流程付出额外成本"这一现实。

于是我决定换个思路：**不要让人去适配流程，让 AI 把流程吃掉**。

## 二、方案：Dify 工作流 + EdgeOne Pages 前端

整体架构非常轻量：

```
[ 录音文件 / 会议文字稿 ]
            │
            ▼
   ┌─────────────────────┐
   │  EdgeOne Pages 前端 │   ← 全球加速、零运维、HTTPS 默认
   └──────────┬──────────┘
              │ 调用 Dify API
              ▼
   ┌─────────────────────┐
   │   Dify 工作流        │
   │  ① 语音转写 (可选)   │
   │  ② 内容清洗/分段     │
   │  ③ LLM 结构化抽取    │
   │  ④ Markdown 渲染     │
   └──────────┬──────────┘
              │
              ▼
   [ 结构化会议纪要 + 待办清单 ]
```

技术选型理由：

- **Dify**：用可视化工作流编排 LLM，比手写一堆 Python prompt 链路省 10 倍时间，团队里产品同学也能改 Prompt。
- **EdgeOne Pages**：腾讯云的边缘静态托管，**Git 推送即部署**、自带全球 CDN、免费 HTTPS，对一个内部工具来说"零运维"四个字非常香。

## 三、Dify 工作流设计（实际跑通的版本）

应用类型选 **Chatflow**（不是 Workflow），用户可以直接在对话框粘贴会议原文，配合附件上传。整体节点链路：

```
START → 代码执行(文本预处理) → LLM(Gemini 2.5 Flash, JSON 模式)
      → 代码执行 2(JSON 解析) → 模板转换(Jinja2 渲染) → ANSWER
```

5 个节点，每个节点都极小，方便后续维护和提交 Marketplace 模板。

### 节点 1：START

Chatflow 自带一个 `sys.query`（用户在对话框输入的文本），我额外只暴露了两个输入字段：

| 变量名 | 类型 | 说明 |
| --- | --- | --- |
| `userinput.query` | String | 兜底字段，与 `sys.query` 同义 |
| `userinput.files` | Array[File] | 允许用户上传录音、手写稿照片、文档草稿 |

> Chatflow 的强校验：下游 LLM 节点的 USER 消息**必须**至少引用一次 `{{#sys.query#}}`，否则无法保存。后面会处理这点。

### 节点 2：代码执行（文本预处理）

负责清洗时间戳、`@某人`、空行、超长截断。**注意 Dify Code 节点只支持基础类型（String/Number/Object/Array[String]/Array[Number]/Array[Object]），不能直接传 `Array[File]`**，所以我们这里只接 `query`。

**输入变量**：

| 节点变量名 | 来源 |
| --- | --- |
| `query` | `{{#sys.query#}}` |

**代码**：

```python
import re

def main(query: str) -> dict:
    text = query or ""
    text = re.sub(r'\[?\d{1,2}:\d{2}(:\d{2})?\]?', '', text)  # 去时间戳
    text = re.sub(r'\d{4}-\d{1,2}-\d{1,2}', '', text)           # 去日期
    text = re.sub(r'@\S+\s?', '', text)                         # 去 @某人
    lines = [l.strip() for l in text.splitlines() if l.strip()]
    cleaned = "\n".join(lines)
    if len(cleaned) > 12000:
        cleaned = cleaned[:12000] + "\n...(已截断)"
    return {"cleaned_text": cleaned}
```

**输出变量**（必须在节点 UI 里手动声明，否则下游变量选择器看不到）：

| 变量名 | 类型 |
| --- | --- |
| `cleaned_text` | String |

### 节点 3：LLM 结构化抽取（核心）

**模型**：Gemini 2.5 Flash（在模型参数里开启 **JSON 输出模式**，避免模型返回 ```` ```json ```` 包裹）。

**SYSTEM Prompt**：

```text
你是一名专业的会议纪要分析师，专门服务于互联网创业团队。
请把零散、口语化的会议原文整理为严格 JSON。

要求：
1. 严格按下面 Schema 输出 JSON，禁止任何解释、Markdown 包裹。
2. 字段缺失时用合理默认值，不要省略字段。
3. action_items 必须能追溯到原文，不要凭空捏造。
4. 简体中文。

Schema：
{
  "summary": "string，3-5 句话的会议总览",
  "key_decisions": ["string"],
  "action_items": [
    {"owner": "负责人或'未指定'", "task": "任务", "due": "截止或'未指定'", "priority": "高/中/低"}
  ],
  "risks": ["潜在风险或待澄清事项"],
  "open_questions": ["未达成共识的问题"],
  "next_meeting": "下次会议时间或'未安排'"
}
```

**USER Prompt**（关键：必须出现 `{{#sys.query#}}` 以满足 Chatflow 校验）：

```text
【用户输入】
{{#sys.query#}}

【清洗后的会议原文】
{{#代码执行.cleaned_text#}}

请严格按 SYSTEM 中定义的 JSON Schema 输出会议纪要，不要输出 JSON 以外的任何文字。
```

### 节点 4：代码执行 2（JSON 解析）

LLM 返回的是 JSON **字符串**，下游模板转换需要的是结构化字段，所以必须在中间加一个解析节点。

**输入变量**：

| 节点变量名 | 来源 |
| --- | --- |
| `llm_text` | LLM 节点的 `text` 输出 |

**代码**：

```python
import json, re

def main(llm_text: str) -> dict:
    s = (llm_text or "").strip()
    s = re.sub(r'^```(?:json)?\s*', '', s)   # 兜底：去掉 ```json 包裹
    s = re.sub(r'\s*```$', '', s)
    try:
        data = json.loads(s)
    except Exception:
        data = {}
    return {
        "summary": data.get("summary", ""),
        "key_decisions": data.get("key_decisions", []),
        "action_items": data.get("action_items", []),
        "risks": data.get("risks", []),
        "open_questions": data.get("open_questions", []),
        "next_meeting": data.get("next_meeting", "未安排"),
    }
```

**输出变量**（同样必须 UI 上逐个声明）：

| 变量名 | 类型 |
| --- | --- |
| `summary` | String |
| `key_decisions` | Array[String] |
| `action_items` | Array[Object] |
| `risks` | Array[String] |
| `open_questions` | Array[String] |
| `next_meeting` | String |

### 节点 5：模板转换（Jinja2 渲染 Markdown）

Dify 的「模板转换」节点用的是 **Jinja2**，不是 mustache。把上一步解析出来的 6 个字段全部从变量选择器接进来，模板代码：

```jinja2
# 会议纪要

## 📌 总览
{{ summary }}

## ✅ 关键决议
{% for d in key_decisions %}
- {{ d }}
{%- endfor %}

## 📋 待办事项
| 负责人 | 任务 | 截止 | 优先级 |
| --- | --- | --- | --- |
{% for a in action_items -%}
| {{ a.owner }} | {{ a.task }} | {{ a.due }} | {{ a.priority }} |
{% endfor %}

## ⚠️ 风险
{% for r in risks %}
- {{ r }}
{%- endfor %}

## ❓ 待澄清问题
{% for q in open_questions %}
- {{ q }}
{%- endfor %}

**🗓 下次会议**：{{ next_meeting }}
```

输出变量：`output` (String)。

### 节点 6：ANSWER

Chatflow 的末端是 **ANSWER** 节点（不是 Workflow 的 End）。「回复内容」**必须**用变量选择器选到 `模板转换.output`，**千万不要保留 LLM.text** —— 否则用户看到的会是裸 JSON。

### 实测输出样例

输入一段口语化会议记录，最终 ANSWER 渲染效果：

```markdown
# 会议纪要

## 📌 总览
阿敏汇报了在 Dify 上修改提示词的进展，并指出 Dify 的工作流追踪
功能非常有效，能帮助定位逻辑问题。她敦促产品尽快上线，因为已有
多个自媒体博主在等待测试。

## ✅ 关键决议
- 产品应尽快上线

## 📋 待办事项
| 负责人 | 任务 | 截止 | 优先级 |
| --- | --- | --- | --- |
| 未指定 | 推动产品上线 | 未指定 | 高 |

## ⚠️ 风险
- 未能及时上线可能错失自媒体博主的测试机会

## ❓ 待澄清问题
- 负责产品上线的具体人员是谁？
- 上线的时间表和所需条件是什么？

**🗓 下次会议**：未安排
```

### 我踩过的 5 个坑（直接抄答案）

把过程里真实踩到的报错都列出来，免得复刻的同学再踩：

- **`main() got an unexpected keyword argument ''`**：代码节点的「输入变量」列表里有一行空名字。删掉空行即可。
- **`Output char_count must be a string, got int instead`**：UI 上声明的输出类型和 `return` 的实际类型不一致。把类型改成 `Number`，或干脆删掉这个无用输出。
- **`Variable #code.cleaned_text# not found`**：手输了变量引用。所有变量必须用 `{x}` 选择器插入，Dify 会自动填正确的节点 ID。
- **`user message 中必须包含 sys.query`**：Chatflow 强校验。LLM 节点 USER 消息里通过选择器插入一次 `{{#sys.query#}}` 即可。
- **ANSWER 输出还是 JSON**：100% 是 ANSWER 节点的"回复"还挂着 `LLM.text` 胶囊。删掉它，重新选 `模板转换.output`。

## 四、前端：部署到 EdgeOne Pages（三步搞定，零代码）

这一节我**没有自己写前端**。EdgeOne Pages 官方模板库里已经有一个 `Dify Frontend Starter`，开箱即用、自带聊天 UI、支持文件上传，正好能直接对接前面做好的 Chatflow。整个部署只有三步，截图照做就行。

### 第 1 步：进入 EdgeOne Pages，「从模板开始」

打开 [EdgeOne 控制台](https://console.cloud.tencent.com/edgeone) → 顶部切到 **Pages** → 点 **创建项目** → 选择 **从模板开始**。

![image.png](https://developer.qcloudimg.com/http-save/yehe-1504583/e4abdc159290a600879b9566f626fbda.png)

> 如果你已经有项目了，左上角下拉里能看到所有 Pages 项目，新建即可，不冲突。

### 第 2 步：搜索 `dify`，选择「Dify Frontend Starter」模板

模板市场右上角搜索框输入 `dify`，会出现一个名为 **Dify Frontend Starter** 的模板：

![image.png](https://developer.qcloudimg.com/http-save/yehe-1504583/a739a4570a6e4babab99b6ca0cebddd3.png)

> 这是 EdgeOne 官方维护的 Dify 通用前端：`A universal web frontend built on the Dify API. Wrap any Dify application…`，下面对应的 GitHub 仓库是 [`TencentEdgeOne/pages-templates/examples/dify-frontend`](https://github.com/TencentEdgeOne/pages-templates)。

### 第 3 步：填项目名 + 两个环境变量，点「立即创建」

模板会自动 Fork 一份仓库到你的 GitHub，构建配置完全不用动，只需要填两件事：

- **项目名称 / 仓库名称**：随意，比如 `meeting-helper`
- **环境变量**（页面下方红框区域，**最关键的两个**）：

| 变量名 | 值 | 说明 |
| --- | --- | --- |
| `APP_KEY` | `app-xxxxxxxxxxxxxxxx` | Dify 应用的 API Key（在 Dify Chatflow 的「访问 API」页生成） |
| `API_URL` | `https://api.dify.ai/v1` | Dify 服务地址，私有化部署填你自己的 |
| `NEXT_PUBLIC_APP_TYPE` | `chat`（可选） | 应用类型，Chatflow 填 `chat`；普通 Workflow 填 `workflow` |

![image.png](https://developer.qcloudimg.com/http-save/yehe-1504583/5e8a67d5d274899b0c347457ef8a9aca.png)

填完点 **立即创建**，EdgeOne 会自动拉代码、构建、分发到全球边缘节点，**大概 40 秒就能拿到一个 `*.edgeone.app` 的访问域名**，可以直接绑定自有域名（HTTPS 证书自动签发）。

### 为什么这三步能直接对接我们的 Chatflow？

模板内部已经处理好了和 Dify Chatflow 协议对接的所有细节：

- 自动调用 Dify 的 `/chat-messages` 流式接口
- 自动透传 `sys.query`（即用户在对话框打的字）
- 支持文件上传，直接喂给 `userinput.files`
- API Key 通过 EdgeOne 的环境变量注入，**不会出现在浏览器**，不需要自己写 Edge Function 代理

也就是说，前面我们在 Dify 里设计的 `START → 代码执行 → LLM → JSON解析 → 模板转换 → ANSWER`，到了前端就是：**用户粘贴会议原文 → 发送 → 收到渲染好的 Markdown 纪要**。整条链路零胶水代码。

### 部署后效果

```
![image.png](https://developer.qcloudimg.com/http-save/yehe-1504583/af68b87cfef8b7b4a89ad5f2fce5cfa0.png)
![image.png](https://developer.qcloudimg.com/http-save/yehe-1504583/d263cf9896595ee3c8252de0279c3231.png)
![image.png](https://developer.qcloudimg.com/http-save/yehe-1504583/c1486c21d07039833a962dcc839ca162.png)
```

线上 Demo（示例）：`https://dify.redcubeai.cn/`

## 五、上线效果：我们团队的真实变化

上线 3 周后的数据（团队 26 人，每周约 18 场各类会议）：

| 指标 | 上线前 | 上线后 |
| --- | --- | --- |
| 有正式纪要的会议占比 | ~15% | **96%** |
| 平均整理一份纪要耗时 | 25 分钟 | **40 秒** |
| 待办事项可追溯率 | 极低，靠记忆 | **100%（结构化字段）** |
| 跨部门信息同步投诉 | 周均 4-5 次 | 周均 0-1 次 |

更重要的是文化层面：会议结束后，主持人把聊天记录/手写稿一贴，30 秒内全员收到结构化纪要 —— **"开完会就消失"这件事，第一次在我们公司被根治。**

## 六、提交到 Dify Marketplace 的模板说明

为了让其他团队也能直接用，我已经把工作流导出为 `.yml` 模板，提交到 Dify Marketplace。模板信息：

- **名称**：会议记录助手 (Meeting Notes Helper)
- **概述**：`[Dify x EdgeOne] 一键将零散会议原文转化为结构化纪要，包含决议、待办、风险与下次会议安排。推荐配合 EdgeOne Pages 部署前端，零运维全球加速。`
- **使用步骤**：
  1. 在 Dify 中导入模板 DSL 文件。
  2. 配置任意一个 LLM 提供商（推荐 OpenAI / 通义千问）。
  3. 复制工作流的 API Key。
  4. Fork 我们提供的前端仓库，按本文第四节部署到 **EdgeOne Pages**。
  5. 在 EdgeOne 控制台配置环境变量 `DIFY_KEY`。
  6. 完成 ✅

## 七、为什么推荐 EdgeOne Pages 作为部署方式

在踩过 Vercel 国内访问慢、自建 Nginx 要续证书、对象存储不能跑函数等坑之后，对一个**内部 AI 工具**而言，EdgeOne Pages 几乎是最优解：

- **国内访问极快**：腾讯云边缘节点，平均首屏 < 1s。
- **Edge Functions**：不用单独搞一台服务器去藏 API Key。
- **Git 即部署**：产品同学改个文案 push 一下就上线了。
- **免费额度对中小团队足够**：我们日均 ~200 次调用完全没超。

## 八、写在最后

这套方案最让我满意的地方，不是它"用了多酷的模型"，而是它**真正落到了团队的日常**：

> 没有人需要改变开会习惯，没有人需要学新工具，
> 你只需要把那张乱糟糟的手写稿拍下来贴进去 —— 剩下的，AI 和边缘节点会替你搞定。

如果你的团队也深陷"会议黑洞"，欢迎从 Dify Marketplace 一键导入这个模板，配合 EdgeOne Pages 部署，半小时内拥有自己的会议助手。

---



模板概述前缀：[Dify x EdgeOne] 会议记录助手 —— 一键生成结构化会议纪要，零运维部署到 EdgeOne Pages。

从「会议黑洞」到「全自动纪要」：我用 Dify + EdgeOne Pages 给创业团队搭了一个会议助手

人工智能

开发工具

低代码

Dify与EdgeOne结合打造会议记录助手，无需代码30分钟快速部署。通过AI自动将会议内容生成结构化纪要，含决议、待办、风险项，支持Markdown输出。利用EdgeOne全球加速与自动HTTPS，实现零运维、高效访问，彻底解决会议信息零散难追溯的问题。

腾讯文档

对象存储

服务器

EdgeOne

GitHub

SaaS

JSON

2026采购季 | AI焕新·智启新局

热销域名限时优惠，新客首年免费！


domain

对象存储COS新用户低至1元！


CDN免费试用


4核4G3M云服务器 新用户低至38元/年！

语音产品特惠新用户14.9元起


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

从「会议黑洞」到「全自动纪要」：我用 Dify + EdgeOne Pages 给创业团队搭了一个会议助手-腾讯云开发者社区-腾讯云

从「会议黑洞」到「全自动纪要」：我用 Dify + EdgeOne Pages 给创业团队搭了一个会议助手

从「会议黑洞」到「全自动纪要」：我用 Dify + EdgeOne Pages 给创业团队搭了一个会议助手

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐