storage-labos/前端UI八页面完成/uploads/labos-text.md

STORAGE LABOS 固件回归测试值守机器人 产品定义、开发方案、竞争策略与未来规划 核心命题 不重新发明测试工具，先把工程师从刷版本、守机器、重启、收日志、填报告等机械劳动中解放出来。 产品代号 Storage LabOS · Regression Worker 版本 V1.0 日期 2026年7月27日 适用对象 联合创始人、产品负责人、研发团队、首批试点客户 首个落地场景 固件 A/B 版本的无人值守循环回归 北极星指标 无人值守完成率 + 每工位释放的工程师工时 一句话定位：固件提交后，系统自动刷版本、运行回归、处理卡死、收集证据、复现失败，并生成版本结论和缺陷单。

文档摘要

最终建议 先做“单工位固件回归值守机器人”，证明它能在一块 SSD、两个固件版本和一套真实 SOP 下，无人值守完成循环测试；测试主机卡死后自动恢复；失败时保存完整证据；结束后自动形成 A/B 对比报告。不要从协议合规、EDA、PCIe 高速背板或自研主控起步。 本项目的本质不是“AI 会不会判断 SSD”，而是建立一个存储实验室数字执行员：专家负责定义测试和决策，系统负责反复执行、值守、恢复、留证和整理。 公开市场中的 ULINK、OakGate、SANBlaze、Quarch 与 PyNVMe3 已经证明存储验证、供电控制、故障注入和自动化测试存在稳定需求；同时也说明新团队不应在底层测试覆盖和最新 PCIe 代际上正面竞争。你们的切口是这些能力之上的统一控制平面。 问题 方案 可量化结果 工程师夜间值守、失败后人工重启 带外控制器监测主机，分级执行软恢复、Reset、整机断电恢复 人工介入次数、自动恢复成功率 工具和脚本分散，失败现场不完整 统一连接器和 Evidence Bundle，将日志、设备状态、画面、温度和恢复过程对齐 证据完整率、从失败到可提单时间 回归结果靠 Excel 和人工对比 固件 A/B 自动对比、失败指纹聚类、自动生成报告与缺陷单 报告生成时间、重复问题合并率 企业已有工具难以推倒重来 以插件方式接入 DriveMaster、SANBlaze、Quarch、PyNVMe、fio 及私有工具 接入周期、适配器数量

目录

上半部分 下半部分

1. 项目判断与战略边界
2. 硬件方案与演进路径
3. 行业痛点、用户与价值模型
4. 竞品分析与竞争策略
5. 产品定位与主打卖点
6. 差异化、护城河与品牌表达
7. MVP 产品定义
8. 产品路线与未来规划 5-6. 产品功能、技术架构与开发方向 11-12. 商业化、团队分工与附录 A-D

1. 项目判断与战略边界

1.1 核心判断

战略公式 已有测试能力 × 无人值守执行 × 带外自救 × 证据闭环 × 失败复现 = 第一款可卖的产品。 你们最适合的起点不是存储芯片设计、EDA、主控固件本身，也不是再造一套协议测试仪，而是替代存储公司中高频、固定、耗时但决策含量低的执行劳动。 测试与验证并非“无脑工作”本身。真正应该被替代的是其中的机械执行层：准备环境、刷固件、反复启动、等待、检测卡死、收集日志、截图、对比版本、整理报告。测试设计、根因确认和发布决策继续由工程师负责。

1.2 产品要解决的任务

把一份固定 SOP 转换成可审计、可恢复、可重复执行的结构化工作流。 在无人值守状态下完成固件刷写、I/O、重启、休眠、恢复和数据校验循环。 测试主机失联或崩溃后，由独立带外控制器恢复环境并从安全检查点继续。 失败发生时自动保存完整现场，而不是只留下“第 67 轮失败”。 将固件 A/B 的结果自动对比，并输出研发可直接使用的报告和缺陷草稿。 兼容客户已有测试工具和私有脚本，降低替换阻力。

1.3 明确不做什么

非目标 原因 何时再考虑 重新开发完整 NVMe 协议合规套件 成熟厂商与开源框架已经积累大量用例；首版投入大、差异化弱 客户明确需要且已有稳定收入后，以连接器或合作方式补齐 PCIe Gen5/Gen6 高速背板与协议分析仪 涉及高速信号完整性、时序、电源和认证，容易拖慢产品验证 在单工位软件闭环和客户付费成立后，由专门硬件团队推进 让大模型直接控制破坏性命令 误操作代价高，不能把安全交给概率模型 大模型只生成草稿；确定性规则和人工审批执行 自动批准固件发布 发布是工程责任与组织流程，不应由系统越权 系统提供门禁证据和风险提示 EDA 或芯片设计自动化 进入核心设计签核，专业、信任、数据和销售门槛均过高 长期若有明确行业伙伴再单独评估

1.4 产品切入点

图 1｜本产品不与底层测试平台争夺协议覆盖，而是作为统一执行与闭环层。

2. 行业痛点、用户与价值模型

2.1 目标用户

用户角色 日常痛点 本产品交付 固件工程师 新固件出来后要等回归结果；失败信息不完整，复现成本高 版本差异、失败证据、最短复现建议 验证 / QA 工程师 大量时间花在刷版本、守机器、重跑和填表 无人值守执行、自动恢复、自动报告 实验室负责人 机器利用率低，夜间失败无人处理，资源状态不透明 工位在线率、任务队列、人工介入统计 FAE / 客户支持 现场问题难复现，日志来源分散 统一证据包、复现工作流、环境指纹 研发经理 无法准确知道版本风险和回归进度 版本门禁看板、阻断问题、历史趋势

