Everything Claude Code (ECC) 常用命令详解

本文系统整理了 Everything Claude Code（ECC）的常用命令体系，围绕核心工作流、测试、代码审查、构建修复、会话管理和学习改进六大类别展开说明。文中重点介绍了 /plan、/tdd、/code-review、/build-fix、/verify 等高频命令的作用、适用场景、参数和典型流程，并补充了测试与语言专用命令的使用方式。后半部分提供了面向实际开发的场景指南，如新功能开发、

XiaoBaibai0o

814人浏览 · 2026-04-10 10:32:09

XiaoBaibai0o · 2026-04-10 10:32:09 发布

概述

Everything Claude Code (ECC) 是一个功能强大的 Claude Code 插件集合，提供了大量斜杠命令（slash commands）来增强开发工作流。本文档详细介绍了 ECC 中最常用的 34 个命令，涵盖核心工作流、测试、代码审查、构建修复、会话管理、学习与改进等六大类别。

命令分类说明

核心工作流命令：开发过程中最基础、最常用的命令，构成 ECC 的基础工作流。
测试相关命令：支持测试驱动开发（TDD）和测试管理的命令。
代码审查命令：针对不同编程语言的代码质量检查和安全性审查。
构建修复命令：帮助诊断和修复构建错误的命令。
会话管理命令：管理 Claude Code 会话的命令，包括保存、恢复、检查点等。
学习与改进命令：从会话中提取知识、创建技能、管理本能的命令。

如何查找和使用命令

在 Claude Code 会话中，输入 / 即可查看所有可用命令。命令通常以 / 开头，后跟命令名称，如 /plan。部分命令支持参数和标志，具体用法请参阅各命令的详细说明。

一、核心工作流命令（6个）

1.1 /plan - 实施计划

功能描述： /plan 命令调用 planner 代理，在编写任何代码之前创建全面的实施计划。它会重新陈述需求、评估风险、创建分步实施计划，并等待用户确认后才开始编写代码。

使用时机：

开始新功能开发时
进行重大的架构变更时
处理复杂的重构任务时
多个文件/组件将受影响时
需求不明确或存在歧义时

基本用法：

/plan [需求描述]

参数说明：

[需求描述]：简要描述需要实现的功能或任务。如果省略，代理会基于当前对话上下文推断需求。

使用示例：用户：/plan 我需要添加市场结算时的实时通知功能

代理（planner）输出示例：

实施计划：实时市场结算通知系统

需求重述

当用户关注的市场结算时，向用户发送通知
支持多种通知渠道（应用内、电子邮件、Webhook）
确保通知可靠送达
包含市场结果和用户持仓结果

实施阶段

阶段1：数据库架构

添加 notifications 表，包含 id、user_id、market_id、type、status、created_at 等字段
添加 user_notification_preferences 表用于存储渠道偏好
为 user_id 和 market_id 创建索引以提升性能

阶段2：通知服务

在 lib/notifications.ts 中创建通知服务
使用 BullMQ/Redis 实现通知队列
添加失败送达的重试逻辑
创建通知模板

阶段3：集成点

接入市场结算逻辑（当状态变为 "resolved" 时）
查询市场中所有有持仓的用户
为每个用户将通知加入队列

阶段4：前端组件

在头部创建 NotificationBell 组件
添加 NotificationList 模态框
通过 Supabase 订阅实现实时更新
添加通知偏好设置页面

依赖项

Redis（用于队列）
电子邮件服务（SendGrid/Resend）
Supabase 实时订阅

风险评估

高风险：电子邮件送达率（需要 SPF/DKIM 配置）
中风险：每个市场 1000+ 用户时的性能问题
中风险：如果市场频繁结算可能导致通知 spam
低风险：实时订阅开销

预估复杂度：中

后端：4-6 小时
前端：3-4 小时
测试：2-3 小时
总计：9-13 小时

等待确认：是否继续执行此计划？（是/否/修改）

工作流程：

分析需求：重新陈述需求，确保理解正确
分解阶段：将实施分解为具体的、可操作的阶段
识别依赖：确定组件间的依赖关系
评估风险：识别潜在问题和阻碍
预估复杂度：评估实施复杂度（高/中/低）
呈现计划：展示完整计划并等待用户明确确认

注意事项：

关键：planner 代理在您明确确认计划（回复"是"、"继续"等肯定回答）之前不会编写任何代码。
如果需要修改，可以回复：
- "修改：[您的修改内容]"
- "不同方法：[替代方案]"
- "跳过阶段2，先执行阶段3"
计划确认后，可使用 /tdd 进行测试驱动开发，使用 /build-fix 处理构建错误，使用 /code-review 审查完成后的实现。

相关命令：

/tdd：测试驱动开发，用于实施计划后的代码实现
/build-fix：如果出现构建错误，用于修复
/code-review：审查完成后的实现代码
/prp-plan：更深入的规划，包含 PRD 集成、代码库分析和模式提取

底层技能：

技能文件：commands/plan.md
代理文件：agents/planner.md

1.2 /tdd - 测试驱动开发

功能描述： /tdd 命令强制执行测试驱动开发（TDD）工作流：首先搭建接口 → 编写失败测试 → 实现功能 → 验证测试覆盖率（80%以上）。这是 ECC 的核心开发工作流之一。

使用时机：

实施新功能或模块时
修复 bug 并需要确保测试覆盖时
重构代码并需要维护测试覆盖率时
任何需要高质量、可测试代码的场景

基本用法：

/tdd [功能描述]

参数说明：

[功能描述]：要实现的 TDD 功能描述。如果省略，将基于当前对话上下文推断。

使用示例：用户：/tdd 实现一个计算市场流动性分数的函数

代理（TDD 工作流）输出示例：

TDD 工作流：市场流动性分数计算

步骤1：搭建接口（RED） 创建接口文件 lib/liquidity.ts：

export interface MarketData {
  totalVolume: number
  bidAskSpread: number
  activeTraders: number
  lastTradeTime: Date
}

export function calculateLiquidityScore(market: MarketData): number {
  throw new Error('Not implemented')
}

步骤2：编写失败测试（RED） 创建测试文件 lib/liquidity.test.ts：

import { calculateLiquidityScore, MarketData } from './liquidity'

describe('calculateLiquidityScore', () => {
  test('should return high score for liquid market', () => {
    const market: MarketData = {
      totalVolume: 5000,
      bidAskSpread: 0.01,
      activeTraders: 50,
      lastTradeTime: new Date()
    }
    expect(calculateLiquidityScore(market)).toBeGreaterThan(80)
  })

  test('should return low score for illiquid market', () => {
    const market: MarketData = {
      totalVolume: 100,
      bidAskSpread: 0.1,
      activeTraders: 5,
      lastTradeTime: new Date(Date.now() - 24 * 60 * 60 * 1000) // 24小时前
    }
    expect(calculateLiquidityScore(market)).toBeLessThan(20)
  })

  test('should handle edge case: zero volume', () => {
    const market: MarketData = {
      totalVolume: 0,
      bidAskSpread: 0.05,
      activeTraders: 0,
      lastTradeTime: new Date()
    }
    expect(calculateLiquidityScore(market)).toBe(0)
  })
})

运行测试确认失败：

