Vibe Coding 配方手册

配合 思考框架 使用：先用 5 层分析法想清楚系统逻辑，再来这里查配方给 AI 下指令。

这是从系统设计知识点到实际 vibe coding 的桥梁。学完知识点后，用这里的配方直接给 AI 下指令。

使用方式：

1. 遇到具体问题 → 查 Part 1 决策速查表，找到对应方案和指令
2. 要从零搭建系统 → 查 Part 2 找最接近的配方，填入你的需求
3. 做完5层分析 → 用 Part 3 的模板转换成 Prompt

---

Part 1: 决策速查表

数据存储选型

场景	方案	给AI的关键指令
读多写少	B-Tree + 缓存	”用PostgreSQL，对查询字段建B-Tree索引，热点数据用Redis缓存”
写多读少	LSM-Tree引擎	”用Cassandra或RocksDB作为存储引擎，适合高写入吞吐”
全文搜索	倒排索引	”用Elasticsearch建倒排索引，支持分词和相关性排序”
实时排名	Redis Sorted Set	”用Redis ZADD更新分数，ZREVRANGE取Top N”
复杂关系查询	图数据库	”用Neo4j存储关注/好友关系，支持多跳查询”
时序数据/日志	时序数据库	”用InfluxDB或TimescaleDB存储带时间戳的指标”
多源异构数据	文档模型	”用MongoDB，schema灵活，不同来源结构可以不同”

缓存策略

场景	方案	给AI的关键指令
热点数据加速	Cache-aside + LRU	”查询先查Redis，miss再查DB并回填，用LRU淘汰”
写入后立即读	Write-through	”写入时同步更新缓存和DB”
写密集容忍短暂不一致	Write-behind	”写入只更新缓存，异步批量刷到DB”
防缓存穿透	布隆过滤器/缓存空值	”不存在的key缓存空值TTL 5分钟，或布隆过滤器前置拦截”
防缓存雪崩	随机TTL	”缓存过期时间加随机偏移(基础TTL ± 10%)，避免同时失效”
防缓存击穿	互斥锁	”热key过期时用分布式锁，只允许一个请求回源”
静态资源加速	CDN	”图片/视频/JS/CSS通过CDN分发，设置Cache-Control”

并发与一致性

场景	方案	给AI的关键指令
怕超卖/超扣	悲观锁	”库存扣减用 SELECT ... FOR UPDATE 加行锁，在事务内完成”
低冲突高并发	乐观锁	”加version字段，UPDATE ... WHERE version=旧版本，失败重试”
跨服务事务	Saga模式	”拆成多个本地事务+补偿操作，失败反向回滚”
需要强一致	同步复制	”数据库配置同步复制，写入等所有副本确认”
容忍短暂不一致	异步复制	”主库写入即返回，从库异步同步，业务容忍秒级延迟”

异步与消息

场景	方案	给AI的关键指令
长耗时操作	消息队列	”API立即返回202，任务丢进队列，worker异步处理”
一对多消费	发布/订阅	”用Kafka topic，不同consumer group各自消费”
消息不能丢	At-least-once + 幂等	”消息确认机制 + 消费端用幂等key去重”
消息必须有序	同一分区	”用相同partition key保证同一实体消息进同一分区”
消费失败	死信队列	”重试3次失败进死信队列，人工或定时处理”

扩展与高可用

场景	方案	给AI的关键指令
读瓶颈	读写分离	”主库写，多从库读，负载均衡分发读请求”
数据量瓶颈	分区	”按key哈希分区到多节点，用一致性哈希减少迁移”
热点key	加盐分散	”热点key加随机后缀分散到多个分区，或本地缓存”
服务高可用	多实例+健康检查	”至少2个实例，负载均衡器健康检查，自动摘除故障”

API设计

场景	方案	给AI的关键指令
RESTful接口	资源+HTTP动词	”资源用名词复数，GET查/POST创建/PUT更新/DELETE删除”
大列表返回	游标分页	”用cursor-based分页(返回next_cursor)，不要用offset”
防滥用	限流	”加Rate Limiter，令牌桶算法，按用户ID限流”
接口幂等	幂等key	”客户端生成唯一idempotency_key，服务端去重”

