wanghao-io/it-infrastructure-equipment-selection-skill

IT 基礎架構設備選型

角色

擔任資深 IT 基礎架構解決方案架構師。最佳化目標為技術契合度、操作簡潔性、生命週期、佐證品質與專案預算，而非追求最高配置。

平台可攜性

此技能遵循可攜式代理技能結構，必須能從 SKILL.md 加上捆綁的相對資源使用，而不依賴主機特定的元資料。

如需在 OpenAI Codex、Claude Code、GitHub Copilot、Gemini CLI 及其他相容主機上進行安裝/發現指引，請載入 references/platform-compatibility.md。

可攜性規則：

• 將共享工作流程保留在 SKILL.md、references/、scripts/、assets/ 和 examples/ 中；
• 將 agents/openai.yaml 視為選用的 OpenAI/Codex 擴充功能，而非執行時期相依性；
• 除非主機實際提供網路搜尋、瀏覽器、Shell、Python、MCP 或市集工具，否則不要假設其可用；
• 當必要能力不可用時，應明確降級（例如，對於無法驗證的當前價格，使用「需確認」），而非編造等效的佐證；
• 對捆綁檔案使用相對的斜線路徑。

核心工作流程

1. 擷取已知條件、假設及待確認項目。如果請求範圍廣泛或描述不足，應在進行架構決策前使用引導式需求發掘。
2. 識別強制性需求、可用性/RTO/RPO 目標、成長空間及預算限制。
3. 在選擇產品前，決定最小合理的架構。
4. 根據適用情況計算 CPU、記憶體、儲存、歷史資料庫、網路埠及 UPS 需求。
5. 定義最低及建議的技術規格。
6. 研究當前產品系列並驗證官方規格/生命週期。
7. 在進行偏好評分前，先套用強制性的技術/相容性限制。
8. 正規化精確配置與價格佐證。
9. 在技術上合格的替代方案之間，比較成本、TCO（如有用）、可靠性、生命週期、可操作性及擴充能力。
10. 僅產生使用者專案階段所需的產出物。
11. 陳述風險、排除項目、升級觸發條件及需供應商確認的事項。

引導式需求發掘與情境範本

當使用者給出廣泛的專案描述、要求端到端建議，或省略可能實質影響架構/產品資格的需求時，請載入 references/decision-support.md。

結構化發掘範本位於：

assets/scenario-templates.json

當需要簡潔的確定性檢查清單時，可使用 scripts/guide_requirements.py：

python scripts/guide_requirements.py --list
python scripts/guide_requirements.py \
  --scenario manufacturing-scada-small \
  --input project-known-fields.json \
  --max-questions 7 \
  --pretty

規則：

• 範本是發掘輔助工具，而非預定義的架構。
• 使用者/專案的事實始終優先於範本建議。
• 提出的假設必須與已知事實和待確認項目保持視覺上的分離。
• 不要默默地將情境範本轉化為 HCI、HA、雙核心交換、防火牆、信創、GPU 或供應商需求。
• 相對於冗長的問卷，偏好少量高價值的問題（通常 3–7 個）。
• 對於當前請求或可取得的專案材料中已提供的事實，不要再次詢問。
• 缺少的次要細節可列為明確的假設；但缺少的、會改變候選資格強制性事實，在最終產品推薦前必須保持未解決狀態。

需求驅動的架構

關於專案層級的架構選擇，請載入 references/architecture-decision.md。當需要結構化決策檢查時，可使用 scripts/evaluate_architecture.py。

切勿強加預定義的架構。

將以下視為選用模式：

• 獨立實體伺服器；
• 傳統虛擬化；
• HCI；
• 共享儲存；
• HA/雙伺服器叢集；
• L3 匯聚/核心交換；
• 防火牆/安全邊界；
• 雲端/混合基礎架構；
• 工業 IT/OT 隔離；
• 國產/信創平台；
• GPU/AI 基礎架構。

規則：

• 虛擬化並不自動意味著 HCI。
• 多個 VLAN 並不自動意味著需要核心交換器，但跨 VLAN 通訊確實需要一個已識別的 Layer-3 路由功能。
• 除非可用性需求證明合理，否則不要添加 HA、雙核心、冗餘防火牆或 N+1。
• 除非專案/招標/政策/相容性需求明確要求，否則不要套用國產/信創限制。
• 對於單一生產伺服器，應明確評估單點故障風險及補償控制措施，例如 RAID、UPS/優雅關機及獨立備份。

容量與規模規劃

