未知事項：代理式工作的瓶頸

資料來源#

• A Field Guide to Fable: Finding Your Unknowns
• Claude Opus 5 System Card
• From Agent Behaviour to Agent-Friendly Documentation

摘要#

Thariq Shihipar 在 2026 年 7 月的實務指南指出一個瓶頸，它既不是模型能力，也不是驗證：人類是否能說清楚自己從未寫下的東西。這個觀點取自 Korzybski——*地圖不是疆域本身。*地圖是你的提示、技能與脈絡：你交給 Claude 的內容。疆域則是工作實際發生之處：程式碼庫、現實世界及其實際限制。兩者之間的差距，就是 Thariq 所說的未知事項；代理程式每遇上一項未知，就得猜測你想要什麼。

這是整篇文章的核心主張，也是本文存在的理由（practitioner-opinion——一位專家的經驗，而非測量結果）：

「Fable 是第一個讓我覺得工作品質受限於我釐清未知事項能力的模型。」

這是一次瓶頸的轉移。較早期的模型受限於它們能做到什麼；Fable 等級的模型則受限於你成功告訴它們什麼。Thariq 引申出的結論是：減少未知事項並為其預作規劃，就是代理式編碼的技能；更重要的是，「這是可以透過與 Claude 合作而精進的技能」。

四個象限#

Thariq 用 Rumsfeld 的方式拆解問題，有意思的是下面兩個象限：

象限	內容	影響所在
已知的已知	「基本上就是提示裡的內容。」你告訴代理程式自己想要什麼。	不會造成問題——這就是你已經畫好的地圖。
已知的未知	你還沒弄清楚，但知道自己還沒弄清楚的事。	解決成本低：詢問、研究、決定。
未知的已知	「明明顯而易見，以致我根本不會寫下來，但看到時又認得出來的事。」	最難處理。你無法提示自己不知道原來相信著什麼。
未知的未知	你完全沒想過的事。「我知道某件事可以做到多好嗎？」	你不知道該問什麼、好的成果長什麼樣子，或有哪些坑。

未知的已知，就是 Andrew Ng 所說的人類「脈絡優勢」的同一個概念——人類掌握而模型沒有的知識；它之所以看不見，正是因為對持有者而言太理所當然。Ng 指出這種不對稱；Thariq 則提供了挖掘方法。兩份資料只差一週，彼此都沒有引用對方。

兩種方向都會失敗#

未知事項無法靠「只要把提示寫得更用力」來解決，因為具體程度過高或不足都會出問題：

• 太具體 →「即使改變方向可能更合適，Claude 仍會照你的指示行事。」
• 太模糊 →「Claude 常會依據業界最佳實務做選擇與假設，但那些做法未必適合你的任務。」

「不把未知事項納入考量，就會兩頭落空。你不知道路上何時障礙重重，也不知道何時一路平順，但你仍希望 Claude 能適時轉向。」

這讓同一位作者提出的限制加空間提示方法更為清晰（「提供足夠的限制以取得你想要的結果，但也留些空間讓模型帶來驚喜」）。你無法在限制程度的刻度上選定固定位置，因為適當的限制程度取決於未知事項所在之處，而那恰恰是你尚未知道的事。

為什麼光做規劃還不夠#

知識庫既有的規劃做法——先盤問，再規劃——假定未知事項能在開始實作前清除。Thariq 說，事情並非如此：

「提早規劃並不總是足夠。實作深入之後仍可能遇上未知事項，也可能是未知事項讓你發現，其實應該用完全不同的方式解決問題。」

因此，探索不是一個階段，而是整段工作的特性。他把技巧分成開始前、進行中、完成後三類；多數以規劃為核心的工作流程缺少的，正是進行中與完成後這兩部分。這是對規劃／執行分工的實質修正：即使人類承擔約 70% 的規劃決策，如果三分之一的決策要到執行中才浮現，這種投入仍派不上用場。

