simplify-code

简化代码 — 并行审查与清理

让四位专注于不同方面的审查者并行审查近期的代码更改，汇总他们的发现，并应用值得采纳的修复。

这是一次清理，而不是查找错误。 你要提升已有可运行代码的质量——消除重复、简化不必要的复杂性、减少浪费，并从根本上解决临时补丁式的修复。不要在这里查找正确性错误；这正是 requesting-code-review 的工作。

核心原则： 四位各有侧重的审查者胜过一位面面俱到的审查者。每位审查者都深入搜索代码库，只查找一类问题——复用、质量、效率、抽象层次——不会因为同时关注这四个方面而分散注意力。他们会并行运行，因此耗时相当于一次审查，而不是四次。

何时使用

当用户说出以下任意内容时，触发此技能：

• “simplify” / “simplify my changes” / “simplify these changes”
• “review my code” / “review my recent changes” / “clean up my changes”
• “/simplify”（如果他们延续了 Claude Code 的使用习惯）

用户还可能添加可选修饰语——请遵循：

• 侧重点： “simplify focus on efficiency” → 只运行效率审查者（或在汇总时赋予其更高权重）。可识别的侧重点：reuse、quality（也接受 simplification）、efficiency、altitude。
• 试运行： “simplify but don't change anything” / “just report” → 运行四位审查者，呈现发现，但不应用任何修改。应用前先征求同意。
• 范围： “simplify the last commit” / “simplify staged” / “simplify src/foo.py” → 相应缩小差异来源（参见阶段 1）。

不要在每次编辑后自动运行此技能，也不要把它附加到无关任务的末尾。这会消耗相当于四个子 Agent 的 Token；仅在用户明确要求时才调用。

流程

阶段 1 — 确定更改内容

捕获要审查的差异。根据用户的要求，按以下默认顺序选择来源：

# 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 行更改），请提醒用户，四个子 Agent 各自携带完整差异会消耗大量 Token，并在继续前询问是否要按目录或提交缩小范围。

阶段 2 — 并行启动四位审查者

使用 delegate_task 批处理模式——将四项任务全部放入一个 tasks 数组中，使其并发运行。对于这种模式，四个是合适的并行数量；在任何默认安装中，都不会超出 delegation.max_concurrent_children 限额。

无法委派？ 如果在当前上下文中无法调用 delegate_task（你是叶子子 Agent、委派已禁用，或预算已用尽），不要跳过审查，也不要遗漏任何角度。在当前上下文中依次自行完成四种审查——遵循同样的搜索标准和发现格式。最后汇总时，请明确说明这是一次内联单轮审查，而非并行分派，以便用户了解实际运行的方式。

为每位审查者提供完整差异（而非片段——跨文件问题可能藏在片段之间），以及绝对仓库路径，以便他们搜索更广泛的代码库。每位审查者都应获得 terminal、file 和 search 工具集（以便使用 git、read_file 以及 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
  

  cost 字段会迫使每项发现证明其价值——如果无法明确说明问题的实际代价，那它很可能只是吹毛求疵。
  • SAFE = 已证实不会影响行为（未使用的导入、注释掉的代码、透传包装器）。自动应用这些修改。
  • CAREFUL = 改进代码但不改变语义（重命名局部变量、简化嵌套三元表达式、提取辅助函数）。应用后进行测试验证。
  • RISKY = 可能改变行为或破坏公共契约（重构 N+1 访问、重命名公共 API、改变内存生命周期）。标记为需要人工审查——不要自动应用。
• 跳过吹毛求疵的问题和纯风格改动。只标记能实质改善代码的问题。

完成以下四项目标（如果用户的关注点排除了某项，则忽略该项）：

审查者 1——代码复用

审查此差异，找出重复实现代码库中已有功能的代码。搜索工具模块、共享辅助函数和相邻文件（使用 search_files / grep），查找新代码可以调用而非重新实现的现有函数、常量或模式。标记：重复现有函数的新函数；现有工具已能完成的手写逻辑（手动处理字符串/路径、自定义环境变量检查、临时类型保护、重新实现解析逻辑）。对于每项，指出应使用的现有内容及其所在位置。

