Frontend 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. 可维护性：权限与路由不要绑死在页面

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

AI 作为前端工程助手：代码理解、变更评审与知识沉淀

wuwenzen@outlook.com (wuwj) — Mon, 20 Jan 2025 00:00:00 +0000

背景

在中大型前端项目中，效率瓶颈往往不在“写代码”，而在：

理解既有代码与历史决策
做变更评审与影响面分析
将经验沉淀为可复用的规范与模板

AI 更适合作为“工程助手”，在不改变既有流程的前提下，降低理解成本与重复劳动。

适用场景与边界

适合让 AI 介入的事情

读代码：梳理模块关系、数据流、关键入口
查影响：对改动点做潜在影响面清单
写评审：生成 code review 的检查项与风险点
做沉淀：把零散讨论转成可检索的技术记录

不适合直接交给 AI 的事情

关键逻辑的“正确性判定”
业务规则的决策与归因
以 AI 输出作为唯一结论（必须可验证）

一套可落地的使用流程

1）代码理解：先结构化，再总结

输入给 AI 的材料建议是“可验证的事实”，例如：

目录结构（关键模块）
入口文件（router/store/bff client）
关键类型定义与接口契约
相关提交 diff（而非整仓库）

期望 AI 输出的格式建议固定为：

模块职责清单（What）
调用链路（How）
关键假设与隐含约束（Why）
潜在风险点（Risk）

这样更像“工程笔记”，而不是泛泛解释。

2）变更评审：用“清单化”替代口头经验

对每个变更（PR/commit）生成一份固定结构的评审清单：

影响页面/模块
影响数据结构/接口
兼容性（旧字段/旧接口/旧路由）
性能点（渲染、列表、长任务）
观测点（埋点、错误、关键链路）
回滚策略（开关/版本/兜底）

AI 的价值在于“补盲”，而不是“替代审查”。

3）知识沉淀：把对话变成可检索资产

建议把以下内容自动化沉淀（写入 Markdown）：

模块说明（README）
常见问题与排查路径（FAQ）
关键决策记录（ADR：Architecture Decision Record）
发布与回滚手册（Runbook）

沉淀策略：少而精，优先覆盖高频问题与关键链路。

工程化落地建议

统一 Prompt 模板：减少输出风格漂移
强制输出引用：引用文件路径、函数名、类型名
结果可回退：AI 不可用时流程不受影响
记录输入与输出：便于复盘与持续改进（注意脱敏）

总结

AI 在前端工程中的价值，更像“放大镜 + 清单生成器”：

2024 年前端与 AI 融合方向的实践观察

wuwenzen@outlook.com (wuwj) — Wed, 18 Dec 2024 00:00:00 +0000

背景

2024 年，AI 能力开始从“可用”逐步走向“可落地”，并在前端工程中呈现出更加清晰的应用边界。

相比早期的探索阶段，这一时期的关注重点不再是模型能力本身，而是 AI 如何以可控、可维护的方式融入现有前端系统。

前端侧可落地的 AI 应用方向

1. 面向内容的辅助能力

AI 在内容相关场景中的成熟度相对较高，包括：

文案生成与润色
提示信息补全
结构化内容转摘要

这类能力通常作为增强工具存在，不直接影响核心业务逻辑。

2. 面向效率的开发辅助

在工程实践中，AI 更常被用于：

辅助生成重复性代码
帮助理解既有代码结构
提供问题排查思路

其价值体现在 降低理解成本，而非完全替代开发过程。

3. 面向系统使用体验的增强

部分系统开始引入 AI 作为交互层补充：

智能提示
操作建议
上下文相关说明

这类能力通常具备可回退机制，不作为唯一入口。

实践过程中暴露的问题

1. 输出不可控带来的风险

在缺乏约束的情况下，AI 输出可能出现：

表达不稳定
语义偏移
与系统实际状态不一致

因此，工程层面必须为 AI 输出设置明确边界。

2. 过度集成的复杂性成本

将 AI 深度嵌入核心流程，往往会带来：

调试难度上升
依赖链条拉长
系统稳定性下降

实践中更可取的方式是 渐进式引入。

3. 成本与收益不对等