---

Part 2: 系统级 Prompt 配方

以下6种常见系统类型的完整 Prompt 模板。做完5层分析后，找到最接近的类型，填入你的具体需求即可。

---

配方1: CRUD + 库存/预订类系统

代表案例：Hotel Reservation、电商订单、票务系统

核心挑战：并发安全、不超卖

关键架构决策：

• 存储：关系数据库（PostgreSQL）— 强事务保证
• 并发：悲观锁（库存扣减）
• 事务：Saga模式（跨服务场景）
• 复制：同步复制（一致性优先）
• 缓存：搜索结果短TTL缓存

示例 Prompt：

请用 Go + Gin + PostgreSQL 实现一个酒店预订系统。

核心功能：
1. 酒店和房型管理（CRUD）
2. 按城市+日期搜索可用酒店
3. 预订房间（扣减库存）
4. 取消预订（恢复库存）

数据模型：
- Hotel: id, name, city, address, rating
- RoomType: id, hotel_id, name, price, capacity
- Inventory: room_type_id, date, total, booked（每天每房型一行）
- Order: id, user_id, room_type_id, check_in, check_out, status, total_price

关键要求：
- 库存扣减必须用 SELECT ... FOR UPDATE 防止超卖
- 预订时检查日期范围内每一天的库存
- 取消预订恢复库存，用事务保证原子性
- 搜索结果缓存30秒（Redis）
- 列表接口用cursor分页

先实现MVP（搜索+预订+取消），暂不需要支付。

---

配方2: 信息流/社交类系统

代表案例：News Feed、Twitter、朋友圈

核心挑战：扇出效率、信息流生成

关键架构决策：

• 推拉混合：普通用户推模式，大V拉模式
• 消息队列：异步分发到粉丝feed
• 缓存：Redis List存feed
• 一致性：最终一致

示例 Prompt：

请用 Go + Gin + PostgreSQL + Redis 实现一个社交信息流系统。

核心功能：
1. 用户关注/取关
2. 发布动态（文字+图片URL）
3. 拉取信息流（关注的人的动态，按时间倒序）

数据模型：
- User: id, name
- Post: id, user_id, content, media_urls, created_at
- Follow: follower_id, followee_id

信息流方案（推模式）：
- 发帖时，异步将帖子ID写入每个粉丝的feed缓存（Redis List）
- 拉取信息流时，从Redis List读取帖子ID，再批量查帖子详情
- 用消息队列（可先用channel模拟）异步分发

关键要求：
- 信息流用cursor分页（基于post_id，不用offset）
- 发帖接口立即返回，feed分发异步
- 粉丝数>10000的用户不走推模式（读时拉取合并）

先实现核心信息流，暂不需要点赞评论。

---

配方3: 实时通信类系统

代表案例：Chat System、在线客服、协作工具

核心挑战：实时推送、消息有序、离线消息

关键架构决策：

• WebSocket：实时推送通道
• 持久化：消息必须入库
• 有序性：同一会话内有序
• 一致性：因果一致

示例 Prompt：

请用 Go + Gin + PostgreSQL + WebSocket 实现一个聊天系统。

核心功能：
1. 1对1聊天
2. 实时消息推送（WebSocket）
3. 离线消息（上线后推送未读）
4. 历史消息加载（向上翻页）

数据模型：
- User: id, name, online_status
- Conversation: id, type(1v1/group), created_at
- Participant: conversation_id, user_id
- Message: id, conversation_id, sender_id, content, type, created_at

关键要求：
- 用WebSocket保持长连接，消息实时推送
- 消息必须持久化到DB（不能只靠WebSocket）
- 用户离线时消息存DB，上线后批量推送未读
- 同一会话的消息按created_at排序
- 历史消息用cursor分页（基于message_id倒序）
- 消息发送幂等（client_message_id去重）

