https://e138bd74.hugo-blog-ddc.pages.dev/使用思源、Hugo、GitHub 和 Cloudflare Pages 部署的静态博客Hugo -- gohugo.iozh-cnevilstarevilstarTue, 09 Jun 2026 00:00:00 +0000https://e138bd74.hugo-blog-ddc.pages.dev/posts/memory-ingest-throughput-rca-20260609/Tue, 09 Jun 2026 00:00:00 +0000evilstarhttps://e138bd74.hugo-blog-ddc.pages.dev/posts/memory-ingest-throughput-rca-20260609/长期记忆 ingest 30 QPS 吞吐问题：从发现到解决的完整复盘 时间：2026-06-08 ~ 06-09 服务：长期记忆微服务（独立 Python/FastAPI 服务，Kafka 异步 ingest 管道） 结论一句话：30 QPS 下 ingest 处理慢、积压发散，真正根因是「LLM 慢调用期间长期占用 DB 连接 -> 连接池饥饿」，而非 LLM 本身慢或重复消费。在每个只读 DB 阶段后及时释放连接后，单条处理从 6-39s 降到 ~2s，吞吐提升约 7 倍。https://e138bd74.hugo-blog-ddc.pages.dev/post/thoughts-time-and-life-z26np1j.htmlSun, 07 Jun 2026 11:29:58 +0800evilstarhttps://e138bd74.hugo-blog-ddc.pages.dev/post/thoughts-time-and-life-z26np1j.html碎碎念，时间和生命 飞光飞光，劝尔一杯酒，吾不识青天高，黄地厚，唯见月寒日暖，来煎人寿。 时间经常会被比作流水，“逝者如斯夫，不舍昼夜”，这个比喻揭示了一个时间的重要的特质，那就是流动，时间是流动的，连绵不断的，不会停止的，不可逆的。时间是客观的物理概念，将人的主观感受与爱恨情仇附着在时间上，就成为了生命。https://e138bd74.hugo-blog-ddc.pages.dev/posts/github-action-auto-release-macos/Sat, 06 Jun 2026 00:00:00 +0000evilstarhttps://e138bd74.hugo-blog-ddc.pages.dev/posts/github-action-auto-release-macos/最近写了个菜单栏小工具，管理 git worktree 用的。功能慢慢成形之后，就遇到一个很现实的问题：怎么发版。 手动发版是能跑的——本地 xcodebuild 打个包，签个名，做成 dmg，再上传到 GitHub Release。问题是这套动作我每次都要重来一遍，而且总有哪一步会忘。打包忘了改版本号、签名漏了某个嵌套 framework、dmg 名字和上次对不上……这种事一旦靠记性，迟早出错。https://e138bd74.hugo-blog-ddc.pages.dev/posts/thoughts-on-using-ai-effectively/Fri, 29 May 2026 00:00:00 +0000evilstarhttps://e138bd74.hugo-blog-ddc.pages.dev/posts/thoughts-on-using-ai-effectively/经过几个月的实践，我总结了使用 AI 的一些心得体会，在这里分享给大家，希望能有一点帮助。 Context 我们在使用 AI 完成任务的时候，就是从起点出发，要到达一个终点。这之间有很多路径，有些可达，有些不可达；有些会绕很多弯路，有些则是笔直通畅。对于我们来说，我们总是希望在最短的时间内找到最短的那条，而不是盲目的进行 DFS。https://e138bd74.hugo-blog-ddc.pages.dev/posts/spokenly-dictation-custom-ai-model/Fri, 29 May 2026 00:00:00 +0000evilstarhttps://e138bd74.hugo-blog-ddc.pages.dev/posts/spokenly-dictation-custom-ai-model/最近在用 Spokenly 做日常输入，整体体验比我预期的好很多。 它最适合的场景不是那种正式会议转录，而是“我脑子里已经有一段话，不想再敲键盘”的时候。比如写 prompt、记想法、回复长消息、整理一段技术说明。以前这些内容我可能会先在脑子里组织一遍，然后慢慢打出来；现在更自然的方式是直接说出来，让 Spokenly 先转成文字，再交给 AI 做一次润色。https://e138bd74.hugo-blog-ddc.pages.dev/posts/memoryos-architecture/Thu, 28 May 2026 00:00:00 +0000evilstarhttps://e138bd74.hugo-blog-ddc.pages.dev/posts/memoryos-architecture/本文基于 /Users/jishihe/work/MemoryOS 当前代码梳理，重点不是复述 README，而是回答三个问题： MemoryOS 解决的核心问题是什么 代码如何把短期、中期、长期记忆组织成一条可运行链路 PyPI、ChromaDB、MCP、Playground、评测代码分别处在什么位置 1. 架构结论 MemoryOS 是一个面向个性化 AI Agent 的分层记忆运行时。它不是单纯的向量检索库，也不是完整聊天应用，而是把对话记忆拆成短期、中期、长期三层，再围绕这三层提供更新、检索和生成能力。https://e138bd74.hugo-blog-ddc.pages.dev/posts/claude-code-memory-system-design/Wed, 20 May 2026 00:00:00 +0000evilstarhttps://e138bd74.hugo-blog-ddc.pages.dev/posts/claude-code-memory-system-design/Context 这份文档分析的是当前本地源码树： /Users/jishihe/work/civil-engineering-cloud-claude-code-source-v2.1.88/01-claude-code-source-crack/claude-code-source 目标不是复述官方文档里的“Claude 有记忆”，而是从源码出发回答几个设计问题： Claude Code 到底把“记忆”分成了哪几类？ 每类记忆存在哪里、什么时候加载、什么时候写入？ 它如何避免把所有历史无脑塞进上下文？ 它如何和 /compact、session resume、agent、team sync 这些系统组合？ 这套设计的取舍是什么？ 先给结论：Claude Code 的“记忆系统”不是一个单点功能，而是一组分层持久化机制。它把规则型指令、跨会话偏好/事实、当前会话工作状态、Agent 专属经验、团队共享知识拆成不同数据面，并用不同的注入方式控制上下文成本。https://e138bd74.hugo-blog-ddc.pages.dev/post/some-thoughts-on-religion-faith-and-death-ytsg4.htmlSat, 16 May 2026 14:01:46 +0800evilstarhttps://e138bd74.hugo-blog-ddc.pages.dev/post/some-thoughts-on-religion-faith-and-death-ytsg4.html东方宗教和西方宗教对于死亡的看法很不一样，以佛教为例，认为人死后灵魂进行转世，根据生前的所做所为进行评判，如果生前行善积德，转世生到富贵人家；如果作恶多端，沦为畜生或者饿鬼，在十八层地狱下经受磨难。佛教来自印度教，轮回的概念也是一脉相承下来。对此我有一些疑问，评判的标准是什么，善恶的标准又是什么，如果一个人拥有很多钱财，热衷于慈善事业，拯救了很多濒临死亡的穷人；但同时为了获得财富，他杀掉了一些竞争者。他杀掉的人可能只有几个，但是拯救的人可能有几千个，几万个。那么这个人转世之后会成为人还是成为畜生呢？ 如果没有客观的标准，那么应该会有一个全知全能的神来判决，神如何判决呢，作为人应该不得而知，不可知的东西为什么会让这么多人深信不疑呢？ 无论怎样，死亡不是终点，死亡即是新生，轮回无休无止，只有拥有大功德的真佛才可以涅槃超脱。https://e138bd74.hugo-blog-ddc.pages.dev/posts/agent-session-manage-architecture/Thu, 14 May 2026 00:00:00 +0000evilstarhttps://e138bd74.hugo-blog-ddc.pages.dev/posts/agent-session-manage-architecture/最近这段时间，我在本地同时用 Claude Code 和 Codex 做开发的频率越来越高。 工具一多，一个很烦的问题就开始反复出现：session 太难找了。 有些对话在 Claude 里，有些在 Codex 里；有些项目我开了很多个 worktree；有时候我只记得一句提问、一个报错，或者记得那次对话大概发生在哪个分支上，但就是想不起来它到底在哪个 session 里。https://e138bd74.hugo-blog-ddc.pages.dev/posts/claude-code-compact-mechanism/Mon, 11 May 2026 00:00:00 +0000evilstarhttps://e138bd74.hugo-blog-ddc.pages.dev/posts/claude-code-compact-mechanism/Context（为什么需要这份分析） 用户想弄清楚 Claude Code 的 compact 功能在源码层面是如何实现的。这不是一个实现任务，而是一次对 /Users/jishihe/work/civil-engineering-cloud-claude-code-source-v2.1.88/01-claude-code-source-crack/claude-code-source 这份泄露源码的逆向阅读。产出就是这份文档——没有要改的代码。