金融系统 on Saiga

金融级流程页面的稳定性设计：草稿、断点恢复与幂等提交

wuwenzen@outlook.com (wuwj) — Fri, 05 Sep 2025 00:00:00 +0000

背景

金融业务系统中的流程页面常见特点：

多步骤（信息填写、声明确认、材料上传、结果确认）
强状态依赖（前置条件与联动校验）
允许中断（网络、切换页面、超时、权限刷新）

流程页一旦不稳定，会直接带来：重复提交、数据丢失、用户放弃率上升。

1. 草稿体系：让中断变成常态能力

本地草稿（默认）

保存频率：输入节流 1–2 秒
存储：localStorage/IndexedDB（按体量选择）
过期：按时间或版本号过期，避免脏数据长期存在

服务端草稿（可选）

适用于：换设备继续、跨端协作、需要留痕的场景。

建议组合策略：本地即时保存 + 步骤完成时服务端持久化。

2. 断点恢复：最小可用状态模型

建议状态模型包含：

当前步骤 step
已完成步骤 completedSteps
草稿数据 draft
最近保存时间 lastSavedAt
版本号 schemaVersion（字段变更时用于迁移）

页面进入时：

检测草稿是否存在
校验版本号，必要时做迁移/清理
恢复到上次步骤并回显数据

3. 幂等提交：避免重复提交与脏数据

幂等通常需要前后端配合，但前端可以先做三件事：

提交按钮防抖与禁用（loading 状态）
为关键请求生成 idempotencyKey（一次提交一次 key）
请求失败时明确失败原因与可重试策略

幂等 key 的建议组成：

用户标识（脱敏）
业务对象 id（如流程实例 id）
时间窗口（例如分钟级）
随机盐

4. 校验与提示：让用户知道“为什么不能继续”

建议将校验分为：

字段级（即时/离焦）
步骤级（提交前聚合）
流程级（前置条件、状态校验）

错误展示策略：

顶部给错误概览
定位第一个错误并滚动到字段
提示文案采用“动作 + 原因”结构（可执行）

5. 可观测性：关键链路必须可追踪

流程页建议至少埋三类指标：

成功率：每步通过率、最终提交成功率
失败分布：失败原因码、接口错误码
中断点：用户在哪一步退出/超时/刷新

并用 traceId 串联前后端日志，方便排查“为什么卡在某一步”。

规则 + AI：金融系统提示与说明文案的可控生成方案

wuwenzen@outlook.com (wuwj) — Sun, 15 Jun 2025 00:00:00 +0000

背景

金融系统的提示与说明文案通常具备三个特征：

高频：表单校验、流程阻断、异常提示随处可见
高一致性要求：不同页面需要同口径
变更成本高：规则变了，文案要跟着同步

AI 可以提升“生成与维护效率”，但必须保证输出可控、可审计、可回退。

核心原则：规则负责判断，AI 负责表达

判断层输出结构化事实

判断层输出类似：

{
  "code": "FIELD_REQUIRED",
  "severity": "high",
  "facts": { "field": "联系地址", "step": "基本信息" },
  "actions": ["补全字段", "返回修改"]
}

表达层仅消费结构化事实

AI 的输入仅包含：

code / severity / facts / actions
已批准短语库（approved phrases）
输出格式约束（字数、必含字段名、禁用词）

AI 不允许：新增事实、改写关键字段名、改变严重等级。

一套可落地的生成链路

规则系统产出结构化结果（可测试）
模板生成“骨架文案”（可兜底）
AI 在骨架上做表达优化（可选）
输出校验：禁用词、字段覆盖、长度与格式
失败即回退到模板文案，并记录日志

文案治理：短语库与术语表的作用

很多“口径问题”不是 AI 造成的，而是系统本身没有统一表达。

建议建设两类资产：

术语表：名词统一（字段名、步骤名、产品名）
短语库：标准句式（建议、引导、阻断提示）

AI 的主要任务是：在短语库与结构化事实之间“组合与改写”，而不是自由发挥。

前端落地建议

封装统一接口：hintService.getHints(context)
超时与降级：AI 超时直接展示模板结果
缓存：相同 code + facts 可缓存一段时间
UI 明确：高风险提示使用 Banner/Modal，低风险使用 Inline/Toast

最小评测集：让效果可验证

按提示码准备样例集：

缺失字段
条件必填
流程阻断
异常错误码解释

评估维度：

金融业务系统的前端权限与操作可追溯：设计要点与落地方式

wuwenzen@outlook.com (wuwj) — Tue, 25 Mar 2025 00:00:00 +0000

背景

在金融业务系统中，“能不能做”与“做了什么”通常同等重要：

权限需要细粒度（页面、模块、动作）
高风险操作需要二次确认与留痕
线上问题需要可追溯（谁、在何时、做了什么）

前端并非审计的最终来源，但前端是“入口层”，对降低误操作与提升可追溯性非常关键。

1. 权限模型：动作权限作为最小单元

推荐以“动作权限”作为最小单元（而不是只做菜单/页面）：

{
  "resource": "order:review",
  "actions": ["view", "approve", "reject", "export"]
}

落地到前端的三层控制：

路由守卫：控制页面是否可进入
组件/指令：控制按钮、入口是否可见/可用
请求层兜底：对敏感接口做二次校验（避免绕过 UI）

2. 操作风险分级：不同级别用不同交互

建议对操作做风险分级（示例）：

低风险：查询、查看详情
中风险：提交、发起流程、修改关键字段
高风险：审批通过、批量处理、导出敏感数据

不同级别对应不同交互策略：

中风险：二次确认 + 明确影响范围
高风险：强确认（输入关键字/再次校验）+ 明确告知留痕

3. 操作留痕：前端如何参与“可追溯”

前端侧建议做三件事：

3.1 为关键动作生成 traceId

每次关键操作生成 traceId
随请求携带到后端
前后端日志用同一 traceId 串联

3.2 标准化审计字段（脱敏）

建议上报结构化字段：

action（动作编码）
resource（资源编码）
targetId（业务对象 id）
result（success/fail）
reason（失败原因码）

避免：把敏感字段明文写入日志/埋点。

3.3 失败也要可追溯

很多事故来自失败重试与重复提交：

失败原因要可读（错误码映射）
可操作指引要明确（下一步做什么）
必要时提供“一键复制 traceId”入口，方便支持排查

4. 误操作防护：前端的“最后一道门”

常见防护手段：

按钮防抖 + 请求幂等 key（避免重复提交）
表单关键字段修改提示（脏数据提示）
高风险操作的预检查（权限、状态、前置条件）
批量操作的预览（影响范围、条数、筛选条件回显）

5. 可维护性：权限与路由不要绑死在页面

建议将权限控制抽象成“能力层”：