論述基礎與限制

本卡抽自 infra 教學模組的溝通層文章重寫。原稿用辦公大樓比喻解釋 VPC / IAM / IaC 等概念給非工程決策者，經作者 review 判定比喻程度過重、反而阻礙溝通。重寫後改為管理視角的情境遞進。限制：evidence 來自單一模組的一次重寫，跨領域（醫療→管理、法律→工程等）的適用性未驗證。

核心原則

向非本領域的專業人士解釋技術議題時，有效的做法是減少術語、讓情境從簡單到複雜遞進。堆疊比喻（「VPC 像辦公大樓」「IAM 像門禁卡」「state 像資產清冊」）看似降低門檻，但有三個結構性問題。

第一，比喻傳遞形狀但不傳遞嚴重性。「VPC 像辦公大樓的圍牆」讓人理解隔離這個概念，但不讓人理解隔離失敗時一個被入侵的服務能橫向存取所有資料庫的商業代價。決策者需要的是後者。

第二，比喻在細節處崩解。辦公大樓沒有 CIDR 地址空間、沒有 peering、沒有跨區冗餘。當討論深入到需要判斷「CIDR 該切多大」或「要不要跨帳號」時，比喻不但幫不上忙，還會成為錯誤直覺的來源 — 讀者開始用辦公大樓的邏輯推斷網路架構。

第三，過度比喻隱含「對方聽不懂」的預設。專業決策者能聽懂「環境描述檔讓系統可以在故障後重建」，不需要先繞到「就像建築藍圖」才能理解。多一層比喻是多一層認知負擔，不是少一層。

情境

infra 教材的溝通層文章原稿用延伸比喻架構整篇文章：

  • VPC = 辦公大樓，有自己的地址範圍
  • Subnet = 樓層分區（public = 大廳，private = 辦公區）
  • Security group = 每個房間的門禁卡設定
  • IAM = 員工證與權限
  • IaC = 建築藍圖
  • State = 資產清冊

每個比喻單獨看都成立，但串在一起時文章變成了一個辦公室管理指南，讀者要在「比喻世界」和「技術世界」之間反覆切換。決策者讀完後記住的是比喻、不是操作風險。

理想做法

用情境遞進替代比喻堆疊。每個技術概念對應到它解決的管理問題，然後從最簡單的情境開始、逐步加入複雜度：

階段情境對應的 infra 能力
1服務掛了，沒人知道怎麼重建環境描述檔（IaC）
2重建了，但不確定跟之前一樣state 追蹤
3測試時的操作打到了正式客戶環境分離
4不知道誰有權限存取什麼身分與權限管控
5出事了，查不到是誰在什麼時候改了什麼變更紀錄

每一行用決策者熟悉的語言：影響範圍（幾個客戶）、恢復時間（幾小時 vs 幾天）、成本（工程師時間 + 停機損失）。這些維度是決策者日常在處理的，不需要翻譯。

情境遞進的優勢是它讓對方在自己的認知框架裡接收新資訊 — 管理者懂「服務掛了要能重建」，從這個已知出發、往「怎麼確保重建結果一致」「怎麼避免測試影響正式」遞進，每一步都建立在前一步的理解上。

沒這樣做的麻煩

  • 記住比喻、忘記風險：決策者開會時說「那個門禁卡的東西做了嗎」，但說不出它解決什麼問題、不做會怎樣。比喻成了一個替代理解的標籤。
  • 比喻限制討論深度：當需要討論「要不要把 production 拆到獨立帳號」時，辦公大樓比喻沒有對應物。討論被迫回到技術語言，之前的比喻投資歸零。
  • 溝通問題被錯誤歸因：推不動 infra 時，團隊以為是「沒解釋清楚」，於是加更多比喻。但問題其實是提案語言跟決策語言的框架不對，不是理解力不足。結果越比喻越偏離決策者的關注點。

判讀徵兆

寫跨專業溝通文件時，如果發現自己在做以下事情，代表可能掉進了比喻堆疊：

  • 為每個技術概念都找一個日常比喻（「X 就像 Y」超過三個）
  • 比喻之間需要互相引用才能成立（「記得剛才說的大樓嗎？這個是大樓裡的…」）
  • 比喻崩解後要補救（「辦公大樓的比喻在這裡不完全適用，但大致上…」）
  • 文章的主要結構是比喻而非情境（H2 標題是比喻物、不是管理問題）

替代方式：每個概念用「它解什麼管理問題 + 不做的後果量級」一句話帶入，需要深入時用情境遞進展開。

跟其他抽象層原則的關係