被 drizzle 按头安利了😭 写数据库 Schema 原来可以这么顺，真的后悔没早用-Skill优仓

核心功能

如果你写过数据库 Schema，一定懂那种痛苦：表名乱、字段随心所欲、迁移文件越堆越多，最后谁都不敢改。drizzle 这个 Agent，干的就是把这些混乱一把掰正的活，而且方式相当温柔。

它围绕 Drizzle ORM，直接从 Schema 定义、迁移生成、类型推导一路管到你日常写业务代码。你只要按约定写表结构，剩下的事情它都能帮你兜住，包括：

统一的 Schema 目录结构，表、迁移、配置一眼就懂
严格的命名规范，表名、字段名全部可预期
内置时间戳 helpers，created_at / updated_at 不再手写
天然支持 PostgreSQL 且开启 strict 模式，错误更早暴露
Schema 即类型，插入和查询类型自动推导

最爽的是，它并不是“限制你”，而是帮你把坑提前填好，写的时候完全不别扭。

实操代码示例

drizzle 的好感，基本都是从第一次写表开始的。比如一个 agents 表：

export const agents = pgTable(
  'agents',
  {
    id: text('id')
      .primaryKey()
      .$defaultFn(() => idGenerator('agents'))
      .notNull(),
    slug: varchar('slug', { length: 100 })
      .$defaultFn(() => randomSlug(4))
      .unique(),
    userId: text('user_id')
      .references(() => users.id, { onDelete: 'cascade' })
      .notNull(),
    chatConfig: jsonb('chat_config'),
    ...timestamps,
  },
  (t) => [uniqueIndex('client_id_user_id_unique').on(t.clientId, t.userId)],
);

没有魔法，没有黑盒，所有约束都写在代码里。配合类型推导：

export type NewAgent = typeof agents.$inferInsert;
export type AgentItem = typeof agents.$inferSelect;

前端、后端、接口层，直接用同一套类型，错一次都嫌多。

优势分析

同类 ORM 或 Schema 工具不少，但 drizzle 真正拉开差距的点在细节。

强约定但不僵硬：snake_case、复数表名不是建议，是默认正确姿势
迁移更安全：强调幂等 SQL，线上跑迁移不再心跳加速
时间戳体系完整：createdAt、updatedAt、accessedAt 一套走天下
ID 设计清晰：前缀区分实体类型，排错和排查日志都更友好
TypeScript 体验拉满：不是“能用”，是真的顺

这种工具，一旦团队里有人开始用，其他人基本都会被拖着一起真香。

应用场景

drizzle 特别适合以下这些场景：

中大型项目，需要长期维护数据库结构
多人协作，Schema 经常被不同人修改
对数据安全和迁移稳定性要求高的业务
前后端同仓，强依赖类型一致性的项目
Agent / AI 产品，需要快速扩展数据模型

尤其是 Agent 类产品，表关系复杂、关联多，靠 drizzle 把 Schema 管住，后面加功能才敢放开手脚。

最佳实践

想把 drizzle 用顺，有几个小经验很值：

Schema 永远只放在 src/database/schemas，别到处散
迁移文件名一定写清楚含义，方便回滚和审计
所有 ALTER / CREATE 都写成 IF NOT EXISTS
多对多表优先用联合主键，避免“幽灵数据”
内部表可以直接用 uuid，业务表再上自定义前缀 ID

当这些习惯固定下来，数据库不再是“不敢动的黑盒”，而是可以放心演进的基础设施。

如果你已经在项目里用到了 drizzle 这种 Schema 规范化能力，接下来一个现实问题就是：怎么系统性地管理、复用这些 Agent 能力？这时候，把 drizzle 这样的实战型 Skills 收进 Skill优仓，统一管理、随用随取，会比零散复制靠谱得多。尤其是当团队规模起来之后，这种集中式的 Skill 仓库，真的能少踩很多坑。