用了 Claude Code 半年，我发现这个功能比 Copilot 还香

关注

原创最新推荐文章于 2026-08-22 15:03:34 发布 555 阅读 AI 写同款· GEO 优化 ›

AI编程工具实战分界线：Cursor、Copilot、Windsurf、Claude Code如何精准匹配开发场景 AI编程助手已从‘代码补全’演进为覆盖重构、文档生成、上下文感知与长逻辑分析的多维能力体系。其核心原理在于模型训练数据来源、上下文窗口长度、IDE集成深度及任务执行范式（指令驱动 vs 实时补全 vs 渐进式Agent）的差异。技术价值体现在显著压缩遗留系统理解周期、自动化合规代码生成、降低跨团队知识传递成本，并支撑DevOps全流程文档沉淀。典型应用场景包括：大型代码库架构分析、高频TypeScript/Python日常开发、VS Code生态内轻量增强、以及无文档C++/Java遗留系统攻坚。本文基于半阅读详情

用了 Claude Code 半年，我发现这个功能比 Copilot 还香

写在前面

最近在使用 Claude Code，同事们问得最多的就是：“跟 cursor比起来怎么样？”

老实说，刚开始我也觉得就那样。但用了几天后，有个功能让我彻底改变了想法 —— 斜杠命令（Slash Commands）。

先说个真实场景：我们项目有个复杂的代码规范，每次 Code Review 都要检查一堆东西。以前我得这样跟 AI 说：

帮我检查这个文件：
1. 组件命名是否符合 PascalCase
2. 是否用了团队约定的 hooks
3. 错误处理是否完整
4. 类型定义是否准确
5. 性能优化点...
巴拉巴拉一大堆

现在？一个 /review src/Button.tsx 搞定。

这就是斜杠命令的魅力 —— 把你的工作习惯「程序化」。

斜杠命令到底是啥？

简单说，就是把你经常用的那些复杂提示词，保存成文件，然后用 /命令名 快速调用。

比如我经常需要写单元测试，每次都要解释我们用的是 Jest + Testing Library，组件在 src/components，工具函数在 src/utils…

现在直接 /test UserCard.tsx，AI 就知道要：

用我们的测试套件
遵循我们的文件结构
按我们的规范写测试用例

这种感觉就像是，你终于有了个真正懂你项目的助手。

先看看内置的命令

Claude Code 本身就带了几个实用命令：

/add-dir - 把某个目录加到对话上下文
/agents - 调用专门的 AI 助手
/bug - 报告问题
/clear - 清空聊天记录
/config - 改配置

这些基本够日常用了，但真正的威力在自定义命令。

两种命令范围

项目级命令 (`.claude/commands/`)

放在项目根目录，只在这个项目里能用。适合放项目特有的东西，比如：

我们团队的代码规范检查
这个项目的部署脚本生成
特定框架的模板（比如我们用的是 Next.js + Prisma）

全局命令 (`~/.claude/commands/`)

放在用户目录，所有项目都能用。我一般放通用的东西：

通用的代码 review 模板
常用的文档格式
我个人的编码习惯

这样设计挺合理的，团队的东西跟着项目走，个人习惯全局复用。

动手写个命令

文件结构很简单

每个命令就是一个 .md 文件，基本格式：

---
description: "做什么的"
argument-hint: "需要什么参数"  
allowed-tools: ["Read", "Edit"]
---

这里写具体的提示词，用 $ARGUMENTS 代表传入的参数

用法就是：/命令名参数

前面那些配置的意思

字段	干啥的	举例
description	命令描述，打 `/` 时会提示	“检查代码规范”
argument-hint	参数提示	“文件名或目录”
allowed-tools	能用哪些工具	[“Read”, “Grep”]
model	用哪个模型	“sonnet-4”

这些都是可选的，但建议都写上，特别是 description。

几个实用技巧

1. 用 `$ARGUMENTS` 传参数

这个很好理解，就是占位符。比如我写了个生成 README 的命令：

---
description: "为项目生成 README"
argument-hint: "项目类型，比如 react, vue, node"
---

为这个 $ARGUMENTS 项目写个 README，包括：
- 项目介绍
- 安装方法
- 使用例子
- 贡献指南

要专业点，但别太正式，像给朋友介绍项目那样。

然后 /readme react 就能生成 React 项目的 README 模板。

