chore(repo): initialize team collaboration repository

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

@@ -0,0 +1,983 @@
+FLASHOPS  REGRESSION
+存储固件回归测试值守机器人
+产品立项、开发架构、竞品差异化与中长期规划方案
+核心判断  不要重新发明一套 NVMe 协议测试仪。先把客户现有脚本、商用测试平台和测试主机统一接管，替代工程师反复刷版本、守机器、救卡死、收日志、写报告的机械劳动。
+1 个真实 SOP第一枪只替代一段真实工作
+100 次循环证明无需人工通宵值守
+0 次错盘危险动作必须确定性防护
+1 套证据包失败可复现、可追责、可比较
+暂定产品名：FlashOps Regression
+上位平台：Storage LabOS（未来品牌架构）
+文档版本：V1.0｜公开资料核查截止：2026 年 7 月 27 日
+用途：合作讨论、产品立项、技术拆解、首轮 PoC 与开发团队输入
+# 执行摘要
+FlashOps Regression 的产品本质不是“更懂 NVMe 的 AI”，而是“存储实验室的数字执行员工”。它位于专业测试工具与工程师之间，负责固件版本流转、测试编排、长时间值守、测试机自救、故障现场冻结、跨工具证据归集、失败重跑、版本 A/B 对比及报告生成。
+项目的第一原则是保留客户既有投入：ULINK、OakGate、SANBlaze、Quarch、NI TestStand、PyNVMe3、fio、nvme-cli 以及企业私有脚本都不应被替换，而应被纳入统一的适配器体系。现有厂商公开能力已经覆盖深度协议验证、性能、合规、功耗及故障注入；本项目应避开正面竞争，把差异化建立在跨工具无人值守闭环上。[1]-[10]
+推荐立项方式  先找到一份真实且高频的固件回归 SOP，用一台测试主机、一块允许破坏性测试的 SSD、两个固件版本和一套带外控制器，完成 100 次循环的无人值守 PoC。PoC 的成败不看页面数量，而看人工触碰次数是否显著下降。
+## 一页结论
+项目项
+建议结论
+首要客户
+中型 SSD / 模组厂、主控与固件团队、工业存储厂商；已有大量脚本但平台碎片化。
+首要场景
+固件 A/B 回归：刷固件、重启/休眠/I/O 循环、卡死恢复、证据留存、报告与缺陷单。
+产品主打
+不推翻现有工具；机器卡死能自救；失败自动形成证据包；版本差异一夜出结论。
+MVP 边界
+单测试节点、单 DUT、Windows/Linux Agent、基础带外控制、客户脚本接入、A/B 报告。
+不做事项
+不自研 PCIe Gen5 高速背板；不重写协议合规套件；不让大模型直接执行破坏性命令；不承诺自动批准固件发布。
+北极星指标
+每 100 次回归中，工程师必须亲自触碰测试机的次数。
+未来方向
+多节点企业版 → 故障签名与最短复现 → 兼容性循环测试柜 → Storage LabOS。
+# 目录
+01  项目背景与问题定义
+02  产品定位与核心价值
+03  目标客户、岗位与典型场景
+04  端到端业务流程
+05  产品与技术总体架构
+06  软件开发方案
+07  硬件与带外控制方案
+08  AI 与故障智能方案
+09  MVP 范围、开发里程碑与验收
+10  竞品格局与差异化战略
+11  商业化与首批客户策略
+12  数据壁垒与长期护城河
+13  未来产品规划
+14  团队配置、投入顺序与治理
+15  风险清单与应对策略
+16  立即行动清单
+附录 A  示例工作流
+附录 B  Evidence Bundle 字段
+附录 C  失败分类体系
+附录 D  公开资料来源
+# 01  项目背景与问题定义
+先区分“需要专家判断的工作”与“可以被机器稳定执行的工作”。
+## 1.1 存储验证中的真实矛盾
+存储固件测试并不缺少专业工具。真正长期消耗组织成本的，是工具之间缺少统一控制、测试任务需要人工值守、失败后证据散落、环境恢复依赖个人经验，以及同类失败被重复分析。工程师往往不是把时间花在“定义测试与判断根因”上，而是花在“让测试能够持续跑下去”上。
+## 1.2 工作拆解：专家劳动与执行劳动
+工作类型
+典型任务
+是否应由首版产品替代
+专家劳动
+定义覆盖范围、制定通过标准、决定发布门禁、最终根因判断
+否。产品提供证据和建议，保留人工决策。
+执行劳动
+刷固件、登记序列号、配置环境、循环重启、等待、收日志、重跑、填表
+是。首版核心替代对象。
+半结构化劳动
+归并相似失败、筛选关键日志、比较版本差异、生成复现步骤
+逐步替代。规则优先，AI 辅助。
+## 1.3 五个高频行业痛点
+痛点
+现场表现
+直接损失
+工具碎片化
+脚本、商用平台、命令行、仪器和 Excel 各自独立
+重复集成、上下文丢失、难以规模化。
+无人值守不完整
+脚本能跑，但蓝屏、掉线、卡死后仍需人工处理
+夜间和周末机器利用率低。
+故障留证不足
+只有 Fail、退出码或零散日志，没有统一时间线
+工程师无法快速复现，争议增加。
+基础设施误报
+网络、系统更新、磁盘满、Agent 崩溃被误判为 DUT 故障
+产生大量无效缺陷，降低自动化可信度。
+报告仍靠人工
+版本、环境、日志、截图和结论手动拼装
+测试结束不等于结论产出，发布周期继续被拖延。
+问题定义  如何在不替换客户现有测试能力的前提下，把一次固件回归任务从“需要工程师持续守着”变成“工程师下达任务后即可离开，第二天获得可信结论与完整证据”？
+## 1.4 技术可行性基础
+NVMe 标准与生态已经提供错误日志、SMART、Telemetry、Persistent Event Log、设备自检等可采集信号；NVM Express 将 nvme-cli 列为 Linux 管理 NVMe SSD 的标准开源工具，并支持厂商插件。[11][12] Linux 内核还提供系统化的 NVMe 故障注入机制，可用于构建测试基础设施自身的验证场景。[13] 因此首版无需从芯片底层重新造轮子，而应优先完成编排、留证、恢复和安全控制。
+# 02  产品定位与核心价值
+定位必须避开“又一套测试仪”，形成可以与现有平台共存的控制层。
+## 2.1 产品定义
+一句话定义  固件提交后，系统自动完成版本刷写、回归执行、测试机自救、故障现场冻结、失败复现、A/B 对比与报告提单。
+### 产品类别
+存储实验室执行智能体（Storage Lab Execution Agent）与控制平面（Control Plane）。它不是 EDA，不是协议分析仪，不是单一测试套件，也不是聊天机器人。
+### 核心产品承诺
+工程师配置一次任务后，可以离开测试现场。
+测试主机或 Agent 故障时，系统通过带外通道自行恢复。
+每个失败自动生成结构化证据包与统一时间线。
+已有脚本和商用测试平台继续使用，不要求客户重写。
+危险动作由确定性策略控制，AI 无权直接越过安全门禁。
+## 2.2 六个核心卖点
+主打点
+客户听得懂的表达
+产品实现
+真正无人值守
+不是“能自动开始”，而是“异常后还能自己继续”。
+心跳、状态机、软恢复、Reset、整机断电、检查点续跑。
+故障现场自动冻结
+失败不再只剩一行报错。
+统一时间线、日志快照、设备状态、画面、温度、恢复过程。
+不推翻已有工具
+客户原来的测试投入全部保留。
+Adapter SDK、CLI/REST/Python/PowerShell 接口、工具封装。
+A/B 版本直接出结论
+不用人工翻目录比较固件差异。
+环境指纹锁定、基线比较、失败签名、回归门禁。
+基础设施与 DUT 故障分离
+减少自动化制造出来的垃圾缺陷。
+故障分类规则、探针交叉验证、Agent/OOB 双通道。
+AI 有用但受控
+AI 做归并、解释和建议，不直接删盘或刷错固件。
+结构化工具调用、安全策略、证据引用、人工发布门禁。
+## 2.3 产品边界
+首版明确要做
+首版明确不做
+固件 A/B 回归任务编排
+自研 NVMe 协议合规测试套件
+Windows/Linux Agent 与客户脚本执行
+PCIe Gen5/Gen6 高速信号背板
+主机带外自救与简单传感
+裸 NAND、FTL、主控固件开发
+设备/环境指纹与安全绑定
+AI 自动批准固件发布
+Evidence Bundle 与自动报告
+替代最终专业根因分析
+规则驱动的失败分类与重跑
+第一版同时支持 NVMe/SATA/eMMC/UFS
+# 03  目标客户、岗位与典型场景
+首批客户应当“有真实痛点、有现成脚本、但没有完整平台”。
+## 3.1 理想客户画像（ICP）
+优先级
+客户类型
+典型现状
+切入理由
+A
+中型 SSD / 存储模组厂
+5—50 个测试节点，脚本与工具分散，依赖关键工程师
+痛点高、决策链较短、可快速拿到真实 SOP。
+A
+主控或固件创业团队
+研发迭代快，但验证平台不完整
+愿意以效率换取工具，适合作为设计合作伙伴。
+A
+工业存储厂商
+客户现场问题多，回归和复现耗时
+更看重稳定性与留证，不只看协议合规。
+B
+存储品牌与 OEM 验证团队
+商用设备与自研脚本并存
+可通过“统一控制层”切入。
+C
+拥有成熟自研 SLT 的头部厂商
+已有调度、追溯和大数据平台
+早期进入难，优先作为未来集成或特定模块客户。
+## 3.2 主要使用角色
+角色
+当前最烦的工作
+产品价值
+验证工程师
+守长测、救机器、收证据、重跑
+从执行员回到验证设计和判断。
+固件工程师
+拿到的缺陷信息不完整，无法复现
+获得最短复现路径和完整环境。
+测试主管
+无法统一了解机器利用率与失败类型
+看见任务进度、故障分布与产能。
+质量/项目经理
+版本是否可发布依赖口头汇总
+获得可审计的版本门禁报告。
+实验室管理员
+设备、主机、固件和脚本版本混乱
+统一资产、环境和权限治理。
+## 3.3 首版典型场景：固件 A/B 回归
+选择 DUT、旧固件 A、新固件 B 与固定测试环境。
+系统校验序列号、介质状态和破坏性测试授权。
+先运行固件 A 的基线任务，再刷入固件 B。
+按相同条件执行 100 次重启、休眠/唤醒、I/O 与数据校验循环。
+出现卡死、蓝屏、掉盘或 Agent 失联时，带外控制器自动恢复。
+每次失败生成 Evidence Bundle，并按失败签名归并。
+输出 A/B 通过率、故障类型、性能回归、恢复行为与发布建议草稿。
+## 3.4 后续可复用场景
+返修问题复现：将客户现场症状转换为可重复执行的验证流程。
+长时间稳定性：跨夜、跨周执行，异常后自动续跑。
+电源状态回归：冷启动、热重启、休眠、休眠恢复、整机断电。
+固件发布门禁：新版本必须通过指定的 Golden Suite。
+多设备并行：同一固件在多块 DUT 上运行并比较离群样品。
+# 04  端到端业务流程
+目标是形成“准备—执行—异常—结果”的闭环，而不是堆叠命令。
+图 1  端到端无人值守闭环
+## 4.1 任务准备阶段
+资产绑定：测试主机、DUT 序列号、固件包、主板/BIOS、OS、驱动、测试工具版本。
+安全检查：确认 DUT 位于允许破坏性测试的白名单，禁止对系统盘执行 Format/Sanitize。
+环境指纹：测试前生成不可变快照，保证 A/B 对比条件一致。
+资源锁：同一 DUT、测试主机、仪器和电源模块不能被并发占用。
+测试计划：明确循环次数、超时、重试、恢复策略、通过门槛和停止条件。
+## 4.2 自动执行阶段
+调用厂商刷固件工具，并验证刷写后的版本、槽位与激活状态。
+执行客户现有 Python、Shell、PowerShell、fio、nvme-cli、PyNVMe3 或商用平台命令。
+持续采集 Agent 心跳、系统日志、设备日志、温度、测试输出与画面状态。
+在每个关键步骤创建检查点，保证恢复后可以安全续跑。
+记录所有命令的模板、参数、发起者、时间与返回状态，满足审计要求。
+## 4.3 异常处置阶段
+异常类型
+识别信号
+默认处置
+测试脚本失败
+进程退出、断言失败、结果文件缺失
+保存上下文，按策略重试或标记脚本失败。
+Agent 失联
+心跳超时，但带外控制器在线
+先软恢复，再 Reset，最后整机断电。
+主机 OS 故障
+蓝屏/内核崩溃/启动失败
+保存画面与串口，带外重启并等待恢复。
+DUT 未枚举
+OS 与 PCIe/NVMe 探针均未发现设备
+记录掉盘证据，执行限定次数恢复。
+数据完整性失败
+哈希/读回比较不一致
+立即冻结现场，停止覆盖性动作，进入高优先级。
+基础设施故障
+网络、存储空间、电源控制器或测试工具异常
+分类为 INFRA_FAILURE，不进入 DUT 缺陷统计。
+## 4.4 结果闭环阶段
+自动生成 Evidence Bundle，保证关键字段完整且可追溯。
+对相似失败进行签名与聚类，避免同一问题重复提单。
+比较固件 A/B 在通过率、掉盘、数据错误、延迟、温度及恢复行为上的差异。
+生成工程报告、管理摘要和 Jira/禅道缺陷草稿。
+将已确认问题沉淀为回归用例，持续扩大 Golden Suite。
+# 05  产品与技术总体架构
+架构要保证“主机挂了，系统仍然有眼睛、有手、有记忆”。
+图 2  FlashOps Regression 总体架构
+## 5.1 五层架构
+层级
+核心模块
+职责
+交互与集成层
+Web 控制台、Open API、CLI、企业系统连接器
+任务配置、状态查看、报告、CI/CD 与缺陷系统接入。
+控制平面
+工作流引擎、调度器、资产中心、策略中心
+编排任务、资源锁、权限、安全门禁、检查点与版本比较。
+执行平面
+Windows/Linux Host Agent、工具适配器
+执行命令、采集日志、管理进程、调用客户工具。
+带外平面
+树莓派/工业控制器、Reset/Power/HDMI/传感器
+主机失联后仍可观察和恢复，形成第二控制通道。
+证据与智能层
+事件总线、对象存储、指标库、规则引擎、AI
+统一时间线、失败分类、聚类、解释、报告与复现建议。
+## 5.2 关键设计原则
+控制面与数据面分离：任务状态不能只存在于测试主机本地。
+双通道观测：Host Agent 与带外控制器相互校验，避免单点误判。
+事件溯源：关键状态变化以事件追加方式记录，方便重建完整时间线。
+适配器优先：任何测试工具都通过标准 Adapter 接口接入。
+默认本地化部署：固件、日志和厂商私有信息不离开客户网络。
+安全默认拒绝：未绑定 DUT、未授权命令、未通过预检时不执行危险动作。
+## 5.3 核心领域对象
+对象
+关键字段
+用途
+DUT
+型号、序列号、容量、固件、BDF、健康信息、标签
+防错盘、资产追踪与版本比较。
+Test Host
+主板、BIOS、CPU、OS、内核、驱动、Agent 版本
+固定环境与兼容性归因。
+Firmware Artifact
+版本、哈希、签名、适用型号、刷写工具
+确保固件包可信且可审计。
+Workflow
+步骤、参数、循环、条件、超时、恢复策略
+将 SOP 变成可执行状态机。
+Run
+环境快照、输入、状态、事件、结果、操作者
+一次完整测试任务。
+Failure Signature
+错误码、日志特征、步骤、设备状态、恢复结果
+聚类、去重与复现。
+Evidence Bundle
+日志、指标、截图、命令、版本、时间线
+缺陷分析与审计交付。
+# 06  软件开发方案
+MVP 先做可靠状态机和执行代理，不先做复杂微服务。
+## 6.1 推荐技术栈
+模块
+MVP 推荐
+演进建议
+前端
+Next.js + React + TypeScript + ECharts
+后续增加实验室拓扑、实时画面与低代码流程编辑器。
+控制平面 API
+FastAPI + Python
+规模化后拆分调度、资产、报告和连接器服务。
+任务执行
+显式状态机 + PostgreSQL 持久化；Redis 队列
+任务复杂度上升后评估 Temporal 等持久工作流引擎。
+Host Agent
+Python/Go 混合；Windows Service / systemd
+关键执行与心跳可逐步迁移到 Go，提高单文件部署与稳定性。
+实时通信
+WebSocket / Server-Sent Events
+多节点后引入 NATS 或 Kafka 作为事件总线。
+数据存储
+PostgreSQL + MinIO/本地对象存储
+高频指标增加 ClickHouse 或时序库。
+部署
+Docker Compose 私有化单机部署
+企业版支持 K3s/Kubernetes 与离线升级。
+说明：技术栈是工程建议，不构成必须绑定；首版优先减少运维复杂度。
+## 6.2 Host Agent 必备能力
+注册与身份：每个 Agent 使用唯一证书或密钥，绑定测试主机资产。
+命令执行：支持白名单模板、参数校验、工作目录隔离、超时与进程树终止。
+日志采集：stdout/stderr、Windows Event Log、dmesg/journal、NVMe 日志、工具输出。
+设备探针：周期检查 DUT 枚举、BDF、固件版本、SMART、温度及链路状态。
+心跳与健康：上报 CPU、内存、磁盘空间、网络、Agent 状态和任务阶段。
+检查点：每个步骤完成后持久化输出，重启后可安全恢复。
+自更新：企业内网签名包升级，支持回滚。
+## 6.3 工作流引擎
+工作流必须是确定性的结构化配置，而不是让大模型自由生成并直接执行命令。核心语义包括：步骤、循环、条件、并行、超时、重试、补偿动作、检查点、资源锁和安全级别。
+能力
+MVP
+企业版
+步骤类型
+命令、脚本、HTTP、等待、设备检查、重启
+仪器控制、子流程、人工审批、动态矩阵。
+循环与条件
+固定次数、通过/失败分支
+基于指标和风险的自适应循环。
+恢复
+从最近安全检查点继续
+跨节点迁移、测试环境重建。
+版本管理
+YAML/JSON + Git 哈希
+可视化编辑、审批、发布与回滚。
+资源管理
+主机/DUT 独占锁
+仪器池、许可证池、多实验室调度。
+## 6.4 Adapter SDK
+适配器是产品扩张的关键。统一接口应至少包含 discover、precheck、execute、collect、cancel、health 和 normalize_result。每个工具的原生输出被转换为统一事件与结果模型。
+class ToolAdapter:    def discover(self, context) -> Capabilities: ...    def precheck(self, context) -> CheckResult: ...    def execute(self, step, context) -> ExecutionHandle: ...    def collect(self, handle) -> EvidenceArtifact: ...    def cancel(self, handle) -> None: ...    def health(self) -> HealthStatus: ...    def normalize_result(self, raw) -> UnifiedResult: ...
+## 6.5 首版页面结构
+页面
+关键内容
+任务中心
+创建任务、队列、实时进度、阶段、预计剩余循环、紧急停止。
+资产中心
+测试主机、DUT、固件包、工具版本、带外控制器、标签。
+工作流中心
+SOP 模板、版本、参数、危险级别、审批记录。
+实时运行
+命令、心跳、设备状态、日志流、画面、温度、恢复动作。
+失败中心
+失败签名、相似运行、时间线、证据包、复现建议。
+版本对比
+固件 A/B 通过率、问题类型、性能和稳定性差异。
+报告中心
+工程报告、管理摘要、缺陷单、导出与审计。
+## 6.6 安全架构
+控制点
+要求
+DUT 绑定
+危险任务必须绑定序列号、BDF/设备路径与允许测试标签，多信号一致才执行。
+命令模板
+Format、Sanitize、固件刷写等命令只能来自签名模板，参数受 schema 限制。
+系统盘保护
+预检检测挂载点、启动盘和分区，命中系统盘立即拒绝。
+权限分级
+查看、执行、编辑流程、批准危险动作、发布门禁分离。
+审计
+记录操作者、审批者、命令模板版本、输入参数、结果和撤销动作。
+紧急停止
+Web、物理按钮与带外控制器均可触发，停止后进入安全状态。
+# 07  硬件与带外控制方案
+硬件的价值是“主机死了以后系统仍能观察和操作”，而不是做一个漂亮盒子。
+## 7.1 MVP 硬件拓扑
+部件
+建议形态
+首版作用
+测试主机
+标准 x86 Windows/Linux 台式机或服务器
+提供原生 M.2/U.2 接口，运行真实测试负载。
+带外控制器
+树莓派 5 / CM4 或工业 Linux 控制器
+独立网络、心跳、Power/Reset、HDMI 采集、传感。
+确定性 MCU
+可选 RP2040/STM32
+执行看门狗、精确按键脉冲和紧急停止。
+电源控制
+首版控制整机 AC/ATX；DUT 独立断电优先采购成熟模块
+避免早期陷入高速信号与供电时序。
+画面采集
+USB HDMI 采集卡
+在 Agent 未启动或蓝屏时仍可留证。
+环境传感
+温度传感器；后续电压/电流
+关联温度与故障，验证测试环境。
+## 7.2 恢复阶梯
+通过 Agent 执行优雅停止或软重启。
+通过操作系统远程管理通道执行重启。
+带外控制器触发主板 Reset。
+带外控制器模拟 ATX 长按关机并重新开机。
+控制整机 AC 断电并等待安全间隔后上电。
+超过限定次数仍失败则冻结现场并停止自动恢复。
+## 7.3 为什么不在首版自研 M.2 Gen5 电源夹层板
+直接位于 PCIe Gen5 数据路径的硬件会引入信号完整性、连接器、时钟、复位、电源时序和热设计风险。ULINK 的 PSPA+ Gen5 已经公开支持 DUT 独立供电控制、电流/电压测量、PERST#、CLKREQ#、PLN#/PLA#、PWDIS# 与 SMBus；Quarch 也提供面向 SSD/PCIe 的电源和故障注入模块。[3][8] 首版应优先适配成熟模块，在软件闭环和客户需求被验证后再决定是否自研。
+## 7.4 硬件演进路线
+阶段
+硬件范围
+判断门槛
+H0 PoC
+树莓派 + 继电器/智能电源 + ATX/Reset + HDMI + 温度
+证明自动恢复和留证。
+H1 工程样机
+隔离型 Power/Reset HAT、看门狗、物理急停、标准线束
+至少 3 个客户场景反复需要。
+H2 工业控制器
+金属机箱、宽温、电气保护、远程升级、模块化端口
+进入客户实验室长期运行。
+H3 DUT 电源模块
+只在有硬件团队和明确接口需求后开发
+商业模块成本或能力成为规模化瓶颈。
+H4 多节点机柜
+统一供电、网络、画面、环境与资产管理
+扩展至兼容性循环测试柜。
+# 08  AI 与故障智能方案
+先建立可解释的规则与数据结构，再让 AI 提升工程师阅读和决策效率。
+## 8.1 AI 的正确位置
+AI 可以做
+AI 不可以直接做
+把自然语言 SOP 草拟为结构化流程
+不经规则校验直接执行命令
+归并几万条日志并提取关键时间点
+凭空判断某块 SSD 必然损坏
+根据证据给出根因候选排序
+独立批准固件发布
+生成工程报告、管理摘要和缺陷单
+自由生成 Format/Sanitize/刷固件参数
+推荐下一轮验证变量与复现步骤
+绕过权限、DUT 绑定和安全门禁
+## 8.2 三层智能架构
+层级
+方法
+职责
+第一层：确定性规则
+阈值、状态机、签名、环境一致性校验
+判断设备是否掉线、数据是否错误、恢复是否成功、故障属于哪一大类。
+第二层：统计与异常检测
+变化点、基线偏离、聚类、离群检测
+发现性能退化、异常个体和重复失败。
+第三层：大模型
+RAG、结构化工具调用、证据引用
+解释日志、生成摘要、建议复现、撰写报告。
+## 8.3 失败签名
+失败签名不应只使用错误码，而应组合：工作流步骤、主机状态、DUT 枚举状态、关键日志模板、错误码、温度/延迟变化、恢复结果、固件和环境指纹。签名用于聚类、去重、相似问题检索和版本回归判断。
+failure_signature = hash(  workflow_step,  normalized_error_codes,  log_templates,  host_state,  dut_enumeration_state,  data_integrity_state,  recovery_outcome,  environment_fingerprint)
+## 8.4 自动复现策略
+固定所有环境变量，按原流程完整重跑一次，确认偶发性。
+裁剪为失败前后的最小步骤区间。
+每轮只改变一个变量，例如 APST、队列深度、负载、温度或电源状态。
+使用二分与风险优先策略减少组合数量。
+输出最短复现流程、触发概率、反例条件和所需证据。
+## 8.5 AI 输出规范
+每条推断必须关联具体 Run ID、时间点和证据文件。
+使用“已证实 / 高概率 / 待验证 / 无足够证据”四级置信表达。
+区分事实、推断和建议，不把建议写成结论。
+对涉及数据完整性、固件发布和安全动作的建议必须要求人工确认。
+模型不可访问未授权固件内容或跨客户数据。
+# 09  MVP 范围、开发里程碑与验收
+第一版只证明：一条真实固件回归 SOP 可以在无人值守条件下完成。
+## 9.1 MVP 必须具备
+Epic
+MVP 功能
+资产与安全
+测试主机、DUT、固件包登记；序列号绑定；系统盘保护；危险命令白名单。
+工作流
+YAML/JSON 流程；循环、条件、超时、重试、检查点；任务队列。
+Host Agent
+Windows/Linux 至少完成一个主平台；命令执行、日志采集、心跳、设备探针。
+带外恢复
+Power/Reset/AC 控制、恢复阶梯、画面或状态留证。
+测试接入
+客户私有刷固件工具 + 现有回归脚本；fio/nvme-cli 作为通用工具。
+证据与报告
+统一事件时间线、Evidence Bundle、固件 A/B 对比、HTML/PDF/缺陷草稿。
+运营监控
+实时任务状态、人工触碰记录、无人值守完成率、基础设施故障统计。
+## 9.2 12 周建议开发计划
+阶段
+周期
+核心输出
+退出条件
+D0 真实流程发现
+第 1—2 周
+脱敏 SOP、样例日志、固件 A/B、DUT 与验收标准
+每一步输入、输出、危险动作和失败处理均明确。
+D1 单机执行闭环
+第 3—4 周
+控制台、基础 Agent、命令执行、日志与资产绑定
+可稳定运行一次完整流程。
+D2 循环与恢复
+第 5—6 周
+状态机、检查点、100 次循环、软重启与 Reset
+Agent 重启后任务状态不丢失。
+D3 带外与证据
+第 7—8 周
+带外控制、画面/温度、统一时间线、Evidence Bundle
+模拟主机失联后可自动恢复并留证。
+D4 A/B 与分类
+第 9—10 周
+环境指纹、A/B 报告、失败分类、基础去重
+同一问题能够被识别为同类。
+D5 客户 PoC
+第 11—12 周
+真实 100 次回归、结果复盘、ROI 数据
+达到验收指标并形成下一版需求。
+## 9.3 MVP 验收指标
+指标
+建议目标
+说明
+人工触碰次数
+相对人工流程下降 ≥ 70%
+记录每次必须到现场或远程人工干预。
+正常任务完成率
+100 次循环中正常路径完成率 ≥ 99%
+排除人为断电等故障注入。
+自动恢复成功率
+对预设主机失联场景 ≥ 95%
+软恢复、Reset、AC 断电阶梯。
+证据包完整率
+关键字段完整 ≥ 95%
+版本、环境、日志、时间线、恢复动作。
+基础设施误报率
+< 5%
+不把 Agent/网络/磁盘满误判为 DUT 故障。
+危险动作安全
+0 次错盘、0 次系统盘破坏
+任何一次发生即判定 PoC 失败。
+A/B 结论时间
+测试结束后 10 分钟内产出初版报告
+不含专家最终签字。
+## 9.4 MVP 暂缓功能
+可视化低代码流程设计器；先用受控 YAML/JSON。
+大规模多租户与云端 SaaS；先做客户内网单租户。
+自研 DUT 独立电源板；先接商业模块或控制整机电源。
+复杂机器学习预测；先做规则、签名和基础聚类。
+全接口支持；首版锁定一种 SSD 形态与一套真实环境。
+# 10  竞品格局与差异化战略
+竞品强项已经很深，正确策略是成为它们之上的统一执行与运营层。
+竞品分析基于公开官网资料，核查截止 2026-07-27；“未强调”不等于竞品完全不具备。
+图 3  基于公开定位的竞品示意图
+## 10.1 竞品类别
+类别
+代表产品
+公开能力重点
+本方案关系
+深度存储测试平台
+ULINK DriveMaster、OakGate SVF/Enduro、SANBlaze SBExpress
+协议/命令、合规、性能、数据完整性、功耗、故障注入、多 DUT、自动化 API。[1]-[7]
+优先集成，不正面替代。
+物理层与电源故障设备
+Quarch
+热插拔、电源循环、功耗与复杂故障注入自动化。[8]
+作为带外执行设备接入。
+通用测试管理平台
+NI TestStand
+多语言模块、序列、并行、资源调度、报告、部署，并已加入 Nigel AI。[10]
+在存储垂直场景做更快开箱与更深证据模型。
+可编程测试框架
+PyNVMe3
+Python API、专用驱动、现成脚本，可在普通 x86/Ubuntu 上规模部署。[9]
+作为低成本执行器和开发者生态。
+企业自研平台
+Jenkins/Python/数据库/继电器
+高度定制、成本可控
+最现实的隐形竞品；用可靠性与产品化降低维护负担。
+## 10.2 ULINK
+ULINK DriveMaster 10 NVMe 公开支持 NVMe 2.0、协议与命令验证、回归和数据完整性测试、功耗测量、来料验证及多种侧带信号测试；其 NVMe Regression Suite 包含随机命令电源循环、数据比较电源循环、全盘扫描、MD5、JEDEC 工作负载等。PSPA+ Gen5 可在不关闭系统的情况下控制 DUT 供电，并支持电流/电压测量及多种侧带信号。[1][2][3]
+与 ULINK 的差异  不与其争夺协议测试深度。FlashOps 接管固件包、测试站、客户私有脚本、DriveMaster 任务、卡死恢复、跨工具证据、失败去重与版本发布闭环。
+## 10.3 OakGate
+OakGate 的公开产品由 Enduro 客户端、Linux 测试 appliance、SVF/Enduro 软件以及可扩展多盘位 enclosure 构成；软件覆盖验证、性能、协议、功耗、自动化、报告和 REST/Python API，并具有内置自动化、协议分析、错误注入和数据验证能力。[4][5]
+与 OakGate 的差异  OakGate 是强大的专业测试环境。FlashOps 的价值是把 OakGate 与客户其他 PC、脚本、固件工具、缺陷系统和带外恢复统一到一个任务与证据模型中。
+## 10.4 SANBlaze
+SANBlaze SBExpress-RM5 公开定位为 16 盘位 Gen5 NVMe 验证系统，支持合规、读写比较、错误注入、自定义命令、多盘控制、槽位供电、功耗测量、热插拔、温度监控，并提供 REST、XML/CLI 与 Python 接口。[6][7]
+与 SANBlaze 的差异  SANBlaze 已具备成熟自动化和 API，因此更适合作为 FlashOps 的高端执行器。FlashOps 重点提供实验室级资源编排、主机自救、工具间证据合并、失败签名和版本决策。
+## 10.5 Quarch
+Quarch 公开强调从简单热插拔循环到复杂数据故障注入的自动化，并被 PyNVMe3 文档用于 PCIe 电源控制和功耗监测。[8][9]
+与 Quarch 的差异  Quarch 提供“手和传感器”；FlashOps 提供“任务、状态、证据和决策闭环”。
+## 10.6 NI TestStand
+NI TestStand 是通用验证与制造测试管理框架，公开支持多语言代码模块、交互式序列、并行执行、资源调度、数据库与多格式报告、部署工具，并在 2026 年产品中强调 Nigel AI。[10]
+与 TestStand 的差异  不比通用编排能力，而比存储开箱能力：DUT/固件/主机环境模型、掉盘与数据完整性语义、带外自救、Evidence Bundle、固件 A/B 和最短复现。
+## 10.7 PyNVMe3 与自研脚本
+PyNVMe3 公开强调 Python、专用 NVMe 驱动、普通 x86/Ubuntu 部署和自动化流水线复用，代表低成本、高可编程的技术路线。[9] 这也是 FlashOps 最现实的价格竞争对手：客户可能认为“Jenkins + Python + 继电器”已经足够。
+与自研方案的差异  卖点必须是总拥有成本而非代码行数：稳定状态机、双通道自救、防错盘、证据模型、审计、失败去重、升级与长期维护。
+## 10.8 差异化能力清单
+差异化能力
+为什么有价值
+形成壁垒的方式
+工具中立的统一控制层
+客户无需推翻原有设备和脚本
+适配器 SDK、认证连接器、长期兼容性。
+测试环境自救
+解决真正阻碍夜间无人值守的问题
+Host Agent + OOB 双平面、恢复策略数据。
+Evidence Bundle
+减少“无法复现”和跨团队扯皮
+统一事件模型、时间线、证据完整性评分。
+基础设施/DUT 故障分离
+降低自动化误报和工程师反感
+探针交叉验证、故障分类数据集。
+自动缩小复现范围
+直接节省固件工程师时间
+失败签名、实验设计、历史触发条件。
+版本门禁与环境指纹
+把测试结果转成发布决策
+Golden Suite、A/B 基线、审计链。
+安全受控 AI
+既提高阅读效率，又不引入危险动作
+证据引用、工具权限、确定性执行。
+# 11  商业化与首批客户策略
+首批销售的不是“平台愿景”，而是一条可以立刻省人的真实流程。
+## 11.1 PoC 产品包
+项目
+PoC 内容
+范围
+1 个测试节点、1 种 DUT、1 份真实 SOP、2 个固件版本、100 次循环。
+交付
+控制台、Agent、带外恢复、脚本适配、Evidence Bundle、A/B 报告。
+客户投入
+测试主机、DUT、固件工具、脱敏 SOP、工程师每周固定评审时间。
+验收
+人工干预下降、安全零事故、证据完整、能够识别至少一种真实或注入故障。
+周期
+以 12 周 MVP 为上限，前 2 周完成流程发现和风险清单。
+## 11.2 商业模式建议
+收入项
+计费逻辑
+早期策略
+PoC 项目费
+按 SOP 适配和现场集成工作量
+保证客户投入资源，避免免费试用失焦。
+软件站点许可
+按测试节点或并发节点
+私有化年费，含基础升级。
+带外控制套件
+硬件销售或租赁
+首版使用成熟器件组合，后续标准化。
+高级连接器
+ULINK/OakGate/SANBlaze/Quarch/TestStand/私有工具
+按连接器或企业包计费。
+故障智能模块
+失败聚类、最短复现、质量图谱
+数据积累后作为高毛利模块。
+服务与维护
+现场部署、流程迁移、培训、SLA
+早期不可避免，但产品化比例要持续提升。
+## 11.3 ROI 计算
+年度价值 ≈  节省的值守工时+ 夜间/周末新增的测试机利用时间+ 减少的重复复现工时+ 提前发现回归所避免的返工成本+ 固件发布周期缩短带来的机会价值- 软件、硬件与集成成本
+## 11.4 首批客户获取方式
+从同学的真实行业关系中筛选 3 家中型团队，不先找平台最成熟的头部厂商。
+每家只问一个问题：“哪一种测试每周反复做，最需要人守着？”
+要求客户提供一份脱敏 SOP、一份最终报告、一次失败日志和允许测试的设备。
+先交付自动执行与证据，不先承诺 AI 根因准确率。
+用人工触碰次数、机器利用率、证据产出时间做业务复盘。
+## 11.5 不建议的销售表达
+不要说
+应该说
+“我们是 AI SSD 测试平台。”
+“我们让你现有的测试平台真正无人值守。”
+“AI 可以自动诊断所有故障。”
+“系统先保存完整证据，再给出可验证的候选原因。”
+“我们可以替代 OakGate/SANBlaze/ULINK。”
+“我们统一调度并放大你已经购买的工具价值。”
+“支持所有存储接口。”
+“首版专注一个真实接口和一条高频流程，随后复制。”
+“很快能做芯片级智能。”
+“先替代机械执行，数据积累后再深入固件和控制器协同。”
+# 12  数据壁垒与长期护城河
+代码可以被复制，长期运行产生的故障与环境关系数据更难复制。
+## 12.1 四类核心数据资产
+数据资产
+内容
+价值
+流程资产
+真实 SOP、参数边界、恢复策略、通过门槛
+缩短新客户上线时间。
+连接器资产
+私有工具、商业平台、固件刷写工具的适配
+形成行业进入门槛。
+故障资产
+失败签名、触发条件、最短复现、恢复结果
+提升去重、归因和重测能力。
+环境图谱
+固件、主机、BIOS、OS、驱动、DUT 与结果关系
+为未来兼容性测试柜和版本风险模型提供基础。
+## 12.2 护城河形成顺序
+先用可靠执行和安全能力获得进入实验室的资格。
+通过连接器和 SOP 积累形成交付速度优势。
+通过统一证据模型积累跨运行的失败签名。
+通过最短复现与自适应重测形成直接工程价值。
+最终建立固件—环境—故障—修复之间的质量知识图谱。
+## 12.3 数据治理原则
+默认每个客户数据完全隔离，模型训练需单独授权。
+固件二进制、私有日志解码器和内部缺陷不得进入公共模型。
+允许客户选择只保存特征、哈希和归一化失败签名。
+所有 AI 输出保留使用了哪些证据和模型版本。
+支持按项目、设备和时间执行数据保留与删除策略。
+# 13  未来产品规划
+路线应从“替代一个岗位动作”自然扩展到“存储实验室操作系统”。
+图 4  产品演进路线
+## 13.1 阶段规划
+阶段
+核心产品
+关键能力
+商业目标
+P0｜0—6 周
+真实 SOP PoC
+单机、单 DUT、100 次循环、基础留证
+证明人工触碰显著下降。
+P1｜6—12 周
+FlashOps MVP
+Agent、带外自救、A/B 报告、缺陷草稿
+完成首个付费或联合设计 PoC。
+P2｜3—9 个月
+企业版
+多节点、权限审计、适配器 SDK、私有化运维
+复制到 3—5 家客户。
+P3｜9—18 个月
+故障智能版
+失败图谱、聚类、最短复现、自适应重测
+从效率工具升级为研发决策工具。
+P4｜18—30 个月
+Storage LabOS
+多实验室、多工具、资源池与质量图谱
+形成平台收入与生态。
+P5｜并行扩展
+兼容性循环测试柜
+多主板/BIOS/OS/驱动矩阵与组合缩减
+进入 OEM、整机与工业兼容性市场。
+## 13.2 未来功能树
+方向
+未来能力
+调度规模化
+多节点、多 DUT、多实验室、许可证和仪器资源池、优先级与配额。
+自动复现
+步骤裁剪、变量控制、版本二分、局部矩阵展开、触发概率估计。
+质量图谱
+固件、主控、NAND/BOM、主机、BIOS、OS、驱动、故障与修复关系。
+发布门禁
+与 Git、CI/CD、固件仓库连接，Golden Suite 通过后才允许进入下一阶段。
+兼容性测试柜
+多真实主机的启动、休眠、驱动、系统更新与数据完整性矩阵。
+现场复现
+将实验室工作流下发到远程客户机器或边缘设备，回收统一证据。
+高级硬件
+在需求被验证后开发工业控制器、标准线束、多节点机柜和专用电源模块。
+## 13.3 长期不应偏离的方向
+长期原则  FlashOps 的核心始终是“把专业测试能力转化为无需人工值守的可靠产出”。即使未来进入兼容性、生产测试或芯片协同，也不应变成一家单纯卖测试脚本或硬件机箱的公司。
+# 14  团队配置、投入顺序与治理
+资金可以提高速度，但首要资源仍然是真实 SOP、样品和懂业务的工程师。
+## 14.1 最小核心团队
+角色
+建议人数
+职责
+产品/全栈负责人
+1
+产品定义、Web、后端编排、AI 工作流、客户沟通。
+存储领域负责人
+1
+测试方法、固件工具、日志解释、客户资源、验收标准。
+系统/Agent 工程师
+1
+Windows/Linux 服务、进程与系统控制、日志、安装升级。
+硬件/嵌入式工程师
+0.5—1
+带外控制、电气安全、线束、看门狗与工业化。
+测试/DevOps
+0.5—1
+故障注入、自身可靠性测试、部署、监控和回归。
+AI/数据工程
+早期兼职
+日志模板、聚类、RAG、模型评估；P3 后转核心。
+## 14.2 你与同学的建议分工
+你负责
+同学负责
+共同决策
+产品形态、交互、平台架构、AI、开发推进、Demo 与材料
+真实 SOP、设备、固件工具、日志含义、行业客户、硬件资金
+目标场景、通过标准、首个客户、是否采购专业模块、定价与公司结构
+## 14.3 资金投入顺序
+先投入真实测试条件：测试主机、DUT、固件版本、工程师时间。
+再投入可靠带外控制与商业电源/故障模块，避免自研硬件拖慢软件闭环。
+第三投入产品化：Agent 稳定性、安全、审计、部署与连接器。
+客户需求稳定后，再投入自研 PCB、工业机箱和多节点硬件。
+有持续运行数据后，再扩大 AI 和数据团队。
+## 14.4 项目治理
+每个功能必须对应减少的人工动作或提高的证据质量。
+每两周用真实测试机进行一次端到端故障演练。
+危险命令、安全事故和数据丢失拥有最高优先级，不能用“先跑起来”豁免。
+任何 AI 功能上线前必须有离线评估集与错误示例。
+首个 PoC 期间禁止大规模扩展需求，优先完成一个闭环。
+# 15  风险清单与应对策略
+这个项目最大的风险不是模型效果，而是测试系统自身不可靠或不安全。
+风险
+影响
+应对
+缺少真实 SOP
+做出看似完整但没人使用的通用平台
+立项前必须拿到流程、日志、报告和测试设备。
+误操作错盘
+数据损失、项目直接失去信任
+多重 DUT 绑定、系统盘保护、命令模板、审批和物理标签。
+自救系统不可靠
+无人值守名不副实
+双通道心跳、分级恢复、恢复上限、定期故障演练。
+商用工具无法集成
+价值被局限在自研脚本
+先验证 CLI/REST/Python 能力；必要时采用 UI 自动化作为过渡。
+客户私有日志封闭
+AI 诊断能力受限
+先做证据与流程；由客户提供解码器插件，不依赖原始语义。
+基础设施误报过高
+工程师不再相信自动化
+建立 INFRA_FAILURE 分类、探针交叉验证与平台自监控。
+AI 过度承诺
+错误结论影响发布与质量
+证据引用、置信等级、人工门禁、禁止危险工具权限。
+销售周期长
+资金消耗、难以快速验证
+先做设计合作伙伴和单 SOP 付费 PoC。
+过早自研高速硬件
+投入大、调试周期长、无法证明需求
+成熟商业模块优先，需求和规模明确后再开发。
+被客户自研替代
+一次性项目、续费弱
+持续强化连接器、运维、安全、数据图谱和跨站点能力。
+# 16  立即行动清单
+下一步不是继续讨论概念，而是拿到一条真实流程。
+## 16.1 向同学索取的材料
+一份最耗人、步骤固定、每周重复的固件回归 SOP。
+一份脱敏后的人工测试报告和对应原始日志目录。
+两个可刷写的固件版本，最好一个为基线、一个存在已知差异。
+一块或多块允许反复写入、重启和破坏性测试的 SSD。
+一台可长期占用的 Windows 或 Linux 测试主机。
+厂商刷固件工具及最小使用说明。
+一名愿意每周固定评审的存储验证工程师。
+## 16.2 第一次工作坊议程
+时段
+议题
+产出
+0—30 分钟
+逐步走一遍当前人工流程
+现状流程图与角色分工。
+30—60 分钟
+标记等待、重复、人工判断、危险动作
+可替代动作清单与不可替代判断。
+60—90 分钟
+复盘最近一次真实失败
+证据缺口与恢复路径。
+90—120 分钟
+定义 PoC 场景和验收指标
+首个工作流、测试设备、目标数据。
+## 16.3 可直接发送给同学的话
+沟通模板  你们公司里有没有一种固件测试，每周反复做，步骤基本固定，需要人刷版本、跑脚本、重启、守机器、收日志和填报告？你给我一份脱敏 SOP、一份真实报告、两个固件版本和一台测试机。我先做一个可以无人值守执行、机器卡死自动恢复、失败自动留证、最后输出 A/B 报告的 PoC，不碰你们核心算法，也不要求替换现有测试工具。
+## 16.4 立项决策门槛
+满足条件
+不满足时的处理
+能够获得真实 SOP 和固定评审工程师
+暂停产品开发，只做流程访谈。
+有允许破坏性测试的 DUT 和测试主机
+先准备实验环境，不做软件假 Demo。
+人工流程确实每周高频重复
+否则寻找更高频场景。
+PoC 指标可以量化人工触碰与完成率
+不能只以“页面好看”验收。
+客户接受本地部署和必要的系统权限
+否则明确安全边界与接入方式。
+# 附录 A  示例工作流
+结构化流程只描述意图和受控参数，实际命令来自签名模板。
+workflow: firmware_ab_power_state_regressionversion: 1.0safety_level: destructive_test_dut_onlyresources:  host: lab-win-01  dut_serial: SSD-TEST-00017  oob_controller: oob-01matrix:  firmware: [FW_A, FW_B]steps:  - precheck_environment  - verify_dut_identity  - flash_firmware:      artifact: ${firmware}  - verify_firmware_version  - write_known_pattern:      size_gb: 20  - repeat:      times: 100      steps:        - run_io_profile:            profile: mixed_4k_qd32            duration_sec: 300        - collect_nvme_logs        - reboot_or_sleep_cycle:            mode: hibernate        - wait_for_host:            timeout_sec: 240        - verify_dut_enumeration        - verify_known_pattern      on_failure:        - freeze_evidence        - oob_recovery:            ladder: [soft_reboot, reset, ac_cycle]        - retry_from_checkpoint:            max_attempts: 2  - compare_with_baseline  - generate_reportrelease_gate:  data_integrity_errors: 0  dut_missing_events: 0  infrastructure_false_positive_rate: < 0.05
+# 附录 B  Evidence Bundle 字段
+每个失败必须能够被另一个工程师独立理解和重放。
+分组
+字段
+身份
+Run ID、项目、DUT 型号/序列号、固件、主机、操作者、工作流版本。
+环境
+主板、BIOS、CPU、内存、OS、内核、驱动、工具版本、测试参数。
+时间线
+步骤开始/结束、命令、状态变化、心跳、设备枚举、恢复动作。
+设备证据
+Identify、SMART、Error Log、Telemetry/Persistent Event Log（若支持）、链路状态。
+主机证据
+Windows Event Log、BSOD/转储、dmesg、journal、服务状态、系统资源。
+测试证据
+stdout/stderr、结果文件、fio/PyNVMe/商用平台报告、哈希与数据校验。
+带外证据
+Power/Reset 动作、HDMI 截图/视频、温度、电压/电流（若支持）。
+分析
+故障分类、失败签名、相似运行、重现概率、候选原因、建议下一步。
+完整性
+文件哈希、生成时间、缺失字段、证据包版本、数字签名。
+# 附录 C  失败分类体系
+先准确判断“哪里坏了”，再判断“为什么坏”。
+代码
+含义
+示例
+INFRA_NETWORK_FAILURE
+实验室网络或控制网络故障
+交换机断连、DNS/SSH 不可用。
+INFRA_STORAGE_FAILURE
+证据存储或测试主机系统盘问题
+磁盘满、对象存储不可写。
+OOB_CONTROLLER_FAILURE
+带外控制器自身故障
+控制器失联、继电器无响应。
+TEST_TOOL_FAILURE
+测试工具或许可证故障
+DriveMaster/TestStand/PyNVMe 进程异常。
+TEST_SCRIPT_FAILURE
+客户脚本逻辑或依赖问题
+参数错误、断言错误、文件缺失。
+HOST_OS_FAILURE
+操作系统级故障
+蓝屏、内核崩溃、启动循环。
+DUT_ENUMERATION_FAILURE
+DUT 未识别或掉盘
+PCIe/NVMe 枚举消失。
+DUT_COMMAND_FAILURE
+NVMe 命令返回异常
+超时、状态码错误、重置失败。
+DUT_DATA_FAILURE
+数据完整性异常
+读回不一致、哈希错误。
+DUT_PERFORMANCE_REGRESSION
+性能相对基线显著下降
+P99 延迟或带宽超出阈值。
+DUT_THERMAL_FAILURE
+温度或热降速异常
+达到阈值后掉速或超时。
+RECOVERY_FAILURE
+规定恢复阶梯未恢复
+Reset 和 AC Cycle 后仍不可用。
+UNKNOWN
+证据不足或多因素耦合
+需要工程师进一步分析。
+# 附录 D  公开资料来源
+竞品与技术生态信息优先采用厂商和标准组织的官方资料。
+[1] ULINK — DriveMaster 10 NVMe  https://ulinktech.com/products/drivemaster-10-nvme/
+[2] ULINK — NVMe Protocol & Regression Test Suites  https://ulinktech.com/products/ulink-nvme-test-suites/
+[3] ULINK — PCIe-SSD Power Adapter Plus Gen5  https://ulinktech.com/products/pcie-ssd-power-adapter-plus/
+[4] Teledyne LeCroy — OakGate SSD Test and Validation Solutions  https://www.teledynelecroy.com/ssdtesting/oakgate-ssd-test-solutions.aspx
+[5] Teledyne LeCroy — SVF/Enduro SSD Testing Software  https://www.teledynelecroy.com/ssdtesting/svf-enduro-software.aspx
+[6] SANBlaze — SBExpress-RM5 NVMe Gen5 Test System  https://www.sanblaze.com/sbexpress-rm5
+[7] SANBlaze — REST Interface  https://www.sanblaze.com/rest-interface
+[8] Quarch — Data Center & AI Solutions / Fault Injection  https://quarch.com/solutions/data-center-ai-solutions/
+[9] PyNVMe3 — Developer’s Guide and User Guide  https://pynv.me/ssd/pynvme3-developers-guide/
+[10] NI — TestStand  https://www.ni.com/ja/shop/electronic-test-instrumentation/application-software-for-electronic-test-and-instrumentation-category/what-is-teststand.html
+[11] NVM Express — Error Reporting, SMART, Telemetry and Persistent Event Log  https://nvmexpress.org/resource/features-for-error-reporting-smart-log-pages-failures-and-management-capabilities-in-nvme-architectures/
+[12] NVM Express — Open Source Software / nvme-cli  https://nvmexpress.org/drivers/open-source-software/
+[13] Linux Kernel Documentation — NVMe Fault Injection  https://docs.kernel.org/fault-injection/nvme-fault-injection.html
+注：竞品功能、版本和产品组合会持续变化，正式商务判断前应向厂商索取最新报价、数据表与演示。
+# 结语  最终建议
+先把一个真实流程跑通，再决定公司要做多大。
+最终立项结论  值得做，但必须以真实 SOP 为起点。第一件产品不是“通用存储 AI 平台”，而是“固件回归值守机器人”：工程师配置一次，系统无人值守完成 100 次循环，卡死能自救，失败自动留证，最后输出固件 A/B 结论。这个闭环成立后，再扩展到多节点、故障智能和兼容性循环测试柜。
+这条路线与现有专业测试厂商并不矛盾。相反，专业平台越多、客户工具越碎片化，统一控制、无人值守和证据闭环的价值越高。项目真正的护城河将来自长期积累的连接器、真实 SOP、故障签名、恢复策略和环境图谱，而不是一个 AI 对话框。

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

@@ -0,0 +1,802 @@
+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. 项目判断与战略边界
+7. 硬件方案与演进路径
+2. 行业痛点、用户与价值模型
+8. 竞品分析与竞争策略
+3. 产品定位与主打卖点
+9. 差异化、护城河与品牌表达
+4. MVP 产品定义
+10. 产品路线与未来规划
+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，企业既有标准操作流程。
+— 文档结束 —