AI 应用 on Saiga

让 AI 帮我做前端性能分析报告

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

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

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

于是试了一件事：

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

1. 输入与输出长啥样？

1.1 输入数据

主要有两部分：

Lighthouse JSON 报告
- 性能得分
- LCP / CLS / TBT / TTI 等指标
- 各种「机会」与「诊断」信息
真实用户监控数据（RUM）（可选）
- 最近一段时间的 LCP P75、FCP P75
- 不同地区/设备的耗时对比

1.2 期望输出

希望 AI 给我的报告包含：

一段 1～2 句话的性能整体概览
用人话解释关键指标的含义和当前水平
列出 3～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
  }
}

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

用大模型做一个「表单配置助手」

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

在很多中台系统里，「加一个表单页面」是非常常见的需求：

运营要配活动
风控要配规则
产品要加信息收集表单

常规流程比较重：写需求 → 画原型 → 前端实现 → 联调 → 上线。
对于那些只是字段多、变更频率高的小表单，其实有点浪费。

所以我们尝试做了一个小工具：

运营用自然语言描述表单，大模型帮忙产出一份「表单配置 JSON」，前端根据配置自动渲染。

这篇文章就简单记录一下实现思路。

1. 目标：从一句话到一份表单配置

我们给自己的目标很克制：

输入：一段自然语言描述，例如

“做一个录入投资人基本信息的表单，需要姓名、手机号、证件类型和证件号，手机号必填要校验格式，证件类型从下拉里选身份证/护照。”
输出：一份前端能直接使用的配置 JSON：
- 字段列表
- 字段类型、标签、占位
- 是否必填、校验规则
- 下拉选项等

前端只负责：

把描述提交给后端
拿到配置 JSON
交给通用 <FormRenderer :config="formConfig" /> 渲染

2. 配置格式：先把「机器读得懂」定义好

要让大模型产出可用结果，首先要有一份清晰的配置格式。示例：

{
  "title": "投资人信息录入",
  "layout": "vertical",
  "fields": [
    {
      "name": "name",
      "label": "姓名",
      "type": "input",
      "required": true,
      "placeholder": "请输入姓名"
    },
    {
      "name": "mobile",
      "label": "手机号",
      "type": "input",
      "required": true,
      "rules": [
        {
          "type": "regex",
          "pattern": "^1\\d{10}$",
          "message": "请输入 11 位手机号"
        }
      ]
    },
    {
      "name": "idType",
      "label": "证件类型",
      "type": "select",
      "required": true,
      "options": [
        { "label": "居民身份证", "value": "ID_CARD" },
        { "label": "护照", "value": "PASSPORT" }
      ]
    },
    {
      "name": "idNo",
      "label": "证件号码",
      "type": "input",
      "required": true
    }
  ]
}

前端已经有配套组件：

在内部运营/中台工具里加一点 AI：从搜索到推荐

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

相比 C 端产品，「内部运营/中台工具」看起来没那么光鲜，界面经常是：

一堆表格、一堆配置、一堆筛选项。

但正因为如此，AI 在这里往往很好落地：

用户数量受控，易于试点；
业务流程清晰，方便评估效果；
哪怕只提升一点效率，整体价值也不小。

这篇文章就分享几个我们在内部工具里「加一点 AI」的尝试：从搜索到推荐再到智能填写。

1. 智能搜索：从「条件筛选」到「自然语言搜索」

1.1 传统方式的痛点

运营同学以前查数据要：

打开一个复杂查询页；
选择 N 个下拉框（业务线、产品、日期区间、状态…）；
点击查询，发现忘记勾某个条件，再重新来一次。

于是我们考虑加一个入口：自然语言搜索。

例如：

「最近 7 天上海地区的私募新增高净值客户」
「失败次数超过 3 次的合同签署记录」

1.2 技术方案

用大模型把自然语言解析成结构化查询条件；
再把这些条件映射到后端已有查询接口；
最终仍然走「原有 SQL / ES 查询逻辑」。

伪代码示意：

const prompt = `
你是查询构建助手。请将用户的自然语言查询转换为 JSON 条件。...
`;

const llmResult = await callLLM(prompt + userQuery);
const conditions = JSON.parse(llmResult);

const data = await callSearchAPI(conditions);

关键点：

不直接让模型生成 SQL（安全风险 & 不可控）；
而是生成一个受控的 JSON 条件对象。

