Claude Code的学习笔记
两个 .claude/ 目录
关键先搞清楚:项目里有两套配置在叠加生效:
~/.claude/ ← 全局,跨所有项目(个人配置,不提交)
<your-project>/.claude/ ← 项目级,跟 git 走(团队共享)
加载顺序:Claude Code 默认 → ~/.claude → 项目 .claude/,后者覆盖前者。
完整目录骨架(项目级)
your-project/
├── CLAUDE.md # 项目记忆,开场必读
├── CLAUDE.local.md # 个人补充(.gitignore 掉)
└── .claude/
├── settings.json # 权限/钩子/MCP/模型,提交
├── settings.local.json # 个人覆盖,不提交
├── .mcp.json # MCP 服务器配置
├── rules/ # 拆分后的指令(CLAUDE.md 太长就用这个)
│ ├── code-style.md
│ └── testing.md
├── commands/ # 斜杠命令,文件名即命令
│ └── review.md # → /review
├── skills/ # 自动触发的工作流
│ └── deploy/
│ ├── SKILL.md
│ └── scripts/
├── agents/ # 子代理(subagent)人格
│ ├── code-reviewer.md
│ └── security-auditor.md
├── hooks/ # 工具事件触发的脚本
│ └── validate-bash.sh
├── plugins/ # 安装的插件清单
└── projects/ # 会话记录、auto-memory(一般别动)
每个目录到底干嘛的
CLAUDE.md —— 最高杠杆的文件。会话一启动就被读进系统提示词,全程在场。写技术栈、构建/测试命令、关键约定、踩坑点。社区共识是控制在 200 行以内——再长 Claude 的指令遵循度反而会下降,因为它会跟其他上下文抢注意力。
rules/ —— 当 CLAUDE.md 撑不下时,按主题拆出来。可以按路径作用域(比如 rules/frontend.md 只在改前端代码时加载),相当于"懒加载的项目知识"。
commands/ —— 斜杠命令。一个 .md 文件就是一个命令的提示词模板,文件名变成命令名。commands/review.md → 输入 /review 就执行里面的逻辑。注意:新版已经把 commands/ 和 skills/ 逻辑合并了——.claude/commands/deploy.md 和 .claude/skills/deploy/SKILL.md 都能创建 /deploy。
skills/ —— 跟你之前问的我容器里的 skills 是同一套机制。每个 skill 是一个目录,有 SKILL.md(YAML frontmatter + 正文)。Claude 启动时只读 frontmatter 里的 name 和 description 做索引,触发时才加载完整内容。可以带 scripts/、references/、templates/ 等子目录放辅助材料。
agents/ —— 子代理。每个 .md 文件定义一个有独立上下文窗口、独立工具白名单、甚至独立模型的"专家"。比如:
--- name: code-reviewer description: Use PROACTIVELY when reviewing PRs
model: sonnet tools: Read, Grep, Glob --- You are a senior code reviewer...
主 Claude 通过 Agent 工具委派任务,子代理在隔离上下文里跑完返回结果——主上下文不会被代码审查的细节淹没。
hooks/ —— 真正的"自动化层"。在工具事件前后触发脚本,可以放行/阻断/改写。常见模式:PreToolUse 拦截危险 bash、PostToolUse 自动跑 prettier、Stop 跑测试。配置在 settings.json 的 hooks 字段里,脚本放 hooks/ 子目录。除了 command 类型,还有 prompt(让小模型判断)、agent(派子代理验证)、http(webhook)。
settings.json —— 权限和配置中枢。最常用的是 permissions:
{ "permissions": { "allow": ["Bash(npm run *)", "Read", "Edit"], "deny": ["Bash(rm -rf *)", "Read(./.env)", "Read(./secrets/**)"] } }
求值顺序:deny → ask → allow,deny 永远赢。settings.local.json 是个人覆盖,应该 gitignore。
.mcp.json —— MCP 服务器配置,把 Claude 接到 GitHub、Jira、Slack、数据库等外部系统。
projects/ —— 这个目录在 ~/.claude/ 下更常见,存会话记录和 auto-memory(Claude 自己学到的 patterns)。用 /memory 浏览。要清空可以 claude project purge。
不太显眼的细节
几个文档之外、但实际坑/亮点:
-
CLAUDE.md可以分层。除了项目根,子目录也能放——Claude 进入那个子目录工作时会一起加载。适合 monorepo 给每个包配独立规则。 - agents 和 skills 看起来像,区别是上下文边界。Skill 是"扩展当前对话能力",加载进主上下文;agent 是"派一个独立窗口去干活",结果摘要回来。重活、可能产生大量 tool 调用的任务用 agent,轻量提示模板用 skill。
-
新版(v2.1.121+)有个隐式豁免:即使你用
--dangerously-skip-permissions,写到.claude/commands/、.claude/agents/、.claude/skills/、.claude/worktrees/仍然不会拦——因为 Claude 经常自己往这些目录写新工件。v2.1.126 进一步豁免了整个.claude/、.git/、.vscode/和 shell 配置文件。 -
commands/和skills/已经合并了。旧的commands/*.md文件继续工作,但新写建议用 skill 格式——能挂载辅助文件、能让 Claude 自动触发(而不只是用户输入斜杠)。 -
路径作用域 rules 是被低估的功能。
rules/api.md可以在 frontmatter 里写globs: ["src/api/**"],只在改这部分代码时注入。比把所有规则塞进根CLAUDE.md高效得多。 -
不要随手
rm -rf ~/.claude。~/.claude.json、~/.claude/settings.json、~/.claude/plugins/包含登录凭证和插件——删了得重新认证。
实用建议
从社区共识看,进阶顺序大概是:
-
先只写
CLAUDE.md(架构 + 命令 + 关键约定) -
加
settings.json把常用命令放 allow、.env放 deny -
重复 prompt 超过两三次就抽成
commands/或skill/ -
CLAUDE.md超过 200 行就拆rules/ -
有专业重活(代码审查、安全审计)再加
agents/ -
想要确定性的自动化(自动 format、阻断危险命令)才上
hooks/
别一上来就堆完整目录,每一层都该解决一个你真实遇到过的摩擦点——不然就成了为配置而配置。
~/.claude/ 全家福
上次只点了 projects/,实际全景:
~/.claude/
├── CLAUDE.md 全局指令
├── settings.json 全局设置
├── history.jsonl 所有 session 的 prompt 历史
├── stats-cache.json 聚合使用统计(按天/按模型 token)
├── mcp-needs-auth-cache.json MCP 待认证缓存
│
├── projects/ 每项目的会话 JSONL(含完整对话)
├── plans/ Plan 模式生成的 .md
├── todos/ 每会话的 TodoWrite 状态
├── tasks/ 长任务追踪
├── file-history/<session-uuid>/ 文件编辑前快照(撤销源)
├── debug/ 每会话 debug 日志(有 latest 软链)
├── shell-snapshots/ 每会话约 50KB 的 shell 环境快照
├── session-env/ 会话环境变量
├── paste-cache/ 粘贴内容(按 hash 去重)
├── downloads/ 下载的工件
├── backups/ 自动配置备份
├── cache/ changelog 等缓存
│
├── commands/ skills/ agents/ 全局版(个人,不跟项目走)
├── output-styles/ 输出风格定义
├── rules/ hooks/ 全局规则和钩子
├── plugins/ 插件市场和已装清单
├── statsig/ feature flag 缓存
├── telemetry/ 遥测(如启用)
├── ide/ VS Code/Cursor 集成的 PID 锁
└── statusline.sh 状态栏脚本(你写的)
外加一个容易漏的关键文件:~/.claude.json(在 home 根,不在 .claude/ 里!)—— 存 OAuth token、MCP 服务器、per-project 状态、feature flags。删了要重新登录。
项目级也漏了几个
.claude/
├── output-styles/ 新(v2.0+),控制响应格式
├── worktrees/ --worktree 标志下创建的隔离工作区
├── scheduled-tasks/ 定时任务(最新加入)
└── subagents/ 子代理的对话记录("sidechain")
.worktreeinclude 项目根的特殊文件,列出哪些 gitignored
文件(如 .env)该被复制进新 worktree
真正"隐藏"的细节
1. 命令文件里可以嵌 shell
.claude/commands/review.md 不只是静态 prompt,支持两个魔法语法:
--- description: Review current changes argument-hint: [issue-number] --- Look at issue #$ARGUMENTS:
!`gh issue view $ARGUMENTS` !`git diff main...HEAD` Now review the diff against the issue requirements.
反引号里的 shell 命令会先执行,输出嵌入 prompt,Claude 看到的是已经渲染好的内容。$ARGUMENTS 是命令名之后的所有文本。
2. rules 支持路径作用域
.claude/rules/api.md 的 frontmatter:
--- description: API conventions globs: ["src/api/**", "src/handlers/**"] ---
只在改这部分代码时注入,避免给前端任务塞后端规则。社区甚至有 CI 工具检测"死规则"——globs 不匹配任何文件的 rule。
3. 子代理的隐藏触发词
--- name: code-reviewer description: Expert code reviewer. Use PROACTIVELY when reviewing PRs model: sonnet tools: Read, Grep, Glob ---
description 里写 PROACTIVELY 是文档里轻描淡写、实际很强的关键词——它让 Claude 主动派发,而不只是用户喊。tools: 是工具白名单,是真正的权限控制(安全审计员只给 Read/Grep/Glob,没有 Write)。
4. Hook 不止 shell 命令
四种类型:
{ "type": "command", "command": "...", "async": true } // 跑 shell { "type": "prompt", "prompt": "Should I stop?" } // LLM 评估 { "type": "agent", "prompt": "Verify tests..." } // 派子代理 { "type": "http", "url": "..." } // webhook
事件 12+ 种:PreToolUse、PostToolUse、UserPromptSubmit、Stop、SubagentStop、Notification、PreCompact、SessionStart、SessionEnd、ExitPlanMode、Setup(新)…… async: true 让钩子后台跑不阻塞。
5. Setup 钩子可以由 CLI 标志触发
claude --init # 触发 matcher: "init" 的 Setup 钩子 claude --maintenance # 触发 matcher: "maintenance" claude --init-only # 跑完就退出,适合 CI
适合做项目首次克隆后的初始化(装依赖、生成 secrets 提示)。
6. 企业管控层
文档里大多忽略这层:
/etc/claude-code/managed-settings.json # Linux/macOS
C:\Program Files\ClaudeCode\managed-settings.json # Windows (2.1.75+)
managed-settings.d/ # systemd 风格 drop-in
├── 10-telemetry.json
└── 20-security.json
managed-settings.d/ 按字母序合并,数字前缀控制顺序。配合 allowManagedHooksOnly: true / allowManagedPermissionRulesOnly: true,组织管理员能强制只用经审计的钩子和权限规则,员工无法绕过。
7. 设置优先级
完整优先级链(高到低):
managed settings → CLI flags → env vars → project (.claude/)
→ user (~/.claude/) → Claude Code defaults
意味着你公司的安全策略永远赢你的个人配置。
8. statusLine 收到的完整 JSON
statusLine.command 通过 stdin 收到的不是简单字符串,是富数据:
{ "session_id": "abc...", "model": {"id": "claude-opus-4-6", "display_name": "Opus"}, "workspace": {"current_dir": "...", "git_worktree": "feature-xyz"}, "output_style": {"name": "default"}, "cost": {"total_cost_usd": 0.012, "total_lines_added": 156}, "context_window": {"used_percentage": 8, "context_window_size": 200000}, "rate_limits": {"five_hour": {...}, "seven_day": {...}} }
可以做实时成本告警、上下文使用率进度条、worktree 名前缀……远不止显示个模型名。
9. 会话 UUID 是横向索引
同一个 session UUID 同时出现在:
projects/<project-hash>/<uuid>.jsonl 完整对话
file-history/<uuid>/ 文件编辑快照
todos/<uuid>.json 任务状态
debug/<uuid>.log 调试日志
session-env/<uuid>/ 环境变量
这就是为什么 /rewind 能时光倒流——所有维度都按 UUID 对齐,能精确恢复任一时刻的状态。
10. 关键环境变量
-
CLAUDE_CONFIG_DIR—— 把整个~/.claude/重定向到别处(多账户/沙盒很有用) -
CLAUDE_PROJECT_DIR—— hook 脚本能读到 -
CLAUDECODE=1—— 在子进程环境里自动设,让被调用的工具能识别"是 AI 在调" -
CLAUDE_CODE_SKIP_PROMPT_HISTORY—— 不写 history(处理敏感工作时关) -
CLAUDE_AGENT_PARENT—— v2.1.120+,更通用的"AI 父进程"标识
11. CLAUDE.md 多层叠加
不止根目录有,子目录也能放。Claude 进入某子目录工作时会一起加载:
project/
├── CLAUDE.md # 全局架构
├── backend/CLAUDE.md # 改后端时额外加载
└── frontend/CLAUDE.md # 改前端时额外加载
monorepo 必备。
12. 隐私/数据保留的坑
projects/<project>/<session>.jsonl 明文未加密存盘——靠 OS 文件权限保护。如果某工具读了 .env 或某命令打印了 token,那值就落地了。缓解办法:
-
设
cleanupPeriodDays缩短保留期 -
设
CLAUDE_CODE_SKIP_PROMPT_HISTORY=1完全不写 -
用
permissions.deny拦掉对凭证文件的读 -
非交互模式
-p配--no-session-persistence
13. --dangerously-skip-permissions 的精细豁免
这个标志名字吓人,但其实有保险:
-
.git/、.vscode/、.idea/、.husky/仍会询问(v2.1.126 前) -
v2.1.121+:
.claude/commands/、.claude/agents/、.claude/skills/、.claude/worktrees/豁免(因为 Claude 经常往这写) -
v2.1.126+:整个
.claude/、.git/、.vscode/、shell rc 文件都豁免 -
rm -rf /这类灾难命令永远拦,跳不掉
14. Plan 模式有自己的存储
/plan 进入计划模式时,每次计划存到 ~/.claude/plans/<session>.md。可以审阅历史方案。ExitPlanMode 钩子能拦截"开始执行"的那一刻——有人写了交互式 UI 让用户批注计划再放行。
实务总结
如果你想"我到底改了什么 Claude 才不会忘",编辑面只有这些:
CLAUDE.md, settings.json, .mcp.json
.claude/rules/ .claude/commands/ .claude/skills/
.claude/agents/ .claude/hooks/ .claude/output-styles/
其他 ~/.claude/ 下的目录全是 Claude 自己管的运行时状态——别手动编辑,要清就用 claude project purge。
如果你想做机器迁移,关键是这几样:~/.claude.json(凭证)、~/.claude/settings.json、~/.claude/CLAUDE.md、~/.claude/skills/、~/.claude/commands/、~/.claude/plugins/、~/.claude/agents/。其他都是"用着用着会重新生成"的。
到这里基本是全的了。再往下挖就是 ~/.claude.json 里 OAuth token 的精确结构、stats-cache.json 字段、jsonl 里 parentUuid 链式回放协议这种实现细节——除非你要写第三方工具集成,否则不必关心。
两个完全不同的层次
┌─────────────────────────────────────────────────────┐
│ 工具配置层(.claude/, .cursor/ 等) │
│ → 给特定工具的行为配置 │
│ → 钩子、子代理、权限 │
├─────────────────────────────────────────────────────┤
│ 协作指令层(CLAUDE.md / AGENTS.md / harness.md 等)│
│ → 给 LLM 看的项目知识/工作流 │
│ → 团队约定、构建命令、边界 │
└─────────────────────────────────────────────────────┘
各工具的"主指令"文件
每个 AI 编程工具都有自己读的"项目说明书"文件,互不通用:
| 工具 | 主指令文件 | 备选 |
|---|---|---|
| Claude Code / Claude Desktop |
CLAUDE.md
|
CLAUDE.local.md(个人,gitignore)
|
| OpenAI Codex |
AGENTS.md
|
AGENTS.override.md(子目录覆盖)
|
| GitHub Copilot |
.github/copilot-instructions.md
|
.github/agents/*.md
|
| Cursor |
.cursor/rules/*.mdc
|
旧版 .cursorrules
|
| Windsurf |
.windsurfrules / .windsurf/rules/
|
|
| Aider |
CONVENTIONS.md 或 .aiderules
|
|
| Kilo Code |
AGENTS.md 或 AGENT.md
|
|
| Builder.io |
.builderrules / AGENTS.md
|
|
| Factory |
AGENTS.md
|
|
| Jules(Google) |
AGENTS.md
|
|
| Continue |
.continuerc.json + rules/
|
|
| OpenCode |
AGENTS.md
|
AGENTS.md:开放标准
这是最重要的一个。AGENTS.md 是 Linux Foundation 旗下 Agentic AI Foundation 维护的开放约定,由 OpenAI Codex、Cursor、Google Jules、Factory、Amp 等共同发起,目标是跨工具通用——你写一份,所有支持的工具都读。
唯一不读的主流工具就是 Claude Code(它只读 CLAUDE.md)。但有个常见技巧:
ln -s AGENTS.md CLAUDE.md
软链接一下,所有工具都能用同一份。
AGENTS.md 的核心规范:
# Project Name ## Commands - `pnpm test` — Run test suite (required before PR) - `pnpm build` — Production build - `pnpm dev` — Dev server at localhost:3000 ## Project Structure - `src/components/` — Reusable UI - `src/features/` — Feature code ## Code Style - TypeScript everywhere - 2-space indent - Components: PascalCase ## Git Workflow - Branch: `initials/short-desc` - Title format: [<project>] <Title> ## Boundaries - **NEVER** commit `.env` or hardcode keys - **ALWAYS** run typecheck before committing - Don't touch `vendor/` or `dist/`
GitHub 分析过 2500+ 个 AGENTS.md,高质量文件覆盖六大块:commands、testing、project structure、code style、git workflow、boundaries。建议控制在 60–150 行——再长信号被淹没,agent 反而抓不住重点。
监管/层级规则
AGENTS.md 的查找规则(Codex 文档定义、其他工具基本沿用):
~/.codex/AGENTS.override.md ← 全局,最高优先
~/.codex/AGENTS.md ← 全局
project/AGENTS.override.md ← 项目根
project/AGENTS.md ← 项目根
project/services/payments/
AGENTS.override.md ← 子目录,覆盖父级
AGENTS.md
走到当前工作目录就停,"最近的 AGENTS.md 赢"。可以在 monorepo 的每个 package 放一份,各管各的约定。
CLAUDE.md 在 Claude Code 里也支持类似的多层叠加,但合并语义略不同——所有层都加载、累加,不是覆盖。
"harness.md" 这类工作流文档
这是另一类——不是工具规范,是项目自己定义的工作流文档。在 agent 编程社区里非常流行,名字没标准。常见的有:
harness.md / HARNESS.md
来自 claude-code-harness 这类项目。"harness" 指围绕模型搭建的脚手架:记忆、钩子、子代理、评审循环。文档通常描述这套脚手架怎么运作——哪个 agent 干什么、产出在哪里、谁审谁。
Plans.md
Plan 模式产物的固定落脚点。Claude 进入 plan 模式生成的计划写到这,工人 agent 读它执行,审阅 agent 读它验收。是 plan→work→review 循环的中枢。
SSOT.md(Single Source of Truth)
项目级真理源。当多个 agent 协作时,所有人都同意"这个文件说的算"。比如 API 契约、数据模型、状态机定义。
SPEC.md / REQUIREMENTS.md
需求或规格说明,agent 工作前必读。
ISSUE.md / TICKET.md
当前在处理的工单。BMad、SuperClaude 这类多 agent 框架用这个传递任务上下文。
ARCHITECTURE.md / DECISIONS.md
架构决策记录(ADR)。比 AGENTS.md 详细,存"为什么"。AGENTS.md 应该指向它们,而不是抄一遍。
PROGRESS.md / STATUS.md
工作日志。长任务里 agent 自己更新——做完一步打勾、卡住记 blocker,下次启动能续上。
CONTEXT.md
背景资料。无法塞进 AGENTS.md 但 agent 需要知道的事(业务术语表、客户名单、历史包袱)。
EVAL.md / eval/*.md
评估用例和验收标准。agent 自检和审阅 agent 用。
CHANGELOG.md for agents
有些项目把"agent 改了什么"和"人改了什么"分开记录。
RUNBOOK.md / PLAYBOOK.md
固定操作手册。"如何部署"、"如何回滚"——和真实运维 SRE 的 runbook 一回事。
一个成熟项目的全景
把这些组合起来,一个深度配置过的项目通常长这样:
project/
├── README.md # 给人看
├── AGENTS.md # 给所有 AI 工具看(→ CLAUDE.md 软链)
├── CLAUDE.md # Claude 专用(或软链 AGENTS.md)
├── ARCHITECTURE.md # 架构决策
├── CONTRIBUTING.md # PR 流程
├── docs/
│ ├── TYPESCRIPT.md # AGENTS.md 链到这里
│ ├── TESTING.md
│ └── API.md
├── Plans.md # 当前计划(plan 模式产出)
├── PROGRESS.md # 长任务进度
├── SSOT.md # 真理源
├── .github/
│ ├── copilot-instructions.md # Copilot 专用
│ └── agents/
│ ├── docs-agent.md
│ └── test-agent.md
├── .cursor/rules/ # Cursor 专用
│ └── *.mdc
└── .claude/ # Claude Code 配置(你已经熟了)
├── agents/, skills/, hooks/, ...
└── ...
子目录里再叠:
packages/api/
├── AGENTS.md # API 包专属约定
└── CLAUDE.md # 同上
"AI 文档"的设计哲学
社区在两年探索里收敛出几条共识:
1. 渐进式披露(Progressive disclosure) AGENTS.md 别写成百科全书——保持精炼,链到详细文档。agent 需要时自己去读。这跟 SKILL.md 里 description 简短、正文延迟加载是同一思路。
## TypeScript 约定 详见 [docs/TYPESCRIPT.md](./docs/TYPESCRIPT.md)
2. 命令优先 agent 最常查的就是"怎么测、怎么构建"。把可执行命令放最前,连参数一起写完整。
3. 边界要硬 "NEVER touch X"、"ALWAYS run Y before Z"——用大写强调。agent 真的会照做。这比 50 条"建议"有效。
4. 描述能力,不描述结构 别写 "src/components 里有 Button.tsx"——这会过时。写 "UI 组件在 src/components",让 agent 自己探。
5. 写完就测 开 session 改一个文件,看 agent 是否遵守约定。违反 = 加强措辞或上提优先级。AGENTS.md 是活文档,迭代写。
6. 一句话项目自述 开篇一句 "This is a React component library for accessible data visualization" 顶 10 句空话——它给 agent 一个角色锚点。
实务总结
如果你只想做一件事:
# 1. 写一份 AGENTS.md(60–150 行,六大块) # 2. 软链到 CLAUDE.md(让 Claude Code 也读) ln -s AGENTS.md CLAUDE.md # 3. 用 GitHub Copilot 的话再软链一份 mkdir -p .github && ln -s ../AGENTS.md .github/copilot-instructions.md
这就覆盖了 90% 的常见 AI 工具,一份文档喂全家。
harness.md、Plans.md、SSOT.md 这类只在你真的做多 agent 编排时才需要——单人单 agent 写代码用不到,会过度工程化。
版权属于:BLOG DEWEBSTUDIO 本文作者:狒狒
原文地址: http://blog.dewebstudio.com/?post=158
版权声明:转载时必须以链接形式注明原始出处及本声明。
继续浏览:

发表评论