普通视图

发现新文章,点击刷新页面。
今天 — 2026年3月2日首页

Everything Claude Code 文档

作者 王小酱
2026年3月2日 15:17

一、项目概述

Everything Claude Code(ECC) 是一个 AI Agent 工作框架性能优化系统,由 Anthropic Hackathon 获奖者 Affaan Mustafa 开发,历经 10 个月以上的生产环境实战积累。

它不只是配置文件的集合,而是一套完整的系统,包含:

  • Skills(技能):可复用的工作流定义
  • Instincts(直觉):持续学习,自动从会话中提取模式
  • Memory Optimization(记忆优化):跨会话上下文持久化
  • Security Scanning(安全扫描):AgentShield 集成,102 条规则
  • Research-first Development(研究优先开发):先调研再编码

支持平台:Claude Code、Codex CLI、Cursor IDE、OpenCode、Cowork 及其他 AI Agent 工作框架。


二、核心架构

目录结构总览

everything-claude-code/
├── .claude-plugin/         # 插件和市场清单(plugin.json, marketplace.json)
├── agents/                 # 13 个专业子代理(.md 文件)
├── .agents/skills/         # 技能定义(SKILL.md + openai.yaml)
├── commands/               # 32 个斜杠命令(.md 文件)
├── rules/                  # 编码规范(common/ + typescript/ + python/ + golang/)
├── hooks/                  # 触发式自动化(hooks.json + 脚本)
├── scripts/                # 跨平台 Node.js 脚本
├── contexts/               # 动态系统提示注入上下文
├── examples/               # CLAUDE.md 配置示例(Next.js、Go、Django 等)
├── mcp-configs/            # MCP 服务器配置(GitHub、Supabase、Vercel 等)
├── .cursor/                # Cursor IDE 适配层
├── .codex/                 # Codex CLI 适配层
├── .opencode/              # OpenCode 适配层
└── docs/                   # 完整文档

三、快速开始(2 分钟上手)

步骤一:安装插件(推荐)

# 添加为市场源
/plugin marketplace add affaan-m/everything-claude-code

# 安装插件
/plugin install everything-claude-code@everything-claude-code

或者直接在 ~/.claude/settings.json 中添加:

{
  "extraKnownMarketplaces": {
    "everything-claude-code": {
      "source": {
        "source": "github",
        "repo": "affaan-m/everything-claude-code"
      }
    }
  },
  "enabledPlugins": {
    "everything-claude-code@everything-claude-code": true
  }
}

步骤二:安装规则(必须手动)

⚠️ Claude Code 插件系统不支持自动分发规则文件,需手动安装。

git clone https://github.com/affaan-m/everything-claude-code.git
cd everything-claude-code

# 使用安装脚本(推荐)
./install.sh typescript          # TypeScript 项目
./install.sh python              # Python 项目
./install.sh typescript python   # 多语言项目

# 针对 Cursor
./install.sh --target cursor typescript

步骤三:开始使用

# 规划新功能
/everything-claude-code:plan "Add user authentication"

# 查看所有可用命令
/plugin list everything-claude-code@everything-claude-code

安装完成后你即可使用:13 个 Agents + 56 个 Skills + 32 个 Commands


四、核心模块详解

4.1 Agents(专业子代理)—— 13 个

Agent 描述
planner 功能实现规划
architect 系统设计决策
tdd-guide 测试驱动开发指导
code-reviewer 代码质量与安全审查
security-reviewer 漏洞分析(OWASP Top 10)
build-error-resolver 构建错误修复
e2e-runner Playwright E2E 测试
refactor-cleaner 死代码清理
doc-updater 文档同步更新
go-reviewer Go 代码审查
go-build-resolver Go 构建错误修复
python-reviewer Python 代码审查
database-reviewer 数据库/Supabase 审查

调用示例:

/everything-claude-code:plan "Add OAuth authentication"  # 触发 planner
/code-review                                              # 触发 code-reviewer
/security-scan                                            # 触发 security-reviewer

4.2 Skills(技能库)—— 56+ 个

Skills 是可复用的工作流定义,按领域分类:

通用开发:

  • coding-standards — 语言最佳实践
  • tdd-workflow — TDD 方法论(先写测试,80% 覆盖率)
  • security-review — 安全检查清单
  • eval-harness / verification-loop — 验证循环评估
  • search-first — 先调研再编码工作流
  • api-design — REST API 设计与分页、错误响应
  • deployment-patterns — CI/CD、Docker、健康检查、回滚

前端:

  • frontend-patterns — React、Next.js 模式
  • frontend-slides — 零依赖 HTML 演示文稿(含 PPTX 转换)
  • e2e-testing — Playwright E2E 测试 + Page Object Model

后端 & 数据库:

  • backend-patterns — API、数据库、缓存模式
  • clickhouse-io — ClickHouse 分析查询
  • postgres-patterns — PostgreSQL 优化
  • database-migrations — Prisma、Drizzle、Django、Go 迁移
  • docker-patterns — Docker Compose、网络、卷、容器安全

Python / Django:

  • django-patterns / django-security / django-tdd / django-verification
  • python-patterns / python-testing

Java Spring Boot:

  • springboot-patterns / springboot-security / springboot-tdd / springboot-verification
  • java-coding-standards / jpa-patterns

Go:

  • golang-patterns / golang-testing

Swift / iOS:

  • swift-actor-persistence — 基于 Actor 的线程安全数据持久化
  • swift-protocol-di-testing — 协议依赖注入可测试 Swift 代码
  • liquid-glass-design — iOS 26 Liquid Glass 设计系统
  • foundation-models-on-device — Apple 设备端 LLM
  • swift-concurrency-6-2 — Swift 6.2 并发特性

C++:

  • cpp-coding-standards — C++ Core Guidelines
  • cpp-testing — GoogleTest + CMake/CTest

学习与优化:

  • continuous-learning / continuous-learning-v2 — 自动从会话提取模式(含置信度评分)
  • strategic-compact — 手动压缩建议
  • cost-aware-llm-pipeline — LLM 成本优化、模型路由、预算追踪
  • iterative-retrieval — 子代理的渐进式上下文精炼

内容创作(新增):

  • article-writing — 无 AI 腔调的长文写作
  • content-engine — 多平台社交内容工作流
  • market-research — 带来源标注的市场研究
  • investor-materials — 融资 Pitch Deck、备忘录、财务模型
  • investor-outreach — 个性化融资外联与跟进

4.3 Commands(斜杠命令)—— 32 个

开发流程:

命令 用途
/plan "..." 创建功能实现计划
/tdd 强制执行 TDD 工作流
/code-review 审查代码变更
/build-fix 修复构建错误
/e2e 生成 E2E 测试
/refactor-clean 清除死代码
/security-scan 安全漏洞扫描
/test-coverage 测试覆盖率分析

Go 专项:

命令 用途
/go-review Go 代码审查
/go-test Go TDD 工作流
/go-build 修复 Go 构建错误

多代理编排:

命令 用途
/multi-plan 多代理任务分解
/multi-execute 编排多代理工作流
/multi-backend 后端多服务编排
/multi-frontend 前端多服务编排
/multi-workflow 通用多服务工作流
/pm2 PM2 服务生命周期管理
/orchestrate 多代理协调

持续学习系统:

命令 用途
/learn 会话中提取模式
/learn-eval 提取、评估并保存模式
/instinct-status 查看已学习的直觉(含置信度)
/instinct-import <file> 导入他人直觉
/instinct-export 导出直觉供分享
/evolve 将相关直觉聚类为技能

其他实用命令:

命令 用途
/checkpoint 保存验证状态
/verify 运行验证循环
/eval 按标准评估
/sessions 会话历史管理
/update-docs 更新文档
/skill-create 从 Git 历史生成技能
/setup-pm 配置包管理器

4.4 Hooks(触发式自动化)

Hooks 在工具事件发生时自动触发,示例:

{
  "matcher": "tool == \"Edit\" && tool_input.file_path matches \"\\.(ts|tsx|js|jsx)$\"",
  "hooks": [{
    "type": "command",
    "command": "grep -n 'console\\.log' \"$file_path\" && echo '[Hook] Remove console.log' >&2"
  }]
}

内置 Hook 脚本(Node.js,全平台兼容):

  • session-start.js — 会话开始时自动加载上下文
  • session-end.js — 会话结束时自动保存状态
  • pre-compact.js — 压缩前保存状态
  • suggest-compact.js — 建议压缩时机
  • evaluate-session.js — 从会话中提取模式

4.5 Rules(编码规范)

按语言分目录组织,安装时按需选择:

rules/
├── common/            # 通用原则(必装)
│   ├── coding-style.md    # 不可变性、文件组织
│   ├── git-workflow.md    # Commit 格式、PR 流程
│   ├── testing.md         # TDD、80% 覆盖率要求
│   ├── performance.md     # 模型选择、上下文管理
│   ├── patterns.md        # 设计模式
│   ├── hooks.md           # Hook 架构
│   ├── agents.md          # 子代理委托时机
│   └── security.md        # 强制安全检查
├── typescript/        # TypeScript/JavaScript 专项
├── python/            # Python 专项
└── golang/            # Go 专项

五、生态工具

5.1 AgentShield — 安全审计工具

Anthropic x Cerebral Valley Hackathon(2026年2月) 上构建,1282 个测试,98% 覆盖率,102 条静态分析规则。

# 快速扫描(无需安装)
npx ecc-agentshield scan

# 自动修复安全问题
npx ecc-agentshield scan --fix

# 深度分析(三个 Opus 4.6 代理:红队/蓝队/审计员)
npx ecc-agentshield scan --opus --stream

# 从零生成安全配置
npx ecc-agentshield init

扫描范围: CLAUDE.md、settings.json、MCP 配置、hooks、agent 定义、skills,覆盖 5 大类别:

  • 密钥检测(14 种模式)
  • 权限审计
  • Hook 注入分析
  • MCP 服务器风险评估
  • Agent 配置审查

输出格式: 终端彩色(A-F 评级)、JSON(CI 管道)、Markdown、HTML。

--opus 模式会运行三个 Claude Opus 4.6 代理组成红队/蓝队/审计员流水线:攻击者寻找漏洞链,防御者评估保护,审计员综合出优先级风险报告。这是对抗性推理,而非单纯的模式匹配。

在 Claude Code 中直接运行:/security-scan

5.2 Skill Creator — 技能生成器

方式 A:本地分析(内置)

