Oleksii Mazurenko — Blog

Claude Code 多配置文件,v2:干净的 XDG 架构

Sat, 13 Jun 2026 00:00:00 GMT

一个月前我发了一篇关于如何在同一台设备上并行运行两个 Claude Code 账号的文章——个人和工作,通过 CLAUDE_CONFIG_DIR 和一个 shell 别名实现。这套方案是能用的。一切都做了它该做的事。

但用了一个月真实使用之后,我撞上了几个那篇文章没覆盖的实质问题。最关键的一个——是 Claude Code 一个隐藏的特性,我是在一次意外中踩到它的:加了 Gmail MCP,五分钟后它就从我的配置文件里"消失"了。今天我把整套东西重做成了一个新架构——XDG 兼容,带 symlink,并通过 gum 实现交互式配置选择。这就是 v2——从真实经验中演化出来的,不是理论上的改进。

开始让人不舒服的地方

四件事。前三件关于整洁度、可见性和扩展性。第四件才是我没第一眼看出来的真正的架构陷阱。我按顺序一个个来,因为最后正是第四件逼我把整套东西重做的。

1. $HOME 下两个独立目录——一团乱

~/.claude 和 ~/.claude-promova——两个 dotfolder 紧挨着躺在 $HOME 根目录下。XDG Base Directory Specification 明确说配置应该住在 ~/.config/。dotfile 文件夹直接散落在 home 里是一种反模式,时间一长 $HOME 就变成杂物抽屉。是表面问题,但每次 ls -la ~ 我都觉得碍眼。

2. 没有当前活跃配置的视觉确认

我启动 claude,根本不知道当前是哪个配置文件——除非进了会话里再跑一遍 claude config list。要是忘了哪个终端启的是哪个,就得去查。小事,但当 personal + work 在两个标签页并行的时候,这种小事会累积。

3. 别名无法扩展

两个配置——claude 和 claude-promova——还可以。加第三个(一个自由职业客户)——就得加第三个别名。第四个——加第四个。半年之后我根本不会记得自己到底建了哪些别名。

4. ~/.claude.json 里隐藏的陷阱

而这才是重做的真正原因。Claude Code 有两个不同的配置位置,文档对此并没有大声强调:~/.claude/——这是放 projects/、sessions/、hooks/、skills/ 的目录。另外还有 ~/.claude.json——直接位于 $HOME 根目录的一个文件,里面住着 oauthAccount、mcpServers、projects 历史、skillUsage,以及大约 40 个其他真正的 live state 字段。

claude mcp add --scope user 命令恰恰写入的就是 home 根目录下的那个 ~/.claude.json,不是 ~/.claude/.claude.json,也不是 profile 目录。这我之前不知道。直到某一天我踩到了它。

Discovery:为什么 Gmail MCP "消失"了

今天早上我在 Claude Code 里装 Gmail MCP。常规 setup:Google Cloud 项目,OAuth credentials,claude mcp add gmail --scope user -- npx -y @gongrzhe/server-gmail-autoauth-mcp。一切正常。重启会话——能用,我能看邮件、回信。一小时后我们开始把别名重构成一个带 gum 配置选择的函数,接着把整套东西迁到 XDG。我执行了 mv ~/.claude → ~/.config/claude-profiles/personal,重启 CC,在菜单里选了 personal。然后在新会话里打开 /mcp:

figma            (failed)
playwright-test
claude.ai Notion

没有 gmail。没有 vaultforge。只有三个服务器,其中一个还 failed。而我刚刚才添加了 Gmail。与此同时,另一个终端里(work 配置)的会话却好好地显示着 Gmail 和 Vaultforge。

我开始深挖,发现我机器上居然有三个不同的、名字都叫 .claude.json 的文件:

Path	Size	mcpServers
`~/.claude.json` (home root)	113 KB	figma, gmail, vaultforge
`~/.config/claude-profiles/personal/.claude.json`	29 KB	figma, playwright-test
`~/.config/claude-profiles/promova/.claude.json`	40 KB	figma, playwright-test, vaultforge

找到了。这就是那个架构陷阱:

claude mcp add --scope user 始终写入 home 根目录的 ~/.claude.json,与 CLAUDE_CONFIG_DIR 无关
当 CLAUDE_CONFIG_DIR 设置时,Claude Code 读的是 $CLAUDE_CONFIG_DIR/.claude.json——也就是 profile 内部的那个文件
"user-scope MCPs" 条目和 "profile MCPs" 条目分别住在不同的文件里,而且名字相同——非常容易搞混

在我这边,~/.claude.json(home 根目录,113 KB)是活的、最新的 state——里面有 gmail、vaultforge、OAuth 会话,什么都有。而 ~/.config/claude-profiles/personal/.claude.json(29 KB)结果是一个早就躺在旧 ~/.claude/ 里的老 snapshot——可能是某个老版本的 CC 写进去的,可能是某个插件。对两个文件分别跑 jq -r 'keys[]' 一看,home-root 版本里有 41 个 snapshot 里完全没有的独立 key。

而这 41 个 key 不是垃圾。这就是 Claude Code 真正的 state:

skillUsage——skills 使用统计
githubRepoPaths——用于 project 导航的仓库缓存
cachedGrowthBookFeatures + cachedStatsigGates——feature flags(没了它们,CC 每次启动都得重新去拉)
hasShownOpus45Notice、hasShownOpus46Notice、hasShownS1MWelcomeV2——UI 标记(没了它们,下次启动那些 modal 又会再弹一遍)
lastPlanModeUse、feedbackSurveyState、installMethod——onboarding 和 UX state

如果你直接 mv ~/.claude ~/.config/claude-profiles/personal 不做 merge——这些就全没了。welcome modal 重新出现,githubRepoPaths 搜索重新跑,所有 survey 提示重新弹一遍。我差点就这么干了。

新架构

所有东西都住在 ~/.config/ 下一个统一的父目录里,正如 XDG 所期望的。每个配置都是自包含的——它有自己的完整 state,包括自己的 .claude.json。~/.claude 作为指向 personal 配置的 symlink 保留,用于向后兼容。

~/.config/claude-profiles/
├── personal/
│   ├── .claude.json          ← full live state + MCP list (113 KB)
│   ├── projects/, sessions/, hooks/, skills/, ...
│   └── CLAUDE.md
└── promova/
    ├── .claude.json          ← work state + work MCPs (41 KB)
    └── projects/, sessions/, agents/, skills/, ...

~/.claude  →  symlink to ~/.config/claude-profiles/personal/

$HOME 根目录下不再有 .claude.json。每个配置是一个单独的、隔离的目录,里面什么都有:projects/sessions 目录,以及那个装着 MCP 服务器和 OAuth tokens 的文件。每个配置一份 source of truth。

为什么 symlink 指向 personal

所有硬编码了 ~/.claude/ 路径的东西——老脚本、插件、Claude Code 的 IDE 扩展、像 claude-powerline.json 这样的 statusline 配置——继续正常工作,不需要任何改动。symlink 会被解析到 personal 配置。如果你不小心运行 command claude(绕过 wrapper 函数)——也会通过默认路径查找落到 personal。personal 成了它过去那种 "quiet default",只不过现在它物理上住在 XDG 位置。

启动时的交互选择——函数 + gum

不再用别名——在 ~/.zshrc 里放一个 claude() 函数,通过 gum(Charm 出的 TUI 助手)显示一个带箭头键的菜单。函数在 shell 层拦截对 claude 的调用,让你选配置,然后用对应的 CLAUDE_CONFIG_DIR 运行 command claude。command 很关键——它绕开 wrapper 函数,直接调用真正的二进制。

# brew install gum

