你以為在指揮 AI，其實 AI 才在限制你的想像力

作者按：這篇文章的靈感，來自 Claude Code 核心開發者 Thariq Shihipar 最反直覺的一個觀察：我們花了大量時間讓 AI 變得更聰明，卻幾乎沒有時間去想 — — 我們到底讓 AI「看到」了什麼。

一個奇怪的下午

某個下午，一位後端工程師盯著終端機畫面，越看越不對勁。

他在用 Claude Code 修改一個認證模組（authentication module）。流程很清楚：找到舊的 JWT 驗證函式，換成新版邏輯，跑測試，收工。他輸入了指令，agent 動了起來，幾秒後回傳一段程式碼，說「已完成修改」，還附上了「修改後」的函式片段。他切到檔案一看 — — 什麼都沒動。

他以為自己哪裡弄錯了，重跑一次。agent 再度信心滿滿地說改完了，貼出的程式碼看起來也對。他再看檔案 — — 還是原樣。

他後來花了 40 分鐘才找出真正的問題：agent 「修改」的，是另一個同名函式的 mock 版本，那個檔案在先前的對話裡被提到過，還留在上下文窗口（Context Window）裡。agent 沒有「找到錯的地方」，它只是「看見了什麼，就改了什麼」。它的世界裡根本沒有那個真正需要被修改的認證模組。

這不是幻覺（hallucination）問題，不是模型能力問題，也不是 prompt 寫得不夠清楚的問題。這是一個感知問題。

Claude Code 的核心開發者 Thariq Shihipar 說過一句話，精準地描述了這個現象：「大多數 agent 失敗，不是因為模型不夠聰明，而是因為 agent 根本沒看到它需要看到的東西。」這一句話，顛覆了我對整個 AI 開發框架的很多理解。

上下文窗口不是技術限制，是認知邊界

在討論 Thariq 的核心洞察之前，我需要先說清楚一個區別，因為這個區別決定了兩種截然不同的設計哲學。

大多數工程師把上下文窗口理解成一個技術指標，就像電腦的 RAM 容量：越大越好，滿了就需要清理或壓縮。這個理解沒有錯，但它讓人自然而然地把問題定義為「如何讓 agent 記住更多東西」，優化方向就變成了擴充容量、改善記憶體管理、做更好的 context compression。

Thariq 的理解不一樣。他把上下文窗口看作 agent 的「感知邊界（perceptual boundary）」。

感知邊界這個詞，借的是認知科學的語言。它指的是一個系統在任何給定時刻能夠「意識到」的資訊範圍。青蛙的眼睛對移動的物體高度敏感，但幾乎看不見靜止的東西 — — 這不是因為青蛙的眼睛性能差，而是因為它的感知邊界就是這樣設計的，對生存有利。AI agent 也一樣：它的感知邊界，就是當前上下文窗口裡有什麼。窗口外的東西，對它而言和不存在沒有兩樣。

這個框架轉換，讓問題從「如何讓 agent 記住更多」變成了「我希望 agent 在執行這個任務時感知到什麼」。哪些資訊應該在它的視野裡？哪些資訊應該被擋在視野外？這是兩個完全不同的工程問題，後者要難得多，也重要得多。

Thariq 把這個概念稱為「像代理人一樣觀察（Seeing like an Agent）」。他的論點是：要有效地使用或設計 AI agent，你必須先學會從 agent 的感知視角看世界，而不是從自己的全知視角往下看。

這個洞察和他的成長背景有關。Thariq 在 MIT 媒體實驗室（MIT Media Lab）念研究所，那裡的訓練強調「從使用者的感知出發設計工具」，而不是「從功能出發」。後來他創辦了桌遊平台 One More Multiverse，拿了 Y Combinator 2020 冬季班（YC W20）的投資，最終在 A 輪募到了 1,750 萬美元。他還深度參與過 PubPub，那是 MIT 媒體實驗室和 MIT 出版社聯合創立的開放學術出版平台，核心概念是「把知識生產的過程透明化、互動化」 — — 這和他後來設計 AI agent 的哲學一脈相承。

一個從遊戲設計、開放知識、學術研究橫跨到 AI 工程的人，思考方式自然不像傳統軟體工程師。他在 Anthropic 的工作，很大程度上是把「系統設計的認知科學」帶進了 AI agent 的工程實踐。

Thariq 給過一個具體數字：在 Claude Code 的實際使用中，上下文窗口達到 10,000 到 20,000 個 token 時，是多數 agent 任務的有效工作區間。超過這個範圍，agent 的表現不是線性下降，而是出現跳崖式崩落。這個現象的原因不難理解：當上下文窗口裡充滿了大量資訊，模型需要花更多的注意力（attention）資源在「找到相關資訊」上，而不是「做出好決策」上。信噪比（signal-to-noise ratio）下降，判斷品質就跟著下降。

