AI 时代的后端开发

• 输入：Figma 原型 / PRD 文档
• 输出：接口文档 / 数据库设计 / Go 后端服务代码 / 单元测试

第一阶段：需求消化与业务建模

在写任何代码前，先让 AI 帮你理清业务逻辑，建立领域模型

操作指南：将 PRD 或 Figma 截图喂给 AI，使用以下 Prompt 进行需求拆解：

我正在开发 [某某业务模块]，请帮我进行需求消化与业务建模。输入信息：[此处粘贴 PRD 核心描述，或上传 Figma 原型截图/交互说明]请输出：1. 核心业务实体及其关系（ER 模型简述），并给出对应的 Go Struct 骨架。2. 实体状态流转图（状态机）以及状态常量/枚举定义（使用 Go 的 const + iota 或自定义类型）。3. 指出潜在的并发问题、边界情况或业务逻辑漏洞。

第二阶段：数据库表结构设计

必须让 AI 遵循你“已有项目”的规范

基于我们刚才确认的业务实体，请帮我设计数据库表结构。项目背景与规范约束：1. 数据库类型：[MySQL 8.0 / PostgreSQL 14]2. 命名规范：表名小写下划线（如 `user_order`）；字段名小写下划线。3. 通用字段：每张表必须包含 `id` (bigint/雪花算法), `created_at`, `updated_at`, `is_deleted` (逻辑删除，tinyint)。4. 索引规范：高频查询字段必须加索引，联合索引注意最左前缀原则。5. 注释：所有表和字段必须有清晰的中文注释。请输出：1. 完整的 DDL 建表语句（包含索引和注释）。2. 对应的 GORM Model (Go Struct) 定义，包含 `gorm` 和 `json` tag。3. 设计理由说明（为什么这么设计索引，为什么用这个数据类型，是否考虑了未来的扩展性）。

第三阶段：接口契约设计

契约先行，先定义好输入输出契约（Request/Response Struct）

基于上述数据库表结构，请帮我设计 RESTful API 接口。设计要求：1. 遵循 RESTful 规范，合理划分 Handler/Controller。2. 严格分离 Request（入参）和 Response（出参）Struct，绝对不要把 GORM Model 直接暴露给前端。3. 考虑到 Figma 原型中的列表页，需要支持分页、条件筛选、排序。4. 字段校验：使用 `validate` 或 `binding` tag（如 `validate:"required,max=50"`）。对于可选字段，请合理使用指针类型（如 `*string`）以区分“零值”和“未传值”。5. 考虑到并发和幂等性，对于创建/修改接口，请说明需要哪些防重校验（如 Redis 分布式锁、数据库唯一索引）。请输出：1. 接口清单（Method, URI, 简述）。2. 核心接口的 Request 和 Response Struct 定义（包含完整的 json 和 validate tag）。

第四阶段：核心逻辑伪代码与测试用例

• 先用伪代码理清复杂业务逻辑（如状态机、分布式锁、事务边界）
• 让 AI 生成测试用例，实现 TDD（测试驱动开发）的 AI 变体

基于上述接口契约和表结构，请帮我编写核心业务逻辑的伪代码，并生成单元测试用例。设计要求：1. 伪代码要求：重点描述核心 Service/UseCase 方法。   - 需明确体现事务边界（如 `db.Transaction(func(tx *gorm.DB) error { ... })`）。   - 需体现并发控制（如 `sync.Mutex`、Redis 分布式锁、或数据库乐观锁 `updated_at` 校验）。   - 需体现 Go 的错误处理哲学（返回自定义的 `*BizError` 或包装后的 `error`，不要直接 panic）。2. 测试用例要求：使用 `GoConvey` 或 `testify`，结合 `gomock` / `mockery` 进行依赖 Mock。3. 场景覆盖：必须包含以下场景：   - 正常流程（Happy Path）。   - 并发冲突场景（如库存不足、状态已被修改）。   - 边界条件（如参数为空、分页越界）。   - 异常分支（如依赖的第三方服务超时，需体现 Context 超时控制）。请输出：1. 核心 Service 方法的伪代码（包含详细的中文注释说明每一步的意图，展示 Context 传递和 error 返回）。2. 完整的单元测试代码（包含 Mock 依赖、Table-Driven Tests 表驱动测试和断言）。

第五阶段：代码实现

通过 Few-Shot（少样本提示）和分步生成，让 AI 完美复刻你项目的 Go 代码风格。

操作指南：

1. 投喂参考代码：找一段你项目里写得最标准、最符合规范的旧代码（包含 Handler, Service, Repository, 错误处理）。
2. 分步生成：先写 Service 核心逻辑，再写 Handler，最后写 Repository/SQL。

我现在要在已有项目中实现 [某某功能] 的接口。项目上下文：- 框架：[Hertz / Kitex]- ORM：[GORM]- 统一返回格式：使用 Go 泛型 `Result[T any]` 包装。- 错误处理：Service 层返回自定义的 `*BizError`（包含 Code 和 Msg），Handler 层通过中间件/统一函数将其转换为 HTTP JSON 响应。- 依赖注入：使用 [Wire / fx / 手动注入]，Service 依赖 Repository 的 Interface 而不是具体实现。- 参考代码：请阅读项目中的 `@file:old_order_handler.go` 和 `@file:old_order_service.go`，**必须严格保持与参考代码相同的代码风格、命名习惯、目录结构和 Context 传递方式**。任务：帮我实现 [新接口名称]。1. 先实现 Service 层（或 UseCase 层）的核心业务逻辑。注意：   - 方法签名必须包含 `ctx context.Context` 作为第一个参数。   - 使用 `db.WithContext(ctx).Transaction(...)` 处理事务。   - 错误返回需使用 `fmt.Errorf("xxx failed: %w", err)` 进行包装，或直接返回 `biz.ErrXxx`。2. 再实现 Handler/Controller 层，使用之前定义的 Request/Response Struct 接收和返回参数，通过 `ctx.ShouldBindJSON` 或类似方法校验参数。3. 使用项目现有的中间件工具（如 `auth.GetUserID(ctx)` 获取当前用户）。不要输出多余的废话，直接给出符合 Idiomatic Go 风格的可运行代码。