150 个构建，0 个缺号

这是我的构建归档，从 B0001 到 B0150。

数字

构建总数        150
编号范围        B0001 – B0150
缺号            0
重号            0
编号与时间同序    是
首个            B0001   2026-08-28 13:04
最新            B0150   2026-09-04 04:15
跨度            6 天 15 小时
平均间隔        64 分钟
活跃天数        8 天，最多一天 29 次

中间改过一次名字

这批归档不是一个名字下来的。

NEXUS Control Tower    106 个    B0001 – B0106
Entrovia NCT            44 个    B0107 – B0150

产品改名发生在 B0106 到 B0107 之间，两个的时间戳都是 09-02 05:35。

改名的时候编号没有重置。 没有从 B0001 重新开始，也没有另起一套编号。

这一点比「150」重要。产品可以改名，公司可以改名，界面可以推倒重做 —— 但那条记录不能断。一断，前面 106 次的历史就无法和后面接上了。

为什么留着每一个

每次构建都会生成一个独立的 .app，编号连续，带时间戳，不覆盖上一个。

不是为了留纪念。是因为当某个东西坏了，我需要知道它是在哪一次坏的。

如果只保留最新一个，出问题的时候只能靠回忆。而回忆是不能被验证的。

缺号是最重要的那一栏

150 个构建，0 个缺号，0 个重号，编号和时间戳严格同序。

这一栏比「150」这个数字重要得多。

150 可以是攒出来的。但只要中间少一个号，或者出现两个相同的号，或者 B0100 的时间戳比 B0101 还晚 —— 整条记录的可信度就没了。

一条不能自证连续的记录，等于没有记录。

64 分钟

平均每 64 分钟一个构建，最多的一天做了 29 次。

这个节奏不是效率指标。它说明的是另一件事：改动是小步的。

一次改一点，构建一次，验证一次。出问题的时候回退的范围就小。

如果两天才构建一次，中间积压的改动会多到分不清是哪一处引起的。那时候 RCA 就变成猜。

它现在管着自己

从某个点开始，NCT 开始被用来管理 NCT 自己的开发。

这批构建里的后半段，是它在治理自己造出来的。

这是最难的一关，也是最容易翻车的一关 —— 因为写规则的人就是我，而唯一有能力绕过规则的人也是我。

如果这套纪律不成立，它会先在这里塌。