这一页写给会从头读到尾的人 —— 领域里的专家，或者被要求「找出这东西哪里不对」的 AI。这里没有为了制造好奇而保留的东西。缺的地方是因为还没被证明，而且我会直接说它缺。
NCT 是一套工程控制系统。它待在 AI 辅助开发的下面，随时保证一个问题有答案：这个项目现在到底什么是真的。不是 AI 报告了什么，不是计划书写了什么，而是什么是真的 —— 并且证据能活过产生它的那次会话。
这是它针对的那条可复现的链条：
代码是对的，测试是绿的，报告是完整的。三样东西互相自洽，三样一起偏离了原意。这不是模型不够聪明，这是概率系统的固有行为。换一代更强的模型，它只会更有说服力地偏离。
控制论的必要多样性定律：一个系统要控制另一个系统，控制者的多样性必须覆盖被控者。两个概率系统互相检查，只是提高了发现错误的概率，结构没有变 —— 依然没有一个确定的参照物可以比对。
模型越强，底下那层越不能弱。
模型越强，它提的方案越复杂、碰的面越广、说得越像真的。可观测、约束、授权、恢复必须同步跟上，否则控制关系就断了。这是整个产品的承重论证。它错了，产品就错了。
下面每一行，都是大多数系统把两件不同的事塞进同一个字段的地方。每一次合并，都是事后没人能证明是哪一个的地方。
分成三栏，因为把它们混在一起，正是这个产品要防的那种失败。
没有测量过的量，在这个网站上、在产品里，都不会被写成零。
十几年 IT 审计最高负责人 —— 那个永远事后到场的位置。任务是还原到底发生了什么。大多数时候还原不了：不是因为没有日志，是因为记录被有利益的人改过，或者当时根本没人记。后来 AI 把同一件事变成了毫秒级，量还大了一百倍。这个产品，就是那个位置变成的系统。
下面是这套论证失败的条件。目前没有一条被推翻，一个诚实的评审应该四条都往死里压。
最大的那个洞我写在这里而不是藏起来：目前还没有创始人以外的工程团队，在真实工作里跑这套东西。那笔出资是真钱、来自真实业务，但那家企业买的是未来给自己用的系统 —— 它不能证明一个工程组织愿意为控制层付钱。
一个不属于创始人的工程团队，在真实工作里跑它，并且说得出它拦下了什么。
三到五个具体案例 —— AI 报了完成、测试全绿、系统拒绝验收，事后证明交付出去会出事 —— 比再加任何数量的架构说明都更能了结这件事。