SpeechlessPanda

这篇博客是由 AI 编写，但里面的项目是由我选取。后续会持续更新。 收集 GitHub 上值得关注的优质开源项目，按类别整理，持续更新。Star 数截至 2026-06-30（每半个月更新一次）。🆕 标记表示最近一次同步新增的项目，点击下方分类标题可展开查看详情。 AI 编码代理这类项目是当前最火的赛道——让 AI 直接在终端里帮你写代码、跑任务。 Cherry Studio ⭐ 48.0k — AI 生产力工作室，集成智能对话、自主代理和 300+ 助手，统一接入前沿 LLM。桌面 GUI 应用，适合非终端用户高效使用 AI。亮点是开箱即用的丰富助手生态和跨平台桌面体验。 Goose ⭐ 50.5k — 开源可扩展 AI 代理。超越简单的代码建议，支持安装、执行、编辑和测试，可搭配任意 LLM 使用。亮点在于高度可扩展的插件架构，面向终端和自动化场景。 Warp ⭐ 62.6k — 诞生于终端的智能开发环境。将传统终端升级为 AI 驱动的 agentic 开发环境，集成了智能补全、命令搜索和工作流自动化。 Toad ⭐ 3.3k — 终端 AI 统一接口。用一...

刚刚阅读了 Design Patterns Suck 这篇文章，对设计模式有了些新的思考，且发现在之前代码品味与架构设计中可能给了些错误的引导，出于对本博客为数不多读者的负责，我快马加鞭写了这一个小短篇。 里面让我对设计模式有了重新思考的一个观点是：设计模式并不是在解决你的问题，而是让你解决语言本身的问题。我们这学期学习的 java 之所以这么推崇设计模式，是因为 java 本身的语言特性不足。 java 设计者认为，如果你给开发者太多权力，他们会自毁前程。但现在大部分语言都不是这样，尤其是 python 和 cpp 。因此设计模式就会显得冗余和过度包装，为了使用设计模式而使用设计模式，就像刚拿到什么高级工具的小孩，在解决一个简单问题时也想用所谓的高级工具（说的就是我）。 其实我早应该发现这个问题的，本人一向是质疑复杂度，推崇奥卡姆剃刀原理的。我反思了这次我被设计模式冲昏头脑的原因，有以下两点。一是，对于刚入门的程序员来说，设计模式实在显得太高级了，一度被我认为是我的大学课堂中为数不多以后能用上的内容。二是，之前和佬的交谈中，将设计模式与代码品味关联在一起，更是为其蒙上了神秘的面...

前情提要这篇博客的思考来源于两个方面，一个提出了问题，一个解决了问题: 我在不久之前尝试 vibe 了一个 AI 游戏，在很好的遵守了我之前摸索出来的大部分经验的情况下，项目依旧理我的理想预期差很远（但是情况比上次好了，说明上次的经验是有用的）。 加到了一个在架构设计和代码品味两方面都表现相当好的佬的 QQ ，和他聊了一下相关的问题，收获颇丰，某种程度上知道了如何解决上面的情况。 之前的经验详情请看vibe coding 开发 BFE 后的反思与总结，先看这篇可以获得最佳食用体验，且里面干货同样满满（我自夸中，不符当没看到，谢谢您嘞）。 第一点中遇到的问题，颇有点像我上次推荐的当规则堆积成为智能的坟墓中提到的项目的腐化和不 review 代码导致的智能技术债务的堆积（这个博客的作者也是大佬来的，自己在开发一个 harness 项目）。 k10s 的负责人，最近删掉了目前所有的该项目的代码，也跟这个有关。虽然这篇博客更面向团队，但是由于我经验和能力都不太足，这个债务堆积的特别快。 代码品味必须承认，我并没有 100% 按照上次的准则去做。我省略掉了最耗时间但是其实也是最...