2.2 当前人工流程

领取测试盘 → 核对序列号 → 刷入固件 → 重启并确认版本→ 配置测试环境 → 跑现有脚本 → 等待 / 观察→ 卡死后人工重启 → 重跑失败段 → 收集多处日志→ 截图 / 复制数据 → 与上一版对比 → 填 Excel→ 写测试报告 → 建缺陷单 → 工程师再次复现 这里面真正需要专业判断的环节有限，但每一次执行都需要工程师保持在线。夜间失败、主机蓝屏、网络断开和脚本挂起会让“已经自动化的测试”重新变成人工值守。

2.3 目标流程

工程师选择 DUT + 固件 A/B + 已审核工作流→ 系统完成安全预检和环境指纹记录→ 自动刷写、运行、重启、休眠、恢复、校验→ 失联时带外控制器分级自救并留痕→ 失败时自动收集 Evidence Bundle 并重现→ 自动聚类同类失败、对比 A/B、生成报告和缺陷草稿→ 工程师只处理需要判断的异常与发布决策

2.4 价值模型

北极星指标 每个测试工位每周释放的工程师工时。辅助指标包括无人值守完成率、人工介入次数、自动恢复成功率、证据完整率和从失败到可提单的时间。 指标 定义 产品阶段目标 无人值守完成率 UCR 无人工触碰完成的计划任务数 ÷ 总计划任务数 POC 先达到可用；产品化后持续逼近 98%+ 人工介入密度 每 100 小时测试需要人工处理的次数 持续下降，且分类记录介入原因 自动恢复成功率 主机/Agent 失联后由带外控制恢复的成功比例 区分软恢复、Reset、整机断电三层 证据完整率 失败任务是否包含规定的环境、日志、状态和恢复记录 关键字段不得因主机崩溃而丢失 报告交付时间 任务结束到可审阅报告生成的时间 分钟级，而不是人工半天整理 基础设施误报率 被错误归因到 DUT 的脚本、主机或网络故障比例 必须单独监控，否则自动化会制造噪声

3. 产品定位与主打卖点

3.1 一句话定位

产品定义 固件提交后，系统自动刷版本、运行回归、处理卡死、收集证据、复现失败，并生成版本结论和缺陷单。 产品名可以暂定为 Storage LabOS，第一款模块叫 Regression Worker。品牌不必强调“AI SSD”，应强调“固件回归不再靠人熬夜”。

3.2 三个主打点

主打点 用户能感知到的结果 为什么重要 一、自动完成，而不只是自动启动 工程师配置一次，系统整夜运行；主机卡死后能够继续，而不是停在那里等人 多数“自动化脚本”在异常后仍需要值守，这是实际人工成本来源 二、失败自动留证 每个失败形成统一时间线和 Evidence Bundle，包含环境、命令、日志、设备状态、画面、温度和恢复过程 减少“无法复现”和跨团队来回索取材料 三、不推翻现有工具 DriveMaster、SANBlaze、Quarch、PyNVMe、fio、私有刷写工具和脚本均以连接器方式接入 降低客户迁移成本，也避免与成熟平台在底层能力上正面竞争

3.3 支撑卖点

基础设施故障与 DUT 故障分开：网络、脚本、系统、Agent、供电和设备异常使用不同状态码。 失败自动复现与缩小范围：固定环境重跑、局部步骤重跑、单变量验证和版本二分。 A/B 版本结论直接可用：不仅给 Pass/Fail，还给新增、消失、加重和偶发问题。 安全优先：绑定 DUT 序列号、破坏性动作白名单、工作流签名、权限和全量审计。 私有化部署：客户日志、固件和工具默认不离开内网；AI 可选本地模型。 报告在测试结束时已完成：工程师从执行者变成审阅者。

3.4 对外表达

场景 推荐表述 官网主标题 固件回归不再需要工程师通宵值守。 副标题 机器卡死能自救，失败自动留证，第二天直接看版本结论。 对研发负责人 把初级工程师从刷版本、重启、收日志和填报告中释放出来。 对实验室负责人 提升工位利用率，量化每周节省的人工介入和停机时间。 不建议使用 “AI 精准判断所有 SSD 根因”“替代验证工程师”“一套工具取代所有测试平台”。

4. MVP 产品定义

4.1 首个场景：固件 A/B 的 100 次循环回归

MVP 只支持一个 SSD 型号、两个固件版本、一台 Windows 或 Linux 测试主机和一套真实 SOP。测试组合可包含 I/O、重启、冷启动、休眠恢复和数据校验。目标不是覆盖所有测试，而是证明全流程能无人值守闭环。

4.2 用户操作流程

1. 选择已登记的测试主机与 DUT，系统校验序列号、容量、当前固件和允许动作。
2. 选择固件 A、固件 B 以及一套已审核工作流模板。
3. 设置循环次数、重试策略、报告接收人和是否允许破坏性写入。
4. 系统执行环境预检：磁盘空间、网络、带外控制器、工具版本、日志目录和时间同步。
5. 任务开始后实时显示当前步骤、轮次、主机状态、设备枚举和关键指标。
6. 异常时自动收证、恢复、重试或中止，并明确区分基础设施故障与 DUT 故障。
7. 任务结束后输出固件 A/B 对比、失败簇、证据包和缺陷草稿。

4.3 MVP 范围

