silk/项目现状与规格说明书优化分析.md

# 智慧蚕房项目现状与《蚕病智能防控平台规格说明书》优化分析

> 分析日期：2026-08-13  
> 分析对象：当前仓库、`.cc-connect/attachments/蚕病智能防控平台规格说明书.md`（V2.1）、`README.md`、`后续工作计划.md`、`开发交接记录.md` 及各端核心源码  
> 结论属性：基于当前代码与本地验证结果的阶段性评审，不等同于生产安全审计、算法效果验收或领域专家医学/检疫结论

## 1. 执行摘要

### 1.1 总体结论

项目已经从单纯的环境监控系统扩展为覆盖环境监测、设备控制、视频、AI 拍照巡检、分子检测、专家会诊、知识库、疫病溯源和区域统计的多端平台，功能广度较高，Go 后端的模块化和 RBAC 基础也已形成。

但当前仍应定义为“功能演示与试点验证阶段”，不宜直接按规格书 V2.1 宣称核心目标全部完成或进入生产验收，主要原因如下：

1. **规格书已落后于实现架构。** 规格书写的是 Vue3 + Python/FastAPI 主后端 + TDengine + MinIO + MobileNet/SSD + 端侧推理；仓库实际是 React + Go/Gin 主后端 + Python AI 微服务 + IoTDB + Ceph/规划中的云对象存储 + YOLOv8 ONNX + 云端推理。
2. **“完成”状态混入了骨架、mock、手工录入和接口预留。** 例如真实 AI 模型尚未接入，摄像头巡检只有抽帧接口骨架，高光谱只有类型预留，微信和天气依赖真实凭证，SERS/qPCR 主要是录入与文件上传，不是设备闭环。
3. **存在必须先处理的安全与业务正确性问题。** 包括仓库内可用的默认密钥/口令、公开的视频流接口、摄像头口令随 API 返回、WebSocket 越权面，以及风险分把“健康类别的高置信度”误当作“高患病概率”。
4. **工程质量与目标态不匹配。** 数据库依赖 AutoMigrate 且忽略迁移错误；通知、令牌黑名单和部分运行状态保存在单机内存；缺少 CI、端到端/负载/安全测试和可观测性闭环。
5. **规格书的验收标准不足以约束研发。** 缺少需求编号、实现状态、接口 schema、异常流程、数据质量、算法数据集切分规则、模型版本治理、RTO/RPO、审计与隐私边界。

### 1.2 建议的总体策略

建议按以下顺序推进，而不是继续横向增加功能：

1. **先止血：** 修复安全暴露、风险评分语义、qPCR 判读边界和小程序类型错误。
2. **再校准：** 发布规格书 V2.2，把“目标态、当前态、验收态”分开，建立需求—代码—测试追踪矩阵。
3. **补闭环：** 完成自动检测任务、离线同步、消毒与种源链、可靠消息、模型/数据治理。
4. **后扩展：** 再投入固定摄像头巡检、LAMP 图像判读、区域流行病学、数字孪生和多模态早期预警。

## 2. 分析范围、方法与限制

### 2.1 已检查的主要证据

- 规格与规划：规格说明书 V2.1、`后续工作计划.md`、`README.md`、`开发交接记录.md`、部署与故障排查文档。
- 后端：路由注册、认证与权限、配置、数据库模型与迁移、巡检、风险评分、分子检测、溯源、视频、WebSocket、通知和 AI 客户端。
- 前端：Web、微信小程序、React Native APP 的页面/API 结构、依赖、脚本与测试配置。
- AI 服务：FastAPI 接口、mock/ONNX 检测器、流抽帧骨架、指标接口和测试。
- 本地验证：Go 测试与 vet、Web 测试与 lint、AI pytest、APP 脚本、小程序 TypeScript 检查。

### 2.2 证据限制

