1.计划目标

1.1 完成三周规划，详细指定每周进度，验收标准

2.工作进展

2.1 制定三周工作规划

第一周: 完成项目雏形，不考虑高并发等加分项

验收指标：完成所有基本功能，形成闭环

第二周：完成基础测试，在高并发方向追求极致

验收指标：QPS达到10k，直播间在线人数达到1k

第三周：完成高并发/高可用测试

验收指标：故障率小于0.01%，可用时间大于99.9%

2.2 技术选型

前端：React + TypeScript

后端：Go + MySQL + Redis

2.3 harness 系统设计

状态和原则层：给定编码规范，业务认知等底层知识

agents.md：角色认知+技能配置+知识库权限

# Agent: Go后端开发助手

### 角色描述
专注于 Go + Gin + GORM 技术栈的开发和优化

### 技能配置
- Go 语言最佳实践
- Gin 框架优化
- 数据库查询优化
- 高并发场景优化

### 知识库
- backend-go/ 目录结构
- 现有模块代码
- 性能优化历史

# Agent: 可观测性工程师

### 角色描述
负责抖音电商直播竞拍系统的监控、告警和性能分析

### 技能配置
- PromQL 告警规则编写
- Grafana 仪表盘设计
- 性能瓶颈分析
- 日志分析和故障排查

### 知识库
- 项目架构文档
- 技术栈：Go + Redis + MySQL
- 业务指标：QPS、出价成功率、在线人数

# Agent: React前端开发助手

### 角色描述
专注于 React + TypeScript 前端开发和用户体验优化

### 技能配置
- React 组件优化
- Ant Design 最佳实践
- 性能优化
- 动画效果设计

### 知识库
- frontend/ 和 h5/ 目录结构
- 现有页面代码
- UI/UX 需求文档

checklist.md: 任务卡点

# 抖音电商直播竞拍全栈系统三周规划验收清单

## 第一周验收检查点

* [x] 项目初始化完成，前后端基础框架搭建成功

* [x] MySQL数据库表结构设计完整，包含用户、商品、竞拍场次、出价记录、订单等核心表

* [x] Redis环境配置完成，缓存数据结构设计合理

* [x] 商家端PC后台登录/注册功能正常

* [x] 商家端商品CRUD功能完整可用

* [x] 商家端竞拍场次创建与规则配置功能正常

* [x] 竞拍场次状态流转逻辑正确（未开始→进行中→已结束/已取消）

* [x] 第一周所有基础API接口测试通过

## 第二周验收检查点

* [x] 竞拍规则引擎完整实现：0元起拍、加价幅度、封顶价自动成交、自动延时

* [x] WebSocket长连接服务搭建成功，支持房间级隔离

* [x] 心跳保活机制正常工作，断线重连功能可用

* [x] 出价接口幂等性校验实现，防止重复出价

* [x] 实时排名计算与推送功能正常

* [x] 毫秒级倒计时多客户端同步一致

* [x] 用户端H5项目核心页面完成（直播间、商品列表、详情）

* [x] 用户端手动出价功能正常，实时接收关键事件提醒

* [x] 完整竞拍流程前后端联调通过

## 第三周验收检查点

* [x] Redis分层缓存策略实现，高频读写性能优化

* [x] Redis分布式锁实现，出价幂等性保障

* [x] 乐观锁机制实现，防止超卖问题

* [x] 单直播间支持1000+用户同时在线

* [x] 竞价氛围体验优化完成：出价领先/被超越动画、实时排行榜、倒计时动画、提示音

* [x] 单元测试与接口自动化测试覆盖核心功能

* [x] 压力测试通过，高并发场景下系统稳定

* [x] 异常场景测试覆盖（网络断开、服务重启等）

* [x] 项目技术方案文档完整

* [x] 双端功能演示视频录制完成

* [x] 最终全流程回归测试通过，项目交付完成

spec.md：文档规范

# 抖音电商直播竞拍全栈系统三周规划 Spec

## Why
基于「实时竞拍大师」抖音电商直播竞拍全栈系统项目需求，制定三周完整开发计划，确保项目从0到1高质量交付，覆盖核心功能实现、高并发优化、测试调优全流程。

