CASE 05 / ENGINEERING IN DETAIL
Dify 运营自助答疑
把运营日常查询接入 360Teams：理解问题，再调用内部接口。
问题与约束
运营经常找研发协助查询数据、状态和业务规则。我参与的项目用 Dify 识别问题、提取参数并调用已有内部接口，再通过 360Teams 机器人返回结果。我的角色是参与项目建设，与团队协作完成相关查询场景。
核心链路简化示意
以下图示为技术思路的简化表达。
- 01 / 运营提问360Teams 机器人
- 02 / 理解问题意图识别与参数抽取
- 03 / 业务查询调用已有内部接口
- 04 / 组织回复返回业务查询结果
架构取舍与实现
分开检查意图、参数和接口调用
难点运营表达的是业务问题，内部接口需要的是明确的操作类型和参数。
方案项目使用 Dify 编排意图识别、参数抽取、内部接口调用与结果回复，分别处理提问到查询结果的各个步骤。
考虑查询出错时，可以先确认意图和参数，再检查接口返回，缩小排查范围。
根据内部接口结果组织回复
难点数据、状态和规则有各自的来源，需要把语言理解和实际业务信息连接起来。
方案工作流将提取出的业务参数用于已有内部接口调用，再围绕返回结果组织回复，面向运营日常查询需求形成问答路径。
考虑回复中的业务数据有对应的接口结果可查，便于检查模型是否误读或遗漏返回内容。
通过 360Teams 提供查询入口
难点查询工具即使可用，如果入口分散，运营仍需要在多个系统之间寻找操作路径。
方案项目接入 360Teams 机器人，供运营直接提问，将数据查询、状态确认和规则答疑的工作流带入日常沟通工具。
考虑运营可在已有沟通工具中发起查询，无需为这些场景另找系统入口。
这套设计解决了什么
项目将意图识别、参数抽取和内部接口调用编排为 Dify 工作流，供运营通过 360Teams 查询数据、状态与规则。
验证关注点
- 问题表达不完整或参数缺失时，是否能够识别需要补充的信息？
- 接口权限、异常响应和空结果，是否纳入上线前的验收范围？
- 回复中的数据与业务接口返回值是否一致，能否回查对应来源？
我的职责
参与运营自助查询项目建设，围绕运营日常的数据、状态与规则查询场景协作推进。