一门 200KB 系统语言让 Claude 重写 GC：828 次崩溃变成 2 万次稳定请求
作者：林岚
林岚
据实验项目 freelang 的开发记录，这门不依赖 libc、虚拟机和传统运行时、直接编译到 x86-64 的小型系统语言，在重写垃圾回收器后，把示例 HTTP 服务器从第 828 次请求附近崩溃，改进到连续处理 2 万次请求且高水位内存不再增长。页面称，大部分修复由 Claude Opus 4.8 完成。
一句话结论： “828 到 2 万”证明的是几个致命 GC 与后端 Bug 被修掉了，不是这门语言性能提升 24 倍，更不是 200KB 新语言已经可以替代成熟生产栈。
原来的问题相当具体。macOS 和 Windows 版本的 GC 会移动存活对象，却没有更新指向它们的指针；另一个实现只回收堆尾部，服务器每个请求产生的碎片无法复用。更隐蔽的是，默认堆太大，测试要做约 400 万次分配才触发一次回收，所以 CI 里 GC 几乎从未真正运行。
Claude 先把堆大小改成编译期参数，让测试一秒内触发回收。随后一串长期潜伏的问题冒了出来：Linux 的 write_bytes 每次都返回 EFAULT，调用者却忽略返回值；一个结构体字段覆盖了堆对象头的大小字段；顶层变量作用域错误会读取未初始化栈内存，测试甚至把某次垃圾值 11 固化成“正确答案”。
这里最值得讨论的不是 Claude 写了多少代码，而是它如何被一个“会大声失败”的系统约束。项目哲学是：外部失败作为数据返回，内部不变量一旦破坏就立即终止。作者让 GC 在不可能状态下直接 abort，第一次运行便抓到错误，修完再运行又抓到下一个。AI 代理很容易自信地沿着错误假设工作，快速、确定的反馈比更长提示词更能提高它的有效性。
当然，这个故事也展示了 AI 修代码的危险。Claude 一度分析了根本没在运行的旧 GC；shell 输入吞掉反斜杠，悄悄改变程序含义；Windows 与 Linux 寄存器调用约定也被混淆。最后仍是编译器、测试和运行时断言把错误拦住。页面把这些失败原样保留，比“AI 一夜写完系统语言”的宣传更可信。
为什么叫 200KB？页面域名强调的是这个小型实现和可直接检查的机器，但正文没有给出足够基准证明其吞吐、延迟或完整工具链质量。2 万次请求也只是稳定性检查，不是每秒 2 万请求。林岚认为，这篇文章最适合作为 Agent 工程课：让错误便宜地暴露，AI 才能快速迭代；如果系统安静地吞错，AI 只会更快地把谎言扩散。
关键事实
- freelang 采用 AOT，直接生成 x86-64，不依赖 libc 或 VM。
- 重写的是非移动式 GC，内存高水位稳定但不会主动降回操作系统。
- 2 万是累计服务请求次数，不是 QPS 性能数字。
- 项目仍公开承认字符串转义、编码和运算符分派等缺陷。
OC 判断
AI 编程的关键基础设施不是“让模型自由发挥”，而是短反馈、强不变量、可复现测试和可观察错误。模型能力越强，这些护栏越重要。
为什么重要
- 对开发者：确保测试真正触发 GC、错误路径和平台后端，覆盖率数字本身不够。
- 对企业：AI 生成的底层代码必须由自动验证约束，不能靠一次成功演示背书。
- 对用户：稳定跑 2 万次请求说明修复有效，不说明语言已经成熟或更快。
评论
围绕这篇文章补充信息、提出问题或分享观察。