1.3 前端体验

搜索框下方展示「解析出的条件」，让用户确认；
支持一键切换到「高级筛选」视图，展示同样条件；
避免让 AI 变成黑盒——用户看得见它怎么理解的。

2. 智能推荐：运营配置页也能变「懂你」一点

场景：

运营在后台配置「某类用户看到哪些运营位/推荐产品」；
一般是靠经验拍脑袋选；
想利用历史数据做一点辅助决策。

2.1 我们做了什么

在原有「人工配置」的基础上，增加一个「AI 建议」按钮：

用 RAG 做项目文档问答：从零搭一个 Demo

wuwenzen@outlook.com (wuwj) — Sun, 10 Sep 2023 00:00:00 +0000

之前写过一篇「文档问答助手」的早期尝试，这次想更系统地从 RAG 角度，把整个过程讲清楚。

RAG（Retrieval-Augmented Generation）= 检索增强生成
简单说就是：先从你自己的文档里检索相关内容，再让大模型基于这些内容生成答案。

这篇文章以「项目文档问答」为例，从零搭一个小 Demo。

1. 目标：让大模型「读得懂」我们的项目文档

设定目标：

知识来源：代码仓库中的 README、设计文档、接口说明等；
使用方式：在一个 Web 界面里提问，例如：
- 「私募投资人小程序支持哪些登陆方式？」
- 「电子合同模块的签署流程有哪些关键步骤？」
期望回答：
- 基本准确；
- 回答中能指出「来自哪份文档」。

约束条件：

不追求「端到端生产可用」，先搭一个可演示、可验证的 Demo；
优先用云端 Embedding + 向量库，而不是自己训模型。

2. 文档准备与切分

2.1 文档来源

Git 仓库中的 Markdown：docs/ 目录、各项目 README；
内部 Wiki 导出的 HTML/Markdown；
部分 API 文档（Swagger/OpenAPI 转文本）。

统一先转成 Markdown/纯文本，方便处理。

2.2 切分策略

RAG 很关键的一步是「chunking」，即把长文档切成小段。
我们采用的是：

按标题结构 + 字数混合切分；
每段控制在 300–600 字；
保留上级标题用于提供上下文。

示例结构：

{
  "docId": "fund-investor-miniapp",
  "docTitle": "信e募投资人小程序技术方案",
  "sectionPath": ["2. 技术架构", "2.1 前端技术栈"],
  "content": "前端采用 Vue3 + uni-app...",
  "index": 12
}

经验：

调用大模型 API 的几个最佳实践：重试、降级与审计

wuwenzen@outlook.com (wuwj) — Mon, 05 Jun 2023 00:00:00 +0000

刚开始用大模型 API 时，大家一般关心的是：

这个模型效果好不好？回答聪不聪明？

但当你真的把它作为「线上能力」接入产品时，会发现很多工程问题：

API 偶尔超时 / 报错怎么办？
费用怎么控？
返回内容里如果有敏感信息怎么办？
出了问题，怎么排查某次请求？

这篇文章就是从这些「落地问题」出发，整理几条接入大模型 API 的最佳实践。

1. 超时与重试：别把前端一直挂着

1.1 超时要有明确上限

大模型生成本身需要时间，如果不设超时，前端可能会一直转圈。
我们一般做法：

在 BFF / 中间层对每个调用设定超时时间（例如 10–15 秒）；
超时后直接返回「超时错误」，由前端给出友好提示；
前端也设置请求超时，避免被挂死。

1.2 重试策略

常见错误类型：

临时网络抖动；
API 限流（429）；
服务端偶发异常。

对幂等请求（比如生成建议文案），我们采用：

指数退避重试：例如最多重试 2 次，间隔 500ms / 1000ms；
遇到某些错误码（如 4xx 中的参数错误）不重试。

伪代码：

async function callLLMWithRetry(payload) {
  const maxRetry = 2;
  let attempt = 0;

  while (true) {
    try {
      return await callLLM(payload);
    } catch (e: any) {
      if (!isRetryableError(e) || attempt >= maxRetry) {
        throw e;
      }
      attempt++;
      await sleep(500 * attempt);
    }
  }
}

2. 降级：模型不可用时要有「备胎」

大模型 API 作为外部依赖，不可能 100% 可用。
因此建议设计「降级方案」：