/skill-create                  # 分析当前仓库
/skill-create --instincts      # 同时生成直觉

方式 B:GitHub App(高级)

适用于 10k+ commits、自动 PR、团队共享:

  • 安装:github.com/marketplace…
  • 在任意 Issue 中评论:/skill-creator analyze
  • 支持 push 到主分支时自动触发

5.3 持续学习系统 v2

/instinct-status    # 查看已学习的直觉及置信度
/instinct-import    # 导入他人的直觉
/instinct-export    # 导出自己的直觉分享给团队
/evolve             # 将相关直觉聚类成可复用技能

六、多平台支持详情

6.1 各平台功能对比

功能 Claude Code Cursor IDE Codex CLI OpenCode
Agents ✅ 13 个 共享(AGENTS.md) 共享 ✅ 12 个
Commands ✅ 33 个 共享 指令式 ✅ 24 个
Skills ✅ 50+ 共享 10 个 ✅ 37 个
Hook 事件数 8 种 15 种 ❌ 暂不支持 11 种
Rules ✅ 29 条 ✅ 29 条(YAML) 指令式 13 条
MCP 服务器 ✅ 14 个 共享 4 个 完整
自定义工具 通过 Hook 通过 Hook ✅ 6 个原生

6.2 Cursor IDE 快速接入

./install.sh --target cursor typescript
./install.sh --target cursor python golang swift

Cursor 的 Hook 使用 DRY 适配器模式,adapter.js 将 Cursor 的 stdin JSON 转换为 Claude Code 格式,复用现有脚本无需重写。

关键 Hook:

  • beforeShellExecution — 阻止在 tmux 外启动开发服务器,审查 git push
  • afterFileEdit — 自动格式化 + TypeScript 检查 + console.log 警告
  • beforeSubmitPrompt — 检测提示词中的密钥(sk-ghp_AKIA 等)
  • beforeTabFileRead — 阻止读取 .env.key.pem 文件

6.3 Codex CLI 快速接入

cp .codex/config.toml ~/.codex/config.toml
codex  # AGENTS.md 自动被检测

