

引言
1.1 背景与痛点
1.1.1 当前工单处理面临的挑战
随着企业数字化转型的深入,工单处理量持续攀升,传统的人工处理模式面临多重挑战:工单来源分散(邮件、聊天、电话等多渠道),信息碎片化严重;高峰时段工单积压,响应时延从分钟级拉长至数小时;客服人员大量时间消耗在重复性答疑和信息查找上,难以聚焦高价值问题。
此外,G端业务的复杂程度高和人员的流动性大会给企业带来高额的培训和学习成本,这也是普遍痛点。
1.1.2 传统解决方案的局限性
传统工单系统依赖人工录入、分类和派发,存在明显的效率瓶颈:信息录入不规范导致后续检索困难;知识分散在邮件、文档和个人经验中,难以复用;工单流转依赖固定流程节点,缺乏智能路由能力;问题解决方案缺乏标准化,回答质量因人而异。
此外,传统系统的"流程驱动"模式在面对非标问题时灵活性不足,无法实现真正的智能化辅助。
- 响应时间长
- 人力成本高
- 服务质量不稳定
1.1.3 AI 技术在客服场景的应用趋势
当前智能客服市场正从"单点智能"向"全链路Agent化"演进,大模型能力深度融入"咨询-处理-售后-质检"全流程。由于公司目前没有专门自研的智能客服,我们组这边就基于公司内部OA工具钉钉的AI助理搭建了一套工单处理智能辅助系统。
1.2 项目目标
1.2.1 核心目标
构建基于钉钉AI助理的工单辅助回复系统,实现工单知识库的搭建和工单的辅助处理。具体包括:实现工单信息的智能提取与结构化录入沉淀成知识库;利用AI秒级回复辅助生成标准化答复内容,降低人工排查和编写时间;建立从"问题提交"到"智能处理"到"知识沉淀"再到"效果追踪"的闭环管理机制。
- 提升工单响应效率(量化指标:响应时间缩短 X%)
- 缩短工单处理流程(量化指标:研发处理工单个数减少 X%)
- 提高服务质量和一致性
1.2.2 次要目标
积累企业工单处理的知识资产,形成可复用的知识库体系;通过钉钉的仪表盘数据分析识别高频问题和业务瓶颈,反向推动产品优化;提升工单处理人员的工作效率与工作体验,降低人员流失率;为后续全业务线的AI赋能提供可复制的方法论与实践经验。
1.3 技术选型理由
1.3.1 为什么选择钉钉 AI 助理
首先公司内部使用的OA工具就是钉钉,所以系统搭建和使用非常便捷,花费由公司购买OA系统时统一赠送使用额度,不需要再额外收费。此外,钉钉AI助理依托阿里云AI Stack构建,具备多项核心优势:开箱即用的超级工单助理能力,支持智能感知聊天记录、图片、音频等多种输入形式;
通过知识库与大模型结合,实现专业、准确的回答;可与钉钉组织架构和业务流程无缝集成,利用低代码平台快速搭建工单处理应用;支持自定义能力开发,可对接企业现有业务系统;具备完善的数据安全与权限管控机制。
1.3.2 技术栈总览
系统技术栈涵盖四个层面:AI能力层(钉钉AI助理平台、大模型服务)、应用搭建层(钉钉宜搭低代码平台)、数据存储层(钉钉多维表/数据库)、集成对接层(钉钉开放平台API、连接器)。
整体采用"AI+低代码"的开发模式,通过可视化编排实现工作流设计,大幅降低开发门槛和上线周期。
二、系统整体架构设计
2.1 系统时序图

