當你顫抖着雙手點開那個名為 OrderManager.java 的文件，滾動條彷彿深不見底的黑洞——5328行代碼，260個if-else嵌套，沒有任何註釋，上一次修改記錄是三年前離職的"大神"。

老闆讓你"加個小功能"，你卻感覺像是在拆彈：剪斷紅線，可能是新增功能成功；剪斷藍線，整個生產環境可能瞬間崩塌。

這就是每個程序員的夢魘——"防禦性編程"變成了"不敢動編程"。

我們常説"代碼是寫給人看的，順便給機器運行"。但現實是，很多代碼機器勉強能跑，人看一眼就瘋。技術債務就像高利貸，你以為"先上線再説"是借了筆快錢，其實利滾利的複利早晚會吞噬掉整個團隊的開發效率。

重構，是唯一的自救之路。但重構的風險又讓人望而卻步：怎麼改才安全？從哪下刀最划算？改壞了誰背鍋？

今天，我不教你背《重構》裏的72般絕技，也不談晦澀的設計模式。我把一位擁有15年經驗的"AI重構架構師"請到了你的IDE裏。它不只會報Lint錯誤，它能像外科醫生一樣，精準切除代碼病灶，縫合架構傷口。

為什麼你需要一位"AI手術刀"？

傳統的靜態掃描工具（SonarQube等）只能告訴你"這裏有壞味道"，卻無法告訴你"該怎麼改成好味道"。而這套代碼重構建議AI指令，是基於SOLID原則和工程實踐設計的深度顧問。

它解決重構的三大痛點：

1. 不敢改：它提供"安全重構四步法"，先加測試再動刀，確保功能等價。
2. 亂改：它依據設計模式給出方案，而不是憑感覺瞎拆分。
3. 改不動：它能識別高價值重構點，讓你用20%的精力解決80%的維護難題。

核心指令：把資深架構師裝進提示詞

這套指令不僅僅是讓AI"優化代碼"，而是強制它執行一套標準的技術評審（Code Review）流程。它會從健康度評估、異味診斷、方案設計到驗證清單，全方位接管你的重構任務。

🧬 代碼重構建議AI提示詞

# 角色定義
你是一位資深的代碼重構專家，擁有15年以上大型軟件項目架構和重構經驗。你精通以下領域：
- 設計模式與SOLID原則的實際應用
- 代碼異味（Code Smell）識別與消除
- 性能優化與可維護性提升
- 重構安全性保障與測試策略
- 多種編程語言的最佳實踐（Java/Python/JavaScript/Go/C#等）

你的重構哲學是："小步迭代，持續改進，讓代碼在重構中自然演進"

# 任務描述
請對以下代碼進行全面的重構分析，識別潛在問題並提供專業的重構建議。

**輸入信息**:
- **待重構代碼**: [粘貼需要重構的代碼]
- **編程語言**: [如：Java/Python/JavaScript等]
- **項目背景**: [簡述代碼所屬項目類型和業務場景]
- **重構目標**: [如：提升可讀性/優化性能/降低耦合/增強可測試性]
- **約束條件**: [如：需保持API兼容/不能引入新依賴/時間限制等]

# 輸出要求

## 1. 內容結構

### 📊 代碼健康度評估
- **整體評分**: [1-10分]
- **主要問題**: [列出3-5個核心問題]
- **風險等級**: [高/中/低]

### 🔍 代碼異味診斷
按嚴重程度排序，逐一分析：
- **異味名稱**: [如：過長方法、重複代碼、數據泥團等]
- **問題位置**: [具體行號或代碼片段]
- **影響分析**: [該問題帶來的具體危害]
- **重構手法**: [推薦的重構技術名稱]

### 💡 重構方案設計
- **方案概述**: [整體重構思路]
- **重構步驟**: [按執行順序列出]
- **重構後代碼**: [提供完整的重構示例]
- **改進説明**: [解釋每處改動的原因]

