Everything Claude Code - 12 个核心观点与实践方案

通过控制 MCP 工具数量、按项目禁用不需要的 MCP Server、根据任务复杂度选择模型来最大化有效上下文窗口。核心数据：200k 上下文窗口在开太多 MCP 工具后可能缩到 70k。

Claude Code 的 system prompt 里会注入所有已启用 MCP 的工具定义。每个 MCP Server 可能贡献数十个工具描述，占用大量 token。当你启用了 Playwright + Pencil + Context7 + Supabase + GitHub 等多个 MCP，system prompt 本身就可能消耗 100k+ token，留给实际对话和代码的上下文大幅缩水。

• 总量控制：全局配置 20-30 个 MCP Server，但每个项目只启用需要的那几个（<80 个工具）
• 项目级禁用：在 .claude/settings.local.json 中用 disabledMcpServers 按项目禁用不需要的 MCP
• 模型选择：简单任务（格式化、重命名、简单搜索）用 Haiku；中等任务用 Sonnet；复杂架构决策用 Opus
• 手动压缩：长会话中感觉变慢/遗忘时，用 /compact 手动触发上下文压缩

高度匹配。你的项目同时启用了 Playwright、Pencil、Context7 等 MCP，加上 CLAUDE.md 本身就很长（约 15k+ 字符），上下文压力大。尤其做设计任务时 Pencil 的工具定义量巨大。

1. 检查当前启用的 MCP 数量：cat ~/.claude/settings.json | grep -c mcp
2. 为 QQnails 项目创建 .claude/settings.local.json 的 disabledMcpServers 列表，做后端开发时禁用 Pencil/Playwright，做设计时禁用 Context7
3. 在 Task 工具调用中，简单查询任务显式指定 model: "haiku" 节省 token

在 AI 辅助开发中引入系统性的验证机制，确保生成的代码符合预期。分两种模式：

还引入了 pass@k 指标：衡量 agent 在 k 次尝试中至少成功一次的概率，用于评估 agent 可靠性。

AI 生成代码有概率出错。不加验证循环的工作流相当于"盲信 AI"，bug 会在后续步骤雪崩式放大。验证循环的核心理念是：生成 → 验证 → 修正 → 再验证，而不是生成后直接进入下一步。

• 定义 /verify 命令：运行 lint + test + 类型检查，一键验证当前状态
• 定义 /checkpoint 命令：在 Git 中创建临时 commit 或 stash，标记当前已验证状态
• 在 skill 中嵌入验证步骤：每个 skill 的最后一步都是"运行相关测试 + lint"
• pass@k 追踪：记录每个 agent 类型的成功率，识别可靠性低的 agent 并优化 prompt

中高匹配。你的项目有完善的测试体系（465+ 测试文件），但目前验证是手动的（写完代码后手动跑测试）。可以把"跑测试"这一步标准化到每个 skill/command 里面。

1. 创建一个 .claude/commands/verify.md 命令，内容为"运行 npm run lint && npm run test:backend -- --bail，报告结果"
2. 养成习惯：每完成一个功能模块，先跑 /verify 再继续下一步
3. 大型重构前用 git stash 或临时 commit 做 checkpoint

利用 Git Worktrees、Cascade 方法和多实例扩展来加速开发。三种模式：

• Git Worktrees：在同一仓库中创建多个工作目录，每个 worktree 对应不同分支，互不干扰。可以同时在多个终端/Claude 实例中开发不同功能。
• Cascade 方法：Agent A 的输出作为 Agent B 的输入，形成链式处理。例如：架构 agent → 编码 agent → 测试 agent → 审查 agent。
• 实例扩展：计算密集型任务启动多个 Claude 实例并行处理，适合批量文件处理（如你的 i18n 重构）。

单线程开发是 AI 辅助编程的最大瓶颈。一个 Claude 实例在跑测试时，你（或另一个实例）完全可以做别的事。Git Worktrees 让你无需 clone 多份代码就能并行开发。

# 创建 worktree（不影响主工作目录）
git worktree add ../qqnails-feature-x feature-x
git worktree add ../qqnails-bugfix-y bugfix-y

# 列出所有 worktrees
git worktree list

# 完成后清理
git worktree remove ../qqnails-feature-x

每个 worktree 可以打开独立的终端运行 Claude Code，互不干扰。

高度匹配。你经常做的 i18n 批量重构、测试覆盖率提升这类任务，天然适合并行化。比如同时用一个实例改前端，另一个实例写后端测试。

1. 下次需要同时做两个不相关的任务时，用 git worktree add 创建第二个工作目录
2. 批量 i18n 重构可以按目录拆分，多个实例分别处理不同目录
3. 大型 spec 实施时，前后端可以在不同 worktree 里并行开发