⚠️ Codex CLI 暂不支持 Hooks(GitHub Issue #2109,430+ 赞),安全策略通过 persistent_instructions 和沙箱权限系统实现。

6.4 OpenCode 快速接入

npm install -g opencode
opencode  # 从仓库根目录运行,自动检测 .opencode/opencode.json

OpenCode 的插件系统比 Claude Code 更强大,支持 20+ 事件类型(包括 file.editedmessage.updatedlsp.client.diagnostics 等)。


七、Token 优化指南

推荐配置(加入 ~/.claude/settings.json

{
  "model": "sonnet",
  "env": {
    "MAX_THINKING_TOKENS": "10000",
    "CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "50",
    "CLAUDE_CODE_SUBAGENT_MODEL": "haiku"
  }
}
设置 默认值 推荐值 效果
model opus sonnet 约降低 60% 成本
MAX_THINKING_TOKENS 31,999 10,000 约降低 70% 隐藏推理成本
CLAUDE_AUTOCOMPACT_PCT_OVERRIDE 95 50 更早压缩,长会话质量更好

日常工作流命令

命令 使用时机
/model sonnet 默认,适用于大多数任务
/model opus 复杂架构设计、深度调试
/clear 切换到无关联任务时(免费、即时重置)
/compact 完成里程碑后、开始下一任务前
/cost 监控会话中的 Token 消耗

上下文窗口管理

⚠️ 不要同时启用所有 MCP 服务器。 每个 MCP 工具描述都会消耗 200k 上下文窗口中的 Token,可能将可用上下文压缩到 ~70k。

// 在项目 .claude/settings.json 中禁用不需要的 MCP
{
  "disabledMcpServers": ["supabase", "railway", "vercel"]
}

建议:每个项目启用 不超过 10 个 MCP,活跃工具不超过 80 个


八、典型工作流示例

开发新功能

# 1. 规划
/everything-claude-code:plan "Add user authentication with OAuth"
# → planner 代理创建实现蓝图

# 2. 测试驱动开发
/tdd
# → tdd-guide 强制先写测试

# 3. 代码审查
/code-review
# → code-reviewer 检查回归问题

修复 Bug

# 1. 写一个能复现 bug 的失败测试
/tdd
# → tdd-guide:先写失败测试

# 2. 实现修复,验证测试通过

# 3. 审查
/code-review
# → code-reviewer:捕获潜在回归

上线前检查

/security-scan      # → 安全漏洞审计(OWASP Top 10)
/e2e                # → 关键用户流程 E2E 测试
/test-coverage      # → 验证 80%+ 覆盖率

代理选择速查表

我想要... 使用命令 调用代理
规划新功能 /plan "Add auth" planner
系统架构设计 /plan + 架构师模式 architect
TDD 写代码 /tdd tdd-guide
审查刚写的代码 /code-review code-reviewer
修复失败构建 /build-fix build-error-resolver
E2E 测试 /e2e e2e-runner
安全漏洞扫描 /security-scan security-reviewer
清理死代码 /refactor-clean refactor-cleaner
更新文档 /update-docs doc-updater
审查 Go 代码 /go-review go-reviewer
审查 Python 代码 /python-review python-reviewer

九、版本更新历史

v1.7.0(2026年2月)— 跨平台扩展 + 演示文稿构建器

  • Codex app + CLI 支持 — 基于 AGENTS.md 的直接 Codex 支持
  • frontend-slides 技能 — 零依赖 HTML 演示文稿构建器,含 PPTX 转换指导
  • 5 个新通用业务技能article-writingcontent-enginemarket-researchinvestor-materialsinvestor-outreach
  • 更广泛的工具覆盖 — Cursor、Codex 和 OpenCode 支持更完善
  • 992 内部测试 — 扩展了插件、Hooks、技能和打包的验证覆盖

v1.6.0(2026年2月)— Codex CLI、AgentShield 与市场

  • Codex CLI 支持 — 新增 /codex-setup 命令生成 codex.md
  • 7 个新技能search-firstswift-actor-persistenceswift-protocol-di-testingregex-vs-llm-structured-text
  • AgentShield 集成/security-scan 可直接运行 AgentShield(1282 测试,102 规则)
  • GitHub Marketplace — ECC Tools GitHub App 上线,含免费/专业/企业层级
  • 30+ 社区 PR 合并

v1.4.0(2026年2月)— 多语言规则、安装向导 & PM2

  • 交互式安装向导configure-ecc 技能提供引导式设置
  • PM2 & 多代理编排 — 6 个新命令
  • 多语言规则架构common/ + typescript/ + python/ + golang/
  • 中文(zh-CN)翻译 — 80+ 文件完整翻译
  • GitHub Sponsors 支持

v1.3.0(2026年2月)— OpenCode 插件支持

  • 完整 OpenCode 集成 — 12 个代理、24 个命令、16 个技能(含 Hook 支持)
  • 3 个原生自定义工具run-testscheck-coveragesecurity-audit
  • LLM 文档llms.txt 提供完整 OpenCode 文档

v1.2.0(2026年2月)— 统一命令 & 技能

  • Python/Django 支持 — Django 模式、安全、TDD、验证技能
  • Java Spring Boot 技能 — 模式、安全、TDD、验证
  • 会话管理/sessions 命令
  • 持续学习 v2 — 基于直觉的学习,含置信度评分

十、系统要求

  • Claude Code CLI:最低版本 v2.1.0+
  • 检查版本claude --version

⚠️ 贡献者注意:不要在 .claude-plugin/plugin.json 中添加 "hooks" 字段。Claude Code v2.1+ 会从已安装插件自动加载 hooks/hooks.json,显式声明会导致重复检测错误(详见 Issue #29、#52、#103)。


十一、常见问题

Q:如何查看已安装的 agents/commands?

/plugin list everything-claude-code@everything-claude-code

Q:Hooks 不工作 / 出现"Duplicate hooks file"错误? 检查 .claude-plugin/plugin.json 中是否有 "hooks" 字段,有则删除。

Q:上下文窗口迅速缩小? 禁用未使用的 MCP 服务器(见第七节),保持活跃 MCP 不超过 10 个。

Q:可以只使用部分组件吗? 可以,使用手动安装方式(Option 2),按需复制文件。每个组件完全独立。

Q:如何贡献新技能? Fork 仓库 → 在 skills/your-skill-name/SKILL.md 创建技能(含 YAML frontmatter)→ 提交 PR。

昨天 — 2026年3月1日首页

Claude Code 创始人 Boris 揭秘:团队 10 倍效率技巧

作者 王小酱
2026年2月28日 23:00

核心观点

当 AI 成为程序员的标配,真正拉开差距的不是工具本身,而是使用方式。

Boris(Claude Code 创始人)首次公开团队内部使用手册,这些技巧来自 Claude Code 核心团队的真实工作场景,可以让工作效率比以前高出 5–10 倍。他的原话颇具代表性:

"我已有 6 个月没写过一行 SQL 代码了。"


十大效率技巧

1. 并行作业:构建多线程作战环境

这是团队给出的 Top 1 建议。

同时开启 3–5 个 git 工作树(worktree),每个运行独立的 Claude 会话:

  • 一个 Claude 负责重构代码
  • 一个 Claude 负责写测试
  • 一个 Claude 负责分析日志

进阶技巧: 给工作树命名并设置 shell 别名(如 zazbzc),一键切换不同任务环境。也可专门维护一个「分析专用」工作树,只用来跑 BigQuery 和看日志。


2. 计划模式(Plan Mode):复杂任务必须先规划

团队铁律:每个复杂任务都从计划模式开始,而不是直接编码。

  • 把精力投入计划阶段,让 Claude 一次性完美实现
  • 进阶玩法: 让一个 Claude 写方案,开第二个 Claude 扮演「主任架构师」审核
  • 避坑指南: 代码一旦跑偏,立刻跳回 Plan Mode 重新规划,而不是反复打补丁

3. CLAUDE.md:让 AI「记住」你的所有规则

这是 Claude 的长期记忆系统,也是普通用户最容易忽视的一点。

每次 Claude 犯错后,在反馈末尾加上:

Update your CLAUDE.md so you don't make this mistake again.

Boris 透露,Claude 非常擅长给自己写规则。持续迭代 CLAUDE.md 文件直到错误率显著下降。有经验的工程师甚至让 Claude 为每个任务/项目维护专门的笔记目录,每次 PR 后更新,并在 CLAUDE.md 中引用这些笔记。


4. 重复的事,一定要变成 Skill

原则:如果某件事每天重复做超过两次,就该把它写成 Skill,提交到 git,在所有项目间复用。

真实案例:

  • /techdebt:每天结束前扫描重复代码
  • 一个 Slash Skill:同步 7 天的 Slack / GDrive / Asana / GitHub 数据
  • 数据工程 Agent:写 dbt、Review、测试

Claude Code 的威力,不在「对话」,而在可复用能力的积累。


5. 90% 的 Bug,Claude 可以自己修

Claude 团队修 Bug 的方式非常「反直觉」——不要去教 Claude 怎么 fix,让 Claude 自己决定。

操作示例:

  • 开 Slack MCP,把一个 Bug 讨论串丢给 Claude,只说一个字:fix
  • 或者直接:Go fix the failing CI tests.(不指定步骤、不微操)
  • 分布式系统中:直接把 docker logs 给 Claude 分析

6. 提升 Prompt 技巧:从「请示」到「挑战」

不要只会求 AI 帮写代码,要学会「挑战」它,像对待高级同事一样协作。

三个改变游戏规则的 Prompt 技巧:

  1. 角色反转审查"证明给我看这能工作",让 Claude 对比主分支和功能分支的行为差异
  2. 优雅重构"已知目前所有条件,把这个垃圾删了,重写一个优雅的方案。"
  3. 详细规格:提前编写详细规格说明,减少歧义——你越具体,输出质量越高

示例 Prompt:"质问我这些变更,直到我通过你的测试才创建 PR。"


7. 终端环境优化:工具配置决定效率上限

Claude Code 团队的偏爱配置:

  • 终端:Ghostty(同步渲染、24-bit 颜色、Unicode)
  • 状态栏:用 /statusline 显示当前 git 分支 + Context 使用率
  • 多任务:tmux / 多 tab,每个标签对应一个任务/worktree,并对标签进行颜色编码和命名

一个被严重低估的技巧:语音输入。 说话比打字快 3 倍,Prompt 质量反而更高。


8. 子代理(Subagents):更多算力,但不污染主上下文

使用原则:

  • 在任何请求后加「使用子代理」,让 Claude 投入更多算力
  • 把单个任务卸载给子代理,保持主代理的上下文窗口干净聚焦
  • 通过 hook 将权限请求路由到 Opus 4.5,自动扫描并批准安全请求,实现权限管理自动化

9. 数据分析:告别手写 SQL 的时代

Claude 团队几乎已经不用手写 SQL

  • 使用 Claude Code 调用 bq 命令行工具即时拉取和分析指标
  • 在代码库中维护 BigQuery 技能,团队每个成员直接在 Claude Code 中进行分析查询
  • 这种方法适用于任何有 CLI、MCP 或 API 的数据库

实战示例:"帮我分析上周用户增长异常的原因"——AI 会自动写 SQL、拉数据、出图表、给结论。


10. 用 Claude 学习:而不只是让它干活

Claude 团队内部的学习用法:

  • /config 中开启「Learning / Explanatory」输出模式,让 Claude 解释改动背后的原因
  • 对于不熟悉的代码,让 Claude 生成可视化 HTML 演示文稿
  • 要求 Claude 绘制新协议和代码库的 ASCII 图表,帮助理解
  • 构建间隔重复学习 Skill(你讲 → 它追问 → 存储)

Claude 不只是生产工具,也是放大理解力的杠杆。


总结

Boris 在开头就强调:使用 Claude Code 没有唯一正确的方式,每个人的设置都不同。

这 10 条技巧只是起点,真正的效率提升来自于:

  • 大胆实验,找到适合自己工作流的方式
  • 持续迭代,不断优化技能和配置
  • 分享交流,从团队中汲取智慧

AI 时代的编程,拼的不是打字速度,而是定义问题的边界以及调度算力的能力。

结合OpenSpec 与 Everything-Claude-Code (ECC) 的构建团队工作流程

作者 王小酱
2026年2月28日 21:06

一、两者定位本质差异

这两个项目解决的是 AI 辅助开发流程中完全不同层面的问题,理解这一点是最关键的。

OpenSpec 解决的是 "做什么"(What) 的问题 —— 它是一个规格驱动开发(Spec-Driven Development)框架。核心理念是:在 AI 写代码之前,先让人和 AI 就需求规格达成共识。它通过 proposal → specs → design → tasks 的制品(artifact)依赖图来管理每一个变更的完整生命周期。

ECC 解决的是 "怎么做"(How) 的问题 —— 它是一个AI 编码助手的配置工具箱。核心理念是:提供一整套生产就绪的 agents、skills、hooks、commands、rules 和 MCP 配置,让 Claude Code(以及 Cursor/OpenCode/Codex)的执行能力最大化。

打个比方:OpenSpec 相当于项目经理的需求管理系统,ECC 相当于开发者的瑞士军刀。


二、核心机制对比

OpenSpec 的核心机制

OpenSpec 的核心是一个 制品依赖图引擎(Artifact DAG)。每个变更(change)被组织为一个独立文件夹,包含四类制品:

proposal.md 记录意图和范围,specs/ 通过 Delta 格式(ADDED/MODIFIED/REMOVED)描述行为变化,design.md 记录技术方案和架构决策,tasks.md 则是带复选框的实施清单。这些制品形成有向无环图的依赖关系,状态通过文件系统存在性自动检测(BLOCKED → READY → DONE)。

它的 OPSX 工作流打破了传统线性阶段的限制,采用流动式操作:你可以在实施过程中随时回头修改设计,不存在阶段门禁。同时它支持 24+ AI 编码工具(Claude Code、Cursor、Windsurf、Gemini CLI、GitHub Copilot、Kiro 等),做到了真正的工具无关性。

特别值得一提的是它的 Delta Spec 概念 —— 不是重写整个规格,而是描述变化量,这对存量项目(brownfield)极其友好。变更完成后通过 archive 操作将 delta 合并回主规格,形成持续演进的系统行为文档。

ECC 的核心机制

ECC 是一套模块化的配置组件库,包含 13 个专用子代理(planner、architect、tdd-guide、code-reviewer、security-reviewer 等),56 个 skills 覆盖前后端模式、持续学习、安全审计等领域,32 个斜杠命令(/plan、/tdd、/code-review、/e2e 等),以及 hooks 系统实现会话记忆持久化、自动格式化、战略性上下文压缩等自动化行为。

它的 Instinct 持续学习系统(v2)是亮点:自动从会话中提取模式,赋予置信度评分,支持跨团队导入导出,并可通过 /evolve 命令将相关直觉聚合为技能。

此外 ECC 的 AgentShield 安全扫描器(1282 个测试、102 条规则)可以扫描你的 AI 配置(CLAUDE.md、hooks、MCP 等)中的漏洞和注入风险,甚至支持三个 Opus 代理的红队/蓝队/审计流水线。


三、各自优缺点

OpenSpec

优点: 工具无关性是它最大的战略优势。支持 24+ AI 工具意味着团队不会被锁定在某个特定 IDE 或 AI 提供商上,前端用 Cursor、后端用 Claude Code 的团队可以共享同一套规格流程。Delta Spec 机制为存量项目提供了优雅的增量规格管理。自定义 schema 能力让团队可以定义自己的制品类型和依赖关系,比如加入 research 步骤。作为 npm 包分发(openspec init 一条命令初始化)降低了团队推广门槛。同时,制品文件夹结构天然支持 Git 版本控制和代码评审。

缺点: 它不涉及代码执行层面的优化,不提供 agent、hook 或 coding skill。对于小型快速迭代任务(hotfix、小 bug)流程可能显得重。需要团队养成写规格的习惯,存在文化适配成本。它也没有 token 优化、上下文管理、会话持久化等运行时增强能力。

ECC

优点: 开箱即用的生产级配置经过了实际产品构建的验证(Anthropic 黑客松获奖作品)。token 优化策略具体且实用(模型选择、thinking token 限制、compaction 阈值),能显著降低成本。多语言 rules 架构(common/ + typescript/ + python/ + golang/)适配不同技术栈。Instinct 学习系统让团队经验可以积累和传承。AgentShield 安全扫描填补了 AI 配置安全性的空白。同时跨平台支持(Claude Code、Cursor、Codex CLI、OpenCode)也相当完善。

缺点: 以 Claude Code 为主要目标,对其他工具的支持虽在扩展但存在功能差距。缺少需求-设计-实施的结构化流程管理,/plan 命令只是调用 planner agent 生成蓝图,不像 OpenSpec 那样有制品依赖图和生命周期管理。配置项繁多(56 skills + 32 commands),新用户需要时间理解哪些组件适合自己。Rules 无法通过插件自动分发(Claude Code 平台限制),需要手动安装。


四、最佳实践姿势

OpenSpec 最佳实践

适合的场景是中大型功能、跨团队协作、需要需求对齐的工作。推荐的流程是:对于明确需求用 /opsx:propose 快速启动然后 /opsx:apply 实施;对于模糊需求先用 /opsx:explore 探索再决定方案;保持每个 change 聚焦于一个逻辑单元;archive 前用 /opsx:verify 验证实现与规格的一致性。

命名规范也很重要:用 add-dark-mode、fix-login-redirect 这种描述性名称,避免 feature-1、wip 这种模糊命名。

ECC 最佳实践

token 管理是关键:默认使用 sonnet,只在复杂架构推理时切换 opus;将 MAX_THINKING_TOKENS 设为 10000,CLAUDE_AUTOCOMPACT_PCT_OVERRIDE 设为 50;MCP 服务器保持 10 个以内,工具总数 80 以内。

工作流模式上:新功能用 /plan → /tdd → /code-review 三步走;修复 bug 先用 /tdd 写失败测试再修复;发布前用 /security-scan + /e2e + /test-coverage 三重验证。任务之间用 /clear 重置上下文,逻辑断点处用 /compact 压缩。


五、面向公司前后端团队的整合方案

基于对两者的深入分析,我推荐的整合策略是 OpenSpec 做流程骨架 + ECC 做执行引擎,两者互补而非替代。

第一层:需求与规格管理(OpenSpec)

在项目根目录执行 openspec init 初始化,所有非 trivial 的功能开发都从 /opsx:propose 或 /opsx:explore 开始。前端和后端开发者在同一个 openspec/changes/ 目录下协作,但各自维护各自领域的 specs(如 specs/api/、specs/ui/)。利用 OpenSpec 的工具无关性,让用不同 IDE 的团队成员共享同一套规格流程。

第二层:编码执行增强(ECC)

在每个开发者的环境中安装 ECC 插件并配置对应语言的 rules(前端装 common/ + typescript/,后端根据栈选择 python/ 或 golang/)。利用 ECC 的 agents 体系:planner 和 architect 辅助 OpenSpec 的 proposal 和 design 阶段,tdd-guide 和 code-reviewer 在 /opsx:apply 实施阶段提供质量保障。配置 token 优化策略统一降本。

第三层:质量与安全闭环

实施完成后,用 /opsx:verify 验证规格一致性(OpenSpec),同时用 ECC 的 /security-scan、/test-coverage、/e2e 进行技术层面验证。用 AgentShield 定期扫描团队的 AI 配置安全性。

第四层:知识积累与传承

利用 ECC 的 Instinct 系统自动学习团队模式,定期 /instinct-export 导出分享。OpenSpec 的 archive 机制自动积累系统行为规格,新人 onboard 时直接阅读 openspec/specs/ 了解系统当前行为。

推荐的完整工作流

一个典型的功能开发流程如下:

  1. PM/开发者启动 → /opsx:explore(OpenSpec,厘清需求)
  2. 需求明确后 → /opsx:propose(OpenSpec,生成 proposal + specs + design + tasks)
  3. 前后端评审制品 → 在 Git PR 中 review openspec/changes/feature-name/
  4. 实施阶段 → /opsx:apply + ECC 的 /tdd/code-review(OpenSpec 管进度,ECC 保质量)
  5. 验证阶段 → /opsx:verify + /security-scan + /e2e
  6. 完成归档 → /opsx:archive(delta specs 合并回主规格)

这套方案的核心价值是:OpenSpec 确保团队在写代码前达成共识(减少返工),ECC 确保写代码时效率和质量最大化(降低成本)。两者结合覆盖了从需求到交付的完整 AI 辅助开发链路。

昨天以前首页

Everything Claude Code 完全长篇指南

作者 王小酱
2026年2月27日 16:54

image.png


在上一篇Everything Claude Code 速查指南中,我涵盖了基础配置:技能(skills)和命令(commands)、钩子(hooks)、子代理(subagents)、MCPs、插件(plugins),以及构成高效 Claude Code 工作流骨干的配置模式。那是一份配置指南和基础设施。

这篇长篇指南深入探讨了将高效会话与浪费性会话区分开来的技术。如果你还没有读过简明指南,请先回去配置好你的设置。接下来的内容假设你已经配置好了技能、代理、钩子和 MCPs 并且它们已正常运行。

这里的主题包括:token 经济学、记忆持久化、验证模式、并行化策略,以及构建可复用工作流的复合效应。这些是我在超过10个月的日常使用中精炼出的模式,它们决定了你是在第一个小时内就被上下文腐烂(context rot)所困扰,还是能够维持数小时的高效会话。

简明和长篇文章中涵盖的所有内容都可在 GitHub 上获取:everything-claude-code


Context & Memory Management

上下文与记忆管理

对于跨会话共享记忆,最好的方法是使用一个技能或命令来总结并检查进度,然后保存到你的 .claude 文件夹中的 .tmp 文件,并在会话结束前持续追加内容。第二天它可以将其作为上下文来使用,从你上次中断的地方继续,为每个会话创建一个新文件,这样你就不会把旧的上下文污染到新的工作中。最终你会有一个很大的会话日志文件夹——只需将其备份到有意义的地方,或者修剪你不需要的会话对话。Claude 会创建一个总结当前状态的文件。查看它,如果需要可以要求修改,然后开始新的对话。对于新对话,只需提供文件路径。当你达到上下文限制并需要继续复杂工作时,这特别有用。这些文件应该包含——哪些方法有效(可验证且有证据)、哪些尝试过的方法没有效果、哪些方法尚未尝试以及还剩什么要做。

image.png 会话存储示例 -> github.com/affaan-m/ev…

策略性清除上下文:

一旦你的计划设定好并且上下文已清除(现在是 Claude Code 计划模式中的默认选项),你就可以从计划开始工作。当你积累了大量不再与执行相关的探索性上下文时,这很有用。对于策略性压缩,禁用自动压缩。在逻辑间隔处手动压缩,或创建一个技能为你执行此操作,或在某些定义的标准下提出建议。


Strategic Compact Skill(直接链接):

(嵌入以供快速参考)

#!/bin/bash
# Strategic Compact Suggester
# Runs on PreToolUse to suggest manual compaction at logical intervals
#
# Why manual over auto-compact:
# - Auto-compact happens at arbitrary points, often mid-task
# - Strategic compacting preserves context through logical phases
# - Compact after exploration, before execution
# - Compact after completing a milestone, before starting next

COUNTER_FILE="/tmp/claude-tool-count-$$"
THRESHOLD=${COMPACT_THRESHOLD:-50}

# Initialize or increment counter
if [ -f "$COUNTER_FILE" ]; then
  count=$(cat "$COUNTER_FILE")
  count=$((count + 1))
  echo "$count" > "$COUNTER_FILE"
else
  echo "1" > "$COUNTER_FILE"
  count=1
fi

# Suggest compact after threshold tool calls
if [ "$count" -eq "$THRESHOLD" ]; then
  echo "[StrategicCompact] $THRESHOLD tool calls reached - consider /compact if transitioning phases" >&2
fi

将它挂钩到 Edit/Write 操作的 PreToolUse 上——当你积累了足够多的上下文、压缩可能有帮助时,它会提醒你。


进阶:动态系统提示注入(Advanced: Dynamic System Prompt Injection)

我学到并正在试运行的一种模式是:不要只把所有东西放在 CLAUDE.md(用户范围)或 .claude/rules/(项目范围)中(这些每次会话都会加载),而是使用 CLI 标志来动态注入上下文。

claude --system-prompt "$(cat memory.md)"

这让你可以更精确地控制何时加载什么上下文。你可以根据当前工作内容在每个会话中注入不同的上下文。

为什么这比 @ 文件引用更重要: 当你使用 @memory.md 或将内容放在 .claude/rules/ 中时,Claude 通过 Read 工具在对话过程中读取它——它作为工具输出传入。当你使用 --system-prompt 时,内容在对话开始前被注入到实际的系统提示中。

区别在于指令层级(instruction hierarchy)。系统提示内容的权威性高于用户消息,用户消息的权威性高于工具结果。对于大多数日常工作来说,这种差异是微不足道的。但对于诸如严格的行为规则、项目特定的约束,或你绝对需要 Claude 优先考虑的上下文——系统提示注入确保它得到适当的权重。

实际配置:

一种有效的方法是将 .claude/rules/ 用于你的基线项目规则,然后为场景特定的上下文设置 CLI 别名,可以在它们之间切换:

# Daily development
alias claude-dev='claude --system-prompt "$(cat ~/.claude/contexts/dev.md)"'

# PR review mode
alias claude-review='claude --system-prompt "$(cat ~/.claude/contexts/review.md)"'

# Research/exploration mode
alias claude-research='claude --system-prompt "$(cat ~/.claude/contexts/research.md)"'

System Prompt Context Example Files(直接链接):

  • dev.md 专注于实现
  • review.md 专注于代码质量/安全
  • research.md 专注于行动前的探索

同样,对于大多数情况,使用 .claude/rules/context1.md 和直接将 context1.md 附加到系统提示之间的区别是微乎其微的。CLI 方法更快(无需工具调用)、更可靠(系统级权威)且稍微更节省 token。但这是一个小优化,对许多人来说开销大于收益。


进阶:记忆持久化钩子(Advanced: Memory Persistence Hooks)

有一些钩子(hooks)是大多数人不知道的,或者知道但没有真正利用的,它们有助于记忆管理:

SESSION 1                    SESSION 2
─────────                    ─────────
[Start]                      [Start]
   │                            │
   ▼                            ▼
┌──────────────┐          ┌──────────────┐
│ SessionStart │ ◄─── reads ─────── │ SessionStart │◄── loads previous
│    Hook      │    nothing yet     │    Hook      │    context
└──────┬───────┘          └──────┬───────┘
       │                         │
       ▼                         ▼
   [Working]                 [Working]
       │                    (informed)
       ▼                         │
┌──────────────┐                 ▼
│  PreCompact  │──► saves state [Continue...]
│    Hook      │    before summary
└──────┬───────┘
       │
       ▼
   [Compacted]
       │
       ▼
┌──────────────┐
│  Stop Hook   │──► persists to ──────────►
│ (session-end)│    ~/.claude/sessions/
└──────────────┘
  • PreCompact Hook: 在上下文压缩发生之前,将重要状态保存到文件中
  • SessionComplete Hook: 在会话结束时,将学习成果持久化到文件中
  • SessionStart Hook: 在新会话开始时,自动加载之前的上下文

Memory Persistent Hooks(直接链接):

(嵌入以供快速参考)

{
  "hooks": {
    "PreCompact": [{
      "matcher": "*",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/memory-persistence/pre-compact.sh"
      }]
    }],
    "SessionStart": [{
      "matcher": "*",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/memory-persistence/session-start.sh"
      }]
    }],
    "Stop": [{
      "matcher": "*",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/memory-persistence/session-end.sh"
      }]
    }]
  }
}

