https://81adcf3e.hugo-blog-ddc.pages.dev/使用思源、Hugo、GitHub 和 Cloudflare Pages 部署的静态博客Hugo -- gohugo.iozh-cnevilstarevilstarFri, 29 May 2026 00:00:00 +0000https://81adcf3e.hugo-blog-ddc.pages.dev/posts/thoughts-on-using-ai-effectively/Fri, 29 May 2026 00:00:00 +0000evilstarhttps://81adcf3e.hugo-blog-ddc.pages.dev/posts/thoughts-on-using-ai-effectively/经过几个月的实践，我总结了使用 AI 的一些心得体会，在这里分享给大家，希望能有一点帮助。 Context 我们在使用 AI 完成任务的时候，就是从起点出发，要到达一个终点。这之间有很多路径，有些可达，有些不可达；有些会绕很多弯路，有些则是笔直通畅。对于我们来说，我们总是希望在最短的时间内找到最短的那条，而不是盲目的进行 DFS。https://81adcf3e.hugo-blog-ddc.pages.dev/posts/spokenly-dictation-custom-ai-model/Fri, 29 May 2026 00:00:00 +0000evilstarhttps://81adcf3e.hugo-blog-ddc.pages.dev/posts/spokenly-dictation-custom-ai-model/最近在用 Spokenly 做日常输入，整体体验比我预期的好很多。 它最适合的场景不是那种正式会议转录，而是“我脑子里已经有一段话，不想再敲键盘”的时候。比如写 prompt、记想法、回复长消息、整理一段技术说明。以前这些内容我可能会先在脑子里组织一遍，然后慢慢打出来；现在更自然的方式是直接说出来，让 Spokenly 先转成文字，再交给 AI 做一次润色。https://81adcf3e.hugo-blog-ddc.pages.dev/posts/memoryos-architecture/Thu, 28 May 2026 00:00:00 +0000evilstarhttps://81adcf3e.hugo-blog-ddc.pages.dev/posts/memoryos-architecture/本文基于 /Users/jishihe/work/MemoryOS 当前代码梳理，重点不是复述 README，而是回答三个问题： MemoryOS 解决的核心问题是什么 代码如何把短期、中期、长期记忆组织成一条可运行链路 PyPI、ChromaDB、MCP、Playground、评测代码分别处在什么位置 1. 架构结论 MemoryOS 是一个面向个性化 AI Agent 的分层记忆运行时。它不是单纯的向量检索库，也不是完整聊天应用，而是把对话记忆拆成短期、中期、长期三层，再围绕这三层提供更新、检索和生成能力。https://81adcf3e.hugo-blog-ddc.pages.dev/posts/claude-code-memory-system-design/Wed, 20 May 2026 00:00:00 +0000evilstarhttps://81adcf3e.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://81adcf3e.hugo-blog-ddc.pages.dev/post/some-thoughts-on-religion-faith-and-death-ytsg4.htmlSat, 16 May 2026 14:01:46 +0800evilstarhttps://81adcf3e.hugo-blog-ddc.pages.dev/post/some-thoughts-on-religion-faith-and-death-ytsg4.html东方宗教和西方宗教对于死亡的看法很不一样，以佛教为例，认为人死后灵魂进行转世，根据生前的所做所为进行评判，如果生前行善积德，转世生到富贵人家；如果作恶多端，沦为畜生或者饿鬼，在十八层地狱下经受磨难。佛教来自印度教，轮回的概念也是一脉相承下来。对此我有一些疑问，评判的标准是什么，善恶的标准又是什么，如果一个人拥有很多钱财，热衷于慈善事业，拯救了很多濒临死亡的穷人；但同时为了获得财富，他杀掉了一些竞争者。他杀掉的人可能只有几个，但是拯救的人可能有几千个，几万个。那么这个人转世之后会成为人还是成为畜生呢？ 如果没有客观的标准，那么应该会有一个全知全能的神来判决，神如何判决呢，作为人应该不得而知，不可知的东西为什么会让这么多人深信不疑呢？ 无论怎样，死亡不是终点，死亡即是新生，轮回无休无止，只有拥有大功德的真佛才可以涅槃超脱。https://81adcf3e.hugo-blog-ddc.pages.dev/posts/agent-session-manage-architecture/Thu, 14 May 2026 00:00:00 +0000evilstarhttps://81adcf3e.hugo-blog-ddc.pages.dev/posts/agent-session-manage-architecture/最近这段时间，我在本地同时用 Claude Code 和 Codex 做开发的频率越来越高。 工具一多，一个很烦的问题就开始反复出现：session 太难找了。 有些对话在 Claude 里，有些在 Codex 里；有些项目我开了很多个 worktree；有时候我只记得一句提问、一个报错，或者记得那次对话大概发生在哪个分支上，但就是想不起来它到底在哪个 session 里。https://81adcf3e.hugo-blog-ddc.pages.dev/posts/claude-code-compact-mechanism/Mon, 11 May 2026 00:00:00 +0000evilstarhttps://81adcf3e.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 这份泄露源码的逆向阅读。产出就是这份文档——没有要改的代码。https://81adcf3e.hugo-blog-ddc.pages.dev/posts/claude-code-task-architecture/Mon, 11 May 2026 00:00:00 +0000evilstarhttps://81adcf3e.hugo-blog-ddc.pages.dev/posts/claude-code-task-architecture/1. 先说结论 这份源码里的 task 不是一个单一概念，而是两个相关但不同的子系统： 运行时后台任务系统 管理正在运行或已结束的后台 bash、agent、remote session 等 核心文件：Task.ts、tasks.ts、utils/task/framework.ts、AppStateStore.ts TodoV2 任务清单系统 管理“要做什么”的结构化任务列表 核心文件：utils/tasks.ts、useTasksV2.ts、TaskCreateTool、TaskUpdateTool、TaskListTool 这两个系统名字都叫 task，但职责完全不同：https://81adcf3e.hugo-blog-ddc.pages.dev/posts/claude-code-tools-architecture/Mon, 11 May 2026 00:00:00 +0000evilstarhttps://81adcf3e.hugo-blog-ddc.pages.dev/posts/claude-code-tools-architecture/1. 结论 Claude Code 的 tools 不是一个简单的函数注册表，而是一套统一的能力运行时协议。它把同一个 tool 同时投影到四个面： 模型侧：tool schema、prompt、strict、defer loading 执行侧：参数校验、调用、进度、结果、中断 权限侧：全局规则、工具特化规则、交互确认 UI 侧：tool use、progress、result、error、grouped render 核心抽象集中在：https://81adcf3e.hugo-blog-ddc.pages.dev/posts/claude-code-source-architecture/Mon, 11 May 2026 00:00:00 +0000evilstarhttps://81adcf3e.hugo-blog-ddc.pages.dev/posts/claude-code-source-architecture/基于 @anthropic-ai/claude-code v2.1.88 还原源码梳理。 1. 架构结论 Claude Code 不是一个“简单 CLI”，而是一个**单进程宿主（host）+ 会话引擎（conversation engine）+ 工具平台（tool platform）+ 多代理任务系统（multi-agent task runtime）**的 TypeScript/Bun 单体应用。