AI 帮你写代码，但工程能力不可外包。这份指南覆盖知识地图、工作流、Prompt 模式、陷阱和工具栈。
AI 帮你写代码，但你需要知道什么时候该信任它、什么时候该接管。以下是不可外包的核心能力。
不是「会 git push」，而是理解分支策略、rebase vs merge、冲突解决。Vibe coding 时 AI 会频繁改动代码，每个功能一个 commit、能随时回退是生存底线。
AI 生成代码时依赖你给的项目结构。目录乱 → AI 输出乱。知道怎么组织 components/hooks/utils/types，让 AI 能读懂上下文。
Vite/Webpack/esbuild 的区别、为什么 dev server 和 production build 行为不同。AI 经常给你 dev-only 的写法，上线就炸。
Flexbox/Grid/层叠上下文/盒模型。AI 会给你一堆 CSS，但你得知道为什么页面乱了——AI 自己调试 CSS 的能力很弱。
什么时候用 useState、什么时候提起到 context、什么时候需要 Zustand/Redux。AI 默认全部塞 useState，项目大了就不可维护。
受控 vs 非受控、组合优于继承、props 接口设计。AI 生成的组件往往职责混乱——你需要能识别并重构。
浏览器 DevTools、React DevTools、网络面板、Performance 面板。AI 说「应该能跑」但跑不了时，只有你能查。
TypeScript 是 AI 协作的最佳接口。好的类型定义 = AI 输出质量翻倍。坏的类型 = AI 疯狂 any 滚雪球。
不是写多少测试，是知道测什么。关键路径 E2E、纯函数单元测试、组件快照测试。AI 能帮你写测试，但你得定义边界。
不是「说一句话让 AI 写完整个页面」，而是把前端开发拆成 AI 擅长的环节和人类必须掌控的环节。
先写 TypeScript 类型定义，不要让 AI 猜你的数据结构。这一步决定了后续所有代码的质量。
// types.ts interface User { id: string name: string email: string role: 'admin' | 'member' | 'guest' avatarUrl?: string } interface Project { id: string name: string ownerId: string members: User[] status: 'active' | 'archived' createdAt: string // ISO }
手动创建目录结构和空组件文件。AI 填充实现，但你控制架构。
src/ ├── components/ │ ├── ui/ # 通用 UI 组件 │ │ ├── Button.tsx │ │ └── Modal.tsx │ └── features/ # 业务组件 │ ├── UserCard.tsx │ └── ProjectList.tsx ├── hooks/ │ └── useUser.ts ├── types/ │ └── index.ts └── utils/ └── format.ts
一次只让 AI 实现一个组件。给它类型定义 + 组件签名 + 用途描述。不要一次生成整个页面。
Prompt 示例:
基于 types.ts 中的 User 类型，实现 UserCard 组件:
- 展示头像、姓名、角色 badge
- 点击头像跳转到 /users/[id]
- role 用不同颜色: admin=红, member=蓝, guest=灰
- 使用 Tailwind，不要引入新依赖
- 导出类型 UserCardProps = { user: User; onClick?: () => void }组件就绪后，手动组装页面，处理数据流和状态。这一步 AI 辅助但人类决策。
组装时关注: 1. 数据从哪来 (fetch / props / store) 2. loading / error / empty 三态 3. 组件间通信方向 (单向数据流) 4. 哪些状态是局部的、哪些是共享的
浏览器里跑起来，用 DevTools 调样式和交互。把具体问题反馈给 AI 修，而不是让它「优化一下」。
有效的反馈: ✅ "UserCard 头像在移动端溢出了，改成 max-w-full + object-cover" ✅ "点击后 URL 变了但页面没刷新，可能是 router 没触发" ❌ "改好看一点" ❌ "优化一下性能"
同样的 AI，不同的 Prompt 产生天差地别的代码。以下是实战中验证过的模式。
| 模式 | 什么时候用 | 示例 |
|---|---|---|
| 类型先行 | 开始新功能时 | 先给 TS 类型定义，再让 AI 实现组件 |
| 约束边界 | 防止 AI 引入无关依赖 | "只用 Tailwind + lucide-react，不要装新包" |
| 示例驱动 | 需要特定 UI 模式时 | 贴一个 CodePen / 截图，让 AI 复刻结构 |
| 渐进式 | 复杂功能 | 先实现静态版本 → 加交互 → 加加载状态 → 加错误处理 |
| 角色设定 | 需要遵循框架惯例 | "你是 Next.js App Router 专家，用 Server Components" |
| 反例驱动 | AI 一直生成你不想要的代码时 | "不要用 useEffect 做数据获取，用 SWR" |
| 测试先行 | 关键逻辑 | 先写测试用例，让 AI 实现到测试通过 |
每个 vibe coder 都踩过这些坑。提前知道能省很多时间。
AI 会自信地使用不存在的 API。比如 React 19 的 use() hook 在旧版本里不存在，或 Tailwind v4 的语法和 v3 完全不同。永远在官方文档里验证 AI 给的 API。
AI 喜欢「装个包解决问题」。一个简单的日期格式化，它会让你装 date-fns + dayjs + moment。在 prompt 里明确约束依赖，否则你的 bundle 会膨胀到 2MB+。
对话超过一定长度后，AI 会忘记之前的约定（用 Tailwind 不是 CSS module、用函数组件不是 class）。解决方案：把项目约定写进 CLAUDE.md 或 system prompt，而不是每次对话重复。
AI 会在不需要抽象的地方建抽象层——Generic Component Factory、一层套一层的 HOC、不必要的 Context Provider。简单直接永远比「优雅的架构」好维护。
AI 给的代码在 dev server 里跑得好好的，build 后白屏。常见原因：用了 Node.js API、动态 import 路径错误、CSS 变量未定义。始终在 CI 或本地跑一次 production build。
AI 生成的 UI 经常缺少 aria-label、键盘导航、焦点管理。不是 AI 的错——是大多数人不在 prompt 里提这些。加上"符合 WCAG AA"就能大幅改善。
不是唯一选择，但这是经过验证的组合——AI 对这些工具的训练数据最充分，生成质量最高。
| 层 | 推荐 | 为什么 |
|---|---|---|
| 框架 | Next.js (App Router) | AI 训练数据最多，Server Components 减少客户端 JS |
| 样式 | Tailwind CSS v4 | AI 对 Tailwind 的掌握远超 CSS Modules / styled-components |
| 类型 | TypeScript (strict) | 类型是 AI 协作的接口，strict 模式防止 any 滥用 |
| 组件库 | shadcn/ui | 复制粘贴模式，AI 能直接修改源码而非配置主题 |
| 状态 | Zustand + SWR | 比 Redux 简洁，AI 不容易生成过度样板化的代码 |
| 测试 | Vitest + Playwright | Vitest 快如闪电，Playwright E2E 覆盖关键路径 |
| 图标 | Lucide React | 轻量、tree-shakeable、AI 认识所有图标名 |
| 部署 | Cloudflare Pages / Vercel | 零配置部署，预览 URL 方便分享验证 |