这些的作用:

  • pre-compact.sh:记录压缩事件,用压缩时间戳更新活动会话文件
  • session-start.sh:检查最近的会话文件(最近7天),通知可用的上下文和已学习的技能
  • session-end.sh:创建/更新每日会话文件模板,跟踪开始/结束时间

将这些串联起来,即可实现跨会话的持续记忆,无需手动干预。这建立在第一篇文章中的钩子类型(PreToolUse、PostToolUse、Stop)之上,但专门针对会话生命周期。


Continuous Learning / Memory

持续学习 / 记忆

我们之前讨论了以更新代码地图(codemaps)的形式进行持续记忆更新,但这也适用于其他方面,比如从错误中学习。如果你不得不多次重复提示,而 Claude 遇到了相同的问题或给了你以前听过的回答,那这部分就适用于你。很可能你需要发送第二个提示来"重新引导(resteer)"并校准 Claude 的方向。这适用于任何此类场景——这些模式必须被追加到技能中。

现在你可以通过简单地告诉 Claude 记住它或将其添加到你的规则中来自动完成此操作,或者你可以有一个技能来专门做这件事。

问题: 浪费 token,浪费上下文,浪费时间,你的皮质醇飙升,因为你沮丧地对 Claude 大喊不要做你在之前会话中已经告诉它不要做的事情。