包含 暂不包含 单工位、单 DUT；Windows 或 Linux 二选一先做 多租户云平台与复杂计费 Python / Shell / PowerShell / fio / nvme-cli / 私有 CLI 连接器 完整 NVMe 合规套件 重启、休眠、冷启动、主机掉电恢复 精准 M.2 3.3V 微秒级掉电 树莓派带外 Power / Reset / 心跳 / 温度 PCIe Gen5/Gen6 自研高速背板 设备、主机、固件和环境指纹 自动 BIOS 版本刷写与视觉操作 统一日志、截图、状态和 Evidence Bundle 大规模预测性故障模型 规则判定 + AI 摘要 / 报告 / 复现建议 由 AI 直接执行危险命令或批准发布

4.4 MVP 功能模块

模块 MVP 功能 验收重点 资产中心 测试主机、DUT、固件、工具版本、序列号与标签 任何破坏性任务必须绑定允许的 DUT 工作流引擎 步骤、循环、条件、超时、重试、检查点、失败处理 任务重启后能从安全状态继续 Host Agent 执行命令、采集日志、心跳、设备枚举、上传证据 Agent 崩溃不应导致全部证据丢失 带外控制 软重启、Reset、整机电源循环、在线状态监测 测试主机完全失联时仍可操作 Evidence Bus 统一事件时间戳、原始日志、截图、摘要、哈希 失败材料可追溯且不被覆盖 比较与报告 A/B 通过率、失败类型、恢复次数、性能与温度差异 报告结论能回链到证据 AI 助手 SOP 草拟、日志摘要、失败归类建议、缺陷草稿 所有结论必须引用证据，不直接控制危险动作

4.5 POC 验收门槛

门槛 最低验收标准 完整执行 对固件 A、B 分别完成规定循环，支持中断恢复和任务审计 零误盘 所有破坏性动作均经过序列号和系统盘保护校验，误操作次数必须为 0 自救能力 模拟 Agent 停止、系统卡死或网络失联时，能够触发至少两级恢复策略 证据闭环 每个失败均可打开一条时间线，并下载统一证据包 版本比较 能够明确显示新增失败、已修复失败、重复失败与基础设施失败 人工减少 与原人工 SOP 对比，显著减少夜间值守、重启、收日志和整理报告时间

5. 产品功能与交互方案

5.1 页面结构

页面 核心内容 用户动作 总览 Dashboard 运行中任务、工位在线率、异常、人工介入、版本风险 快速判断实验室是否需要人处理 资产中心 主机、DUT、固件、工具、带外控制器、标签与状态 登记、绑定、禁用和审计 工作流模板 SOP 转换后的步骤、参数、权限、版本和审批状态 复制、编辑、审核、发布 任务创建 选择资产、固件、模板、循环、报告和安全策略 启动或预约任务 实时运行 当前轮次、步骤、心跳、设备状态、日志和恢复动作 只在必须时人工接管 证据浏览器 失败时间线、原始日志、截图、环境和哈希 定位证据、下载包、生成缺陷 版本比较 A/B 成功率、失败簇、性能、温度和恢复差异 作出版本判断 失败中心 跨任务聚类、指纹、首次/最近出现、关联版本 去重、标记、复现和分派

5.2 失败状态模型

INFRA_NETWORK_FAILURE 网络 / 交换机 / SSH / RPCINFRA_AGENT_FAILURE Agent 或插件运行器异常INFRA_HOST_OS_FAILURE 蓝屏、Kernel Panic、系统无法启动TEST_SCRIPT_FAILURE 脚本异常、参数错误、依赖缺失DUT_ENUMERATION_FAILURE SSD 未识别、掉盘、链路异常DUT_DATA_FAILURE 校验失败、介质错误、不可恢复数据错误DUT_PERFORMANCE_REGRESSION 超出已审核阈值的性能 / 长尾退化DUT_FIRMWARE_FAILURE 刷写、提交、激活或回退异常UNKNOWN 证据不足，等待工程师分类 状态模型必须在大模型之前建立。AI 可以解释和推荐，但真正的状态码应由规则、工具返回值和硬件信号生成。

5.3 Evidence Bundle

类别 内容 身份与环境 Run ID、DUT 序列号、型号、固件、主板、BIOS、操作系统、内核/驱动、工具版本 流程上下文 工作流版本、步骤、循环轮次、输入参数、超时、重试和检查点 设备证据 Identify、SMART/Health、Error Log、Self-test、Telemetry/厂商私有日志（可用时） 主机证据 系统日志、事件查看器、dmesg/journal、进程、资源、设备枚举和链路状态 现场证据 HDMI 截图/录像、串口、温度、供电控制动作、主机心跳和网络状态 数据证据 测试文件哈希、校验结果、失败 LBA/范围、fio/PyNVMe/私有工具输出 恢复证据 软恢复、Reset、断电、重新上线、重新枚举和恢复耗时 完整性 所有文件清单、时间戳、大小、哈希和生成组件版本 NVMe 标准已经定义 SMART/Health、Error Information、Device Self-test、Persistent Event 和 Telemetry 等可供诊断的日志或能力；厂商私有日志可通过专用工具或 nvme-cli 插件扩展读取。[11][12]

5.4 A/B 报告结构

执行摘要：版本是否建议进入下一阶段、阻断问题数量、关键风险。 环境锁定：两次测试的主机、BIOS、OS、驱动、工具和配置是否一致。 通过率与稳定性：总循环、完整完成、失败、自动恢复、人工介入。 问题变化：新增、已修复、仍存在、出现频率变化和严重性变化。 证据链接：每一个结论回链到原始任务、事件时间线和 Evidence Bundle。 下一步建议：复现工作流、需要固定/变化的变量、建议责任团队。

