name: simplify-code description: “Parallel 4-agent cleanup of recent code changes.” version: 1.1.0 author: Hermes Agent (inspired by Claude Code /simplify) license: MIT platforms: [linux, macos, windows] metadata: hermes: tags: [code-review, cleanup, refactor, delegation, subagent, parallel, simplify] related_skills: [requesting-code-review, test-driven-development]

简化代码——并行审查与优化

让四名专注的审查者同时并行处理您最近的代码更改，汇总他们的发现，并应用那些确实需要修复的问题。

这属于代码优化环节，而非错误排查。 您的任务是提升现有代码的质量——消除重复代码、简化不必要的复杂性、去除冗余内容，并深化临时性修复措施。请勿在此处寻找逻辑错误，那应该是使用 requesting-code-review 功能来处理的事。

核心原则： 四名专注的审查者胜过一名范围宽泛的审查者。每位审查者都会深入代码库，专门针对某一类问题进行排查——如代码复用性、质量、效率等——而不会分散精力去处理其他所有问题。由于他们同时运行，您只需承担一次审查的延迟，而非四次。

适用场景

当用户说出以下任意语句时，即可触发此功能：

• “简化” / “简化我的更改” / “简化这些更改”
• “审查我的代码” / “审查我最近的更改” / “优化我的更改”
• “/simplify”（如果用户习惯使用 Claude Code 的命令格式）

用户可能还会添加一些可选的修饰语——请予以尊重并予以执行。

• 关注点： “简化为专注效率” → 仅运行效率审查器（或让聚合结果更侧重于效率）。已支持的关注点包括：reuse、quality（也接受simplification）、efficiency、altitude。
• 试运行： “简化处理但不做任何更改”/“仅报告结果” → 运行四个审查器，呈现分析结果，但不要应用任何修改。在实际应用前请先征得用户同意。
• 范围： “简化最近一次提交的内容”/“简化已暂存的内容”/“简化src/foo.py文件” → 按照相应方式缩小差异对比的范围（详见第一阶段）。

请勿在每次编辑后自动运行此功能，也不要将其附加到无关任务的后端。该操作会消耗四个子智能体相当的计算资源——仅应在用户明确要求时才调用它。

工作流程

第一阶段 — 确定变更内容

获取需要审查的差异内容。根据用户的请求选择对比来源，默认顺序如下：

# 1. Default: uncommitted working-tree changes (tracked files)
git diff

# 2. If that's empty, include staged changes
git diff HEAD

# 3. Scoped variants the user may request:
git diff --staged                 # "staged changes"
git diff HEAD~1                    # "the last commit"
git diff main...HEAD              # "this branch" / "my PR"
git diff -- src/foo.py            # specific file(s)

如果 git diff 和 git diff HEAD 的输出均为空，且既不存在 Git 仓库也没有任何更改，那么就转而检查用户明确指定的文件，或是当前会话中最近创建/修改过的文件。如果确实找不到任何有变化的代码，请如实说明并停止操作——因为此时已无需进一步简化处理流程。

需完整捕获差异文本，并记录其大小：若文本量极大（例如超过2000行变动代码），应提醒用户，同时启动四个分别处理完整差异内容的子代理会消耗大量令牌，建议在继续之前缩小检查范围（按目录或按提交来处理）。

第二阶段——并行启动四个审查器

使用 delegate_task 的批量模式，将全部四个任务放入同一个 tasks 数组中，以便它们同时运行。对于这种处理方式而言，四个审查器是合适的数量；在任何默认配置下，这一数值都在 delegation.max_concurrent_children 的允许范围内。

无法进行任务委托？ 如果在当前环境下无法调用 delegate_task（比如你是最底层的子代理、任务委托功能被禁用，或是令牌预算已耗尽），则绝不能跳过审查步骤或简化审查维度。应在此环境下依次手动完成全部四个维度的审查，保持相同的搜索标准与结果呈现格式。最后在总结中明确说明这是单次顺序式审查，而非并行处理，这样用户就能清楚知晓实际执行了何种审查流程。

请为每位审查者提供完整的代码差异对比结果（而非零散片段——跨文件的问题往往隐藏在这些间隙中），同时告知他们仓库的完整路径，以便其能在更广泛的代码库中进行搜索。每位审查者都将获得“终端操作”、“文件处理”以及“搜索”三类工具集（从而能够执行git命令、读取文件，以及使用search_files/grep功能）。

请告知每位审查者需执行以下操作：