用一组专用 agent 分工协作完成复杂任务。核心思想：

• 任务分解：/multi-plan 把大目标拆成可并行的子任务
• 迭代检索（Iterative Retrieval）：agent 之间不直接传递全部上下文，而是逐步精炼，每次只传递需要的信息，防止上下文爆炸
• PM2 管理：用 PM2 管理多个后台 agent 进程，实现任务队列和负载均衡

单个 agent 的上下文窗口有限。当任务涉及多文件、多领域时，单 agent 容易丢失重要上下文。多 agent 的优势：

• 每个 agent 专注一个领域，prompt 更精准
• 失败隔离：一个 agent 出错不影响其他
• 可并行执行独立子任务

中等匹配。你已经在用 Task 工具做子代理了（Explore、Bash 等），但还没有系统性的编排。你的项目规模（后端 + 前端 + 3 个 Flutter app）很适合多代理模式。

1. 创建几个常用的自定义 agent：.claude/agents/code-reviewer.md（只读审查）、.claude/agents/test-writer.md（专写测试）
2. 大 spec 实施时，先用 Plan agent 拆任务，然后分配给不同 agent 并行执行
3. 在 TeamCreate 工作流中实践 leader-worker 模式

通过 Hook 自动观察用户行为，提取编码偏好为"直觉"（Instinct），带置信度评分，跨会话持久化。核心数据结构：

{
  "trigger": "写 TypeScript 函数时",
  "action": "优先用函数式写法而非 class",
  "confidence": 0.7,        // 0.3-0.9
  "domain": "code-style",   // code-style | testing | git | debugging | workflow
  "evidence": 3,            // 观察到 3 次用户纠正
  "decay_rate": 0.02         // 每周期衰减 0.02
}

解决 Claude Code 的"失忆问题"。每次新会话，Claude 不知道你喜欢什么写法、什么工具、什么测试方式。目前你用 MEMORY.md 手动记录，但覆盖面有限。自动化可以捕获你意识不到的隐性偏好。

完整流水线：

PreToolUse/PostToolUse Hook 捕获
  ↓
observations.jsonl 存储（10MB 上限，7 天归档）
  ↓
后台 Haiku agent 每 5 分钟分析（需 20+ 条观察）
  ↓
检测信号：用户纠正 / 错误解决路径 / 重复工作流 / 工具偏好
  ↓
生成/更新 instinct（置信度 0.3 起步，0.7+ 自动采纳）
  ↓
/evolve 聚类：3+ 相关直觉 → skill / command / agent

置信度动态：

中等。你已经有 MEMORY.md 手动记忆系统，效果不错。这套自动系统的增量价值在于：能捕获你没意识到的偏好（比如"你总是先读文件再编辑"、"你倾向用 Grep 而不是 Bash grep"）。但部署成本较高，需要 Python CLI + Hook 配置 + 后台 Haiku 消耗。

1. 轻量版实践：不用装整套系统，但可以借鉴思路 — 每周花 5 分钟回顾本周会话，手动提取 2-3 个新发现的偏好写入 MEMORY.md
2. 进阶版：写一个简单的 PostToolUse hook，记录每次工具调用到 JSONL 文件，月底分析统计
3. 团队场景下，instinct-export/import 的思路很好 — 可以把你的 MEMORY.md 做成可分享的模板

利用 Claude Code 的 Hook 系统在特定事件发生时自动执行脚本。四个触发点：

Hook 是 Claude Code 最强大但最被低估的功能。它让你可以：

• 防护：阻止 Claude 删除重要文件、修改 .env、push 到 main
• 自动化：每次编辑 .ts 文件后自动跑 lint；每次 Git commit 后自动跑测试
• 记录：追踪所有工具调用，事后分析 Claude 的行为模式
• 增强：给 Claude 注入额外上下文（如"这个文件最近被改过 5 次，注意"）

在 .claude/settings.local.json 中配置 hooks：

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "tool == 'Edit' && tool_input.file_path matches '\\.(ts|tsx)$'",
        "command": "node .claude/hooks/check-ts-edit.js"
      }
    ],
    "PostToolUse": [
      {
        "matcher": "tool == 'Write'",
        "command": "node .claude/hooks/log-write.js"
      }
    ],
    "SessionStart": [
      {
        "command": "node .claude/hooks/load-context.js"
      }
    ]
  }
}

高度匹配。你的项目有明确的规范（禁止硬编码、禁止直接角色检查、禁止 AWS RDS 引用），这些规则完全可以通过 PreToolUse hook 自动检查，而不是靠 CLAUDE.md 里的文字提醒。

