今年做了一次尝试：

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

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

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

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

一开始就想清楚边界：

1. 不负责通过/拒绝 PR

   • 不修改状态，只给评论和建议
   • 最终决策仍然是人类 reviewer

2. 关注「模式」而不是细枝末节

   • 比如错误处理缺失、越界风险、循环里请求等
   • 而不是变量名叫 a 还是 data

3. 输出要尽量具体

   • 指出文件、位置、问题和建议
   • 避免空话：「可以优化」「可以重构」这种直接过滤掉

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

流程：

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

为控制成本和复杂度：

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

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

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

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

1. 明显的 bug 或潜在边界问题
2. 异常处理和错误提示是否合理
3. 性能隐患（多余循环、重复请求等）
4. 安全/权限风险

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

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

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

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

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

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

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

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

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

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

  “做一个录入投资人基本信息的表单，需要姓名、手机号、证件类型和证件号，手机号必填要校验格式，证件类型从下拉里选身份证/护照。”

• 输出：一份前端能直接使用的配置 JSON：
  • 字段列表
  • 字段类型、标签、占位
  • 是否必填、校验规则
  • 下拉选项等

前端只负责：

1. 把描述提交给后端
2. 拿到配置 JSON
3. 交给通用 <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
    }
  ]
}

前端已经有配套组件：

如果用一句话概括 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 实验和监控：让前端更「可观测」

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

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

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

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

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

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

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

1.1 传统方式的痛点

运营同学以前查数据要：

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

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

例如：

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

1.2 技术方案

1. 用大模型把自然语言解析成结构化查询条件；
2. 再把这些条件映射到后端已有查询接口；
3. 最终仍然走「原有 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 角度，把整个过程讲清楚。

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
}

经验：

2023 年对我来说有一个明显变化：

编辑器不再是一个「孤立工具」，而是被各种 AI 助手包围。

从简单的代码补全，到用大模型参与需求理解、方案推演、重构、写单测……
这篇文章就讲讲我是怎么给自己搭一套「AI 助理」开发流程的。

1. 先想清楚：希望 AI 在开发中帮我做什么？

我给自己列了一个清单：

1. 样板代码生成：页面骨架、接口封装、组件模板；
2. 复杂逻辑解释/重构：老代码梳理、新方案对比；
3. 单测生成：尤其是工具函数、纯逻辑模块；
4. 文档和注释：根据代码生成合适的注释、接口说明；
5. 代码 Review 辅助：帮我发现一些潜在问题或改进点。

工具上则主要依赖：

• 编辑器内的代码补全（Copilot 类）；
• Chat 类大模型（ChatGPT 等）；
• 自己整理的一些 Prompt 模板。

2. Prompt 模板：把「怎么问」提前想好

很快会发现：随便问一句「帮我优化这段代码」效果参差不齐。
于是我开始为不同场景整理固定 Prompt 模板。

2.1 重构模板

请作为资深前端工程师，帮我重构下面这段代码：

1. 目标是提高可读性和可维护性，而不是追求最短写法；
2. 如果有明显的边界情况，请指出并补上处理；
3. 给出重构后的代码，并用要点列出你做了哪些调整和原因。

代码如下：
```ts
// code here
```

2.2 单测生成模板

帮我为下面这个纯函数生成单元测试用例：

1. 使用 Jest 语法；
2. 覆盖常见正常输入和几种边界情况；
3. 简要说明每个测试用例要验证的点。

代码如下：
```ts
// code here
```

我会把这些模板存成 Snippet 或者存在笔记里，方便复用。

3. 编辑器内的 AI：使用边界和习惯

装上 Copilot 类插件之后，一开始很容易「啥都接」。
用了一段时间，我给自己定了几个使用习惯：