## What Changes
- 第一周：项目架构搭建与基础功能开发
- 第二周：核心竞拍逻辑与实时通信实现
- 第三周：高并发优化、测试调优与项目交付
- 每周明确工作内容、工作重点、工作难点，预留充足测试调优时间

## Impact
- Affected specs: 全栈系统开发规划
- Affected code: 前端React+TS项目、后端Node/Go服务、MySQL/Redis数据库设计

## ADDED Requirements
### Requirement: 三周完整开发周期规划
系统 SHALL 提供清晰的三周任务分解，每周包含明确的工作内容、重点、难点和测试调优时间。

#### Scenario: 第一周完成基础架构
- **WHEN** 第一周结束
- **THEN** 完成项目初始化、数据库设计、前后端基础框架搭建、商家端基础管理功能

#### Scenario: 第二周完成核心竞拍功能
- **WHEN** 第二周结束
- **THEN** 完成完整竞拍规则引擎、WebSocket实时通信、用户端核心竞拍交互

#### Scenario: 第三周完成优化与交付
- **WHEN** 第三周结束
- **THEN** 完成高并发优化、全流程测试、性能调优、项目文档与演示准备

tasks.md：任务清单

# 抖音电商直播竞拍全栈系统三周任务清单

## 第一周：项目架构搭建与基础功能开发
**目标**：完成项目初始化、数据库设计、前后端基础框架搭建、商家端基础管理功能

- [x] 第1天：项目初始化与技术选型确认
  - [x] 确认前后端技术栈（React+TS + Node.js/Go + MySQL + Redis）
  - [x] 创建前端React+TypeScript项目，配置路由、状态管理
  - [x] 创建后端项目，配置基础服务框架、中间件
  - [x] 搭建Git仓库，初始化项目结构

- [x] 第2天：数据库设计与环境搭建
  - [x] 设计MySQL数据库表结构（用户表、商品表、竞拍场次表、出价记录表、订单表）
  - [x] 配置Redis环境，设计缓存数据结构
  - [x] 编写数据库初始化脚本
  - [x] 搭建本地开发环境（MySQL、Redis服务）

- [x] 第3天：后端基础API开发
  - [x] 实现用户认证授权接口（JWT）
  - [x] 实现商品CRUD基础接口
  - [x] 实现竞拍场次基础管理接口
  - [x] 统一API响应格式、异常处理中间件

- [x] 第4天：商家端PC后台前端开发
  - [x] 实现登录/注册页面
  - [x] 实现商品列表、商品新增/编辑页面
  - [x] 实现竞拍场次创建与规则配置页面
  - [x] 对接后端基础API

- [x] 第5天：商家端管理功能完善
  - [x] 实现商品图片上传功能
  - [x] 实现竞拍场次状态管理（未开始、进行中、已结束、已取消）
  - [x] 实现订单列表与详情查看页面
  - [x] 第一周中期功能联调

- [x] 第6天：第一周功能测试与Bug修复
  - [x] 测试商家端全流程功能
  - [x] 修复发现的Bug
  - [x] 代码Review与基础优化
  - [x] 第一周阶段性总结

- [x] 第7天：第一周缓冲与调优时间
  - [x] 处理遗留问题
  - [x] 优化代码结构
  - [x] 准备第二周开发计划

**第一周工作重点**：数据库设计合理性、前后端分层架构清晰、商家端基础管理功能完整可用
**第一周工作难点**：竞拍相关复杂表结构设计、状态流转逻辑定义

---

## 第二周：核心竞拍逻辑与实时通信实现
**目标**：完成完整竞拍规则引擎、WebSocket实时通信、用户端核心竞拍交互

- [x] 第8天：竞拍规则引擎后端实现
  - [x] 实现0元起拍规则逻辑
  - [x] 实现加价幅度校验逻辑
  - [x] 实现封顶价自动成交逻辑
  - [x] 实现自动延时机制逻辑

- [x] 第9天：WebSocket服务搭建
  - [x] 搭建WebSocket长连接服务，实现房间级隔离
  - [x] 实现心跳保活机制
  - [x] 实现用户连接管理、断线重连处理
  - [x] 设计WebSocket消息协议规范

