Claude Code 进阶使用指南

2026 年 5 月 26 日 · 阅读约 27 分钟 · 作者 Arpan Patel

我曾在一次重构上浪费了四十分钟，而 claude 本该在四分钟内完成。问题不在模型本身，而在模型之外的一切。普通用户输入提示词，接受第一个建议，把 claude 当作花哨的自动补全来用。而我把它当作一个可编程的代理（Agent）来运行：持久化记忆、自定义命令、跨工作树（worktree）衍生出的并行会话——项目布局也随着每周使用而日趋精炼。本指南假设你已经在终端中输入过 claude 并了解了基本用法。接下来，我们要深入更进阶的内容……

现在，真正有趣的部分开始了。

1. 超越基础的 Claude Code

别再把 Claude Code 当成一个"输入提示词然后等待"的聊天机器人了。把它当作一个需要护栏（guardrails）的自主代理，你的整个工作流程都会随之转变。Boris Cherny 和 Anthropic 团队提出的核心原则很简单：让 Claude 拥有验证自身工作的能力。没有这个闭环，你就是唯一的反馈信号。有了它，Claude 会持续迭代，直到代码真正能运行。Boris 认为仅此一项改动就能带来 2-3 倍的质量提升。

以下几个模式将从根本上改变你的日常操作方式。

先探索，再规划，最后编码。 按两次 Shift+Tab 进入规划模式（plan mode），该模式为只读状态。让 Claude 阅读文件、追踪流程、梳理数据模型，得到一份规划方案，然后再执行。对于小型修复可以跳过规划，但当变更涉及多个文件时，务必使用规划模式。

把规划模式当作设计文档来用。 让一个 Claude 编写规划方案，再启动一个新的 Claude 会话，要求它以资深工程师的视角审查这份规划——没有上下文偏见，这样才能真正发现疏漏。如果实现过程偏离了方向，回到规划模式重新规划，并将验证步骤内置其中。

引用，而非描述。 不要说"看一下认证模块"，而是直接输入 @src/auth/login.py。不要粘贴错误日志，而是用管道传递：cat error.log | claude。精确的上下文永远胜过近似的描述。

委派任务，而非结对编程。 Cat Wu（Claude Code 团队成员）直言不讳："把模型当作你委以重任的工程师，而非需要你逐行指引的结对编程搭档，它的表现会最好。"写一份清晰简明的任务说明，然后让它自主执行。

提示： 按 Ctrl+G 可以在编辑器中打开 Claude 的规划方案，并在 Claude 执行前进行调整。规划方案只是文本，所以在它变成代码之前先把它打磨好。

提示： 当 Claude 犯错时，在提示词末尾加上"更新 CLAUDE.md，这样你就不会再犯同样的错误。"Boris 称 Claude "在根据自身失败为自己编写规则方面好得不可思议"。请注意，这一个习惯的复利效应比本指南中的任何其他技巧都要强。

2. 正确理解 .claude 目录

大多数人打开 .claude/ 目录，看到 CLAUDE.md，就匆忙离开了。实际上它是一套分层的配置系统。它有两个作用域。

项目作用域（Project scope）位于代码仓库内的 .claude/ 目录，提交到版本库以便团队共享。

全局作用域（Global scope）位于 ~/.claude/，在你本机的所有项目中通用。

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

一个典型的项目布局：

my-repo/
├── .claude/
│   ├── settings.json
│   ├── agents/
│   │   ├── pr-review.md
│   │   └── test-writer.md
│   ├── skills/
│   │   └── api-conventions/SKILL.md
│   └── rules/
│       ├── frontend.md        # path-gated to src/frontend/
│       └── migrations.md      # path-gated to db/migrations/
├── CLAUDE.md                  # checked in, team-shared
├── CLAUDE.local.md            # gitignored, personal
└── .mcp.json                  # team-shared MCP servers

