Spectronaut Workshop / 实操课页面

每个任务都需要明确三件事：输入是什么，改变的是哪一层对象，最终输出的是什么。Task 2 的输出是可解释的 workflow 决策，Task 5 的输出是一套与当前问题匹配的 report schema。

只要这三层结构明确，整条 discovery 工作流就能被重新组织出来。

• 确认 raw files、library 或 FASTA、GO annotation、Search Archive 和结果目录都位于清晰可追踪的位置。
• 确认本地高速盘、临时目录和 Search Archive 目录是否足够支撑大队列分析，而不是只够跑 demo。
• 确认这次是教学演示、方法评估还是正式 discovery 项目，因为这会直接影响后续 workflow 选择和交付标准。

• 已有高质量且样本匹配的 library 时，仍然不加判断地改走 directDIA，往往会削弱长期可比性优势。
• 项目目标是 acquisition benchmark 时，误把 Method Evaluation 当成常规定量 workflow，会让结果解释从起点就偏掉。
• 把 directDIA 简化成“版本更新后的默认路线”，会掩盖先验知识和 project-specific library 的真实价值。

• 完成 Condition Setup 后，不要只看颜色标签，而要用自然语言复述：哪个 condition 是 reference、哪些是 replicates、fractions 是否被正确标记、哪些 correction factor 会作用到 quantity 上。
• 如果这一步说不清，后面的 PCA、volcano、heatmap 和 report 中的比较结构都很可能被误解。

• 先看 scoring、completeness、CV、normalization 和对象层级 q-value，再进入 volcano 或 candidates，能够避免在不稳定的结果矩阵上提前放大生物学解释。
• 标准顺序是：质量层图先确认矩阵是否稳，再由机制层图判断结构是否成立，最后再进入候选优先级排序。

如果这批 run 同时使用了 canonical + non-canonical FASTA，先不要急着解释新增命中。第一步先确认当前 workflow 是否启用了对应复杂数据库的 precursor 层控制；第二步确认 scoring 与对象层级 q-value 是否仍然稳定；第三步再判断这些新增对象是否只停留在 precursor 层，还是已经被 protein inference 汇总到蛋白层。只有这三步都站稳，新增名录才具备继续解释的前提。

• 如果问题是蛋白层结论，就不该默认把 fragment 层字段全部导出给最终交付对象。
• 如果问题是位点项目或峰型复核，就必须知道何时下钻到 PTM Site、Elution Group 或 Fragment 层。
• 高质量 schema 不是字段越多越好，而是对象层、FDR 解释与当前项目的结论边界彼此一致。

如果项目使用了 non-canonical FASTA、开放搜索空间或放宽了 single-hit protein 保留策略，蛋白层名单不能只带一列 PG.Qvalue 就直接进入最终交付。更稳的做法是同步写明 database 结构、protein inference 规则与 single-hit protein 策略，并把这三项写进 report schema 对应的说明区或项目方法部分。

• QC 不是附加图，而是在问这次 run 放到长期历史里是不是仍然稳定。
• Pipeline 不是单纯加速，而是在问这套 schema、目录、输出和结果留存方式是否已经足够标准化，值得纳入生产流程。