LLMs 有时能识别数字模式，但能否解释其推理？通过互动演示来看。

• FAQ 部分：

  • 询问为何不先让 LLM 写出推理等，点击 LLM 行旁的“展开”可查看发送给 API 的消息，示例中 Alice 会多次操作并使用eval_js工具，还会先写出假设再用代码测试，可通过更改设置中的prompts键值来实验提示，详情见“如何自己运行”。
  • 解释运行流程，包括生成紧凑栈语言程序、拒绝明显无聊的程序、通过种子搜索问题、让 LLM 选择序列并给出模式、让另一个 LLM 仅根据 Alice 的模式选择序列、让第三个 LLM 检查前两者的选择是否正确等。
  • 介绍如何自己运行，包括提供 Anthropic API 密钥、通过设置更改很多内容（如提示、HTTP 请求等）、配置 demo 以连接其他 API 及注意事项（如设置中值可能包含任意 JavaScript 等）。
  • 探讨此研究的意义，认为 LLM 推理能力有限，虽能识别斐波那契序列变体但模式常无意义，解释质量低，即便多次对话后解释仍可能很差，还讨论了对未来计算机在该任务上表现的乐观态度及防止作弊方法等。
  • 说明做此研究的原因，是某天散步看到 1347 房子想到自动生成数字模式的问题，曾计划让亚马逊 Mechanical Turk 工人与 LLM 竞争但因基础设施无聊而放弃，上周决定制作简单 UI 让人们自己玩。
  • 回应关于 LLM 能否做此任务及人类能否识别模式的质疑，以具体示例说明如何引导 LLM 识别数字模式及程序的工作原理等。

• 示例程序部分：

  • 介绍多种程序，如 doubling（2 *，将栈顶数字翻倍）、Fibonacci（+，栈顶两数相加，生成斐波那契序列）、Catalan numbers（len 2 * 1 - 2 * * len 1 + /，基于卡特兰数生成序列）、Collatz sequence（dup 2 % bgtz 5 2 / 1 bgtz 4 3 * 1 +，应用考拉兹函数生成序列）等，并解释其原理和执行过程。

• 静态分析部分：

  • 说明符号执行器的两个目的，帮助人类理解和验证程序，帮助计算机生成好问题，介绍符号表达式、符号栈等表示方法及各种操作的语义。
  • 定义“无聊”程序（肯定是常数、栈顶无值、栈顶只有一个值且只有一个符号表达式）和“混淆”程序（肯定使栈下溢，通过检查栈顶符号值的索引来近似判断），并以rot * unrot 2 +程序为例说明静态分析的现状和改进方向。

• 随机反思部分：

  • 提及使用 YAML 避免写设置 UI 的困扰，eval用于模板很可怕但节省时间，用JSON.stringify做结构比较对演示有帮助但怀念 BEAM 值，尝试不用 React 写 UI 但手动处理<details>元素的状态恢复较烦人。
• 结尾部分：感慨很少有人会读到这里但感谢阅读，说明这是个分散注意力的副业项目，提供 demo 的源代码及相关许可证信息，最后提到在爸爸意外去世三周年写此博客，提醒自己要珍惜时间为他人做事，还提到之前博客中关于房子编号的错误及相关思考。