几个容易忽略的细节。

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 都能注册斜杠命令，但技能可以附带支撑文件、设置 disable-model-invocation、指定允许的工具以及代理覆盖配置。去年我曾把一组仓库自动化脚本以松散的 commands/*.md 形式编写，后来当需要支撑文件时，不得不将它们全部迁移到 skills/。新的工作都应该放在 skills/ 中。

提示： 运行 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。整个团队每周多次向它贡献内容。

# Development Workflow

**Always use `bun`, not `npm`.**

# 1. Make changes

# 2. Typecheck (fast)

bun run typecheck

# 3. Run tests

bun run test -- -t "test name"# Single suite
bun run test:file -- "glob"# Specific files

# 4. Lint before committing

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

# 5. Before creating PR

bun run lint:claude && bun run test

再读一遍。Claude 无法自行猜测的构建命令、执行命令的精确顺序、单个测试的调用方式、创建 PR 前的必要步骤——全都在这里了。没有代码风格偏好，没有代码库导览，没有套话。

Boris 还在 PR 评论中使用 @claude 让 Claude 直接将规则提交到文件中：

nit: use a string literal, not a ts enum
@claude add to CLAUDE.md to never use enums, always prefer literal unions

他将这称为"复利式工程（Compounding Engineering）"——每一次 PR 评审都会转化为 CLAUDE.md 的一次改进。评审者只需捕获一次错误，Claude 就永远不会再犯。

以下是遵循同一理念的完整模板：

# Code style

- Use ES modules (import/export), not CommonJS (require)

# Workflow

- Always use `bun`, not `npm`
- Run `bun run typecheck` before claiming done
- Never push to main directly. Always open a PR.

# Architecture

- All API routes go through src/api/middleware/auth.ts
- New database queries go in src/db/queries/. No inline raw SQL.

# Gotchas

- `User` and `UserRecord` are distinct types. UserRecord is the DB row, User is the runtime object.
- `formatCurrency` assumes USD. For international use `formatCurrencyByLocale`.

请注意"Gotchas"（陷阱）部分。其中的每一条都始于 Claude 在某个真实 PR 上犯的真实错误，并在犯错的那一刻被记录下来。那种心往下一沉的感觉——你刚发现模型给法国用户推了美元格式化代码——只需记录一次，它就永远不会再发生。

CLAUDE.md 中应避免的内容： 标准语言规范、逐文件的代码库描述、长篇教程、API 文档，以及任何频繁变更的内容。

提示：IMPORTANT 或 YOU MUST 等词语能提高 Claude 的遵从度。但请节制使用，以保持它们的分量。

你可以使用 @path 语法导入其他文件，在保持 CLAUDE.md 简短的同时按需引入详细信息：

See @README.md for project overview and @package.json for scripts.
@~/.claude/my-preferences.md

文件精简，收益巨大。保持紧凑。

3.2 值得研读的知名 CLAUDE.md 文件

借鉴那些已经做过这项工作的人的经验。以下四个是我反复回顾的资源。

• **mattpocock/skills CLAUDE.md**：关于如何编写和测试技能的规范约定
• **anthropics/claude-code-action**：Anthropic 自己的仓库，其 CLAUDE.md 与内部工具同等对待
• **awesome-claude-code**：汇集了数十个跨语言生态系统的公开 CLAUDE.md 文件链接
• **claudelog.com**：社区维护的示例集合，按技术栈分类

阅读三个，然后编写你自己的。

4. 将 CLAUDE.local.md 作为日常工具

CLAUDE.local.md 与 CLAUDE.md 放在同一位置，以相同方式加载，且永远不会离开我的机器。它直接被写入 .gitignore。

以下是我的使用方式。每次 PR 之后，审查者会留下评论。我不会试图把这些反馈记在脑子里，而是在看到的第一时间将它们粘贴到 CLAUDE.local.md 中。几周下来，这个文件就会变成一份针对我反复收到的反馈而调优的个人规则文件。

# Personal review notes (private)

# From PR feedback

- New SQS consumers need a DLQ and alarms in the same PR
- Use `Optional<T>` over null returns
- Tests for new endpoints must include the auth-failure case
- Prefer named tuples over plain dicts for return types with 3+ fields

# My own quirks to correct

- Stop using `console.log`; use the project logger instead
- Always update the OpenAPI spec when adding endpoints

每次会话都会加载这个文件。现在 Claude 会自动包含认证失败的测试用例并更新 OpenAPI 规范，无需我额外提醒。两周内，我 PR 上的琐碎意见就明显减少了。

提示： 将文件内容明确分为两个部分：项目相关的反馈和需要纠正的个人习惯。混在一起会让后续的清理工作变得更加困难。

提示： 几周后做一次清理。已经形成肌肉记忆的内容可以删除。这个文件应该记录仍在调整中的事项；已经内化为自动行为的内容可以移除。

5. 技能（Skills）深度解析

技能是将 Claude Code 从"什么都能做的代理"转变为"按照你团队的方式、完成你项目实际需要的三件特定事情的代理"的手段。技能是可复用的专业知识单元，一旦写了一两个之后，你会不断回过头来使用它们……

5.1 技能的实际构成

上周二，我需要 Claude 以同样的方式总结我未提交的代码差异（diff），于是我在 ~/.claude/skills/ 下放了一个文件夹就去忙别的了。那个文件夹就是技能。文件夹内有一个 SKILL.md 文件，包含前言（frontmatter）和指令，而文件夹名称本身就变成了你在提示符下输入的斜杠命令（slash command）。项目级别的技能放在 .claude/skills/<name>/ 下，全局级别的放在 ~/.claude/skills/<name>/ 下。

以下是最小但足够实用的版本：

---
description: Summarizes uncommitted changes and flags anything risky. Use when the user asks what changed, wants a commit message, or asks to review their diff.
---

## Current changes

!`git diff HEAD`

## Instructions

Summarize the changes in two or three bullet points, then list any risks: missing error handling, hardcoded values, tests that need updating.

将其保存到 ~/.claude/skills/summarize-changes/SKILL.md，之后你打开的每个会话中都会出现 /summarize-changes 命令。

技能之所以强大的三个原因：

• 渐进式加载（Progressive disclosure）。 会话开始时，Claude 只读取前言中的描述，每条大约 100 个 token。完整的 SKILL.md 及辅助文件只有在技能实际触发时才会被加载。
• 每个技能都是独立的文件夹，因此你可以在 SKILL.md 旁边放一个 templates/ 目录，存放参考文档，并将脚本放在同一目录树中。SKILL.md 只是你交给 Claude 的入口。
• 内联 Shell 命令。 以 ! 开头的任何行都会在调用时执行该命令，并将输出直接拼接进提示词中。

前言本身还提供了大量可选配置项：

---
name: my-skill
description: When to use this skill
disable-model-invocation: true # only runs when user explicitly types /my-skill
allowed-tools: Read, Grep, Bash
agent: read-only
---

提示： 对具有副作用的技能使用 disable-model-invocation: true。你希望 /ship 只在显式输入时才执行部署，而不是在 Claude 认为相关时自动触发。

设置一次，永久省心。

5.2 编写一个实际的技能：Go API 约定

以下是一个面向 Go 服务团队的完整技能。它包含了团队的约定、常见陷阱，以及搭建新 HTTP 处理程序的脚手架。

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

---
description: Scaffolds a new HTTP handler in our Go service following team conventions for routing, validation, error handling, and tests. Use when the user asks to add a new endpoint, a new handler, or extend an existing route group.
---

# Go HTTP Handler Skill

## Stack

- Go 1.22 with chi router
- sqlc for typed queries, never write raw SQL strings in handlers
- zap for structured logging, never fmt.Println
- testify for assertions, table-driven tests preferred

## Gotchas

- `chi.URLParam` returns `""` for missing params, not an error. Always check.
- Our `httperr.Wrap` doesn't log. Log separately with `h.log.Error` before returning.
- Auth middleware injects via `context.Value(authkey.User)`. Type-assert to `*models.User`.
- sqlc nullable strings use `pgtype.Text`. Check `.Valid` before calling `.String`.
- Tests must use `httptest.NewRecorder` and `httptest.NewRequest`. No real server.

请注意这里发生的事情。一个新入职的开发者在第一天就能交付完全符合团队约定的端点，无需先深入探索（spelunking）整个代码库。

5.3 值得安装的热门技能

mattpocock/skills 是最受欢迎的技能仓库，星标数约 10 万。以下是我长期加载的几个：

• /grill-me：在编写任何代码之前，对你的方案进行盘问式审查
• /tdd：严格执行红-绿-重构（red-green-refactor）流程
• /diagnose：纪律化的调试流程——复现、最小化、假设、修复、回归测试

使用 npx skills@latest add mattpocock/skills 安装。

Jeffallan/claude-skills 提供了 66 个语言特定的配置文件，如 go-pro、python-pro、java-architect、typescript-pro、rust-engineer、sql-pro 等。你可以组合使用它们。一个 Next.js 任务可以同时引入 nextjs-developer 和 typescript-pro。

Anthropic 官方技能：

• /code-review：四个并行子代理审查代码差异，只输出带有置信度评分的发现
• /simplify：审查近期代码，寻找复用和效率改进的机会
• /batch：将迁移任务扇出（fan-out）到数十个并行子代理，每个代理在独立的工作树（worktree）中隔离运行
• /webapp-testing：赋予 Claude Playwright 控制权来测试你的本地 Web 应用

我以前每周都会把同样的提示词写上三遍，直到有一天我突然想通了……

提示： 如果某件事你每天做不止一次，就把它变成技能。任何你重复做的事情都是一个等待被写下来的技能。

提示： 将技能提交到 git 仓库。它们会沉淀为机构知识，新工程师只需克隆仓库就能免费获得团队积累的最佳实践。

6. 构建自定义子代理（Subagents）

启动一个子代理，它可以在不膨胀主会话上下文的前提下处理五十个文件，然后交回一份整洁的摘要。隔离的上下文、受限的工具权限、各自独立的影响范围。我是在一次调试会话中看着主会话的上下文预算被耗尽——当时它在整个单体仓库中追踪导入关系——之后开始默认使用子代理的。

将 markdown 文件放入 .claude/agents/ 即可用于项目级别，或放入 ~/.claude/agents/ 以全局使用。前言声明名称、描述、工具和模型。五行配置，完整的契约。

6.1 详解 /pr-review 代理

上周五，我差点提交了一个缺少空值检查的 PR，从那以后我构建了这个代理。

---
name: pr-review
description: Reviews the current branch diff against main, looking for bugs, security issues, missed edge cases, and project-convention violations. Use proactively before opening a PR.
tools: Read, Grep, Glob, Bash
model: opus
---

You are a senior staff engineer reviewing a pull request. Thorough, direct, goal is to catch issues before human reviewers do.

## Process

1. Run `git diff main...HEAD`
2. Run `git log main..HEAD --oneline`
3. Read full files, not just diff context
4. Cross-check against CLAUDE.md, CLAUDE.local.md, and .claude/rules/

## Flag

- Correctness bugs: off-by-one, null handling, error paths, race conditions
- Security: injection risks, missing auth checks, secrets in code
- Missing tests for new logic
- N+1 queries
- Convention violations from CLAUDE.md or rules/

## Do NOT flag

- Style preferences not in project rules
- Refactoring suggestions for working code
- Anything outside this diff

## Output

Group by severity (Critical / High / Medium / Low). File + line + issue + suggested fix.
End with a verdict: **SHIP**, **FIX FIRST**, or **REWORK**.

我通过在会话中输入 Have the pr-review agent look at my current branch. 来触发它。子代理在隔离的上下文中完成工作，我的主会话不会被审查相关的琐碎信息搞得杂乱。

有几个设计选择值得说明。tools 列表刻意限制为只读，因为一个能修改代码的审查者会开始合理化自己的修复方案，而不是把问题标记出来。我选择了 model: opus，因为在人工审查者之前捕获安全漏洞的价值远超其成本。顺便说一下，"Do NOT flag" 部分才是让输出真正可用的关键。没有它，我会被淹没在关于变量命名的吹毛求疵中。

花了十分钟构建。已经帮我避免了两次问题。

6.2 值得借鉴的热门子代理

直接来自 Claude Code 团队自身工作流的代理包括 build-validator、code-architect、code-simplifier、oncall-guide 和 verify-app，它们每天都在被使用。

以下是社区中最受欢迎的几类子代理……

如果你想要经过整理的集合，VoltAgent/awesome-claude-code-subagents 收录了超过 100 个代理，hesreallyhim/a-list-of-claude-code-agents 也整理了一批高质量的子代理。

提示： 链式调用子代理：会话 A 负责实现，然后调用 Use the code-reviewer subagent to check the work.。审查者在全新的上下文中进行评估，不会受到实现阶段的偏见影响。

提示： 在前言中添加 isolation: worktree 可让子代理在独立的 git 工作树中运行，这在将迁移任务扇出到数十个并行子代理时尤为强大。

今天就借鉴这些模式，明天你就会好奇当初没有它们是怎么交付代码的。

7. 插件与插件市场

插件将技能（Skills）、钩子（Hooks）、子代理（Subagents）和 MCP 服务器打包为一个可安装的整体单元。运行 /plugin 即可打开插件市场浏览器。通过 /plugin marketplace add owner/repo 可以添加社区市场。

首日推荐安装：

/code-review 会同时启动四个代理并行工作。两个检查 CLAUDE.md 的合规性，一个排查缺陷，一个读取 git blame 获取上下文。输出结果附带置信度评分，确保高信号、低噪声。

/feature-dev 是官方市场上安装量最高的技能。只需提供一份功能需求简述，即可获得可运行的代码。整个流程分为七个阶段：需求分析、探索调研、架构设计、代码实现、测试验证、代码审查和文档生成。

语言服务器插件 将符号级导航和实时编辑诊断直接接入你的会话。团队一致认为这是你能安装的最高杠杆插件。

/security-guidance 是 Anthropic 官方的安全技能，在代码提交之前发现潜在的安全隐患。

值得关注的插件类别（截至 2026 年中，75 个以上的市场中已有超过 1000 个插件）：

• Git 工作流、代码智能（LSP）、文档生成器、测试、浏览器自动化（Playwright）、设计系统（Figma）、可观测性（Sentry、Datadog）

提示： 一份团队共享的 .mcp.json 搭配几个精心挑选的插件，能让新工程师在克隆仓库后几分钟内就进入高效状态。把插件选择当作入职引导的一部分来对待。

8. 被低估的 Claude Code 命令

大多数人学会了 /clear、/compact 和 /init 就不再深入了。而真正的生产力恰恰藏在其余的命令中，却鲜有人触及。

下面深入讲解我每天都会用到的两个命令……

/compact 与 /clear 的区别： 如果你要开始一个全新的任务，用 /clear 并手动撰写一份新的简要说明。如果下一个任务仍然依赖于刚才的工作，就用 /compact 并通过 hint 参数指定需要保留的内容。/compact 会用 LLM 对会话做一次有损压缩摘要，而 /clear 是你自己精心撰写的简要说明。我曾把这两者混淆了好几个星期，一直纳闷为什么会话总是逐渐偏离方向。一旦理解了这个区别，我的上下文就能在数小时内保持干净清爽。

/rewind 会在每次提示时自动创建检查点，这些检查点可以跨会话保留。因此，当 Claude 走上一条错误的路径时，克制住输入"那没用，试试 X"的冲动。那样做只会把失败的尝试埋进上下文，模型会不断被它绊住。正确的做法是回退到出错之前的检查点，然后根据你从失败中观察到的信息重新给出提示。你的上下文窗口会为此感谢你。

提示： 使用 ! 作为 shell 转义。!git status 或 !npm test 会立即执行，输出直接进入上下文。

提示： 设置 CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000。在 1M 模型上，上下文腐化（context rot）大约在 300-400k token 时出现，因此强制提前压缩以保持会话质量。

扇出模式： 先编写任务列表，然后循环执行。上个季度我用这种方式迁移了大约两千个组件文件。先生成列表，手动验证其中三个的合理性，反复调整提示词直到这三个的结果完全正确，然后放手让它在其余文件上批量运行，自己则去喝杯咖啡。

for file in $(cat files.txt); do
  claude -p "Migrate $file from React to Vue. Return OK or FAIL." \
    --allowedTools "Edit,Bash(git commit *)" \
    --bare
done

8.1 /goal：内置的 Ralph 循环

上周二，我只输入了一行命令，合上笔记本电脑，吃了顿晚饭，回来时就看到一个通过了所有检查的 PR。/goal 设定一个完成条件，Claude 会持续工作直到该条件满足。每一次尝试停止时都会触发对会话记录的校验。

/goal all tests in test/auth pass and the lint step is clean

真实示例：

/goal all integration tests in tests/api pass without flaking 3 runs in a row
/goal the OpenAPI spec validates and matches the actual response shapes
/goal docker compose up runs cleanly and the healthcheck endpoint returns 200
/goal coverage on src/billing/ is above 80% and all new tests are not placeholders

选择可验证且具有确定性的目标。将目标绑定到测试命令、CLI 退出码或某个可以用 grep 检查的文件状态上。如果写"代码质量好"这种模糊条件，那就注定会失败……

与之搭配的好帮手：

• /loop：按固定间隔重复执行，逐步消化积压任务
• /schedule：在云端按既定节奏运行
• Stop 钩子：以你自己的测试套件或 CI 端点作为把关条件
• 自动模式（Auto mode）：消除权限确认提示，避免长时间运行的目标被中断

提示： 将 /goal + 自动模式 + /focus 组合使用。写一份清晰的简要说明，设定目标，然后离开。回来时就能看到一个完成的 PR。这正是 Boris 和 Cat Wu 为 Opus 4.7 推荐的工作流。

9. MCP：真正的利器

MCP 生态系统：连接外部工具与服务

MCP 是一根导线，将 Claude Code 从一个编码代理转变为一个具备系统感知能力的代理。MCP 服务器通过标准化的协议契约，向 Claude 暴露外部工具（数据库、设计画布、错误追踪器、笔记应用等），使代理可以像调用内置工具一样调用它们。

没有 MCP，Claude 只能读取文件和执行命令。有了 MCP，它可以读取你的 Linear 工单、查询你的 Postgres 数据库、调出 Figma 组件、获取实时的 Sentry 堆栈追踪，或者读取你的 Obsidian 笔记库——这一切都不需要你离开终端。

工程工作中最常用的 MCP：

本地服务器通过 stdio 通信，厂商托管的服务器通过 HTTP 加 OAuth 通信：

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

团队共享的 MCP 配置放在项目根目录的 .mcp.json 中，个人配置放在 ~/.claude.json 中。一旦配置完成，你编写的下一条提示就不再局限于代码仓库，而是面向整个技术栈。

9.1 一个真实的 Obsidian 工作流

当你将 Obsidian 笔记库视为三层记忆结构时，Obsidian 与 Claude Code 的配合才能真正发挥威力。忽略这个框架，就退回到了"Claude 能读我的文件"这种浅层用法，完全错失了要点。

配置： 在 Obsidian 中安装 obsidian-claude-code-mcp。它会通过本地 WebSocket（端口 22360）暴露笔记库，Claude Code 会自动发现它。在笔记库根目录放置一个 CLAUDE.md 文件，让代理了解你的文件夹结构。

文件夹结构：

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

三层记忆结构：

热存储：每日会话日志。 每次会话运行时，都会在 10-Daily/<today>.md 中写入一条带时间戳的记录。我配置了一个 Stop 钩子，确保在会话结束时自动追加内容，无需手动复制粘贴。

温存储：项目笔记。 每个项目都存放在 20-Projects/ 下。每次开始新会话时，Claude 会先阅读项目的 README 和最近两到三次的会话日志，然后才开始工作。两周的上下文在大约 30 秒内即可恢复。

冷存储：决策记录与知识原子。 架构决策一旦确定，就会被提升为 ADR（架构决策记录）存入 30-Decisions/。可复用的知识会被提炼到 40-Atoms/ 中，并通过双向链接（wikilinks）将同一个事实串联到所有需要它的项目中。

日常工作流：

• What is in my inbox? Summarize and suggest where each item belongs.
• Check 30-Decisions/ for anything related to retry policies.
• Read the last 3 session logs for billing-v2. Tell me where I left off.

提示： 克制安装所有 MCP 的冲动。每一个 MCP 都会扩展 Claude 需要推理的工具列表，而膨胀的工具列表会损害决策质量。入门配置建议：GitHub、Context7，再加一到两个领域相关的 MCP。

提示： 在 Claude Code 中运行 /mcp 可以列出所有活跃的服务器及其连接状态。当出现问题时，这是首先要检查的地方。

10. 优化日常工作流

早晨。 在项目中打开 Claude Code，浏览子代理（subagent）和定时任务在夜间处理的内容。每周运行一次 /insights，并认真阅读其输出。

新功能。 先进入规划模式（plan mode），然后用 Ctrl+G 在编辑器中调整计划，直到它与你的设想一致。然后开始实现。可以调用 /pr-review 子代理，或者启动一个全新的 Claude 会话来审查代码。

Bug。 在动手修复之前先复现问题。通过 cat error.log | claude 将错误日志传入，让 Claude 编写一个能复现该 Bug 的失败测试。只有当测试亮红灯之后，再让它修复。跳过这一步，所谓的修复不过是披着体面外衣的猜测。

迁移或批量变更。 使用 /batch。它会先询问你的实际需求，然后扇出（fan-out）到多个并行代理，每个代理运行在独立的工作树（worktree）中，各自运行测试并开设独立的 PR。你从逐行敲代码的人变成了代码审查者。

不熟悉的代码。 交给子代理处理。比如这样的指令："使用子代理调查我们的认证模块如何处理令牌刷新。"它会在自己的上下文窗口（context window）中消化数十个文件，然后返回一份简洁的摘要。你的主会话保持整洁——这一点的重要性远超多数人的想象，尤其是当你曾经在一次次深入探索（spelunking）中烧掉 20 万 token 的上下文窗口之后。

并行会话。 Boris 和团队将其称为最大的生产力突破，我只有在抵触了一周之后才深有同感。三到五个工作树，每个运行独立的 Claude 会话。使用代理视图（claude agents）作为控制面板，这样无需在六个终端窗口之间来回切换，就能一目了然地看到每个代理的工作状态。

编写者/审查者模式。 会话 A 负责实现变更。会话 B 在全新的上下文中审查代码，不带任何先前对话的包袱。将审查意见复制回会话 A，修复问题，如此反复，直到会话 B 不再提出异议。

在里程碑节点进行压缩。 完成一个逻辑单元后，运行 /compact Preserve the decisions made, files changed, and test commands.。在上下文变得混乱之前执行压缩，友善地对待你的上下文，养成频繁压缩的习惯。

提示： 永远不要让 Claude 在没有证据的情况下宣称成功——无论是测试结果、截图还是真实的命令输出。信任与验证之间的鸿沟，是产生低质量输出的最大根源。

11. 来自 Anthropic 团队的建议

擅长使用 Claude 的人与与它较劲的人之间的差距，归结起来不过是十来个习惯。以下是 Boris、Cat Wu、Thariq 以及团队其他成员日常真正在做的……

"给 Claude 一种验证自身输出的方式。一旦做到这一点，Claude 就会反复迭代，直到结果令人满意。" 这是 Boris 反复强调最多的观点。

几乎所有任务都使用 Opus 并设置为 high 或 xhigh 推理强度。 较小的模型虽然看似轻量，但需要更多修正，总体速度反而更慢。这正是 Boris 默认使用 Opus 的原因。

并行运行 3-5 个会话。 工作树优于普通的分支检出（checkout）。使用 claude --worktree 或桌面应用。代理视图将它们统一管理。

为每个项目维护一个笔记目录，每次 PR 之后更新。 让 Claude 将笔记写入指定目录，并在 CLAUDE.md 中引用它。你的代码库会逐渐积累对自身的认知。

构建一个 /techdebt 斜杠命令（slash command）。 在每次会话结束时运行它，用于发现和消除重复代码。

团队的 CLAUDE.md 是共享的，每周编辑多次。 每当有人发现 Claude 犯了某个错误，就添加一条规则。将它视为一份持续演进的活文档。

按两次 Esc 可以打开回退（rewind）功能。 配合检查点（checkpoint）使用：尝试有风险的操作，发现失败后，干净地回退到之前的状态。

对于 UI 变更，配置 Playwright MCP。 Boris 每次处理前端代码时都会使用 Chrome 扩展。Claude 会打开浏览器、点击操作、验证结果。

安装语言服务器插件（language server plugin）。 每次编辑后都能捕获类型错误和未使用的导入。这是你能安装的影响力最大的插件。

使用 /voice 进行语音提示。 你说话的速度是打字的三倍，一旦使用语音，你的提示词会变得详尽得多。

自动模式（auto mode）+ /focus + /goal。 写一份清晰的任务简报，设定目标，然后离开。回来时 PR 已经完成。

使用 Ctrl+G 在编辑器中直接修改 Claude 的计划。 比在聊天框中逐字输入修正意见要高效得多。

让 Claude 为新的协议和代码库绘制 ASCII 图。 这是 Boris 快速理解陌生代码的诀窍。

12. 资源

官方文档

• Claude Code 文档
• 探索 .claude 目录
• Claude Code 最佳实践
• 记忆（CLAUDE.md、规则、自动记忆）
• 技能（Skills） · 子代理（Subagents） · 插件（Plugins） · MCP · 钩子（Hooks）

Boris 及团队

• Boris 如何使用 Claude Code：89 条以上来自创建者本人的一手经验，整理自他的 X 系列推文
• Anthropic 博客：Opus 4.7 搭配 Claude Code 的最佳实践
• shanraisshan/claude-code-best-practice

技能

• mattpocock/skills："面向实战工程师的技能"
• Jeffallan/claude-skills：66 个语言相关的专项技能
• addyosmani/web-quality-skills：Web 性能与质量
• Anthropic 技能手册（cookbook）

子代理

• VoltAgent/awesome-claude-code-subagents：100 多个子代理，按类别分类
• hesreallyhim/a-list-of-claude-code-agents

插件与市场

• Chat2AnyLLM/awesome-claude-plugins：1000 多个插件，覆盖 75 个以上市场
• claudemarketplaces.com

MCP

• Obsidian Claude Code MCP 插件
• 官方 MCP 服务器列表
• claude.com/partners/mcp

结语

当我停止把 Claude Code 当作终端版 ChatGPT 来用的那一刻，一切豁然开朗。思维模型从"我需要自己写这段代码"转变为"我需要让 Claude 准备好把这段代码写好"。配置本身就是工作，执行就是验证。

以下几件事切实改变了我的工作方式：

CLAUDE.md 是一种复利式基础设施。 Claude 犯的每一个错误都是一条待写入的规则。经过几周"更新 CLAUDE.md 以免重蹈覆辙"的积累，同样的提示词会产生显著更好的输出。

CLAUDE.local.md 用于沉淀 PR 反馈。 你的审查者实际上在为你提供免费的训练数据。将反复出现的评审意见转化为规则，让 Claude 在下一轮自动应用。

技能是可复用专业知识的最小单元。 如果你已经写了两次相同的指令，那就说明有一个技能等着被提炼出来。

用子代理代替大杂烩式提示词（kitchen-sink prompt）。 分离关注点，保持每个上下文的整洁，单项任务的质量就会提升。

并行会话是被所有人低估的生产力突破。 三个 Claude 分布在三个工作树中，效果事半功倍。试上一天，你自有体会。

大多数人止步于提示词。真正的价值在更深处——在目录结构、技能、子代理、插件和 MCP 之中。你训练它、配置它、操作它。输出的质量追踪着配置的质量。