SpeechlessPanda

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

本篇文章是最近看的部分博客、文章和视频之后有意识的整理以及产生的思考。在此也推荐一篇比尔·盖茨的博客 The turbulent AI era is here. The choices we make now are critical. AI is coming! 这是一个客观事实，但还有很多很多隐藏在这个冰山之下。老生常谈的话题是， AI 会取代大家的工作。我之前的观点得到了很多渠道的印证，就是 AI 平等的踹死一切岗位。不止计算机，其他专业也是如此。在计算机专业里，有人觉得硬件和 infra 是个出路。不可否认，暂时来看，比其他方向要好。但是硬件一贯待遇不好，且最近 Anthropic 宣布推出硬件用 MCP：Model Hardware Standard（MHS），加上具身智能的迅猛发展，硬件岗位的中层也将死一大片。至于 infra ，更多是因为暂时这方面岗位会比较多，但是 AI 也已经能做到比大部分人 infra 做得好了。 之前的信心，来源于以前的技术革命中，新出现的岗位会替代旧的岗位吸收人口。但现在这个迷之自信要被我亲手打破。之前的变革大多会持续几代人，并在这个过程中...

本文摘取 learncpp 教程中的规则、最佳实践和警告部分构成（由笔者手动复制粘贴）。像所有最佳实践一样，本文内容应作为指导方针，而不是绝对的教条。在遵循它们的同时，请始终结合具体场景进行判断。 全文共 218 条规则，按 31 个主题分组整理。点击各主题标题即可展开查看，文末附有核心原则速览表。 1. 变量与初始化良好的变量习惯是写出清晰、可维护 C++ 代码的基础。 #1 首选直接列表初始化或值初始化来初始化变量，并在创建变量时立即初始化。 #2 将局部变量定义在尽可能靠近其首次使用的地方。 #3 不要对值参数使用 const，按值返回时也不要使用 const。除此之外，应尽可能将变量声明为常量。优先使用常量变量，而不是带有替换文本的类对象宏。 #4 避免在代码中使用“魔法数字”，而是使用 constexpr 变量。 #5 任何初始化器为常量表达式的常量变量，都应声明为 constexpr；初始化器不是常量表达式的，则应声明为 const。 #6 尽可能使用局部变量而非全局变量。 #7 只在循环内部使用的变量，应该在循环的作用域内部定义。 2. 类型与数值选择合...

今天看完了梁文锋在投资者交流会上的发言，全文三万多字，看下来觉得时间花的值（虽然也是在等 agent 干活的时候看的）。 叠甲：鉴于这是投资者大会上的发言，且本人的感悟也只是读了这篇发言（且懒得二次验证），所以其中不一定都是真相，甚至极大概率梁文锋在里面讲了不少故事。但其中蕴含的一点精华就足以对你我有益，故此有此文。 克制 首先是他非常强调克制。本身幻方和大企业比规模不能算大，所以他们能这么成功，离不开他们始终坚持走在实现自己愿景的路上，以及坚定地执行路线图。他们专注于智能的提升，他们认为多模态并不是智能提高的表现，所以没有当成主线去做，更多是为了回应 C 端的期待。同样，他们认为世界模型也没有提高模型智能，所以也没有做这个。在他们的路线中，智能是第一重要的，等模型能够自主学习和进化之后，他们的任务才算阶段性完成，届时才会开始具身智能这些其他方向的研究。关于具身智能，他认为是一定要做的，因为只有这样 AI 才能更好落地，普惠更多人，做更多事。但是他们是一条线的在去做，而不是像其他公司多线并行。 关于克制另一个很好的体现是商业化。众所周知的是，国内御三家都在积极谋求上市。不难...

先叠甲，本人还没上过班，所以发言肯定有不当之处，纯空想。 看某公司的技术文章，其中说他们把仓库的文档做好分层结构化整理之后，不仅 agent 干活效率更高，新人也能快速上手了。 原话是：一个有意思的副作用：这套知识库对人类新人同样有用。我们组新同学入职后，不再需要"找老人聊一上午"才知道项目结构——直接读 overview.md 加几份模块 wiki，半天就能上手改 bug。“AI 友好” 和 “新人友好” 在这里完全统一了。 看着有一种怪诞的感觉。大家之前不知道这样可以提高新人的效率吗，肯定是知道的，但是没人愿意这么做。我想了想，粗浅的认为有三种可能的原因。 人可以选择性遗忘无用的知识，不会被仓库淹死 第一种没什么好说的，目前人类相对于 AI 来说为数不多的优势和价值所在。人能够选择性的忘掉一些不重要的上下文，或者只保留个印象，到需要的时候再去重新读取一遍。而所有 AI 目前都面临着上下文问题，大家想了很多办法来缓解，比如 RAG 、分层结构化文档和记忆宫殿等，但是还是做不到完全像人类的机制一样优秀（所以有些事记不住就记不住吧， AI 有数值，你有...

今天刷 leetcode 每日一题，题面如下：给你一个整数 n ，请你计算以下两个值的最大公约数（ GCD ）： sumOdd ：最小的 n 个正奇数的总和； sumEven ：最小的 n 个正偶数的总和；返回 sumOdd 和 sumEven 的 GCD 。 给大伙看看用辗转相除法怎么做。 123456789class Solution {public: int gcd(int x, int y) { return y == 0 ? x : gcd(y, x % y); } int gcdOfOddEvenSums(int n) { return gcd(n * n, n * (n + 1)); }}; 事实上，要是用上 <numeric> 库里自带的 gcd 函数，这道题将会更简单。但是今天分享的重点不在这里，让我们关注一下最后一条语句。学过高中数学的都知道，这是由等差数列求和公式算出来的奇数和和偶数和。具体公式如下： sumOdd=1+3+⋯+(2∗n...

今天刷 leetcode 遇到一个很神奇的问题：给你一个整数数组 nums 和一个整数 k ，请你统计并返回该数组中和为 k 的子数组的个数 ，子数组是数组中元素的连续非空序列。 单看问题本身并不神奇，但是它的题解非常有趣。我把两个题解放在下面，读者不妨猜猜看，哪个题解是官方的能通过的题解。 12345678910111213141516171819202122232425262728293031323334353637383940class Solution {//题解1public: int subarraySum(vector<int>& nums, int k) { const int n = nums.size(); int count = 0; for (int start = 0; start < n; ++start) { int sum = 0; for (int end = st...

刚刚阅读了 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 ），但另一方面，也因为我舍友和这位学姐，已经是短暂不用担心“前途”的阶段了。学姐不用说，舍友也是大概率能保研或...