6. 技术架构与开发方向

图 2｜MVP 总体架构。带外恢复面独立于测试主机，证据面独立保存失败现场。

6.1 核心组件

组件 职责 MVP 建议 Web 控制台 资产、模板、任务、运行状态、证据、比较和权限 Next.js + TypeScript + ECharts API / Orchestrator 领域模型、权限、安全门禁、任务编排和报告 FastAPI + PostgreSQL Durable Workflow 长时间任务、重试、等待主机上线、检查点与补偿动作 POC 用数据库状态机；产品化再评估 Temporal 等持久工作流 Host Agent 命令执行、心跳、设备/系统采集、插件隔离与上传 MVP 用 Python 服务；稳定后将核心守护进程迁移到 Go Plugin Runner 接入 CLI、脚本、DriveMaster、SANBlaze、Quarch 等 清单化插件 + JSON 输入输出 + 超时/权限声明 OOB Controller Power、Reset、AC、电源状态、HDMI/串口/温度 树莓派 / CM4 / 工业控制器 + 独立 Agent Evidence Store 原始日志、截图、证据包和不可变清单 MinIO / S3 兼容对象存储；元数据进 PostgreSQL AI Service SOP 草拟、摘要、聚类标签、复现建议和报告 可配置本地或客户批准的模型；所有输出引用证据

6.2 工作流状态机

DRAFT → APPROVED → QUEUED → PRECHECK → RUNNING ↘ WAITING_FOR_HOST ↘ COLLECTING_EVIDENCE ↘ RECOVERING → RESUME / RETRY ↘ PASSED ↘ FAILED_DUT ↘ FAILED_INFRA ↘ ABORTED / EMERGENCY_STOP 持久状态机比普通脚本循环重要。测试可能持续数小时或数天，控制服务、Agent、主机或网络都可能重启；任务状态必须可恢复，且每一步需要幂等、超时和补偿逻辑。

6.3 工作流定义示例

workflow_version: 1name: fw_ab_powerstate_regressionsafety: allowed_dut_serials: ["SAMPLE-001"] destructive_write: true require_approval: truevariables: cycles: 100 firmware: "FW_B.bin"steps: - id: precheck action: lab.precheck - id: flash action: vendor.flash_firmware args: {image: "${firmware}"} - id: reboot action: host.reboot wait_for: {agent_online: true, timeout_sec: 600} - id: loop repeat: "${cycles}" steps: - action: nvme.collect_baseline - action: io.run_profile args: {profile: "4k_mixed", duration_sec: 300} - action: host.hibernate - action: host.wait_resume - action: dut.verify_enumeration - action: data.verify_hashon_failure: - action: evidence.capture_all - action: recovery.escalate - action: failure.classify

6.4 插件规范

字段 作用 name / version / platform 标识连接器、版本兼容和运行环境 capabilities 声明刷固件、采日志、I/O、供电、Reset 等能力 risk_level 只读、写入、格式化、Sanitize、固件更新等风险级别 inputs / outputs 使用 JSON Schema 约束参数和结构化结果 timeout / retry / idempotent 定义超时、重试和能否安全重复执行 evidence 声明必须产生的日志、快照和状态字段 healthcheck 任务前验证工具、许可证、设备和依赖是否可用 cleanup / compensation 失败或取消后恢复环境的动作

6.5 数据模型

实体 关键字段 Host 主机 ID、硬件、BIOS、OS、驱动、Agent、带外控制器、状态 DUT 序列号、型号、容量、形态、固件、标签、允许动作、生命周期 Firmware 文件哈希、版本、来源、兼容型号、审批、刷写工具 Workflow 版本、步骤、参数、风险、审批、签名、关联 SOP Run / Step Run 状态、时间、主机、DUT、固件、输入、输出、重试、检查点 Evidence 类型、URI、哈希、时间范围、来源组件、关联步骤 Failure Signature 状态码、日志特征、步骤、环境、DUT 状态、聚类 ID Intervention 人工介入原因、动作、耗时、结果，用于量化真实节省

6.6 AI 与确定性系统的边界

由确定性系统负责 由 AI 辅助 设备序列号与系统盘保护 把自然语言 SOP 草拟成工作流 命令白名单、权限、审批、超时和紧急停止 解释日志和生成工程摘要 真正执行刷写、格式化、Sanitize、供电和 Reset 给失败簇命名、提取相似特征 Pass/Fail 阈值、发布门禁和状态码 提出下一轮单变量验证或复现建议 原始证据采集、哈希和审计 生成 A/B 报告与缺陷草稿 AI 原则 任何 AI 结论都必须包含证据引用、置信度和“尚不能排除”的替代解释。AI 不直接执行危险动作，也不替代工程师作最终根因和发布判断。

6.7 安全与私有化

默认部署在客户内网；固件、私有工具、日志和客户数据不上传公共云。 工作流模板需要版本化、审批和签名；运行时禁止临时拼接未审核的危险命令。 系统盘、非白名单序列号和生产盘默认禁止写入；破坏性动作需要双重确认或审批。 Secrets 与日志分离；刷写工具凭据、许可证和 API Token 使用专门密钥存储。 所有自动恢复和人工接管动作写入不可变审计日志。 模型调用可配置脱敏；客户要求时使用本地推理。

