不是"AI 辅助开发"，是 AI 写完了我负责测试、提意见、然后 AI 自己改 bug。这就是 vibe coding。
一句话背景
一直想通过Vibe Coding创造一点有意思又有用的东西，原本是想做一个基于web的抽卡小游戏，但纯抽卡太没意思了，所以想到通过番茄钟专注时长获取原石来抽卡。于是某个周六晚上，我打开 Hermes Agent，开始了这段"多动嘴少动手"的开发之旅。
第一阶段：概念迭代（就是聊天）
我打开 Hermes，把需求扔过去：做一个网页抽卡游戏，用户是学生，作用是激励学习。Hermes 给了三个方案：
- 研途抽卡 · 名校召唤 —— 纯 gacha，SSR 是录取通知书
- 知识大陆 · RPG 冒险 —— 高数王国、英语帝国，抽角色打 Boss
- 星光研路 · 星座收集 —— 唯美治愈风，每天完成专注亮一颗星
我选了方案一，但改了卡池："SSR 是双一流大学的校徽，其他等级不要跟学习太相关"。于是 SSR 变成了 39 所 985 的校徽/建筑，SR 是城市风景，R 是猫狗，N 是美食。
整个过程就是打字聊天，不到十分钟方向就定了。这大概是 vibe coding 最舒服的地方——你不写代码，你只需要做决策。
第二阶段：从零搭建就是一句话的事
"好了，开始写代码吧"。
Hermes 一股脑输出了 server.py、db.py、cards_data.py、static/ 下的三件套、还有 Dockerfile 和 docker-compose.yml。大概 30 秒后，一个完整的抽卡应用就躺在我目录里了。
技术栈选得也合我意：FastAPI + SQLite（后端的"Hello World"组合），前端原生三件套零依赖。我问为什么不用 React，Hermes 说"单用户、单页面、不需要状态管理，原生就够了"。AI 做架构决策时意外地务实——它不会因为某个技术热度高就硬上。
第三阶段：卡片生成 —— Codex 批量绘制
105 张卡片需要配图，39 张 SSR 还各有各的标志性建筑。我自己画是不可能的，但 AI 绘画我又不想一张张调参数。
我的做法：写了一个 260KB 的 prompts.md，把 39 所高校的建筑描述、风格参数、构图要求全部写进去，然后一股脑扔给 Codex CLI，让它批量生成。
结果出乎意料地好——同一批 prompt 模板、同一套风格参数，39 张 SSR 的风格一致性非常高。清华的二校门、北大的西门、复旦的光华楼……每张都能认出是哪所学校，但又有统一的插画风格。SR 的城市风景、R 的猫狗、N 的美食，也是分三批批量生成的。
这是整个项目中我认为最有价值的一个经验：批量 prompt + 统一的风格参数 = 设计一致性。不用三张图换三个 AI 工具。
第四阶段：迭代 —— 这就是 vibe coding 最真实的样子
代码跑起来之后，真正的"开发"才开始。以下是我们迭代过程中几个典型案例：
"升星系统"—— 一句话描述，AI 搞定
"加一个星级机制。卡片默认一星。三张同名升一星。满五星分解返还书页。十连不要弹窗直接展示十张小卡。"
Hermes 改了三个文件：db.py 加 star 和 dup_counter 列、server.py 改抽卡逻辑、app.js 重写十连显示。我跑了一下，有 bug（分解返还逻辑不对，把普通重复也当成分解了），回了一句"只有满星分解才返还"，它自己改了。
全程我没写过一行 SQL ALTER TABLE。
"成就系统踩的坑"——AI 写的死代码
成就系统有 18 个成就。跑起来之后发现"单抽 SSR"和"双黄蛋"都不触发。我说"检查所有成就逻辑"。
Hermes 查了一圈，找到了两个 bug：
- 十连的成就检查写在
return后面 —— Python 里这行代码永远不会执行。AI 自己写的，AI 自己找出来的。 - 保底判断用
total_pulls % 80而不是真正的 pity 计数器 —— 如果中途抽到过 SSR 导致保底复位，total_pulls就不再等于实际保底计数。这是逻辑错误，不是语法错误。
最有意思的是：我通过"它写了我帮忙 debug"这个循环，获得了比亲手写代码更深的代码理解——因为你需要跟 AI 精确描述"哪里不对"，这个描述过程本身就是代码审查训练。
"从凌晨到 UTC"—— Docker 时区炸了
部署到服务器后，朋友反馈凌晨学习早鸟没触发。我看数据库记录：started_at 是 UTC 的 Z 结尾，completed_at 是无时区的本地时间，同一个 session 的两个时间戳竟然不在同一时区。
根因：Docker 默认 UTC。前端发 UTC、服务端存本地、但判断早鸟用的 datetime.now() 在容器里也是 UTC。凌晨 = 下午。解决方案是给 docker-compose.yml 加 TZ=Asia/Shanghai、Dockerfile 加 tzdata、然后把所有时间戳统一到本地时区。
没有 AI 的话我可能要死磕半天。有 AI 的话大概十轮对话修好了——但十轮对话主要花在"描述问题"上，代码改动只有三行。
vibe coding 的真实体验
我用 Hermes Agent 开发这个项目大概花了一个周末——说"一个周末"可能不太准确，因为真正花在打字上的时间加起来不到两小时。大部分时间在想需求、测试、提 bug。
几个真实的感受：
优点
- 架构决策比人务实。 AI 不会因为"微服务很火"就拆服务，不会因为"React 是主流"就上框架。它的每一个技术选择都是"能跑就行"级别的极简主义。
- 重构是真·零成本。 "把昨天写的那个函数拆成三个"——一句话，三秒钟。没有心理负担，没有"又要改一堆引用"的痛苦。
- bug 修复比你想象的快。 前提是你能精确描述 bug。描述能力决定了 AI 写代码的上限。"抽卡返回卡面不对"和"
cardImage()里用了card.image_url但它指向.png后缀但你放的是.jpg"——效果完全不同。
痛点
- 上下文丢失。 聊了 50 轮后 AI"忘记"了之前说过什么。有一次它把十连抽的成就检查写到了
return后面，其实就是忘了之前在别的函数里怎么写的。 - 你要能 review 代码。 vibe coding 不是不思考。你不需要写代码，但你必须能读出"这行逻辑不对"。role 从"coder"变成了"QA + PM"。
- Docker 那一套，AI 踩坑跟人一样多。 pip 回溯解析爆炸、aarch64 的 .so 拷到 x86 崩掉、镜像网速、缓存失效……这些问题 AI 给的方案和 ChatGPT/Google 搜出来的差不多，最终还是要靠你试。
技术细节速览
| 层级 | 选择 | 原因 |
|---|---|---|
| 后端 | FastAPI + SQLite | 单用户不需要并发，ORM 是多余的 |
| 前端 | 原生 HTML/CSS/JS | 零构建、零依赖、刷新即生效 |
| 部署 | Docker Compose | 单容器，volume 持久化，config 挂载 |
| 配置 | config.yaml |
所有数值参数集中管理，重启生效 |
| 抽卡动画 | CSS 3D Transform | 无 JS 动画库，纯 CSS 翻转 + SSR 粒子 |
核心设计原则：单用户、零构建、全透明。 概率写在 config 里，保底计数器显示在界面上，SQLite 数据库可以随时 sqlite3 打开看。这本质上是一个反商业化的设计——商业抽卡游戏把概率藏在服务端、把消耗算得滴水不漏，而 PuppyFocus 反过来：概率你想调就调，书页你想改就改。
部署
git clone https://gitee.com/xyxu421/puppy-focus.git
cd puppy-focus
uv venv && uv pip install fastapi uvicorn pyyaml aiosqlite
docker compose up -d --build
卡面图放 assets/cards/，支持 jpg/png。挂上去就行，不用重建镜像。
项目开源在 Gitee。
如果哪天你打开这个项目，想当奸商，调到 ssr_probability: 0.001，然后设了个 1000 抽保底——我不会问为什么。config.yaml 在那，这是你的自由。