---

name: simplify-code description: "审查 diff 的清晰度和安全简化，然后可选地应用低风险修复。" risk: safe source: "Dimillian/Skills (MIT)" date_added: "2026-03-25"

简化代码

审查变更代码的复用性、质量、效率和清晰度问题。使用 Codex 子代理并行审查，然后可选地仅应用高置信度、保持行为不变的修复。

适用场景

• 当用户要求简化、清理、重构或审查变更代码时。
• 当你需要对有范围的 diff 进行高置信度、保持行为不变的改进时。

模式

根据用户请求选择模式：

• review-only：用户要求审查、审计或检查变更
• safe-fixes：用户要求简化、清理或重构变更
• fix-and-validate：与 safe-fixes 相同，但在编辑后还会运行最小相关验证

如果用户未指定，默认为：

• review-only 用于"审查"、"审计"或"检查"
• safe-fixes 用于"简化"、"清理"或"重构"

步骤 1：确定范围和 Diff 命令

按以下优先顺序选择范围：

1. 用户明确指定的文件或路径
2. 当前 git 变更
3. 当前 Codex 轮次中早期编辑的文件
4. 最近修改的跟踪文件，仅当用户要求审查但没有 diff 时

如果没有明确范围，简要说明并停止。

使用 git 变更时，根据仓库状态确定最小正确的 diff 命令：

• 未暂存的工作：git diff
• 已暂存的工作：git diff --cached
• 用户明确请求的分支或提交比较：使用该确切 diff 目标
• 混合暂存和未暂存的工作：两者都审查

当有更小的 diff 可用时，不要假设 git diff HEAD 是正确的默认值。

在审查标准或应用修复之前，阅读仓库的本地指令文件和相关项目文档。优先使用最接近的适用指导，例如：

• AGENTS.md
• 仓库工作流文档
• 涉及模块的架构或风格文档

使用这些指令来区分真正的问题和有意的本地模式。

步骤 2：并行启动四个审查子代理

当范围足够大时使用 Codex 子代理进行并行审查。对于微小的 diff 或一个很小的文件，可以在本地审查。

启动子代理时：

• 给每个子代理相同的范围
• 告诉每个子代理只检查其分配的审查角色
• 要求简洁、结构化的发现
• 要求每个子代理报告文件、行或符号、问题、推荐修复和置信度

使用四个审查角色。

子代理 1：代码复用审查

审查变更中的复用机会：

1. 搜索已存在的辅助函数、工具或共享抽象，它们已经解决了相同的问题。
2. 标记变更中引入的重复函数或近似重复逻辑。
3. 标记应该调用现有辅助函数而不是重新实现的内联逻辑。

子代理 2：代码质量审查

审查相同变更的代码质量问题：

1. 冗余状态、缓存值或不必要存储的派生值
2. 通过现有调用链传递新参数导致的参数膨胀
3. 应该成为共享抽象的略有变化的复制粘贴
4. 跨模块边界的抽象泄漏或所有权违规
5. 已存在类型化契约、枚举或常量时使用字符串类型的值

子代理 3：效率审查

审查相同变更的效率问题：

1. 重复工作、重复读取、重复 API 调用或不必要的重新计算
2. 可以安全并发运行的顺序工作
3. 在启动、渲染、请求或其他热路径中添加的新工作，没有明确需要
4. 当操作本身可以直接尝试并处理错误时的存在性预检查
5. 内存增长、缺失清理或监听器/订阅泄漏
6. 代码只需要子集时的过于宽泛的读取或扫描

子代理 4：清晰度和标准审查

审查相同变更的清晰度、本地标准和平衡：

1. 违反本地项目约定或模块模式
2. 不必要的复杂性、深层嵌套、弱命名或冗余注释
3. 过于紧凑或巧妙的代码降低了可读性
4. 将不同关注点合并为一个不清晰单元的过度简化
5. 死代码、死抽象或无价值的间接层

只报告实质性改善可维护性、正确性或成本的问题。不要仅仅为了让代码看起来不同而进行变更。

步骤 3：汇总发现

等待所有审查子代理完成，然后合并它们的发现。

将发现规范化为以下格式：

1. 文件和行号
2. 问题类别（复用/质量/效率/清晰度）
3. 问题描述
4. 推荐修复
5. 置信度（高/中/低）

去重并按置信度和影响排序。