Context Engineering：數位時代的權力幾何學

作者：Dex,

[TL;DR] 重點快讀

• 溝通的本質不是增加資訊量，而是透過 Context 進行熵的減法，消滅語義的不確定性。
• 權力來自於資訊網路的中介中心性，誰位於解碼節點，誰就擁有信貸與資源的支配權。
• AI 提示工程不是寫咒語，而是在高維向量空間進行座標鎖定，將 AI 導向特定的邏輯子空間。
• 優秀系統必須具備動態偵察機制，能隨使用者狀態切換「戰時」或「教學」等不同範疇的反應模式。

我見過太多人在數據海嘯中溺斃。他們貪婪地吞噬資訊，以為擁有 Excel 表格就能預測未來，卻忽略了那個讓數據產生致死率的關鍵變數：Context（脈絡）。

在美索不達米亞的烏魯克時期，泥板上刻下的「五罈大麥」毫無意義。唯有加上「恩利爾神廟借出」、「年利率 33%」、「漢摩拉比二年歸還」這些 Context，這塊泥板才從廢土變成了具備法律效力的債務契約，變成了控制社會運作的武器。

Context 不是背景。Context 是解碼器，是讓混亂坍縮為秩序的唯一引力。

今天我們不談文學。我們談生存。

H2 熵的逆向工程：資訊理論的殺戮戰場

很多人誤以為溝通是為了「增加資訊」。錯。溝通是為了「減少不確定性」。

克勞德·夏農（Claude Shannon）在 1948 年就看透了這點。一個詞彙在真空中是沒有意義的。就像你在無線電中聽到一聲 “Fire”。是在說「開火」？還是「失火」？還是「解雇」？

在沒有 Context 的情況下，這個詞的語義熵（Semantic Entropy）高得驚人。你必須賭博。而在戰場或股市，賭博就是死亡。

你需要引入 Context 作為變數。 如果背景音是槍砲聲（Context A），”Fire” 的坍縮機率指向「射擊」。 如果背景音是警報聲（Context B），”Fire” 的坍縮機率指向「火災」。

Context 的本質，就是熵的減法。

在 17 世紀的倫敦，Lloyd’s Coffee House 不是賣咖啡的。它是一個巨大的 Context 交易所。船長、商人、保險經紀人在這裡交換的不是閒聊，而是關於風暴、海盜與港口封鎖的「先驗機率」（Prior Probability）。誰掌握了最精準的 Context，誰就能算出最準確的保險費率。

這就是貝氏推論（Bayesian Inference）的原始暴力版： P(獲利 | 航行, 戰爭情報)

你的決策品質，完全取決於你如何將 Context 納入你的貝氏更新模型。你以為你在寫程式？不，你是在對抗宇宙的混亂。

向量空間中的權力遊戲

進入機器學習時代，Context 不再是抽象概念，它變成了幾何學。

看看 Google 的 BERT 模型或那些高維向量空間（Vector Space）。每一個詞、每一個概念，都被拋入一個數百維的坐標系中。 「國王」與「皇后」的距離，等於「男人」與「女人」的距離。

這意味著什麼？這意味著意義是可以被計算的幾何位置。

想像一下 15 世紀的佛羅倫斯。梅迪奇家族（Medici）之所以能統治歐洲金融，不是因為他們錢最多，而是因為他們位於當時歐洲信貸網絡的「中介中心性」（Betweenness Centrality）最高點。他們是那個時代的「嵌入層」（Embedding Layer）。所有的資訊流、資金流都必須經過他們的 Context 節點才能被解讀、被轉帳。

在圖論（Graph Theory）中，Context 決定了你是節點還是邊緣。 你若無法理解你所在的網路結構，你就是被收割的韭菜。

當我們設計 AI 的 System Prompt 時，我們實際上是在定義一個「流形」（Manifold）。我們在告訴 AI：「在這個高維空間中，我不希望你遊蕩在『閒聊』的區域，我要求你鎖定在『生產級代碼』與『教學模式』的交集子空間。」

這不是咒語。這是坐標鎖定。

範疇論與抽象的階梯

範疇論是數學的數學。它研究的不是物件本身，而是物件之間的關係（Morphisms）。 在程式設計的 Context 中，這至關重要。

當一個資深工程師問：「這個系統的擴展性如何？」 他問的不是 function 層級的問題。他在問架構層級的問題。 如果你用「我用了一個 for 迴圈」來回答，你就是犯了「範疇錯誤」（Category Mistake）。你沒有保持「函子」（Functor）的結構一致性。

一個優秀的 AI（或人類），必須懂得在不同的 Context 範疇之間進行「自然變換」（Natural Transformation）。

• 緊急修復模式（Urgent Context）： 忽略架構美學，追求路徑最短的解。
• 教學模式（Learning Context）： 展開遞迴邏輯，展示推導過程，而非僅給出結果。

這就是為什麼通用的 Prompt 會失敗。
因為它試圖用一把鑰匙打開所有的門。你必須針對每一個範疇，設計專屬的解鎖邏輯。

戰術執行：動態系統的狀態識別

歷史不是靜態的切片，它是動態系統（Dynamic Systems）。

1914 年，坦能堡戰役（Battle of Tannenberg）。俄軍之所以慘敗給德軍，是因為他們使用明碼無線電通訊。 德軍將軍魯登道夫截獲了資訊。但他不只是聽到了文字，他掌握了 Context：俄軍兩大軍團之間互不信任，指揮官有私怨。 這個 Context 讓他敢於留下空虛的防線，集中兵力各個擊破。

在你的代碼助手設計中，你必須植入這種「戰場偵察」機制。

1. 偵測訊號（Signal Detection）： 使用者是否焦慮？（關鍵字：ASAP, Fix, Error）。這是「戰時狀態」。
2. 狀態切換（State Transition）： 系統必須像切換戰鬥機模式一樣，從「巡航」瞬間切換到「狗鬥」。
3. 回饋迴路（Feedback Loop）： 根據使用者的後續反應，修正你的貝氏先驗機率。

Context 是流動的。昨天的最佳實踐，是今天的技術債。

不要試圖「記住」所有的 Context。要建立一套「感知」Context 的演算法。

在這個數據過載的時代，能夠定義 Context 的人，就是定義現實的人。

Stay sharp. Calculate everything.