审查者 2——代码质量

审查此差异中的质量问题。检查：冗余状态（重复现有状态或可从现有状态推导出的值；不必要的缓存）；参数泛滥（不断添加新参数，而该函数本应重新设计）；复制粘贴后稍作修改（应抽象为共用逻辑的近似重复代码块）；抽象泄漏（暴露内部实现、破坏现有封装边界）；字符串类型代码（在已有常量/枚举/注册表的情况下仍使用原始字符串——标记前先检查规范注册表）；深层嵌套条件（连续三元表达式、三层或更多层的 if/else 金字塔——使用守卫子句、提前返回或查找表来简化）；AI 生成的冗余代码模式（重复陈述显而易见代码的多余注释，例如在 count++ 上方写 // increment counter；对已验证输入进行不必要的防御性空值检查；绕过类型系统的 as any 类型断言；与文件其余部分不一致的模式）。对于每项，给出具体的重构方案。

审查者 3——效率

审查此差异中的效率问题。检查：不必要的工作（冗余计算、重复读取文件、重复 API 调用、N+1 访问模式）；错失并发机会（相互独立的操作按顺序运行）；热点路径臃肿（在启动时或每个请求的路径上执行繁重/阻塞的工作）；TOCTOU 反模式（操作前先检查是否存在，而不是直接执行操作并处理错误）；内存问题（无界增长、缺少清理、监听器/句柄泄漏；长期存活的回调或闭包构造的对象捕获了整个外层作用域——对象存活多久，捕获的内容就会保留多久，因此应优先使用只复制所需内容的小型类或显式字段结构体）；读取范围过宽（需要局部内容时却加载整个文件）；静默失败（空的 catch 块、忽略错误返回、except: pass、没有任何处理的 .catch(() => {})、错误传播链断裂——这些都会隐藏错误，至少应在吞掉错误前记录日志）。对于每项，给出具体的修复方法，并说明其为何更快或更安全。 评审员 4 — 修复深度 检查此 diff 是否存在修复层级不当的问题——在共享基础设施之上打补丁，而不是直接修复基础设施。修复过浅的迹象包括：在通用代码路径中添加只为一个调用方处理问题的特殊分支（如 if (caller == X) 分支、类型检查、魔法值逃生口）；只在调用点修复症状，而同类调用点仍有相同缺陷；在先前的变通方案上再叠加变通方案；为避免修改真正需要改动的部分而添加包装器；引入配置或标志来绕过有问题的默认行为，而不是修复默认行为。对于每个问题，指出改动试图绕过的底层机制，并说明更彻底的修复方案——泛化共享路径、修复默认行为根源，或修复整类缺陷；同时如实说明，当更彻底的修复规模太大时，应将其作为独立任务，而不是纳入本次清理。请先阅读相关代码和 git blame：看似打补丁的做法有时是有意设置的边界（兼容性垫片、分阶段迁移、隔离 vendored 代码）。不要标记这类情况。

阶段 3 — 汇总并应用

等待全部四位评审员返回（批处理模式会一次性返回全部结果）。

