前言¶

做架構設計最常見的兩個坑：一是還沒想清楚體量、團隊和演進速度，就直接在單體和微服務之間做選擇；二是隻畫一張模塊圖，可用性、擴展性、安全、可觀測性這些非功能性目標沒人認領。下面介紹的這個 Skill，就是把這兩件事系統化：先從需求出發定約束，再對比候選架構的權衡，最後用 C4 和時序圖把結論表達清楚。

這是什麼¶

軟件架構設計是一個社區發佈的通用 SKILL.md 格式 Skill，座標 @user_af163eaa/z-dev-architecture，發佈者 user_af163eaa，當前版本 1.0.1，分類 dev-programming。它不生成代碼，而是提供一套設計方法論：在動手寫框架代碼之前，幫你把需求驅動的約束、候選架構的權衡、質量屬性的目標和驗證方式理清楚。

核心功能¶

1、需求驅動定約束。把體量、團隊規模、演進速度作爲輸入，而不是先選技術棧。體量決定部署單元的數量級，團隊決定溝通成本和邊界劃分，演進速度決定重構窗口和耦合容忍度。

2、候選架構對比。圍繞單體、微服務、事件驅動、Serverless 四類形態展開權衡，關注各自的適用前提、運維複雜度、故障域和一致性成本，而不是簡單羅列優缺點。

3、質量屬性清單。把可用、擴展、安全、可觀測這幾項明確到可驗證的程度：可用性對應故障域和降級路徑，擴展性對應瓶頸點與水平擴展能力，安全對應信任邊界和數據暴露面，可觀測性對應指標、日誌、鏈路三件套。

4、用圖表達結論。建議用 C4 模型分層表達靜態結構，用時序圖表達關鍵鏈路的調用和失敗路徑，避免一張大圖說不清邊界和時序。

安裝與啓用¶

官方頁面未公開統一的 CLI 安裝命令，Skill 以通用 SKILL.md 格式提供，需要按宿主環境的規則加載。

Cursor / Codex CLI / Claude Code 三者的加載方式不同，官方資料未分別給出命令，這裏不做推測。覈實不到的部分請以官方頁面爲準：

https://api.skillhub.cn/user_af163eaa/z-dev-architecture

https://www.skillhub.cn/skills/user_af163eaa/z-dev-architecture

使用前建議確認兩點：一是 Skill 的 requires_api_key=false，不依賴外部付費模型接口；二是宿主工具能否正確讀取 SKILL.md 的元數據和正文。

典型用法¶

下面是從官方簡介可以推導出的復現路徑，按順序執行即可。

1、先給出體量、團隊人數、迭代節奏三句話。例如：服務數在 3 到 5 個，團隊 6 人，每兩週一次發佈。這三句決定後面選型的天花板。

2、再列出候選架構形態。單體、微服務、事件驅動、Serverless 各寫一行適用前提和一條主要代價，不要只寫名字。

3、然後按質量屬性逐項打勾。可用性寫清故障域和降級路徑，可觀測性寫清指標、日誌、鏈路分別覆蓋哪些鏈路，安全寫清信任邊界。

4、最後補兩張圖。一張 C4 上下文圖說明系統邊界和外部依賴，一張時序圖說明關鍵鏈路的調用順序與失敗分支。

適用場景與注意¶

適合的場景：新項目立項階段需要一份能評審的架構說明；現有系統要拆分或重構，需要先把約束和質量目標寫清楚；跨團隊討論時需要統一語言和圖表表達。

需要注意的地方：這是方法論類 Skill，輸出的是決策和文檔，不替代代碼驗證。選型結論仍然要拿真實負載和故障演練去檢驗。另外，微服務、事件驅動、Serverless 的代價往往在運維和排障上，別隻看開發期效率。團隊規模小、服務邊界不穩定時，單體加模塊化往往比微服務更合適。

結語¶

這個 Skill 的價值在於把架構設計從經驗判斷變成可評審的流程：先定約束，再比權衡，然後落到質量屬性和圖。它不替你做決定，但能讓你把決定的原因寫清楚。

官方地址：https://api.skillhub.cn/user_af163eaa/z-dev-architecture