npm test lib/liquidity.test.ts
FAIL lib/liquidity.test.ts
  ✕ should return high score for liquid market
  ✕ should return low score for illiquid market
  ✕ should handle edge case: zero volume

步骤3：实现最小化代码（GREEN） 实现 calculateLiquidityScore 函数：

export function calculateLiquidityScore(market: MarketData): number {
  if (market.totalVolume === 0) return 0

  const volumeScore = Math.min(market.totalVolume / 1000, 100)
  const spreadScore = Math.max(100 - (market.bidAskSpread * 1000), 0)
  const traderScore = Math.min(market.activeTraders / 10, 100)
  const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60)
  const recencyScore = Math.max(100 - (hoursSinceLastTrade * 10), 0)

  const score = (
    volumeScore * 0.4 +
    spreadScore * 0.3 +
    traderScore * 0.2 +
    recencyScore * 0.1
  )

  return Math.min(Math.max(score, 0), 100)
}

运行测试确认通过：

npm test lib/liquidity.test.ts
PASS lib/liquidity.test.ts
  ✓ should return high score for liquid market
  ✓ should return low score for illiquid market
  ✓ should handle edge case: zero volume

步骤4：重构（REFACTOR） 优化代码结构，提取常量，提高可读性：

const WEIGHTS = {
  VOLUME: 0.4,
  SPREAD: 0.3,
  TRADERS: 0.2,
  RECENCY: 0.1,
} as const

const SCALE_FACTORS = {
  VOLUME: 1000,
  SPREAD: 1000,
  TRADERS: 10,
  RECENCY: 10,
} as const

export function calculateLiquidityScore(market: MarketData): number {
  if (market.totalVolume === 0) return 0

  const volumeScore = Math.min(market.totalVolume / SCALE_FACTORS.VOLUME, 100)
  const spreadScore = Math.max(100 - (market.bidAskSpread * SCALE_FACTORS.SPREAD), 0)
  const traderScore = Math.min(market.activeTraders / SCALE_FACTORS.TRADERS, 100)
  const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60)
  const recencyScore = Math.max(100 - (hoursSinceLastTrade * SCALE_FACTORS.RECENCY), 0)

  const score = (
    volumeScore * WEIGHTS.VOLUME +
    spreadScore * WEIGHTS.SPREAD +
    traderScore * WEIGHTS.TRADERS +
    recencyScore * WEIGHTS.RECENCY
  )

  return Math.min(Math.max(score, 0), 100)
}

运行测试确认重构后依然通过。

步骤5：验证覆盖率 运行覆盖率测试，确保达到 80%+：

npx jest --coverage lib/liquidity.test.ts
------------|---------|----------|---------|---------|-------------------
File        | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
------------|---------|----------|---------|---------|-------------------
liquidity.ts| 100.00  | 100.00   | 100.00  | 100.00  |
------------|---------|----------|---------|---------|-------------------

覆盖率达标：100% 语句覆盖率，100% 分支覆盖率。

工作流程：

RED：搭建接口并编写失败测试
RED：运行测试确认失败
GREEN：实现最小化代码使测试通过
REFACTOR：优化代码结构，提高可读性
验证：检查测试覆盖率（必须达到 80%+）

注意事项：

严格遵循 RED → GREEN → REFACTOR 循环
测试必须先行编写
覆盖率必须明确验证，确保达到 80% 以上
检查点证据必须清晰保存

相关命令：

/plan：在 TDD 之前进行规划
/test-coverage：专门检查测试覆盖率
/code-review：TDD 完成后进行代码审查
语言特定的 TDD 命令：/go-test、/kotlin-test、/rust-test、/cpp-test

底层技能：

技能文件：skills/tdd-workflow/SKILL.md
命令文件：commands/tdd.md（遗留兼容层）

1.3 /code-review - 代码审查

功能描述： /code-review 命令对本地未提交的更改或 GitHub Pull Request 进行全面的代码质量、安全性和可维护性审查。支持两种模式：本地审查模式（默认）和 PR 审查模式（当提供 PR 编号或 URL 时）。

使用时机：

提交代码前进行本地审查
审查 GitHub Pull Request
确保代码符合安全标准和最佳实践
识别潜在的安全漏洞和代码质量问题

基本用法：

/code-review [pr-number | pr-url | 留空进行本地审查]

参数说明：

pr-number：GitHub Pull Request 编号（例如：123）
pr-url：GitHub Pull Request 的完整 URL
留空：对本地未提交的更改进行审查

使用示例：

示例1：本地代码审查
/code-review

示例2：审查 GitHub PR #123
/code-review 123

示例3：审查 GitHub PR 通过 URL
/code-review https://github.com/owner/repo/pull/456

工作流程：

本地审查模式：

收集阶段：使用 git diff --name-only HEAD 获取更改的文件列表
审查阶段：逐个读取每个更改的文件，检查：
- 安全问题（关键）：硬编码凭证、API 密钥、SQL 注入漏洞、XSS 漏洞、缺少输入验证、不安全的依赖、路径遍历风险
- 代码质量（高）：函数超过 50 行、文件超过 800 行、嵌套深度超过 4 层、缺少错误处理、console.log 语句、TODO/FIXME 注释、缺少公共 API 的 JSDoc
- 最佳实践（中）：突变模式（应使用不可变）、代码/注释中使用表情符号、新代码缺少测试、可访问性问题（a11y）
报告阶段：生成包含以下内容的报告：
- 严重程度：关键、高、中、低
- 文件位置和行号
- 问题描述
- 建议的修复方案
- 如果发现关键或高级别问题，则阻止提交

PR 审查模式：

获取阶段：获取 PR 差异、读取完整文件、运行验证
审查阶段：类似于本地审查，但针对 PR 中的所有更改
发布阶段：在 GitHub PR 上发布审查评论

注意事项：

如果发现安全问题（关键或高级别），将阻止代码提交
永远不批准存在安全漏洞的代码
审查过程会检查硬编码的凭证、API 密钥等敏感信息
支持 GitHub PR 审查，需要提供 PR 编号或 URL

相关命令：

语言特定的代码审查命令：/python-review、/go-review、/kotlin-review、/rust-review、/cpp-review
/plan：在代码审查前进行规划
/tdd：在代码审查后验证测试覆盖率
/verify：完整的验证循环，包含代码审查

底层技能：

命令文件：commands/code-review.md
基于 PRPs-agentic-eng 的 PR 审查模式，属于 PRP 工作流系列

1.4 /build-fix - 构建修复

功能描述： /build-fix 命令自动检测项目的构建系统，并逐步修复构建和类型错误。它通过最小的、安全的更改来解决问题，一次修复一个错误，确保不会引入新的问题。

使用时机：

项目构建失败时（编译错误、类型错误）
需要快速修复构建问题以便继续开发时
在代码更改后出现构建错误时
作为持续集成（CI）失败后的本地修复工具

基本用法：

/build-fix

参数说明：该命令无需参数，会自动检测项目类型并运行相应的构建命令。

使用示例：用户：/build-fix

代理（构建修复）输出示例：

构建修复工作流

步骤1：检测构建系统 检测到 package.json 中存在 build 脚本，使用 npm run build 命令。

步骤2：运行构建并收集错误 运行 npm run build，发现 3 个 TypeScript 错误：