1. 合并评审结果，去除重复项——当两条结果指向同一行或同一底层机制时，将其合并为一条。
2. 剔除误报——你掌握的上下文最多；无需与评审员争辩，直接静默舍弃薄弱或错误的建议。
3. 解决冲突。 评审员可能意见不一（评审员 1：“使用现有工具函数 X”；评审员 3：“X 太慢，直接内联”）。默认优先级：正确性 > 用户声明的关注点 > 可读性/复用 > 微观性能。除非该路径确实是热点，否则不要应用牺牲清晰度的性能“修复”。如果两条建议互斥但都说得通，选择改动较少的方案，并说明另一种方案。
4. 按风险等级顺序应用：
   • SAFE 优先（自动应用）：未使用的导入、已注释掉的代码、直通包装器、多余的类型断言。之后运行测试。
   • CAREFUL 接着处理（核验后应用，每次处理一个文件）：重命名局部变量、展开三元表达式、提取辅助函数、合并重复代码。每处理一个文件后运行测试。若有改动导致测试失败，则还原。
   • RISKY 最后处理（标记为待评审——不要自动应用）：N+1 重构、公共 API 变更、并发修复、错误处理变更。逐项说明风险和测试覆盖情况。修复深度方面的发现通常属于此类——更彻底地修复意味着要改动共享基础设施，因此应说明更深入的修复方案，让用户决定现在处理还是留待后续。 如果用户选择了试运行，则展示全部三个等级的内容，但不应用任何改动。
5. 验证没有引入问题：运行针对已修改文件的项目专项测试（而非完整测试套件），并重新运行仓库使用的任何 linter／类型检查。如果某项修复导致测试失败，还原该项修复并报告。
6. 总结所做的改动：按评审类别和风险等级简要列出已应用的修复，以及有意跳过的发现和原因。如果是内联执行（未委派），在此说明。

注意事项

• 不要将任务分发给超过 4 个审查者。 审查者越多，成本越高，需要协调的冲突建议也越多，覆盖面却不会更广。这四个类别已涵盖所有情况。
• 将完整的差异交给每位审查者。 将差异拆分给不同审查者会违背设计初衷——跨文件重复和 N+1 问题只有在掌握全貌时才会显现。
• 审查者要搜索，不要猜测。 如果复用建议没有指出现有工具的位置（“这大概有个辅助工具”），那就是噪声。要求提供 file:line 证据；没有证据的发现一律舍弃。
• 应用修复 ≠ 重写。 这是对用户近期更改的清理，不是重构整个模块的许可。修改范围应限于差异涉及的内容，以及修复所需的最小周边改动。架构层级问题是例外：如果正确的修复需要深入到差异范围之外，就将其标记出来——不要在清理过程中擅自重建共享机制。
• 不要偏离到查找 Bug 上。 如果审查者发现真正的正确性 Bug，要醒目地报告——但应作为单独的“发现 Bug”说明，而不是并入清理修复。正确性审查是另一轮工作，有不同的验证标准。
• 遵循项目约定。 如果仓库中有 AGENTS.md / CLAUDE.md / HERMES.md 或 linter 配置，应将这些规则纳入审查者的提示词，让建议符合项目风格，而不是与之冲突。
• 大型差异会耗尽上下文。 如果差异很大，应先缩小范围再委派——让 4 个子 Agent 各自处理一份 5000 行差异，成本高昂，还可能导致内容被截断。
• 不要过度信任死代码工具。 knip、ts-prune 和 depcheck 会将动态使用的导出项（基于字符串的导入、反射）标记出来。移除前务必搜索该符号名称——工具报告干净不代表万无一失。
• 重命名前先检查公开契约。 导出名称、API 路由路径、DB 列名称和配置键都是契约——即使名称不理想，重命名也会破坏使用方。将公开契约变更标记为 RISKY；绝不要自动重命名。
• 不要移除“多余”的错误处理。 空的 catch 块或被忽略的错误可能是有意为之——在该上下文中，这种错误可能是预期且无害的。应将其标记出来，不要移除；由人工决定。
• 并非所有特殊处理都是临时补丁。 兼容性垫片、分阶段迁移，以及围绕供应商代码的隔离层，看起来像是架构层级违规，但可能是有意设计。标记之前先检查 git blame 和周边注释；意图不明确时，将 confidence: low。

相关内容

如果你的安装中包含 subagent-driven-development 技能（可选），它介绍了互补的场景：在实现过程中按任务并行审查。本技能则是独立的事后清理流程。提交前的安全与质量把关请使用 requesting-code-review——那是查找 Bug；本技能则用于清理。