先实现1v1聊天，群聊后续再加。

---

配方4: 内容存储+分发类系统

代表案例：YouTube、Google Drive、图床

核心挑战：大文件处理、全球分发

关键架构决策：

• 对象存储：S3/MinIO存文件
• 异步处理：转码/缩略图生成
• CDN：静态资源分发
• 分块上传：大文件支持断点续传

示例 Prompt：

请用 Go + Gin + PostgreSQL + MinIO 实现一个视频平台。

核心功能：
1. 视频上传（支持大文件）
2. 视频列表和搜索
3. 视频播放

数据模型：
- User: id, name
- Video: id, uploader_id, title, description, status(uploading/processing/live/failed), duration, thumbnail_url, created_at
- VideoFile: id, video_id, resolution, format, storage_path, size

关键要求：
- 大文件用分块上传（multipart），支持断点续传
- 视频文件存MinIO，元数据存PostgreSQL
- 上传完成后异步转码（可先用goroutine模拟）
- 转码生成多个分辨率版本（720p, 1080p）
- status字段跟踪处理进度
- 缩略图自动生成

先实现上传+播放，推荐系统后续再加。

---

配方5: 搜索类系统

代表案例：Search Engine、站内搜索、知识库检索

核心挑战：全文检索、相关性排序

关键架构决策：

• 倒排索引：Elasticsearch
• 分词器：中文分词
• 评分：BM25相关性
• 高亮：匹配片段

示例 Prompt：

请用 Go + Gin + Elasticsearch 实现一个内部文档搜索系统。

核心功能：
1. 文档导入（标题+正文+作者+标签）
2. 全文搜索（关键词匹配）
3. 搜索结果高亮
4. 按来源/作者/时间筛选

数据模型（ES Index）：
- doc_id, source, title, content, author, tags[], updated_at

关键要求：
- 用Elasticsearch中文分词器（ik_max_word）
- 搜索支持标题和正文全文匹配
- 结果按相关性(BM25)排序，可切换按时间
- 匹配片段高亮显示
- 搜索结果分页
- 按source和author筛选

先实现搜索和筛选，自动补全后续再加。

---

配方6: 地理位置类系统

代表案例：Proximity Service、外卖/打车平台

核心挑战：地理空间查询效率

关键架构决策：

• PostGIS/GeoHash：空间索引
• 距离计算：精确距离排序
• 范围自适应：无结果时扩大搜索

示例 Prompt：

请用 Go + Gin + PostgreSQL(PostGIS) 实现一个附近商家搜索服务。

核心功能：
1. 商家注册（名称+地址+坐标+类别）
2. 附近搜索（经纬度+半径，返回附近商家）
3. 按类别筛选
4. 按距离排序

数据模型：
- Business: id, name, category, location(PostGIS Point), address, rating, hours

关键要求：
- 用PostGIS的ST_DWithin做范围查询
- 用ST_Distance计算精确距离并排序
- 对location字段建GiST空间索引
- 支持按category筛选
- 搜索结果用cursor分页
- 半径内无结果时自动扩大范围（翻倍，最大50km）

先实现搜索，导航后续再加。

---

Part 3: 5层框架 → Prompt 转换模板

做完5层分析后，填入这个模板就能生成给 AI 的 Prompt：

请用 {技术栈} 实现一个{系统名称}。

## 目标用户与核心场景
{第1层：谁在用，完成什么任务}

核心用户故事：
{第2层：列出2-3个关键场景}
1. ...
2. ...
3. ...

## 功能需求
MVP：
{第3层MVP功能}
- ...
- ...

后续迭代：
{第3层扩展功能}
- ...

## 数据模型
{第4层：列出核心实体及字段}
- Entity1: field1, field2, ...
- Entity2: field1, field2, ...
关系：{描述实体间关系}

## 关键流程
{第5层：用Given/When/Then描述核心流程}

### 流程1: {名称}
- Given: {前提条件}
- When: {用户动作}
- Then: {系统响应}
- 失败路径: {异常处理}

