重新思考CNV基线
当前进度
这段时间一直在联调前后端、做安全审计。说实话，对“上线”这件事我是有心理阴影的——人类数据，一旦有漏洞就是血本无归，所以在安全上花了远超“够用”的力气。
但某天突然反应过来：获客都还没开始做，我在防谁呢？ 一个用户都没有的阶段，把上线后的种种风险当成当下的头号问题，多少有点本末倒置。安全是要做的，但它不该是现阶段吞掉我最多精力的那块。想明白这点，节奏松了一些。
老问题：系统镜像又对不上了
前后端持续调整的副作用是——之前好不容易建好的系统镜像，和现在的流程又不适配了。接口动一动、流程改一改，镜像里固化下来的那套环境就慢半拍，又得找时间重新打磨一次。这件事在待办上已经躺了好几轮，每轮都因为“再改一点就去建”而推迟。
CNV基线的新思路
真正让我想单独写一篇的，是关于CNV基线的一个思路转变。
之前的方案：用户自建基线
CNV检测要准，需要一组覆盖背景做参照。我原来的设想很“较真”：要求用户自己上传10个正常样本，用它们构建基线，再拿这组基线去对真实样本做CNV calling。
出发点是好的——同批次、同探针的正常样本最能反映本组数据的覆盖偏好，做出来的CNV最真实。但实际想下去，问题很明显：
- 耗时：用户要凑齐10个正常样本，多数时候根本没有这么多对照可上传。
- 成本高：10个样本意味着10次的存储、10次的计算，平台和用户两边都不划算。
- 体验差：为了一个“配角”功能让用户承担这么重的前置工作，门槛太高。
新方案：预设基线 + 单样本加权调整
换了个角度想。大家做WES，探针虽然各家不同，但靶向的CDS区域本质上是同一批——差异不在“测哪儿”，而在“每组探针对同一区域的捕获效率”。
既然CDS区域是共通的，那我完全可以预先在平台侧建好一组通用基线作为背景，用户只需要提供1个正常样本。我把用户这一个样本赋以较高的权重，用它去调整预设基线，拟合出该用户本组探针的覆盖特征，最终形成“用户基线”。
旧方案： 10个正常样本 → 构建基线 → CNV检测
（耗时、高成本）
新方案： 预设基线（平台预建）
＋
用户1个样本 × 高权重
↓
用户基线 → CNV检测
这里有个关键判断：用户那一个样本，承担的不是“统计意义上的基线”，而是“校准锚点”。它的作用是告诉系统“我这组探针的捕获效率长这样”，而不是提供多样本的统计稳定性。所以给它高权重是对的——我要的就是它身上那份panel特异性，而不是把它当作十分之一的声音稀释进背景。
取舍：弱化CNV，聚焦SNP/InDel
得承认，这套方案在准确度上不如10个真实样本构建的基线。单样本加权再怎么调，也补不回多样本本该提供的统计冗余。
但这恰好和我对平台定位的判断对上了：云平台对CNV的支持本来就该弱化，重点还是SNP和InDel。 WES做CNV本就是“能看个大概”的范畴，硬要追极致准确，既不现实也不经济。把CNV做成“够用、顺手”的辅助能力，把真正的精度留给SNP/InDel，是更清醒的资源分配。
而且，只要求1个样本构建基线，用户体验上是质的提升——从“凑10个”到“给1个”，这个门槛的降低是实打实的。
这意味着什么
新思路落地，平台侧就多出两件事：
- 预先建立通用基线：用平台自己的参考数据，构建一组覆盖通用CDS区域的预设基线，作为所有用户的背景。
- 做出这套权重基线流程：把“预设基线 + 用户单样本高权重调整 → 用户基线”这条链路实现出来。
于是又绕回了开头那个老问题——系统镜像还得继续打磨。基线数据和这套流程都得固化进去，镜像不重建就没法跑通。看来这次是真的躲不过去了。
回头看，这一段其实是在做同一件事：不在不值得的地方死磕，把精力留给真正决定产品形态的东西。安全焦虑是这样，CNV的精度也是这样。