说实话，Claude Code 里有些命令我用了一次就离不开了，但问身边朋友知道的人反而不多。这个系列文章就来聊聊这些被严重低估的命令——/simplify、/review、/loop、/batch。

这些命令你知道有就行了，不用硬背。打个斜杠 / 就出来了，比你吭哧吭哧打字快多了。

版本说明：本文基于 2026 年 5 月 Claude Code 官方 Commands 文档和当前客户端行为整理。Claude Code 命令更新很快，最终以 /help、/ 命令列表和官方 Commands 页面为准。

先理清 Claude Code 的命令体系

Claude Code 里 / 开头的东西，来源有两层：

• Commands（硬编码命令）—— /clear、/compact、/model、/cost、/help、/review 等。逻辑写死在CLI 代码里，直接与终端交互，不涉及 AI 推理，执行速度快且不消耗 Token。
• Bundled Skills（捆绑技能）——/simplify、/batch、/debug、/loop、/claude-api 。本质是基于Prompt 的能力：调用时，Claude 会载入特定的 Markdown指令集到上下文，然后调动子代理（Sub-agents）执行多步工作流。
• 下面详细介绍这几个实用的内置能力。

/simplify：代码简化与重构

/simplify 做的事很简单：审查你刚写的代码，找出隐藏的问题，然后直接帮你改掉。现在官方文档已把 /simplify 列为 bundled skill。

工作机制：三步走

第一步：确定审查范围。 通常围绕最近变更文件工作；不带参数时，它跑 git diff 拿增量变更；如果工作区没有未提交的修改，它会自动审查最近一次 commit。指定具体类名时（比如 /simplify MarketDataService），它会读取整个文件做全量审查。具体范围以当前 Claude Code 版本行为为准。

第二步：并行启动三个审查 Agent。 不是串行地逐条检查，而是同时派出三个"审查员"，各自带着不同的视角去读同一份 diff：

三个 Agent 各管一摊：

• Code Reuse Agent：看你的代码是不是在重复造轮子。比如你手写了一个requireNonBlank()，它会在项目里搜一圈，发现已经有一个 InputValidator.requireNonBlank()做了同样的事。
• Code QualityAgent：看代码设计有没有问题。比如同一个字符串硬编码写了三遍、两个方法长得几乎一样、一个类既管认证又管发邮件——该拆没拆、该抽象没抽象的地方，它都会指出来。
• Efficiency Agent：看代码跑起来会不会有性能问题。比如循环里反复创建同一对象，单线程场景非要用ConcurrentHashMap、该用缓存的结果每次都重新算。
  第三步：汇总并修复。 三个 Agent 各自报告发现，Claude Code 会自动判断哪些是真问题、哪些是误报，然后直接动手改代码。

⚠️ 风险提示：/simplify 会应用修复，但仍建议通过 diff、测试和 review 复核，尤其是涉及事务、安全、并发的改动。它是 prompt-based skill，可能误判。

指定关注方向

也可以给它指定关注方向：

/simplify thread safety
/simplify SQL performance
/simplify exception swallowing
/simplify MarketDataService

在你已经知道哪块大概有问题、想让 AI 帮你精确定位的时候，这个功能很实用。

实战案例：Spring 事务失效

有一次我写了一个用户认证模块，自测通过就准备提交了。习惯性地先跑了一遍 /simplify，它直接帮我找到了 6 个潜在问题，经过确认，确实都是实际存在的问题。

最值得说的是一个 Spring 事务失效 的问题。三个 Agent 中有两个独立地从不同角度捕获到了同一个 Bug。

问题代码是这样的——WatchlistService 里，外层方法获取 Redis 分布式锁做 double-check，内部调一个 protected 方法执行数据库写入：

public void initializeDefaultWatchlist(Long userId) {
    // Redis 分布式锁 + double-check（幂等）
    // ...
    doInitializeDefaultWatchlist(userId);  // 同一类内部调用
    // ...
}

@Transactional(rollbackFor = Exception.class)
protected void doInitializeDefaultWatchlist(Long userId) {
    groupService.save(defaultGroup);        // INSERT 分组
    stockService.saveBatch(initialStocks);  // INSERT 5 只股票
}

代码结构看起来合理：外层管锁和幂等，内层管事务。但 @Transactional 写在这实际上完全不起作用——因为 Spring AOP 基于动态代理，同一个类内部的直接调用会绕过代理，注解根本不会被拦截到。

这意味着如果 saveBatch 中途抛异常，save 已经提交的分组记录不会回滚，数据库里会出现一个没有股票的空壳分组。

前提条件：在 Spring 默认代理式 AOP 下，同类内部直接调用会绕过代理，@Transactional 不会生效；如果使用 AspectJ weaving 或通过代理对象调用，结论不同。

• Code Quality Agent 标记了自调用导致 @Transactional 失效，评为高严重性。 Efficiency
• Agent 排除了锁 TTL 不足的可能，精准定位事务失效是根因。 Code Reuse Agent
• 确认手写的分布式锁没有可复用替代，实现合理。

/simplify 给出的修复方案是把声明式事务换成编程式事务，用 TransactionTemplate 直接控制事务边界。其他修复方式包括：把事务方法移动到另一个 Spring Bean、通过代理对象调用、调整事务边界到外层 public 方法。

@RequiredArgsConstructor
public class WatchlistService {

    private final TransactionTemplate transactionTemplate;

    private void doInitializeDefaultWatchlist(Long userId) {
        transactionTemplate.executeWithoutResult(status -> {
            groupService.save(defaultGroup);
            stockService.saveBatch(initialStocks);
        });
    }
}

这次扫描还发现了另外 5 个问题，涵盖代码复用、安全性和效率：