错误1：src/utils.ts(15,7): error TS2304: Cannot find name 'UserData'. 错误2：src/api.ts(42,21): error TS2345: Argument of type 'string' is not assignable to parameter of type 'number'. 错误3：src/components/Button.tsx(8,10): error TS2307: Cannot find module './styles'.

步骤3：逐个修复错误

修复错误1：缺少类型定义 读取 src/utils.ts 第 15 行，发现使用了未定义的 UserData 类型。修复：添加导入语句 import { UserData } from '../types'。

修复错误2：类型不匹配 读取 src/api.ts 第 42 行，发现字符串参数传递给期望数字的函数。修复：将参数转换为数字 Number(userId)。

修复错误3：缺少模块 读取 src/components/Button.tsx，发现缺少 ./styles 模块。修复：创建 src/components/styles.ts 文件并导出必要的样式。

步骤4：验证修复 重新运行 npm run build，所有错误已修复，构建成功。

步骤5：总结

修复了 3 个构建错误
没有引入新的错误
构建现在可以通过

工作流程：

检测构建系统：根据项目文件识别构建工具（npm、Cargo、Gradle、Go 等）
解析和分组错误：运行构建命令，捕获错误，按文件路径分组，按依赖顺序排序
修复循环：逐个处理每个错误：
- 读取文件，查看错误上下文
- 诊断根本原因（缺少导入、类型错误、语法错误）
- 使用最小的更改修复错误
- 重新运行构建验证修复
安全防护：如果出现以下情况，停止并询问用户：
- 修复引入的错误比解决的问题更多
- 同一错误尝试 3 次后仍然存在
- 修复需要架构变更（不仅仅是构建修复）
- 构建错误源于缺少依赖
总结：显示修复结果、剩余错误、建议的后续步骤

恢复策略：

缺少模块/导入：检查包是否安装，建议安装命令
类型不匹配：读取两种类型定义，修复较窄的类型
循环依赖：识别导入图中的循环，建议提取
版本冲突：检查 package.json / Cargo.toml 中的版本约束
构建工具配置错误：读取配置文件，与工作的默认配置比较

注意事项：

一次只修复一个错误以确保安全
优先使用最小的差异，而不是重构
如果问题超出构建修复范围，会建议使用其他命令（如 /plan）
支持多种构建系统：Node.js/npm、TypeScript、Rust/Cargo、Java/Maven、Gradle、Go、Python 等

相关命令：

语言特定的构建修复命令：/go-build、/kotlin-build、/rust-build、/cpp-build、/gradle-build
/verify：完整的验证循环，包含构建检查
/plan：如果构建错误需要架构变更，进行规划

底层技能：

命令文件：commands/build-fix.md

1.5 /verify - 完整验证循环

功能描述： /verify 命令运行完整的验证循环：构建 → 代码检查 → 测试 → 类型检查。它确保代码在多个维度上都符合质量标准，是发布前的最终验证步骤。

使用时机：

代码更改完成后，提交或合并前
持续集成（CI）管道中作为质量门
发布前进行最终验证
需要全面检查代码健康状况时

基本用法：

/verify

参数说明：该命令无需参数，会根据项目类型自动选择合适的验证深度和顺序。

使用示例：用户：/verify

代理（验证循环）输出示例：

完整验证循环

步骤1：构建验证 运行 npm run build... ✓ 构建成功，无错误

步骤2：类型检查 运行 npx tsc --noEmit... ✓ 类型检查通过，无类型错误

步骤3：代码检查 运行 npm run lint... ⚠️ 发现 2 个代码风格问题：

src/utils.ts:15：行长度超过 100 字符
src/api.ts:42：缺少 JSDoc 注释

步骤4：测试运行 运行 npm test... ✓ 所有测试通过（45 个测试，覆盖率 92%）

步骤5：安全/日志检查 检查安全问题和日志输出... ✓ 未发现硬编码凭证 ✓ 未发现敏感信息泄露 ⚠️ 发现 1 个 console.log 语句：src/debug.ts:8

步骤6：差异审查 审查未提交的更改... ✓ 更改符合项目标准 ⚠️ 建议：为新增的公共函数添加 JSDoc

验证结果

✅ 构建：通过
✅ 类型：通过
⚠️ 代码检查：2 个警告（非阻塞）
✅ 测试：通过（覆盖率 92%）
⚠️ 安全/日志：1 个警告（非阻塞）
⚠️ 差异审查：1 个建议

总体状态：验证通过，有少量建议改进。

工作流程：

构建验证：运行项目构建命令，确保编译/构建成功
类型检查：运行类型检查器（如 TypeScript、MyPy 等），确保类型安全
代码检查：运行代码检查工具（如 ESLint、Pylint 等），确保代码风格一致
测试运行：运行测试套件，确保功能正确且测试覆盖率达标
安全/日志检查：检查安全漏洞（硬编码凭证、敏感信息）和调试日志
差异审查：审查未提交的更改，确保符合项目标准
报告结果：提供每个步骤的验证结果和总体状态

注意事项：

验证深度会根据用户请求的模式和项目类型自动调整
验证顺序会根据当前仓库的配置进行优化
报告仅包含验证结论和阻碍因素，而不是完整的检查清单
如果任何关键步骤失败（构建、类型检查、测试失败），验证将标记为失败
警告和建议不会阻塞验证通过，但会提供改进建议

相关命令：

/build-fix：专门修复构建错误
/test-coverage：专门检查测试覆盖率
/code-review：专门的代码审查
/quality-gate：质量门检查，专注于项目标准

底层技能：

技能文件：skills/verification-loop/SKILL.md
命令文件：commands/verify.md（遗留兼容层）

1.6 /quality-gate - 质量门检查

功能描述： /quality-gate 命令按需对文件或项目范围运行 ECC 质量管道。它检测语言/工具，运行格式化检查、代码检查/类型检查，并生成简洁的修复清单。这是钩子（hook）行为的手动调用版本。

使用时机：

在提交前手动运行质量检查
检查特定文件或目录的质量状况
作为 CI/CD 管道的一部分进行质量验证
需要自动修复代码格式问题时

基本用法：

/quality-gate [路径|.] [--fix] [--strict]

参数说明：

[路径|.]：可选的目标路径，默认为当前目录（.）
--fix：可选，允许自动格式化/修复（在配置支持的情况下）
--strict：可选，在支持的情况下将警告视为失败

使用示例：

示例1：检查当前目录
/quality-gate

示例2：检查特定目录
/quality-gate src/components

示例3：检查并自动修复
/quality-gate src/utils --fix

示例4：严格模式检查
/quality-gate . --strict

工作流程：

检测语言/工具：根据目标路径检测项目语言和工具链
运行格式化检查：运行格式化工具（如 Prettier、Black、gofmt 等）
运行代码检查/类型检查：运行代码检查（ESLint、Pylint 等）和类型检查（TypeScript、MyPy 等）
生成修复清单：提供简洁的问题列表和修复建议

输出示例：用户：/quality-gate src/utils --fix

代理（质量门）输出示例：

质量门检查：src/utils

检测到的工具

语言：TypeScript
格式化工具：Prettier
代码检查工具：ESLint
类型检查工具：TypeScript

检查结果

格式化检查 ⚠️ 发现 3 个格式化问题：

src/utils/date.ts:15：行尾缺少分号
src/utils/string.ts:42：缩进不一致（应为 2 个空格，实际为 4 个）
src/utils/math.ts:8：超过最大行长度（120 > 100）

