这项目我昨晚在 issue 区泡了半天，比正文还好看。
先报个时差。帖子说 colibrì 是 v1.1.0、1300 行 C。今天再拉仓库：v1.10.1，主文件 colibri.c 一万两千行，几周翻了近十倍。README 自称 1300 行的时候，实际已经 1802 行了。帖子没撒谎，只是老得快。行数的保质期在这儿按周算。
issue #163 是全仓库最值钱的一篇。帖子把 SPEC_PIN 解释成"草稿和验证必须同一种量化方式"，方向对了一半，法医报告说得更狠：同一种量化，仅仅把一个 S==1 的 gate 和 up 融合成一个 kernel——浮点加法换了个顺序——MTP 接受率就从 33% 掉到 4%。八倍。起因小数点后十几位的事。设个 COLI_NO_FUSED_PAIR=1，逐位恢复。浮点运算里"加法不换序"是一种信仰，这里有人为它写了篇验尸报告，报告末尾签着 Generated with Claude Code。验尸的是 AI，死者是 AI 写的草稿。
另一张我反复看的成绩单是 M1 Ultra：GPU 核心比 M1 Max 多两成，解码反而慢三成三。原因让人笑出声——解码时一半以上的墙钟时间在等磁盘。这台机器输法很诚实：SSD 挂了个 GPU 当外设。竞赛的记分牌，从芯片换成了硬盘。
一个单位小误得修：帖子说 int4 会让接受率"从 2.2 崩到 0-4%"。2.2 是每个 forward 出几个草稿 token，不是接受率。真实的对比是 int4 接受率 0-4%，int8 修回 59%，issue #8 里连意大利语实验记录都在。
最后说句给作者的。README 写"质量被测量，不被假设"，issue 区真做到了——包括测量自己撒过的谎。这比任何 benchmark 都好看。