- 项目要求优先使用 codebase-memory 知识图谱，但本会话未提供 `search_graph`、`trace_path`、`check_index_coverage` 等接口，因此本次按项目约定退回到目标源码读取和精确文本检索。
- 未连接开发服务器、数据库、IoTDB、MQTT、WVP/ZLM、Ceph、微信、天气服务或真实 GPU 模型，不能把本地静态检查当成联调或生产验收。
- 未执行依赖漏洞数据库扫描、渗透测试、负载测试、恢复演练和算法数据集审计。

## 3. 当前项目能力画像

| 模块 | 当前状态 | 已具备能力 | 关键缺口 |
|---|---|---|---|
| 环境监测与设备控制 | 可用基础较完整 | MQTT、IoTDB/PG 降级、阈值告警、设备控制、WebSocket | 数据新鲜度与质量标识不足；设备级授权不足；缺少校准/维护计划 |
| 视频监控 | 基础可用 | GB28181/WVP/ZLM、直播、录像、告警片段 | 视频流公开；摄像头密钥返回；运行状态部分内存化；代理超时与并发治理不足 |
| AI 拍照巡检 | **骨架/联调态** | 图片上传、AI HTTP 接口、记录、风险分级、幂等 | 默认 mock；真实模型未验收；非端侧推理；风险概率语义错误；无整齐度数据；无离线队列 |
| 蚕匾/批次/饲养 | 部分可用 | Tray/Batch/RearingRecord CRUD | 缺消毒记录、蚕种来源链、死亡/淘汰/产量、样本链路和二维码身份 |
| 天气与阶段风险 | 骨架可用 | 天气接口、定时规则、阶段提示 | 真实凭证缺失；连续 3 天等时窗规则未完整实现；规则版本不可追踪 |
| LAMP/qPCR/SERS/高光谱 | 流程录入态 | LAMP 任务与步骤、结果照片、Ct 判读、光谱上传、推荐规则 | LAMP AI 判读未做；设备自动回传未做；qPCR 对照/无效态不足；高光谱仅预留 |
| 专家会诊 | 表单流程可用 | 病例快照、状态流转、方案归档 | 无实时协作、SLA/排班、消息可靠性、专家签名与版本留痕 |
| 疫病溯源 | v1 规则态 | 环境回溯、同房间历史、排查清单、区域/月度统计 | 缺独立发病事件模型、空间传播、样本/种源链、三级实验室结构化数据 |
| 知识库 | 基础可用 | 病种、文章、阶段提示、图片上传 | 内容证据等级、审核发布、版本、专家经验沉淀和素材质量不足 |
| 数据分析 | 初版可用 | 健康画像、月度统计、区域柱/饼图 | 健康分未经验证；缺处置效果、损失/成本、地图、队列趋势和数据导出 |
| 多端体验 | 不一致 | Web 功能最全，小程序覆盖核心现场流程，APP 覆盖环境监控 | APP 未同步蚕病功能；小程序离线能力未实现；测试覆盖严重不均衡 |

## 4. 规格说明书 V2.1 需要优化的地方

### 4.1 先解决“目标架构与实际架构冲突”

规格书第 5、6 章与当前仓库有多处直接冲突：

| 主题 | 规格书 V2.1 | 当前项目/已作决策 | V2.2 建议 |
|---|---|---|---|
| Web 技术 | Vue3 + Element Plus | React + Ant Design | 改为 React 现状；若保留 Vue 只作为已否决方案写入 ADR |
| 主后端 | Python + FastAPI | Go/Gin/GORM 主业务 + FastAPI AI 微服务 | 明确混合架构及服务边界 |
| 时序库 | TDengine | MVP 沿用 IoTDB，PG 降级；TDengine 是候选 | 写明当前决定、切换触发条件和迁移策略 |
| 对象存储 | MinIO 本地 | 当前 Ceph S3；生产规划 OSS/COS | 区分开发现状和生产目标态 |
| AI 模型 | SSD-MobileNet + MobileNetV3 | YOLOv8s 二分类路线，ONNX 服务端推理 | 以当前训练路线为基线，旧路线进入备选/历史决策 |
| 推理位置 | 小程序端侧优先 | 当前图片上传到 Go，再调用 AI 服务 | 端侧推理改为后续能力，补模型兼容与更新机制后再验收 |
| 消息队列 | Redis + Celery | Go 定时协程/异步 goroutine，通知部分内存存储 | 写清当前无可靠任务队列，不应宣称已有 |

