# 后续工作计划

> 依据：《蚕病智能防控平台规格说明书》V2.1（2026-08-11，来源 `.cc-connect/attachments/蚕病智能防控平台规格说明书.md`）

## 技术选型决策（2026-08-11 确定）

**采用混合架构：现有 Go 底座 + Python AI 微服务**

- 平台/业务：沿用 `server-go`（Go/Gin/GORM、PostgreSQL、IoTDB、Valkey/Redis、VerneMQ、Ceph S3、WVP+ZLM 等现有能力）
- AI 能力：新建独立 Python 服务 `ai-service/`（FastAPI + ONNX Runtime），承载 YOLO 检测、图像/光谱分析
- 通信：Go 后端 ↔ AI 服务通过 HTTP/gRPC；摄像头流巡检由 AI 服务直接消费 ZLMediaKit 流
- 端侧：农户端微信小程序沿用现有 Taro miniapp；端侧 ONNX 推理作为后续优化项

**部署决策（2026-08-11 确定）：生产环境全部上云，本地仅用于开发/训练/测试**

- 生产：业务云主机 + GPU 云主机（NVIDIA T4 16G）+ 云对象存储（OSS/COS），同地域同 VPC 内网互通
- 本地（开发 VM + fnOS/i7-8700T/Tesla P4 物理机）：仅做代码开发、YOLO 模型训练、数据集处理与功能测试；训练产物（`best.onnx` 等）上传云端部署

## 云部署配置（2026-08-11 确定）

| 资源 | 推荐配置 | 用途 |
|---|---|---|
| 业务云主机 | 8 vCPU / 32GB / 100GB SSD 系统盘 + 500GB SSD 数据盘，10Mbps 起步（视频多则按量），Debian 12 / Ubuntu 22.04，华南或华东 | Go 后端、PostgreSQL、IoTDB、VerneMQ、Valkey、Docker（WVP/ZLM/MySQL/Redis）、recorder-go、前端 |
| GPU 云主机 | NVIDIA T4 16G，8 vCPU / 32GB / 100GB SSD，与业务主机同 VPC | `ai-service`（ONNX Runtime 推理），不承担训练 |
| 云对象存储 | OSS/COS：录像 bucket + 图片 bucket，配置生命周期（录像按保留期转低频/删除） | 替代 Ceph（现有 loop 100GB 容量/性能受限） |
| 网络与入口 | 域名 + HTTPS 证书（小程序合法域名需 ICP 备案）、负载均衡（可选）、CDN（模型/静态资源分发） | 对外访问与端侧模型更新 |
| 数据库 | 优先云 RDS（高可用+自动备份）；成本敏感则业务主机自装 + 每日备份 + 云盘快照 | PostgreSQL 业务数据 |

## 一、前置准备（P0）

- [ ] 1. 修复数据集：按原始图重新划分 train/valid/test（消除 Roboflow 增强副本导致的跨集泄漏）；修正 `data.yaml`（`heathly` → `healthy`、绝对路径）；删除空标签
- [ ] 2. 远程训练服务器（fnOS / i7-8700T / 62G / Tesla P4 8G）搭建环境：venv + PyTorch（cu121/cu124，兼容 P4）+ ultralytics
- [ ] 3. 数据集上传服务器 `/vol1/ai/datasets`
- [ ] 4. YOLOv8s 二分类基线训练（healthy/sick），产出 `best.pt` / `best.onnx` + 指标报告（mAP、混淆矩阵）

## 二、AI 巡检闭环（规格书阶段一，MVP）

- [ ] 5. 新建 `ai-service/`：FastAPI + ONNX Runtime，`POST /detect` 返回框/类别/置信度，部署在 P4 服务器（systemd 或 Docker + nvidia-container-toolkit）
- [ ] 6. Go 后端对接：AI client + AI 巡检记录表（`InspectionRecord`）
- [ ] 7. 蚕房/蚕匾/批次管理：现有蚕房/设备/传感器扩展蚕匾、批次、饲养记录、消毒记录、蚕种来源
- [ ] 8. 农户小程序拍照巡检：拍照→上传→风险分级（绿/黄/橙/红）→预警→记录
- [ ] 9. 风险评分引擎：0–100 分 = 0.5×AI 置信度 + 0.2×环境系数 + 0.15×饲养阶段系数 + 0.15×群体整齐度偏离度
- [ ] 10. 知识库初始版：4 类蚕病症状图谱与防治指南、AI 结果解读
- [ ] 11. 推送：保留 WebSocket，新增微信订阅消息（注意订阅次数限制）

## 三、环境监测 + LAMP 检测（规格书阶段二）

- [ ] 12. 天气数据接入与高发病天气预警规则（白僵病/软化病等触发条件）
- [ ] 13. 饲养阶段风险提示（按龄期提示高发病种）
- [ ] 14. LAMP 检测管理：检测任务单、分步操作引导、拍照判读 + AI 辅助判读、结果录入
- [ ] 15. 交叉验证：AI 结果 vs 检测结果（一致→确认诊断；不一致→升级专家会诊）
- [ ] 16. 耗材管理：库存、低库存预警、批次效期、采购建议
- [ ] 17. 技术员 Web 后台：检测任务处理、耗材、巡检复查（扩展现有 web）

## 四、专家诊断 + 多检测方式 + 疫病溯源（规格书阶段三）

- [ ] 18. 专家会诊：病例打包（照片+AI+检测+环境+饲养+历史趋势）、在线会诊、防控方案下发、归档
- [ ] 19. qPCR/SERS/高光谱接入：Ct 值录入自动判读；SERS 数据回传与光谱库框架；高光谱接口预留
- [ ] 20. 多检测方式推荐引擎（设备条件/紧急程度/成本/操作者水平）
- [ ] 21. 疫病溯源（V2.1 新增）：`TraceRecord` 数据模型；一级自动溯源（首发位置、72h 环境回溯、历史关联、传播途径推断、区域关联→溯源初报）；二级分病种排查清单与报告；三级专家/实验室记录
- [ ] 22. 区域发病热力图（乡镇/县级可视化）
- [ ] 23. 摄像头流 AI 巡检：复用 WVP + ZLMediaKit + recorder-go，AI 服务拉流抽帧检测（建议二期，需补摄像头视角数据）

## 五、数据分析与运维

- [ ] 24. 蚕房健康画像、防控效果评估、年度发病规律
- [ ] 25. 时序存储决策：沿用 IoTDB 或按规格书引入 TDengine（不阻塞 MVP）
- [ ] 26. AI 服务部署与 GPU 监控（P4 温度/显存）
- [ ] 27. 测试基建：后端 `go test` 骨架、前端 Vitest（建议，可延后）

## 依赖关系

```text
数据/环境(1-4) → AI 服务(5) → 拍照巡检(6-11)          [阶段一]
                      ↓
环境+LAMP(12-17) → 专家会诊(18) → 疫病溯源(21)        [阶段二→三]
                      ↓
摄像头流巡检(23) + 数据分析(24)                       [阶段三→四]
```

## 待决策事项

- [ ] 时序数据库：IoTDB（现状）还是 TDengine（规格书）
- [ ] 数据集病种扩展：由二分类（healthy/sick）扩展为 7 类病种标注（影响 AI 巡检与溯源联动）
- [x] AI 服务部署形态：已定——云 GPU 主机（T4 16G），容器化部署
- [x] 对象存储：已定——云 OSS/COS，替代 Ceph