外包你的思考，不要外包你的理解

資料來源#

• A Field Guide to Fable: Finding Your Unknowns
• After Math
• Andrej Karpathy: From Vibe Coding to Agentic Engineering
• Inside AI-pilled engineering teams: Five lessons for scaling without losing the plot
• Loop Engineering

摘要#

Andrej Karpathy對「當智慧變得廉價時，還有哪些東西值得深入學習？」的回答，建立在他反覆提起的一則推文上：**「你可以外包思考，但不能外包理解。」**資訊仍然必須進入你的大腦。人類成了瓶頸：要知道該打造什麼、為什麼值得做，以及如何指揮代理程式；而若缺乏理解，就無法成為好的指揮者，因為 LLM 本身「並不擅長理解」。在代理程式時代，理解是人類剩下的、不可委派的能力。

思考與理解#

• 思考 = 處理、產生中間步驟、搜尋。可以委派給代理程式。
• 理解 = 讓你能指揮、判斷與驗證的內在模型。不能委派——「你仍然是唯一能掌管這件事的人。」

人類「正在成為瓶頸，甚至連知道我們想打造什麼、為什麼值得做、以及如何指揮代理程式都成了瓶頸」。這和本文集從不同角度反覆指出的剩餘能力相同：在 Vibe Coding vs. Agentic Engineering 中是品味／規格／監督，在 HTML as the New Markdown 中是 Compute Allocator 這個角色，在 Engineer PM Convergence 中則是產品品味。

測驗關卡：讓理解可檢驗#

這個主張是一項原則，而一項永遠不會讓人不及格的原則，最終只會淪為蓋章認可。Thariq Shihipar 提供了本文集中第一個真正能判定你是否通過的工具（2026 年 7 月，practitioner-opinion）：

「先給 Claude 一大堆背景，再請它考我這次改動，能幫助我理解發生了什麼。只有完美通過測驗後，我才會合併。」

他需要這麼做的原因，正是理解如何在不知不覺間流失的具體機制：「閱讀程式碼差異，只能讓我對發生的事有粗淺理解，因為許多行為取決於既有的程式碼路徑。」差異檢視呈現了哪些地方改變，卻藏起了改變代表什麼——因此，檢視差異讓人感覺自己理解了，實際上卻幾乎沒有提供理解。

這道關卡反轉了檢視的方向。一般檢視驗證代理程式的輸出；測驗則驗證人類，並讓合併取決於理解，而非核准。它的限制也很明確：由本人自行測驗，而且由模型評分模型自己的工作。沒有人能阻止你照樣合併。它只會衡量那些希望自己的理解受到衡量的人——不得不說，這和本頁原本就認同此觀點的讀者是同一群人。另見 Unknowns as the Agentic Bottleneck。

知識庫作為理解工具#

Karpathy 將這個主張直接連結到他開創的 LLM-wiki 模式：把讀過的文章整理成個人 wiki，再「針對事情提問」。他的解釋是：「每當我以不同方式投影資訊，就會獲得新的洞見」——他把建立 wiki 視為對固定資料進行合成資料生成，藉此迫使資訊進入腦中。這個模式的創始者正在解釋它為何有效——不是因為檢索，而是因為重新編譯所產生的理解。（這個知識庫就是一個實例。）

「你必須理解才能指揮」的迴圈#

這套論證之所以形成循環，是因為各環節彼此承載：代理程式負責思考 → 但代理程式無法提供理解 → 所以人類必須理解，才能指揮思考 → 因此，能建立人類理解的工具（知識庫、資訊的良好呈現方式）就成了槓桿效益最高的投資。瓶頸不是算力或模型品質，而是人類真正理解的速度。他最後希望「幾年後再回來看看，他們是否也把理解自動化了」——將此標示為尚待突破的前沿。

簡潔透露的訊息#

他談到nanoGPT 簡化的軼事，也是一個理解的例子：他理解最精簡、乾淨的 LLM 訓練程式碼應該長什麼樣子；模型卻產生不出來（「它們討厭這樣，做不到」）。在一個超出模型 RL circuits 的領域裡，他的理解勝過模型——正是人類不可外包的理解發揮價值之處。

迴圈放大：理解債務與認知屈從#

