跳至主要內容

Claude Code 核心命令详解：simplify、review、loop、batch

说实话，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）执行多步工作流。

注意：/review 是内置 PR review 命令，不是 bundled skill；深度多 Agent 审查应使用 /ultrareview。

下面详细介绍这几个实用的内置能力。

/simplify：代码简化与重构

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

工作机制：三步走

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

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

三个 Agent 各管一摊：

  • Code Reuse Agent：看你的代码是不是在重复造轮子。比如你手写了一个 requireNonBlank()，它会在项目里搜一圈，发现已经有一个 InputValidator.requireNonBlank() 做了同样的事。
  • Code Quality Agent：看代码设计有没有问题。比如同一个字符串硬编码写了三遍、两个方法长得几乎一样、一个类既管认证又管发邮件——该拆没拆、该抽象没抽象的地方，它都会指出来。
  • 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 个潜在问题，经过确认，确实都是实际存在的问题。

直接运行 /simplify 命令

扫描到的问题

最值得说的是一个 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 个问题，涵盖代码复用、安全性和效率：

发现Agent修复方式
两个 Controller 各自定义了 requireNonBlank()，和已有的 InputValidator 重复Reuse删除私有方法，改用 InputValidator.requireNonBlank()
异常处理器的 regex 每次 replaceAll 都重新编译，且字符类不含 +/=，base64 token 会漏脱敏Quality + Efficiency提取为 static final Pattern，扩展字符类覆盖 base64
用 ConcurrentHashMap + @Scheduled 手动清理 30 秒过期的 TicketEfficiency替换为项目已有的 Caffeine 缓存（自带 TTL 淘汰）
@Bean 方法里的局部 Map 用了 ConcurrentHashMapEfficiency改为 HashMap（单线程填充，不需要并发安全）
注释笔误："兖底" 应为 "兜底"Quality修正

最终结果：5 个文件修改，净减少 38 行代码，修复 6 个问题，编译一次通过。

实战案例：指定模块审查

/simplify 还可以指定具体的类或模块做深度审查：

直接审查具体的类

/simplify MarketDataService

我对项目的行情数据服务 MarketDataService（约 570 行）跑了一次专项审查。这个类聚合多个数据源，提供 Caffeine 本地缓存 + Redis 分布式缓存 + 熔断降级。三个 Agent 找到了 8 个问题，其中有两个高严重性的：

Bug：year 周期被静默降级为 month。 normalizePeriod 方法里有一个 switch：

case "year", "yearly", "y" -> "month";  // Bug！应该是 "year"

其他周期都正确映射（day → "day"、week → "week"、month → "month"），唯独 year 被映射到了 month。调用方请求年度 K 线，实际拿到的是月度 K 线，没有任何报错或提示。

适合的场景

适合的：

  • 提交 PR 前的自审——尤其是涉及多文件重构的变更，让三个 Agent 并行扫一遍，成本很低但收益可能很高。
  • 重构后的质量检查——刚做完一次大范围代码整理，用来确认没有引入新的设计问题。
  • Code Review 的辅助工具——帮你发现那些需要领域知识才能识别的问题。

不太适合的：

  • 全项目代码审计——不带参数时基于 git diff 工作，只审查增量变更。
  • 风格统一——花括号放哪一行，用 tab 还是空格，那是 formatter 的活。
  • 安全审计——专业的安全审查需要 SAST 工具。

与传统工具的核心差异： 传统规则型工具默认更擅长发现通用代码味道；框架语义类问题往往需要专项规则或语义分析。/simplify 的优势在于它能结合上下文推理，理解框架语义。

/review：代码审查

前置说明：/review 是本地 PR review 命令，用于审查当前分支或指定 PR；如果要讲深度多 Agent 审查，应使用 /ultrareview；安全审查应使用 /security-review。

/review 和 /simplify 定位完全不同：/simplify 是自动清理工，找到问题直接改；/review 是资深审查员，找到问题列出来给你看，你自己决定改不改。

简单说，/simplify 关注可复用性、代码质量和效率，偏重清理与改进；/review 关注代码有没有写错，偏重正确性审查。

工作机制

