Claude Code这四个命令，用一次就离不开了

Claude Code用了一段时间，最深的感受不是它写代码有多快，而是写完代码之后那堆事——审查、重构、测试、修复——以前全得自己干，现在有几个命令能帮你接住。

/simplify、/review、/loop、/batch。知道的人不多，但用一次就回不去了。

先搞清楚：命令分两种

Claude Code里斜杠开头的东西，不是一类东西。

硬编码命令——/clear、/compact、/model、/help，逻辑写死在CLI里，不消耗Token，执行速度飞快。

捆绑技能——/simplify、/batch、/debug、/loop，本质是一组Markdown指令集。调用时Claude把指令载入上下文，然后派子代理去干活。消耗Token，但干的活也复杂得多。

/review是个例外，它是硬编码命令，不是捆绑技能。想深度多Agent审查，得用/ultrareview。

好，一个个来。

/simplify：让AI自己审自己

你刚写完一段代码，自测通过了，准备提交。但你心里清楚，自测通过不等于没问题。

这时候跑一遍 /simplify。

它怎么工作的？三步。

第一步，确定审查范围。没参数时它跑git diff拿增量变更；工作区干净的话就审查最近一次commit；指定类名比如 /simplify MarketDataService，它读整个文件做全量审查。

第二步，同时派三个审查Agent出去，各管一摊：

• Code Reuse Agent——你是不是在重复造轮子。你手写了一个requireNonBlank()，它会在项目里搜一圈，发现已经有InputValidator.requireNonBlank()做了同样的事。

• Code Quality Agent——设计有没有问题。同一字符串硬编码三遍、两个方法长得几乎一样、一个类既管认证又管发邮件——该拆没拆、该抽象没抽象的地方，它都会指出来。

• Efficiency Agent——跑起来会不会有性能问题。循环里反复创建同一对象，单线程场景非要用ConcurrentHashMap、该用缓存的结果每次都重新算。

第三步，三个Agent各自报告发现，Claude Code自动判断哪些是真问题哪些是误报，然后直接动手改代码。

注意——是直接改。不是给你列个清单让你自己决定。

所以用完/simplify之后，一定要跑 /diff 看它改了什么。

实战：Spring事务失效

有个案例特别经典。写了个用户认证模块，自测通过，习惯性跑了一遍/simplify，找到了6个潜在问题。

最绝的是一个Spring事务失效的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);

    stockService.saveBatch(initialStocks);

}

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

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

三个Agent里有两个独立地从不同角度捕获到同一个Bug——Code Quality Agent标记了自调用导致@Transactional失效，Efficiency Agent排除了锁TTL不足的可能，精准定位事务失效是根因。

/simplify给出的修复方案是把声明式事务换成编程式事务，用TransactionTemplate直接控制事务边界。最终5个文件修改，净减少38行代码，修复6个问题，编译一次通过。

你也可以指定关注方向：

/simplify thread safety

/simplify SQL performance

/simplify exception swallowing

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

什么时候用

• 提交PR前的自审——成本低，收益可能很高

• 重构后的质量检查——确认没有引入新的设计问题

• Code Review的辅助——帮你发现需要领域知识才能识别的问题

什么时候别用：

• 全项目代码审计——它基于git diff工作，只看增量

• 风格统一——那是formatter的活

• 安全审计——需要专业SAST工具

/review：不改代码，只告诉你问题在哪

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

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

怎么用：

/review              
# 审查当前分支

/review 123          
# 审查指定PR

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

三种review怎么选：

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

实战：三个我没想到的问题

写了用户认证模块，自测通过，顺手跑了一遍/review：

Critical——密码重置接口没做速率限制。攻击者可以无限次调用重置接口轰炸用户邮箱。测试环境只有我一个用户，哪来的速率限制需求？但上生产就是漏洞。

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

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

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

/review和/simplify怎么选

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

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

/loop：AI编程的"自动试错引擎"

Claude Code之父认为最强大的两个命令之一。他多次公开推荐。

/loop解决两类烦人的事：

第一类——需要反复做的事。每隔半小时检查有没有新PR需要处理、每天早上跑一遍测试看有没有挂掉的。不难，但总忘。

第二类——需要反复试错的事。修复一个牵扯多个模块的Bug、把整个项目从CommonJS迁移到ESM。一次做不完，中间会出错，出错了要改，改完再验证。

两种工作模式。

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

/loop 30m /review                    
# 每30分钟跑一次代码审查

