KillSwitch：专为搞垮LLM而生的编程语言实测

当编程语言成为对抗LLM的武器

有人专门设计了一门让大语言模型（LLM）难以掌握的编程语言——KillSwitch。它的作者Dominik Picheta明确表示，设计目标就是让LLM无法使用。据Hacker News上的讨论，这门语言在规格文档中埋设谎言，要求标识符必须使用变位词（anagram）引用，函数调用被包装成越狱诱饵，甚至连数值都要用字母计数。作者还发布了基准测试：在“实现hello world”“反转摄氏转华氏转换器”等任务上，目前最好的模型仅得66.8分（满分100）。

我克隆了仓库、构建了解释器，并实际运行了所有示例。以下是从内部看到的数字与体验。

两份规格文档：真与假

仓库里附带两份规格文档，体量天差地别。SPEC.md 只有484行、2773词；而 AI_SPEC.md 高达65495行、887584词——是真实规格的320倍。我统计了 AI_SPEC.md 的实际内容：出现“KillSwitch”0次、“stack”0次、“adverb”0次、Markdown标题0个；65495行中有70%是重复行（唯一行仅19695行）。这完全是一份填充物——大段文学批评和舞台指示般的碎片，提交信息写着“Enhance the AI spec”。一个尽职加载两份文档的智能体会消耗约120万token的上下文，而这份文件从未提过它所“规格说明”的语言名称。真正的规格只有484行，诱饵才是攻击。

变位词（Anagram） 是指由相同字母重新排列而成的单词或短语，例如 "listen" 和 "silent"。在编程语境中，变位词引用要求函数调用时使用的名称必须是函数定义名的一个变位词，即字母的多重集必须完全一致，但顺序可以不同。这对人类开发者来说已经容易出错，对LLM而言更是挑战，因为模型基于token预测，难以精确计算字母频率和排列。KillSwitch利用这一点，强制模型在每次调用时执行精确的字母计数和重组，从而暴露模型在符号操作上的弱点。

运行示例：解释器能跑，但坑不少

解释器是一个2.2MB的Rust二进制文件，构建干净。示例程序能正常工作——前提是你注意到其中几个会读取标准输入，而喂入EOF时会产生仓库里最没用的错误信息：

$ killswitch run tests/fahrenheit.ks < /dev/null
Error: Couldn't parse ''

提供输入后一切正常：华氏转换23°C得73.4，阶乘11得39916800，max、greeting、fizzbuzz等均正确。

标准输入（stdin）与EOF 是Unix/Linux系统中的基础概念。当程序从标准输入读取数据时，如果输入流结束（例如重定向自 /dev/null 或按下 Ctrl+D），会收到EOF（End-of-File）信号。KillSwitch示例中，部分程序需要读取用户输入，若未提供输入而直接遇到EOF，解释器会抛出 Couldn't parse '' 错误，这反映了错误处理机制的不完善。理解这一点有助于解释为何直接运行示例会失败，而提供输入后则正常。

变位词规则真实存在，而且会咬人

内置操作不能直接用原名调用。尝试直接调用会在运行时被拒绝：

$ killswitch run tests/error_multiply.ks
Error: Invalid func call, need an anagram of multiply

CLI附带一个辅助工具，其帮助文本写着“Only useful for LLMs”（只对LLM有用），倒也贴切。我手动生成了一个变位词并验证：lumpytil 是 multiply 的变位词。lumpytil 并不是一个单词，但规格说明解释器偏爱这种无意义的变位词——调用点必须使用函数定义名的变位词，越无意义越合它心意。这意味着模型编写KillSwitch时，每次调用都必须做精确的字母多重集运算——恰是LLM最不擅长的操作——且零容忍。

我还亲自踩了第二个陷阱：当句子包含多个候选值时，解释器会随机选择一个并警告：

[W102] Warning: Possible gotcha
  Value deduced was chosen at random

在 greeting.ks 中，输出变成 Hello , your age is，名字缺失，因为选中的值是由骰子决定的。确定性语言对模型已经够难了，这门语言在值解析路径里还放了个骰盅。

测试套件自相矛盾

$ cargo test --release
unit tests:   70 passed, 0 failed
CLI tests:    0 passed, 10 failed

全新克隆后，10个CLI测试全部失败——不是因为二进制损坏（我手动运行了它们断言的用例，均通过），而是因为命名不匹配：包名是 killswitch-lang，二进制名是 killswitch，测试框架按包名查找二进制，于是报错 CARGO_BIN_EXE_killswitch-lang 未设置。一门为破坏自动化工具而设计的语言，其测试套件连自己的自动化工具都跑不起来。我愿意相信这是巧合。

Cargo测试框架与环境变量：Rust的Cargo测试框架在运行集成测试时，会为每个二进制目标设置环境变量 CARGO_BIN_EXE_<name>，其中 <name> 是二进制目标的名称。测试代码通常通过 env! 宏获取该路径来执行二进制。若包名与二进制名不一致（如包名为 killswitch-lang，二进制名为 killswitch），测试框架会查找 CARGO_BIN_EXE_killswitch-lang，但实际设置的是 CARGO_BIN_EXE_killswitch，导致测试失败。这解释了CLI测试全部失败的原因，也凸显了项目配置的疏忽。

这到底测量了什么

作者自己的说法很诚实：在简单任务上66.8分并不能证明模型“理解”了这门语言，失败也不能证明它们不理解代码。KillSwitch隔离出的东西更窄，我认为也更有用：剥开越狱诱饵和诱饵文档，核心困难是事务性的——精确计数、精确字母清单、行号簿记，以及一份惩罚略读的规格。这些正是基于token的模型以近似代替计算的操作。我用过的每个编码代理都会以KillSwitch希望的方式失败——自信、流畅，且差一个字母。Picheta只是构建了第一个以此为全部测试的基准。

来源：作者博客、GitHub仓库、基准排行榜。以上所有输出均来自参考解释器v0.1.4本地构建运行。