面试官：“简历写着熟练使用 Claude Code，连 simplify 代码审查命令都不知道!”，我：“那又如何呢？”

说实话，Claude Code 里有个命令我用了一次就离不开了，但问了身边好几个同样在用 Claude Code 的朋友，竟然没一个人知道。它就是 /simplify。

这个命令做的事情很简单：审查你刚写的代码/指定的代码，找出隐藏的问题，然后直接帮你改掉。

下面聊聊它到底怎么做到的，以及我拿它在实际项目里发现了哪些真实的 Bug。

/simplify 命令是什么

先理清一个容易混淆的概念。Claude Code 里 / 开头的东西，来源有两层：

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

/simplify 的前身是 code-simplifier ，最早由 Anthropic 团队在 2026 年 1 月左右开源，放在官方插件仓库 anthropics/claude-plugins-official 里供开发者手动安装。当时的版本侧重单文件重构和清理。

2026 年 2 月底，Claude Code v2.1.63 正式把 code-simplifier 收编为内建 Bundled Skill，改名为 /simplify，同时做了三件事：引入三 Agent 并行审查机制（Code Quality + Efficiency + CLAUDE.md 合规性）、支持跨多文件的项目级上下文理解、变成开箱即用——安装 Claude Code 后直接可用，零配置。

简单说就是：

阶段	名称	形式	核心特点
2026 年 1 月	code-simplifier	官方开源插件	需手动安装，侧重单文件重构与清理
2026 年 2 月（v2.1.63）	/simplify	内建 Bundled Skill	三 Agent 并行审查、跨文件上下文感知、开箱即用

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

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

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

还可以指定具体的类或者模块：

/simplify MarketDataService

在你想要优化特定类或者模块的时候，这个功能很实用。

/simplify 的审查机制

/simplify 的工作分三步走。

第一步：确定审查范围。/simplify 有两种工作模式。不带参数时，它跑 git diff 拿增量变更；如果工作区没有未提交的修改，它会自动审查最近一次 commit。指定具体类名时（比如 /simplify MarketDataService），它会读取整个文件做全量审查——不看 diff，只看完整代码。

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

三个 Agent 各管一摊：

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

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

这三个 Agent 是并行执行的，各自独立搜索代码库。这意味着同一个问题可能被多个 Agent 从不同角度捕获——后面的案例会看到。

/simplify 命令实战

如果你还不知道如何使用 Claude Code ，可以参考文末的 Claude Code 接入 MiniMax/GLM 的详细教程。

实战一：提交前自审，发现隐藏的事务 Bug

昨天晚上给项目做了一次代码质量清理，26 个文件、新增 443 行——DTO 类从 Controller 里拆出来了，线程池的 magic number 换成了常量，异常处理器加了日志脱敏，自选股初始化加了分布式锁。全部改完之后自我感觉良好：代码规范、逻辑清晰、注释完整。准备提交。

习惯性地先跑了一遍 /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 基于动态代理，同一个类内部的直接调用（this.doInitializeDefaultWatchlist()）会绕过代理，注解根本不会被拦截到。

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

• Code Quality Agent 标记了自调用导致 @Transactional 失效（protected 访问级别进一步印证该方法仅被内部调用），评为高严重性。
• Efficiency Agent 排除了锁 TTL 不足的可能，精准定位事务失效是根因。
• Code Reuse Agent 确认手写的分布式锁没有可复用替代，实现合理。

/simplify 给出的修复方案是把声明式事务换成编程式事务，用 TransactionTemplate 直接控制事务边界：

@RequiredArgsConstructor
public class WatchlistService {