這個數字背後有一個設計要求：一個 agent 的有效感知空間非常有限，你必須主動管理它的感知邊界，而不是放任資訊累積，希望模型自己「挑出重要的看」。

我自己測試過一個反差明顯的例子。同樣是請 Claude Code 修改一個複雜元件，在乾淨的上下文（只放相關檔案、清晰的任務描述）裡，第一次就做對的機率很高。但當我在同一個對話裡先跑了幾個不相關的任務，上下文裡充滿了前幾次任務留下的 log 和片段，再問同一件事，agent 開始出現奇怪的行為 — — 它會「借用」前一個任務的變數名稱邏輯，把不相關的假設帶進來。模型沒有變笨，它只是在雜訊更多的感知環境裡工作。

這讓我重新理解了 Claude Code 裡「開新對話（new session）」這個動作的意義。很多人習慣在一個漫長的對話裡做所有事，捨不得開新的。但有時候，開新對話的目的不是「整理思路」，而是「清理感知邊界」 — — 給 agent 一個乾淨的、信噪比高的起點。

這是一個反直覺的操作：有時候，「忘掉」比「記住」更有效。

「prompt 要寫好」，你在解決什麼問題？

我觀察過很多認真使用 Claude Code 的工程師，他們花最多時間在哪裡。答案幾乎一致：反覆調整 prompt。

這個答案本身沒問題，但它暴露了一個更深的工作模型：大多數人把 prompt 當成一個「咒語」，試圖透過調整措辭，「撞」到讓 agent 正確執行的組合。改一個詞、換個語氣、加幾個例子，測試，再改，再測試。這個循環可能持續幾個小時。

Thariq 的觀點比這個深一層：好的 prompt 不是讓 agent「聽懂你的話」，而是讓 agent「看到它需要看到的世界」。

這是兩個截然不同的任務。前者假設問題在語言層面 — — 你說的話不夠清楚，所以 agent 做錯了。後者假設問題在感知層面 — — agent 感知到的資訊環境不對，所以就算你說得再清楚，它也做不出正確決策。

多數時候，問題是後者。

他給了一個非常具體的工具來處理這個問題：CLAUDE.md。

CLAUDE.md 是 Claude Code 的專案設定檔。表面上功能很簡單，你在裡面寫下這個專案的架構原則、程式風格規範、build 命令、常見地雷和注意事項。但 Thariq 把它稱為「專案的 DNA（project DNA）」，這個比喻點出了它真正的設計意圖。

DNA 不是說明書。說明書是給人讀的，在你需要的時候查閱，讀完就放下。DNA 是細胞每次分裂時都必然讀取的基礎資訊，它定義了細胞的「默認行為模式」。一個有正確 DNA 的細胞，不需要有人每次指揮它「現在分裂、現在生產蛋白質」，它知道在什麼情況下做什麼。

CLAUDE.md 的設計哲學完全相同。它不是要你把所有規範塞進去，而是要把那些「如果 agent 沒看到，就一定會出錯」的核心約束，放在它每次啟動都必然讀取的位置。

這解決了 Claude Code 使用中一個根本性的痛點：跨 session 的失憶問題。

Claude Code 的每一次對話都是全新開始。agent 不記得上次你說這個專案用的是哪個 Node.js 版本，不記得你說過「不要自動提交」，不記得上週踩過的那個 API 版本相容性問題。如果你沒有把這些資訊固化在環境裡，每次對話就都得重新說一遍 — — 或者你忘了說，agent 又踩了同一個坑。

CLAUDE.md 把這些資訊從「你腦子裡的知識」轉移到「agent 每次都能感知到的環境」。用 Thariq 的話說：「環境即記憶（environment as memory）。」

這個概念的工程意涵比表面看起來更深。它改變了你的優化方向：與其試圖讓 agent 變得更聰明、記憶力更好，不如把重要資訊設計成環境的一部分，讓它每次都能「看見」。

這個思路和 Claude 4 Opus 在 SWE-bench 上拿到 72.5%、Terminal-bench 上拿到 43.2%（行業平均約 25%）有直接關係。Thariq 提到，這些分數背後，模型能力當然是原因之一，但 Anthropic 的工程團隊花了同等力氣在設計評測環境本身 — — 確保模型在每個任務時刻能感知到正確的資訊。測試環境的感知設計，和模型本身一樣重要。

軌跡回饋：讓 AI 對自己做「審訊」

有一次，一個工程師朋友跟我描述他第一次用軌跡回饋（Trajectory Feedback）除錯的體驗，他說：「就像突然能問嫌疑人『你為什麼這麼做』，然後得到一份真實的供詞。」

