一、需求澄清与细化（需求不清晰时）
目标：将模糊的需求转化为明确的、可执行的开发任务。
1.1 人：提出原始需求（自然语言）
- 用一句话描述要做什么（例：“做一个拍卖行系统”）。
1.2 AI：生成需求澄清问题列表
- 要求AI列出所有需要明确的点，例如：
- 拍卖类型（英式、荷兰式、一口价）？
- 出价规则（加价幅度、是否允许代理出价）？
- 并发场景（多少人同时出价）？
- 一致性要求（是否允许超卖）？
- 异常处理（支付失败、背包满、服务重启）？
1.3 人：回答问题，补充细节
- 逐一回答AI的问题，形成最终的需求文档（Markdown格式）。
1.4 AI：输出需求规格说明书（PRD）
- 包含：功能列表、业务流程（流程图）、接口定义、数据模型、非功能性需求（性能、安全、可扩展性）。
产出：清晰的需求文档，所有人达成共识。
二、编程规则限定（模拟真正程序员的开发习惯）
目标：让AI生成的代码符合团队规范，避免“玩具代码”。
2.1 人：设定编程规则清单（一次性定义，后续复用）
规则示例：
纯文本
- 语言：Go 1.22+ - 风格：遵循 Uber Go Style Guide - 错误处理：所有错误必须显式处理，不允许 _ - 日志：使用 structured logging（zap），关键路径打印 traceId - 并发：所有共享变量必须加锁或使用 channel，禁止裸 sync.Map - 事务：数据库事务必须显式控制边界，不允许自动提交 - 幂等：所有写操作必须携带 requestId，并在数据库层去重 - 测试：单元测试覆盖率 ≥ 80%，核心路径 100%，必须包含并发测试 - 安全性：所有用户输入必须在服务端校验，禁止拼接 SQL2.2 AI：将规则嵌入系统提示（System Prompt）
- 在每次对话开始时，将规则列表粘贴给AI，要求其严格遵守。
2.3 人：代码审查时对照规则清单
- 逐条检查AI生成的代码是否符合规则，不符合则打回重写。
产出：一致的代码风格和质量基线。
三、开发阶段（模拟真正程序员开发）
3.1 架构设计与接口定义
| 步骤 | 谁做 | 内容 |
|---|---|---|
| 设计模块划分 | 人 | 画出模块图（Handler → Service → DAO → DB/Cache/MQ） |
| 定义API接口 | 人 + AI | 人写出接口路径、请求/响应；AI生成OpenAPI规范 |
| 定义数据模型 | AI + 人审 | AI生成表结构、Redis键设计；人审核索引、约束 |
3.2 骨架代码生成
| 步骤 | 谁做 | 内容 |
|---|---|---|
| 生成项目结构 | AI | 按分层架构生成目录和文件 |
| 生成DAO/Cache/MQ层 | AI | 生成CRUD、锁、消息收发等基础代码 |
| 生成Service层空壳 | AI | 生成函数签名、注释、错误定义 |
3.3 核心逻辑实现（人指导，AI执行）
| 步骤 | 谁做 | 内容 |
|---|---|---|
| 人写伪代码/流程图 | 人 | 用自然语言描述核心流程（例：出价→校验→扣款→更新→通知） |
| AI翻译为代码 | AI | 将伪代码转为实际代码，注意事务、锁、幂等 |
| 人审查关键代码 | 人 | 检查状态机、并发安全、错误处理、边界条件 |
| 迭代修复 | 人+AI | 人提出修改意见，AI调整 |
3.4 单元测试（AI生成，人补充）
| 步骤 | 谁做 | 内容 |
|---|---|---|
| 生成基础测试 | AI | 覆盖正常路径、常见异常 |
| 人补充测试矩阵 | 人 | 列出所有必须覆盖的场景（并发、边界、幂等、状态机非法转换） |
| AI补全缺失测试 | AI | 根据矩阵生成测试代码，含goroutine并发测试 |
| 运行并修复 | 人+AI | 运行go test -race，修复data race和逻辑错误 |
3.5 并发与安全加固
| 步骤 | 谁做 | 内容 |
|---|---|---|
| 并发压测 | 人 | 用wrk/hey模拟高并发，观察是否有超卖、死锁 |
| 分析问题 | 人+AI | 人定位问题，AI给出多个修复方案 |
| 选择并实施修复 | 人 | 选择最优方案，AI执行代码修改 |
| 安全审计 | AI + 人审 | AI扫描常见漏洞，人确认风控规则 |
3.6 集成测试与预发布
| 步骤 | 谁做 | 内容 |
|---|---|---|
| 搭建集成环境 | 人 | 启动依赖服务，准备测试数据 |
| 编写集成测试 | AI | 覆盖端到端流程 |
| 模拟故障 | 人 | MQ宕机、Redis切换、服务重启；AI辅助编写故障脚本 |
| 验证幂等与补偿 | 人+AI | 重复请求、部分失败场景 |
3.7 性能调优
| 步骤 | 谁做 | 内容 |
|---|---|---|
| 制定压测目标 | 人 | 如：P99 < 200ms，QPS ≥ 500 |
| 执行压测 | 人 | 记录QPS、延迟、错误率 |
| 分析瓶颈 | 人+AI | AI分析pprof、慢查询；人判断瓶颈 |
| 优化代码 | 人指导，AI执行 | 增加缓存、优化SQL、减小锁粒度 |
四、单元测试专项指南
4.1 测试覆盖矩阵模板
| 测试场景 | 优先级 | 是否覆盖 | 测试函数名 |
|---|---|---|---|
| 正常流程（Happy Path） | P0 | ✅ | TestXxx_Success |
| 参数错误（负值、空值） | P0 | ✅ | TestXxx_InvalidParam |
| 业务异常（余额不足、库存不足） | P0 | ✅ | TestXxx_Insufficient |
| 并发竞争（多人同时操作） | P1 | ❌ | 需补 |
| 幂等性（重复请求） | P1 | ❌ | 需补 |
| 边界条件（时间截止、库存为1） | P1 | ❌ | 需补 |
| 状态机非法转换 | P2 | ❌ | 需补 |
| 服务重启后恢复 | P2 | ❌ | 需补 |
4.2 AI生成测试的要求
- 每个测试函数独立，使用
t.Run子测试组织。 - 并发测试必须使用
t.Parallel()和sync.WaitGroup。 - 使用
go test -race验证无数据竞争。 - 使用 mock/stub 隔离外部依赖（数据库、Redis、MQ）。
- 测试数据尽量随机生成，避免硬编码。
4.3 测试通过标准
- 单元测试覆盖率 ≥ 80%（核心模块 ≥ 90%）。
- 所有P0/P1场景覆盖。
go test -race -count=1全部通过，无警告。- 压测场景下无死锁、无数据不一致。
五、部署与监控
| 步骤 | 谁做 | 内容 |
|---|---|---|
| 配置管理与特性开关 | 人+AI | AI生成配置结构体，人设置Feature Flag |
| 数据库迁移脚本 | AI | 生成向上/向下迁移，人审核向前兼容性 |
| CI/CD配置 | AI | 生成Dockerfile、Pipeline配置 |
| 灰度发布 | 人 | 制定分批上线策略 |
| 监控告警 | 人+AI | AI生成指标暴露代码，人配置告警规则 |
| 全链路追踪 | AI | 集成OpenTelemetry |
六、持续改进
| 步骤 | 谁做 | 内容 |
|---|---|---|
| 线上问题复盘 | 人+AI | 人描述问题，AI辅助分析日志 |
| 性能优化 | 人指导，AI执行 | 根据线上数据调整参数 |
| 规则更新 | 人 | 根据经验更新编程规则清单 |
附录：人与AI分工速查表
| 任务 | 负责人 | 示例 |
|---|---|---|
| 业务决策、架构选型 | 人 | 选择数据库、缓存策略 |
| 代码生成、测试编写 | AI | 生成DAO、单元测试 |
| 代码审查、安全审计 | 人 | 检查状态机、SQL注入 |
| 故障诊断 | 人主导，AI辅助 | 人描述现象，AI列出可能原因 |
| 性能调优 | 人指导，AI执行 | 人指出瓶颈，AI修改代码 |