- [x] 第10天：实时竞拍核心逻辑开发
  - [x] 实现出价接口幂等性校验
  - [x] 实现实时排名计算与推送
  - [x] 实现毫秒级倒计时同步机制
  - [x] 实现竞拍状态实时广播

- [x] 第11天：用户端H5项目开发
  - [x] 创建移动端H5项目，适配移动端交互
  - [x] 实现模拟直播间页面
  - [x] 实现商品列表与详情页面
  - [x] 实现用户登录/注册

- [x] 第12天：用户端竞拍交互开发
  - [x] 实现手动出价功能
  - [x] 实现实时排行榜展示
  - [x] 实现关键事件提醒（被超越、竞拍延时、竞拍结束）
  - [x] 对接WebSocket实时消息

- [x] 第13天：第二周功能联调与测试
  - [x] 前后端联调完整竞拍流程
  - [x] 测试多用户同时出价场景
  - [x] 测试自动延时、封顶价成交等核心规则
  - [x] 修复实时同步相关Bug

- [x] 第14天：第二周缓冲与调优时间
  - [x] 优化WebSocket连接稳定性
  - [x] 优化前端交互体验
  - [x] 处理第二周遗留问题
  - [x] 第二周阶段性总结

**第二周工作重点**：竞拍规则零漏洞实现、毫秒级实时同步、WebSocket房间级隔离
**第二周工作难点**：高并发下出价数据一致性、多客户端倒计时精确同步、网络波动下断线重连状态恢复

---

## 第三周：高并发优化、测试调优与项目交付
**目标**：完成高并发优化、全流程测试、性能调优、项目文档与演示准备

- [x] 第15天：Redis缓存策略优化
  - [x] 实现竞拍数据分层缓存
  - [x] 实现高频读写操作走Redis
  - [x] 实现缓存防击穿、防穿透、防雪崩策略
  - [x] 优化数据库查询性能

- [x] 第16天：分布式锁与高并发优化
  - [x] 实现Redis分布式锁解决出价幂等性
  - [x] 实现乐观锁机制防止超卖
  - [x] 优化WebSocket消息广播性能
  - [x] 实现单直播间1000+用户同时在线支持

- [x] 第17天：竞价氛围体验打磨
  - [x] 添加上出价领先/被超越动画效果
  - [x] 优化实时排行榜视觉效果
  - [x] 添加倒计时动画、出价提示音
  - [x] 优化整体交互紧张感营造

- [x] 第18天：全流程集成测试
  - [x] 编写单元测试用例
  - [x] 编写接口自动化测试
  - [x] 进行压力测试，模拟高并发出价场景
  - [x] 进行异常场景测试（网络断开、服务重启等）

- [x] 第19天：性能调优与Bug修复
  - [x] 根据压力测试结果进行性能调优
  - [x] 修复所有发现的性能问题和Bug
  - [x] 优化前端加载速度、减少包体积
  - [x] 完善系统可观测性（日志、监控）

- [x] 第20天：项目文档与演示准备
  - [x] 编写项目技术方案文档
  - [x] 编写核心模块设计说明
  - [x] 录制双端功能演示视频
  - [x] 准备高并发场景测试演示

- [x] 第21天：最终交付与总结
  - [x] 最终全流程回归测试
  - [x] 代码最终整理与优化
  - [x] 项目整体复盘总结
  - [x] 完成项目交付

**第三周工作重点**：高并发架构优化、极致竞价氛围体验、完整测试覆盖
**第三周工作难点**：高并发下系统稳定性保障、性能瓶颈定位与优化、异常场景全面覆盖

## 任务依赖关系
- 第二周任务依赖第一周任务完成
- 第三周任务依赖第二周核心竞拍功能完成

上下文和对话层：提供清晰提示词和精准上下文

提示词：角色认知 + 业务指标 + 技术选型 + 方案分析

上下文：提供精准相关的代码文件路径

你是一个可观测工程师,能够完成技术选型，接入的闭环流程.
你需要保证:
能够即时观测QPS等网络指标，CPU使用率等系统指标，故障报错等业务指标.
同时对项目侵入性低，带来性能损耗小.

