加载失败
项目发端于作者在使用 Claude Code（Anthropic 的代码模型）时发现模型生成了需要人读的 TypeScript，于是提出为模型而非人类设计中间语言的想法并实现了一个名为 Nerd 的实验。作者声称机器生成代码占比显著（约 40%）并已做出 bootstrap 编译器，通过 LLVM（一个开源编译器基础设施）生成本地代码，但项目仍处早期。评论者把该想法与已有的中间表示/字节码（如 JVM bytecode、汇编）相比较，同时强烈关切可读性、调试复杂度和审计安全性，举了 React Native 桥接调试需要跨多语言的例子。工程实务讨论集中在缺乏训练数据、如何用上下文窗口教会 LLM、以及 token 化与“压缩”常用操作（例如把复杂操作作为单一 token）的权衡。
反对者认为将大量代码刻意设计成对人类不可读会带来严重后果。评论里举例说，最终仍然需要在更低层级调试（如 JVM bytecode 或 V8 内部），而额外的抽象层和转换会迫使开发者掌握多种语言与平台（例如 React Native 的 JS 与 Android/Java/Kotlin/C++ 桥接），从而大幅增加调试复杂度。有人把新语言比作 Forth 却更难读，同时质疑可审计与安全性：机器生成的中间语言一旦出错谁来负责、谁能理解并审计安全性。整体观点强调可维护性与可观察性不应被设计牺牲。
作者将 Nerd 视为思维实验，出发点是观察到模型生成代码的比例上升（作者提到约 40%），于是探索如果不以人类为主要读者，中间语言会如何设计。项目已实现 bootstrap 编译器并通过 LLVM 生成本地代码，作者承认实现粗糙但可运行，并邀请贡献者共同改进。讨论中也有观点认为为 LLM 优化的语法设计确有潜力，但语言设计仍可能需要人工主导，生成与消费优化并不意味着让模型去完全设计语言或编译器。总体论调是既有怀疑也有对实验价值的认可。
许多评论指出这一方向并非全新：编译器和运行时长期存在不以人类为首要读者的中间表示与字节码。评论中提到 JVM bytecode、V8 内部表示和汇编等已有层级，它们本质上就是面向机器或编译器的表示，用于优化与跨平台执行。因而部分人认为 Nerd 更像是把现有 IR/字节码思路搬到 LLM 场景，关键在于是否能提供等同的工具链、可观测性和审计能力，而非单纯语法创新。
实际工程层面面临训练数据稀缺与 token 化效率两大问题。评论提出在没有大量训练数据时，需要在上下文窗口教会 LLM，一种实践是从极简语言开始，观察模型为未支持特性“幻觉”出哪些 API/语法，然后将常见模式逐步加入以减少对复杂系统提示的依赖。另有观点从 token 角度讨论“压缩”策略：可以通过新增 token 将常见复杂操作（例如 sha256）映射为单一 token，从而节省上下文，但这会带来类似 CISC vs RISC 的权衡与生态维护成本。总体上讨论集中于如何在减少人类负担与维持模型可用性之间取舍。
Intermediate Representation (IR) / 中间表示: 编译器或工具链使用的低层中间语言，介于源代码与机器码之间，用于优化、分析与跨目标代码生成，通常不是以人类可读性为首要目标。
LLVM: LLVM（一个开源编译器基础设施），提供中间表示、优化器和后端，用于将语言编译为本地机器码，常作为语言实现的后端工具链。
Bytecode / 字节码（如 JVM bytecode）: 为虚拟机设计的低级指令集，可被解释或由 JIT（即时编译）转为机器码，常用于跨平台运行与运行时优化。
Token（LLM 的 token）: 在大型语言模型中，文本被切分为 token（子词或符号）；模型的输入/输出和上下文窗口都以 token 为单位，新的语法或关键字会影响 token 消耗与交互成本。