随笔

前端结合 AI 开发

前言

AI 编程工具正在深刻改变前端的开发方式：从补全代码、生成组件，到改写重构、排查 bug，几乎每个环节都能借力。本文分享如何把 AI 真正”用起来”，而不是停留在”问一问”。

一、主流 AI 编程工具盘点

工具 类型 特点
GitHub Copilot IDE 插件 行内补全 + Chat，生态最成熟，按订阅收费
Cursor AI 原生编辑器 深度集成 AI，支持多文件编辑、Composer
Windsurf AI 原生编辑器 与 Cursor 类似，强调”Agent”协作
Claude Code / Codex CLI 终端 Agent 命令行驱动，适合批量改造与自动化
通义灵码 / 文心快码 / CodeBuddy 国内 IDE 插件 本土化好、中文友好，免费额度充足
大模型 Web 版 网页对话 ChatGPT、Claude、DeepSeek、Kimi 等，适合讨论方案

不必纠结选哪个，IDE 插件（补全）+ 一个顺手的 Agent/编辑器（做重活）+ 一个 Web 对话（讨论方案） 的组合就够日常使用。

二、AI 在前端开发中的高效用法

1. 代码补全与生成

  • 写好函数名、注释、类型定义，让 AI 补全实现
  • 描述 UI 结构，让 AI 生成组件骨架（表格、表单、弹窗）
  • 根据已有代码风格，生成同风格的新模块

2. 代码改写与重构

  • 大函数拆小、提取公共逻辑、抽 hook / 工具函数
  • 把回调地狱改成 async/await，把重复代码抽成组件
  • 升级 API 用法（如 Vue2 选项式转 Vue3 组合式、class 组件转函数组件）

3. 排查 bug 与调试

  • 把报错信息和相关代码贴给 AI，快速定位原因
  • 描述”现象 + 期望 + 已尝试”，让 AI 给排查思路
  • 让 AI 读完整模块，找出边界情况和潜在隐患

4. 生成测试与文档

  • 为函数/组件自动生成单元测试用例
  • 生成组件文档、README、接口说明
  • 让 AI 帮你写 commit message、整理 PR 描述

5. 学习与选型

  • 不熟悉的库，让 AI 讲原理 + 给最小示例
  • 技术选型时让 AI 列优缺点对比、适用场景
  • 让 AI 模拟面试官追问，检验自己是否真懂

三、写好 Prompt 的技巧

AI 输出的质量，很大程度取决于你怎么问。几个实用原则：

  1. 给足上下文：贴代码片段、说明技术栈版本、描述项目结构，别让 AI 猜
  2. 明确角色与目标：”你是一个资深前端工程师，帮我重构下面这个组件，要求……”
  3. 拆小任务：一次只做一件事，比”帮我做个系统”靠谱得多
  4. 给约束条件：指定技术栈、代码风格、是否兼容旧浏览器、是否需要 TS 类型
  5. 要求”边想边说”：复杂问题让 AI 先列思路/步骤，确认后再生成代码
  6. 迭代优化：第一版不理想就继续追问，说清哪里不对，别推倒重来

示例对比：

  • ❌ “帮我写个表格组件”
  • ✅ “用 Vue3 + TypeScript + Ant Design Vue，写一个支持分页、多选、列排序的通用表格封装，props 接收列配置和接口，暴露刷新和重置方法，代码风格参考项目现有规范”

四、VSCode 配置 AI 插件与规范

1. 选装哪些插件

VSCode 里把 AI 能力拆成”补全”和”对话/Agent”两块，各装一个即可：

插件 类型 作用 说明
GitHub Copilot / Copilot Chat IDE 插件 行内补全 + 对话 生态最成熟，付费
通义灵码 / 文心快码 / CodeBuddy IDE 插件 补全 + 对话 + 免费额度 国内可用、中文友好
Continue IDE 插件 补全 + 对话 开源、可接本地/自定义模型，隐私敏感或自建模型场景
Cline / Roo Code IDE 插件 强 Agent（可自动改文件） 适合批量重构，需谨慎授权
Claude Code 终端 Agent 命令行驱动的自主编程 擅长多文件理解与批量改造，可与 VSCode 联动
OpenAI Codex CLI 终端 Agent 命令行驱动的自主编程 同样面向任务式自动化，适合跑脚本、批量重构

推荐组合：一个补全插件（日常提词）+ 一个对话/Agent 插件（做重活），不要装一堆互相打架。终端 Agent（Claude Code / Codex）适合放到”批量改造、跑脚本、自动化”这类需要跨文件操作的重活上，日常补全还是交给 IDE 插件更快。

2. 提前规范哪些内容

AI 输出质量取决于它”读到了什么约定”。装好插件后，第一时间把下面这些内容沉淀成项目级规则文件（如 CodeBuddy 的规则、.cursorrules、.vscode/ 配置或团队 Wiki）：

① 技术栈与版本

  • 框架版本（Vue 3 / React 18）、构建工具（Vite）、语言（TS 版本）、UI 组件库（Ant Design Vue / Element Plus）及版本号
  • 明确”用 TS 还是 JS”，避免 AI 混用

② 代码风格规范

  • 组合式 API（<script setup>）还是选项式；函数组件还是类组件
  • 缩进、引号、分号、尾逗号等（直接指向 ESLint + Prettier 配置）
  • 导入顺序、import type 与值导入的区分