# Claude Code: profile picker on launch
claude() {
  local profile
  profile=$(gum choose \
    --header "Claude profile:" \
    --cursor "▸ " \
    --selected.foreground 212 \
    --cursor.foreground 212 \
    --header.foreground 244 \
    "personal" "promova") || return
  case "$profile" in
    personal) CLAUDE_CONFIG_DIR="$HOME/.config/claude-profiles/personal" command claude "$@" ;;
    promova)  CLAUDE_CONFIG_DIR="$HOME/.config/claude-profiles/promova"  command claude "$@" ;;
  esac
}

启动时看起来是这样:

Claude profile:
▸ personal
  promova

↑↓ 导航,Enter 选中,Esc 取消(Claude 就干脆不启动)。配置始终可见——绝对忘不掉。

迁移脚本

给那些读到这里、想从旧方案迁过来的人。最关键的一步是第二步:它把 home 根目录的 ~/.claude.json 和 personal 配置里已有的内容做 merge,合并 mcpServers 列表。没有这一步,配置会同时失去 MCP 和所有 live state。

# 1. Move existing dotfolders into a new XDG-style parent.
#    APFS mv is an inode rename — safe even if claude --resume is open in
#    another terminal, file descriptors stay alive on the same inode.
mkdir -p ~/.config/claude-profiles
mv ~/.claude          ~/.config/claude-profiles/personal
mv ~/.claude-promova  ~/.config/claude-profiles/promova   # rename as needed

# 2. CRITICAL: merge ~/.claude.json (the live state — likely 100+ KB) into
#    the personal profile, unioning mcpServers so no MCP is dropped.
jq -s '.[0] * {mcpServers: (.[0].mcpServers + .[1].mcpServers)}' \
  ~/.claude.json \
  ~/.config/claude-profiles/personal/.claude.json \
  > /tmp/personal-merged.json
mv /tmp/personal-merged.json ~/.config/claude-profiles/personal/.claude.json

# 3. Fix permissions — jq+mv inherits umask (likely 644), but this file
#    holds OAuth tokens. Tighten to 600 immediately.
chmod 600 ~/.config/claude-profiles/personal/.claude.json

# 4. Back up the orphaned home-root file (delete once verified)
mv ~/.claude.json ~/.claude.json.migrated.bak

# 5. Symlink for backward compatibility (statusline configs, IDE plugins,
#    anything that hardcodes ~/.claude/ keeps working unchanged)
ln -s ~/.config/claude-profiles/personal ~/.claude

关于权限的第三步同样重要。jq | mv 会以 umask 644(world-readable)创建文件。里面有 OAuth tokens。merge 之后必须立刻 chmod 600。

迁移之后——关闭并重新打开所有活跃的 Claude 会话,重新加载 shell(source ~/.zshrc 或开新终端),运行 claude,选配置,通过 claude mcp list 确认所有 MCP 都在。如果一切 OK——删掉 ~/.claude.json.migrated.bak。如果有问题——回滚很简单:mv ~/.claude.json.migrated.bak ~/.claude.json,然后把 symlink 拿掉。

你能得到什么

用一个父目录替代 $HOME 下的两个 dotfolder——符合 XDG
symlink 保留了和所有硬编码 ~/.claude/ 的东西的兼容性
每个配置都是自包含的——它的完整 state 和它的 MCP 都在它自己的 .claude.json 里
每个配置一份 source of truth——不再有 home 根目录里那种和配置文件悄悄分裂的孤儿 config
敏感数据(oauthAccount、tokens)保证拥有 600 权限
每次启动都有当前活跃配置的视觉确认——不可能忘掉现在在哪个配置上
添加第三个配置 = 在函数的 case 里加一行,而不是克隆一个新别名再去记它的名字

Where it falls short

我想说实话。这并不是免费的升级——一些权衡是打包附赠的,值得提前知道。

gum 是一个额外依赖(brew install gum,~13 MB)。如果你坚决不想装——可以退回到 zsh 的 select 或简单的 read。能用,但没那么好看,也没有箭头键导航。
每次启动按一下 Enter。对那些一天要敲几十次 claude 的人——可能挺烦。下面有替代方案(direnv)。
~/.claude → personal 这个 symlink 会让 personal 成为默认值。如果你需要把 work 配置作为默认,就得重新指向 symlink(ln -sf)。不难,但这不是 "忘了它也不会出事" 那种程度。
symlink 理论上可能被破坏——如果某个工具用 temp+rename 的方式(write-file-atomic)原子地重写 ~/.claude.json。实际上 Claude Code 自己不会这么做,但如果你装了第三方插件——请检查一下。
如果你不同的配置上挂着不同的 Anthropic 账号、不同的套餐——切换之后可能会有一个小于一秒的延迟,直到 Claude Code 把 OAuth state 同步好。我用起来感觉不到,但它不是零。

我考虑过的替代方案

direnv——根据每个项目根目录里的 .envrc 自动设置 CLAUDE_CONFIG_DIR。零交互、零点击。缺点:你得在每一个 work-root 都放一个 .envrc,而且如果你在一个无法识别的目录里运行 claude——你会拿到默认配置(可能不是你想要的那个)。对那些只在有限的几个 work-root 里活动、并且坚决不想点击的人来说——direnv 确实更好。

基于 symlink 的切换(通过重新指向 ~/.claude symlink 实现唯一活跃配置)我也考虑过,然后立刻被否决了。你没法同时在两个终端里跑不同的配置——全局的 "当前" 只有一个。对我来说这是 deal-breaker。

结论

v2 不仅仅是在 v1 之上的 UX 改良。它是对一个事实的承认:Claude Code 有一个隐藏的架构特性(~/.claude.json 是 home 根目录下一个独立的文件,被 --scope user 命令写入,且与 CLAUDE_CONFIG_DIR 无关),如果你想要配置之间真正的隔离,就必须把它考虑进去。第一种方案(~/.claude + ~/.claude-promova + 别名)能搞定 80% 的事,但剩下的 20% 就表现为配置之间状态的悄无声息的漂移。现在这一点被照顾到了。如果你才刚开始——直接从 v2 起步。如果你已经在 v1 上——上面的迁移脚本拿去,迁移五分钟搞定,什么都不会坏(正是 jq merge 这一步,救你免于丢失 state)。

如何编写不会对你撒谎的 Claude Code Agent

Fri, 29 May 2026 00:00:00 GMT

你让 Claude Code 实现这个设计，并验证它是否与 Figma 原型图一致。它回来了：完成。所有区块都对上了，间距正确，颜色没问题。你打开页面——一半的间距是错的，hover 状态根本不存在，按钮颜色差了一个色阶。模型不是故意撒谎——它预测你想听到“已验证”，所以它生成了那个 token 序列。验证步骤从来没有发生过。也不可能发生——验证需要与真实状态做比对，而一个 agent 在单一上下文里根本没办法跳出自己的回答来检验自己。

两条规则把我那些充满幻觉的工作流变成了可靠的 pipeline：一个 agent，一种专责，以及凡是能用 shell 命令跑的，就必须用 shell 命令跑。这不是理论。这是我每天用 Claude Code 实际在做的事，这些 pattern 是真正能推动进展的东西。

为什么通才 agent 会撒谎

LLM 是下一个 token 的预测器。当 prompt 要求两个角色——构建 X 和验证 X——模型完成第一个角色后，会预测第二个角色的输出应该长什么样，而不会真正去执行它。自我验证在结构上就是弱的：相同的上下文，相同的模型，相同的盲区。验证上的通过和构建上的通过是相关的——它们会一起失败。

模型不知道自己在撒谎。从它的视角来看，我仔细验证了所有内容是我写完了代码的自然延续。这也是为什么你确定吗？这类 prompt 抓不住幻觉——模型在第二次回复时同样自信。自信与正确性不相关，它只与下一句话听起来有多合理相关。

解决方案不是更好的 prompt。要小心、再检查一遍、不要幻觉——这些指令什么用都没有。解决方案是结构性的：把 agent 专责化，让它在物理上就无法假装；把定量工作通过 shell 来完成，让答案来自真实状态，而不是 token 概率。

