从零开始VibingCoding第六个项目_拾光盲盒小程序

seeyouagain_

293人浏览 · 2026-09-24 17:16:30

seeyouagain_ · 2026-09-24 17:16:30 发布

从零开始VibingCoding第六个项目：拾光盲盒小程序

用 AI 写代码的第 183 天，我花 3 天完成了一个 27 张表、9 个模块的校园社交小程序

不是我会写代码了，是我学会了让 AI 按我的规矩写代码。

体验地址：拾光盲合体验地址
体验说明：使用手机号登录会自动获取验证码，不会发送真实短信验证码全是虚拟数据

📌 一、什么是 Vibing Coding？

先说结论：Vibing Coding 不是让 AI 自由发挥，是你定规矩，AI 执行。

很多人对 AI 编程有误解——觉得就是打开 ChatGPT，说一句"帮我写个小程序"，然后坐等成品。如果你试过一次就知道，这样生成的代码 90% 跑不起来，剩下的 10% 能跑但完全不是你要的。

我做 Vibing Coding 到现在第六个项目，总结出一句话：

氛围编程 = 你写"宪法"（CLAUDE.md）+ 你审"计划书"（plan）+ AI 批量"施工"（execute）+ AI 交叉"质检"（review）

在这个项目里，"我"的角色是产品经理 + 架构师 + 最终验收人，AI 的角色是程序员 + 测试 + 代码审查员。

下面我用「拾光盲盒」这个项目的真实经历，讲讲这个氛围到底是怎么"营"出来的。

📐 二、项目背景：第六个挑战

这次要做的东西不简单——一个完整的校园社交小程序，对标市面上真实上线的产品：

模块	功能
纸条箱	匿名放纸条、随机抽取、回信、收藏、精选专区
心动圈	图文动态、点赞评论、收藏转发、话题体系
缘分匹配	问卷问答、契合度计算、匿名互动
校园树洞	匿名发帖、评论、敏感词过滤
签到任务	每日签到、连续奖励、日常任务
余额商城	装扮道具、虚拟币经济体系
消息中心	6 类消息通知、已读管理
举报风控	工单处理、用户封禁
管理后台	数据统计看板 + 全模块 CRUD

数据规模：27 张业务表、70 个后端 Controller、39 个小程序页面、73 个管理后台视图。

按照纯手写代码的估算，这至少需要一个 3 人小团队干 1-2 个月。而实际的提交记录是这样的：

2026-07-15：6  个提交（基础设施搭建）
2026-07-16：21 个提交（后端全部模块 + 管理后台）
2026-07-17：16 个提交（小程序端全量 + 修复）

3 天，44 个提交，266 个文件，33055 行新增代码。

这不是我写代码的速度，是 AI 在正确引导下的产出速度。

📜 三、CLAUDE.md：给 AI 立的"宪法"

Vibing Coding 的第一步，不是打开 AI 就说"帮我写代码"，而是先花 1-2 小时写一份 CLAUDE.md。

这份文件是整个项目的"宪法"，它告诉 AI：

项目的目录结构是什么
每个目录的代码必须遵守什么规则
哪些事情绝对禁止做
接口命名规范、返回格式、权限模型
UI 组件库是哪个、用什么风格

这份文件有多重要？ 它决定了 AI 产出的代码质量下限。没有它的 AI 就像一个没有入职培训的新员工——能干活，但活干得五花八门。

3.1 我的 CLAUDE.md 长什么样

# 拾光盲盒 全局强制约束

## 1. 项目基础信息 & 技术栈
- admin-backend: SpringBoot3 + JDK17 + MyBatis + JWT
- admin-front: Vue2 + Element UI + 原生 JS（非 TS）
- timebox-uniapp: UniApp Vue2 + Vuex + tuniao-ui（tn-* 组件）

## 2. 目录开发强制规则
1. admin-backend：仅输出后端代码，适配 jakarta.* 包，禁用 javax.*
2. admin-front：仅输出管理端代码，不混入小程序逻辑
3. timebox-uniapp：
   - 业务功能遵循 doc 需求文档
   - UI 组件必须复用现有组件，禁止从零自定义

## 3. Superpower 标准执行流程（固定顺序）
1. /superpowers:brainstorm → 拆解模块，输出文件路径清单
2. /superpowers:write-plan → 分阶段开发计划
3. /superpowers:execute-plan → 批量生成可运行代码
4. /superpowers:code-review → 四重校验