建议新增“架构决策记录”附录，至少记录：混合后端、IoTDB 延续、云对象存储、云 GPU、YOLO 路线、端侧推理延期。每项包含决策日期、备选方案、理由、影响和复审条件。

### 4.2 给每条需求增加可追踪标识

当前功能表只有名称和 P0/P1/P2，无法稳定映射代码、接口和测试。建议使用如下结构：

| 字段 | 示例 |
|---|---|
| 需求 ID | `AI-INS-001` |
| 用户故事/目的 | 农户上传巡检图后获得可解释的风险结果 |
| 前置条件 | 已登录、有 `inspection:create`、房间存在 |
| 正常流程 | 上传—存储—推理—评分—落库—通知 |
| 异常流程 | 图片无效、存储失败、AI 超时、重复请求、离线待同步 |
| 输入/输出 | 字段、类型、枚举、单位、范围、样例 |
| 权限与数据范围 | 角色权限 + 组织/区域/房间范围 |
| 验收标准 | 可自动测试的 Given/When/Then |
| 当前状态 | 未开始/骨架/mock/手工录入/部分可用/可验收/已验证 |
| 证据 | API、页面、测试、监控、发布记录 |

`后续工作计划.md` 中不应再用一个勾选框同时表达“骨架完成”和“功能完成”。建议采用上述七态模型，并增加“真实依赖是否已联调”字段。

### 4.3 重写 AI 验收标准

“准确率 ≥80%”不足以约束蚕病筛查系统，尤其在健康样本远多于患病样本时会产生虚高结果。V2.2 至少应规定：

- 按养殖场、批次、拍摄日期或原始图分组切分 train/validation/test，增强副本不得跨集合。
- 同时报告每类 precision、recall、F1、混淆矩阵、PR-AUC、漏诊率和置信度校准；核心筛查以患病召回率和漏诊率优先。
- 测试集版本、数据来源、设备型号、光照、龄期、季节、病种确诊依据必须可追溯。
- 明确“healthy/sick 二分类基线”和“7 类病种模型”是两个验收阶段，不能用二分类结果替代病种分类完成度。
- 明确模型版本、阈值、标签集、训练代码版本、ONNX 校验结果、回滚版本和灰度范围。
- 对 mock、研究原型和生产模型的 UI 标识做强制要求，禁止 mock 结果被误当成诊断数据。

### 4.4 修订风险评分定义

规格书把“AI 识别置信度”直接写入公式，但没有定义它是健康置信度、异常概率、最大病种概率还是校准后的风险概率。当前实现因此出现实际逻辑错误：`healthy=0.95` 也会贡献 47.5 分。

建议 V2.2 改为：

```text
AI 异常风险 = P(sick) 或所有异常病种校准概率之和
综合风险 = f(AI 异常风险, 环境规则, 龄期, 群体整齐度, 数据新鲜度, 缺失标记)
```

并补充以下规则：

- 健康类别高置信度必须降低风险，而不是提升风险。
- 数据缺失不能简单当作 0；应返回 `unknown`/低可信度并显示缺失原因。
- 环境数据必须带采集时间，过期数据不能参与实时评分。
- 每次评分保存输入快照、规则版本、模型版本和解释项，便于复盘与审计。
- 风险阈值应通过试点数据校准；规格书使用闭合区间，消除 30～31 等边界歧义。
- 风险评分只触发“建议动作”，涉及隔离、消毒或设备自动控制时必须配置人工确认和安全上限。

### 4.5 修订分子检测规格

当前 qPCR 实现把“没有 Ct 值”判为阴性，规格书也没有定义阳性对照、阴性对照、内参、重复孔和无效实验。建议：

