写完一个功能之后，很多人的流程差不多是：跑一遍测试 → 自己扫一眼代码 → 开 PR → 等同事挑出「这里重复了」「这个循环里不该读配置」一类问题 → 再改 → 再等。这类反馈里有一半是机械性的代码卫生问题，不是设计分歧，却仍然占掉半天。
Claude Code 自带的三个命令专门挡在这个环节前面：/simplify、/code-review --fix、/batch。不需要装额外 Skill 或插件，装好 Claude Code 就能用。下面按日常用法讲清楚它们各自干什么、怎么串起来，以及和 CLAUDE.md 怎么配合。
/simplify：写完功能后的一键清洁
/simplify 是后置清理命令：功能能跑了，但你知道里面还有重复逻辑、可读性差的地方或效率不高的写法，直接输入 /simplify，剩下交给它。
它会先用 git 差异找出最近改过的文件，再并行启动三个审查 Agent，分别盯：
| Agent | 方向 | 具体看什么 |
|---|---|---|
| 代码复用 | 重复逻辑 | 已有工具函数没用上、多处手写类似逻辑、能用现有抽象替换的地方 |
| 代码质量 | 可读性 / 结构 | 冗余状态、参数过多、复制粘贴后只改了一点点、该用常量的地方写了字面量 |
| 执行效率 | 性能 / 资源 | 循环里的重操作、该并发却串行、整文件读取却只用一小段、明显的资源浪费 |
三个 Agent 跑完后汇总，自动修掉有效问题、跳过误报，最后给你一份短摘要；如果代码已经够干净，它也会直说没什么可改。整个过程不用另写 prompt。
官方帮助中心也把「改完代码后追加 /simplify」写成了 power user 习惯：并行审查复用、质量、效率，以及是否符合 CLAUDE.md。
/code-review --fix：同一套审查，多一点控制权
较新的 /simplify 底层会走到 /code-review --fix。你也可以直接用后者：效果接近，但参数更完整。
/code-review 是 Claude Code 的代码审查流水线：多个专门 Agent 并行看不同类别的问题，再经过一轮对照实际代码行为的验证，减少误报。加上 --fix 后，不只报告，还会把修复写进工作区（仍走你当前的权限模式）。本地还可以指定 diff、分支或路径；需要在 GitHub PR / GitLab MR 上留言时，用 --comment 一类参数（以本地审查文档为准）。
严重程度大致分三档：
- Important：合并前应修的问题
- Nit：值得修但不阻塞
- Pre-existing：仓库里本来就有的问题，不是这次引入的
加了 --fix 后，Important 和 Nit 会被直接改；Pre-existing 通常只报告不动手。
/code-review --fix
上面这条和单独跑 /simplify 在「审查最近改动并自动修」这件事上高度重叠；差别在于 /code-review 还能接 PR 评论、指定范围等场景，而 /simplify 更像固定好的一键入口。
/batch：跨仓库规模的批量重构
/simplify 只看你最近改的文件。如果要对整库做同一种修改——比如把几十个 React class 组件迁到 hooks，或统一所有 API 错误响应格式——就用 /batch。
用法示例：
/batch 把项目里所有 React class 组件转成 functional component 和 hooks
流程分三段：
- 调研和规划。 进入 plan mode，探索 Agent 摸清涉及哪些文件和模式，把工作拆成大约 5 到 30 个彼此独立的单元，每个单元可以单独实现、单独合并。计划会先给你确认。
- 并行执行。 批准后，每个单元起一个独立 Agent，各自在隔离的 git worktree 里干活（独立分支与工作目录）。做完后会自动再跑一遍
/simplify，再测、提交、推送、开 PR。 - 追踪进度。 状态表实时更新，最后类似「22/24 个单元已经开好 PR」。
为什么必须是 git 仓库
/batch 的可靠性来自 worktree 隔离：某个单元翻车，其他单元不受影响。成功的 PR 可以合，失败的可以丢。因此项目必须是 git 仓库，不是可选项。
适合用 /batch 的场景：框架迁移、API 格式统一、命名规范批量落地、依赖替换、给未覆盖模块补测试。不适合：强耦合改动（A 必须先于 B）、方向还没定的探索性重构、只改一两个文件的小活。
三个命令怎么配合
| 维度 | /simplify | /code-review --fix | /batch |
|---|---|---|---|
| 作用范围 | 最近改动 | 最近改动（可指定范围） | 整个代码库 |
| 使用时机 | 功能写完后 | 功能写完后 / PR 前 | 大规模迁移前 |
| Agent 数量 | 约 3 个并行审查 | 多个并行审查 | 约 5–30 个并行实现 |
| 输出 | 直接改工作区 | 直接改工作区 | 每个单元一个 PR |
| 是否需要确认计划 | 否 | 否 | 是 |
典型工作流：
- 写完功能 →
/simplify→ 开 PR - 发现整库某类格式不统一 →
/batch→ 每个 Worker 做完自动再/simplify→ 逐个 merge
内嵌关系也值得记住：/simplify 会走到 /code-review --fix 这一路；/batch 的每个 Worker 完成后也会自动再跑 /simplify，不用你手动串。
和 CLAUDE.md、REVIEW.md 一起用
审查系统会读项目里的 CLAUDE.md，以及专门约束审查行为的 REVIEW.md（若存在）。你在规范里写清「API 必须有集成测试」「错误响应统一成某种结构」「controller 不得直连数据库」之类规则后，/simplify 发现违规会按 Nit 或更高优先级标出并尽量修。
REVIEW.md 适合写「哪些目录跳过」「Important 怎么划界」「一次最多报多少 Nit」；它通常比 CLAUDE.md 更偏审查策略。项目级规则怎么落到 .claude 目录，可以对照站内这篇：Claude Code 的 .claude 文件夹怎么配。
几个实际场景
日常功能开发。 刚写完注册流程（四个文件），开 PR 前跑一次 /simplify。常见结果是：token 校验在两个文件里写了两遍并被抽到公共模块；循环内重复读配置被挪到循环外；过宽的异常捕获被收窄。git diff 确认后开 PR。
重构前摸底。 对老项目先做一处无意义的小改动，再让 /simplify 扩大关注范围，拿一份代码健康度快照，再决定要不要上 /batch。
批量迁移。 例如把 src/components/ 下 Options API 迁到 Composition API，并在提示里写明「迁移后跑测试」。它会先出计划，确认后并行执行，每个单元自带审查与测试门槛。
写在最后
这三个命令覆盖了从「写完一个功能」到「重构半个仓库」的常见光谱：/simplify 像随手可用的自动审查员，/batch 像临时拉起的迁移小队，都是 Claude Code 自带能力，不额外收费配置。
若你还在每次开 PR 前纯靠肉眼扫代码卫生，或面对几十个同质文件发愁，先从 /simplify 试起；大迁移再上 /batch。想把审查和权限护栏一起收紧，也可以再看 AI 编程工具的沙箱不是完整安全边界。
官方入口：Commands 一览、Code Review、本地 /code-review。
如果你在用 AIGoCode 给 Claude Code 配模型线路，写完功能后养成 /simplify 再开 PR 的习惯，往往比单纯换更强模型更能少一轮来回修改。