Context Engineering 是一門半套的工程。而半套的那一半，剛好是唯一會讓你有成就感的那一半。
上週，Anthropic 把 Claude Code 的系統提示詞砍掉了超過八成——這件事在圈內炸了鍋。趁大家還在轉發這則新聞，我想先把它講清楚，再告訴你我自己撞到的、這則新聞沒告訴你的那面牆。
Anthropic 做了什麼：把系統提示詞砍掉八成
Claude Code 的工程師 Thariq Shihipar 最近揭露一件事：針對 Opus 5 與 Fable 5 這兩個新模型，他們把 Claude Code 的系統提示詞縮短了超過 80%，而內部的編碼評估沒有測出明顯的性能下降。
先界定清楚，免得你誤讀：刪掉的是大量示例、重複指令，以及過度絕對的限制——不是把 80% 的安全規則都刪了，安全邊界並沒有跟著一起消失。這個界定很重要，因為接下來很容易滑向「新模型很聰明、什麼都不用寫」的危險結論。真正發生的事情更精確：過度規範的成本，開始超過它帶來的收益。
這件事反直覺，是因為從 GPT-3 時代開始，業界被教育的一直是「提示詞要寫得越詳細越好」「把 AI 當成聽不懂人話的實習生，手把手教它每一步」。現在，寫出這套規則的公司自己帶頭把它拆了。
為什麼開始失效
任務的尺度先變了。Anthropic 發布頁援引 Stripe 的早期測試：Fable 5 曾在一天內完成一個約 5000 萬行 Ruby 代碼庫的全庫遷移，Stripe 估計團隊手工做要兩個多月（這算是轉述的客戶案例，雖然轉述的案例可信度應該要被打折，但案例其實是有很多啟發點，繼續看下去）。這種任務不是 IDE 裡按 Tab 補一行代碼能比的——它需要模型真正理解整個專案架構，知道改了這個檔案會牽動哪個模組。
由此帶出一個雙面現實：模型能力變強後，舊時代留下的硬規則反而開始限制它的判斷；但與此同時，太多無關上下文依然會稀釋注意力。這兩件事要一起看才不會走偏——前者說「不要管太細」，後者說「也不能什麼都塞」。答案不是不寫，是寫對。用 Anthropic 工程師的說法：以前那種保姆式的提示詞，現在反而成了限制模型發揮的枷鎖。
「上下文」這個詞本身也一路在擴張：
| 世代 | 代表工具 | 上下文範圍 |
|---|---|---|
| 補全時代 | 最早的 Copilot | 當前打開的檔案，最多加幾個相鄰檔案 |
| 對話時代 | ChatGPT、早期 Claude | 你們之間的對話歷史 |
| 專案時代 | Cursor 這類工具 | 整個代碼庫做成索引，檢索相關片段餵給模型 |
| 生態時代 | Opus 5 / Fable 5 + Claude Code 級 Agent | 系統提示詞＋動態技能＋本地配置＋自動記憶＋豐富引用構成的複雜生態系統 |
到了生態時代，上下文已經不再是簡單的文本堆砌。Anthropic 把構建與管理這整套生態系統的過程，稱為 Context Engineering（上下文工程）。
五個核心轉變
① 立規矩 → 給空間：舊做法把所有邊界條件都堵死——Claude Code 舊版提示詞明確寫著「預設不寫註釋」「絕對不要寫多段文檔字符串」。這樣做有兩個問題：碰到複雜算法或用戶自己的代碼規範時，硬規定會逼出難維護的代碼；而且一個請求裡可能出現互相衝突的指令（系統說不要註釋，用戶說要文檔），模型遇到自相矛盾就會困惑。新做法濃縮成一句話——「編寫與周圍代碼風格一致的代碼：匹配其註釋密度、命名和慣用語法」。因為新模型已具備類似資深工程師的上下文感知能力，不需要逐條教它「遇到 A 情況做 B」。
② 給例子 → 設計接口：餵一堆 Few-shot 示例曾是教 AI 用工具最穩妥的辦法，但 Thariq 指出，對最新模型來說，示例反而可能限制探索空間——它會照貓畫虎，只在給定範例的邊界內打轉（這個判斷限定新模型，老模型該給的示例還是要給）。新做法是把力氣花在接口設計：把 Todo 工具的狀態參數定義成 pending/in_progress/completed 這種自解釋的枚舉型別，模型看到就知道怎麼用，不必寫一長串說明。本質上是回歸軟體工程的老道理——好的 API 設計本身就是最好的文檔。附帶一條原則：同一條要求不用在系統提示詞和工具描述裡反覆強調，放在最相關的位置說清楚一次就夠了。
③ 全盤托出 → 按需加載：這一點對開發 AI Agent 影響最大。舊做法把 CLAUDE.md 寫成百科全書，想把所有坑、所有規範都塞進去；問題是上下文窗口有限，哪怕新模型有百萬 Token 窗口，塞太多無關資訊照樣干擾注意力，還會推高成本（Fable 5 的輸出價格差不多是 Opus 4.8 的兩倍）。新做法是漸進式披露：把代碼審查規則寫成一個獨立 Skill，把資料庫遷移注意事項寫成另一個，模型真的需要時才去調用。不只規則，工具也能按需加載——就像平時寫代碼，主函數保持乾淨，業務邏輯封裝到模組裡按需調用。
④ 手動記憶 → 自動記憶：以前官方建議手動把經驗教訓存進 CLAUDE.md，像帶實習生——每次他犯錯，你都得拿小本本記下來，下次幹活前再讓他看一遍。新做法是 Claude 進化出自動記憶功能，能在工作過程中自己總結經驗，把有用的資訊自動保存，下次工作時自動調取。對開發者最直觀的好處：不用再當那個「記小本本」的人。
⑤ 簡單規範 → 豐富引用：舊做法是寫一份列 1234 步驟的 Markdown 文檔讓模型照做。新模型能處理遠比 Markdown 複雜的參考資料——直接餵 HTML 格式的 UI 原型，比用幾百字描述界面管用得多；扔給它一整套測試套件，讓它照著測試用例實現功能；用 Rubrics（評估標準） 啟動一個專門的驗證 Agent，把你定義的「什麼是優雅的 API 設計」餵給它，讓它去評估主 Agent 的產出符不符合你的「品味」。
別誤讀，也別忽略兩個現實問題
砍 80% 不等於什麼都不用寫。Anthropic 並沒有放棄提示工程，而是再次強調一個範圍更大的概念——Context Engineering（這個概念他們至少從 2025 年就開始系統性地講，不是這次才有的新詞）。分野在於：提示詞只是你對 AI 說的一句話，上下文是它做決策時的全部背景資訊。 很多人抱怨新模型寫的代碼有 bug 或跑不起來，更可能不是模型不行，是給的上下文不對——參考資料混亂、專案邊界不清、該給的資訊沒給。
落地時還會撞到兩堵牆：
- 成本——Fable 5 的輸出價格大約是 Opus 4.8 的兩倍，常見做法是按任務複雜度分流：簡單補全和基礎問答用小模型，只有跨多檔案、需要長程推理的硬核重構才上頂配（這是通用的成本控制思路，不是官方規定的固定架構）。
- 安全邊界——Fable 5 配有額外的安全分類器，部分命中網路安全或生物相關的請求可能被轉交給 Opus 4.8，或在 API 場景下直接返回拒絕。Anthropic 稱這類機制平均在不到 5% 的會話中觸發，但正常開發任務也可能被誤傷，正式接入前一定要實測。
這場轉變可以濃縮成一句底層邏輯：隨著模型推理能力進化，Prompt Engineering 正在向 Context Engineering 演進，這其實是在回歸傳統的軟體工程思維。
你需要考慮的不再是怎麼把話說明白，而是怎麼設計你的上下文架構。
由此延伸出四個自檢問題：你的 CLAUDE.md 是不是只保留了最核心的專案陷阱，不寫模型掃一眼代碼庫就知道的廢話？工具接口是不是設計得足夠自解釋，參數命名和類型定義夠不夠準確？大段的規範是不是拆成了按需加載的模組，而不是一次全部塞進主提示詞？你給模型的參考資料，是模糊的文字描述，還是高保真的代碼和測試用例？把這些工程化問題解決好，比花幾個小時摳提示詞的字眼有用得多。
模型正在變得像一個有經驗的架構師——它不需要你教它寫 for 迴圈，需要的是清晰的專案邊界、高質量的參考實現、合理的工具鏈。門檻正在提高，只會寫簡單 Prompt 的「提示詞工程師」會慢慢失去優勢，真正懂系統架構、懂如何構建高效上下文環境的人，才能榨取出這些頂級模型的全部價值。
這整套邏輯定調成一場範式轉移：從「人寫代碼」到「人設計上下文、AI 寫代碼」。這個新時代繼承了軟體工程裡模組化、接口設計、關注點分離的傳統，卻顛覆了代碼產出的具體方式——AI 不再是打字機，而是工程夥伴。一句話總結：別再用管實習生的方式去管架構師了。
這是 Anthropic 官方的說法，也是這波討論裡大家在轉發的主流敘事。
上週這則新聞傳開時，我的第一個反應不是驚訝，是——他們也撞到那面牆了。一個月前我剛把同一件事寫成自己系統裡的一條紀律，然後在第二十二天，我發現我做錯得比自己想像的離譜得多。
先講清楚我不主張什麼。我沒有發明「上下文工程」這個詞——上面也提過，這個概念業界從 2025 年就在系統性地討論。而且我原本想在這裡寫「我早了一個月」，回頭去查日期，是三週又三天。這種地方我現在會查——為什麼會養成這個習慣，你讀到後面『我撞到的牆』那一節就知道了。
我早的不是那個詞。我早的是另一件事：我在把它寫下來的同一天，就在文件裡留了一句話——只投資輸入、不驗證輸出，會回到樂觀信任的坑。
那句話當時只是謹慎。三週後它變成了診斷書。
所以這篇文章不打算教你怎麼把 context 給對。因為大部分人——包括一個月前的我——問的都是同一題：我該怎麼把 context 給對？
這題問錯了。我花了二十二天才知道錯在哪。
我一個月前寫下的那條紀律，和它刻意選錯的名字
那條紀律的內容很單純：餵給 AI 的資料和任務定義有多好，決定了產出有多好。與其在後面一層一層加把關，不如先把前面餵進去的東西弄對——前面多花一分力氣，比後面多花十分還划算。
但我在命名上刻意繞了一圈。我沒有把它叫做「context 要給齊」，我把它叫做槓桿。
這個選擇本身就是主張。「齊全」暗示的是堆量，是一種可以無限加碼的美德；「槓桿」問的是划不划算，它一開口就承認加到某個點之後，再加就沒用了。
寫在那份文件裡的原話是：
不是「context 越多越好」過載也是病
而是「投資輸入的 ROI 高於投資下游」。這是一個取捨判斷，不是一個堆量指令。
我到今天仍然相信這個結論。這裡沒有反轉，我不打算在文章中段推翻自己的前提。
真正的問題出在同一份文件的最後一段。我在「已知邊界」那一欄寫下：
與「不信 AI 自評」並用才完整
只投資輸入不驗證輸出，會回到「樂觀信任」的坑。二者是互補不是替代。
寫下它的時候，我以為那是一句負責任的免責聲明。我沒想到它會是我三週後的病歷。
這裡標一次證據等級：以上引述來自我自己系統裡的內部設計文件，有版本紀錄、日期可查，但從未公開發表過。它的證據等級是自證。你可以不信，這不影響後面的論證——後面的論證靠的是一組讀數，不是靠這份文件。
兩個時代，兩個問題
過去幾年，我們優化 AI 產出的方式其實只有一種：改寫那句話。
你把提示詞寫得更明確、把邊界條件補得更死、把例子舉得更全。這套做法有一個很少被注意到的前提——失敗是看得見的。產出不對，你回去重讀那段提示詞，措辭的問題就在那裡等你，你找得到它。
而現在這個時代的失敗，不長那個樣子。
現在的失敗長什麼樣？是模型做決定的那一刻，桌上少了一份它該看到的文件——而它照樣做出了決定，照樣講得頭頭是道。
你把提示詞重讀一萬遍，也找不到一份根本沒被放進去的文件。
這兩種問題，你根本不會在同一個地方找到它們。所以我認為這不是「同一個問題變難了」，而是問題本身換了一題。
| 提示詞時代 | 上下文時代 | |
|---|---|---|
| 你在調什麼 | 話怎麼講 | 哪些東西有到它手上 |
| 出問題時長什麼樣 | 講得不夠清楚 | 該給的沒給 |
| 去哪裡找問題 | 重讀那段提示詞 | 提示詞裡找不到 |
| 它會不會自己報錯 | 會——產出明顯不對 | 不會——產出看起來完全正常 |
| 怎麼發現 | 讀一遍就知道 | 只能看產出，回頭猜哪裡少了 |
第四列是這整篇文章的地基，後面所有的結論都從它長出來。請先記住它，後面『這個故事的教訓不是「去檢查你的設定檔」』那一節會回來拆它。
兩個時代各自可以壓縮成一個提問。舊的那個是：
「我這句話講清楚了嗎？」
新的那個是：
「它做這個決定的時候，桌上有什麼、沒有什麼？」
順帶說明一下開場那件事的位置：砍掉八成系統提示詞而評估沒有掉，正是因為被砍掉的東西大多落在措辭層。那是舊時代的資產在新時代貶值，不是新時代的答案——細節前面都整理過了，這裡不重複，有興趣回頭翻上面那一節就好。
我撞到的牆：一個標點符號決定了我的 context 邊界
寫下那條紀律之後，我對自己這一塊的評價其實相當高。
按需載入，做了。分層，做了。單一導航入口，做了。該做的功課我一項沒漏，而且是在別人還在討論怎麼寫提示詞的時候就做完的。如果那時候有人問我「你的上下文工程做得怎麼樣」，我會回答：這一塊我是領先的。
第二十二天，我拿一份外部課綱來對照自己的系統。我不是去抓 bug 的。 我只是順手量了一件從來沒量過的事：每次開工，在我還沒問任何問題之前，已經燒掉多少。
讀數是五萬五千個 token。
這個數字本身沒有嚇到我——系統大，入場費高，可以理解。真正的問題出在往下拆的時候：主要入口設定檔裡的那些引用，多數根本沒有生效。只有少數幾則真的展開了。
原因是程式在讀設定檔時的一個小毛病：引用後面如果緊接一個全形標點，它就把那一整條讀壞、直接跳過。
沒有錯誤訊息。沒有警告。沒有任何一個地方會亮紅燈。它只是安靜地不載入，然後讓一切看起來運作正常。
而錯法不是隨機的。這是最重的一擊——它兩個方向同時錯到底：
一邊，我系統裡最龐大的那份規格文件，每一次對話都整份載入，佔掉入場費的六成以上。而它根本不必每次都在——系統裡本來就有三道機制，會在真的需要時去把它讀進來。
另一邊，我系統裡層級最高的那份安全底線文件——所有紅線的正本——自上線第一天起，沒有進過任何一次對話。
一次都沒有。
你以為你在做 context engineering，其實你的 context 邊界，是被一個標點符號決定的。
哪些東西會進到對話裡、哪些不會——這條線不是任何人畫的。沒有人權衡過、沒有人審過、沒有人簽字。它是程式讀檔時的一個小毛病順手畫出來的，而我在這條線上面建了整套制度。
修法之後，入場費可以降到兩萬九，少掉將近一半。但我要在這裡把話說完整，不然這個數字會誤導你：
第一，你不該帶走 47% 這個數字。 這是 n=1，我自己的系統、我自己量的，不是公開可復現的評測。你的系統不會是這個比例。你該帶走的是失敗的形狀，不是我的數值。
第二，有人會說 caching 讓這筆帳沒那麼嚴重。 對，費用帳會打折。但那份每次全載的文件，佔掉的是 context window 的空間和模型的注意力——cache 讓它變便宜，不會讓它變不存在。 這兩件事要分開算。
這個故事的教訓不是「去檢查你的設定檔」
如果你讀完上一節的結論是「我今晚回去檢查一下我的設定檔」，那我這一節就白寫了。
檢查設定檔會修好那個 bug。但它修不好真正的問題，因為真正的問題不是那個 bug。
真正的問題是這個：
我寫下了 ≠ 它被載入了 ≠ 它起了作用。
這三件事我一直當成同一件事。我寫下了紅線，所以我覺得我有紅線。架構圖上它是最高階的防線，我每次講到自己的系統設計都會提到它。
那它在實際運轉裡是什麼？
答案非常明確——它是裝飾。
一條不遵守也不會被抓的防線，不是防線。而這條防線的狀況更徹底：它連「被遵守的機會」都沒有過，因為它從頭到尾就沒被放進去過。
而它裝飾了多久，我不知道。因為沒有人在量。
同一個系統裡還有一個剛好相反的病灶。我那個放長期記憶的地方，是唯一一個每次都整份塞進去、從來沒套用我自己「需要時才載入」那套規矩的部分。它會擷取、會儲存、會在需要時找出來用——唯獨不會整理。裡面躺著同一件事實的三個舊版本，彼此矛盾，而它們每次都一起被塞進來。
一個該一直在的從來沒在，一個不必一直在的每次都在，一個早該丟掉的一直留著。三種錯法，一個共通點：
沒有任何一個環節，會告訴我它錯了。
這就是前面『兩個時代，兩個問題』那張表第四列的意思。上下文工程出錯的時候，不會有任何東西跳出來告訴你——因為它的錯不是「做錯了什麼」，是「少了什麼」。而少了什麼，是不會發出聲音的。少一份文件，對話照跑、答案照出、語氣照樣自信。
所以，輸入端的品質，只能從輸出端測得。
你沒有第二個地方可以量它。這不是我的偏好，這是這類失敗的物理性質。
為什麼它天生是半套：泵與閥
上一節的結論成立之後，「你也要驗證輸出」就不再是一句勸誡，而是一個事實陳述：不驗證輸出，你就沒有讀數。 你的輸入投資從頭到尾是一場沒有儀表板的實驗。
但這帶出第二個問題，而且是更有意思的那個：既然這麼明顯，為什麼幾乎沒有人做？
不是因為大家懶。是因為結構。
我後來用兩個字來分這兩側——加法側是泵，減法側是閥。
泵的特性是：它不需要誰主動，系統就會長胖。多寫一份文件、多加一條規則、多掛一個引用，每一步都是往上加，而且每一步都有明確的完成感。你今天做了 context engineering，你知道你做了，你甚至可以截圖。
閥的特性剛好相反：它需要有人主動去點火。沒有人點，它就停在那裡，而停著不會有任何症狀。
兩者不對稱。所以——空轉是閥的預設狀態。
判斷一個閥是不是真的在運轉，只有一個測試：它是否曾經真的吐出過一次「收縮」的判決。 從沒吐過的閥，跟休眠中的閥，在外觀上不可分。
現在回頭看主論點。Context Engineering 之所以流行得這麼快、做起來這麼舒服，正因為它整條都坐落在泵那一側。它是一門做了就有進度感的工程。而它對稱的另一半——驗證輸出——你做了只會拿到壞消息。
一邊給你成就感，一邊給你壞消息。你猜哪一邊會被做完，哪一邊會被排到下週？
半套不是說它錯了。是說它單獨使用時，會系統性地讓你高估自己。
最後標一次證據等級：泵和閥是比喻，不是模型。我不會給你一條公式來算「有效 context 比例」——一個講不確定性的東西如果配了小數點，那本身就是自相矛盾。這組比喻的用途只有一個：讓你在看到自己的系統時，能分辨眼前這個東西是會自己長大，還是需要你去點火。
對稱的另一半：別讓同一個 context 給自己打分
那麼「驗證輸出」具體是什麼？
我只講一個機制，不給你技巧清單——因為技巧清單本身就是一種泵。
一次審查要有價值，前提是它得出的結論跟執行者不一樣。如果結論永遠一樣，那次審查沒有產生任何資訊，它只是把已經做完的事再確認一次。
而在同一個對話裡「做完再自己審一遍」，結構上必然得出一樣的結論。原因不是模型不誠實，是它手上的材料跟剛才一模一樣：同樣的前提、同樣的誤解、同樣的盲點。它不是在審查，它是在自己同意自己。
所以換一個乾淨的對話去審，買到的不是「更聰明的審查者」，是一組不同的材料。價值來自差異，不是來自能力。
這一節的存在是為了說明一件事，而這也是整篇文章最終要落在的地方：
同一個東西——context——既是你要投資的資產，也是你要隔離的變數。投資輸入是把 context 做好；驗證輸出是不讓同一個 context 給自己打分。兩件事都在講 context，方向剛好相反。這就是為什麼它們是對稱互補，不是兩條可以各自採納的建議。
就地講代價：如果審查的和執行的是同一家的模型，那它們天生就會犯一樣的錯，換幾個對話都一樣。換對話能消掉的是「材料一樣」造成的盲點，消不掉「出身一樣」造成的盲點。所以最後那一關還是得是人，這不是選配。
代價
我不打算給你一份沒有帳單的建議。上面每一條主張都要付錢，以下是七筆。
| 主張 | 它會怎麼壞 |
|---|---|
| 投資輸入的 ROI 高於下游 | 對探索性任務過早精確化會扼殺發散——在還不知道要找什麼的時候先鎖死範圍。而且「上游再投資 vs 下游補把關哪個划算」常常沒有客觀答案，最後還是人在判斷 |
| 必須驗證輸出 | 閥要人點火，而人會累。 防線真正的死法不是被推翻，是被略過。審查疲勞會讓你開始蓋橡皮圖章——一個從來只吐「通過」的閥，跟沒有閥不可分 |
| 換個對話去審查 | 貴，而且同一家的模型會犯一樣的錯，這種盲點換幾個對話都換不掉。它買到的是不同的材料，不是更好的判斷力 |
| 改成需要時才載入 | 你把成本從每次都付的固定開銷，換成了該讀的時候沒讀到的風險。這是交換，不是免費午餐 |
| 用量測、不靠直覺 | 量測要花時間，而且會顛覆你的直覺。我實測後發現，自己原本認定的兩個「花錢大戶」其實根本不花錢，真正的病根是文件本身一直在變胖——如果我照直覺去修，會修錯地方 |
| 該嚴的才嚴、不必要就放過 | 這條最容易被拿來當偷懶的藉口。 該省的是「為了將來可能用到而先加的東西」，不是該有的防護；在不可逆、碰錢、對外的事情上，多一層不叫過度工程 |
| 這篇文章本身 | 如果你讀完決定去建一套「context 品質評分制度」，你就親手示範了它要防的那個病。修過度工程的藥，不得變成新的過度工程。 本文所有建議的力度上限是「一句自問，追不到就停」 |
最後一列不是自謙，是必要條件。一篇主張「機制會自我膨脹」的文章，如果它自己催生了一套新機制，那它就推翻了自己。
所以何時開泵、何時開閥
到這裡該給的不是答案，是切換的判準。這兩側都不是永遠該開的。
| 情境 | 該做什麼 | 為什麼 |
|---|---|---|
| 一次性、風險低、該知道的都已經在對話裡的小事 | 兩邊都免 | 這種事花力氣準備，收穫小於成本。硬上全套只會變成儀式，還把人搞累 |
| 探索性對話、目標本身就是發散 | 關掉泵 | 過早精確化會殺掉探索。這時候模糊是功能，不是缺陷 |
| 接著上一輪繼續做，該知道的它都還記得 | 泵轉小 | 再餵一次是純浪費，只會分散它的注意力 |
| 多階段工作流、跨 session 移轉 | 泵開滿 | 這是輸入投資報酬最高的地方——定義、載入、打包，四樣都值得 |
| 產出要進到別人手上、或會被拿去做決定 | 閥必開 | 這裡的錯誤不由你承擔，你沒有資格用「我覺得沒問題」結案 |
| 不可逆、碰錢、對外發布 | 閥必開，而且最後一關要是人 | 換個 AI 來審，消不掉它們天生一樣的盲點。這種事情上多一層不叫過度工程 |
| 你發現自己連續三次審查都判「通過」 | 停下來檢查閥本身 | 一個從來沒說過一次「這個該砍掉」的閥，跟沒裝一樣。此刻該懷疑的是機制，不是產出 |
最後一列是我自己現在真的在用的一條。它比任何評分制度都便宜，而且它問的是機制活性，不是產出品質。
結論：你憑什麼知道自己給對了
先換一個鏡頭再給清單。
上一代的問題是 AI 講不聽。這一代的問題是 AI 講得太好聽。
你以為你在設計 context，其實你在設計的是——你看不見什麼。
Context Engineering 不是「讓 AI 更懂你」，而是「讓你更查得出它哪裡不懂」。投資輸入不只是讓輸出變好，而是讓輸出的好壞變得可測。
立即可做的 3 件事
每一件都必須在今天做完，而且必須產出一個讀數。沒有讀數的不算。
- 量一次你的入場費。 開一個全新的對話，什麼都還沒問之前，先問它：「你現在手上有哪些指示和文件？」把它列出來的，跟你以為你給了它的，兩邊比對。讀數＝少掉的那幾份。那就是你以為給了、其實根本沒進去的東西。
- 證明你最重要的那份文件真的在場。 不要去看設定檔，看行為——給它一個那份文件明確禁止的請求，看它擋不擋。讀數是二元的：擋，或不擋。 擋不住就代表它從來沒有進來過，跟你寫得多完整無關。
- 讓審查換一個乾淨的對話。 把你剛才那個對話的產出，複製到一個全新的空白對話，只給產出、不給過程，問「這裡面有什麼問題」。讀數＝兩份評價的差距。如果沒有差距，你的審查一直是裝飾。
長期培養的習慣
- 每加一樣常駐的東西，就同時登記一個退役條件。 泵會自己長，閥要你裝——裝的最好時機是加進去的那一刻，不是三個月後。
- 對你設的每一條規則，登記一句「它若失效，我會在哪裡發現？」 答不出來的那一條，此刻就是裝飾。這句話比任何評分表都短，而且它問的不是「這條規則寫得夠不夠周全」，是「它壞掉的時候，我看不看得見」。
- 把證據等級寫進你自己的筆記。 每寫一個數字，順手標它是實測、是轉述、還是推測。我從 2026 年開始這樣做，三個月後你會感謝自己——這篇文章開頭那句「不是一個月，是三週又三天」，就是這個習慣的產物。
回到最初那個問題
我該怎麼把 context 給對？
這題問錯了。錯在它預設了「給對」是一個做完就會知道的動作。
它不是。輸入端從來不會告訴你它錯了——它只會安靜地少一份文件，然後讓一切看起來運作正常。
該問的是這一題：
如果我給錯了，我會在哪裡、隔多久，發現？
答錯這題的代價，是你花一整年把輸入做到最好，卻始終沒有一個地方會告訴你：你最重要的那份文件，一次都沒有被讀到。
查證與證據等級
本文的主張分兩類，這裡分開交代。
外部事實（可公開查核）
- Anthropic：砍掉 Claude Code 逾 80% 系統提示詞
- Anthropic Engineering：Effective context engineering for AI agents（2025/09/29）——「上下文工程」不是 2026 年才出現的新詞
- Simon Willison 的記錄（2026/07/21）——本文「早三週又三天」的日期基準
自證主張（n=1，不可復現）
前面『我一個月前寫下的那條紀律』引述的設計文件、『我撞到的牆』與『這個故事的教訓不是「去檢查你的設定檔」』兩節的全部讀數（五萬五千 token 入場費、多數引用其實沒被讀進去、安全底線文件從未載入、修法後降至兩萬九），皆來自我自有系統的單次實測，有版本紀錄可回溯，但未公開發表、無獨立第三方驗證。它們的作用是提供一個失敗的形狀，不是提供一組你可以套用的數值。
前面『為什麼它天生是半套：泵與閥』一節的「泵／閥」是比喻，不是可量化的模型，本文不提供公式。
如果這篇讓你想去量一次自己的入場費，歡迎訂閱我的 Newsletter。每週一篇，我會把自己系統裡量到的東西——包含那些量出來很難看的——寫給你看。