解决方案: 当 Claude Code 发现一些非平凡的东西——调试技术、变通方法、某些项目特定的模式——它会将该知识保存为新技能。下次出现类似问题时,技能会自动加载。


Continuous Learning Skill(直接链接)

为什么我使用 Stop hook 而不是 UserPromptSubmit?UserPromptSubmit 在你发送的每条消息上都会运行——这会带来很大的开销,给每个提示增加延迟,坦率地说对这个目的来说是大材小用。Stop 在会话结束时只运行一次——轻量级,不会在会话期间拖慢你的速度,而且评估的是完整会话而非碎片化的内容。

安装:

# Clone to skills folder
git clone https://github.com/affaan-m/everything-claude-code.git ~/.claude/skills/everything-claude-code

# Or just grab the continuous-learning skill
mkdir -p ~/.claude/skills/continuous-learning
curl -sL https://raw.githubusercontent.com/affaan-m/everything-claude-code/main/skills/continuous-learning/evaluate-session.sh > ~/.claude/skills/continuous-learning/evaluate-session.sh
chmod +x ~/.claude/skills/continuous-learning/evaluate-session.sh

Hook Configuration(直接链接):

{
  "hooks": {
    "Stop": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/skills/continuous-learning/evaluate-session.sh"
          }
        ]
      }
    ]
  }
}

这使用 Stop hook 在每个提示上运行一个激活脚本,评估会话中值得提取的知识。该技能也可以通过语义匹配激活,但钩子确保了一致的评估。

Stop hook 在你的会话结束时触发——脚本分析会话中值得提取的模式(错误解决方案、调试技术、变通方法、项目特定模式等),并将它们保存为 ~/.claude/skills/learned/ 中的可复用技能。

手动提取 - /learn:

你不必等到会话结束。仓库中还包含一个 /learn 命令,你可以在会话中途刚解决了一些非平凡的问题时运行它。它会提示你立即提取模式,起草一个技能文件,并在保存前征求确认。参见这里

会话日志模式:

该技能期望会话日志保存在 .tmp 文件中。模式为:~/.claude/sessions/YYYY-MM-DD-topic.tmp——每个会话一个文件,包含当前状态、已完成项目、阻碍因素、关键决定和下次会话的上下文。示例会话文件在仓库的 examples/sessions/ 中。


其他自我改进的记忆模式:

来自 @RLanceMartin 的一种方法涉及反思会话日志以提炼用户偏好——本质上是建立一个记录什么有效、什么无效的"日记"。每次会话后,一个反思代理(reflection agent)提取哪些做得好、哪些失败了、你做了哪些修正。这些学习成果会更新一个记忆文件,在后续会话中加载。

来自 @alexhillman 的另一种方法是让系统每15分钟主动建议改进,而不是等你注意到模式。代理审查最近的交互,提出记忆更新建议,你批准或拒绝。随着时间推移,它会从你的批准模式中学习。


Token Optimization

Token 优化

我从价格敏感的消费者那里收到了很多问题,或者那些作为重度用户经常遇到限制问题的人。在 token 优化方面,有一些技巧可以使用。

主要策略:子代理架构

主要是优化你使用的工具和子代理架构,旨在将最便宜的、足以完成任务的模型委派出去以减少浪费。你有几个选项——可以尝试试错法并随着进展调整。一旦你了解了什么是什么,你就可以区分哪些委派给 Haiku、哪些委派给 Sonnet、哪些委派给 Opus。

基准测试方法(更深入):

另一种更深入的方法是,你可以让 Claude 设置一个基准测试,在一个有明确目标、任务和明确计划的仓库中。在每个 git worktree 中,让所有子代理都使用同一个模型。在任务完成时记录日志——理想情况下在你的计划和任务中记录。你必须至少使用每个子代理一次。

一旦完成一轮完整测试并且任务已从你的 Claude 计划中勾选完毕,停下来审核进度。你可以通过比较差异(diffs)、创建在所有 worktree 中统一的单元测试、集成测试和端到端测试来做到这一点。这将给你一个基于通过/失败案例的数值基准。如果所有 worktree 都全部通过,你需要添加更多的边界测试用例或增加测试的复杂度。这可能值得也可能不值得做,取决于这对你来说到底有多重要。

模型选择快速参考:

image.png

各种常见任务上子代理的假设配置及选择背后的推理

90% 的编码任务默认使用 Sonnet。当首次尝试失败、任务跨越5个以上文件、架构决策或安全关键代码时升级到 Opus。当任务是重复性的、指令非常清晰,或在多代理设置中作为"工人(worker)"使用时降级到 Haiku。坦率地说,Sonnet 4.5 目前处于一个尴尬的位置,每百万输入 token 3,每百万输出token3,每百万输出 token 15,与 Opus 相比成本节省约66.7%,绝对值来说这是不错的节省,但相对而言对大多数人来说微不足道。Haiku 和 Opus 组合最有意义,因为 Haiku 与 Opus 有5倍的成本差异,而与 Sonnet 只有1.67倍的价格差异。

image.png

来源:platform.claude.com/docs/en/abo…

在你的代理定义中,指定模型:

---
name: quick-search
description: Fast file search
tools: Glob, Grep
model: haiku  # Cheap and fast
---

工具特定优化:

想想 Claude 最频繁调用的工具。例如,用 mgrep 替换 grep——在各种任务上,与传统 grep 或 ripgrep(Claude 默认使用的)相比,平均有效 token 减少约一半。

image.png

来源:github.com/mixedbread-…

后台进程:

适用时,如果你不需要 Claude 处理整个输出并实时流式传输,请在 Claude 之外运行后台进程。这可以通过 tmux 轻松实现(参见简明指南Tmux Commands Reference(直接链接))。获取终端输出后,要么总结它,要么只复制你需要的部分。这将节省大量输入 token,这是大部分成本的来源——Opus 4.5 每百万 token 5,输出每百万token5,输出每百万 token 25。

模块化代码库的好处:

拥有更模块化的代码库,包含可复用的工具函数、函数、钩子等——主文件在数百行而非数千行——既有助于 token 优化成本,也有助于第一次就正确完成任务,两者是相关的。如果你必须多次提示 Claude,你就在大量消耗 token,尤其是当它反复读取非常长的文件时。你会注意到它需要进行大量工具调用才能读完文件。中间过程中,它会告诉你文件非常长,它将继续读取。在这个过程中的某个地方,Claude 可能会丢失一些信息。而且,停止和重新读取会消耗额外的 token。这可以通过拥有更模块化的代码库来避免。示例如下 ->

root/
├── docs/              # Global documentation
├── scripts/           # CI/CD and build scripts
├── src/
│   ├── apps/          # Entry points (API, CLI, Workers)
│   │   ├── api-gateway/    # Routes requests to modules
│   │   └── cron-jobs/
│   │
│   ├── modules/       # The core of the system
│   │   ├── ordering/       # Self-contained "Ordering" module
│   │   │   ├── api/             # Public interface for other modules
│   │   │   ├── domain/          # Business logic & Entities (Pure)
│   │   │   ├── infrastructure/  # DB, External Clients, Repositories
│   │   │   ├── use-cases/       # Application logic (Orchestration)
│   │   │   └── tests/           # Unit and integration tests
│   │   │
│   │   ├── catalog/        # Self-contained "Catalog" module
│   │   │   ├── domain/
│   │   │   └── ...
│   │   │
│   │   └── identity/       # Self-contained "Auth/User" module
│   │       ├── domain/
│   │       └── ...
│   │
│   ├── shared/        # Code used by EVERY module
│   │   ├── kernel/         # Base classes (Entity, ValueObject)
│   │   ├── events/         # Global Event Bus definitions
│   │   └── utils/          # Deeply generic helpers
│   │
│   └── main.ts        # Application bootstrap
├── tests/             # End-to-End (E2E) global tests
├── package.json
└── README.md

精简代码库 = 更便宜的 Token:

这可能很明显,但你的代码库越精简,token 成本就越低。关键是要通过使用技能来持续清理代码库,利用技能和命令进行重构来识别死代码。另外在某些时候,我喜欢通读整个代码库,寻找那些让我觉得突出或看起来重复的东西,手动拼凑这些上下文,然后将其与重构技能和死代码技能一起输入给 Claude。

系统提示精简(进阶):

对于真正注重成本的人:Claude Code 的系统提示占用约18k token(200k 上下文的约9%)。这可以通过补丁减少到约10k token,节省约7,300 token(静态开销的41%)。如果你想走这条路,参见 YK 的 system-prompt-patches,我个人不这样做。


Verification Loops and Evals

验证循环与评估

评估和框架调优——取决于项目,你需要使用某种形式的可观测性和标准化。

可观测性方法:

一种方法是让 tmux 进程挂钩到追踪思维流和输出上,每当技能被触发时。另一种方法是使用 PostToolUse 钩子来记录 Claude 具体执行了什么以及确切的变更和输出是什么。

基准测试工作流:

将其与不使用技能地要求相同的事情进行比较,检查输出差异以进行相对性能基准测试:

           [Same Task]
                │
    ┌────────────┴────────────┐
    ▼                         ▼
┌───────────────┐     ┌───────────────┐
│  Worktree A   │     │  Worktree B   │
│  WITH skill   │     │ WITHOUT skill │
└───────┬───────┘     └───────┬───────┘
        │                     │
        ▼                     ▼
   [Output A]            [Output B]
        │                     │
        └──────────┬──────────┘
                   ▼
              [git diff]
                   │
                   ▼
          ┌────────────────┐
          │ Compare logs,  │
          │ token usage,   │
          │ output quality │
          └────────────────┘

分叉对话,在其中一个中启动一个没有技能的新 worktree,最后查看差异,看看日志记录了什么。这与持续学习和记忆部分相关联。

评估模式类型:

更高级的评估和循环协议在这里登场。分为基于检查点的评估和基于强化学习任务的持续评估。

CHECKPOINT-BASED              CONTINUOUS
─────────────────             ──────────
[Task 1]                      [Work]
    │                            │
    ▼                            ▼