引導技巧目錄#

Thariq 說：「我不會每次都用上所有技巧。」每種技巧都是「在修正成本變高之前，找出自己先前不知道之事的低成本方法」。值得一提的是，幾乎所有技巧產生的都是 HTML 成品，而不是聊天回覆——見HTML 是新 Markdown。

實作前#

• 盲點檢視 — 針對未知的未知。請 Claude 使用字面上的「blindspot pass」和「unknown unknowns」兩個詞，找出並說明你不知道自己不知道的事。提供你的起點：你是誰、已經知道什麼、對這個程式碼庫有多少經驗。「我正在新增一個 auth provider，但對這個程式碼庫的 auth modules 一無所知。你可以做一次 blindspot pass，幫我找出相關的未知的未知，並協助我更好地提示你嗎？」
• 腦力激盪與原型 — 針對未知的已知，也就是「一看到就知道」的標準。及早把它們說出來：「在實作過程中才發現，成本可能（相對）很高……功能或規格的小改動，就可能導致程式碼實作截然不同。」他幾乎每次都從這裡開始，以意圖設定範圍——「腦力激盪可以避免我把範圍訂得太窄或太寬。」請它提出幾個截然不同、大膽出奇的方向，再告訴它你的反應。（這是把原型優先於 PRD當成引導工具，而不是規格。）
• 訪談 — 腦力激盪後的補充。*「一次問我一個問題，針對任何模糊之處；優先詢問那些答案會改變架構的問題。」*優先排序這個條件才是關鍵：依照答案改變決策的力量排列問題，而不是依出現順序。這是把設計概念盤問濃縮成一句話。
• 參考資料 — 有些東西無法描述時，就拿來指給它看。「你可以提供圖表、文件或圖片，但最好的參考資料絕對是原始碼」——即使是不同語言也一樣。*「vendor/rate-limiter 裡的這個 Rust crate 實作了我想要的確切退避行為。讀過後，在我們的 TypeScript API client 裡重現相同語意。」*Thariq 指出，Claude Design就是這樣運作：你指向網站上喜歡的模組，它會讀取底層程式碼，「而不只是看截圖」，因此取得的是標記、結構與建構方式，而不是外觀。
• 依照可能修改的機率排列實作計畫 — 計畫的目的是找出你可能會想修改的地方，所以把這些放在前面。*「用 HTML 寫實作計畫，但先列出我最可能調整的決策：資料模型變更、新的型別介面，以及任何面向使用者的內容。機械式重構放到最後，我信任你處理那部分。」*按照可修改程度而非執行順序排列計畫，是個小巧而回報可觀的想法：人類有限的注意力會用在只有現在才有機會改動的決策上。

實作期間#

• implementation-notes.md — 由代理程式維護的暫存檔，記錄它做過的決策，特別是記下迫使它偏離計畫的邊界案例的 Deviations 區段。*「如果遇到迫使你偏離計畫的邊界案例，選擇保守做法，記到 'Deviations' 底下，然後繼續。」*這同時做到兩件事：代理程式不會因為等你回覆而卡住，而偏離計畫之處也會成為下一次嘗試的輸入。這是反向運用脈絡檔案模式——不是把意圖寫下來給代理程式看，而是讓代理程式把發現寫下來給你看，免得下一次執行又得重新推導（在進行中償還意圖債務）。

實作後#

• 提案與解說 — 把原型、規格與實作筆記打包成一份文件，爭取支持。這招有效，是因為「審閱者一開始面對的未知事項和你一樣」，也因為專家看到你已經考慮過他們原本會指出的失敗點時，就能更快核准。
• 測驗閘門 — 見下文。

測驗閘門#

這篇文章中最犀利的實務做法，也是知識庫中第一個針對反覆被提及卻始終沒有解方的失敗，提出具體機制的例子：