Addy Osmani 的 Loop Engineering 文章，為這項主張提供了最嚴峻的壓力測試。當自我提示的迴圈在無人看管下交付程式碼時，他提出的失敗模式中，有兩種正是這項原則遭到破壞：

• 理解債務——「迴圈交付你沒寫的程式碼愈快，現有內容與你實際理解之間的落差就愈大。」外包思考（由迴圈負責），卻沒有保留理解（閱讀它產出的內容），正是這種落差，而且如今會以迴圈的速度不斷累積。它是 Agentic Technical Debt 在認知層面的近親。
• 認知屈從——「人很容易停止表達意見，直接接受它交回來的任何結果。」一旦迴圈移除了過去迫使人投入其中的阻力，Karpathy 所說的「不能外包理解」就變成一種必須主動捍衛的紀律。Osmani 的解方與 Karpathy 相同：「以判斷力設計迴圈，就是解方；為了逃避思考而設計迴圈，就是加速器」——繼續當工程師。

大型組織中的同一句格言——以及一項衡量主張#

Farhan Thawar（Shopify 副總裁暨工程主管）幾乎逐字重述了這項原則（Inside AI-pilled engineering teams: Five lessons for scaling without losing the plot，case-study，2026 年 6 月）：**「你不該放棄思考，而該放棄苦工。」**Karpathy 說的是個人該學什麼；Osmani 說的是迴圈的特性；Thawar 說的則是管理責任，而且本文集首次提出了具體方法，說明如何將此原則落實為日常運作。

**深入兩到三層，作為招聘與檢視的門檻。**防護措施很明確：「工程師必須理解自己正在處理的系統之下兩到三層。」這不是原則，而是可以檢驗的理解深度；性質上更接近上面的測驗關卡，而非一項勉勵，而且它被明確列為要求，不是願景。

**失效的指標，以及有效的指標。**最有力的貢獻是一項否定判斷，也是一則關於衡量方式的警告：

在 Shopify，AI 輔助程式碼的回退率，仍大致與 AI 出現前的基準相同

Thawar 報告了這個數字，同時指出它並未解決問題——維持深度要求「不是因為 AI 生成的程式碼品質較差」，而是因為理解能讓團隊維護、演進並復原。程式碼輸出品質指標看不見理解債務。工程師交付正確程式碼，卻無法診斷程式碼為何故障，在回退率、週期時間與缺陷密度等指標上看起來都沒問題。他提出的衡量方式則是每週展示——因為展示能「呈現團隊是否理解自己正在打造的東西，而不只是是否更快打造出來」。

這在本文集的衡量資料中補上了真正的缺口。Telemetry vs. Survey Measurement 說明儀器化資料能捕捉感知不到的損害；這裡則是反向情況——有一種損害在結構上逃過遙測，因為成品沒問題，改變的是人。它也提供了 The Tragedy of the Cognitive Commons 中 Validation Tether 所需的機制：實質監督需要專業能力，專業能力會悄悄流失，而沒有任何已交付程式碼的指標會回報這種流失。

Thawar 將此框定為生理問題，而非經濟問題——「大腦是肌肉；如果你不去健身房，或者不使用大腦，它就會萎縮」——這個主張比來源本身能支持的更強。回退率數字是第一手且未經審核的，也沒有提供對理解本身的衡量；每週展示是提案，並非經驗證的工具。

數學中的實例：證書藏起了落差（2026-09）#

以上案例都來自軟體領域，讀者至少還能察覺自己不理解程式碼。 After Math（De Toffoli 與 Duede，practitioner-opinion）則把同一主張帶到唯一具有可靠自動驗證器的領域；關鍵在於驗證器如何改變訊號。他們主張，機器證明可以符合證明的邏輯概念——「由不需要理解的機械程序檢查」——卻不提供可理解的概念，也就是數學家能「掌握、與其他專家交流、連結既有知識，並據以繼續推進」的想法（參見 Logical vs Intelligible Proof）。

對本頁而言，可延伸的重點不是理解再次成為剩餘能力，而是通過檢查，可能讓理解的缺席變得無從辨認。在軟體案例中，理解債務至少最終會浮現——檢視時、事故發生時，或被問到你是否理解底下兩層時。沒有 sorry 的 Lean 證明卻不會發出任何訊號：成品已經通過驗證，因此找不到能追溯到理解缺失的失敗；這門學科可能累積起沒有人能使用的認證成果，而每項指標仍然亮綠燈。Clay Institute 闡述證明何以重要時所用的說法，正點出了面臨風險的事物：「因為證明帶來的不只是確定性，還有理解。」

