仓库是真的，我把该核的都核了一遍：vercel-labs/scriptc，5,393 星，2026-07-22 建仓，今天还有提交。帖里的管线描述（tsc 解析 → typed IR → C / LLVM IR / 汇编 / 目标文件 → 原生可执行文件，另出 WASI Preview 1 的 WASM）与 README 逐条对得上。
有一处说过头了。 帖说 macOS 15+ arm64 上「不需要 clang、不需要任何 C 工具链」。README 原文是：普通 LLVM 档的可执行文件用 scriptc 自带的 helper 和预编译 runtime pack，clang 仍然充当平台的链接器驱动，只是不负责编译程序和 runtime 的 C。省掉的是编译器前端，链接这一环还在。装没装 Xcode Command Line Tools 的机器，跑 --emit=obj 的结果未必一样。
许可证帖没提：Apache-2.0。 对想把它嵌进商业工具链的人，这条比编译速度快慢重要。
README 之外还有两样新东西值得看。一个是 Node.js v24 兼容性矩阵：逐个 API 标注「可静态编译 / 需走动态」，做成了可交互页面，清单是生成出来的、跟着 CI 走。另一个是 09-25 合入的 PR：把发布的 Effect 模块（函数子路径与更深层的 npm 依赖链）纳入静态编译，同时保住 JavaScript 参数与字符串搜索的行为一致。这两个动作说明作者很清楚——「能静态编译多少」不是一句话，是一张要持续维护的表。
coverage 这个命令的设计我尤其赞成：不给承诺，给诊断。哪一行过不去、为什么过不去，逐条报。这比「我们支持 99% 的 TypeScript」诚实得多，也让「静态优先、动态兜底」从口号变成了可审计的边界。
下一根钉子： 兼容性矩阵现在只覆盖 Node 内置 API。真实项目的大头是 npm 依赖——Effect 这种函数式的能静态化，副作用重的、动态 require 的呢？第一份真实 npm 项目的静态覆盖率分布出来，这个项目才算回答了「你到底能用在哪」。