7. 硬件方案与演进路径

7.1 MVP：树莓派作为带外控制器，不作为高性能测试主机

树莓派的价值不是跑满高端 SSD，而是在测试主机完全失联时仍能独立判断在线状态、操作 Power/Reset、记录温度和恢复过程。I/O 与固件测试应优先在真实 x86 Windows/Linux 主机的原生 M.2/U.2 接口上运行。 组件 首版选择 作用 测试主机 普通 x86 台式机或服务器，系统盘与 DUT 分离 运行客户原有工具、驱动和真实负载 带外控制器 Raspberry Pi 5、CM4 或工业 Linux 控制器 心跳、Power、Reset、AC、传感和画面 ATX 控制 光耦隔离的 Power/Reset 控制板 模拟按键，避免直接操作高风险供电轨 供电控制 首版先控制整机 AC；需要 DUT 精确掉电时接入成熟工具 避免首版陷入 M.2 供电时序和信号完整性 画面采集 USB HDMI 采集，可选串口 OS 未启动或蓝屏时仍能留证 传感器 温度为主，后续增加电流/电压 辅助判断热相关和供电相关异常 网络 控制面与带外控制器独立心跳 区分主机崩溃与网络故障

7.2 分级恢复策略

1. Agent 仍在线：终止异常进程、清理资源、重新执行安全步骤。
2. Agent 失联但操作系统可达：远程软重启或服务恢复。
3. 主机无响应：带外控制器短按 Reset，并监测重新上线。
4. Reset 无效：执行整机 AC 电源循环，保存断电和恢复时间。
5. 多次恢复失败：进入安全停止，保留现场，禁止无限重启。

7.3 硬件演进

阶段 硬件投入 进入条件 H0 现成硬件 POC 测试主机 + 树莓派 + ATX 控制 + 温度 + 可选 HDMI 先证明完整闭环和人工减少 H1 工程样机 工业控制器、隔离 I/O、机箱、状态灯、看门狗、可靠供电 已有试点客户，需要长期无人值守 H2 第三方仪器集成 PSPA、Quarch、智能 PDU、温箱等适配器 客户确实需要 DUT 独立掉电和故障注入 H3 自研带外控制板 多路 Power/Reset、传感、串口、硬件看门狗、远程升级 多个客户有一致需求，外购成本或集成复杂度成为瓶颈 H4 专业 DUT 电源 / 夹层板 精确掉电、测量、旁带信号和保护 由硬件团队完成 SI/PI、电气安全和长期可靠性验证 硬件边界 第一版不要直接切断 M.2 3.3V，也不要自研 Gen5/Gen6 高速转接背板。专业厂商已经提供可软件控制的 DUT 供电、功耗测量、Reset、HotPlug 和故障注入能力；先适配，后自研。[3][5][6][8]

8. 竞品分析与竞争策略

8.1 市场现状

截至 2026 年 7 月，主流存储验证厂商继续向更高 PCIe 代际、更多 DUT、协议合规、功耗测量、供电控制和故障注入扩展。OakGate 与 SANBlaze 已公开面向 PCIe 6.0 的产品路线，说明新团队若从高速验证硬件正面进入，将面对成熟技术积累与持续代际升级。[13][14] 另一方面，ULINK、SANBlaze、Quarch 和 PyNVMe3 都提供不同程度的自动化或 API 能力，不能把差异化建立在“竞品不会自动化”上。真正可建立的新定位是：跨工具编排、测试主机自救、证据闭环、失败去重与复现，以及对企业真实 SOP 的快速适配。

8.2 主要竞品画像

竞品 公开定位与能力 强项 本项目的策略 ULINK DriveMaster + NVMe Suites + PSPA Windows 上的 NVMe 命令、协议、回归与数据完整性测试；回归套件覆盖多种电源循环、数据比较和 JEDEC 工作负载；PSPA 支持软件控制 DUT 供电与测量。[1][2][3] 测试内容成熟，协议/命令控制和电源循环结合紧密 不重写套件；做上层版本流转、任务调度、主机恢复、跨工具证据和缺陷闭环 Teledyne LeCroy OakGate 专有 SVF 软件与桌面/机架设备组合，支持主流存储协议，可扩展多个 DUT，面向中大型测试团队。[4] 成熟、稳定、规模化、底层验证能力强 把 OakGate 视为高价值执行器；产品在其上方统一编排实验室流程 SANBlaze SBExpress Turnkey NVMe 验证系统；RM5 为 16 盘位 Gen5 机架设备，支持供电、功耗和错误注入；桌面系统提供 Python、REST、CLI/XML，公开资料称有 900+ 内置测试。[5][6] 协议、合规、硬件控制、API 和多盘位一体化 不比测试数量；比人工介入、异常自救、证据完整性和跨平台复现 Quarch 聚焦功耗、供电循环、HotPlug、旁带和物理层故障注入，提供 Python/REST 等自动化接口，并可与 PyNVMe 等集成。[7][8] 电源与物理故障注入专业、模块化 作为硬件连接器；不先自研精密供电与信号故障注入 PyNVMe3 Python + 专用用户态 NVMe 驱动，可在通用 x86/Ubuntu 平台运行，适合脚本化与 CI，降低专用硬件门槛。[9][10] 灵活、低成本、开发者友好、易于定制 作为首批默认执行器之一；补齐带外自救、资产、安全、证据和报告 企业自研脚本 / Jenkins 类流水线 自由组合 Python、Shell、PowerShell、fio 和私有工具 最贴合内部需求，已有沉没成本 真正的隐形竞品；必须做到接入而非替换，并明显降低维护和值守成本

