AI 辅助前端开发的正确姿势
这篇文章不讲 prompt 技巧，不列工具对比表格。分享的是我 2025–2026 年在真实项目中用 AI 辅助前端开发的工作流和判断标准。
2026 年的 AI 编码工具有一个共同特征：它们已经够好了，但前提是你知道怎么用。这个"怎么用"不是指写 prompt 的技巧，而是指：什么时候该用、什么时候不该用、怎么验证输出、怎么在团队层面落地。
一个判断框架：什么任务交给 AI
我总结了一个简单的四象限判断，用来决定一个任务是否适合 AI：
高复杂度
│
AI 辅助策划 │ AI 辅助实现
(给方向) │ (写代码)
│
──────────────┼──────────────→ 高确定性
│
自己写 │ AI 自动化
(不适合AI) │ (重复劳动)
│
低复杂度- 高确定性 × 高复杂度（右上）：AI 最适合。比如"写一个符合 OpenAPI 规范的接口 handler"。规范清楚、预期明确，AI 能一次搞定。
- 低确定性 × 高复杂度（左上）：AI 适合做调研和方案生成，但需要你审校和决策。比如"设计这个页面的组件结构"。
- 高确定性 × 低复杂度（右下）：用自动化脚本，不必每次都调 AI。
- 低确定性 × 低复杂度（左下）：自己写更快。比如改个文案、调个颜色。
判断依据就一句话：AI 写的代码我能不能一眼判断对不对？
能 → 交给 AI。不能 → 先自己理清楚。
我的 AI 辅助工作流
这套流程的核心逻辑是：用 AI 处理执行，用人脑处理决策。
Step 1：建立上下文
这是最容易被跳过、但最重要的一步。
AI 在没有上下文的情况下写的代码，看起来没错，但放进项目里就是不对劲——用的变量名不合约定、样式没走设计 token、import 路径风格不一致。
做法：项目根目录放一个 CLAUDE.md（Cursor 用户是 .cursorrules），告诉 AI 这个项目的基本约定。
我的 CLAUDE.md 大概长这样：
markdown
# 项目规范
## 技术栈
- Vue 3 + TypeScript + Vite
- Pinia 状态管理，不用 Vuex
- Vue Router 4，hash 模式
## 代码规范
- Vue 组件用 Composition API + `<script setup>`
- CSS 用 Tailwind utility class，少写自定义 CSS
- 组件文件名用 kebab-case
- 接口定义放在 `src/types/`，按模块拆分
- API 调用封装在 `src/api/`，不在组件里直接 fetch
## 组件设计
- 一个组件不超过 150 行，超出就拆分
- Props 必须用 TypeScript 类型标注
- 复杂组件要有 loading / error / empty 状态当我开始新功能时，先读这个文件再看现有组件的写法——然后让 AI 按同一套标准写代码。效果立竿见影：AI 生成的代码可以和队友 review 了。
Step 2：描述意图，不是描述实现
这是我观察到的最大的 common mistake：开发者花十分钟详细描述 AI 应该怎么写代码，而不是花一分钟描述想要什么效果。
diff
- // ❌ 告诉我用 array.reduce 分组，然后 Object.entries 遍历
- // 在 TableHeader 组件里加一个排序功能
+ // ✓ 用户点击表头按该列排序，再次点击切换方向
+ // 现有组件在 src/components/TableHeader.vue前者是"描述实现"，后者是"描述意图"。
AI 比你更擅长写实现——前提是你告诉它你要什么，而不是教它怎么写。 给 AI 一个目标函数，而不是一步步操作步骤。
Step 3：写测试描述，让 AI 生成测试
这是 AI 辅助开发里性价比最高的场景。
把测试当成"可执行的 spec"来写：
typescript
describe('SearchInput', () => {
it('输入文字后 300ms 触发搜索，防止频繁请求')
it('清空输入框时搜索重置为默认结果')
it('搜索 loading 状态正确显示')
it('搜索失败时显示错误提示，不隐藏搜索结果')
})然后告诉 AI：按上述描述生成 Vue Test Utils + Vitest 测试用例。
AI 生成的测试可能需要小修，但骨架有了，边界情况也覆盖了。这比手动写测试快 10 倍。
Step 4：diff review
这是绝对不能跳过的步骤。
AI 生成的代码，在合并之前，你必须逐行 review diff。这个过程中我会检查：
- 逻辑正确性 — AI 有没有"发明"不存在的 API？有没有路径写错？
- 异常处理 — try-catch 覆盖了？错误状态有了？
- 边界情况 — 空数组、null、undefined 会不会崩？
- 可维护性 — 如果六个月后我来改这代码，能看懂吗？
AI 擅长写"happy path"，弱于处理边界。 所以 review 一定要盯着边界看。
Step 5：截图反馈循环
这是前端开发特有的环节。AI 写的 CSS 在逻辑上可以完全正确，但看起来就是不对劲。
我的做法：写完后跑 dev server，截屏，把截图发给 AI（Claude Code / Cursor 都支持图片输入），问题具体描述而不是泛泛说"不好看"：
diff
- // ❌ 这个按钮看起来不对
+ // ✓ 按钮的 hover 效果太生硬，加 transition
+ // padding 上下 12px 左右 20px
+ // 背景色改成从 primary-600 渐变到 primary-700AI 擅长根据视觉反馈做精准的 CSS 调整。两三次迭代就能达到和设计稿一致的效果。
什么时候不应该用 AI
1. 复杂的状态交互
场景：三个组件共享状态，涉及生命周期、异步竞态、内存管理
AI 在处理跨越多个文件的复杂状态时容易出错。不是它写不出来，而是它容易漏掉一个更新路径，导致 bug 很隐蔽。
做法：自己在纸上把状态机画清楚，然后让 AI 按你画的路径写实现。
2. 安全相关的逻辑
场景：权限校验、支付处理、数据脱敏
AI 生成的代码倾向于"功能正常"，但在安全性上经常偷懒。比如忘记校验空值、鉴权判断漏了边界。
做法：安全逻辑自己写核心判断，AI 只负责外围（输入验证、错误展示等）。
3. 需要深度理解现有业务逻辑的修改
场景：在一个写了三年的代码库里改一个五层嵌套的条件判断
AI 的上下文窗口再大也大不过你对业务本身的理解。这种情况下，"让 AI 改"的风险 >= "自己改"的时间成本。
做法：先理清现有的逻辑链路，改完后用 diff review 反复验证。
在团队中落地 AI 辅助开发
原则：代码规范在前，AI 辅助在后
团队引入 AI 辅助开发，最大的风险不是"AI 写的代码有问题"——AI 写的代码大多是对的——而是代码风格和架构一致性被破坏。
解法：先定好规范，再让 AI 按规范写。CLAUDE.md / .cursorrules 是团队的"编码宪章"，每个人（包括人类和 AI）都要遵守。
原则：人的 review 不可替代
不要在 PR 里放 AI 生成的代码而不 review。这会让团队失去对代码库的掌控感。
我在团队里推行这条规则：AI 生成的代码，PR 里必须标注来源。 比如在 PR description 里写"TableHeader 组件由 AI 辅助生成，已 review"。这样 reviewer 知道要对哪些部分重点检查。
原则：把测试覆盖率作为 AI 代码的门禁
我们的 CI 有一条规则：AI 生成的新代码如果降低了测试覆盖率，CI 不通过。这倒逼开发者要么自己补测试，要么让 AI 生成测试。
结果是——AI 生成测试的频率比人类高得多。因为"让 AI 写测试"几乎零门槛，而手动补测试的意愿阈值要高得多。
总结
AI 辅助开发的正确姿势不是"让 AI 写一切的 prompt"，而是一套带有决策节点的工作流：
- 判断 — 这个任务适不适合 AI（用四象限判断）
- 喂上下文 — 让 AI 了解你的规范和已有代码
- 描述意图 — 告诉 AI 你想要什么效果，不是教它怎么实现
- 生成 + 验证 — AI 写代码、写测试，人 review diff
- 视觉迭代 — 截图反馈让 AI 优化（前端特有）
- 团队规范 — CLAUDE.md 和 CI 规则确保一致性
这套流程和我在 OpenSpec 系列文章 里提到的"规范驱动开发"是一脉相承的：先明确方向和约束，再用 AI 加速执行。 不把 AI 当黑箱，而是当团队里最勤奋的 junior 工程师——写得多、写得快，但需要 senior 审核后才能合入。
工具一直在变，但"人做判断、AI 做执行"这个分工不会变。