超越提示词：把 Claude Code 当成可编程 Agent 来用

我曾经在一次重构上耗掉四十分钟，而 claude 本可以四分钟就交付——差距不在模型，而在它周围的一切。随手用的人只会敲提示词、接受第一个建议，把 claude 当成花哨一点的自动补全。而我把它当成一个可编程的 Agent 来跑：持久记忆、自定义命令、跨 worktree 并行启动的多个会话，以及一套每周打磨都会更锋利的项目结构。这篇指南默认你已经在终端里敲过 claude、见过它能干什么。我们要走得更远。

接下来是有意思的部分。

1. 越过基础：把 Claude Code 当 Agent 用

别再把 Claude Code 当成"问一句、等一句"的聊天机器人。把它当成一个需要护栏的自主 Agent，你整个工作流就变了。Boris Cherny 和 Anthropic 团队的核心原则很简单：给 Claude 一个能验证自己工作的方式。没有这个反馈回路，你就是唯一的反馈信号；有了它，Claude 会一直迭代到代码真的能跑起来。Boris 把这一招单独拎出来，说它能带来 2–3 倍的质量提升。

几个会改变你日常操作方式的模式：

先探索，再规划，最后写代码。连按两次 Shift+Tab 进入 plan 模式（只读）。让 Claude 读文件、追踪流程、梳理数据模型，拿回一份计划，然后再执行。小修小改可以跳过规划；但只要改动牵涉到多个文件，第一时间就进 plan 模式。

把 plan 模式当成设计文档。让一个 Claude 写计划，再开一个全新会话的第二个 Claude，让它以"资深工程师"的身份去评审这份计划——没有上下文偏见，才能真正挑出漏洞。如果实现跑偏了，回到 plan 模式，把验证步骤直接写进去重新规划。

引用，而不是描述。别说"看一下 auth 模块"，直接敲 @src/auth/login.py。别粘贴报错，用管道喂进去：cat error.log | claude。精确的上下文每一次都胜过模糊的描述。

委派，而不是结对编程。Claude Code 团队的 Cat Wu 说得很直白：“把模型当成一个你正在委派任务的工程师，而不是一个你逐行指导的结对搭档，它的表现才最好。“前期写一份清晰的任务说明，然后让它跑。

小技巧：按 Ctrl+G 在编辑器里打开 Claude 的计划，在它继续之前先改一改。计划只是文本，趁它还没变成代码之前先塑形。

小技巧：Claude 犯错时，在提示词末尾加一句"更新 CLAUDE.md，以后别再犯”。Boris 说 Claude “出奇地擅长从自己的失败里给自己写规则”。注意：这个习惯的复利效应，比本文任何其他东西都强。

2. 正确理解 .claude 目录

大多数人打开 .claude/，看到 CLAUDE.md，就走了。底下其实是一套分层的配置系统。

两种作用域。项目作用域在仓库内的 .claude/，提交进 git，团队共享；全局作用域在 ~/.claude/，跟着你这台机器上的每一个项目走。

心智模型：项目文件描述项目，全局文件描述你。

一个典型的目录布局：

my-repo/
├── .claude/
│   ├── settings.json
│   ├── agents/
│   │   ├── pr-review.md
│   │   └── test-writer.md
│   ├── skills/
│   │   └── api-conventions/SKILL.md
│   └── rules/
│       ├── frontend.md        # 按路径门控到 src/frontend/
│       └── migrations.md      # 按路径门控到 db/migrations/
├── CLAUDE.md                  # 提交进 git，团队共享
├── CLAUDE.local.md            # gitignore，个人专属
└── .mcp.json                  # 团队共享的 MCP server

几个容易漏掉的点：

• CLAUDE.md 是级联加载的。在 monorepo 里，当你在 billing 服务下工作时，root/CLAUDE.md 和 root/services/billing/CLAUDE.md 都会加载。各目录约定不同时非常好用。

