# 这个工具到底藏了多少命令？ 你在 `/help` 里看到的二三十个命令只是冰山一角。系统性扫描 `commands/` 目录后，会发现 Claude Code 竟然有 101 个独立命令入口——从用户交互到远程集成、从内部调试到实验性功能，覆盖了开发者工作流的几乎每个角落。本章对这 101 个命令做**代表性分类**（四类合计约 83 个典型入口举例，其余约 18 个以 ant-only 内部调试命令为主，本章不逐一枚举），揭示隐藏命令背后的产品战略。 > **📏 关于"101 个命令"的计数规则** > > 本章和全书统一使用 **101** 作为命令总数的权威口径。计算方式： > > - **86** = `src/commands/` 下的子目录数（每个子目录对应一个命令实现包） > - **15** = `src/commands/` 下的根命令文件数（含 12 个 `.ts` 文件 + 3 个 `.tsx` 文件：statusline / install / ultraplan） > - **101** = 86 + 15，与 `ls src/commands/` 看到的一级条目总数一致 > > 核验建议： > - 在 macOS/Linux bash 中验证，直接写 `ls src/commands/ | wc -l`（正文 markdown 里的 `\|` 只是为了防止表格渲染冲突做的转义，复制到终端时要去掉反斜杠） > - 用 `find src/commands/ -maxdepth 1 -mindepth 1 -type d | wc -l` 可数出 86 个子目录，用 `find src/commands/ -maxdepth 1 -type f | wc -l` 可数出 15 个根文件；如果不带 `-maxdepth/-type` 约束，`find` 会递归深入子目录、计数远大于 101，那不是本书所指的"一级入口数" > > 早期统计曾给出 98 这个数字，是因为漏数了 3 个 `.tsx` 后缀的命令文件。本章基于精确核验后的 101 进行分类。 > 💡 **通俗理解**：就像瑞士军刀——看似一个工具，展开后有几十种功能。 > 🌍 **行业背景**：CLI 工具的命令丰富度是衡量其生态成熟度的指标之一，但 AI 编程工具之间差异悬殊。**Aider**、**GitHub Copilot CLI**、**Codex（OpenAI）**、**OpenCode**、**Cursor/Windsurf** 的命令数量与设计风格差异悬殊，有的聚焦少量高频动作，有的通过 IDE 菜单而非斜杠命令暴露功能。与它们作横向比较时请把"命令数"当作一个粗粒度的形状维度而非优劣评判——本段落里提到的其它工具命令数量、版本号等只做方向性参考，未在本章逐一穷举核验来源；严格引用请以各自官方文档为准。 Claude Code 的 101 个命令入口在 AI CLI 工具中确实罕见，但需要说明：其中相当一部分是内部调试命令（ant-only）和实验性功能，用户日常接触的仍是 30-40 个核心命令（这一"30-40"是基于 `/help` 展示范围与常用命令清单的粗略估计，不是精确计量）。命令数量本身不代表优势——诸如 Git 有 150 多个子命令但大多数开发者日常只常用十几个的说法广为流传，关键在于核心命令的设计质量和可发现性。 --- ## 问题 你打开 Claude Code，输入 `/help`，看到了大概二三十个斜杠命令。你觉得"也就这些了"。但如果我告诉你，`commands/` 目录下有 **101 个命令入口**呢？那些你看不到的命令是什么？为什么要藏起来？ --- > **[图表预留 2.20-A]**：分类图 — 101 个命令的四象限分类（用户可见 × 对外/对内 → 用户交互 / 远程集成 / 内部调试 / 实验性功能） ## 你可能以为…… "一个 CLI 工具能有多少命令？二三十个顶天了吧。"你可能这么想。毕竟连 Git 也就几十个常用命令。 --- ## 实际上是这样的 系统性扫描 `commands/` 目录后，我数到了 **101 个独立命令入口**——86 个是目录结构（每个目录一个命令），15 个是单文件命令。它们可以分为四大类，大部分你永远不会在 `/help` 输出中看到。 ### 小节 1：你已经知道的——用户交互命令（约 45 条一级入口，以下列出代表性命令约 33 个，非穷举；`/advisor` 只在本节出现一次，不在后续小节重复计数） 这些是 `/help` 会列出的"正常"命令。但即使在这个类别里，也有不少冷门的（以下按类别列举代表性样本，不含全部 ~45 条）： **对话管理**： - `/branch` — 分支当前对话（像 git 一样） - `/rewind` — 回滚到之前某个状态 - `/btw` — 发起侧问（不污染主上下文） - `/compact` — 手动触发上下文压缩 - `/resume` — 恢复之前的会话 - `/export` — 导出完整对话 **模型与思考控制**： - `/model` — 切换模型 - `/effort` — 调整思考深度（low/medium/high/max） - `/fast` — 快速模式（同一模型，更快输出；fast vs 标准的价格倍率来自 `modelCost.ts:54-69` 两套单价直接相除得出约 6 倍，非任意口径） - `/advisor` — 配置审查模型（注：`/advisor` 在本章只在这里归类一次，不再在"小节 4 实验性命令"中重复列出） **用户界面**： - `/color` — 颜色主题 - `/theme` — 主题切换 - `/vim` — Vim 模式（在终端 AI 里用 Vim 键绑定） - `/keybindings` — 自定义键绑定 - `/output-style` — **已废弃**，提示用 `/config` 代替 **信息查看**： - `/cost` — 当前对话花了多少钱 - `/usage` — 使用量统计 - `/stats` — 会话统计 - `/files` — 已访问的文件列表 - `/diff` — 查看 Claude 做的文件修改 - `/status` — 会话状态 **系统管理**： - `/config` — 设置（替代了原来的多个独立设置命令） - `/permissions` — 权限模式切换 - `/hooks` — Hooks 管理 - `/memory` — 记忆系统管理 - `/mcp` — MCP 服务器管理 - `/plugin` — 插件管理 - `/skills` — Skills 管理 - `/login` / `/logout` — 认证 - `/upgrade` — 升级 Claude Code - `/doctor` — 诊断工具 - `/privacy-settings` — 隐私设置 ### 小节 2：看不见的冰山——远程集成命令（~11 个） 这些命令让 Claude Code 不只是一个终端工具，而是一个**多端协同平台**： ``` /bridge — 从浏览器远程控制终端 Claude（Bridge 系统核心） /chrome — Chrome 浏览器扩展集成 /desktop — Desktop 桌面应用集成 /ide — VS Code / JetBrains 等 IDE 集成 /mobile — 移动端集成 /remote-env — 远程环境管理 /remote-setup — 远程设置 /teleport — 会话"传送"（跨设备转移？） bridge-kick — 踢掉 Bridge 会话 install-github-app — 安装 GitHub App install-slack-app — 安装 Slack App ``` `/teleport` 是最神秘的——**"传送"这一解读完全来自命令名的字面暗示**，本章未在源码中读到能明确证明它做跨设备会话迁移的实现路径。如果后续核验下来确认它不是跨设备、只是跨目录/跨 session 的"上下文携带"，那"传送"这一类比就会失准。这里把推测标记清楚，读者不要直接采信。 集成的广度值得关注：Chrome、Desktop、Mobile、IDE、GitHub、Slack——几乎覆盖了开发者日常接触的所有界面。这个方向与 GitHub Copilot 的多端策略（VS Code、JetBrains、CLI、Mobile）类似，但 Claude Code 从终端出发向外扩展的路径与 Copilot 从 IDE 出发的路径形成了有趣的对比。 ### 小节 3：内部人专属——ant-only 调试命令（~10 个） > 📚 **课程关联**：内部调试命令的设计可类比**软件工程**课程中"可观测性"（Observability）三支柱的实践——`/heapdump` 近 Metrics/Profiling、`/ant-trace` 近 Tracing、`/ctx_viz` 近 Logging/Visualization。工业界常有"运维/可观测性代码占比远高于核心业务"这一经验谈，但"30-50%"这一数字因项目差别很大，本章不作为确定结论，只作方向感参考。 这些命令只在 Anthropic 内部可用（`process.env.USER_TYPE === 'ant'`）： ``` /ant-trace — 内部追踪系统 /break-cache — 故意破坏 prompt cache（测试缓存失效场景） /backfill-sessions — 回填会话数据 /debug-tool-call — 调试工具调用 /heapdump — 堆内存快照（排查内存泄漏） /mock-limits — 模拟限流（测试 rate limit 处理逻辑） /reset-limits — 重置限流计数 /ctx_viz — 上下文可视化 /perf-issue — 性能问题报告 /env — 查看环境变量 ``` `/break-cache` 特别有趣——它故意让 prompt cache 失效。为什么需要这个？因为 prompt cache 是 Claude Code 的核心性能优化（在本书其它章节会讲到的"投机执行"、"CacheSafeParams"机制都依赖它——本章不再展开这两个术语，详见对应子系统章节），测试"缓存失效时系统是否还能正常工作"是必要的边界测试。 `/heapdump` 说明 Claude Code 的 Node.js 进程确实会遇到内存问题——在本书 Swarm 章节里提到的极端场景（292 个 Teammate、峰值 RSS 接近 37GB）正好说明为什么需要内存快照工具。这里引用的具体数字来自 Swarm 章节对源码注释的直接援引，完整上下文请参见 Q14；本章不在此处重复注释原文。 `/ctx_viz`（上下文可视化）可能是最有教育意义的——它让开发者**看到**上下文窗口里到底装了什么。"学术价值"这一断言偏强，本章调整为"教育意义"更稳妥。如果这个功能面向外部用户开放，它可能是帮助人们理解"LLM 在每次请求里实际看到了什么"的好工具。 ### 小节 4：未来的伏笔——实验性命令（约 14 个，已从此列中移出 `/advisor` 归入小节 1） 这些命令暗示了 Claude Code 的演进方向： ``` /brief — 精简输出模式 /plan — 进入/退出计划模式 ultraplan — "超级计划"模式（名字暗示比 /plan 更深入） /thinkback — 回放 AI 的思考过程 /thinkback-play — 播放思考过程（带动画？） /insights — 洞察/分析 /bughunter — Bug 猎手（自动寻找 bug？） /stickers — 贴纸（？？？） /good-claude — 给 Claude 正面反馈 /tag — 标签管理 /passes — Passes/推荐系统 /onboarding — 新用户引导 /issue — Issue 管理 /init — 初始化项目 CLAUDE.md ``` `/thinkback` 和 `/thinkback-play` **从命名推测**可能是一个"思考回放"系统。需要澄清：本章对 `/thinkback` 的分类依据并非其内部实现，而是文件名和零散注释——它也有可能是"基于历史 JSONL 做对话统计回顾"的命令（与前文 Q11 提到的"年度回顾"思路接近）而非逐帧 thinking token 流式重放。请把这里的描述当作方向性猜测，留待后续考证。 `/stickers` 的用途本章未能从源码确证——命名暗示它与"贴纸/表情反馈"相关，**也可能**与 Buddy 系统配合（前面章节介绍的 ASCII 宠物有 reaction 气泡），也可能是别的产品化想法，这里不再重复两个"也许"的猜测堆叠；能确定的只有：这是一个入口命令，细节需要进一步核验。 `/good-claude` 暗示了一个正面反馈机制——不只是"这个回答不好"（thumbs down），也有"这个回答很好"（thumbs up）。这可能用于 RLHF 数据收集。 `ultraplan` 的文件类型是 `.tsx`（而非目录），说明它使用了 React 组件入口（Claude Code 的 UI 层走 Ink/React）。"复杂的 UI 意味着可以交互协商"是基于"tsx = 组件 = 可交互"的合理推测，但 `.tsx` 本身只说明"使用了 React 语法/组件结构"，并不自动等同于"有复杂交互式 UI"；以实际组件实现为准，本章不在此处做过度推论。 ### 小节 5：一个优雅的迁移模式——createMovedToPluginCommand > 📚 **课程关联**：这种"占位符重定向"模式是**软件工程**课程中"API 废弃策略"（Deprecation Strategy）的教科书实现。HTTP 协议中的 301 永久重定向、Python 的 `DeprecationWarning`、Java 的 `@Deprecated` 注解都遵循同一原则：不直接删除旧接口，而是保留入口并引导到新位置。这种做法在大规模系统的版本迁移中至关重要。 在命令清单中有一个特殊的工厂函数： ``` createMovedToPluginCommand — 创建"已移至插件"的占位命令 // 源码位置：src/commands/createMovedToPluginCommand.ts:22 // 使用示例：src/commands/security-review.ts:198、src/commands/pr_comments/index.ts:3 ``` 当一个功能从内置命令迁移到插件时，原来的命令不是直接删除，而是变成一个占位符——告诉用户"这个功能已经移到了对应的插件"。这是一个优雅的向后兼容策略：老用户的肌肉记忆不会失效，他们输入熟悉的命令时会被引导到新的位置。 --- ## 这背后的哲学 101 个命令揭示了 Claude Code 的三个战略意图： 1. **深度 Dogfooding**。约 10 个 ant-only 命令意味着 Anthropic 的工程师每天用自己的产品——不是"用基础版"，而是用"有额外调试能力的增强版"。`/break-cache`、`/heapdump`、`/mock-limits` 这些命令只有在团队深度使用产品时才需要。 2. **全端覆盖**。Chrome、Desktop、Mobile、IDE、GitHub、Slack——Claude Code 的目标不是"一个终端工具"，而是"一个无处不在的开发伙伴"。Bridge 系统是实现这个目标的技术基础。 3. **渐进式功能暴露**。用户刚开始只看到 `/help` 里的二三十个命令。随着他们深入使用，逐渐发现 `/effort`、`/advisor`、`/thinkback` 等高级功能。101 个命令不是复杂度的证据，而是**一个系统在不同深度层次上服务不同用户**的证据。 --- ## 代码落点 - `src/commands/` — 完整命令目录（86 个一级子目录 + 15 个一级根文件，共 101 个一级入口） - `src/commands.ts` — 命令注册与路由入口（源码中确实是 `src/commands.ts` 这个单文件，不是 `src/commands/index.ts`） - `src/commands/advisor.ts`，第 96-109 行：`advisor` 命令定义（单文件命令的代表，`isEnabled` + `isHidden` 联动；这里路径是 `commands/advisor.ts` 而不是 `commands/advisor/index.ts`，刚好属于"15 个根文件"那一类） - `src/commands/voice/voice.ts`，第 1-151 行：`/voice` 命令五步 pre-flight - `src/commands/output-style/output-style.tsx`，第 1-6 行：已废弃命令的优雅提示 - `src/commands/effort/effort.tsx` — `/effort` 命令 UI（React 组件） - `src/commands/createMovedToPluginCommand.ts` — "已移至插件"占位命令工厂 --- ## 局限性与批判 - **命令发现性差**：101 个命令中大部分不在 `/help` 中显示，用户只能通过探索或阅读源码发现——渐进暴露的理念好，但缺乏中间层的引导机制 - **ant-only 功能不对等**：约 10 个调试命令仅内部可用，这意味着外部用户遇到问题时缺乏同等的诊断工具 - **实验性命令缺乏生命周期管理**：`/stickers`、`/bughunter` 等实验性命令没有明确的"实验"标记或过期机制，不清楚它们是未来正式功能还是已被放弃的原型 --- ## 还可以追问的方向 1. **`/teleport` 的完整实现**：它真的能跨设备传送会话吗？序列化的内容包括什么？ 2. **`/thinkback` 的 thinking token 回放**：它显示原始 thinking 还是整理后的？有时间线 UI 吗？ 3. **`/stickers` 的真正用途**：贴纸在终端里到底是什么？ 4. **`/bughunter` 的自动化程度**：它是手动指定范围还是全自动扫描？ 5. **ant-only 到外部的功能迁移路径**：一个功能从 ant-only 到 public 的决策标准是什么？ ---