✅ 自动修复已应用（使用 --fix 标志）

代码检查 ⚠️ 发现 2 个代码检查问题：

src/utils/date.ts:30：使用 any 类型，应使用具体类型
src/utils/string.ts:55：未使用的变量 temp

类型检查 ✅ 类型检查通过，无错误

修复清单

修复 src/utils/date.ts:30：将 any 替换为具体类型
修复 src/utils/string.ts:55：删除未使用的变量 temp 或使用它

总体状态

格式化：已自动修复
代码检查：2 个警告（需要手动修复）
类型检查：通过

注意事项：

此命令是钩子行为的手动调用版本，提供相同的检查但由操作员触发
使用 --fix 标志可以自动修复格式化问题，但代码逻辑问题仍需手动修复
使用 --strict 标志会将警告视为失败，适用于 CI/CD 环境
支持多种语言和工具链：JavaScript/TypeScript、Python、Go、Rust、Java/Kotlin 等
检查范围可以是单个文件、目录或整个项目

相关命令：

/verify：完整的验证循环，包含质量门检查
/code-review：更全面的代码审查，包含安全性和最佳实践
/build-fix：专门修复构建错误

底层技能：

命令文件：commands/quality-gate.md

二、测试相关命令（6个）

2.1 /e2e - 端到端测试

功能描述： /e2e 命令生成并运行 Playwright 端到端测试，捕获屏幕截图、视频和跟踪信息。它模拟真实用户操作，验证整个应用流程。

使用时机：

需要验证关键用户流程时
发布前进行端到端测试
回归测试确保功能完整
跨浏览器兼容性测试

基本用法：

/e2e [测试描述]

示例：

/e2e 测试用户登录流程

生成登录测试脚本，模拟用户输入凭据、点击登录按钮、验证重定向。

相关命令：/tdd、/test-coverage

2.2 /test-coverage - 测试覆盖率

功能描述： /test-coverage 命令报告测试覆盖率，识别测试覆盖的空白区域。它分析测试套件，显示语句、分支、函数和行的覆盖率。

使用时机：

评估测试套件的完整性
识别需要更多测试的代码区域
确保满足覆盖率要求（如80%+）
代码更改后验证测试覆盖率

基本用法：

/test-coverage [目标路径]

示例：

/test-coverage src/components

分析 src/components 目录下的测试覆盖率，生成覆盖率报告并指出未覆盖的代码行。

相关命令：/tdd、/verify

2.3 /go-test - Go语言TDD

功能描述： /go-test 命令为 Go 语言提供测试驱动开发（TDD）工作流，支持表驱动测试，确保 80%+ 的测试覆盖率（使用 go test -cover）。

使用时机：

开发 Go 语言功能时
需要遵循 Go 最佳实践的 TDD 时
确保 Go 代码具有高质量的测试覆盖率时

基本用法：

/go-test [功能描述]

示例：

/go-test 实现一个 HTTP 中间件

创建 Go 测试文件，使用表驱动测试覆盖各种场景，然后实现中间件功能。

相关命令：/tdd、/go-review、/go-build

2.4 /kotlin-test - Kotlin语言TDD

功能描述： /kotlin-test 命令为 Kotlin 语言提供测试驱动开发（TDD）工作流，使用 Kotest 测试框架和 Kover 覆盖率工具。

使用时机：

开发 Kotlin/JVM 或 Kotlin Multiplatform 功能时
需要遵循 Kotlin 最佳实践的 TDD 时
确保 Kotlin 代码具有高质量的测试覆盖率时

基本用法：

/kotlin-test [功能描述]

示例：

/kotlin-test 实现一个数据类验证器

创建 Kotlin 测试文件，使用 Kotest 的丰富断言，然后实现验证器逻辑。

相关命令：/tdd、/kotlin-review、/kotlin-build

2.5 /rust-test - Rust语言TDD

功能描述： /rust-test 命令为 Rust 语言提供测试驱动开发（TDD）工作流，支持单元测试和集成测试（使用 cargo test）。

使用时机：

开发 Rust 库或应用程序时
需要遵循 Rust 最佳实践的 TDD 时
确保 Rust 代码具有全面测试时

基本用法：

/rust-test [功能描述]

示例：

/rust-test 实现一个解析器组合子

创建 Rust 测试模块，编写单元测试和集成测试，然后实现解析器功能。

相关命令：/tdd、/rust-review、/rust-build

2.6 /cpp-test - C++语言TDD

功能描述： /cpp-test 命令为 C++ 语言提供测试驱动开发（TDD）工作流，使用 GoogleTest 测试框架和 gcov/lcov 覆盖率工具。

使用时机：

开发 C++ 库或应用程序时
需要遵循现代 C++ 最佳实践的 TDD 时
确保 C++ 代码具有高质量的测试覆盖率时

基本用法：

/cpp-test [功能描述]

示例：

/cpp-test 实现一个矩阵运算库

创建 GoogleTest 测试用例，编写测试覆盖各种矩阵操作，然后实现矩阵运算功能。

相关命令：/tdd、/cpp-review、/cpp-build

三、代码审查命令（5个）

3.1 /python-review - Python代码审查

功能描述： /python-review 命令对 Python 代码进行全面的代码审查，检查 PEP 8 规范、类型提示、安全问题和惯用模式。

使用时机：

审查 Python 代码质量时
确保代码符合 Python 最佳实践时
识别 Python 特定安全漏洞时

基本用法：

/python-review [文件或目录]

示例：

/python-review src/api.py

审查 src/api.py 文件，检查 PEP 8 合规性、类型提示、安全性等。

相关命令：/code-review、/verify

3.2 /go-review - Go代码审查

功能描述： /go-review 命令对 Go 代码进行全面的代码审查，检查惯用模式、并发安全性、错误处理和 Go 最佳实践。

使用时机：

审查 Go 代码质量时
确保代码符合 Go 惯用模式时
识别并发安全问题和错误处理缺陷时

基本用法：

/go-review [文件或目录]

示例：

/go-review cmd/server

审查 cmd/server 目录下的 Go 代码，检查惯用模式、错误处理、并发安全等。

相关命令：/code-review、/go-test、/go-build

3.3 /kotlin-review - Kotlin代码审查

功能描述： /kotlin-review 命令对 Kotlin 代码进行全面的代码审查，检查空安全、协程安全性、清洁架构和 Kotlin 最佳实践。

使用时机：

审查 Kotlin 代码质量时
确保代码充分利用 Kotlin 特性时
识别空安全问题和协程安全缺陷时

基本用法：

/kotlin-review [文件或目录]

示例：

/kotlin-review src/main/kotlin

审查 Kotlin 代码，检查空安全、协程使用、扩展函数等最佳实践。

相关命令：/code-review、/kotlin-test、/kotlin-build

3.4 /rust-review - Rust代码审查

功能描述： /rust-review 命令对 Rust 代码进行全面的代码审查，检查所有权、生命周期、不安全使用和 Rust 最佳实践。

使用时机：

审查 Rust 代码质量时
确保代码符合 Rust 所有权模型时
识别不安全代码和生命周期问题时

基本用法：

/rust-review [文件或目录]

示例：

/rust-review src/lib.rs

审查 Rust 代码，检查所有权、生命周期、错误处理、unsafe 使用等。

