AI 帮你写接口和逻辑,但系统设计、数据一致性、安全边界不可外包。这份指南覆盖知识地图、工作流、Prompt 模式、陷阱和工具栈。
AI 帮你写接口和逻辑,但系统设计、数据一致性、安全边界不可外包。以下是后端 vibe coder 的核心能力。
状态码不是摆设--404 vs 400 vs 403 vs 409 的区别直接影响客户端逻辑。AI 经常混用 400 和 500,你得能识别并纠正。理解 idempotency、content negotiation、caching headers。
范式、索引、外键约束、N+1 问题。AI 能写 SQL,但不会帮你设计 schema--它不知道你的查询模式。理解什么时候反范式、什么时候加索引、什么时候分区。
进程 vs 线程 vs 协程、事件循环、阻塞 vs 非阻塞 I/O。Node.js 单线程、Python GIL、Go goroutine--AI 写的代码默认它熟悉的并发模型,你得知道是否匹配你的运行时。
资源命名、版本策略、分页/过滤/排序约定、错误格式统一。AI 倾向于「能跑就行」的接口设计,你需要定义 API 规范并让它遵循。
Session vs JWT vs OAuth2、RBAC vs ABAC、token 刷新策略。安全相关的代码 AI 最容易写出漏洞--永远人工审查认证逻辑,不接受 AI 的「应该安全」。
Cache-aside vs write-through vs write-back、TTL 设计、缓存穿透/击穿/雪崩。AI 会帮你加 Redis,但不会告诉你缓存失效策略可能导致数据不一致。
ACID、隔离级别、乐观锁/悲观锁、分布式事务(Saga / TCC / Outbox)。AI 默认所有操作在一个事务里,跨服务时这就错了。
结构化日志、metrics、distributed tracing。AI 写的 console.log 不是日志。生产系统需要 request ID 贯穿、错误聚合、慢查询监控。
Dockerfile 最佳实践、多阶段构建、环境变量管理、健康检查。AI 生成的 Dockerfile 经常把 secret 烤进镜像、用 root 运行、不分阶段。
SQL 注入、XSS、CSRF、SSRF、路径遍历、依赖漏洞。AI 写的代码里参数化查询不一定参数化、文件路径不一定校验。安全审查不可外包。
后端比前端更需要结构化流程--一个错误的接口设计会波及所有客户端。以下是验证过的工作流。
先写 OpenAPI / TypeScript 类型 / Protobuf,不要让 AI 猜接口长什么样。契约是前后端和 AI 的共同接口。
// contracts.ts interface CreateUserRequest { email: string name: string role: 'admin' | 'member' } interface CreateUserResponse { id: string email: string name: string role: 'admin' | 'member' createdAt: string // ISO 8601 } interface ApiError { code: string // 'USER_EXISTS' not 'error' message: string // human-readable field?: string // which input field caused it }
手写 schema 迁移文件。AI 可以辅助,但索引策略和关系设计必须你决策。先想清楚查询模式再建表。
-- migrations/001_create_users.sql CREATE TABLE users ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), email TEXT NOT NULL UNIQUE, name TEXT NOT NULL, role TEXT NOT NULL DEFAULT 'member' CHECK (role IN ('admin', 'member')), created_at TIMESTAMPTZ NOT NULL DEFAULT now(), updated_at TIMESTAMPTZ NOT NULL DEFAULT now() ); -- 按创建时间排序的查询最多 -> 索引 CREATE INDEX idx_users_created_at ON users (created_at DESC);
一次只让 AI 实现一个端点。给它契约 + schema + 框架惯例。不要一次生成整个 controller。
Prompt 示例: 实现 POST /api/users 端点: - 入参: CreateUserRequest (见 contracts.ts) - 返回: 201 + CreateUserResponse - 错误: 409 if email exists (code='USER_EXISTS') - 用 Hono 框架, Zod 校验入参 - 参数化查询, 不要拼 SQL - 返回时不要暴露内部字段 (如 updated_at) - 加 structured log: method, path, status, duration_ms, request_id
端点就绪后,处理跨切面:中间件链(认证、日志、错误处理、CORS)、依赖注入、配置管理。
// app.ts - 人工组装,AI 辅助 import { Hono } from 'hono' import { logger } from 'hono/logger' import { cors } from 'hono/cors' import { authMiddleware } from './middleware/auth' import { errorHandler } from './middleware/error' import { usersRoute } from './routes/users' const app = new Hono() app.use('*', logger()) app.use('*', cors(corsConfig)) app.use('*', errorHandler) app.use('/api/*', authMiddleware) app.route('/api/users', usersRoute)
关键路径写集成测试(真实数据库),纯逻辑写单元测试。用 AI 生成测试用例,但你自己定义边界条件。
必须测试的场景: ✅ 正常路径: 创建用户 -> 201 + 正确响应 ✅ 重复 email -> 409 + error code ✅ 缺少必填字段 -> 400 + field 指向缺失字段 ✅ 无认证 -> 401 ✅ 无权限 (member 创建 admin) -> 403 ✅ 超长 name -> 400 (如果有限制) ❌ 不要测框架本身 (Hono 的路由) ❌ 不要测第三方库 (Zod 的校验)
后端 prompt 的核心是约束安全边界--不给约束,AI 会生成能跑但不安全、不可维护的代码。
| 模式 | 什么时候用 | 示例 |
|---|---|---|
| 契约先行 | 开始新 API 时 | 先给 OpenAPI/TS 类型,再让 AI 实现。契约是双方共识 |
| 安全约束 | 涉及用户输入时 | "所有查询必须参数化,禁止拼 SQL字符串。入参用 Zod 校验" |
| 框架锁定 | 防止 AI 混用框架 | "用 Hono + Drizzle ORM,不要引入 Express 或 Prisma" |
| 错误规范 | 需要统一错误格式时 | "错误返回 { code, message, field? },code 用大写蛇形,不要用 HTTP 状态码做 code" |
| 事务边界 | 涉及多表写入时 | "这个操作需要原子性,用事务包裹。失败时回滚并返回 500" |
| 日志规范 | 需要可观测性时 | "用 pino structured log,每条日志包含 request_id, method, path, status, duration_ms" |
| 迁移安全 | 修改 schema 时 | 先写迁移脚本,再改 ORM 代码。迁移必须可回滚 |
后端翻车比前端严重--数据丢了不能 Ctrl+Z。以下是高频陷阱。
AI 会用看起来参数化的写法,实际在拼字符串。比如 `WHERE id = ${id}`(模板字符串拼接)vs `WHERE id = $1`(真正参数化)。区别是前者可以被注入。永远检查 SQL 拼接方式,不接受任何形式的字符串插值。
AI 默认把所有数据库操作放在一个事务里。但如果你在事务里调用了外部 API(发邮件、调支付网关),事务会一直开着等网络返回,锁住行。外部调用必须移到事务外,或用 Outbox 模式。
AI 写 ORM 代码时经常在循环里查询。`users.map(u => getProfile(u.id))` 看起来人畜无害,100 个用户就是 101 条 SQL。用 include/join/eager loading 一次性查完,或在代码审查时用 EXPLAIN 验证。
AI 会把 secret 硬编码进代码、写进 Dockerfile、提交到 git。它不区分 .env 和 .env.example。永远在 .gitignore 里排除 .env,Dockerfile 里用 ARG/ENV 而非 COPY .env,CI 里用 secrets。
AI 喜欢 try-catch 然后返回一个通用的 500。这让你丢失了错误上下文。catch 块里必须 log 原始错误(含 stack trace),然后返回结构化的 error response。永远不要 catch 了不 log。
AI 写的并发代码几乎不考虑竞态。检查-然后操作(先查 email 再创建用户)在并发下会产生重复记录。用数据库唯一约束 + 乐观锁(version 字段)或 SELECT FOR UPDATE 来防止。
AI 生成的迁移脚本经常是不可回滚的(DROP TABLE、ALTER COLUMN 类型)。在生产环境,迁移必须先在 staging 验证,且要有 down 迁移。永远不要让 AI 直接对生产库跑 schema 变更。
按语言分推荐。选择标准:AI 训练数据充分 + 类型安全 + 生态成熟。
| 层 | 推荐 | 为什么 |
|---|---|---|
| 运行时 (TS) | Bun / Node.js 22 | Bun 快且内置测试/打包,Node 生态最广。AI 对两者都很熟 |
| 框架 (TS) | Hono | 轻量、类型安全、edge-first,AI 生成质量高 |
| ORM (TS) | Drizzle | SQL-like API、类型推断强、迁移文件可读。比 Prisma 更透明 |
| 运行时 (Py) | Python 3.12+ | asyncio 成熟,类型提示完善 |
| 框架 (Py) | FastAPI | 自动 OpenAPI 文档、Pydantic 校验、async 原生支持 |
| ORM (Py) | SQLAlchemy 2.0 | 类型提示完善、async 支持、表达式语言强大 |
| 数据库 | PostgreSQL 16 | JSONB、全文搜索、分区、逻辑复制。一个数据库解决大部分问题 |
| 缓存 | Redis 7 | 数据结构丰富、pub/sub、Lua 脚本。不要只当 key-value 用 |
| 部署 | Docker + Cloudflare / Fly.io | 容器化保证环境一致,边缘部署降低延迟 |
| 可观测性 | OpenTelemetry + Grafana | 统一 trace/metric/log 标准,不锁定厂商 |
| 消息队列 | Redis Streams / NATS | 简单场景用 Redis Streams,高吞吐用 NATS |
| CI/CD | GitHub Actions | AI 对 GH Actions YAML 最熟悉,生成质量高 |