导读

把这页当成整个站点的阅读契约。它定义 fq-compressor 想在公开层面证明什么、文档如何组织，以及不同读者最快该走哪条路线。

站点契约

• 本站把 fq-compressor 当作系统设计来论证，而不是单独的一条 benchmark headline。
• 每条稳定的公开主张，都应该能回到架构、方法学或仓库中的跟踪产物。
• 阅读顺序优先服务严苛的 GitHub 高级开发者和技术评审。

它不是什么

• 不是 README 镜像
• 不是脱离证据的功能清单
• 不是靠复杂前端效果掩盖工程内容的展示页

默认阅读顺序

1. 先读 算法白皮书 理解压缩命题。
2. 再读 系统设计 查看这些思想分别落在哪些模块和格式责任上。
3. 再读 性能证据 确认仓库当前实际能证明什么，以及证据边界停在哪里。
4. 如果问题偏实操，就进入 操作路径。
5. 如果问题偏文献、对照或历史，就进入 参考研究。

读者意图

读者	从哪里开始	接着读什么	主要结果
高级评审	算法白皮书	性能证据	判断公开叙事是否技术上成立
贡献者	系统设计	操作路径	动手前先理解边界
操作者	操作路径	系统设计	运行和校验归档时不靠猜
研究读者	参考研究	算法白皮书	把 fq-compressor 放回 FASTQ 压缩的大语境

为什么这样组织

fq-compressor 只有在文档像一份技术 dossier 时才更容易被信任。于是顶层路径被保持得足够浅，证据话术被显式约束，而支撑性的书目和对照仓库也不会被藏进脚注里。

阅读路线

先按问题选择路线，再保持在同一条轨道里。

1. 01

   高级评审 / 面试官

   在一次阅读里评估项目命题

   先读算法白皮书，再回到性能证据核对每条公开主张。

   入口

   白皮书 -> 性能证据

   结果

   你可以判断公开叙事有没有超出仓库当前能证明的范围。

   进入这条轨道
2. 02

   操作者

   从安装走到一次可验证运行

   如果当前目标是安装、运行、校验或 spot-check，直接停留在操作路径。

   入口

   操作路径 -> 系统设计

   结果

   你可以运行工具，同时理解格式与校验要求。

   进入这条轨道
3. 03

   贡献者

   动手前先建立代码地图

   把系统设计与贡献流程并排阅读，先看边界，再改实现。

   入口

   系统设计 -> 操作路径

   结果

   你会知道解析、压缩、格式、命令编排分别归谁负责。

   进入这条轨道
4. 04

   研究读者

   把设计选择放回外部语境

   参考研究部分负责论文、对照仓库，以及 closeout 阶段的演进说明。

   入口

   参考研究 -> 白皮书

   结果

   你可以说明 fq-compressor 保留、改写或拒绝了哪些上游思路。

   进入这条轨道