墨池码窖 | Sentixxx's Blog

如果你在其他平台看到这篇文章，这可能不是最终版本。为了获得更好的阅读体验（包含最新的评论讨论和勘误），欢迎移步原文 最近终于是要毕业了，于是准备换掉我原来陪伴了我三年的 niz 静电容，换一把新键盘，经过一番物色，我在视频博主的推荐下选择了 WOB rainy75 这把键盘，然后马上给它物色了一套心仪的键帽： 加装了键帽的 rainy75 看上去还挺不错！ 但是随着我开始在 Mac 下使用，问题出现了…… 第一个问题是我发现这个键盘的 2.4G 开关居然是放在了 CapsLock 键下面。 是的，在键帽的下面，这就导致如果你想要打开 2.4G 就需要把键帽拆掉，然后用手把开关打开，再把键帽给安排上去。 好在这样的设计你只需要拆装一次，后面就可以通过键盘的 Fn 组合键进行切换——不过这样一来，我们就没法主动控制键盘的节电了，很麻烦。 第二个问题更加离谱，如果你在 Mac 下使用这把键盘，那你有福了。 我们知道 Mac 的键位由 Control、Option 以及 Command 键组成，而 Command 键位在这三个键中处于第三列，但是在很多键盘上的却映射到了 Win...

如果你在其他平台看到这篇文章，这可能不是最终版本。为了获得更好的阅读体验（包含最新的评论讨论和勘误），欢迎移步原文 开源壁纸软件 今晚，我像往常一样刷了会视频，突然看到了一个比较吸引我的视频： 可能是Mac上最好用的开源壁纸软件，wallpaper engine近乎完美渲染 ，我点进去一看，我去！居然可以从 wallpaper engine 的创意工坊直接下载壁纸！我去！居然还能从 wallheaven 爬壁纸！这一下子解决了我之前在 macOS 上遇到的好几个关于壁纸的痛点，于是乎我马上找到了这个项目的地址，准备下载下来体验一下，然后我就发现了几个大问题： UI 设计非常 AI，项目整体风格和 MacOS 的设计语言并不搭配 我发现下载实际上是通过 steamCMD 来实现的，这就要求我们去输入自己的 steam 密码与令牌 第二个问题让我有点担心，于是我就把源码也拉下来快速 vibereading 了一遍，很快我就发现了代码里关于密码的处理有相当多的 AI 幻觉，似乎开发者完全是处于一种盲目的 wishcoding...

如果你在其他平台看到这篇文章，这可能不是最终版本。为了获得更好的阅读体验（包含最新的评论讨论和勘误），欢迎移步原文 随着 LLM 编码能力的飞速提升，结合我近期的观察，技术圈似乎正在向同一个方向演进：利用 AI 构建高度客制化的个人软件。 这一趋势的背后有两个主要推手。首先，不少开源项目在大量接收 AI 生成的 PR 后，代码质量出现了肉眼可见的下滑——与其在泥沙俱下的代码海里做 Code Review，不如自己来。其次，大家逐渐意识到，与其苦等上游更新，自己 Fork 甚至从零重写来得更快，而且更贴合自己的实际需求。多年前人人皆可写软件的设想，似乎正以一种始料未及的方式悄然成真。 这也引发了我的深思：在 AI 时代，什么样的软件形态才是真正的未来？ 从一个状态栏插件说起 最近因为订阅额度紧俏，我开始尝试在 pi 中使用 deepseek 作为一些简单的任务的替代品来节约 token 的使用，之所以使用 pi 而不是直接在 codex 或是 claudecode 里接入 deepseek 的原因有两点： codex 和 claudecode...

如果你在其他平台看到这篇文章，这可能不是最终版本。为了获得更好的阅读体验（包含最新的评论讨论和勘误），欢迎移步原文 最近高强度使用 Codex 桌面 app 进行开发（因为这真的很方便），你可以在一台电脑/手机上同时和多台电脑上的 agent 进行沟通，当然了，我也安装了一些插件，比如 github 插件，这就遇到了第一个坑：openai 提供的插件中会覆盖我们的一些项目配置，这在 agent 看来似乎优先级较高，比如我们要求在 PR 中按照我们给定的格式，并且按照中文，但是如果你开启了 github plugin 中的 yeet skill，agent 就会去读取其中定义的一些模式，从而违背项目的规则，这就很蛋疼。

如果你在其他平台看到这篇文章，这可能不是最终版本。为了获得更好的阅读体验（包含最新的评论讨论和勘误），欢迎移步原文 最近写博客的时候大量上传了很多图片到我的 github 图床里，这种打擦边球的行为实际上是违反了 github 用户条例的，再加上今年 github 的基础设施状态疑似不是很好，以及前阵子我的小号有被封号的惨痛经历，这让我开始下定决心要转移我的图床。 既然决定要换，那就先来调研一下目前市面上有哪些可选方案。 方案调研 付费方案 对象存储 各家云厂商的付费方案大同小异，核心都是将资源托管在对象存储（如 OSS / S3）中，再通过 URL 进行外链访问。好处是你可以再接一个 CDN 资源给国内访问做加速，这样国内也能正常加载。坏处也比较明显： 要钱 不续费也不备份的话，图片就会消失，而且存储下线后，图片的映射关系就丢了 如果需要自定义访问域名则需要备案 这个问题倒还行，因为我之前因为折腾 cardconjurer 这个项目，已经完整地走过一遍阿里云 OSS 的方案流程了 ...

