⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 mp.weixin.qq.com/s?__biz=Mzg2OTA0Njk0OA==&mid=2247553629&idx=1&sn=e30d8188b174d3ad5302eb07ff8abae0&poc_token=HIcf_GmjaFT3iaU4AEUhQsQGLc8CQQ2TYVAddduu 「null」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

说实话，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 效果更好的小技巧分享一下：

提交粒度要合适。 如果你一次性提交 50 个文件，diff 会很大，Agent 需要在大量变更中定位问题。比较理想的方式是按功能模块拆分提交，每次 10-20 个文件以内。
刚重构完马上用。 重构是最容易引入微妙 Bug 的时候——你移动了代码、改了调用关系、拆了方法。重构完立即跑 /simplify，趁上下文还新鲜，效果最好。
关注 High severity 的发现。 三个 Agent 会给出不同严重级别的标记。Medium 和 Low 的建议可以酌情忽略，但 High 级别的发现（像这次的事务失效）建议逐个确认。
不要盲信，但要认真看。 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)。

验证是否生效

芋道源码 —— 纯源码解析博客

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