快了，转个弯就到
当前进度
天才程序员现在每天都在用codex对项目进行精修，真的真的很快就能上线了。项目最初定下的开发周期是一年（2026年），现在看来是能准时上线的。
说实话，每天看着代码一点点变好，这种感觉挺奇妙的。有时候一个函数改完，跑一遍测试，所有用例都通过，那种顺畅感会让人上瘾。但更多时候是改了A，发现B又冒出来问题，然后修B的时候又牵扯到C——这种连锁反应才是日常。不过好在整体方向是对的，每解决一个，离上线就近一步。
后知后觉：minibwa带来的成本思考
李恒大神上线了新的比对器minibwa，看预印论文速度比bwa-mem2还要快一倍。按照我的WES分析来说，总体分析时间大约是60分钟（32C64G的实例下运行），其中我之前用bwa-mem2比对的时间大概是12分钟，也就是说换成minibwa的话，比对可以压缩到6分钟。由于所有下游流程都在等比对结果，所以这个时间是可以直接折算到总时间上的，也就是说总体时间会下降到54分钟。
按我初步的定价，每分钟1积分，1积分1元来说，用户的实际支出会从单样本60元下降到54元。
更大的降本空间
其实还有一个巨大的给用户降本的空间，就是把现在的数据库从每次任务启动时的对象储存复制，调整成挂载云硬盘镜像，这会直接削减15分钟的开销。但是这个方案，我需要上量才能做，因为这相当于提高了我自己的运营成本🤐
技术选型的思考
这里其实有个技术选型的思考：minibwa虽然快，但它是新工具，社区支持和稳定性可能不如bwa-mem2。不过对于云平台来说，这种风险是可控的——如果出现问题，我可以快速回滚到bwa-mem2，用户体验上就是慢一点而已。但成本下降是实实在在的，用户每单能省6块钱，积少成多也是不小的数字。
不过，在项目上线前，我都不会考虑切换到minibwa。原因很简单：现在每引入一个新工具，都需要重新测试、验证、调整流程，这会增加测试时间，进一步拖延项目的开发进度。上线前的最后阶段，稳定性比性能优化更重要。等项目正式上线、流程跑通之后，再考虑切换到minibwa也不迟。
另外，miniwdl目前开发到v0.7版本，仍然在快速迭代过程中。等正式版发布后，再考虑切换到minibwa，这样也能确保工具的稳定性和兼容性。
至于云硬盘镜像的方案，这涉及到一个更根本的问题：我到底是在卖分析服务，还是在卖基础设施便利性？ 如果是前者，那成本应该主要花在计算上；如果是后者，那存储和IO优化就更重要。目前来看，我的定位是前者，所以数据库优化的优先级可以往后放放，先把核心分析流程跑通再说。
回头看，这一段其实是在做同一件事：在有限的资源里找到性价比最高的优化点。minibwa的引入是这样，云硬盘镜像的思考也是这样。上线前的最后冲刺，每一点优化都要权衡投入和产出，既要让用户感受到成本极低，又不能让自己陷入过度优化的泥潭。