AI 编程工作流搭建：我的日常开发 SOP

导语

把 AI 工具嵌入每个开发环节，形成标准化工作流后，我的日常开发变成了「审代码」而不是「敲代码」。

这篇分享我现在的「AI 增强版」日常 SOP，以及省下的时间账。

一、工作流全景图

复制代码

需求评审 ──→ 技术设计 ──→ 编码 ──→ 自测 ──→ Code Review ──→ 部署
    │           │          │         │            │            │
    ▼           ▼          ▼         ▼            ▼            ▼
 Kimi读PRD   Claude出    Cursor   AI生成      AI预检      AI生成
 出疑问清单   时序图+建表   补全代码  单元测试     常见Bug    发布说明

二、各环节工具配置与 Prompt 模板

2.1 需求评审：Kimi 读 PRD 出疑问清单

输入：产品 PRD 文档（Markdown / PDF / 飞书链接）

Prompt：

复制代码

你是一名资深 Java 后端开发工程师，擅长识别需求中的技术风险。
请阅读以下 PRD，输出一份「技术评审疑问清单」，重点关注：
1. 接口字段是否有歧义（如时间格式、枚举值定义）
2. 并发场景是否考虑（如库存扣减、积分兑换）
3. 数据量级预估（是否需要分库分表、索引优化）
4. 与现有系统的冲突（是否有重复字段、接口命名冲突）
5. 安全合规（敏感数据脱敏、权限控制）

请按优先级 P0/P1/P2 分类，每个问题给出建议方案。

输出示例：

markdown 复制代码

## 技术评审疑问清单

### P0（阻塞上线）
1. **库存扣减未考虑并发**：PRD 中只说「扣减库存」，未说明分布式锁或乐观锁策略。
   - 建议：使用 Redis 分布式锁 + 数据库乐观锁（version 字段）双重保障。

2. **接口返回字段 `expiry_date` 格式未定义**：前端可能传 `2024-01-01` 也可能传时间戳。
   - 建议：统一使用 ISO-8601 格式 `yyyy-MM-dd HH:mm:ss`，DTO 用 @JsonFormat 注解。

### P1（建议优化）
3. **查询接口未分页**：「查询全部药品」在数据量增大后会 OOM。
   - 建议：默认分页 pageSize=20，最大 pageSize=100。

时间账 ：原来读 PRD + 自己想问题要 30 分钟，现在 Kimi 5 分钟出清单，我花 10 分钟审核补充。省 15 分钟。

2.2 技术设计：Claude 出时序图 + 建表语句

输入：PRD + 已有的领域模型

Prompt：

复制代码

你是一名 Java 架构师，请根据以下需求输出技术设计文档：

需求：[粘贴 PRD 核心内容]
现有表结构：[粘贴相关表 DDL]

要求输出：
1. Mermaid 时序图（用户→前端→后端→数据库的完整交互）
2. 新增表的 DDL（PostgreSQL，字段带注释，含索引建议）
3. 核心接口的 OpenAPI 规范（路径、方法、参数、返回值）
4. 缓存策略（哪些数据走 Redis，过期时间）
5. 风险点清单

输出示例（节选）：
PostgreSQL 库存Mapper Redis 库存Service 库存Controller 前端用户 PostgreSQL 库存Mapper Redis 库存Service 库存Controller 前端用户 alt [quantity >= deductQty] [库存不足] alt [获取锁成功] [获取锁失败] 提交扣减请求 POST /api/stock/deduct deduct(dto) SET stock:lock:{drugId} NX EX 10 selectQuantity(drugId, warehouseId) SELECT quantity FROM inventory ... 100 100 UPDATE inventory SET quantity = quantity - ? ... UPDATE ... 1 DEL stock:lock:{drugId} true DEL stock:lock:{drugId} throw BizException("库存不足") throw BizException("操作频繁") Result<Boolean> 扣减结果

sql 复制代码

-- 库存流水表
CREATE TABLE stock_record (
    id BIGSERIAL PRIMARY KEY COMMENT '主键',
    drug_id VARCHAR(32) NOT NULL COMMENT '药品编码',
    warehouse_id VARCHAR(32) NOT NULL COMMENT '仓库编码',
    type VARCHAR(16) NOT NULL COMMENT '操作类型：DEDUCT-扣减, REPLENISH-补货',
    quantity INT NOT NULL COMMENT '变动数量',
    before_qty INT NOT NULL COMMENT '变动前库存',
    after_qty INT NOT NULL COMMENT '变动后库存',
    biz_no VARCHAR(64) NOT NULL COMMENT '业务单号（幂等键）',
    operator_id VARCHAR(32) COMMENT '操作人',
    created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
    CONSTRAINT uk_biz_no UNIQUE (biz_no)
);

-- 索引
CREATE INDEX idx_record_drug_warehouse ON stock_record(drug_id, warehouse_id, created_at);
CREATE INDEX idx_record_created ON stock_record(created_at);