- 结果枚举至少包含 `positive`、`negative`、`invalid`、`indeterminate`。
- 只有对照有效且目标未扩增时才能判阴性；缺失 Ct、内参失败、曲线异常应判无效或待复核。
- Ct 阈值应绑定试剂盒/靶标/仪器/实验方案版本，不能使用全局固定 35 作为通用事实。
- LAMP 增加空白对照、阳性对照、反应温度/时长、试剂批次和操作员记录。
- SERS/高光谱必须区分“文件上传成功”“算法分析完成”“方法学验证通过”三个阶段。
- 增加样本编号、采样对象、采样位置、采样时间、运输条件、接收人和流转记录，形成样本链路。

### 4.6 完善数据模型与数据治理

规格书第 5.1 章包含 `DiseaseRecord`，当前模型没有独立的发病事件实体，TraceRecord 直接关联房间、LAMP 和会诊，导致“确诊事件—处置—损失—复发—溯源”难以形成稳定主线。

建议核心链路调整为：

```text
组织/养殖场 → 蚕房 → 蚕匾 → 饲养批次
                         ├─ 日常记录/消毒记录/投入品记录
                         ├─ 巡检事件 → 检测任务 → 样本 → 检测结果
                         └─ 发病事件 → 处置措施 → 会诊 → 溯源 → 效果评估
```

同时补充：

- 数据所有者、组织/区域数据隔离、保留期限、删除/匿名化规则。
- 图片、视频、光谱、模型训练数据的授权用途和导出控制。
- 数据字典：单位、枚举、空值语义、时间时区、来源和质量标识。
- 规则、知识文章、专家结论和模型输出的版本与审核状态。
- 训练数据从业务数据进入标注集的审批、脱敏、质检和撤回流程。

### 4.7 扩展接口设计

第 8 章目前只有协议级概述，不能直接用于联调。建议单独维护 OpenAPI 文档，并在规格书中定义：

- 统一响应与错误码、分页、排序、过滤、幂等、并发更新版本号。
- 请求/响应 schema、枚举、单位、最大文件大小和示例。
- 鉴权方式、权限码、组织/房间数据范围和审计事件。
- 外部设备的签名、重放保护、时间戳、设备身份、重试与死信策略。
- AI、天气、微信、WVP、对象存储等依赖的超时、熔断、降级和补偿行为。
- API 版本兼容、废弃策略和客户端最低版本。

### 4.8 扩展非功能性需求

V2.1 只有少量性能、可用性和安全条目。建议增加：

| 类别 | 必须补充的内容 |
|---|---|
| 可用性 | SLI/SLO、依赖降级、维护窗口、故障演练、单点清单 |
| 灾备 | RPO、RTO、备份保留、异地副本、季度恢复演练和恢复验收 |
| 性能 | 明确数据量、并发模型、p95/p99、冷/热缓存、视频与图片带宽 |
| 安全 | 密钥管理、强制改密、最小权限、对象级授权、文件扫描、审计保留 |
| 隐私 | 个人信息清单、处理目的、最小收集、脱敏、导出/删除流程 |
| 可观测性 | 请求 ID、结构化日志、指标、追踪、业务告警、模型与数据漂移 |
| 兼容性 | 微信基础库、Android/iOS、浏览器、弱网和低端设备矩阵 |
| 可维护性 | 版本化数据库迁移、CI 质量门禁、依赖升级、配置校验和回滚 |
| AI 治理 | 模型卡、数据卡、版本、阈值、灰度、回滚、人工复核和申诉机制 |

### 4.9 给技术与产业数据增加来源等级

规格书包含准确率、设备价格、单次成本、研究年份、传播周期和推广事件等具体陈述，但没有参考文献或采集日期。建议每条事实标注：来源链接/文献、发布日期、访问日期、证据等级、适用范围和是否经领域专家确认。价格与产业状态应设有效期，避免长期成为“固定事实”。

## 5. 当前项目问题清单

### 5.1 P0：发布前必须处理

#### P0-1 风险评分把健康置信度当患病概率