「先給我很多脈絡，再請 Claude 考我對這項變更的理解，有助於我明白實際會發生什麼。只有我完全答對，才會合併。」

原因是閱讀差異檔提供的資訊不足：「許多行為取決於既有程式碼路徑」，因此差異檔會顯示改了什麼，卻隱藏它代表什麼。測驗顛倒了審查方向。一般審查驗證代理程式的成果；測驗則驗證人類——而且合併閘門取決於人類是否理解，而非人類是否核准。

這是對知識庫中以三種方式陳述、卻沒有任何一種得到解決的問題，提出直接且可測試的答案：「你可以把思考外包，但不能把理解外包」闡述了原則，卻沒有檢查方式；Osmani 的理解債務指出逐漸累積的缺口；監督疲勞則指出它造成的照單全收。可以答錯的測驗，能偵測這三種問題。值得注意的是，這種做法是自行執行的——沒有人能阻止你照樣合併，所以只有想要測量自己理解程度的人，才會測出自己的理解程度。

實例：Fable 上市影片#

Fable的上市影片完全由Claude Code剪輯；Thariq 表示，在這個領域他「絕不是專家」。整個過程完整走過技巧目錄的每個步驟：

1. 從已知的已知開始——Claude 可以用程式碼剪輯並轉錄影片。
2. 把已知的未知轉成已知的已知——「準確度夠嗎？」→ 請 Claude 解釋 Whisper 類型的轉錄如何運作，以及能否用 ffmpeg 刪掉嗯啊聲與停頓。
3. 透過原型探索未知的未知——不確定能否做到逐字對時的 UI → 用一份轉錄稿製作一次性的 Remotion 原型，找出答案。
4. 辨認出一項未知的未知——影片看起來色彩黯淡；他知道這叫「color grading」，便要求 Claude 提供幾種版本讓他選。但他隨後發現，自己不知道好作品應該長什麼樣子，因此再多版本也無濟於事。他停止產生版本，先請 Claude 教他色彩分級。

第四步是整份指南主張的縮影：**產生更多選項無法解決未知的未知，因為你沒有能力評判這些選項。**正確做法是離開循環，補上缺少的評判標準。

哪些人很少遇到未知事項#

「最好的代理式編碼者，遇到的未知事項相對較少。看著像 Boris 或 Jarred [Sumner] 這樣的人寫提示，對我來說很明顯，他們非常清楚自己想要什麼。他們與程式碼庫及模型行為都配合得非常好。但他們也會預設未知事項存在。」

有兩項主張值得分開看。第一，專業知識意味著未知事項較少——這提供了一種解釋機制，說明Anthropic 的測量結果為何顯示，能預測誰善用代理程式的是領域理解，而非編碼技能：專家的地圖已經和疆域相符。第二項較為微妙：專家不只擁有較少的未知事項，也會假設未知事項仍然存在並預先因應。熟練代表知道地圖哪些地方空白，而不是相信地圖已經完整。

延伸閱讀#

