背景

复杂系统引入 AI 的最大风险并非“效果不够好”，而是：

• 输出不稳定导致体验波动
• 依赖链拉长导致线上不确定性上升
• 成本不可控（调用量与 token 消耗）
• 缺乏回退机制导致事故扩大

因此需要把 AI 当成一种“工程能力模块”，纳入治理体系。

1. 能力分级：先决定“用不用、用在哪”

建议按风险把场景分三档：

• 低风险：内容摘要、帮助说明、检索辅助
• 中风险：规则解释、提示文案优化（基于结构化事实）
• 高风险：核心决策、资金/权限相关结论（原则上禁用）

分级不是文档，而是要落到开关与权限策略上：不同页面/角色可启用不同能力。

2. 统一接入层：把不确定性收敛到一个地方

建议统一封装 AI 调用：

• 超时控制（避免卡住主流程）
• 限流与预算（按用户/模块/时间窗）
• 缓存（相同输入复用输出）
• 降级（失败回退到规则/模板）
• 日志（输入与输出脱敏存档）

统一接入层的目标：即使换模型/换供应商，业务层也不需要大改。

3. 输出约束：从“自由生成”到“受限生成”

工程可控的关键：让 AI 输出处在可验证范围内。常用手段：

• 结构化输入：只给事实与允许的选项
• 格式约束：JSON/固定段落结构
• 词库治理：术语表、短语库、禁用词
• 校验失败回退：不通过就不展示 AI 结果

4. 成本治理：把 AI 当成一种资源

建议建立三层成本控制：

• 业务层：只在“确实节省成本/提升体验”的场景使用
• 工程层：缓存、去重、减少重复调用
• 策略层：按模块预算、按角色限额、按时间窗限流

成本控制做得好，AI 才能长期运行，而不是“试点一阵就下线”。

5. 回退策略：可用性比智能更重要

回退策略建议至少包含：

• 单次失败回退：本次调用失败 -> 使用模板/规则结果
• 全局开关回退：线上异常 -> 一键关闭 AI 能力
• 体验回退：低置信度 -> 优先展示引用与原始结果

原则：AI 只能增强，不得成为唯一依赖。

总结

复杂系统引入 AI 的正确打开方式是“工程化治理”：

一句话

AI 可以当“外挂”，别当“方向盘”。
治理的目标：让 AI 更像安全带，而不是赌运气。

1）先分级：3 档够用

• 低风险：摘要/帮助/检索
  → 可用，但要能降级
• 中风险：规则解释/提示润色（基于结构化事实）
  → 只能做表达，不能做判断
• 高风险：资金/权限/核心决策
  → 原则上禁用（或强隔离+强审核）

2）统一接入层：把“不确定性”关进盒子

统一入口做五件事：

• 超时（别卡主流程）
• 限流/预算（别一夜烧钱）
• 缓存（同样问题别反复问）
• 降级（失败走模板/规则）
• 日志（脱敏记录，能追溯）

3）受限生成：别让 AI 自由作文

让输出可检查：

• 固定格式（JSON/固定段落）
• 必填字段（必须包含关键名词）
• 禁用词（保证/承诺/一定）
• 事实来源（规则码/文档 id）

校验不过：直接不用 AI 结果。

4）成本治理：AI 也是资源

最实用三条：

• 只在“真有收益”的场景用
• 缓存 + 去重（省钱又稳定）
• 按模块设预算（超了就降级）

5）回退：永远要 Plan B

• 单次回退：这次失败 -> 模板
• 全局回退：异常 -> 一键关开关
• 体验回退：置信度低 -> 少说话，多给引用

结尾：上生产前检查表

• 分级清楚
• 统一入口
• 受限输出 + 校验
• 一键回退
• 样例评测集

背景

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

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

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

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

本地草稿（默认）

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

服务端草稿（可选）

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

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

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

建议状态模型包含：

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

页面进入时：

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

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

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

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

幂等 key 的建议组成：

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

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

建议将校验分为：

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

错误展示策略：

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

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

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

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

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

背景

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

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

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

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

判断层输出结构化事实

判断层输出类似：

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

表达层仅消费结构化事实

AI 的输入仅包含：

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

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

一套可落地的生成链路

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

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

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

建议建设两类资产：

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

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

前端落地建议

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

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

按提示码准备样例集：

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

评估维度：

背景

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

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

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

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 更适合作为“工程助手”，在不改变既有流程的前提下，降低理解成本与重复劳动。

适用场景与边界

适合让 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 在前端工程中的价值，更像“放大镜 + 清单生成器”：