有兩點界限。這是一項論證，不是衡量——本文集沒有相關研究，也沒有任何衡量可理解性的工具。而且作者明確預期這個落差只是暫時的：未來系統「很可能產生既經形式認證、又完全可理解的真正證明」；這是本頁第一個開放問題的樂觀分支，出自對當前情況持悲觀解讀的人之口。

關聯文章#

• Logical vs Intelligible Proof — 數學領域中的同一種剩餘能力，以及更尖銳的憂慮：當成品帶有可靠證書時，缺失的理解完全不留痕跡
• Community Smells Under AI Adoption — 以整體人口規模檢驗替代的擔憂，結果未獲證實：整體關聯方向相反（採用 AI ↔ 更多以專業分工為導向的同儕互動）；但同一批受訪者中，確有一群直言不諱的少數派在開放式回答中描述了這種取代，其中一人稱這是初階員工在「外包思考」
• The Tragedy of the Cognitive Commons — 將同一建議擴展到整個專業領域，並說明它為何不會自願發生：保留理解對個人而言可有可無，對集體而言卻是承重基礎
• Returns to Expertise in Agentic Coding — **這項主張的實證證明。**Anthropic 對 40 萬次工作階段的研究發現，工作階段是否成功取決於對問題的領域理解，而非程式設計技巧（「程式碼代理程式並未取代領域專業知識」）；一個人理解愈多，代理程式就能產出愈多高品質工作——Karpathy 的主張，經過實際衡量
• Planning / Execution Division of Labor — 將「外包思考，保留理解」付諸實行的分工：人類保留約 70% 的規劃（理解），同時委派約 80% 的執行（思考）
• Building Is Cheap, Arguing Is Expensive — 透過產生 PR 來解決爭論，仍然需要理解結果
• Founder-Led Sales Discipline — 創辦人不能外包銷售對話所建立的理解
• Andrej Karpathy — 教育主張；他最後的回答
• LLM-as-Compiler Knowledge Base — 他用來建立理解的工具；「不同呈現方式 → 洞見」說明了整個知識庫為何存在
• Vibe Coding vs. Agentic Engineering — 品味／規格／監督，是應用於指引方向的理解
• Compute Allocator — Thariq Shihipar 對人類剩餘角色的描述；判斷什麼值得投入算力需要理解
• Jagged Intelligence (Ghosts, Not Animals) — nanoGPT 簡化案例：當幽靈模型碰上分佈外領域，人類的理解更勝一籌
• Engineer PM Convergence — 將產品品味視為持久人類技能，就是產品脈絡中的理解
• AI-Driven Formal Proof Search — DeepMind 發現，形式證明的草稿即使尚未證明，也能深化數學家的理解：AI 作為理解工具，正是此處主張的例子
• Design Concept Grilling — 在規劃前先找到 Brooks 所說的「設計概念」，就是讓理解先於思考
• AI Brain Fry — 監督程度超過理解時的失敗模式：未經理解就蓋章認可
• Experimental Learning Impact of Generative AI — **近乎受控的測試。**Contractor 與 Reyes 隨機分配 AI 使用權，再依使用方式區分參與者：增益（AI 協助你理解）帶來一週後仍持續存在的學習；自動化（AI 代替你思考）產生的成果則在 AI 移除後立刻消失——「外包思考，不要外包理解」不再只是主張，而是以因果對比衡量
• The Automation–Optimism Link — 問卷呈現的張力：重度委派者認為自己的技能更有價值，也表示學習沒有減少；但此主張警告，委派可能削弱讓他們有價值的理解——自我回報或許察覺不到這種流失
• Loop Engineering — 理解債務與認知屈從，是這項主張在迴圈速度下受到的壓力測試；Osmani 所說的「繼續當工程師」，就是無人看管迴圈時代的 Karpathy「不能外包理解」
• Acceleration Whiplash — Faros AI 所述資深工程師的「稅」，就是在檢視時兌現的理解債務：有人必須緩慢又耗費心力地重建 AI 作者從未掌握的意圖
• Unknowns as the Agentic Bottleneck — 測驗關卡：「只有完美通過測驗後，我才會合併」，是本文集第一個可實際執行、用來檢驗此主張的方式；本文也診斷了差異檢視為何不足以增進理解
• Context Advantage, Not Taste — Andrew Ng 認為人類剩餘角色在於他們知道什麼，而不是他們能欣賞什麼；這比「品味」更接近 Karpathy 所說的「理解」
• Review as the Control Point — 以檢視作為構念，衡量「不能外包理解」：當檢視升高到意圖層級，卻不再建立逐行的心智模型時，就會累積理解債務（「我們愈來愈常檢視輸出，而不是端到端理解行為」）；CMU 理論則對應了它如何透過回饋迴圈侵蝕未來的檢視能力
• Standardize the Infrastructure, Not the Tools — 同一來源的另一面：為每項 AI 請求計量的閘道，恰好會產生無法察覺理解債務的指標
• Telemetry vs. Survey Measurement — 與該文主張相反的案例：這裡失明的是儀器化指標（回退率），因為成品沒問題，改變的是人
• The Tragedy of the Cognitive Commons — 同一種流失在專業領域規模下的版本；Thawar 的「深入兩到三層」規則與每週展示，是 Validation Tether 之前提的第一批建議衡量工具
• Post-Acceptance Edit Behavior — 以按鍵為單位呈現依賴情形，並提醒衡量工具有所侷限。涵蓋 IDE 內 5.36 萬次編輯的資料中，開發者自行加入最終程式碼的 20%，且在最終狀態中有 36% 的程式碼由開發者自行加入不到 5%——這是理解疑慮的行為足跡，以數據而非格言呈現。但它也是本文集最接近 Thawar 所缺少的理解指標之處，依然無法看見理解：保留記錄的是開發者做了什麼；完整保留一段程式碼，無論是有人逐行讀過，還是完全沒讀，都是同一筆紀錄。這與同一種盲點相同，只是比回退率早一層出現
• Psychological Costs of AI Adoption — **這句格言在職場案例中獨立出現，並帶有代價。**該案例對驗證負擔的解釋機制，就是換句話說的本頁主張：驗證「要求他們重建對委派工作足夠的理解，才能評估並認可它」。該文進一步說明為何重建理解成本高昂；本頁把它表述為原則，該文則指出流程變化——「軟體工程師不是寫完程式碼才驗證，而是在寫程式碼的過程中驗證」，因此將生成工作外包「把這個過程壓縮成主要發生在事後的驗證，要求從業者評估他們未曾充分參與其推理過程的解決方案」。理解原本是創作的副產品，如今成了另一筆工項。該文還列出從業者實際採取的做法：手動編碼儀式、先自行嘗試解決再詢問 AI，以及保留業務邏輯工作、委派樣板程式碼
• Systems Thinking Over Specialization — Elizabeth Stone 從實務工作者的角度指出，即使代理程式寫下所有程式碼，工程師仍必須理解系統如何運作（「我仍然需要熟悉我們打造的東西，才能知道它好不好，也知道如何修正」）；她也坦承困難所在——代理程式寫的程式碼「很難追蹤……如果這個東西故障，我根本不知道該怎麼修」，而工程領域尚未找到不親自寫程式碼也能學會理解的方法
• Verification as the New Bottleneck — 將同一原則折算成一項工時：過去寫程式碼時就能免費獲得理解，如今必須在檢視時花錢買回，這正是驗證成為瓶頸的原因