• 代理程式文件行為 — **Shihipar 的 implementation-notes.md 所屬的文件類型，是透過測量而非設計發現的。**Gao & Chen 對 557 個真實程式碼工作階段進行 Tier-2 分類時，發現一種不在他們初始分類中的項目——代理程式工作筆記：代理程式為下一個行動者撰寫的計畫、thoughts/ 資料夾、腦力激盪、驗證紀錄——在 3,033 次文件互動中出現 760 次（25.1%），查閱和產生的數量幾乎相同（382 次對 367 次）。下方的 Deviations 紀錄做法是人工設計的實例，而論文的警告正是本文應該帶出的重點：這些成品會累積成持久的儲存庫內容，但目前的清理工具、審查清單和文件品質指標都沒有為它們分類
• 同模型審查盲點 — 自我評分測驗閘門在任何偏移發生前就有的缺陷。下方的開放問題擔憂，自行執行、由模型評分的測驗，會隨時間退化成舒適的平衡狀態。Greptile 的配對資料集（case-study）指出，第一輪就已出現閘門失效：模型審查同一模型家族撰寫的程式碼時，偵測到的高嚴重度錯誤比審查另一家族的程式碼少 6–12 個百分點。因此，由模型針對自己的工作出題，問題也會來自產生程式碼時的同一套預設。模型審查時較少注意的類別，和它撰寫時較少注意的類別彼此相關——表示這個閘門系統性忽略了作者本身的盲點，而不只是可能被評得太寬鬆。低成本的解法和 Greptile 採用的一樣：交由不同模型家族出題。2026-07-29 的研究檢視記下了這個尚未填補的缺口
• 認知公地的悲劇 — 自我評分測驗疑慮背後的理論：Validation Tether 指出，實質審查需要專業知識，而委派工作會侵蝕這種專業知識；Vicente & Matute 發現 80.7% 的人即使偵測出問題仍會照做，正是這種失敗模式的測量結果
• Unproductive Self-Verification — 反模式：Opus 5 花了數小時除錯一條在結果出現前就已建好的驗證流程，把預算耗在已知事項上，最後卻由未知事項決定結果
• 脈絡優勢，而非品味 — 從另一端命名同一概念：Thariq 的未知的已知就是 Ng 的脈絡優勢；本文提供的是挖掘它的方法
• HTML 是新 Markdown — 同一位作者；幾乎每種技巧都以這種媒介輸出（「幾乎在所有這些情況下，HTML 成品都是最好的視覺化呈現方式」）
• 外包思考，不要外包理解 — 測驗閘門是這項主張的可執行檢查；把理解設為合併先決條件，而不是只當成目標
• 設計概念盤問 — 「一次問我一個問題，優先詢問答案會改變架構的問題」就是一句話版的 grill-me；本文指出盤問仍不足夠，因為實作期間和完成後也會浮現未知事項
• 原型優先於 PRD — 把原型當作引導工具（找出未知的已知），而不是規格本身；同一份成品的第三種用途
• 代理程式脈絡檔案 — implementation-notes.md 把模式反過來用：把代理程式執行中發現的事寫給人類看，並附上 Deviations 紀錄
• 規劃／執行分工 — 這項修正指出：前置規劃無法清除只會在實作深入後出現的未知事項
• 代理式編碼的專業知識回報 — 「最好的代理式編碼者，遇到的未知事項相對較少」是解釋專業能力溢價測量結果的機制
• 代理式技術債 — 執行中記錄的偏離事項，就是在意圖債務累積成下一個工作階段的重新推導之前先行償還
• AI 腦力耗竭 — 測驗閘門可對抗未理解就核准的問題
• 迴圈工程 — 理解債務就是測驗閘門所測量的對象；無法通過理解測驗的程式碼交付循環，就是認知上的放棄
• Compute Allocator — Thariq 的另一種說法：如果生成的 token 有 99% 是鷹架，那麼大部分鷹架都在引出未知事項
• 驗證是新的瓶頸 — 再上游一步的瓶頸：驗證問「這對嗎？」，未知事項問「我曾經說明什麼才算對嗎？」
• 研究品味是人類的瓶頸 — 如果人類的剩餘價值在於脈絡而非品味，對策就是引出脈絡，而非培養品味；本文就是這種觀點所推導出的方法
• AI 原生建構的三個迴圈 — 願景→規格的資訊流失，是用迴圈來陳述同一問題：Andrew Ng 的開發者回饋迴圈正是未知事項在實作後浮現之處，完全呼應 Thariq 所說的規劃無法避免這種情況
• 提示注入中的任務規格效應（AutoDojo） — 規格不足會帶來雙重問題：Thariq 視為品質風險的「行動開放／聽從內容指示」任務形式（Claude 猜測未知事項），同樣也是經測量的安全性風險——AutoDojo 顯示，行動開放的任務更容易遭到注入，因為注入內容可以偽裝成規格不足的請求要代理程式處理的內容
• Thariq Shihipar — 作者
• Claude Fable 5 — 其能力使人類成為限制因素的模型
• Claude Design — 參考資料技巧的產品化形式：指定某個元件後，它會讀程式碼，而非只看截圖
• Configurable Human Participation — 「釐清發生於承諾之前」已獲測量：HAS-Bench 發現，釐清在資訊不對稱／潛在限制模式中特別有效（先挖掘隱藏的已知資訊，再讓代理程式承諾某個候選方案），並指出由代理程式決定何時發問是核心技能——這是承諾前清除未知事項的基準測試證據