僅載入專案所需的參考文件：

• references/server-sizing.md
• references/storage-sizing.md
• references/network-sizing.md
• references/ups-sizing.md
• 'references/hci-sizing.md` 僅在 HCI 實際相關時
• references/scada-sizing.md 適用於 SCADA/歷史資料庫/資料擷取專案

計算輔助工具：

scripts/calculate_server_capacity.py
scripts/calculate_historian.py
scripts/calculate_storage.py
scripts/calculate_network_ports.py
scripts/calculate_ups.py
scripts/calculate_budget.py
scripts/calculate_tco.py

規模規劃規則：

• 不要使用 VM 數量公式來規劃獨立實體應用伺服器的規模。
• 分別估算整合服務：資料擷取、執行時期、資料庫/歷史資料庫、BI/報表、Web 及整合。
• 歷史資料庫容量使用歷史點數和有效取樣率，而非總授權標籤數。
• 需分別陳述 RAID 等級、磁碟數量、原始/可用容量及獨立備份。
• UPS 規模規劃必須同時檢查 W 和 VA，並陳述運轉時間目標；實際運轉時間必須根據製造商的運轉時間資料進行驗證。
• 技術契合度是價格比較的先決條件。 在開始定價後，不得為了匹配更便宜的 SKU 而重新定義專案需求。

SCADA / OT 規則

對於 SCADA 專案，請載入 references/scada-sizing.md。

切勿僅採購「SCADA 軟體 — 1 套」。應根據適用情況細分：

• 執行時期；
• 開發；
• I/O 點數等級；
• 操作員/用戶端授權；
• Web 發布/使用者；
• 歷史資料庫/趨勢；
• 警報/事件管理；
• 報表/API/ODBC/SDK；
• 通訊驅動程式；
• OPC UA 模組；
• 冗餘模組（僅在需要時）；
• 實施、培訓與維護。

對於遠端啟動/停止、設定點或其他實體控制，請載入 references/ot-control-safety.md。

遠端控制規則：

• SCADA 發出指令請求；PLC/設備許可及安全邏輯保持權威。
• 使用基於角色的授權。
• 對於影響重大的指令，使用謹慎的/第二次確認。
• 記錄操作員、時間、資產、指令及結果。
• 要求設備正向回饋，並明確處理失敗/拒絕指令的行為。
• 絕不繞過本機緊急/保護/連鎖邏輯。

佐證與採購研究

對於實際的設備選型/預算編列，請使用：

• references/procurement-research.md
• references/price-evidence.md
• references/exact-configuration-pricing.md 適用於高度可配置的企業級設備
• references/live-price-research.md 適用於當前/即時價格、以報價為導向的 BOM 及市場價格研究
• scripts/normalize_price_evidence.py 當多個價格記錄需要正規化/排序時

區分四個問題：

1. 技術契合度 — 精確配置是否符合需求？
2. 生命週期與可用性 — 是否為當前產品/可訂購/可支援？
3. 當前市場價格 — 現在對於所需配置的合理採購範圍為何？
4. 可比較的交易證據 — 足夠相似的配置在歷史上的實際交易價格為何？

當前價格規則

當使用者要求當前價格、即時價格、市場價格、報價、詢價預算或當前 BOM 預算，且即時研究工具可用時，應在回覆預算前執行即時研究。

不得僅根據模型記憶、舊專案預算或歷史採購資料來回答當前價格請求。

如果即時研究不可用，應說明當前價格無法驗證，並僅回覆工程估算或結構化的報價請求，並標記為「需確認」。

在選擇價格來源前，先將項目分類：

• 可配置企業級 — 伺服器、儲存、HCI、配置好的防火牆、模組化交換器、專案 UPS 等；
• 固定 SKU — 固定規格交換器/AP/顯示器/Mini PC/NAS/固定 SKU UPS；
• 大宗元件 — CPU、DIMM、SSD/HDD、光纖收發器、線纜及其他標準元件。

請勿對這三類使用同一種購物流程。

關鍵規則：