相关命令：/code-review、/rust-test、/rust-build

3.5 /cpp-review - C++代码审查

功能描述： /cpp-review 命令对 C++ 代码进行全面的代码审查，检查内存安全、现代惯用法、并发安全和 C++ 最佳实践。

使用时机：

审查 C++ 代码质量时
确保代码使用现代 C++ 特性时
识别内存安全问题和并发缺陷时

基本用法：

/cpp-review [文件或目录]

示例：

/cpp-review include/ library.cpp

审查 C++ 代码，检查内存管理、智能指针使用、移动语义、并发安全等。

相关命令：/code-review、/cpp-test、/cpp-build

四、构建修复命令（5个）

4.1 /go-build - Go构建修复

功能描述： /go-build 命令专门修复 Go 项目的构建错误，处理导入问题、类型错误和 Go 特定的构建问题。

使用时机：

Go 项目构建失败时
需要修复 Go 编译错误时
Go 依赖管理出现问题时

基本用法：

/go-build

示例：

/go-build

检测 Go 项目，运行 go build ./...，逐个修复编译错误。

相关命令：/build-fix、/go-test、/go-review

4.2 /kotlin-build - Kotlin构建修复

功能描述： /kotlin-build 命令专门修复 Kotlin 项目的构建错误，处理 Gradle/Maven 配置、类型推断问题和 Kotlin 特定的编译问题。

使用时机：

Kotlin 项目构建失败时
需要修复 Kotlin 编译错误时
Gradle/Maven 依赖冲突时

基本用法：

/kotlin-build

示例：

/kotlin-build

检测 Kotlin 项目，运行 Gradle 或 Maven 构建，逐个修复编译错误。

相关命令：/build-fix、/kotlin-test、/kotlin-review

4.3 /rust-build - Rust构建修复

功能描述： /rust-build 命令专门修复 Rust 项目的构建错误，处理 Cargo 依赖、所有权问题和 Rust 特定的编译错误。

使用时机：

Rust 项目构建失败时
需要修复 Cargo 编译错误时
依赖版本冲突或特性问题时

基本用法：

/rust-build

示例：

/rust-build

检测 Rust 项目，运行 cargo build，逐个修复编译错误。

相关命令：/build-fix、/rust-test、/rust-review

4.4 /cpp-build - C++构建修复

功能描述： /cpp-build 命令专门修复 C++ 项目的构建错误，处理 CMake/Makefile 配置、头文件依赖和 C++ 特定的编译问题。

使用时机：

C++ 项目构建失败时
需要修复 C++ 编译错误时
链接错误或头文件问题时

基本用法：

/cpp-build

示例：

/cpp-build

检测 C++ 项目，运行 CMake 或 Makefile 构建，逐个修复编译错误。

相关命令：/build-fix、/cpp-test、/cpp-review

4.5 /gradle-build - Gradle构建修复

功能描述： /gradle-build 命令专门修复 Gradle 项目的构建错误，处理 Gradle 配置、依赖冲突和 Java/Kotlin 编译问题。

使用时机：

Gradle 项目构建失败时
需要修复 Gradle 编译错误时
依赖解析失败或插件冲突时

基本用法：

/gradle-build

示例：

/gradle-build

检测 Gradle 项目，运行 ./gradlew build，逐个修复构建错误。

相关命令：/build-fix、/kotlin-build、/java-build（如存在）

五、会话管理命令（6个）

5.1 /save-session - 保存会话

功能描述： /save-session 命令保存当前 Claude Code 会话状态，包括对话历史、上下文和当前任务状态，以便后续恢复。

使用时机：

长时间会话需要中断时
重要进展需要保存时
会话即将超时或需要暂停时

基本用法：

/save-session [会话名称]

示例：

/save-session 用户认证功能开发

保存当前会话，生成会话 ID 和恢复信息。

相关命令：/resume-session、/sessions

5.2 /resume-session - 恢复会话

功能描述： /resume-session 命令加载最近保存的会话状态，恢复之前的对话历史、上下文和任务进度。

使用时机：

继续之前中断的会话时
需要恢复之前的工作状态时
切换回重要任务时

基本用法：

/resume-session [会话ID或名称]

示例：

/resume-session 用户认证功能开发

加载之前保存的会话，恢复所有上下文和状态。

相关命令：/save-session、/sessions

5.3 /sessions - 会话管理

功能描述： /sessions 命令浏览、搜索和管理保存的会话历史，支持查看、筛选和删除会话。

使用时机：

查看所有保存的会话时
搜索特定会话时
管理会话存储空间时

基本用法：

/sessions [搜索词]

示例：

/sessions 认证

列出所有包含"认证"关键词的保存会话。

相关命令：/save-session、/resume-session

5.4 /checkpoint - 检查点标记

功能描述： /checkpoint 命令标记当前会话的检查点，记录重要进展状态，便于后续回溯或比较。

使用时机：

完成重要里程碑时
需要标记可回溯状态时
复杂任务需要多个检查点时

基本用法：

/checkpoint [检查点描述]

示例：

/checkpoint 完成用户模型设计

标记当前会话状态，记录检查点描述和时间戳。

相关命令：/save-session、/sessions

5.5 /aside - 旁路问答

功能描述： /aside 命令回答快速侧问题而不丢失当前任务上下文，适用于临时查询或澄清问题。

使用时机：

需要快速查询信息时
澄清与当前任务相关的问题时
不想中断主要任务流程时

基本用法：

/aside [问题]

示例：

/aside React 中如何条件渲染组件？

快速回答 React 条件渲染问题，然后恢复主任务上下文。

相关命令：无特定相关命令，用于辅助主任务。

5.6 /context-budget - 上下文预算分析

功能描述： /context-budget 命令分析当前上下文窗口使用情况，帮助优化对话长度和内容管理。

使用时机：

对话接近上下文限制时
需要优化上下文使用效率时
管理长对话的存储空间时

基本用法：

/context-budget

示例：

/context-budget

分析当前上下文使用情况，显示已用/剩余token数量，提供优化建议。

相关命令：/save-session、/resume-session

六、学习与改进命令（6个）

6.1 /learn - 模式提取

功能描述： /learn 命令从当前会话中提取可重用的模式和知识，转化为可保存的本能（instinct）或技能。

使用时机：

完成有价值的任务或解决问题后
发现可重用的工作模式时
需要将经验转化为持久知识时

基本用法：

/learn [模式名称]

示例：

/learn API错误处理模式

分析当前会话，提取API错误处理的最佳实践和模式，保存为可重用知识。

相关命令：/learn-eval、/evolve、/promote

6.2 /learn-eval - 学习评估

功能描述： /learn-eval 命令从会话中提取模式并在保存前进行自我评估质量，确保提取的知识具有高质量和实用性。

使用时机：

提取重要知识并需要质量保证时
确保学习内容符合标准时
创建正式的可重用技能前

基本用法：

/learn-eval [模式名称]

示例：

/learn-eval 数据库迁移最佳实践

提取数据库迁移模式，评估其完整性、准确性和实用性，然后保存。

相关命令：/learn、/evolve、/skill-create

6.3 /evolve - 本能进化

功能描述： /evolve 命令分析学习到的本能，建议进化的技能结构，优化知识组织和重用效率。

使用时机：

本能库积累到一定规模时
需要优化知识组织结构时
提高本能重用效率时

