Phase 2 / Ep 08: 数据库引擎选型辩论

⏱ 预计阅读 3 分钟 更新于 2026/4/13

在 PRD 落地到 docs/ 目录后，下一步就是敲定技术底座和存储选型。这通常也是独立开发者最容易选型失误的环节（“听说最近 Supabase 很火，那我就用 Supabase。哎呀等一下，听说 Prisma 也不错……”）。

在这里，我们要彻底利用起 planning-with-files 赋予 Agent 的外挂脑区机制（特别是 findings.md 这份文档）。

1. 向内追问：抛开偏见的技术栈辩论

在 Agent 界面中发出指令：

“基于刚才的整体 PRD_System_Design.md，我们目前需要建立严谨的跨端同步事务层。请横向对比纯粹的 Prisma + Postgres、Supabase 生态，以及纯 Drizzle ORM，到底哪个最适合我们？请给出推断过程。并在得出结果后，将我们的选型及决策理由，追加写入到 docs/findings.md（作为一个独立的决策断言）中。”

2. 什么是好的“诊断写入”？

聪明的架构师 Agent（因为 GEMINI.md 告诉它要追求极简与降低门槛）会分析出诸如：

  • Supabase 带了自建 Auth 和实时推送非常香，但对于我们只做一个 Google Calendar 单点同步且无多租户需求的单机强需求而言，它稍微重叠了。
  • Prisma 的 DX（开发者体验）更好，非常适合配合 Next.js 的 Server Actions 去执行。

Agent 回复你确认采用 Prisma 之后，它会在后台静默地调用 write_to_file 工具或通过执行 cat >> 类命令（这里系统会有特定的工具指令机制要求遵循规范），向你的 docs/findings.md 注入一条永久记忆：

<!-- docs/findings.md 的片段 -->
### [决策记录] 数据库存储选型 (2026-X-X)
- **选择**: PostgreSQL + Prisma ORM
- **背书理由**: 系统对 Google Calendar 同步强依赖事务性操作（Transaction），Prisma 的互动事务支持使得在回滚本地数据流方面非常安全且有类型推断加持。
- **排斥项**: 放弃自建 Auth，纯使用 Google OAuth Session 实现无密码管理。

3. ADR (Architecture Decision Record) 的威力

这在工程学上叫做 架构决策记录（ADR）。

传统开发中，只有高级正规军才会去维护 ADR。而在这里，不仅你不再需要手工手敲它，而且它是写给将来的“其他 Agent 子进程”看的！

当明天你的测试 Agent 在跑 E2E 报错、质问你为什么不使用 Supabase 用户表体系时，主控 Agent 只需要读一下 findings.md，就可以坚定地说：“因为我们在架构设计之初就放弃了它”，从而防止整个研发走向自我推翻的死循环中。