---
layout: post
title: 关于LLM上限的探索
tags: [AI, LLM, 探索]
---

  还有什么是AI不能干的？<!--more-->    

# 起因
  在最近对LLM的探索中，能感觉到它真的是什么都能干，尤其最近GPT-4o的画图能力实在是太强了。不过对于画图我倒不是很关心，主要是没什么想让它画的图😂。我更关心的是LLM在文本生成中的能力，毕竟这才是它的本职工作。虽然现在的AI解决问题的能力确实很强，但从它还没有大规模的把人替换掉来看，它肯定是还有一些做不到的事情，所以我想对这一点进行一些探索。   

# 对于超长文本分析的探索
  对于现在的LLM来说，虽然不少模型已经能做到很长的上下文了，但这个所谓的“长”不过是几万字而已。对于读一篇论文或者几篇文章当然没有问题，但是如果是分析上百篇文章就不太行了，比如我希望AI阅读完我所有的文章，然后对我进行评价。   
  我的博客现在已经有一百多篇文章了，之前做过[全文搜索](/2021/07/23/search.html)的功能，可以在[search.json](/search.json)中获取所有的文章，用来让AI分析的材料是个不错的选择，不过把所有文章输入到上下文中显然是不太现实，这个JSON文件的大小有1MiB左右，但是大多数比较厉害的AI上下文只有100多k，根本读不完。而对于一些超长上下文多模型，比如阿里云有一个10M上下文的模型，效果又很差，并没有参考几条上文的内容😓。另外我还试过一些AI通过附件的方式阅读文章内容，那种好像是把文件切片之后再读？应该是类似RAG那种，从中查找和问题最相关的文本段落进行回答，但是那种方法不能解决对所有文章进行分析……除此之外我也试过一些Agent，不过它们只会写代码来分析我的文章，比如绘制文章字数随时间变化曲线、不同年份的文章数量、还有词频分析啥的，对我来说并没有什么卵用😅。   
