前端工程师的 Vibe Coding 最佳实践（三）：质量保障与工程化

前两篇解决了「怎么让 AI 写得又快又准」，这一篇解决最关键的问题：怎么让这些代码敢上线。 这是区分「玩具 demo」和「专业工程」的分水岭，也是 AI 时代前端工程师真正的护城河。

一、第一性原理：AI 提升的是「产出速度」，不是「质量下限」

一个残酷的事实：AI 会把你的好习惯放大，也会把你的坏习惯放大。

你有评审 + 测试 + 护栏的习惯 → AI 帮你以 5 倍速度产出可靠代码。
你没有这些习惯 → AI 帮你以 5 倍速度产出屎山，而且是你看不懂的屎山。

所以工程化不是「可选项」，而是用 AI 的前提。下面从四道防线讲起：评审 → 护栏 → 测试 → 安全。

二、第一道防线：评审纪律（Review Discipline）

这是最重要的人工防线。重申第一篇的铁律：不要合并你看不懂的代码。

怎么高效审 AI 的代码

AI 的代码有它特有的「坑点分布」，审查时重点盯这些：

高发问题	具体表现
🔴 幻觉 API	调用了不存在的方法、传了不存在的参数、用了过时的库用法
🔴 边界条件	空数组/null/undefined、空字符串、0、超长输入没处理
🔴 错误处理缺失	异步没 catch、loading/error 态没做、失败了静默
🟡 过度设计	为一个简单需求引入抽象层、设计模式、不必要的依赖
🟡 偷偷加依赖	顺手 `npm install` 了一个你不需要的包
🟡 复制式重复	不复用已有工具/组件，又造一个轮子
🟡 性能隐患	不必要的 re-render、缺 memo、巨大 bundle、循环里发请求

一个好用的「自审」技巧

让 AI 先审自己，再交给你：

你刚才的实现，请用资深前端的标准自查一遍：
有没有未处理的边界条件、内存泄漏、类型不安全、可访问性问题？
如果有，直接修。

但永远不要用「AI 自审通过」替代「人工审查」——这只是帮你过滤掉一批低级问题，最终把关的还是你。

红线：警惕「自动化偏见」

人有个心理弱点叫自动化偏见：机器给的答案，我们倾向于不假思索地信。AI 措辞越自信，越容易让你放松警惕。对越「顺滑、自信」的输出，越要多看一眼。

三、第二道防线：用工程护栏「绑住」AI

最聪明的做法，是让机器去约束机器——配置好自动化护栏，AI 的低质量输出会被工具直接拦下，根本到不了你眼前。这是「四两拨千斤」的一步。

前端项目的护栏清单：

TypeScript strict 模式：strict: true、noUncheckedIndexedAccess 等。类型系统是最强护栏，AI 一旦类型对不上就报错，幻觉 API 当场暴露。
ESLint + 规则集：eslint-plugin-react-hooks（hooks 依赖项）、jsx-a11y（可访问性）、no-floating-promises（异步没处理）等。
Prettier：统一格式，省掉所有风格争论。
pre-commit 钩子（husky + lint-staged）：提交前自动跑 lint + 类型检查 + 测试，不过不让提交。
CI 流水线：PR 必须通过 lint / typecheck / test / build 才能合并。
依赖守门：用 lockfile，CI 检查依赖变更，防止 AI 偷偷加包或引入有漏洞的版本。

关键心法：把你的质量标准「代码化」成工具配置。 这样无论是你、队友还是 AI 写的代码，都被同一套客观标准卡住。AI 写得越多，这套护栏的价值越大。

而且这形成一个正反馈闭环：护栏报错 → 把错误丢回给 AI → 它自己修 → 再次校验。很多工具已经能自动读取 lint/类型错误并自我修复，你要做的就是先把护栏建好。

四、第三道防线：测试策略

「AI 写的代码能跑」和「AI 写的代码正确」是两回事。测试是验证正确性、且让你敢于重构的安全网。

用 AI 写测试，但你定「测什么」

AI 特别擅长写测试样板，但测试用例的设计（尤其是边界和异常）需要你主导：

为 @src/utils/formatPrice.ts 写单元测试（Vitest）。
必须覆盖这些用例：
  - 正常金额：1234.5 → "¥1,234.50"
  - 0 → "¥0.00"
  - 负数、null、undefined、NaN
  - 超大数字（千分位）
  - 小数精度（0.1 + 0.2 这类）

注意：是你列出边界用例，AI 来实现。因为「想到该测什么」恰恰是 AI 容易漏、而工程师该负责的判断。

警惕「测试造假」

