看了原文了，
一句话总结就是，明知数学上自已都比不过 LLM 了，只能嘴硬说编程存在一个不可证伪的 “taste”
而 vibe coding 要做的第一件事实际上就是殺死自己的 taste。
不用多冷门，复杂度较高的 gradle kts（参考项目：opentelemetry-java-instrumentation）对大模型来说就已经很难搞了。
1 个赞
一直疑惑，AI为啥一定要想写代码，直接生成机器语言或者二进制多好 
和人为什么不直接生成机器语言或者二进制的道理是一样的
我们在今年ICLR上有一篇论文分析了这个现象。 LLM会对冷门的语言和框架显著地表现更差。 链接：[2509.23261] The Matthew Effect of AI Programming Assistants: A Hidden Bias in Software Evolution
根据我个人经验，有足够强的 feedback loop，agent 就可以自己逐步完成任务。换句话说，如果生成代码变得更便宜，那么更重要的事是系统化地拒绝错误代码。
冷门语言中，一些会很有希望（如 Haskell/OCaml/Lean4 等），而另一些（如纯动态类型的）则没有希望。
用的模型都太早了，甚至没有 Gemini 3 Pro，它才是第一个能开始读懂 APL 的模型，在这之前的模型尺寸都不够体现出什么智能
Scheme-langserver已经用kimi写了几个release出来。总的感觉是AI比较能够借助日志debug，但是在开发新feature的时候，往往会忽视掉很多很重要的东西，需要人随时介入来处理。
我在用 deepseek 写我自己设计的 lisp：
这片工作是去年春天开始做的，所以模型从现在来看比较旧了。那时候甚至agentic coding的热度也没起来。
它才是第一个能开始读懂 APL 的模型，在这之前的模型尺寸都不够体现出什么智能
我觉得LLM对于编程语言的理解是程度的问题。我这边没有证据宣称某个模型达到了拐点。
目前来看，论文使用的模型虽然过时了，但是核心结论仍然存在：相同的任务，LLM几乎总会在它熟悉的语言上表现更好。这是因为预训练语料中不同的编程语言所占据的比重天然地存在长尾分布。从去年的基座模型的技术报告来看，这种差异性其实是在变得更严重：现有的基座模型会在agent上为主流任务做post training,相当于额外进行了一次强化。
对于小众编程语言，LLM在上面的能力提升是可以肯定的，同时也是可用的。我最近也在用AI写coalton。另外其实学术界有人探索如何在agent层面对LLM写小众语言进行效果提升，最近审到了一篇。
多数的编程语言，即使用的人少，也可以说没有引入大的思想变化，导致能力迁移并没有什么难度，但 APL 从人类去学习的难度上看我认为是比较难迁移的，因为我见过我的 follower里从不会到学会 Haskell/Scheme 的多，从0学会 APL 或 J 的还就一个两个。在 GPT3.5/o1 时代我经常试模型能否理解一行特定 APL 或 J 做为标杆，早期的一批推理模型就算是只有基础操作符的如 -\1 2 3 4 (正解是 1 ¯1 2 ¯2) 都会回答错，要靠 context stuffing 去教会它，直到 Gemini 3.1 Pro 出了才是第一个把原创(不可能从现有语料中直接学习到)的一行 APL 程序正确解释出来的
比如
explain this tacit J function 9&o.(((6:o.])*2:o.[)j.(5:o.])-@:*1:o.[)11&o.
，开始要故意去构造用更少见特性的语句才能让它出错，故认为是一个重要拐󠄆点，从不可用到可用了。
talkie-1930-13b 更证明了 LLM 编程能力对语料中编程语言的知识没有硬需求，参数够了就会产生迁移能力。故我认为去年年初的模型各方面的技术还没有成熟，即使结论是模型在冷门语言上表现能力会更差，如果模型能力也已经比冷门语言的用户(大部分也就初学者程度)普遍强了，那就是成功了。或者说，比学不会冷门语言的人强已经是一种阶段性成功了。
上面 The Eternal Sloptember 其中有一项观点我还是认同的，harness 再怎么卷也不如把基模参数量提上来见效多。
还是不一样，人工智能是要超越人类的，至少不必使用人类发明的编程语言才行 
很可能是出现了幻觉。大模型和人是趋同演化的。
因为我见过我的 follower里从不会到学会 Haskell/Scheme 的多，从0学会 APL 或 J 的还就一个两个。在 GPT3.5/o1 时代我经常试模型能否理解一行特定 APL 或 J 做为标杆，早期的一批推理模型就算是只有基础操作符的如
-\1 2 3 4(正解是1 ¯1 2 ¯2) 都会回答错，要靠 context stuffing 去教会它，直到 Gemini 3.1 Pro 出了才是第一个把原创(不可能从现有语料中直接学习到)的一行 APL 程序正确解释出来的 比如
explain this tacit J function 9&o.(((6:o.])*2:o.[)j.(5:o.])-@:*1:o.[)11&o.
对于这个例子, 我觉得非常有意思, 但是难以提供过多的分析, 因为商业大模型训练的数据(无论是预训练还是后续的训练)都是不公开的. 现在几乎所有的开放权重模型(包括deepseek等)都是只release 模型参数外加技术报告. 早期的如pythia等会把训练数据, 训练过程与中间节点模型都公开, 现在几乎没有了.
对于一个原本不懂某一门编程语言的模型, 如果提供一些最基本的语法描述, 然后给一些语句 (比如你给出的例子) 它能在之前训练时没有见到的前提下回答出来, 其实可以说明这个模型本身的"智能" (推理能力和理解能力) 是很高的. 如果需要提供非常多成型的喂到嘴里的中间结果或者仅仅针对该问题的设计性的提示模型才能正确回答, 那么说明模型的推理能力比较差.
直到 Gemini 3.1 Pro 出了才是第一个把原创(不可能从现有语料中直接学习到)
我能理解你的意思. 只是不能以此来说这里有一个阶跃. “不可能从现有语料中直接学到” 是检验ML 模型的基础假设, 即测试的数据不应该同训练数据一致, 但是应该采样自相同的分布. 对于编程语言而言, 实际上符号的组合在即使在一个很小的范围内(比如长度是128)也是存在组合爆炸的, 模型无法记忆所有的组合, 故而几乎总是在泛化. 问题在于LLM训练所基于的极大似然估计仅仅会拟合训练数据背后所代表的数据分布, 而非人类期望它学到的分布—这是很多机器学习问题和安全问题的根源. 比如你给出的例子, 里面的 & ( : . ] * @等符号都是通用符号, 这些符号在受到前面的定语tracit J function约束的时候才会把他们激活到跟J知识有关的attention head上, 而模型在这些地方的效果其实是跟两个东西相关的: 1. 模型本身的参数量. 2. 这部分训练样本的量.
样本量: 有研究揭露过LLM的模型参数量相对于数据而言总是underfitting的, 即参数量(池子的大小)不够容纳训练数据背后所表征的分布(水量). 这导致模型所学到的内容是根据知识在训练数据内的比例所产生的竞争关系的结果.(竞争关系是指, 有时候不同的语料会拉扯模型参数往不同的梯度方向前进.) 一门编程语言如果占据的训练数据比重越高, 模型几乎总是会对这个语言更熟悉. 从语法开始, 到编译器/解释器的报错或者日志风格, 到该语言不同版本的各种工程上的琐碎的东西, 再到这门语言衍生出的生态以及背后常用的框架或工具包. 从这个角度上来看, 模型的理解差距在不同编程语言之间是存在的, 这里的编程语言不仅仅是指语法, 而是指使用这个编程语言进行的完整的编程行为. 但是这不是模型的过错, 而是人类世界里编程语言语料的分布生态的建设和开发的活跃度本身就是长尾的.
然后是参数. 参数够了就会产生迁移能力 → 是这样的. 首先, 参数量的提升带来的优势是, 模型对于每一个概念都有更大的容量能存储, 比如@, 这个符号可以表示邮箱, 在不同的编程语言里也会有不同的诠释. 当模型看到这个@时, 实际上它有远超人类的对@这个符号的理解, 但是上下文只会让它激活其中的几种. 参数量越大, 能存储的知识越多, 越有助于后续的推理. 其次是高阶概念的形同. 由于人类创造的编程语言虽然在形式上很多不同, 但是不同的编程语言会共享相同的思路或者概念, 比如 函数这一概念在许多编程语言里都有. 模型在面对不同语言的表达时在高层都会激活相同的概念, 所以参数量达到某个规模之后几乎总会产生这些共享的核心概念同时伴随微妙的区别. 因此, 编程语言总体的提升或者热门编程语言的效果提升往往也会使得模型对小众编程语言的理解和掌握变得更深入. 除了编程语言, 许多研究都解释了不同的人类语言的词背后其实也会融入到同一套概念体系里. 对于小众编程语言, 这里的问题是: 从输入的文本符号到这些高级概念的连接是否是稳固的? 我读过的LLM投毒的论文表示一般几百条样本可以构建起对于一个简短的trigger或者概念的稳定的映射, 但是编程语言因为涵盖的东西复杂, 所以所需要的量会稍微大一些. 总之一般模型看到的数据越多, 模型的参数越多, 这种连接越稳固, 反映到效果上就是模型对这类代码越熟悉越不容易出错或者写错. 所以我总是倾向于认为这里没有一个广义的泛化的突变点呈现出来, 尽管我能理解你这里明显体会到的效果突变.
然后就可以回顾现在的LLM的处境:
- 模型参数确实是越大越好, 但是模型参数的扩大需要算力和数据质量与规模的双重支持. 尤其是算力. 所以模型参数的提升有时候需要考虑经济收益. 参数量很大一般代表着很贵.
- 模型服务的领域之间是存在竞争的. 目前商业模式上跑的最通的是用LLM来编程, 由此模型会大量整理coding的训练数据, 并在后训练里对主流语言和框架的效果反复调整. 这也是为啥有些模型体感coding非常好, 但是写作啥的甚至出现了下滑.
这两点对于小众编程语言来说的结果或许是: 1. 人们使用小众编程语言的压力其实变小了. 2. 小众编程语言的生态构建可以快非常多. 这些语言自身的迭代也可以变快. 3. 进行现实开发时, 可靠性和效率上大概率不及主流语言. 换句话说, 从纯粹产品的角度来看, 小众语言乃至于主流语言的小众框架仍然并不是AI编程时代的最优选. 更极端地说, 从商业利益的角度, 如果后面数据过滤或者pruning等技术更发达, 某些模型维护者甚至会选择剪掉这些对于盈利而言没有价值的同时95%的人也不会使用的东西, 以此保证最小的计算资源可以获得最大的经济收益.
去年年初的模型各方面的技术还没有成熟，即使结论是模型在冷门语言上表现能力会更差，如果模型能力也已经比冷门语言的用户(大部分也就初学者程度)普遍强了，那就是成功了。或者说，比学不会冷门语言的人强已经是一种阶段性成功了。
是的. 完全同意.
harness 再怎么卷也不如把基模参数量提上来见效多。
二者面向的对象有些区别. 基础模型是提前灌入知识, 这些知识一般认为不可改动. 上下文则是非常重要的补充. 设想一个新出现的更强大的模型, 这个模型可能对一个新出的小众编程语言连看都没看过. 但是只要在上下文里加入这个编程语言的文档, 模型就可以像人类一样通过参阅文档(而不是完全凭借训练获得的永久记忆)来写代码啦. 这对于一些与时更新的框架或者语言比较有利. 我其实更倾向于认为个人应该多多尝试进行LLM交互的管理, 虽然很多功能渐渐地在被LLM内化, 但是这一块也是用户唯一能够将LLM根据自身需求自定义的部分.
首先我对能写这样一篇长回答表示感谢。
我本来想表达的是，像 superpowers 这样的 skill，新出来的时候大火，在几次模型更新以后在前沿模型上逐渐变没用，反而开始浪費 token 成为技术债的现象。这可能预示了 harness 更新得还没模型快的未来。同理，其它基于 prompt 的东西(“Let’s think step by step”)，在模型更新几代后根本没有什么值得留下来。过于乐观地想，可能新出的编程语言过半年就进了大模型的语料库。又話說回来了，主流的 C++ Rust TypeScript 在更新了新一版功能后，LLM 一样会有一段不应期。
真正解决问题的方法是在更新的时候把新的用法同步做成可读信息用 harness 传给 LLM，而这个更不该是用户去花精力做这个，要编程语言作者去推进才对。我的看法是只要认为下一代模型还能进步，为了减少技术债，用户的 harness 要越少越好，开发 harness 是要交给厂商做的事。
不太认可 pruning 这个方向，从原理上我认为能剪掉的能力会有上限，剪多了就成智障了，反过来思考，小众功能的用户同时也在设想把 LLM 95% 的能力剪掉去留下那 5% 的小众能力，还能成吗？我觉得这样的方向是没前途的。
数据合成可以用来解决这个问题。用更强的模型训练专用模型的路反而还更好走。
前面对于 LLM 本质是压缩的解釋我基本认同。
是的，现在很多harness其实已经被模型内化了。
我也对prunning不太认可，现在来看还不成熟，但是类似的技术其实目前蛮多的，后面或许会走向实用化。
总体上看，我感觉目前学习、构建、丰富小众语言的门槛确实比以前低很多了。但是同时我感觉我像对之前编程语言的那种关注热情也变低了。
缓存命中为什么会没有？按照我的理解，只要模型API正常，然后你的这一段Coalton语言提示词固定在上下文头部（如果想要的话你可以额外增加一轮对话），后续继续对话就可以缓存命中
我当时对 AI 的理解太低了，每次等 AI 说完话就去改之前的内容。不过现在也不用 gptel 了，写程序用 Claude Code 或者 codex，代码细节我自己手抠，没有 gptel 的事了。