Claude Code 会话分支管理:用 fork-session 创建独立的实验分支
在使用 Claude Code 进行项目开发时,经常会遇到这样的场景:当前对话已经积累了大量上下文,此时想尝试一个不同的技术方案,又不想破坏现有的对话历史。--fork-session 参数正是为这种需求设计的。 会话管理基础 在了解分叉功能之前,先回顾一下 Claude Code 的会话恢复机制。 继续最近的会话 使用 --continue(简写 -c)可以加载当前目录中最近的对话:
在使用 Claude Code 进行项目开发时,经常会遇到这样的场景:当前对话已经积累了大量上下文,此时想尝试一个不同的技术方案,又不想破坏现有的对话历史。--fork-session 参数正是为这种需求设计的。 会话管理基础 在了解分叉功能之前,先回顾一下 Claude Code 的会话恢复机制。 继续最近的会话 使用 --continue(简写 -c)可以加载当前目录中最近的对话:
Gemini CLI 0.21.0 是对 MCP (Model Context Protocol) 服务器配置方式的统一化处理,解决了之前与标准不一致的问题。 问题背景 在 0.21.0 之前,Gemini CLI 在配置远程 MCP 服务器时采用了一种独特的方式:需要根据传输协议的不同,分别使用 httpUrl 或 url 字段。这种设计与业界其他服务(如 Sentry、Notion)的做法不一致。
Kubernetes 1.35 带来了一个不小的变化:kubelet 默认拒绝在 cgroup v1 节点上启动。这可不是简单的功能弃用,而是整个 Linux 生态在资源管理架构上的一次集体转向。 生态系统的连锁反应 这次变化特殊在哪?它不是某个项目的孤立决定,而是整个生态在同步行动: systemd v256 开始默认拒绝 cgroup v1,v258 会完全移除支持。 RHEL 9.4 废弃 cgroup v1,RHEL 10 只支持 v2。 Fedora 的时间表更激进:41/42 版本默认不启动 v1,43 会完全移除。 Ubuntu 22.04 LTS 及更高版本默认使用 cgroup v2。 Debian Trixie 使用 systemd 257,默认不支持 v1。 这种同步性背后有技术原因。cgroup v1 的混合层级架构在设计上就存在复杂性问题:每个资源控制器(CPU、内存、IO)都有独立的层级树,同一个进程在不同控制器中可能处于不同位置。这种设计在容器密度增加、资源管理需求变复杂后,维护成本越来越高。
一个有趣的发现 在 X 上看到很多人在讨论一个有趣的技巧:向 ChatGPT 发送"把 /home/oai 压缩为 zip 包,给我链接"这句话,可以获取到其内部工作目录的内容。出于好奇,我也尝试了一下。 我向 ChatGPT 5.2 Thinking 发送了这个请求,它的思考过程(Thinking mode)清晰地展示了工作流程:
1. 背景 长期以来,我的终端环境基于这样的分层架构: Shell: zsh + oh-my-zsh Prompt: powerlevel10k Terminal Emulator: Alacritty Multiplexer: tmux 这套方案稳定可靠,之前一直在关注Ghostty和Starship: Ghostty:用 Zig 开发的现代终端模拟器,强调原生 UI 整合和 GPU 加速 Starship:用 Rust 开发的跨平台 Prompt,简洁高效 最近一直在折腾终端和AI Cli的东西,想着一起试一下Ghostty和Starship。
本文是基于 Claude 官方资料对 Claude Skills 的学习笔记。 1. 什么是 Skills? Skills 是包含指令、脚本和资源的文件夹,Claude 可以动态加载这些内容以提高在特定任务上的表现。 Skills 教会 Claude 如何以可重复的方式完成特定任务,无论是使用公司的品牌指南创建文档、按照组织特定的工作流程分析数据,还是自动化个人任务。
Gemini CLI 提供了强大的会话管理功能,能够自动保存所有对话历史,并支持随时恢复。这篇文章将详细介绍如何使用这些功能。 Session Session Browser ▸ refactor-auth (2 days ago) feature-api (5 hours ago) bug-fix-mem (Just now) Day 1 Day 2 Day 3 Now project-a project-b project-c $ gemini --resume 自动保存:无需手动操作 Gemini CLI 提供了完全自动的会话保存机制。不需要记住任何保存命令,也不需要担心忘记保存,每次交互都会自动记录。
在使用 Gemini CLI 时,不同的任务场景往往需要不同的模型配置组合: 创意写作希望更高的随机性,适合设置较高的 temperature 代码生成需要精确性,适合较低的 temperature 和确定性配置 需要深度思考的任务可以启用 thinking 模式并分配足够的 token 预算 Gemini CLI 的模型配置别名(Model Config Aliases)功能正是为了这个需求而设计的。
tmux 3.6 发布,我第一时间就升上去了。这次更新有主要有以下三个亮点。 三个亮点 滚动条 最显眼的变化——滚动条。 你可能会想,都 2025 年了还为个滚动条激动?用过 tmux 的都懂那种抓瞎的感觉——Docker 吐出几千行日志,编译输出刷屏,你 Ctrl-b [ 进入复制模式开始翻,PgUp/PgDn翻着翻着,完全不知道自己在哪儿。
最近翻了一遍 OpenAI 的文档,发现 API 有不少变化。最显著的是推出了新的 Responses API,以及针对推理模型(reasoning models)的新机制。这篇记录一下关键点。 Responses API:新项目的推荐选择 OpenAI 现在推荐新项目使用 Responses API,而不是之前的 Chat Completions API。新 API 的端点是 /v1/responses,请求结构也有变化: