这些论坛上好像到处都是那些喜欢炫耀自己 AI 工作流程有多复杂的人。他们那套关于怎么把上下文喂给 Claude 写代码的，确实也算是个技术活吧。但我就会想：这真的比当年用 C 语言学做游戏、写数据库、或者搞内存管理更难吗？
这其实就相当于重新搭建一个开发者本来就会的开发流程和环境。那你说，配置 Claude 写代码，真的比自己搞个定制化的 Neovim 配置还要复杂吗？
而且你再看，所谓的“Claude 写代码”这技能，其实就是在一堆纯文本文件里用英文写提示词。说到底，它不过是以一种非确定性的方式生成一堆代码而已。或者最多就是个高级点的自动补全，因为你限制太多模型之后，其实大部分时候还是得自己动手写。
看起来好像只有那些不会写代码的人才特别热衷于“ vibe 编码（vibe coding）”这种东西。我自己去了一些开发者的论坛，看到的全是一堆处理 LLM 生成错误的恐怖故事。
说到大模型（LLMs），大家都不愿意承认一个现实：
它们天生就是不可预测的，而且永远都会这样。
这就是为什么我只把它们用在研究上，而不是实际工作中。因为工作中需要完整的上下文理解，而试图让 LLM 理解上下文，就像逆水行舟，根本使不上劲。
而且你想在短上下文窗口里增加信息量也很难，
因为上下文越长，计算复杂度是呈二次方增长的。需要的矩阵乘法暴增。
虽然有一些优化手段，但它们都有代价，比如稀疏注意力机制（sparse attention），但这样准确率又会下降。
说到底，LLM 的能力受限于它的数学原理。想要突破上下文窗口的限制，你可能得完全抛弃注意力机制才行。
这对开发者来说意味着什么？
随着代码库的复杂度上升，LLM 的表现会越来越差。你越依赖它来写代码，你的系统里就会引入越多“黑盒”行为。
所以，所有这些努力和所谓的“AI 技能”，最终换来的，可能还不如一个你完全掌握的代码来得靠谱。而且情况可能会越来越糟，因为 LLM 的底层数学机制，本身就决定了它很难有根本性的突破。 |
微信登陆 