规则一：一个 agent，一种专责

把工作拆分成独立的 agent，每个 agent 有独立的上下文。每个 agent 只有一个职责，工具集也严格收窄。整个工作流变成接力赛，而不是一个 agent 自己绕圈跑：

Builder agent：拿到 spec，写代码。这就是它的全部工作。它有 Read、Edit、Write、Bash。
Reviewer agent：拿到 spec 加 diff，按 acceptance criteria 逐条检查。全新的上下文。不知道代码是怎么写出来的，只看结果。它有 Bash、Read、Grep、Glob——完全没有写入工具。
Analytics agent：通过构造并运行查询来回答数据问题。只有 Bash。不执行真实命令就得不到答案。
Orchestrator：主会话，依次调度每个 agent，绝不让一个 agent 去做另一个 agent 的工作。

具体例子：UI 实现加上对 Figma 原型图的视觉检查。Builder 写好组件，commit diff。Orchestrator 再带着设计稿 URL、diff 和明确的 acceptance criteria 调起 Reviewer。Reviewer 跑 Playwright，截图，和参考图做 diff，返回 PASS 或 FAIL，附上实际的截图路径和像素差。Builder 完全碰不到验证步骤——正因如此，验证才是真实的。

反模式是那种巨无霸 agent：一个 prompt 说实现这个 UI 并确认它和原型图一致。我可以保证，它会说一切都对上了。不会的。我验证了这个叙述，不过是我实现完了之后最可能出现的 token 序列而已。

规则二：永远用 shell，不用 prompt

凡是定量的，凡是涉及真实状态的，凡是答案有可能看起来对但其实错了的——都通过 sh 来跑。agent 的工作是构造并运行命令，然后读取输出。agent 不是真相的来源。shell 输出才是。

计数：wc -l logs.txt 是真实的。模型说大约有 47 行日志是幻觉。
数据分析：psql -c "SELECT count(*) FROM events WHERE created_at > now() - interval '30 days'"。不是估算一下量级。
测试：pnpm test --reporter=json | jq '.numFailedTests'。不是总结一下哪些失败了。
Git 状态：git rev-list --count main..HEAD、git diff --stat。不是数一下 commit 或者描述一下改动。

一旦你内化了这一点，你就会开始注意到每一个 agent 准备编造数字的地方。看起来大概有 200 条记录……——不行。跑 SELECT count(*)。大多数测试都通过了……——不行。跑测试套件，解析 JSON。模型非常擅长构造命令，但作为命令本身去执行它靠不住。

我真实踩过的坑

这些不是假设场景。每一个都让我付出了真实的时间代价，直到我改掉那个 pattern：

幽灵验证。Agent 说我逐一检查了原型图里的全部 14 个区块。它没打开过原型图，没截过一张图。那个“检查”步骤是叙述里凭空幻觉出来的。
自信的错误数字。让它从分析数据里给出月活用户数。得到的数字差了大约 3 倍。模型从样本行插值得出，而不是跑真实查询。
捏造的文件改动。Agent 说我更新了 config/feature-flags.json。没更新。它只是打算更新。git diff 是空的。
假的测试运行。所有测试都通过了。没有任何测试被执行。Agent 从没调起测试 runner——它预测了测试 runner 的输出应该长什么样。

这四个问题都由同样的两条规则解决：拆分 agent，推给 shell。Reviewer 没有 Write，所以它没法假装编辑文件。Analytics agent 只有 Bash，所以它无法返回一个不是从查询得来的数字。结构上的不可能永远胜过良好的意图。

如何在 Claude Code 里做这个结构