基本用法：

/evolve

示例：

/evolve

分析现有的本能库，识别模式、冗余和优化机会，建议改进的技能结构。

相关命令：/learn、/learn-eval、/instinct-status

6.4 /promote - 本能提升

功能描述： /promote 命令将项目范围的本能提升到全局范围，使有价值的模式在所有项目中可用。

使用时机：

发现具有跨项目价值的本能时
需要共享最佳实践时
标准化工作流程时

基本用法：

/promote [本能名称]

示例：

/promote React组件测试模式

将当前项目的React组件测试模式提升为全局本能，使其在所有项目中可用。

相关命令：/learn、/learn-eval、/instinct-status

6.5 /instinct-status - 本能状态

功能描述： /instinct-status 命令检查本能的状态和健康状况，显示可用本能、使用统计和存储信息。

使用时机：

查看本能库状态时
诊断本能相关问题时
管理本能存储空间时

基本用法：

/instinct-status

示例：

/instinct-status

显示本能库统计信息：本能数量、存储使用、最近使用情况等。

相关命令：/learn、/evolve、/promote

6.6 /skill-create - 技能创建

功能描述： /skill-create 命令分析本地git历史，提取模式并生成可重用的技能，将开发经验转化为自动化工具。

使用时机：

从成功的开发任务中创建技能时
自动化重复性工作流程时
将专家知识转化为可重用工具时

基本用法：

/skill-create [技能描述]

示例：

/skill-create 数据库迁移技能

分析git历史中的数据库迁移相关提交，提取最佳实践，创建数据库迁移技能。

相关命令：/learn、/learn-eval、/evolve

七、使用场景指南

7.1 开始新功能开发

工作流程：

研究与重用：在编写新代码前，先搜索现有实现
- 使用 GitHub 代码搜索（gh search repos、gh search code）
- 查阅库文档确认 API 行为
- 搜索包注册表（npm、PyPI、crates.io 等）
- 优先采用或移植经验证的方法
规划阶段：使用 /plan 命令
```
/plan 实现用户认证功能
```
- 创建详细实现计划
- 识别依赖和风险
- 分解为可执行的阶段
测试驱动开发：使用 /tdd 命令
```
/tdd 实现登录验证逻辑
```
- 先写失败测试（RED）
- 实现代码通过测试（GREEN）
- 重构优化（IMPROVE）
- 确保 80%+ 测试覆盖率
代码审查：使用 /code-review 命令
```
/code-review
```
- 检查代码质量和安全性
- 解决关键和高优先级问题
验证：使用 /verify 命令
```
/verify
```
- 运行完整验证循环
- 确保构建、类型、测试全部通过

核心命令组合： /plan → /tdd → /code-review → /verify

7.2 修复Bug流程

工作流程：

重现问题：确认 bug 可重现，收集相关错误信息
定位问题：分析错误日志，确定问题根源
修复构建错误：如果存在构建问题，使用 /build-fix
```
/build-fix
```
编写测试：创建重现 bug 的测试用例
```
/tdd 修复用户数据导出失败的bug
```
实施修复：最小化更改解决问题
验证修复：运行相关测试，确保修复有效
全面验证：使用 /verify 确保修复不引入新问题
```
/verify
```
代码审查：使用 /code-review 审查修复
```
/code-review
```

核心命令组合： /build-fix（如需要）→ /tdd → /verify → /code-review

7.3 代码审查流程

工作流程：

本地审查：提交前进行本地审查
```
/code-review
```
- 检查安全问题（硬编码凭证、SQL注入等）
- 检查代码质量（函数长度、嵌套深度等）
- 检查最佳实践（错误处理、测试覆盖等）

语言特定审查：针对特定语言使用专业审查

/python-review src/api.py

/go-review cmd/server

/rust-review src/lib.rs

质量门检查：运行质量管道
```
/quality-gate src --fix
```
- 自动修复格式化问题
- 检查代码风格一致性
测试覆盖率验证：确保测试充分
```
/test-coverage src
```
端到端测试：验证关键用户流程
```
/e2e 测试用户注册流程
```

核心命令组合： /code-review → 语言特定审查 → /quality-gate → /test-coverage

7.4 会话管理最佳实践

工作流程：

定期保存：重要进展后保存会话
```
/save-session 完成用户模型设计
```
检查点标记：关键里程碑标记检查点
```
/checkpoint 实现核心业务逻辑
```
上下文管理：监控上下文使用情况
```
/context-budget
```
- 优化对话长度
- 管理存储空间

会话恢复：中断后恢复工作

/resume-session 完成用户模型设计

会话管理：查看和管理所有会话
```
/sessions 用户认证
```

旁路问答：快速查询不中断主任务

/aside React中useEffect的依赖数组如何工作？

最佳实践：

每个功能模块完成后保存会话
复杂任务设置多个检查点
定期清理不必要的会话
使用旁路问答保持主任务专注

7.5 持续学习工作流

工作流程：

模式提取：从成功任务中提取知识
```
/learn API错误处理模式
```
学习评估：评估提取模式的质量
```
/learn-eval 数据库迁移最佳实践
```
技能创建：从git历史创建可重用技能
```
/skill-create 数据库迁移技能
```
本能管理：查看和管理学习成果
```
/instinct-status
```
本能进化：优化知识组织结构
```
/evolve
```
本能提升：将有价值模式提升为全局可用
```
/promote React组件测试模式
```

持续改进循环： /learn → /learn-eval → /skill-create → /evolve → /promote

价值：

将个人经验转化为团队资产
标准化最佳实践
减少重复工作
加速新成员上手

八、命令快速参考表

8.1 按功能分类的命令速查表

