安心到家家政产品系统

“安心到家 AI 家政履约中台”是一个连接客户、家政服务人员和运营管理方的三端协同平台。 项目不仅提供线上预约，更侧重把“客户提需求、平台派单、人员上门、服务确认、费用结算、客户维护”串成完整业务闭环，并将 AI 助手嵌入日常业务操作。
本项目的立项逻辑，是解决家政服务中需求、人员、订单和服务过程相互割裂，主要依靠人工沟通协调的问题。具体包括：

账号与权限管理 用户登录、个人资料、多角色工作台切换、用户及角色权限管理
服务项目管理 服务套餐及附加项展示、服务详情查看、后台服务目录维护
预约与需求管理 服务时间和地址选择、预约下单、需求与意向提交、需求池受理及进度追踪
订单管理 订单列表与详情、状态查询、改约、取消、备注及客户确认
派单与排班管理 人员可服务时间查询、排班日历、排班模板、任务分配与调整
上门履约管理 服务人员接单、到场、开工、完工，以及服务过程记录
客户关系管理 客户档案、服务历史、客户关系维护、回访记录及跟进待办
支付与结算管理 支付状态查询、收款记录、线下收款审核、结算账单及记录查询
AI 业务助手 自然语言交互、任务与订单查询、业务办理辅助、工具授权及执行记录
即时通讯与通知 联系人、即时聊天、未读消息、公告及业务待办提醒
推广管理 推广入口、推荐关系及推广相关配置
运营与系统管理 工作台概览、附件管理、系统配置、服务监控、登录及操作审计
1. 客户端：完成从预约到服务确认的流程
客户可以浏览服务套餐和服务人员，选择时间、填写服务地址并发起预约；对于尚未明确的服务需求，也可先提交需求或意向，由运营进一步跟进。下单后可查看订单进度，并按业务规则进行改约、取消及服务确认。
2. 服务人员端：集中处理日常上门任务
服务人员通过移动工作台查看待办、任务安排和客户信息，完成接单、到场、开工、完工等操作。同时可查询客户服务历史、记录回访情况及查看收入、结算信息，减少在多个工具间切换。
3. 运营管理端：统一受理、调度和跟进
运营人员通过后台或移动工作台集中处理需求池、订单和排班，结合人员可服务时间进行派单与调整；维护服务项目、客户关系和公告，并通过工作台了解业务待办及订单处理情况。
4. AI 助手：通过对话辅助办理业务
AI 助手嵌入不同角色的工作场景，支持用自然语言查询任务、订单、客户信息和可服务时间，并在授权范围内辅助执行操作。业务执行受到角色权限、工具白名单、必要的二次确认和审计记录约束，不能绕过权限直接操作。
5. 全流程记录：让服务协作可追踪
平台以订单为主线，将客户需求、派单排班、上门履约、客户确认、收款结算和后续跟进关联起来，使各方共享业务进度，便于异常处理和运营复盘。

我主要负责项目需求梳理、业务流程设计和核心功能落地，围绕客户预约、运营派单、服务人员上门履约构建三端协同流程；参与管理后台和移动端开发、后端接口及数据模型设计，并负责 AI 业务助手接入、权限控制、系统联调、自动化测试和部署验证。

具体可以拆成四部分：
- **业务设计：**梳理预约、派单、接单、完工、结算等流程，明确角色权限和订单状态规则。
- **核心开发：**实现订单、需求池、排班、客户管理及相关前后端交互。
- **AI 能力建设：**将自然语言对话与受控业务工具连接，处理授权、确认及执行反馈。
- **质量与交付：**开展接口测试、业务回归、跨端适配和故障场景验证。
二、技术栈与架构
项目存在早期模块化单体和后续 Cloud 独立服务两套工程，介绍时建议以 Cloud 为主，不混用两套版本。
层次 主要技术
管理后台 Vue 3、TypeScript、Element Plus、Vue Router、Axios、Vite
移动端 uni-app、Vue，包含原生 App 页面及 H5 预览工程
后端 Java 21、Spring Boot 3.5.7、Spring Cloud Gateway
服务通信 Apache Dubbo、ZooKeeper
数据访问 MyBatis、MyBatis-Plus、Flyway
数据存储 MySQL，按服务划分数据库和账号；MongoDB 存储结构化运行事件
一致性与治理 Seata Saga、本地事务、Outbox、幂等控制、Resilience4j
实时交互 WebSocket 即时通讯、SSE 模型流式输出
AI 展示 Markdown-it、Highlight.js、DOMPurify
测试与构建 Maven、JUnit／MockMvc、H2、Node Test、Playwright、pnpm


整体采用前后端分离、按业务领域拆分服务的架构：
客户／服务人员移动端 + 运营管理后台
↓
Gateway 统一入口
↓
身份、目录、订单、排班、支付、结算、
客户、通讯、AI 助手、附件、审计等服务
↓
各服务独立数据库与本地事务
网关负责认证与路由，内部业务通过 Dubbo 调用；服务之间不直接共享数据库表。早期单体工程仍保留，不能将独立服务建设等同于全量生产迁移完成。
三、实现亮点
1. AI 不只回答问题，还能辅助办理业务
模型通过白名单工具查询订单、任务、客户和可约时间，并在授权范围内执行操作。写操作配有独立意图复核，必要时进行二次验证，并保留执行回执和审计记录。

亮点在于把 AI 接入真实业务，同时限制其操作边界。
2. 围绕订单构建三端协同
客户提交需求，运营受理和派单，服务人员接单并推进到场、开工、完工，客户再确认服务。不同角色围绕同一业务记录协作，而不是各端分别维护一套进度。
3. 对重复请求和异常结果做明确处理
订单创建采用幂等键和请求摘要，防止重复提交生成多张订单；订单保留价格及服务信息快照，避免后续目录变化影响历史记录。跨服务流程使用 Saga 补偿，事件通过 Outbox 记录并按具体链路投递。
四、实现难点及解决方式
难点 实现方式
多人同时预约，避免同一人员时间冲突 统一分钟级容量占用，结合数据库唯一约束、行锁和本地事务控制争抢
跨服务调用超时，无法确定远端是否成功 使用持久化幂等记录、Saga 状态和补偿机制；超时不直接视为回滚，也不盲目重试写操作
AI 多步操作部分成功、部分失败 限制工具调用次数，逐项保留成功回执；未确认的写入标记为结果未知，不自动重放
多角色的数据和操作权限隔离 网关认证之外，业务服务继续校验会话、角色和数据归属，AI 工具也遵循相同权限
H5 与原生 App 的体验一致性 对齐业务契约和角色流程，分别处理页面生命周期、登录恢复、消息连接及布局差异，并进行回归验证


项目最值得突出的技术点，是“受控 AI 业务执行”和“跨服务履约一致性”，而不只是使用了多少框架。 上述是实现机制说明，不代表真实支付渠道、全部故障场景和所有原生页面均已完成生产验收。