ECC 全部 84 个命令速查手册:从元管理到语言特化的全栈工具箱

2980 字
15 分钟
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-guideECC 入门使用指南新人第一天带看

关键洞察/ecc:aside 是被低估的”中断救星”——写代码时突然要查文档、查 Stack Overflow、查某个不熟的概念,用它不会污染主上下文。我自己几乎每天用。

四、开发工作流命令(26 个):从想法到 PR 的完整流水线#

这是 ECC 的核心价值区——80% 的开发任务都在这一组命令里完成。

4.1 规划与 PRD(5 个)#

命令用途何时用
/ecc:plan制定实施计划(planner agent)接到新需求,先想清楚再写
/ecc:plan-prd生成产品需求文档(PRD)给非技术同事/老板看
/ecc:prp-planPRP 流程的计划阶段PRP = Plan → Requirements → Production,比纯 PR 更严谨
/ecc:prp-prdPRP 流程的 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-commitPRP 流程的提交阶段
/ecc:prp-implementPRP 流程的实现阶段
/ecc:prp-prPRP 流程的 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-helphookify 帮助文档查 hook 语法
/ecc:hookify-list列出当前 hookify 规则看现在有什么自动化
/ecc:jiraJira 集成(从任务创建到状态同步)公司用 Jira 管任务
/ecc:gan-buildGAN Harness —— 构建阶段(实现)GAN 是一种多代理生成对抗网络开发方法
/ecc:gan-designGAN Harness —— 设计阶段(规范)同上
/ecc:cost-reportToken / 成本报告月底算账
/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:pm2PM2 进程管理

/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 全流程
质量/审查8PR 合并前门禁
集成/外部10连接工具链
语言特化21各技术栈的构建/审查/测试
学习/适应4让 ECC 自我进化
循环/自动化4长任务守护

核心建议

  1. 新手:先熟用 /ecc:aside/ecc:code-review/ecc:plan 这 3 个
  2. 中级:把 PRP 流水线(5 个)+ 质量门禁(4 个)打通
  3. 高级:按项目需要选 multi-* 和 orch-*,并配合 cost-report 控制成本

延伸阅读Everything Claude Code (ECC) 入门:把 AI 编程助手升级成专业开发引擎 —— 如果你还没装 ECC,先看这篇入门。

命令清单的更新比文档快,建议收藏本文,每季度回来对照 /ecc:skill-health 看有没有新增命令。

文章分享

如果这篇文章对你有帮助,欢迎分享给更多人!

ECC 全部 84 个命令速查手册:从元管理到语言特化的全栈工具箱
https://boke.hackerdream.xyz/posts/ecc-commands-full-reference/
作者
晴天
发布于
2026-06-17
许可协议
CC BY-NC-SA 4.0
Profile Image of the Author
晴天
Hello, I'm 晴天.
公告
欢迎来到我的博客!这是一则示例公告。
音乐
封面

音乐

暂未播放

0:00 0:00
暂无歌词
分类
标签
站点统计
文章
155
分类
24
标签
387
总字数
345,424
运行时长
0
最后活动
0 天前

目录