reducing-entropy

reducing-entropy skill 概覽

reducing-entropy skill 是一種只能手動啟用的重構輔助工具，目的是有意識地把程式碼庫縮小。它不是通用型的 cleanup prompt，也不應該自動觸發。當你的真正目標是減少系統中的可變動零件、降低總程式碼量，並且比一般重構更明確地偏向刪除時，才適合使用它。

這個 skill 最適合哪些人

reducing-entropy 特別適合以下情境的人：

• 正在重構一個持續膨脹的成熟程式碼庫
• 正在審查看似是「cleanup」但其實可能偷偷增加抽象層的方案
• 正在判斷某個功能、分層或 helper 到底有沒有存在必要
• 想真正簡化架構，而不只是重新整理架構的人

它對 reducing-entropy for Refactoring 尤其有價值，因為這類工作最常見的錯誤直覺，就是新增結構，而不是移除既有結構。

真正要解決的核心問題

這個 skill 要回答的，不只是「我該改什麼？」這種表層問題，而是更難的幾個判斷：

• 改完之後，程式碼庫最終應該長什麼樣子
• 最終狀態是否真的更小
• 哪些東西可以刪掉，而不是被保留下來

因此，當你需要模型強烈偏向「整體淨減少」時，它會比泛泛的「幫我簡化這段程式碼」提示更有用。

reducing-entropy 的差異點在哪裡

reducing-entropy 最核心的差異，在於它衡量成功的標準是：最終程式碼量，不是實作過程花了多少工。

這表示它會偏好像這樣的結果：

• 寫一段小型 migration，換來移除一整個大型子系統
• 用更簡單的資料結構取代自訂型別
• 刪除可有可無的行為，而不是把它們抽象化、一般化
• 拒絕那些「看起來更乾淨」，但其實會讓總程式碼變多的設計

導入前的重要限制

這不是每個任務都能安心當成預設值的 skill。repository 裡已明確把 reducing-entropy 定位為僅限手動使用，而且必須在使用者有明確意圖時才啟用。如果你的團隊在某個任務中更重視可擴充性、未來相容性，或介面穩定性，而不是縮減程式碼，那這個 skill 可能會過度偏向刪除。

決定是否使用前，先讀哪些檔案

先讀這些檔案：

• skills/reducing-entropy/SKILL.md
• skills/reducing-entropy/README.md
• skills/reducing-entropy/references/simplicity-vs-easy.md

接著，再依你的情境補看一到兩個 reference mindset 檔案：

• references/data-over-abstractions.md
• references/design-is-taking-apart.md
• references/expensive-to-add-later.md

這些 reference 很重要，因為這個 skill 預設你在採取行動前，至少會先用一種「簡化觀點」來做判斷，而不是直接下手改。

如何使用 reducing-entropy skill

reducing-entropy 的安裝與設定

如果你使用這個 repository 的 Skills CLI 模式，可以用以下指令安裝：

npx skills add softaworks/agent-toolkit --skill reducing-entropy

安裝後，先打開 skill 所在資料夾，第一次使用前務必讀完 SKILL.md。這不是裝好就能直接跑的自動化 skill；它更像是一套需要你刻意啟動的決策框架。

先從必讀的 reference mindset 開始

很多使用者會漏掉一個很實際的細節：reducing-entropy 會要求你在繼續之前，至少先載入 references/ 裡的一個檔案。請先做這一步，並且明確說出你選的是哪一個。

常見搭配方式如下：

• 當某個熟悉的模式很誘人，但實際上過重時，用 simplicity-vs-easy.md
• 當程式碼裡到處都是 wrappers、managers 或自訂型別時，用 data-over-abstractions.md
• 當責任分工糾結在一起時，用 design-is-taking-apart.md
• 當刪除可能與未來補救成本衝突時，用 expensive-to-add-later.md

這一步會明顯提升輸出品質，因為它讓模型有一個具體的簡化視角，而不是只有模糊的「把它弄乾淨一點」。

reducing-entropy 需要什麼輸入資訊

如果你想拿到有用的結果，不要只丟一個 repo 連結或一大包檔案。reducing-entropy 在以下資訊完整時效果最好：

• 使用者已同意的目標
• 必須保留的現有行為
• 本次納入範圍的程式碼區域
• API、migration 或時程上的限制
• 是否允許跨檔案、模組或功能刪除內容

好的輸入範例如下：