## 4. 编码硬性规范
- 全部使用 jakarta.* 包
- 分页、异常、统一返回体复用框架内置工具
- 扣费、次数校验、敏感词过滤等逻辑必须完整实现
- app 端接口路径 /api/app/*，管理端 /api/*

## 5. 禁止行为
- 跨目录生成代码（后端逻辑写到小程序）
- 省略余额校验、权限校验
- 脱离需求文档新增字段

3.2 为什么是"强制约束"而不是"建议"？

因为 AI 有一个致命问题——它会"偷懒"。

比如让它做敏感词过滤，它可能会说"这里先跳过，后续补充"。如果你写的文档里说的是"建议做"，它就真的跳了。

所以我用的是强制语气：“必须”、“禁止”、“不得”。这不是修辞——对于 AI 来说，这些词就是编译器的语法规则。

🗺 四、开发计划：AI 产出的 44 步施工图

有了宪法之后，下一步是让 AI 出一个可执行的开发计划。

我没有直接开始写代码，而是先让 AI 根据需求文档生成了一份详细的 plan。这份 plan 不是给人看的甘特图——它是给 AI 自己执行的任务清单：

Phase 0: 数据库建表（27 张表 DDL）
Phase 1: 基础设施（异常处理、全局配置、敏感词）
Phase 2: 认证模块（微信登录、JWT 签发）
Phase 3: 业务模块 7 个（纸条、动态、匹配、树洞、签到、商城、举报、消息、用户）
Phase 4: 管理后台前端（9 个模块 CRUD 页面）
Phase 5: 小程序端（请求封装 + API + 39 个页面）

每个 Phase 下面又有具体的 Task，比如 Phase 3 的纸条模块：

Task 7: 纸条模块
  - [ ] 7.1 Entity: Paper, PaperTag, PaperReply, PaperDrawLog
  - [ ] 7.2 Mapper + XML: CRUD + 随机抽取 + 回信计数
  - [ ] 7.3 Service: 发布(敏感词)、抽取(免费→扣费)、回信(上限+扣费)、收藏
  - [ ] 7.4 Controller: /api/app/paper/* (JWT, 小程序端)
  - [ ] 7.5 Admin Controller: /api/paper/* (权限校验, 管理端)

这份计划的作用是什么？

它把一个巨大的项目拆解成了 AI 可以逐个攻克的小任务。每个 Task 的粒度刚好是 AI 一次能处理的上下文量——太大了会丢信息，太小了又浪费时间。

⚙️ 五、执行阶段：AI 是怎么"搬砖"的

计划确认后，进入执行阶段。这才是 Vibing Coding 的"高光时刻"。

5.1 批量生成：一个 Task = 一次 AI 调用

我用的工具是 Claude Code + Superpowers 插件。执行流程是：

我输入 /superpowers:execute-plan Task 7
AI 读取 plan 中 Task 7 的具体要求
AI 读取 CLAUDE.md 中的约束规则
AI 一次性生成：4 个 Entity、4 个 Mapper 接口、4 个 Mapper XML、1 个 Service 接口、1 个 ServiceImpl、2 个 Controller
AI 自动运行 mvn compile 检查编译
AI 自动 git commit 提交代码

整个过程我只需要确认，不需要写一行代码。

5.2 实际产出：一次 Task 的提交记录

以 Task 7（纸条模块）为例，一次执行产生了这个提交：

feat(paper): add paper module (entities/mapper/service/controllers)
  with publish/draw/reply/collect + shared UserInfo/UserMsg

 - Entities: Paper, PaperTag, PaperReply, UserCollect, UserMsg
 - Mappers + XML: standard CRUD + draw query (ORDER BY RAND())
 - PaperServiceImpl: publish (sensitive-word + max_reply_count),
   draw (free-draw-first then balance charge, visible-scope random),
   reply (cap + charge + user_msg notify), collect (idempotent toggle)
 - Controllers: PaperController, PaperTagController,
   PaperReplyController, PaperCollectController

 6 files changed, 1060 insertions(+)

1060 行代码，一个提交。 这还不是个位数的提交——整个项目 44 个提交里，平均每个提交新增 750 行代码。

5.3 代码质量：AI 写的能直接用吗？

说实话，第一版不能。但这就是 Vibing Coding 的精髓——AI 生成只是 60 分，后续的 review 和迭代才是 80 分的关键。

我遇到的典型问题：

问题 1：接口返回格式不统一

AI 有时候会自创返回格式，而不是用框架的 AjaxResult。

修复方式：在 CLAUDE.md 里加一条更明确的规则，然后告诉 AI “全局搜索所有 Controller，统一返回 AjaxResult”。

问题 2：小程序端鉴权方式写错

AI 沿用了旧项目的 header.token 鉴权方式，但新后端要求 Authorization: Bearer。

修复方式：这个问题被记录到了 AI 的持久记忆里（.claude/projects/.../memory/），后续所有 API 调用都自动修正了。

问题 3：Mapper XML 引用了不存在的字段

AI 有时候会"幻觉"出数据库里没有的字段。

修复方式：让 AI 执行 mvn compile，编译报错后 AI 会自己读错误信息并修复。

🔍 六、Code Review：AI 给自己找 Bug

Superpowers 插件有一个非常强大的功能——在每个 Task 执行完后，自动运行 review-package 脚本。

这个脚本做的事情是：

读取当前提交的 diff
对照 CLAUDE.md 的规则逐条检查
对照需求文档检查业务逻辑完整性
输出一份"审计报告"，列出所有不合规的地方

实际的 review 结果（节选）：

[FAIL] Report 模块：用户举报接口缺少登录态校验
  → 修复：添加 @PreAuthorize 注解

[FAIL] Treehole 模块：详情接口未返回 isMine 字段
  → 前端需要此字段判断是否显示"关闭评论"按钮
  → 修复：DTO 增加 isMine 字段，Service 层判断当前用户

[FAIL] Message 模块：消息类型枚举值与需求文档不一致
  → 文档定义 6 种类型，代码只实现了 4 种
  → 修复：补充 AT_REMIND 和 MATCH_SUCCESS 类型处理

然后 AI 自动修复这些问题，生成新的 fix 提交。

这就是为什么你在 git log 里看到很多 fix: 开头的提交——它们不是我发现问题后手动改的，是 AI 自己 review → 自己发现 → 自己修复的。

🧠 七、AI 的"记忆系统"：跨会话的知识积累

Vibing Coding 有一个很多人忽略的要点：AI 的上下文窗口是有限的。

当你执行到第 20 个 Task 时，AI 已经忘了第 1 个 Task 的细节。这就是为什么需要持久记忆系统。

在这个项目里，AI 自动维护了一个记忆文件：

---
name: uniapp-cross-tier-contract
description: 小程序端与后端通信规范
---

## 关键发现

1. 鉴权方式：新后端用 Authorization: Bearer，旧项目用 header.token
2. 状态管理：用 Vuex（不是 Pinia）
3. UI 组件库：tuniao-ui（tn-*），通过 easycom 自动注册
4. 请求封装：旧项目用全局 mixin $request，新模块需新建 utils/request.js
5. 分页组件：mescroll-uni，使用 upCallback/downCallback 模式

这份记忆是 AI 在开发过程中自己发现、自己记录的。当后续 Task 涉及到小程序端开发时，AI 会自动读取这份记忆，避免重复犯错。

这就是为什么后面的 Task 比前面的 Task 质量高——AI 在"成长"。

🐛 八、踩坑记录：那些 AI 搞砸的瞬间

Vibing Coding 不是银弹。下面这些坑，每一个都是真实发生的。

8.1 图片上传成功但 UI 显示失败

现象：调用 /common/upload 返回 200，但小程序端显示"上传失败"。

排查过程：

我先让 AI 检查后端日志 → 后端正常返回
让 AI 检查小程序端 request.js → 发现 uploadFile 函数期望 {data: {url, fileId}} 格式
但 /common/upload 实际返回 {url, fileName, ...} 没有 data 包裹层

根因：API 返回格式不统一。

AI 的修复：在 uploadFile 里加了一层格式兼容逻辑：

const payload = d.data && typeof d.data === 'object' ? d.data : d
resolve(payload)

教训：在 CLAUDE.md 里加一条规则——“所有接口返回格式必须在 plan 中明确定义，AI 不得自行假设格式”。

8.2 静态资源 404

现象：No static resource upload/2026/09/08/profile_xxx.jpeg

排查过程：

让 AI 检查 ResourcesConfig → 映射配置是 /profile/** → profile/upload/
让 AI 检查 getPathFileName() → 返回路径是 /profile/upload/...
路径重复了！

AI 的修复：修改资源映射根目录。

教训：Spring 的路径映射规则需要在 CLAUDE.md 里写清楚，否则 AI 会按"默认理解"配置。

8.3 `trim is not a function`

现象：小程序端计算属性报错。

排查过程：

后端通过 @JsonProperty("images") 把 imagesList 序列化为 images 字段
前端收到的是数组，但代码按字符串处理（imgs.split(',')）

AI 的修复：添加类型判断：

if (Array.isArray(imgs)) return imgs.filter(Boolean)
if (typeof imgs === 'string') return imgs.split(',')...

教训：前后端字段类型必须在 plan 中明确标注，不能让 AI 猜。

8.4 图片尺寸反复调整

这个比较搞笑——AI 生成的九宫格图片尺寸，我前后改了 4 次：

第 1 轮：1 张图 249px × 249px → "太大了"
第 2 轮：1 张图 300rpx × 300rpx → "还是太大了"
第 3 轮：1 张图 60% × 240rpx → "宽度太宽"
第 4 轮：1 张图 60% × 240rpx，2/4 张 200rpx，3+ 张正方形 → "OK"

教训：UI 尺寸这种主观判断，最好在 CLAUDE.md 里直接写死数值，不要让 AI “自由发挥”。

📊 九、数据说话：Vibing Coding 的效率提升

9.1 开发速度

指标	传统开发	Vibing Coding
项目总工时	约 240 人时（3人×4周）	约 30 人时（1人×3天 AI 辅助）
代码产出	约 33,000 行	约 33,000 行
平均每日产出	约 1,400 行	约 11,000 行
Bug 密度（首轮）	中等	较高（但 review 后快速收敛）
Bug 密度（终轮）	低	接近传统开发

9.2 提交统计

总提交数：44
feat 提交：24 个（新功能，占 55%）
fix 提交：19 个（修复问题，占 43%）
chore 提交：1 个（初始化）

按天分布：
  7月15日：6  个（基础设施）
  7月16日：21 个（后端 + 管理后台全量）
  7月17日：16 个（小程序端 + 修复）
  9月7日： 1  个（后续 bug 修复）

关键观察：fix 提交集中在 7 月 16-17 日，说明 AI 在批量生成后进行了集中的 review 修复。

9.3 代码分布

后端代码：
  - 20 个 Mapper XML
  - 40+ 个 Service 接口 + 实现
  - 70 个 Controller（管理端 + 小程序端）
  - 27 张表 DDL

小程序端：
  - 13 个 API 模块文件
  - 39 个 Vue 页面
  - 12 个业务组件（ImageGrid、PaperNoteCard、TnDrawBox...）

管理后台：
  - 13 个 API 文件
  - 73 个 Vue 视图
  - 9 个模块的 CRUD 页面

🎯 十、Vibing Coding 的方法论总结

做了六个项目之后，我总结出了一套可复制的 Vibing Coding 流程：

10.1 五步法

┌─────────────────────────────────────────────────────────────┐
│                    Vibing Coding 五步法                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ① 写宪法（CLAUDE.md）                                       │
│     └─ 告诉 AI 什么能做、什么不能做、必须怎么做               │
│                          │                                  │
│                          ▼                                  │
│  ② 出计划（plan.md）                                        │
│     └─ 让 AI 把大项目拆成它能处理的小任务                     │
│                          │                                  │
│                          ▼                                  │
│  ③ 审计划（人工确认）                                        │
│     └─ 你检查 plan 是否合理，调整优先级和依赖关系             │
│                          │                                  │
│                          ▼                                  │
│  ④ 批量执行（execute-plan）                                  │
│     └─ AI 按 Task 逐个生成代码 + 编译 + 提交                 │
│                          │                                  │
│                          ▼                                  │
│  ⑤ 迭代修复（review → fix → re-review）                     │
│     └─ AI 自审 + 你验收 + 发现新问题 → 回到 ① 更新宪法       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

10.2 核心原则

原则	说明
宪法先行	没有 CLAUDE.md 不开工，磨刀不误砍柴工
计划驱动	不让 AI 自由发挥，每个 Task 都有明确输入输出
批量执行	一次处理一个模块，不要东一个西一个
自动 Review	每次提交后自动跑 review，发现问题立即修复
记忆沉淀	跨会话的知识要持久化，避免重复犯错
人工验收	AI 生成的代码必须人工跑一遍，不能盲信

10.3 适用场景

Vibing Coding 不是万能的，它在以下场景效果最好：

✅ CRUD 密集型项目（管理后台、CMS、ERP）
✅ 架构规范明确的项目（基于 RuoYi、Spring Boot 等成熟框架）
✅ 需求文档完善的项目（有明确的表和接口定义）
❌ 强算法型项目（AI 写算法容易出错，需要人工把控）
❌ 强 UI/UX 项目（AI 的审美一言难尽，需要设计师介入）
❌ 探索型项目（需求不明确时，AI 无法替你做决策）

🔧 十一、工具链：我的 Vibing Coding 装备

工具	用途
Claude Code	主力 AI 编程工具（终端内运行，直接操作文件）
Superpowers 插件	提供 brainstorm → plan → execute → review 工作流
CLAUDE.md	项目宪法，约束 AI 行为
Git	每次 AI 提交都有完整记录，可随时回滚
Maven	后端编译检查，AI 自动运行
微信开发者工具	小程序端实时预览