前言¶
代碼庫跑了半年到兩年，通常會進入一種狀態：改動沒有停，但沒人說得清哪裏改得多、哪裏幾乎沒人碰、哪個模塊是事實上的關鍵路徑。靠翻目錄和 git log 心裏有數，但這種判斷很難傳承，也很難在評審時拿出來討論。
架構深化這個 Skill 面向的是另一個問題：不是從零設計架構，而是在已有代碼上找可以「深化」的點——把模糊的地方變明確，把隱式約定寫成顯式約束。它的做法是先掃描代碼庫，再產出一份可視化 HTML 報告，然後對報告裏選定的項逐條追問。下面介紹它的實際能力邊界和啓用方式。
這是什麼¶
一句話定位：掃描代碼庫尋找架構深化機會，生成可視化 HTML 報告，並對選定項展開拷問。
- 名稱：架構深化
- 座標：
@kunlungrowth/improve-codebase-architecture - 版本：1.0.0
- 來源歸屬：enterprise
- 發佈者：崑崙增長
- 分類：dev-programming
- 標籤：
requires_api_key=false - 官方地址：https://www.skillhub.cn/skills/kunlungrowth/improve-codebase-architecture
需要 API Key 嗎？不需要。標籤裏明確寫了 requires_api_key=false，這是它和一類依賴外部模型服務的 Skill 的差別，本地跑不涉及密鑰配置。
核心能力¶
資料裏給出的能力是兩條，沒有更多：
- 掃描代碼庫，找出「深化」機會。
- 產出可視化 HTML 報告，並對選定項拷問。
「深化機會」在官方簡介裏沒有逐項定義。從名稱和流程推斷，它指向的是讓現有結構更明確的方向，例如分層邊界、模塊職責、隱式依賴方向。具體命中哪些項，需要實際跑一遍才能確認，這裏不替它預設清單。
輸出形態是 HTML，不是終端裏的一段文字。這點值得先說明：報告要打開瀏覽器看，意味着它面向的是需要拿給人看、需要在評審會上討論的場景，而不是隻想快速過一眼結論的場景。
「拷問選定項」是流程的後半段。報告給出候選之後，可以就其中某一項繼續追問。追問的具體形式，資料未展開。
安裝與啓用¶
官方資料沒有給出安裝命令、目錄約定或配置字段。可以確認的只有座標和頁面：
座標: @kunlungrowth/improve-codebase-architecture
頁面: https://www.skillhub.cn/skills/kunlungrowth/improve-codebase-architecture
版本: 1.0.0
這類 Skill 基於通用 SKILL.md 格式，通常放入對應 Agent 的 skills 目錄後即可被識別。但具體路徑、是否要在配置文件裏註冊、Cursor 與 Claude Code 的目錄差異，本資料沒有覆蓋，不在這裏編造。啓用方式請以官方頁面爲準。
有一個數據值得留意：截至資料抓取時，下載量 1216，安裝量 0。安裝量爲 0 意味着還沒有人真正把它接進自己的環境，遇到問題時難以在社區找到現成的排查記錄。
典型用法¶
資料沒有提供可復現的官方示例，以下流程按簡介描述的三步給出，供實際使用時參考：
- 在 Agent 裏發起掃描，輸入目標代碼庫路徑。這一步做的是全庫掃描，產出候選深化點。
- 打開生成的 HTML 報告，瀏覽可視化結果。
- 選定其中一項，繼續追問，直到得到明確結論。
命令行層面的具體寫法，資料未提供，這裏不虛構。
適用場景與注意¶
適合的場景：
- 代碼庫已經有一定規模，架構靠口頭約定維持，需要把約束顯性化。
- 有評審或交接需求，需要一份能打開瀏覽器討論的產出物。
- 不想從零做架構設計，只想在現有結構上找改進點。
不適合的場景：
- 空倉庫或只有少量文件的項目，掃描沒有足夠信息可挖。
- 需要精確到函數級調用鏈分析的場景，資料未說明它能做到這個粒度。
需要注意的點：
- 它的產出是一份報告加後續追問，不是自動改代碼。深化之後的實際重構仍要人工完成。
- 評分顯示爲 100000（資料抓取時數據），下載量 1216，安裝量 0。樣本量很小，評分參考價值有限。
- 抓取時間點爲 2026-11-04，上述數字可能已經變化。
結尾¶
架構深化做的事情不復雜：把代碼庫裏「說不清楚爲什麼這樣分層」的地方找出來，攤成 HTML，然後逐條追問到能落地爲止。它的價值在於產出的形態——一份能拿去討論的東西，而不是一次改完就消失的代碼改動。
官方地址：https://www.skillhub.cn/skills/kunlungrowth/improve-codebase-architecture
