component-refactoring

component-refactoring 技能概覽

component-refactoring 是做什麼的

component-refactoring 技能可協助你重構 Dify 前端中高複雜度的 React 元件，不必憑感覺亂猜從哪裡下手。它特別適合元件已經過大、巢狀過深，或測試起來太難乾淨拆分的情況，能提供一套有結構的計畫，協助你拆分 UI、抽出 hooks，或降低認知複雜度。

什麼情況下最適合用

當 pnpm analyze-component --json 顯示複雜度高於 50、行數超過 300，或分析器明確建議先重構再測試時，就很適合使用 component-refactoring 技能。若任務本身就是要做 code splitting、hook extraction，或簡化已累積太多條件分支的元件，這個技能也很合適。

為什麼它有用

這個技能比一般的重構提示更偏向決策導向。它把工作流程直接連到 Dify 的元件分析工具，並提供具體的降複雜度模式，例如以區塊切分與 hook 抽取為主。這很重要，因為大型 React 檔案最常見的失敗，不是語法錯誤，而是在降低耦合的同時，還要把行為完整保留下來。

如何使用 component-refactoring 技能

安裝並指向正確的 repo

使用 npx skills add Charlie85270/Dorothy --skill component-refactoring 安裝 component-refactoring 技能。這套流程是以 Dify frontend 的目錄結構為前提，所以請從 web/ 目錄執行命令，並使用相對於該目錄的路徑，例如 app/components/...。

先做分析，不要直接重寫

一個好的 component-refactoring usage 流程是：先分析元件、再檢視生成的提示內容，最後只重構真正造成複雜度的部分。使用 pnpm analyze-component <path> --json 來確認分數和行數；如果你想要機器可讀的重構摘要，則使用 pnpm refactor-component <path> --json。如果檔案沒有超過門檻，這個技能可能就不需要。

先讀這些檔案

如果你想讓 component-refactoring guide 真正有實用價值，請先讀 SKILL.md，再讀那些解釋提示背後模式的參考文件：references/complexity-patterns.md、references/component-splitting.md、references/hook-extraction.md。這些檔案會告訴你，這個技能如何定義複雜度，以及哪些修改真的能把複雜度降下來。

把粗略目標改成更好的提示

當你的輸入有清楚寫出目標元件、目的與限制時，這個技能的效果最好。舉例來說，不要只說「重構這個元件」，而是說：「重構 app/components/foo/index.tsx，將認知複雜度降到 50 以下。優先抽出處理 state/effects 的 hooks，並拆分 modal 區塊，但不要改變行為或 public props。」這種具體程度會讓輸出更好，因為它清楚告訴技能哪些要保留、哪些要優化。

component-refactoring 技能 FAQ

component-refactoring 只適用於 Dify 嗎？

是，component-refactoring for Refactoring 這套流程是依照 Dify frontend 的慣例、命令名稱與元件路徑設計的。你可以把概念套用到其他地方，但如果你是在這個 codebase，或非常相近的 React monorepo 中工作，安裝與使用說明才最有價值。

可以拿它取代一般提示詞嗎？

可以，但當你需要可重複、且與可量化複雜度綁定的重構指引時，這個技能會比一般提示詞更好。普通提示詞可能只會建議做大方向清理；component-refactoring 則更適合用在你需要下一步行動有證據可依、並受分析器輸出範圍約束的情況。

需要很進階才會用嗎？

不用。只要你能找出目標檔案並執行分析命令，這個技能就適合初學者。重點需求是，你要能提供明確的元件路徑，並告訴模型優先目標是拆分、抽 hook，還是降低複雜度。

什麼情況下不該用？

不要把 component-refactoring 技能用在簡單元件、第三方 wrapper，或你只是想加測試但不想改結構的情況。如果元件本來就容易讀，而且低於門檻，硬重構反而可能帶來不必要的改動成本。

如何改善 component-refactoring 技能

提供更好的輸入指標

最快改善 component-refactoring usage 的方式，是在請求中附上分析器輸出：complexity score、maxComplexity、lineCount，以及任何警告訊息。這些細節能幫助技能抓到真正的壓力點，而不是把每個大檔案都當成同一類問題處理。

明確說出你想要的重構風格

如果你要的是特定結果，就一開始講清楚。例如：「先拆 UI 區塊」、「先為共用 state/effects 抽 custom hook」，或「減少 main return 裡的 conditional rendering」。這比籠統說「讓它更乾淨」更有效，因為技能可以把你的目標對應到參考文件中的正確模式。

注意常見失敗模式

最容易犯的錯誤包括過度切分、只是搬移邏輯卻沒有簡化，以及為了追求更低複雜度而改變行為。更強的輸入可以降低這些風險：請先指出哪些 props、side effects 與 modal 流程必須保持穩定，並要求盡量不要改變外部 API。

第一次重構後要再迭代

完成第一輪重構後，重新執行 pnpm analyze-component <path> --json，並把分數與目標比較。如果複雜度還是偏高，就請技能專注處理剩下那個分支很多的區塊，或挑一個單一 hook 候選來下手，不要整個檔案又重新大改一次。