时间账 ：原来画时序图 + 写 DDL 要 1 小时，现在 Claude 10 分钟出初稿，我花 15 分钟调整。省 35 分钟。

2.3 编码：Cursor 补全 + Copilot

工作方式：

Cursor：新接口开发（Tab 补全生成 Controller / Service / Mapper 骨架）
GitHub Copilot（IDEA 内）：老代码维护时的单行补全

Cursor 的 .cursorrules 配置：

复制代码

You are an expert Java backend developer.
Technology stack: Spring Boot 2.7, MyBatis-Plus, PostgreSQL, Redis, Maven.
Coding standards:
- Follow Alibaba Java Coding Guidelines
- Use Lombok @Data for DTOs, @Builder for complex objects
- Controller returns Result<T> wrapper
- Service methods are annotated with @Transactional when writing to DB
- Use SLF4J log.info/log.error for all public methods
- Prefer Optional over null checks
- Use Java Stream API for collection operations
- All SQL in Mapper XML must have index hints in comments

时间账 ：原来写一个新接口（Controller + 3 个 DTO + Service + Mapper + XML）要 2 小时，现在 Cursor 20 分钟出骨架，我花 40 分钟填业务逻辑。省 1 小时。

2.4 自测：AI 生成单元测试

见上一篇《用 AI 自动生成单元测试》的详细流程。

简化版 Prompt：

复制代码

给以下 Java 类生成 JUnit 5 + Mockito 单元测试：
- 覆盖正常流程、异常流程、边界条件
- 使用 @ExtendWith(MockitoExtension.class)
- 不启动 Spring 上下文
- 输出完整可运行的 Java 代码

源码：
[粘贴代码]

时间账 ：原来写测试要 1.5 小时，现在 AI 5 分钟出生成，我花 20 分钟调数据。省 1 小时 5 分钟。

2.5 Code Review：AI 预检常见 Bug

在提交 PR 前，先让 AI 扫一遍：

Prompt：

复制代码

你是一名严格的 Code Reviewer，请 Review 以下 Java 代码，按以下维度检查：
1. 是否有 NPE 风险（未判空的字段、可能返回 null 的方法）
2. 是否有并发问题（共享变量、未加锁的扣减操作）
3. 是否有资源泄漏（未关闭的流、未释放的锁）
4. 是否有 SQL 注入（拼接 SQL、$ 符号）
5. 是否有性能问题（循环查库、N+1、大事务）
6. 是否符合 Java 规范（魔法数字、异常吞掉、日志占位符）

对每个发现的问题，给出：问题描述、风险等级、修复建议、修复后的代码片段。

时间账 ：原来 Review 自己代码要 20 分钟，现在 AI 3 分钟出报告，我花 10 分钟确认。省 7 分钟。

2.6 部署：AI 生成发布说明

Prompt：

复制代码

请根据以下 Git Commit 记录，生成一份发布说明（Release Note）：
- 按功能模块分类（新增、优化、修复）
- 每个变更用一句话描述用户价值（不是技术描述）
- 标注是否有数据库变更（DDL/DML）
- 标注是否需要配置变更
- 输出 Markdown 格式

Commit 记录：
[粘贴 git log --oneline]

输出示例：

markdown 复制代码

## Release v1.2.0

### ✨ 新增功能
- **库存预警**：当药品库存低于安全线时，自动发送钉钉通知给采购员
- **批量导入**：支持 Excel 批量导入药品基础信息，单次最多 5000 条

### 🔧 优化
- **查询速度**：药品查询接口响应时间从 800ms 优化到 120ms（加联合索引）
- **页面加载**：库存列表页支持虚拟滚动，10万条数据不卡顿

### 🐛 Bug 修复
- **并发扣减**：修复高并发下库存超扣问题（加 Redis 分布式锁）
- **时间格式**：修复导出 Excel 时日期显示为数字的问题

### ⚠️ 升级注意
- 需执行数据库迁移脚本：V1.2.0__add_stock_alert.sql
- 需在 Nacos 新增配置：stock.alert.threshold=50

时间账 ：原来写发布说明要 30 分钟，现在 AI 2 分钟出稿，我花 5 分钟调整。省 23 分钟。

三、Prompt 模板库：5 个高频模板

我把最常用的 Prompt 整理成了模板库，存在 Notion 里，用时复制：

模板 1：SQL 优化请求

复制代码

表结构：
[粘贴 DDL]

慢查询 SQL：
[粘贴 SQL]

执行计划：
[粘贴 EXPLAIN 结果]

请给出优化建议，要求：
1. 分析慢的原因
2. 给出优化后的 SQL
3. 给出索引建议（含 DDL）
4. 预估优化后的执行时间

模板 2：报错分析

复制代码

报错信息：
[粘贴完整堆栈]

相关代码：
[粘贴代码]

配置文件：
[粘贴相关配置]

请：
1. 用大白话解释报错原因
2. 给出修复方案
3. 给出修复后的代码

模板 3：代码重构

复制代码