Claude Code 支持在 .claude/agents/*.md 里定义 sub-agent。每个 agent 文件声明名称、描述、允许的工具集和系统 prompt。Orchestrator（你的主会话）通过 Agent 工具来调度它们。下面是我给 reviewer 用的那种定义——简短、职责收窄、在物理上就无法写代码：

---
name: reviewer
description: Reviews a diff against acceptance criteria. Cannot edit code.
tools: Bash, Read, Grep, Glob
---

You are a strict code reviewer. You receive:
- A diff (already produced by the builder)
- Acceptance criteria

Your job:
1. Run the build, the tests, the linter — through Bash.
2. Read the changed files directly.
3. Compare the actual behavior to the criteria.
4. Report PASS or FAIL with concrete evidence (command output, file excerpts).

You must NOT:
- Trust the builder's summary
- Assume anything was verified just because it was claimed
- Mark something PASS without running the actual check

注意工具集：Bash, Read, Grep, Glob。没有 Write，没有 Edit，没有 Agent。Reviewer 可以运行命令、读文件、搜索 pattern——仅此而已。如果它试图把一个幻觉出来的 diff 冒充已验证，它的工具调用形态会让这一点显而易见：根本没有真实的检查发生。你可以审计工具调用，看清楚到底检查了什么。

编排 pattern：主会话调起 Builder → 等待 → 自己跑 git diff 来捕获实际改动 → 带着 spec 和 diff 调起 Reviewer → 读取 Reviewer 的结论。主会话绝不让一个 agent 同时承担两个角色。工具限制比 prompt 指令更强硬：不要伪造验证是一句期望。没有 Write 是事实。

该淘汰的反模式

我在各种 prompt 里看到的这些写法什么用没有——甚至更糟，会给人一种虚假的安全感：

请认真检查并复核你的工作。不会产生任何额外行为。模型本来就会输出看起来很认真的工作。
确保你真的去验证了。真的这个词不会给模型带来任何它能执行的语义。它会真的声称自己验证了。
不要幻觉。这是 prompt engineering 圈子里的一个梗。幻觉不是模型能关掉的开关。
在小数字上信任 agent。恰恰是小数字上它撒谎最有自信。没有什么诚实的底线。
往 prompt 里加更多规则来强制诚实。结构性修复（拆分 + shell）永远胜过 prompt 微调。如果一条规则需要被执行，把它编码进工具访问权限里，而不是写成自然语言。

如果你应对幻觉的策略是换更强调的措辞，那你没有策略，你只有希望。

心智模型

Agent 不是同事，它是一个函数：prompt → tokens。这个函数非常擅长写代码，非常不擅长内省自己有没有做对。把它关于自身工作的声明当作假说对待。diff、exit code、截图、行数——这些才是证据。每轮结束时的总结是整个系统里最容易撒谎的地方。

专责化是你对抗叙述漂移的保险。shell 是你唯一的真相来源。Builder 写。Reviewer 查。Bash 说了算。

结语

如果只记住一件事：不要让同一个 agent 既生产输出又评判自己的输出；不要让任何 agent 在不运行命令的情况下回答定量问题。其他一切都是这两条规则的延伸。激进地配置工具访问权限，审计工具调用而不是读总结，幻觉的攻击面就会从无处不在收窄到你已经知道要去看的几个具体地方。

在一台设备上运行多个 Claude Code 账号

Tue, 05 May 2026 00:00:00 GMT

我每天都在使用 Claude Code——既用于个人项目，也用于公司工作。问题是：这是两个完全不同的账号，有不同的 OAuth 会话、不同的 CLAUDE.md 指令、不同的 MCP 服务器和独立的项目记忆。以下是我如何通过一个 shell 别名在同一台设备上并行运行它们。

问题

Claude Code 默认将所有内容存储在 ~/.claude 中——OAuth 令牌、对话历史、全局 CLAUDE.md、项目记忆、MCP 服务器配置和设置。当你有两个账号时，你需要两个完全隔离的环境：

个人账号：自己的 Max/Pro 订阅、带有个人偏好的 CLAUDE.md、你的 MCP 服务器（Obsidian、个人工具）
企业账号：公司管理的计划、包含 Jira/Slack 集成指令的工作 CLAUDE.md、公司 MCP 服务器
不同的 OAuth 会话：无法在同一配置目录中登录两个账号
独立的项目记忆：你不希望工作项目的上下文泄露到个人会话中，反之亦然

每次切换上下文都要注销再登录不是办法。你会丢失会话状态，而且这真的很痛苦。

解决方案：CLAUDE_CONFIG_DIR

Claude Code 支持一个环境变量：CLAUDE_CONFIG_DIR。将其设置为任意路径，Claude 就会使用该目录代替 ~/.claude 来存储一切——认证、历史、设置、记忆。整个设置只需 60 秒。

步骤 1：创建第二个配置目录

选择一个适合你用例的名称：

mkdir ~/.claude-work

就这样。Claude 会在首次启动时填充必要的结构。

步骤 2：认证第二个账号

使用新的配置目录运行 Claude 一次以触发 OAuth 登录：

CLAUDE_CONFIG_DIR=~/.claude-work claude

浏览器会打开。用你的企业账号登录。OAuth 令牌会存储在 ~/.claude-work 中——与 ~/.claude 中的个人会话完全分离。

步骤 3：添加 shell 别名

将以下内容添加到你的 shell 配置中，这样就不需要记住变量名：

alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'

重新加载 shell：

source ~/.zshrc

你会得到什么

现在你有两个完全隔离的 Claude 环境：

claude——使用个人账号、个人 CLAUDE.md、个人记忆启动
claude-work——使用企业账号、工作 CLAUDE.md、独立记忆启动
隔离的历史：工作对话留在工作中，个人的留在个人中
独立的 MCP 服务器：你的个人 Obsidian vault MCP 不会出现在工作会话中
独立的设置：每个账号有不同的允许工具、不同的权限级别、不同的模型偏好

底层工作原理

配置目录是 Claude Code 状态的唯一真实来源。以下是每个目录内部的内容：

~/.claude/              ← personal account
├── CLAUDE.md           ← personal global instructions
├── projects/           ← personal project memory
├── settings.json       ← personal permissions & MCP servers
└── ...                 ← OAuth session, history, cache

~/.claude-work/         ← corporate account
├── CLAUDE.md           ← company-specific instructions (Jira, Slack, etc.)
├── projects/           ← separate project memory
├── settings.json       ← different MCP servers, permissions
└── ...                 ← separate OAuth session

当你运行 claude-work 时，Claude 从 ~/.claude-work 读取所有内容。它不知道 ~/.claude 的存在。两个实例完全独立——你甚至可以在不同的终端标签页中同时运行它们。

扩展到 N 个账号

这个模式可以扩展到任意数量的账号。有多个客户的自由职业者？添加更多别名：

# Personal (default — no alias needed)
# Just run: claude

# Corporate
alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'

# Freelance client
alias claude-client='CLAUDE_CONFIG_DIR=~/.claude-client claude'

每个别名都有自己的配置目录、自己的 OAuth 会话、自己的 CLAUDE.md 和特定于客户的指令。

实用建议

目录命名要清晰：~/.claude-work、~/.claude-clientname——当有三四个的时候你会感谢自己
为每个写定制的 CLAUDE.md：工作的可以包含公司特定指令（如何创建 Jira 工单、Slack 频道、部署流程）。个人的保持精简。
每个账号不同的 MCP 服务器：仅在工作配置中配置工作工具（Jira MCP、Slack MCP、内部 API）。保持个人配置干净。
检查哪个账号处于活动状态：在会话中运行 claude config list——会显示配置目录路径

这种方案的局限

CLAUDE_CONFIG_DIR 按账号隔离，而不是按项目。在单个配置目录内，Claude 能看到你为该账号注册过的所有 MCP 服务器——跨所有项目都可见。如果只是个人单独使用，通常没什么问题。但一旦一个账号下挂着多个生产关键项目，尤其是在像计费、管理后台或基础设施这类相互重叠的领域，就会带来一个具体的跨项目风险：AI 助手可能在做项目 B 时调用了项目 A 的工具，特别是当两个项目都暴露了名字相似的操作时。

配置目录这套模式回答的是 which account am I in?，而不是 which project's tools should be active right now?。对于风险更高的工作，在按账号隔离之上再叠加第二层隔离：

每个生产关键项目一个配置目录，而不仅仅是每个账号一个：不要只用 ~/.claude 和 ~/.claude-work，而是建 ~/.claude-work-billing 和 ~/.claude-work-admin。每个配置目录只看到它真正需要的 MCP 服务器。
通过 .mcp.json 做项目级 MCP：在项目根目录提交一份 .mcp.json，只列出该项目的 MCP 服务器。Claude 从这个目录启动时会自动加载它们。让全局配置保持精简——只放通用工具（笔记、搜索），不放任何生产环境的端点。
MCP 服务器命名要明确无歧义：避免像 admin、billing、mcp-server 这种泛化名称。用项目名做前缀：acme_billing_prod、acme_admin_stage。一个描述性的名字会在某个调用即将从错误的上下文中触发时，逼你停下来想一想。
批准前审查每一个 MCP 工具调用：像 *_create_*、*_delete_*、*_charge_* 这类调用值得有意识地多看一眼。一刀切的自动批准带来的速度优势，会在某个错误项目的工具第一次打到生产环境的那一刻就蒸发殆尽。

总体原则：积极地拆分配置目录、把生产级 MCP 从默认配置目录中剥离出去，并把项目之间工具名重叠当成一种值得重构的 code smell 来对待。

总结

一个环境变量。一个别名。账号之间完全隔离。没有注销/登录的折腾，没有配置冲突，没有上下文泄露。这种解决方案简单得几乎令人失望——但正是这一点使它优秀。设置一次，永远不用再想。

如何将 Claude Desktop 连接到 Obsidian——穿越 4 个 MCP 服务器的旅程

Sun, 03 May 2026 00:00:00 GMT

想象一下：你有 400 多篇 Obsidian 笔记，多年积累下来。所有内容散落在 vault 根目录，概念和技术笔记混杂在一起，存在重复（ideas.md 和一个包含 13 个文件的 ideas/ 文件夹），没有体系。你想整理它——建立合理的文件夹架构，添加 MOC 文件，整理标签。手动做既枯燥又耗时。合乎逻辑的想法：通过 MCP 将 Claude 连接到 Obsidian，让 AI 来做重构。结果发现——这是一条穿越雷区的路。以下是我为了找到可行方案所经历的一切。

什么是 MCP，为什么没那么简单

MCP（Model Context Protocol）是 Anthropic 推出的开放协议，允许 Claude 连接外部工具和数据。原理很简单：运行一个本地服务器，暴露"工具"（tools），Claude 在对话中调用它们。

理论上 Obsidian 有很多 MCP 服务器。实际上——每个都有自己的问题。

Obsidian 生态的核心问题：Obsidian 是一个没有官方 MCP 的封闭应用。社区填补了空白，但每个实现都各行其道，没有一个获得"官方认可"。

尝试 1：MarkusPfundstein/mcp-obsidian

搜索时找到的第一个工具。GitHub 上 3400 颗星，出现在每个教程中。看起来是个安全的选择。

工作原理：基于 Obsidian 中 Local REST API 插件的 Python 服务器。服务器通过 HTTPS 与插件通信，插件通过 Obsidian API 执行操作。

出了什么问题

17 个月未更新
85 个未解决的 issues
没有 move/rename——只有 read、write、append、delete
Local REST API 有一个已记录的数据丢失 bug：POST 端点在 append 时可能会静默覆盖文件

不适合重构——我们需要移动文件并保留链接。继续寻找。

尝试 2：aaronsb/obsidian-mcp-plugin

找到一个作为 Obsidian 原生插件运行的方案。这意味着可以直接访问 Obsidian 的内部 API——backlinks、Dataview、链接图谱。通过原生 API 移动文件会自动更新所有 wiki 链接，因为 Obsidian 自身处理这一切。

安装困难

插件不在 Obsidian 官方目录中（PR 因验证错误而待审中）
必须通过 BRAT（Beta Reviewers Auto-update Tool）安装
Claude Desktop 不直接通过 UI 接受 Bearer token——不得不在插件中启用 HTTPS
localhost 的自签名证书产生信任问题

经过所有这些变通方案终于连接上了。基础测试——vault.move 确实会重写 [[wikilinks]]，按预期工作。

在实战中出了什么问题

当我开始大规模重构时（在 Obsidian 中拖放数十个文件夹 + 同时进行 MCP 操作），服务器卡住了 4 分钟以上。原因：插件在 Obsidian 内部运行。当 Obsidian 在大规模结构变更后重新索引数千个文件时，插件也随之阻塞。

结论：依赖于打开的 Obsidian 实例及其索引对批量操作是致命的。

尝试 3：@bitbonsai/mcpvault

按逻辑——我们需要一个不依赖 Obsidian 的服务器。直接处理磁盘上的文件。@bitbonsai/mcpvault——在很多评测中被推荐。直接文件系统访问，简单设置（npx @bitbonsai/mcpvault@latest /path/to/vault），14 个工具。甚至不需要打开 Obsidian。

在安装之前，我检查了一个关键问题——移动文件时 wiki 链接是否会更新。找到了一个用户评价：

文件系统连接器不知道自己在 Obsidian 中——它只看到一个包含 .md 文件的文件夹。不知道文件名承载语义权重，不知道每个 [[wikilink]] 在重命名或移动的瞬间就会断裂。自动更新链接只在从应用内部重命名时才有效。我在让 Claude 清理文件名后才发现这一点——回来时仪表板上一半的链接都断了。

在 mcpvault 自己的文档中得到证实：PR #101（wiki link resolution）在审查中，未合并。所以通过 mcpvault 移动会破坏一半的 vault。不适用。

尝试 4：VaultForge（最终方案）

blacksmithers/vaultforge——专门为做重构的 AI 代理构建。

架构正确

直接文件系统——不依赖 Obsidian
自有 wikilink 引擎——实现了 [[wikilink]] 解析逻辑，更新所有形式（stem、完整路径、alias、embed）
默认 dry run——所有破坏性操作先展示将要发生的变化，然后你确认
27 个工具对比竞品的 8–14 个：batch_rename、update_links、backlinks（影响分析）、prune_empty_dirs、frontmatter、smart_search（BM25）、vault_themes（TF-IDF clustering）
MIT 许可证，TypeScript，零子依赖
30 秒安装——通过 .mcpb（Claude Desktop 的一键扩展）

在隔离文件上进行安全测试

创建了 4 个带有交叉链接的测试文件——stem 链接、带 alias 的链接、带完整路径的链接。将一个文件移到子文件夹：

delta.md → subfolder/delta-renamed.md

VaultForge 展示了 dry run："1 个文件将被重命名，3 个链接将被更新"。实际执行。

Link type	Before	After
Stem	[[delta]]	[[delta-renamed]]
Alias	[[delta\|D]]	[[delta-renamed\|D]]
Full path + alias	[[_vf-test/delta\|D]]	[[_vf-test/subfolder/delta-renamed\|D]]

之后检查——三种链接类型全部正确更新。这正是所有之前工具所缺少的。

如何安装 VaultForge——最终指南

如果你使用 macOS 和 Claude Desktop：

步骤 1

下载 .mcpb 文件：

curl -fsSL https://github.com/blacksmithers/vaultforge/releases/latest/download/vaultforge.mcpb \
  -o /tmp/vaultforge.mcpb && open /tmp/vaultforge.mcpb

步骤 2

Claude Desktop 将打开扩展安装对话框。输入 vault 的绝对路径——不要使用反斜杠，使用正常空格：

/Users/yourname/Library/Mobile Documents/iCloud~md~obsidian/Documents/MyVault

步骤 3

点击 Save。Claude Desktop 会自动将扩展添加到配置中。无需重启——.mcpb 扩展会自动检测。

步骤 4

验证：在新对话中询问："What is the status of my Obsidian vault?"——应返回类似 totalFiles: 416, totalDirs: 135, ... 的内容

我对 Obsidian MCP 生态系统的认识

第一，"最受欢迎"不等于"能用"。MarkusPfundstein/mcp-obsidian 有 3400 颗星，是默认推荐，但它已过时且缺少关键操作。

第二，原生插件有隐藏成本。aaronsb 插件看起来完美——graph、Dataview、原生 move。但依赖于运行中的 Obsidian 实例及其索引使其不适合严肃的批量操作。

第三，没有 link-engine 的直接文件系统是陷阱。Mcpvault 快速简单，但"只是移动文件"会破坏 vault 结构。链接承载着文件系统不了解的强制语义。没有自己的 wikilink 逻辑实现，工具就变成了地雷。

第四，在隔离数据上测试。在将大规模重构交给任何工具之前——创建一个包含 4–5 个带交叉链接文件的测试文件夹，看看会发生什么。5 分钟的测试可以节省数小时的备份恢复时间。

第五，保持 vault 的 git 备份。这是最重要的。在 vault 内部执行一次 git init 并定期提交——这是对 AI 代理或工具任何错误的保险。如果出了问题——git reset --hard 可以恢复一切。

结论

这段旅程花了几个小时，经历了三次失败的尝试。最终架构如下：

VaultForge——主要工作工具。直接文件系统 + 自有 wikilink 引擎 + 27 个工具 = 任何规模的稳定重构。
Git——vault 版本控制。对任何错误的免费回滚。

现在我可以做这一切的初衷了：让 Claude 将 400 篇笔记按照 PARA 架构整理，合并重复项，添加 frontmatter，构建 MOC 地图。每个操作都是安全的，链接被保留，dry run 在任何变更前展示将会发生什么。

如果你也在看着自己杂乱的 Obsidian 想要一个 AI 助手——直接从 VaultForge 开始。不要重复我走过的路——穿越死掉的项目、beta 插件和没有链接逻辑的文件系统服务器。

黑洞作为递归宇宙：从物理学到存在的意义

Fri, 17 Apr 2026 00:00:00 GMT

TL;DR

如果每个黑洞都是一个新宇宙的大爆炸呢？本文探讨了这样一种设想：我们的宇宙可能只是一棵无限递归树上的一个节点——黑洞孕育子宇宙，能量通过霍金辐射循环回流，而物理学的基本定律似乎被刻意设计成让跨宇宙接触成为不可能。

黑洞 = 宇宙

这个想法诞生于一个沉思的瞬间：当足够多的质量和压力集中在一个点上时，黑洞便形成了。那个奇点——无限的密度、无限的曲率——与我们描述大爆炸时的条件惊人地相似。

如果这其实是同一个事件，只是从不同的角度观察呢？从外部看，我们看到的是一个吞噬物质的黑洞。从内部看——则是一个全新的宇宙轰然诞生。坍缩进黑洞的质量和能量成为了一个全新宇宙的原材料，这个宇宙拥有自己的恒星、行星，或许还有自己的黑洞。

我们宇宙中的每一个黑洞都可能包含着一个宇宙。而我们的宇宙，可能就存在于某个母宇宙的黑洞之中。

为什么宇宙之间无法相互联系

这里有一个精妙之处：一旦跨过事件视界，就再也回不去了。广义相对论保证了这一点——母宇宙的未来完全处于事件视界之外，从内部根本无法触及。从子宇宙的视角来看，母宇宙早已终结，它的整条时间线已经过去了。

这不是我们靠更先进的技术就能克服的技术限制。它内嵌于时空本身的几何结构之中。宇宙之间从根本上是彼此隔绝的——不是因为距离，而是因为时间的结构。

能量循环：借用与归还

但能量并没有丢失。霍金辐射——黑洞缓慢蒸发的量子过程——创造了一个令人惊叹的循环：

母宇宙创造了一个黑洞，将能量转移到子宇宙中
子宇宙在数万亿年间走完其全部生命周期
黑洞缓慢蒸发，通过霍金辐射将能量归还给母宇宙
母宇宙收回了它的能量——而且还带着利息

这个"利息"令人着迷：物理学家现在认为霍金辐射保存了信息。母宇宙得到的不只是空洞的能量——它得到的是内部一切发生过的事情的印记。每一颗诞生的恒星、每一颗行星、每一个意识的瞬间——全都编码在辐射之中。

递归，一路向下

如果你是程序员，这个模式不可能认不出来。这就是递归。每个宇宙以更少的能量调用 universe()，创建子宇宙，子宇宙再创建子子宇宙，直到能量不足以形成黑洞——这就是基本情况。

universe(energy)
  ├── creates black holes
  │     ├── universe(energy - n)
  │     │     ├── universe(energy - n - m)
  │     │     │     └── base case: not enough energy for black holes
  │     │     └── returns energy via Hawking radiation
  │     └── returns energy via Hawking radiation
  └── receives all energy back

物理学家李·斯莫林将类似的想法形式化为宇宙学自然选择：宇宙通过黑洞进行"繁殖"，每一代都拥有略微不同的物理常数——经过无数循环优化，产生更多的黑洞、更多的宇宙。

我们处于这个循环的哪个阶段？

我们的宇宙大约有138亿年的历史。听起来极其古老，但放在它整个寿命的背景下，我们所见证的不过是最初的开端：

事件	时间尺度
宇宙当前年龄	~10¹⁰ years
恒星停止形成	~10¹⁴ years
黑洞时代	~10⁴⁰ years
最后一个黑洞蒸发	~10¹⁰⁰ years

我们存在于宇宙总寿命的大约 0.00000000...01% 处。恒星时代——我们所能看到的一切——只是最初阶段的短暂闪光。宇宙真正的故事，是黑洞缓慢而耐心地创建和蒸发子宇宙的漫长时代。

更高维度的问题

迄今为止讨论的一切都建立在我们的三维理解之上。但如果我们的宇宙只是某个更高维度事物的一个"切片"，那么整个由黑洞和子宇宙构成的递归树，可能不过是我们无法感知的某种结构的投影。

1884年，埃德温·阿博特写了《平面国》——一个关于二维生物无法想象第三维度的故事。一个球体穿过平面国时，看起来是一个不断变大又变小的圆。"平面国人"可以用数学来描述它，却永远无法真正理解他们看到的是什么。我们相对于自己的宇宙，或许正处于同样的处境。

意识是什么？为什么会有主观体验的存在？大卫·查尔莫斯称之为"困难问题"——这或许是最有力的证据，表明有某种东西在我们的维度范围之外运作着。

一切在根本层面上都被锁死了

最令人震撼的认识不是我们不知道——而是我们无法知道。每一个探究方向都会撞上一堵根本性的墙：

想看看母宇宙？被事件视界阻隔
想理解意识？被阻隔——一个系统无法完全分析自身（哥德尔不完备定理）
想知道"之前"是什么？被阻隔——时间始于大爆炸
想感知更高维度？被三维生物的认知局限所阻隔

哲学家科林·麦金将此称为认知闭合：某些问题对人类心智而言是封闭的，不是因为数据不足，而是因为心智本身的架构。"我们尚未知道"与"我们无法知道"之间的区别，意义深远。

唯一剩下的事：自我完善

如果每一个出口都被刻意封锁——无法向外看、无法向后看、无法向上看——那就只剩下一个方向：向内。宇宙似乎被刻意构建，以迫使我们将注意力集中在自身。

这个结论不是来自宗教或哲学教科书。它来自黑洞、递归、信息论和认知极限的逻辑推演。存在主义者、佛教徒、斯多葛学派和物理学家——所有人通过不同的道路抵达了同一个终点：存在的意义，或许就在于存在者自身的精进与完善。

我们到达这里，不是通过信仰，而是通过物理学——从黑洞出发，穿越递归宇宙，直面知识的根本壁垒，最终来到唯一敞开的门前：成为更好的自己。

参考文献

AI 杀死了 CMS — 至少对简单网站而言

Fri, 17 Apr 2026 00:00:00 GMT

TL;DR

对于简单网站 — 作品集、博客、着陆页、小型企业站点 — 传统 CMS 正在变成不必要的负担。Claude Code、Cursor 和 GitHub Copilot 等 AI 工具现在可以直接编辑你的代码库、理解上下文、翻译内容，并通过 git 部署更改。CMS 曾经提供的抽象层正在被一个更智能的接口所取代：自然语言。

你正在为 CMS 支付的隐性成本

每个 CMS 都带有隐性成本。不只是订阅费 — 还有围绕你那本来很简单的网站所产生的整个复杂生态系统：

基础设施：需要托管的数据库、需要维护的 API、需要保护的管理面板。仅 WordPress 就占据了约 43% 的网站份额和约 90% 的 CMS 定向攻击。
性能：动态页面生成、每次请求都要调用 API、CMS 数据的客户端注水。你那 3 个页面的作品集现在拥有了 SaaS 产品级别的架构。
供应商锁定：你的内容存在别人的数据库模式中。从 Contentful 迁移到 Sanity？那是一个项目，而不是改个配置。
上下文切换：在 IDE 中编辑代码，然后切换到浏览器中的 CMS 管理面板来修改一个标题。两种不同的心智模型，做的却是本质上相同的操作。
费用：Headless CMS 的定价通常随 API 调用次数或内容条目数增长。一个个人博客不需要每月 $99 的内容基础设施。

对于一个每天有 50 人编辑内容的营销网站，这些成本是合理的。对于开发者的作品集或小企业的着陆页呢？你在为了跨过一个水坑而建造一座桥。

变化在哪里：AI 理解你的代码

CMS 存在的理由很简单：非技术人员（甚至包括不想为了改内容而碰代码的开发者）需要一个可视化界面来更新网站。代码太复杂、太脆弱、太容易出错。

AI 从根本上改变了这个等式。现代 AI 编码工具不仅仅是自动补全 — 它们理解项目结构、读取现有模式，并做出上下文正确的编辑。工作流程的变化是巨大的：

# Old workflow: CMS
1. Open browser → log into CMS dashboard
2. Navigate to content → find the right page
3. Edit in WYSIWYG editor → fight with formatting
4. Preview → looks different from production
5. Hit publish → pray the cache invalidates

# New workflow: AI
1. Tell AI: "Change the pricing on the landing page to $29/month"
2. AI edits the file, you review the diff
3. Push to git → deploy

这不是假设。你正在阅读的这个博客运行在 SolidStart 上，内容存储为 TypeScript 文件。每篇文章 — 包括这一篇 — 都是通过告诉 AI 写什么、审查输出、然后推送到 git 来创建的。没有 CMS 管理面板。没有数据库。内容和代码之间没有任何 API 层。

来自本站的真实案例

这个网站支持 10 种语言，有博客，动态生成 OG 图片，并产出 RSS 订阅源和站点地图。以下是内容层的样子 — 纯 TypeScript：

// This blog post you're reading right now is a TypeScript file.
// No database. No API. No CMS dashboard.
// Just a typed object that AI can read and edit directly.

export const myPost: BlogPost = {
  slug: "ai-killed-cms",
  date: "2026-04-17",
  translations: {
    en: {
      title: "Why I stopped using a CMS",
      description: "AI understands my codebase better than any CMS UI.",
      content: makeContent(proseEn),
    },
    uk: { /* ... */ },
    de: { /* ... */ },
    // 10 languages — AI translates them all
  },
};