我现在需要完善可观测性:
参考promethus日志采集，grafana可视化；
Elasticsearch检索日志。Logstash日志过滤，kibana可视化；
滴滴的“华佗”--自研并开源的云原生操作系统可观测性项目HUATUO；
云原生监控和报警的利器Nightingale等技术选型

给出方案，方案优缺点

让我先查看一下当前项目的架构，了解一下项目的基本情况，然后为您提供合适的可观测性方案。
        
            
toolName: view_folder
            
status: success
          
d:\douyin
          

        
            
toolName: view_files
            
status: success
          
            
filePath: d:\douyin\doc\抖音电商直播竞拍全栈系统技术方案文档.md
          
完美！我已经了解了项目的架构。现在为您提供完整的可观测性技术选型方案：

---

# 抖音电商直播竞拍系统 - 可观测性技术方案

## 一、系统分析

根据您的项目特点：
- **Go后端** + **高并发** + **实时性**要求高
- **微服务架构**（未来可扩展）
- **MySQL + Redis** 双数据库
- **WebSocket长连接**
- **业务指标**：QPS、出价成功率、在线人数等

---

## 二、技术选型方案对比

### **方案1：Prometheus + Grafana + Loki + Alertmanager（CNCF推荐栈）**

#### 架构设计
```
                    ┌─────────────────────────────────────────────────┐
                    │              指标采集层                          │
                    │  - Prometheus (指标存储)                        │
                    │  - node_exporter (系统指标)                     │
                    │  - mysqld_exporter (MySQL指标)                  │
                    │  - redis_exporter (Redis指标)                   │
                    │  - custom_exporter (Go业务指标)                 │
                    └────────────┬────────────────────────────────────┘
                                 │
                    ┌────────────▼────────────────────────────────────┐
                    │              日志采集层                          │
                    │  - Loki (日志聚合存储)                           │
                    │  - Promtail (日志采集Agent)                     │
                    └────────────┬────────────────────────────────────┘
                                 │
                    ┌────────────▼────────────────────────────────────┐
                    │              可视化报警层                        │
                    │  - Grafana (统一仪表盘)                         │
                    │  - Alertmanager (告警管理)                       │
                    └─────────────────────────────────────────────────┘
```

#### 优点
1. **云原生标准**：CNCF毕业项目，生态最成熟
2. **侵入性低**：Go SDK (`prometheus/client_golang`) 简单易用
3. **性能损耗小**：拉取模式，采样率可调
4. **告警强大**：PromQL灵活查询 + Alertmanager丰富的通知渠道
5. **统一可视化**：Grafana同时支持指标和日志（Loki）
6. **成本低**：完全开源，无商业版授权
7. **Go友好**：原生支持Go语言pprof、trace等

#### 缺点
1. **日志检索能力有限**：Loki不如Elasticsearch强大
2. **时序数据存储成本**：长期存储需要配合VictoriaMetrics等
3. **告警规则配置较复杂**：需要学习PromQL

#### 接入成本
- **开发成本**：1-2周（指标埋点 + 仪表盘配置）
- **运维成本**：中等（Prometheus HA需要维护）

---

### **方案2：Prometheus + Grafana + ELK Stack（经典组合）**

#### 架构设计
```
                    ┌─────────────────────────────────────────────────┐
                    │              指标采集层                          │
                    │  - Prometheus + Exporter生态                    │
                    └────────────┬────────────────────────────────────┘
                                 │
                    ┌────────────▼────────────────────────────────────┐
                    │              日志采集层                          │
                    │  - Elasticsearch (搜索引擎)                     │
                    │  - Logstash (日志过滤清洗)                      │
                    │  - Filebeat (轻量级Agent)                        │
                    └────────────┬────────────────────────────────────┘
                                 │
                    ┌────────────▼────────────────────────────────────┐
                    │              可视化报警层                        │
                    │  - Grafana (指标可视化)                         │
                    │  - Kibana (日志可视化)                          │
                    │  - Alertmanager (告警管理)                       │
                    └─────────────────────────────────────────────────┘
```

#### 优点
1. **日志检索最强**：Elasticsearch全文检索能力业界领先
2. **日志聚合完善**：Logstash强大的ETL能力
3. **生态成熟**：大量现成的仪表盘和告警规则模板
4. **适合复杂业务**：日志分析、链路追踪能力强

