2026-03-19 13:00:00
最近在东京认真找房子，每次拿到一个物件地址，我都要重复做同样一套操作：打开 [[Google Maps]] 搜地址，确认大概位置；找最近的车站，看步行距离；切到 Yahoo 地图查灾害风险图；再搜一圈附近有没有超市、医院、药局。做完一遍下来，十几分钟就过去了，物件多的时候，这些重复的信息收集工作比看房本身还累。某天做完第 N 遍之后，我决定干脆自己做一个工具，输入地址，全部自动搞定。这就是 BukkenAI 的起点。
日本的看房信息通常只有地址和最近车站，缺乏对”周边生活环境”的系统性描述，不同平台的信息分散，每次都要自己东拼西凑。交通方面要查最近的车站是哪个、步行几分钟、有几条线路可以换乘；生活便利方面要找附近的超市、便利店、药妆店；医疗方面要确认最近的医院、诊所、药局在哪里；还有小孩就学的学区划分、周边的绿地公园，以及这一带的灾害风险——洪水、滑坡、海啸——在日本这个自然灾害频发的国家，买房或租房都不能忽视这件事。每一条信息单独查都不难，但要每次都把这些全部查完，拿着手机在多个 App 之间反复横跳，是一件相当磨人的事情。
我是以”Vibe Coding”的方式来做这个项目的——不是从零开始设计架构，而是带着一个具体的痒点，边做边想，边想边改。用 [[Claude Code]] 作为主要的编程助手，迭代速度比我以往做 side project 快很多，很多时候是先把想法说给 AI，它出一版实现，我来 review 和调整，如此反复。技术栈上没有太多纠结：后端用 [[FastAPI]] 加 [[SQLAlchemy]] 异步 ORM 和 [[PostgreSQL]]（带 PostGIS 地理扩展），前端是 [[Next.js]] 搭配 [[React]] 和 [[TailwindCSS]]，数据来源是 [[Google Maps]] Places API 负责周边设施搜索，国土交通省的 REINFOLIB API 提供灾害风险和地价数据，最后用 [[Claude]] API 把收集到的数据汇总成一份可读性强的分析报告。
整个核心流程只需要输入一个日本地址，系统就会在几十秒内完成：用 Google Places API 搜索周边一千到一千五百米范围内的各类设施，查询国土交通省的灾害风险图数据，拉取同区域近三年的房价交易参考，最后把这些数据交给 AI 做综合分析，生成报告。
报告的核心是六个维度的评分，全部采用零到十分制，分别是教育、医疗、交通、自然环境、安全和生活便利。评分逻辑特意设计成”距离优先”——距离最近设施的远近是主要信号（零到七分），数量作为加成（零到三分）。这样可以避免”设施数量多但全都在两公里外”这种情况被高估，实际上距离最近的那家超市或者车站距离，才是真正影响日常生活感受的关键数字。安全维度则从满分起扣，高风险区域扣三分，中风险扣一点五分，低风险扣零点五分，直接反映灾害风险的轻重。
灾害风险分析是我个人觉得最实用的功能之一。日本的地震、洪水风险在各地区差异很大，但这类信息平时不太容易直观地查到，很多人买房的时候也容易忽视。BukkenAI 接入了国土交通省的 REINFOLIB API，可以查询洪水淹没、土砂灾害（滑坡）、海啸、高潮（台风引发的风暴潮）四类风险，每类风险标注高中低三个等级，并显示最近的指定避难场所位置。
找房过程中经常会收到物件的截图，地址就印在图片里，手动打字输入是一件小而烦的事。所以我加了一个图片上传功能：上传物件照片或截图，AI 自动 OCR 识别并提取地址，确认后直接进行分析。这个功能做完之后自己用起来确实方便，有时候对方发来的图片质量并不高，识别结果还需要手动确认一下，但大多数情况下准确率不错，省去了不少打字的工夫。
每份报告都有固定 URL，可以直接分享给家人或者一起看房的朋友，对方打开就能看到完整的分析内容，不需要注册账号。考虑到周边环境会随时间变化——新车站开通、新医院开业、新的楼盘落成——报告支持”重新生成”，使用最新数据生成新版本，同时保留旧版本可以对比查看，这样可以追踪一个区域的环境变化情况。
整个项目从第一行代码到上线，用了大概两三周的业余时间，功能比我最初预期的要丰富不少。Vibe Coding 的最大体验是：可以快速把一个”有点烦”的真实需求变成可用的东西，而不是被技术细节卡在起步阶段。当然代价是需要持续地和 AI 一起 review 生成的代码，尤其是涉及数据准确性、缓存策略、权限控制这些地方，不能完全放手，生成的代码质量参差不齐，还是要靠自己把关。如果你也在日本找房，或者对某个地址的周边环境感到好奇，欢迎去 BukkenAI.com 试试，输入一个地址看看报告长什么样——因为 Token 使用有成本，所以设定了限制，未登录用户有一次免费额度，注册之后有三次。
2026-03-18 13:00:00
最近在使用 [[Claude Code]] 做项目的时候，遇到了一个反复让我头疼的问题：每次开新会话，AI 对上一次为什么这样写代码、选择这个架构、为什么放弃了某个方案，完全没有记忆。代码变更留在 Git 历史里，但那些和 AI 的对话、推理过程、权衡讨论，全部随着会话关闭而消失了。
直到我发现了 [[Entire]] 这个工具，才意识到这个问题是可以从根本上被解决的。
我们已经习惯了用 Git 管理代码的每一次变化，git blame 可以告诉你某一行代码是谁在什么时间写的，git log 可以追溯整个演进历史。但这套体系有一个盲区：它只记录了代码”是什么”，完全无法告诉你代码”为什么这样”。
在 AI 辅助编程越来越普及的今天，这个盲区变得格外突出。当你和 Claude Code 或者 Gemini CLI 协作了几个小时，讨论了架构选型、踩了几个坑、最终选择了某个方案，这整个推理过程就是一座知识金矿。但第二天打开新会话，这些全都不见了。你要重新解释背景、重新踩坑、重新权衡，AI 也不得不从零开始理解项目上下文，大量 token 就这样被浪费掉了。
Entire 的切入点就在这里——它把 AI 会话的完整上下文，以 Git 原生的方式版本化保存下来。
Entire 是一个与 [[Git]] 深度集成的开发者工具，通过 Git 钩子（hooks）在你正常提交代码的同时，自动捕获 AI 编程助手的完整会话数据，并以”检查点”（Checkpoints）的形式存储，与代码提交形成关联。
这里有一个设计上很聪明的地方：捕获的检查点不会作为额外的提交出现在你的分支历史里，也就是说，你的 git log 保持干净整洁，AI 会话数据以 Git 的底层对象形式独立存储，只在需要的时候才会浮现出来。
每个检查点里包含的内容相当丰富：与 AI 助手的完整对话记录、使用的 prompt、本次会话中 AI 涉及的文件列表、token 使用量统计，以及所有工具调用的详细记录。这些信息与具体的 git commit 绑定，形成一条完整的”代码 + 推理”双轨历史。
目前 Entire 已经支持几款主流的 AI 编程助手：
从支持列表来看，它瞄准的正是当下最活跃的那批 AI 编程工具用户。
Entire 的功能设计围绕着一个核心理念展开：让 AI 会话成为 Git 历史的一等公民。
在存储层面，它采用的是 Git 原生存储方案，会话数据随着 git push 一起同步到远程，不需要额外的云服务或中间层。整个体系是本地优先的，数据完全在开发者自己的环境里运行，没有第三方云端依赖，隐私方面更有保障。
时间回溯是另一个让我觉得特别有用的功能。想象一下，两周前 AI 帮你分析了某个接口的设计方案，当时觉得没问题就过了，现在发现有 bug。你可以直接回到那个检查点，重新加载当时完整的 AI 会话，把整个推理过程重新过一遍，找到是哪个假设出了问题。这种能力在传统开发工作流里是完全缺失的。
可搜索历史则让整个知识库变得可以查询。你可以跨代码库搜索之前和 AI 的对话内容，比如搜索”为什么选 Redis 而不是 Memcached”，或者”OAuth 那次集成遇到了什么坑”，这些过去的讨论都变成了可检索的团队知识资产。
Entire 采用 MIT 许可证开源，代码完全透明，这对于需要处理敏感代码库的团队来说是一个重要的信任基础。
安装 Entire 有几种方式，macOS 用户可以直接用 [[Homebrew]] 安装，Linux 用户可以用官方脚本，或者也可以从源码编译。
安装完成后，在项目仓库里运行一条命令就可以启用：
entire enable
这条命令会在当前 Git 仓库里安装对应的钩子，之后就完全是透明的了。你照常使用 Claude Code 或其他 AI 助手写代码、照常 git commit、照常 git push，Entire 在后台默默完成检查点的捕获和同步，不改变任何现有的工作流习惯。
这种”零侵入”的设计选择我觉得是很明智的。对于开发者来说，任何需要改变已有工作流的工具都会面临很高的采纳阻力，而 Entire 选择完全融入 Git 的自然节奏，阻力降到了最低。
个人使用 Entire 当然有价值，但我觉得它真正有趣的场景在于多人团队的 AI 辅助开发。
当团队里每个人都在用 AI 助手写代码，每个人的 AI 会话都可以被捕获并推送到共享仓库时，就形成了一个集体的 AI 协作知识库。新成员接手模块时，不仅能看到代码历史，还能看到前任开发者当初是如何和 AI 讨论、权衡、决策的，上手成本会大幅降低。
更重要的是，这可以有效减少重复推理的浪费。AI 辅助开发中一个常被忽视的成本是：同一个问题，不同的开发者、不同的会话，可能在和 AI 重复讨论相同的背景信息。Entire 把这些讨论固化下来，团队可以直接复用已有的推理结果，而不必每次都从头开始让 AI 理解上下文。
Entire 解决的是一个在 AI 编程助手广泛普及之后才开始变得迫切的问题：如何保留 AI 与开发者协作产生的知识，而不仅仅是保留最终的代码输出。
Git 已经成为代码领域最成功的版本控制基础设施之一，Entire 选择在这个基础上构建，而不是另起炉灶搭建新的数据平台，这个决策我觉得是正确的。对开发者来说，接受一个融入已有工作流的工具，远比接受一个全新系统容易得多。
目前 Entire 还处于相对早期的阶段，支持的 AI 助手数量有限，功能上也还在发展中。但它提出的核心问题和解法方向，我认为是对的。随着 AI 编程助手的渗透率越来越高，”AI 会话版本化管理”这个需求只会越来越强烈，Entire 值得持续关注。
2026-03-18 13:00:00
在用了十几年命令行之后，我越来越觉得 Shell 历史是个被严重低估的功能。每次换机器、重装系统，那些积累了多年的命令历史就这么消失了。更让人抓狂的是，明明记得自己用过某个复杂的 ffmpeg 转码命令，或者某个 kubectl 调试命令，但就是死活想不起来完整参数。
直到发现了 [[Atuin]]，这个问题才算真正解决。
[[Atuin]] 是一个开源的 Shell 历史增强工具，GitHub 上已经获得了接近三万颗星。它最核心的思路是：把传统的纯文本 ~/.bash_history 替换成一个 SQLite 数据库，在存储命令的同时，记录下更多有价值的上下文信息。
原来的 Shell 历史只记录”你输入了什么”，而 Atuin 还会记录”你在哪个目录输入的”、”命令运行了多久”、”命令是否成功退出”、”是在哪台机器上输入的”。这些信息听起来不起眼，但当你真正需要找回某条命令时，这些上下文就是救命稻草——特别是你记得”这个命令我是在项目目录下运行的，而且大概跑了一分多钟”，就能快速缩小搜索范围。
更重要的是，Atuin 支持将历史加密同步到多台设备，所有数据在本地加密后才上传，即使使用官方提供的免费同步服务器，服务端也无法看到你的命令内容。如果不放心，也可以自己搭建服务器。
Atuin 的功能设计相当克制，没有塞入太多花哨的东西，但每一个功能都切中要害。
搜索界面是最直接的改变。按下 Ctrl+R 或者上箭头，会弹出一个全屏的搜索界面，支持模糊搜索，可以按工作目录、主机名、会话等维度过滤。找到目标命令后，按 Enter 直接执行，或者按 Tab 只填入命令行不执行。
统计功能可以告诉你哪些命令用得最多，类似 atuin stats 可以生成一份使用分析报告。如果你是那种喜欢研究自己工作习惯的人，这个功能会让你花很多时间盯着屏幕看。
跨设备同步是 Atuin 最吸引人的功能之一。工作电脑、家用 Mac、远程服务器，所有历史都可以同步汇聚在一起。在家里的机器上能直接搜到上午在公司服务器上运行过的命令，这种体验真的很爽。
多 Shell 支持方面，Atuin 覆盖了主流 Shell，包括 Zsh、Bash、Fish、Nushell、Xonsh 和 PowerShell。不管你用哪个 Shell，都能无缝接入。
安装 Atuin 非常简单，官方提供了一键安装脚本：
curl --proto '=https' --tlsv1.2 -LsSf https://setup.atuin.sh | sh
如果不想直接跑脚本，也可以通过各种包管理器安装：
# macOS
brew install atuin
# Arch Linux
pacman -S atuin
# Cargo（Rust 工具链）
cargo install atuin
安装完二进制文件之后，需要给自己的 Shell 添加初始化配置。
Zsh 用户把这行加入 ~/.zshrc：
eval "$(atuin init zsh)"
Bash 用户需要先安装 bash-preexec，然后：
eval "$(atuin init bash)"
Fish 用户在 ~/.config/fish/config.fish 中添加：
atuin init fish | source
配置完成后，执行 atuin import auto 导入现有的 Shell 历史，这样历史不会断档。
如果想使用云同步功能，需要注册一个账号。可以使用官方服务器，免费的：
atuin register -u your_username -e [email protected]
注册后，登录并同步：
atuin login -u your_username
atuin sync
如果嫌每次手动同步麻烦，可以设置自动同步。在配置文件 ~/.config/atuin/config.toml 中添加：
[sync]
records = true
[daemon]
enabled = true
sync_frequency = 300
这样 Atuin 会在后台每五分钟自动同步一次。
掌握了几个快捷键，Atuin 的使用效率会大幅提升。
在搜索界面中，Ctrl+D 可以切换搜索范围，在”全局历史”和”当前目录历史”之间切换。很多时候你需要找的命令就是在特定项目目录下运行的，切换到目录过滤模式可以大幅减少干扰。
按 Alt+数字 可以快速跳转到搜索结果的第几项，适合在少数几个候选命令间快速切换。
atuin search 命令也可以在命令行直接使用，支持通过 --cwd 参数按目录过滤，--exit 参数按退出状态过滤（比如只看成功执行的命令）：
# 只搜索在当前目录运行过的命令
atuin search --cwd .
# 只搜索失败的命令（用来复盘报错）
atuin search --exit 1
# 搜索特定关键词
atuin search kubectl
统计命令可以帮你了解自己的命令行使用习惯：
atuin stats
对数据隐私有更高要求的话，可以自己搭建 Atuin 服务器。官方提供了完整的自托管方案，支持 Docker 和 [[Kubernetes]] 部署。
使用 Docker Compose 是最简单的方式：
services:
atuin:
image: ghcr.io/atuinsh/atuin:latest
command: server start
ports:
- "8888:8888"
environment:
ATUIN_HOST: "0.0.0.0"
ATUIN_OPEN_REGISTRATION: "true"
ATUIN_DB_URI: "postgres://atuin:password@postgres:5432/atuin"
depends_on:
- postgres
postgres:
image: postgres:16-alpine
environment:
POSTGRES_USER: atuin
POSTGRES_PASSWORD: password
POSTGRES_DB: atuin
volumes:
- postgres_data:/var/lib/postgresql/data
volumes:
postgres_data:
搭好服务器之后，在客户端配置文件中指定自定义服务器地址：
sync_address = "https://atuin.your-domain.com"
然后重新注册或者登录，之后的同步都走自己的服务器。
用 Atuin 替换默认 Shell 历史之后，我最大的感受是”数据终于有了价值”。以前的命令历史像是一堆散乱的纸片，而现在变成了一个可以检索、有上下文的知识库。
尤其是跨设备同步这个功能，对于同时使用多台机器工作的人来说，价值不可估量。不再需要在不同机器间手动同步 ~/.bash_history，也不用担心某台机器的历史突然消失。
工具好不好，往往要用过才知道。Atuin 属于那种”用了就不想回头”的类型，如果你还没有试过，可以花几分钟装上体验一下，说不定会改变你对命令行历史的看法。
2026-03-17 13:00:00
从 Warp 切换到了 [[Ghostty]]，理由非常简单，我使用 atuin 来同步 Shell 历史，但是 Warp 不支持，外加上 Ghostty 自带 Metal GPU 加速渲染、原生 macOS AppKit 构建、启动飞快，可以让 AI 以纯文本方式配置，就果断切换了。
让 Claude Code 给了一些初始化设置之后一直用到现在，积累了一些配置心得，整理成文。
Ghostty 是 HashiCorp 联合创始人 Mitchell Hashimoto 开发的开源终端模拟器。用 Zig 语言编写，macOS 上走 Metal 渲染，Linux 上走 GTK4。它的设计哲学是”零配置即可用”——默认内置 JetBrains Mono 字体和 Nerd Font 支持，开箱就能正常显示各种图标。
和 iTerm2 比，Ghostty 更轻更快；和 Warp 比，Ghostty 不会和 tmux 冲突；和 Alacritty 比，Ghostty 有原生的标签页和分屏支持。
配置文件位于 ~/.config/ghostty/config，纯键值对格式，没有复杂语法。可以使用软链接的方式放到 dotfiles 中保存。
Ghostty 内置了 300+ 主题，可以用命令查看：
ghostty +list-themes
几个最流行的暗色主题：
| 主题 | 背景色 | 风格 |
|---|---|---|
| Catppuccin Mocha | #1e1e2e |
柔和温暖，社区生态最完整 |
| Gruvbox Dark Hard | #1d2021 |
复古暖色调，接近纯黑 |
| Tokyo Night Night | #1a1b26 |
冷色调蓝紫系，Neovim 社区标配 |
| Dracula+ | #212121 |
经典高对比，色彩鲜艳 |
| Kanagawa Wave | #1f1f28 |
日式水墨画美学 |
直接在 config 里引用内置主题名即可，支持 dark/light 自动切换：
theme = dark:Gruvbox Dark Hard,light:Gruvbox Light Hard
用内置主题的好处是 Cmd+Shift+, 热重载一定能生效。如果用自定义主题文件，改完可能需要完全重启 Ghostty。
如果你在终端里跑 TUI 应用（比如 [[Claude Code]]），可能会遇到某些文字颜色和背景色对比度不足、看不清的问题。Ghostty 提供了一个 minimum-contrast 配置项，会自动调整前景色以确保最低对比度：
minimum-contrast = 1.3
值越大强制对比度越高，但也可能让部分颜色偏离主题原色。1.3 是一个比较平衡的值。
以下是我实际在用的配置，逐项解释。
font-family = MesloLGS Nerd Font Mono
font-size = 13
font-thicken = true
font-thicken 在 Retina 屏幕上让字体稍微加粗，提升可读性。如果觉得默认字体间距太紧，可以加一个 adjust-cell-height：
adjust-cell-height = 5%
默认值是 0，即不做任何调整。25% 会明显偏大，5%~10% 是比较舒适的范围。
window-colorspace = display-p3
window-padding-x = 1
window-padding-y = 1
window-padding-color = extend
window-padding-balance = true
window-step-resize = false
window-save-state = always
macos-titlebar-style = transparent
background-opacity = 0.98
几个值得注意的配置：
window-colorspace = display-p3：macOS 上启用 Display P3 广色域渲染，颜色更丰富准确。这是很多人会忽略的设置。window-padding-balance = true：让终端内容在窗口中自动居中对齐，视觉上更舒适。window-save-state = always：关闭再打开 Ghostty 时恢复之前的窗口位置、标签页和分屏状态。这个设置非常重要——默认值 default 在 macOS 自动更新重启后可能丢失所有 session。background-opacity = 0.98：轻微透明，能隐约看到下方窗口但不影响阅读。如果想要更明显的毛玻璃效果，可以降到 0.85 并配合 background-blur-radius = 20。cursor-style = block
cursor-style-blink = false
adjust-cursor-thickness = 2
mouse-hide-while-typing = true
mouse-scroll-multiplier = 2
link-url = true
mouse-scroll-multiplier = 2：默认滚动速度偏慢，翻倍后浏览长输出更高效。link-url = true：终端里的 URL 可以 Cmd+点击 直接在浏览器打开。clipboard-paste-protection = true
clipboard-trim-trailing-spaces = true
copy-on-select = true
macos-auto-secure-input = true
confirm-close-surface = false
auto-update = check
scrollback-limit = 10000
clipboard-paste-protection = true：粘贴内容包含换行符时弹出确认，防止误执行命令。这是一个安全功能，建议保持开启。Ghostty 1.3 还修复了一个粘贴注入的安全漏洞（CVE-2026-26982）。confirm-close-surface = false：关闭标签页或分屏时不弹确认框，减少打断。auto-update = check：只检查更新但不自动安装重启，避免意外中断工作。scrollback-limit = 10000：控制回滚缓冲区为 1 万行。默认值很大，如果不限制可能在长时间运行后消耗大量内存。shell-integration-features = no-cursor,sudo,title
Ghostty 的 Shell Integration 是一个被低估的功能。启用后可以：
Cmd+Up / Cmd+Down：在终端输出中按命令提示符跳转，快速定位到每条命令的位置sudo：输入 sudo 时自动提示title：标签页标题显示当前运行的命令no-cursor 是因为我自己在 config 里定义了光标样式，不需要 Shell Integration 再覆盖。
Ghostty 支持自定义 Dock 图标样式，可以让它和你的主题配色统一：
macos-icon = custom-style
macos-icon-frame = plastic
macos-icon-ghost-color = #ebdbb2
macos-icon-screen-color = #1d2021
这里的颜色用了 Gruvbox 的前景色和背景色，让图标融入整体视觉。
Ghostty 的默认快捷键已经很合理，但有几个值得自定义的：
macos-option-as-alt = true
keybind = cmd+right=text:\x05
keybind = cmd+left=text:\x01
keybind = cmd+backspace=text:\x15
macos-option-as-alt = true：让 Option 键作为 Alt 使用，这对 tmux 和 Vim 用户来说是必需的。Cmd+Left/Right：映射到行首/行尾（Ctrl+A / Ctrl+E），符合 macOS 的编辑习惯。Cmd+Backspace：删除整行（Ctrl+U）。如果不用 tmux，Ghostty 原生就支持分屏：
| 快捷键 | 功能 |
|---|---|
Cmd+D |
垂直分屏 |
Cmd+Shift+D |
水平分屏 |
Cmd+[ / Cmd+]
|
切换分屏焦点 |
Cmd+Shift+Enter |
当前分屏最大化/还原 |
Cmd+Shift+, 是 Ghostty 的默认热重载快捷键，不需要额外绑定。修改 config 文件后直接按这个组合键就能生效。但注意：如果修改的是自定义主题文件（而非内置主题），可能需要完全重启才能生效。
Ghostty 内置了 Quake 风格的下拉终端，用一个全局快捷键可以在任何应用中呼出/收起：
keybind = global:f12=toggle_quick_terminal
这个功能和 iTerm2 的 Visor 模式类似，不需要依赖 Hammerspoon 或其他工具。Quick Terminal 是一个独立于主窗口的轻量终端，适合快速执行一两条命令。
不过如果你已经用 Hammerspoon 做了类似的快捷键绑定（比如 F12 切换 Ghostty 窗口），两者会冲突，需要二选一。
但是你如果依赖 Ghostty 的 Tab，那么还是建议使用 Hammerspoon 来配置。
Ghostty 利用 GPU 渲染的优势，支持自定义 GLSL 片段着色器作为终端背景。可以实现 CRT 复古效果、动态渐变、光晕等视觉效果：
custom-shader = ~/.config/ghostty/shaders/bloom.glsl
custom-shader-animation = true
多个 shader 可以叠加使用：
custom-shader = ~/.config/ghostty/shaders/tft.glsl
custom-shader = ~/.config/ghostty/shaders/bettercrt.glsl
custom-shader = ~/.config/ghostty/shaders/bloom.glsl
社区有不少现成的 shader 集合，比如 ghostty-watercolors 提供了水彩画风格的背景。
Ghostty 支持 Kitty 图片协议，可以在终端内直接显示图片。配合 imgcat 或 Kitty 的 icat 工具，可以在 SSH 远程服务器上生成图表后直接在终端里预览，不需要再 scp 到本地打开。
按 Cmd+Shift+I 可以打开 Ghostty 的内置 Inspector，能查看每个 cell 的属性、颜色值、字体渲染信息。排查显示问题时非常有用——比如某个字符颜色不对，可以用 Inspector 精确查看它用了哪个 palette 颜色。
如果你还在用旧版本，强烈建议升级到 1.3。这个版本包含了 6 个月的开发工作，180 位贡献者的 2800+ 次提交，几个亮点功能：
Cmd+F 搜索终端历史输出，用独立线程实现，不影响终端 I/O 性能scrollbar 配置项升级方式：
brew upgrade --cask ghostty
# vim: ft=ghostty
# Font
font-family = MesloLGS Nerd Font Mono
font-size = 13
font-thicken = true
window-inherit-font-size = true
# Look and Feel
theme = dark:Gruvbox Dark Hard,light:Gruvbox Light Hard
window-colorspace = display-p3
window-padding-x = 1
window-padding-y = 1
window-padding-color = extend
window-padding-balance = true
window-step-resize = false
macos-icon = custom-style
macos-icon-frame = plastic
macos-icon-ghost-color = #ebdbb2
macos-icon-screen-color = #1d2021
adjust-cursor-thickness = 2
cursor-style = block
cursor-style-blink = false
minimum-contrast = 1.3
link-url = true
macos-titlebar-style = transparent
mouse-hide-while-typing = true
mouse-scroll-multiplier = 2
window-save-state = always
background-opacity = 0.98
# Behavior
clipboard-paste-protection = true
clipboard-trim-trailing-spaces = true
copy-on-select = true
macos-auto-secure-input = true
macos-secure-input-indication = true
confirm-close-surface = false
quit-after-last-window-closed = false
auto-update = check
scrollback-limit = 10000
shell-integration-features = no-cursor,sudo,title
# Key bindings
macos-option-as-alt = true
keybind = cmd+right=text:\x05
keybind = cmd+left=text:\x01
keybind = cmd+backspace=text:\x15
Ghostty 的设计哲学是”默认即合理”，大多数情况下不需要太多配置就能用得很舒服。上面这些配置是我在实际使用中逐步调整出来的，核心思路是：用内置主题、启用 P3 广色域、控制内存占用、减少不必要的确认弹窗。
如果你从 iTerm2 迁移过来，最大的区别可能是配置方式——从 GUI 菜单变成了纯文本文件。但习惯之后会发现这种方式更适合版本控制和跨设备同步，把 config 文件放到 dotfiles 仓库里就行了。
2026-03-16 13:00:00
用 AI 写代码这件事，大家都已经习惯了。但一个尴尬的现实是：AI 在修改代码的时候，经常不知道自己改的那个函数被多少地方调用、改完之后会不会连锁反应把别的功能搞崩。这不是 AI 模型不够聪明，而是它看不到代码库的全貌——依赖关系、调用链路、执行流程，这些结构性的信息在普通的文件搜索里是丢失的。
[[GitNexus]] 就是为了解决这个问题而生的。它把你的代码仓库索引成一张知识图谱，然后通过 [[MCP]]（Model Context Protocol）把这些结构化的上下文喂给 AI Agent，让 AI 在动手之前就能看清楚”改这个函数会影响到哪些地方”。
GitNexus 是一个开源的零服务器代码智能引擎，由 abhigyanpatwari 开发。它有两种使用模式：
核心技术栈是 [[Tree-sitter]]（语法解析）+ LadybugDB（图数据库）+ MCP 协议。CLI 模式下使用 Tree-sitter 原生绑定，Web 模式下编译为 WebAssembly 在浏览器里运行。不管哪种模式，所有数据都留在本地，不会上传到任何外部服务器。
项目在 2025 年 8 月创建，最初并没有引起太大关注。到了 2026 年 2 月底，随着 AI 编程工具的普及，开发者们对”AI 改代码改出 bug”这件事的痛感越来越强，GitNexus 在短短几周内就积累了超过 16,000 个 GitHub Star。
传统的 AI 编程工具在处理代码时，本质上做的是文本检索——grep 搜索、文件读取、语义搜索。这些方法能找到代码在哪里，但找不到代码之间的关系。
举个实际的例子。在我们的项目里，假设你要修改一个 AccountService 里的 read 方法。用普通搜索你能找到这个方法的定义和一些调用点，但你很难一次性看清楚：
这些关系在代码库里是隐含的，需要一个人花很长时间去追踪才能理清。而知识图谱把这些关系预先计算好了，AI Agent 只需要一次查询就能拿到完整的上下文。
GitNexus 官方用了一个很形象的说法：传统 RAG 是把原始代码片段扔给 AI，让它自己去发现关系；GitNexus 是把预先计算好的关系直接给 AI，一次调用就能拿到完整上下文。
需要 [[Node.js]] 运行环境。
全局安装：
npm install -g gitnexus
进入项目目录，运行一行命令即可完成索引：
npx gitnexus analyze
这个命令会：
.gitnexus/ 目录下的 LadybugDB 数据库中.claude/skills/gitnexus/ 安装 Agent 技能文件CLAUDE.md 中追加 GitNexus 使用指南以我们大约 1500 个文件的 Java 项目为例，索引过程大约花了 29 秒，生成了 12,847 个节点、50,347 条边、1,258 个功能集群和 300 个执行流程。
常用的索引选项：
gitnexus analyze --force # 强制完整重建索引
gitnexus analyze --embeddings # 启用 embedding 生成（更好的语义搜索，但更慢）
gitnexus analyze --skip-embeddings # 跳过 embedding（更快）
gitnexus analyze --verbose # 显示跳过的文件
gitnexus analyze --skills # 生成仓库特定的技能文件
这是让 AI 编程工具能调用 GitNexus 的关键步骤。
Claude Code（最深度的集成）：
claude mcp add gitnexus -- npx -y gitnexus@latest mcp
Cursor（~/.cursor/mcp.json）：
{
"mcpServers": {
"gitnexus": {
"command": "npx",
"args": ["-y", "gitnexus@latest", "mcp"]
}
}
}
Windsurf / OpenCode / Codex 也都支持，配置方式类似，具体可参考官方文档。
一键自动配置所有已安装的编辑器：
npx gitnexus setup
配置好 MCP 之后，AI Agent 可以调用以下工具：
| 工具 | 用途 | 示例 |
|---|---|---|
query |
按概念搜索代码 | gitnexus_query({query: "auth validation"}) |
context |
查看某个符号的 360 度全景 | gitnexus_context({name: "AccountService"}) |
impact |
修改前的爆炸半径分析 | gitnexus_impact({target: "read", direction: "upstream"}) |
detect_changes |
提交前的变更范围检查 | gitnexus_detect_changes({scope: "staged"}) |
rename |
基于图谱的安全重命名 | gitnexus_rename({symbol_name: "old", new_name: "new", dry_run: true}) |
cypher |
原始图查询 | gitnexus_cypher({query: "MATCH ..."}) |
list_repos |
列出所有已索引的仓库 | — |
这是我觉得最有价值的功能。在修改任何函数之前，先跑一次 impact 分析，它会告诉你：
风险等级分为 LOW、MEDIUM、HIGH、CRITICAL，AI Agent 在收到 HIGH 或 CRITICAL 警告时会主动提醒你。
在准备提交代码之前，detect_changes 会基于 git diff 分析你的变更影响了哪些符号和执行流程。这相当于一个智能的 pre-commit 检查——不是检查代码风格，而是检查你的变更是否只影响了预期的范围。
GitNexus 会自动识别代码库中的功能集群（高内聚的代码模块）和执行流程（从入口点到输出的完整路径）。这对于理解不熟悉的代码库特别有帮助。你可以通过 MCP Resource 访问：
gitnexus://repo/<repo-name>/clusters # 所有功能集群
gitnexus://repo/<repo-name>/processes # 所有执行流程
gitnexus://repo/<repo-name>/process/<name> # 某个执行流程的详细步骤
GitNexus 使用一个全局注册表（~/.gitnexus/registry.json）来管理多个仓库的索引。一个 MCP 服务器可以同时服务多个已索引的仓库，LadybugDB 连接会按需懒加载（最多 5 个并发连接，5 分钟无活动后自动回收）。
GitNexus 支持 13 种编程语言：TypeScript、JavaScript、Python、Java、Kotlin、C#、Go、Rust、PHP、Ruby、Swift、C 和 C++。
支持的特性包括：导入解析、命名绑定追踪、导出检测、类继承映射、类型注解提取、构造函数推断、配置文件解析、框架检测和入口点评分。
1. gitnexus_impact({target: "要修改的函数名", direction: "upstream"})
2. 查看爆炸半径和风险等级
3. 如果风险是 HIGH 或 CRITICAL，评估是否需要更谨慎的方案
1. gitnexus_query({query: "你想了解的功能描述"})
2. 找到相关的执行流程
3. gitnexus_context({name: "感兴趣的函数名"}) 查看完整上下文
1. gitnexus_context({name: "目标函数"}) 查看所有引用
2. gitnexus_impact({target: "目标函数", direction: "upstream"}) 查看爆炸半径
3. 如果是重命名，用 gitnexus_rename 的 dry_run 模式先预览
1. gitnexus_detect_changes({scope: "staged"})
2. 确认变更只影响了预期的范围
代码变更提交后，索引会变得过时。重新索引：
npx gitnexus analyze
如果之前启用了 embedding，加上 --embeddings 参数以保留它们。Claude Code 用户会有一个 PostToolUse hook 在 git commit 后自动重新索引。
gitnexus status # 查看当前仓库的索引状态
gitnexus list # 列出所有已索引的仓库
gitnexus clean # 删除当前仓库的索引
gitnexus serve # 启动本地 HTTP 服务器，用于 Web UI 浏览
gitnexus wiki # 从知识图谱生成 Wiki 文档
如果你更喜欢可视化的方式来浏览代码知识图谱，可以直接访问 gitnexus.vercel.app 在浏览器里使用。支持拖入 GitHub 仓库链接或 ZIP 文件，无需安装任何东西。
也可以在本地启动：
gitnexus serve
然后打开浏览器，Web UI 会自动检测本地服务器并展示所有已索引的仓库。
这一点值得单独强调：
.gitnexus/ 文件夹中（已被 gitignore）对于有严格数据合规要求的企业来说，这种完全本地化的架构是一个很大的优势。
AI 编程工具的瓶颈正在从”代码生成”转向”代码理解”。生成一段代码很容易，但理解这段代码在整个系统中的位置、修改它会产生什么连锁反应，这才是真正困难的部分。GitNexus 通过把代码库预先索引为知识图谱，让 AI Agent 在修改代码之前就能看到完整的依赖关系和调用链路，从根本上减少了”AI 改代码改出 bug”的概率。
安装只需要 npm install -g gitnexus，索引一个中等规模的项目不到 30 秒，配置 MCP 也只是一行命令的事情。如果你正在用 Claude Code 或 Cursor 做日常开发，值得花几分钟试一下。
2026-03-15 13:00:00
自从安装使用 OpenClaw 之后，我一直没有找到一个好办法直接在 OpenClaw 里追踪 Token 的消耗情况。虽然我日常主要用的是月订阅套餐，但偶尔为了测试一些新模型或者跑特定任务，还是会走 API 调用。这部分花费是按量计费的，用多少扣多少，如果不注意很容易超额。之前也试过在 Anthropic 控制台手动查 Usage，但那个粒度太粗了，根本看不出来钱到底花在了哪些项目、哪些模型上。直到最近发现了 [[Clawalytics]] 这个项目，通过它的可视化仪表盘查看 Token 消耗的详细数据，才终于有了一种”心里有底”的感觉。
Clawalytics 是一个开源的 OpenClaw Token 消耗统计和可视化工具。简单来说，它会读取 OpenClaw 本地产生的 JSONL 会话日志文件，解析其中的 Token 用量数据，然后计算出每一次请求、每一个会话、每一天的实际花费，最终以一个漂亮的 Web 仪表盘呈现出来。对于像我这样既有月订阅又偶尔走 API 调用的用户来说，它能帮你清晰地看到 API 部分到底花了多少，从而避免不知不觉超额使用。
跟那些需要你把 API Key 交给第三方服务的方案不同，Clawalytics 完全在本地运行，数据存储在本地的 [[SQLite]] 数据库里，不会把你的任何信息上传到外部服务器。这一点对于在意隐私的开发者来说非常重要。
技术栈上，前端用的是 [[React]] 19 + [[TanStack Router]] + [[shadcn/ui]]，后端是 [[Express.js]] + better-sqlite3，用 [[Vite]] 构建，整体非常现代。图表部分用了 Recharts，动画用了 Framer Motion，状态管理选择了 Zustand，基本上是当下 React 生态里最主流的技术组合。
如果你经常使用 Claude Code 或者 OpenClaw，一定对”Token 消耗失控”这件事不陌生。社区里有人反馈过一个月 API 账单达到 3600 美元的情况，也有人因为一个心跳循环在夜间跑了一整晚，醒来发现多了 200 美元的账单。这些听起来像段子，但确实在发生。
问题的根源在于，每一次请求都会重新注入完整的工具列表、技能元数据和工作区文件，再加上完整的对话历史。这意味着你的第 20 轮对话的输入 Token 量是第一轮的 20 倍。不同模型的价格差异也非常大——在 Opus 上跑的任务如果切到 Haiku，成本可以降低到二十五分之一。
但如果你不做追踪，这些信息全都是模糊的。你可能只知道”这个月花了不少”，但根本说不出来钱花在了哪里、哪些模型最烧钱、缓存到底省了多少。Clawalytics 就是来解决这个问题的。
打开 Clawalytics 的主页面，你能看到一个非常直观的成本概览。它按照今天、本周、本月和全部时间四个维度展示总花费，同时给出 Token 的详细拆分——输入 Token、输出 Token、缓存创建和缓存读取分别用了多少。最有价值的是缓存节省计算器，它会告诉你因为使用了 Prompt Caching 而省下了多少钱。
仪表盘上还有一个 30 天的每日花费趋势图和模型使用分布饼图，让你一眼就能看出最近的消费趋势和各个模型的占比情况。
每一次编码会话都会被记录下来，包括项目路径、开始和结束时间、使用的模型、消耗的 Token 数量和对应的成本。你可以展开任意一个会话查看详细信息，也可以按项目分组来看不同项目的花费对比。对于同时维护多个项目的开发者来说，这个功能特别实用——终于能清楚地知道哪个项目是”吞金兽”了。
Clawalytics 支持几乎所有主流的 AI 提供商和模型，包括 Anthropic 的 Claude 全系列、OpenAI 的 GPT 系列、Google 的 Gemini 系列、DeepSeek、Moonshot/Kimi 等等。每个模型的花费、Token 消耗、使用趋势都有独立的图表展示。你可以在模型对比页面上一目了然地看出，比如 Claude Opus 4 的输入价格是每百万 Token 15 美元，而 Claude Haiku 只要 0.25 美元——差了 60 倍。这种直观的对比能帮你更理性地选择模型。
这可能是对钱包最友好的功能了。你可以分别设置每日、每周和每月的预算上限，当花费接近或超过阈值时，Clawalytics 会自动发出告警。在 CLI 界面上，预算进度会以进度条的形式展示，非常直观。虽然它本身不能阻止你继续花钱（那是 API 提供商的事），但至少能让你在失控之前收到提醒。
如果你使用 OpenClaw 的多 Agent 功能，Clawalytics 还能追踪每个 Agent 的独立花费，并按 Agent 维度做成本拆分。类似地，如果你的 OpenClaw 接入了 WhatsApp、Telegram、Slack 等消息渠道，也能看到每个渠道的消息量、成本和单条消息的平均花费。
Clawalytics 还内置了一套安全监控功能，包括设备配对管理、连接事件日志、安全告警和完整的审计日志。考虑到 OpenClaw 之前爆出过不少安全问题（包括一个 CVSS 8.8 分的远程代码执行漏洞），有这样一个安全仪表盘确实能让人安心不少。
Clawalytics 还提供了一个 Model Context Protocol 服务器，暴露了十个工具，包括获取花费摘要、成本拆分、预算状态、安全告警等。这意味着你可以直接在 Claude Code 的对话里查询自己的花费情况，比如问一句”这周花了多少钱”，AI 就能通过 MCP 工具帮你查出来。
安装非常简单，一行命令搞定：
npm install -g clawalytics
或者如果你用 pnpm：
pnpm add -g clawalytics
安装完成后，Clawalytics 会自动注册为系统后台服务。在 macOS 上它会创建一个 LaunchAgent，在 Linux 上会创建 systemd 用户服务，在 Windows 上则注册为任务计划。服务会随系统启动自动运行，你不需要手动去启动它。
直接在终端输入 clawalytics（不带任何参数），会显示一个精简的状态面板，包括当前运行状态、花费概览和预算进度条。
要打开完整的 Web 仪表盘，服务默认运行在 9174 端口，用浏览器访问 http://localhost:9174 即可。
其他常用命令：
# 查看详细状态
clawalytics status
# 编辑配置文件
clawalytics config
# 设置预算
clawalytics budget --daily 10 --weekly 50 --monthly 200
# 查看日志
clawalytics logs -f
# 查看所有文件路径
clawalytics path
# 检查更新
clawalytics update --check
# 停止
clawalytics uninstall-service
配置文件位于 ~/.clawalytics/config.yaml，首次运行时会自动创建。你可以在里面自定义模型价格、设置预算阈值、配置 OpenClaw 的路径等。配置文件采用深度合并的方式，所以更新版本后新增的模型定价会自动生效，不会覆盖你的自定义设置。
一个典型的配置片段：
# 预算告警阈值
alertThresholds:
dailyBudget: 10
weeklyBudget: 50
monthlyBudget: 200
# OpenClaw 集成路径（通常自动检测）
openClawPath: ~/.openclaw
securityAlertsEnabled: true
如果你想在 Claude Code 里直接查询花费数据，可以把 Clawalytics 的 MCP 服务器加到配置中：
{
"mcpServers": {
"clawalytics": {
"command": "clawalytics-mcp"
}
}
}
如果你的 Clawalytics 跑在远程服务器上，可以通过 SSH 隧道访问：
clawalytics tunnel
这个命令会显示具体的 SSH 隧道建立说明。
所有数据都存储在 ~/.clawalytics/ 目录下：
clawalytics.db —— SQLite 数据库，使用 WAL 模式提供良好的并发读取性能config.yaml —— 配置文件clawalytics.log —— 运行日志pricing-cache.json —— 模型定价缓存（24 小时有效期）数据库里总共有 13 张表，涵盖会话记录、请求详情、每日成本汇总、模型使用统计、Agent 和 Channel 数据、设备管理、安全告警和审计日志。数据导出支持 CSV 和 JSON 两种格式。
卸载同样简单：
npm uninstall -g clawalytics
卸载脚本会自动清理系统服务（LaunchAgent / systemd / 任务计划），但会保留 ~/.clawalytics/ 目录里的数据和配置。如果你想彻底清理，需要手动删除这个目录：
rm -rf ~/.clawalytics
如果只想移除系统服务但保留 Clawalytics 本身，可以用：
clawalytics uninstall-service
社区里其实已经有一些 AI 成本监控的方案了。比如 TokPinch 是一个代理层方案，它能在请求层面做实时的预算限制和模型路由；ClawMetry 提供只读的统计数据；Tokscale 是一个纯 CLI 工具。
Clawalytics 的定位更偏向于”全功能本地仪表盘”。它不是一个代理，不会拦截你的请求，而是被动地读取日志文件来分析数据。这种方式的好处是零侵入——你的 AI 工具完全感知不到 Clawalytics 的存在，不会引入额外的延迟或故障点。缺点是它无法像代理方案那样主动阻止超支。所以最理想的做法可能是 Clawalytics 负责可视化和分析，API 提供商的原生限额功能负责兜底。
在 AI 辅助编程成为日常的今天，Token 消耗就像水电费一样——你不去看的时候感觉不到，但账单到手的时候往往会吓一跳。Clawalytics 做的事情其实很朴素：把散落在日志文件里的数据收集起来，计算清楚，然后用可视化的方式呈现给你。但就是这样一个”朴素”的工具，让我第一次真正理解了自己的 AI 使用习惯。
比如我发现自己有 60% 以上的花费其实来自 Opus 模型处理一些完全可以用 Sonnet 甚至 Haiku 搞定的任务。又比如，缓存命中率的提升让我一个月省了将近 40% 的成本，而这些在没有数据的时候都只是模糊的猜测。
如果你也是 Claude Code 或 OpenClaw 的重度用户，强烈建议试试 Clawalytics。安装只需要一行命令，卸载也很干净，几乎没有试错成本。
