大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



副标题：进阶用户的系统性配置指南，让 Claude 自动选择最优工具链

你可能好奇：为什么 Claude 能在遇到”查找 GitHub Issues”任务时，自动调用 gh CLI 而不是让我去浏览器手动操作？为什么分析 API 数据时，自动组合 gh api | jq 而不是粘贴到在线工具？

答案：Claude 的”主动性”来自三层能力叠加：

任务识别 → 工具知识库 → 自动选择最优方案

真实演示（刚才的对话）：

1. 用户说：”安装 GitHub CLI” → Claude 判断：这是 Windows 环境，brew 不适用 → 自动选择：winget install GitHub.cli
2. 用户说：”查看 GitHub 用户信息” → Claude 判断：已认证 gh，可直接调用 API → 自动组合：gh api users/xxx | jq（高速解析）
3. 用户说：”搜索代码中的 Service 类” → Claude 判断：ripgrep 自动跳过 .gitignore、比 grep 快 10-100 倍 → 自动执行：rg "class.*Service" –type java -c | jq（统计分析）

关键洞察：

• ✅ Claude 记住了工具能力（安装后不会忘记）
• ✅ Claude 有判断逻辑（任务类型 → 工具匹配）
• ✅ Claude 遵循**实践（优先专用工具，组合优化）
• ✅ Claude 主动执行（无需用户明确指定工具名称）

这篇文章的核心目标： 帮你配置出这样的 Claude —— 面对任务时，自动选择最优工具链，而非每次都要你指导”用 XX 工具”。

---

Windows 环境推荐安装：

# GitHub CLI（操作 PR、Issue、API） winget install GitHub.cli gh auth login

jq（JSON 解析、API 数据处理）

winget install jqlang.jq

ripgrep（高速代码搜索，自动跳过 .gitignore）

winget install BurntSushi.ripgrep.MSVC

为什么 CLI 优于 MCP：

经验法则： 能用 CLI 完成的，优先用 CLI；MCP 只用于没有 CLI 的数据源。

---

精简原则（检验标准）：

对每一行问：”如果删掉这行，Claude 会犯错吗？” 如果不会，就删掉。

进阶用户的 CLAUDE.md 模板（控制在 <2000 tokens）：

# 项目：Maple Cart Mall 电商系统（Spring Boot + Vue 3）。架构见 @README.md。

构建与测试

• 后端：mvn clean install -pl maple-modules/maple-mall -am
• 前端：cd maple-netdisk-ui && pnpm dev
• 测试单个：mvn test -Dtest=UserServiceTest -DskipTests=false

工具优先级（CRITICAL）

• IMPORTANT: 代码搜索用 ripgrep（rg），不要用 grep
• IMPORTANT: JSON 处理用 jq，不要粘贴到在线工具
• IMPORTANT: GitHub 操作用 gh CLI，不要手动浏览器访问

代码规范

• Java：Alibaba 规范，UTF-8，LF 换行
• Vue：函数式组件 + hooks，Tailwind CSS
• 测试：80% 覆盖率，TDD 先写测试

工作流

• YOU MUST: 修改代码后运行测试验证
• NEVER: 不要修改 migrations/ 下的已有文件
• 提交遵循 Conventional Commits（feat/fix/refactor）

  关键点：

  • ✅ 用 IMPORTANT 强调工具优先级 —— Claude 更遵从
  • ✅ 只写 Claude 猜不到的信息（如”ripgrep 比 grep 快”、”用 gh 不要浏览器”）
  • ✅ 详细 API 文档用 @README.md 引用，不重复粘贴

  ---

  常见安全命令预批准：

  { "permissions": { "allow": [ "Bash(mvn test *)", "Bash(pnpm lint)", "Bash(pnpm test)", "Bash(git commit *)", "Bash(git push *)", "Bash(rg *)", "Bash(jq *)", "Bash(gh )" ], "deny": [ "Read(.env)", "Read(.env.)", "Bash(curl *)", "Bash(rm -rf *)" ] } }

  Boris 的原则： /permissions 预批准而非 –dangerously-skip-permissions —— 前者是有意识的安全决策，后者是关闭安全门。

  ---

  PostToolUse Hook：自动格式化

  { "hooks": { "PostToolUse": [ { "matcher": "Edit|Write", "command": "pnpm prettier –write "$FILE_PATH"" } ] } }

  Stop Hook：强制验证（防止 Claude 停在半完成状态）

  { "hooks": { "Stop": [ { "command": "pnpm test", "description": "验证测试通过才允许停止" } ] } }

  关键区别：

  维度 CLAUDE.md 规则 Hooks 驱动模型 建议性（AI 可能忽略） 事件驱动，确定性执行 执行保证 不保证 退出码 0 继续，退出码 2 阻止 适用场景 “应该做什么” “必须发生什么”

  ---

  Skills 解决的核心问题： 如何在保持上下文轻量的同时提供大量专业知识？

  答案： AI 按需加载 —— description 常驻（~2%），完整内容仅在调用时加载。

  实战示例：

  # .claude/skills/review/SKILL.md — name: review description: 代码审查当前变更 —

