From a55d5afb8ae76d7e6aee14b45566912892b51bb6 Mon Sep 17 00:00:00 2001
From: weijuesen <weijuesen.gx@chinatelecom.cn>
Date: Tue, 11 Aug 2026 20:41:31 +0800
Subject: [PATCH] =?UTF-8?q?docs:=20=E6=96=B0=E5=A2=9E=E5=90=8E=E7=BB=AD?=
 =?UTF-8?q?=E5=B7=A5=E4=BD=9C=E8=AE=A1=E5=88=92=EF=BC=88=E6=B7=B7=E5=90=88?=
 =?UTF-8?q?=E6=9E=B6=E6=9E=84=E5=86=B3=E7=AD=96=EF=BC=89=E5=B9=B6=E6=9B=B4?=
 =?UTF-8?q?=E6=96=B0=20AGENTS.md?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 AGENTS.md       |  4 ++-
 后续工作计划.md | 70 +++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 73 insertions(+), 1 deletion(-)
 create mode 100644 后续工作计划.md

diff --git a/AGENTS.md b/AGENTS.md
index e4f8844..7b61735 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -17,7 +17,8 @@
 3. `app/` — React Native 移动端（RN 0.74），后端地址通过 `.env` 配置（参考 `.env.example` 的 `API_BASE_URL`）。
 4. `miniapp/` — 微信小程序（Taro 4 + React + TypeScript + Sass）；`project.config.json` 的 `miniprogramRoot` 指向 `dist/`，该目录是 Taro 构建产物，不得手改。
 5. `wvp/` — WVP-PRO + ZLMediaKit 视频平台（`docker-compose.yml` 包含 WVP、ZLMediaKit、MySQL、Redis），并含 `recorder-go`（Go 连续录制服务，默认 :9090）与 Dockerfile。
-6. 根目录文档 — `README.md`、`部署指南(物理机).md`、`变更记录.md`、`故障排查处理记录.md`、`物联网设备接口和数据格式.md` 等为项目说明与部署运维依据。
+6. 根目录文档 — `README.md`、`部署指南(物理机).md`、`变更记录.md`、`故障排查处理记录.md`、`物联网设备接口和数据格式.md`、`后续工作计划.md`（规格书 V2.1 的工作清单与技术选型决策）等为项目说明、规划与部署运维依据。
+7. `ai-service/`（规划中）— Python FastAPI + ONNX Runtime AI 推理微服务（YOLO 蚕病检测、图像/光谱分析），独立部署于 Tesla P4 GPU 服务器，与 Go 后端通过 HTTP/gRPC 通信；技术方向为「现有 Go 底座 + Python AI 微服务」混合架构，详细规划见 `后续工作计划.md`。
 
 生成文件及其来源命令：
 
@@ -46,6 +47,7 @@
 6. 选择未明确指定的技术栈、包管理器、数据库、运行时、部署目标或外部服务前，必须先获得用户确认。
 7. 初始化项目时，如果技术栈尚未明确，应先让用户选择技术栈，再创建项目文件。
 8. 不得将密钥写入需要提交的文件；需要环境配置时使用占位值创建 `.env.example`。
+9. AI 推理服务（规划中）：Python 3.11 + 虚拟环境，PyTorch（cu121/cu124 wheel，兼容 Tesla P4）+ ultralytics；训练与推理在远程 fnOS 服务器（i7-8700T / 62G / Tesla P4 8G）上进行，模型导出 ONNX 后由 FastAPI 服务加载；数据集路径 `/vol1/ai/datasets`。
 
 ## 验证
 
diff --git a/后续工作计划.md b/后续工作计划.md
new file mode 100644
index 0000000..ba0d7ff
--- /dev/null
+++ b/后续工作计划.md
@@ -0,0 +1,70 @@
+# 后续工作计划
+
+> 依据：《蚕病智能防控平台规格说明书》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 检测、图像/光谱分析，部署于 Tesla P4 GPU 服务器
+- 通信：Go 后端 ↔ AI 服务通过 HTTP/gRPC；摄像头流巡检由 AI 服务直接消费 ZLMediaKit 流
+- 端侧：农户端微信小程序沿用现有 Taro miniapp；端侧 ONNX 推理作为后续优化项
+
+## 一、前置准备（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 巡检与溯源联动）
+- [ ] AI 服务部署形态：Docker（nvidia-container-toolkit）还是 systemd 裸进程