分类	命令	核心用途	推荐搭配
核心工作流	`/plan`	先规划需求、风险和实施阶段	`/tdd`、`/prp-plan`
核心工作流	`/tdd`	按 TDD 流程实现功能并补齐测试	`/plan`、`/test-coverage`、`/verify`
核心工作流	`/code-review`	做通用代码质量与安全审查	`/verify`
核心工作流	`/build-fix`	自动诊断并修复构建错误	`/verify`、语言专用构建命令
核心工作流	`/verify`	运行完整验证循环	`/code-review`、`/quality-gate`
核心工作流	`/quality-gate`	按项目标准检查质量门	`/verify`
测试相关	`/e2e`	生成并运行端到端测试	`/tdd`、`/verify`
测试相关	`/test-coverage`	查看覆盖率并找出测试盲区	`/tdd`、`/verify`
测试相关	`/go-test`	Go 语言 TDD 工作流	`/go-review`、`/go-build`
测试相关	`/kotlin-test`	Kotlin 语言 TDD 工作流	`/kotlin-review`、`/kotlin-build`
测试相关	`/rust-test`	Rust 语言 TDD 工作流	`/rust-review`、`/rust-build`
测试相关	`/cpp-test`	C++ 语言 TDD 工作流	`/cpp-review`、`/cpp-build`
代码审查	`/python-review`	Python 代码规范、类型与安全审查	`/verify`
代码审查	`/go-review`	Go 惯用法、并发与错误处理审查	`/go-test`、`/go-build`
代码审查	`/kotlin-review`	Kotlin 空安全、协程与架构审查	`/kotlin-test`、`/kotlin-build`
代码审查	`/rust-review`	Rust 所有权、生命周期与 unsafe 审查	`/rust-test`、`/rust-build`
代码审查	`/cpp-review`	C++ 内存安全与现代惯用法审查	`/cpp-test`、`/cpp-build`
构建修复	`/go-build`	修复 Go 构建与编译错误	`/go-test`、`/go-review`
构建修复	`/kotlin-build`	修复 Kotlin/Gradle 构建错误	`/kotlin-test`、`/kotlin-review`
构建修复	`/rust-build`	修复 Rust/Cargo 构建错误	`/rust-test`、`/rust-review`
构建修复	`/cpp-build`	修复 C++/CMake/Make 构建错误	`/cpp-test`、`/cpp-review`
构建修复	`/gradle-build`	修复 Gradle 项目构建与依赖错误	`/kotlin-build`、`/verify`
会话管理	`/save-session`	保存当前会话进度	`/resume-session`、`/checkpoint`
会话管理	`/resume-session`	恢复已保存会话	`/sessions`
会话管理	`/sessions`	浏览和搜索历史会话	`/resume-session`
会话管理	`/checkpoint`	标记当前里程碑或阶段	`/save-session`
会话管理	`/aside`	临时提问而不打断主任务	任意主工作流命令
会话管理	`/context-budget`	分析上下文窗口使用情况	`/save-session`、`/checkpoint`
学习与改进	`/learn`	从当前会话提取可复用模式	`/learn-eval`、`/evolve`
学习与改进	`/learn-eval`	评估提取知识质量再保存	`/learn`、`/skill-create`
学习与改进	`/evolve`	优化本能和技能结构	`/instinct-status`、`/promote`
学习与改进	`/promote`	将项目级本能提升为全局可用	`/learn-eval`、`/instinct-status`
学习与改进	`/instinct-status`	查看本能库状态和统计	`/evolve`、`/promote`
学习与改进	`/skill-create`	从 git 历史生成可复用技能	`/learn`、`/learn-eval`

8.2 按使用频率排序的命令列表

说明：以下排序基于日常开发中的典型使用频率，可作为“先学什么、常用什么”的优先级参考。

优先级	命令	使用频率	典型场景
1	`/plan`	非常高	开始新功能、复杂重构、需求澄清
2	`/tdd`	非常高	新功能实现、bug 修复、补测试
3	`/verify`	非常高	每轮修改后的完整验证
4	`/code-review`	高	提交前审查、安全和质量检查
5	`/build-fix`	高	构建失败、类型错误、依赖问题
6	`/test-coverage`	高	检查覆盖率是否达标
7	`/quality-gate`	中高	发布前或合并前的质量门检查
8	`/e2e`	中高	关键流程回归、发布前验收
9	`/save-session`	中高	长任务中断前保存上下文
10	`/resume-session`	中高	第二天继续未完成任务
11	`/checkpoint`	中	标记阶段性成果
12	`/context-budget`	中	上下文接近上限时优化会话
13	`/aside`	中	临时追问概念或命令细节
14	`/sessions`	中	查找和管理历史会话
15	`/learn`	中	从已完成任务中提炼经验
16	`/learn-eval`	中	将高价值经验正式沉淀
17	`/skill-create`	中	把重复流程沉淀为技能
18	`/promote`	中低	将项目经验升级为全局实践
19	`/evolve`	中低	整理本能/技能结构
20	`/instinct-status`	中低	查看本能库存和健康度
21	`/python-review`	按需	Python 项目专项审查
22	`/go-review`	按需	Go 项目专项审查
23	`/kotlin-review`	按需	Kotlin 项目专项审查
24	`/rust-review`	按需	Rust 项目专项审查
25	`/cpp-review`	按需	C++ 项目专项审查
26	`/go-test`	按需	Go 项目 TDD
27	`/kotlin-test`	按需	Kotlin 项目 TDD
28	`/rust-test`	按需	Rust 项目 TDD
29	`/cpp-test`	按需	C++ 项目 TDD
30	`/go-build`	按需	Go 项目构建修复
31	`/kotlin-build`	按需	Kotlin 项目构建修复
32	`/rust-build`	按需	Rust 项目构建修复
33	`/cpp-build`	按需	C++ 项目构建修复
34	`/gradle-build`	按需	Gradle 项目构建修复

建议的学习顺序：

先掌握 4 个通用核心命令：/plan、/tdd、/verify、/code-review
再补上 4 个高频辅助命令：/build-fix、/test-coverage、/save-session、/resume-session
最后根据技术栈学习语言专用测试、审查和构建命令

最常用的黄金组合：

新功能开发：/plan → /tdd → /code-review → /verify
Bug 修复：/build-fix → /tdd → /verify
发布前检查：/test-coverage → /e2e → /quality-gate
知识沉淀：/learn → /learn-eval → /skill-create

8.3 命令参数速查

命令	参数格式	参数是否必填	参数说明	示例
`/plan`	`[需求描述]`	否	要规划的功能、任务或改动目标	`/plan 实现订单导出功能`
`/tdd`	`[功能描述]`	否	要按 TDD 实现的功能或 bug 修复	`/tdd 修复登录超时问题`
`/code-review`	`[文件或目录]`（可选）	否	不带参数时通常基于当前改动审查	`/code-review src/auth`
`/build-fix`	无	否	自动检测项目类型并执行构建修复	`/build-fix`
`/verify`	无	否	运行构建、测试、类型、lint 等验证	`/verify`
`/quality-gate`	无	否	根据项目标准做质量门检查	`/quality-gate`
`/e2e`	`[测试描述]`	否	指定要覆盖的用户流程	`/e2e 测试支付流程`
`/test-coverage`	`[目标路径]`	否	限定要统计覆盖率的目录或模块	`/test-coverage src/components`
`/go-test`	`[功能描述]`	否	Go 项目中的 TDD 任务描述	`/go-test 实现重试中间件`
`/kotlin-test`	`[功能描述]`	否	Kotlin 项目中的 TDD 任务描述	`/kotlin-test 实现表单校验器`
`/rust-test`	`[功能描述]`	否	Rust 项目中的 TDD 任务描述	`/rust-test 实现配置解析器`
`/cpp-test`	`[功能描述]`	否	C++ 项目中的 TDD 任务描述	`/cpp-test 实现缓存类`
`/python-review`	`[文件或目录]`	否	指定 Python 审查目标	`/python-review app/api.py`
`/go-review`	`[文件或目录]`	否	指定 Go 审查目标	`/go-review internal/service`
`/kotlin-review`	`[文件或目录]`	否	指定 Kotlin 审查目标	`/kotlin-review app/src/main/kotlin`
`/rust-review`	`[文件或目录]`	否	指定 Rust 审查目标	`/rust-review src/lib.rs`
`/cpp-review`	`[文件或目录]`	否	指定 C++ 审查目标	`/cpp-review include/ src/`
`/go-build`	无	否	修复 Go 构建错误	`/go-build`
`/kotlin-build`	无	否	修复 Kotlin 构建错误	`/kotlin-build`
`/rust-build`	无	否	修复 Rust 构建错误	`/rust-build`
`/cpp-build`	无	否	修复 C++ 构建错误	`/cpp-build`
`/gradle-build`	无	否	修复 Gradle 构建错误	`/gradle-build`
`/save-session`	`[会话名称]`	否	自定义会话保存名称，便于恢复	`/save-session 认证模块开发`
`/resume-session`	`[会话ID或名称]`	否	指定要恢复的会话	`/resume-session 认证模块开发`
`/sessions`	`[搜索词]`	否	过滤会话列表	`/sessions 认证`
`/checkpoint`	`[检查点描述]`	否	标记当前阶段名称或说明	`/checkpoint 完成支付接口`
`/aside`	`[问题]`	是	临时提问的具体内容	`/aside Python里如何做重试？`
`/context-budget`	无	否	查看当前上下文使用情况	`/context-budget`
`/learn`	`[模式名称]`	否	要提取的经验模式名称	`/learn API限流模式`
`/learn-eval`	`[模式名称]`	否	要评估并沉淀的模式名称	`/learn-eval 发布清单流程`
`/evolve`	无	否	分析并优化本能/技能结构	`/evolve`
`/promote`	`[本能名称]`	否	需要提升为全局的本能名称	`/promote React测试模式`
`/instinct-status`	无	否	查看本能库状态	`/instinct-status`
`/skill-create`	`[技能描述]`	否	说明要生成的技能主题	`/skill-create 数据迁移技能`