“Use reducing-entropy on our billing retry flow. Goal: preserve current retry behavior for Stripe failures, but reduce total code in services/billing/ and workers/retry/. You may remove dead configuration paths and duplicate helper layers. Do not change public API responses or database schema this week.”

這會遠比下面這種說法有效：

“Refactor billing to be simpler.”

把模糊需求變成有效的 reducing-entropy prompt

一個好的 reducing-entropy usage prompt，通常會包含五個部分：

1. 明確啟用
2. 目標範圍
3. 需要保護的行為
4. 刪除權限
5. 輸出格式

範例：

“Apply the reducing-entropy skill. Load one reference mindset first and tell me which one you chose. Analyze src/cache/ and src/session/ for the smallest codebase that still supports current login/session behavior. Prefer deletion over reorganization. Reject options that increase total code even if they look cleaner. Give me:

• the smallest end-state design
• what to delete
• what to merge
• risks
• rough before/after code footprint”

適合實際重構工作的建議流程

一套可靠的流程如下：

1. 讀 SKILL.md
2. 選一個 reference mindset
3. 檢查目前的模組邊界
4. 列出哪些行為一定要保留
5. 問出這個 skill 的三個核心問題
6. 產出 2–3 個候選的最終狀態
7. 以「淨減少的程式碼量」比較它們
8. 實作最小且可行的方案
9. 再次檢查是否還有殘留的抽象層或死路徑

這樣可以避免一種很常見的失敗模式：還沒先決定「最小可存活的設計」是什麼，就直接跳進去改程式。

每次使用 reducing-entropy 都該強制問的三個問題

這個 repository 把 skill 的核心建立在三個檢查點上。實務上，最好在 prompt 裡把它們直接寫明：

• What is the smallest codebase that solves this?
• Does the change result in less total code?
• What can we delete?

如果你沒有強制要求這三個問題，輸出結果通常很容易滑回一般重構建議的路線。

reducing-entropy 最適合發揮的情境

最合適的任務包括：

• 把重複的模組收斂成一條更簡單的路徑
• 移除 wrappers、factories、managers 與過薄的抽象層
• 用普通資料加上函式，取代自訂結構
• 刪除使用率低的功能或過度可配置性
• 在新增工作之前，先把糾結的子系統簡化

這也是為什麼 reducing-entropy for Refactoring 會是最強適配情境：它重點更偏向重新設計最終狀態，而不是打磨局部程式碼風格。

什麼情況不適合使用 reducing-entropy

當主要任務是以下情況時，請避免使用這個 skill：

• 新增一項未來需求還不明朗的新能力
• 需要為第三方保留穩定的擴充介面
• 正在設計那些日後很難補救的基礎能力
• 在沒有刪除或合併權限的前提下，只想讓程式碼更好讀

在這些情境中，偏向刪除不但不是優勢，反而可能變成不匹配。

repository 中值得先讀的實用檔案

如果你想最快建立理解，建議依這個順序閱讀：

1. SKILL.md
2. README.md
3. references/simplicity-vs-easy.md
4. references/design-is-taking-apart.md
5. references/data-over-abstractions.md

只有在你想理解作者如何看待這些哲學性支援檔案時，再去讀 adding-reference-mindsets.md。

能明顯提升輸出品質的實用技巧

影響最大的三個做法是：

• 在要求程式碼修改前，先要求「最小的最終架構」。
• 明確要求列出要刪掉的東西，而不只是說要簡化。
• 要求模型估算哪些東西會消失：檔案、函式、classes、branches、configs。

這樣才能把這個 skill 從「風格上的小提醒」，變成真正的縮減練習。

reducing-entropy skill 常見問題

reducing-entropy 會比一般 refactor prompt 更好嗎？

通常會，前提是你的目標真的是「整體淨簡化」。一般 prompt 往往會提出更乾淨的分層、更好的命名，或更可重用的抽象。當這些做法會讓程式碼庫繼續變大，而你希望模型能克制這種衝動時，reducing-entropy 會更合適。

reducing-entropy 適合初學者嗎？

可以，只要這位初學者已經足夠理解現有系統，能說清楚哪些行為必須保留、範圍在哪裡。這個 skill 的框架本身不複雜，但要有好結果，前提是你知道哪些東西可以安全移除。

reducing-entropy 是不是就等於刪程式碼？

不是。它也可能認為「多寫一點程式碼」是合理的，只要那樣做能換來更大量的整體刪除。關鍵判準是最終狀態。如果小幅增加能取代更大的結構，那也是可以接受的。