③ 命名规范

  • 组件大驼峰（UserTable.vue）、工具函数小驼峰（formatDate）、常量全大写（MAX_SIZE）、CSS 类名约定（BEM 或原子类）

④ 目录结构约定

  • 页面 src/views、组件 src/components、API src/api、类型 src/types、状态 src/store、工具 src/utils
  • 明确”什么逻辑放哪”，避免 AI 乱放文件

⑤ 项目约定与约束

  • 状态管理用 Pinia 还是 Vuex；请求库是 Axios 封装；路由守卫约定
  • 禁止项：不用 any、不直接操作 DOM（Vue 中）、不写魔法数字、不引入未在依赖里的第三方库
  • 兼容性要求：是否需支持旧浏览器、移动端

⑥ 让 AI 排除的目录

  • node_modules、dist、build、*.lock、.git 等，避免 AI 误读污染上下文

3. 规则文件配置示例

以 Vue 项目为例，可放到项目根目录的规则文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
你是本项目的前端开发助手，请严格遵守以下约定。

【技术栈】
- Vue 3 + TypeScript + Vite + Ant Design Vue + Pinia + Axios
- 优先使用组合式 API（<script setup lang="ts">）

【代码风格】
- 遵循项目 ESLint + Prettier 规范（引号用单引号、结尾加分号）
- 类型定义放在 src/types 下，接口请求函数放 src/api
- 禁止使用 any，禁止魔法数字，禁止引入 package.json 之外的第三方库

【命名规范】
- 组件大驼峰（UserTable.vue），工具函数小驼峰（formatDate），常量全大写（MAX_SIZE）

【目录约定】
- 页面 src/views，通用组件 src/components，状态 src/store，工具 src/utils

【输出要求】
- 所有生成代码必须包含完整 TS 类型定义
- 只输出需要修改的代码片段，不要重写整个文件
- 复杂逻辑先用注释说明思路，再写实现

4. 高频提示词（Prompt）清单

把常用的提示词存成”代码片段”或笔记，随时取用：

生成类

1
2
3
- 生成一个 {功能} 的 {Vue/React} 组件，包含 {具体字段/交互}，遵循项目规范
- 根据这份接口文档，生成 src/api 下的请求函数和对应 TS 类型
- 写一个 {名称} 工具函数，入参 {参数}，返回 {返回值}，处理 {边界情况}

重构类

1
2
3
- 把下面这段代码重构得更清晰，拆出可复用的 hook/工具函数，保持行为不变
- 将这段回调地狱改成 async/await，并补充错误处理
- 将下面的选项式 API 组件改写成组合式 API（<script setup>）

排查类

1
2
3
- 这个报错是什么原因？请给出定位思路和修复方案（附报错信息 + 代码）
- 帮我审查这段代码，指出潜在 bug、性能问题和边界情况
- 这段代码在 {某种场景} 下会有什么问题？

测试与文档类

1
2
3
- 为这个组件/函数生成单元测试，覆盖正常、异常、边界三种情况
- 生成这个模块的 README / 使用文档
- 根据本次改动，生成一条符合 Conventional Commits 规范的 commit message

学习类

1
2
3
- 用通俗的语言解释 {概念}，并给出一个最小可运行示例
- {技术 A} 和 {技术 B} 有什么区别？各适合什么场景？
- 站在面试官角度，针对 {这个知识点} 连续追问我三个问题

5. 团队规范落地

  • 统一把 lint 规则、目录规范、组件库约定写进规则文件，纳入仓库版本管理，团队共享
  • 让 AI 生成代码后跑一遍 lint + 单测，自动化兜底
  • 建立”AI 生成代码必须 review”的共识，重要逻辑人肉把关

五、高效工作流示例

以”新增一个业务列表页”为例，看 AI 如何串起全流程：

  1. 需求拆解：跟 AI 讨论页面结构、字段、交互，输出需求清单
  2. 生成骨架：描述清楚后，让 AI 生成页面 + 表格 + 搜索 + 分页代码
  3. 补接口：把后端接口文档贴给 AI，生成 src/api 下的请求函数和 TS 类型
  4. 联调修 bug：把报错贴回，让 AI 定位并修复
  5. 代码 review：让 AI 审查一遍，指出潜在问题和优化点
  6. 补测试与文档：生成测试用例和页面说明

这样一套下来，原本半天的工作量，可能压缩到一两小时。

六、避坑与心态

  1. AI 加速，但不能替代理解：每段 AI 生成的代码你都要能看懂、讲清，否则就是埋雷
  2. 警惕”看起来对”：AI 会一本正经地编造不存在的 API 或过时写法，务必验证
  3. 敏感信息勿外传：不要把密钥、token、内部业务数据贴给第三方 AI
  4. 别过度依赖：基础能力和调试能力永远是根基，AI 只是放大器
  5. 保持人审：关键业务逻辑、安全相关代码（鉴权、支付）必须人工把关

总结

前端结合 AI 开发的核心是：把 AI 定位为”加速器”，而不是”替代者”。选一套顺手的工具组合，学会写高质量 Prompt，把项目规范沉淀进配置，再配合”生成 → 联调 → review”的闭环工作流，就能真正实现效率跃迁。技术会变，但”用 AI 放大自己能力”的思维，值得长期持有。

内容由 AI 生成，仅供参考。本文发布于 码上学习，转载请注明出处。