一台开发机上同时维护个人项目和工作项目，提交记录希望用不同的 GitHub 账号。不想每次 clone 后手动改 user.email，也不想搞全局切换脚本。SSH 密钥隔离 + Git 条件配置就能解决，配完一劳永逸。

1. 场景

典型需求：

• 个人项目（~/personal/*）用个人 GitHub 账号提交
• 工作项目（~/work/*）用公司 GitHub 账号提交
• 每个账号有独立的 SSH 密钥，互不干扰
• 进入不同目录自动切换身份，无需手动配置

额外痛点：

• 公司网络可能封 SSH 默认端口 22，需要走 443
• 有些项目需要用别名（如 work.github.com）区分 remote URL

2. 整体思路

三层配置协同工作：

1. SSH 层（~/.ssh/config）：为不同账号配置独立密钥和 Host 别名
2. Git 全局层（~/.gitconfig）：设置默认账号和 SSH 命令
3. Git 条件层（~/.gitconfig-work）：按目录路径自动覆盖账号信息

关键机制：includeIf 让 Git 在特定目录下加载额外配置文件。

3. 步骤

3.1 生成 SSH 密钥对

为每个账号生成独立密钥：

# 个人账号密钥
ssh-keygen -t rsa -b 4096 -C "personal@example.com" -f ~/.ssh/id_rsa_personal

# 工作账号密钥
ssh-keygen -t rsa -b 4096 -C "work@company.com" -f ~/.ssh/id_rsa_work

生成后会得到：

• ~/.ssh/id_rsa_personal + ~/.ssh/id_rsa_personal.pub
• ~/.ssh/id_rsa_work + ~/.ssh/id_rsa_work.pub

将 .pub 公钥分别添加到对应 GitHub 账号的 SSH keys 设置页面。

3.2 配置 SSH Host 别名

编辑 ~/.ssh/config（没有则创建）：

# 个人账号（默认）
Host github.com
  HostName ssh.github.com
  User git
  IdentityFile ~/.ssh/id_rsa_personal
  Port 443

# 工作账号（使用别名 work.github.com）
Host work.github.com
  HostName ssh.github.com
  User git
  IdentityFile ~/.ssh/id_rsa_work
  Port 443

重点说明：

• Port 443：绕过防火墙对 22 端口的封锁，GitHub 官方支持 ssh.github.com:443
• Host 别名：work.github.com 是本地别名，实际连接的还是 ssh.github.com
• IdentityFile：指定使用哪个密钥

测试连接：

# 测试个人账号
ssh -T git@github.com
# 预期输出：Hi personal-username! You've successfully authenticated...

# 测试工作账号
ssh -T git@work.github.com
# 预期输出：Hi work-username! You've successfully authenticated...

3.3 配置 Git 全局默认

编辑 ~/.gitconfig：

[user]
  name = Your Name
  email = personal@example.com

[core]
  # 全局强制使用个人账号密钥
  sshCommand = ssh -i ~/.ssh/id_rsa_personal -F /dev/null

# 条件配置：work 目录自动切换账号
[includeIf "gitdir:~/work/"]
  path = ~/.gitconfig-work

关键点：

• sshCommand 强制使用指定密钥，-F /dev/null 阻止 ~/.ssh/config 干扰（可选，取决于你的优先级策略）
• includeIf 匹配路径时，gitdir: 后的路径必须以 / 结尾才能匹配子目录
• 路径支持 ~ 展开和通配符 *

3.4 配置工作账号条件文件

创建 ~/.gitconfig-work：

[user]
  name = Your Name
  email = work@company.com

[core]
  sshCommand = ssh -i ~/.ssh/id_rsa_work -F /dev/null

现在逻辑是：

• 默认用个人账号（~/.gitconfig）
• 进入 ~/work/ 任何子目录，自动切换到工作账号（~/.gitconfig-work 覆盖）

3.5 使用 Host 别名 clone 工作项目

工作项目 clone 时需要修改 URL：

# 原始 URL（会用个人账号）
git clone git@github.com:company/project.git

# 改用 Host 别名（会用工作账号密钥）
git clone git@work.github.com:company/project.git

或者 clone 后修改 remote：

git remote set-url origin git@work.github.com:company/project.git

为什么需要别名？

即使在 ~/work/ 目录下，如果 remote URL 是 git@github.com，SSH 会优先匹配 ~/.ssh/config 中的 Host github.com 配置。Host 别名让你在 URL 层面就区分账号。

4. 验证配置

4.1 检查当前目录生效的配置

# 在个人项目目录
cd ~/personal/my-project
git config user.email
# 输出：personal@example.com

# 在工作项目目录
cd ~/work/company-project
git config user.email
# 输出：work@company.com

4.2 检查 SSH 连接使用的密钥

# 查看实际使用的 SSH 命令
git config core.sshCommand

# 手动测试（带详细日志）
GIT_SSH_COMMAND="ssh -v" git ls-remote origin
# 输出中会显示 "Offering public key: /path/to/id_rsa_xxx"

4.3 测试提交身份

# 创建测试提交
echo "test" > test.txt
git add test.txt
git commit -m "test commit"

# 查看提交的 author
git log -1 --format="%an <%ae>"

5. 常见问题

5.1 端口 22 被墙

症状：ssh -T git@github.com 超时

解决：在 ~/.ssh/config 中添加：

Host github.com
  HostName ssh.github.com
  Port 443

GitHub 官方在 ssh.github.com 的 443 端口提供 SSH 服务，专门用于绕过防火墙。

5.2 密钥权限问题

症状：Permissions 0644 for 'id_rsa_work' are too open

解决：

chmod 600 ~/.ssh/id_rsa_*
chmod 644 ~/.ssh/id_rsa_*.pub

私钥必须只有所有者可读写（600），公钥可以宽松一些（644）。

5.3 includeIf 不生效

检查清单：

1. 路径必须以 / 结尾：gitdir:~/work/（对）vs gitdir:~/work（错）
2. Git 版本：includeIf 需要 Git 2.13+，运行 git --version 确认
3. 路径展开：~ 会展开，但相对路径不会，建议用绝对路径或 ~/
4. 调试：运行 git config --show-origin user.email 查看配置来源

5.4 已有项目切换账号

如果项目已经用错误账号提交过：

# 1. 修改 remote URL（如果需要）
git remote set-url origin git@work.github.com:company/project.git

# 2. 修改最近一次提交的 author（如果还没 push）
git commit --amend --reset-author

# 3. 批量修改历史提交（慎用，会改写历史）
git filter-branch --env-filter '
if [ "$GIT_COMMITTER_EMAIL" = "wrong@example.com" ]; then
  export GIT_COMMITTER_EMAIL="correct@example.com"
  export GIT_AUTHOR_EMAIL="correct@example.com"
fi
' --tag-name-filter cat -- --branches --tags

6. 进阶：更细粒度的控制

6.1 按项目单独配置

如果某个项目需要特殊配置，在项目内运行：

git config user.email "special@example.com"
git config core.sshCommand "ssh -i ~/.ssh/id_rsa_special"

项目级配置（.git/config）优先级最高，会覆盖全局和条件配置。

6.2 多个工作目录

如果有多个工作目录：

[includeIf "gitdir:~/work/"]
  path = ~/.gitconfig-work

[includeIf "gitdir:~/company-a/"]
  path = ~/.gitconfig-company-a

[includeIf "gitdir:~/company-b/"]
  path = ~/.gitconfig-company-b

6.3 HTTPS 协议多账号

本文聚焦 SSH，但 HTTPS 也可以多账号：

• macOS Keychain 存储凭据，git-credential-osxkeychain 管理
• 或用 GitHub CLI：gh auth login 支持多账号切换
• 条件配置中可以设置不同的 credential.helper

7. 总结

配置后的工作流：

1. 个人项目放在 ~/personal/，自动用个人账号
2. 工作项目放在 ~/work/，自动用工作账号
3. Clone 工作项目时记得用 git@work.github.com
4. 忘记配置也没关系，提交前 git config user.email 检查一下

核心收益：

• 零手动切换：进入目录自动生效
• 隔离彻底：密钥、身份、目录三层隔离
• 可验证：每步都有明确的测试方法

这套配置用了两年，再没有提交记录用错账号的情况。

用 Claude Code 半年，从一开始把它当 “VSCode + Cursor 的某种替代”，到现在更像在管理一个能并行的小团队。这篇是把我自己日常真正在用的高级功能梳一遍 —— hook、MCP、subagent、worktree、CLAUDE.md 分层、/clear 时机这些。不是官方文档复述，是有取舍判断的使用者视角。读完应该能直接抄走改改就用。

0. 文章地图

8 个模块，按"先操作后理念"排：

操作类都附完整的、能复制就跑的片段；理念类讲的是"为什么这样设计、什么时候动手"。

1. Hook 系统：在生命周期事件上挂脚本

Hook 是 Claude Code 最低估的一个能力。它把整个会话切成一组生命周期事件，让你在每个点插入自己的脚本：

注册位置在 ~/.claude/settings.json 或者项目里的 .claude/settings.json。最常见的两种用法：

用法一：模型动作前后挂自动化。 例如每次 Edit 之后自动跑一遍 ESLint。把 lint 错误回灌到模型上下文，比"你忘了 lint 我帮你催一下"靠谱得多 —— 模型会在下一轮直接修。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "node /Users/me/.claude/hooks/lint-changed.js",
            "timeout": 30
          }
        ]
      }
    ]
  }
}

matcher 支持工具名的正则 —— Edit|Write 表示文件写入类工具触发。脚本从 stdin 拿到 hook payload（包括被改的文件路径），跑 lint、把错误打到 stdout 即可。退出码非 0 时 Claude Code 会把 stderr 当作模型输入。

用法二：把会话状态接到外部世界。 我之前写过 一篇专门讲 Mac 通知 + Bark 推送 的文章，本质就是 Stop + Notification 两个事件接一个 Python 脚本，本地弹一条 macOS 通知，远程发一条手机推送。长任务跑完不用一直盯屏幕。

Hook 真正的强项是 它把"提醒模型做某件事"变成了"由系统强制做某件事"。指令型的提示再怎么写也会被遗忘，hook 不会。

2. CLAUDE.md：给 Agent 的项目说明书

CLAUDE.md 看起来很简单 —— 就是一份 Markdown，自动注入每次会话的 system prompt。但它的真正威力来自分层：

~/.claude/CLAUDE.md         # 全局：所有项目都注入
<repo>/CLAUDE.md            # 项目级：cd 到这个 repo 才注入
<repo>/<subdir>/CLAUDE.md   # 子目录级：进入子目录的工作才注入

合并顺序是从外到内，越靠内的优先级越高。结合用法：

• 全局 写"我是谁、偏好什么"。例如"我是 Jason，写代码时优先函数式风格"，“中文回复偏正式术语，避免口语化译法”。
• 项目级 写"这个 repo 的隐式规则"。例如"用 pnpm 不用 npm"、“提交前必须跑 pnpm test"、“Tailwind 颜色只用 tokens.ts 里定义的，不准 bg-red-500"。
• 子目录级 写"这块代码的局部约定”。例如 apps/api/CLAUDE.md 写"所有 endpoint 必须有 zod schema 验证”。

写什么最有效？我自己摸出来的几条：

1. 写"模型容易踩的坑"，不写"显然的规则"。 “用 React” 不用写，模型会自己看 package.json。“我们的 useFetch 必须放在 try/catch 外层因为内部已经 catch” —— 这种写。
2. 写"一次教会、永久有效的"。 Boris Cherny 那句"compounding engineering" —— 每次 Claude 犯的错被记下来都是永久红利。把"昨天它又把 logger 引错位置了"这种小坑加进去。
3. 每条尽量给原因。 “用 X 不用 Y” 不如"用 X 不用 Y，因为 Y 会触发 ESM/CJS 互引问题"。模型知道为什么之后泛化能力强一档。
4. 保持精简。 CLAUDE.md 每次会话都加载，吃上下文。我个人的红线是单文件不超过 200 行。超过就考虑拆到子目录或 slash command 按需加载。

一份我自己在用的项目级模板片段：

# Project: lifelog

## Stack
- Hugo (extended) + 自定义主题 inkstone (git submodule)
- 内容在 content/posts/，中英双语：foo.md + foo.en.md
- 通过 translationKey 关联两版

## 写作约定
- 第一人称、有取舍判断
- 引言用 blockquote 起手
- 长文在第 0 节给文章地图
- 避免口语化译法（专业术语用正式中文，不用流行翻译腔）

## 操作约定
- 启动本地预览：`hugo server -D`
- 提交前跑：`hugo --minify` 确保没有报错
- 永远不直接 `git push`，让我自己来

最后一条是配合下面 §7 的权限模型用的 —— Agent 看到这条会克制自己。

3. MCP Server：把外部能力包成工具

MCP（Model Context Protocol）是 Anthropic 开源的协议，作用是让任何外部工具/数据源都能以统一的方式接入到 Claude（或者其他兼容 client）。Anthropic 自己有一句话：MCP 之于 LLM 等价于 USB-C 之于硬件。

Claude Code 默认就内置了一些（filesystem、bash、web fetch），但真正解锁场景的是自定义 MCP server。三个原语对应 Agent 的三种"知道方式"：

注册一个 MCP server 到 Claude Code 最快的路径是用 CLI：

# 加一个本地 stdio server
claude mcp add my-tools \
  --command "node /Users/me/mcp-servers/my-tools/index.js"

# 加一个 HTTP server
claude mcp add notion \
  --url "https://mcp.example.com/notion" \
  --header "Authorization: Bearer xxx"

# 看现在挂了哪些
claude mcp list

写一个最小的自定义 server 也不复杂。下面是一个"读 Linear issue"的最小骨架（Node.js + 官方 SDK）：

// index.js
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const server = new Server(
  { name: "linear-mini", version: "0.1.0" },
  { capabilities: { tools: {} } }
);

server.setRequestHandler("tools/list", async () => ({
  tools: [
    {
      name: "get_issue",
      description: "Fetch a Linear issue by identifier (e.g. ENG-123)",
      inputSchema: {
        type: "object",
        properties: { id: { type: "string" } },
        required: ["id"],
      },
    },
  ],
}));

server.setRequestHandler("tools/call", async (req) => {
  if (req.params.name !== "get_issue") throw new Error("unknown tool");
  const { id } = req.params.arguments;
  const r = await fetch(`https://api.linear.app/graphql`, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: process.env.LINEAR_API_KEY,
    },
    body: JSON.stringify({
      query: `query($id:String!){ issue(id:$id){ title description state { name } } }`,
      variables: { id },
    }),
  });
  const data = await r.json();
  return { content: [{ type: "text", text: JSON.stringify(data, null, 2) }] };
});

await server.connect(new StdioServerTransport());

接进 Claude Code 之后，会话里直接说"看一下 ENG-123 这条 issue"，模型就会调 get_issue。

我的取舍判断：

• 能用现成 MCP 别自己写。 GitHub、Notion、Slack、Postgres 这些都有官方/社区维护的 server，先去 modelcontextprotocol.io↗ 翻一遍。
• 自定义 MCP 适合"私有 / 内部 / 跨工具"的能力。 例如把公司内部的状态板、自己的笔记库、家里的 NAS 接进来。
• MCP server 启动失败不会致命，但会降级。Claude Code 启动时如果 server 跑不起来，整个会话还是能跑，只是那个工具不可用。所以可以放心多挂几个。

4. 并行 Agent：一次派多路 subagent

Claude Code 内置了一个 Task 工具，可以在主会话里派出 subagent 并行干活。这不是噱头，是真正改变工作节奏的能力。

典型场景：

• 大重构：把"重命名 X 到 Y"拆成"找所有引用"、“改 src/"、“改 test/"、“改 docs/“四路并行
• 多技术栈对照：让两个 subagent 分别用 React 和 Vue 实现同一个组件，回来对比
• 代码审查：派一个 subagent 看安全、一个看性能、一个看可读性

调用方式在主会话里就是说一句类似的话：“请并行启动 3 个 subagent，分别检查 src/api/、src/components/、src/hooks/ 三个目录的类型错误，把结果汇总。“模型会自动用 Task 工具 fan out。

如果想固化成标准流程，可以在 .claude/agents/ 下定义命名 subagent：

<!-- .claude/agents/security-reviewer.md -->
---
name: security-reviewer
description: 专注于安全漏洞的代码审查 agent
tools: Read, Grep, Glob, Bash
---

你是一个专注于 OWASP Top 10 的代码审查者。
扫到的每条问题按以下格式输出：

- **风险等级**: Critical / High / Medium / Low
- **位置**: file:line
- **类型**: SQL Injection / XSS / SSRF / ...
- **修复建议**: 具体改法

只看安全问题，不要给样式或性能反馈。

之后在主会话里"用 security-reviewer 子代理审一下 src/api/“就会精准触发。tools: 字段限制 subagent 能用的工具（不给它 Edit/Write 就让它只读）。

几条用了一阵之后的体会：

• 并行的极限大概在 5-8 个。再多 token 成本和上下文切换成本就上来了。
• subagent 不共享主会话的上下文。它只看自己的 prompt 和能调到的工具。所以指令必须自包含。
• 结果的合并是主 agent 的活。 主 agent 拿回 N 份输出之后还要再做一轮整合，这一步的质量很大程度决定了并行的最终价值。
• 不是所有任务都适合并行。强耦合的任务（A 的输出是 B 的输入）拆成并行反而更慢。判断标准：能不能写成"互不影响、独立完成"的若干份子任务。

5. Worktree 隔离：让多个 session 物理上分开

并行的另一种粒度是多个 Claude Code 主会话并行跑在同一个 repo 上。最大的坑是：它们都改同一个 working tree，互相覆盖。

git worktree 是为这个量身打造的：

# 主 repo 在 ~/code/myapp（在 main 分支上正常开发）
cd ~/code/myapp

# 派生两条独立分支的工作目录
git worktree add ../myapp-feat-a -b feat/a
git worktree add ../myapp-feat-b -b feat/b

# 现在物理上有 3 个目录：
#   ~/code/myapp        (main)
#   ~/code/myapp-feat-a (feat/a)
#   ~/code/myapp-feat-b (feat/b)
# 共享同一个 .git，但工作树完全隔离

然后开三个终端，各自 cd 到对应目录、claude 启动会话。三个 agent 同时干三件事，互不污染。

我自己的工作流：

1. 复杂任务先在主 repo shift+tab 进 plan mode，跟模型把任务拆成 3-5 个正交的子任务
2. 每个子任务开一个 worktree（命名 <repo>-<task-slug>）
3. 开三个终端窗口（用 tmux / Warp 的 split），各自跑一个 Claude
4. 跑完之后回主 repo，用 git worktree list 检查，挨个 review、merge、git worktree remove

git worktree list                      # 看现在有哪些 worktree
git worktree remove ../myapp-feat-a    # 干完拆掉
git worktree prune                     # 清理过期引用

几条经验：

• 每个 worktree 用独立分支。在同一个分支上开两个 worktree 会被 git 拒绝（这是好事）。
• node_modules / .venv 不共享。每个 worktree 都要重新装。可以用 pnpm 的 store 或者 venv 的 symlink 缓解，但代价是配置变复杂，看权衡。
• 跨 worktree 的环境变量、.env 不会自动复制。需要的话 cp 或者 symlink。
• worktree 不是 fork。所有 worktree 共享同一个 .git/，所以 git fetch 一次全更新，commit 也是同一个 object database。这是它比 git clone 多份快的原因。

worktree + 并行 subagent 是两种不同的并行：subagent 是"在一个会话里 fan out”，worktree 是"多个独立会话物理隔离”。前者快但耦合，后者慢但干净。我一般在重构 / 跨模块改动时用 worktree，在调研 / 检查 / 生成类任务里用 subagent。

6. Slash 命令 / Skill：把工作流固化

/command 是 Claude Code 的另一个 compounding 投资点。任何你做过两次的工作流，第三次开始就该考虑把它变成 slash 命令。

定义位置：

~/.claude/commands/<name>.md         # 全局，所有项目都能用
<repo>/.claude/commands/<name>.md    # 项目级

文件本身就是一份 Markdown，会作为 prompt 注入。下面是我用的 /review 命令：

<!-- .claude/commands/review.md -->
---
description: 对当前分支 vs main 的 diff 做一轮自审
allowed-tools: Bash(git diff:*), Bash(git log:*), Read
---

请对当前分支相对于 main 的所有变更做一轮代码自审：

1. 跑 `git diff main...HEAD --stat` 看改了哪些文件
2. 跑 `git diff main...HEAD` 看具体内容
3. 按以下角度给反馈：
   - 有没有引入复杂度但没价值的抽象
   - 有没有破坏既有约定（参考 CLAUDE.md）
   - 测试覆盖是否够（重点看新增 public 函数）
   - 是否有遗留的 console.log、debugger、TODO

最后给出一份 markdown 形式的审查报告，可以直接贴进 PR。

会话里 /review 一敲就跑完整套。allowed-tools 字段限定只允许跑 git diff/log 类命令 —— 即使不在全局 allowlist 里也临时放行，保证安全。

支持参数也很简单，文件里用 $ARGUMENTS 占位：

<!-- .claude/commands/explain.md -->
请详细解释 $ARGUMENTS 这段代码做了什么、为什么这样写、有没有更简单的写法。

会话里 /explain src/utils/debounce.ts 就会把路径替换进去。

我现在常驻的几条命令：

Skill（更广义的"打包能力”）目前还在演进，但核心思路是一样的：把"反复需要解释给 Claude 的工作流"变成"一行就能触发的资产”。每条都是永久红利。

7. 权限与安全模型：allow / deny / skip 三档

Claude Code 的权限系统是它跟普通"AI 编辑器"最大的区别之一。简单说有三档：

settings.json 里的 permissions 块是最常调的地方：

{
  "permissions": {
    "allow": [
      "Bash(npm test:*)",
      "Bash(pnpm:*)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(git log:*)",
      "Edit",
      "Write",
      "Read"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(chmod:*)",
      "Bash(curl:*)",
      "Bash(git push:*)",
      "Bash(git commit:*)"
    ]
  }
}

deny 优先于 allow。我个人的风格偏保守：

1. 能拒绝的危险动作全 deny。 rm -rf、git push、git commit、curl（防 exfil）、chmod、sudo。
2. 常用读操作 allow。 git status、git log、ls、pwd、cat、各种 test 命令。
3. 写操作不在 allowlist 里。Edit / Write 我反而留默认 ask —— 模型每次写文件都会再问一下，体感慢一点但底线很稳。

--dangerously-skip-permissions（启动参数）是核武器：所有权限检查全跳过。它不是给日常用的，是给以下场景：

• Docker / VM 沙盒里，反正搞坏了重启就没了
• 一次性脚本任务，例如批量重命名 1000 个文件，全程在自己看着的情况下跑
• CI / Headless 跑，整个环境本来就是临时的

千万别在自己的工作环境里日常开 dangerouslySkipPermissions。代价是 —— 如果模型某次产生幻觉决定 rm -rf ~，你会哭。

更稳的做法是用 沙盒：把 Claude 跑在 devcontainer / Docker / Multipass VM 里，物理上隔离。Anthropic 自己的 安全最佳实践文档↗ 就推荐了这种用法。

权限模型的真正用途是让 Agent 在合理范围内自主，越界时强制停下来问。allow 太松会被坑，deny 太多会变成每步都问的 “co-pilot 模式” 失去 agentic 价值。这个度需要项目和个人风格双重平衡。

8. 上下文管理：context 是 king，但会腐烂

最后一条，理念为主。Andrej Karpathy 那句被引爛的话：

“Context engineering is the delicate art and science of filling the context window with just the right information for the next step.”

而 Anthropic 自家的研究反复确认了一个反直觉的事：上下文不是越多越好。模型在长上下文下会出现"context rot”（上下文腐烂）—— 即使是简单任务，输入越长性能越下滑。

所以 Claude Code 提供了几把刀：

我的使用习惯：

• 任务边界是 /clear 的天然时机。 写完 feature A 要修 bug B，先 /clear。
• 跑了 30+ 轮还在同一任务上、感觉模型开始"漂”，先 /compact。 体感上 /compact 之后模型会重新聚焦。
• CLAUDE.md 是"永久上下文”，不要让它变成废话仓库。 每条都该是高频用到的。
• 真正长的参考资料别贴对话里，写到文件让模型 Read。 Read 是按需加载，不贴整段 paste 进 prompt。

更深一层的理念是 subagent 是上下文管理的工具。每派一个 subagent 出去，相当于给那个子任务一个干净的上下文窗口；它跑完只把摘要回传给主 agent。这就是为什么大重构用 subagent 比"主 agent 一个人改"更快 —— 不是因为并行省时间，是因为每个子上下文都更干净。

跟权限模型一样，上下文管理是个"时机感"问题，没有死规则。原则只有一条：当你感觉模型开始重复、绕圈、忘事，就该动手了。这个直觉是用出来的。

9. 收束：从工具到团队

写完这 8 节，回头看共同的主线其实是：

Claude Code 最值钱的不是它能写代码，是它能被你配置成你工作方式的一部分。

Hook 是反射弧，CLAUDE.md 是长期记忆，MCP 是感官扩展，subagent 是分身，worktree 是物理隔离，slash 命令是肌肉记忆，权限模型是边界，上下文管理是节制 —— 这些组合起来，你管理的就不再是"一个 AI 编辑器"，是一个有反射、有记忆、能并行、有边界、会休息的小团队。

具体到日常，最容易落地的三条（如果只能选三条）：

1. 每个项目至少有一份 200 行以内的 CLAUDE.md。这是最便宜的复合投资。
2. 任何做过两次的事，第三次包成 slash 命令或 hook。
3. 超过 30 分钟的任务先 plan mode，复杂改动直接开 worktree。

剩下的 MCP、subagent、自定义 server 这些是"再进一步" —— 有需要再加，没需要不要为了用而用。工具的价值在于它在你不在的时候替你工作，不在于"我用了多少种"。

参考资源：

• Claude Code 官方文档↗
• MCP 协议主页↗
• Anthropic Engineering: Claude Code Best Practices↗
• How Anthropic Teams Use Claude Code↗
• 我之前写的 给 Claude Code 接上 Mac 通知 + Bark 推送
• 我之前写的 CS146S 课程笔记 （其中 Week 3 / Week 4 跟本文重叠最多）

CS146S《The Modern Software Developer》↗ 是斯坦福 2025 秋季的新课，讲师 Mihail Eric，每周一位重磅客座（Boris Cherny、Zach Lloyd、Isaac Evans、Tomas Reimers……）。我把官方作业仓库↗ 里 8 周的内容捋了一遍，沿途做了实操。这篇是把 8 周的笔记整理。

1. 课程的真正主题：开发者身份的位移

课程主页那句标语挺直白：

“Many AI coding courses only teach you how to write fast — this course draws the baseline for shipping: testable, auditable, defensible.”

如果只看周次表，会以为这是一门 “AI 工具使用大全”。但读完 8 周的材料和作业，更准确的描述是：

它在系统地训练你成为 Agent Manager。

不是 “学会用 ChatGPT 写代码”，是从写代码的人变成指导 Agent 写代码、并且对结果负责的人。Boris Cherny（Claude Code 创造者）那句话被反复引用：

“It’s not so much about deep work, it’s about how good I am at context switching and jumping across multiple different contexts very quickly.”

8 周内容可以归到三条主线：

1. Prompt → Context（Week 1 → 3）：从写一句好提示，到搭一整套信息环境
2. Coder → Agent Manager（Week 2 → 5）：从亲手写代码，到指导/编排多个 Agent
3. Speed → Defensible（Week 6 → 8）：从快速产出，到可审计、可防御、可上线

下面按这三条主线展开。

2. 主线一：Prompt → Context

Week 1：6 种基础提示技巧

第一周用 Ollama 跑本地模型，挨个练 6 种技巧：K-shot、Chain-of-Thought、Tool Calling、Self-consistency、RAG、Reflexion。每个技巧一份 Python 文件，调到 test 通过为止。

练完最大的体感不是 “我学了 6 种技巧”，而是：这些技巧不是平行选项，是一条进化链。

• K-shot 给的是模式
• CoT 给的是推理空间
• Tool Calling 让模型不再"猜"，而是"查"
• Self-consistency 用多次采样换稳定性
• RAG 把外部知识接进上下文
• Reflexion 让模型审视自己的输出再迭代

到 Reflexion 这一步，模型已经从 “回答机器” 变成了 “能自我修正的小循环”。这就是 Agent 的雏形。

Week 2：第一次让 AI 跑通需求闭环

作业是一个最小的 FastAPI + SQLite 的 Action Item Extractor：自然语言笔记 → 结构化 todo 列表。要求用 Cursor 的 Agentic Mode 完成 5 个 TODO：用 LLM 替换规则提取、加单元测试、重构、加新端点+前端按钮、生成 README。

我在自己的实践笔记里总结了一个 “本地需求执行 Agent” 的最小能力模型：

需求理解 → 代码上下文获取 → 方案规划 → 代码生成 → 验证执行 → 结果反馈
    ↑                                                      |
    └──────────── 失败时回溯修正 ←───────────────────────┘

每一步都对应 Week 1 学过的某个技巧。Agent 不是新发明，是把那些原子能力按这个 loop 串起来。

跑完一遍最大的感受：当前的 AI Agent 真正擅长的是 “边界清晰、可验证” 的任务。脚手架代码、单函数实现、happy path 测试、文档生成 —— 这些是优势。判断"什么不该改"、跨模块副作用推理、涉及取舍的深层重构 —— 这些还得人来。

Week 3：从 Prompt Engineering 到 Context Engineering

第三周是整门课信息密度最高的一周（另一个高密度周是 Week 6）。客座 Boris Cherny。核心命题是 Andrej Karpathy 的那句定义：

“Context engineering is the delicate art and science of filling the context window with just the right information for the next step.”

里面最让我重新审视自己工作方式的两条：

“Context is King” — 甚至是 intelligence 的前提。 课程里那句很狠：“Claude 已经足够聪明 — 智能不是瓶颈，上下文才是。当 AI Agent 失败时，本能反应是 blame the model，但几乎总是错的。表现不好的是围绕它构建的信息环境。”

Context Rot（上下文腐烂）。 模型性能会随输入长度显著下降，即使是简单任务。所以 /clear、/compact、分层记忆、CLAUDE.md 精简，这些不是洁癖，是性能策略。

Week 3 的作业是写一个自定义 MCP Server。我做的是 GitHub Issue 助手，3 个 Tools（search_issues / create_issue / get_issue_detail）+ 1 个 Resource（仓库元数据）+ 1 个 Prompt（bug report 模板），STDIO 接 Claude Desktop。

亲手实现完才真的理解：MCP 的三大原语（Tools / Resources / Prompts）不是抽象概念，对应的是 Agent 三种不同的"知道方式" —— 能做什么、能查什么、该怎么说。

Boris Cherny 还分享了一套日常工作流：每天发 20-30 个 PR，靠的是同时跑 5 个 Claude Code 实例 + 5-10 个 claude.ai/code，每个实例都从 Plan Mode 起步，CLAUDE.md 当团队共享记忆。最被反复强调的一句：

“给 Claude 一种验证自己工作的方式 —— 浏览器测试、测试套件、模拟器。验证能让最终结果质量提升 2-3 倍。其他一切（subagent、slash command、MCP 集成）都建立在这个基础之上。”

3. 主线二：Coder → Agent Manager

Week 4：作为 Agent Manager 的 Claude Code

Week 4 的核心句：

“The goal is to train you as an Agent Manager — not someone who writes code, but someone who directs Agents to write code.”

这周整理了 5 种 agentic 工作流模式：

• Sequential Flow：默认模式，70% 的日常工作
• Operator：层级式，中央编排者 + 专门 sub-agent
• Split-and-Merge：fan-out/fan-in，最多 ~10 路并行
• Agent Teams：协作式，可互相通信，跨独立会话协调
• Headless：CI/CD、Cron、Webhook 触发，无人值守

以及 12 个 “Agent Harness 模式”（持久指令、目录级指令、分层记忆、记忆卫生、上下文压缩、并行分支、检查点审查、选择性工具加载、定制工具、权限粒度、生命周期钩子、复合改进）。

最戳我的一句：

“问题不在于你的模型，而在于你的 harness（控制框架）。区分酷炫 demo 和生产级 AI 系统的不是智能，而是控制。”

作业是用 Slash Commands、CLAUDE.md、SubAgents 给一个 FastAPI starter app 加至少 2 个自动化。这周开始我的肌肉记忆变了：遇到任何重复的工作流，先想 “这能不能塞进 .claude/commands/"；遇到 Claude 反复犯的错，先想 “这条该不该写进 CLAUDE.md”。

复合工程（Compounding Engineering）这个词我喜欢：每次 AI 犯的错被记下来，都是永久的红利。

Week 5：终端不再是高级用户的玩具

Week 5 客座是 Warp CEO Zach Lloyd。Warp 的 2.0 把自己从 “更好的终端” 重新定义为 ADE（Agentic Development Environment）。

这周的对照表对我比较有用：

它们其实是叠加关系：Claude Code 可以跑在 Warp 里。多 Agent 并行的关键工具是 git worktree —— 每个 Agent 在独立的工作目录里干活，互不污染，结束再合分支。这个技巧后面我的实际工作里也用上了。

但 Warp 团队也很坦诚：并行不是免费的。每周省 6-7 小时是真的，但前提是你的认知带宽能管得住 5 个 tab —— 这才是真正的 bottleneck。

4. 主线三：Speed → Defensible

Week 6：Semgrep 与 AI 代码安全

第六周邀请了 Semgrep CEO Isaac Evans。这周的开场数据让我停下来想了一下：

Claude Code 在安全扫描实验中发现了 46 个真实漏洞（真阳性率 14%，误报率 86%）。

这不是说 Claude 不行，是说 AI 的安全直觉不可靠 —— 7 条告警里只有 1 条真正是漏洞。Semgrep 的价值在于把这个比例反过来：减少 80% 误报，同时提升 250% 真阳性。

Semgrep 三件套：

• Code (SAST)：第一方代码漏洞，跨文件分析
• Supply Chain (SCA)：依赖中的可达漏洞（reachability analysis 把不可达的 CVE 过滤掉，高/严重级别误报降 98%）
• Secrets：硬编码密钥，含语义分析 + 熵分析 + 验证

作业是用 semgrep ci --subdir week6 扫描一个故意藏漏洞的 FastAPI app，挑 3 个修。修法朴素但本质：参数化 SQL、限制 CORS、密钥转环境变量、依赖升级、加密算法换强的、DOM 写入消毒。

这周收的最朴素的一句话：“Secure Vibe Coding” 的目标是让快和安全统一，不是对立 —— 靠的是把扫描自动化进 CI，而不是事后人工补救。

Week 7：Graphite Diamond 与 AI 代码审查

第七周客座是 Graphite CPO Tomas Reimers。命题是：

“AI will never replace human code review. But every PR should be reviewed by AI + human together.”

AI 审查的优势：风格一致性、常见 Bug 模式、安全漏洞、代码重复、100% PR 覆盖、秒级响应。 人类审查的优势：架构判断、业务逻辑正确性、tradeoff 评估、创造性建议、团队上下文、UX 设计。

最佳模式是 “AI First, Human Second”：AI 第一层过滤掉机械问题，人类第二层聚焦高价值判断。Graphite 团队的另一个产品创新是 Stacked PRs —— 把一个大 PR 拆成多个小的、顺序的 PR，因为 AI 审查在小 PR 上表现明显更好。

作业很扎实：4 个独立任务，每个都按"创建分支 → 1-shot AI prompt 实现 → 手动逐行审 → 开 PR → 用 Graphite Diamond 跑 AI 审查 → 对比"的流程做一遍，最后写一份反思 —— 你的审查 vs Graphite 的审查，谁更好、什么时候更好。

这种 “对比反思” 的训练我觉得是这周最珍贵的部分。它不是教你信任 AI，是教你知道 AI 什么时候比你强、什么时候不如你。这种元认知，在 AI 时代比任何具体工具都重要。

Week 8：Bolt.new 与多栈快速构建

第八周转向 “原型到生产” 主题。客座是 Vercel AI Research 负责人。核心句：

“Rapid prototyping is just the starting point. Between demo and production lies a chasm.”

Bolt.new 用 StackBlitz 的 WebContainer 技术做到完全在浏览器里跑 Node.js，从提示词直出全栈应用。但它的能力曲线很陡：

作业要求用 3 种不同技术栈构建同一个应用，至少一个用 Bolt、至少一个用非 JS 语言。这设计很狡猾 —— 它在偷偷训练你两个能力：

1. 抽象思维：把业务从框架里抽出来，理解什么是本质、什么是实现细节
2. AI 工具评估：同一个需求，让 Bolt 在 Next.js / Django / Rails 上分别生成，质量差异巨大 —— 你必须培养出 “什么是生产就绪代码” 的直觉

5. 三条收回来能用的实操结论

读完 8 周的内容，做完几个作业，我自己往日常工作里搬的就是这三条：

5.1 Plan Mode 是免费的红利

Boris 那句 “在审查和批准书面计划之前，永远不要让 Claude 写代码” —— 这是 8 周里被引用最多的一条。我现在做任何超过 30 分钟的任务都先 shift+tab 进 Plan Mode，跟 Claude 来回讨论清楚再切到 auto-accept。返工率明显下降。

5.2 CLAUDE.md 是复合改进的载体

每次 Claude 犯错或者我发现一个不显然的项目约定，都往 CLAUDE.md 里加一条。这个习惯非常便宜、非常划算：每条加了之后就再也不用解释第二次。但要保持精简 —— 它每次会话都加载，吃上下文。

5.3 给 Agent 一种验证自己的方式

这是 Boris 的"最重要的洞见”。具体到我自己的实践：

• 写后端：让 Claude 跑测试，失败再改，不要"看起来对就提交"
• 写前端：起 dev server，让 Claude 用 Playwright 实际点一遍 golden path
• 写 API 集成：先有一个 curl 或 httpie 的最小复现脚本

这个习惯本身就是 Reflexion 模式（Week 1 学过的）的工程化版本 —— 把"自我审视"内置到工作流里。

6. 收尾：8 周完整弧线

Week 1:  如何与 AI 对话           → Prompt Engineering
Week 2:  AI 如何使用工具          → Coding Agents & MCP
Week 3:  如何为 AI 构建信息环境   → Context Engineering
Week 4:  如何管理 AI              → Agent Manager
Week 5:  AI 增强的终端            → AI Terminal
Week 6:  AI 代码安全              → Semgrep
Week 7:  AI 代码审查              → Graphite Diamond
Week 8:  AI 构建应用              → Bolt.new 多栈
(Week 9-10:  AI 运维 + 未来       → 课程后半段)

每一周都是下一周的基础。最后留下的不是一堆工具的使用说明，是一种新的工作姿态：

你不再是写代码的人，你是设计信息环境、指导 Agent、并且对最终交付物负责的人。

写代码的速度提升了 10 倍，但写错代码的速度也提升了 10 倍。课程划的那条 baseline —— 可测试、可审计、可防御 —— 不是束缚，是这个新姿态能站住脚的前提。

参考资源：

• 课程主页：themodernsoftware.dev↗
• 作业仓库：mihail911/modern-software-dev-assignments↗
• 中文版社区整理：ShouZhengAI/CS146S_CN↗
• Claude Code 最佳实践：anthropic.com/engineering/claude-code-best-practices↗
• 12 Agentic Harness Patterns：generativeprogrammer.com↗
• How Anthropic Teams Use Claude Code：claude.com/blog↗
• Andrej Karpathy on Context Engineering（X 原帖）
• Boris Cherny 工作流：howborisusesclaudecode.com↗

起因：在 GitHub 上看到一份 Windows 下给 Claude Code 加系统通知的 gist↗ ，PowerShell 写的，落地 Mac 用不了。索性重写一份 macOS 版，再顺手加一条 Bark↗ 推送 —— 长任务跑起来人离开屏幕，手机也能响。

1. 思路

Claude Code 的 hook 系统暴露一组生命周期事件，对"被通知"的需求，只需要两个：

• Stop —— 模型当前回合结束。任务跑完该响一声。
• Notification —— 模型需要确认/输入（permission prompt、问题等）。这种更紧急。

Hook 命令的 stdin 会拿到一份 JSON：cwd（项目路径）、transcript_path（JSONL 全量对话）、Notification 事件还会带 message。

设计取舍：

• 单文件 Python —— macOS 自带 python3，不再依赖 jq、curl 的 JSON 转义脏活。
• 本地通知优先 terminal-notifier —— 装了就用（可点击、有 group 去重），没装回落 osascript，零依赖。
• Bark 是可选项 —— 只有当 BARK_KEY 环境变量存在才推。失败静默，不影响 hook 退出码。
• 不 chmod —— 原因见末尾"坑"那节。脚本不可执行，靠 python3 path/to/notify.py 调用。

2. 脚本：~/.claude/hooks/notify.py

#!/usr/bin/env python3
"""Claude Code notification hook for macOS.

Local toast (osascript or terminal-notifier) + optional Bark push.

Usage: notify.py <Stop|Notification|...>

Reads JSON from stdin (Claude Code hook payload):
  cwd               -> current working directory
  transcript_path   -> path to JSONL transcript (Stop event)
  message           -> notification message (Notification event)

Environment variables (all optional):
  BARK_KEY            Bark device key. If unset, Bark push is skipped.
  BARK_SERVER         Bark server (default: https://api.day.app).
  BARK_GROUP          Notification group (default: ClaudeCode).
  BARK_SOUND          Notification sound (default: minuet).
  BARK_ICON           Custom icon URL.
  BARK_STOP_LEVEL     Level for Stop events (default: passive).
  BARK_NOTIFY_LEVEL   Level for Notification events (default: timeSensitive).
                      Valid: active | timeSensitive | passive | critical.
  CLAUDE_NOTIFY_OFF   If set to "1", suppress all notifications.
"""
from __future__ import annotations

import json
import os
import shutil
import subprocess
import sys
import urllib.request
from pathlib import Path

TITLE_PREFIX = "ClaudeCode"
MAX_BODY_LEN = 200


def read_stdin_json() -> dict:
    try:
        raw = sys.stdin.read()
    except Exception:
        return {}
    if not raw.strip():
        return {}
    try:
        return json.loads(raw)
    except Exception:
        return {}


def last_assistant_text(transcript_path: str) -> str:
    p = Path(transcript_path)
    if not p.is_file():
        return ""
    try:
        with p.open("r", encoding="utf-8", errors="replace") as f:
            lines = f.readlines()[-30:]
    except Exception:
        return ""
    for line in reversed(lines):
        try:
            entry = json.loads(line)
        except Exception:
            continue
        msg = entry.get("message") or {}
        if msg.get("role") != "assistant":
            continue
        content = msg.get("content")
        text = ""
        if isinstance(content, str):
            text = content
        elif isinstance(content, list):
            for block in content:
                if isinstance(block, dict) and block.get("type") == "text":
                    t = block.get("text", "")
                    if t.strip():
                        text = t
                        break
        if text.strip():
            return text
    return ""


def truncate(s: str, n: int) -> str:
    s = (s or "").strip()
    if len(s) <= n:
        return s
    return s[: n - 1] + "…"


def send_mac_notification(title: str, body: str) -> None:
    tn = shutil.which("terminal-notifier")
    if tn:
        try:
            subprocess.run(
                [tn, "-title", title, "-message", body,
                 "-sound", "Glass", "-group", "claude-code", "-ignoreDnD"],
                check=False, timeout=5,
                stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL,
            )
            return
        except Exception:
            pass

    def esc(s: str) -> str:
        return s.replace("\\", "\\\\").replace('"', '\\"')

    script = (
        f'display notification "{esc(body)}" '
        f'with title "{esc(title)}" sound name "Glass"'
    )
    try:
        subprocess.run(
            ["osascript", "-e", script],
            check=False, timeout=5,
            stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL,
        )
    except Exception:
        pass


def send_bark_push(title: str, body: str, event: str) -> None:
    key = os.environ.get("BARK_KEY", "").strip()
    if not key:
        return

    server = os.environ.get("BARK_SERVER", "https://api.day.app").rstrip("/")

    if event == "Notification":
        level = os.environ.get("BARK_NOTIFY_LEVEL", "timeSensitive")
    elif event == "Stop":
        level = os.environ.get("BARK_STOP_LEVEL", "passive")
    else:
        level = "active"

    payload = {
        "title": title,
        "body": body or " ",
        "group": os.environ.get("BARK_GROUP", "ClaudeCode"),
        "level": level,
        "sound": os.environ.get("BARK_SOUND", "minuet"),
    }
    if icon := os.environ.get("BARK_ICON", "").strip():
        payload["icon"] = icon

    try:
        req = urllib.request.Request(
            f"{server}/{key}",
            data=json.dumps(payload, ensure_ascii=False).encode("utf-8"),
            method="POST",
            headers={"Content-Type": "application/json; charset=utf-8"},
        )
        with urllib.request.urlopen(req, timeout=5) as r:
            r.read()
    except Exception:
        pass


def main() -> int:
    if os.environ.get("CLAUDE_NOTIFY_OFF") == "1":
        return 0

    event = sys.argv[1] if len(sys.argv) > 1 else "Stop"
    data = read_stdin_json()

    cwd = data.get("cwd") or ""
    project = os.path.basename(cwd) if cwd else ""

    if event == "Stop":
        title = f"{TITLE_PREFIX} - {project}" if project else TITLE_PREFIX
        body = ""
        transcript = data.get("transcript_path") or ""
        if transcript:
            body = last_assistant_text(transcript)
        if not body.strip():
            body = "Task completed, please review results."
    elif event == "Notification":
        title = f"{TITLE_PREFIX} - Needs Attention"
        if project:
            title = f"{title} - {project}"
        body = (data.get("message") or "").strip() \
            or "Claude is waiting for your input or approval."
    else:
        title = TITLE_PREFIX
        body = f"Event received: {event}"

    body = truncate(body, MAX_BODY_LEN)

    send_mac_notification(title, body)
    send_bark_push(title, body, event)
    return 0


if __name__ == "__main__":
    sys.exit(main())

几个细节值得一提：

• 抓 transcript 倒数往前找 —— 只读最后 30 行 JSONL，倒序遍历，第一条 role == "assistant" 且非空文本就用。content 字段在不同 SDK 版本下可能是 string 也可能是 array，两种都处理。
• truncate 用 … 单字符 —— 而不是 ... 三个 ASCII 句号，省 2 字节给正文。
• Bark level 分场景 —— Stop 默认 passive（不打扰，只入推送列表），Notification 默认 timeSensitive（穿透专注模式）。等长任务跑完手机不必尖叫，但要确认时必须能听见。
• 失败静默 —— Bark 推不上、osascript 报错、transcript 读不到，全部吃异常返回。Hook 不应该把模型卡死。

3. 接入 ~/.claude/settings.json

把下面这块合进 settings.json，保留你原有的 env / permissions / enabledPlugins 等字段：

{
  "hooks": {
    "Notification": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "python3 /Users/you/.claude/hooks/notify.py Notification",
            "timeout": 15
          }
        ]
      }
    ],
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "python3 /Users/you/.claude/hooks/notify.py Stop",
            "timeout": 15
          }
        ]
      }
    ]
  }
}

matcher: "" 是匹配所有 —— Stop / Notification 这两个事件本来也没有 sub-matcher 概念。timeout: 15 秒兜底，超时不影响主流程。

4. 启用 Bark

Bark 是 iOS 上一个挺老的推送工具，免费版 key 在 day.app↗ 拿。装好 app，主页能看到一段类似 https://api.day.app/abc123xyz/ 的链接 —— 中间那段就是设备 key。

把它加到 settings.json 的 env 块（hook 进程会继承）：

"env": {
  "BARK_KEY": "abc123xyz"
}

可选环境变量速查：

5. 验证

设好 BARK_KEY 后，手动跑一发 Notification 模拟：

BARK_KEY=你的key echo '{"cwd":"/tmp","message":"test"}' \
  | python3 ~/.claude/hooks/notify.py Notification

正常情况下：

1. 桌面右上角弹一条 macOS 通知
2. 手机 Bark 通知到达，分组是 ClaudeCode，级别是 timeSensitive

如果只想看本地通知不打扰手机，把 BARK_KEY 临时去掉就行。

6. 几个坑

hook 不生效？ Claude Code 的 settings watcher 只盯着会话启动时已经存在的目录。如果 .claude/ 是会话开始后才创建的，settings 修改可能不会被 reload。打开一次 /hooks 菜单（会强制 reload），或者重启 Claude Code session。

chmod 被 deny 怎么办？ 我的 settings 里 permissions.deny 包含 Bash(chmod:*)，所以脚本不能 chmod +x。解法是 hook command 直接用 python3 path/to/notify.py 调用，不依赖文件可执行位 —— 反而更显式，少一处隐式状态。

通知正文太长？ 脚本里 MAX_BODY_LEN = 200，截到 199 字符 + …。macOS 通知中心本身也会截断，但提前截能避免在 Bark 上看到一串 JSON 转义崩溃的字符。

想再省一点？ Stop 事件每回合都触发，会很吵。两个解法：

• 在 Bark 那条线把 BARK_STOP_LEVEL 已经设成 passive —— 只入推送列表，不响。
• 想本地也不响：在 send_mac_notification 里检查 event == "Stop" 时不发 osascript 就行（5 行改动）。

7. 可拓展方向

留给以后自己折腾：

• Telegram / Lark / Slack —— 把 send_bark_push 改名 send_remote_push，按 REMOTE_KIND 环境变量分发。Bark 只是其中一种。
• 细化 Notification 文案 —— 当前直接拿模型给的 message。可以判断 tool_name（如果将来 hook payload 加进来）做更精准的标题。
• 聚合连发 —— 短时间内多次 Stop 合并成一条（debounce 5s）。当前每次都响。
• 统计 —— 把每次 hook 触发记一行到 ~/.claude/hooks/notify.log，看一周下来跑了多少回合、几次需要确认。这些数据其实挺有意思。

整套配置改一次就一直在了。每次模型响完 / 卡住等输入，桌面右上角"叮"一声，手机口袋里也跟着震一下 —— 长任务跑起来终于可以放心去倒杯水。