AI 有时会写出为了通过而通过的测试——比如把断言写成迎合当前（可能有 bug 的）实现，或者 mock 掉了真正该验证的逻辑。审测试代码时问自己：这个测试如果实现写错了，它会失败吗？ 不会的话，这测试就是摆设。

前端测试的分层建议

单元测试：纯函数、自定义 hooks、工具方法——性价比最高，AI 写起来又快又好。
组件测试（Testing Library）：交互行为、条件渲染、可访问性。
E2E（Playwright）：关键用户路径（登录、下单、支付），数量少而精。
别追求覆盖率数字，追求关键路径和边界被覆盖。

五、第四道防线：安全红线

这是绝对不能对 AI 放松的地方。AI 没有安全直觉，它只会让代码「能跑」，不保证「安全」。

前端安全自查清单：

XSS：警惕 dangerouslySetInnerHTML / v-html。AI 经常图省事直接塞 HTML——用户输入必须经过消毒（如 DOMPurify）。
密钥泄露：AI 可能把 API key、token 硬编码进前端代码或提交进仓库。前端没有秘密，敏感密钥永远放后端。
输入校验：不要只信前端校验，但前端该做的边界（长度、格式、类型）也要做，且服务端必须再校验一遍。
鉴权/权限：登录态、路由守卫、按钮级权限——AI 容易做「假权限」（只藏 UI 不挡接口）。真正的权限必须在后端。
依赖安全：AI 引入的包要查是否有已知漏洞（npm audit）、是否维护活跃、体积是否离谱。
URL/重定向：开放重定向、target="_blank" 不加 rel="noopener" 等小坑。

一句话：鉴权、加密、支付、用户数据处理——这些逻辑，AI 的每一行都要当作不可信，逐行审查 + 重点测试。

六、前端专项检查清单（贴在显示器旁）

除了通用工程，前端有自己特有的、AI 容易翻车的点：

性能

列表用稳定 key，不是数组 index
大列表有虚拟化（react-window 等）
合理 memo / useMemo / useCallback，但别滥用
没有在渲染期做重计算 / 发请求
图片有懒加载、合适尺寸、现代格式
关注 bundle 体积（AI 引入的大库？按需引入？code splitting？）

可访问性（a11y）

交互元素用语义化标签（<button> 而非 <div onClick>）
图片有 alt，表单有 label
键盘可达、焦点可见、必要的 aria-*
颜色对比度达标

健壮性

loading / empty / error 三态都做了
异步竞态处理（快速切换不出现旧数据覆盖新数据）
组件卸载时清理副作用（定时器、监听、订阅、AbortController）
防抖/节流用在该用的地方（搜索、滚动、resize）

一致性

复用了设计系统/现有组件，而不是重造
响应式在主流断点都正常
文案、间距、交互与产品其它部分一致

七、反模式合集（这些坑别踩）

反模式	后果	正确做法
🚫 大爆炸提示，一次生成整个功能	几百行陌生代码无从审起	小步快跑，分步验证
🚫 「能跑就行」，不读 diff 直接合并	埋雷，线上爆炸	逐行审查，看不懂就别合
🚫 AI 跑偏了还硬掰	越掰越乱，浪费 token	果断停下、纠偏或重启会话
🚫 让 AI 自由装依赖	包膨胀、安全风险	明确约束「不要引入新依赖」
🚫 把架构决策甩给 AI	方向错，全盘返工	架构自己定，AI 当参谋
🚫 无脑接受「AI 自审通过」	漏掉真问题	自审 + 人审 + 自动护栏，三重
🚫 在脏的长对话里继续	AI 忘事、跑题、出错率高	适时开新会话，带上必要上下文
🚫 复制粘贴敏感逻辑不审查	安全事故	安全代码逐行审 + 重点测

八、AI 时代的「完成定义」（Definition of Done）

给你一份可直接落地的清单。一个 AI 辅助完成的前端任务，满足以下全部才算「Done」：

□ 我完全理解每一行代码，能向别人讲清楚
□ 通过了 lint / 类型检查 / 格式化
□ 关键逻辑和边界有测试覆盖，且测试是「真的在测」
□ loading / empty / error 三态完整
□ 无安全红线问题（无硬编码密钥、输入消毒、权限正确）
□ 性能无明显隐患（key / re-render / bundle / 内存泄漏）
□ 可访问性达标
□ 复用了现有组件/工具，没造重复轮子，没乱加依赖
□ 在真实环境/数据下手动验证过
□ commit 信息清晰，diff 干净

把这份清单也写进你的 rules 文件，让 AI 在交付前自己对照一遍——但最终一项「我完全理解」，只有你能打勾。