并非所有场景都适合引入 AI：

低频功能收益有限
调用成本难以摊平
维护复杂度高于收益

是否引入，应以实际价值为判断依据。

工程层面的共识原则

1. AI 作为增强能力而非核心依赖

在架构设计中，应确保：

长期维护复杂系统的工程治理实践

wuwenzen@outlook.com (wuwj) — Tue, 05 Nov 2024 00:00:00 +0000

背景

当系统进入长期运行阶段后，开发重心往往不再是功能堆叠，而是如何稳定地演进。

在多成员参与、需求持续迭代的情况下，如果缺乏清晰的工程治理策略，系统复杂度会随着时间快速累积，最终影响交付效率与稳定性。

常见治理问题

1. 技术债持续累积

常见表现包括：

临时方案长期存在
过期代码无人清理
模块边界逐渐模糊

技术债并非一次性问题，而是长期决策叠加的结果。

2. 修改成本不可预期

在缺乏约束的系统中：

小改动引发连锁问题
回归测试成本上升
开发人员对改动范围缺乏信心

3. 责任边界不清晰

随着人员流动和系统扩展：

模块负责人缺失
历史决策难以追溯
问题定位依赖经验而非结构

工程治理的核心思路

1. 明确系统边界与模块职责

通过清晰的模块划分：

限制复杂度扩散
明确代码归属
为后续重构提供基础

边界清晰比局部优化更重要。

2. 将技术债显性化

有效的做法包括：

记录技术债产生背景
标注影响范围与优先级
纳入迭代计划而非搁置

可被管理的技术债，才不会失控。

3. 建立可持续的改进节奏

治理并非一次性重构，而是持续过程：

小步调整
控制风险
在业务推进中逐步改善结构

工程层面的实践方式

1. 保持核心路径稳定

优先保障：

高频使用功能
核心业务流程
对外依赖接口

非核心区域允许逐步演进。

2. 为关键模块补充保护措施

包括但不限于：

基础测试覆盖
明确的接口约束
必要的文档说明

这些投入可以显著降低后续修改风险。

3. 定期进行结构性回顾

通过阶段性回顾：

评估现有结构是否仍然合理
识别复杂度增长点
为下一阶段调整提供依据

工程治理的长期价值

良好的治理并不会立刻提升开发速度，但可以：

降低长期维护成本
提升系统可预测性
减少团队对系统的心理负担

这类收益通常在系统运行一段时间后逐步显现。

在前端系统中引入 AI 辅助提示与文案生成

wuwenzen@outlook.com (wuwj) — Sat, 22 Jun 2024 00:00:00 +0000

背景

随着大模型能力逐步成熟，AI 不再只用于对话场景，也开始进入实际业务系统，承担提示生成、文案辅助与信息补全等角色。

在前端系统中合理引入 AI，可以在不改变原有业务流程的前提下，提升信息表达效率与一致性。

常见应用场景

1. 提示文案辅助生成

在配置类或操作型页面中，常见需求包括：

自动生成操作说明
根据上下文补充提示文案
统一不同页面的表达风格

AI 更适合充当“草稿生成器”，而非最终决策者。

2. 动态提示内容补全

基于页面状态或用户输入，生成更具体的提示信息：

根据选择结果生成说明
针对异常情况给出补充建议
避免模板化、重复性文案

3. 复杂规则的自然语言转译

当系统内部规则较为复杂时，可以通过 AI 将结构化信息转化为更易理解的描述：

配置结果解释
条件判断结果说明
操作后果提示

引入 AI 时的设计原则

1. 明确 AI 的角色边界

在前端系统中，AI 更适合承担：

文案辅助
表达优化
信息重组

而不适合直接参与业务判断或规则决策。

2. 保持可控的输出范围

为避免不可预期的输出，应当：

提供明确的上下文与输入约束
使用固定模板 + AI 补全的方式
对输出结果进行二次校验或人工确认

3. 输出结果可回退、可替换

AI 生成内容应具备以下特性：

不影响主流程运行
支持一键替换为默认文案
不作为唯一信息来源

前端实现思路

1. 以“增强能力”形式接入

在实现层面，通常将 AI 能力视为可选增强：