1. 第一步：创建一个 PreToolUse hook，检查 Edit/Write 工具是否在修改 .env 文件，如果是则提示确认
2. 第二步：创建一个 PostToolUse hook，检查新写入的 JS 文件是否包含 role === 'admin'（违反 RBAC 规范）
3. 第三步：创建 SessionStart hook，自动读取最近的 Git log 和 TODO 列表注入到上下文

根据当前任务类型，动态注入不同的 system prompt 补充内容。比如：

• dev.md — 开发模式：包含编码规范、测试要求、文件结构
• review.md — 审查模式：包含安全 checklist、性能关注点、代码质量标准
• research.md — 研究模式：包含搜索策略、信息整理格式、竞品分析框架

你的 CLAUDE.md 有 15k+ 字符，每次会话都会全量注入。但实际上：

• 做后端开发时不需要 Flutter 和 Landing Page 的信息
• 做 i18n 重构时不需要数据库架构信息
• 做竞品调研时不需要测试规范

动态上下文的核心是按需注入，减少噪音。

• 创建多个上下文文件：.claude/contexts/backend-dev.md、.claude/contexts/frontend-dev.md、.claude/contexts/i18n-refactor.md
• 通过 SessionStart hook 根据当前分支名或目录自动加载对应上下文
• 或手动通过 slash command /context backend 切换

高度匹配。你的 CLAUDE.md 信息密度很高（多租户架构、测试规范、PM2 管理、Flutter 配置……），不同任务场景只需要其中一部分。拆分后能显著减少无关上下文消耗。

1. 把 CLAUDE.md 里的内容按领域拆分成 3-4 个 context 文件（保留 CLAUDE.md 作为核心，context 文件作为补充）
2. 创建 .claude/commands/ctx-backend.md、.claude/commands/ctx-frontend.md 等快捷命令
3. 配合分支命名规范（###-feature-name），用 SessionStart hook 根据分支前缀自动选择上下文

把 Claude Code 的行为规则按层级组织，而不是堆在一个 CLAUDE.md 里：

~/.claude/rules/           # 用户级（所有项目）
  common/
    coding-style.md        # 通用编码风格
    git-workflow.md        # Git 提交规范
    testing.md             # 测试标准
    security.md            # 安全规范
  typescript/
    style.md               # TS 特定规则
    patterns.md            # TS 设计模式
  python/
    style.md               # Python 规则

.claude/rules/             # 项目级（仅当前项目）
  rbac-enforcement.md      # RBAC 强制规则
  multi-tenancy.md         # 多租户规范
  i18n-requirements.md     # 国际化要求

当前你所有规范都堆在 CLAUDE.md 里，问题：

• 文件过长，Claude 可能"选择性遗忘"靠后的规则
• 不同项目不能复用（CLAUDE.md 绑定仓库）
• 修改一条规则需要编辑整个大文件

分层后：每条规则独立文件，按需加载，跨项目复用。

• 在 ~/.claude/rules/ 下创建按领域分类的规则文件
• 每个文件聚焦一个主题，保持 50-100 行以内
• 项目特定规则放 .claude/rules/（跟着仓库走）
• CLAUDE.md 保留核心概览，详细规则引用 rules 目录

高度匹配。你的 CLAUDE.md 现在包含了架构、规范、端口配置、测试命令、安全规则……全混在一起。分层后，做 i18n 任务时只加载 i18n rules，做安全审计时只加载 security rules。

1. 先从 CLAUDE.md 中提取 3 个高频规则到独立 rules 文件：RBAC 规范、多租户规范、命名规范
2. 创建 ~/.claude/rules/common/ 目录，放入通用编码规则（可在其他项目复用）
3. 逐步瘦身 CLAUDE.md，只保留项目概览和快速参考

/skill-create 命令分析仓库的 Git commit 历史，自动提取反复出现的开发模式，生成 SKILL.md 技能定义文件。可选加 --instincts 同时生成直觉集合。

两种模式：

你的仓库已经有几千个 commit，里面蕴含大量模式：

• "每次新增 API 端点都会修改哪些文件？"
• "每次做 i18n 重构的步骤是什么？"
• "Bug 修复通常涉及哪些目录？"

这些模式人工总结效率低，但 Git 历史里全有。

中等。概念很好，但目前 Claude Code 官方没有内置这个功能，需要用第三方工具。不过核心思路 — "从历史中提取模式" — 你可以手动实践。

1. 手动版：跑 git log --oneline --since="2026-01-01" | head -100，分析你最近 100 个 commit 的模式
2. 把发现的模式写成 .claude/skills/（比如 add-api-endpoint.md — "新增 API 端点标准流程"）
3. 如果想尝试自动化，可以装 Everything Claude Code 作为 plugin 试用 /skill-create