• rules/*.md 是按路径门控的。只针对 migrations 目录的指引，不该通过 CLAUDE.md 塞进每一次会话——它应该放进 .claude/rules/migrations.md，配一个 glob。

• Skills 比 commands 强。.claude/commands/*.md 和 .claude/skills/<name>/SKILL.md 都能注册斜杠命令，但 skill 能携带配套文件、disable-model-invocation、允许的工具、agent 覆盖。我去年把一堆仓库自动化做成了零散的 commands/*.md，后来需要配套文件时不得不全部移植到 skills/。新东西都放 skills/。

• CLAUDE.md 和 CLAUDE.local.md 在会话开头就一起加载，两者都占上下文。收集内存时 Claude 会沿目录树向上递归，把沿途每一层的 CLAUDE.md / CLAUDE.local.md 都收进来；冲突时，越具体、越靠近你当前工作目录的那条越被采纳——但这不是"覆盖删除”，它们始终同时在上下文里，模型是在读到多条指令后做权衡。这也正是要严格控制这几份文件总长度的原因：每次会话开局就先吃掉一截预算。

小技巧：运行 claude project purge ~/path/to/repo --dry-run，能看到 Claude 为某个项目保存了哪些本地状态——交接电脑前很有用。

3. CLAUDE.md：Boris 写它的方式

CLAUDE.md 在每次会话开始时加载。写错了，Claude 一次次踩同一个耙子；写对了，同样的提示词忽然产出你真敢上线的结果。

在这件事上 Boris 只在乎两点，搞定这两点其余都是噪声。我花了一个月写越来越精巧的上下文文件，最后又绕回他的框架——而那些精巧版本在每一个可衡量的维度上都更差。

保持简短。长文件会把真正重要的规则埋掉。每写一行，都过一遍 Boris 的过滤器问自己：“删掉这行会不会导致 Claude 犯错？“如果答案是否，就删。要狠。这个文件不是知识库，是护栏。

让 Claude 给自己写规则。每次 Claude 做错了什么，就让它"更新 CLAUDE.md，以后别再犯”。Claude 出奇地擅长把自己的错误提炼成精确的规则。坚持几周，这个文件就变成了你项目里所有坑的精选清单——用的还是模型最吃的那种措辞。你不再需要猜该往里面写什么，因为模型自己会告诉你。

3.1 Claude Code 团队真实的 CLAUDE.md

在一次分享里，Boris 展示了 Claude Code 团队提交进自己仓库的真实 CLAUDE.md。整个团队每周都会往里贡献好几次。

# 开发工作流

**始终用 `bun`，不要用 `npm`。**

# 1. 改动代码

# 2. 类型检查（快）

bun run typecheck

# 3. 跑测试

bun run test -- -t "test name"   # 单个 suite
bun run test:file -- "glob"      # 指定文件

# 4. 提交前 lint

bun run lint:file -- "file1.ts"
bun run lint

# 5. 创建 PR 之前

bun run lint:claude && bun run test

再读一遍：Claude 猜不出来的构建命令、运行的确切顺序、单测的调用方式、建 PR 前的固定仪式。没有风格偏好、没有代码库导览、没有空话。

Boris 还会在 PR 评论里用 @claude 让 Claude 直接提交一条规则：

nit: 用字符串字面量，别用 ts enum
@claude 加进 CLAUDE.md：永远不用 enum，始终优先用字面量联合类型

他把这叫做"复利工程”（Compounding Engineering）——每一次 PR 评审都变成一次 CLAUDE.md 的改进。评审者只需抓住一次错误，Claude 就再也不会重犯。

下面是一份遵循同样哲学、内容更完整的模板：

# 代码风格

- 用 ES module（import/export），不用 CommonJS（require）

# 工作流

- 始终用 `bun`，不用 `npm`
- 声称"完成"之前先跑 `bun run typecheck`
- 永远不要直接 push 到 main，始终开 PR

# 架构

- 所有 API 路由都走 src/api/middleware/auth.ts
- 新的数据库查询放进 src/db/queries/，不要内联裸 SQL

# 坑（Gotchas）

- `User` 和 `UserRecord` 是不同的类型。UserRecord 是数据库行，User 是运行时对象。
- `formatCurrency` 默认 USD。国际化场景用 `formatCurrencyByLocale`。

注意那个"坑"小节。里面的每一条都源自 Claude 在真实 PR 上犯过的真实错误，在它发生的那一刻被记下来。当你意识到模型刚刚把 USD 格式甩给了一个法国用户时那种下沉的感觉？写下来一次，它就再也不会发生。

CLAUDE.md 里不要写这些：标准语言约定、逐文件的代码库描述、长篇教程、API 文档、任何频繁变动的东西。

小技巧：IMPORTANT 或 YOU MUST 这类词能提高遵守度，但要省着用，才有分量。

你可以用 @path 语法导入其他文件，让 CLAUDE.md 保持简短、按需拉取细节：

项目概览见 @README.md，脚本见 @package.json。
@~/.claude/my-preferences.md

文件短，回报大。保持精炼。

3.2 值得研究的几份公开 CLAUDE.md

直接抄那些已经做好功课的人。下面这四份是我反复回看的：

• mattpocock/skills 的 CLAUDE.md：关于 skill 应该如何编写和测试的约定
• anthropics/claude-code-action：Anthropic 自己的仓库，把它当内部工具一样对待
• awesome-claude-code：汇集了跨语言生态的几十份公开 CLAUDE.md
• claudelog.com：按技术栈整理的社区精选示例

先读三份，再写你自己的。

4. 把 CLAUDE.local.md 用成日常驱动

CLAUDE.local.md 紧挨着 CLAUDE.md，以同样的方式加载，但永远不离开我的机器——直接进 .gitignore。

我是这么用的：每次 PR 之后，评审者会留下评论。与其在脑子里硬记，我读到的那一秒就把它们粘进 CLAUDE.local.md。几周下来，它就变成了一份针对"我反复收到的反馈"调校过的个人规则文件。

# 个人评审笔记（私有）

# 来自 PR 反馈

- 新的 SQS consumer 需要在同一个 PR 里带上 DLQ 和告警
- 用 `Optional<T>` 而不是返回 null
- 新接口的测试必须包含鉴权失败的用例
- 返回类型有 3 个以上字段时，优先用 named tuple 而不是普通 dict

# 我自己要改的毛病

- 别再用 `console.log`，改用项目的 logger
- 加接口时永远记得同步更新 OpenAPI spec

每次会话都加载。现在 Claude 会主动带上鉴权失败的测试、主动更新 OpenAPI spec，不用我开口。两周内我 PR 上的吹毛求疵评论明显变少了。

小技巧：把两个小节清晰分开——项目相关反馈，和个人要改的习惯。混在一起以后很难精简。

小技巧：几周后做一次精简。已经变成肌肉记忆的可以删掉。这个文件应该捕捉还在变动中的东西；已经自动驾驶的部分可以走了。

译注：原文把 CLAUDE.local.md 当成日常主力来推荐，这是作者的个人实践，确实能用。但要补一句：较新的 Claude Code 已经弱化了这种写法，更推荐用 @path import（在 CLAUDE.md 里写 @~/.claude/my-preferences.md 这类）或直接放进用户级 ~/.claude/CLAUDE.md 来管理个人偏好。原因之一是 .local.md 只对单一目录生效，在 monorepo 多包场景里行为容易让人困惑。两种方式都在会话开头加载、都占上下文，区别在作用域和可维护性——按你的项目结构选一种即可。

5. 深入 Skills

Skills 是把 Claude Code 从"能干任何事的 Agent"变成"按你们团队的方式、专门干你项目真正需要的那三件事的 Agent"的方式。它是可复用专业能力的单元——写过一两个之后，你会一直回头用它。

5.1 Skill 到底是什么

上周二我需要 Claude 每次都用同样的方式总结我未提交的 diff，于是我往 ~/.claude/skills/ 丢了一个文件夹，然后就不管了。那个文件夹就是 skill。里面住着一个带 frontmatter 和指令的 SKILL.md，而文件夹名本身就变成你在提示框里敲的斜杠命令。项目级的放在 .claude/skills/<name>/ 下，全局的放在 ~/.claude/skills/<name>/ 下。

下面是能站住脚的最小版本：

---
description: 总结未提交的改动并标出任何风险。当用户问"改了什么"、想要 commit message、或要求评审 diff 时使用。
---

## 当前改动

!`git diff HEAD`

## 指令

用两三条 bullet 总结改动，然后列出任何风险：缺失的错误处理、硬编码的值、需要更新的测试。

把它存到 ~/.claude/skills/summarize-changes/SKILL.md，之后你打开的每一个会话里 /summarize-changes 都会出现。

让 Skills 强大的三点：

• 渐进披露。会话开始时 Claude 只读 frontmatter 里的 description，每个大约 100 token。完整的 SKILL.md 和任何辅助文件，要等到这个 skill 真正触发时才拉进来。
• 每个 skill 自成一个文件夹，所以你可以在 SKILL.md 旁边放一个 templates/ 目录、塞参考文档、把脚本放在同一棵树里。SKILL.md 只是你交给 Claude 的入口。
• 内联 shell。任何以 ! 开头的行，会在调用时运行该命令，并把输出直接拼进提示词。

frontmatter 本身带不少可选旋钮：

---
name: my-skill
description: 何时使用这个 skill
disable-model-invocation: true  # 只有用户显式敲 /my-skill 时才运行
allowed-tools: Read, Grep, Bash
agent: read-only
---

小技巧：对有副作用的 skill 用 disable-model-invocation: true。你希望 /ship 只在显式敲入时才部署，而不是 Claude 觉得"相关"时就执行。

配置一次，永远忘掉它。

5.2 写一个真实的 Skill：Go API 约定

下面是给一个 Go 服务团队的完整 skill。它带上了约定、坑，以及一个全新 HTTP handler 的脚手架。

.claude/skills/go-handler/
├── SKILL.md
├── templates/
│   └── handler.go.tmpl
└── examples/
    └── healthz.go

---
description: 按团队在路由、校验、错误处理和测试上的约定，脚手架一个新的 HTTP handler。当用户要求新增接口、新增 handler 或扩展现有路由组时使用。
---

# Go HTTP Handler Skill

## 技术栈

- Go 1.22，chi router
- 用 sqlc 做类型化查询，handler 里永远不写裸 SQL 字符串
- 用 zap 做结构化日志，永远不用 fmt.Println
- 用 testify 做断言，优先表驱动测试

## 坑（Gotchas）

- `chi.URLParam` 在参数缺失时返回 `""` 而不是 error，必须自己检查。
- 我们的 `httperr.Wrap` 不打日志。返回前用 `h.log.Error` 单独打。
- 鉴权中间件通过 `context.Value(authkey.User)` 注入。要类型断言成 `*models.User`。
- sqlc 的可空字符串用 `pgtype.Text`。调用 `.String` 前先检查 `.Valid`。
- 测试必须用 `httptest.NewRecorder` 和 `httptest.NewRequest`，不要起真实 server。

注意这里发生了什么：一个新人第一天就能交付一个完全符合约定的接口，而不必先在代码库里东挖西刨。

5.3 值得安装的热门 Skills

mattpocock/skills 是最热门的 skills 仓库，大约 10 万 star。我常驻几个：

• /grill-me：在写任何代码之前，先就你的计划对你"拷问"一番
• /tdd：严格执行红-绿-重构
• /diagnose：有纪律的调试——复现、最小化、提假设、修、加回归测试

安装：npx skills@latest add mattpocock/skills。

Jeffallan/claude-skills 提供 66 个语言特定的 profile，比如 go-pro、python-pro、java-architect、typescript-pro、rust-engineer、sql-pro 等。你可以组合它们——一个 Next.js 任务会把 nextjs-developer 和 typescript-pro 一起拉进来。

Anthropic 官方的 skills：

• /code-review：四个并行 agent 审计 diff，只给带置信度评分的发现
• /simplify：评审近期代码的复用性和效率
• /batch：把一次迁移扇出给几十个并行 agent，每个都隔离在自己的 worktree 里
• /webapp-testing：给 Claude Playwright 控制权来测试你本地的 web 应用

我以前每周要把同样的提示词写三遍，直到这一点开窍。

小技巧：如果一件事你一天做不止一次，就把它做成 skill。任何你在重复的东西，都是一个等着被写出来的 skill。

小技巧：把 skill 提交进 git。它们会变成团队的制度性知识——新人 clone 仓库，就免费拿到团队积累的全部实践。

6. 构建自定义 Subagent

开一个 subagent，它能啃过五十个文件而不撑爆你的主会话，最后交回一份干净的总结。隔离的上下文、限定作用域的工具权限、独立的爆炸半径。我是在眼睁睁看着一次调试会话为了在 monorepo 里追 import 而烧光上下文预算之后，才开始动不动就用它的——现在它是我的默认选择。

往 .claude/agents/ 丢一个 markdown 文件就是项目级，丢 ~/.claude/agents/ 就是全局可用。frontmatter 声明 name、description、tools、model。五行，一份完整契约。

6.1 走一遍 /pr-review agent

上周五我差点把一个漏了空指针检查的 PR 推出去——就是那时候我建了这个 agent。

---
name: pr-review
description: 把当前分支的 diff 对照 main 评审，找 bug、安全问题、漏掉的边界情况和违反项目约定之处。开 PR 前主动使用。
tools: Read, Grep, Glob, Bash
model: opus
---

你是一位资深 staff 工程师，正在评审一个 pull request。要彻底、直接，目标是在人类评审者之前抓住问题。

## 流程

1. 运行 `git diff main...HEAD`
2. 运行 `git log main..HEAD --oneline`
3. 读完整文件，不要只看 diff 上下文
4. 对照 CLAUDE.md、CLAUDE.local.md 和 .claude/rules/ 交叉核对

## 要标出

- 正确性 bug：off-by-one、空值处理、错误路径、竞态条件
- 安全：注入风险、缺失的鉴权检查、代码里的密钥
- 新逻辑缺失测试
- N+1 查询
- 违反 CLAUDE.md 或 rules/ 的约定

## 不要标出

- 不在项目规则里的风格偏好
- 对能正常工作的代码提重构建议
- 任何超出本次 diff 的东西

## 输出

按严重程度分组（Critical / High / Medium / Low）。文件 + 行号 + 问题 + 建议修法。
结尾给一个裁决：**SHIP**、**FIX FIRST** 或 **REWORK**。

我在会话里敲一句 让 pr-review agent 看一下我当前的分支 来触发它。subagent 在隔离的上下文里干活，我的主会话不会被评审的碎碎念塞满。

几个值得指出的选择：tools 列表故意是只读的——一个能改代码的评审者，会开始为自己的修法找理由，而不是把问题标出来。我选 model: opus，因为"在人类评审者之前抓到一个安全 bug"值这个成本。顺带一提，“不要标出"那一节才是让输出真正可用的关键——没有它，我会被关于变量命名的吹毛求疵淹没。

十分钟建好，已经救了我两次。

6.2 值得借鉴的热门 Subagent

直接来自 Claude Code 团队自己的工作流，你会看到 build-validator、code-architect、code-simplifier、oncall-guide 和 verify-app 每天都在跑。

下面是社区一直在反复用的：

想要精选合集，VoltAgent/awesome-claude-code-subagents 提供了 100 多个 agent，hesreallyhim/a-list-of-claude-code-agents 也整理了一套靠谱的。

小技巧：把 agent 串起来：会话 A 实现，然后调用 用 code-reviewer subagent 检查这份工作。评审者在全新上下文里评估，没有实现时的偏见。

小技巧：在 frontmatter 里加 isolation: worktree，让 subagent 在自己的 git worktree 里运行——在把一次迁移扇出给几十个并行 agent 时尤其强大。

今天就把这些模式偷过来，明天你会想不通自己当初是怎么不靠它们交付的。

7. Plugin 与市场

Plugin 把 skills、hooks、subagent 和 MCP server 打包成一个可安装的单元。运行 /plugin 打开市场浏览器，用 /plugin marketplace add owner/repo 添加社区市场。

第一天就该装的：

/code-review 并行启动四个 agent。两个检查 CLAUDE.md 合规性，一个找 bug，一个读 git blame 拿上下文。输出带置信度评分。信号高，噪声低。

/feature-dev 是官方市场上安装量最高的 skill。给它一份功能说明，拿回可用代码。七个阶段：需求、探索、架构、实现、测试、评审、文档。

Language server 插件把符号级导航和编辑时诊断直接接进你的会话。团队一直把它列为你能装的杠杆最高的插件。

/security-guidance 是 Anthropic 官方的安全 skill，在问题上线之前把它们浮出来。

值得知道的插件类别（截至 2026 年中，75+ 个市场里有 1000+ 插件）：Git 工作流、代码情报（LSP）、文档生成器、测试、浏览器自动化（Playwright）、设计系统（Figma）、可观测性（Sentry、Datadog）。

小技巧：一份团队共享的 .mcp.json 加上几个精选插件，能让新工程师在 clone 仓库后几分钟内就进入生产状态。把插件选型当成你 onboarding 故事的一部分。

8. 被低估的 Claude Code 命令

大多数人学会 /clear、/compact 和 /init 就停了。命令面剩下的部分才是真正藏着生产力的地方，而几乎没人碰。

挑两个我每天都用的深入说说：

/compact vs /clear：如果你要开始的是一个真正全新的任务，按 /clear 然后手写一份新的说明。如果下一个任务还要倚靠你刚才做的东西，运行 /compact 并带上"什么该保留"的提示。/compact 是会话的有损 LLM 摘要；/clear 是你自己刻意写下的说明。我把这两个搞混了好几周，还纳闷为什么会话总在漂移。一旦这个区别开窍，我的上下文能连着几个小时保持干净。

/rewind 在每一个提示处都丢下一个检查点，而且这些检查点跨会话保留。所以当 Claude 走上一条错路时，忍住别敲"那个没用，试试 X”。这么敲只会把这次糟糕的尝试埋进你的上下文，模型会一遍遍被它绊倒。回退到错误之前，再带上你从它失败里学到的东西重新提示。你的上下文窗口会感谢你。

小技巧：用 ! 作为 shell 转义。!git status 或 !npm test 会立即运行，输出落进上下文。

小技巧：设置 CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000。在 1M 上下文的模型上，上下文腐化（context rot）大约在 30 万–40 万 token 时开始，所以强制提前压缩以保持锋利。

扇出（fan-out）模式：先写任务清单，再循环它。上个季度我就是这样迁移了大约两千个组件文件。生成清单，手动验证其中三个，把提示词收紧到这三个都干净返回，然后趁你去倒咖啡时把它放出去跑剩下的。

for file in $(cat files.txt); do
  claude -p "把 $file 从 React 迁移到 Vue，返回 OK 或 FAIL。" \
    --allowedTools "Edit,Bash(git commit *)" \
    --bare
done

8.1 /goal：内置的 Ralph 循环

上周二我敲了一行字，合上笔记本，吃了顿晚饭，回来时是一个绿色的 PR。/goal 设定一个完成条件，Claude 会一直磨到这个条件成立。它每一次想停下来，都会触发一次对会话记录的检查。

/goal test/auth 下所有测试通过且 lint 步骤干净

真实例子：

/goal tests/api 下所有集成测试连续 3 次运行不抖动地通过
/goal OpenAPI spec 校验通过且与实际响应结构一致
/goal docker compose up 干净运行且 healthcheck 端点返回 200
/goal src/billing/ 的覆盖率高于 80% 且所有新测试都不是占位

挑一个可验证、确定性的目标。把它绑到一个测试命令、一个 CLI 退出码，或某个你能 grep 出来的文件状态上。写"代码很好"——你已经输了。

配套搭得好的：

• /loop：按间隔重复，烧掉积压
• /schedule：在云端按节奏运行
• 一个 Stop hook：用你自己的测试套件或 CI 端点来门控
• 自动模式：去掉权限提示，让长目标不会卡住

小技巧：组合 /goal + 自动模式 + /focus。写一份清晰的说明，设好目标，走开。回来时是一个完成的 PR。这正是 Boris 和 Cat Wu 为 Opus 4.7 推荐的工作流。

9. 把 MCP 当成强力工具

MCP（Model Context Protocol，模型上下文协议）是把 Claude Code 从一个编码 Agent 变成一个"系统感知"Agent 的连线。一个 MCP server 通过标准契约，把外部工具（数据库、设计画布、错误追踪、你的笔记）暴露给 Claude，于是 Agent 能像调用任何其他工具一样调用它们。

没有 MCP，Claude 只能读文件、跑命令。有了 MCP，它能读你的 Linear 工单、查你的 Postgres、拉出一个 Figma 组件、抓实时的 Sentry 堆栈、读你的 Obsidian 库——全程不离开终端。

工程工作里的常用 MCP：

本地 server 通过 stdio 通信，厂商托管的走带 OAuth 的 HTTP：

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

团队共享的 MCP 落在项目根的 .mcp.json，个人的放在 ~/.claude.json。接好之后，你写的下一个提示就不再只关于你的仓库，而是关于你整个技术栈。

9.1 一个真实的 Obsidian 工作流

当你把库（vault）当成三层记忆来对待时，Obsidian 和 Claude Code 才真正咬合。跳过这个框架，你就退回到"Claude 能读我的文件"——而这恰恰错过了要点。

配置：在 Obsidian 里安装 obsidian-claude-code-mcp。它通过本地 WebSocket 在 22360 端口暴露库，Claude Code 会自己找到它。在库根目录放一个 CLAUDE.md，让 Agent 知道你的目录布局。

目录结构：

vault/
├── 00-Inbox/         # 原始捕获
├── 10-Daily/         # 每天一条笔记
├── 20-Projects/      # 活跃的项目笔记
│   └── billing-v2/
│       ├── README.md      # 目标、状态、待解问题
│       ├── decisions/     # ADR
│       └── sessions/      # 每个 Claude 会话一份日志
├── 30-Decisions/     # 跨项目的 ADR
├── 40-Atoms/         # 可复用知识，互相链接
└── 90-Archive/

三层：

• 热存储：每日会话日志。我跑的每一个会话都会往 10-Daily/<今天>.md 写一条带时间戳的条目。我挂了一个 Stop hook，会话结束时自动追加，无需复制粘贴。
• 温存储：项目笔记。每个项目住在 20-Projects/ 下。开始一个会话时，Claude 在动手前先读项目 README 和最近两三份会话日志。两周的上下文大约 30 秒就重新水合（rehydrate）完成。
• 冷存储：决策与原子。架构层面的决定一旦站稳，就提升进 30-Decisions/ 成为 ADR。可复用的知识被提炼进 40-Atoms/，配上 wikilink，让同一个事实串联到每一个需要它的项目。

日常用法：

• 我的 inbox 里有什么？总结一下，并建议每一项该归到哪里。
• 检查 30-Decisions/ 里有没有跟重试策略相关的东西。
• 读 billing-v2 最近 3 份会话日志，告诉我我上次做到哪了。

小技巧：忍住别把每个 MCP 都装上。每多一个，Claude 推理时要权衡的工具列表就更长，臃肿的工具列表会损害决策质量。起步套装：GitHub、Context7，外加一两个领域专用的。

小技巧：在 Claude Code 里运行 /mcp 列出每个活跃 server 及其连接状态。出问题时第一个该看的地方。

10. 优化你的日常工作流

早上。在项目里打开 Claude Code。扫一眼 subagent 和排程任务昨晚跑出来的东西。每周一次，运行 /insights 并认真读它。

新功能。从 plan 模式开始，用 Ctrl+G 把计划改到和你脑子里一致，再实现。然后要么调用 /pr-review subagent，要么开一个全新的 Claude 会话把它撕开来看。

Bug。动手之前先复现。用 cat error.log | claude 把报错喂进去，让 Claude 写一个复现这个 bug 的失败测试。只有那个测试变红之后，你才要求修复。跳过这一步，修复不过是一个穿了西装的猜测。

迁移或大规模改动。用 /batch。它会就你到底想要什么对你做一番询问，然后扇出给并行 agent，每个在自己的 worktree 里、各自跑测试、各自开 PR。你从打字员变成了评审者。

陌生代码。交给 subagent。比如"用一个 subagent 调查我们的 auth 是怎么处理 token 刷新的"。它在自己的上下文窗口里啃过几十个文件，回来交一份干净的总结。你的主会话保持清爽——这一点的重要性，等你为一次"挖矿"烧掉 20 万 token 窗口之后就懂了。

并行会话。Boris 和团队把这称作最大的单一生产力解锁，而我也只是在抗拒了一周之后才同意。三到五个 git worktree，每个跑自己的 Claude 会话。用 agent 视图（claude agents）当控制面板，这样你不用在六个终端间 alt-tab 也能看清谁在干什么。

写者/评审者模式。会话 A 实现改动，会话 B 在完全全新的上下文里评审，没有任何先前对话的包袱。把评审结果复制回会话 A，修，重复，直到会话 B 不再抱怨。

在里程碑处压缩。完成一个逻辑块之后，运行 /compact 保留做出的决策、改动的文件和测试命令。在上下文变浑之前做，温柔地做，经常地做。

小技巧：永远不要让 Claude 在没有证据的情况下宣称成功——无论是测试、截图还是真实命令输出。“信任但不验证"之间的缝隙，是糟糕输出最大的单一来源。

11. 来自 Anthropic 团队的建议

“驾驭 Claude 的人"和"跟 Claude 较劲的人"之间的区别，大概就归结于十几个习惯。下面是 Boris、Cat Wu、Thariq 以及团队其他人日常真正在做的：

• “给 Claude 一个验证自己输出的方式。一旦你做到，Claude 会一直迭代到结果很棒为止。” Boris 最常重复的一句。
• 几乎所有事都用 Opus，开 high 或 xhigh 的努力档。一个需要更多纠正的小模型，整体反而更慢。这就是 Boris 默认用 Opus 的原因。
• 并行跑 3–5 个会话。worktree 胜过 checkout。用 claude --worktree 或桌面 App，agent 视图把它们串起来。
• 每个项目维护一个笔记目录，每次 PR 后更新。让 Claude 把笔记写进一个目录，并让 CLAUDE.md 指向它。你的代码库在自我认知上产生复利。
• 建一个 /techdebt 斜杠命令。每个会话结束时跑一次，找出并干掉重复代码。
• 团队的 CLAUDE.md 是共享的，每周编辑好几次。每当有人看到 Claude 做错了什么，就加一条规则。把它当成活文档。
• Esc 两次打开 rewind。配合检查点，试一些有风险的事，发现它失败了，干净地回退。
• UI 改动配 Playwright MCP。Boris 每次碰 web 代码都会用 Chrome 扩展。Claude 打开浏览器、点来点去、验证结果。
• 装一个 language server 插件。每次编辑后你都会抓到类型错误和未使用的 import。你能装的影响力最高的插件。
• 用 /voice 提示。你说话比打字快 3 倍，而且一旦开口，提示会详细得多。
• 自动模式 + /focus + /goal。写一份清晰的说明，设好目标，走开。回来是一个完成的 PR。
• 用 Ctrl+G 在编辑器里改 Claude 的计划，再实现。比在聊天里打字纠正更快。
• 让 Claude 给新协议和代码库画 ASCII 图。Boris 快速理解陌生代码的小窍门。

12. 资源

官方文档：Claude Code 文档、探索 .claude 目录、Claude Code 最佳实践、Memory（CLAUDE.md、rules、自动记忆）、Skills、Subagents、Plugins、MCP、Hooks。

Boris 和团队：How Boris Uses Claude Code（89+ 条直接来自作者、整理自他的 X 帖子）、Anthropic 博客《Best practices for Opus 4.7 with Claude Code》、shanraisshan/claude-code-best-practice。

Skills：mattpocock/skills（“给真正工程师的 Skills”）、Jeffallan/claude-skills（66 个语言特定 skill）、addyosmani/web-quality-skills（web 性能与质量）、Anthropic skills cookbook。

Subagents：VoltAgent/awesome-claude-code-subagents（100+，按类别排序）、hesreallyhim/a-list-of-claude-code-agents。

Plugin 与市场：Chat2AnyLLM/awesome-claude-plugins（75+ 市场里 1000+ 插件）、claudemarketplaces.com。

MCP：Obsidian Claude Code MCP plugin、官方 MCP server 列表、claude.com/partners/mcp。

结语

Claude Code 在我手里开窍，是从我不再把它当成"终端里的 ChatGPT"开始的。心智模型从"我需要写这段代码"翻转成"我需要把 Claude 配置好，让它把代码写好”。配置才是工作，执行只是验证。

几件真正改变了我工作方式的事：

• CLAUDE.md 是会产生复利的基础设施。Claude 犯的每一个错误，都是一条等着被写下的规则。坚持几周"更新 CLAUDE.md，以后别再犯"之后，同样的提示词会产出好得多的结果。
• CLAUDE.local.md 捕捉 PR 反馈。你的评审者在白送你训练数据。把反复出现的评论转成规则，让 Claude 下一轮自己应用。
• Skills 是可复用专业能力的单元。如果你把同一套指令提示了两遍，你就有一个等着被写出来的 skill。
• 用 subagent 而不是大杂烩提示词。把关注点分开，让每个上下文保持干净，单任务质量就上去了。
• 并行会话是所有人都低估的解锁。三个 Claude 在三个 worktree 里，是另一种量级的乘数。试一天就知道。

大多数人停在提示词上。真正的价值在那之后——在目录布局、skills、subagent、plugin 和 MCP 里。你训练它、配置它、操作它。输出，跟着配置走。

原文：Beyond the Prompt: Claude Code，作者 Arpan Patel，发布于 2026 年 5 月 26 日。本文为中文翻译，遵循 CC BY-SA 4.0 署名。

关于

关注我获取更多资讯

📢 公众号

💬 个人号