• 在现有代码库中查找相关证据（切勿仅依据代码差异进行判断）；
• 遵循切斯特顿法则：在标记某段代码需要删除之前，先对该行代码运行git blame命令，弄清楚其存在的缘由。若无法确定其最初的设计目的，请将其标记为confidence: low——切勿主观猜测；
• 以结构化格式汇报审查结果，明确说明相关操作的代价、置信度以及潜在风险。

  file:line → problem → cost (what's duplicated/wasted/harder to maintain) → suggested fix | confidence: high/medium/low | risk: SAFE/CAREFUL/RISKY
  

“成本”字段要求每个问题都必须说明其实际影响——若无法阐明问题所带来的具体代价，那很可能是无关紧要的细节问题。

• SAFE = 经验证不会影响程序行为（如未使用的导入、被注释掉的代码、仅起传递作用的包装函数）。可自动应用这些标记。
• CAREFUL = 能在不改变语义的前提下提升代码质量（如重命名局部变量、简化嵌套的三元运算、提取辅助函数）。应用此类修改时需通过测试验证。
• RISKY = 可能会改变程序行为或破坏公共接口规范（如N+1查询优化重构、公共API重命名、内存生命周期变更）。此类问题应标记出来供人工审核——严禁自动应用。
• 应忽略那些无关紧要的细节问题和仅涉及格式上的改动。仅标记那些能显著提升代码质量的问题。

请遵循以下四个目标（若用户另有侧重，可省略其中部分）：

审核员1 — 代码复用

审核此代码差异，检查是否存在重复利用代码库中已有功能的代码。通过搜索工具模块、共享辅助函数以及相关文件（可使用search_files / grep命令），查找新代码可以调用而非重新实现的现有函数、常量或模式。需标记的问题包括：与现有功能重复的新函数；那些本可由现有工具完成的手动逻辑实现（如手动字符串/路径操作、自定义环境检查、临时性的类型判断、重新实现的解析逻辑）。对于每一种情况，需指出应使用的现有功能及其所在位置。

审核员2 — 代码质量 请仔细检查此代码差异，排查其中存在的质量问题。需重点关注以下方面：冗余状态（重复的数值或可从现有状态推导出的数值；本不必存在的缓存）；参数泛滥（本应重构函数却新增了大量参数）；类似但略有不同的复制粘贴代码（本应通过抽象机制共享的近似重复代码块）；存在漏洞的抽象设计（暴露了内部实现，破坏了原有的封装边界）；强制字符串类型的代码（在已有常量、枚举或注册表的情况下仍使用原始字符串——在标记问题前请先查阅标准注册表）；过度嵌套的条件语句（三目运算符链、3层及以上的if/else嵌套结构——可通过保护性条款、提前返回或查找表来简化结构）；AI生成的低质量代码模式（如在count++上方添加// 增加计数器这类重复说明的注释；对已经过验证的输入进行不必要的防御性空值检查；绕过类型系统的as any类型转换；与文件其他部分不一致的代码模式）。针对每一类问题，都需要给出具体的重构方案。

审核人3 — 效率 请检查此差异文件，排查效率问题。重点关注以下方面：不必要的操作（冗余计算、重复读取文件、多次调用 API、N+1 访问模式）；并发性缺失（独立操作被顺序执行）；热点路径性能瓶颈（在启动阶段或每次请求的处理路径上存在耗时/阻塞型操作）；TOCTOU 错误用法（在执行操作前先进行存在性检查，而非直接执行操作并处理错误）；内存问题（内存无限制增长、缺乏清理机制、监听器/处理程序泄漏；以及使用闭包创建的长期存在的回调函数或对象，这些闭包会捕获整个外部作用域——只要对象存在，所有被捕获的内容就会一直存活，因此建议采用小型类或仅复制所需字段的显式结构体）；过度宽泛的读取操作（本应只读取部分内容却加载了整个文件）；静默失败（空的异常处理块、被忽略的错误返回值、使用 except: pass 或 .catch(() => {}) 且未做任何处理、错误传播缺失——这些情况会掩盖漏洞，至少应在吞掉错误前进行日志记录）。针对每一种问题，请给出具体的修复方案，并说明为何该方案能提升效率或增强安全性。

审核人 4 — Altitude

请仔细检查此差异，确认是否存在在错误层级上进行的修改——即那些仅作为临时补救措施、叠加在共享基础设施之上的解决方案，而非对基础设施本身的真正修复。浅层修复的典型迹象包括：为处理某个特定调用者而在通用代码路径中添加特殊逻辑（如 if (caller == X) 分支、类型检查或特殊值处理机制）；仅在某个调用点进行修补，而其他同类调用点仍存在相同缺陷；在原有临时方案之上再叠加新的 workaround；为避免触及真正需要修改的部分而添加包装层；或是引入配置项或标志来绕过有问题的默认设置，而非修复该默认设置本身。针对每一处情况，需明确该修改试图规避的底层机制，并描述更深层次的修复方案——比如对共享路径进行抽象化处理、修复根本的默认设置，或是彻底解决整个错误类别——同时诚实地评估该深层修复的工作量是否已大到足以独立成项，而无需再纳入此次清理工作中。在开始之前，请先阅读相关代码并使用 git blame 工具分析：那些看似临时补救的措施，有时其实是经过刻意设计的边界处理方式（如兼容性适配层、分阶段迁移方案或外部代码隔离机制），此类情况不应被标记为问题。

第三阶段 —— 汇总与应用

等待所有四个检查工具返回结果（批量模式下会一次性返回所有结果）。

1. 将各工具的检测结果合并为一个列表，对重复的条目进行去重处理——即当两个检测结果针对同一行代码或同一底层机制时，将其合并为一条记录。
2. 忽略误报——您拥有最全面的上下文信息，无需与审核者争论，只需直接忽略那些不准确或无效的建议即可。
3. 解决冲突。不同审核者可能会提出不同意见（例如：审核者1建议“使用现有的工具X”；审核者3则认为“X效率较低，建议直接内联代码”）。默认的解决优先级为：正确性 > 用户指定的重点 > 可读性/复用性 > 微性能优化。除非某项性能优化确实能显著提升效率，否则不要采用可能损害代码清晰度的方案。当两个建议相互排斥但都合理时，应选择对代码改动较小的方案，并注明另一种方案。
4. 按风险等级依次应用：
   • 首先处理SAFE级（自动应用）：未使用的导入、被注释掉的代码、直接传递的包装函数以及多余的类型断言。操作完成后运行测试。
   • 接着处理CAREFUL级（需验证后逐个文件应用）：重命名局部变量、简化三元运算、提取辅助函数、合并重复代码等。每处理完一个文件后都要运行测试，若出现错误则恢复原状。
   • 最后处理RISKY级（需标记审核——禁止自动应用）：N+1查询结构优化、公共API修改、并发问题修复以及错误处理机制改动。针对每一项改动，都需要说明其风险点及测试覆盖率情况。那些需要深入修改的方案通常属于此类别——因为这类修改会涉及共享基础设施，因此应先提出更深入的修复方案，由用户决定是立即实施还是稍后处理。
     如果用户选择了试运行模式，则会显示所有三个等级的修改方案，但不会实际应用任何改动。
5. 验证未破坏任何功能：针对被修改的文件运行项目中的对应测试（无需运行全部测试套件），并重新执行仓库中使用的所有代码检查工具和类型检查工具。如果某个修复导致了测试失败，请撤销该修复并予以报告。
6. 总结所做的更改：按审核者类别和风险等级列出已应用的修复项简表，同时说明有意跳过的发现及其原因。若为直接处理（未委托他人）则需在此处注明。

常见误区

• 审核人数勿超过4人。审核者越多，成本越高，需要协调的冲突建议也越多，反而无法提升审查覆盖率。四个类别已足以覆盖所有需求。
• 需将完整差异内容提供给每位审核者。将差异拆分给不同审核者会违背设计初衷——只有看到完整内容，才能避免跨文件重复问题及N+1次处理的情况。
• 审核者是靠搜索而非猜测。仅指出存在重复问题却未提供现有工具的参考信息（如“很可能已有相关辅助函数”）属于无用信息。必须提供文件:行号级别的证据，否则应忽略此类发现。
• 应用修复 ≠ 重写代码。这只是对用户近期更改的整理，而非重构整个模块的许可。修改范围应仅限于差异涉及的内容以及修复所需的最低限度的周边调整。Altitude工具发现的特殊情况除外：若合适修复方案的范围超出差异显示的内容，请标记该问题——切勿在整理过程中擅自重构共享机制。
• 避免陷入错误排查的误区。 如果审核者发现真正的正确性错误，应明确标注出来——但需作为单独的“发现错误”记录，而非合并到代码整理修复中。正确性审查属于另一轮审查流程，拥有不同的验证标准。
• 遵守项目规范。 若仓库中存在 AGENTS.md / CLAUDE.md / HERMES.md 文件或代码检查器配置，应将相关规则纳入审核提示中，这样提出的建议才能符合项目风格，而非与之相悖。
• 过大的差异会导致上下文丢失。 如果代码差异过大，在分配任务前应先缩小范围——让四个子代理分别处理5000行左右的差异不仅效率低下，还可能造成内容截断。
• 过度依赖死代码检测工具。 knip、ts-prune 和 depcheck 等工具可能会标记那些会被动态使用的导出项（如基于字符串的导入、反射机制）。在删除之前务必先通过 grep 查找该符号的实际使用情况——干净的工具报告并不能作为确凿依据。
• 未经检查便重命名。 导出名称、API 路由路径、数据库列名以及配置键值都属于项目契约的一部分——即便原名存在问题，随意重命名也会影响其他依赖该名称的模块。将涉及公共契约的更改标记为“高风险”，绝不可自动执行重命名操作。
• 删除“不必要的”错误处理代码。 空的异常捕获块或被忽略的错误可能是有意为之——因为在特定场景下这些错误是预期中的且无害的。应对其进行标记而非直接删除，由人工来判断是否需要处理。
• 并非所有特例都只是权宜之计。 为兼容性问题设计的填充模块、分阶段迁移方案，以及针对第三方代码的隔离层，虽然看似违背了常规设计原则，实则是经过深思熟虑的设计选择。在标记问题之前，请先查看 git blame 报告及相关注释；若意图不明确，请将问题的置信度标记为“低”。

相关内容

如果您的安装环境配备了 subagent-driven-development 技能（可选），它可处理另一种互补场景：即在实现过程中针对每项任务进行并行审查。该技能则用于事后的独立清理工作。对于提交前的安全/质量检查，请使用 requesting-code-review 功能——那属于缺陷排查阶段，而此功能则负责后续的清理工作。