silk/AGENTS.md

AGENTS

沟通规则

1. 先说明结论，再说明影响和后续操作。
2. 除非项目约定另有要求，否则使用用户偏好的语言。
3. 交付说明应聚焦于修改的文件、验证结果和风险。
4. 对不清楚的需求或不可逆选择，执行前先向用户确认。
5. 创建或重写本指令文件前，询问用户该文件应使用哪种语言。
6. 每完成一项交付（功能/模块/部署），必须更新根目录 开发交接记录.md，追加「做了什么、设计思路与决策依据、验证结果、回滚点」，保证同事阅读后能快速接手；不得只做口头总结。

项目结构

本仓库是「智慧蚕房环境监测与智能调控系统」多模块 monorepo，各目录职责边界如下：

1. server-go/ — Go 后端（Go 1.23，Gin + GORM），入口为 cmd/server/main.go；提供 REST API（默认 :3000）、WebSocket /ws、视频代理 /live/proxy；消费 MQTT 遥测并处理阈值告警、设备控制、RBAC；依赖 PostgreSQL、IoTDB、Valkey/Redis、Ceph S3、WVP/ZLM、recorder-go。
2. web/ — Web 后台前端（Vite + React + TypeScript + Ant Design），开发端口 5173，/api 代理到后端 :3000。
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、后续工作计划.md（规格书 V2.1 的工作清单与技术选型决策）等为项目说明、规划与部署运维依据。
7. ai-service/（已建骨架，训练挂起期间 mock 模式）— Python FastAPI + ONNX Runtime AI 推理微服务（YOLO 蚕病检测、图像/光谱分析），生产部署于云 GPU 主机（NVIDIA T4 16G），与 Go 后端通过 HTTP 通信；模型训练在本地 fnOS/P4 物理机完成（当前物理机问题，训练挂起）。技术方向为「现有 Go 底座 + Python AI 微服务」混合架构，生产环境全部上云（业务云主机 + GPU 云主机 + 云对象存储），本地仅用于开发/训练/测试，详细规划见 后续工作计划.md。

生成文件及其来源命令：

1. miniapp/dist/ — 由 npm run dev:weapp / npm run build:weapp 生成。
2. web/dist/ — 由 npm run build 生成。
3. app/android/app/build/outputs/apk/release/app-release.apk — 由 cd android && gradlew assembleRelease 生成。
4. server-go/server-go-linux — 由 go build -o server-go-linux ./cmd/server 交叉编译生成。

已完成功能（截至 2026-08-13）

按《后续工作计划》推进（YOLO 训练相关 #1-4 因物理机问题挂起）。详细设计、验证与回滚点见根目录 变更记录.md、开发交接记录.md 及服务器 /home/pan/backups/rollback-20260812/README.md。

阶段一：AI 巡检闭环（#5-#11）

• ai-service：FastAPI + ONNX Runtime 骨架——GET /health、POST /detect（返回框/类别/置信度）；默认 MODEL_MODE=mock，ONNXDetector 已实现 YOLOv8 后处理，训练恢复后放 models/best.onnx 即切真实推理（接口不变）。
• Go 对接（#6）：inspection_records 表；POST/GET /api/v1/inspections（图片→S3 silk-images/inspections/→AI→记录；Idempotency-Key 幂等）；权限 inspection:create/read；配置 AI_SERVICE_BASE。
• 蚕匾/批次/饲养记录（#7）：trays/batches/rearing_records 三表 + CRUD；Web「批次管理」页（批次+蚕匾+饲养记录）；小程序蚕房详情展示蚕匾与当前批次。
• 拍照巡检（#8）：小程序「拍照巡检」页——拍照→上传→AI 结果（类别/置信度/风险提示）→巡检历史。
• 风险评分引擎（#9）：ComputeRiskScore（0.5/0.2/0.15/0.15 权重）+ 分级（绿 0-30/黄 31-60/橙 61-80/红 81-100）+ 阶段/环境系数；巡检创建时自动评分落库。
• 知识库（#10）：蚕病百科（9 病种 + 「其它/未知」）、AI 风险分级解读、LAMP/SERS 教程、四季防控提醒、症状图谱图片上传（S3 silk-images，公开读）；knowledge:read/write 权限；Web「知识库」页 + 小程序知识库（列表/详情/阶段风险提示）。
• 微信订阅消息（#11，骨架）：wechat_bindings 表 + /wechat/binding|bind|subscribe；巡检风险非绿异步触发；配置 WECHAT_APPID/SECRET/TEMPLATE_* 占位（待凭证联调真实推送）。

阶段二：环境监测 + LAMP（#12-#17）

