Deepseek-V4
Minimax-M2.7
Kimi-k2.6簡化代碼
並行使用 3 個代理清理最近的代碼更改。
技能元數據
| 來源 | 捆綁（默認安裝） |
| 路徑 | skills/software-development/simplify-code |
| 版本 | 1.0.0 |
| 作者 | Hermes Agent（靈感來自 Claude Code /simplify） |
| 許可證 | MIT |
| 平臺 | linux, macos, windows |
| 標籤 | code-review, cleanup, refactor, delegation, subagent, parallel, simplify |
| 相關技能 | requesting-code-review, test-driven-development, plan |
參考：完整 SKILL.md
以下是觸發此技能時 Hermes 加載的完整技能定義。這是技能激活時代理看到的指令。
簡化代碼 — 並行審查與清理
通過三個專注的審查者並行運行，審查你最近的代碼更改，彙總他們的發現，並應用值得應用的修復。
核心原則： 三個狹窄的審查者勝過一個是寬泛的審查者。每個審查者深入搜索代碼庫以查找單一類別的問題——複用、質量、效率——而不會將注意力分散到所有三個方面。它們併發運行，因此你只需支付一次審查的延遲，而不是三次。
何時使用
當用戶說出以下任何內容時，觸發此技能：
- "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（質量）、efficiency（效率）。 - 幹跑： "simplify but don't change anything" / "just report"（簡化但不要更改任何內容 / 僅報告）→ 運行三個審查者，展示發現，不應用任何更改。在應用前詢問。
- 範圍： "simplify the last commit" / "simplify staged" / "simplify src/foo.py"（簡化最後一次提交 / 簡化暫存區 / 簡化 src/foo.py）→ 相應地縮小差異源（參見階段 1）。
不要在每次編輯後自動運行此技能。它會消耗相當於三個子代理的 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 行更改），警告用戶三個子代理各自攜帶完整差異將會消耗大量 token，並在繼續之前提供縮小範圍（按目錄、按提交）的選項。
階段 2 — 並行啟動三個審查者
使用 delegate_task 批處理模式 —— 將所有三個任務在一個 tasks 數組中傳遞，以便它們併發運行。對於這種模式，三個是合適的扇出數量；在任何默認安裝中，這都在 delegation.max_concurrent_children 預算範圍內。
給每個審查者提供完整的差異（不是片段——跨文件問題隱藏在間隙中）以及絕對倉庫路徑，以便他們可以搜索更廣泛的代碼庫。每個審查者獲得 terminal、file 和 search 工具集（以便他們可以使用 git、read_file 和 search_files/grep）。
告訴每個審查者：
- 搜索現有代碼庫以獲取證據（不要僅從差異中進行推理）。
- 將發現報告為具體列表：
file:line → problem → suggested fix（文件:行號 → 問題 → 建議修復）。 - 對每個發現排名
high/medium/low（高 / 中 / 低）置信度。 - 跳過吹毛求疵和僅涉及風格的變動。僅標記那些能實質性改進代碼的內容。
傳遞這三個目標（刪除用戶焦點排除的任何目標）：
審查者 1 — 代碼複用
審查此差異，查找重複代碼庫中已有功能的代碼。搜索實用模塊、共享輔助程序和相鄰文件（使用 search_files / grep）以查找現有函數、常量或模式，新代碼可以調用它們而不是重新實現。標記：重複現有函數的新函數；現有實用程序已經完成的手寫邏輯（手動字符串/路徑操作、自定義環境檢查、臨時類型守衛、重新實現的解析）。對於每個標記，命名要使用的現有事物及其位置。
Reviewer 2 — 代碼質量
審查此差異（diff）中的質量問題。查找：冗餘狀態（重複或可從現有狀態派生的值；不必要的緩存）；參數蔓延（在應重構函數的地方強行添加新參數）；帶變體的複製粘貼（應共享抽象的近重複代碼塊）；洩露的抽象（暴露內部實現，破壞現有的封裝邊界）；字符串類型化代碼（在已有常量/枚舉/註冊表的情況下使用原始字符串——在標記前請檢查規範註冊表）。針對每一項，給出具體的重構方案。
Reviewer 3 — 效率
審查此差異（diff）中的效率問題。查找：不必要的工作（冗餘計算、重複文件讀取、重複 API 調用、N+1 訪問模式）；錯失的併發機會（獨立操作順序執行）；熱點路徑膨脹（啟動時或每個請求路徑上的繁重/阻塞工作）；TOCTOU 反模式（在執行操作前進行存在性預檢查，而不是直接執行操作並處理錯誤）；內存問題（無限制增長、缺少清理、監聽器/句柄洩漏）；過於寬泛的讀取（加載整個文件，而實際上只需切片部分）。針對每一項，給出具體的修復方案，並說明為何它更快或更輕量。
階段 3 — 彙總與應用
等待所有三個評審員返回（批處理模式會一起返回它們）。
- 合併發現結果到一個列表中，去除評審員重疊部分的重複項。
- 丟棄誤報——你擁有最多的上下文；無需與評審員爭辯，只需靜默地丟棄薄弱或錯誤的建議。
- 解決衝突。 評審員可能會意見相左（評審員 1：“使用現有工具 X”；評審員 3：“X 很慢，將其內聯”）。默認解決順序為：正確性 > 用戶聲明的重點 > 可讀性/複用性 > 微性能。 除非路徑確實是熱點，否則不要應用損害清晰度的性能“修復”。當兩個建議互斥且都有道理時，選擇觸及代碼較少的那個，並註明替代方案。
- 應用保留下來的修復，直接使用
patch/write_file——除非用戶要求幹跑（dry run），在這種情況下，先呈現列表並詢問。 - 驗證你沒有破壞任何內容：運行受觸文件的針對性測試（而非全套測試），並重新運行倉庫使用的任何 linter/類型檢查。如果某個修復破壞了測試，回滾該修復並報告。
- 總結你所做的更改：按評審員類別分組的已應用修復簡短列表，以及你故意跳過的任何發現及其原因。
陷阱
- 不要將範圍擴大到超過 ~3 個評審員。 更多的評審員意味著更高的成本和更多需要協調的衝突建議，而不是更好的覆蓋率。三個類別足以覆蓋該空間。
- 將完整的 diff 提供給每個評審員。 將 diff 拆分給不同評審員會違背設計初衷——跨文件重複和 N+1 問題只有在查看全貌時才會顯現。
- 評審員進行搜索，而非猜測。 沒有指向現有實用程序的指針的複用發現（“可能有為此準備的輔助函數”）是噪音。要求提供
file:line證據；丟棄缺乏此類證據的發現。 - 應用 ≠ 重寫。 這是對用戶最近更改的清理，而非重構整個模塊的許可。保持編輯範圍侷限於 diff 觸及的內容以及修復所需的最小周圍更改。
- 尊重項目約定。 如果倉庫有 AGENTS.md / CLAUDE.md / HERMES.md 或 linter 配置，將這些規則納入評審員提示中，以便建議符合內部風格，而不是與之衝突。
- 大型 diff 會撐爆上下文。 如果 diff 巨大，在委託之前先縮小範圍——三個子代理各自攜帶 5000 行的 diff 既昂貴又可能導致截斷。
相關
如果你的安裝包含 subagent-driven-development 技能（可選），它涵蓋了互補的情況：在實現過程中並行審查，按任務進行。本技能是獨立的事後清理步驟。使用 requesting-code-review 作為提交前的安全/質量門禁。