軌跡回饋是 Thariq 在 Claude Code 內部大量使用的除錯技術，邏輯其實很直覺。

傳統的 AI 除錯方式是這樣的：agent 做錯了，你不知道為什麼，於是你改 prompt，重跑，看結果，再改。這個迴圈的問題在於：每次重跑，agent 都是在新的狀態下執行，你永遠不知道「改了這個詞」和「結果變好了」之間，是不是真的有因果關係，還是只是隨機波動。

軌跡回饋的做法完全不同：當 agent 執行了一個你覺得不對的行為，你不是去改 prompt，而是把這次執行的完整歷史 — — 每一步的輸入、輸出、工具呼叫（tool call）、決策過程 — — 全部打包，放回給模型，然後問它：「看看你做了什麼，解釋一下為什麼在第 X 步你選擇了這個路徑，而不是另一個。」

Thariq 的觀察是：agent 在「回顧（retrospective）模式」下分析自己決策的品質，遠遠高於它在「執行（execution）模式」下做正確決策的能力。

為什麼會這樣？又回到了感知邊界。在執行模式下，agent 每一步只「看到」當前的即時狀態。它不知道三步前它做了一個假設 — — 比如「這個變數名稱應該是 user_id」 — — 到了第七步，這個假設已經不成立了，但它還是按照那個假設繼續走。它看不見這個矛盾，因為那個假設的起點已經不在當前的感知視野裡了。

但在回顧模式下，完整的執行軌跡都在上下文窗口裡。agent 可以「看到全貌」：看到第三步的假設，看到第七步的結果，看到兩者之間的矛盾。在這個時刻，它的表現明顯好很多 — — 因為它的感知邊界裡有了它真正需要的東西。

這個技術有三個直接的應用場景：

除錯（debug）：agent 做出了奇怪的決策，你不知道為什麼。把完整的執行軌跡給它看，讓它解釋每個步驟的理由。你通常會在它的解釋裡找到問題所在 — — 它在某個時刻做了一個錯誤假設，後面的行為都是從那個假設推導出來的。

改善（improvement）：任務完成了，但結果差強人意。把執行歷史給它，問它「如果重來一次，哪個步驟你會做得不一樣，為什麼」。這比你自己猜測「哪裡的 prompt 要改」要精準得多。

驗證（verification）：不確定 agent 的改動是否符合你的期望。讓它逐步說明每個決策的理由，你可以在這個過程中發現它的思路和你預期的分歧在哪裡。

這裡有一個反直覺的地方：讓 AI「回顧自己的錯誤」比「一次就做對」更有效。在傳統軟體工程裡，這幾乎是不可能的 — — 程式碼要麼對要麼錯，沒有「讓它回頭想想」這個選項。但 AI agent 的特性讓這件事成為可能，也有效：感知邊界不同，判斷品質就不同。軌跡回饋的本質，是主動替 agent 創造一個「擁有全局感知的時刻」。

TrueSkill 演算法，揭示了 AI 排序問題的本質缺陷

這裡有一個技術細節，我第一次看到的時候覺得驚豔：Thariq 的團隊在建立 Claude Code 的評估體系時，採用了微軟 Xbox 發明的 TrueSkill 演算法來對 AI 模型進行排名。

TrueSkill 最初是為了解決線上遊戲配對問題而設計的 — — 如何從不完整、不對稱的對戰紀錄中，準確估算每個玩家的「真實技術水平」。Halo 2 的線上配對用的就是它。它的核心數學是貝葉斯推斷（Bayesian inference）：把每個玩家的技術水平不表達為一個固定分數，而是一個機率分布（均值 μ 加上不確定性 σ）。每場比賽的結果都會更新這個分布，讓估算越來越精準。

把這套邏輯搬到 AI 模型評估，解決的是一個非常微妙但很重要的問題：傳遞律失效（transitivity failure）。

在直覺上，如果模型 A 比 B 好，B 比 C 好，那麼 A 應該比 C 好 — — 這是傳遞律，也是所有排名系統的基本假設。但在實際的 AI 評估中，這個假設經常失效。你可能發現 Claude 在某類程式碼任務上勝過 GPT-4，GPT-4 在某類推理任務上勝過 Gemini，但 Gemini 在某些特定場景下反而勝過 Claude。

如果你用最常見的 Elo 評分（那套起源於國際象棋排名的系統）來處理這個問題，你會得到一個強迫壓平的全局排名 — — 每個模型都有一個分數，A > B > C。但這個排名在特定場景下是失真的，它掩蓋了模型之間真正的能力差異結構。