• 和风天气与高发病天气预警（#12）：weather_alerts 表、GET /weather/now、GET /weather/alerts、30 分钟定时评估；规则取自规格书 3.2.3（白僵病/核型多角体病/软化病）；配置 QWEATHER_API_KEY/LOCATION 占位。
• 饲养阶段风险提示（#13）：GET /knowledge/stage-hints（young/grown/late5/pupa）+ 小程序选择器。
• LAMP 检测管理（#14）：lamp_tests/lamp_test_steps（标准 5 步自动生成）+ 结果照片上传 + 结果录入；Web「分子检测」页 + 小程序录入。
• 交叉验证（#15）：LAMP 结果自动与同房间最近巡检比对（一致→确认诊断，不一致→建议会诊），cross_status/cross_reason 落库。
• 耗材管理（#16）：consumables 表 + CRUD + 低库存/临期预警 + 采购建议；Web「耗材管理」页。
• 技术员 Web 后台（#17）：「巡检记录」页（列表 + 详情抽屉，含 roomName 联查）；检测任务处理/耗材在 #14/#16 已落地。

阶段三：专家诊断 + 多检测 + 溯源（#18-#22）

• 专家会诊（#18）：consultations 表 + 病例快照打包（房间/巡检/LAMP/批次/天气）+ 状态机（受理/出方案/归档）+ 专家意见/防控方案；Web「专家会诊」页。
• 分子检测扩展（#19）：检测任务支持 lamp/qpcr/sers/hyperspectral；qPCR Ct 自动判读（judge-qpcr，阈值可配）；SERS 光谱上传（S3 spectrum/）+ spectrum_entries 光谱库；高光谱预留。
• 多检测方式推荐引擎（#20）：GET /detection-methods/recommend（设备/紧急/操作者/成本偏好加权）；Web 新建任务弹窗内置推荐工具。
• 疫病溯源（#21）：trace_records 三级溯源——一级自动（环境回溯/历史关联/传播推断→初报）、二级分病种排查清单（→分析报告）、三级专家/实验室备注；Web「疫病溯源」页。
• 区域发病统计（#22）：rooms.region 字段 + GET /trace-records/region-stats（柱状图/饼图表达热力趋势；GeoJSON 地图后续按需接入）。

数据分析与运维（#24、#27）

• 蚕房健康画像与年度发病规律（#24）：GET /health-profiles/:roomId（健康分+评级）、GET /trace-records/monthly-stats；Web 蚕房「健康画像」抽屉 + 年度折线图。
• 测试基建（#27）：Web 引入 Vitest + jsdom（npm test），utils/format.ts 公共函数与首批单测；Go 各模块已有单测。

待办与外部依赖

• #23 摄像头流 AI 巡检：计划标注二期、需摄像头视角数据，暂缓。
• #25 时序存储决策：沿用 IoTDB（现状）或引入 TDengine（待用户决策，不阻塞 MVP）。
• #26 GPU 监控：依赖 GPU 主机 / P4 物理机恢复；开发环境 ai-service 以 mock 模式运行于开发服务器 :8000。
• 微信订阅真实推送：需小程序 AppID/Secret 与订阅消息模板 ID。
• 和风天气真实数据：需 QWEATHER_API_KEY 与位置。
• YOLO 训练（#1-4）：物理机问题修复后恢复（数据集修复→训练→best.onnx 接入 ai-service）。

编码规则

1. 遵循现有命名、分层、错误处理和格式化约定。
2. 将修改范围限制在用户请求的任务内。
3. 不得覆盖用户无关的已有修改。
4. 不得猜测或编造缺失的需求、事实、约定或技术决策。
5. 根据用户明确输入、仓库文件、配置、文档或命令输出验证相关结论。
6. 如果相关细节不确定、有歧义、存在冲突或无法验证，必须停止并先向用户确认，再继续操作。
7. 不得手改生成产物（如 miniapp/dist/、web/dist/、编译后的 APK、server-go-linux）；需要改动时先修改源文件或源 schema，再重新生成。

安装与配置

1. 后端：cd server-go && go build -o server-go-linux ./cmd/server；开发运行用 go run ./cmd/server。必需环境变量以 README「Go 后端环境变量」为准：PG、REDIS、JWT_SECRET、JWT_EXPIRES_IN、MQTT、IOTDB_URL、WVP_API_BASE、ZLM_API_BASE、RECORDER_API_BASE、S3_ENDPOINT、S3_ACCESS_KEY、S3_SECRET_KEY、S3_BUCKET、PORT、DEFAULT_ADMIN_USERNAME、DEFAULT_ADMIN_PASSWORD。
2. Web 前端：cd web && npm install && npm run dev；生产构建 npm run build。
3. React Native APP：cd app && npm install，按 app/.env.example 配置 API_BASE_URL，然后 npm start / npm run android。
4. 微信小程序：cd miniapp && npm install && npm run dev:weapp；生产构建 npm run build:weapp，产物输出到 dist/。
5. WVP 视频平台：cd wvp && docker compose up -d。
6. 选择未明确指定的技术栈、包管理器、数据库、运行时、部署目标或外部服务前，必须先获得用户确认。
7. 初始化项目时，如果技术栈尚未明确，应先让用户选择技术栈，再创建项目文件。
8. 不得将密钥写入需要提交的文件；需要环境配置时使用占位值创建 .env.example。
9. AI 推理服务（规划中）：Python 3.11 + 虚拟环境，PyTorch（cu121/cu124 wheel，兼容 Tesla P4）+ ultralytics；模型训练在本地 fnOS 服务器（i7-8700T / 62G / Tesla P4 8G，数据集路径 /vol1/ai/datasets）完成，导出 ONNX 后部署到云 GPU 主机（T4 16G）由 FastAPI 服务加载。