如果你在其他平台看到这篇文章，这可能不是最终版本。为了获得更好的阅读体验（包含最新的评论讨论和勘误），欢迎移步原文 正如之前所提，我为适配 ClaudeCode 专门配置了一套沙盒体系。最近，我打算借此机会系统地梳理一下这套环境目前的搭建现状与进展。 如果从一个完整的视角来看，这套体系其实应该分为沙盒、宿主机以及本地机器。 宿主机 我的宿主机是一台 MacOS 设备。也正是如此，其实不太需要过分担心最近 Linux 内核连发的那些 CVE 漏洞，因此直接选用 Docker 作为沙盒方案。 在宿主机层面，主要做了两项核心配置：网络代理与目录挂载。 代理网络分流 为了更好地适配 Claude Code 的请求，我对网络进行了针对性的分流处理，具体策略如下： 常规分流：根据预设规则，对常见域名进行基础分流。 定向代理：将 Anthropic 相关域名精准路由至固定节点，保证 API 连通性。 沙盒兜底：针对沙盒所在的 IP 网段设置特殊规则作为兜底，将其流量同样指向特定的节点。 目录挂载 起初，为了让沙盒重启后状态不丢失，我直接把整个 Home...

如果你在其他平台看到这篇文章，这可能不是最终版本。为了获得更好的阅读体验（包含最新的评论讨论和勘误），欢迎移步原文。 写在前面 最近在折腾容器内开发，工作流很简单：容器先在外部跑起来，我再用 VS Code 的 Dev Containers: Attach to Running Container... 直接连进去。 结果踩了一个极度别扭的坑： git pull、git ls-remote 看起来都正常 但一到 git push 就开始报认证错误 更气人的是，我明明前面已经把仓库切成了 PAT，过一阵子又像是“被切回去了” 一开始我也以为是最常见的那几类问题： PAT 过期了 GitHub 权限不对 容器环境重启后没把凭证保存住 但顺着日志往下挖，最后发现这次还真不是 PAT 本身的问题，而是 VS Code Remote / Dev Containers 自动注入的 git credential helper 在接管认证链路。 这篇文章完整记录了整个排查过程和最终结论，希望能帮大家少在这类“明明配过，结果又像没配”的灵异问题上浪费时间。 ...

如果你在其他平台看到这篇文章，这可能不是最终版本。为了获得更好的阅读体验（包含最新的评论讨论和勘误），欢迎移步原文。 写在前面 作为一个折腾爱好者，最近在弄让 AI Agent 自动跑项目、提 PR 的工作流。结果一开始没做频率限制，专门给 Agent 用的 GitHub 小号用裸的 gh CLI 短时间内狂刷 PR 和评论，直接被 GitHub 的防滥用风控当场封禁（Suspended）。 痛定思痛后，我决定引入 MCP（Model Context Protocol）来接管 GitHub 操作，因为官方 MCP 自带了完备的限流和退避机制。但同时，为了让 Agent 还能正常执行 git push，我依然在容器的环境变量里留了一个 PAT（Personal Access Token）。 结果在观察日志时，我发现了一个更危险的现象：大模型一旦发现 MCP 工具调用失败或者图省事，它就会直接去翻环境变量里的 PAT，然后自己手搓 curl 脚本去直连 GitHub API！而且它的脚本一旦报错，它为了修 Bug...

如果你在其他平台看到这篇文章，这可能不是最终版本。为了获得更好的阅读体验（包含最新的评论讨论和勘误），欢迎移步原文 本文部分内容采用 AI 辅助生成，核心素材与推演逻辑均提炼自排查该 Bug 时的真实 Session 对话文本。 越读越烂，返工一下 —— 2026.4.20 一个矛盾的回复 事情的起因源于 cc-connect 的一个 bug：同一分钟内，Telegram 群收到两条互相矛盾的回复 一条说"会话已结束" 另一条说“前一条请求仍在处理”。 显然这是矛盾的。 我很快梳理出了问题的链路，并提交了响应的 PR。 问题排查 第一层，agent 进程没死透。 agent/claudecode/session.go 的 readLoop 用 bufio.Scanner 读 stdout。Claude CLI 退出时，若有子孙进程继承了 stdout fd，管道不会 EOF，scanner 就一直阻塞。cs.ctx.Done() 触发时，defer 里虽然会关 channel，但那一路逻辑分支没有关 stdout，于是 readLoop...

如果你在其他平台看到这篇文章，这可能不是最终版本。为了获得更好的阅读体验（包含最新的评论讨论和勘误），欢迎移步原文 GFS 是什么 GFS 是 Google 为了应对海量数据增长，通过分布式软件架构抵消廉价硬件的不可靠性，并针对其特定业务（大文件追加、流式读取）量身定制的高扩展存储系统。 预设的情景提到 Google 的大多数场景都是顺序读，这是什么场景？ Google 早期的大量任务（如构建搜索索引、数据分析）主要依赖 MapReduce 等分布式处理框架，这些程序通常会扫描整个数据集。它们从文件的开头开始，一直读到结尾，将数据分块处理 架构 GFS 的架构如下图所示 一个 Master 节点 元数据全部在内存中进行处理，但会以追加 LOG 的形式持久化到磁盘 块位置通过查询得到，无需存储 控制流和数据流分离避免主节点成为瓶颈 若干个 ChunkServer (默认三副本不同机架) Q：为什么往磁盘中写 LOG，而不是用数据库的形式管理 LOG 呢？ A：磁盘可以对大量 LOG 直接进行一次性的追加写，这样只需要等磁盘旋转一次，但是数据库是 B...