第一章：为什么我开始做这件事？——来自日常工作的“无声抗议”

如果你也在公司里负责 IT 运维、内务支持、客服体系，应该会非常懂——每天醒来第一件事，就是被各种渠道的“请帮我看一下工单”淹没。

有来自邮箱的、来自企微的、来自当面喊一声的，还有莫名其妙流入我私聊的。

很多时间都浪费在了“在找问题在哪里”。

更要命的是：

1. 有些人描述特别模糊，像谜语人
2. 有些人发消息像机关枪，信息碎得像玻璃渣
3. 问题散落在 outlook 对话串里，完全没有集中管理

直到某一天，我突然冒出一个念头：

如果有一个入口

用户能像平时说话一样描述

AI 能自动帮我提取问题信息

然后把数据送进一个系统

让我们 IT 真正从“找信息”解放成“解决问题”

那该多好。

这就是我开始这段探索的原因。

现在大家都在吹什么“人人都是开发者”、“人人都能构建 AI 应用”。

我也想试试自己能不能在不写代码的前提下，把这件事干成。

没有什么远大叙事，就是单纯地：我想让每天的工作好受一点。

第二章：第一步，我需要一个能“听懂人话”的入口 —— Dify ChatFlow

当我真正开始研究市面上的 AI 工作流工具时，我其实试用了好几个热门产品：

有的功能强但上手成本高，有的对数据承载能力不友好，有的需要自己搭界面。

最后落到 Dify 上，是因为：

• 对话式流程编辑器非常直观
• 搭建门槛低，几乎不需要写代码
• 部署成本为零，不用找研发人员支持
• ChatFlow 入口可以直接嵌入前端页面，不用自己写聊天 UI

总之，它就是那种“你只要把逻辑想好，我来帮你落地”的工具。

所以我决定先用 Dify 解决第一个关键问题：

如何优雅地收集一个“完整的工单”？

2.1 我给 AI 安排了一份“工单信息收集专员”的工作

在 LLM 节点里，我写下了这段 system prompt：

1. 角色设定：你是公司的 IT 工单服务助手。你的任务是帮助员工提交 IT 报修工单。
2. 必要信息列表：
3. – 问题描述 (Description)
4. – 设备类型 (Device Type)
5. – 紧急程度 (Priority)【低、中、高、紧急】
6. – 申请人 (Applicant)
7. 执行逻辑：
8. 检查用户的输入是否包含所有上述必要信息。
9. 如果信息缺失：请礼貌地向用户追问缺失的部分，不要编造信息。
10. 如果信息收集完毕：请基于收集到的信息，仅输出以下标准格式的 JSON：
11. Ticket_Complete_JSON: {“title”: “…”, “description”: “…”, “device”: “…”, “priority”: “…”}
12. 注意：只有信息收集齐全后，才输出 Ticket_Complete_JSON。否则请继续与用户对话。

让模型明白：

什么时候继续对话，什么时候正式“收单”。

如果没有模型key，推荐在deepseek api平台https://platform.deepseek.com/usage充值10元，获取一个key。个人使用几乎用不完。

2.2 再用一个分类器判断：AI 是在聊天？还是已经收集完毕？

ChatFlow 里我加入了一个“回复分类器”。

这个节点负责判断：

• 如果 AI 还在自然对话 → 把内容原样返回给用户继续聊
• 如果出现 Ticket_Complete_JSON → 表示“信息已完整” → 进入后续处理分支

这个判断点非常重要，它让整个流程像一个真正的“工单入口”而不是聊天机器人。

2.3 下一步就是：“数据要放哪？”

此时我有了结构化工单信息，但我需要一个数据容器来承载它。

我试过几个方向：

• • 用 Excel？太脆弱，不是长久方案。
  • 自建数据库？我只是想解决问题，不想开新项目。

正当我纠结时，我在 Dify 的工具库里发现了“HAP”的工具插件。

既然平台原生集成了，我就顺手注册试用了一下，结果发现：

• • 上手体验几乎零学习成本
  • 真的可以免费先用起来
  • 不需要找销售开权限，直接注册账号即可（这点好评👍）
  • 更关键的是：它是一个真正的数据库，而不仅仅是“表单工具”

我当时只是想找个能装数据的地方，但当我开始使用 HAP 的那一刻，我才意识到：

我之前的预期太保守了。

第三章：我本来只想找个能存数据的地方，结果……HAP 让我意识到它不是“表单工具”，而是“数据基座”。

我第一次打开明道云 HAP 的时候，其实心里很坦白：

