售后助手主要针对售后场景进行设计，涵盖了多个关键功能。具体而言，它包括车辆故障识别、提供相应的修理建议、预约维修服务以及通过电子邮件通知等功能，旨在为用户提供高效、便捷的售后服务体验。除了支持常规的自然语言沟通外，助手还深度集成了后端数据交互机制，确保用户的隐私信息得到充分保护。在数据处理和信息交互过程中，除了依赖大型模型的智能支持，整个系统的架构已经实现了私有化部署，以更好地保障数据的安全性和隐私性。
以下是售后顾问助手的详细介绍，以及它如何在实际应用中提供高效的售后服务支持。
技术方案
功能一览
首先，为了加速开发过程并确保用户体验，我们决定以 Dify 可视化界面作为主要载体，结合其直观易用的特点进行前端设计。然而，核心的流程部分，尤其是涉及数据库操作和业务逻辑的部分，我们采用了 Spring AI 框架进行开发。该框架能够为我们提供强大的后端支持，确保系统的高效性和可扩展性。接下来，简要介绍一下当前智能助手的主要功能模块：
- 汽车故障查询：该功能支持两种沟通方式，用户可以通过自然语言对话与系统进行互动，或者直接上传故障车辆的图片，系统会自动识别并分析图片内容，从而快速提供故障原因和修复建议。
- 维修店查询：助手能够根据用户当前位置或提供的地点信息，查询附近的维修店并展示相关信息，帮助用户快速找到就近的维修服务。
- 维修预约管理：用户可以在系统中输入相关的预约信息，包括姓名、邮箱、车辆信息等。系统会将这些信息保存到数据库中，以便进行后续的预约管理和服务跟踪。
- 邮箱通知：当用户预约维修信息时，系统会自动通过邮件通知用户。
Dify+Spring AI
在后台开发的过程中，为了确保系统能够实现快速迭代和灵活的功能更新，我们选择了dify的Chatflow方式来进行开发。该工作流方式能够支持实时更新，从而加速开发周期，并有效应对需求变更。
在以Spring AI为底层框架的Java项目中，我们特别关注如何避免提示词模板的更新导致整个系统重启的问题。为此，我们引入了Nacos作为配置管理中心，通过Nacos实现提示词的实时更新，确保无需重启服务即可快速适应模型的更新和限制。
此外，Spring AI的架构设计有效降低了开发的技术门槛，使得具备MVC开发经验的开发人员也能够轻松上手并参与开发工作。数据库操作方面，项目使用了MyBatis-Plus作为ORM框架，借助其简洁且高效的操作方式，快速访问和处理数据库中的数据，从而确保用户数据的实时保存与精准管理。
邮箱通知
最后，项目中采用了邮箱通知的方式来向请求预约的客户发送确认信息，这不仅有效避免了客户对大模型预约确认信息可能产生的疑虑和不信任感，还提高了用户体验的可信度和透明度。
为了确保邮件内容的一致性和高效生成，我们使用了预设的HTML邮件模板。在大模型的函数调用过程中，我们通过动态替换必填参数，自动生成个性化且准确的邮件内容，从而实现邮件的稳定性、可靠性和快速发送。
实战演示及解析
知识库维护
为了更好地将我们的业务场景结合呈现给用户，这里简单的维护了一个知识库小文档方便演示，只单单测试下应用场景，如图所示：
在后续的工作中，我们将引用该知识库文档作为助手回答的基础性参考资料，为用户提供更加准确和专业的解答。
必填信息
为了能够更高效地服务客户，在开始对话时，我们预设了几个关键的必填项，以确保能够尽快获取到必要的客户信息。这些必填项包括但不限于：客户的称呼、邮箱地址以及当前的居住地址。为了便于本次演示，简化了操作，仅列出了两个城市选项：北京市和上海市。如图所示：
为了更好地帮助用户理解，特地为大家准备了一个简短的开场白，旨在简单介绍一下售后助手的各项能力和功能，方便大家对其有一个初步的了解。如图所示：
汽车故障/使用类问题
首先，为了帮助大家更好地了解售后助手的基本功能，我们将从最基础的打字沟通开始进行简单的测试。为了便于演示和操作，我们在开场白部分特别设置了一个预设问题，只需要点击该问题即可快速进入。
在这一部分，主要测试了知识库引用和联网搜索功能。目前知识库中仅维护了一些基本的内容，并未大规模地积累和整理大量的知识片段供用户检索，因此，实际命中的场景相对较少。为了更好地展示这一功能，我们特别将一个常见的问题进行了预设，用户可以直接点击进行测试，便于更直观地理解这一部分的应用。
接下来，将进行图片理解功能的简要测试。考虑到许多客户在描述问题时可能不太擅长文字表达，售后助手也特别提供了图片理解功能，帮助用户通过图片进行问题描述。测试效果如图所示
在这一部分，我们进行了简单的测试，涵盖了一些用户常见的使用场景。例如，许多新手司机对于车辆仪表盘上的各种指示灯感到困惑，此外，外部剐蹭的智能分析也是一个常见的需求，尤其是在日常行车过程中，用户可能不太清楚外表受损的程度和修复建议。我们通过智能分析技术，提供了对剐蹭痕迹的自动识别与评估，以便更好地帮助用户了解车辆的外观状况并给出相应的处理建议。
故障报修
由于这一部分涉及到用户的数据保存与查询操作，我们决定采用Spring AI来接收并处理用户的自然语言输入，以便对其进行语义分析和理解。此过程中，前提是dify需要将所有相关且有效的数据准确传递到后端进行进一步处理。如图所示：
为了确保数据的完整性和避免大模型的错误调用，除了在提示词中进行数据校验之外，我们的函数内部还需要再次进行严格的校验。这样可以确保输入的数据格式和内容都符合预期，避免由于数据问题导致模型的错误调用或不准确的结果。具体实现可以参考如下示例：
通过这种方式，基本上可以确保函数的正确调用，从而有效避免了存储错误信息的情况，并且减少了因错误调用导致的频繁邮件通知。这不仅提高了系统的稳定性，还能够优化资源的使用，避免不必要的重复操作。实际效果可以参考下方的图示：
接下来，我们可以检查邮件是否成功发送并及时通知到我们。通知效果如图所示：
预约信息查询
用户完成预约后，通常会有查询需求。在此场景下，我们进行了一定的优化。由于用户查询的目的仅是展示预约信息，且没有太多额外的提示需求，我们在查询数据后，采用了自定义拼接的Markdown表格形式进行展示。这样可以有效避免在无意义的场景中浪费更多的token，提升系统性能。效果如图所示：
当前系统版本暂未支持删除和修改操作，用户仅能执行新增和查询功能。
经销商信息
这些经销商信息属于公司内部的敏感数据，因此我们在处理这部分数据时，采用了Spring AI后端项目进行开发。为了保证数据的安全性和稳定性，我们仅提供了基本的查询功能来满足用户的需求。效果如图所示：
为了更好地满足用户可能存在的搬迁需求，我们需要提供迁移经销商的功能。这样，当用户迁移时，我们能够及时更新客户默认选择的经销商信息，避免在后续的维修单中仍然显示旧的经销商信息，从而防止给用户带来不必要的困扰和混淆。效果如图所示：
由于在内部判断过程中涉及到"经销商"字样，因此用户在选择经销商时，必须确保选择的名称中包含"经销商"这一字样。否则，可能导致大模型无法准确判断，从而产生错误的结果。
其他类型问题
为了有效防止用户将我们的售后顾问助手误用为闲聊助手，从而导致不必要的 token 费用支出，我们特别设计并实施了相关的判断和限制机制。效果如图所示：
缺陷和不足
介绍完刚才的所有功能后，我们的助手当前的缺陷也较为明显，以下几点需要在未来开发中加以注意和优化：
- 用户提问与回复的模版要求：为了保证助手能够准确理解并有效回应，用户的提问和回复需要尽量符合预设的模板。如果用户的表述过于简略或模糊，可能会导致大模型做出错误判断，从而中断原有的提问流程，并污染上下文记忆，影响后续对话的准确性和连贯性。
- 工作流中断与用户等待处理：虽然dify支持私有化部署，但目前仍无法像coze那样实现中断工作流并在等待用户回答后继续执行。这个功能的缺失限制了助手在更复杂、动态工作流中的适应性和灵活性。
- 提示词模板微调的时间成本：由于缺乏足够的提示词微调经验，我们在优化过程中发现，微调提示词所需的时间远远超过了初期开发的预期。这不仅影响了开发效率，也给后续优化带来了较大的挑战，需要进一步积累经验和优化策略。
- 维修预约信息的管理不足：当前系统还未提供对维修预约信息的删除与修改操作，这在实际应用中可能导致数据的滞后或不准确，影响用户体验。因此，亟需完善该功能，以便更好地满足用户需求和实际业务场景。
这些问题的存在需要在后续版本中持续关注和优化，确保助手在功能全面性和用户体验方面逐步提升。
我是努力的小雨，一个正经的 Java 东北服务端开发，整天琢磨着 AI 技术这块儿的奥秘。特爱跟人交流技术，喜欢把自己的心得和大家分享。还当上了腾讯云创作之星，阿里云专家博主，华为云云享专家，掘金优秀作者。各种征文、开源比赛的牌子也拿了。
💡 想把我在技术路上走过的弯路和经验全都分享出来，给你们的学习和成长带来点启发，帮一把。
🌟 欢迎关注努力的小雨，咱一块儿进步！🌟