---
name: simplify
description: 审查变更代码中的重用、简化、效率和高层次问题，然后应用修复。
---

`/simplify → 4 个清理代理并行 → 应用修复`

你正在提升已变更代码的质量，而非寻找 bug。审查其重用、简化、效率和高层次问题，然后修复你发现的问题。不要寻找正确性 bug——那是 `/code-review` 的任务。

## 阶段 0 — 收集差异

运行 `git diff @{upstream}...HEAD`（或 `git diff main...HEAD` / `git diff HEAD~1` 如果没有上游）以获取待审查的统一差异。如果有未提交的更改，或者范围差异为空，也运行 `git diff HEAD` 并将工作树变更纳入范围——审查通常在提交前运行。如果传入了 PR 编号、分支名称或文件路径作为参数，改为审查该目标。将此差异视为审查范围。

## 阶段 1 — 审查（4 个清理代理并行）

通过 Agent 工具启动 **4 个独立的审查代理**，全部在单个消息中以便它们并发运行。将差异和以下四个角度之一传递给每个代理。每个代理返回其发现，包含 `file`、`line`、单行 `summary` 以及具体成本（什么被重复、浪费或更难维护）。

### 重用

标记重新实现了代码库中已有功能的新代码——在共享/实用模块和与变更相邻的文件中搜索，并指出应改为调用的现有辅助函数。

### 简化

标记差异增加的不必要复杂性：冗余或可推导的状态、带有轻微变化的复制粘贴、深层嵌套、遗留的死代码。指出做相同工作的更简单形式。

### 效率

标记差异引入的浪费工作：冗余计算或重复 I/O、顺序运行的独立操作、添加到启动或热路径上的阻塞工作。指出更便宜的替代方案。

### 高层次

检查每个变更是否在正确的深度实现，而不是作为一个脆弱的创可贴。在共享基础设施上叠加特殊情况是修复不够深入的信号——优先泛化底层机制，而非添加特殊情况。

## 阶段 2 — 应用修复

等待所有四个代理完成，对指向相同行或机制的发现进行去重，然后直接修复每个剩余的发现。跳过任何其修复会改变预期行为、需要远超已审查差异范围的更改或被判断为误报的发现——注明跳过而不是争辩。以简要总结作结：已修复的内容和被跳过的内容（或确认代码已经干净）。