2. 用 `!` 执行命令

这个厉害了，可以先跑个 shell 命令，再让 AI 分析结果。

我有个检查测试覆盖率的命令：

---
description: "检查测试覆盖率"
---

!npm test -- --coverage

看看测试覆盖率怎么样，哪里还没测到，给点建议。
不用太严格，重要的业务逻辑覆盖到就行。

这样 AI 会先跑测试，然后分析报告给建议。比我手动截图发给 AI 方便多了。

3. 用 `@` 读取文件

这个是我最爱的功能。以前要让 AI 看代码，得复制粘贴，现在直接：

---
description: "代码 review"
argument-hint: "文件路径"
---

帮我看看这个文件有啥问题：

@$ARGUMENTS

重点关注：
- 有没有明显的 bug
- 性能能不能优化
- 代码写得够不够清楚

别太吹毛求疵，主要问题指出来就行。

用法：/review src/hooks/useAuth.js，AI 就会自动读取文件内容分析。

4. 触发深度思考

有时候你希望 AI 想得更仔细点，可以在提示词里加上 “仔细想想”、“分析一下”、“规划一下” 这类词：

---
description: "新功能技术方案"
argument-hint: "功能描述"
---

仔细分析一下这个功能的技术方案：$ARGUMENTS

考虑这些方面：
- 数据库要改哪些表
- 需要新增哪些 API
- 前端页面怎么组织
- 可能有什么坑
- 大概要几天

给个靠谱的方案，别太理想化。

这样 AI 会更认真地思考，给出更全面的分析。

用目录整理命令

命令多了之后，可以按类别放到不同文件夹：

.claude/commands/
├── git/
│   ├── commit.md      # 智能提交信息
│   └── pr.md          # PR 描述生成
├── test/
│   ├── unit.md        # 单元测试
│   └── e2e.md         # E2E 测试
├── docs/
│   ├── api.md         # API 文档
│   └── readme.md      # README 生成
└── deploy/
    └── staging.md     # 预发布检查

然后用 /git/commit、/test/unit 这样调用。

我们团队现在有 30 多个命令，分类整理后找起来方便多了。

MCP 命令（高级玩法）

MCP 是个协议，可以让外部服务提供命令。格式是：

/mcp__服务名__命令名 参数

比如你接了个数据库服务，就能直接：

/mcp__database__query SELECT * FROM users LIMIT 10

这个功能还比较新，我还在摸索。不过想象空间很大，比如接个 Slack 服务，就能直接在 Claude Code 里发消息。

几个我常用的命令

代码 Review 命令

这是我用得最多的，结合了我们团队的规范：

---
description: "团队代码 review"
argument-hint: "文件路径"
allowed-tools: ["Read", "Bash"]
---

!git diff --name-only HEAD~1

Review 这个文件：$ARGUMENTS

按我们团队标准检查：
- 变量命名是不是清楚（别用 a、b、c 这种）
- 函数是不是太长了（超过 50 行要考虑拆分）
- 有没有处理错误情况
- TypeScript 类型定义对不对
- 有没有潜在的性能问题

@$ARGUMENTS

别太严格，重点问题指出来就行。实在有问题的地方给个修改建议。

这个命令会先看看最近改了哪些文件，然后针对具体文件做 review。

API 文档生成器

写文档是程序员的痛，这个命令能减轻不少负担：

---
description: "生成 API 文档"
argument-hint: "API 文件路径"
---

帮我为这个 API 文件写文档：$ARGUMENTS

格式要求：
- 每个接口写清楚干什么的
- 请求参数要有类型说明
- 响应格式要有例子
- 重要的错误码要说明

文档风格要友好点，像给同事写的，不要太正式。

@$ARGUMENTS

数据库迁移助手

这个是我们后端同学最爱的：

---
description: "创建数据库迁移"
argument-hint: "要做什么变更"
allowed-tools: ["Bash", "Read"]
---

!ls migrations/ | tail -3

为这个变更写个数据库迁移：$ARGUMENTS

参考现有的迁移文件格式，包括：
- UP 迁移（怎么改）
- DOWN 迁移（怎么回滚）
- 该加的索引别忘了
- 数据类型选择要合理

生成的 SQL 要能多次执行不出错。

这个命令会先看看现有的迁移文件是什么样的，然后生成符合我们项目风格的迁移脚本。