专项代码生成全家桶

这个 pack 包含什么

LLM 编辑器做一次性补全很强，但当同一种翻译你要做一千次（每个 PR、每次 API 变更、每个新迁移），它不是合适的工具。这时候你要的是有 spec 输入的确定性生成器。这个 pack 就是一线开发者的精选生成器集合，再加两个 AI 助手处理那些边角模糊的事（项目脚手架、自然语言转正则）。

整套覆盖七种细分翻译任务：

• 项目脚手架：基于模板（Cookiecutter）或者基于 prompt（Meta Agentic Project Scaffold）
• OpenAPI spec → 客户端 SDK 和服务端 stub（OpenAPI Generator）
• SQL 查询 → 类型安全代码（sqlc）
• GraphQL schema → 强类型 resolver 和服务端（gqlgen）
• JSON Schema → TypeScript 静态类型（TypeBox）
• TypeScript 优先的校验，顺便当类型（Zod）
• Schema-first 自然语言 → 结构化代码（TypeChat）
• 从自然语言示例生成正则（grex）
• 新 DSL 或语法的解析器生成器（Tree-sitter）

这十个都不和你的 coding agent 竞争。它们坐在 agent 下面。Agent 写 spec，这些工具把 spec 翻译成你手写时本来就该写的代码 —— 但不会有 typo。

推荐安装顺序

1. Cookiecutter — 从项目骨架开始。挑个模板，回答五个问题，得到一个填好的仓库。门槛最低，定下了后续所有工具的目录结构。
2. Meta Agentic Project Scaffold — 没有合适模板的时候，让 AI agent 带你一步步搭一个。Claude Code agent 会问对的问题、写目录树、初始化配置。配 Cookiecutter 用：让 agent 写第一遍，再把结果沉淀成可复用模板。
3. OpenAPI Generator — 装一次，生成 60+ 语言的客户端 SDK 和 40+ 的服务端 stub。CI 里锁版本。openapi.yaml 一发布，所有消费方（你的 APP、合作方、内部服务）都拿到可重新生成的 client。
4. sqlc — 在 .sql 文件里写普通 SQL 查询，sqlc generate 输出包装它们的类型安全 Go（或 Kotlin、Python）函数。你不用再手动把 SELECT 行转成 struct。改列名时编译器比测试更早抓住。
5. gqlgen — Schema-first 的 Go GraphQL。写 schema.graphql，跑 codegen，得到强类型的 resolver 接口。你实现业务逻辑，胶水代码由生成器写。在 API 层和 sqlc 对称。
6. TypeBox — 一份 source of truth 同时输出 JSON Schema 和 TypeScript 静态类型。定义一次 schema，得到运行时校验 + .d.ts 类型。Fastify 和 Ajv 直接接。
7. Zod — TypeScript-first 的 schema 校验。和 TypeBox 思路一样，但 schema 就是 TypeScript 表达式本身。要同时输出原生 JSON Schema 给 OpenAPI 用，选 TypeBox；纯 TS 里活的话，选 Zod。
8. TypeChat — Microsoft 开源的库，让 LLM 输出符合 schema 的结构化数据。把响应形状定义为 TypeScript 类型，TypeChat 把模型逼到合规。AI 生成代码 → 强类型运行时的桥梁。
9. grex — 贴几个示例，得到正则。归纳法能抓住你手写正则会漏掉的边界。比问 LLM 快，确定性，零 token 消耗。
10. Tree-sitter — 增量解析器生成器。哪天你决定自家配置文件或 DSL 要 first-class IDE 支持，就是这个工具。Neovim、GitHub semantic search、绝大多数现代编辑器的语法智能都靠它。

它们怎么协同

Cookiecutter / Meta Agentic Scaffold
   │
   └── 起一个布局一致的新仓库
        │
        ├── openapi.yaml ──── OpenAPI Generator ───► clients/, server-stubs/
        │
        ├── queries.sql ───── sqlc ─────────────────► db/typed-queries.go
        │
        ├── schema.graphql ── gqlgen ──────────────► resolvers.go (强类型)
        │
        ├── *.schema.json ─── TypeBox ─────────────► types.d.ts + 校验器
        │                          │
        │                          └── 喂给 OpenAPI Generator 和 Ajv
        │
        ├── Zod (纯 TS)    ───────────────────────► z.infer<typeof X>
        │
        └── TypeChat ───────────────────────────────► LLM 输出 → 强类型运行时

独立的长尾工具：
   grex（示例 → 正则）
   Tree-sitter（语法 → 增量解析器）

主干是 脚手架 → spec → 生成。每个 spec 文件都对应一个 CI 步骤：重新生成、diff、如果生成的代码漂离 commit 就 fail build。这个纪律是 codegen 在团队层面规模化的关键。

你会遇到的取舍

• TypeBox vs Zod — TypeBox 顺便输出原生 JSON Schema，能直接接 OpenAPI Generator 和 Ajv 无需翻译。Zod 的 TypeScript 工效更顺手，生态更大（tRPC、Hono、Next.js）。多数项目选一个为主；有些团队 API 边界用 TypeBox、应用内部用 Zod。
• sqlc vs Prisma/Drizzle — sqlc 从 SQL 出发生成代码，Prisma 和 Drizzle 从 TypeScript schema 出发生成 SQL。DB 是 source of truth、DBA 写查询的团队选 sqlc。应用层拥有 schema 的团队选 Prisma/Drizzle。它们不是本 pack 的直接竞争对手 —— 本 pack 服务的是 SQL-first 团队。
• gqlgen vs code-first GraphQL — gqlgen 是 schema-first：.graphql 文件主导，代码跟随。TS 里 Apollo Server 可以 code-first。Schema-first 在跨语言场景下扩展性更好（前端读同一份文件）。
• OpenAPI Generator vs 手写 client — 生成的 client 可能比手写难看。胜负不在美观，在「spec 一改就重新生成」的循环。Spec 不变就手写，每 sprint 都变就生成。
• TypeChat vs 原生 function-calling — provider 的 function-calling API 在朝同一个方向收敛。TypeChat 是「库不是 API」，能跑在任意模型上，自带 retry 和 repair 循环。在意可移植性、或想白拿 retry 逻辑就选它。

常见踩坑

• 不 commit 生成代码 — 争论了很多年。务实做法：commit。Reviewer 能看 diff，CI 能验证「重新生成是干净的」，新人 day 1 不需要装工具链。只有当工具链全员都有、并且 CI 强制时才用 generate-on-build。
• spec 和代码漂移 — 每个生成器都需要一个 CI 步：跑生成、diff 失败就 fail。没有这一步，spec 和代码会悄悄不同步。
• 不锁生成器版本 — OpenAPI Generator 和 sqlc 偶尔在小版本之间换输出。CI 里锁版本，否则你会看到大量和改动无关的噪声 diff。
• Tree-sitter 语法调试 — 你写的第一个语法肯定有歧义。从 day 1 就用 tree-sitter test 语料库，不要肉眼读 parse tree 调试。
• TypeChat 的 retry 吃掉真 bug — TypeChat 在 LLM 返回畸形输出时重试。如果你的 schema 本身错了，它会永远重试。打日志 + 设最大尝试次数。