┌─────────┐                  ┌─────────┐
│Checkpoint│◄── verify       │ Timer/  │
│   #1     │    criteria     │ Change  │
└────┬────┘                  └────┬────┘
     │ pass?                      │
  ┌───┴───┐                       ▼
  │       │                  ┌──────────┐
 yes   no ──► fix ──┐       │Run Tests │
  │               │  │       │ + Lint   │
  ▼           └────┘ │       └────┬─────┘
[Task 2]              │            │
    │                 │       ┌────┴────┐
    ▼                 │       │         │
┌─────────┐           │      pass     fail
│Checkpoint│          │       │         │
│   #2     │          │       ▼         ▼
└────┬────┘           │   [Continue]  [Stop & Fix]
     │                │
    ...            └────┘

Best for: Linear workflows    Best for: Long sessions
with clear milestones         exploratory refactoring

基于检查点的评估:

  • 在工作流中设置明确的检查点
  • 在每个检查点根据定义的标准进行验证
  • 如果验证失败,Claude 必须在继续之前修复
  • 适合具有明确里程碑的线性工作流

持续评估:

  • 每 N 分钟或在重大变更后运行
  • 完整测试套件、构建状态、lint 检查
  • 立即报告回归
  • 在继续之前停下来修复
  • 适合长时间运行的会话

决定因素是你工作的性质。基于检查点适用于具有明确阶段的功能实现。持续评估适用于探索性重构或维护,因为你没有明确的里程碑。

我会说,通过一些干预,验证方法足以避免大部分技术债务。让 Claude 在完成任务后通过运行技能和 PostToolUse 钩子来验证有助于此。持续更新代码地图也有帮助,因为它保持了变更日志以及代码地图如何随时间演变的记录,作为仓库本身之外的事实来源。通过严格的规则,Claude 会避免创建杂乱的随机 .md 文件、为相似代码创建重复文件,以及留下一片死代码的荒原。

评分器类型(来自 Anthropic - 直接链接)

基于代码的评分器(Code-Based Graders): 字符串匹配、二元测试、静态分析、结果验证。快速、便宜、客观,但对有效变体很脆弱。

基于模型的评分器(Model-Based Graders): 评分标准打分、自然语言断言、成对比较。灵活且能处理微妙之处,但非确定性且更昂贵。

人工评分器(Human Graders): 专家审查、众包判断、抽样检查。金标准质量,但昂贵且缓慢。

关键指标:

pass@k: At least ONE of k attempts succeeds
┌─────────────────────────────────────┐
│ k=1: 70%    k=3: 91%    k=5: 97%   │
│ Higher k = higher odds of success   │
└─────────────────────────────────────┘

pass^k: ALL k attempts must succeed
┌─────────────────────────────────────┐
│ k=1: 70%    k=3: 34%    k=5: 17%   │
│ Higher k = harder (consistency)     │
└─────────────────────────────────────┘

当你只需要它能工作且任何验证反馈就足够时,使用 pass@k。当一致性至关重要且你需要接近确定性的输出一致性(在结果/质量/风格方面)时,使用 pass^k

构建评估路线图(来自同一 Anthropic 指南):

  • 尽早开始——从真实失败中提取20-50个简单任务
  • 将用户报告的失败转化为测试用例
  • 编写明确的任务——两个专家应达成相同结论
  • 构建平衡的问题集——测试行为应该和不应该出现的情况
  • 构建健壮的测试框架——每次试验从干净环境开始
  • 评分代理产生的结果,而非它走过的路径
  • 阅读许多试验的记录
  • 监控饱和度——100%通过率意味着需要添加更多测试

Parallelization

并行化

在多 Claude 终端设置中分叉对话时,确保分叉中的操作范围和原始对话的操作范围都有明确定义。在代码变更方面尽量减少重叠。选择彼此正交的任务以防止干扰的可能性。

我的首选模式:

个人而言,我更喜欢主聊天用于处理代码变更,而我做的分叉是用于我对代码库及其当前状态的问题,或者做外部服务的研究,比如拉取文档、在 GitHub 上搜索适用的开源仓库来帮助任务,或其他有用的一般性研究。

关于任意终端数量:

Boris @bcherny(创建 Claude Code 的传奇人物)有一些关于并行化的建议,我对此有赞同也有不赞同的地方。他建议过类似在本地运行5个 Claude 实例和5个上游实例这样的事情。我建议不要设置这样的任意终端数量。增加一个终端和增加一个实例应该出于真正的必要性和目的。如果你可以用脚本来处理该任务,就用脚本。如果你可以留在主聊天中让 Claude 在 tmux 中启动一个实例并在单独的终端中流式传输,那就那样做。

引用推文:Boris Cherny @bcherny · 1月3日 回复 @bcherny 1/ 我在终端中并行运行5个 Claude。我给我的标签页编号1-5,并使用系统通知来知道何时 Claude 需要输入 code.claude.com/docs/en/ter…

image.png

你的目标真的应该是:用最小可行的并行化量完成尽可能多的工作。

对于大多数新手,我甚至建议在你熟练掌握单实例运行和管理一切之前远离并行化。我不是主张限制自己——我是说要小心。大多数时候,即使是我也只使用大约4个终端。我发现通常只需打开2或3个 Claude 实例就能完成大部分事情。

扩展实例时:

如果你要开始扩展你的实例,并且有多个 Claude 实例在相互重叠的代码上工作,使用 git worktrees 并为每个实例制定非常明确的计划是必不可少的。此外,为了在恢复会话时不会混淆或迷失哪个 git worktree 是做什么的(除了树的名称之外),使用 /rename <name here> 来命名你所有的聊天。

Git Worktrees 用于并行实例:

# Create worktrees for parallel work
git worktree add ../project-feature-a feature-a
git worktree add ../project-feature-b feature-b
git worktree add ../project-refactor refactor-branch

# Each worktree gets its own Claude instance
cd ../project-feature-a && claude

好处:

  • 实例之间没有 git 冲突
  • 每个都有干净的工作目录
  • 容易比较输出
  • 可以在不同方法之间对同一任务进行基准测试

级联方法(The Cascade Method):

当运行多个 Claude Code 实例时,使用"级联"模式来组织:

  • 在右侧的新标签页中打开新任务
  • 从左到右扫描,从最旧到最新
  • 保持一致的方向流
  • 根据需要检查特定任务
  • 一次最多关注3-4个任务——超过这个数量,心理开销的增长速度会快于生产力

Groundwork

基础工作

从零开始时,实际的基础非常重要。这应该是显而易见的,但随着代码库的复杂性和规模增加,技术债务也会增加。管理它非常重要,如果你遵循一些规则,其实并不困难。除了为当前项目有效配置你的 Claude 之外(参见简明指南)。

双实例启动模式(The Two-Instance Kickoff Pattern):

对于我自己的工作流管理(不是必须的但很有帮助),我喜欢用2个打开的 Claude 实例来启动一个空仓库。

实例 1:脚手架代理(Scaffolding Agent)

  • 负责搭建脚手架和基础工作
  • 创建项目结构
  • 配置设置(CLAUDE.md、规则、代理——简明指南中的所有内容)
  • 建立约定
  • 把骨架搭好

实例 2:深度研究代理(Deep Research Agent)

  • 连接到你所有的服务、网络搜索等
  • 创建详细的 PRD(产品需求文档)
  • 创建架构 mermaid 图
  • 用实际文档中的实际片段编译参考资料

image.png

启动配置:左侧终端用于编码,右侧终端用于提问——使用 /rename 和 /fork。

最小化启动所需的内容就够了——这比每次都用 Context7 或喂链接让它抓取或使用 Firecrawl MCP 站点要快。当你已经深入某件事情且 Claude 明显语法出错或使用过时的函数或端点时,那些方法才派上用场。

llms.txt 模式:

如果可用的话,你可以在许多文档参考上通过在到达其文档页面后访问 /llms.txt 来找到一个 llms.txt 文件。这是一个示例:www.helius.dev/docs/llms.t…

这给你一个干净的、为 LLM 优化的文档版本,你可以直接提供给 Claude。

理念:构建可复用模式(Philosophy: Build Reusable Patterns)

来自 @omarsar0 的一个我完全认同的见解:"早期,我花时间构建可复用的工作流/模式。构建起来很繁琐,但随着模型和代理框架的改进,这产生了疯狂的复合效应。"

值得投资的方面:

  • 子代理(简明指南)
  • 技能(简明指南)
  • 命令(简明指南)
  • 计划模式
  • MCP 工具(简明指南)
  • 上下文工程模式

为什么会产生复合效应(@omarsar0):"最棒的部分是所有这些工作流都可以转移到其他代理,如 Codex。"一旦构建完成,它们可以跨模型升级工作。投资于模式 > 投资于特定模型的技巧。


Best Practices for Agents & Sub-Agents

代理和子代理的最佳实践

在简明指南中,我列出了子代理结构——planner、architect、tdd-guide、code-reviewer 等。在这一部分,我们关注编排和执行层。

子代理上下文问题(The Sub-Agent Context Problem):

子代理的存在是为了通过返回摘要而非倾倒所有内容来节省上下文。但编排器(orchestrator)拥有子代理所缺乏的语义上下文。子代理只知道字面上的查询,不知道请求背后的目的/推理。摘要通常会遗漏关键细节。

来自 @PerceptualPeak 的类比:"你的老板让你去参加一个会议并要求你做个总结。你回来给他汇报情况。十次有九次,他会有后续问题。你的总结不会包含他需要的所有内容,因为你没有他拥有的隐含上下文。"

迭代检索模式(Iterative Retrieval Pattern):

┌─────────────────┐
│  ORCHESTRATOR   │
│  (has context)  │
└────────┬────────┘
         │ dispatch with query + objective
         ▼
┌─────────────────┐
│   SUB-AGENT     │
│ (lacks context) │
└────────┬────────┘
         │ returns summary
         ▼
┌─────────────────┐    ┌─────────────┐
│    EVALUATE     │─no──►│  FOLLOW-UP  │
│   Sufficient?   │    │  QUESTIONS  │
└────────┬────────┘    └──────┬──────┘
         │ yes                │ sub-agent
         ▼                    │ fetches answers
      [ACCEPT]                │
         ◄──────────────────────┘
                        (max 3 cycles)

要修复这个问题,让编排器:

  • 评估每个子代理的返回结果
  • 在接受之前询问后续问题
  • 子代理回到源头,获取答案,返回
  • 循环直到充分(最多3个循环以防止无限循环)

