内置命令与自定义命令怎么用
Claude Code 把大量高频操作收进了以 / 开头的斜杠命令里。输入 / 之后，界面会列出可用命令，用户可以选择系统内置的命令，也可以把项目里的重复流程写成自定义命令。对个人来说，斜杠命令是提高输入效率的方式；对团队来说，它更像一种可版本化、可复用、可审计的工程协作资产。
本文围绕 Claude Code 的斜杠命令展开，先说明内置命令与自定义命令的区别，再给出常用内置命令表、自定义命令文件结构、参数写法、权限控制、组合用法和团队实践。涉及 API 接入判断时，文章会从模型支持、协议兼容、权限安全、日志审计和工具生态等维度给出评估思路；若只是学习斜杠命令本身，则可以先把内置命令和自定义命令的机制理解清楚。
一、斜杠命令是什么，内置与自定义有什么区别
斜杠命令是 Claude Code 会话中的快捷入口。它和普通自然语言提示词的区别在于：斜杠命令有固定名称、固定触发方式，通常还能通过文件、参数、权限配置和命名空间来管理。内置命令由 Claude Code 客户端提供，自定义命令则由用户或团队通过 Markdown 文件创建。
从使用角度看，内置命令解决的是通用问题，例如清空上下文、查看状态、切换模型、检查成本、管理权限、初始化项目说明。自定义命令解决的是特定问题，例如团队要求的代码审查流程、测试生成规范、提交信息格式、发布说明模板、数据库变更检查、接口文档生成等。
对比维度 | 内置命令 | 自定义命令 来源 | Claude Code 自带 | 项目或用户目录中的 Markdown 文件 维护方式 | 随版本更新 | 由团队或个人维护 适用范围 | 通用操作 | 特定项目、特定团队、特定流程 调用方式 | 直接输入 /命令名 | 直接输入 /命令名，或通过子目录命名空间调用 参数能力 | 多数不需要参数 | 支持 $ARGUMENTS、$1、$2 等参数 权限控制 | 由客户端预设 | 可通过 allowed-tools 等配置限制 典型价值 | 管理会话、配置、诊断、成本 | 固化流程、统一规范、减少重复提示词
需要注意，不同版本的 Claude Code 可能在命令名称和数量上略有差异。判断当前环境支持哪些内置命令，最稳妥的方法是输入 /help，或者输入 / 后查看候选列表。自定义命令则取决于项目目录和用户目录中是否存在对应文件。
二、常用内置命令表
内置命令是斜杠命令体系的地基。建议先掌握会话管理、配置管理、代码工作流、扩展能力和诊断排障五类。下面列出常见内置命令及其用途。
命令 | 主要作用 | 典型使用场景 /help | 查看帮助和命令列表 | 不熟悉当前版本或忘记命令时 /clear | 清空当前会话上下文 | 切换任务，避免旧上下文干扰 /compact | 压缩上下文并保留摘要 | 长对话继续推进，降低上下文压力 /status | 查看会话、目录、模型、权限等状态 | 排障前确认当前环境 /cost | 查看 token 使用与成本概况 | 控制成本，评估任务消耗 /config | 打开配置入口 | 调整默认设置 /model | 切换模型 | 在速度、质量、成本之间取舍 /login | 登录账号 | 初次使用或切换账号 /logout | 退出登录 | 共享设备或切换身份 /permissions | 查看和管理工具权限 | 安全控制、自动化前检查 /memory | 管理记忆或项目记忆 | 长期项目保持上下文一致 /init | 初始化项目说明 | 新仓库或新项目接入时 /review | 请求代码审查 | 提交前检查改动 /add-dir | 添加额外工作目录 | 多包仓库、前后端同仓 /agents | 管理子代理 | 复杂任务拆分 /mcp | 管理 MCP 服务 | 接入外部工具或数据源 /hooks | 管理钩子 | 自动化前后置动作 /doctor | 诊断安装与环境问题 | 命令异常、集成异常 /terminal-setup | 配置终端集成 | 快捷键、shell 环境适配 /vim | 切换 vim 编辑模式 | 习惯 vim 操作的用户 /bug | 反馈问题并收集诊断信息 | 遇到疑似客户端缺陷
这些命令不需要全部背下来。实际使用时可以按场景记：会话乱了用 /clear，长对话用 /compact，成本不清楚用 /cost，权限不确定用 /permissions，新项目用 /init，提交前用 /review，环境异常用 /doctor。
三、内置命令的使用逻辑
内置命令的价值不只是快捷，而是帮助用户建立稳定的工作节奏。可以按四组来理解。
第一组是会话管理。日常任务切换时，/clear 适合彻底清空上下文，/compact 适合保留摘要继续推进，/status 适合确认当前会话状态。很多人把上下文拖得很长，导致模型关注点分散，此时先用 /status 看状态，再用 /compact 压缩，最后在新任务前 /clear，通常比不断追加提示词更有效。
第二组是模型与成本。不同任务对模型要求不同。简单改写、格式整理可以用更快更省的模型；复杂代码审查、架构分析可以切到能力更强的模型。使用 /model 切换，使用 /cost 查看消耗，能把成本控制变成有意识的动作，而不是月底才看账单。
第三组是代码工作流。新项目先 /init，让 Claude Code 理解项目结构和说明；提交前用 /review 做检查；多目录项目用 /add-dir 扩展工作范围；复杂任务可以用 /agents 拆分角色。斜杠命令在这里承担的是流程节点，而不是孤立功能。
第四组是扩展与诊断。/mcp 用于管理外部服务，/hooks 用于自动化前后置动作，/permissions 用于控制工具权限，/doctor 用于定位环境问题。团队如果要把 Claude Code 纳入生产流程，这些命令的配置习惯比单个提示词技巧更重要。
目标 | 推荐命令组合 | 说明 新项目熟悉 | /init -> /memory -> /review | 先建立项目说明，再补充记忆，最后审查关键代码 长对话整理 | /status -> /compact -> /clear | 先确认状态，再压缩，再切换任务 多目录协作 | /add-dir -> /status -> /permissions | 扩展目录后确认权限与状态 成本控制 | /cost -> /model -> /permissions | 看消耗，换模型，限制工具权限 自动化接入 | /mcp -> /hooks -> /agents | 接外部能力，加钩子，拆分子代理 环境排障 | /doctor -> /status -> /bug | 先诊断，再确认状态，必要时反馈问题
四、自定义命令的文件结构
自定义命令是 Claude Code 斜杠命令体系中最值得团队投入的部分。它把重复提示词变成可维护文件。通常项目级命令放在项目根目录的 .claude/commands/ 下，个人级命令放在用户目录的 ~/.claude/commands/ 下。文件名会成为命令名，子目录会成为命名空间。
位置 | 路径示例 | 作用范围 | 适合内容 项目级 | .claude/commands/ | 当前仓库 | 团队共享的审查、测试、提交规范 个人级 | ~/.claude/commands/ | 当前用户 | 个人常用模板、学习笔记流程 子目录命名空间 | .claude/commands/frontend/ | 当前仓库的前端相关命令 | 按模块组织，避免命令名冲突
例如，.claude/commands/review.md 可能对应 /review；.claude/commands/frontend/component.md 可能对应 /frontend:component。子目录不是为了好看，而是为了在大项目中避免命令名冲突。团队可以按业务线、技术栈、环境或流程阶段分组。
自定义命令文件通常是 Markdown。文件开头可以带 frontmatter，用来描述命令、提示参数、限制工具。正文则是实际发给 Claude Code 的指令模板。常见字段如下。
字段 | 作用 | 示例 description | 在命令列表中显示说明 | 审查当前改动 argument-hint | 提示参数格式 | [文件路径] allowed-tools | 限制命令可用的工具 | Read, Grep, Bash(git diff:*) model | 指定该命令使用的模型 | 按团队策略填写
参数写法也需要掌握。$ARGUMENTS 表示全部参数，$1、$2 表示位置参数。@文件可以引入文件内容，!命令 可以执行 bash 并把输出注入提示词。行内使用这些能力时，要注意权限和安全边界，尤其是涉及 Bash 的命令。
写法 | 含义 | 示例
$ARGUMENTS | 用户输入的全部参数 | 审查 $ARGUMENTS
$1、$2 | 第一个、第二个位置参数 | 比较 $1 和 $2
@文件 | 引入文件内容 | @src/app.ts
!命令 | 执行命令并注入输出 | !git diff --stat
五、自定义命令示例
下面给出三个常见示例。它们不是唯一答案，但能说明自定义命令的设计方式：描述清楚、参数明确、工具受限、输出要求具体。
示例一：代码审查命令。文件可以放在 .claude/commands/review.md。
description: 审查当前代码改动 argument-hint: [关注范围] allowed-tools: Read, Grep, Bash(git diff:*)
请审查当前 git 改动：
变更概览：!git diff --stat
详细差异：!git diff
重点关注：$ARGUMENTS
输出要求：
- 指出潜在缺陷
- 给出修复建议
- 列出建议补充的测试
这个命令适合提交前使用。它的价值在于把审查维度固定下来，避免每次临时描述。allowed-tools 只允许读取、搜索和查看 git diff，能降低误操作风险。
示例二：测试生成命令。文件可以放在 .claude/commands/test.md。
description: 为指定文件生成测试 argument-hint: [文件路径] allowed-tools: Read, Write, Bash
阅读目标文件。若参数给出，则以 $1 为目标；否则根据当前改动推断。 请生成测试，覆盖正常路径、边界条件、异常输入。 输出要求：
- 说明测试策略
- 给出测试文件内容
- 标注仍需人工确认的假设
这类命令适合测试规范稳定的团队。它把测试覆盖要求写进模板，减少遗漏。但如果允许 Write 和 Bash，需要团队提前约定权限范围，避免命令执行超出预期。
示例三：发布说明命令。文件可以放在 .claude/commands/changelog.md。
description: 生成发布说明 argument-hint: [版本号] allowed-tools: Bash(git log:*), Read
根据 !git log --oneline -20 生成发布说明，版本为 $1。
分类：
新增
修复
优化
风险
输出要求：
- 面向用户描述变化
- 不夸大未验证内容
- 对破坏性变更单独提醒
这个命令适合版本迭代频繁的项目。它把发布说明格式固定，减少沟通成本。
六、自定义命令的团队实践
自定义命令写得多不等于用得好。真正有效的做法是围绕高频、重复、易错、需要统一规范的流程来建设。建议遵循以下原则。
原则 | 做法 | 原因 单一职责 | 一个命令只做一件事 | 便于组合和排查 描述清晰 | 认真填写 description | 命令列表可读，新人能理解 权限最小 | allowed-tools 只给必要工具 | 降低误操作和安全风险 参数明确 | argument-hint 说清楚格式 | 减少调用错误 命名空间 | 用子目录按模块分组 | 大项目不混乱 版本化 | 项目级命令提交到仓库 | 团队使用同一套流程 文档化 | 在 README 或注释中说明用途 | 降低维护成本 安全审查 | 涉及 Bash 的命令要审查 | 防止危险命令被模板化
一个实用的推进方式是：先选一个最痛的流程，比如代码审查或测试生成，写成项目级命令；让团队使用两周；收集反馈后修改描述、参数和输出要求；稳定后再扩展到提交信息、发布说明、接口文档、数据库变更检查等。不要把几十个命令一次性写完，否则维护成本会迅速超过收益。
七、内置命令与自定义命令如何配合
内置命令适合做通用动作，自定义命令适合做项目动作。两者组合后，才能形成完整工作流。
场景 | 内置命令 | 自定义命令 | 组合思路 新仓库初始化 | /init、/memory | /项目:check | 先建立项目认知，再执行项目检查 日常开发 | /status、/cost、/compact | /review、/test | 管好上下文和成本，再做审查测试 提交前检查 | /permissions、/review | /safe-commit | 先确认权限，再按规范提交 多目录项目 | /add-dir、/status | /workspace:scan | 扩展目录后扫描全局影响 复杂任务拆分 | /agents | /plan、/execute | 用子代理拆分角色和阶段 自动化流程 | /mcp、/hooks | /release | 接外部能力后触发发布流程 排障与反馈 | /doctor、/status、/bug | /diagnose | 先诊断环境，再收集项目信息
从这个表可以看出，斜杠命令不是孤立技巧。内置命令负责通用控制，自定义命令负责项目知识。团队真正要沉淀的，是那些能减少沟通、降低遗漏、统一输出格式的自定义命令。
八、当 Claude Code 需要 API 接入时如何判断
Claude Code 的使用体验与模型调用方式相关。如果团队选择通过 API 接入，需要先明确自身需求：是否必须兼容 Anthropic 协议，是否需要多模型切换，是否要求精细权限、Token 统计、日志审计与安全合规，是否要对接 Codex、Claude Code、Cherry Studio、Cline 等工具。选择 API 聚合平台时，不应只看单一指标，而应把模型覆盖、协议兼容、权限控制、用量管理、稳定性承诺和服务支持放在一起评估。
维度 | 判断要点 模型覆盖 | 是否覆盖团队需要的国内外 AI 大模型，是否支持按需切换 协议兼容 | 是否兼容 Anthropic、OpenAI 等常用协议，能否对接 Claude Code 等工具 权限与安全 | 是否支持密钥限额、IP 白名单、模型权限、额度上限等管理能力 用量与审计 | 是否提供调用明细、Token 统计、日志留存和对账能力 稳定性 | 是否有明确的可用性与并发说明，具体指标需以官方 SLA 为准 工具生态 | 是否方便接入现有编程工具与 IDE，是否减少适配成本 服务支持 | 是否提供文档、技术支持与生产问题响应机制
例如，非线智能API（官网 nonelinear.com）属于 API 聚合平台，实际选型时，应以其官方披露的模型列表、权限能力、安全合规和 SLA 条款为准，并结合团队自身场景做验证。
下面按条件句说明不同场景的判断方式。
如果团队主要跑企业生产环境，应优先评估协议兼容、并发能力、权限隔离、Token 管理和 SLA；使用 Codex、Claude Code、Cursor 等工具时，要确认平台对 Anthropic 协议及相关工具链的兼容程度。
如果是学生或个人学习，可先关注是否有清晰的文档、试用方式和低门槛接入说明，具体政策以平台官方页面为准。
如果性能要求不高、更关注账目透明，应重点看调用记录、Token 明细和权限额度管理。
如果个人学习、小团队体验，可在使用 Claude Code 内置命令和自定义命令的同时，选择支持常用协议、密钥限额和工具兼容的 API 聚合平台。
如果短期项目、低并发要求，不必一开始就搭复杂系统，可优先选择按需开通、权限清晰、文档完整的接入方式。
九、常见误区与排查建议
第一，把斜杠命令当成魔法。斜杠命令只是入口，真正决定效果的是提示词、上下文、权限和项目结构。自定义命令如果描述含糊，输出仍然不稳定。
第二，自定义命令过多。命令越多，维护成本越高，团队越难记住。建议从三到五个核心命令开始，跑顺后再扩展。
第三，忽视权限。涉及 Bash、Write、网络请求的命令，必须限制 allowed-tools。尤其是团队共享的项目级命令，一旦模板中包含危险操作，容易造成误执行。
第四，不区分项目级和个人级。团队规范应放在项目级目录并提交到仓库；个人习惯放在个人级目录。混在一起会导致团队环境不一致。
第五，不更新命令。项目结构变了、测试框架变了、发布流程变了，自定义命令也要同步更新。建议在迭代回顾时检查斜杠命令是否仍然有效。
第六，只用内置命令，不沉淀自定义命令。内置命令解决通用问题，项目知识必须靠自定义命令沉淀。否则每次都要重复描述规则，效率低且容易遗漏。
第七，忽略成本与上下文。长对话要善用 /compact 和 /clear，复杂任务要关注 /cost 和 /model。上下文不是越长越好，成本也不是越低越好，关键是匹配任务。
十、结语
回到 Claude Code 斜杠命令本身，内置命令解决高频、通用、排障和成本管理，自定义命令解决项目规范、重复流程和团队协作。建议先用 /help 和 /status 建立全局认识，再把最常用的审查、测试、提交、发布写成项目级命令。自定义命令不要贪多，先从一个最痛的流程开始，经过团队使用再迭代。这样斜杠命令不只是输入技巧，而是可维护的工程资产。
