ECC 全部 84 个命令速查手册:从元管理到语言特化的全栈工具箱
一、为什么你需要这份命令速查手册?
如果你已经用上了 Everything Claude Code(ECC),一定遇到过这个痛点:装了 60+ 个命令之后,根本记不住每个命令是干嘛的。每次想用都得去翻文档,要么翻 GitHub README,要么翻本地 commands/ 目录——费时费力。
更尴尬的是,很多命令之间是高度协同的:/ecc:plan 之后应该接 /ecc:feature-dev、/ecc:prp-prd 之后必须接 /ecc:prp-implement 再到 /ecc:prp-pr、而 /ecc:code-review、/ecc:quality-gate、/ecc:security-scan 构成一套完整的代码质量门禁。
但官方文档把命令分散在 7 个大类里,没有一张完整的”该用哪个”的速查表。今天这篇文章,我们就来一次性把这 84 个命令全部拆解清楚——按官方分类逐一讲解,附实际使用场景速查,让你以后再也不用翻文档。
阅读建议:第一次通读建立全局认知;之后遇到具体任务时直接跳到”速查表”那部分。
二、命令生态全景
先把整个命令空间画出来,建立心智模型:
84 commands├── 11 元/管理(导航、会话、技能管理)├── 26 开发工作流(规划、实现、PR、编排)├── 8 质量/审查(code-review、security-scan、refactor-clean、checkpoint 等)├── 10 集成(hookify、jira、gan、cost-report 等)├── 21 语言特化(C++/Go/Kotlin/Rust/React/Flutter/Python/FastAPI/Gradle)├── 4 学习/适应(learn、evolve、model-route)└── 4 循环/自动化(loop-start/status、santa-loop、pm2)核心规律:前 4 类是”通用工程能力”,第 5 类是”垂直技术栈”,第 6-7 类是”元能力”——让 ECC 自己变强、自动化跑任务。
三、元/管理命令(11 个):会话导航 + 技能管理
这一组命令解决的是**“在 ECC 里穿梭”**——你不用退出当前上下文就能查东西、保存状态、管理技能。
| 命令 | 用途 | 实际场景 |
|---|---|---|
/ecc:aside | 旁支问题,不打断主会话上下文 | 写到一半突然想确认一个 API 用法,先 /ecc:aside 查完回来 |
/ecc:resume-session | 恢复之前保存的会话 | 昨天写到一半被打断,今天继续 |
/ecc:save-session | 保存当前会话状态 | 关键节点先存盘,下次秒恢复 |
/ecc:sessions | 列出所有已保存会话 | 找回 3 天前那个调试会话 |
/ecc:instinct-export | 导出已学习的经验规则 | 跨机器同步你积累的”本能” |
/ecc:instinct-import | 导入经验规则 | 拿到同事的规则文件 |
/ecc:instinct-status | 查看已学习的本能列表 | 看 ECC 已经”学会”了哪些 |
/ecc:skill-create | 创建新技能(模板/向导) | 给项目定制专属 skill |
/ecc:skill-health | 技能健康仪表板(成功率、失败模式、版本历史) | 每月看一次:哪些 skill 在拖后腿 |
/ecc:auto-update | 拉取 ECC 最新仓库变更并重装 | ECC 升级后自动应用新命令 |
/ecc:ecc-guide | ECC 入门使用指南 | 新人第一天带看 |
关键洞察:/ecc:aside 是被低估的”中断救星”——写代码时突然要查文档、查 Stack Overflow、查某个不熟的概念,用它不会污染主上下文。我自己几乎每天用。
四、开发工作流命令(26 个):从想法到 PR 的完整流水线
这是 ECC 的核心价值区——80% 的开发任务都在这一组命令里完成。
4.1 规划与 PRD(5 个)
| 命令 | 用途 | 何时用 |
|---|---|---|
/ecc:plan | 制定实施计划(planner agent) | 接到新需求,先想清楚再写 |
/ecc:plan-prd | 生成产品需求文档(PRD) | 给非技术同事/老板看 |
/ecc:prp-plan | PRP 流程的计划阶段 | PRP = Plan → Requirements → Production,比纯 PR 更严谨 |
/ecc:prp-prd | PRP 流程的 PRD 阶段 | 同上 |
/ecc:feature-dev | 端到端功能开发流水线 | 一个人想做完”规划→实现→测试”全流程 |
PRP vs 普通 PRD 的区别:PRP 在 PRD 基础上加了实施约束——库选型、性能预算、错误处理边界条件——更适合 AI 直接执行。
4.2 实现与协调(5 个)
| 命令 | 用途 |
|---|---|
/ecc:multi-plan | 启动多代理并行规划 |
/ecc:multi-execute | 多代理并行执行任务 |
/ecc:multi-backend | 多代理并行处理后端 |
/ecc:multi-frontend | 多代理并行处理前端 |
/ecc:multi-workflow | 多代理工作流编排 |
/ecc:multi-* 是 ECC 的杀手锏——一次让 3-5 个 sub-agent 并行干活。比如前端同时调 5 个组件、后端同时写 3 个 API。前提是任务可以并行分解且互不依赖。
4.3 编排(Orchestrate,5 个)
| 命令 | 用途 |
|---|---|
/ecc:orch-build-mvp | 编排 MVP 构建(PRD → 最小可用产品) |
/ecc:orch-add-feature | 编排功能添加 |
/ecc:orch-change-feature | 编排功能修改 |
/ecc:orch-fix-defect | 编排缺陷修复 |
/ecc:orch-refine-code | 编排代码精炼 |
orch-* 是比 multi-* 更”高级”的编排——它会自己规划任务依赖、决定何时并行、何时串行。代价是更慢、更费 Token——适合大重构,不适合小修小补。
4.4 PRP 流水线(3 个)
| 命令 | 用途 |
|---|---|
/ecc:prp-commit | PRP 流程的提交阶段 |
/ecc:prp-implement | PRP 流程的实现阶段 |
/ecc:prp-pr | PRP 流程的 PR 阶段 |
完整 PRP 链路:/ecc:prp-plan → /ecc:prp-prd → /ecc:prp-implement → /ecc:prp-pr → /ecc:prp-commit。
4.5 Git 与 PR(6 个)
| 命令 | 用途 |
|---|---|
/ecc:pr | 创建 Pull Request |
/ecc:review-pr | 审查 PR(读取 PR 内容并执行审查) |
/ecc:promote | 晋升代码(staging → production) |
/ecc:prune | 删除无用代码/文件 |
/ecc:projects | 项目管理视图 |
/ecc:project-init | 初始化新项目 |
4.6 修复(1 个)
| 命令 | 用途 |
|---|---|
/ecc:build-fix | 自动检测构建系统并增量修复编译/类型错误 |
五、质量/审查命令(8 个):PR 合并前的最后一道门
| 命令 | 用途 | 适用阶段 |
|---|---|---|
/ecc:code-review | 代码审查(本地未提交改动或 GitHub PR) | 提交 PR 前 / 审查 PR 时 |
/ecc:quality-gate | 质量门禁检查(在 PR 合并前) | CI/CD 流水线 |
/ecc:security-scan | 安全扫描(secrets、注入、敏感数据) | 发布前 |
/ecc:refactor-clean | 死代码清理 + knip/depcheck/ts-prune | 代码腐烂预警 |
/ecc:test-coverage | 测试覆盖率分析 | 写完功能后 |
/ecc:harness-audit | 代理配置审计 | 调试 ECC 不听话时 |
/ecc:update-codemaps | 更新代码地图(架构图) | 每次大改之后 |
/ecc:update-docs | 更新文档 | 同上 |
/ecc:checkpoint | 创建/验证/列出工作流检查点 | 多步骤任务的中途存档 |
实战组合拳:
写完代码 ↓ /ecc:code-review(先自我审查) ↓ /ecc:test-coverage(确认覆盖率) ↓ /ecc:security-scan(最后安全扫描) ↓ /ecc:quality-gate(一键合并前门禁) ↓ git push → /ecc:pr(创建 PR)六、集成/外部工具命令(10 个):连接你的工具链
| 命令 | 用途 | 适用场景 |
|---|---|---|
/ecc:hookify | 把常见行为转化为 hooks(自动化) | 把”提交前跑测试”做成 hook |
/ecc:hookify-configure | 配置 hookify 规则 | 同上 |
/ecc:hookify-help | hookify 帮助文档 | 查 hook 语法 |
/ecc:hookify-list | 列出当前 hookify 规则 | 看现在有什么自动化 |
/ecc:jira | Jira 集成(从任务创建到状态同步) | 公司用 Jira 管任务 |
/ecc:gan-build | GAN Harness —— 构建阶段(实现) | GAN 是一种多代理生成对抗网络开发方法 |
/ecc:gan-design | GAN Harness —— 设计阶段(规范) | 同上 |
/ecc:cost-report | Token / 成本报告 | 月底算账 |
/ecc:marketing-campaign | 营销活动规划 | 产品/运营用 |
/ecc:setup-pm | 设置 PM(项目管理)工具 | 配 Jira/Linear/Asana |
/ecc:cost-report 是被低估的省钱神器——每次看 ECC 烧了多少 Token,能让你立刻关掉没必要的命令。
七、语言特化命令(21 个):每条技术栈三条
ECC 对每个支持的语言都提供 3 个命令:构建修复、审查、测试。
| 技术栈 | 构建修复 | 审查 | 测试 |
|---|---|---|---|
| C/C++ | /ecc:cpp-build | /ecc:cpp-review | /ecc:cpp-test |
| Go | /ecc:go-build | /ecc:go-review | /ecc:go-test |
| Kotlin | /ecc:kotlin-build | /ecc:kotlin-review | /ecc:kotlin-test |
| Rust | /ecc:rust-build | /ecc:rust-review | /ecc:rust-test |
| React/TypeScript | /ecc:react-build | /ecc:react-review | /ecc:react-test |
| Flutter/Dart | /ecc:flutter-build | /ecc:flutter-review | /ecc:flutter-test |
| Python | — | /ecc:python-review | — |
| FastAPI | — | /ecc:fastapi-review | — |
| Gradle | /ecc:gradle-build | — | — |
实战举例:写完一段 Rust 代码遇到编译报错——直接 /ecc:rust-build,ECC 会自动分析错误、给出最小修复 patch、跑测试验证。
八、学习/适应命令(4 个):让 ECC 自我进化
| 命令 | 用途 |
|---|---|
/ecc:learn | 从当前会话中学习经验规则 |
/ecc:learn-eval | 评估学习到的规则的有效性 |
/ecc:evolve | 让 ECC 自我进化(基于历史数据改进技能) |
/ecc:model-route | 模型路由策略(根据任务复杂度自动选 Haiku/Sonnet/Opus) |
核心洞察:ECC 会主动学习你的反馈——你每次纠错、给规则、修正输出,/ecc:learn 会把这些提炼成”本能”,下次自动应用。配合 /ecc:evolve 可以让整个 skill 库持续优化。
/ecc:model-route 是省钱利器——简单任务用 Haiku、复杂任务用 Opus,自动选择最优性价比。
九、循环/自动化命令(4 个):长任务守护
| 命令 | 用途 |
|---|---|
/ecc:loop-start | 启动自主代理循环(开发自动化) |
/ecc:loop-status | 查看运行中的循环状态 |
/ecc:santa-loop | 圣诞循环模式(批量任务派发) |
/ecc:pm2 | PM2 进程管理 |
/ecc:loop-start 适合啥场景:凌晨 3 点让 ECC 自己跑 100 个 test cases、跑完报告失败列表。
十、实际使用场景速查表
按”你想做什么”反查”该用哪个命令”:
| 你想做什么 | 推荐命令 |
|---|---|
| 写一个新功能 | /ecc:plan → /ecc:feature-dev |
| 修复编译错误 | /ecc:build-fix(自动检测语言) |
| 代码审查 | /ecc:code-review |
| PR 创建/审查 | /ecc:pr / /ecc:review-pr |
| 安全审计 | /ecc:security-scan |
| 清理死代码 | /ecc:refactor-clean |
| 多代理并行任务 | /ecc:multi-* |
| PRP 完整流程 | /ecc:prp-plan → /ecc:prp-prd → /ecc:prp-implement → /ecc:prp-pr → /ecc:prp-commit |
| 找/查 ECC 帮助 | /ecc:ecc-guide |
| 技能健康检查 | /ecc:skill-health |
| 持续学习 | /ecc:learn / /ecc:evolve |
| 临时问题旁查 | /ecc:aside |
| 保存/恢复会话 | /ecc:save-session / /ecc:resume-session |
| 创建新技能 | /ecc:skill-create |
| 月底看 Token 烧了多少钱 | /ecc:cost-report |
十一、维护建议
11.1 命令源文件位置
所有命令的源文件位于本地:
C:\Users\Administrator\.claude\plugins\marketplaces\ecc\commands\每个 .md 文件对应一个 slash 命令,可通过直接查看源文件获取最新描述。
11.2 规则蒸馏
ECC 会从会话中自动提炼跨技能的通用原则——每月运行一次 /ecc:rules-distill,可以发现新出现的最佳实践,并把它注入到对应命令的规则章节。
通过
/ecc:rules-distill在本会话中新增的规则,会自动影响对应命令的行为。例如/ecc:code-review增加 “Verification Phases” 章节后,所有未来代码审查都会自动应用该原则。
11.3 健康监控
定期跑 /ecc:skill-health,它会告诉你:
- 成功率:哪个 skill 经常失败
- 失败模式:是 prompt 问题、模型问题、还是网络问题
- 版本历史:什么时候升级过、回滚过
当某 skill 成功率长期 < 80%,就该考虑禁用它或重新训练。
十二、常见误区
误区 1:装了就用,越多越好
错。ECC 有 84 个命令,但你项目用得到的也就 10-15 个。装太多反而增加 prompt 长度、拖慢响应、降低准确率。
正确做法:根据项目技术栈选 10-15 个核心命令,其他需要时再开。
误区 2:所有任务都要走完整流水线
错。/ecc:prp-plan → /ecc:prp-implement → /ecc:prp-pr → /ecc:prp-commit 适合新功能开发,但改一个 typo 直接手动改 + /ecc:code-review 就够了。
正确做法:按”任务复杂度”选择”命令复杂度”。
误区 3:multi-* 越多越快
错。/ecc:multi-execute 一次开 10 个 sub-agent 不会让速度变成 10 倍——反而会互相抢资源、互相冲突。
正确做法:单 agent 写不完才上 multi-*,且并行数控制在 3-5 个。
误区 4:cost-report 不用看
错。不看 cost-report 的人,月底会发现 Token 费是平时的 5 倍——都是 /ecc:multi-* 和 /ecc:loop-start 偷跑的。
正确做法:每周看一次 cost-report,超过预算的 skill 立即降级或关掉。
十三、总结
ECC 的 84 个命令看似庞大,但分 7 大类后每类都有清晰边界:
| 类别 | 命令数 | 核心用途 |
|---|---|---|
| 元/管理 | 11 | 会话导航、技能维护 |
| 开发工作流 | 26 | 规划、实现、PR 全流程 |
| 质量/审查 | 8 | PR 合并前门禁 |
| 集成/外部 | 10 | 连接工具链 |
| 语言特化 | 21 | 各技术栈的构建/审查/测试 |
| 学习/适应 | 4 | 让 ECC 自我进化 |
| 循环/自动化 | 4 | 长任务守护 |
核心建议:
- 新手:先熟用
/ecc:aside、/ecc:code-review、/ecc:plan这 3 个 - 中级:把 PRP 流水线(5 个)+ 质量门禁(4 个)打通
- 高级:按项目需要选 multi-* 和 orch-*,并配合 cost-report 控制成本
延伸阅读:Everything Claude Code (ECC) 入门:把 AI 编程助手升级成专业开发引擎 —— 如果你还没装 ECC,先看这篇入门。
命令清单的更新比文档快,建议收藏本文,每季度回来对照 /ecc:skill-health 看有没有新增命令。
文章分享
如果这篇文章对你有帮助,欢迎分享给更多人!