背景

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

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

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

1. 面向内容的辅助能力

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

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

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

2. 面向效率的开发辅助

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

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

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

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

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

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

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

实践过程中暴露的问题

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

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

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

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

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

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

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

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

3. 成本与收益不对等

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

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

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

工程层面的共识原则

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

在架构设计中，应确保：

背景

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

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

常见治理问题

1. 技术债持续累积

常见表现包括：

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

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

2. 修改成本不可预期

在缺乏约束的系统中：

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

3. 责任边界不清晰

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

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

工程治理的核心思路

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

通过清晰的模块划分：

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

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

2. 将技术债显性化

有效的做法包括：

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

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

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

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

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

工程层面的实践方式

1. 保持核心路径稳定

优先保障：

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

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

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

包括但不限于：

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

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

3. 定期进行结构性回顾

通过阶段性回顾：

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

工程治理的长期价值

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

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

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

有段时间我发现自己经常在做几件很机械的事：

• 新建一个页面：建目录、复制模板、改标题、改路由
• 加一个接口：建 service 文件、写类型、写请求封装
• 搭一个模块：列表页 + 详情页 + 编辑页，一遍遍重复

于是索性写了一组小 CLI 工具，把这些动作变成命令行：

npx fe-tools create-page
npx fe-tools create-api
npx fe-tools create-module

这篇文章就简单记录一下这几个脚本的思路。

1. create-page：新页面一条命令

很多中台项目新增页面的套路都差不多：

1. 在 views 下建目录
2. 填一个基础骨架组件
3. 在路由里挂载
4. 有的还要加到菜单配置里

用 Node.js 写了一个 create-page 命令：

npx fe-tools create-page

命令执行后，做几件事：

1. 命令行交互询问：

   • 页面英文名（路由 path）
   • 页面中文标题
   • 页面类型：列表 / 表单 / 详情 / 组合

2. 基于模板生成对应文件，例如：

<template>
  <PageWrapper title="投资人概览">
    <!-- TODO: 填充页面内容 -->
  </PageWrapper>
</template>

<script setup lang="ts">
// 预留接口调用和状态管理位置
</script>

3. 自动往某个路由模块里追加配置

这样新页面出现的那一刻就已经可以访问，只需要填内容。

2. create-api：接口封装生成器

写接口封装时经常要做：

背景

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

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

常见内容管理痛点

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

常见情况包括：

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

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

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

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

3. 内容“写完即沉没”

很多内容在完成记录后：

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

AI 在内容整理中的角色

1. 辅助理解与归纳

AI 更适合承担以下工作：

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

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

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

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

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

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

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

AI 更适合作为统一入口：

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

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

实现思路概览

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

在引入 AI 之前，应确保：

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

这是后续扩展的基础。

2. 构建轻量级索引层

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

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

3. AI 查询作为增强能力

在查询阶段引入 AI：

背景

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

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

常见应用场景

1. 提示文案辅助生成

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

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

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

2. 动态提示内容补全

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

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

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

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

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

引入 AI 时的设计原则

1. 明确 AI 的角色边界

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

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

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

2. 保持可控的输出范围

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

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

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

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

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

前端实现思路

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

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

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

2. 统一封装调用接口

通过统一的 AI 服务封装：

前端做性能优化，两个常见痛点：

1. 报表很数据化，非技术同学看不懂
2. 每次写性能报告都很花时间：看指标 → 找问题 → 翻译成大家听得懂的结论

于是试了一件事：

我负责把数据准备好，AI 帮我写一份「结构化的性能分析报告」，我只做最后校对。

1. 输入与输出长啥样？

1.1 输入数据

主要有两部分：

1. Lighthouse JSON 报告

   • 性能得分
   • LCP / CLS / TBT / TTI 等指标
   • 各种「机会」与「诊断」信息

2. 真实用户监控数据（RUM）（可选）

   • 最近一段时间的 LCP P75、FCP P75
   • 不同地区/设备的耗时对比

1.2 期望输出

希望 AI 给我的报告包含：

1. 一段 1～2 句话的性能整体概览
2. 用人话解释关键指标的含义和当前水平
3. 列出 3～5 个主要问题（按影响排序）
4. 每个问题配上具体可执行的优化建议
5. 告诉我「先做哪几件事最划算」

2. 先做精简：给 AI 的不是原始 JSON

原始 Lighthouse JSON 体积很大，直接给模型既浪费 Token，也容易让它迷路。
所以写了一个小脚本，把它整理成简版结构：

{
  "url": "https://example.com",
  "score": 0.72,
  "metrics": {
    "LCP": 3800,
    "CLS": 0.11,
    "FID": 25,
    "TTI": 4200
  },
  "opportunities": [
    {
      "title": "减少未使用的 JavaScript",
      "estimatedSavingsMs": 800
    },
    {
      "title": "消除阻塞渲染的资源",
      "estimatedSavingsMs": 600
    }
  ],
  "diagnostics": [
    "主线程工作过多",
    "部分图片未压缩"
  ],
  "rum": {
    "LCP_p75": 4200,
    "FCP_p75": 2100,
    "sampleCount": 120000
  }
}

这样输入既足够有信息量，又相对稳定。