审查当前分支相对于 main 的所有变更。

1. git diff main --name-only 列出变更文件
2. 逐个审查，检查安全漏洞、性能、边界情况
3. 按严重度（Critical/Warning/Suggestion）输出

   调用：

   > /review # Claude 自动加载完整审查流程

   对比 Slash Commands：

   维度 Slash Commands Skills 本质 命令式：”去做这件事” 声明式：”我是一种能力” 发起者 用户主动调用 AI 自发现匹配任务 上下文 共享主会话 按需加载（description 常驻）

   ---

   关键规则：

   一次调试会话或代码库探索就可能产生数万 token。当上下文接近上限时，Claude 可能”遗忘”早期指令或犯更多错误。

   上下文效率目标：

   指标 目标 说明 基础上下文消耗 < 20K tokens 占 200K 的 10% CLAUDE.md 大小 < 2000 tokens 60-80 行以内 MCP 工具定义总量 < 20K tokens 空闲也占空间 上下文清理频率 每 ~60K tokens 在 30% 而非上限时清理

   ---

   任务切换 → /clear（最简单有效） 上下文快满 → /compact 聚焦关键决策 Claude 反复犯错 → /clear + 更好的提示词（而非反复修正） 需要探索但不确定范围 → 用子代理隔离（不污染主上下文）

   陷阱：反复修正

   表现：Claude 做错了，你修正它，还是错，再修正……上下文被失败方案污染。

修复：修正两次后，立即 /clear，融合前两轮学到的信息写更好的提示词。

---

为什么需要子代理：

可以把主 Claude 会话想象成 CTO，子代理是各部门总监 —— 专注安全审计、测试覆盖、调试分析，各自有独立上下文窗口。

实战配置：

# .claude/agents/security-reviewer.md

name: security-reviewer description: 审查代码安全漏洞 tools: Read, Grep, Glob, Bash

model: opus

你是一名高级安全工程师。审查代码的：

• 注入漏洞（SQL、XSS、命令注入）
• 认证和授权缺陷
• 代码中的密钥或凭证

提供具体行号引用和修复建议。

调用技巧：

> 用子代理调查 auth 模块的安全问题 # Claude 自动委托给 security-reviewer

---

快捷键：

• Esc：停止 Claude，保留上下文
• Esc + Esc 或 /rewind：打开回退菜单
• /clear：清空上下文，开始新任务

经验法则：

检查点只追踪 Claude 的修改，不能替代 Git。但在 Claude 反复犯错时， /rewind 比 Git checkout 更快 —— 不需要手动 reapply 正确的部分。

---

核心痛点：

每次开启新会话都要重新解释项目背景、架构决策、已完成的工作？

解决方案：项目记忆系统

Claude Code 提供了持久化的记忆存储，新会话会自动加载项目记忆，无需重复说明。

---

记忆存储位置：

项目根目录/.claude/memory/ ├── MEMORY.md # 记忆索引（自动加载） └── session-*.md # 具体会话记录

---

实战演示：

假设你在会话 A 完成了重要工作：

# 会话 A：完成聚合网盘 Controller 实现 > 实现了 4 个 Controller，54 个 REST 端点 > OAuth 授权流程完整可用 > Service 层还有 10 处 TODO 需修复

Claude 自动或手动触发记忆保存

> /remember # 使用 remember 技能保存成果

remember 技能会自动：

1. ✅ 提取关键发现（已完成的工作、重要决策）
2. ✅ 写入 .claude/memory/session-2026-04-17-xxx.md
3. ✅ 更新 MEMORY.md 索引文件

---

新会话 B 如何使用：

# 会话 B：继续完成剩余工作 > 开启新会话

Claude 自动加载 MEMORY.md，看到：

✅ "上次完成了 4 个 Controller" ✅ "还有 10 处 Service TODO 需修复" ✅ "OAuth 授权流程已打通"

> 继续修复 Service 层的 TODO

Claude 立即知道上下文，无需你重新解释！

---

手动查看记忆：

# 查看项目记忆索引 cat .claude/memory/MEMORY.md

查看具体会话记录

cat .claude/memory/session-2026-04-17-netdisk-controller-fix.md

---

记忆分类原则：

关键规则：

不要把所有内容都塞进一个记忆文件。保持简洁、结构化、可索引。

---

**实践：