执行 /review 时，Claude Code 会做三件事：

第一步：拿到变更。 它先跑 git diff 拿增量变更，或者根据你指定的 PR 读取远程变更。

第二步：并行分析。 Claude Code 并行审查变更，结合置信度过滤来减少误报。

第三步：输出分级报告。 最后你会拿到一份分级的问题清单（Critical / High / Medium / Low），每个问题带具体行号、原因和修复建议。

怎么用

/review              # 审查当前分支对应 PR，或本地 PR 语境
/review 123          # 审查指定 PR

文件级审查建议写成自然语言：比如"review src/auth/login.service.ts"。

审查完发现问题后，你可以直接说"修复所有 Critical 问题"，Claude 会根据审查建议自动改。

/review、/security-review、/ultrareview 怎么选

命令适合场景重点
/review日常 PR / 本地变更审查正确性、边界条件、潜在 Bug
/security-review登录、支付、权限、上传、Webhook 等敏感模块注入、鉴权、数据泄露、权限绕过
/ultrareview重要 PR 上线前，想做更深一层审查云端沙箱、多 Agent、深度 Review

我的建议：普通 PR 用 /review，涉及安全边界的改动额外跑 /security-review，核心链路或大版本上线前再考虑 /ultrareview。

/review 和 /simplify 怎么选

/simplify/review
目标消除技术债、提升可读性确保正确性、发现 Bug
做什么等效变换（重构）逻辑诊断（分析）
结果直接改代码列出问题和建议
关注点嵌套过深、变量命名、冗余逻辑安全漏洞、性能瓶颈、边界条件、逻辑错误

选 /simplify：代码能跑但涉及可复用性、代码质量或效率问题、刚写完原型想快速重构、想删掉冗余代码省 Token。

选 /review：不确定代码有没有 Bug、上线前做最后把关、涉及安全或资金的关键模块、想看资深工程师会对你的代码提什么意见。

最推荐的用法是先 /review 后 /simplify——先确保逻辑正确，再清理代码。

实战案例

有一次我写了一个用户认证模块，自测通过就准备提交了。顺手跑了一遍 /review，它标出了三个问题：

Critical：密码重置接口没做速率限制。 攻击者可以无限次调用重置接口轰炸用户邮箱。这个我自己测试的时候根本想不到——测试环境只有我一个用户，哪来的速率限制需求。

High：Token 过期时间从配置读取但没兜底。 配置项没设的话，过期时间会变成 0，意味着 Token 一生成就过期。/review 建议加一个 Math.max(config.tokenExpiry, 3600) 做保底。

Medium：日志里把 userId 明文打印了。 虽然不算敏感信息，但在合规要求严格的场景下还是脱敏比较好。

三个问题，两个和安全性相关。如果不跑 /review，前两个问题直接上生产。

注意事项

它不替你做决定。 和 /simplify 不同，/review 默认不改代码，只给建议。涉及安全的关键代码，这种"先看再动"的模式更让人放心。

它依赖 CLAUDE.md。 如果你没有在 CLAUDE.md 里写规范，/review 就只能做通用审查。把项目的编码规范、技术选型偏好、安全要求写进去，输出质量会高很多。

它不是 SonarQube。 SonarQube 基于规则匹配，/review 能理解框架语义——它知道 Spring 代理是怎么工作的，知道 @Transactional 在类内部自调用时会失效。这是它比传统静态分析工具强的地方。

/loop：定时任务与自主迭代

这是 Claude Code 之父认为最强大的两个命令之一，他多次分享推荐。

Claude Code 推荐使用 loop 命令

/loop 可以帮你定时跑任务，也可以帮你反复试错直到把活干完。

解决了什么问题

日常开发里有两类事特别烦人：

  • 第一类是需要反复做的事。比如每隔半小时检查一下有没有新的 PR 需要处理、每天早上跑一遍测试看看有没有挂掉的。这些事不难，但总忘。
  • 第二类是需要反复试错的事。比如修复一个牵扯多个模块的 Bug，把整个项目从 CommonJS 迁移到 ESM。这种任务的特点是：一次做不完，中间会出错，出错了要改，改完再验证。

