总述
Spectronaut 技术总述按“软件定位、工作流、结果解释、交付、自动化、附录判读”的顺序展开， 对应 discovery DIA 从输入到交付的完整结构。
总述
Spectronaut 的正文从软件角色开始，随后进入输入资源、工作流选择、结果解释、交付体系、设置与附录判读。这条路线把软件结构、数据结构和交付结构放在同一条主线里。
Spectronaut 不是单一分析工具，而是把样本前处理、质谱采集、计算分析、统计解释和结果交付串联起来的软件平台。上游样本、采集方法、数据库文件和下游报表结构都会直接影响最终结果。
| 模块 | 核心问题 | 对应判断 |
|---|---|---|
| 软件角色 | Spectronaut 在蛋白质组流程中解决什么核心问题 | 能区分 discovery 平台和 targeted 验证平台的职责 |
| 数据与数据准备 | run、library、FASTA、GO 各自会影响什么 | 能从输入数据、谱库和数据库层解释结果差异的来源 |
| 工作流主线 | 该走 library-based、directDIA 还是 PTM / Method Evaluation | 能按项目目标选择工作流，而不是只会点按钮 |
| 结果解释 | 结果矩阵够不够稳，哪些机制解释站得住 | 能区分质量层图和机制层图 |
| 交付与平台 | 怎样把结果变成可复用的 schema、QC 和 pipeline 文件 | 能解释 report / QC / pipeline 的业务闭环 |
| 标准化与自动化 | 怎样让多项目、多用户分析保持一致 | 能理解 schema、Databases、CLI 和 XIC DB 的平台意义 |
第一部分
Spectronaut 的角色是 discovery DIA 平台。它面对高通量、多条件、多重复和长时间运行的蛋白质组项目，因此从设计上就属于平台型软件。高性能本地磁盘、Search Archive、统一目录和长期 QC 历史都属于这一定位的直接延伸。
从产品交付角度看，Spectronaut 位于“发现候选”的核心位置。上游来自易肽试剂盒、Auto 工作站、不同仪器平台和采集方法；下游则可能通向 OmicsCloud、内部数据库、统计脚本和 SpectroDive 的 targeted 验证。library、FASTA、GO、report schema 与 XIC export 因此共同进入同一套知识体系。
软件管理从第一课就需要建立。样本一旦超过几十个 run，单次分析就会同时牵涉命名规则、统计结构、QC panel、报表模板和实验记录留存。
| 软件 / 环节 | 更擅长回答什么问题 | Spectronaut 的核心职责 |
|---|---|---|
| 前处理 / 采集 | 样本质量、峰形、采集策略是否稳定 | 没有它们，软件很难产出可靠 discovery 结果 |
| Spectronaut / discovery | 哪些 proteins / peptides / PTM 值得进一步解释 | 它把高通量 DIA 结果组织成可统计、可交付、可管理的系统 |
| SpectroDive / 验证 | 哪些候选进入 targeted 验证 | 它承接 discovery 结果，但不能替代 discovery 层的广覆盖分析 |
| OmicsCloud / 数据平台 | 结果如何共享、归档和协同 | 如果没有 Spectronaut 的结构化输出，这层很难建立统一的数据结构和报告规范 |
第二部分
从技术结构看，所有内容都可以先压缩为四类输入：raw files、spectral library、FASTA / protein database、GO / gene annotation。这四类输入共同决定软件能力边界、后分析解释深度，以及结果能否无缝进入下游统计或云平台。
library 决定进入分析时携带的先验知识。高质量且与项目匹配的 library 会提升识别稳定性并强化长期可比性；过时、不匹配或字段质量不统一的 library 则会把错误先验带进整个流程。
FASTA 与 GO 常被低估。FASTA 决定蛋白注释、搜索空间与蛋白推断；GO 决定后分析的富集解释是否顺畅。Databases Perspective、Library Perspective 与 Report Perspective 因此共同构成同一套上游数据库、谱库和注释结构。
canonical FASTA、non-canonical FASTA、免疫肽或开放搜索空间，并不只是“多加几条序列”的差别。数据库边界一旦放宽，候选 precursor 集合、protein inference 路径与错误发现压力都会同步改变。数据库版本、cleavage rules、修饰命名、group 结构与 single-hit protein 处理因此必须一并固定，才能保证同类项目之间可复盘、可比较。
| 数据库结构 | 结果会发生什么变化 | 需要一起固定的规则 |
|---|---|---|
| Canonical FASTA | 蛋白注释和分组最稳定，对应常规 discovery 队列 | 固定 database 版本、protein inference、single-hit protein 策略 |
| Canonical + non-canonical FASTA | 候选 precursor 增多，shared peptides 与 group 结构变复杂 | 增加 per-group precursor FDR，并写清 non-canonical 分组逻辑 |
| 开放搜索 / peptidomics / unspecific | 搜索空间显著放大，经验错误压力上升 | 同步管理 cleavage rules、修饰命名、group 结构与蛋白层交付边界 |
如果 raw files 不变，但数据库从 canonical 扩展到 canonical + non-canonical，变化的不只是“多识别了一些 precursor”。shared peptides 的归属会改变，protein inference 的路径会改变，某些原本能被唯一支撑的蛋白会落入更复杂的 group 结构。此时即便 PG.Qvalue 仍然存在，蛋白层对象的含义也已经发生变化。
这类项目最容易出现的错误，是继续沿用旧项目的 single-hit protein 策略和数据库说明。更稳的写法是把 database 版本、group 结构、protein inference 规则与 single-hit protein 策略一并写入项目说明和 schema 版本。
| 输入 | 最直接影响什么 | 最常见误区 |
|---|---|---|
raw files | 识别数量、峰形、data completeness 与后续 QC | 把所有问题都归咎于软件，而忽略采集质量 |
spectral library | 先验知识质量、长期可比性与 search space | 简单理解成“有库一定更好” |
FASTA | 蛋白注释、推断和 search space | 只在建库时关心，忽略后续 report 与解释也依赖它 |
GO / gene annotation | 后分析富集和机制解释 | 等到结果出来才发现注释文件不完整 |
第三部分
分析主线由 library-based DIA、directDIA、PTM probing、Method Evaluation、directDIA+、conditions 与人工 refinement 共同组成。核心在于不同工作流的选择逻辑。directDIA 属于项目内自建知识库的 library-free 路线，先验知识来源与建库路线不同，但逻辑同样完整。
directDIA+ Fast / Deep 对应速度、深度和 search space 复杂度之间的权衡。Method Evaluation 对应 acquisition benchmark，PTM probing 对应更开放的修饰搜索空间。工作流一旦变化，结果解释和 FDR 压力也会随之变化。
Condition Setup 不只是设置 condition、reference、replicate 和 correction factor，而是在定义整个 differential abundance 的统计骨架。这里的设置会直接传递到后分析和报表层。
library-based DIA、directDIA、PTM probing 与 directDIA+ Deep 对应不同的先验知识与候选空间密度。workflow 一旦改变，precursor 集合的复杂度就会改变，FDR 的压力也会跟着改变。SP20 把 global precursor FDR 与 precursor FDR per group 放进主流程，目的正是让 discovery DIA 在更开放的搜索空间下仍然保持可解释的 precursor 层控制。
| 工作流 | 对应项目 | 最容易被误解成什么 |
|---|---|---|
library-based DIA | 已有高质量库、强调稳定和长期可比性 | 误以为只是“传统路线” |
directDIA | 无现成库、希望项目内自建知识库 | 误以为只是“没库时的简化版” |
directDIA+ Fast / Deep | 需要在速度和深度之间做权衡 | 误以为是简单的高低档按钮 |
PTM probing | 修饰空间不确定、需要开放探索 | 误以为所有项目都应默认开启 |
Method Evaluation | 比较采集方法、做 benchmark | 误以为对应常规定量项目 |
第四部分
Post Analysis 负责把 analysis 结果转化为可判断、可解释、可继续验证的证据。只有把 scoring histograms、PCA、volcano、heatmap、GO enrichment、data completeness 和 PTM plots 读清楚，结果矩阵才真正具备解释价值。
Post Analysis 分为两层。第一层是“结果可靠性层”，包括 scoring histograms、run identifications、data completeness、CV、normalization overlay 等，这些图回答的是结果矩阵是否稳定。第二层是“机制解释层”，包括 PCA、GO enrichment、GO clustering、volcano、heatmap、PTM vs protein fold changes 等，这些图回答的是稳定矩阵里出现了什么生物学结构。
Appendix 5 与 Appendix 7 共同补足 Post Analysis 与 Review 的读图层。附录承担的正是图谱解释与结果复核任务。
| 图层 | 当前重点 | 后续判断 |
|---|---|---|
| scoring / identifications / completeness | 矩阵稳不稳、识别是否分离、缺失值是否可接受 | 值不值得进入候选与机制解释层 |
| PCA / GO / clustering | 是否存在条件分离和稳定的功能结构 | 哪些机制线索值得继续讲述 |
| volcano / heatmap / PTM plots | 具体候选、差异模式和位点层结构 | 哪些分子优先进入后续验证或产品方案表达 |
第五部分
如果把 Analysis 视为“生产结果”的环节，那么 Report、QC 和 Pipeline 就是把结果沉淀为业务能力的环节。Report 负责把对象层和字段层组织成能被统计、可读、可交付的结构；QC 负责把单次结果放入时间维度和仪器维度；Pipeline 负责把单次项目推进到批量可运行状态。三者共同构成同一条“交付链”。
Report Perspective 真正难的地方，不是勾选列，而是理解 schema tree、column chooser、filters 和 preview 背后的对象层逻辑。PG、PEP、EG、FG、F、PTM 不只是字段前缀，而是不同问题的载体。QC Perspective 的难点也不只是看图，而是把 iRT kit、sample-specific QC panel、instrument history 和 analysis quality 放入长期监控视角。至于 Pipeline，它最常被误解为“为了更快”，其实手册强调的是顺序处理、多实验队列和结果留存，这更接近生产系统的稳定性问题。
一旦把这三部分理顺，XIC 导出数据库的意义也就会自然浮现。报表里的每一行并不是结果的终点，它还可能回连到真实 chromatogram。到这一步，软件已经不再只是 GUI，而变成了一个可以被平台、数据库和算法系统调用的分析接口。
PG.Qvalue 可以进入交付，并不意味着蛋白层风险天然等同于 precursor 层风险。protein inference 决定哪些 precursor / peptide 证据被汇总到 protein group，single-hit protein 策略则决定单条证据支持的蛋白是否保留。这两层一旦变化，蛋白层对象数量、经验错误比例与交付边界都会变化，因此 report schema、方法说明和项目结论必须把这三项一起固定。
| 如果当前项目属于 | 蛋白层交付最少应补充什么说明 | 不补充时最可能造成的误读 |
|---|---|---|
| 标准 canonical FASTA discovery | PG.Qvalue、protein inference 规则、single-hit protein 策略 | 把蛋白层列表误读成天然稳定且与 precursor 层完全同义 |
| non-canonical FASTA / immunopeptidomics | 再补 database 版本、group 划分和 per-group FDR 说明 | 不同数据库条件下的蛋白层结果被错误横向比较 |
| 开放搜索或深度探索性项目 | 再补 entrapment / 经验验证与结果使用边界 | 把探索性命中直接当成正式交付名录 |
交付前至少要回答四个问题：当前对象层是不是 Protein Group；数据库结构是不是与比较对象一致；protein inference 是否固定；single-hit protein 是按默认 stratified 策略保守控制，还是被人为放宽。只有这四个问题同时固定，PG.Qvalue 才具备真正可比较的上下文。
protein inference、non-canonical FASTA 与 single-hit protein 需要放在同一条规则链中理解。它们并不是三个独立开关，而是蛋白层结论能否进入项目结论、方法说明和对外报告的统一边界。
| 交付层 | 最先要建立什么 | 如果做对了，会沉淀成什么 |
|---|---|---|
| Report | schema、对象层级和字段选择规则 | 可复用的交付模板 |
| QC | 历史、仪器命名和长期监控维度 | 平台稳定性档案 |
| Pipeline | 顺序处理、队列和结果留存逻辑 | 可重复运行的生产流程 |
| XIC 导出数据库 | report 行与证据层的回连关系 | 可复核、可开发的数据接口 |
第六部分
进入多项目、多用户、多仪器环境后，核心问题会集中到默认设置、数据库版本和输出规则。FASTA 怎么管理、GO 怎么统一、custom modifications 如何留档、file name parsing 是否一致、reporting 输出是否统一、Search Archive 放在哪里、JSON override 谁能改、Exit Codes 如何接入调度器，都会直接影响软件稳定性。
Settings、Databases 与 Command Line 共同构成这一层能力。GUI 向导负责单次分析，schema、arguments file、pipeline mode 与 command-line 负责跨项目复用、统一输出与批处理运行。
标准化与自动化直接决定结果是否可重复、可审计、可长期比较。这一层已经属于平台能力本身。
| 需统一的对象 | 优先统一什么 | 不统一会怎样 |
|---|---|---|
| Databases / FASTA / GO | 版本、修饰命名和注释来源 | 不同人跑同类项目也会得到不同结构化结果 |
| schema / settings | routine、PTM、大队列、快筛等模板 | analysis 行为随人而变，难以复盘 |
| file naming / directories | 命名规则、Search Archive、results、temp 路径 | conditions 自动注释和结果留存会混乱 |
| CLI / arguments file / JSON override | 最小可运行命令模板和有限覆盖规则 | 始终停留在手工 GUI，无法进入 pipeline |
第七部分
Appendix 1-7 集中解释提取窗口、质量误差、图谱证据、run identifications、data completeness、LFQBench、PCA、volcano 与 heatmap 等核心读图语言。这一层决定结果能否被正确判断。
例如 volcano plot 需要同时结合 fold change、显著性与数据质量层；data completeness 需要连到 missing value、CV 与候选筛选稳定性；PDM、ion mobility overview、identifications per cycle 直接影响问题定位效率。
附录因此承担参数判读、图谱判读与结果复核三类任务，是 Spectronaut 判断能力的重要来源。
| 附录群 | 核心问题 |
|---|---|
| Appendix 1-4 | 理解 DIA、Pulsar、directDIA 与 library generation 的底层规则 |
| Appendix 5-7 | 训练 review、post analysis 和 plot 判读能力 |
| Appendix 8 | 建立字段字典和对象层解释语言 |
| Appendix 9 / XIC DB | 让结果回到 chromatogram 证据层并进入再开发 |
第八部分
workflow 属于方法选择，而不是功能按钮。directDIA、library-based、PTM probing 与 Method Evaluation 分别对应不同的 search space、目标与统计结构。
报表只是结果的结构化表达，report schema、对象层级与 XIC 证据共同决定结果解释强度。设置问题、环境问题与科学问题也需要分层判断，例如 data completeness 可能来自样本、采集、QC 或参数层。
附录中的设置说明与图谱解释承担最终的结果复核任务，不能从学习主线中剥离。
| 常见误区 | 更准确的理解 |
|---|---|
| “directDIA 一定更先进” | 它只是先验知识来源不同，不自动代表更对应你的项目 |
| “导出一张表就算结果交付了” | schema、对象层、QC 与 XIC 证据共同决定结果价值 |
| “data completeness 差一定是软件参数问题” | 也可能来自样本、采集和 QC 控制不足 |
| “附录只是补充，不影响主线学习” | 附录恰恰决定你能否真正读懂图和字段 |