TrueSkill 的優勢是它能夠更準確地建模「在特定情境下，哪個模型更好」，而不是強求一個扁平的全局排名。在有限的比較數據下，它能給出更可靠的相對估算。

但 Thariq 分享的更深層洞見在這裡：當他們用 TrueSkill 分析大量對比評估（pairwise evaluation）數據時，清晰地看到了 AI 模型在「相對判斷（comparative judgment）」上的一個系統性缺陷。

AI 模型非常擅長評估絕對品質 — — 「這個答案對不對？」「這段程式碼有沒有 bug？」但在評估相對品質時 — — 「A 和 B 哪個更好？」 — — 模型的判斷會受到呈現順序、框架效應（framing effect）、比較基準等因素的干擾，導致判斷不一致甚至相互矛盾。同樣的兩個答案，先問「A 好還是 B 好」和先問「B 好還是 A 好」，可能得到不同的結論。

這個發現有直接的工程意義：如果你在用 AI 做 A/B 測試或評估多個方案，不要只做單次比較，不要只從一個角度問。多角度問，對結果做統計，才能得到可靠的結論。單次「哪個更好」的答案，可信度比你想像的低很多。

這也是「像代理人一樣觀察」的另一個層面：AI 在做判斷時「看到的比較框架」，決定了它的判斷品質。你不只要設計 agent 執行任務時的感知邊界，也要設計它做評估時的感知框架。

未來開發者的核心能力，不是寫程式，是「設計感知邊界」

Thariq 有一個比喻，我覺得很精準地描述了現在 AI 開發者的處境：「我們就像早期汽車的駕駛員 — — 大家知道怎麼踩油門和轉方向盤，但還沒人完全搞清楚引擎是怎麼運作的，也不確定在什麼路況下需要換什麼檔。」

Claude Code 現在的使用現狀就是這樣。很多人用起來，能讓 agent 做不少事，但停留在試錯層面 — — 遇到問題，先改 prompt，不行換個說法，再不行就去 Twitter 搜「Claude Code 怎麼用」。

這樣用沒什麼問題，但有個天花板：你永遠是在別人總結的模式上走。哪天模型換版、場景不一樣，你又回到了猜測的起點。

理解「感知邊界」這個框架，讓這個問題變得清晰很多。agent 在任何時刻只能依賴它感知到的資訊做決策。你管理好了感知邊界 — — CLAUDE.md 寫清楚了、上下文窗口的信噪比管好了、軌跡回饋機制建立了 — — agent 的表現就會穩定。反之，感知邊界一團亂，不管 prompt 寫得多精彩，結果都是飄的。

Anthropic 內部有兩種使用 Claude Code 的模式，Thariq 把它們描述為「同步協作（synchronous collaboration）」和「非同步自主（asynchronous autonomy）」。同步協作是你在旁邊，隨時介入修正；非同步自主是你下完指令就去做別的事，讓 agent 自己跑完整個任務。他的觀察是：真正能做到非同步自主的開發者，往往不是在等「更強的模型」，而是在認真設計 agent 的感知環境。他們對自己設置的感知邊界有足夠的信心，所以才敢放手。

還有一件事不得不提。Check Point 在 2025 年發現了 CVE-2025–59536，攻擊者透過精心構造的 prompt，讓 Claude Code 執行了任意程式碼（Remote Code Execution，RCE）。這個漏洞說明了另一個問題：當 AI agent 有真實的執行權限，感知邊界的安全設計就不只是「用起來準不準」的問題，而是基礎設施層面的資安問題。你給 agent 建立了什麼感知環境，也決定了它在面對惡意輸入時有多脆弱。

Thariq 在一次訪談裡引用過 11 世紀伊斯蘭哲學家安薩里（Al-Ghazali）的一個觀點，大意是：真正的理解不是獲得更多資訊，而是在正確的時刻「看到正確的東西」。他把這個概念稱為「靈性技術（Spiritual Technology）」 — — 技術的設計，要服務於人類認知的本質結構，而不是追求更多、更快、更大。這和他的感知邊界理論有著奇妙的呼應：一個 11 世紀的哲學家，和一個 2020 年代的 AI 工程師，都在問同一個問題 — — 我們是否真的「看見了」我們以為自己看見的東西？

Claude 4 Opus 的 SWE-bench 72.5% 明年可能就會被突破，Terminal-bench 43.2% 也不會永遠是頂點。模型會越來越強，這是確定的。但不管模型多強，它永遠只能「看到上下文窗口裡有什麼」。感知邊界的設計能力，不會因為模型變強而過時 — — 因為更強的模型在設計糟糕的感知環境裡，只是更快地走錯路。

你以為在指揮 AI，其實你一直在做的事，是設計它能看到的世界。

這個認知讓我用 Claude Code 的方式，從此不一樣了。