- 证据：`server-go/internal/handler/inspection.go` 取所有 detection 的最大 `confidence`；`server-go/internal/service/risk.go` 将其作为 AI 风险直接加权。
- 影响：mock 默认返回 `healthy=0.95`，仅 AI 项即为 47.5 分，产生黄色预警；真实二分类模型同样可能把“非常健康”算成高风险。健康画像、微信推送、统计和溯源触发都会被污染。
- 方案：AI 响应增加类别概率或明确的 `abnormalProbability`；风险层只消费异常概率；增加 healthy 高置信度、sick 高置信度、多框混合、无检测和模型失败测试；修复前隔离 mock 数据或增加 `isMock` 标识。

#### P0-2 仓库内存在可直接使用的默认密钥与口令

- 证据：`server-go/internal/config/config.go` 内含数据库、Redis、MQTT、S3、ZLM、内部 API、JWT 和管理员默认值；小程序和 APP 登录页预填默认管理员密码。
- 影响：环境变量漏配时系统会以已知凭据启动；历史凭据可能已进入部署环境；客户端预填进一步放大弱口令风险。
- 方案：敏感配置改为生产环境必填并在启动时校验；默认只允许显式的本地开发 profile；轮换所有已提交过的密钥；管理员首次启动一次性初始化并强制改密；客户端不预填密码。

#### P0-3 视频流绕过 JWT，摄像头与 SIP 密码可被 API 返回

- 证据：`server-go/internal/middleware/auth.go` 放行录像流和直播流；`server-go/internal/handler/video_stream.go` 明确注册为公开接口；`Camera.PasswordEnc`、`Camera.GbAuthPassword` 有 JSON 字段，列表/详情直接返回模型；WVP 配置接口返回 `sipPassword`。
- 影响：知道或枚举 ID 即可能观看录像/直播；拥有普通 `video:read` 的用户可获得摄像头/SIP 凭据，造成隐私、设备接管和横向移动风险。
- 方案：恢复 JWT 与对象级授权，或使用短时签名 URL/一次性播放令牌；所有密钥字段 `json:"-"` 并使用专门 DTO；WVP 配置接口只返回硬件配置所需的非敏感信息；审计所有播放和凭据操作。

#### P0-4 数据库迁移失败不阻断启动

- 证据：`server-go/internal/database/db.go` 使用 `AutoMigrate`，错误被记录为“可忽略”后继续启动。
- 影响：代码与 schema 不一致时服务仍对外提供 API，可能在运行期丢字段、写入失败或产生半迁移状态。
- 方案：引入可回滚、可审计的版本化迁移；生产禁止自动迁移；启动前检查 schema 版本，不一致则失败；备份与迁移验收进入发布门禁。具体迁移工具需在实施前确认。

#### P0-5 小程序当前 TypeScript 检查失败

- 证据：`miniapp/src/pages/dashboard/index.tsx:288` 和 `:350` 的 JSX 文本包含未转义 `>`，`npx tsc --noEmit` 返回 TS1382。
- 影响：类型质量门禁无法通过，不同编译器/升级版本下可能阻断构建。
- 方案：使用 `{'>'}`、`>` 或统一箭头图标；把 `tsc --noEmit` 加入小程序 CI。

#### P0-6 qPCR “无 Ct 即阴性”存在错误判读风险

- 证据：`server-go/internal/model/molecular.go` 在 Ct 数组为空时直接返回 negative。
- 影响：缺数据、实验失败、内参失败或未录入都可能被误记为阴性，影响交叉验证和防控决策。
- 方案：增加对照与内参字段以及 invalid/indeterminate 状态；判读规则按试剂/靶标版本配置并由领域专家审核。

### 5.2 P1：进入稳定试点前处理

#### P1-1 WebSocket 缺少来源和对象级授权

- `CheckOrigin` 始终返回 true；JWT 可经 query 传输，可能进入代理日志；任意已登录用户可订阅任意 `deviceKey`，并收到全局 `telemetry.all` 和设备状态。
- 建议限制 Origin，优先使用安全握手/短时票据，按用户可访问的组织/房间/设备校验订阅，并停止无范围的全局广播。

