EP.3 | AI实践与思考（二）：编程世界中的乐高积木，我是如何使用低代码平台进行开发

本文基于我在 MIS3012《LLMs in Business》课程中的实战项目，同时结合了我在 Plaud AI 的实习体验，讲述一个从用户痛点出发，用低代码平台 Dify 搭建出完整 VOC 智能系统的过程。

Part 1｜为什么选择低代码平台？——从“用AI”到“造AI”

在正式进入这一篇的主题前，我想先简单介绍一下 Dify （另一个类似的应用叫Coze）——这是我在 MIS3012 课程中接触到的一个低代码AI开发平台，也是这篇文章中多次提到的工具主角。

简单来说，Dify 就像“AI的乐高工作台”：

• 它让你不用写代码，就能搭建属于自己的 AI 应用；
• 可以拖拽模块、设置提示词（Prompt）、接入知识库、调用API；
• 输出结果可以是一个聊天机器人、评论分析系统，或自动化报告流程。

相比直接用 ChatGPT 提问，Dify 更强调“任务链条”——让 AI 不只回答你的问题，而是按你的流程完成整段工作。

例如：

• 搭建一个“智能客服”：读取产品知识库 → 自动回复 → 汇总总结；
• 或者设计一个“评论分析员”：读取用户评论 → 情感打标签 → 输出结构化结果。

在课程里，我亲手用 Dify 搭建了几个工作流，也正是在这个过程中，我第一次意识到：

“使用AI”和“构造AI”，其实中间只隔着一层界面和一点点思维方式的转变。”

在接触Dify前，我的AI应用经历与多数人相似：用ChatGPT优化简历、撰写论文、完成行业研究；虽系统学习过吴恩达的LLM课程并实践Prompt工程，但这些技能未能带来工作方式的根本性变革。在LLM技术突飞猛进的两年间，我的应用始终停留在基础层面。

直到MIS3012课程引入Dify，才促使我重新思考AI能力的分层模型：

在第三维度（被动使用 AI 工具）徘徊的我们，经常会误以为AI时代下我们的核心竞争力是「如何使用工具」。但接触了 Dify 之后我才真正意识到：作为非技术背景（尤其是商科生），我们的核心优势从来不是“会用工具”，而恰恰是结构化的业务思维与产品化能力。

AI 的快速普及和低代码平台的兴起，正在重新定义能力的边界：

• 低代码，大幅降低了开发与实现业务想法的技术门槛；
• 工程思维，帮助我们将复杂的业务场景，转化为清晰的系统流程；
• 产品化思维，则引导我们以用户价值为中心，定义需求并创造落地可行的解决方案。

通过 Dify，商科生完全能够跳出过去“只能使用工具”的局限。我们不必成为专业程序员，就可以：

• 用商业洞察精准定义真实需求；
• 用结构化的框架思维搭建可落地的业务流程；
• 用低代码工具将想法高效地转化为实际产品。

而这种从第三维度（被动使用 AI）迈向第二维度（主动构建 AI）的跨越，才是真正属于商科生的核心竞争力：

在 AI 浪潮中，把对行业的深刻理解，变成可以被落地的系统化解决方案。

那接下来，请允许我用一个自己做的真实案例，给你展示一下这个过程！

Part 2｜Super VOC Agent：用 Dify 搭建一个“意见处理总管”

起点：从实习中的“反馈处理困境”开始

这个项目的灵感，起源于我在 Plaud AI 实习的 VOC 工作中：

VOC(Voice of Consumer): 收集并整理各个渠道上用户对产品的评论，进行分析。

当时，我们使用 Sprout Social 平台收集海外用户的社交媒体评论（如 Instagram、X、Facebook）。这个平台可以做情感分类，还能整合评论，看上去已经是个“半自动”的解决方案了。

但真正在使用中，我发现它有三个致命短板：

1. 缺乏功能维度的分类（aspect-specific）——只告诉你这条评论是“正面”，却不知道是夸电池还是屏幕；
2. 团队仍需人工copy到Excel中再做维度划分——导致工作流程极度冗余；
3. 情绪识别容易翻车——像“照片拍得还不错，但系统有点卡”这种混合评论，常被误判为纯正面。

这让我开始思考：

“有没有可能搭建一个真正理解情绪、能分辨产品维度、还可以自动推送分析结果的系统？”