这几天，阴差阳错将一个保研来我们学校的学姐（不是我们专业的）带上了学习 claude code 怎么使用的路，看着她兴致勃勃的探索，并逐渐掌握我大部分日常用的内容，我不由得感叹原来 agent 的普及率没我想的那么高，以及会用 agent 真的不能算一个多么有优势的点。两个舍友也恰巧开始摸索如何使用 claude code 了，无时无刻不震惊于 claude code 的强大，就像我一年前一样（有一说一，看着挺好玩）。水群确实害人不浅啊，我以为我身边早已经被 agent 包围了。 但是最感慨的两点是，原来还可以不是 fomo ，原来真的没必要 fomo 。我能感觉到他们学习使用 agent 的时候是快乐的，那是一种发现 agent 真的帮助自己提升效率，和省去一些琐事的时间的快乐。他们没有担忧自己会被 agent 替代，也没有想过自己和 agent 比竞争优势在哪里。讲真我很羡慕。虽然我猜一方面有可能是还不知道 agent 到底有多强（用的还只是 dsv4 和 mimo ），但另一方面，也因为我舍友和这位学姐，已经是短暂不用担心“前途”的阶段了。学姐不用说，舍友也是大概率能保研或...

昨晚由于一些原因，深入了解了一下之前就听过的 Warp ，看完之后非常心动，非常迫切想试一下。但是由于之前的 Powershell 已经有各种配置了，改用 Warp 同样的东西要再配一次，还要改各种软件的终端，虽然这可能是很快的事，但是我事太多了，多到哪怕时间不用花太多，我也没这个精力了，哎。 由此我思考了一些我面临的快与慢的矛盾。现在的技术发展的太快了，我应用和学习使用的速度远远慢于新项目和好项目出现的速度。甚至我之前已经应用了解变成我工作流一部分的项目，会成为我接触新项目的阻碍，迁移成本只是阻碍的一部分，还有重新学习的成本。所以有句话说，学的越慢，学的越快，慢就是快。 有人会说，之前你不是告诉过如何减缓 fomo 吗，怎么自己做不到。但其实我认为我这次并不能算 fomo ，因为我感觉这个项目是能解决我的一些需求的，而不是创造了我的需求。虽然有点需求被放大了的嫌疑，但这就像，你可以和 GPT chat 然后把他生成的代码复制粘贴到文件中，且你需要写代码的时候很少，但当有 agent 能帮你直接编辑文件的时候，你肯定也还是会去想试一试。哪怕我就算有点 fomo 的嫌疑，我认为也是...

苦难定理 1 ：我总是会平凡的度过一段时间后，周期性的经历一个满是苦难的阶段。 苦难定理 2 ：在苦难阶段内，苦难会一窝蜂的降临。 今天过的真是太痛苦了，感觉最近越来越痛苦。昨晚因为比赛酣畅淋漓的失眠了， 3:30 才睡着，还是 2:30 的时候受不了了，刷了会手机缓解焦虑才达到的效果，尽管这间接推动了我们整个比赛的进度——今早起来就把昨晚在脑子里翻来覆去想的事中能做的先做了——这也侧面说明了我为什么焦虑，感觉进度只有我在推，甚至一次失眠起来后的兴起让进度翻了起码一半说是。这里没有责怪队友的意思，毕竟确实队友好像也有其他事忙，不过确实让我感觉不安，因为这个比赛不像能有精力分心打好的比赛， emmm ，暂时没有责怪的意思吧。想到指导老师之前和我说的一句话，你要做好大家不能 all in 基本只能靠你自己的准备，真是我靠。 这时候就有好奇的人要问了，作者作者，为什么这个比赛打着这么难受，还要团队协作，你还要去打呢。别问，问就是泥深的保研率和额外加分政策是我大学目前为止，所有苦难阶段的根源。 然后下午看 dsa 这门课的课件。惊讶的发现有个课件居然有一多半的内容要自学，要是我学分绩...

最近在学 rust 。事情的起因是，有人跟我说：“学完 rust 之后你就自动会写安全现代的 cpp 了”。我对于这种能提高编程思维和品味之类的事，由于本就缺乏，所以会更感兴趣。加上那段时间还算清闲，我很快就开始了 rust 的学习。 那么清闲的时光已经离我远去了，我什么时候才能再拥有那样的时光呢，欸。 说实话，我现在已经学了教程的一半，但是由于基础差的太多，所以对那句话我还是不太能理解。这个状态一直持续到我看了一本书，叫做《代码的文明》。不是什么很流行的书，说不定也不是什么很高质量的书，因为我在 zlibrary 上甚至没找到电子版，最后还是买了本实体书（上次买实体书还是在上次了）。主要讲的编程语言的发展史，以及背后蕴含的设计哲学和思想。对于我这种还没有深度使用过多种语言，没有感受过具体形式之上，有关抽象层面的语言差距的小菜鸟来说，这本书还是非常有用的，至少给了我一个思考的方向，带我入了门。 接下来我将结合在学习 rust 过程中的感悟和看那本书的收获，谈一谈我对那句话浅薄的理解——一切的关键都在于所有权——这是 rust 的核心，也是 rust 领先于其他语言的机制优势。...