### 流程2: {名称}
- Given: ...
- When: ...
- Then: ...
- 失败路径: ...

## 非功能性需求
- 一致性：{强一致/最终一致，说明原因}
- 预估规模：{QPS / 存储量 / 带宽}
- 关键架构决策：
  - 存储：{选型和理由}
  - 缓存：{策略}
  - 并发：{锁/事务策略}
  - 异步：{哪些操作异步}

请先实现MVP功能。

使用示例

假设你用5层框架分析了一个”二手交易平台”：

请用 Go + Gin + PostgreSQL + Redis 实现一个二手交易平台。

## 目标用户与核心场景
卖家（发布闲置物品）和买家（搜索和购买物品）。

核心用户故事：
1. 卖家拍照 → 填写商品信息和价格 → 发布 → 在商品列表中可见
2. 买家搜索关键词 → 看到匹配商品 → 按价格/距离排序 → 联系卖家
3. 买家下单 → 卖家确认 → 买家付款 → 卖家发货 → 买家确认收货

## 功能需求
MVP：
- 商品发布（标题、描述、图片、价格、位置）
- 商品搜索和浏览
- 下单和简单状态流转

后续迭代：
- 站内聊天、评价系统、推荐

## 数据模型
- User: id, name, phone, location
- Product: id, seller_id, title, description, images[], price, status(available/sold/removed), location, created_at
- Order: id, buyer_id, product_id, status(pending/paid/shipped/completed/cancelled), total_price
关系：卖家发布多个商品；一个商品对应一个订单

## 关键流程

### 流程1: 下单购买
- Given: 商品状态为available
- When: 买家点击购买
- Then: 加锁 → 检查商品状态 → 创建订单 → 更新商品状态为sold → 释放锁
- 失败路径: 商品已被购买 → 提示"已售出"

## 非功能性需求
- 一致性：商品不能被两个人同时购买（强一致）
- 预估规模：10万日活，QPS约1000
- 关键架构决策：
  - 存储：PostgreSQL（事务保证）
  - 缓存：商品列表页缓存60秒
  - 并发：商品购买用悲观锁
  - 异步：图片压缩/缩略图生成异步

请先实现MVP功能。

---

Part 4: 完整对话示范

光有 Prompt 模板不够。下面是 3 段完整的用户-AI 对话，示范怎么和 AI “聊”出好代码。

示范 1：从零搭建一个功能（追问式对话）

下面是一段真实的 Vibe Coding 对话过程。注意用户不只是”下指令”，而是在持续判断和追问。

你：帮我给记账系统加一个导出功能，用户可以导出本月的费用记录为 CSV 文件。

AI：好的，我来实现一个 GET /api/expenses/export 接口，返回 CSV 文件...
    [生成了一段代码]

你：等一下。如果用户有 5000 条记录，一次性全查出来会不会有问题？

AI：好问题。5000 条其实还好，但如果数据量更大，可以考虑流式写入。
    目前先用一次性查询，我加一个 LIMIT 10000 的安全上限。

你：CSV 的编码是什么？Excel 打开中文会不会乱码？

AI：默认是 UTF-8，Excel 打开确实可能乱码。我加一个 UTF-8 BOM 头，
    这样 Excel 能正确识别中文。
    [修改了代码，加了 BOM 头]

你：好，还有一个问题——这个接口需要认证吗？

AI：当然需要。这个接口应该走 JWT 中间件，而且只导出当前用户自己的数据，
    不能导出别人的。我用 c.GetUint("user_id") 做过滤。
    [更新了代码]

你：好，跑一下看看。

复盘这段对话：

• 用户没有一次性说完所有需求，而是在 AI 给出方案后逐步追问
• 每次追问都在检查一个可能的问题：性能、编码、权限
• 最终的代码比”一次性 Prompt”生成的更完善

示范 2：修复 Bug（定位式对话）

你：页面上点"删除"按钮没反应，Console 里有个红色错误：
    TypeError: Cannot read properties of undefined (reading 'id')
    at handleDelete (ExpenseList.jsx:45)