传递目标上下文,而不仅仅是查询。 当派遣子代理时,同时包含具体查询和更广泛的目标。这有助于子代理确定在其摘要中优先包含什么内容。

模式:带有顺序阶段的编排器(Pattern: Orchestrator with Sequential Phases)

Phase 1: RESEARCH (use Explore agent)
- Gather context
- Identify patterns
- Output: research-summary.md

Phase 2: PLAN (use planner agent)
- Read research-summary.md
- Create implementation plan
- Output: plan.md

Phase 3: IMPLEMENT (use tdd-guide agent)
- Read plan.md
- Write tests first
- Implement code
- Output: code changes

Phase 4: REVIEW (use code-reviewer agent)
- Review all changes
- Output: review-comments.md

Phase 5: VERIFY (use build-error-resolver if needed)
- Run tests
- Fix issues
- Output: done or loop back

关键规则:

  • 每个代理获得一个明确的输入并产生一个明确的输出
  • 输出成为下一阶段的输入
  • 永远不要跳过阶段——每个阶段都有价值
  • 在代理之间使用 /clear 保持上下文新鲜
  • 将中间输出存储在文件中(不仅仅是记忆中)

代理抽象层级列表(Agent Abstraction Tierlist)(来自 @menhguin):

第1层:直接增益(容易使用)

  • 子代理(Subagents) ——防止上下文腐烂和临时专业化的直接增益。只有多代理一半的用处,但复杂度低得多
  • 元提示(Metaprompting) ——"我花3分钟来提示一个20分钟的任务。"直接增益——提高稳定性并对假设进行健全性检查
  • 在开始时多问用户(Asking user more at the beginning) ——通常是增益,尽管你必须在计划模式中回答问题

第2层:高技能门槛(较难用好)

  • 长时间运行的代理(Long-running agents) ——需要理解15分钟任务 vs 1.5小时 vs 4小时任务的形态和权衡。需要一些调整,而且显然是非常长的试错过程
  • 并行多代理(Parallel multi-agent) ——方差非常高,仅在高度复杂或分段良好的任务上有用。"如果2个任务需要10分钟,而你花了任意时间在提示上,或者更糟糕的是合并变更,那就适得其反了"
  • 基于角色的多代理(Role-based multi-agent) ——"模型演进太快,硬编码的启发式规则除非套利非常高否则没意义。"难以测试
  • 计算机使用代理(Computer use agents) ——非常早期的范式,需要大量调教。"你在让模型做一年前它们绝对不应该做的事情"

要点:从第1层模式开始。只有在掌握了基础知识并有真正的需求时才升级到第2层。


Tips and Tricks

提示与技巧

一些 MCP 是可替代的,将释放你的上下文窗口

方法如下。

对于版本控制(GitHub)、数据库(Supabase)、部署(Vercel、Railway)等 MCP——这些平台中的大多数已经有健壮的 CLI,MCP 本质上只是对它们的包装。MCP 是一个不错的包装器,但它有成本。

要让 CLI 更像 MCP 一样工作,而实际上不使用 MCP(以及随之而来的上下文窗口缩减),考虑将功能捆绑到技能和命令中。剥离 MCP 暴露的使事情变得简单的工具,并将它们转化为命令。

示例:不要始终加载 GitHub MCP,而是创建一个 /gh-pr 命令来包装 gh pr create 并使用你偏好的选项。不要让 Supabase MCP 消耗上下文,而是创建直接使用 Supabase CLI 的技能。功能是一样的,便利性相似,但你的上下文窗口被释放出来用于实际工作。

这与我收到的一些其他问题相关。自从我发布原始文章以来的过去几天里,Boris 和 Claude Code 团队在记忆管理和优化方面取得了很大进展,主要是 MCP 的懒加载,使它们不再从一开始就消耗你的窗口。以前我会建议在可能的地方将 MCP 转换为技能,以两种方式之一卸载执行 MCP 的功能:在当时启用它(不太理想,因为你需要离开并恢复会话)或者拥有使用 MCP 的 CLI 类似物的技能(如果它们存在的话),让技能成为它的包装器——本质上让它充当伪 MCP。

通过懒加载,上下文窗口问题基本上已经解决。但 token 使用和成本并没有以同样的方式解决。CLI + 技能方法仍然是一种 token 优化方法,其效果可能与使用 MCP 相当或接近。此外,你可以通过 CLI 而不是在上下文中运行 MCP 操作,这显著减少了 token 使用,对于数据库查询或部署等繁重的 MCP 操作特别有用。

Everything Claude Code 速查指南

作者 王小酱
2026年2月27日 16:20

这是黑客松冠军日常使用 10 个月后的完整配置:技能(skills)、钩子(hooks)、子代理(subagents)、MCP、插件(plugins),以及真正好用的部分。

自从 2 月份实验性发布以来,我一直是 Claude Code 的深度用户,并且在 Anthropic x Forum Ventures 黑客松上与 @DRodriguezFX 一起完全使用 Claude Code 构建了 Zenith 并获胜。

cogsec @affaanmustafa · 2025年9月16日

在纽约的 @AnthropicAI x @forumventures 黑客松上拿下了冠军,感谢主办方举办这次精彩的活动(还有 15k 的 Anthropic Credits)

@DRodriguezFX 和我构建了 PMFProbe,帮助创始人从 0 到 1,在 MVP 阶段前验证你的想法,后续还有更多内容

图片1图片2图片3图片4


Skills and Commands

技能与命令

技能类似于规则,被限定在特定的作用域和工作流中。它们是执行特定工作流时的快捷提示词。

在用 Opus 4.5 长时间编码后,想清理无用代码和零散的 .md 文件?运行 /refactor-clean。需要测试?/tdd/e2e/test-coverage。技能和命令可以在一条提示词中链式调用。

链式调用命令链式调用命令

我可以创建一个在检查点更新代码地图(codemap)的技能——让 Claude 快速导航你的代码库,而不必在探索上消耗上下文。

~/.claude/skills/codemap-updater.md

命令是通过斜杠命令执行的技能。它们有重叠,但存储方式不同:

  • Skills: ~/.claude/skills - 更广泛的工作流定义
  • Commands: ~/.claude/commands - 快速可执行的提示词
# Example skill structure
~/.claude/skills/
  pmx-guidelines.md           # Project-specific patterns
  coding-standards.md          # Language best practices
  tdd-workflow/                # Multi-file skill with README.md
  security-review/             # Checklist-based skill

Hooks

钩子

钩子是基于触发器的自动化,在特定事件上触发。与技能不同,它们被限定在工具调用和生命周期事件中。

钩子类型

  • PreToolUse - 工具执行前(验证、提醒)
  • PostToolUse - 工具完成后(格式化、反馈循环)
  • UserPromptSubmit - 当你发送消息时
  • Stop - 当 Claude 完成响应时
  • PreCompact - 上下文压缩前
  • Notification - 权限请求

示例:在运行长时间命令前提醒使用 tmux

{
  "PreToolUse": [
    {
      "matcher": "tool == \"Bash\" && tool_input.command matches \"(npm|pnpm|yarn|cargo|pytest)\"",
      "hooks": [
        {
          "type": "command",
          "command": "if [ -z \"$TMUX\" ]; then echo '[Hook] Consider tmux for session persistence' >&2; fi"
        }
      ]
    }
  ]
}

image.png

在 Claude Code 中运行 PostToolUse 钩子时获得的反馈示例

专业提示: 使用 hookify 插件通过对话方式创建钩子,而不是手动编写 JSON。运行 /hookify 并描述你想要的功能。


Subagents

子代理

子代理是主编排器(主 Claude)可以委派任务的进程,具有有限的作用域。它们可以在后台或前台运行,为主代理释放上下文。

子代理与技能配合很好——一个能够执行你部分技能的子代理可以被委派任务并自主使用这些技能。它们还可以通过特定的工具权限进行沙盒化。

# Example subagent structure
~/.claude/agents/
  planner.md                   # Feature implementation planning
  architect.md                 # System design decisions
  tdd-guide.md                 # Test-driven development
  code-reviewer.md             # Quality/security review
  security-reviewer.md         # Vulnerability analysis
  build-error-resolver.md
  e2e-runner.md
  refactor-cleaner.md

为每个子代理配置允许的工具、MCP 和权限,以实现合理的作用域划分。


Rules and Memory

规则与记忆

你的 .rules 文件夹存放 Claude 应该始终遵循的最佳实践 .md 文件。两种方式:

  • 单一 CLAUDE.md - 所有内容放在一个文件中(用户级或项目级)
  • Rules 文件夹 - 按关注点分组的模块化 .md 文件
~/.claude/rules/
  security.md                  # No hardcoded secrets, validate inputs
  coding-style.md              # Immutability, file organization
  testing.md                   # TDD workflow, 80% coverage
  git-workflow.md              # Commit format, PR process
  agents.md                    # When to delegate to subagents
  performance.md               # Model selection, context management

示例规则:

  • 代码库中不使用 emoji
  • 前端避免紫色调
  • 部署前始终测试代码
  • 优先使用模块化代码而非超大文件
  • 永远不要提交 console.log

MCPs (Model Context Protocol)

MCP(模型上下文协议)

MCP 将 Claude 直接连接到外部服务。它不是 API 的替代品——而是围绕 API 的提示驱动封装,在信息导航方面提供更多灵活性。

示例: Supabase MCP 让 Claude 可以拉取特定数据、直接在上游运行 SQL,无需复制粘贴。数据库、部署平台等同理。

Supabase MCP 列出公共 schema 中的表的示例Supabase MCP 列出公共 schema 中的表的示例

Chrome in Claude: 是一个内置的插件 MCP,让 Claude 可以自主控制你的浏览器——点击查看各种功能。

关键:上下文窗口管理

对 MCP 要精挑细选。我把所有 MCP 放在用户配置中,但禁用所有不用的。导航到 /plugins 并向下滚动或运行 /mcp

你 200k 的上下文窗口在压缩前可能只有 70k,如果启用了太多工具的话。性能会显著下降。

使用 /plugins 导航到 MCP 查看当前已安装的及其状态使用 /plugins 导航到 MCP 查看当前已安装的及其状态

经验法则: 配置中放 20-30 个 MCP,但保持启用的不超过 10 个 / 活跃工具不超过 80 个。


Plugins

插件

插件将工具打包以便于安装,而不需要繁琐的手动设置。一个插件可以是技能 + MCP 的组合,或者钩子/工具的捆绑。

