Appearance
真正拉开差距的，根本不是你那一句prompt写得有多漂亮。而是你有没有把
.claude这套配置栈搭起来。
现在，打开终端，进入你的主力AI项目，运行：
bash
tree .claude对很多正在用Claude Code的工程师来说，结果大概率是：
command not found
或者，里面只有一个孤零零的文件，写着几句很虚的指令，比如"请写干净代码""请遵循最佳实践"。
这也不是不能用。但这等于把Claude Code 80%的能力直接扔在地上。
一个真正被power user配好的仓库长这样
.claude/
├── CLAUDE.md # 主记忆文件
├── rules/ # 路径级规则
│ ├── langgraph.md
│ ├── retrieval.md
│ ├── tests.md
│ └── python-types.md
├── agents/ # 自定义子代理
│ ├── retrieval-reviewer.md
│ ├── prompt-auditor.md
│ └── eval-runner.md
├── skills/ # 技能包
│ ├── new-rag-eval/
│ └── claude-pr-checklist/
├── settings.json # 权限和hooks
└── .mcp.json # MCP服务器配置重点不是文件多。重点是，每个文件都很短、很准、很有边界。
第一层：Memory Hierarchy
Claude Code有一套五层memory hierarchy：你的个人偏好、项目根目录文件、路径级规则、本地未提交覆盖，以及每个session自动写入的memory。
根memory文件应该短。控制在200行以内。语气要命令式。
比如一个RAG service的最小可用CLAUDE.md：
markdown
# citation-rag
Retrieval + answer-generation service. LangGraph-based pipeline,
PostgreSQL+pgvector retrieval, Gemini answer generation, eval harness in `evals/`.
## Layout
- `services/retrieval/` — chunking, embedding, reranker, citation packer
- `services/answer/` — prompt templates, generator node, guardrails
- `shared/` — schemas, tracing, settings
- `evals/` — golden sets, runners, scoring
## Build & test
- Install: `uv sync`
- Unit tests: `uv run pytest -q`
- Eval harness: `uv run python -m evals.run --suite citations`
## Canonical conventions
- The canonical answer prompt lives at `services/answer/prompts/v4.md`.
- All LLM outputs are validated with the pydantic models in `shared/schemas/answers.py`.
- Retrieval always returns `Chunk` objects with a `citation_id`.
## Guardrails
- Never bump the model version string without updating `evals/snapshots/<version>.json`.
- Never introduce network calls inside `tests/unit/`.
- Keep functions under ~40 lines.这才是memory文件该做的事。不是塞知识库，而是放真正高频、关键、会影响决策的规则。
第二层：Path-Scoped Rules
把根memory控制住之后，文件级、目录级的特殊规则放进path-scoped rules。
这种模式通常用YAML frontmatter。你定义一组glob paths，**只有当Claude触碰匹配文件时，规则才会加载。平时，它