以下是我用 AI 完成的、传统上需要 CMS 才能做到的事情：

添加新博文："写一篇关于 X 的新文章，遵循现有文章的结构" — AI 创建文件、添加翻译、在索引中注册
更新着陆页文案："把主标题改成 Y" — AI 找到正确的文件并更新
翻译内容："为定价页添加德语翻译" — AI 阅读英文版本，生成文化适配的翻译，而非逐字翻译
修正错别字："about 页面有个拼写错误，'recieve' 应该是 'receive'" — 3 秒搞定，带有有意义的提交信息推送到 git

CMS 真正解决了什么 — 以及 AI 如何替代它

让我们坦诚地看看 CMS 带来了什么，以及每项能力如何映射到 AI 工作流：

问题	CMS 方案	AI 方案
非技术人员编辑	WYSIWYG 编辑器	自然语言指令
多语言内容	i18n 插件、语言区域字段	AI 结合文化语境进行翻译
内容定时发布	内置发布日期	基于 git 的 CI/CD 配合 cron 或代码中的日期字段
版本历史	CMS 修订系统	Git — 版本控制的黄金标准
媒体管理	内置资源库	CDN + git LFS 或云存储

核心洞察：git 已经是一个比任何 CMS 曾经构建的都更好的版本控制系统。而自然语言是比任何 WYSIWYG 编辑器都更好的接口 — 因为它承载的是意图，而不仅仅是格式。