開放問題#

• Karpathy 尚未解答的前沿問題：理解本身最終能否自動化，還是按定義而言，它就是人類剩餘的能力？他說「幾年後再回來看看」，讓問題保持開放。After Math 在 2026-09-21 記錄了一項相關預測（practitioner-opinion，未經衡量）：De Toffoli 與 Duede 雖然反對當前系統，仍預期自動化分支會出現——未來 AI「很可能產生既經形式認證、又能讓數學家完全理解的真正證明」，也就是由機器交付理解，而不只是交付結果。兩位數學實踐哲學家與 Karpathy 從相反動機出發，卻提出相同的保留判斷；值得一提，但無法據此定論。
• 如果理解是瓶頸，那麼投資報酬率最高的技能是否為學會如何快速建立理解（維護知識庫、提出適當的資訊呈現方式）——而且這能教會人嗎？The Psychological Costs of Artificial Intelligence Adoption in Software Engineering（case-study；某間受監管軟體公司的 21 名員工，採用 AI 一年後）在 2026-09-22 對前半問題提供了部分答案。它是本文集中第一份工作場域調查，呈現從業者在理解成為關鍵限制時，未經提示便逐漸採取哪些做法；清單裡沒有知識庫維護：每日手動寫程式的習慣（「不用就會失去」）、先自行嘗試解決再詢問模型以保護獨立推理、委派樣板程式碼並保留需要大量業務邏輯的工作、把先前對程式碼庫的知識視為監督工作的前提而非其產物，以及依複雜度分流委派工作。每一項做法都是保留理解能力，而非加快理解的過程——所以，從業者對「投資報酬率最高的技能是什麼」的回答，更接近不要失去這種能力，而非快速建立理解；這與本段最初假設的方向有實質差異。至於可教性，研究並未觸及：作者建議設計「AI 輔助驗證」課程，也指出先自行思考、再使用 AI 的順序可作為教學方法，但這是建議而非研究結果，研究並未衡量任何做法是否能保存能力。延伸資料（2026-09-22）來自 Training novices to think, or giving them LLMs? Evidence from an RCT（empirical，預先註冊的 2×2 RCT，n=1,053 名大學一年級學生），補上了可教性這一半——透過隨機分派，研究的是一項推理技能，而非維持習慣。約 6 分鐘的遊戲（分成四個部分、共 12 題二選一題目，每部分附有解題範例與回饋；對照組則以安慰劑形式作答相同題目，但不提供引導）使後續寫作中的機制辨識提升約 0.55 SD、證偽邏輯提升約 0.85 SD，不同解答之間的點子多樣性也提升約 0.47 SD。與本段直接相關的是：即使有能力不錯的模型可用，受訓技能也不會被排擠——訓練與 ChatGPT 使用權的每項交互作用都為正且達顯著，效果是在兩項主要效果之外再增加（機制 +0.129、可證偽性 +0.203、邏輯連貫性 +0.228）；而且有無使用工具，多樣性效果都相同。因此，認知技能可以用很低的成本教會，而且仍會實際運用，而非委派出去。三項限制使結論仍不完整。所教的技能是因果推理，不是「快速建立理解」——它回答了此問題中有關嚴謹思考的一半，而非知識庫維護的一半。研究結果是輔助生成內容中的推理風格，由 LLM 評分規準衡量；沒有未使用 AI 的後測、沒有移除工具，也沒有衡量工具撤除後的表現；作者更直言，無法區分真正學會知識，還是只取得了輸出。至於論文自身的整體評分結果，訓練沒有帶來好處（−0.111，p<0.01）——因為評分規準懲罰了機制、可證偽性以及偏離常見答案的程度；這提醒我們，能教會且會實際運用，不代表一定會得到肯定。