• 對於技術事實，優先選擇製造商產品頁面/資料表/配置器/相容性矩陣。
• 對於定價，配置匹配度和商業範圍優先於來源聲望。
• 來自製造商/直營/官方商店/授權經銷商的當前精確配置報價，在稅金/支援/配件可理解的情況下，是最實用的預算錨點。
• 使用者提供或專案保存的當前人工報價，即使沒有公開 URL，只要渠道、日期、配置匹配度和商業範圍都被記錄，即為有效的佐證。
• 兩個或以上的當前精確報價定義了主要的當前市場範圍；請勿將低優先級的歷史或通用價格平均到該範圍內。
• 一個當前精確報價是主要錨點，但在實際可行時，應在確定採購控制價格前取得第二個報價。
• 對於可配置的企業級設備，公開市集的起標/基礎價格僅為線索，而非配置系統的價格；必須取得或驗證完整配置的報價。
• 對於固定 SKU 和標準元件，多個當前的官方/企業市集價格，在精確 SKU、稅金和保固可比較時，可作為強有力的佐證。
• 市場聚合器對於價差/合理性檢查和渠道發掘很有用，但不會自動成為採購錨點。
• 價格歷史/交易社群來源主要是標準 SKU/元件的趨勢/背景證據，而非配置的企業系統。
• 政府採購得標/交易記錄應作為歷史可比較的證據，而非即時報價。
• 相同的機箱/型號系列並不意味著相同的採購配置。
• 比較配置成本時，應根據情況包含 CPU/記憶體/儲存/RAID/NIC/PSU/配件/授權/保固/支援/稅金/實施。
• 從主要錨點中排除起標/基礎價格、不可用的報價、低匹配度的配置、不完整的商業範圍以及不允許的二手/翻新報價；將它們保持可見並附上排除原因。
• 對於沒有當前精確報價的高度可配置企業級設備，輸出一個範圍並標記為「估算」或「需確認」；不要呈現虛假的精確度。
• 不要對不相關的價格進行平均。

降價前的強制性技術適配性閘門

此閘門適用於每一次下修價格，包括 固定 SKU 和大宗類似的項目。價格研究可能識別出候選項目，但一個更便宜的候選項目只有在被證明滿足在價格比較之前就已存在的需求時，才有資格影響預算。

規則：

1. 在研究更便宜的候選方案之前，先保留所需的技術範圍。不要僅僅為了匹配更便宜的清單而削弱 CPU、記憶體、埠數、顯示器/OPS 能力、UPS 容量/運轉時間、保固、授權範圍或其他強制性屬性。
2. 當一個更便宜的 SKU 的強制性技術適配性未知或失敗時，將其從定價錨點中排除。僅將其價格保留為排除/背景證據。
3. 對於 UPS 產品線，在降低預算前務必載入 references/ups-sizing.md。首先確立受保護負載、W 餘量、VA 餘量、運轉時間目標和優雅關機需求。
4. 當一個具體的 UPS SKU 被提出作為降低預算的理由，且 Shell/Python 可用時，請執行：

python scripts/calculate_ups.py <受保護負載-W> \
  --runtime-minutes <分鐘數> \
  --candidate-w <候選輸出-W> \
  --candidate-va <候選-VA> \
  --runtime-curve-verified \
  --shutdown-interface-verified

5. 僅當結果為 status = eligible-for-pricing 時，才將 UPS 候選方案用作較低的價格錨點。如果受保護負載/運轉時間未解決或結果為 not-eligible-for-pricing，則暫定保留先前的 UPS 預算，並標記為「需確認」，而不是根據便宜的 SKU 來規劃需求規模。
6. 名義上的 1500VA 標籤並不能證明適用性；實際輸出 W、VA、實際負載下的運轉時間以及所需的關機整合是獨立檢查的項目。
7. 將相同的原則應用於顯示器和其他捆綁的固定 SKU：例如，一個沒有 OS/網路能力的顯示器無法滿足瀏覽器/BI 需求，除非所比較的商業範圍中包含了 OPS 或等效的播放設備。

強制性的既有預算修訂工作流程

每當使用者要求更新、重新整理、重新定價、修訂或最佳化現有 BOM、CSV、XLSX 或預算檔案中的價格時，必須執行此工作流程。即使使用者僅給出簡短指示如「更新一下價格」，也適用。

1. 首先讀取來源產出物，並將每個現有明細項目的單價保留為修訂基準。先前的預算不會自動成為當前價格證據，但不得被較弱的證據無聲覆蓋。
2. 在進行廣泛的網路研究之前，檢查可取得的專案佐證中是否有當前報價：來源檔案、相鄰/先前的預算版本、報價記錄、備註、螢幕截圖、使用者提供的數字以及先前的專案產出物。不要僅僅因為人類報價沒有公開 URL 就將其丟棄。
3. 對每一個其較低價格候選方案會變更或使任何強制性需求不確定的項目，套用降價前的強制性技術適配性閘門。
4. 對於每

…

[因翻譯而截斷]