一、一条三天后才看到的客户消息前几天忙完一个项目的交付收尾翻手机时看到一条客户消息——三天前发来的。“系统有点问题客户资料导出时报错了。”我赶紧回复、排查、修复前后花了半小时。但真正让我介意的不是 Bug 本身而是这条消息在聊天记录里躺了三天我才看到。这不是第一次了。自由职业接单最容易被忽略的就是交付后的回访。客户的问题可能过几天才出现而我已经投入了下一个项目。没有回访计划没有工单跟踪没有满意度记录——全靠微信聊天记录和记忆力。我想做一个客户服务回访台账把客户、回访计划、问题工单和满意度放到一个 Web 页面里让售后跟项目进度一样清晰可见。二、成品首秀服务指挥台打开页面第一眼看到的就是工作台四个指标卡片直接把今天要关注的事情摆到面前待回访数量、处理中的工单、超时工单、平均满意度。右侧的工单动态列出最新提交的问题左侧的近期回访日历标出还没完成的回访计划。最下面是满意度趋势折线图服务质量好不好一眼就知道。这就是我想解决的问题——不是做一个复杂的客服平台而是让在售后这个环节出现的信息不再散落在聊天记录里。三、三条业务线串起售后闭环在动手开发之前我把售后流程理成了三条线客户线客户信息 → 服务项目 → 回访记录 → 工单历史回访线计划回访 → 执行回访 → 记录满意度工单线发现/反馈问题 → 创建工单 → 分配处理 → 解决 → 确认关闭这三条线串起来就是一个完整的售后闭环六个角色页面覆盖了完整流程页面解决的问题工作台待办集中展示一眼看到今天要做什么客户列表所有客户及其服务状态按是否已回访筛选客户详情项目、回访、工单串成一条时间线回访计划所有回访安排超期自动标记问题工单五状态流转轨道跟踪每个问题的处理进度满意度趋势折线图让服务质量变化可见四、用智能引导把业务想法翻译成代码接下来就是把上面的业务设计落地成代码。我打开飞算 JavaAI 的 IDEA 插件选择了「智能引导」模式——它最适合帮我把业务想法拆成角色、实体和页面而不是上来就生成大量无结构的代码。在输入框里敲入需求智能引导对需求做了拆解给出了四个核心实体Customer客户、Project服务项目、Followup回访记录、Ticket问题工单。下一步是表结构设计。智能引导考虑了外键关联和状态枚举接着是代码生成计划路由结构、组件树、数据层、页面布局全部列出。最后100% 进度跑完代码生成完成。五、核心功能模块工作台服务指挥台工作台是所有待办的集中入口。四个指标卡片可以直接点击跳转到对应页面——点击「待回访」进入回访计划页点击「工单」进入工单列表。回访日历用青绿色块标记已经安排的回访日期超期的会自动标记红色。客户详情时间线客户详情页把所有的服务记录——交付项目、回访记录、历史工单——串成一条垂直时间线。这样打开一个客户就能看到完整的服务脉络而不是在各个页面之间来回切换。工单状态流工单页面的横向状态轨是唯一一个只有这个项目才会出现的视觉组件。从新建到已分配、处理中、待确认、已关闭每个状态用不同颜色区分。服务负责人可以分配处理人技术支持可以领取和更新进度负责人最后确认关闭。满意度趋势每次回访完成时负责人可以记录客户满意度1-5 分。这些数据汇聚到满意度趋势页用折线图展示服务质量的变化趋势。支持按客户筛选可以查看每个客户的历史满意度变化。六、总结复盘这次开发过程飞算 JavaAI 帮我完成了三件事数据层骨架API 接口模式一键生成六个数据模型之间的关联关系客户到项目、项目到回访和工单一次成型。路由和页面框架路由配置、页面骨架和 CRUD 操作的基本结构省掉了大量重复的模板代码。状态枚举与常量工单状态、紧急程度、角色定义等琐碎但必须统一的东西AI 一次性生成到位。而真正花时间打磨的是以下几个方面状态机流转逻辑工单从新建到关闭不是简单的 CRUD每个状态之间的合法转换、操作权限的判断需要手工一点点定义。时间线数据聚合客户详情页要把项目、回访、工单三个独立数据源按时间合并排序这个聚合逻辑需要手工编写。满意度计算口径哪些回访计入满意度平均、最新的回访是否覆盖旧数据——这些口径规则涉及业务判断不是自动生成就能搞定的。对小团队来说这个服务台账的核心价值不在于功能有多强大而是把售后从「想起再做」变成了「有计划地做」。有回访计划就不会忘记联系客户有工单跟踪就不会让问题石沉大海有满意度记录就能知道服务质量是变好了还是变差了。AI 把骨架搭好了但让这个骨架有血有肉、真正运转起来的还是对这些业务关系的理解和对细节的打磨。如果你也在关注 AI 编程工具的落地可以关注 #飞算JavaAI炫技赛 #AI编程 #Java开发 #程序员日常 #技术分享