安装插件:

# Add a marketplace
claude plugin marketplace add https://github.com/mixedbread-ai/mgrep
# Open Claude, run /plugins, find new marketplace, install from there

显示新安装的 Mixedbread-Grep 市场显示新安装的 Mixedbread-Grep 市场

LSP 插件: 如果你经常在编辑器外运行 Claude Code,这特别有用。语言服务协议(Language Server Protocol)为 Claude 提供实时类型检查、跳转到定义和智能补全,无需打开 IDE。

# Enabled plugins example
typescript-lsp@claude-plugins-official     # TypeScript intelligence
pyright-lsp@claude-plugins-official        # Python type checking
hookify@claude-plugins-official            # Create hooks conversationally
mgrep@Mixedbread-Grep                      # Better search than ripgrep

与 MCP 同样的警告——注意你的上下文窗口。


Tips and Tricks

技巧和窍门

快捷键

  • Ctrl+U - 删除整行(比疯狂按退格快)
  • ! - 快速 bash 命令前缀
  • @ - 搜索文件
  • / - 启动斜杠命令
  • Shift+Enter - 多行输入
  • Tab - 切换思考模式显示
  • Esc Esc - 中断 Claude / 恢复代码

并行工作流

/fork - 分叉对话,在不重叠的任务上并行工作,而不是排队发送消息

Git Worktrees - 用于有重叠的并行 Claude,避免冲突。每个 worktree 是独立的检出

git worktree add ../feature-branch feature-branch
# Now run separate Claude instances in each worktree

tmux 用于长时间运行的命令: 流式查看和监控 Claude 运行的日志/bash 进程。

tmux new -s dev
# Claude runs commands here, you can detach and reattach
tmux attach -t dev

mgrep > grep: mgrep 比 ripgrep/grep 有显著提升。通过插件市场安装,然后使用 /mgrep 技能。支持本地搜索和网络搜索。

mgrep "function handleSubmit"                    # Local search
mgrep --web "Next.js 15 app router changes"      # Web search

其他有用命令

  • /rewind - 回到之前的状态
  • /statusline - 自定义显示分支、上下文百分比、待办事项
  • /checkpoints - 文件级撤销点
  • /compact - 手动触发上下文压缩

GitHub Actions CI/CD

在你的 PR 上用 GitHub Actions 设置代码审查。配置后 Claude 可以自动审查 PR。

Claude 批准一个 bug 修复 PRClaude 批准一个 bug 修复 PR

沙盒化

对有风险的操作使用沙盒模式——Claude 在受限环境中运行,不影响你的实际系统。(使用 --dangerously-skip-permissions 则相反,让 Claude 自由操作,如果不小心的话可能会造成破坏。)


On Editors

关于编辑器

虽然不需要编辑器,但它可能正面或负面地影响你的 Claude Code 工作流。虽然 Claude Code 可以在任何终端上工作,但配合一个强大的编辑器可以解锁实时文件追踪、快速导航和集成命令执行。

Zed(我的首选)

我使用 Zed——一个基于 Rust 的编辑器,轻量、快速、高度可定制。

为什么 Zed 与 Claude Code 配合良好:

  • Agent Panel Integration(代理面板集成) - Zed 的 Claude 集成让你在 Claude 编辑时实时追踪文件变更。在 Claude 引用的文件间跳转,无需离开编辑器
  • Performance(性能) - 用 Rust 编写,即时打开,处理大型代码库无延迟
  • CMD+Shift+R Command Palette(命令面板) - 在可搜索的 UI 中快速访问所有自定义斜杠命令、调试器和工具。即使你只想运行一个快速命令而不切换到终端
  • Minimal Resource Usage(最小资源占用) - 在繁重操作期间不会与 Claude 争夺系统资源
  • Vim Mode(Vim 模式) - 完整的 vim 键绑定

Zed 编辑器使用 CMD+Shift+R 的自定义命令下拉菜单。右下角靶心图标显示跟随模式。Zed 编辑器使用 CMD+Shift+R 的自定义命令下拉菜单。右下角靶心图标显示跟随模式。

  • Split your screen(分屏) - 一边终端运行 Claude Code,一边编辑器
  • Ctrl + G - 在 Zed 中快速打开 Claude 正在编辑的文件
  • Auto-save(自动保存) - 启用自动保存,确保 Claude 的文件读取始终是最新的
  • Git integration(Git 集成) - 使用编辑器的 Git 功能在提交前审查 Claude 的更改
  • File watchers(文件监视器) - 大多数编辑器自动重新加载已更改的文件,确认已启用

VSCode / Cursor

这也是一个可行的选择,与 Claude Code 配合良好。你可以以终端格式使用,通过 \ide 启用 LSP 功能实现与编辑器的自动同步(现在与插件有些冗余)。或者你可以选择扩展版本,它与编辑器集成度更高,有匹配的 UI。

来自文档来自文档,地址:code.claude.com/docs/en/vs-…


My Setup

我的配置

插件

已安装:(我通常同时只启用其中 4-5 个)

ralph-wiggum@claude-code-plugins         # Loop automation
frontend-design@claude-code-plugins      # UI/UX patterns
commit-commands@claude-code-plugins      # Git workflow
security-guidance@claude-code-plugins    # Security checks
pr-review-toolkit@claude-code-plugins    # PR automation
typescript-lsp@claude-plugins-official   # TS intelligence
hookify@claude-plugins-official          # Hook creation
code-simplifier@claude-plugins-official
feature-dev@claude-code-plugins
explanatory-output-style@claude-code-plugins
code-review@claude-code-plugins
context7@claude-plugins-official         # Live documentation
pyright-lsp@claude-plugins-official      # Python types
mgrep@Mixedbread-Grep                    # Better search

MCP 服务器

已配置(用户级):

{
  "github": {
    "command": "npx",
    "args": ["-y", "@modelcontextprotocol/server-github"]
  },
  "firecrawl": {
    "command": "npx",
    "args": ["-y", "firecrawl-mcp"]
  },
  "supabase": {
    "command": "npx",
    "args": ["-y", "@supabase/mcp-server-supabase@latest", "--project-ref=YOUR_REF"]
  },
  "memory": {
    "command": "npx",
    "args": ["-y", "@modelcontextprotocol/server-memory"]
  },
  "sequential-thinking": {
    "command": "npx",
    "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]
  },
  "vercel": {
    "type": "http",
    "url": "https://mcp.vercel.com"
  },
  "railway": {
    "command": "npx",
    "args": ["-y", "@railway/mcp-server"]
  },
  "cloudflare-docs": {
    "type": "http",
    "url": "https://docs.mcp.cloudflare.com/mcp"
  },
  "cloudflare-workers-bindings": {
    "type": "http",
    "url": "https://bindings.mcp.cloudflare.com/mcp"
  },
  "cloudflare-workers-builds": {
    "type": "http",
    "url": "https://builds.mcp.cloudflare.com/mcp"
  },
  "cloudflare-observability": {
    "type": "http",
    "url": "https://observability.mcp.cloudflare.com/mcp"
  },
  "clickhouse": {
    "type": "http",
    "url": "https://mcp.clickhouse.cloud/mcp"
  },
  "AbletonMCP": {
    "command": "uvx",
    "args": ["ableton-mcp"]
  },
  "magic": {
    "command": "npx",
    "args": ["-y", "@magicuidesign/mcp@latest"]
  }
}

按项目禁用(上下文窗口管理):

# In ~/.claude.json under projects.[path].disabledMcpServers
disabledMcpServers: [
  "playwright",
  "cloudflare-workers-builds",
  "cloudflare-workers-bindings",
  "cloudflare-observability",
  "cloudflare-docs",
  "clickhouse",
  "AbletonMCP",
  "context7",
  "magic"
]

这是关键——我配置了 14 个 MCP,但每个项目只启用约 5-6 个。保持上下文窗口健康。

关键钩子

{
  "PreToolUse": [
    // tmux reminder for long-running commands
    {
      "matcher": "npm|pnpm|yarn|cargo|pytest",
      "hooks": ["tmux reminder"]
    },
    // Block unnecessary .md file creation
    {
      "matcher": "Write && .md file",
      "hooks": ["block unless README/CLAUDE"]
    },
    // Review before git push
    {
      "matcher": "git push",
      "hooks": ["open editor for review"]
    }
  ],
  "PostToolUse": [
    // Auto-format JS/TS with Prettier
    {
      "matcher": "Edit && .ts/.tsx/.js/.jsx",
      "hooks": ["prettier --write"]
    },
    // TypeScript check after edits
    {
      "matcher": "Edit && .ts/.tsx",
      "hooks": ["tsc --noEmit"]
    },
    // Warn about console.log
    {
      "matcher": "Edit",
      "hooks": ["grep console.log warning"]
    }
  ],
  "Stop": [
    // Audit for console.logs before session ends
    {
      "matcher": "*",
      "hooks": ["check modified files for console.log"]
    }
  ]
}

自定义状态栏

显示用户、目录、git 分支(带脏标记)、剩余上下文百分比、模型、时间和待办事项数量:

Mac 根目录中的示例状态栏Mac 根目录中的示例状态栏

规则结构

~/.claude/rules/
  security.md          # Mandatory security checks
  coding-style.md      # Immutability, file size limits
  testing.md           # TDD, 80% coverage
  git-workflow.md      # Conventional commits
  agents.md            # Subagent delegation rules
  patterns.md          # API response formats
  performance.md       # Model selection (Haiku vs Sonnet vs Opus)
  hooks.md             # Hook documentation

子代理

~/.claude/agents/
  planner.md             # Break down features
  architect.md           # System design
  tdd-guide.md           # Write tests first
  code-reviewer.md       # Quality review
  security-reviewer.md   # Vulnerability scan
  build-error-resolver.md
  e2e-runner.md          # Playwright tests
  refactor-cleaner.md    # Dead code removal
  doc-updater.md         # Keep docs synced

Key Takeaways

关键要点

  • 不要过度复杂化 - 把配置当作微调,而非架构设计
  • 上下文窗口很宝贵 - 禁用未使用的 MCP 和插件
  • 并行执行 - 分叉对话,使用 git worktrees
  • 自动化重复工作 - 用钩子处理格式化、代码检查、提醒
  • 限定子代理的作用域 - 有限的工具 = 专注的执行

References

参考链接


注: 这只是部分细节。如果大家感兴趣,我可能会发更多关于具体内容的帖子。

❌
❌