2.2 核心模块划分
2.2.1 数据采集与预处理模块
负责从钉钉对话、工单答疑群、工单管理平台等多个数据源采集工单相关信息,通过数据清洗去除噪声和冗余内容,将非结构化的对话文本转化为结构化数据,为后续的知识库构建和模型训练提供高质量的数据基础。
2.2.2 知识库构建模块
整合我们部门内部的FAQ文档、产品手册、历史工单解决方案等多源知识,通过知识点原子化拆分和标签体系建设,构建面向AI检索的结构化知识库。知识库需支持语义检索和向量化存储,确保AI能够精准定位相关知识。
2.2.3 工单辅助回复模块
基于大模型和知识库,实现工单内容的智能分析与辅助回复生成。当运营或者技术支持提交问题时,模块首先在知识库中检索相关答案,结合大模型的理解能力生成专业、准确的回复建议。
研发人员可选择直接采纳或在此基础上修改完善,实现"AI先行筛选、人工后段决策"的协作模式。
2.2.4 效果评估与反馈模块
建立工单处理的闭环评估机制,通过追踪辅助回复准确率、工单个数、响应时长等关键指标,持续评估AI辅助效果。同时收集开发和技术支持人员的反馈意见,形成"使用→评估→优化"的持续改进循环。
2.3 系统特性
本系统具备以下核心特性:7×24小时全天候响应能力;知识库动态更新与自学习机制;与钉钉组织架构深度融合的权限管控;支持低代码快速迭代和自定义扩展。
三、工单申请模板优化设计
首先,优化后的工单申请模版可以让研发人员获取到更多的有用信息,减少无效工单,降低往返无效的沟通成本;其次,优化的工单申请模板可以从源头提升数据质量,有利于沉淀出高质量的Oncall范本内容供给AI助理去学习,一定程度上有助于提高AI辅助回复工单的准确率。
因此,本章介绍如何设计结构化的工单申请模板。
3.1 模板设计原则
3.1.1 STRUCTURE 原则
工单模板设计遵循STRUCTURE原则:Standard(标准化字段定义)、Targeted(面向目标问题类型)、Reusable(可复用设计)、Usable(用户友好填写)、Clear(清晰的信息层级)、Time-saving(减少填写时间)、Understandable(AI易于理解的结构化格式)、Relevant(聚焦必要信息)、Expandable(支持扩展)。
-
结构化:引导用户提供完整信息
-
标准化:统一问题描述格式
3.1.2 字段设计最佳实践
字段设计遵循"最小必要信息"原则,在保证工单可处理的前提下尽可能减少用户填写负担。必填字段控制在3-5个以内,优先使用下拉选择、单选按钮等结构化控件替代自由文本输入。字段命名需与业务术语对齐,并提供清晰的填写提示和示例。
3.2 模板定制化实践
3.2.1 基础模板设计
工单提交基础模板包含核心字段:工单名称、业务类别、业务环节、OnCall内容、工单类型(常规订正、业务咨询、技术排查....)、政采云环境枚举、紧急程度(低/中/高/紧急)和附件上传(截图/日志)。

工单回复基础模版包含核心字段:问题类型、回复结果和AI辅助回复评分。

四、工单数据集建设
4.1 数据收集策略
4.1.1 数据来源分析
工单数据来源主要包括:钉钉对话记录(工单群聊、单聊中的工单相关交流)、历史工单系统导出的结构化数据。其中由于工单提交之后,工单机器人会推送工单消息到钉钉工单答疑群里,钉钉对话记录由于覆盖最完整的上下文语境,是知识提取的核心数据源。
4.1.2 历史工单数据导出
通过工单系统的数据导出功能,批量获取历史工单的完整数据,包括:工单标题、问题描述、处理过程记录、最终解决方案等关键字段。导出数据需确保覆盖至少3-6个月的时间跨度,以保证知识覆盖的全面性。
4.1.3 数据收集方式
采用"自动采集+人工补充"的双轨策略:通过钉钉机器人的自动化流程实时采集工单数据并写入钉钉文档;通过钉钉文档的自动化流程将非结构化的对话文本转化为结构化数据,对于关键场景的优质案例,由工单处理人员进行人工标注和补充。
工单数据采集写入钉钉文档采用的是增量更新机制,确保一直有新数据持续流入数据集。
自动化流程里会调用AI能力节点将工单里的基础信息提取出来并写入钉钉表格里,表格里的工单内容、工单回复等信息是自动采集工单数据写入的,而补充信息则是人为补充的.为了交流处理工单的经验,我们小组会组织每周的周会都会简要过一下需要重点关注的工单,而这个过程也是建了一个专门的自动化事件定时通知大家填写补充内容。

