工程師習慣優化效能：
降低延遲（latency）、減少計算量、壓縮資料、減少 I/O、避免阻塞。
而在內容世界裡，對應的效能參數叫做：
「認知負荷（Cognitive Load）」
它決定：
- 讀者看不看得下去
- 會不會中途跳出
- 會不會收藏
- 會不會互動
- 會不會覺得你「很難懂」
- 會不會關掉你的頁面
- 會不會關掉你的帳號
如果你曾經覺得：
「我明明講得很清楚，為什麼沒人看？」
通常不是內容不好、不是觀點不夠深，
而是：
你的內容太花讀者的腦力了。
工程師跨領域最容易犯的錯，就是無意識提高別人的認知負荷。
🔍 ① 認知負荷 = 理解一段內容需要花費的「運算成本」
用工程語言翻譯：
Cognitive Load = Processing Cost
認知負荷越高，系統越容易：
- delay
- timeout
- drop
- disconnect
你以為讀者是慢慢讀完、慢慢不耐煩？
不。
人類的注意力是瞬斷式的。
只要在某個瞬間覺得「累」，
就直接退出，不會提前告警。
就像 API 在某秒突然 timeout，
不是警告，而是直接掛掉。
🔧 ② 內容中的認知負荷，常來自五種工程因素
我把它整理成工程師能理解的版本：
1. Parsing Cost（解析成本）
句子太長、結構太複雜、太多從句 →
大腦需要 split / tokenize / parse → 很累。
2. Context Switch（上下文切換成本）
你在同一句話塞三個概念 →
讀者需要不停跳 context → 很累。
3. Memory Load（工作記憶負擔）
你一次塞太多資訊 →
大腦的「RAM」滿了 → 很累。
4. Latency（理解延遲）
你用抽象語言、不給例子 →
大腦需要推理 → 延遲 → 很累。
5. Error Handling（矛盾、模糊、需自行揣測）
如果讀者需要自己補意圖 →
就像 exception 要手動 catch → 很累。
當這些「耗能點」累積到某個閾值，
System 1 會直接關掉：
跳出。 不看。 不互動。 不再追蹤你。
不是你的內容不好，
是他的大腦覺得累。
🔥 ③ 使用者不是在「讀你的內容」，而是在「選擇要不要耗能」
內容不是考試題。
沒有義務看完。
使用者只會看：
- 最省力的
- 最容易理解的
- 最快吸收的
- 最不需要動腦的
如果你的文章跟別人的內容相比，
你 = 要花 50 單位腦力
別人 = 只要 10 單位腦力
那答案非常簡單：
他會選 10 單位的。
不因為你不好，
而是人類的大腦天生「省能優先」。
🧪 ④ 如何讓內容「讀起來不累」？（工程師最擅長優化的地方）
你可以把「降低認知負荷」當成一種效能優化：
1. 壓縮資料量（資訊密度清晰、不是塞更多）
不要一次塞 10 個概念，
而是把一個概念講到可理解。
2. 降低 parsing cost（短句、直白、清楚）
你的文章不是語文比賽，
越清楚越強。
3. 善用「預測性排版」
段落先講一個清楚的意圖句 →
讓大腦知道要讀什麼。
4. 用敘事讓大腦「順流」
敘事不是講故事，而是 有順序 的資訊流。
5. 減少 context switch
先講痛點 → 再講原因 → 再講解法 → 再講例子。
讓大腦一次只處理一件事。
🧠 ⑤ 認知負荷越低，內容越容易被「看完、理解、採用」
高價內容靠深度，
但高深度 ≠ 高負荷。
真正厲害的工程師會：
- 把複雜的東西拆簡單
- 把抽象的東西講具體
- 把深度濃縮成易讀的格式
- 把高級概念變成省力的理解體驗
行銷內容也完全一樣。
你不是在炫技，
你是在寫：
給 System 1 能秒讀的格式。
這不是降低智商。
這是提升傳輸效率。
🔚 下一篇將會進入：訊號（Signal）vs 噪音（Noise）
當你降低認知負荷後，
下一個問題是：
哪些訊息是真正有價值的？ 哪些只是噪音？ 你怎麼控制輸出的訊號品質？
下一篇會把這個轉成工程語言。
反思小問
如果把你最近的一篇內容當成效能監控，你覺得它的耗能點落在哪？