对比：为什么GPT或传统ML方法解决不了？

我意识到，不是“不能识别评论”，而是“不能把识别嵌入到自动流程中”。我需要一个 Agent，不仅能理解情绪，还能：

• 把评论结构化；
• 自动分类并统计；
• 输出报告或表格；
• 再自动分发给业务团队。

这就是我为什么要用 Dify 来搭建我自己的 Super VOC Agent。

实现过程：工作流长什么样？

这是我在 Dify 上搭建的 Super VOC Agent 的完整工作流程图。它的目标是让 VOC 团队只需上传评论数据，后续的处理、输出和分发全部实现自动化。

整个流程由两条并行通道组成：

• 一条负责结构化数据处理（标签打完后自动写入飞书多维表格）；
• 一条负责语义洞察生成（自动生成“用户反馈趋势报告”）；
• 最终，两条路径的结果统一由机器人推送至团队群聊，实现闭环交付。

VOC 流程分步详解（Dify 实现）

1️⃣ 文档提取（输入层）

在这一节点中，我们可以自定义用户输入内容。比如我设置了文件上传（CSV/Excel），让用户可以直接上传评论数据文件。

针对格式不确定的文档内容，我们使用 Dify 的文档提取器节点，将评论文本提取为纯字符串数组，为后续 LLM 处理做好准备。

2️⃣ 评论标签生成（核心处理）

在提取出纯文本后，下一步我们使用 GPT-4o-mini 模型对每条评论进行双标签分类。

这一部分是整个流程的智能核心。我们调用大模型的 API，并在系统提示词中写入以下内容：

# 角色
你是一个专业的评论分析员，擅长根据给定的评论内容，准确地进行分类和标签标注，以便生成可导入 Excel 的标签。