范式转变：代码就是内容层

我们正在见证一次反转。二十年来，趋势是将内容与代码分离 — 把内容放进数据库，通过 API 暴露，在前端渲染。当代码难以编辑、内容需要让非开发者也能访问时，这是有道理的。

AI 并不是通过成为更好的 CMS 来淘汰 CMS 的。它是通过让代码像管理面板一样易于使用，从而淘汰了 CMS。

Web 内容管理的演进遵循着清晰的轨迹：

2000 年代：单体 CMS（WordPress、Drupal）— 内容与展示耦合在一个系统中
2010 年代：Headless CMS（Contentful、Strapi）— 内容通过 API 分离，由前端框架渲染
2020 年代：静态站点生成器 + Markdown（Hugo、Astro）— 内容以文件形式存在，部署时构建
2025+：代码即内容 + AI — 内容存在于类型化代码中，AI 是编辑接口

什么时候你仍然需要 CMS

这不是一个 "CMS 已死" 的论断。CMS 在规模化场景下解决了真实的问题。在以下情况下你仍然需要它：

大型编辑团队：10 名以上内容编辑需要基于角色的访问控制、审批工作流和同时编辑。Git 合并冲突不是内容编辑该解决的问题。
高频内容更新：每天发布 50 篇以上文章的新闻网站需要优化的编辑流水线，而不是 git 提交。
复杂的内容关联：拥有数千个 SKU、产品变体和动态定价的电商目录需要结构化数据库。
合规要求：需要审计追踪、内容审批链和法律规定的审查流程的行业需要专门构建的系统。