AI：从错误信息看，第 45 行的 handleDelete 函数里，
    传入的对象是 undefined。让我看一下你的代码...

    找到了问题。你的 map 里写的是：
    onClick={() => handleDelete(expense)}

    但 handleDelete 期望的参数是 expense.id，不是整个对象。
    应该改成：
    onClick={() => handleDelete(expense.id)}

你：等一下，我看了一下，之前是好的，这次改了什么导致的？

AI：让我对比一下。看起来是你之前重构 handleDelete 函数时，
    把参数从接收整个对象改成了只接收 id，但调用的地方忘了同步修改。

    有两种修法：
    1. 调用处改：onClick={() => handleDelete(expense.id)}
    2. 函数改回来：const handleDelete = (expense) => { ... expense.id }

    建议用方案 1，因为只传 id 更清晰。

你：用方案 1，改完帮我检查一下其他地方有没有同样的问题。

AI：检查完了，其他 3 处调用都是正确的，只有这一处漏改了。已修复。

复盘这段对话：

• 用户提供了完整的错误信息（错误类型 + 文件名 + 行号）
• 不只是让 AI 修，还追问了根因（“之前改了什么导致的”）
• 让 AI 扩大检查范围（“其他地方有没有同样的问题”）

示范 3：技术选型（质疑式对话）

你：记账系统要加一个实时通知功能——管理员审批后，
    用户的页面上立刻弹出通知。怎么实现？

AI：推荐用 WebSocket。后端用 gorilla/websocket 库，
    前端建立 WebSocket 连接，审批时服务端推送消息。

你：10 个人的内部系统，用 WebSocket 是不是太重了？
    有没有更简单的方案？

AI：你说得对，10 个人确实不需要 WebSocket。更简单的方案：
    1. 前端每 30 秒轮询一次 GET /api/notifications
    2. 有新通知就弹出提示

    轮询在小规模下完全够用，实现简单，几行代码就搞定。

你：轮询的话，30 秒会不会太慢？用户等半分钟才看到审批结果？

AI：可以折中：
    - 默认 30 秒轮询
    - 但用户点击"刷新"按钮时立刻查一次
    - 或者在审批相关页面缩短到 5 秒

    这样既不浪费请求，又不让用户等太久。

你：好，就用 5 秒轮询 + 手动刷新的方案。先做后端接口，
    前端我等接口好了再让你做。

AI：好的，我先实现：
    1. notifications 表（user_id, message, read, created_at）
    2. GET /api/notifications?unread=true 接口
    3. PUT /api/notifications/:id/read 标记已读
    4. 审批通过/驳回时自动创建通知记录

复盘这段对话：

• AI 默认推荐了”高级”方案（WebSocket），用户质疑了必要性
• 用户用”10 个人的内部系统”这个约束条件推翻了 AI 的建议
• 最终选了更简单的方案，但通过追问优化了体验
• 用户还控制了工作节奏（“先做后端，前端等一下”）

---

对话技巧总结

技巧	示例	为什么有效
追问性能	”5000 条记录一次性查会不会有问题？“	AI 不会主动考虑边界情况
追问安全	”这个接口需要认证吗？“	AI 经常忘记权限检查
追问根因	”之前改了什么导致的？“	修 bug 不只是修表面
质疑复杂度	”10 个人用 WebSocket 是不是太重了？“	AI 倾向于推荐”高级”方案
扩大检查	”其他地方有没有同样的问题？“	一个 bug 往往不是孤例
控制节奏	”先做后端，前端等一下”	分步验证比一次性生成更稳
提供约束	”不改架构，加索引+缓存解决”	约束越明确，AI 越不会跑偏

---

下一步

• 准备动手做完整项目？ → 项目实战 以酒店预订系统为例，从零走完 10 个阶段
• AI 生成代码后怎么检查？ → 代码审查清单 花 5 分钟过一遍关键检查项
• 5 层框架怎么用？ → 思考框架 详细说明