/loop 把这两类事都接过去了。

三种调度方案怎么选

Claude Code 不止 /loop 这一种定时机制，它实际上有三套调度方案：

Cloud 任务Desktop 任务/loop
运行位置Anthropic 云端你的机器你的机器
需要开机吗不需要需要需要
需要打开会话吗不需要不需要需要
重启后还在吗在在会话级；关闭期间不会执行；使用 --resume / --continue 恢复同一会话时，7 天内未过期的 recurring task 可恢复
能访问本地文件吗不能（重新 clone）能能
MCP 服务器每个任务单独配置配置文件和连接器继承当前会话
最小间隔1 小时1 分钟1 分钟

一句话选型：要可靠、不想管机器 → Cloud 任务；要读本地文件 → Desktop 任务；临时轮询、快速用一下 → /loop。

两种工作模式

模式一：定时调度（Cron 模式）

告诉它"干什么"和"隔多久干一次"，到点它自己跑：

/loop 30m /review              # 每 30 分钟跑一次代码审查
/loop 1h "跑一遍单元测试，看看有没有失败的"  # 每小时检查测试
/loop 5m "检查 GitHub 上开放的 PR 状态"    # 每 5 分钟看 PR 动态

间隔写法有三种：

写法示例效果
间隔在前/loop 30m 检查构建状态每 30 分钟
"every"在后/loop 检查构建状态 every 2 hours每 2 小时
不写间隔/loop 检查构建状态Claude 动态选择下一次执行间隔（通常 1 分钟到 1 小时）；Bedrock/Vertex AI/Microsoft Foundry 场景下固定 10 分钟

模式二：自主迭代（Agentic Loop）

这个模式下 /loop 不再是定时器，而是"自动试错引擎"。你给它一个目标，它自己规划、执行、验证、修正，循环往复。它适合把"执行—观察—修正—再执行"这类循环交给 Claude，但要写清完成标准、最大尝试次数和停止条件：

/loop "修复 auth 模块里所有失败的单元测试，直到全部通过"
/loop "把 src/legacy 下所有组件迁移到 Tailwind CSS，确保页面渲染正常"
/loop "实现支付宝支付模块，补上单元测试，确保全部通过"

普通模式下 Claude 写完代码就交给你了，报错你得自己贴回去。/loop 模式下，它自己读报错、自己改、自己重跑测试，全程不用你盯着。

五个实际场景

1. 自动监控 PR 状态。 每 5 分钟拉一次开放的 PR，检查有没有冲突、能不能安全合并、生成摘要。

/loop 5m "用 gh 命令检查开放 PR 的状态，标记有冲突的和可以安全合并的"

2. 自动测试看门狗。 定时跑测试，发现了失败的测试就尝试修。多人协作的项目里特别实用——别人合进来的代码可能悄悄搞挂了你的模块。

/loop 2h "运行测试套件，发现失败的就修复"

3. 定时同步项目文档。 改了代码忘了改文档，这是开发者最常犯的错。每 2 小时让 /loop 扫一遍代码变更，自动把改动同步到用户文档里。

/loop 2h "检查最近的代码变更，更新对应的公开文档"

4. 大规模技术迁移。 比如把整个项目从 CommonJS 迁到 ESM，几十个文件，中间一定会有报错。/loop 能自己处理这些错误，一个文件一个文件地改过去。

/loop "把项目里所有 CommonJS 的 require/module.exports 改成 ESM 的 import/export，确保测试全部通过"

5. 批量拉起自动化任务。 可以写一个自定义命令文件，把所有定时任务列在里面。项目启动时跑一条命令就能把所有自动化任务一起拉起来。

怎么管理任务

直接用自然语言跟 Claude 说就行：

我现在有哪些定时任务？
停掉那个检查部署的任务

底层靠三个工具干活：

工具干什么
CronCreate创建任务，接收 cron 表达式、要执行的 prompt、是否循环
CronList列出所有在跑的任务，显示 ID、调度时间、prompt
CronDelete按 ID 删任务

运行机制细节