#### P1-2 ai-service 的流接口存在 SSRF 和阻塞风险

- `/stream-detect` 接受任意 URL，服务端直接 `VideoCapture`；异步路由中执行同步视频 I/O；无来源白名单、私网地址限制、帧尺寸/时长/并发限制和服务认证。
- 建议禁止客户端直接传任意 URL，改传 `cameraId/taskId`，由 Go 后端解析授权后的内部流；用任务队列和 worker 执行，设置超时、并发、帧率和资源配额；AI 服务只允许 VPC 内认证调用。

#### P1-3 消息、吊销和任务状态不持久

- 通知列表、JWT 吊销、登录限流和活跃录制包含单机内存状态；重启或多实例会丢失/不一致。
- 建议把需要跨实例一致性的状态迁移到 Redis/数据库；通知采用 outbox + 重试 + 状态机；业务写入和事件产生保持可追踪。

#### P1-4 规格动作没有自动形成闭环

- 规格书要求橙灯自动生成分子检测任务、红灯触发专家会诊；当前巡检代码主要做评分、记录和微信推送，没有自动创建 LAMP/DetectionTask 或 Consultation。
- 建议新增统一 `DetectionTask`，把“推荐方式”和“实际执行方式”分开；事件处理必须幂等；自动触发后允许技术员确认、改派和取消，并记录原因。

#### P1-5 环境风险规则被过度简化

- 当前只读取最新温湿度，未完整实现连续 3 天高湿、温度突变窗口、通风、桑叶潮湿、蚕头密度、消毒和种源条件；缺失数据被当成 0 风险。
- 建议建立带时间窗和版本的规则引擎，输入包含来源、时间和质量；规则输出保存命中条件和缺失项。

#### P1-6 缺少正式的发病事件、消毒与种源链

- 当前 TraceRecord 不是完整 DiseaseEvent；批次虽有来源字段，但没有供应商/蚕种批号/检疫证/跨批次链路，也没有消毒计划、执行、药剂、浓度和复核。
- 建议优先补齐这些基础数据，否则微粒子病追溯、内源/外源判断和防控效果评估缺少可信输入。

#### P1-7 多端功能与测试不均衡

- Web 有 1 个测试文件、3 个测试；APP 和小程序未发现测试文件；APP 当前本机缺少 TypeScript/ESLint 可执行依赖，无法验证；AI 本机缺 FastAPI/Pillow，pytest 无法收集。
- 建议先覆盖风险评分、权限、上传、离线同步、检测判读和核心用户流程；建立统一依赖安装与 CI，输出可复现的测试报告。

#### P1-8 缺少生产级可观测性和容量证据

- AI `/metrics` 是自定义 JSON，不是统一指标系统；未发现请求追踪、错误聚合、SLO 看板、告警规则或容量测试证据。
- 建议建立 API、数据库、MQTT、IoTDB、对象存储、视频、AI、微信/天气依赖和业务闭环指标；进行 500/1000 用户目标下的负载模型验证。

### 5.3 P2：中期优化

- 拆分过长的 handler/page，减少业务规则散落在 HTTP 层和大页面中。
- 查询统一分页与总数，修复无上限 telemetry limit、N+1/全表辅助查询和批量导出能力。
- 将健康画像从人工扣分公式升级为可解释、可回测、可版本化的指标体系。
- 建立知识内容审核、发布、撤回、引用来源和专家签名。
- 统一 APP、小程序、Web 的接口类型与枚举，降低多端漂移。
- 清理仓库中的编译二进制、压缩包等大文件，制定制品仓库和 Git LFS 策略。

## 6. 优化方案与实施路线图

### 阶段 A：0～2 周，安全与正确性基线

