AI on Saiga

复杂系统引入 AI 的工程治理：分级、成本与回退策略

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

背景

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

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

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

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

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

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

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

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

建议统一封装 AI 调用：

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

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

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

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

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

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

建议建立三层成本控制：

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

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

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

回退策略建议至少包含：

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

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

总结

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

复杂系统引入 AI 的工程治理：分级、成本与回退策略

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

一句话

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

1）先分级：3 档够用

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

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

统一入口做五件事：

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

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

让输出可检查：

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

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

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

最实用三条：

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

5）回退：永远要 Plan B

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

结尾：上生产前检查表

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

规则 + 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

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

按提示码准备样例集：

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

评估维度：

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 作为增强能力而非核心依赖

在架构设计中，应确保：

使用 AI 辅助整理与检索个人内容的方法

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

背景

随着个人技术积累逐渐增多，内容往往分散在博客、笔记工具、项目文档等不同位置。
当内容规模扩大后，单纯依赖目录结构或标签分类，已经难以快速定位所需信息。

在这种情况下，引入 AI 作为辅助整理与检索工具，是一种成本较低、可逐步演进的方案。

常见内容管理痛点

1. 内容分散，检索成本高

常见情况包括：

同一主题存在多份记录
不同工具之间缺乏统一入口
只能依赖全文搜索，结果噪声较多

2. 标签与分类难以长期维护

人工维护分类体系容易出现：

标签粒度不一致
分类不断膨胀
新内容难以快速归类

3. 内容“写完即沉没”

很多内容在完成记录后：

很少被再次查阅
难以形成复用价值
无法支撑长期积累

AI 在内容整理中的角色

1. 辅助理解与归纳

AI 更适合承担以下工作：

对已有内容进行摘要
提炼核心观点
生成结构化要点

而不是替代原始内容本身。

2. 提供语义层面的检索能力

相比关键词匹配，语义检索可以：

容忍表达差异
根据问题意图返回结果
提高命中相关内容的概率

在个人内容规模增长后，这种能力尤为重要。

3. 作为“入口层”而非数据源

AI 更适合作为统一入口：

帮助定位已有内容
提供参考链接
指向原始记录位置

而不是成为新的内容存储层。

实现思路概览

1. 保持原有内容结构稳定

在引入 AI 之前，应确保：

内容来源清晰
原始文件可长期维护
不依赖单一工具或平台

这是后续扩展的基础。

2. 构建轻量级索引层

可以通过以下方式降低成本：

对已有内容生成摘要或关键描述
将元信息集中管理
避免过早引入复杂基础设施

3. AI 查询作为增强能力

在查询阶段引入 AI：

在前端系统中引入 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 服务封装：