#### 缺点
1. **侵入性中等**：需要规范日志格式
2. **资源消耗大**：Elasticsearch内存和CPU消耗较高
3. **运维复杂度高**：ES集群维护需要专业能力
4. **成本较高**：服务器资源投入大

#### 接入成本
- **开发成本**：2-3周（日志规范 + 指标埋点）
- **运维成本**：较高（ES集群运维）

---

### **方案3：Nightingale（夜莺）+ VictoriaMetrics + Loggie（国产开源方案）**

#### 架构设计
```
                    ┌─────────────────────────────────────────────────┐
                    │       采集层 (Categraf)                         │
                    │  - 系统指标 + MySQL + Redis + 自定义Go指标      │
                    └────────────┬────────────────────────────────────┘
                                 │
                    ┌────────────▼────────────────────────────────────┐
                    │       存储层                                    │
                    │  - VictoriaMetrics (指标存储，性能是Prom 3倍)    │
                    │  - Elasticsearch/ClickHouse (日志存储)           │
                    └────────────┬────────────────────────────────────┘
                                 │
                    ┌────────────▼────────────────────────────────────┐
                    │       夜莺核心 (Nightingale)                    │
                    │  - 统一仪表盘 + 告警引擎 + 管理后台              │
                    └─────────────────────────────────────────────────┘
```

#### 优点
1. **国产开源**：中文文档友好，社区活跃（滴滴开源）
2. **性能极致**：VictoriaMetrics相比Prometheus存储节省70%，查询快3倍
3. **统一运维**：一个平台搞定指标、日志、告警，无需Grafana
4. **Go友好**：完美兼容Go生态
5. **成本低**：完全开源，无授权费用
6. **功能全面**：支持告警自愈、机器分组、权限管理等企业级功能

#### 缺点
1. **相对年轻**：相比Prometheus生态，历史较短
2. **日志方案灵活**：需要搭配ELK或ClickHouse
3. **国际化稍弱**：主要面向国内用户

#### 接入成本
- **开发成本**：1-2周（Categraf采集 + 仪表盘配置）
- **运维成本**：低（夜莺部署简单，文档完善）

---

### **方案4：华佗HUATUO（滴滴云原生操作系统）**

#### 架构设计
```
                    ┌─────────────────────────────────────────────────┐
                    │       华佗可观测平台 (HUATUO)                   │
                    │  - 指标监控 + 日志分析 + 链路追踪一体化          │
                    │  - 基于eBPF的无侵入数据采集                     │
                    └────────────┬────────────────────────────────────┘
                                 │
                    ┌────────────▼────────────────────────────────────┐
                    │       存储层                                    │
                    │  - 自研时序数据库 + 搜索引擎                    │
                    └─────────────────────────────────────────────────┘
```

#### 优点
1. **无侵入性**：基于eBPF技术，无需修改代码即可采集指标
2. **一体化**：指标、日志、链路追踪统一平台
3. **云原生**：专为Kubernetes设计
4. **性能损耗小**：eBPF在内核态采集，性能极高

#### 缺点
1. **生产就绪度待验证**：项目较新，大规模生产案例较少
2. **技术门槛高**：eBPF技术栈较深
3. **中文文档**：主要面向国内用户

#### 接入成本
- **开发成本**：低（无侵入，主要是配置）
- **运维成本**：中等（需要熟悉eBPF）

---

## 三、推荐方案（方案3：Nightingale + VictoriaMetrics）

### **推荐理由**
1. **最适合Go项目**：完美契合您的Go后端 + 高并发场景
2. **性能最优**：VictoriaMetrics相比Prometheus性能优势明显
3. **成本最低**：完全开源，无商业授权
4. **运维简单**：一个平台搞定所有监控需求
5. **中文友好**：文档和社区都是中文，上手快

### **具体实施计划**

#### 1. **指标采集**
- **系统指标**：`Categraf` 原生支持CPU、内存、磁盘、网络
- **Go应用指标**：集成 `prometheus/client_golang`
- **MySQL指标**：`Categraf` MySQL插件
- **Redis指标**：`Categraf` Redis插件
- **业务指标**：
  - QPS统计
  - 出价成功率
  - WebSocket在线人数
  - 缓存命中率
  - 竞拍延迟

