3. 计算协同需求建模

在生物实验数据与计算协同平台中，最容易被低估的工程问题不是算力，也不是存储，而是三类角色之间的任务依赖没有被显式建模。实验人员掌握样本与湿实验上下文，计算人员负责流程实现与资源调度，数据科学家负责统计建模与结果解释。三者若只靠口头沟通和共享文件夹协作，就会出现“样本元数据缺失导致流程中断”“分析参数与实验设计不匹配”“结果无法回溯到原始孔位”等典型问题。本节的目标是把协作流程、角色边界和任务依赖转化为可建模、可校验的结构。

一、角色划分：不是按人分，而是按“责任域”分

协同需求建模的第一步，是明确每个角色对哪些数据对象和决策点负责。建议用“责任域”而非“岗位”来划分，因为同一人可能在不同任务中承担不同角色。

责任域划分后，需要为每个责任域定义最小可交付对象。例如实验人员交付的不是“原始数据文件夹”，而是“带 sample_id、batch_id、group、timepoint 四列的样本清单 + 仪器原始文件 + 质控备注”。计算人员交付的不是“跑完了”，而是“流程版本号 + 参数快照 + 中间矩阵 + QC 指标表”。数据科学家交付的不是“图”，而是“模型公式 + 分组变量来源 + 校正方法 + 可复现脚本”。

二、协作流程：以“数据契约”为交接点

三类角色的协作不应建模为线性流水线，而应建模为以数据契约为交接点的有向依赖图。数据契约是上下游之间约定的字段、格式、取值域和校验规则。例如实验人员与计算人员之间的契约可以定义为：

sample_manifest.tsv 必填字段：
sample_id    string  唯一，形如 S001
batch_id     string  形如 B01
group        enum    control | treat_low | treat_high
timepoint    int     单位 h，取值 0/6/24
raw_path     string  相对路径，指向 fastq 或 csv
qc_flag      enum    pass | warn | fail

计算人员在流程入口处先执行契约校验：字段是否齐全、枚举值是否越界、raw_path 是否存在、sample_id 是否重复。校验失败则任务状态置为 blocked，并生成缺失字段清单回传实验人员。这一步把“口头催数据”变成了可追踪的任务依赖。

三、任务依赖关系：用状态机表达“谁在等谁”

任务依赖的核心不是“先后顺序”，而是状态与阻塞条件。建议为每个任务定义五种状态：draft、ready、running、blocked、done。依赖关系体现为：下游任务只有在所有上游任务 done 且契约校验通过后才能进入 ready；任一上游 blocked，下游自动 blocked 并标注阻塞源。

下面这张图展示了三类角色围绕一次“处理组 vs 对照组差异分析”的协作依赖。图中实线箭头表示数据或交付物流向，虚线箭头表示校验或反馈回路，颜色区分角色责任域。

四、依赖建模的落地方式

把上述关系落到平台中，通常需要三张表：role（角色与责任域）、task（任务与状态）、dependency（任务间依赖与契约版本）。依赖表的关键字段包括 upstream_task_id、downstream_task_id、contract_version、blocking_condition。当实验人员更新样本清单时，系统根据 contract_version 判断哪些下游任务需要重新校验；当计算人员调整流程参数时，数据科学家的建模任务被标记为 stale，提示需要重新确认分组变量。

五、一个可执行的协作检查清单

在每次分析启动前，三类角色可按以下清单对齐，避免返工：

• 实验人员：样本清单字段是否齐全？group 与 timepoint 是否与实验设计表一致？qc_flag 是否已标注异常孔位？
• 计算人员：流程版本与契约版本是否匹配？参数快照是否已记录？QC 指标是否在预设阈值内？
• 数据科学家：分组变量来源是否明确？协变量是否完整？多重检验校正方法是否与实验设计匹配？
• 三方共同：本次分析对应的 contract_version 是否一致？阻塞任务是否有明确责任人和预计解决时间？

当这些依赖被显式建模后，协作就从“人找人”变成“状态驱动”。实验人员知道缺什么字段会阻塞哪一步，计算人员知道哪些参数变化会触发下游重算，数据科学家知道结果能否追溯到具体样本与批次。这正是计算协同需求建模要解决的核心问题：让角色边界清晰、让依赖可追踪、让每一次交接都有契约可依。