后台管理功能框架与底座需求
1. 文档定位
本文从需求评审和技术实现视角定义后台管理的一期功能框架、共性底座能力、系统边界和验收口径。
本文不展开具体菜单的页面字段、交互细节和业务规则。各菜单功能说明以 10-工作台需求、11-客户查询需求、12-工单中心需求、13-进件查询需求、14-借款与还款查询需求、15-退费减免需求、20-后台用户需求、21-角色与App数据范围需求、22-审计日志需求 为准。技术架构、服务拆分、接口约定和部署方案详见 99-后台管理技术实现方案。
本文评审重点：
- 一期后台要交付哪些菜单和共性底座。
- 菜单之间依赖哪些统一对象、权限、数据路由和审计能力。
- 技术实现必须满足哪些安全、可追溯、可扩展和可运维要求。
- 哪些能力明确不进入一期，避免需求评审时误扩大范围。
2. 一期建设范围
2.1 一期纳入范围
一期后台管理面向现金贷客服、运营支持和系统管理员，覆盖以下能力：
| 一级菜单 | 二级菜单 | 一期定位 | 对应需求文档 |
|---|---|---|---|
| 总览 | - | 文档入口、范围说明、菜单与文档索引 | 00-总览 |
| 工作台 | - | 个人待处理事项、客户服务运营概览、风险提醒入口 | 10-工作台需求 |
| 客户服务 | 客户查询 | 以客户为中心查询基础信息、进件、借款、还款、工单和处理记录 | 11-客户查询需求 |
| 客户服务 | 工单中心 | 客服工单创建、跟进、处理、关闭和查询 | 12-工单中心需求 |
| 业务查询 | 进件查询 | 进件申请查询、状态追踪、审批/风控摘要展示 | 13-进件查询需求 |
| 业务查询 | 借款与还款查询 | 借款、还款计划、还款记录、扣款状态和异常定位 | 14-借款与还款查询需求 |
| 补救处理 | 退费减免 | 客户退费、减免等补救动作的申请、校验、执行和记录 | 15-退费减免需求 |
| 系统管理 | 后台用户 | 后台账号生命周期、状态、安全策略和人员信息维护 | 20-后台用户需求 |
| 系统管理 | 角色与App数据范围 | 角色权限、菜单权限、操作权限、App 数据范围配置 | 21-角色与App数据范围需求 |
| 系统管理 | 审计日志 | 后台访问、查询、操作、配置变更和敏感数据访问追踪 | 22-审计日志需求 |
2.2 一期不纳入范围
以下能力不作为一期交付范围，若后续纳入需单独评审：
- 审批中心和通用审批流平台化能力，详见 08-审批中心与审批流程需求。
- 手机分期、线下门店、营销活动、催收作业等非现金贷客服后台场景。
- 面向业务人员开放 App/产品线注册、数据源接入、字段映射等配置页面。
- 直接修改核心账务、还款计划、放款结果、清结算结果的后台入口。
- 跨系统批量导入、批量修改、批量执行补救动作。
- 通用 BI 报表、复杂经营分析和可视化看板。
2.3 评审结论口径
需求评审通过时，应确认以下结论：
- 原型菜单、需求文档和技术实现边界一致。
- 每个菜单均有明确用户、查询对象、操作动作、权限要求和审计要求。
- 所有跨菜单能力均落到底座能力，不在单个页面重复实现。
- 涉及客户隐私、资金、账务、减免、退费的能力必须具备权限校验、服务端校验、幂等控制和审计留痕。
3. 功能框架
3.1 功能分层
后台管理按以下四层组织：
| 层级 | 职责 | 一期内容 |
|---|---|---|
| 前端壳层 | 登录态承载、导航、路由、页面权限、全局交互 | 左侧菜单、顶部用户信息、页面级权限拦截、全局空态/异常态 |
| 业务菜单层 | 面向客服和运营的具体工作页面 | 工作台、客户查询、工单中心、进件查询、借款与还款查询、退费减免 |
| 管理配置层 | 管理后台用户、角色、数据范围和审计 | 后台用户、角色与 App 数据范围、审计日志 |
| 共性底座层 | 为所有菜单提供统一身份、权限、路由、聚合、审计和安全能力 | 登录会话、RBAC、App 数据范围、数据源路由、审计日志、敏感信息脱敏 |
3.2 菜单与底座依赖
| 菜单 | 依赖的底座能力 | 评审关注点 |
|---|---|---|
| 工作台 | 登录用户上下文、角色权限、App 数据范围、工单/补救聚合指标 | 指标必须按当前用户可见范围计算，不能展示越权统计 |
| 客户查询 | App 数据范围、客户统一索引、数据聚合、敏感信息脱敏、查询审计 | 查询入口必须校验权限，敏感字段默认脱敏 |
| 工单中心 | 用户权限、客户上下文、工单状态机、操作审计 | 工单操作必须记录处理人、处理时间、状态变化和备注 |
| 进件查询 | App 数据范围、进件数据适配、状态映射、敏感信息脱敏 | 只读查询，不允许后台直接改进件核心状态 |
| 借款与还款查询 | 借款/还款数据聚合、资金流水展示、异常状态映射、查询审计 | 资金相关字段展示需可追溯来源，异常状态不可被前端自行推断 |
| 退费减免 | 操作权限、服务端规则校验、幂等控制、审计日志、结果回写 | 所有资金或权益影响动作必须后端二次校验 |
| 后台用户 | 用户生命周期、状态控制、登录安全、账号审计 | 禁用用户必须即时失效或在技术方案中明确失效延迟 |
| 角色与 App 数据范围 | 菜单权限、操作权限、数据范围、权限生效机制 | 权限配置变更必须可审计，并明确生效时机 |
| 审计日志 | 日志采集、日志查询、日志留存、敏感字段保护 | 审计日志不可被普通业务角色修改或删除 |
4. 统一对象模型
后台管理需要在各菜单之间保持统一对象口径，避免同一业务对象在不同页面使用不同标识或不同状态定义。
| 对象 | 统一标识 | 说明 |
|---|---|---|
| App/产品线 | app_id | 用于权限范围、数据路由、页面筛选和审计留痕 |
| 后台用户 | admin_user_id | 后台登录、操作、审计和权限判断的主体 |
| 角色 | role_id | 菜单权限、操作权限和数据范围的授权载体 |
| 客户 | customer_id / global_customer_id | 客户查询、工单、进件、借款、还款和补救处理的关联主体 |
| 进件 | application_id | 进件查询、客户 360、工单关联的业务对象 |
| 借款 | loan_id | 借款详情、还款计划、还款记录、补救动作的关联对象 |
| 还款记录 | repayment_id / repayment_ref | 还款流水、扣款异常和补救处理的定位依据 |
| 工单 | ticket_id | 客服跟进、处理闭环和操作审计的对象 |
| 退费减免单 | remedy_id | 补救动作申请、执行、结果回写和审计追踪的对象 |
| 请求链路 | trace_id | 跨前端、网关、业务服务、审计日志的问题定位标识 |
技术实现要求：
- 前后端接口必须返回稳定的业务主键，不允许仅依赖展示字段跳转或关联。
- 跨菜单跳转应携带业务主键和必要查询上下文，不通过页面标题、客户姓名、手机号明文等展示字段做关联。
- 状态字段必须由后端输出标准枚举和展示文案，前端只负责展示，不自行推导关键业务状态。
5. 共性底座能力需求
5.1 身份与会话
后台用户必须通过统一登录入口进入系统。登录成功后，系统应建立后台用户上下文，包括用户 ID、姓名、角色、可访问菜单、可执行操作、可见 App 范围和会话有效期。
实现要求：
- 所有后台 API 必须校验有效登录态。
- 后端不得信任前端传入的用户身份、角色和数据范围。
- 用户禁用、角色解绑、权限回收后，系统必须明确权限失效机制。
- 会话超时、登录失效、无权限访问时，前端应按 03-后台管理交互说明 展示统一提示。
5.2 权限与 App 数据范围
后台权限由角色权限和 App 数据范围共同决定：
最终可访问范围 = 用户有效角色权限 ∩ 用户可见 App 数据范围 ∩ 当前菜单/操作服务端校验结果权限需要覆盖：
| 权限类型 | 示例 | 控制位置 |
|---|---|---|
| 菜单权限 | 是否可见客户查询、退费减免、审计日志 | 前端展示 + 后端接口 |
| 页面权限 | 是否可进入详情页、客户 360、配置页 | 前端路由 + 后端接口 |
| 操作权限 | 创建工单、关闭工单、提交退费、禁用用户 | 后端强校验 |
| 字段权限 | 查看手机号、证件号、银行卡等敏感字段 | 后端脱敏策略 + 前端展示 |
| 数据范围 | 可查看哪些 App/产品线数据 | 后端查询条件和数据路由 |
评审要求：
- 不允许只在前端隐藏按钮来实现权限控制。
- 查询类接口也必须校验 App 数据范围。
- 系统管理能力应与普通客服能力隔离，避免客服角色访问用户、角色、审计配置。
- 角色与数据范围的配置、变更、启停必须写入审计日志。
5.3 数据源路由与查询聚合
后台菜单会查询客户、进件、借款、还款、工单和补救处理数据。技术实现应通过统一的数据路由和聚合服务封装数据来源差异。
路由要求：
| 查询场景 | 路由依据 | 输出要求 |
|---|---|---|
| 按客户查询 | App 范围、手机号/客户 ID/证件号等查询条件 | 返回客户列表和可进入详情的业务主键 |
| 按进件查询 | App 范围、进件号、客户、状态、时间 | 返回标准进件状态和关键摘要 |
| 按借款查询 | App 范围、借款号、客户、状态、时间 | 返回借款主数据、计划、还款摘要 |
| 按还款记录查询 | App 范围、还款引用号、扣款状态、时间 | 返回还款记录、通道状态和异常原因 |
| 按工单查询 | 当前用户权限、App 范围、工单状态、处理人 | 返回工单列表、状态和关联业务对象 |
| 按补救单查询 | 操作权限、App 范围、客户/借款/还款对象 | 返回补救单状态、校验结果和执行结果 |
实现要求：
- 前端不直接拼接多个业务系统接口形成最终业务结论。
- 后端聚合服务应输出标准字段、标准状态和数据来源标识。
- 当部分数据源异常时，应返回可识别的部分失败状态，不得将系统异常包装为“无数据”。
- 关键查询必须写入审计日志，记录查询人、查询条件摘要、App 范围、结果数量和 trace_id。
5.4 敏感信息保护
客户手机号、证件号、银行卡、联系人、地址、设备信息、风控命中原因等信息均属于敏感信息。
实现要求：
- 默认展示脱敏值，只有具备对应字段权限的用户才允许查看明文或发起解密查看。
- 敏感信息明文查看必须记录审计日志。
- 列表页原则上不展示完整敏感字段。
- 导出能力如后续开放，必须单独评审导出权限、字段范围、审批机制和审计留痕。
5.5 审计日志
后台审计必须覆盖查询、查看、配置、操作和异常五类行为。
| 行为类型 | 示例 | 必须记录 |
|---|---|---|
| 查询行为 | 查询客户、查询进件、查询借款还款 | 操作人、时间、查询条件摘要、App 范围、结果数量 |
| 查看行为 | 打开客户详情、查看敏感字段 | 操作人、客户/业务对象、字段类型、trace_id |
| 配置行为 | 新增用户、修改角色、调整 App 范围 | 变更前后摘要、操作人、审批/授权依据 |
| 业务操作 | 创建工单、关闭工单、提交退费减免 | 业务对象、动作、请求参数摘要、结果 |
| 异常行为 | 无权限访问、接口失败、幂等冲突 | 异常码、异常描述、trace_id |
审计日志不得被普通业务角色修改或删除。日志留存周期、归档策略和查询性能要求在技术实现方案中明确。
5.6 补救动作安全底座
退费、减免等补救动作会影响客户权益或资金结果，必须作为高风险操作处理。
实现要求：
- 前端只负责提交操作意图，后端负责规则校验和最终执行。
- 后端必须校验操作人权限、App 范围、客户状态、借款状态、还款状态、金额边界和重复提交。
- 同一业务对象的重复提交必须具备幂等控制。
- 操作结果必须可追踪，包括成功、失败、处理中、需人工复核等状态。
- 一期不建设通用审批中心时，高风险动作仍需保留后续接入审批流的扩展点。
6. 前后端职责边界
| 能力 | 前端职责 | 后端职责 |
|---|---|---|
| 菜单与路由 | 根据权限展示菜单、处理跳转和空态 | 返回当前用户可访问菜单和页面权限 |
| 权限控制 | 隐藏无权限入口、提示无权限状态 | 对所有接口做权限和数据范围强校验 |
| 数据查询 | 提交查询条件、展示标准结果 | 执行数据路由、聚合、状态映射和脱敏 |
| 状态展示 | 展示后端返回的状态枚举和文案 | 输出标准状态、异常码和解释字段 |
| 业务操作 | 采集操作参数、展示结果 | 完成服务端校验、幂等、执行和审计 |
| 审计日志 | 传递 trace_id 和必要上下文 | 生成、存储、查询和保护审计日志 |
评审原则：
- 涉及权限、金额、状态、客户身份、账务结果的判断必须在后端完成。
- 前端不得通过本地缓存或隐藏字段绕过服务端校验。
- 所有操作接口必须具备明确成功、失败、处理中和重试语义。
7. 非功能要求
| 类型 | 要求 |
|---|---|
| 安全性 | 后台 API 全量鉴权；敏感字段脱敏；高风险操作强校验；审计日志不可篡改 |
| 可追溯 | 查询、查看、配置、操作均可通过 trace_id 和业务主键追踪 |
| 可扩展 | App 数据范围、菜单权限、操作权限支持后续增加产品线和角色 |
| 一致性 | 同一业务对象在不同菜单使用统一主键、统一状态、统一展示口径 |
| 可用性 | 部分数据源异常时明确提示异常来源，不将异常误判为无数据 |
| 可运维 | 接口错误码、日志、链路 ID、慢查询和异常统计可用于问题定位 |
| 性能 | 列表查询必须分页；复杂聚合查询应控制默认时间范围和结果数量 |
8. 需求评审清单
需求评审时逐项确认：
- 原型菜单是否均有对应需求文档，且文档名称与菜单一致。
- 每个菜单是否明确用户角色、入口、查询条件、列表字段、详情字段、操作动作、状态流转和异常提示。
- 每个查询入口是否明确 App 数据范围和敏感字段脱敏要求。
- 每个业务操作是否明确服务端校验、权限要求、幂等要求和审计要求。
- 后台用户、角色、App 数据范围、审计日志是否足以支撑一期所有菜单。
- 与资金、账务、减免、退费相关的需求是否明确不可直接修改核心账务数据。
- 审批中心是否作为后续考虑，不阻塞一期闭环。
9. 技术实现评审清单
技术方案评审时逐项确认：
- 是否存在统一后台网关或服务入口承载鉴权、权限、trace_id 和审计上下文。
- 是否由后端统一返回当前用户菜单权限、操作权限和 App 数据范围。
- 是否所有接口都在后端校验权限和数据范围，而不是仅依赖前端控制。
- 是否有统一数据路由和聚合层，避免前端直接拼接多个业务系统结果。
- 是否有标准状态枚举、错误码、异常提示和部分失败处理机制。
- 是否明确敏感字段脱敏、明文查看授权和审计记录方式。
- 是否明确用户禁用、角色变更、权限变更后的生效机制。
- 是否明确审计日志的存储、查询、留存、权限隔离和防篡改策略。
- 是否明确高风险操作的幂等键、重复提交处理和结果查询机制。
10. 待确认事项
| 编号 | 待确认事项 | 影响 |
|---|---|---|
| TBD-01 | 一期是否需要开放任何列表导出能力 | 影响字段权限、导出审计和数据安全评审 |
| TBD-02 | 用户禁用、角色变更后的权限失效是否要求实时生效 | 影响会话缓存、权限缓存和强制下线设计 |
| TBD-03 | 客户统一索引是否已有稳定服务，还是一期由后台聚合服务临时承载 | 影响客户查询、客户 360 和跨菜单跳转 |
| TBD-04 | 退费减免是否需要一期接入人工复核，还是仅保留后续审批扩展点 | 影响操作状态、权限配置和审计口径 |
| TBD-05 | 审计日志留存周期和查询范围是否有合规要求 | 影响存储容量、归档策略和查询性能 |