4.1.4 数据分类体系
建立多层级的数据分类体系:按工单类型(技术排查、业务咨询、数据订正等)、按产品线/业务模块(高校采购、车辆控购、绿色建材)和按问题紧急程度等进行分类标注。分类体系需兼顾业务视角(便于人工理解)和算法视角(便于模型训练),为后续的知识库构建和AI模型训练提供标签基础。
在工单系统中,我们针对所在业务小组的实际业务需求,定制了一批特有的业务字段。当运营或技术支持人员使用行采工单模版提交工单时,会自动填写这些字段。原本我们希望这些定制字段的内容也能通过钉钉 Webhook 同步推送到工单处理群,但和研发中心沟通后发现,现有的工单系统只支持公司层面的通用字段推送,无法直接推送各业务团队自定义的业务字段。
那么,这些分类数据该如何同步到钉钉的工单回复记录表中呢?如果依赖人工逐个打开工单链接查看类别再手工回填,会给开发团队带来沉重负担。因此,我们采用了另一种实现方式:利用 tmux、launchd 和 Claude 组合,以每周一次的频率自动执行工单补充信息同步任务。具体流程如下:
- 调用钉钉 MCP,获取工单回复记录表中过去 7 天的工单记录;
- 根据每条记录中的
caseNo值,调用工单接口xxx
获取对应工单的完整数据; - 从返回的数据中提取指定节点下的分类内容;
- 再次调用钉钉 MCP,将这些分类数据回填到工单回复记录表中。
通过这套自动化流程,我们免去了人工操作的高成本和易错风险,实现了定制字段数据的定期、可靠同步。上面流程沉淀出的skill如下:
md
# 同步工单业务字段到工单回复记录表
从 iPaaS 工单接口获取业务类别、业务环节、工单类型、AI辅助回复评分,回写到钉钉 AI 表格的工单回复记录表。
## 参数
- `$ARGUMENTS`:可选,指定处理日期(格式 YYYY-MM-DD),默认处理所有缺失业务类别的记录
## 执行步骤
### 1. 定位目标 Base 和 Table
搜索"工单回复记录"Base,获取其下的数据表: - baseId 和 tableId 通过 `search_bases` -> `get_base` -> `get_tables` 链路获取
- 关键字段:
- `工单caseNo`(fieldId: xxo2LyN):工单编号,用于调用 iPaaS 接口
- `业务类别`(fieldId: WnpP0m5):待回写
- `业务环节`(fieldId: seeng6c):待回写
- `工单类型`(fieldId: UByLyNJ):待回写
- `AI辅助回复评分`(fieldId: 48nZBw1):待回写
- `工单处理时间`(fieldId: YgDD0nR):用于按日期筛选
### 2. 查询需要补充的记录
使用 `query_records` 查询工单回复记录表,筛选条件(二选一):
**按日期筛选**(当用户指定日期时):
- 由于 `createdTime` 字段的日期筛选可能不生效,建议查询全部记录后本地过滤
- 按 `工单处理时间` 降序排列,遍历全部分页(使用 cursor 翻页)
**按缺失字段筛选**(默认):
- 筛选 `业务类别` 为空的记录,优先处理 对查到的记录提取 `工单caseNo` 字段值,过滤掉 caseNo 为空的记录。
### 3. 调用 iPaaS 工单接口获取业务字段
对每条记录的 caseNo 调用接口: ``` GET xxx``` 从返回的 `result.records` 中提取两类数据: **从开始节点**(nodeExtension.nodeType = "START")的 `formInstance.fieldList` 提取(formId=96): | fieldId | 字段名 | 提取字段 | |---------|--------|---------| | 125 | 业务类别 | `showLabel` | | 126 | 业务环节 | `showLabel` | | 124 | 工单类型 | `showLabel` | **从处理节点**(formInstance.formId = 98,即"高校采管-处理工单表单")的 `fieldList` 提取: | fieldId | 字段名 | 提取字段 | |---------|--------|---------| | 127 | 小心然回复评分 | `showLabel` | > 注意:字段名是 `showLabel`(驼峰),不是 `showlabel` 如果对应节点中找不到 fieldId,可遍历所有 records 的 formInstance 查找。
### 4. 批量回写到 AI 表格
使用 `update_records` 批量更新记录,每条记录写入四个字段: ```json { "recordId": "<recordId>", "cells": { "WnpP0m5": "<业务类别 showLabel>", "seeng6c": "<业务环节 showLabel>", "UByLyNJ": "<工单类型 showLabel>", "48nZBw1": "<AI辅助回复评分 showLabel>" } } ``` 单次最多更新 100 条,超出需分批。
### 5. 输出结果汇总
展示本次同步的统计:
- 扫描记录数
- 成功回写数
- 跳过数(caseNo 为空或接口返回异常)
- 按业务类别/工单类型的分布概览
## 注意事项
- API 调用建议并行(最多 4 个并发),避免串行耗时过长
- 如果接口返回异常(如 caseNo 不存在),跳过该记录并在汇总中标注
- 已有业务类别的记录默认不覆盖,除非用户明确要求
同步之后工单回复记录表中的工单数据也就带上了它们对应的分类数据。
4.2 数据预处理流程
4.2.1 数据清洗
对原始数据进行去重、去噪处理,包括:过滤无关信息(问候语、客套话、表情符号);统一不同来源数据的字段格式。数据清洗的质量直接决定了后续知识提取的效果。