空闲时才触发。 调度器每秒检查一次有没有到期任务，但只在 Claude 空闲时才触发。如果你正在跟它对话，任务会排队等当前这轮结束再跑。

有抖动机制。 防止所有用户任务在同一时刻砸向 API。循环任务最多延迟周期的 10%，上限 15 分钟。若任务间隔小于 1 小时，最多延迟半个 interval。需要精确触发的话，建议避开 :00 和 :30。

任务有保质期。 循环任务创建 7 天后自动过期，会最后执行一次然后自行删除。需要更长周期的，用 Cloud 或 Desktop 的定时任务。

注意事项

  • Token 消耗不低。 特别是自主迭代模式，指令尽量具体，完成标准要明确。
  • 只在当前会话有效。 关掉终端或退出 Claude Code，关闭期间不会执行，也不会补跑。它不是 CI/CD 的替代品。
  • 建议加上限。 目标一直达不到它会一直跑。在指令里加一句"最多尝试 10 次"之类的约束。
  • 写清停止条件。 包括最多尝试次数和验收标准（测试全部通过/CI green/无 lint error）。
  • 失败时先汇报。 限制写操作，避免无限修改。涉及关键路径的改动建议先 commit 再跑 /loop，方便回滚。
  • 7 天限制。 循环任务创建 7 天后自动过期，dynamic loop 也适用此限制。需要更长周期用 Routines 或 Desktop scheduled tasks。

/debug：Claude Code 自己出问题时先跑它

/debug 不是帮你 debug 业务代码，而是帮你排查 Claude Code 会话本身的问题。

比如 MCP 连接异常、工具调用失败、命令卡住、权限规则没生效、插件加载异常，这类问题别急着重启，先跑：

/debug MCP 连接一直失败
/debug 为什么工具调用被拒绝
/debug Claude Code 卡住不动

它会开启当前会话的 debug log，并结合日志分析问题。

注意：如果你不是用 claude --debug 启动的，/debug 只能从执行之后开始捕获日志，之前的错误可能看不到。

/batch：多任务并行编排

/batch 的核心本质是多任务并行编排器，它的强大之处在于它能将一个复杂的"大需求"自动拆解并并行执行。

  • 任务拆解 (Task Decomposition)： 当你说一个大任务或者多条需求的时候，Claude 并没有胡乱开始，而是将其逻辑拆分成独立的 Unit（工作单元）。
  • 并行工作 (Parallel Workers)： Claude 会同时启动多个后台 Agent，分别处理不同的功能模块。
  • 独立工作区 (Independent Worktrees)： 为了防止多个 Agent 同时修改代码导致冲突，Claude 为每个 Worker 创建了独立的 Git Worktree。这意味着它们在物理隔离的环境中修改代码，互不干扰。

使用方法很简单：

/batch  1、移除自选股界面，直接通过分析界面来管理，每一行股票的最右侧展示选项，支持删除和分组。
  2、自选股提取一个组件、K线展示和讨论室都单独提取一个组件出来。
  3、优化提示词管理，例如支持删除和重命名。
  4、历史记录目前支持10条记录，这块的设计优化一下。

Claude 收到后会先给出拆分计划（通常 5～30 个 unit），经确认后在隔离 worktree 中并行执行，每个单元通常产出独立 PR。

Claude Code 运行 /batch 命令

每个 Worker 完成后，主进程会检查每个单元的改动，最终产出多个独立 PR（而非合并成一个大的 PR）。

⚠️ 风险提示：/batch 适合边界清晰、模块相对独立的大任务；不适合强耦合核心链路一次性大改。共享文件（如 package.json、路由表、公共类型、数据库迁移脚本）容易冲突。使用前建议先 commit 干净工作区。

Claude Code 合并改动

你可以理解为： 你请了三个外包程序员（Worker）为三个不同的房间干活，现在项目经理（Main Agent）发现那三个房间的门锁有点问题，于是他亲自去每个房间把写好的代码拷贝出来，最后交到你手里。

几个容易被忽略的辅助命令

上面几个命令负责干活，但真正用顺手之后，你还会频繁用到这些辅助命令。

