从《氛围编程》泡泡书中学到的9条Tips

前段时间回老家，今天才拿到吾真本的《氛围编程》泡泡书，哈哈直接一口气翻完啦👋
从2月份到现在，vibe-coding的时长少说也有600个小时了，自以为个各种小实践都趟过了，一看还是发现泡泡书有很多实用的 tips，快速做个整理记录，下周开始用起：

1 多工具组合方法

针对相对复杂的需求，组合多个工具完成不同的需求，一来利用不同工具的有点效率更高，二来就是省 token（这个已经在实践了，不过还可以持续优化）

我现在的工作流程一般是：

1）使用 Gemini/AI原型设计器，先设计初始版产品设计提示词
2) v0/loveable 生成初版原型，前端页面交互先完成
3) Augment来设计架构并完成核心交互功能
4) Augment来优化架构，实现必要的前后端分离/数据库集成/大模型 API集成工作
5) 用Gemini来设计产品的设计系统提示词
6) 以当前 APP 和设计系统提示词为输入，让uxpilot 或 Figma来进行界面优化设计
7) 把输出的 HTML 页面代码作为输入，让 Augment来重构优化现有界面
8）复杂的功能重构或Bug 修复，先让 Augment+GPT5 来做设计；然后再让 Claude 4 执行
9）同步开着 Trae，如果是简单的功能修改，会让 Trae Builder 来做，复杂的功能让Augment 来执行（Trae里面代码执行完之后直接预览，可选中 UI 元素来进行调整，这个体验还是很不错）

2. 理测评解 4 步法

当希望在需求复杂且需长期稳定运行的软件系统中试点Vibe Coding时，应按照软件架构设计最佳实践将试点组件拆分出来，并在生成代码后，理解、测试、评审和解释大模型的每一行代码，才能将其提交到代码库(现在AI搭子里面的好几个工具代码都超过 3 万行了，得当个遗留系统来维护更新了——准备尝试加到User Rules 文件来固化这个流程，免得平时用的时候又偷懒)

3. 工具升级指导原则 —— 自己想不清楚的时候用更厉害的工具

当你对任务的意义、概念和实现方法理解不够深入，难以用提示词清晰表达时，需要选择能力和口碑更强的Vibe Coding工具与大模型（比如 Augment+GPT5/Claude 4）

4. Kaggle网站查找数据集

Kaggle 一个面向数据科学家和机器学习从业者的数据科学竞赛平台和在线社区，用于发布和查找数据集（学到了！）

5. 非技术背景的人员，也适合使用IDE工具

我现在使用最多的是 Augment Code，一开始也在犹豫是否要跟其他产品伙伴们推荐 Augment——会不会门槛过高？《氛围编程》书中的建议是，即使没有编程经验的人也会很容易掌握 IDE 的基本使用，而使用 Augment/Trae 的优势比如指定代码文件或者文档作为上下文，以及直接报告的编译错误等优势都会更加高效。所以我也就放心把 Augment/Trae/Cursor 也列入针对产品经理的推荐工具啦～

6. 使用 Project Rules为项目设置特定约束规则

之前在 v0/Cursor/Augment 中都用到了 User Rules，但还没有用过 Project Rules——以前总是加个单独的 md 文件来说明一些css，API 调用规则，但遵循性好像并不好——接下来可以试试Project Rules啦

7. 在仅做 MVP 原型时，提示词中加入最精简的技术栈建议

在做出第一版MVP原型实现时，提示词是否要加“技术栈要求”？结合书中给出的建议，及自己的实践，我的建议是需要加，但要用最简单的方式加（比如先不要做前后端分离）——以免一开始架构过于复杂，在实现初始版本之前遇到依赖库/配置等无关的架构问题，干扰主线目标。
这是我建议的默认技术栈提示词：

核心框架

Next.js 15 - React 全栈框架，支持 SSR/SSG/API Routes
React 18 - 前端 UI 框架
TypeScript - 类型安全的 JavaScript 超集
UI 组件与样式
shadcn/ui - 现代化组件库
Radix UI - 无样式、可访问的 UI 原语
Tailwind CSS - 实用优先的 CSS 框架
Lucide React - 现代图标库
CSS Variables - 主题系统支持
状态管理与数据处理
Zustand - 轻量级状态管理
TanStack Query (React Query) - 服务端状态管理
React Hook Form - 表单状态管理
Zod - TypeScript 优先的模式验证
开发工具与构建
ESLint - 代码质量检查
PostCSS - CSS 后处理器
Autoprefixer - CSS 自动前缀
API 与后端集成
Next.js API Routes - 全栈 API 端点
- App Router 架构 ( route.ts 文件)
- RESTful API 设计
- TypeScript 支持
- 统一错误处理
- 环境变量配置
- 参数验证与类型检查
通用工具库
clsx - 条件类名工具
class-variance-authority (CVA) - 变体样式管理
cmdk - 命令面板组件
date-fns - 日期处理库
用户体验增强
Sonner - 现代化通知系统
Next Themes - 主题切换支持
Embla Carousel - 轮播组件
Recharts - 数据可视化图表

8. 当第一版端到端功能完成后，让 AI 来梳理架构和调用链路

当功能一多，比如页面有3 个以上，组件有 10 个以上的时候，还要用数据库和 AI 功能，代码架构就会变得复杂，如果没有清晰的架构约束，就会出现改1步退2步、或者陷入Bug 泥潭，怎么修都修不好/越修越错的情况。此时就需要从逻辑上理解架构和逻辑调用链路，来帮 AI 指定修改的范围和调整的方向。比较好的办法就是让 AI 来自己梳理架构和调用链路图。比如书中给出的这段提示词：

请理解整个代码库 , 分析这个项目的前后端代码，按照 c4 模型的三层架构(上下文层、容器层、组件层)用 Mermaid 脚本绘制3个层级的架构图。每个脚本分别以 c4context、C4Container 和C4Component 开头。3个层级的架构图需体现层层深入的特征,例如可以将容器层中的前后端部分在组件层中展开详述。另外要求以c4Container 和c4Component 开头的两张图里都要画 User。
在组件层中请标注每个组件对应的源文件名，以便快速查找相关代码。在容器层中需标注所有技术栈的具体版本号。

9. 让 AI 添加端到端测试并在提交前运行

之前有的时候 AI 会生成一些测试代码，我因为不知道如何管理，总觉得多余，在跑完以后还会直接手动删除。但如果已经有一个相对成熟的版本发布在使用，要做大的功能升级，还是应该有对第一个版本的端到端测试做保护，从书中学到的方法是单独放到一个目录，并且可以用 npm test 来 run 这些测试（以前都不知道哦～）

学了这 9 条，感觉自己的 vibe coding 技能又上了一个台阶啦～
对于初学者来说，按照书中的实操一遍，Vibe coding 的技巧就从L1到L2啦——我的书已经被我家初中生占为己有啦～