weijuesen
30 KiB
30 KiB
智慧蚕房项目现状与《蚕病智能防控平台规格说明书》优化分析
分析日期：2026-08-13
分析对象：当前仓库、.cc-connect/attachments/蚕病智能防控平台规格说明书.md（V2.1）、README.md、后续工作计划.md、开发交接记录.md及各端核心源码
结论属性：基于当前代码与本地验证结果的阶段性评审，不等同于生产安全审计、算法效果验收或领域专家医学/检疫结论
1. 执行摘要
1.1 总体结论
项目已经从单纯的环境监控系统扩展为覆盖环境监测、设备控制、视频、AI 拍照巡检、分子检测、专家会诊、知识库、疫病溯源和区域统计的多端平台，功能广度较高，Go 后端的模块化和 RBAC 基础也已形成。
但当前仍应定义为“功能演示与试点验证阶段”，不宜直接按规格书 V2.1 宣称核心目标全部完成或进入生产验收，主要原因如下：
- 规格书已落后于实现架构。 规格书写的是 Vue3 + Python/FastAPI 主后端 + TDengine + MinIO + MobileNet/SSD + 端侧推理；仓库实际是 React + Go/Gin 主后端 + Python AI 微服务 + IoTDB + Ceph/规划中的云对象存储 + YOLOv8 ONNX + 云端推理。
- “完成”状态混入了骨架、mock、手工录入和接口预留。 例如真实 AI 模型尚未接入，摄像头巡检只有抽帧接口骨架，高光谱只有类型预留，微信和天气依赖真实凭证，SERS/qPCR 主要是录入与文件上传，不是设备闭环。
- 存在必须先处理的安全与业务正确性问题。 包括仓库内可用的默认密钥/口令、公开的视频流接口、摄像头口令随 API 返回、WebSocket 越权面，以及风险分把“健康类别的高置信度”误当作“高患病概率”。
- 工程质量与目标态不匹配。 数据库依赖 AutoMigrate 且忽略迁移错误；通知、令牌黑名单和部分运行状态保存在单机内存；缺少 CI、端到端/负载/安全测试和可观测性闭环。
- 规格书的验收标准不足以约束研发。 缺少需求编号、实现状态、接口 schema、异常流程、数据质量、算法数据集切分规则、模型版本治理、RTO/RPO、审计与隐私边界。
1.2 建议的总体策略
建议按以下顺序推进，而不是继续横向增加功能：
- 先止血： 修复安全暴露、风险评分语义、qPCR 判读边界和小程序类型错误。
- 再校准： 发布规格书 V2.2，把“目标态、当前态、验收态”分开，建立需求—代码—测试追踪矩阵。
- 补闭环： 完成自动检测任务、离线同步、消毒与种源链、可靠消息、模型/数据治理。
- 后扩展： 再投入固定摄像头巡检、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 改为：
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 和会诊，导致“确诊事件—处置—损失—复发—溯源”难以形成稳定主线。
建议核心链路调整为：
组织/养殖场 → 蚕房 → 蚕匾 → 饲养批次
├─ 日常记录/消毒记录/投入品记录
├─ 巡检事件 → 检测任务 → 样本 → 检测结果
└─ 发病事件 → 处置措施 → 会诊 → 溯源 → 效果评估
同时补充：
- 数据所有者、组织/区域数据隔离、保留期限、删除/匿名化规则。
- 图片、视频、光谱、模型训练数据的授权用途和导出控制。
- 数据字典：单位、枚举、空值语义、时间时区、来源和质量标识。
- 规则、知识文章、专家结论和模型输出的版本与审核状态。
- 训练数据从业务数据进入标注集的审批、脱敏、质检和撤回流程。
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 目录
- 文档控制、范围、术语与参考资料
- 产品目标、非目标、用户角色与业务边界
- 当前态、目标态和部署拓扑
- 核心业务流程与异常/补偿流程
- 带 ID 的功能需求
- 数据模型、数据字典、数据治理与保留策略
- API、事件、设备和外部系统契约
- AI 数据、训练、评估、推理和模型治理
- 权限、隐私、安全与审计
- 性能、可用性、灾备、可观测性和兼容性
- 分阶段范围、依赖、退出条件与验收矩阵
- 风险清单、假设、开放决策和 ADR 索引
- 蚕病领域知识附录与证据来源
- 需求—实现—测试—发布追踪矩阵
建议把 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：
- 修复风险评分和 qPCR 判读，隔离不可信历史数据。
- 收口视频、密钥、WebSocket 和 AI 服务的安全边界。
- 发布与真实架构一致的规格书 V2.2 和追踪矩阵。
- 建立版本化迁移、CI、可靠任务/通知和基础可观测性。
完成这些之后，再以“二维码样本链 + 消毒/种源链 + 自动检测任务 + 离线工作台”为首个业务增强包，能够显著提高现有功能之间的闭环程度，并为后续真实 AI 模型、区域流行病学和科研合作提供可信数据底座。