4.2.2 数据标准化
将口语化、非规范的表述转换为标准化的表达方式。例如将"咋退货"、"怎么退"统一为"退货流程";将"登不上去"、"连不上"统一为"登录失败"。通过建立同义词库和业务术语映射表,实现表述的规范化。

五、知识库构建与管理
高质量的知识库是 AI 助理工单辅助回复的核心支撑。本章介绍如何从多源数据构建结构化、可向量化检索的知识库。
5.1 知识来源整合
5.1.1 知识来源矩阵
知识库的知识来源构成一个矩阵,横向按知识类型(产品文档、工单数据、政策规范等)划分,纵向按业务领域(产品线、功能模块)划分。矩阵化管理有助于识别知识覆盖的薄弱环节,指导知识补充的优先级。
5.1.2 工单知识提取
首先,新产生的工单数据按前一章节介绍的流程经过自动化编排进行处理。而历史工单中直接依托于大模型中的NLP技术自动提取"问题-解决方案"对,识别高频问题模式和专家处理经验。对于已解决的优质工单,人工提炼为标准知识条目;对于复杂案例,保留完整的问题诊断路径作为知识链存储,供AI在类似场景中进行推理参考。

经 AI 模型解析与重构后,历史工单数据被统一转化为如下所示的问答(QA)形式,便于检索与复用
5.1.3 产品文档解析
通过文档解析工具将产品手册、操作指南、技术白皮书等非结构化文档转化为结构化知识。利用OCR和版面识别技术处理PDF、Word等格式文档,按章节和功能点进行拆解。关键技术术语和操作步骤需要打上相应的业务标签,便于语义检索。
5.1.4 代码逆向生成
在部分业务模块中,历史业务逻辑往往较为复杂。无论是撰写产品设计方案还是编写技术方案,都极度依赖人工翻阅和梳理现有代码,既费时又费力。针对这一痛点,我们设计了一套逆向 Prompt 模板,由 AI 自动过滤技术实现细节,将 Java 代码直接转化为纯业务视角的 Markdown 说明与 Mermaid 流程图。随后,利用开评标团队提供的 MCP 工具,将生成的知识内容提交至 Confluence系统,经开发人员复核后正式纳入知识库,并由钉钉 AI 助理进行学习与问答。
md
角色:你是一位资深的技术产品经理,擅长从技术实现中提炼业务价值。
任务:请帮我逆向分析项目里的cn.gov.zcy.demand.controller.cost.CostController这个入口类涉及的代码,并输出一份面向【产品经理和业务方】的产品功能文档。 帮我把生成的文档以md的格式写入到/Users/nachuan/AI逆向 下,命名参照xxx产品功能文档的格式来命名。
【项目背景】
这是一个基于Spring Boot的采购管理系统项目,核心业务是采购人发起前置审批单、需求单、生成采购任务、关联采购计划、生成采购单进行采购、在最后采购完之后发起报账单和第三方财务系统交互报账,以及最后资产入库。
【代码信息】
语言:Java 8
框架:Spring Boot (包含Controller, Service, Repository三层)
核心业务流程:我需要理解合同模版相关的完整业务逻辑。
入口类:cn.gov.zcy.demand.controller.cost.CostController
【输出要求 - 请严格按照以下结构生成Markdown文档】
# 产品功能文档:{功能名称,如:预约报账}
## 1. 功能概述
用2-3句话,从产品角度描述这个功能是做什么的,解决了用户的什么痛点。
## 2. 业务流程
分步骤描述该功能的完整业务流程(用户视角)。请使用"用户首先...然后系统...最后..."的叙述方式。
## 3. 业务规则与逻辑
请根据代码逆向推导出以下内容,并以表格或列表形式呈现:
- **配置的功能作用**:如果有,描述该配置的作用
- **核心判断条件**:例如,什么情况下需要冻结剩余经费?什么情况下释放剩余经费?
- **数据校验规则**:例如,下单时必须传哪些字段?格式要求是什么?
- **异常处理逻辑**:例如,经费不足、报账失败时,用户会看到什么提示?系统内部如何处理?
- **关键计算逻辑**:如果有,请描述,例如"报账金额 = 交易单据金额"。
## 4. 交互流程(时序图)
请生成一个Mermaid格式的时序图,展示该功能涉及的主要模块(Controller, Service, Repository, 外部服务)之间的交互顺序。用中文标注每个步骤的动作。
## 5. 数据实体关系
请列出该功能涉及的主要数据实体(如采购单、交易单据、报账单),并描述它们之间的关系(如:采购单和报账单一对多关系)。
## 6. 潜在问题与建议(可选)
根据代码分析,是否存在任何从产品角度需要考虑的边界情况或优化点?(例如:数据权限、部分失败的事务一致性等)
【补充说明】
请特别注意代码中对[某个具体逻辑,如"合同分期情况报账"]的处理,并在文档中体现。
5.2 知识结构化处理
5.2.1 知识点拆分(原子化)
将长篇文档拆解为独立的、可单独检索的知识点。每个知识点聚焦一个具体问题或一个操作步骤,长度控制在200-500字,确保AI检索和生成的精度。原子化原则:一个知识点只回答一个问题,不混杂多个主题。
5.2.2 标签体系建设
建立多维度的标签体系,包括:业务标签(所属产品/功能/场景)、内容标签(问题类型/操作类型)、关联标签(相关知识点ID)。标签体系需支持树状层级结构,便于知识分类管理和语义扩展。

