大模型 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
  }
}

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

AI Code Review 实战：规则、提示词与边界

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

今年做了一次尝试：

不改变现有流程的前提下，让大模型参与到 Code Review 里，当一个「辅助 reviewer」。

它不会替代人类审核，只做三件事：

帮忙找明显 bug / 边界问题
帮忙发现重复逻辑、代码味道
帮忙写结构化的改进建议

1. 我们希望 AI 扮演什么角色？

一开始就想清楚边界：

不负责通过/拒绝 PR
- 不修改状态，只给评论和建议
- 最终决策仍然是人类 reviewer
关注「模式」而不是细枝末节
- 比如错误处理缺失、越界风险、循环里请求等
- 而不是变量名叫 a 还是 data
输出要尽量具体
- 指出文件、位置、问题和建议
- 避免空话：「可以优化」「可以重构」这种直接过滤掉

2. 整体方案：在 CI 里多插一段「AI Review」

流程：

CI 获取本次 PR 的变更文件 + diff
对每个文件构造一个「上下文 + diff」的 payload
调用大模型，让它产出结构化的 review 结果
再由机器人账号把评论贴回 PR（或者汇总成一条）

为控制成本和复杂度：

优先只分析变更行附近的代码
超长文件只截取相关片段

3. Prompt 设计：告诉 AI「只看这四件事」

一个简化的系统提示大致是：

你是一名资深前端/全栈工程师，正在做 Code Review。
请只关注以下问题：

明显的 bug 或潜在边界问题

异常处理和错误提示是否合理

性能隐患（多余循环、重复请求等）

安全/权限风险

不要评论代码风格、缩进、单双引号之类的问题，这些交给 Lint 工具。

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

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
    }
  ]
}

前端已经有配套组件：

用大模型做一个简单「文档问答助手」

wuwenzen@outlook.com (wuwj) — Sun, 30 Oct 2022 00:00:00 +0000

2022 年开始，大模型 API 越来越好用，大家最直觉的一个想法就是：

能不能把项目文档「喂给」模型，然后直接用自然语言问问题？

这篇文章记录的是一个从 0 到 1 的小 Demo：用大模型 API + 向量检索，实现一个能回答「我们自己文档」问题的小助手。

1. 目标和约束

目标很简单：

把部分项目文档（接口说明、架构设计、规范）导入系统；
在一个聊天界面里，可以问：
- 「用户登录接口的必填参数有哪些？」
- 「私募投资人小程序的技术栈是什么？」
助手能基于文档给出相对准确的回答。

约束：

不追求「完美答案」；
优先做到：能指向正确文档，并给出简洁总结。

2. 总体架构

整体流程可以概括成：

文档导入 & 切分；
向量化（Embedding）并存入向量库；
用户提问 → 向量检索相关片段；
把相关片段 + 问题一起发给大模型 → 生成回答；
前端展示答案 + 引用片段。

用一张简图就是所谓的：RAG（检索增强生成）。

3. 文档预处理：从 Markdown 到「小段文本」

我们选用的文档源主要是：

Git 仓库里的 Markdown（README、设计文档）；
部分导出的接口文档（JSON/YAML 转文本）。

预处理步骤：

把 Markdown 转成纯文本（保留标题层级）；
按一定策略切分成「小段文本」，比如每段 300–500 字；
每段附带元信息：文档名、段落标题、在文档中的位置。

简单示例：

{
  "docId": "fund-investor-miniapp",
  "title": "技术栈与整体架构",
  "content": "前端采用 Vue3 + uni-app...",
  "section": "2.1 技术栈",
  "index": 5
}

切分策略的小经验：