AI 应用 on Saiga

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 服务封装：

2023 年技术小结：从前端工程到 AI 应用

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

如果用一句话概括 2023 年的技术主线，大概是：

一边继续把前端工程体系打磨扎实，一边认真把 AI 接到「真业务」里。

这一年做了几件印象比较深的事情：

把多个前端项目合到 Monorepo；
尝试微前端，把老系统和新模块串起来；
在中台里跑了几轮完整的 A/B 实验；
接入大模型 API，做了文档问答、内部工具智能化的小应用；
把 AI 真正纳入自己的日常开发流程。

这篇总结就按这两条主线——前端工程 和 AI 应用 来回顾一下。

1. 前端工程线：更「稳」也更「合在一起」

1.1 Monorepo 落地

年初开始，把几个关联度高的中台项目合进一个 Monorepo：

tools：pnpm + Turborepo；
结构：apps/ + packages/；
公共库：UI 组件、工具函数、统一 ESLint 配置。

收益：

组件库和工具修一次，多项目同步升级；
工程规范「一处改，全员受益」；
新项目孵化成本明显降低。

也逼着自己思考：「什么才值得抽成库，什么就留在应用里？」
这对边界感的训练很有帮助。

1.2 微前端小规模应用

不是全线切微前端，而是谨慎选择了几块：

老 Vue2 中台 + 新 Vue3 模块；
部分实验性应用用 React 写。

用「框架型微前端」把它们挂在一个壳子下：

主应用管登录、导航、全局样式；
子应用各自管内部路由和业务。

实践下来感受是：

在「多团队 + 多技术栈 + 独立发布」场景下确实好用；
但也确实增加了复杂度，需要配套工程规范。

1.3 实验和监控：让前端更「可观测」

这一年比较系统地做了两件事：