資料來源#

• Andrej Karpathy: From Vibe Coding to Agentic Engineering
• A Field Guide to Fable: Finding Your Unknowns — Thariq Shihipar，2026-07-04（practitioner-opinion）：測驗關卡
• Thread by @AndrewYNg — Andrew Ng，The Batch（2026-06-30），practitioner-opinion：「情境優勢」對剩餘能力的重新詮釋
• Inside AI-pilled engineering teams: Five lessons for scaling without losing the plot — Bessemer Atlas，2026-06-10（case-study）：§5「避免理解債務的隱藏危險」——Thawar 所說的「放棄苦工，不要放棄思考」、深入兩到三層的要求、作為理解訊號的每週展示，以及 AI 輔助程式碼回退率與 AI 前基準相符的第一手主張
• After Math — Silvia De Toffoli（IUSS Pavia）與 Eamon Duede（Princeton/Purdue），"After Math"，Terence Tao 部落格客座文章，2026-09-12，約 2,000 字，practitioner-opinion。本文引用它來說明邏輯證明與可理解證明的區別，以及可靠證書會掩蓋而非揭露理解缺失的觀察。這是一項關於數學的哲學論證，沒有衡量資料，也不涉及軟體——將它連結到本頁軟體案例，是本 wiki 的工作。完整討論見 Logical vs Intelligible Proof