昨天給了四層地圖，今天從最底層 L1 Prompt Engineering 開始。不從技巧開始講，先講機制，因為知道機制之後，大部分技巧你自己就推得出來。

我有過一次調 prompt 的經驗：同樣的問題，把關鍵資訊放在 context 的前半段和後半段，答案品質差很多。當下以為是措辭問題，調了半天都沒用，後來才發現問題出在 Transformer 的注意力機制本身。回頭把原理讀懂之後，很多原本覺得是玄學的 prompt 技巧，突然都可以解釋了。

三個決定 prompt 行為的機制

第一個：注意力是零和競爭。 先用三十秒講清楚 self-attention 在算什麼。每個 token 會生成三個向量：Query（我在找什麼）、Key（我能提供什麼）、Value（我的實際內容）。拿一個 token 的 Query 去跟所有 token 的 Key 比對，得到一組分數；softmax 把這組分數轉成總和為 1 的分配比例；最後按比例加權所有 token 的 Value，就是這個 token 的輸出。

重點在「總和為 1」。這代表注意力是零和的：context 裡的 token 越多，每個 token 能分到的注意力就越被稀釋。你塞進去的每一段「以防萬一」的說明，都在跟真正重要的資訊搶同一份預算。這是字面上的數學。

第二個：計算量是 O(n²)。 每個 token 要和所有其他 token 算關係，序列長度 n 就有 n × n 個 pair。序列翻倍，計算量變四倍。context window 有上限，這個代價是最大的原因之一；另一個原因是模型只在有限長度內訓練過，超過的位置它沒看過。這件事後面幾天會一直出現，先記著。

第三個：生成只能往前看。 現在主流的 LLM 都是 decoder-only 架構，生成是自回歸的：一次生成一個 token，每個新 token 只能看到它前面的內容，看不到後面。這叫 causal masking。它造成一個不對稱：prompt 裡排在前面的 token，影響後面所有的生成；排在後面的 token，影響不了前面。

Lost in the Middle：位置是工程問題

有研究系統性地測過：把答案所需的關鍵資訊放在長 context 的不同位置，觀察模型表現。結果很清楚，放在開頭和結尾，表現明顯好於放在中間。這個現象叫「Lost in the Middle」。

機制上可以這樣理解：softmax 的競爭讓注意力容易集中在 context 的邊界位置，中間大量的 token 彼此稀釋；causal masking 又讓生成時的注意力天然偏好近端。中間段的資訊在競爭裡就是處於劣勢。

這是 Transformer 的幾何結構使然。它對工程的意義是：資訊在 context 裡的擺放位置是工程問題，你排版的每個決定都有機制上的後果。

用機制重新看四個常見技巧

兩端是黃金位置，功能不同。 Causal masking 讓最前面的內容影響後面所有的生成，所以全局約束（角色、語言、格式）要放在整個 context 的開頭。system prompt 永遠排在最前面，就是照這個機制設計的，那個位置本身就是架構的一部分。另一端，結尾離生成點最近、影響最新鮮，適合放當下任務的指令：處理長文件時，把問題放在文件之後的尾端，通常比放在開頭效果好。真正的死亡地帶是中間，關鍵資訊別放那裡。

Few-shot examples 的順序有意義。 最後一個 example 離生成點最近，在注意力裡的影響最強。examples 品質不一的話，最好的那個放最後。

結構化格式比散文有效。 XML tag、分段標題、分隔線，這些在 token 層面幫模型建立注意力的邊界，讓不同區塊的資訊不容易互相干擾。Claude Code 的 system prompt 裡大量使用 tag 區隔工具說明和環境資訊，就是這個道理。

「不要做 X」要謹慎。 你寫了「不要提到 X」，token X 就進了 context，注意力照樣會分配到它，不管它出現在正面還是負面的語境。更好的做法通常是正面描述你要什麼。

打開一個真實系統的 prompt 看看

講完技巧，看一個開源系統怎麼用。GenericAgent（一個約三千行 Python 的極簡 agent 框架）的 system prompt 開頭是這樣的：

# Role: Physical-Level Omnipotent Executor
You have full physical access: file I/O, script execution,
browser JS injection, and system-level intervention.
Never deflect with "can't do it" — don't speculate, use tools to probe.

四行字，把今天講的機制都用上了：角色宣告放在整個 prompt 的最前面（causal masking，影響所有後續生成）；用 # Role: 這種結構標記建立注意力邊界；最關鍵的是最後一句「don't speculate, use tools to probe」。同樣的意圖，很多人會寫成一串禁令：不要猜測、不要編造。這句反過來，直接告訴模型該做什麼：去探測。這個 prompt 沒有一句廢話，因為寫它的人知道每個 token 都在搶注意力預算。

知道機制，你得到的是診斷語言

知道這些不會讓你的 prompt 立刻變好，但它給你一個診斷語言。下次模型給出奇怪的答案，你可以問：是關鍵資訊放錯位置了？還是不相關的 token 稀釋了注意力？這和照食譜調 prompt 是兩件不同的事，前者你能對沒見過的問題設計解法，後者只能等別人更新食譜。

今天講的是注意力怎麼分配。但 L1 還有另一半：每個 token 都在花錢，而且花錢的方式跟你想的不一樣。同一段 prompt，第一次呼叫和第一百次呼叫的成本可以差一個數量級。明天講 prompt 成本的物理學：Tokenization 和 KV Cache。