| 交付物 | 验收结果 |
|---|---|
| 风险评分语义修复 | healthy 高置信度不升风险；异常概率、模型版本、mock 标识可追踪；回归测试通过 |
| 密钥与管理员治理 | 生产缺关键配置时拒绝启动；历史凭据完成轮换；客户端无默认密码 |
| 视频与摄像头安全 | 未授权用户无法访问流；API 不返回任何摄像头/SIP 密钥；播放行为有审计 |
| qPCR 判读修订 | 支持无效/不确定；对照失败不能判阴性；规则有版本 |
| 构建恢复 | Go test/vet、Web test/lint、小程序 typecheck、APP typecheck/lint、AI pytest 均可复现 |

### 阶段 B：2～6 周，工程化与规格校准

| 交付物 | 验收结果 |
|---|---|
| 规格书 V2.2 | 架构与仓库一致；需求有 ID、状态、验收和证据；无“骨架=完成” |
| 版本化数据库迁移 | 新环境可从 0 部署；升级/回滚演练通过；schema 不一致拒绝启动 |
| CI 质量门禁 | 多模块静态检查、单测、构建、密钥扫描和制品输出自动执行 |
| 可靠事件机制 | 巡检—检测任务—通知幂等；失败可重试；状态可查询；重启不丢失 |
| 可观测性基线 | 请求 ID、结构化日志、核心指标、错误告警和依赖健康可统一查看 |

### 阶段 C：1～3 个月，补齐可用 MVP 闭环

- 自动检测任务和专家升级规则。
- 小程序离线巡检、断点上传、冲突处理和同步状态可视化。
- 消毒记录、种源链、样本链和发病事件。
- LAMP 对照与流程质控、qPCR 结构化结果、SERS 数据标准。
- 区域/房间/设备级数据权限和专家 SLA。
- 处置措施、复查结果和防控效果评估。

### 阶段 D：3～6 个月，真实模型与规模化试点

- 修复数据集泄漏，完成二分类基线，再决定是否进入 7 类模型。
- 建立数据卡、模型卡、标注复核、灰度、漂移监测和回滚。
- 在真实农户、设备、网络和季节条件下试点；以漏诊、误报、任务完成率、响应时间和损失改善评估价值。
- 完成云环境的备份恢复、容量、弱网、故障注入和安全测试。

### 阶段 E：6 个月以后，研究型能力

- 固定摄像头巡检任务编排和群体整齐度模型。
- LAMP 显色图像辅助判读。
- SERS/高光谱方法学验证与数据集建设。
- 区域传播模型、聚集性异常检测和跨年复发分析。
- 在人工确认、安全约束和回滚机制下探索环境控制数字孪生。

## 7. 建议新增的功能

### 7.1 高价值、应优先增加

| 功能 | 价值 | 复杂度 | 建议阶段 |
|---|---|---|---|
| 蚕匾/批次/样本二维码 | 串联巡检、采样、检测、处置和溯源，减少手工选错对象 | 中 | 阶段 C |
| 消毒与生物安全管理 | 为内源复发判断提供核心数据，可形成计划、执行和复核闭环 | 中 | 阶段 C |
| 蚕种来源与检疫链 | 支撑微粒子病和跨批次追溯 | 中高 | 阶段 C |
| 检测任务中心 | 统一 LAMP/qPCR/SERS/高光谱的派单、SLA、样本和结果 | 中 | 阶段 C |
| 防控措施效果评估 | 对比处置前后风险、阳性率、损失和复发，回答“措施是否有效” | 中 | 阶段 C/D |
| 离线工作台 | 弱网下完成拍照、记录、采样和任务，联网后可靠同步 | 高 | 阶段 C |
| 数据/模型质量工作台 | 标注、复核、难例、漂移、版本和回滚 | 高 | 阶段 D |

### 7.2 规模化运营能力