8.3 能力重心对比

能力维度 专业测试平台 自研脚本 / CI Regression Worker 协议与底层测试覆盖 强，通常是核心卖点 取决于团队积累 不作为首版核心；调用外部能力 供电 / Reset / 故障注入 成熟平台可很强 需要自接硬件 统一适配，并提供带外恢复策略 企业私有 SOP 适配 可定制，但取决于平台 强，但维护分散 以工作流与插件为核心 主机完全卡死后的自救 部分平台具备设备级控制；跨主机流程各异 常需人工处理 产品级主打能力 跨工具证据时间线 通常围绕自身工具 多目录、多格式 统一 Evidence Bundle 基础设施与 DUT 故障区分 依赖具体平台和脚本 容易混杂 统一状态模型和分类 失败去重与最短复现 通常需工程师完成 依赖内部开发 核心增值能力 报告 / 缺陷闭环 有报告，但跨工具整合有限 人工拼接常见 测试结束即生成可提单结果 采购与替换阻力 可能较高 最低 叠加在现有资产上，降低迁移阻力

8.4 如何真正脱颖而出

1. 指标不同：竞品常用协议覆盖、测试数量、带宽、盘位和测量精度证明能力；你们用“每周节省多少人工介入、多少失败能够自动形成证据”证明价值。
2. 中立连接层：支持竞品和客户自研工具，把已有投入变成插件。客户无需在迁移前先否定过去的系统。
3. 主机级自救：很多存储工具能控制 DUT，但客户真正痛苦的是测试主机、操作系统、Agent 和网络异常后没人处理。
4. Evidence First：把“失败结果”变成可转交、可复现、可审计的工程资产。
5. Failure Intelligence：基于结构化状态和真实证据做去重、版本关联、单变量复现和历史问题检索。
6. SOP 产品化：每接入一套真实 SOP，就形成可复用模板、连接器和行业知识，而不是一次性外包脚本。

8.5 竞争风险

风险 判断 应对 成熟厂商增加 AI、报告或调度 很可能发生，不能依赖单一功能领先 保持跨厂商中立、做连接器广度和真实 SOP 数据 客户选择自研 这是最常见替代方案 以更快上线、带外硬件、证据标准和长期维护降低自研吸引力 被认为只是“套壳 Jenkins” 如果只做任务调度，确实会发生 必须把 OOB 自救、DUT 安全、证据包、失败指纹和复现做深 客户不愿开放私有工具和日志 存储行业数据敏感 内网部署、最小权限、适配器边界、脱敏和可审计 不同客户 SOP 差异过大 可能沦为项目制外包 核心模型标准化，连接器和模板参数化，严格控制定制边界

9. 差异化、护城河与品牌表达

9.1 可持续护城河

护城河 形成方式 为什么不容易复制 连接器网络 对专业平台、私有 CLI、操作系统和硬件控制器持续适配 单个连接器不难，但长期兼容和组合测试成本高 标准证据模型 把主机、DUT、工具、画面、供电和恢复放入统一时间线 需要深刻理解真实故障流程和客户材料要求 失败指纹库 跨固件、环境、步骤和日志生成稳定签名与聚类 数据来自长期真实回归，不能靠一次模型训练获得 SOP 模板资产 将客户流程抽象为可复用工作流、参数和门禁 越贴近行业，交付越快，客户切换成本越高 带外控制经验 主机状态识别、分级恢复、避免死循环和安全停止 软硬件结合，需要大量异常场景验证 可信度与审计 零误盘、证据完整、可回溯、私有化 存储验证的信任来自长期稳定运行，不只是界面和模型

9.2 数据飞轮

更多真实工作流→ 更多结构化运行与失败证据→ 更稳定的失败指纹和恢复策略→ 更快的 SOP 接入与更少误报→ 更高无人值守完成率→ 客户愿意接入更多工位和工具 数据飞轮不能依赖上传客户原始敏感数据。产品应支持在客户本地训练/统计，中心仅同步脱敏的规则、连接器版本和通用失败模式；是否共享由客户明确授权。

9.3 品牌与销售语言

建议强调 避免强调 存储实验室数字执行员 万能 AI 存储专家 无人值守完成率和释放工时 测试脚本数量 异常自救和证据闭环 简单任务调度 不替换现有工具，快速叠加 颠覆所有测试平台 工程师保留最终判断 替代验证工程师 私有化、安全、可审计 把所有日志上传云端训练

10. 产品路线与未来规划

图 3｜路线以里程碑和验收门槛推进，而不是先搭建“大而全”平台。

10.1 阶段 A：单工位 POC

交付 进入下一阶段的门槛 一台测试主机、一块允许破坏性测试的 SSD、两个固件版本、一套 SOP 完整跑通 A/B 工作流，所有动作可追溯 Agent、基础工作流、树莓派 Power/Reset、日志和报告 模拟主机失联后能自动恢复 设备身份、安全白名单、Evidence Bundle 误盘为 0；失败证据不因主机崩溃丢失 人工流程对照测量 明确减少了哪些步骤和工时

10.2 阶段 B：试点版 Regression Worker

接入客户真实刷写工具、私有日志工具和一到两套回归 SOP。 增加角色权限、模板审批、审计、报告版本和缺陷系统接口。 完善 Windows / Linux 主机故障识别与分级恢复。 建立基础失败指纹、任务对比和工位利用率指标。 形成可重复安装、升级和远程诊断的私有化部署包。

