第一次用 AI 写前端代码：哪些好用，哪些坑
2022 年我开始把 AI 编码助手真正用在日常开发里，体验可以用一句话概括：
它不是银弹，但如果用得好，很像一个永远不喊累的实习生。
这篇文章主要记录几个方面：
- 它在哪些场景明显好用；
- 哪些地方容易翻车；
- 我最后形成的一些使用习惯。
1. 几个「惊艳到」的使用场景
1.1 写样板代码（boilerplate）
比如：
- 新建一个 Vue 3 组合式组件；
- 写一个标准的 Axios 封装；
- 初始化一个简单的 React 页面结构。
以前要么复制项目里旧代码改，要么从 CLI 模板改；
现在直接丢一句：
「写一个 Vue3 + TypeScript 的表格组件，支持分页、排序，props 包含 xxx。」
然后拿到一个 70% 可用的版本，再按自己习惯调整。
1.2 写简单的工具函数
例如：
- 将后端分页结果转换为前端表格数据；
- 格式化日期/金额；
- 从树结构中找到某个节点路径。
用自然语言描述需求 + 给一两个例子，AI 通常能给出还不错的实现。
有时候还能顺带推荐几种写法，帮你对比。
1.3 帮忙「翻译」老代码
面对一些古早 jQuery/复杂 if-else 的老代码，直接让 AI：
「帮我解释这段代码在干嘛，并用更现代的写法重构。」
得到的是：
- 一段自然语言解释（方便确认理解）；
- 一版初步的重构实现（不一定完美，但至少是个起点）。
2. 重构和单测：AI 很适合当助手
2.1 帮忙拆函数 / 命名
长函数重构时，让 AI：
「这段函数太长了，帮我按逻辑拆成几个小函数，顺带起一些更好的函数名。」
它会：
- 识别一些相对独立的小块逻辑；
- 给出更语义化的函数名（比如
validateParams,buildRequestPayload）； - 你再按实际业务做微调。
2.2 自动生成单元测试草稿
给一段纯函数代码，让 AI：
「用 Jest 为这个函数生成单元测试，覆盖几种正常和异常场景。」
可以快速拿到：
- 基本测试骨架；
- 多组输入输出样例。
你需要做的是：
- 检查每个期望是否符合真实业务；
- 补充边界条件；
- 和项目里的测试工具函数对齐。
3. 哪些地方容易踩坑？
3.1 杜撰 API / 配置
AI 非常擅长「一本正经地胡说」，尤其是：
- 某些库的最新 API；
- 某些框架的配置项。
典型翻车案例：
- 给出的 Vue Router 用法和当前版本不兼容；
- 提到一个压根不存在的配置字段。
解决方法只有一个：对照官方文档核实。
我一般把它当成「先给我一个大致方向」，细节自己查文档。
3.2 忽略项目上下文
AI 不知道你项目里：
- 已经有一套封装好的请求工具；
- 约定的错误处理、日志规范；
- 自己定义的组件/Hook。
它给出的代码往往是「一个脱离上下文的理想例子」。
需要你主动告诉它：
「我们项目里用的是 xxx 封装，请按这个风格重写。」
并且时不时把相关文件一起贴给它看。
3.3 隐性 bug 不容易被看出来
AI 写的代码看起来「很对」，但真的对不对，需要：
- 你理解逻辑本身；
- 你去跑单测或真机验证。
如果一味「无脑粘贴」，会把一些小坑带进代码库。
所以我给自己的原则是：
AI 写的代码，一定要像「别人写的 PR」那样认真审。
4. 我最后形成的一些使用习惯
4.1 把需求描述清楚
相比「写这个组件」，更好的 prompt 是：
「写一个使用 Vue3 + TS 的表格组件，要求：
- 通过
columns配置表头；- 支持服务端分页，请求函数通过 props 传入；
- 需要有 loading 和空状态展示；
输出完整组件代码。」
需求越清楚，返工越少。
4.2 小步用它，而不是一口气生成一大段
- 让它分次帮你「搞定几个小点」，比如先生成接口层，再生成组件；
- 而不是一句话让它「写完整管理后台」。
这样你可以在每个小步骤中及时纠正方向。
4.3 善用「对比」和「解释」
- 「帮我对比这两种写法的优缺点」；
- 「解释这段正则表达式的含义，并提供更易读写法」。
这些任务很适合 AI，能帮你节省大量心智负担。
5. 团队协作视角：怎么避免「风格四分五裂」？
如果团队里有人重度用 AI，有人不用，很容易出现：
- 代码风格忽然变了；
- 不符合团队既有规范；
- 出现一些「AI 风味」强的代码。
几个建议：
- 把团队已有的 ESLint/Prettier/架构规范告诉 AI，让它按这个来；
- 所有 AI 生成的代码仍然要走正常 Code Review；
- 在 Review 时，要求提 PR 的同学解释关键逻辑，而不是「AI 说的就是对的」。
6. 小结：把 AI 当「辅助开发环境」的一部分
第一次尝试用 AI 写前端代码之后，我的感受是：
- 它非常适合做：样板代码、工具函数、初次重构、单测草稿、代码解释；
- 不太适合完全托管复杂业务逻辑，尤其是涉及钱、风控、权限的地方；
- 它的价值很大一部分在于：降低「开始写」和「开始改」的阻力。
我现在更习惯把它看成：
一个永远在线的「会写代码的搜索引擎 + 实习生」，
好用，但需要你有足够判断力，知道哪些可以放心交给它，哪些必须自己亲自来。