開放問題#

• 「第一個受我的未知事項限制的模型」究竟是 Fable 的特性，還是 Thariq 的特性？對模型非常熟悉的前沿實驗室工程師，會比一般使用者更早碰到人類端的上限——這代表它可能是領先指標，而非目前普遍適用的情況。
• 測驗閘門由人自行執行，也由模型評分（評的是模型自己的工作）。怎樣才能避免審閱者愈來愈懶，測驗也跟著愈來愈容易，形成舒適的平衡狀態？參見驗證是新的瓶頸中的製作者／檢查者問題。（這個問題擔心的偏移，如今已有一種衡量方式——代理程式生成程式碼的安全債務發現，人類提交的真實外洩憑證中，有 67.6% 位於代理程式 PR；作者將其解讀為警覺性降低。這證明偏移確實存在，卻沒有說明什麼能阻止它，因此問題依然懸而未決。）從意料之外的角度得到部分回答（2026-08-12），而且缺陷出現得更早：Greptile（case-study）測得，模型審查同一模型家族撰寫的程式碼時，對高嚴重度錯誤的召回率比審查另一家族程式碼低 6–12 個百分點。測驗閘門不必等到退化才會變弱——模型針對自己撰寫的工作出題，問的會是撰寫模型認為重要的事；它在審查中較少注意的類別，也和撰寫時較少注意的類別相關，因此盲點從第一天起就不會出現在題目裡。這和本項目所問的平衡狀態是不同的失敗，而且已有明顯的緩解方式（交由不同模型家族出題）。至於平衡狀態本身——怎樣才能避免審閱者愈懶、測驗就愈容易——仍沒有答案；目前沒有人測量自我評分閘門隨時間的變化。
• 引導探索需要成本。這裡的每項技巧，都會花掉一個工作階段的 token 和注意力，讓工作暫時沒有進展。來源沒有提供任何界線，說明盲點檢視的成本何時會高於它所避免的錯誤。
• 如果未知的已知可以挖掘，那麼它們能否一次挖掘，永久受用？把盲點檢視寫成技能檔案，能否永久縮小差距，還是每遇到新的疆域，差距就會重新出現？

資料來源#

• From Agent Behaviour to Agent-Friendly Documentation — Gao & Chen（Peking University），arXiv 2608.20195，2026-08-20，empirical。本文僅引用工作筆記類別：§3.3 Tier 2（此類別由語言模型分類 527 個模糊路徑時浮現，初始分類中並不存在）、§4.1.2/Table 1（760 次互動，占 25.1%）、Table 7（查閱 382 次、產生 367 次）及 §6.1（新維護面的含意）。**附帶的限制說明：**Tier-2 標籤未經人工驗證，也沒有可靠性統計，因此 25.1% 的比例仍屬暫定；「這個類別確實存在」的質性主張才是較可靠的部分。完整討論見代理程式文件行為
• A Field Guide to Fable: Finding Your Unknowns — Thariq Shihipar（@trq212），發布於 2026-07-04（practitioner-opinion）。範例成品位於 thariqs.github.io/html-effectiveness/unknowns/；2×2 象限圖與階段圖是發布在 X 上的圖片，未轉錄。