一、一条三天后才看到的客户消息

前几天忙完一个项目的交付收尾，翻手机时看到一条客户消息——三天前发来的。

"系统有点问题，客户资料导出时报错了。"

我赶紧回复、排查、修复，前后花了半小时。但真正让我介意的不是 Bug 本身，而是这条消息在聊天记录里躺了三天，我才看到。

这不是第一次了。

自由职业接单，最容易被忽略的就是交付后的回访。客户的问题可能过几天才出现，而我已经投入了下一个项目。没有回访计划，没有工单跟踪，没有满意度记录——全靠微信聊天记录和记忆力。

我想做一个客户服务回访台账，把客户、回访计划、问题工单和满意度放到一个 Web 页面里，让售后跟项目进度一样清晰可见。

二、成品首秀：服务指挥台

打开页面，第一眼看到的就是工作台：

四个指标卡片直接把今天要关注的事情摆到面前：待回访数量、处理中的工单、超时工单、平均满意度。右侧的工单动态列出最新提交的问题，左侧的近期回访日历标出还没完成的回访计划。最下面是满意度趋势折线图，服务质量好不好，一眼就知道。

这就是我想解决的问题——不是做一个复杂的客服平台，而是让在售后这个环节出现的信息，不再散落在聊天记录里。

三、三条业务线串起售后闭环

在动手开发之前，我把售后流程理成了三条线：

客户线：客户信息 → 服务项目 → 回访记录 → 工单历史 回访线：计划回访 → 执行回访 → 记录满意度 工单线：发现/反馈问题 → 创建工单 → 分配处理 → 解决 → 确认关闭

这三条线串起来，就是一个完整的售后闭环：

六个角色页面覆盖了完整流程：

四、用智能引导把业务想法翻译成代码

接下来就是把上面的业务设计落地成代码。

我打开飞算 JavaAI 的 IDEA 插件，选择了「智能引导」模式——它最适合帮我把业务想法拆成角色、实体和页面，而不是上来就生成大量无结构的代码。

在输入框里敲入需求：

智能引导对需求做了拆解，给出了四个核心实体：Customer（客户）、Project（服务项目）、Followup（回访记录）、Ticket（问题工单）。

下一步是表结构设计。智能引导考虑了外键关联和状态枚举：

接着是代码生成计划：路由结构、组件树、数据层、页面布局全部列出。

最后，100% 进度跑完，代码生成完成。

五、核心功能模块

工作台：服务指挥台

工作台是所有待办的集中入口。四个指标卡片可以直接点击跳转到对应页面——点击「待回访」进入回访计划页，点击「工单」进入工单列表。回访日历用青绿色块标记已经安排的回访日期，超期的会自动标记红色。

客户详情时间线

客户详情页把所有的服务记录——交付项目、回访记录、历史工单——串成一条垂直时间线。这样打开一个客户就能看到完整的服务脉络，而不是在各个页面之间来回切换。

工单状态流

工单页面的横向状态轨是唯一一个只有这个项目才会出现的视觉组件。从新建到已分配、处理中、待确认、已关闭，每个状态用不同颜色区分。服务负责人可以分配处理人，技术支持可以领取和更新进度，负责人最后确认关闭。

满意度趋势

每次回访完成时，负责人可以记录客户满意度（1-5 分）。这些数据汇聚到满意度趋势页，用折线图展示服务质量的变化趋势。支持按客户筛选，可以查看每个客户的历史满意度变化。

六、总结

复盘这次开发过程，飞算 JavaAI 帮我完成了三件事：

1. 数据层骨架：API 接口模式一键生成，六个数据模型之间的关联关系（客户到项目、项目到回访和工单）一次成型。
2. 路由和页面框架：路由配置、页面骨架和 CRUD 操作的基本结构，省掉了大量重复的模板代码。
3. 状态枚举与常量：工单状态、紧急程度、角色定义等琐碎但必须统一的东西，AI 一次性生成到位。 而真正花时间打磨的，是以下几个方面：

• 状态机流转逻辑：工单从新建到关闭不是简单的 CRUD，每个状态之间的合法转换、操作权限的判断，需要手工一点点定义。
• 时间线数据聚合：客户详情页要把项目、回访、工单三个独立数据源按时间合并排序，这个聚合逻辑需要手工编写。
• 满意度计算口径：哪些回访计入满意度平均、最新的回访是否覆盖旧数据——这些口径规则涉及业务判断，不是自动生成就能搞定的。 对小团队来说，这个服务台账的核心价值不在于功能有多强大，而是把售后从「想起再做」变成了「有计划地做」。有回访计划就不会忘记联系客户，有工单跟踪就不会让问题石沉大海，有满意度记录就能知道服务质量是变好了还是变差了。

AI 把骨架搭好了，但让这个骨架有血有肉、真正运转起来的，还是对这些业务关系的理解和对细节的打磨。

如果你也在关注 AI 编程工具的落地，可以关注 #飞算JavaAI炫技赛 #AI编程 #Java开发 #程序员日常 #技术分享