命令作用我一般什么时候用
/diff查看 Claude 到底改了什么每次 /simplify、/batch 后必看
/context查看上下文占用长任务开始变慢、变飘时先看
/compact总结并压缩上下文长会话继续推进前用
/debug排查 Claude Code 会话问题MCP、工具调用、权限异常时用
/permissions管理工具权限跑 /loop、/batch 前先检查
/statusline配置状态栏想常驻看模型、目录、上下文、成本时用
/usage / /cost查看用量和成本长任务前后看消耗

别忽略上下文管理：/context 和 /compact

长任务跑久了，Claude Code 不一定是"能力变差"，很多时候是上下文被塞得太满了。

先看：

/context

它会展示当前上下文使用情况，告诉你是不是工具输出、历史对话、规则文件把窗口挤爆了。

如果任务已经聊了很久，但还想继续推进，可以用：

/compact 只保留当前重构目标、已完成改动、剩余 TODO、关键约束

/compact 会总结当前会话，释放一部分上下文。大任务中途做一次 compact，但一定要给它明确的保留范围，不要只裸跑 /compact。

别把权限全放开：/permissions 要会用

Claude Code 能读文件、改文件、跑命令，能力很强，但权限不能无脑全开。

建议先跑：

/permissions

把高风险命令设成 ask 或 deny，比如删除文件、执行部署脚本、操作生产数据库、推送远程分支这类动作。尤其是你要跑 /loop 或 /batch 时，更应该先收紧权限。

让 AI 自动干活可以，但别让它自动闯祸。

让用户养成"看 diff 再信 AI"的习惯

Claude 改完代码后，不要只看它的总结，直接跑：

/diff

它会打开交互式 diff viewer，看当前工作区到底被改了哪些文件、哪些行。尤其是 /simplify、/batch 这类会直接动代码的命令，跑完之后先看 diff，再决定要不要继续。

真正高频的不是命令本身，而是组合

上面讲了 /simplify、/review、/loop、/batch，但真正用顺手之后，你会发现这些命令是可以组合成一个完整工作流的：

  • /batch 负责拆任务
  • /loop 负责反复执行和验证
  • /simplify 负责清理技术债
  • /review 负责正确性把关
  • /security-review 负责安全兜底
  • /diff 负责人工验货
  • /context + /compact 负责上下文续命

一个更稳的工作流是这样的：

  1. /context 先看上下文是否健康
  2. /permissions 检查权限设置是否合理
  3. /batch 把大需求拆成多个独立任务
  4. /loop 处理需要反复验证的复杂任务
  5. /simplify 清理冗余代码和技术债
  6. /review 做正确性审查
  7. 涉及登录、支付、权限、上传、Webhook 等敏感模块，再跑 /security-review
  8. /diff 人工确认改动
  9. 最后跑测试、提交 PR

这一套走下来，能显著减少机械操作，但关键节点仍要看计划、看 diff、跑测试、做最终 review。

附录：Claude Code 接入国内模型

CClaude Code 强在它的工具链和执行力，但 Claude 官方模型太贵，加上现在 Claude 太容易封号。我们可以使用国内的 MiniMax 或 GLM 作为它的底层大模型。它们都采用了标准的 OpenAI 兼容接口，接入过程非常丝滑。

1. 获取 API Key

MiniMax Key 获取

GLM Key 获取

2. 推荐使用 CC Switch

强烈推荐安装 CC Switch，这是一个专门管理 Claude Code 模型切换的小工具，支持管理 Skills、MCP 和提示词。

项目地址：https://github.com/farion1231/cc-switch

CC Switch 主界面

启动 CC Switch，点击右上角 "+" ，选择预设的 MiniMax/GLM 供应商，填写 API Key，选择模型，添加即可。

CC Switch 配置 MiniMax/GLM API Key

CC Switch 配置模型

3. 验证是否生效

在任意目录下输入 claude 命令即可启动 Claude Code，选择 信任此文件夹 (Trust This Folder)。

验证是否生效

4. 接入验证清单

MiniMax / GLM 接入不是"能对话"就算成功，Claude Code 的关键是工具调用。建议验证以下核心功能：

编辑此页
最近更新:
贡献者: Guide,Mr.Hope