我只是想找个能放工单信息的地方。

真的，就是这么朴素的需求。

但当我开始创建应用、创建表的时候，我的感受一路从“还挺方便”发展到“哦还有这个功能?”，最后变成了——

“这玩意儿怎么比我预期的强这么多？？？”

3.1 新建应用：进入 HAP 的第一步体验

进入 HAP 后，我先照着产品的导航，在左侧找到【应用】，点了【新建应用】。

应用名称我直接输入了“工单管理”。创建成功后，就跳到了一个空的应用页面。

这里会让我创建第一个工作表。点“从空白创建”，弹出一个窗口，里面有两个选项：

• 使用 AI 创建
• 从 Excel 导入创建

本来我准备自己列字段的，但看到“使用 AI 创建”，还是点进去试试看。毕竟建字段最耗时间，如果能自动生成，那就太省事了。

3.2 HAP 的 AI 生成表单：比我想得更“完整”

进入 AI 对话框后，推荐选项里的内容似乎基于“工单管理”生成的，细节好评。

点了第一个推荐选项，右侧的表单结构很快生成出来了。

字段数量比我预期多不少，但不是那种“堆砌式”的多，而是非常贴合企业内部流转逻辑的那些：工单编号、类型、状态、优先级、提交时间、处理描述、附件……甚至连“受理人”“受理部门”都考虑到了。

老实讲，我在那个当下没想那么细，它已经替我把“正常企业运作中应该存在的字段”都列得比较完善了。

AI功能的信任感就应该通过这种超出预期的回答来构建。

当然，对这次 demo 来说，我不需要这么完整，于是我根据提示 hover 看了下字段说明，删掉了一些暂时不会用到的字段。整体调整起来很顺手。

hover到字段上竟然还有提示信息，很惊喜

3.3 表单保存后，我意识到 HAP 并不是简单的表单工具

表单保存后，系统接着问我要不要继续扩展，比如创建“客户信息”“设备信息”等关联表。

一开始我以为只是常见的模板推荐，但点进去看之后发现：

HAP 的工作表，其实就是结构化的数据表，关联关系与数据库的逻辑是一致的。

区别在于，它把这些“数据库建模步骤”封装成了普通业务用户也能理解的操作方式。

这种感觉有点像——

前一秒我还只是想建个表，后一秒系统告诉我：

“要不顺便把业务数据模型也一起搭了？”

这让我重新审视了它的定位。不只是“能展示数据”，而是“能沉淀业务数据结构”。

对我这种需要一个轻量但能增长到复杂业务的工具的人来说，这个方向感是加分的。

3.4 再建一个『客户信息表』：为 dify → HAP 的工单闭环做好准备

为了让后续 dify 在创建工单时能写入更完整的信息，我又创建了一个“客户信息”表。

输入“客户信息”后，AI 生成的字段一样完整：客户名称、电话、邮箱、备注、客户类型……我依然按需求删减了一些多余字段，只保留了 demo 会用到的部分。

到这一步：

• 工单信息表
• 客户信息表

已经都准备好了，两个表之间也可以轻松建立关联。

至此，HAP 端的“数据底座”算是搭好了，接下来就可以回到 dify，把这两个系统串起来。

第四章：让 Dify 写进 HAP —— 工单真正“落地”的那一步

当工单表结构终于在 HAP 里准备好后，下一步就是让用户输入的自然语言真正“落地”为一条 HAP 工单记录。

对我来说，这部分其实比想象简单，但第一次上手时也踩了点小坑。这里分享下过程。

4.1 参数提取：把 AI 的结构化结果拆成可写入数据库的字段

模型在意图分类之后会返回一段完整的结构化 JSON —— 但这个 JSON 是“整体”的，而 HAP 新建记录工具需要的是“逐字段”对应的值。

所以这里我加了一个「参数提取器」。

它的作用很简单：

• 把整段结构化 JSON 拆成独立变量

（例如：Title、Description、Applicant、Priority……）

• 供后续节点逐项填写

这里不需要额外逻辑，就是纯粹的字段拆分。

4.2 核心节点：HAP「新建记录」—— 真正把工单写进数据库

整个分支的核心节点是 HAP-新建记录。

（1）选择工具：HAP → 新建记录

在工具搜索框输入 “hap”→安装

选择 「新建记录」。

（2）填写 AppKey / Sign

新建记录需要鉴权。

在 HAP 页面右上角打开菜单 → API 开发文档，就能看到应用的：