5.4 知识库运营
5.4.1 定期更新机制
建立知识库的定期更新机制:工单的问题和回复内容沉淀成标准的解决方案后会于每周五让AI助理自动学习;而产品版本更新或业务规则变更一般会于每月底完成相关知识的同步更新。

六、AI 模型选择
6.1 模型选择策略
6.1.1 主流大模型对比
本系统以钉钉 AI 助理为核心交互组件,但该助理所能选用的模型较为有限,具体可选模型如下图所示:

通过网络公开资料得出参数和场景对比分析如下表:
| 模型 | 上下文窗口 | 特点 |
|---|---|---|
| 通义千问QwQ-plus | 128K | 推理增强版,擅长数学、代码和逻辑推理任务,性能较强但上下文窗口相对较小 |
| 通义千问3.0-plus | 128K | 综合均衡型,推理、速度、成本三者平衡,适合中等复杂任务 |
| 通义千问2.5-max | 32K | Max版本,处理能力较强但参数规模比Plus小 |
| 通义千问-Long | 10000K | 超长上下文窗口,专为长文档、RAG、合规等场景设计 |
| DeepSeek-V3(671B满血版) | 128K | - 综合处理能力强,尤其适合长程复杂任务 |
| ERNIE 4.0 Turbo | 128K | 中文文档理解、知识问答 |
6.2 Prompt 工程设计
6.2.1 System Prompt 设计
text
你是一个专业的行业采购专家,具备深厚的高校采购、绿色建材、车辆控购、医疗采购、科研、政法及大宗物资采购等领域的知识。 你能够熟练掌握各种采购流程和法规,提供全面、深入且准确的采购策略和建议,帮助用户优化采购方案,降低成本,提高效率。
七、钉钉 AI 助理集成应用
将 AI 能力集成到钉钉,实现工单辅助回复的完整闭环。本章介绍钉钉开放平台配置、API 对接、交互优化等实战内容。
7.1 钉钉开放平台配置
7.1.1 创建 AI 助理
在钉钉开放平台的AI助理创建页面完成基础配置:定义助理的名称、头像和描述;配置角色设定(System Prompt);选择关联的知识库;设置助理的可用范围(组织内成员/指定部门/全员)。创建完成后可通过分享链接或二维码将助理分发给企业成员使用。

