
关于
审查差异以提高清晰度和安全简化,然后可选地应用低风险修复。
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 命令
按以下优先顺序选择范围:
- 用户明确指定的文件或路径
- 当前 git 变更
- 当前 Codex 轮次中早期编辑的文件
- 最近修改的跟踪文件,仅当用户要求审查但没有 diff 时
如果没有明确范围,简要说明并停止。
使用 git 变更时,根据仓库状态确定最小正确的 diff 命令:
- 未暂存的工作:
git diff - 已暂存的工作:
git diff --cached - 用户明确请求的分支或提交比较:使用该确切 diff 目标
- 混合暂存和未暂存的工作:两者都审查
当有更小的 diff 可用时,不要假设 git diff HEAD 是正确的默认值。
在审查标准或应用修复之前,阅读仓库的本地指令文件和相关项目文档。优先使用最接近的适用指导,例如:
AGENTS.md- 仓库工作流文档
- 涉及模块的架构或风格文档
使用这些指令来区分真正的问题和有意的本地模式。
步骤 2:并行启动四个审查子代理
当范围足够大时使用 Codex 子代理进行并行审查。对于微小的 diff 或一个很小的文件,可以在本地审查。
启动子代理时:
- 给每个子代理相同的范围
- 告诉每个子代理只检查其分配的审查角色
- 要求简洁、结构化的发现
- 要求每个子代理报告文件、行或符号、问题、推荐修复和置信度
使用四个审查角色。
子代理 1:代码复用审查
审查变更中的复用机会:
- 搜索已存在的辅助函数、工具或共享抽象,它们已经解决了相同的问题。
- 标记变更中引入的重复函数或近似重复逻辑。
- 标记应该调用现有辅助函数而不是重新实现的内联逻辑。
子代理 2:代码质量审查
审查相同变更的代码质量问题:
- 冗余状态、缓存值或不必要存储的派生值
- 通过现有调用链传递新参数导致的参数膨胀
- 应该成为共享抽象的略有变化的复制粘贴
- 跨模块边界的抽象泄漏或所有权违规
- 已存在类型化契约、枚举或常量时使用字符串类型的值
子代理 3:效率审查
审查相同变更的效率问题:
- 重复工作、重复读取、重复 API 调用或不必要的重新计算
- 可以安全并发运行的顺序工作
- 在启动、渲染、请求或其他热路径中添加的新工作,没有明确需要
- 当操作本身可以直接尝试并处理错误时的存在性预检查
- 内存增长、缺失清理或监听器/订阅泄漏
- 代码只需要子集时的过于宽泛的读取或扫描
子代理 4:清晰度和标准审查
审查相同变更的清晰度、本地标准和平衡:
- 违反本地项目约定或模块模式
- 不必要的复杂性、深层嵌套、弱命名或冗余注释
- 过于紧凑或巧妙的代码降低了可读性
- 将不同关注点合并为一个不清晰单元的过度简化
- 死代码、死抽象或无价值的间接层
只报告实质性改善可维护性、正确性或成本的问题。不要仅仅为了让代码看起来不同而进行变更。
步骤 3:汇总发现
等待所有审查子代理完成,然后合并它们的发现。
将发现规范化为以下格式:
- 文件和行号
- 问题类别(复用/质量/效率/清晰度)
- 问题描述
- 推荐修复
- 置信度(高/中/低)
去重并按置信度和影响排序。
兼容工具
Claude CodeCursor
标签
AI与机器学习