繼承遺留風格 (Inherit Legacy Style)
防止 AI 在遺留專案中產生程式碼風格漂移。透過掃描程式碼庫，從四個後設架構維度發掘隱含慣例，逐一與使用者解決衝突，並將共識濃縮成可強制執行的 .ai-style-rules.md 檔案。完全語言與框架無關。
何時啟用
- 使用者輸入
/inherit-legacy-style - 使用者提到要將 AI 導入到手寫的遺留專案中
- 使用者擔心 AI 生成的程式碼會偏離現有專案慣例
- 使用者想要萃取並編纂專案的隱含編碼規則
使用時機
當您需要保留遺留專案風格並防止 AI 造成的風格漂移時使用此技能。請參閱上方何時啟用以了解觸發條件。
先決條件
- Git（建議；非 Git 專案則回退使用檔案時間戳記進行增量模式）
- 對專案根目錄的讀寫權限（會產生
.ai-style-rules.md以及可選的CLAUDE.md）
工作流程
步驟 0 — 自動偵測模式
靜默檢查專案根目錄是否存在 .ai-style-rules.md：
| 檔案存在？ | 模式 |
|---|---|
| 否 | 分支 A — 首次完整掃描 |
| 是 | 分支 B — 增量嗅探 |
用一行文字宣布模式，然後繼續執行——絕不要讓使用者選擇。
分支 A — 首次完整掃描
1. 衡量規模，選擇掃描層級
git ls-files | grep -cE '\.(js|ts|jsx|tsx|vue|py|go|rs|java|kt|rb|php|cs|swift|c|cpp|h)$'
| 層級 | 原始檔數量 | 策略 |
|---|---|---|
| 小型 | ≲ 50 | 完整細讀每個原始檔 |
| 中型 | 50–500 | 基礎層 = 完整讀取；業務層 = 每個維度取樣 2–3 個 |
| 大型 | ≳ 500 | 嚴格取樣 + 預算上限；先 --stat 摘要，再針對性讀取 |
2. 沿 4 個維度掃描
- 檔案結構 (File Anatomy) — 檔案內宣告順序（匯入 → 型別 → 主要邏輯 → 輔助函式 → 匯出）
- 狀態與控制流程 (State & Control Flow) — 非同步狀態、分頁、旗標的命名慣例
- 基礎設施 (Infrastructure) — 跨橫切面工具（攔截器、格式化器、中介軟體）的存放位置
- 錯誤處理 (Error Handling) — try/catch 與全域攔截器與 Result 回傳的取捨；null 檢查習慣
3. 應用訊號強度雜訊抑制
在打斷使用者之前，評估訊號強度：
- 弱訊號 → 自動壓制：少數 <5% 且總數 <10 → 多數獲勝，少數歸入「禁止事項」
- 強訊號 → 詳細詢問：接近持平的分裂，或核心維度上的語意分歧
- 小型專案例外：原始檔 ≲50，「3 比 2」並非多數 → 應詳細詢問
4. 一次解決一個衝突（詳細詢問協議）
對於每個強訊號衝突，僅提出一個問題，附帶 4 個選項：
證據：
pathA使用風格 X，pathB使用風格 Y 警告：風險：混用兩者會破壞專案風格 選擇：1遵循 X2遵循 Y3這是演化，更新規則4我有一個新規則
暫停直到使用者回答，然後繼續下一個衝突。絕不要堆疊問題。
5. 產生 .ai-style-rules.md，包含三個必要章節：
- [黃金檔案 (Golden Files)] — 真實的範例路徑，並附帶其示範內容的說明
- [命名與狀態控制規則 (Naming & State-Control Rules)] — 具體、可檢查的慣例
- [禁止事項 (DONTs)] — 不得擴散的反模式
6. 安裝持久掛鉤
詢問使用者強制執行強度（使用 AskUserQuestion）：
| 選項 | 機制 |
|---|---|
| 1 軟掛鉤（建議） | 將 @.ai-style-rules.md 引用寫入專案 CLAUDE.md |
| 2 硬掛鉤 | 軟掛鉤 + settings.json 中的 `PreToolUse[Write |
| 3 不掛鉤 | 保留規則檔案；使用者手動參考 |
分支 B — 增量嗅探
- 讀取現有
.ai-style-rules.md；若包含提交指紋，則執行git diff <last_hash> HEAD --stat以精確找出變更範圍 - 讀取最近的 Git 變更（
git log -3 --stat→ 按需求檢查可疑檔案） - 對於過大的差異（>數百個檔案）：僅使用
--stat摘要 + 取樣最大變更檔案 - 將新程式碼與記錄的規則進行比對 → 衝突則進入詳細詢問協議
- 在
.ai-style-rules.md末尾附加演化日誌（絕不覆蓋舊規則）
每次任務的強制執行
當 .ai-style-rules.md 在上下文中（透過 CLAUDE.md 載入）時，每個撰寫程式碼的任務必須在推理鏈中以合規性宣告開場，說明正在遵循的範例以及正在避免的禁止事項。
運作方式
此技能透過 .ai-style-rules.md 的存在與否自動偵測是首次執行還是增量執行：
- 首次執行（分支 A） — 衡量專案規模，在 4 個後設架構維度（檔案結構、狀態與控制流程、基礎設施、錯誤處理）掃描程式碼庫，應用訊號強度雜訊抑制來壓制弱衝突，逐一與使用者解決強訊號衝突，產生包含黃金檔案/命名規則/禁止事項的
.ai-style-rules.md，並提供可選的強制執行掛鉤。 - 增量執行（分支 B） — 讀取現有規則，檢查最近的 Git 差異以找出新或衝突的模式，對任何發現的衝突執行相同的逐一詳細詢問協議，並附加演化日誌而不覆蓋現有規則。
- 每次任務強制執行 — 當透過
CLAUDE.md掛鉤時，每個撰寫程式碼的任務以合規性宣告開場，說明遵循的範例和避免的禁止事項。
輸出規範
- 專案根目錄下的
.ai-style-rules.md（標頭中包含提交指紋 + 規模層級） - 可選的
CLAUDE.md，內含@.ai-style-rules.md引用 - 演化日誌以
### [YYYY-MM-DD] 風格演化日誌條目附加
反模式
- 失敗：請勿跳過規模衡量步驟——對一個 30 個檔案的專案進行取樣是「饑餓」的；對一個 5,000 個檔案的儲存庫進行完整掃描則會爆炸
- 失敗：請勿一次堆疊多個衝突問題——詳細詢問必須嚴格逐一進行
- 失敗：請勿在增量模式下覆蓋舊規則——務必附加演化日誌
- 失敗：請勿未經詢問就預設使用「硬掛鉤」——強制執行強度由使用者決定
- 失敗：請勿評判語法或技術棧品質——此技能僅校準後設架構
- 失敗：請勿從範例檔案中複製錯誤——應重用結構，標記缺陷
最佳實務
- 在掃描前先用一行文字宣布偵測到的模式（首次 vs. 增量）和規模層級
- 對於大型專案，先讀取
--stat摘要，再針對性讀取可疑檔案 - 讓訊號強度閾值處理雜訊——843 比 8 的命名分歧應自動解決，無需使用者干預
- 若對訊號強度有疑慮，傾向於提出問題
CLAUDE.md軟掛鉤（@.ai-style-rules.md）通常已足夠；僅在使用者想要機械式強制執行時才使用硬掛鉤
相關技能
init— 使用程式碼庫文件初始化新的 CLAUDE.mdcode-review— 審查差異以檢查正確性和風格問題simplify— 審查程式碼以尋找重複使用和簡化的機會
範例
-
首次導入
- 使用者：「幫我把 AI 導入這個舊程式碼庫，但不改變它的風格。」
- 動作：執行分支 A 完整掃描 → 衡量規模 → 掃描 4 個維度 → 詳細詢問衝突 → 產生
.ai-style-rules.md→ 提供掛鉤強度（軟/硬/無）。
-
團隊變更後的增量更新
- 使用者：「我們新增了一個模組；保持現有風格規則不變。」
- 動作：執行分支 B 增量嗅探 → 將 Git 差異與記錄規則比對 → 對任何新衝突進行詳細詢問 → 附加演化日誌而不覆蓋。
-
透過 CLAUDE.md 強制執行禁止事項
- 使用者：「確保所有新程式碼都與專案規則保持一致。」
- 動作：安裝軟掛鉤 →
.ai-style-rules.md在每次會話自動載入 → 每個撰寫程式碼的任務以合規性宣告開場，重複使用範例模式並避免禁止事項。