我可以把 reducing-entropy 用在 greenfield work 嗎？

通常不建議把它當成主要指引。相較於從零設計全新系統，這個 skill 更擅長修剪、縮減或簡化既有程式碼庫。

reducing-entropy 和一般 cleanup 工作有什麼差別？

一般 cleanup 常常是在優化局部可讀性或整理結構；reducing-entropy skill 則是優先追求更少的概念、更少的結構，以及更少的總程式碼。這些目標有重疊，但並不相同。

安裝前最主要的風險是什麼？

最大的風險包括：

• 刪掉了你其實真的需要的彈性
• 對未來需求過度簡化
• 太機械式地把行數當成指標
• 移除了那些其實是出於真實營運需求而存在的結構

這也是為什麼 expensive-to-add-later.md 很重要。它替「不是所有東西都該刪」提供了一個有原則的例外。

reducing-entropy 適合所有 repository 嗎？

不適合。它最適合那些「程式碼持續膨脹本身就是問題」的環境。若是高度受監管、對外平台型，或極度重視擴充性的系統，明確而顯性的結構本來就可能是產品需求的一部分，這時就不太適用。

如何改善 reducing-entropy skill 的使用效果

為 reducing-entropy 設下更清楚的邊界

要改善 reducing-entropy usage，最快的方法就是明確定義哪些東西不能改。否則模型可能會提議刪掉其實很有價值的行為。

實用的邊界描述包括：

• “Preserve API shape.”
• “No schema changes.”
• “Keep test coverage expectations.”
• “User-visible behavior must stay identical.”

邊界清楚，這個 skill 才能安全地激進。

不要只要單一答案，要求比較不同最終狀態

與其只問一個建議，不如要求 2 到 3 個候選最終狀態，並依下列面向排序：

• total code reduction
• migration cost
• risk of breaking behavior
• maintenance burden

這能讓取捨更透明，也幫助你及早排除那種「雖然最小，但目前風險過高」的設計。

提供能暴露 entropy 的程式碼訊號

當你明確指出膨脹跡象時，這個 skill 會表現得更好，例如：

• 模組之間有重複邏輯
• wrapper classes 幾乎沒有實際行為
• configs 裡有沒人在用的模式分支
• helper layers 只是單純轉呼叫
• 其實用 plain data 就夠，卻做了 custom types

這些線索能幫模型鎖定真正值得簡化的地方，而不是只做表面整理。

留意常見失敗模式

最常見的不良輸出包括：

• 把程式重新整理成更多檔案
• 為了「準備未來成長」而增加抽象層
• 繼續保留已經沒用的相容性路徑
• 只提更乾淨的命名，卻沒減少結構
• 把「降低改動量」誤當成目標

如果你看到這些傾向，就要重申核心指標：最終程式碼庫的總程式碼要更少。

策略性地使用 reference files

選對 mindset，結果通常會更好：

• 用 data-over-abstractions.md 去挑戰 class 過重的設計
• 用 design-is-taking-apart.md 去拆開混雜在一起的責任
• 用 simplicity-vs-easy.md 來辨識那種熟悉但耦合過高的解法
• 用 expensive-to-add-later.md 替那些值得保留的少數結構辯護

這是整個 repository 很強的一部分，值得主動而明確地使用，而不是被動略過。

要求按類別列出刪除候選項

一個高產出的 prompt 模式是：

“List deletion candidates by category: feature, abstraction, config, compatibility path, helper, type, and file.”

這樣的結構會迫使模型不要只盯著局部程式碼修改，而是去找更大範圍的縮減機會。

第一輪輸出後要繼續追問

第一輪完成後，可以接著問這類問題：

• “What remains that exists only to support the old design?”
• “Which abstractions are now redundant?”
• “What can be merged further without changing behavior?”
• “What would you remove if you had to cut this module by 30%?”

這些第二輪問題，往往才會挖出真正的收益。

驗證時看淨複雜度，不要只看行數

行數在這裡很重要，但不要盲目使用。最好的改善也應該同時降低：

• 要學習的概念數量
• 追蹤行為時需要跳轉的模組數
• 特殊情況
• 分支路徑
• 相依面積

如果程式碼庫變小了，卻依然糾結混亂，那最多只能算部分成功。最理想的 reducing-entropy guide 使用方式，是把刪除和解耦一起做到。