#### 2. **日志采集**
- **轻量级方案**：使用 `Loggie` 替代Filebeat + Logstash
- **日志存储**：初期使用ELK，后期可切换到ClickHouse
- **日志规范**：统一日志格式为JSON

#### 3. **告警规则配置**
```yaml
# 示例：QPS异常告警
groups:
- name: auction_alerts
  rules:
  - alert: HighQPS
    expr: rate(http_requests_total[1m]) > 1000
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "QPS超过阈值"

  - alert: LowBidSuccessRate
    expr: rate(bid_success_total[5m]) / rate(bid_total[5m]) < 0.95
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "出价成功率低于95%"

  - alert: HighRedisLatency
    expr: histogram_quantile(0.99, rate(redis_commands_duration_seconds_bucket[5m])) > 0.1
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "Redis P99延迟超过100ms"
```

#### 4. **仪表盘设计**
- **系统概览**：CPU、内存、网络、磁盘
- **应用监控**：QPS、P99延迟、错误率
- **业务指标**：出价成功率、在线人数、竞拍热度
- **数据库监控**：MySQL连接数、Redis命中率
- **网络指标**：WebSocket连接数、消息延迟

---

## 四、各方案对比总结

| 评估维度 | 方案1(Prometheus) | 方案2(ELK) | 方案3(Nightingale) | 方案4(华佗) |
|---------|------------------|-----------|-------------------|-----------|
| 侵入性 | 低 | 中 | 低 | 极低 |
| 性能损耗 | 低 | 中 | 低 | 极低 |
| 指标监控 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 日志检索 | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 运维成本 | 中 | 高 | 低 | 中 |
| 成本 | 低 | 中 | 低 | 低 |
| Go友好度 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 中文文档 | 中 | 中 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 推荐指数 | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |

---

## 五、实施建议（分阶段）

### **Phase 1（1-2周）：基础指标监控**
1. 部署 **Nightingale + VictoriaMetrics**
2. 接入系统指标、MySQL、Redis
3. 配置基础告警规则
4. 搭建基础仪表盘

### **Phase 2（2-3周）：业务指标 + 日志**
1. 集成Go业务指标埋点
2. 接入日志采集
3. 配置业务告警
4. 完善业务仪表盘

### **Phase 3（持续优化）：高级功能**
1. 分布式追踪（Jaeger）
2. 告警自愈
3. 性能分析（pprof集成）
4. 容量规划

---

## 六、成本估算

| 项目 | 方案1 | 方案2 | 方案3 | 方案4 |
|------|-------|-------|-------|-------|
| 开发人力 | 2人·周 | 3人·周 | 1.5人·周 | 1人·周 |
| 服务器（月） | ¥2,000 | ¥5,000 | ¥1,500 | ¥1,500 |
| 商业授权 | 0 | 0 | 0 | 0 |
| **首年总成本** | ¥48,000 | ¥96,000 | ¥36,000 | ¥36,000 |

---

## 最终建议

对于您的**抖音电商直播竞拍系统**，我**强烈推荐方案3（Nightingale + VictoriaMetrics）**，因为：

✅ 完美契合Go项目，性能最优  
✅ 运维成本最低，中文文档友好  
✅ 国产开源，社区活跃  
✅ 成本最低，功能最全  

这是一个既能满足当前需求，又能支持未来扩展的最优方案！

调用工具或子agent层：指定合适的工具或子agent名片，明确工具和agent的调用权限

在可观测方案选择任务中，使用zread的mcp，能够利用zread强大的检索能力，快速专业了解开源项目；为可观测选型提供可靠依据

执行流程编排层：提供可靠的流程执行规划，避免死锁

通过DAG作为引擎，Kahn拓扑排序编排任务执行流程，线程池并行任务；安全高效执行任务。

故障检测修复层：实时检出错误并修复

主要通过TDD实现，给定规则生成代码的同时生成代码测试，利用编译器上下文优化生成代码；同时在配置信息任务场景中，让ai根据已给出的测试数据编写代码，提高了ai code的稳定性。

2.4 项目成果

客户端

商家端