部署到开发服务器（dev：100.83.103.1）

环境依据：部署指南(物理机).md。SSH 主机 100.83.103.1、用户 pan，密码不写入提交文件，通过环境变量 PAN_SSH_PASS 传入；SSH/SFTP 辅助脚本为 scripts/devssh.py（不含任何密钥）。部署范围目前为 Go 后端（:3000）与 Web（:5174），小程序走微信开发者工具发布流程，不属于本服务器部署。

部署前置（每次发布必做）

1. 本地验证必须全部通过：后端 go test ./...、go build ./...、go vet ./...；Web npm run lint、npm run build；涉及小程序时 npm run build:weapp。
2. 代码可回滚检查（先于任何覆盖操作）：
   • 检查开发服务器 git 仓库状态：git status、git branch --show-current、git log -1 --oneline，确认服务器代码与发布基线的关系；记录服务器当前 commit。
   • 为服务器当前状态打可回滚标记：git tag pre-<YYYYMMDD-HHMMSS>（或把 commit hash 写入部署记录）。
   • 服务器工作区有未提交改动且与发布内容冲突时，不得强制 checkout/reset，先与用户确认。
3. 数据库可回滚检查：本次涉及 schema 变更（新增表/列/索引、数据迁移）时，发布前必须 pg_dump 全库备份到 /home/pan/backups/silk-<YYYYMMDD-HHMMSS>.dump，并记录恢复命令；纯代码发布可不强制，但每次发布前至少确认存在最近一份可用备份。
4. 运行环境检查：df -h（磁盘空间）、ss -tlnp（3000/5174/9090/5432 等端口监听）、服务进程存在性；有异常先记录并停止发布。

部署步骤

1. Go 后端：本机交叉编译 GOOS=linux GOARCH=amd64 go build -o silk-server-go-linux ./cmd/server/ → 上传服务器 → 保留旧二进制（如 silk-server-go-linux.bak-<时间戳>）→ 按 start_sh.txt / 部署指南方式重启（source .env 或导齐环境变量）→ curl http://localhost:3000/api/v1/health 健康检查 → 检查启动日志无 panic/连接错误。
2. Web：npm run build → 上传 dist → 备份旧 dist → 重启 server.cjs → curl -s -o /dev/null -w '%{http_code}' http://localhost:5174/ 应为 200。
3. 新接口/新功能冒烟：用登录 token 调用新增 API（如 /api/v1/knowledge/diseases）验证返回；检查后端日志无 5xx。
4. 部署后：更新 变更记录.md（日期、内容、验证结果、回滚点），并把服务器 commit/备份路径记入部署记录；同时按沟通规则追加 开发交接记录.md。

回滚预案

1. 代码回滚：服务器 git git checkout <pre-commit>，或恢复 .bak 二进制/旧 dist，重启服务并做健康检查。
2. 数据库回滚：仅在新 schema 有问题时执行 pg_restore 恢复备份；恢复前先再次备份当前状态并确认影响范围。
3. 回滚后更新部署记录与 变更记录.md。

禁止事项

1. 未完成备份/未记录回滚点前，不得覆盖服务器代码、二进制或数据库。
2. 不得在服务器上直接修改生成产物；需要修复时改源文件后重新构建部署。
3. 服务器密钥/密码不得写入提交文件；一律通过环境变量注入。

验证

1. 常规修改的针对性检查：Go 后端 go build ./...；Web npm run lint 与 npm run build；APP npm run lint 与 npm run tsc；小程序 npm run build:weapp。
2. 共享行为修改或发布工作执行更广泛检查：后端 go test ./...、go vet ./...，前端构建产物可用性检查。
3. 如果检查无法运行（缺少依赖、网络受限等），必须清楚报告确切命令和失败原因。

代码审查

1. 审查修改的正确性、回归风险、安全性、可维护性和测试覆盖率。
2. 按严重程度排列审查发现，并尽可能提供文件和行号引用。
3. 具体问题优先于总结；如果没有发现问题，应明确说明。
4. 指出影响发布风险的未验证行为、缺失测试或尚未解决的不确定项。