2026-03-29 20:59:49
前段时间，学院发了关于星火杯的报名文件。上个学期就听说过星火杯，但没想到这学期刚开学就要提交作品，没有做什么事先准备。
3月8日晚点名结束后，我与一位同学在图书馆用“腾讯元器”做了一个 AI 问答服务，零代码平台开发这个并不难，但一个小时弄出作品还是给这位同学比较大的震撼。星火杯有支持提交零代码平台开发的智能体的赛道，我打算就这样交上去。
当天晚上，那位同学找我，我们和另外一位同学沟通一些想法，初步确定往“教-学-管-评”智能体方向去做，设计一个平台来服务教育教学。
智能体知识库本身其实就是一个 RAG 系统，我将此前做 RAG 的代码基本照搬过来，大致用 flask + langchain 做了一个后端出来。姚焱夫同学负责前端，此前他并没有接触过前端的开发，现用现学，很快就了解了前端项目的文件结构、代码逻辑，非常厉害。孟子钦同学将我们聚到一起，对一些想法进行了完善。
通过我们的观察，大学的课堂教学过程中存在一些问题，例如：
针对这些问题，我们用我们的项目给出解决方案：
这是关于系统问答与知识库功能的流程动图：学生向学习助手提出问题，学习助手在知识库中检索相关资料附在问题后交给大模型，大模型回答学生；教师可以在管理后台看到学生提出的问题并给出权威答案，权威答案沉淀到知识库中，下一次有学生提出类似的问题，大模型将被要求根据权威答案生成回答。
这是关于系统架构的动图：前端用 Vue 进行开发，后端由 Python Flask 提供服务，使用 Qwen 开源模型。
以上两张动图都是用 manim 制作的，截取自我们的项目介绍视频。PPT 的模板来自人智院的刘卓东学长。由于视频文件比较大，内容就是这两个动图加上功能的演示，所以介绍视频的链接附在本文的附录。
结合我与 Gemini、ChatGPT的对话记录，总结在开发过程中遇到的问题。
环境依赖问题
这个问题我愿意给到“夯爆了”，配环境的时候基本都会出现各种各样的依赖问题，要么是 Python 版本太低或者太高了，要么是langchain_community的版本跟其他依赖不匹配……langchain两个大版本的接口有很大的差异。每次遇到这种问题问 ai 折腾一两个小时估计都折腾不好，用一下搜索引擎很快就解决了。
在与 ChatGPT 沟通的过程中，遇到开发中最麻烦的两个模块create_retrieval_chain和create_stuff_documents_chain。根据我们 ChatGPT 同学之前的回答，它应该是知道由langchain_classic这个包的，但不知道为什么它在这及之后就忘记这两个模块被移到langchain_classic里面去了。我也是头脑不清醒，跟着它折腾半天，最后不得不找谷歌看看。（其实谷歌应该是第一选项才对，但是我懒，喜欢让 ai 直接给答案）
我在谷歌上搜索了一下这个导入语句，马上就找到了 python – Using create_retrieval_chain due to RetrievalQA deprecation – Stack Overflow 这个帖子，将langchain改成langchain_classic，问题就这样解决了。
在与 Gemini 谈话的过程中，估计是训练数据过时了或者没有搜索到合适的资料，它反复提醒我：“导包错误：LangChain 较新版本中，记忆和链模块应从langchain.memory和langchain.chains导入，而不是langchain_classic。”还好我自己知道，没在同一个地方摔倒第二次。
在开发的过程中也遇到过依赖地狱，不过折腾几次全部使用新版本就解决了。
Prompt拼接问题
这个问题也挺搞心态，没找到什么比较好的解决方案，后面用曲线救国的方式解决了。属于是治本不行就治标吧。
if '<|im_end|>' in token or '<|im_start|>' in token:
token = token.replace('<|im_end|>', '').replace('<|im_start|>', '')
if not token.strip():
continue我在后端开发好之后让 ai 写了一份接口文档，供负责前端的姚同学阅读。原本以为 git 和前后端协作这方面会出现一些问题，结果并没有我想的那样困难。在帮忙装后端环境的时候出现了一个问题，关于 cuda 的问题：
我在装 pytorch 的时候，Gemini 给的命令pip install --pre torch --index-url https://download.pytorch.org/whl/nightly/cu128能用，而cu129的预编译包却找不到。没办法，只好让同学降级，后面我在代码里也适配了没有 cuda 的环境。
答辩之前，代码之外，团队协作的过程中出现一些小插曲，经过沟通顺利解决。团队的负责人需要跟进比赛的时间点，熟悉项目并协调准备好材料，带领团队推进。
准备答辩时将材料交给皓子学长过目，大佬给了一些诸如突出显示关键词之类的建议。
3 月 26 日晚上，我参加了网安密码学部的院级答辩。将答辩的录音转文字进行分析，结合答辩时的一些主观感受，发现答辩中暴露的一些问题：
差不多要 29 日学院里统计分数后才会出结果，这段时间可以对提出的不完善的功能进行一下优化。如果被推荐到学校里，完善完善，校赛再战。
与浦彦松学长交流了一下答辩的事情，学长给了一些建议：
让 ai 完善了一下留言邮件提醒的逻辑，学生提交留言提醒之后会先在最近 24 小时的留言里匹配相似度，如果发现有相似度高于 0.85 的留言，则不会给老师发送邮件通知。
在我们完善代码的时候微信发来消息，我们的项目没有被推荐到校赛，这次主体赛我们到这里就结束了。我们队伍里面讨论了一下，决定将这个项目做完。“无论还有没有机会，无论结没结束，咱们都尽量把这个项目完成。不管成没成功，都是自己做的一个项目。”
我们梳理了尚未完成的工作，大致分成三个部分：
假如LLM无限上下文了，RAG还有意义吗？ 这篇回答给我提供了一个可能的优化方向，即“主动RAG，让模型自己决定查什么”。
原先的问答代码是这样的，用户提问→系统检索→模型生成，整个生成过程只检索一次知识库，属于是一个比较普通的 RAG 流程。以下是关于这一流程的生动的图片，图片中红色的内容为投毒内容，暂时不考虑这一点。
我让 Gemini 根据主动检索的概念对代码进行修改，修改后的 ai 可以自己决定要不要检索知识库，如果是寒暄之类的提问可以直接回答，跳过检索步骤。可以进一步对代码进行优化，让 AI 自己决定检索词。
关于抗投毒，TrustRAG: Enhancing Robustness and Trustworthiness in RAG(arXiv:2501.00879) 提供了一种可行的方法，主要通过 k-均值聚类和大模型自评估来过滤恶意投毒文档。因为懒，目前文档数量比较少，没有什么过滤的必要。
项目 README 的实现效果需要实际应用之后才能拿到数据，不方便摆太多的数字。
3 月 29 日晚上，在推完主动检索的修改之后，将新生成的向量知识库上传到 GitHub，发了一个版本。目前的开发任务差不多就完成了。
3 月 29 日中午，就在我们知道我们这个项目没有被推荐到学校过后不久，学部把选拔赛的获奖名单发出来了，我们项目获得选拔赛的一等奖。到此，算是“有始有终”。
致谢
感谢负责进行前端开发工作的姚焱夫同学、负责协调与 UI 图标设计工作的孟子钦同学、给我们提供宝贵建议的皓子大佬和浦彦松学长与提供 PPT 的刘卓东学长。与此同时，我在大创课题组所做的工作在本次比赛开发 AI 应用过程中给我提供帮助，感谢苗教授和负责指导我们的博士师兄。
附录
2026-03-26 11:58:22
人在接收到不同的想法时会本能地进行抵抗，说教感强的语言貌似会导致争执与僵化，太擅长辩论的人有着不善倾听的悲哀。
前段时间，土木坛子发了一篇文章 少和人类多和AI交流，文中提到“与身边的人聊天实在是没有什么有质量的回报”。我虽然也喜欢 AI 给我带来对我来说新鲜的理念和方法，但在这我并不想谈论这个。
我与他人交谈大致有三种状态：一是找别人的漏洞，非要吵赢他才肯罢休；二是将自己的经历分享给别人，常常避免不了一些说教；三是将自己置于与对方平等的位置，一起讨论一个功能应该怎么做。
人，或者是我，在自己的观点受到反驳的时候会自动进入防卫模式，在评论别人的观点时又会进入进攻模式。若双方都在进攻模式，交流就不再是交流，沟通不再是沟通，而是争论、口角，甚至更激烈的碰撞。
大家都是平等的，独立的，没有谁需要被别人教。说教天然将自己置于比别人高的位置，请教有时又将自己置于比别人低的位置。颐指气使没人喜欢，自我贬低就没人尊重。说教的语言会让本应平等的对话陷入僵局。“我凭什么要你教？”“我都说了，你为什么不做？”
交谈之时会抛出一条橄榄枝，若他人真心待我，便侃侃而谈，若他人冷眼相对，便不再理睬。没读懂别人的意思，认为是别人没读懂，发些不尊重对方智力的话，算是结束对话的一种干脆但不愉快的方式。别人与你交谈，建立在他相信你智力正常的前提下。若发此言，算是他看瞎了眼。
交流有时是有目的的，为了达成目的可以适当使用一些手段。若是不容讨论或无法沟通，通知命令的语气就很合适。交流有时没办法让双方都愉快，你也没有让另一方愉快结束谈话的义务，尤其是对方让你不愉快时。但如果双方都想让问题得到更好的解决，平等的沟通对他们来说就是愉快的。
在《士兵突击》里有这样一句台词，“你我都长于辩论，但都不擅长倾听。”沟通不是辩论擂台，说赢对方不是什么荣耀。辩论常常不是为了达成观点的共识，而是在各自的领域筑起高墙。在争执和普通的辩论中，双方发言的目的是输赢和击败，而不是达成共识和解决问题。
“也对。”“可以试试。”“这样会不会更好？”
辩论的输赢之外，辩题正反两面的风景在展现它的意义。争论的输赢之外，妥协背后是争取共识解决问题的追求与智慧。
你，我，听得见吗？
2026-02-26 18:17:05
《都市天际线2》这款游戏我玩了大概半年，游戏平台上显示我玩了五百多个小时，玩通了两次（指的是达到最终的里程碑）。这款游戏的体验比较好，我在里面喜欢静静看着十字路口的车流发呆。
玩游戏经常会遇到棘手的交通堵塞问题，且最近一次工业区还因为交通条件不好出现了大面积进货成本过高的情况。
之前我是这样缓解拥堵问题的：拓宽普通道路、区与区之间用简单的八车道道路或高速公路连接。导致了一些问题：内陆地区没有高速公路，交通条件差，到其他区域的运输时间长；高速公路出入口容易拥堵，从主干道堵到高速上等。
除了工业区大面积提示原料成本过高之外，因为一处人行天桥设计不到位，几个东西“互锁”起来删也删不掉，所以打算重新开一个存档解决交通堵塞的问题。
存档初期建立两个居民区和一个工业办公区，区与区之间用高速公路连接，区内部用双向四车道道路，居民上下高速通过区内部的高速主干道和立交桥。
高速公路匝道出入口可以使用 Taffic 插件设置让行规则与规划车道，经过一番设计，高速公路的承载能力有所提高。
区内路网像前文那样设计会出现一个问题：高速车道会延伸出四条高速主干道插入小区，如果高速主干道位于小区的中间，那这几条主干道需要同时承担车辆进出高速和小区内部两部分沟通的功能，会发生拥堵。
根据参考资料[1]，要避免拥堵，需要设计以快速路为骨架、主干道为辅助、高密度支路为主体的分级交通网络。这样可以做到交通流逐级往下分配缓解拥堵。同时设计地铁连接主要功能区。
关于地铁的设计：每个辖区设一个地铁站，通过地铁线路连接居民区和工业办公区，区内部设置住宅到地铁站的辖区公交环线，方便居民通过公交转乘地铁通勤。
连接网状居民区的路口需要有人行天桥，否则游戏红绿灯的神奇机制会让路口堵塞。
“高速-高架立交-主干道-八车道次干道-四车道小区网格”路网的效果不错。在有两处较高密度住宅区连接的次干道，车流流动顺畅。
参考资料：
都市天际线2：通过优化设计路网解决拥堵最先出现在林林杂语。
2026-02-23 22:28:29
我辞去开往维护组负责人的文章一经发出，Blogsclub的创始人便邀请我前去参加维护，盛情难却，如今也在 Blogsclub 上挂了名。几年以来，与十年之约、开往、中文博客列表导航和 Blogsclub 打交道多了，有些话，收集起来发在这里，与君共勉。
数载躬行未肯轻，是非功过任人评。
心持灯火照前路，不负江湖不负名。
因为公告和博客是维护组的传声筒，对开往项目举足轻重，所以谁掌握了公告和博客，谁就掌握了开往。
域名这些基础设施固然重要，服务器可能被投毒，域名解析可能被篡改。掌握基础设施的人如果愿意可以导致开往一段时间的瘫痪。但，QQ 群被封了可以发个公告让大家到新群，域名变了可以发通知让大家改域名。项目需要这些基础设施，但并不依赖某个特定的基础设施。换句话说，开往没了某个域名、某台服务器照样还能转。就影响力来说，在我看来不如博客。博客作为开往维护组对外发声的主要工具，同样也是将开往某个成员的想法、观点上升为项目集体意志的主要途径。
某个圈子里有他们自己的道德，好比行侠仗义，讲的是自己心中的义，而不是法律和规定差不多。
你项1跟个球场看台一样，都有一群人在上面看球，下面踢球的每次都不一样。（开往成员群2025年8月20日公告）
不以“世界是个草台班子”为由耻笑任何一个站在台上、且能一直站住的人。创造一出戏要比评价一场表演难一万倍。敢上台的人，就是要比坐在下面黑漆漆人群里的看客牛逼。宁当草台上的主演，不做豪华席位的观众。
摘自微信公众号“新青年王昱”
有时，你会收到来自他人自以为是的指导。他们其实也不知道该怎么做，随便乱说一通，等你失败之后再来一句「我早就说了…」。要清楚台上的人就是比看客牛逼。我也一样。
开往不一定要发博客、发公告、颁布新规则才能算回应，无声本身就是一种回应。（2026年2月8日晚与柯致信）
两年半前，我曾跟着写一篇《加入开往团队所给我带来的》，具陈当时项目的氛围。“希望之后可以将开往内部的一些讨论分享出来，让大家了解，这是一个有趣的维护组，有趣的小团伙。”如今的光景又有些不一样。
就本文章而言，前面说要严格标准不要门槛太低，后面又说审核不透明。加入门槛这件事高了有人骂，低了也有人骂。我们夹在中间很不舒服。但是我们不会让只有初始页的网站加入开往，至于您遇到的网站可能是由于删库导致的，如果您遇到长期没有更新博客的网站可以通过成员列表的投诉功能向开往反应。至于您引用 HowieHz 的文章，建议您阅读开往去年 5 月和 7 月的博客，QQ 群的事情说明不了什么。关于兜底条款，您可以在仓库中搜索有援引该条款驳回的情况。我在审核的过程中援引该条款时会在社群说明。原本我在项目的讨论里发了一个废除兜底条款的帖子，但组里没有同意。兜底条款算是目前比较平衡的一个方案了。最后，我从初三接手开往到现在，除去高三缺席的一年，四年接手经营的项目被您说成黑社会，我深感痛心。感谢您能拨冗写出这一篇炮轰开往的文章。每个人对开往这种项目都有自己的理解。对我来说，我平时逛逛开往，给博客发一点评论，欣赏欣赏别人的文章，这是开往于我的意义。（于《炮轰开往：泛滥低质链接失去初心的开往，还有存在的必要吗？》一文下的留言）
我问：不知你曾经是否有这种感觉：作为一个项目的维护者，很少从这个项目得到成就感，每次都像是给站长们打工似的被催审，出事的时候被嘲讽，还没有人在我们花时间处理申请和事件之后说一声谢谢。维护者有何错，才让站长们群嘲热讽？谁愿意忍受人世的鞭挞和讥嘲、旁人看客的冷眼和费尽辛勤所换来的小人的鄙视。干得好了，是应该的；干不好了，就是自己的失责。钱要自己花，时间精力要自己出，评价的那张嘴却张在闲人头上。
他答：所以我不干啦。（与某人的对话）
这份所谓的规范貌似可以看作十年之约项目组交接的直接原因。目前十年之约主动注销了ICP备案，关闭了项目网站的访问。
夜以继日燃烧着自己热情与精力，秉持着利他主义辛勤工作着的十年之约维护者，已经做得足够好了！（于频道中的发言）
革命的队伍越到后面越是精纯。
在热闹之后是无人问津和费劲不讨巧。做这件事情需要耐得住寂寞，但我显然耐不住寂寞。
先前的我错了，管理一个团队并不是讨好团队里的所有人，并幻想一些人能够在团队中和睦相处，而是划定一个共同的目标，将害群之马从团队里清除出去。讨好别人太累，幻想用自己的热情留下别人不切实际，跟一个不讲道理的人讲道理更是不着边际。
就跟公司一样，开往的开发不是热闹的，热闹的时候也不会用来开发和维护，而是在吵需求、可用性、必要性这类可有可无的东西，因为其实开往本身就是可有可无的东西，有些需求只要妥协一下就消失了。开往项目的维护在时间精力投入上像个无底洞，就跟不断优化博客加载速度、访问体验一样。从开往跳出来对于别人来说未尝是件难事，互联网也不是我们生活的一切。我更希望维护组的成员能在做完自己安排的事情之后，自我提升完，再来弄开往的事情。显然，我自己做不到。我个人从去年开始就有些担心开往正在我的误导下逐渐背离初衷，还有开往被其他的项目淹没（开往不是博客聚合项目。）我个人的领导能力很差，每当维护组群里要吵起来的时候，我这个INFP都很想发“别吵了，你们别吵了”。从小学开始到现在，由我主导的活动、团体比赛无一幸免地失败了，我一直在告诉自己那只不过是过去的自己能力不够，但一次又一次的巧合…上面论证了我在能力和人品上存在不足，外加我对项目的一些看法和期许。（2024年2月16日一些没用的话）
不要每天花出多少时间来维护，只需要能跟着长期做下来。（与某人的对话）
︎
四载心血筑联营，岂为虚名纸上争。
台前尽历风霜路，屏后谁同苦甘情？
春蚕吐尽心尤热，烛火燃残夜自明。
莫道无声真已默，山河不改月长庚。
2026-02-16 20:00:00
很多题不会做，等题解出来在这里一并记录自己当时做题的思路和照着题解做题的过程。
看控制台发现网页每过一段时间向/record发请求（通过Authorization Header 来鉴权），再通过/check检查是否达到足够的时间。tracker.js被混淆了，就是一个黑盒。用 Postman 试试看。
接口并没有限制 time 的大小，那我们填大一点，发完请求在浏览器等一会 flag 就出来了。
但如果挂机等一个小时的话应该也能做出来。
我自己没做出来这一题。
什么你这卖的东西这么贵 什么为什么都用uid了用户名还要抢啊， 什么凭啥admin可以管我们所有人的钱啊
题目的题干
update接口直接改的好像是User类的balance属性欸，但是User属性中balance似乎并非。。。该怎么修改balance呢
题目的提示
一开始看题目和登陆页面看感觉像是 SQLi，要直接登录到 admin 账号去管钱。注入试了两次之后发现能登录，登陆进去发现鉴权用的是 Bearer Token，token 为 JWT，用空密钥试了一下不行。然后对着/api/update接口调了半天，发现没用，睡觉。
第二天醒来接着看这道题，注册了一个用户名和 uid 都是 111 的账号，对着 JWT 解析出来的结果发呆。不知道想到什么了，试着把 111 输到密钥里，验证成功…是哪个地方有问题吗？为什么就验证成功了？我将 token 拿到工具里爆破了一下，工具给出结果：密钥还真是 111。
我猜想密钥应该和 uid 是一样的，因为 uid 也被放在 header 传给接口了。拿其他账号一试，我猜错了：是所有账号生成的 JWT 密钥都是 111 啊。这样就可以构造一个 admin 的 token 了。
然后用这个管理员的 token 在题目环境里试了试，知道了这些信息：
我又试了试，还是没有试出什么名堂来。题目归档之后，CopperKoi 同学把题解发给我，是我没见过的原型链污染。大概就是用前面伪造的 token 发请求到 /update 接口，payload 如下：
{"__init__": {"__globals__": {"balance": 2000000}}}
看样子题目确实是这么解的。
很早以前玩虚拟空间的时候有部署过一个 PHP 文件就实现文件上传、查看、登录等功能，给我当时幼小的心灵带来一些震撼。
“uu是什么意思，很简单吗，分开来想想你就明白啦”，题干是这样说的。从同学口中得知，uu 是 upload & update 的意思。他还说，做题首先应该尝试拿到源码。我在题目环境的/app/update里发现了一个压缩包，像是源码，想着用download_file接口进行目录穿越下载下来又不行，浏览器好像会把../和链接的上一级进行“消消乐”。
然后我就把源码的压缩包下载下来了。打开一看，Rust Cargo！
我将代码喂给 GitHub Copilot 和 Deepseek，Deepseek 给出一种可能的攻击方案：可以先在本地加恶意代码并编译，再通过上传接口将文件上传到/app/update（又是一个目录穿越），等代码自动更新之后拿到 flag。
import requests
url = "http://环境地址/api/upload_file"
files = {
'file': ('../../../../app/update/easyuu',
open('target/x86_64-unknown-linux-musl/release/easyuu', 'rb'),
'application/octet-stream')
}
response = requests.post(url, files=files)
print(response.status_code)
print(response.text)但是没成功。上传文件这个接口的目录穿越可行。但自动更新这个机制能否利用不清楚，本地编译了几次，一直cargo clean cargo build --release --target x86_64-unknown-linux-musl，文件大小都是553928。估计编译出来的一直是老代码。
读附件的代码之后发现应用并没有限制 php 文件的上传，所以上传了一个一句话木马上去，然后用蚁剑连接。结果发现上传附件的文件夹只有我上传的文件，flag也不在文件系统当中。
HGAME 2026 WriteUp最先出现在林林杂语。
2026-02-16 12:28:02
WordPress 如果没有缓存，就会加载得超级慢。此前，我在网站上装了 Jetpack Boost、WP Super Cache 等插件。昨晚看到 此前发的文章，发现还能装一个 Redis Object Cache。
插件装得越来越多，我问 ChatGPT 有没有必要装这么多插件，它向我推荐了一种方案。如今，网站的访问速度基本得到了改善。秒开估计还是有些困难。
WordPress 上的缓存插件都是在 PHP 运行的过程中起作用的，Fastcgi 缓存可以将服务器的缓存前置到 Nginx，如果 Nginx 匹配到缓存文件直接返回，请求不会给到 PHP。
在站点的 Nginx 配置文件伪静态部分后面加上如下片段，其中加粗部分为缓存的有效时间。
set $skip_cache 0;
if ($request_method = POST) { set $skip_cache 1; }
if ($http_cookie ~* "wordpress_logged_in_") { set $skip_cache 1; }
if ($request_uri ~* "/wp-admin/|/wp-login.php|/xmlrpc.php") { set $skip_cache 1; }
if ($args != "") { set $skip_cache 1; }
location ~ \.php$ {
include fastcgi_params;
fastcgi_pass unix:/tmp/php-cgi-85.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_cache WORDPRESS;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
<strong>fastcgi_cache_valid 200 301 302 30m;
fastcgi_cache_valid 404 1m;</strong>
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
add_header X-Cache $upstream_cache_status;
}在 Nginx 的全局配置文件中加上如下片段。
fastcgi_cache_path /www/wwwroot/fastcgi_cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";知道创宇的加速乐本就有 Gzip 自动压缩的功能，默认开启且无法关闭。皓子的 静态资源预压缩：零运行时开销，极致节省带宽 这篇文章给我提供了一种可能的优化路径。因为原先安装的 Nginx 并没有带 Brotli 模块，所以我卸载掉重新编译安装了一个。
然后 apt 安装 Brotli，在网站目录里搜索 js、css 文件并生成其对应的 gz、br 文件。
随后，在 Nginx 站点配置文件中添加关于 Gzip 和 Brotli 压缩的设置。
brotli on; brotli_static on; brotli_comp_level 5;
brotli_types text/plain text/css application/javascript application/json application/xml text/html image/svg+xml;
gzip on; gzip_static on; gzip_vary on; gzip_comp_level 5;
gzip_types text/plain text/css application/javascript application/json application/xml text/html image/svg+xml;但可能是因为 CDN，我并没能测试到服务器返回 br encoded 的内容。
弄好上面的缓存和压缩之后，把 WP Super Cache 插件移除掉网站访问起来也不会太卡。目前网站正在用这些优化速度的插件：
| 插件名 | 用途 |
| Advanced Database Cleaner | 清理修订版本等垃圾数据 |
| CompressX | 提供图片的webp和avif版本 |
| Redis Object Cache | 网站目前使用的唯一缓存插件 |
新年新气象：网站快一点，再快一点最先出现在林林杂语。