7.2 辅助回复功能实现
辅助回复功能基于钉钉群自动化机器人的工作流编排实现,整体流程如下:
当用户在公司的 Zone 平台提交工单后,工单系统会通过钉钉群的 Webhook 向"工单答疑群"推送一条机器人消息。自动化机器人感知到群内新消息后,依次执行参数提取等节点操作,并向钉钉 AI 助理发起提问。
AI 助理在其知识库中检索匹配的知识内容,随后将检索结果自动发送回该群,为工单处理人员提供参考,然后工单处理人员结合个人经验和工单辅助回复去处理工单。
工单处理完毕后,自动化机器人中的工作流编排会自动将本次工单的提问与回复沉淀为知识,并定时触发 AI 助理进行学习更新,从而持续优化后续的智能回复能力。


八、效果评估与持续优化
8.1 评估指标体系
8.1.1 质量指标
关键效率指标包括:工单平均处理时长(从创建到回复的总耗时)、AI辅助回复准确率(无需人工介入即可解决的工单占比)、人工处理工单的日均处理量变化。
- 平均处理时长
- 人均处理量
- 回复准确率

8.2 反馈收集机制
建立多渠道的反馈收集机制:工单回复模版中加入AI辅助回复评分,实时收集用户反馈;定期组织工单处理人员会议,收集使用体验和改进建议。反馈数据需结构化记录,作为模型和知识库迭代优化的输入。
研发人员处理工单回复时,会给AI辅助回复打一个评分。前文提到,工单系统中的定制字段数据会定期同步至工单回复记录表,团队在每周周会上将依据该表讨论工单处理情况并收集使用建议。
8.3 持续优化循环
建立"用户提问→AI回答→人工评价→知识优化"的闭环机制。当工单处理人员对比参考了AI的回复内容后,进行工单回复时会给该条工单的小心然辅助回复打一个评分;AI助理维护负责人会对于AI无法回答或回复质量低的问题(评分低)进行统计,自动将其纳入知识缺口分析,推动新知识的补充。


九、安全与合规
内容审查确保 AI 应用交互过程中的内容安全性和合规性,对大模型输出和输入词汇进行监控,有效屏蔽不当或者敏感信息。但是钉钉的AI助理目前仅支持对模型的输出进行内容检测,它目前支持打*处理或者回复固定文案。

9.1 数据安全
在工单智能辅助回复系统中,我们大多数关心的是给AI助理的输入内容的安全合规性。在行采的业务领域里,为了便于研发人员排查问题,车辆控购类型工单里经常会提过来含有电话号码的工单,而电话号码作为私密数据是应该严格进行控制和加密的。要想实现这个加密的过程,
我们可以在上文提到的自动化流程里加入内置工具,本质就是一段Python代码,对手机号进行掩码。

10.总结
本项目的核心价值在于:在不额外投入研发资源的前提下,充分利用企业现有数字化基础设施(钉钉),以"AI+低代码"模式快速搭建了工单智能辅助系统。通过模板优化从源头提升数据质量,通过自动化流程实现知识自动沉淀,通过代码逆向等创新手段低成本构建知识库,最终实现了从"流程驱动"到"知识驱动"的工单处理模式升级,为后续全业务线的AI赋能提供了可复制的方法论与实践经验。