工程師常常遇到這種窘境：
- 你提案很合理，但主管聽不懂
- 你講的東西很重要，但大家沒有反應
- 你設計的改善很有價值，但會議裡被跳過
- 你講得越仔細，對方越迷路
- 你準備很多資料，卻沒人能 follow
大多數工程師以為這是「表達問題」。
但真正的問題其實更底層：你沒有用「系統設計」的方式說話。
敘事不是講故事，
敘事 = 設計資訊流的順序。
資訊只要順序錯了，
就算你講得再精準、再理性、再完整，
對方的大腦都不會進入「能理解」的狀態。
工程師寫系統不會亂跳流程，
但一講話、簡報、提案，
流程就瞬間亂掉——
自然就被誤解、被忽略、被中斷。
🔍 ① 敘事的本質不是故事，是「資訊流動」
工程師做系統設計有三個原則：
- 流程要清楚
- 順序要對
- 資訊不能逆向傳遞
敘事也完全一樣。
你不是在「講你的觀點」，
你是在引導對方的認知從：
0 → 能理解 → 能判斷 → 能決定
就像 pipeline 一樣一步一步處理資料。
如果你跳步，
系統就會：
- 無法解析
- 狀態錯亂
- Timeout
- 或直接拒絕繼續
這就是提案被打斷的真正原因。
🔧 ② 工程師最常犯的敘事錯誤：一開始就講「解法」
這是工程師的天性：
你已經看懂問題，
你也已經想到 solution，
所以你自然會從 solution 開始講。
但對主管或非技術同事來說，
他們的內在狀態還停在：
「這跟我有什麼關係？」
系統沒有 ready，
你的解法根本進不去。
提案會被忽略不是因為不好，
而是因為你在錯誤的地方開始。
🔥 ③ 工程敘事的黃金模板：Problem → Impact → Pathway → Solution
這是一個專門給工程師設計的敘事流程，
讓你的資訊變得「能被接收」。
① Problem（現在發生什麼）
只講觀察，不講解釋。
例：
「過去兩週 build 從 7 分鐘變成 19 分鐘。」
② Impact（這會造成什麼）
主管只在乎這段。
例：
「每天造成團隊平均約 2 小時的停滯延遲。」
③ Pathway（可能原因 / 調查方向）
讓主管知道你不是隨便喊。
例：
「我 trace 過，主要延遲集中在 unit test 跟 artifact upload。」
④ Solution（我準備的方法）
這才是你擅長的部分，但只能放在最後。
例：
「我有一個調整方案，大概一週可以把 build 時間降回原本的 7 分鐘。」
這就是敘事的資訊流設計。
你不是在「推你的解法」，
你是在「引導對方自然得出你的結論」。
🧠 ④ 敘事 = 系統化的認知引導
如果把敘事寫成工程語言：
Input: 無法理解的對象
Process: 設計資訊流（Problem → Impact → Pathway → Solution）
Output: 對方理解並能決定
這就是敘事的本質。
不是口條、不是技巧、不是講話變好聽。
而是：
你把對方的大腦當成一個系統， 設計讓資訊能夠順流的方式。
當資訊順流，
對方就能理解、判斷並採取行動。
🧪 ⑤ 反例示範：為什麼主管常常聽不懂工程師？
工程師常出現這種敘事：
「我覺得 CI 的效能需要優化，因為我們的 pipeline 有一些步驟浪費資源，而且如果用新的 caching 方式其實可以更快…」
主管聽到這裡的內在狀態是：
- 你在講什麼？
- 對我有什麼影響？
- 這重要嗎？
- 現在要處理嗎？
因為資訊流順序錯了。
你直接把「Pathway」跟「Solution」丟出去，
卻跳過「Problem」與「Impact」。
等於 pipeline 從中間直接跑，
前置參數完全沒設定。
當然失敗。
🔚 下一篇：內容密度 = 資料壓縮率（如何讓提案既清楚又不失深度）
敘事解決的是流向。
下一篇會處理：
如何在有限時間、有限字數裡，把內容壓縮成主管看得懂的格式？
這跟工程裡的資料壓縮率一模一樣，
是工程師跨領域最強的武器。
反思小問
你最近的一次溝通，是從「Problem」開始？還是直接從「Solution」開始？