在前文中，我们曾提到过， BFE 比同量级的项目多花了多得多的 token ，这固然有第一次 vibe 不太有方法论和策略，整体规划做的不太好和 token 是免费的用起来不心疼的原因，但就算将上述原因全部纳入考虑，如此庞大的 token 消耗数依旧是不太正常的。所以，我猜测， BFE 中可能有部分需求触及到了 agent 能力的边界。目前我想到最有可能的就是，对十个主题的适配。由于我的项目定位更像是一个辅助平台，所以他是从现有的两个博客框架 hexo 和 hugo 中各挑了五个主题，辅助用户搭建这十个主题的博客。由于主题都是个人创作者发布并维护的，加上框架并没有规定官方的统一格式，所以每个主题的格式和配置基本都不一样。这就需要 agent 从网上下载十个主题的源码，浏览并学会如何使用，辨别出每个主题的不同，再用适配的脚本将用户的配置填入到特定的主题中。事实上，这是我理想中 agent 应该干的事，但是我的 agent 似乎在搜索和辨别这方面偷了懒，十个主题有些一次就能过，有些就不行。有些配置有的主题支持，有的不支持， agent 也未识别出来。 但，将这个可能性列出来之后，我发...

项目简单介绍BFE 全称 BlogForEveryone ，是一个专为小白设计的面向 GitHub 部署的一站式博客搭建创作发布软件。这是项目的仓库，想要体验的可以直接点进这个链接，软件内有详细的教程。欢迎大家前来体验，有 bug 或者有什么想和我交流的都欢迎直接联系我。 项目开始之前如果我们想要通过 vibe 出来的项目来学东西，无论是学语言，还是学类似的项目应该怎么构建，还是学项目的管理和最佳实现等诸如此类的内容，那我建议在项目正式开始之前，先跟 agent chat 。我们可以先从最简单的问题开始，比如这个项目最好用什么语言实现，逐步通过 chat 的方式让我们了解整个项目怎么写，应该怎么构建。这个过程中，我们提出的问题很重要，要有意识的提那些让项目能够逼近最佳实现的问题。如果毫无头绪，也可以问 agent 有没有什么类似的成功的项目，问 agent 他们好在哪里，问题又在哪里。我们可以不关心最底层怎么实现，但是再往上的所有内容我们都需要在这个环节进行一些了解，这才能有助于我们在 vibe 的过程中学习到东西，对项目也有着更好的掌控。 这里有个小小的 tips :对于小白...

本来这篇文章的内容应该在我记录项目的那篇博客里的，但是后面发现想写在前面的东西太多，又有很多跟项目开发无关的内容，就单独拎了出来。 有关项目这是我多看之后想做的第一个项目，从 idea 的分类上有点像之前博客里的第二点。简单来说，是想搭建一个一站式博客搭建平台，让想写博客搭自己博客网站的小白能够更容易开始。 idea 的来源离不开我个人搭建博客的经历和实践，同样印证了我之前博客里的观点，idea 的产生与实践分不开。其实在编写那一篇博客的时候，这个项目就已经开始了，所以有了当时的最后一段。因为我当时已经知道类似的项目已经有人做过了，且在老资历那里家喻户晓（前面提到的博客都是这一篇：多看之后，有关idea）。 看想做后记在我决定开始这个项目之后，我对之前的多想多看和实践有了更多新的感悟，所以在正式介绍项目之前，我先把这部分内容补充完整，就当是作为前面博客的后记。 怎么搞得如果你看我的博客，好像还有点风险了呢（bushi）。因为我会把一个想法在不同的博客逐渐补充完善甚至推翻，如果只看一篇好像容易被误导说是。但我觉得记录这种变化和过程是有意义的。 首先回顾一下前面提到过的两个看起来...