后端工程师 AI 工具包

这个 pack 包含什么

受众：你以写 Go / Rust / Python / Node 服务为生。编辑器里已经有 LLM。它现在还做不好的事情是：任何碰到生产现实的部分 — 80 列的真 schema、半年前下游团队批准的契约、不是你选的微服务拓扑、凌晨 3 点 trace 突然断掉的事故。

这个 pack 9 个工具就是为这个缺口设计的。每一个都可以被 agent 直接操作（MCP server 或 skill），不是又一个你 go get 就能装的库。三层：

• 数据层 — 给 agent 一个安全、有结构的 Postgres 通道，让它能读 schema、提索引建议、dry-run SQL，又不烧掉你的生产集群。
• API + 服务层 — 让它能生成框架正确的 handler、OpenAPI 客户端、符合团队风格的 Go 服务骨架。
• 调试 + 可观测 — 出事故的时候，给它真的 debugger 和真的 telemetry，不是一个 print。

推荐安装顺序

顺序很重要。每一层解锁下一层。

1. PostgreSQL MCP（id 660）— 从这里开始。一个只读 MCP server，连到一个非生产副本上。这一步之后，agent 就能 describe table users、列出索引、采样 100 行。就这一个动作，把「AI 写看起来合理的 SQL」变成了「AI 写在你真实 schema 上能编译的 SQL」。
2. Postgres MCP Pro（id 3283）— 只读用顺了，再加索引调优 + 安全 SQL 这一层。同样的思路，更大的面：EXPLAIN 集成、索引推荐、加了安全模式的写工具。别在第 1 步之前装这个 — 你需要先吃过 agent 误读 schema 的亏。
3. Backend Architect agent（id 4367）— 一个 Claude Code skill：吃需求描述，吐出服务形状：表、端点、队列边界、失败模式。只动嘴不动代码 — 这是「想清楚」的环节。
4. FastAPI（id 839）— 强意见、类型驱动的 Python 框架。哪怕你生产环境跑 Go，FastAPI 也是给 agent 做原型 / 内部 AI 端点的最快目标栈。Pydantic 模型同时充当 LLM 的 schema 真相源。
5. OpenAPI Generator（id 2668）— 契约层。把你的 OpenAPI spec 给 agent，30 种语言的客户端 + 服务端 stub 一把出。别再让 agent 写手撸 HTTP 客户端、然后跟 spec 慢慢漂移了。
6. Golang Pro agent（id 4524）— 一个 Go 专家 Claude Code agent。懂幂等 error 包装、context.Context 传播、table test、标准项目布局。在 Backend Architect 定下形状之后用。
7. Microservices Architect agent（id 4433）— 需求跨服务时上。讨论服务边界、transactional outbox、idempotency key、saga vs 2PC。可选 — 单体团队请绕开。
8. Debugger agent（id 4393）— 一个跑四阶段 root cause 协议的 Claude Code skill：复现、隔离、假设、验证。配合真 debugger（Delve / pdb / node --inspect）用。专治「LLM 用 try/except 把症状盖过去」这个失败模式。
9. Logfire（id 3235）— 基于 OpenTelemetry 的 Python 可观测。哪怕不是 Python 服务，OTel 管道 + Logfire 的结构化视图也是一个合理的默认选择，让 Debugger agent 在凌晨 3 点有东西可读。

它们怎么协同

         ┌─────────────────────┐
         │  Backend Architect  │  ← 「设计这个功能」
         │     (4367)          │     （只说话，还不写代码）
         └──────────┬──────────┘
                    │ schema + 端点方案
                    ▼
   ┌────────────────┴────────────────┐
   │      数据层（只读）              │
   │  PostgreSQL MCP (660)           │  ← agent 读真 schema
   │  Postgres MCP Pro (3283)        │  ← 再推索引 / dry-run SQL
   └────────────────┬────────────────┘
                    │
                    ▼
   ┌─────────────────────────────────┐
   │      API + 服务层                │
   │  OpenAPI Generator (2668) ──┐   │  ← 契约即真相源
   │                             │   │
   │  FastAPI (839)   Golang Pro │   │  ← agent 写出栈正确的代码
   │                  (4524)     │   │
   │  Microservices Architect (4433) │  ← 跨边界调用而非进程内
   └────────────────┬────────────────┘
                    │
                    ▼
   ┌─────────────────────────────────┐
   │   调试 + 可观测                  │
   │  Logfire (3235) ─── spans ──┐   │
   │                             ▼   │
   │  Debugger agent (4393) ◀────────┤  ← 读 span + 重现 bug
   └─────────────────────────────────┘

关键的闭环：Architect 起草 → MCP server 把草稿落地到真 schema → 代码生成 agent 出框架正确的代码 → 可观测 + debugger 等生产说真话再回填反馈。 任何一层缺位，下一层就开始幻觉。

你会遇到的取舍

• 只读 DB MCP vs 可写 DB MCP — PostgreSQL MCP（660）默认只读，Postgres MCP Pro（3283）在安全模式后面开了写工具。先在非生产副本上跑只读至少两周；信任 agent 的 SQL 之后再放开。
• 懂 ORM 的 agent vs 写裸 SQL 的 agent — Backend Architect 和 Golang Pro 都不预设 ORM。如果团队规范是 GORM / sqlx / SQLAlchemy，在 CLAUDE.md 写一段说明 — 否则一个 PR 里会出现一半裸 SQL 一半 ORM。
• 单体 vs 微服务工具 — Microservices Architect（4433）对边界类工作真有用，但它倾向于「能拆服务就拆」。服务数 < 5 的团队可以装，但少用。
• 手撸客户端 vs OpenAPI Generator — openapi-generator 出的代码量大，部分丑。赢的不是代码好看 — 是 spec 和客户端漂移会变成编译错误，而不是凌晨 4 点的 bug。
• Logfire vs 既有 OTel 栈 — Logfire 偏 Python 风但说 OTel，Go / Rust 服务也能把 span 导过去。如果已经在跑 Tempo 或 Honeycomb，就把 Logfire 当作给 AI 看的副通道，别替换已经能用的东西。

常见踩坑

• DB MCP 指向生产 — 别。用逻辑副本、只读角色、或脱敏快照。agent 早晚会在 events 表上跑一个 12 路 join 把一个 CPU 卡死。
• 让 agent 发明 OpenAPI spec 里没有的端点 — 第 5 步装完之后，code review 必须卡「spec 是否声明了这个端点」。否则契约就变成小说。
• 同一个任务上叠两个架构 agent — Backend Architect + Microservices Architect 一起跑同一个 prompt，文本量乘 4 信号量乘 0。每轮规划用一个。
• 「我们有 Datadog 了所以不要 Logfire」 — 行，可以跳。但 Debugger agent 就没东西可读了；要么把它指向你既有的 OTel exporter，要么接受第 8 步效果减半。
• 把 Debugger agent 当一键「fix this」按钮 — 它是个四阶段协议；如果第一阶段（复现）失败，停下，别让它跳到「猜一个 fix」。