Phase 2 / Ep 09: 数据模型 Schema 设计自动化

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

既然我们在上一步敲定了采用 Prisma + PostgreSQL，那剩下的苦力活：去把 User、TimeBlockTask、CalendarEvent 及其关联写入 schema.prisma 这类事，就不应该由人类来敲键盘了。

但在让 Agent 动手干这件危险的事之前，我们必须给它建立一套名为流水线的工作流，以防止它把数据库干崩。

1. 建立业务流：database-migration.md

在我们的魔法地带 .agents/workflows/ 下新建一个文件 database-migration.md：

description: 数据库 Schema 变更与同步规范流程
当你收到修改、建立数据库实体的指令时，请分步骤执行：
// turbo-all

1. 查阅 `docs/PRD_System_Design.md` 以及 `docs/findings.md` 确保字段命名契合业务语境（不要乱造缩写）。
2. 在 `prisma/schema.prisma` （不存在则创建）中增加或修改对应的 Model 定义。所有的表名使用全小驼峰映射。
3. 任何与第三方关联的（特别是 Google 事件）表，必须预留 `providerId` 和 `providerSyncToken` 字段以解决上游双向游标问题！
4. 完成文件修改后，使用 `npx prisma format` 和 `npx prisma validate` 确认无误。

2. 自动化指挥下的实体生成

有了上述护栏后。此时你只需说一句极冷淡的话：

“运行 Database Migration 工作流，为我们的 T-Block 创建所需的本地业务表。”

Agent 会自动开始它的工作：

  1. 它触发了 Using-Superpowers -> 检测到了有特定的 workflow -> 强制阅读该流。
  2. 它提取了之前的 PRD，发现用户需要拖拽的时间块（需要顺序 order 字段），需要连接日历（需要 googleEventId 字段）。
  3. 它修改了 schema.prisma 并为你加上了详尽的注释。
  4. 它自己在底层终端跑了 validation，发现没报错，然后再来反馈向你汇报：“设计完毕。”

你看，它甚至主动预测并防御了数据库关联错误。 因为我们把前人的工程经验写在了 workflow 这一层护甲上，每一次的执行，都是无脑地踩在最佳实践的肩膀上前进！