10.3 阶段 C：多工位 Storage LabOS

统一资源预约、任务队列、优先级、并发和维护窗口。 主机、DUT、固件、工具和许可证资产管理。 跨工位失败聚类、历史版本关联和实验室健康看板。 连接器 SDK 与客户自助适配框架。 支持接入 OakGate、SANBlaze、Quarch、DriveMaster 等现有资产。

10.4 阶段 D：兼容性循环测试柜（方向 4）

在单工位工作流、自救、证据和调度成熟后，增加多主板、多 BIOS、OS、驱动和电源状态矩阵。此时方向 4 不再是一个新项目，而是同一 LabOS 的新资源类型与测试模板。 独立测试节点与带外控制，避免首版设计高速 PCIe 共享背板。 系统镜像恢复、驱动安装、启动前画面采集和兼容性环境指纹。 Pairwise / 风险加权等组合缩减，避免矩阵全排列。 输出固件与主板/BIOS/驱动的兼容性图谱、白名单和最小复现组合。

10.5 阶段 E：相邻产品

产品模块 复用能力 新增能力 RMA 返修盘初检 资产、工作流、日志、证据、报告 返修登记、标准复现、初步分流 来料质检工位 多工位调度、设备身份、报告 批量扫码、批次基线、标签/系统接口 工业存储黑匣子 Agent、事件时间线、异常模型 现场长期采集、边缘缓存、远程回传 精确掉电与故障注入 带外控制、工作流、证据 自研电源/信号板或深度仪器集成 实验室运营分析 任务、工位、介入、失败数据 容量规划、利用率和质量趋势

10.6 关键决策门

决策门 继续投入的必要证据 从 POC 到试点 真实 SOP 下显著减少人工介入；至少一次异常被自动恢复并形成可用证据 从试点到产品化 客户愿意持续使用并提供第二套 SOP；部署、升级和安全问题可控 从单工位到多工位 客户有明确工位规模和调度痛点，而非为了平台化而平台化 从外购硬件到自研控制板 三个以上客户出现重复硬件需求，且外购成本/集成限制影响销售 进入兼容性测试柜 单工位底座稳定，且有主板/BIOS/OS 矩阵的真实付费需求

11. 商业化与首批客户策略

11.1 最适合的首批客户

客户特征 为什么适合 中型 SSD、主控、模组或工业存储团队 有真实测试压力，但未必已有完整内部 LabOS 拥有 5-50 个测试工位或大量零散脚本 人工值守和维护成本明显，能量化 ROI 至少有一套固定且高频的固件回归 SOP 容易形成第一条闭环，而不是开放式咨询 愿意提供脱敏报告、正常/异常样品和工程师接口 能验证产品是否真正解决问题 需要私有化部署和现有工具接入 恰好匹配中立控制层定位 首批客户选择 暂不优先挑战已经拥有成熟自研 SLT / LabOS 的头部厂商。先找“已有测试能力，但流程碎片化、夜间仍要人守”的团队。

11.2 POC 交付包

一份真实 SOP 的结构化工作流和风险清单。 一台测试主机 Agent 与一套树莓派带外控制。 客户私有刷写工具、I/O 工具和日志工具连接器。 固件 A/B 循环任务、异常自救和 Evidence Bundle。 版本对比报告、人工步骤对照和 ROI 结果。 下一阶段产品化边界与报价依据。

11.3 商业模式

收入项 说明 POC / 集成服务 围绕一套 SOP 和一个工位完成连接器、流程和现场验证 软件许可 / 订阅 按工位、并发任务或实验室规模授权，私有化部署 带外控制硬件 标准控制盒、机箱、传感和可选画面采集 高级连接器 专业测试平台、仪器、缺陷系统和私有工具适配 维护与升级 连接器兼容、系统升级、安全补丁和远程支持 后续模块 兼容性柜、RMA、来料质检、运营分析

11.4 ROI 计算方式

每月可节省成本 ≈（原每次人工操作分钟 × 每月任务次数 × 工程师综合小时成本）+ 夜间 / 周末值守成本+ 因失败证据不足导致的重复复现时间+ 测试机空转和等待人工恢复的机会成本- 软件与硬件的月度摊销成本 销售时不要只展示“技术很强”，而要对照客户原 SOP 逐步标注哪些动作被删除、哪些异常不再需要人到场、报告提前了多久。

11.5 POC 访谈问题

哪一套测试每周重复最多，步骤最固定，最需要人守？ 测试主机最常见的中断原因是什么：蓝屏、掉盘、脚本、网络、供电还是环境？ 失败后工程师必须收集哪些证据才能建缺陷单？ 现有工具有哪些 CLI、API 或可调用入口？哪些只能操作 GUI？ 哪些动作可能破坏数据或刷错盘？现有审批与白名单是什么？ 一名工程师每周花多少时间在执行、值守、重跑和整理报告上？ 哪些问题由于证据不足经常被标记为“未复现”？

12. 团队分工、风险与立项动作

12.1 初始团队

角色 主要职责 你：产品 / 全栈 / AI 产品定义、控制台、工作流、数据模型、AI 报告、交付体验和项目推进 同学：存储领域 / 客户 / 资金 真实 SOP、测试样品、固件/日志解释、行业关系、首批客户和资源投入 验证工程师（必须） 把真实流程拆成可执行步骤、定义门禁、验收状态和异常分类 嵌入式 / 硬件工程师 带外控制、隔离、可靠供电、看门狗、机箱与后续自研板 后续平台工程师 Agent 稳定性、部署、升级、对象存储、权限和多工位调度

