<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>EVILSTAR</title><link>https://087a3ecb.hugo-blog-ddc.pages.dev/</link><description>使用思源、Hugo、GitHub 和 Cloudflare Pages 部署的静态博客</description><generator>Hugo -- gohugo.io</generator><language>zh-cn</language><managingEditor>evilstar</managingEditor><webMaster>evilstar</webMaster><lastBuildDate>Wed, 20 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://087a3ecb.hugo-blog-ddc.pages.dev/index.xml" rel="self" type="application/rss+xml"/><item><title>Claude Code 记忆系统设计分析</title><link>https://087a3ecb.hugo-blog-ddc.pages.dev/posts/claude-code-memory-system-design/</link><pubDate>Wed, 20 May 2026 00:00:00 +0000</pubDate><author>evilstar</author><guid>https://087a3ecb.hugo-blog-ddc.pages.dev/posts/claude-code-memory-system-design/</guid><description>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 专属经验、团队共享知识拆成不同数据面，并用不同的注入方式控制上下文成本。</description></item><item><title>关于宗教，信仰，死亡的一些思考</title><link>https://087a3ecb.hugo-blog-ddc.pages.dev/post/some-thoughts-on-religion-faith-and-death-ytsg4.html</link><pubDate>Sat, 16 May 2026 14:01:46 +0800</pubDate><author>evilstar</author><guid>https://087a3ecb.hugo-blog-ddc.pages.dev/post/some-thoughts-on-religion-faith-and-death-ytsg4.html</guid><description>东方宗教和西方宗教对于死亡的看法很不一样，以佛教为例，认为人死后灵魂进行转世，根据生前的所做所为进行评判，如果生前行善积德，转世生到富贵人家；如果作恶多端，沦为畜生或者饿鬼，在十八层地狱下经受磨难。佛教来自印度教，轮回的概念也是一脉相承下来。对此我有一些疑问，评判的标准是什么，善恶的标准又是什么，如果一个人拥有很多钱财，热衷于慈善事业，拯救了很多濒临死亡的穷人；但同时为了获得财富，他杀掉了一些竞争者。他杀掉的人可能只有几个，但是拯救的人可能有几千个，几万个。那么这个人转世之后会成为人还是成为畜生呢？ 如果没有客观的标准，那么应该会有一个全知全能的神来判决，神如何判决呢，作为人应该不得而知，不可知的东西为什么会让这么多人深信不疑呢？ 无论怎样，死亡不是终点，死亡即是新生，轮回无休无止，只有拥有大功德的真佛才可以涅槃超脱。</description></item><item><title>为了找回散落的 session，我做了一个 Claude Code / Codex 会话管理器</title><link>https://087a3ecb.hugo-blog-ddc.pages.dev/posts/agent-session-manage-architecture/</link><pubDate>Thu, 14 May 2026 00:00:00 +0000</pubDate><author>evilstar</author><guid>https://087a3ecb.hugo-blog-ddc.pages.dev/posts/agent-session-manage-architecture/</guid><description>最近这段时间，我在本地同时用 Claude Code 和 Codex 做开发的频率越来越高。
工具一多，一个很烦的问题就开始反复出现：session 太难找了。
有些对话在 Claude 里，有些在 Codex 里；有些项目我开了很多个 worktree；有时候我只记得一句提问、一个报错，或者记得那次对话大概发生在哪个分支上，但就是想不起来它到底在哪个 session 里。</description></item><item><title>Claude Code `/compact` 机制分析</title><link>https://087a3ecb.hugo-blog-ddc.pages.dev/posts/claude-code-compact-mechanism/</link><pubDate>Mon, 11 May 2026 00:00:00 +0000</pubDate><author>evilstar</author><guid>https://087a3ecb.hugo-blog-ddc.pages.dev/posts/claude-code-compact-mechanism/</guid><description>Context（为什么需要这份分析） 用户想弄清楚 Claude Code 的 compact 功能在源码层面是如何实现的。这不是一个实现任务，而是一次对 /Users/jishihe/work/civil-engineering-cloud-claude-code-source-v2.1.88/01-claude-code-source-crack/claude-code-source 这份泄露源码的逆向阅读。产出就是这份文档——没有要改的代码。</description></item><item><title>Claude Code Task 架构分析</title><link>https://087a3ecb.hugo-blog-ddc.pages.dev/posts/claude-code-task-architecture/</link><pubDate>Mon, 11 May 2026 00:00:00 +0000</pubDate><author>evilstar</author><guid>https://087a3ecb.hugo-blog-ddc.pages.dev/posts/claude-code-task-architecture/</guid><description>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，但职责完全不同：</description></item><item><title>Claude Code Tools 设计分析</title><link>https://087a3ecb.hugo-blog-ddc.pages.dev/posts/claude-code-tools-architecture/</link><pubDate>Mon, 11 May 2026 00:00:00 +0000</pubDate><author>evilstar</author><guid>https://087a3ecb.hugo-blog-ddc.pages.dev/posts/claude-code-tools-architecture/</guid><description>1. 结论 Claude Code 的 tools 不是一个简单的函数注册表，而是一套统一的能力运行时协议。它把同一个 tool 同时投影到四个面：
模型侧：tool schema、prompt、strict、defer loading 执行侧：参数校验、调用、进度、结果、中断 权限侧：全局规则、工具特化规则、交互确认 UI 侧：tool use、progress、result、error、grouped render 核心抽象集中在：</description></item><item><title>Claude Code 源码架构文档</title><link>https://087a3ecb.hugo-blog-ddc.pages.dev/posts/claude-code-source-architecture/</link><pubDate>Mon, 11 May 2026 00:00:00 +0000</pubDate><author>evilstar</author><guid>https://087a3ecb.hugo-blog-ddc.pages.dev/posts/claude-code-source-architecture/</guid><description>基于 @anthropic-ai/claude-code v2.1.88 还原源码梳理。
1. 架构结论 Claude Code 不是一个“简单 CLI”，而是一个**单进程宿主（host）+ 会话引擎（conversation engine）+ 工具平台（tool platform）+ 多代理任务系统（multi-agent task runtime）**的 TypeScript/Bun 单体应用。</description></item><item><title>Claude Code 系统提示词设计整理</title><link>https://087a3ecb.hugo-blog-ddc.pages.dev/posts/2026-05-11-claude-code-system-prompt-design/</link><pubDate>Mon, 11 May 2026 00:00:00 +0000</pubDate><author>evilstar</author><guid>https://087a3ecb.hugo-blog-ddc.pages.dev/posts/2026-05-11-claude-code-system-prompt-design/</guid><description>目标 这份文档整理 Claude Code 在一次 query 中如何构造最终发给模型的 prompt，重点说明：
system prompt 由哪些模块组成 哪些内容其实不在 system，而是在 messages 里 CLAUDE.md、memory、git status、日期、MCP 指令分别从哪里进入 prompt cache 为什么要把 system prompt 切成静态和动态两段 本地日志默认能看到什么，不能看到什么 这里说的“最终 prompt”不是单一字符串，而是一次 API 请求中的两部分：</description></item><item><title>Claude Code 缓存设计架构文档</title><link>https://087a3ecb.hugo-blog-ddc.pages.dev/posts/claude-code-caching-architecture/</link><pubDate>Mon, 11 May 2026 00:00:00 +0000</pubDate><author>evilstar</author><guid>https://087a3ecb.hugo-blog-ddc.pages.dev/posts/claude-code-caching-architecture/</guid><description> 源码依据：/Users/jishihe/work/civil-engineering-cloud-claude-code-source-v2.1.88/01-claude-code-source-crack/claude-code-source/src 所有行号与路径都指向该目录。</description></item><item><title>Durable Run 作业化迁移方案</title><link>https://087a3ecb.hugo-blog-ddc.pages.dev/posts/durable-run-plan/</link><pubDate>Mon, 11 May 2026 00:00:00 +0000</pubDate><author>evilstar</author><guid>https://087a3ecb.hugo-blog-ddc.pages.dev/posts/durable-run-plan/</guid><description>Summary 把当前“HTTP 请求内跑 agent + SSE 仅负责附着输出”的模型，改成“后台 durable job 驱动执行，HTTP 只负责创建 run、附着流、暂停/恢复/注入消息”。
目标效果：</description></item></channel></rss>