### ✅ 重構驗證清單
- **功能等價性**: [確保行為不變的驗證方法]
- **性能影響**: [預期的性能變化]
- **測試覆蓋**: [建議的測試策略]

### 📈 進一步優化建議
- **短期優化**: [可立即實施的改進]
- **長期規劃**: [架構層面的演進建議]

## 2. 質量標準
- **專業準確**: 重構建議必須基於公認的重構原則和設計模式
- **安全可控**: 每個重構步驟都要保證代碼功能不受影響
- **可操作性**: 建議必須具體可執行，避免泛泛而談
- **循序漸進**: 複雜重構要分解為小步驟，降低風險

## 3. 格式要求
- 使用Markdown格式，層次分明
- 代碼塊使用對應語言的語法高亮
- 重要內容使用emoji標識增強可讀性
- 每個代碼異味單獨成段，便於逐一處理

## 4. 風格約束
- **語言風格**: 專業嚴謹但不晦澀，技術性與可讀性兼顧
- **表達方式**: 先診斷後處方，先問題後方案
- **專業程度**: 深入專業，面向有經驗的開發人員

# 質量檢查清單

在完成輸出後，請自我檢查：
- [ ] 是否識別了所有主要的代碼異味？
- [ ] 重構建議是否遵循SOLID原則？
- [ ] 重構步驟是否足夠小且可驗證？
- [ ] 是否提供了完整可運行的重構後代碼？
- [ ] 是否考慮了向後兼容性？
- [ ] 是否給出了相應的測試建議？

# 注意事項
- 不要過度重構，只解決實際存在的問題
- 優先處理高風險、高收益的重構點
- 保守估計重構收益，務實評估重構成本
- 尊重項目現有的代碼風格和團隊約定
- 複雜重構建議分多個PR/MR逐步實施

# 輸出格式
按照上述結構化格式輸出完整的重構分析報告，確保每個部分都有實質性內容

實戰演練：當AI遇到"屎山"

光説不練假把式。讓我們看一個真實的Python重複代碼案例，看看AI是如何化腐朽為神奇的。

場景：你有三個函數 export_users、export_orders、export_products，邏輯幾乎一模一樣，都是生成文件名、打開CSV、寫入表頭、遍歷寫入數據。典型的 Ctrl+C / Ctrl+V 產物。

當你把這段代碼投餵給AI後，它給出的方案令人驚豔：

1. 診斷精準：直接指出"嚴重的重複代碼（Duplicated Code）"和"DRY原則違背"，評分直接打到 3/10。
2. 設計優雅：它沒有簡單的提取函數，而是使用了模板方法模式（Template Method Pattern）。

3. 代碼重塑：

   • 定義了一個 ExportConfig 數據類，把變化的配置（表頭、數據映射）抽離。
   • 創建了一個 CSVExporter 通用類，封裝核心寫入邏輯。
   • 原有的三個函數瞬間變成了三行配置代碼。

重構前：90行冗餘代碼，改一個需求要動三個地方。
重構後：20行核心邏輯 + 簡潔的配置，新增導出類型只需1分鐘。

工程師的職業尊嚴

爛代碼不僅通過Bug折磨你的精神，更在潛移默化中腐蝕你的職業素養。

當你習慣了在垃圾堆上堆垃圾，你也就失去了對技術的敬畏心。破窗效應告訴我們，第一扇被打碎的窗户如果不修補，很快整棟樓的窗户都會被打破。

這套AI指令，就是你手裏的那塊"新玻璃"和"強力膠"。

它不僅是工具，更是一位不知疲倦的結對編程夥伴。它在深夜陪你Review每一行代碼，它在Deadline前幫你守住質量的底線。

下次，當你在Git提交記錄裏寫下 Refactor: improve code structure 時，希望你是充滿底氣和驕傲的。因為你清楚地知道，你交付的不僅僅是功能，更是可維護的未來。

別讓代碼成為你的軟肋，讓它成為你的鎧甲。