一组只读的专用审查 agent，分别负责不同维度的代码质量检查：

关键优势是权限隔离：审查 agent 只有 Read 权限，不会意外修改代码。这比让一个全能 agent "顺便审查一下"安全得多。而且每个 agent 的 prompt 可以针对性优化，比通用 prompt 更精准。

创建 .claude/agents/code-reviewer.md：

---
name: code-reviewer
description: 只读代码审查 agent，检查代码质量和最佳实践
tools: [Read, Grep, Glob]
---

你是一位资深代码审查员。你的职责是：
1. 检查代码可读性和命名规范
2. 识别潜在 bug 和边界情况
3. 评估错误处理是否完善
4. 检查是否违反项目规范（RBAC、多租户、i18n）

输出格式：
- 严重问题 (必须修复)
- 建议改进 (可选)
- 优点 (好的实践)

高度匹配。你的 CLAUDE.md 有大量规范（RBAC、多租户、命名约定、安全规则），这些规则塞给一个专用审查 agent 比塞给通用 agent 效果好得多。

1. 创建 .claude/agents/code-reviewer.md，把 CLAUDE.md 里的代码审查检查项搬进去
2. 创建 .claude/agents/security-reviewer.md，聚焦 SQL 注入、XSS、权限检查
3. 每次 PR 前跑一次审查 agent，形成习惯

用 /tdd 命令和专用 agent 强制执行 Red-Green-Refactor 循环：

1. RED：先写一个会失败的测试，定义期望行为
2. GREEN：写最少代码让测试通过
3. REFACTOR：在测试保护下重构代码
4. VERIFY：运行完整测试套件确认无回归

Everything Claude Code 在 rules 里写死了 80% 覆盖率硬性要求。

AI 生成代码时容易"先写实现再补测试"，这样测试容易变成实现的镜像（而不是行为的验证）。TDD 反过来：先定义行为，再让 AI 写实现，测试质量更高。

• 创建 .claude/commands/tdd.md 命令模板：接收功能描述 → 生成测试 → 运行测试（应失败）→ 实现代码 → 运行测试（应通过）→ 重构
• 在 skill 里定义"先测试后编码"的严格顺序
• 把覆盖率检查作为最后一步自动运行

中高匹配。你的 CLAUDE.md 已经要求"关键流程必须先编写自动化测试"和"后端逻辑遵循 Red-Green-Refactor"，但实际执行时 Claude 经常跳过 Red 直接到 Green。用 skill/command 强制执行可以解决这个问题。

1. 创建 .claude/commands/tdd.md：指导 Claude 先写测试、确认测试失败、再写实现
2. 在 CLAUDE.md 或 rules 中明确"新增 service 必须用 /tdd 命令启动"
3. 使用 test-and-fix agent 类型来自动跑测试并修复

Everything Claude Code 把所有 hooks 从 bash/shell 重写为 Node.js，解决跨平台兼容问题。同时提供了智能包管理器检测（自动识别 npm/yarn/pnpm/bun）。

Bash hooks 的问题：

• Windows 上不可用（需要 WSL 或 Git Bash）
• macOS 和 Linux 的 bash 版本差异（macOS 默认 bash 3.x，很多语法不支持）
• Shell 脚本的错误处理能力弱

Node.js hooks 的优势：

• 所有平台一致行为（Node.js 是项目已有依赖）
• 更好的错误处理（try/catch）
• 可以直接读取 JSON 配置、调用项目 API
• 支持 async/await

// .claude/hooks/check-edit.js
const fs = require('fs');
const path = require('path');

// Hook 接收环境变量：TOOL_NAME, TOOL_INPUT, FILE_PATH
const toolName = process.env.TOOL_NAME;
const filePath = process.env.FILE_PATH || '';

// 检查是否在修改 .env 文件
if (filePath.endsWith('.env') || filePath.includes('.env.')) {
  console.error('WARNING: 正在修改环境变量文件，请确认！');
  process.exit(1); // 非 0 退出码会阻止工具执行
}

process.exit(0);

中等。你目前主要在 macOS 开发，短期内没有跨平台需求。但如果你开始写 hooks，直接用 Node.js 写而不是 bash 是正确的起手式，因为你的项目本身就是 Node.js 技术栈，维护成本更低。

1. 如果开始写 hooks，统一用 Node.js（不要用 bash）
2. 创建 .claude/hooks/utils.js 工具库，封装常用检查（文件路径匹配、JSON 读取等）
3. 所有 hook 脚本放 .claude/hooks/ 目录，跟着仓库走

按 投入产出比 排序的建议实施顺序：