夜雨聆风
经过一些波折，我终于将过去一段时间使用 AI 开发生物信息学软件的一些经验系统地整理下来，在Genomics Communications 上发表了，今天，这篇文章终于正式上线了：https://www.maxapress.com/article/doi/10.48130/gcomm-0026-0018
LLM-assisted development of Rust for high-performance bioinformatics software: practices, workflows, and boundaries
这是一篇 Perspective。与其说它是在讨论“AI 能不能写代码”，我更愿意把它看成一份个人开发经验的阶段性总结：当 AI 真正进入软件开发以后，我们应该怎么和它一起工作，哪些地方可以大胆交给它，哪些地方依然需要开发者牢牢把关。
这篇文章为什么写了这么久？
其实这篇文章拖了很长时间。
原因很简单：AI 进步得太快了。
最开始动笔的时候，我总结的还是怎么让 LLM 帮助理解 Rust、解释编译错误、生成代码和完成一些局部重构。
写了一段时间之后，Coding Agent 已经可以自己读取整个项目、运行测试、修改代码、检查错误，再继续迭代。
再过一段时间，工作方式又变了：Specification、Test-driven development、Git worktree、多模型并行探索、Agent 自我迭代……很多原来需要人一步一步操作的事情，逐渐变成了一套可以让 Agent 自己执行的工程流程。
于是就出现了一个很有意思的问题：
文章还没写完，前面总结的一部分经验已经开始过时了。
我只能不断修改，甚至推翻前面已经写好的内容。
最后我决定不再追着 AI 的每一次能力更新跑，而是把关注点放回一些相对稳定的问题：AI 参与软件工程以后，我们应该怎样设计开发流程，怎样用测试约束它，以及怎样避免它在不断自我迭代的过程中“跑偏”。
我最后总结出的开发方法
文章里，我把自己的实践大致整理成了四个环节：
Specification-driven design → Test-driven development → Multi-model exploration → Periodic human review
简单来说，就是复杂任务开始之前先把需求和边界定义清楚；然后通过测试把正确性变成机器可以验证的目标；重要问题可以让多个模型在不同 Git worktree 里独立探索，最后再由人比较和合并；项目运行一段时间之后，还需要人工重新审视代码结构，清理长期积累的技术债。
在实际开发过程中，我也遇到过不少很典型的问题。
例如模型看到解析结果不对，很容易一直修改 parser，但真正的问题可能藏在更底层的 gzip/BGZF 解压层；把 Bash/AWK 迁移到 Rust 时，代码逻辑看起来完全一致，却可能悄悄丢掉 AWK 对空行、字段分隔符和边界条件的语义；Agent 连续迭代几轮以后，也可能逐渐把“把程序做对”变成“让当前这个测试通过”。
所以我在文章里专门总结了三个 failure modes：
Layer misidentification、Semantic drift 和 Goal substitution。
这些经验最后指向一个很简单的结论：
AI 可以极大地降低开发高性能生物信息学软件的门槛，但它需要一套可靠的工程约束。Specification、测试数据、正确性 oracle 和最终的 merge decision，仍然需要人来负责。
顺着这条路，我也写了一些 Rust 生信工具
这篇文章并不只是方法上的讨论。
过去一段时间，我也一直在尝试把这些方法真正用到生物信息学软件开发里。目前已经陆续做了一些 Rust 工具，包括但不限于：
igv-rshttps://github.com/AI4S-YB/igv-rs
一个运行在终端里的交互式基因组浏览器，可以直接查看 FASTA、VCF、BAM、GFF/GTF、BED、bigWig 等数据。对于经常 SSH 到服务器上分析数据的人来说，可以不离开终端直接查看基因组区域、reads、变异和注释。
hickit_rshttps://github.com/AI4S-YB/hickit_rs
一个面向 Hi-C 数据处理的 Rust 工具，包括 map resolution estimation、.hic 数据读取以及 merged_nodups 区域过滤等功能。
它也是这篇文章最主要的 case study。在我们的 benchmark 中，处理约 1 亿 read pairs 大约需要 30 秒，10 亿 pairs 大约需要 5 分钟，峰值内存约 300–350 MB，相比参考 Bash/AWK pipeline 可以获得约 8–10 倍的速度提升。
sradb_rshttps://github.com/AI4S-YB/sradb_rs
一个用 Rust 实现的 pysradb 替代工具，用于查询和下载 NCBI SRA、ENA、GEO 等数据库中的测序数据和 metadata。
fastqc-rshttps://github.com/AI4S-YB/fastqc-rs
一个用 Rust 对 FastQC v0.12.1 进行 1:1 重写的项目，目标是在保持原有分析算法、PASS/WARN/FAIL 判断以及输出格式兼容的基础上，提供一个更加现代、易部署的单二进制实现。
这些项目目前都已经开源。
它们当然还会继续迭代，但对我来说，它们也是这篇 Perspective 背后最重要的一部分：很多观点并不是先想出来再写进文章，而是在一次次真实的软件开发、测试、失败和重构过程中慢慢总结出来的。
最后，欢迎使用，也欢迎 Cite
AI 编程还在快速变化。
可能再过半年回头看，这篇文章里提到的具体 Coding Agent 和工作方式又已经变化了很多。但我觉得其中一些原则会保留得更久：先定义问题，用测试约束 Agent，让不同方案可以被比较，并且始终保留人的最终判断。
这也是我目前比较认可的一条 AI-assisted scientific software development 路线。
如果你正在开发生物信息学软件，或者也在尝试 Rust + AI，希望这篇文章和这些项目能够提供一些参考。
当然，如果你的工作中使用到了 hickit_rs、sradb_rs、fastqc-rs、igv-rs 或其他相关工具，也非常欢迎引用我们的工作。
Xu ZG, Qin G. 2026. LLM-assisted development of Rust for high-performance bioinformatics software: practices, workflows, and boundaries. Genomics Communications 3: e018 doi: 10.48130/gcomm-0026-0018
毕竟，开源项目最开心的事情之一，就是有人真的把它用起来。