请重构以下代码，要求：
1. 使用 Java Stream API 替代 for 循环
2. 提取重复逻辑为私有方法
3. 使用 Optional 替代 null 判断
4. 添加方法级注释
5. 保持原有逻辑不变

源码：
[粘贴代码]

模板 4：生成接口文档

复制代码

请根据以下 Controller 代码，生成 Markdown 接口文档：
1. 接口名称和描述
2. 请求方式、URL、Content-Type
3. 请求参数（字段名、类型、必填、说明）
4. 响应参数（字段名、类型、说明）
5. 错误码列表
6. 请求/响应示例（JSON）

源码：
[粘贴代码]

模板 5：写发布说明

复制代码

请根据以下 Commit 记录生成发布说明：
- 按新增/优化/修复分类
- 用用户视角描述（不是技术视角）
- 标注数据库变更和配置变更
- Markdown 格式

Commits：
[粘贴 git log]

四、知识库管理：让 AI 懂你的业务

4.1 项目 README 规范

每个模块根目录放 AI-CONTEXT.md，告诉 AI 这个模块的业务背景：

markdown 复制代码

# 库存管理模块 - AI 上下文

## 业务背景
- 药品库存管理，支持多仓库
- 核心流程：采购入库 → 库存冻结 → 销售扣减 → 库存释放
- 并发场景：每日峰值 1000 QPS，库存扣减必须强一致

## 领域术语
- 安全线：库存低于此值触发预警
- 冻结：订单占用但未出库的库存
- 批次：同一药品不同生产批次的库存分开管理

## 技术约束
- 数据库：PostgreSQL 14，主从架构
- 缓存：Redis Cluster，库存余额缓存 5 分钟
- 消息：RabbitMQ，库存变动异步通知 ERP

## 历史坑点
- 2024-03：并发扣减导致超卖，已加分布式锁
- 2024-05：批次过期未清理，已加定时任务

4.2 领域词汇表

markdown 复制代码

| 中文 | 英文 | 数据库字段 | 说明 |
|------|------|-----------|------|
| 药品 | Drug | drug_id | 唯一编码，非自增 |
| 库存 | Stock | quantity | 实时库存，含冻结 |
| 可用库存 | Available | quantity - frozen | 计算字段，不存库 |
| 仓库 | Warehouse | warehouse_id | 分仓编码 |
| 批次 | Batch | batch_no | 生产日期+流水号 |

4.3 历史方案文档

把重要的技术决策记录（ADR）也喂给 AI：

markdown 复制代码

## ADR-003：库存扣减方案选型

### 背景
需要支持高并发库存扣减，防止超卖。

### 选项
1. 数据库悲观锁（SELECT FOR UPDATE）
2. 数据库乐观锁（version 字段）
3. Redis 分布式锁 + 数据库更新

### 决策
选方案 3：Redis 分布式锁保证并发安全，数据库乐观锁做二次校验。

### 原因
- 悲观锁性能差（TPS 从 500 降到 50）
- 纯乐观锁在极端并发下仍有 race condition
- Redis 锁 + 乐观锁双重保障，TPS 维持在 400+

五、效率数据：省下的时间账

开发环节	传统方式	AI 辅助方式	节省时间
需求评审	30 min	15 min	15 min
技术设计	60 min	25 min	35 min
编码（新接口）	120 min	60 min	60 min
写单元测试	90 min	25 min	65 min
Code Review	20 min	13 min	7 min
写发布说明	30 min	7 min	23 min
合计（每个需求）	350 min	145 min	205 min

结论：每个需求平均节省 3.4 小时 ，按每天 2 个需求算，一天省 7 小时------当然实际没这么夸张，因为省下的时间被用来处理更复杂的架构问题了。

六、避坑指南：3 个血泪教训

教训 1：过度依赖 AI 导致基础能力退化

有段时间我几乎不手写 SQL 了，全让 AI 生成。结果有一次线上问题，AI 生成的索引建议导致全表扫描，我花了 2 小时才定位------因为我已经忘了怎么看执行计划。

对策：每周至少手写 2 个复杂 SQL，保持手感。

教训 2：AI 幻觉引发的线上事故

AI 生成的代码里有一段「优雅」的 Stream 操作，我直接复制上线，结果在空集合时抛了 NoSuchElementException。

对策：AI 生成的代码必须跑过单元测试 + 集成测试，不能「盲信」。

教训 3：人工审核的底线原则

我定了三条红线，AI 生成的内容必须人工确认：

涉及数据库变更（DDL/DML）：必须 DBA Review
涉及金额计算：必须双人复核
涉及权限控制：必须安全团队 Review

写在最后

AI 工作流不是「买了工具就会自动变快」，而是重新设计你的工作方式。最大的改变不是「省时间」，而是「把注意力从体力活转移到思考上」。

当你每天少写 200 行样板代码，多出来的时间可以用来：

读源码，理解框架底层
画架构图，思考系统演进
写技术博客，沉淀经验

这才是 AI 编程的真正价值。