/loop 1h 
"跑一遍单元测试，看看有没有失败的"
  
# 每小时检查测试

/loop 5m 
"检查GitHub上开放的PR状态"
       
# 每5分钟看PR动态

间隔写法有三种：/loop 30m xxx（间隔在前）、/loop xxx every 2 hours（"every"在后）、/loop xxx（不写间隔，Claude动态选择1分钟~1小时）。

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

不再是定时器，而是"自动试错引擎"。你给目标，它自己规划、执行、验证、修正，循环往复：

/loop 
"修复auth模块里所有失败的单元测试，直到全部通过"

/loop 
"把src/legacy下所有组件迁移到Tailwind CSS，确保页面渲染正常"

/loop 
"实现支付宝支付模块，补上单元测试，确保全部通过"

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

避坑

• Token消耗不低——自主迭代模式指令尽量具体，完成标准要明确

• 只在当前会话有效——关掉终端或退出Claude Code，关闭期间不会执行，也不会补跑

• 加上限——目标一直达不到它会一直跑，在指令里加一句"最多尝试10次"

• 写清停止条件——包括最多尝试次数和验收标准（测试全部通过/CI green/无lint error）

• 7天限制——循环任务创建7天后自动过期，需要更长周期用Cloud或Desktop的定时任务

三种定时方案怎么选

| |
Cloud任务
|
Desktop任务
|
/loop
|
| --- | --- | --- | --- |
|
运行位置
|
Anthropic云端
|
本地机器
|
本地机器
|
|
需要开机吗
|
不需要
|
需要
|
需要
|
|
重启后状态
|
保留
|
保留
|
会话级；7天内未过期的可通过--resume恢复
|
|
访问本地文件
|
不可
|
可
|
可
|
|
最小间隔
|
1小时
|
1分钟
|
1分钟
|

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

/batch：请了一群外包程序员

/batch的本质是多任务并行编排器。

你说一个大需求，Claude先拆解成独立的工作单元（Unit），然后同时启动多个后台Agent，分别处理不同的功能模块。为了防止冲突，每个Agent在独立的Git Worktree里改代码，互不干扰。

/batch 1、移除自选股界面，直接通过分析界面来管理，每一行股票的最右侧展示选项，支持删除和分组。

 2、自选股提取一个组件、K线展示和讨论室都单独提取一个组件出来。

 3、优化提示词管理，例如支持删除和重命名。

 4、历史记录目前支持10条记录，这块的设计优化一下。

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

说人话就是：你请了三个外包程序员为三个不同的房间干活，项目经理发现门锁有问题，亲自去每个房间把代码拷贝出来，最后交到你手里。

避坑

• 适合边界清晰、模块相对独立的大任务；不适合强耦合核心链路一次性大改

• 共享文件（package.json、路由表、公共类型、数据库迁移脚本）容易冲突

• 用前先commit干净工作区

别忽略这些辅助命令

上面四个负责干活，但真正用顺手之后，你还会频繁用到这些：

• /diff——查看代码变更内容，执行/simplify、/batch后必用

• /context——查看上下文占用情况，长任务响应异常时用

• /compact——精简压缩会话上下文，长会话继续操作前用，一定要给明确的保留范围，不要裸跑

• /debug——排查会话本身的问题（MCP连接失败、工具调用被拒绝、命令卡住）

• /permissions——管理工具权限，执行/loop、/batch前提前检查，高风险命令设成ask或deny

真正的高频：命令组合

单个命令各有各的用，但真正顺手之后，你会发现它们可以组合成一个完整工作流：

/context          → 先看上下文是否健康

/permissions      → 检查权限设置

/batch            → 把大需求拆成多个独立任务

/loop             → 处理需要反复验证的复杂任务

/simplify         → 清理冗余代码和技术债

/review           → 做正确性审查

/security-review  → 敏感模块额外跑安全审查

/diff             → 人工确认改动

测试 + 提交PR

先review后simplify——先确保逻辑正确，再清理代码。跑完simplify或batch之后，先看diff再决定要不要继续。跑loop之前，收紧权限、写清停止条件。

这一套走下来，机械操作少了，但关键节点——看计划、看diff、跑测试、做最终review——仍然在你手里。

AI可以自己审自己、自己改自己、自己反复试错直到通过。但最后签字的那个，得是你。

---

以上，觉得有收获，点个赞、在看、转发支持一下；想不错过更新，记得星标⭐。下次见。
搜索公众号:"知悟之旅"关注我看更多