Skip to content
• Anonymous

為了讓 AI 更聽話，我刪了 80% 的使用說明書：LLM Core Guidelines 優化指南

深入探討 Prompt Engineering 中的「中間遺忘（Lost in the Middle）」現象，以及為何「原則導向」比「範例導向」在系統提示詞中更有效。

#AI #LLM #Prompt Engineering #Best Practices #System Design

在 AI 協作開發的過程中，我們很容易陷入一個誤區：以為把規則寫得越詳細，AI 就會執行得越完美。

於是，我們的 System Prompt（或如同本專案中的 LLMGUIDE.md）開始無限膨脹。從程式碼風格、命名規範、Git 流程，到每一個細節的 Edge Case 處理，文件從 50 行長到 500 行。

然而，奇怪的事情發生了：文件越長，AI 越容易犯錯。 它開始忽略中間的規則，甚至產生幻覺。為了解決這個問題，我做了一個反直覺的決定：將一份 270 行的詳細指南，重構並刪減為僅剩 33 行的「核心準則」。

結果？AI 的準確率反而提升了。這背後其實有著深刻的技術原因。

1. 為什麼 AI 會「忘記」規則？

要理解這個現象，我們必須談談 LLM (Large Language Model) 處理長文本的機制，以及著名的 「中間遺忘（Lost in the Middle）」 現象。

Lost in the Middle 現象

2023 年，Stanford、UC Berkeley 和 Samaya AI 的研究人員發表了一篇重要論文 Lost in the Middle: How Language Models Use Long Contexts。他們發現，現有的 LLM 架構（基於 Transformer）在處理長 Context Window 時，並非「一視同仁」地關注所有資訊。

模型的注意力機制（Attention Mechanism）呈現出一種 U 型曲線：

  • 開頭（Primacy Effect）：模型對 Context 最開頭的資訊記憶最深刻。
  • 結尾（Recency Effect）：模型對 Context 最末尾（通常是使用者最新的指令）的資訊反應最強烈。
  • 中間（The Middle）：模型往往會「忽略」或「遺忘」位於中間段落的資訊。

當我們的 LLMGUIDE.md 寫得又臭又長時，那些夾在中間的重要規範（例如「i18n 必須使用 data-i18n」或「特定命名規則」），就正好落入了這個「注意力黑洞」。

Token 大爆炸與注意力稀釋

另一個問題是注意力機制的本質。在 Transformer 中，Attention 是透過計算 Token 之間的相關性權重運作的。當輸入的 Token 數量激增（例如一份冗長的文件），模型必須分配有限的「注意力預算」給更多的 Token。這導致每個 Token 被分配到的權重被稀釋，模型更難以分辨哪些規則才是「關鍵且不可違背」的。

因此，精簡（Consiseness）不僅是為了省錢，更是為了讓模型「專注」。

2. 原則導向 vs. 範例導向：誰更勝一籌？

在 Prompt Engineering 領域，經常聽到 “Few-Shot Prompting”（提供少量範例）能提升效果。但在 系統級指令(System Instructions) 中，過度依賴範例反而可能有害。

範例導向 (Example-oriented) 的陷阱

假設我們要規範變數命名，我們可能會這樣寫：

❌ 如果是用戶 ID，請用 userId；如果是產品名稱，請用 productName；如果是訂單列表，請用 orderList…

這種寫法的問題在於：

  1. 過擬合（Overfitting）：模型可能會誤以為只有這些特定的變數需要駱駝峰命名，遇到 customerAddress 時就不知所措。
  2. 缺乏泛化（Lack of Generalization）：模型是模仿者，如果你給的範例不夠全面，它無法推導出未見過的情況。
  3. Token 浪費：列舉所有可能性是不切實際且浪費空間的。

原則導向 (Principle-oriented) 的優勢

優化後的寫法是直接提取第一性原理（First Principles）：

✅ Variables: camelCase

這短短一行字，對 LLM 來說包含了巨大的資訊量。因為 LLM 在預訓練階段已經閱讀過數十億行程式碼，它完全理解什麼是 camelCase。

原則導向的優點：

  • 高壓縮比：用最少的 Token 喚醒模型內在的龐大知識庫。
  • 強泛化力：模型了解「原則」後，可以自行將其應用於任何新情境，無需窮舉。
  • 減少雜訊：清晰的原則如同憲法，簡單明瞭，減少模型解讀歧義的空間。

3. 實戰優化：從 272 行到 33 行

在本專案中，我們對 LLMGUIDE.md 進行了毀滅性的重構。以下是幾個具體的改動案例：

案例 A：Git 規範

Before (冗長)： 解釋了什麼是 Semantic Versioning，什麼是 Major/Minor/Patch，詳細說明每個版號增加的時機，還舉了多個 Git Commit 的例子，甚至教學如何切分支…（約 50 行）

After (精簡)：

## Workflow & Versioning
- Branches: `master` (Prod), `feature/*`, `fix/*`.
- Versioning: `vMajor.Minor.Patch`. **Patch MUST increment for new dates**.

分析：LLM 早就知道什麼是 Git Flow 和 SemVer。我們只需要告訴它本專案的特定約定（例如 Patch 必須隨日期增加），其他的通用知識完全不需要重複。

案例 B：術語對照表

Before (列表)： 一個巨大的 Markdown 表格，列出了「軟體 vs 軟件」、「影片 vs 視頻」等數十個對照，佔據了大量篇幅。

After (壓縮)：

### Taiwan Terminology (Strict)
**❌ Forbidden -> ✅ Correct**:
軟件->軟體, 屏幕->螢幕, 視頻->影片, 數據->資料...

分析：將表格轉換為緊湊的 CSV 格式文本。這不僅大幅減少 Token，更利用了 LLM 對模式識別的強項。它能輕易理解這種 X -> Y 的映射關係。

4. 結論：Less is More

在與 AI 協作的新時代，撰寫文件的方式發生了根本性的轉變。

  • 給人看的文件：需要詳盡、循序漸進、充滿範例，因為人需要學習過程。
  • 給 AI 看的文件：需要精準、高密度、原則性強，因為 AI 已經具備知識，它需要的是約束（Constraints）與對齊（Alignment）。

如果你發現你的 AI 助手開始「不聽話」，試著不要再增加規則，而是開始刪減。去除雜訊，留下信號，你會發現，AI 其實比你想像的更聰明。

關鍵 takeaway:

  1. 重要指令請放在 System Prompt 的開頭或結尾。
  2. 用「原則」喚醒模型知識，而非用「範例」去訓練它。
  3. 相信模型的預訓練知識，不要重複解釋通用概念。