系统难度与我们的实现
同一笔服务订单，会经过不同部门、不同终端和不同资金渠道。 页面中的按钮、表单和金额，必须理解服务类型、当前责任人、业务状态、数据权限和有效历史记录。
| 难点 | 项目中的具体实现 | 体现的能力 |
|---|---|---|
| 服务种类多，表单和流程各不相同 | 按服务模板配置字段、默认值、必填与阶段规则；PC 与 PWA 使用同一业务契约 | 复杂领域建模与可配置系统设计 |
| 多部门围绕同一订单协作 | 管家、预订、产品、机动和结算各有工作入口；流程按当前状态给出可执行动作 | 业务流程编排与角色协作产品设计 |
| 长期迭代不能改变旧单的解释 | 保存订单模板、场景和责任快照，绑定流程与策略版本；动作携带版本信息 | 版本演进与历史可追溯设计 |
| 重复点击和旧页面提交会产生冲突 | 幂等键、订单版本、运行时指纹和当前动作校验；保留提交、结果和操作事实 | 并发处理与可靠业务执行 |
| 一个账号可能承担多个岗位 | 后端计算当前工作身份的有效角色；移动端切换身份时更新权限并清理离线快照 | 身份、权限与缓存隔离 |
| 付款、消费和结算不是同一个金额 | 区分付款来源、币种、定金、成本、对客金额、商户账户和结算记录 | 财务业务理解与账务集成 |
| AI 需要与业务表单连接 | 按当前模板编译结构化字段，检查契约、类型、枚举和建议范围；保留人工采纳或拒绝 | 受业务约束的 AI 工作流集成 |
| 旧系统迁移牵涉资料、订单和资金 | 来源映射、字段口径、历史归档、资金核对、分批补缺与独立验证 | 数据治理与系统迁移工程 |
产品与业务界面
本案例优先使用项目内已有的匿名合成数据验证截图：页面来自实际项目组件，数据为示例会员、示例商户、测试车队及模拟统计。它们用于展示产品和工程实现，图中数量、金额、路线与状态不是经营成果。
PC：订单分析与运营视角
订单分析支持时间口径、统计周期、币种、服务板块、服务类型与管家维度，并展示趋势、服务分布和排行。数字背后需要统一订单、消费与结算口径，处理可见范围与金额权限，不能只把接口结果放进图表。
图为 2026-09-08 独立验证页的局部展示；原始完整截图在素材包中。所有统计值是模拟样本。
PC：车队供给与预约安排
驾驶舱把车辆、司机、当前工作安排、预约地点和行程摘要连接起来。工作状态来自排班与资源记录，地图展示预约地点；截图中的底图和人员是测试替身，不能据此判断真实车辆位置。
PC：从安排到可查的履约记录
行程记录按服务日期、司机、车辆、服务类型、订单进度和订单号检索，将实际执行人、车辆、结果记录与原订单关联。履约提交、管家确认和结算分别表达，不用一个“完成”状态覆盖全部工作。
两张车务图来自 2026-10-06 本地组件验证，原图保留“全部为测试夹具，不连接后台或数据库”的提示；本案例选取可读的界面局部。
移动端：管家创建与预订任务
管家在手机上选择服务、会员和需求，按模板补全信息并确认创建。预订人员进入自己的任务池，读取当前责任、实际处理人与动作入口。移动端围绕岗位任务组织，PC 端承担更多配置、批量操作和完整分析。
移动端：产品维护与服务资料核对
产品人员可以查询商户消费、跟进合同与资料。界面明确区分“金额未提供”和真实的零金额，并把分页结果与当前可见范围联系起来，避免缺失数据被误读成经营事实。
移动图来自 2026-10 的隔离验证，使用真实页面和合成 API 响应，未发送远端请求或真实写入。截图不是生产登录态或设备安装态验收。
系统架构
| 层级 | 分工 |
|---|---|
| PC 管理后台 | 会员、商家、服务订单、配置、审核、批量查询与运营分析 |
| 移动 PWA | 管家、预订、产品、结算和机动等岗位的任务办理、档案查询与现场工作 |
| 会员 H5 | 会员认证、账单、服务订单与预订分享等面向客户的页面 |
| 身份与公共能力 | 当前工作身份、角色权限、租户与数据范围、通知、文件访问和日志 |
| 领域服务 | 会员中心、商户资源、会员服务中心、AI、工作流及配套业务模块 |
| 数据与异步处理 | 业务记录、版本快照、动作提交、账务记录、历史映射与任务处理 |
PC 使用 Vue 3、TypeScript、Ant Design Vue、Vben 和 Fast Crud；移动 PWA 使用 Vue 3、Vant、Pinia、Dexie 与 Workbox；后端使用 Java 21、Spring Boot / Spring Cloud、MyBatis-Plus 等模块化能力。
系统采用既有平台框架。团队的业务扩展集中在行业规则、多端协作、流程执行和持续数据演进。
多端协同与后台管理
同一条服务链，按工作任务分工
| 岗位 / 领域 | 典型工作 |
|---|---|
| 会员与会籍 | 会员资料、会籍状态、权益、关系、事件、账户和资料审核 |
| 管家 | 理解客户需求、创建服务、确认信息、跟进结果、交接与客户沟通 |
| 预订 | 接收任务、联系商家、处理预订、维护凭证与结果记录 |
| 产品 | 商户、分店、合同、资料、服务政策、合作规则与资源维护 |
| 机动 | 人车资源、排班、派单、行程、履约记录与费用反馈 |
| 结算 | 账单、付款来源、消费与成本、定金和退款、对账与相关审批 |
| 主管与运营 | 服务态势、订单分析、排行、质检、异常与待办跟进 |
服务订单连接这些领域。具体部门参与、必填字段与下一动作随模板和场景变化，并非每笔订单都固定经过全部岗位。
移动端是独立的工作产品
PWA 具有岗位路由、底部导航、动态表单、消息入口、档案与任务页面，并处理手机安全区域、触控和长表单。它还支持应用资源缓存、版本更新提示，以及按账号保存的草稿和查询快照。
离线能力用于保留草稿和有限查询内容。创建订单及业务提交仍需要网络和服务端确认；工作身份变化时，旧权限下的离线快照需要清理，避免换岗后继续读取不适用的数据。
关键工程实现
模板与流程：把变化点变成可管理的规则
服务模板配置字段、枚举、默认来源、显示与校验规则；前后端围绕模板运行时处理表单。订单保留模板、场景和责任快照，并绑定相应的动作策略版本。
处理动作时，执行器检查订单版本、模板版本、策略版本与运行时指纹，并验证该动作是否属于当前可执行动作。幂等键与请求摘要用于识别同一次重复提交；相同键携带不同内容则拒绝处理。
每次提交保留来源、字段、附件和结果，再根据业务规则转移状态并记录后续处理。这样，迭代新服务规则时仍能解释旧订单为什么进入某个流程，以及谁在何时做了什么。
AI 预填：模型建议进入受控的字段流程
- 规范化客户需求文本，结合当前选择确定服务类型；不确定时要求人工选择。
- 读取当前有效模板，把允许预填的字段和字典编译成结构化契约。
- 校验模型输出的契约版本、模板运行时指纹、字段类型、枚举、引用与置信度格式。
- 忽略模板之外、敏感、系统计算和不允许预填的字段；现有值的替换受来源与规则约束。
- 返回候选字段及缺失项，由操作人员全部采纳、部分采纳或拒绝；保存采纳字段、操作人、时间及拒绝原因。
这里的 AI 能力是把自然语言转化为业务建议，并让建议接受模板、权限和人工选择约束。它不直接代替人员确认订单或资金动作；模型输出中的置信度也不等于经过校准的正确率。
财务：让金额对应业务事实
一笔服务可能涉及对客消费、成本、公司代付、客人现场付款、定金抵用、商户账户或公司卡。它们的记账主体、币种和确认时点不同，不能只用一个金额字段代表所有事实。
系统把付款来源和分项与订单及有效提交关联，并检查金额、币种和已有记录。重复执行需要复用既有来源事实，避免产生重复资金记录；账单、付款、消费与结算按对应规则组织。
这项工作体现业务与财务契约的建模能力。本案例说明已核对的实现方式，不把源码或示例界面当作全部真实资金链路的验收结果。
身份、资料与移动缓存共同维护数据边界
当前工作身份由后端解析有效角色，决定该岗位的功能权限。订单服务另核对租户和可见订单范围，敏感资料与财务信息还需要相应的字段和访问权限。
PWA 切换工作身份后更新权限，清理该账号的离线快照；更换账号时清理上一账号的离线内容。文件与证件访问结合授权和审计，截图中的部分掩码不能替代完整的数据权限设计。
旧系统迁移：迁数据，也迁业务解释
新旧系统的会员、会籍、商户、合同、订单、付款与历史流水并不天然一一对应。迁移工作需要保存来源关系，区分资料差异、等价转换、新系统新事实和待裁定冲突，并按业务明细核对金额与币种。
工程资料包含来源映射、归档、前检、分批补缺、独立后检和回滚口径。历史事实承接需要保护目标系统的新业务修改，不能以简单覆盖或汇总金额相等代替逐项核对。全量切换和最终验收仍按当前上线计划收口，不宣称已全部完成。
这项项目体现的能力
| 能力 | 专属管家项目中的体现 |
|---|---|
| 大型业务系统建设 | 会员、供应商、服务订单、车务、结算与运营的跨领域协作 |
| 产品与工程共同建模 | 把部门工作、业务场景、字段、状态和资金口径落到产品与服务 |
| 多端交付 | PC 管理、岗位 PWA、会员 H5 与后端共同使用业务契约 |
| 可配置流程与版本治理 | 模板、快照、动作策略、历史事实、版本检查与幂等执行 |
| AI 集成 | 结构化预填、引用与字段校验、人工采纳和建议审计 |
| 权限与资料保护 | 工作身份、角色、租户、订单数据范围、敏感资料和缓存边界 |
| 账务与历史数据工程 | 付款来源、币种、定金与消费规则，以及旧系统映射和核对 |
| 持续迭代与验证 | 业务契约、双端对照、针对性测试、隔离组件验收与发布记录 |
这项项目展现的是把复杂组织的工作方式转化成可维护系统的能力。 从客户需求到部门协作，再到履约、账务和历史数据，每一层都需要清楚的规则与可追溯的事实。
资料与说明
- 工程依据：
prestige主工作区的 PC、PWA、会员 H5、业务后端及 PRD / 契约 / 验证资料，整理于 2026-10-08；本次仅取证和制作案例。 - 使用七张已有原始验证截图，生成五张产品展示图；另有五张按代码和契约绘制的工程图。原始图片没有会员姓名、真实联系方式、证件、私人偏好或客户凭证。
- PC 数值、测试车队与地图，移动页面中的会员、商户和订单均为合成样本。未采用只有手机号打星、仍暴露姓名生日偏好的会员截图，也未把 ImageGen 设计稿当作实际产品截图。
- 本次检查代码、文档与图片，没有修改业务仓库、连接业务数据库、登录生产后台、执行真实订单 / 资金动作、调用在线模型或部署。历史测试与截图有各自日期，不是本次全量业务验收。
- 项目仍在持续迭代。不同模块的当前发布和验收状态，按对应版本与记录核对；不使用无法验证的营收、效率提升、测试通过率或全面完成率数字。