12.2 主要风险清单

风险 影响 缓解措施 没有真实 SOP，只按想象开发 做出漂亮但没人使用的通用平台 第一条工作流必须来自同学公司或真实客户 试图一次支持所有工具和接口 项目失控、无法验收 先锁定一个 OS、一个 SSD 类型、一套工具链 只做网页调度，没有异常自救 容易被视为脚本平台或 Jenkins 套壳 带外控制、状态机和证据闭环必须进入 MVP AI 结论过度承诺 降低工程师信任并带来错误决策 证据引用、置信度、规则优先、人工确认 硬件故障导致误判或损坏 DUT 安全和品牌风险 隔离、保险、白名单、紧急停止和硬件评审 客户定制过多 变成低毛利项目制 插件 SDK、标准模型、可配置模板、定制边界 无法证明节省人工 购买理由不充分 从第一天记录人工介入和原流程基线

12.3 立项后的第一批动作

1. 向同学获取一份最耗人的固件回归 SOP、一份脱敏测试报告和两个固件版本。
2. 选定一台独立测试主机和一块允许反复写入/刷写的测试 SSD。
3. 用人工完整执行一次 SOP，逐步记录动作、等待、判断、异常和最终报告。
4. 将流程拆成“专家判断”和“机械执行”，只自动化后者。
5. 先实现设备身份、安全预检、任务状态机和原始证据采集，再做 AI。
6. 接入第一个刷固件工具与第一个 I/O/日志工具。
7. 接入树莓派 Power/Reset，模拟 Agent 失联和主机卡死。
8. 完成固件 A/B 的 100 次循环 Demo，统计人工介入和失败证据。
9. 让真实验证工程师审阅报告，修改 Evidence Bundle 和状态码。
10. 用 Demo 向第二个潜在客户验证是否存在同类 SOP，而不是立即扩功能。

12.4 最终立项结论

建议立项 以“固件回归测试值守机器人”为第一产品，底层定位为 Storage LabOS 的单工位执行节点。第一阶段只证明三件事：测试能自动完成、主机异常能自救、失败能自动形成可用证据。完成后再扩展多工位和兼容性测试柜。

附录 A｜工作流与证据目录示例

A.1 Evidence Bundle 目录

run-20260727-0001/├── manifest.json├── environment/│ ├── host.json│ ├── dut.json│ ├── firmware.json│ └── tool_versions.json├── timeline/events.ndjson├── device/│ ├── identify.json│ ├── smart-health.json│ ├── error-log.json│ └── telemetry.bin├── host/│ ├── system.log│ ├── kernel.log│ └── device-enumeration.json├── test/│ ├── stdout.log│ ├── stderr.log│ ├── metrics.json│ └── hashes.json├── oob/│ ├── heartbeat.ndjson│ ├── power-actions.ndjson│ ├── temperature.csv│ └── screenshots/├── recovery/recovery.json└── summary/ ├── failure-signature.json ├── ai-summary.md └── issue-draft.md

附录 B｜失败指纹建议

失败指纹应由稳定、可解释的字段组成，而不是直接使用大模型生成的文本。建议包含： 失败状态码与工作流步骤。 DUT 是否枚举、控制器/命名空间状态和链路信息。 关键错误码、内核事件、工具返回值和日志模板。 固件、主板、BIOS、OS、驱动和电源状态。 失败前后时间窗口内的温度、供电动作和恢复结果。 数据校验是否失败以及失败范围。 将结构化字段归一化后计算签名，再使用聚类或语义模型辅助合并相似问题。工程师可以手动拆分、合并和给簇命名，结果反哺后续规则。

附录 C｜参考资料与竞品官方来源

以下资料用于核对竞品公开定位与 NVMe 日志能力，访问日期均为 2026 年 7 月 27 日。竞品“缺口”属于基于公开产品定位的战略判断，不代表其不存在非公开或定制功能。 [1] ULINK DriveMaster 10 NVMe [2] ULINK NVMe Test Suites [3] ULINK PCIe-SSD Power Adapter Plus Gen4 [4] Teledyne LeCroy OakGate SSD Test and Validation Solutions [5] SANBlaze SBExpress-RM5 [6] SANBlaze SBExpress-DT5CD [7] Quarch Data Center & AI Solutions [8] Quarch PyNVMe / PyNVMe3 Integration [9] PyNVMe3 User Guide [10] PyNVMe3 Developer’s Guide [11] NVM Express: Error Reporting, SMART, Log Pages and Management [12] NVM Express: Open Source NVMe CLI [13] Teledyne LeCroy: OakGate PCIe 6.0 / NVMe Validation Announcement [14] SANBlaze: Gen6 SSD Testing Announcement

附录 D｜术语

术语 说明 DUT Device Under Test，被测设备，本项目主要指 SSD。 OOB / 带外控制 独立于测试主机操作系统的控制路径，用于 Power、Reset、画面、串口和传感。 Evidence Bundle 一次失败或任务的标准化证据包。 UCR Unattended Completion Rate，无人值守完成率。 Failure Signature 由状态、步骤、日志、环境和设备特征组成的失败指纹。 Regression Worker Storage LabOS 的第一款单工位固件回归执行模块。 LabOS 面向存储实验室的统一控制平面，管理任务、工位、证据、恢复和智能分析。 SOP Standard Operating Procedure，企业既有标准操作流程。 — 文档结束 —