• AppKey
• Sign

把它们填进节点配置即可。

（3）工作表 ID 从哪里来？

工作表 ID 同样在 API 文档里。

进入表单的《字段对照表》页面，顶部就能看到：

工作表ID：xxxxxxxxxxxxxx

（4）重点：如何填「记录字段（对象）」？

这是最容易卡住的一步，但其实可以非常省心。

HAP 要求记录字段是这样的结构：

1. {
2. “字段ID”: “你要写入的值”,
3. “字段ID2”: “值2”
4. }

字段 ID 可以从 API 文档的《字段对照表》直接复制。

人工拼 JSON 非常烦，我把下面两份内容发给大模型：

• 字段对照表截图
• 需要写入的字段（Title、Description、Applicant、Priority 等）

让模型生成最终的 JSON 模板。

把这个 JSON 填进「记录字段（对象）」里，整条链路就串起来了。

第五章：系统上线后的实际效果，以及一次挺意外的感受

当整个流程跑起来以后（Dify 负责“听懂人话”，HAP 负责“承载与管理数据”），我把对话入口嵌入了我们前端页面的一个独立工单入口。

员工打开页面，就是一个简单的聊天框：

描述问题 → AI 提问补充信息 → 自动创建工单。

整个体验的学习成本几乎为零。

而对我们 IT 团队而言，最明显的变化是：

• 工单不再散落在邮箱里
• 数据是结构化的
• 分析、筛选、追踪变得简单
• 后续流程可以随时扩展，不需要重新建系统

只是一个最小可用的 demo，就已经把“收单混乱”这个长期痛点解决掉了。

我们把 Dify 的对话入口嵌到内部门户上，发了封邮件告诉大家：

以后 IT 问题通过“找机器人”，机器人会帮你整理信息、创建工单，IT 再接手处理。

5.1 再往前看半步：这次尝试让我意识到 AI 驱动开发的潜力巨大

在整个流程真正跑起来之后，我有个挺明显的感受：

这种“AI 负责理解、平台负责承载”的组合，其实已经改变了我们构建内部工具的方式。

过去做一个小系统——比如工单、资产管理、服务反馈——

往往需要拉上 IT、安排排期、做表结构、做页面、对接 API……流程完整但耗时。

这次用 Dify + HAP，体验很不一样：

• 想法成型的速度比以前快太多
• 很多逻辑不需要自己写，AI 可以先顶上
• 工具之间的互通也变得轻量
• 大部分时间花在“定义业务”，而不是“实现业务”

换句话说：

AI 不是替代开发，而是把更多人带入“能自己构建点什么”的状态。

这其实是我在整个项目里最意外的部分。

第六章：最后收个尾——工单只是开始

系统跑通之后，我们先让它稳定运行了一段时间。

期间我又做了两件事，算是顺手把这个体系补全了一下。

6.1 让聊天机器人“更像真的能解决问题的人”——我们把知识库也加上了

在工单流程跑稳之后，我顺带在 Dify 里构建了一个基础知识库。

内容很简单：

• 常见网络问题
• 邮箱同步问题
• VPN 使用指引
• 电脑无法开机/无法联网的基本检查办法
• 几个容易重复问的账号相关流程

这件事带来的效果其实挺明显的：

对于那种不需要真正创建工单的小问题，机器人就可以直接解决。

用户问完之后，很多时候连工单都不需要了，IT 的压力也下降不少。

工单入口的“智能化程度”，并不是只能靠问问题，而是可以靠知识沉淀。

6.2 HAP 的部分，我们实际上已经开始把它从“工单承载”升级成“工单系统”了

这篇文章里我主要讲了一个最小可用的闭环：

聊天 → 信息收集 → 工单落库

但在这个基础上继续往前走，其实非常顺：

• 做工单处理流程
• 加权限、加视图
• 做 SLA
• 做部门统计大盘
• 做处理人工作台
• 做跨团队协作节点

这些都不是幻想，而是 HAP 的能力本身就支持的。

我们团队内部已经开始把它往“完整工单系统”方向搭建，而不是只把它作为一个数据容器。

但——

这部分内容太大了，不适合塞在这一篇里。

如果大家感兴趣、想继续看我怎么做的，欢迎多点点赞、留言告诉我——

后面我可以单独开两篇把下面这些讲清楚：

1. 如何基于知识库，让Dify Chatflow从“收集字段”升级成“真正解决问题”
2. 如何基于 HAP 搭建一套完整的工单系统（处理流、SLA、协作、看板、报表）