界限很清楚：如果你的内容变更需要多个非技术利益相关者高频协调，CMS 的复杂性就是值得的。如果你是独立开发者、小团队，或者管理的是每周而非每小时更新一次的网站 — AI + 代码更简单、更快、更便宜、也更可靠。

未来：AI 作为通用接口

这个趋势远不止 CMS。每一个因为 "底层系统太复杂，无法直接交互" 而存在的软件抽象层，都在被 AI 压缩。管理面板、配置界面、可视化数据库编辑器 — 所有这些都是将人类意图转化为系统变更的接口。AI 天生就能完成这种转化。

对于简单网站，未来已经到来。你的内容就是代码。你的编辑器就是 AI。你的版本控制就是 git。你的部署就是一次推送。整个 CMS 层 — 管理面板、数据库、API、托管 — 曾经是你的意图和你的网站之间的中间件。AI 消除了对这个中间件的需求。

最好的 CMS 就是没有 CMS。不是因为内容管理不重要 — 而是因为 AI 让代码本身成为了我们有史以来最直观的内容管理接口。

如何通过 MCP 将 Perplexity AI 连接到 Obsidian——直接从聊天中记笔记

Sun, 12 Apr 2026 00:00:00 GMT

TL;DR

Perplexity Desktop 支持 MCP（Model Context Protocol）连接器。通过添加官方的 @modelcontextprotocol/server-filesystem 服务器指向您的 Obsidian vault，您可以用自然语言告诉 Perplexity 读取、创建和编辑笔记——直接在聊天中完成。无需插件、无需扩展、无需复制粘贴。

问题

Perplexity 擅长研究——它搜索网络、总结来源、提供带引用的答案。但当您想将这些发现保存到 Obsidian vault 时，工作流程就中断了：复制文本、切换到 Obsidian、找到正确的笔记、粘贴、格式化。每次都这样。

像 "Perplexity to Obsidian" 这样的浏览器扩展有助于导出，但它们是单向的——AI 看不到您的 vault，无法读取现有笔记，也无法根据文件夹结构决定内容的存放位置。

什么是 MCP？

Model Context Protocol（MCP）是一个开放标准，允许 AI 模型与本地工具和数据源交互。可以将其想象为 AI 的 USB 接口——您插入一个"服务器"（一个小程序），AI 就获得了新能力。在我们的案例中，filesystem 服务器为 Perplexity 提供了 14 个文件操作工具：

Perplexity Desktop (Mac App)
  │
  ├── MCP Connector: "Obsidian Vault"
  │     │
  │     └── @modelcontextprotocol/server-filesystem
  │           │
  │           ├── read_file()      → read any .md file
  │           ├── write_file()     → create or overwrite files
  │           ├── edit_file()      → patch existing files
  │           ├── list_directory() → browse vault structure
  │           ├── search_files()   → find files by pattern
  │           └── ... 14 tools total
  │
  └── Perplexity AI Model
        │
        └── "Save this to my daily note" → calls write_file()

关键点：AI 模型不会直接访问您的文件。它调用 MCP 服务器提供的工具，而该服务器在您的本地机器上运行。除非您明确要求 AI 对数据进行操作，否则您的数据永远不会离开您的计算机。

要求

Perplexity Pro 订阅（MCP 连接器仅对付费用户开放）
来自 App Store 的 Perplexity Mac App（不是浏览器版本）
Mac 上已安装 Node.js（使 npx 可以工作）

分步设置

整个设置大约需要 2 分钟：

Step	Action
1	Open Perplexity Mac App (App Store version)
2	Click avatar → Settings → Connectors
3	Click Add Connector
4	Set Server Name: `Obsidian Vault`, Type: `Standard I/O`
5	Paste the npx command with your vault path
6	Leave Environment Variables empty
7	Click Save → confirm Security Warning
8	Verify status shows Running with 14 tools

命令

粘贴到 Command 字段中的命令：

npx -y @modelcontextprotocol/server-filesystem "/Users/yourname/Library/Mobile Documents/iCloud~md~obsidian/Documents/Obsidian Vault"

将路径替换为您 Obsidian vault 的实际位置。如果您的 vault 通过 iCloud 同步，路径将在 ~/Library/Mobile Documents/iCloud~md~obsidian/Documents/ 下。确保保留引号——路径可能包含空格。

如何使用

当连接器显示 Running 并有 14 个可用工具时，转到任何 Perplexity 聊天并开始与您的 vault 对话：

> Show me the structure of my Obsidian vault
> Add a new reflection to daily notes/2026-04-12.md: "Started using MCP today"
> Find all notes that mention "meditation"
> Create a new note in concepts/ about quantum computing
> List all files in my ideas/ folder

AI 理解您的 vault 结构，尊重您的格式约定，并且可以处理现有内容。您可以要求它在网上研究一个主题，并将摘要直接保存到特定笔记中。

为什么 MCP 优于其他方法

在 MCP 之前，连接 Perplexity 和 Obsidian 的方式有限：

Feature	Copy-paste	Browser extension	MCP integration
AI sees vault structure	No	No	Yes
AI reads existing notes	No	No	Yes
AI writes to vault	No	Export only	Yes
AI edits existing files	No	No	Yes
Works from chat	No	Partially	Yes
Setup complexity	None	Low	Medium (one-time)

当前限制