- **多组织/合作社/区域管理：** 组织、养殖场、人员、数据范围和跨区域脱敏统计。
- **专家排班与会诊 SLA：** 自动分派、超时升级、意见模板、签名、复诊和工作量统计。
- **设备资产与校准：** 传感器校准、摄像头维护、试剂设备保养、固件与故障工单。
- **库存批次追溯：** 试剂批号、供应商、入库、领用、报废、温控和召回。
- **经营损失与成本分析：** 死亡率、淘汰量、蚕茧产量、用药/消毒/检测成本和投资回报。
- **数据导出与监管报表：** 按权限脱敏导出，生成区域疫情、检疫、消毒和处置报表。
- **适老化/乡村 UX：** 大字号、语音播报、图片化操作、方言/普通话提示和一步式上报。

### 7.3 创新与研究功能

- **主动学习：** 自动挑选低置信度、模型分歧和专家纠正样本进入标注队列。
- **多模态异常检测：** 图像、环境、活动度、声音、摄食和历史共同判断群体异常。
- **传播网络与聚集性预警：** 结合种源、人员/工具流转和空间关系识别可能传播链。
- **数字孪生与安全控制建议：** 模拟通风、温湿度和密度调整的影响，只输出受约束建议，关键动作由人确认。
- **分子分型/实验室接口：** 将三级溯源从自由文本升级为结构化分型、环境采样和实验室报告。
- **跨季节风险基线：** 建立不同地区、品种、龄期和季节的正常范围，降低统一阈值误报。

## 8. 建议的规格书 V2.2 目录

1. 文档控制、范围、术语与参考资料  
2. 产品目标、非目标、用户角色与业务边界  
3. 当前态、目标态和部署拓扑  
4. 核心业务流程与异常/补偿流程  
5. 带 ID 的功能需求  
6. 数据模型、数据字典、数据治理与保留策略  
7. API、事件、设备和外部系统契约  
8. AI 数据、训练、评估、推理和模型治理  
9. 权限、隐私、安全与审计  
10. 性能、可用性、灾备、可观测性和兼容性  
11. 分阶段范围、依赖、退出条件与验收矩阵  
12. 风险清单、假设、开放决策和 ADR 索引  
13. 蚕病领域知识附录与证据来源  
14. 需求—实现—测试—发布追踪矩阵

建议把 1000 行以上的现有规格书拆为“产品/系统规格主文档 + 蚕病知识附录 + API 文档 + 数据字典 + AI 模型与数据规范 + 验收矩阵”，减少科学资料、产品需求和具体技术实现互相覆盖。

## 9. 验证结果

| 检查 | 结果 | 说明 |
|---|---|---|
| `server-go: go test ./...` | 通过 | handler/model/service 测试通过，其余多个包无测试文件 |
| `server-go: go vet ./...` | 通过 | 与 go test 同一命令链执行完成 |
| `web: npm test` | 通过 | 1 个测试文件，3 个测试通过 |
| `web: npm run lint` | 通过但有 5 个 warning | 包含 hooks 依赖、缺 key 和 fast-refresh 警告 |
| `ai-service: python -m pytest -q` | 未执行成功 | 当前 Python 环境缺 `fastapi`、`Pillow`，测试收集失败 |
| `app: npm run tsc / npm run lint` | 未执行成功 | 当前目录缺可执行 `tsc`、`eslint`，说明依赖环境不完整 |
| `miniapp: npx tsc --noEmit` | 失败 | dashboard 两处 TS1382 |
| Git 工作区 | 分析前后均无意外生成物修改 | 本文档与交接记录除外 |

## 10. 最终建议

本项目下一阶段最有价值的工作不是继续扩充菜单，而是把“可信、可追踪、可恢复”补齐。建议把以下四项作为下一迭代唯一 P0：

1. 修复风险评分和 qPCR 判读，隔离不可信历史数据。
2. 收口视频、密钥、WebSocket 和 AI 服务的安全边界。
3. 发布与真实架构一致的规格书 V2.2 和追踪矩阵。
4. 建立版本化迁移、CI、可靠任务/通知和基础可观测性。

完成这些之后，再以“二维码样本链 + 消毒/种源链 + 自动检测任务 + 离线工作台”为首个业务增强包，能够显著提高现有功能之间的闭环程度，并为后续真实 AI 模型、区域流行病学和科研合作提供可信数据底座。