2026年9月15日赛博日记

生成时间：2026-09-15 23:52 (Asia/Shanghai)

核心工作

今日共 6 个 Cursor 会话（205 条消息），Claude Code 会话 0 个，主线为 MeterSphere 测试平台（项目X）的部署与架构梳理：

中间件职责梳理（15:43，会话 aa0e5221）：厘清 MySQL / Redis / Kafka / MinIO 四件套在测试平台中的定位——MySQL 是平台元数据库（Flyway 管表结构），Redis 承载 Shiro Session 与缓存，Kafka 负责平台内部异步消息，MinIO 做对象存储；被测业务库与平台库是两条链路，业务库需在用例/环境的 JDBC 数据源里单独配置，不能混淆。
前后端启动攻坚（15:54，会话 82865d8f）：前两次启动失败（测试编译报错、PowerShell 吞掉 -D 参数）均已处理，服务已在 https://localhost:8443/ysbapitest/ 正常运行。
测试流程画布与 API 用例链路梳理（16:34，会话 c16ce996）：核心发现——流程图通过 test_flow_case_link 关联 UI/API 用例节点（case_type：0=传统UI、3=接口自动化等）；执行结果统一按 case_type 路由写入 test_execution_record / test_failure_record；场景执行模型为 Setup → Steps → Report → Teardown(finally)，支持 scenarioSweep 清残留。
bug-analysis-report skill 安装检查（18:35，会话 fd5263ec）：安装被阻塞——本机 Python 3.10.4 低于要求的 3.11+、仓库缺同步脚本、repository.yml 路径（F:\code\java）与本机实际（E:\code\java_code）不符、ES 配置与 OceanBase MCP 信息待用户提供。已汇总阻塞项等用户补充。
另有 3 个低信息量会话（pytest-ysb 152 消息兜底摘要、ysbapitest 两轮短会话）。

昨日定稿的三篇硬件笔记今日仍在修订，NVFP4 生产切换已落地：

A/B 终版结论：NVFP4(W4A16/TEP2/MTP6) vs AWQ-INT4(PP2/spec3)——decode 全档 +52%~+74%（96-107 t/s 平带），AWQ 栈必崩的 spec 每请求记账竞态在 NVFP4 栈上 2/2 通过零 Xid。
PLE 精度实验：BF16 原版表（95.4G）对比 FP8 表（51G）prefill 反降 40-61%（表超 RAM 引发 page fault），decode 持平——精度→草稿质量假设证伪，FP8 表为最优组合，且旧栈时代的"BF16 甜区"结论不可迁移（MTP6 gather 频率×7）。
生产切换完成：flashnext.service 已切 NVFP4（systemd drop-in 60-nvfp4-prod.conf，回滚只需删文件+daemon-reload），默认 524288+YaRN2.0，客户端零改动。
硬核踩坑：--hf-overrides 的 quantization_config 是整块替换而非深合并，注入块会丢 quant_method/ignore 导致 vLLM 报量化方法不匹配——正解是 config.json 直接用 W4A16 声明版。
另有 safetensors 两遍法写 header 的坑（单遍回填会覆盖数据头，sha256 核验抓出）。

MeterSphere 类测试平台要按数据流向区分"平台资产存储"与"被测业务数据"两条链路，不能只看组件名。
hf-overrides 不做深合并这类隐性行为，配置注入前应先读源码确认合并语义。
bug-analysis-report 安装阻塞项清单已发出，等用户提供：完整仓库路径、ES 配置、OceanBase MCP 连接信息；凭据只写本机配置文件不入库。

双线并行：白天主线是 MeterSphere 测试平台的部署与架构梳理（中间件职责、流程画布数据模型、前后端启动成功）；硬件线完成 NVFP4 生产切换收尾（PLE FP8 定稿、systemd 切换、回滚路径就绪），推理 decode 提速 52-74% 且彻底摆脱旧栈竞态崩溃。