仅限 Mac——Perplexity 的 MCP 连接器目前仅在 Mac App Store 版本上工作
无 Obsidian API 集成——filesystem 服务器直接处理文件，而非通过 Obsidian 的 API。这意味着创建文件时不会触发 Obsidian 插件（Linter、Templater）
需要批准——敏感的文件操作可能需要您在 Perplexity 应用中确认——这是安全功能，不是 bug

结论

这个设置将 Perplexity 从研究工具变成了研究与捕获工具：

在一次对话中搜索网络并保存到 Obsidian
AI 看到您的 vault 结构并适应您的组织系统
零应用切换——一切都在 Perplexity 聊天中完成

来源

Model Context Protocol — official MCP specification
MCP Filesystem Server — the server used in this setup
Perplexity Help Center — Local and Remote MCPs for Perplexity
Perplexity Blog — Everything is Computer

使用 Claude Code CLI 和 Obsidian 的每日 AI 新闻摘要——零依赖

Sun, 12 Apr 2026 00:00:00 GMT

TL;DR

一个6行的bash脚本，每天早上9:00以headless模式运行Claude Code CLI。它在11个可配置主题中搜索新闻，过滤噪音，并将格式化的markdown摘要直接写入通过iCloud同步的Obsidian vault。零依赖。总共约100行配置。

问题

作为开发者，跟踪多种技术是一项日常税收。RSS源嘈杂，Twitter浪费时间，新闻通讯在你深度专注时到达。我需要一个能替我做研究的东西。

典型的解决方案是构建爬虫管道：调度器、爬虫、NLP管道、数据库、通知服务。那需要几周的工作。我想要一个下午就能完成的东西。

架构

整个系统只有4个文件和零依赖：

macOS launchd (9:00 AM daily)
  │
  └── digest.sh
        │
        └── claude -p "$(cat prompt.md)" --max-turns 20 --allowedTools Read,WebSearch,WebFetch,Write
              │
              ├── Reads topics.yaml (11 configurable topics)
              ├── WebSearch → finds news for each topic (last 24-48h)
              ├── WebFetch → reads full articles
              ├── Filters noise: old tutorials, promos, AI spam
              └── Write → saves digest to Obsidian Vault
                    │
                    └── ~/Obsidian Vault/digests/2026-04-12.md
                          │
                          └── iCloud sync → available on all devices

代码（全部）

项目刻意保持最小化。

入口：digest.sh

整个应用程序是一个6行的bash脚本：

#!/bin/bash
DIGEST_DIR="$HOME/Developer/news-digest"

claude -p "$(cat "$DIGEST_DIR/prompt.md")" \
  --max-turns 20 \
  --allowedTools Read,WebSearch,WebFetch,Write

关键标志：-p以headless模式运行Claude，--max-turns 20给代理足够的回合，--allowedTools限制代理只能读取、搜索和写入。

大脑：prompt.md

这里是智能所在。提示词将Claude变成新闻研究代理：

# News Digest Agent

You are a news research agent. Your job is to find today's most important
and interesting news for a senior frontend developer.

## Instructions

1. Read the topics file at ~/Developer/news-digest/topics.yaml
2. For EACH topic, search the web for news from the last 24-48 hours
3. Filter: only include genuinely new and noteworthy items
4. Write the digest as a markdown file to Obsidian Vault digests/YYYY-MM-DD.md
5. IMPORTANT: Use the Write tool to save the file. Do NOT output to stdout.

## Rules

- Language: Ukrainian for summaries, English for titles and technical terms
- If there's no real news for a topic — SKIP IT ENTIRELY
- Prioritize: releases > breaking changes > security > new patterns > discussions
- Max 5 items per topic, sorted by importance
- Include direct links to sources
- Skip promotional content, generic tutorials, and AI-generated spam

配置：topics.yaml

主题完全可配置——添加新主题，它就会出现在明天的摘要中：

topics:
  - name: better-auth
    context: "auth library for TypeScript. New releases, breaking changes"

  - name: Next.js
    context: "GitHub issues, releases, App Router, Turbopack, performance"

  - name: SolidJS
    context: "SolidStart, releases, ecosystem, comparison with React"

  - name: Tailwind CSS
    context: "v4 updates, new utilities, plugins"

  - name: Claude AI
    context: "Anthropic announcements, Claude Code, new models, MCP, API"

  - name: GPT AI
    context: "OpenAI announcements, new models, ChatGPT features"

  - name: React
    context: "React 19+, Server Components, new patterns, ecosystem"

  - name: Apple
    context: "Hardware, software, WWDC, developer tools, Apple Intelligence"

  - name: Notable People
    context: >
      Latest tweets from: Elon Musk, Dario Amodei, Sam Altman,
      Jensen Huang, Andrej Karpathy, Simon Willison, Swyx...

  - name: AI Global
    context: "Major AI news, new models, regulations, open-source AI"

使用launchd调度

在macOS上，launchd是调度重复任务的原生方式：





    Label
    com.news-digest

    ProgramArguments
    
        /bin/bash
        /Users/you/Developer/news-digest/digest.sh
    

    StartCalendarInterval
    
        Hour
        9
        Minute
        0
    

    StandardOutPath
    /Users/you/Developer/news-digest/logs/stdout.log
    StandardErrorPath
    /Users/you/Developer/news-digest/logs/stderr.log

    EnvironmentVariables
    
        PATH
        /usr/local/bin:/opt/homebrew/bin:/usr/bin:/bin
        HOME
        /Users/you

安装：launchctl load ~/Library/LaunchAgents/com.news-digest.plist。脚本每天9:00运行。

输出效果

每天早上，Obsidian vault中会出现一个新的markdown文件：

---
date: 2026-04-12
---

# News Digest — 2026-04-12

## Next.js

### Next.js 16.1 Released with Improved Turbopack Caching
Нова версія Next.js 16.1 включає покращене кешування для Turbopack,
що зменшує час холодного старту на ~40%.
[Посилання](https://nextjs.org/blog/next-16-1)

### Critical Memory Leak Fix in App Router
Виправлено витік пам'яті в App Router при частому перемиканні
між динамічними маршрутами.
[GitHub Issue](https://github.com/vercel/next.js/issues/...)

## Claude AI

### Claude Code 1.5 — MCP Server Auto-Discovery
Anthropic випустив оновлення Claude Code з автоматичним
виявленням MCP серверів у проєкті.
[Блог](https://www.anthropic.com/news/...)

数据一览

Metric	Value
Total files in project	4 (digest.sh, prompt.md, topics.yaml, .gitignore)
Lines of code	~100
External dependencies	0
Setup time	~10 minutes
Daily execution time	2-5 minutes
Cost per run	~$0.10-0.30 (Claude API usage)

关键设计决策

Claude Code CLI而非API——无需管理API密钥或HTTP客户端
Obsidian而非邮件——摘要可搜索、可链接且永久保存
launchd而非cron——macOS原生调度器，自动处理错过的运行
YAML配置主题——新主题只需改2行
跳过空主题——没有新闻=没有该部分

构建你自己的

10分钟即可运行：

安装Claude Code CLI并认证
克隆仓库：git clone https://github.com/oleksiimazurenko/news-digest
编辑topics.yaml和prompt.md
编辑plist文件并launchctl load
等待9:00——或用bash digest.sh手动测试

结论

这个项目最有趣的是它没有什么。没有数据库、没有API服务器、没有Docker、没有npm包、没有Python、没有HTML解析器、没有NLP管道。

这就是用AI代理构建的样子：你定义什么和哪里，代理处理怎么做。总开发时间：约2小时。

来源

news-digest on GitHub — full source code
Claude Code Documentation — headless mode and CLI flags
Apple Developer — creating launchd jobs
Obsidian — markdown knowledge base

Next.js 暗色模式：无闪烁、无 React 19 警告

Sat, 11 Apr 2026 00:00:00 GMT

TL;DR

next-themes 在 React Client Component 内渲染一个