## 技能
### 技能 1: 分析评论并打标签
1. 仔细阅读{{#context#}} 中的评论内容。
2. 从情绪角度，判断该评论属于好评、中性还是差评，并给出相应的情绪标签。
3. 从类别角度，判断该评论涉及摄像、外观、电池、性能、其他中的哪一类，并给出相应的类别标签。
4. 最终输出可以导入 excel 的标签结果。
5. 不需要输出日期
6. 如果评论的类别大于一条，比如为n条，请自动分为n条评论，例如：手机屏幕很耐摔，但电池不行
如果是现在的flow：大概率只能检测出其中一种评论，比如屏幕，然后结束
目标实现的部分：分为两条评论，例如手机屏幕-好评-耐摔；电池-差评-不耐用

## 限制:
- 仅依据 context 的内容进行分析打标签，不涉及其他无关信息。
- 输出结果必须符合要求的标签类别，不能随意添加或更改。 

参考如下：
[
    {
        "订单号": "123456",
        "文本": "外观非常时尚，屏幕清晰度很高，就是充电速度再快一点就完美了。",
        "类别": "外观",
        "子特性": "清晰度",
        "情绪": "Positive", 
        "情绪点": "屏幕清晰"
    }
]

通过这一 Prompt，我们实现了两个目标：

• 多维度评论标签提取；
• 输出结构化 JSON 数据，便于后续操作和数据落地。

3️⃣ 分流一：多维表格写入（结构化数据输出）

完成标签化后，我希望将结构化结果直接同步到飞书的多维表格中。为此我做了以下几步：

1. 在飞书开发平台创建应用并绑定所需多维表格；
2. 在 Dify 插件市场中添加“飞书多维表格”插件；
3. 使用开发者 Token 完成授权；
4. 对字段进行标准化命名，确保插件可以顺利识别数据。

上图是数据运行前的飞书表格。让我们往下看，见证“魔法”发生的瞬间。

4️⃣ 分流二：趋势报告生成（语义洞察输出）

并行的另一条路径是语义分析模块。我们再次调用大模型，基于整批评论数据，生成一份结构清晰的 Markdown 格式报告。

请根据{{#context#}}，总结输出对于用户反馈评论的报告，
要求分为电池，性能，其他，外观四个品类，内容详细具体

调用方式与多维表格节点类似，我们：

• 授权云文档应用；
• 添加 Dify 的“飞书文档”插件；
• 编写系统提示词如下：

大模型根据以上指令，输出趋势分析结果并自动同步到飞书文档中。这部分内容可以被视为 VOC 团队的“日报”或“周报”自动生成器。

5️⃣ 自动推送（闭环触达）

最后，我配置了一个虚拟群聊（名为“VOC 部门”），并通过机器人节点将最终生成的表格链接与报告链接统一打包推送至群中。

6️⃣ 效果演示

输入： 上传一份原始评论文件，例如：

运行： 点击运行工作流后，系统将自动完成提取、标签生成、报告撰写与群聊推送等全流程操作。

输出：
推送内容不仅包含结构化数据表格和趋势报告的链接，还附带表情符号与摘要文字，实现了真正意义上的——
从用户评论上传 → 数据处理 → 分发结果 → 反馈闭环，全流程自动化。

总结：运营视角的VOC agent

最后，让我们从一个运营人员的角度出发，复盘下这个VOC agent的作用：他不需要你懂 AI，也不需要你写任何代码。你只需要做一件事：上传一份评论文件。

然后，大约 5 分钟后，你会在飞书群里收到两条推送：

1️⃣ 一份结构化的评论数据表格，已经自动打好了情绪和功能维度标签，支持筛选、排序、画图，马上可以拿去做周报或舆情分析；

2️⃣ 一篇自动生成的用户反馈趋势报告，告诉你过去一周用户最常提到的问题、最满意的功能，以及可以用在广告里的“金句好评”。

整个过程零手动处理、零 copy-paste、零格式调整，你不再需要反复打开 Excel、标黄、改格式，所有操作都自动完成。

这不仅提升了效率，更释放了你思考的时间 ——
把精力从“数据处理”转向“策略决策”。

我接触的其他项目

在 MIS3012 课程中，我不仅搭建了 Super VOC Agent，也尝试/接触了多个轻量、实用的智能代理项目。它们虽然功能各异，但背后共同体现了我对低代码工具的深入探索与“AI 应用产品化”的思考。

项目 1：反鸡汤助手

这是一个由 Coze 搭建的小型聊天应用。你输入一句“鸡汤文学”（比如“努力一定有回报”），它会回怼一句毒鸡汤进行“反向激励”。

亮点：我使用 Coze 的 UI 编辑器设计了网页版聊天界面，完全无需前端知识，仅用几分钟就完成了部署与上线。这是我第一次完整体验从逻辑构建到产品发布的全过程，让我意识到低代码平台在“表达创意”方面的巨大潜力。

项目 2：新闻助手

这是一个信息收集型 Agent。我设定了几个新闻源网站（如财新、虎嗅等），每天早上 8 点，它会自动爬取页面内容，摘要整理后推送到我的飞书群或微信对话框。

实用价值：它大大节省了我早起浏览信息的时间，真正实现了“信息即服务”的效率提升，也让我第一次将定时调度 + 自动摘要 + 推送功能打通为一个完整闭环。

项目 3：面试助手

这个 Agent 的目标用户是正在准备求职的同学。你输入目标岗位关键词（如“产品经理”），它会自动爬取小红书上的面经笔记，提取高频面试问题，并与用户进行模拟问答交互，支持评分和回答优化建议。

亮点：这个项目结合了数据采集能力与 LLM 的自然语言生成能力，同时借助了 Coze 提供的“小红书爬虫插件”，无需写一行爬虫代码即可快速实现采集逻辑。这是我第一次尝试“垂直场景 Agent”的构建，也是对“搜索 +理解 +模拟”一体化能力的实践。

这些项目虽然轻量，但每一个都让我对低代码平台的边界与可能性有了更具体的理解。相比传统的 ChatGPT 工具使用，它们真正实现了“AI 工具 → 系统产品”的跃迁。

Part 3｜从实战中悟出的四条铁律

在搭建 Super VOC Agent 的过程中，我踩过的坑、修过的 Bug、对着报错信息抓狂的时刻，最终凝结出四条底层认知。这些认知不仅适用于 AI 工作流开发，更让我重新理解了“技术”和“业务”之间该如何协作。

铁律一｜AI 是齿轮，不是发动机

—— 真正驱动系统的是整体流程，而不是单点智能

起初我对 Dify 的想象，是一个“AI 万能解决方案”——把问题丢进去，模型自动给出答案。但当我真正开始搭建流程，面对工作流中密密麻麻的节点，才意识到：

AI 模型只是一个强大的处理单元，它本身并不是解决问题的全能选手，而是需要与提取器、转换器、外部 API、插件等功能模块协作，才能完成一次闭环的任务流。

以我构建的 VOC Agent 为例，整个流程用了 8 个节点，只有两个节点是真正调用了 GPT 模型，其余都是数据清洗、格式标准化、权限授权、消息推送等模块。

人们总想用 AI 覆盖全流程，却忽略了系统设计的本质是分工协作。

铁律二｜产品思维 + 工程思维 = 可落地的智能系统

—— 设计一个好用的 Agent，既要理解人，也要理解机器

AI Agent 的开发从来都不是技术导向，而是需求导向。产品思维告诉我们“用户到底想要什么”，工程思维告诉我们“用什么方式实现最合适”。

例如，在处理 1000 条用户评论时，我们知道 VOC 团队希望看到的是一份精炼的趋势分析报告。但 GPT 无法一次性处理这么大的输入，于是我将流程拆解为：

1. 数据切分
2. 分批送入 LLM 进行处理
3. 汇总生成结构化表格和摘要报告
4. 自动推送结果到团队群组

产品思维让我们站在业务角度思考交付内容；工程思维让我们找到最合适的技术路径执行。这两者必须结合，缺一不可。

铁律三｜低代码 ≠ 零技术门槛

—— 技术素养是“低代码开发”中被低估的隐性门槛

当我尝试将 LLM 输出结果写入飞书多维表格时，迎来的是一串让人摸不着头脑的 JSON 报错：
“Invalid JSON format”“Field type mismatch”“Missing required fields”

这背后并不是插件问题，而是我对接口结构、字段配置和数据格式的理解不到位。最后的解决过程是：

• 阅读飞书开发平台的 API 文档，搞清楚字段结构和格式要求
• 用 Postman 模拟接口请求，逐步调试数据结构
• 回到 Dify 插件配置界面，手动完成字段映射和格式修正

整个过程虽然没有写一行代码，但完全依赖于对 HTTP 请求、权限配置、数据结构的理解。所谓“低代码”，本质是“可视化配置”，但这并不代表门槛消失——它只是换了一种形式存在。

铁律四｜插件生态决定能力边界

—— 选择平台，就是选择你能触达的边界

目前主流的低代码平台中，Dify 和 Coze 是两种风格鲜明的代表：

• Dify 更偏向海外开发者生态，插件自由度高、模型兼容性强（支持 GPT-4、Claude、Gemini 等），适合自定义需求强、场景复杂的应用；
• Coze 更适配国内市场，由字节跳动开发，插件生态以微信、飞书、小红书等中国主流平台为主，用户体验更友好，但模型默认绑定豆包，模型选择相对受限。

以我做的面试助手为例，当我希望抓取小红书面经内容时：

• 在 Dify 中虽然有爬虫插件，但反爬机制限制多，操作复杂；
• 在 Coze 中，社区已经有封装好的“小红书爬虫”插件，拖进去即用，效率更高。

因此，平台的插件生态，决定了你能多快、用多低的代价把方案实现出来。用什么平台，不只是技术选择，更是资源调度策略。

🎯 最终的转变

通过这些项目，我完成了一个身份上的转变：从一个“等 AI 给答案的使用者”，变成了一个“为 AI 设计流程的搭建者”。

AI 不该是一个独立表演的明星，它应该是我们构建系统时的一个核心成员。真正的价值，不是“AI 多聪明”，而是“我们如何把它用在正确的位置”。

欢迎留言交流，我也乐意开源我的 Prompt 模板与 Dify 配置文件，帮助更多人构建自己的 AI 工作助手！

关于「毕业输出挑战」🚩

受弋零的启发，我从 2025 年 4 月开始发起了自己的「毕业输出挑战」。计划在最后一个月，用 14 篇文章系统整理过去几年积累的思考、观察与知识体系，在输入—内化—输出之间，构建一个正向循环。

我选择以 Newsletter 的形式发布内容，是希望以一种更专业、结构化的方式来进行长期分享。同时，我也会在小红书上不定期发布部分内容切片，触达更多感兴趣的读者。

欢迎你在阅读过程中随时反馈：无论是内容勘误、观点补充，还是你的灵感火花，我都会认真参考并在后续内容中持续优化。

如果你喜欢这样的内容，也欢迎订阅邮箱更新，获得更完整的阅读体验。