✅ 系统性修复工作 → 使用 /remember 自动保存
✅ 重大架构决策 → 手动写入 MEMORY.md
✅ 临时调试笔记 → Notepad（不持久化）
✅ 重复出现的模式 → 考虑写入 CLAUDE.md（而非 memory）

---

与其他能力的对比：

---

经验法则：

在关键节点（完成重要功能、发现关键问题、做出架构决策）主动使用 /remember —— 新会话的 Claude 会感谢你的前瞻性。

---

核心洞察：

新上下文让代码审查更客观 —— Claude 不会偏向自己刚写的代码。

实操流程：

会话 A（Writer）： > 实现用户认证功能，包含登录、注册、密码重置

会话 B（Reviewer，独立会话）： > 审查会话 A 的代码变更。检查安全漏洞、边界情况、测试覆盖。 > 指出问题后，回到会话 A 修复。

---

核心价值：

每个 Claude 会话独立工作目录，互不干扰 —— 一个人当一个团队用。

实操：

# 终端 1：功能开发 claude –worktree feature-auth

终端 2：Bug 修复

claude –worktree bugfix-123

终端 3：测试编写

claude –worktree add-tests

Boris 的实践：

日常同时维护 3-5 个 worktrees，最长的一次 Claude 运行持续了 42 小时。

---

核心概念：

# Claude 变成函数：f(输入) → 输出 git diff HEAD~3 | claude -p "总结这些变更的影响" > summary.txt

关键参数：

# 免确认执行（避免阻塞） claude -p "修复 lint 错误" –allowedTools "Edit,Bash(npm run lint)"

结构化输出（强制 JSON）

claude -p "提取所有 API 端点" –json-schema ‘{"type":"array","items":{"type":"string"}}’

---

自动修复 CI 失败：

name: Auto Fix CI on: check_run:

types: [completed] 

jobs: fix:

if: github.event.check_run.conclusion == 'failure' runs-on: ubuntu-latest steps: - uses: anthropics/claude-code-action@v1 with: anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }} prompt: "修复失败的 CI 测试"

---

Boris 的日常配置是 Opus + High Effort，用于所有任务。他认为最强模型 + 深度推理是产出高质量代码的基础。

配置方式：

/model # ← → 箭头键调节 Effort Level 滑块

---

给 Claude 一个反馈循环，它就能自我纠正。不给反馈循环，它就在猜。

验证策略：

---

Boris 的日常流程：先让 Claude 在 Plan Mode 下理解代码、生成计划，然后用第二个 Claude 会话审计这个计划的合理性，确认后才开始编码。

切换方式：

Shift+Tab # 循环：Normal → Auto-Accept → Plan

---

Boris 大量使用 macOS 语音输入（按两次 fn 键）。语音天然产出更详细的描述，而 Claude 擅长理解非结构化的自然语言。

---

> grill me on these changes and don't make a PR until I pass your test 

> prove to me this works. diff main 和 feature branch 的行为差异 > knowing everything you know now, scrap this and implement the elegant solution > play devil’s advocate

关键洞察：

这些提示利用了 Claude 的推理能力，比简单的”帮我实现 X”能得到更深思熟虑的结果。

---

---

---

---

---

---

本指南中的模式不是一成不变的 —— 它们是在一般情况下有效的起点。

注意观察什么有效：

• 当 Claude 产出优秀结果时，回忆你做了什么：提示词结构、提供的上下文、使用的模式。
• 当 Claude 挣扎时，问为什么：上下文太嘈杂？提示词太模糊？任务太大不适合一轮完成？

随着时间推移，你会发展出直觉：

• 何时该具体、何时该开放
• 何时该计划、何时该探索
• 何时该清空上下文、何时该让它积累

最终目标： 配置出一个 Claude，面对任务时自动选择最优工具链，让 AI 从”被动响应”变为”主动高效协作”。

---

精选资源（持续更新）：

• 官方**实践：https://docs.anthropic.com/claude-code/best-practices
• Boris Cherny 的 Workflow（X 平台）：搜索 “Boris Cherny Claude Code”
• Superpowers 技能框架：https://github.com/musistudio/superpowers
• everything-claude-code（社区配置集合）：https://github.com/everything-claude-code

---

作者经验：

本文基于 Claude Code 官方**实践文档、Boris Cherny 的真实工作流分享，以及作者在实际项目（Maple Cart Mall）中的配置经验总结。

关键实践验证：

• ✅ 工具链组合：gh + jq + ripgrep（实际演示）
• ✅ Worktree 并行：同时维护 3 个 worktrees
• ✅ Headless 自动化：GitHub Actions CI 自动修复
• ✅ Writer/Reviewer 模式：独立会话审查质量提升

---

本文由mdnice多平台发布