文章目录先理清 Claude Code 的命令体系/simplify代码简化与重构工作机制三步走指定关注方向实战案例Spring 事务失效实战案例指定模块审查适合的场景/review代码审查工作机制怎么用/review、/security-review、/ultrareview 怎么选/review 和 /simplify 怎么选实战案例注意事项/loop定时任务与自主迭代三种调度方案怎么选两种工作模式五个实际场景运行机制细节注意事项/debugClaude Code 自己出问题时先跑它几个容易被忽略的辅助命令别忽略上下文管理/context 和 /compact附录Claude Code 接入国内模型2. 推荐使用 CC Switch3. 验证是否生效4. 接入验证清单说实话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。 BundledSkills捆绑技能——/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 个潜在问题经过确认确实都是实际存在的问题。最值得说的是一个 Spring 事务失效 的问题。三个 Agent 中有两个独立地从不同角度捕获到了同一个 Bug。问题代码是这样的——WatchlistService 里外层方法获取 Redis 分布式锁做 double-check内部调一个 protected 方法执行数据库写入publicvoidinitializeDefaultWatchlist(Long userId){// Redis 分布式锁 double-check幂等// ...doInitializeDefaultWatchlist(userId);// 同一类内部调用// ...}Transactional(rollbackForException.class)protectedvoiddoInitializeDefaultWatchlist(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 失效评为高严重性。 EfficiencyAgent 排除了锁 TTL 不足的可能精准定位事务失效是根因。 Code Reuse Agent确认手写的分布式锁没有可复用替代实现合理。/simplify 给出的修复方案是把声明式事务换成编程式事务用 TransactionTemplate 直接控制事务边界。其他修复方式包括把事务方法移动到另一个 Spring Bean、通过代理对象调用、调整事务边界到外层 public 方法。RequiredArgsConstructorpublicclassWatchlistService{privatefinalTransactionTemplatetransactionTemplate;privatevoiddoInitializeDefaultWatchlist(LonguserId){transactionTemplate.executeWithoutResult(status-{groupService.save(defaultGroup);stockService.saveBatch(initialStocks);});}}这次扫描还发现了另外 5 个问题涵盖代码复用、安全性和效率这次扫描还发现了另外 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 个问题其中有两个高严重性的Bugyear 周期被静默降级为 month。 normalizePeriod 方法里有一个 switchcase “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密码重置接口没做速率限制。 攻击者可以无限次调用重置接口轰炸用户邮箱。这个我自己测试的时候根本想不到——测试环境只有我一个用户哪来的速率限制需求。HighToken 过期时间从配置读取但没兜底。 配置项没设的话过期时间会变成 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 之父认为最强大的两个命令之一他多次分享推荐。/loop 可以帮你定时跑任务也可以帮你反复试错直到把活干完。解决了什么问题日常开发里有两类事特别烦人第一类是需要反复做的事。比如每隔半小时检查一下有没有新的 PR 需要处理、每天早上跑一遍测试看看有没有挂掉的。这些事不难但总忘。 第二类是需要反复试错的事。比如修复一个牵扯多个模块的 Bug把整个项目从 CommonJS 迁移到 ESM。这种任务的特点是一次做不完中间会出错出错了要改改完再验证。/loop 把这两类事都接过去了。三种调度方案怎么选Claude Code 不止 /loop 这一种定时机制它实际上有三套调度方案对比项Cloud 任务Desktop 任务/loop运行位置Anthropic 云端本地机器本地机器需要开机吗不需要需要需要需要打开会话吗不需要不需要需要重启后状态保留保留会话级关闭期间暂停执行7天内未过期的周期性任务可通过 --resume / --continue 恢复访问本地文件不可访问重新克隆可访问可访问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 模式下它自己读报错、自己改、自己重跑测试全程不用你盯着。五个实际场景自动监控 PR 状态。 每 5 分钟拉一次开放的 PR检查有没有冲突、能不能安全合并、生成摘要。/loop 5m “用 gh 命令检查开放 PR 的状态标记有冲突的和可以安全合并的”自动测试看门狗。 定时跑测试发现了失败的测试就尝试修。多人协作的项目里特别实用——别人合进来的代码可能悄悄搞挂了你的模块。/loop 2h “运行测试套件发现失败的就修复”定时同步项目文档。 改了代码忘了改文档这是开发者最常犯的错。每 2 小时让 /loop 扫一遍代码变更自动把改动同步到用户文档里。/loop 2h “检查最近的代码变更更新对应的公开文档”大规模技术迁移。 比如把整个项目从 CommonJS 迁到 ESM几十个文件中间一定会有报错。/loop 能自己处理这些错误一个文件一个文件地改过去。/loop “把项目里所有 CommonJS 的 require/module.exports 改成 ESM 的 import/export确保测试全部通过”批量拉起自动化任务。 可以写一个自定义命令文件把所有定时任务列在里面。项目启动时跑一条命令就能把所有自动化任务一起拉起来。怎么管理任务直接用自然语言跟 Claude 说就行我现在有哪些定时任务停掉那个检查部署的任务底层靠三个工具干活工具干什么CronCreate创建任务接收 cron 表达式、执行指令、是否循环CronList列出运行中的任务展示ID、调度时间、执行指令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。/debugClaude 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。这意味着它们在物理隔离的环境中修改代码互不干扰。使用方法很简单/batch1、移除自选股界面直接通过分析界面来管理每一行股票的最右侧展示选项支持删除和分组。2、自选股提取一个组件、K线展示和讨论室都单独提取一个组件出来。3、优化提示词管理例如支持删除和重命名。4、历史记录目前支持10条记录这块的设计优化一下。Claude 收到后会先给出拆分计划通常 530 个 unit经确认后在隔离 worktree 中并行执行每个单元通常产出独立 PR。每个 Worker 完成后主进程会检查每个单元的改动最终产出多个独立 PR而非合并成一个大的 PR。⚠️ 风险提示/batch 适合边界清晰、模块相对独立的大任务不适合强耦合核心链路一次性大改。共享文件如 package.json、路由表、公共类型、数据库迁移脚本容易冲突。使用前建议先 commit 干净工作区。你可以理解为 你请了三个外包程序员Worker为三个不同的房间干活现在项目经理Main Agent发现那三个房间的门锁有点问题于是他亲自去每个房间把写好的代码拷贝出来最后交到你手里。几个容易被忽略的辅助命令上面几个命令负责干活但真正用顺手之后你还会频繁用到这些辅助命令。命令作用使用场景/diff查看代码变更内容执行 /simplify、/batch 后必用/context查看上下文占用情况长任务响应异常、逻辑混乱时使用/compact精简压缩会话上下文长会话继续操作前使用/debug排查会话相关问题出现 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 负责上下文续命一个更稳的工作流是这样的/context 先看上下文是否健康/permissions 检查权限设置是否合理/batch 把大需求拆成多个独立任务/loop 处理需要反复验证的复杂任务/simplify 清理冗余代码和技术债/review 做正确性审查 涉及登录、支付、权限、上传、Webhook 等敏感模块再跑/security-review/diff 人工确认改动 最后跑测试、提交 PR这一套走下来能显著减少机械操作但关键节点仍要看计划、看 diff、跑测试、做最终 review。附录Claude Code 接入国内模型CClaude Code 强在它的工具链和执行力但 Claude 官方模型太贵加上现在 Claude 太容易封号。我们可以使用国内的 MiniMax 或 GLM 作为它的底层大模型。它们都采用了标准的 OpenAI 兼容接口接入过程非常丝滑。获取 API KeyMiniMax 开放平台https://platform.minimaxi.com/user-center/basic-information/interface-keyGLM 开放平台https://www.bigmodel.cn/usercenter/proj-mgmt/apikeys2. 推荐使用 CC Switch强烈推荐安装 CC Switch这是一个专门管理 Claude Code 模型切换的小工具支持管理 Skills、MCP 和提示词。项目地址https://github.com/farion1231/cc-switch启动 CC Switch点击右上角 “” 选择预设的 MiniMax/GLM 供应商填写 API Key选择模型添加即可。3. 验证是否生效在任意目录下输入 claude 命令即可启动 Claude Code选择 信任此文件夹 (Trust This Folder)。4. 接入验证清单MiniMax / GLM 接入不是能对话就算成功Claude Code 的关键是工具调用。建议验证以下核心功能是否能稳定 stream 输出 是否能调用 Bash/Read/Edit/Write 是否能跑 subagent 是否能处理长上下文和压缩 是否支持 MCP 工具调用 是否能完成真实项目的「改代码 → 跑测试 → 修复」闭环
【AI编码】----Claude Code 核心命令详解：simplify、review、loop、batch
文章目录先理清 Claude Code 的命令体系/simplify代码简化与重构工作机制三步走指定关注方向实战案例Spring 事务失效实战案例指定模块审查适合的场景/review代码审查工作机制怎么用/review、/security-review、/ultrareview 怎么选/review 和 /simplify 怎么选实战案例注意事项/loop定时任务与自主迭代三种调度方案怎么选两种工作模式五个实际场景运行机制细节注意事项/debugClaude Code 自己出问题时先跑它几个容易被忽略的辅助命令别忽略上下文管理/context 和 /compact附录Claude Code 接入国内模型2. 推荐使用 CC Switch3. 验证是否生效4. 接入验证清单说实话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。 BundledSkills捆绑技能——/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 个潜在问题经过确认确实都是实际存在的问题。最值得说的是一个 Spring 事务失效 的问题。三个 Agent 中有两个独立地从不同角度捕获到了同一个 Bug。问题代码是这样的——WatchlistService 里外层方法获取 Redis 分布式锁做 double-check内部调一个 protected 方法执行数据库写入publicvoidinitializeDefaultWatchlist(Long userId){// Redis 分布式锁 double-check幂等// ...doInitializeDefaultWatchlist(userId);// 同一类内部调用// ...}Transactional(rollbackForException.class)protectedvoiddoInitializeDefaultWatchlist(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 失效评为高严重性。 EfficiencyAgent 排除了锁 TTL 不足的可能精准定位事务失效是根因。 Code Reuse Agent确认手写的分布式锁没有可复用替代实现合理。/simplify 给出的修复方案是把声明式事务换成编程式事务用 TransactionTemplate 直接控制事务边界。其他修复方式包括把事务方法移动到另一个 Spring Bean、通过代理对象调用、调整事务边界到外层 public 方法。RequiredArgsConstructorpublicclassWatchlistService{privatefinalTransactionTemplatetransactionTemplate;privatevoiddoInitializeDefaultWatchlist(LonguserId){transactionTemplate.executeWithoutResult(status-{groupService.save(defaultGroup);stockService.saveBatch(initialStocks);});}}这次扫描还发现了另外 5 个问题涵盖代码复用、安全性和效率这次扫描还发现了另外 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 个问题其中有两个高严重性的Bugyear 周期被静默降级为 month。 normalizePeriod 方法里有一个 switchcase “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密码重置接口没做速率限制。 攻击者可以无限次调用重置接口轰炸用户邮箱。这个我自己测试的时候根本想不到——测试环境只有我一个用户哪来的速率限制需求。HighToken 过期时间从配置读取但没兜底。 配置项没设的话过期时间会变成 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 之父认为最强大的两个命令之一他多次分享推荐。/loop 可以帮你定时跑任务也可以帮你反复试错直到把活干完。解决了什么问题日常开发里有两类事特别烦人第一类是需要反复做的事。比如每隔半小时检查一下有没有新的 PR 需要处理、每天早上跑一遍测试看看有没有挂掉的。这些事不难但总忘。 第二类是需要反复试错的事。比如修复一个牵扯多个模块的 Bug把整个项目从 CommonJS 迁移到 ESM。这种任务的特点是一次做不完中间会出错出错了要改改完再验证。/loop 把这两类事都接过去了。三种调度方案怎么选Claude Code 不止 /loop 这一种定时机制它实际上有三套调度方案对比项Cloud 任务Desktop 任务/loop运行位置Anthropic 云端本地机器本地机器需要开机吗不需要需要需要需要打开会话吗不需要不需要需要重启后状态保留保留会话级关闭期间暂停执行7天内未过期的周期性任务可通过 --resume / --continue 恢复访问本地文件不可访问重新克隆可访问可访问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 模式下它自己读报错、自己改、自己重跑测试全程不用你盯着。五个实际场景自动监控 PR 状态。 每 5 分钟拉一次开放的 PR检查有没有冲突、能不能安全合并、生成摘要。/loop 5m “用 gh 命令检查开放 PR 的状态标记有冲突的和可以安全合并的”自动测试看门狗。 定时跑测试发现了失败的测试就尝试修。多人协作的项目里特别实用——别人合进来的代码可能悄悄搞挂了你的模块。/loop 2h “运行测试套件发现失败的就修复”定时同步项目文档。 改了代码忘了改文档这是开发者最常犯的错。每 2 小时让 /loop 扫一遍代码变更自动把改动同步到用户文档里。/loop 2h “检查最近的代码变更更新对应的公开文档”大规模技术迁移。 比如把整个项目从 CommonJS 迁到 ESM几十个文件中间一定会有报错。/loop 能自己处理这些错误一个文件一个文件地改过去。/loop “把项目里所有 CommonJS 的 require/module.exports 改成 ESM 的 import/export确保测试全部通过”批量拉起自动化任务。 可以写一个自定义命令文件把所有定时任务列在里面。项目启动时跑一条命令就能把所有自动化任务一起拉起来。怎么管理任务直接用自然语言跟 Claude 说就行我现在有哪些定时任务停掉那个检查部署的任务底层靠三个工具干活工具干什么CronCreate创建任务接收 cron 表达式、执行指令、是否循环CronList列出运行中的任务展示ID、调度时间、执行指令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。/debugClaude 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。这意味着它们在物理隔离的环境中修改代码互不干扰。使用方法很简单/batch1、移除自选股界面直接通过分析界面来管理每一行股票的最右侧展示选项支持删除和分组。2、自选股提取一个组件、K线展示和讨论室都单独提取一个组件出来。3、优化提示词管理例如支持删除和重命名。4、历史记录目前支持10条记录这块的设计优化一下。Claude 收到后会先给出拆分计划通常 530 个 unit经确认后在隔离 worktree 中并行执行每个单元通常产出独立 PR。每个 Worker 完成后主进程会检查每个单元的改动最终产出多个独立 PR而非合并成一个大的 PR。⚠️ 风险提示/batch 适合边界清晰、模块相对独立的大任务不适合强耦合核心链路一次性大改。共享文件如 package.json、路由表、公共类型、数据库迁移脚本容易冲突。使用前建议先 commit 干净工作区。你可以理解为 你请了三个外包程序员Worker为三个不同的房间干活现在项目经理Main Agent发现那三个房间的门锁有点问题于是他亲自去每个房间把写好的代码拷贝出来最后交到你手里。几个容易被忽略的辅助命令上面几个命令负责干活但真正用顺手之后你还会频繁用到这些辅助命令。命令作用使用场景/diff查看代码变更内容执行 /simplify、/batch 后必用/context查看上下文占用情况长任务响应异常、逻辑混乱时使用/compact精简压缩会话上下文长会话继续操作前使用/debug排查会话相关问题出现 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 负责上下文续命一个更稳的工作流是这样的/context 先看上下文是否健康/permissions 检查权限设置是否合理/batch 把大需求拆成多个独立任务/loop 处理需要反复验证的复杂任务/simplify 清理冗余代码和技术债/review 做正确性审查 涉及登录、支付、权限、上传、Webhook 等敏感模块再跑/security-review/diff 人工确认改动 最后跑测试、提交 PR这一套走下来能显著减少机械操作但关键节点仍要看计划、看 diff、跑测试、做最终 review。附录Claude Code 接入国内模型CClaude Code 强在它的工具链和执行力但 Claude 官方模型太贵加上现在 Claude 太容易封号。我们可以使用国内的 MiniMax 或 GLM 作为它的底层大模型。它们都采用了标准的 OpenAI 兼容接口接入过程非常丝滑。获取 API KeyMiniMax 开放平台https://platform.minimaxi.com/user-center/basic-information/interface-keyGLM 开放平台https://www.bigmodel.cn/usercenter/proj-mgmt/apikeys2. 推荐使用 CC Switch强烈推荐安装 CC Switch这是一个专门管理 Claude Code 模型切换的小工具支持管理 Skills、MCP 和提示词。项目地址https://github.com/farion1231/cc-switch启动 CC Switch点击右上角 “” 选择预设的 MiniMax/GLM 供应商填写 API Key选择模型添加即可。3. 验证是否生效在任意目录下输入 claude 命令即可启动 Claude Code选择 信任此文件夹 (Trust This Folder)。4. 接入验证清单MiniMax / GLM 接入不是能对话就算成功Claude Code 的关键是工具调用。建议验证以下核心功能是否能稳定 stream 输出 是否能调用 Bash/Read/Edit/Write 是否能跑 subagent 是否能处理长上下文和压缩 是否支持 MCP 工具调用 是否能完成真实项目的「改代码 → 跑测试 → 修复」闭环