参数使用建议：

任务型命令尽量补上清晰描述，例如 /plan、/tdd、/e2e、/learn
文件型命令优先传入具体目录或文件，缩小分析范围，例如 /python-review src/api.py
会话型命令建议使用易搜索的中文名称，便于后续 /sessions 和 /resume-session
无参数命令通常依赖当前工作目录与当前对话上下文，因此在执行前最好先明确主任务

附录

命令安装与配置

ECC 的安装通常分为两部分：插件安装，以及规则（rules）安装。只安装插件可以使用一部分能力，但如果希望获得更完整、更稳定的行为约束，建议同时安装规则。

推荐安装路径：

先添加 ECC 市场并安装插件
再克隆仓库并执行安装脚本安装规则
最后在 Claude Code 中验证命令是否可见

插件安装示例：

/plugin marketplace add affaan-m/everything-claude-code

/plugin install ecc@ecc

规则安装示例（macOS/Linux）：

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

cd everything-claude-code

npm install

./install.sh --profile full

规则安装示例（Windows PowerShell）：

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

cd everything-claude-code

npm install

.\install.ps1 --profile full

按语言安装示例：

./install.sh typescript

./install.sh python

./install.sh golang

./install.sh swift

关键配置点：

Node.js 版本要求为 >=18
支持的包管理器包括 npm、pnpm、yarn、bun
可以通过环境变量 CLAUDE_PACKAGE_MANAGER 指定首选包管理器
multi-* 命令还需要额外安装 ccg-workflow 运行时

手动安装规则时的注意事项：

始终复制整个规则目录，例如 rules/common、rules/typescript
不要把多个规则目录拍平复制到同一层，否则会覆盖同名文件
语言规则依赖 common 规则中的相对路径引用，因此 common 层通常需要一起安装

安装后的简单验证：

在 Claude Code 会话中输入 /
确认能看到 /plan、/tdd、/verify 等命令
运行一个简单命令，例如 /plan 添加一个登录表单
如需检查命令总览，可参考仓库中的 COMMANDS-QUICK-REF.md

常见问题解答

Q1：为什么安装后看不到某些命令？ A：最常见原因是只安装了插件但没有安装规则，或者当前宿主工具没有成功加载插件目录。先确认插件已安装，再确认规则已按说明安装完成。

Q2：为什么 multi-* 命令不能使用？ A：这些命令不只依赖基础插件，还依赖额外的 ccg-workflow 运行时。如果没有执行对应初始化安装，这些命令通常不会正常工作。

Q3：为什么手动复制规则后行为异常？ A：很可能是把 rules/common 和语言规则目录内的文件“拍平”复制了。ECC 的规则目录依赖分层结构和相对路径引用，必须复制整个目录，而不是只复制其中的单个文件。

Q4：命令前面为什么有时要写成 /ecc:plan，有时是 /plan？ A：如果你是通过插件市场安装，常见形式是命名空间写法，例如 /ecc:plan；如果是手动安装旧式命令兼容层，通常可以直接使用 /plan。

Q5：如何选择先学哪些命令？ A：建议先掌握 /plan、/tdd、/code-review、/verify 这 4 个核心命令，再根据语言和项目类型学习语言专用命令。

Q6：/verify 和 /quality-gate 有什么区别？ A：/verify 偏向完整验证循环，覆盖构建、类型、测试、安全等多个维度；/quality-gate 更偏向按路径或项目范围执行质量检查，并支持 --fix、--strict 这类参数。

Q7：如何确认当前 ECC 版本？ A：可以查看仓库根目录的 VERSION 文件，或查看 package.json 中的 version 字段。本文档基于的版本是 1.10.0。

Q8：如果命令行为和文档不完全一致怎么办？ A：优先以当前仓库中的命令实现、技能文件和 README 为准。ECC 迭代较快，文档可能滞后于个别命令实现细节。

所有评论(0)

查看更多评论

XiaoBaibai0o

@XiaoBaibai0o

已为社区贡献1条内容

Everything Claude Code (ECC) 常用命令详解

XiaoBaibai0o

概述

命令分类说明

如何查找和使用命令

一、核心工作流命令（6个）

1.1 /plan - 实施计划

1.2 /tdd - 测试驱动开发

1.3 /code-review - 代码审查

1.4 /build-fix - 构建修复

1.5 /verify - 完整验证循环

1.6 /quality-gate - 质量门检查

二、测试相关命令（6个）

2.1 /e2e - 端到端测试

2.2 /test-coverage - 测试覆盖率

2.3 /go-test - Go语言TDD

2.4 /kotlin-test - Kotlin语言TDD

2.5 /rust-test - Rust语言TDD

2.6 /cpp-test - C++语言TDD

三、代码审查命令（5个）

3.1 /python-review - Python代码审查

3.2 /go-review - Go代码审查

3.3 /kotlin-review - Kotlin代码审查

3.4 /rust-review - Rust代码审查

3.5 /cpp-review - C++代码审查

四、构建修复命令（5个）

4.1 /go-build - Go构建修复

4.2 /kotlin-build - Kotlin构建修复

4.3 /rust-build - Rust构建修复

4.4 /cpp-build - C++构建修复

4.5 /gradle-build - Gradle构建修复

五、会话管理命令（6个）

5.1 /save-session - 保存会话

5.2 /resume-session - 恢复会话

5.3 /sessions - 会话管理

5.4 /checkpoint - 检查点标记

5.5 /aside - 旁路问答

5.6 /context-budget - 上下文预算分析

六、学习与改进命令（6个）

6.1 /learn - 模式提取

6.2 /learn-eval - 学习评估

6.3 /evolve - 本能进化

6.4 /promote - 本能提升

6.5 /instinct-status - 本能状态

6.6 /skill-create - 技能创建

七、使用场景指南

7.1 开始新功能开发

7.2 修复Bug流程

7.3 代码审查流程

7.4 会话管理最佳实践

7.5 持续学习工作流

八、命令快速参考表

8.1 按功能分类的命令速查表

8.2 按使用频率排序的命令列表

8.3 命令参数速查

附录

命令安装与配置

常见问题解答

相关资源链接

所有评论(0)

温馨提示：您尚未绑定手机号

XiaoBaibai0o