silk/后续工作计划.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（建议，可延后）

依赖关系

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

待决策事项

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