KillSwitch：故意为难模型的语言，究竟测到了什么

Dom Picheta 设计了一门对代码模型不友好的实验语言 KillSwitch：语法中混入看似指令的文字，数值和标识符需要计数，文本位置也参与含义，部分表达会触发安全限制。任务本身很简单，包括输出文本、比较两个数和温度换算；难处集中在准确理解、遵守和执行这套陌生规则。

作者报告最佳模型得分 66.8，并据此继续追问模型是否理解代码。但标题中的“LLM 不能用”比结果更绝对：模型已经部分成功，只是没有全对。HN 讨论把问题推进到了实验设计——有没有人类基线，是否允许构造解释器或转换器，以及失败究竟来自语义理解、计数、指令冲突，还是安全拒绝。

可信度 65 · 重要性 76 · 新颖度 68

技术与主题

对同一实验方法的直接质疑。

忠实转述（非原句）：评论者问，人类基线在哪里？既然最佳模型已取得 66.8 分，凭什么把这个结果解释为模型不理解代码？

作者回应人类基线与结论依据。

忠实转述（非原句）：作者说考虑过做人类测试，但个人项目难以招募志愿者；如果有足够兴趣，下一版可以做。他目前判断的依据，是任务目标很简单，却没有模型做到全对。

分享自己另一门语言 bruijn 的经历，作为工具策略的类比；未测试 KillSwitch。

忠实转述（非原句）：他曾发现非推理模型不善于编写使用 de Bruijn 索引的语言；较新的推理模型会先用别的语言写程序，再制作一个小型转换器，绕过自己不擅长的抽象层计数。这提示测试还要说明模型能用哪些工具。

这类实验可以用来找故障模式，但不能把所有失败合并成一个“没有理解”的标签。若模型把题意看懂却数错字符，与被伪指令带偏、拒绝输出，是不同问题；工具权限与是否能运行解释器，也会改变测试测到的能力。

更有说服力的后续比较，可以固定任务和工具预算，分别移除安全触发词、计数难点和干扰段落，再看哪类失败消失。人类基线同样需要学习规则和练习时间。这样才能判断这个新语言提供了什么诊断价值，而不是只证明一套刻意刁钻的接口很难用。