不影响原有逻辑
异常时自动降级
与核心业务解耦

2. 统一封装调用接口

通过统一的 AI 服务封装：

复杂业务场景下的表单设计与交互实践

wuwenzen@outlook.com (wuwj) — Thu, 10 Feb 2022 00:00:00 +0000

背景

在中后台系统与业务管理类页面中，表单是最常见、也是最容易被低估的一类界面形态。
当字段数量增加、填写规则变复杂时，简单堆砌输入框往往会带来较高的使用成本。

如何在不引入额外学习成本的前提下，提升表单填写效率与可理解性，是前端实现中需要重点考虑的问题。

常见问题分析

1. 必填项不明确

在字段较多的表单中，常见问题包括：

必填与非必填混杂展示
校验规则只在提交时才触发
错误提示信息不清晰

这类问题会显著降低填写效率。

2. 一次性信息输入负担过重

将所有字段集中在一个页面中，容易导致：

页面过长，用户难以快速定位
心理负担增加，填写中途放弃
错误集中暴露，修改成本高

3. 表单状态反馈不足

缺乏清晰反馈时，用户往往无法判断：

当前填写是否符合规则
是否已满足提交条件
提交操作是否成功触发

表单设计与交互实践

1. 明确字段优先级

通过视觉层级区分字段重要性：

必填项显式标识
非关键字段弱化展示
合理使用占位说明与辅助文案

有助于用户快速理解填写重点。

2. 分步骤拆解复杂表单

将长表单拆分为多个步骤：

每一步聚焦一类信息
提供清晰的进度提示
支持上一步回退与数据保留

这种方式能有效降低单次填写压力。

3. 提前进行输入校验

在用户输入过程中进行校验：

输入完成后即时提示错误
明确指出错误原因
避免提交后集中报错

可以显著减少重复操作。

4. 提供清晰的状态反馈

在关键节点给予明确反馈：

提交中状态提示
成功或失败结果明确展示
异常情况提供可操作指引

让用户始终清楚当前所处状态。

工程实现层面的考虑

在实现层面，通常会关注：

表单状态集中管理
校验逻辑与 UI 解耦
表单组件的可复用性

这些实践有助于在多个业务场景中复用同一套表单能力。

总结

复杂表单的设计并不依赖特定行业背景，而是对信息结构、交互节奏与用户认知的综合考量。

通过合理拆分、清晰反馈与一致的交互规则，可以在不增加实现复杂度的前提下，显著提升整体使用体验。

从 jQuery 到模块化：一次前端工程意识的转变

wuwenzen@outlook.com (wuwj) — Fri, 20 Dec 2019 00:00:00 +0000

背景

在较早阶段的前端开发中，常见技术栈以 jQuery + 传统页面结构 为主。
这种模式在页面数量有限、业务逻辑简单时，具备实现成本低、交付速度快的优势。

但随着功能逐步增多、页面之间产生联动，代码结构问题开始显现，对可维护性提出了更高要求。

传统写法暴露的问题

1. 全局作用域污染

var list = [];
function init() {}
function render() {}

常见问题包括：

变量与函数暴露在全局作用域
多页面脚本容易互相覆盖
问题定位与调试成本逐渐升高

2. 文件职责混乱

在缺乏结构约束的情况下：

单个 JS 文件体积不断膨胀
DOM 操作、业务逻辑、接口请求混杂
修改局部逻辑时容易产生连锁影响

3. 代码复用能力弱

相似功能在不同页面中往往通过复制实现：

复制后再做细微修改
长期来看难以统一维护
Bug 修复成本被成倍放大

引入模块化思路

为缓解上述问题，开始尝试在不依赖复杂工具链的前提下，引入基础的模块化设计思想。

1. 按职责拆分代码结构

js/
├── api.js
├── render.js
├── event.js
└── main.js

通过人为约定实现基础分层：

接口请求集中管理
渲染逻辑独立拆分
事件绑定避免分散在各处

即使不依赖构建工具，也能显著提升代码可读性。

2. 使用 IIFE 隔离作用域

(function () {
  var state = {};
  function init() {}
  window.pageInit = init;
})();

这种方式在早期用于：