Community研究與資料分析github.com

vlaskos/brief-to-architecture

將原始需求摘要、RFP、探索記錄或功能規格轉換為架構等級的分析報告,提取出架構顯著需求,並依功能、品質屬性與限制條件進行分類與優先排序。

brief-to-architecture 是什麼?

此技能專為 AI 代理(如 Claude Code、Cursor 或 Codex)設計,用於將非結構化的需求輸入(如簡報、RFP、探索通話記錄、啟動文件或功能規格)轉換為嚴謹的架構分析。它採用六步驟流程:提取真實需求、分類為功能性/品質屬性/限制條件、精煉成可測試的條目、根據業務價值與架構影響進行優先排序、檢查高優先級需求之間的內部矛盾,最後撰寫可衡量的品質場景並選擇相應的設計策略。該分析以 ISO/IEC 25010 品質模型為基礎,確保全面覆蓋各品質維度,並提供共享詞彙。支援 detecting logical fallacies(如隱藏的假設、矛盾數字),並以「改變架構的關鍵問題」作為產出,使後續的溝通與估算更具依據。

相容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/vlaskos/brief-to-architecture/tree/HEAD

Installed? Explore more 研究與資料分析 skills: affaan-m/uspto-database, affaan-m/scholar-evaluation, affaan-m/literature-review · View all 6 →

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

ASR 分析

一份簡報並非規格,它是一堆願望、假設和半陳述的限制條件,而隱藏其中的少數需求,才會真正決定系統的形狀與成本。此技能負責找出這些需求,使其精確,並在任何人承諾估算或設計之前,先相互檢查它們。

架構顯著需求(ASR) 是指對架構有可衡量影響的需求:滿足它會強迫做出結構性選擇、限制某項技術、設定難以達成的品質門檻,或與其他需求產生交互作用,從而限制你的選項。簡報中的大多數需求 並非 架構顯著。任務是從眾多需求中分離出關鍵的少數,並說明每個需求為何重要。

品質屬性方面的工作基於 ISO/IEC 25010,這是一項國際標準產品品質模型。使用標準的品質特性集合,能確保每次分析完整(每次都檢查相同的維度),並為所有人提供共享詞彙。請參閱 references/quality-model.md。

流程

將簡報執行六個步驟。每個步驟產出的產物,供下一步使用。

  1. 提取,而非轉錄。 閱讀原始輸入,提取出真正的需求,包括那些以功能、抱怨或隨口提及的方式陳述的需求。像「我們的黑色星期五流量是平時的 40 倍」這句話,並非功能請求;它其實是效能和可擴展性的需求。需要進行解讀。請參閱 references/asr-framework.md,了解如何辨識什麼是架構顯著的。

  2. 分類。 將每個提取的需求歸入以下三類之一:

    • 功能 — 系統必須 做 什麼。
    • 品質屬性 — 系統必須做到多好(效能、可靠性、安全性、可維護性……)。使用 ISO/IEC 25010 特性,確保每次檢查同一套維度 — references/quality-model.md。
    • 限制條件 — 固定、不可協商的邊界(強制採用的技術、法規、截止日期、現有系統)。限制條件不在設計討論範圍內;它們會塑造其他一切。
  3. 精煉。 將每個顯著需求重寫為無歧義且可測試的形式,並說明其 架構意涵 — 認真對待它時所產生的結構性後果。剝離作者偷偷塞入的解決方案(「使用 Kafka」是提議的機制,而非需求;真正的需求是其背後的吞吐量或解耦能力)。無法測試的需求,你就無法估算。

  4. 雙軸優先排序。 並非每個 ASR 都值得同等關注。根據以下兩點進行排名:

    • 業務價值 — 結果對客戶的重要性。
    • 架構影響 — 它對設計的限制程度,以及逆轉的成本(高影響關乎 不可逆性與爆炸半徑,而非工作量)。 兩者皆高的需求,才是真正決定架構的地方。將分析重點放在此處。請參閱 references/scenarios-and-priorities.md。
  5. 檢查可行性。 在設計任何東西之前,先檢查高優先級需求能否 共存。最危險的簡報往往內部矛盾:一個延遲目標、一個一致性目標和一個成本上限,不可能同時成立。請參閱 references/feasibility-check.md,了解具體方法,包括針對數值需求的算術方法。

  6. 制定場景並選擇策略。 針對高優先級的品質屬性,撰寫 可衡量的品質場景(觸發條件、環境以及可衡量的回應),然後選擇能滿足每個場景的 設計策略,並附帶其成本。請參閱 references/scenarios-and-priorities.md 和 references/design-strategies.md。

使分析值得信賴的原則

  • 發覺氣味。 簡報中存在反覆出現的失敗模式:模糊的誇大用語、隱藏的假設、沒有單位或來源的數字、相互矛盾的需求。references/brief-smells.md 是這些模式的目錄,以及當你發現時應提出的問題。
  • 標記每個假設。 當簡報未說明而你填補了空白時,請標記它:是 填補空白(資訊缺失,你提供了預設值)、解讀(模稜兩可,你選擇了一種理解),還是 範圍縮減(你刻意排除了某些東西)?建立在未標記假設之上的估算,不過是穿西裝的猜測。
  • 以改變架構的問題作結。 一份良好分析的產出,應包含兩到三個答案最能改變架構的問題。這些問題應成為下次客戶溝通的焦點。
  • 估算的可辯護性,完全取決於其背後的基礎分析。 這正是為什麼分析必須先行:它是你提供給客戶的數字能夠站得住腳的原因。

如何使用此技能

  • 對簡報進行端到端分析 → 執行上述六步驟流程。
  • 判斷什麼是架構顯著的 → references/asr-framework.md。
  • 選擇並涵蓋品質屬性 → references/quality-model.md(ISO/IEC 25010)。
  • 撰寫可測試的品質場景並進行排序 → references/scenarios-and-priorities.md。
  • 根據品質屬性選擇設計方法 → references/design-strategies.md。
  • 發現矛盾與不可能組合 → references/feasibility-check.md。
  • 批判性地閱讀簡報 → references/brief-smells.md。
  • 塑造書面交付成果 → references/output-template.md。

相關技能