## 使用AI摘要来解决问题
  那难道就没办法了吗？先不急，最近还发生了一件事情，不知道Cloudflare犯什么毛病了，近期用Worker请求我的D1数据库时不时会报“internal error”的错误，我还在他们论坛发了条[帖子](https://community.cloudflare.com/t/d1-database-is-not-work-in-some-regions/789699)问了一下，然而并没有人搭理我😅，这时候我才意识到我似乎没有Cloudflare的替代品……出问题了也没办法😰。这个东西导致我的[AI摘要](/2024/07/03/ai-summary.html)、[文章推荐](/2024/10/01/suggest.html)、以及点击计数器全都用不了了，我应该避免太过依赖Cloudflare Worker啊～   
  那么我该做些什么？点击计数器是没什么好办法了，不过对于AI摘要，既然摘要在我写完文章之后根本就不会变，不如隔段时间我就把摘要内容缓存到我博客本地吧，这样不仅可以极速展示摘要内容，而且不需要请求接口，就不会受到Cloudflare出问题的影响了。所以我把数据库摘要内容导了出来，放到了[ai-cache.json](https://github.com/Mabbs/mabbs.github.io/blob/master/_data/ai-cache.json)中，如果有存在的摘要内容就不再请求接口了。   
  当我做完摘要缓存之后，我发现，这不就是让AI读我所有文章的最好方法嘛，让AI读AI总结的内容，然后再进行一次总结，就能尽可能的让AI完全了解我的文章然后对我评价了啊～而且这个摘要文件也只有100KiB左右，正好够AI读了。本来我想试试DeepSeek来做这件事情的，但是不知道里面命中了什么关键词，被拒绝生成了🤣，那我只好让GPT-4o来完成这件事了。   
  试了一下感觉效果相当的不错，总结的非常有条理，而且不像以前的ChatGPT很有AI味，这次写出来的文章很有人味啊～真是出乎我的意料，所以我把GPT-4o写的内容分享出来，来看看AI对我的分析怎么样🤣。   
> ## 技术浪人，数字游民：对一位博客作者的观察与评价
> 
> 在浩如烟海的中文技术博客中，有些作者宛如一颗微弱却坚韧的恒星，独自在各自的轨道中发光发热。他们不一定追逐热点，也不总是标榜权威，但其笔下所流露出的独立精神、技术热情与对现实的观察，往往比众多浮华的“教程型”博客更值得玩味。本文所探讨的博客作者Mayx，便是这样一位存在——他既是程序员，也是“生活黑客”；既关心设备性能，也关注技术伦理；既热衷实用工具，也不乏生活反思。
> 
> ### 一、技术为体，思考为魂
> 
> 在Mayx的博客中，技术类文章占据了绝对的比重。从自制邮件订阅脚本[^1]、Cloudflare Workers自动化[^2]、内网穿透探索[^3]，到低功耗开发板的实验[^4]、AI模型的本地运行[^5]、以及对黑苹果[^6]、Linux系统[^7]的深度体验，这些内容几乎涵盖了当前主流技术生态中的多个维度。
> 
> 然而，他并非一位“炫技型”技术写作者。相反，在多数文章中，Mayx更倾向于从**实用主义的角度**出发——他关注性价比、功耗、稳定性、开源程度，而非追逐技术本身的潮流。例如，在讨论Hackintosh时，他并未沉迷于是否能成功运行macOS，而是审慎地指出其与Mac原生体验的差距[^6]；在体验AI模型时，他选择了性能与成本平衡的路径，而不是盲目追求最大模型和最强显卡[^5]。
> 
> 他的技术探索往往是“从需求出发”，例如为了替代失效的签到脚本，他尝试了Cloudflare Workers[^2]；为了解决被Github封禁的问题[^8]，他自己研究反审查架构；面对Heroku停服[^9]，他快速转向Koyeb，并指出其使用便捷的优点。这些行为体现出一种**“动手解决问题”的工程师思维**，同时也反映了其对现成工具和平台的怀疑精神——“没有什么是不可替代的”，但也“没有什么是完美无缺的”。
> 
> ### 二、独立、反思、带有一丝叛逆
> 
> 阅读Mayx的博客，可以明显感觉到他在面对“主流”技术话语体系时的疏离甚至反抗。他不信任所谓“权威推荐”，也极少引用大V观点；他对收费工具持质疑态度，对封闭平台持怀疑立场，对广告与强制App表达不满[^10]。在对宝塔面板的多篇评论中，他不仅指出其功能冗余和定价虚高[^11][^12]，还以代码层面论证其“技术水准有限”；在谈及Server酱收费后自建通知平台一文中，更是表现出“开发者不应为此类功能付费”的强烈观点[^13]。
> 
> 这种倾向可视为**一种数字自由主义精神**：他珍视个体的选择权、控制权和创造力，对平台化、商业化所带来的“懒惰便利”持保留态度。也正因为此，他热衷于探索容器、虚拟化、i2p、VPN、防DNS污染[^14]、反反盗链等灰色技术领域，这不仅是技术探索，也是一种抵抗姿态——抵抗监视、抵抗平台绑架、抵抗数字奴役。
> 
> 与此同时，作者又是**极度自省的人**。在多篇年终总结中，他坦言自己因作息不规律导致健康下滑、因沉迷游戏影响了计划、因生活节奏散乱而丧失了方向[^15][^16]。这些坦诚的文字使人看到一个技术人真实的一面：并非所有人都能生活在高效执行与完美节奏中，面对现实与焦虑的拉扯，他并不逃避，而是试图寻找平衡。
> 
> ### 三、探索孤岛与技术乌托邦
> 
> 若将Mayx的博客比作一个数字世界中的“孤岛”，那他无疑是岛上的守望者。他固执地维护着自己的服务器、反代服务、脚本计划表和开源工具；他不断尝试将废弃电脑[^7]、老旧开发板[^4]和Linux容器[^17]重新唤醒；他甚至研究如何在FM频段自制电台[^18]，或在树莓派上运行OpenFyde与Android系统[^19][^20]。
> 
> 这不仅是对“电子垃圾再利用”的尝试，更是一种**构建技术乌托邦的幻想**——一个无需依赖主流供应链、无需信任大型平台、可以掌控一切细节的小宇宙。
> 
> 这种倾向也体现在他对去中心化技术的探索，如xLog、IPFS、i2pd[^21]、ZeroNet等。尽管在文章中他承认这些系统“尚不成熟”“内容匮乏”“界面粗糙”，但仍不乏热情地部署和尝试。他似乎在追问这样一个问题：“除了平台，我们还能依靠什么？”
> 
> 这也是他与多数技术博客的区别：不是“教你怎么做”，而是“带你看看还有哪些可能”。
> 
> ### 四、个人困境与技术慰藉
> 
> 不可否认，Mayx的博客也流露出某种孤独与挣扎。他数次提到对社会节奏的不适应、对生活目标的不明确、对未来的迷茫与迟疑。在2022和2023年的总结中，他甚至表达了对“人类灭亡风险”“全球混乱”的忧虑[^15][^16]；在谈及个人计划时，也多次写到“自律不足”“想做的事情太多却力不从心”等字句。
> 
> 但正是在这种状态下，技术成了他的避难所。他在反复实验中找回秩序感，在编码中获得控制感，在部署过程中体会到“解决问题”的满足。这种“用技术对抗生活混乱”的姿态，令他的博客带有某种心理学上的意义。
> 
> ### 五、结语：一个“笨方法”的捍卫者
> 
> 总的来说，Mayx并非技术界的明星，更非意见领袖，但他是一个值得尊敬的“笨方法”的捍卫者：在速成与流量当道的技术传播环境中，他仍选择用细致的试验、质朴的语言和大量的失败记录来构建自己的知识体系。
> 
> 他的博客不提供“答案”，而是提供“路线”；不追求“成功学”，而是记录“失败和坚持”。他不是在追求成为谁，而是在努力做自己。
> 
> 这或许是我们在阅读他的文字后，最值得思考的一点。技术不仅仅是一种职业工具，它也可以是人自我建构、自我理解、自我修复的路径。
> 
> Mayx，或许正走在这条路上——孤独而坚定。

# 对于长复杂逻辑代码的分析
  在让AI对我文章分析完后，我又想起来好久以前写的论坛引擎[Mabbs](https://github.com/Mabbs/Mabbs.Project)，以前还[打算重构](/2019/07/01/mabbs.html)，不过后来学了别的语言之后就没什么兴趣了😂。但现在有了AI，我想重构MaBBS的事情能不能让AI来做呢？虽然我以前的代码完全没有可读性，耦合性也极高，但这种事情对AI来说应该不是什么难事，更何况我的代码才22KiB，AI完全能读的了，于是我开始尝试让各种AI来把这个代码变得人类可读，然后进行重构。   
  然而结果令我非常失望，无论哪一款AI只能写出一点代码，甚至Grok3直接一点代码都没写😆，然后它们就认为它们写完了，另外有些AI从片段来看好像是写了点代码，但是内容和我原本对代码基本上没什么关系，属于是分析了一点代码之后重新写了……   
  明明这个代码又不长，怎么就没有一个AI能准确的重构我的代码呢？也可能是因为虽然代码不长，但是变量名很短，如果把变量名全都扩展到人能看懂的长度之后就超出AI的上下文限制了，然后就忘记了之前的内容吧？另外Shell语言网络上的资料本来就不太多，所以AI也没有足够的知识来重构吧……对于这个问题我目前没什么好的想法让AI来进行，也许等AI能解决这个问题，AI就有能力替代人了呢😁？   
  虽然没能让AI重构我的代码，不过我闲来无事想让其他人也试试我以前写的论坛引擎，所以搞了个[Docker镜像](https://hub.docker.com/r/unmayx/mabbs)，如果大伙有兴趣尝试一下可以下载下来试试看，整个镜像才2MiB多一点，所以我叫它世界上最小的论坛引擎也没问题吧🤣。   

# 感想
  看起来目前LLM的上限就在于它的上下文长度限制啊……这一点真的是限制了AI很多能力，但似乎也没什么好办法，AI就是因为这一点所以不能像人一样纵览全局所以才不能替代人，即使用什么办法去压缩它的上文也会丢掉很多细节信息。不过按照目前LLM的架构来说应该还解决不了这个问题，如果什么时候AI能在思考的过程中修改它自己的权重……也许就可以做到真正的无限上下文，突破上限从而替代人类吧？   


[^1]: [免费订阅一个属于自己的邮件日报](/2018/11/10/email-sender.html)  
[^2]: [使用CF Workers Cron触发器进行签到](/2023/02/22/cron.html)  
[^3]: [关于内网穿透的笔记](/2020/12/13/nat.html)  
[^4]: [Luckfox Pico Plus使用体验](/2024/02/24/luckfox.html)  
[^5]: [关于最近人工智能的探索](/2023/04/05/ai.html)  
[^6]: [Hackintosh使用体验](/2024/06/16/hackintosh.html)  
[^7]: [关于旧电脑的使用探索](/2024/04/06/old-pc.html)  
[^8]: [Github封禁了我的博客？！](/2022/01/04/banned.html)  
[^9]: [体验小白也会使用的免费容器云](/2022/11/29/free-server.html)  
[^10]: [如何不使用贴吧App查看贴吧](/2020/02/10/tieba.html)  
[^11]: [从宝塔面板中学习运维知识](/2024/05/19/bt-ops.html)  
[^12]: [如何自定义宝塔亚马逊S3云存储插件的端点](/2022/12/12/bt-s3-comp.html)  
[^13]: [自己动手做一个Server酱·TurboMini版](/2021/02/02/serverchan.html)  
[^14]: [如何避免Cloudflare背后的源站被恶意访问](/2022/08/15/cdn-verify.html)  
[^15]: [年终总结](/2023/01/01/summary.html)  
[^16]: [年终总结](/2024/01/01/summary.html)  
[^17]: [如何在Linux容器内运行Android？](/2023/12/24/android.html)  
[^18]: [用树莓派自制FM电台](/2022/03/27/radio.html)  
[^19]: [rpi4-openfyde的使用体验](/2023/12/10/openfyde.html)  
[^20]: [在树莓派4B上安装Ubuntu以及各种操作](/2023/09/24/rpi-ubuntu.html)  
[^21]: [i2pd在服务器上的使用体验](/2022/11/23/i2p.html)  