    private final TransactionTemplate transactionTemplate;

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

TransactionTemplate 直接通过 PlatformTransactionManager 管理事务，和 AOP 代理无关，无论怎么调用都能正确生效。

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

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

开启优化

所有修改完成

实战二：指定模块审查，发现隐藏的数据 Bug

/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 线，没有任何报错或提示。Code Quality Agent 直接标记为高严重性。

冗余熔断器：本地 dataSourceStates 和 healthService 完全重复。 这个类内部维护了一套自己的熔断器（3 次失败后冷却 30 秒），同时又注入了 DataSourceHealthService 做同样的事（3 次失败后冷却 60 秒）。每次数据源调用都同时更新两套状态，但两套冷却时间不同，可能导致一个认为数据源已恢复、另一个还认为在冷却。三个 Agent 都独立报告了这个问题。

修复结果：

• 修正 year → "year" 的映射（1 行）
• 移除整个本地熔断器（删除 dataSourceStates 字段、DataSourceState 内部类、三个方法、两个常量、两个 import）
• 预编译 normalizeStockCode 中的 5 个正则表达式为 static final Pattern

另外还有 5 个中等/低等问题（fetch 方法 copy-paste、enrichValuation 应只调一次等）被记录为架构改进项，未在此次修复。

两次实战的感受

/simplify 最大的价值不在于找语法错误——那是 linter 的活。它的杀手锏是能发现需要领域知识才能识别的问题。比如事务失效那个 Bug，代码能编译、能运行、功能看起来正常，只有在特定异常场景下（saveBatch 中途失败）才会暴露数据不一致。这种问题在人工 Code Review 中也很容易被忽略。

不过它也有局限——架构级重构（比如把 570 行的 MarketDataService 拆成三个子服务）它只会建议，不会主动执行。这类改动需要你自己做设计决策。事实上，审查完之后我手动把 MarketDataService 拆成了 QuoteService、KLineService、StockSearchService 三个子服务，并抽取了公共的 StockCodeNormalizer 工具类。

/simplify 适合什么场景

经历了这次实战，我对 /simplify 的定位有了更清晰的认识。

适合的场景：

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

不太适合的场景：

• 全项目代码审计。不带参数时 /simplify 基于 git diff 工作，只审查增量变更；指定类名时可以审查单个文件的全量代码。但它做不了“对整个项目所有文件做全量扫描”，想给整个项目做代码质量体检，得换个思路。
• 风格统一。它不关心你的花括号放在哪一行，也不关心用 tab 还是空格。那是 formatter 和 linter 的活。
• 安全审计。虽然它发现了 regex 脱敏的盲区，但这不是它的核心能力。专业的安全审查需要 SAST 工具。

与传统工具的核心差异： SonarQube、Checkstyle 这类工具基于规则匹配——它们能发现“这个方法超过 80 行”或“这里有空指针风险”，但无法判断“类内部自调用时 @Transactional 是否还能生效”。/simplify 的优势在于它能理解框架语义：它知道 Spring 的代理是怎么工作的，知道 TransactionTemplate 和 @Transactional 的区别，知道 Caffeine 已经在项目的依赖里了。

/simplify 实践建议

最近用下来，有几个让 /simplify 效果更好的小技巧分享一下：

1. 提交粒度要合适。 如果你一次性提交 50 个文件，diff 会很大，Agent 需要在大量变更中定位问题。比较理想的方式是按功能模块拆分提交，每次 10-20 个文件以内。
2. 刚重构完马上用。 重构是最容易引入微妙 Bug 的时候——你移动了代码、改了调用关系、拆了方法。重构完立即跑 /simplify，趁上下文还新鲜，效果最好。
3. 关注 High severity 的发现。 三个 Agent 会给出不同严重级别的标记。Medium 和 Low 的建议可以酌情忽略，但 High 级别的发现（像这次的事务失效）建议逐个确认。
4. 不要盲信，但要认真看。 Agent 偶尔会报误报。比如这次它说 @Bean 方法里的 ConcurrentHashMap 不必要——确实如此，但影响微乎其微。关键是它同时也找到了真正的 Bug。把 /simplify 当成一个知识面很广、但偶尔会多虑的 Reviewer，而不是一个全自动的修复工具。

附录：Claude Code 接入 MiniMax/GLM

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

如果你本机没有安装 Claude Code 的话，只需要运行下面这行命令安装即可（Node.js 18+）：

npm install -g @anthropic-ai/claude-code

1. 获取 API Key

• MiniMax 开放平台获取 Key：https://platform.minimaxi.com/user-center/basic-information/interface-key
• GLM 开放平台获取 Key：https://www.bigmodel.cn/usercenter/proj-mgmt/apikeys

MimiMax Key 获取

GLM Key 获取

2. 神器推荐

强烈推荐安装 CC Switch，这是一个专门管理 Claude Code 模型切换的小工具，能让你在不同 Provider 之间一键横跳。并且，还支持管理 Skills、MCP 和提示词。

启动 CC Switch，点击右上角 "+" ，选择预设的 MiniMax/GLM 供应商，并填写你的 MiniMax/GLM API Key。

CC Switch 配置 MiniMax/GLM API Key

将模型名称全部改为 MiniMax/GLM，完成后点击右下角的 “添加”。

CC Switch 配置模型

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

3. 测试是否生效

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

验证是否生效