那些一路關注我一段時間的人應該知道，教學與指導 對我來說是件大事™️。
在我進入科技業之前，我曾是一名老師，而且到現在我仍然覺得自己骨子裡是個老師。在我眼裡，當老師和導師 從來都不是 和當一個優秀的程式設計師與工程師分開的；恰恰相反，教學是我在每個階段都能持續精進技藝的一種工具。
但在過去幾年，尤其是最近幾個月，教與學的版圖正以令人不安的速度改變。LLM 和「AI」寫程式助手的出現，徹底改變了我們獲取工程技能的方式，而且是以一種我們顯然還沒有準備好的方式。
這一切引發了我許多思考與對話，我希望能在這篇文章裡整理其中一部分。
按照塔木德式的風格，這篇文章不會提供太多答案，希望讀完後你帶走的問題會比開始時更多。但提出問題，正是我們展開這些對話的起點；而如果我們想為即將到來的下一代程式設計師與工程師盡到責任，這些對話 必須 發生。
不要餵我現成答案
身為學生，無論是在我過去每天花好幾個小時埋首於猶太學院（Yeshiva）裡那些密集的塔木德法律辯論與玄奧的哈西迪哲學，還是在 Flatiron 訓練營學習 Rails 和 React 的時候，我很快就意識到一個讓人不太舒服的事實：技能習得的本質。
我最好的、最深刻的學習，從來不是在課程進行得很順利時發生的；而是在我痛苦地卡住、對著晦澀的錯誤訊息猛撞，或是和某個怎樣都無法真正理解的概念死纏爛打時發生的（通常是凌晨 2 點，靠著冷掉的咖啡和純粹的固執撐著）。
當你把那份掙扎剝掉，成長也就被拿走了；而當成長被拿走，學習就不會真正發生。
即使你只是死記硬背到足以通過考試，終究也是「來得快去得也快」。沒有那種認知上的摩擦，知識會在你關掉編輯器的瞬間蒸發。
我遇過最好的老師和導師，都直覺地理解這一點。當我盯著一支壞掉的腳本，心裡知道八成只是某個笨到不行、其實很好修的問題時，他們不會直接衝過來，把答案硬塞到我螢幕上（這讓睡眠不足的我常常氣得要命）。
相反地，他們會使用蘇格拉底式提問法。他們會指向某一行程式碼，開始用溫和但帶有探索性的問題，慢慢戳破我錯誤的假設。
他們會主動擁抱那份摩擦，創造出剛剛好的認知空間，讓我能自己把線索串起來。
他們明白我們教學工藝中的一條根本原則：好的指導，不是只為了把你帶到程式碼本身。目標不只是今天把測試變成綠燈；而是建立起足夠的心理韌性，去除錯明天那個幾乎必然會發生的下一次失敗。
而當輪到我成為老師時，我也帶著這些能力上路了。無論是在 Jewish Online School 教二年級學生、在 Flatiron 當助教，或是指導新加入團隊的同事，都是如此。
IDE 裡的應聲蟲
快轉到今天，我們這個產業在很大程度上已把那一層最初的指導外包給了 LLM 和寫程式助手。問題是，現實有點難堪：AI 是一個糟糕透頂的蘇格拉底式導師。
如果你曾經花過不少時間跟現代 LLM 一起配對寫程式（甚至只是聊聊天），你就知道它們是病態的應聲蟲。你告訴 AI，你想為一個只有十二個活躍使用者的待辦清單 App 設計一個分散式微服務網格，它不會反駁你，反而會附和說：「這真是個很棒的洞見！」然後立刻吐出 400 行樣板程式碼。
AI 預設就是盲目信任。它很少質疑錯誤的假設；當你問它為什麼堆疊追蹤爆掉時，它也會立刻給你一個可以直接複製貼上的修正，而不是幫你理解底層到底哪裡出了 bug。
AI 的行為就像一台演算法販賣機（error_in => fix_out），它系統性地把開發過程中的所有認知摩擦都拿掉了。
在我們追求 10 倍速度的狂熱中，我們忘了技能習得的一條基本原則：摩擦是特性，不是 bug。那是我們移除的一道承重結構！
這不只是哲學上的猜想；有實證資料支持。Anthropic 最近的一項 研究（如果你喜歡看方法論細節，也可以直接看 原始論文）找來 52 位正在學習陌生程式庫的軟體工程師，分成兩組：一組使用 AI 寫程式助手，另一組手寫程式。
整體結果既嚴厲又不令人意外。把寫程式工作交給 AI 的工程師，在概念掌握與除錯能力上下降了 17%（相當於整整兩個等第！），而且完成任務的速度往往也沒有比手動組還快多少。
為什麼？因為當你把「痛苦地卡住」所帶來的認知摩擦外包出去時，你的大腦就永遠無法建立起判斷產生出來的程式碼到底好不好的深層神經路徑。
公平地說，資料裡也 有 一點細微差異：少數使用 AI 的工程師其實表現優於手動組。但他們是誰？是那些拒絕盲目信任 AI 的開發者。他們把 LLM 當成學習夥伴，持續提出追問，並且手動把自己的摩擦重新注入流程中。
對其他人來說，那個自動化的應聲蟲只是悄悄地摧毀了他們的理解。
學習者的兩難：手動注入摩擦
這種動態把初階開發者推進了一個巨大的困境。
我那些還在職涯早期的朋友與後輩 曾抱怨，他們感覺自己被困在一個令人沮喪的兩難局面裡：
一方面，他們必須務實地接受 AI 不會消失這個現實。如果 LLM 能從一個提示詞就產生可運作的樣板程式碼，你不可能只是倔強地拒絕使用它。完全忽視 AI 也顯得不負責任，因為你在日常工作流程中終究會大量使用這些工具。
但另一方面，如果你盲目依賴那種自動補全，就會落入所謂的「表面式學習」。你會得到一個快速答案，足以讓你通過測試或讓 PR 被核准，卻完全沒有真正理解底層機制。你錯過的是「深度學習」——那種真正、也足以支撐職涯成長的進步。
以我的經驗來看，這種表面化是開發者焦慮與冒牌者症候群的直接管道。真正的專業自信，不是來自按 Tab 接受提示詞；而是來自對程式碼的掌握，以及強烈的腦力勞動與汗水。
為了撐下去，勤奮的學習者現在被迫把摩擦 重新 手動注入他們的工作流程，才不會讓大腦直接關機。
我一位初階開發者朋友 已經開始 明確要求他的 IDE 套用保護性提示，例如：「我想學會自己寫，不想只是複製貼上，所以請用你可以做到的方式幫我達成這件事。」
他們用手寫筆記（對，真的就是紙筆！），還會設定實體計時器，只為了重現主動聆聽的保護機制；而一個為了即時滿足而設計的工具，正系統性地試圖繞過這些機制。
為什麼我們需要那張雜亂的脈絡網
如果你看過 Emily Bender 與 Alex Hanna 的書 《The AI Con》，就會明白這種刻意自我施加的掙扎為什麼完全合理，因為它指出資訊存取中的摩擦其實是特性，不是 bug。
想想看，你是如何透過搜尋引擎手動追查一個冷門 bug 的。
你會閱讀雜亂的文件、翻看有十二則留言的 GitHub issue 討論串（通常最後以維護者在 2014 年把它關掉，標記為「不是 bug」收場）、權衡 Stack Overflow 上互相矛盾答案的可信度，還會一路碰上其他相關陷阱。
那張雜亂的脈絡與元資訊網路，正是真正工程背景脈絡建立的地方。
AI 聊天機器人會把這一切豐富、令人挫折的掙扎壓平，濃縮成一個看似權威（而且有時還會「幻覺」）的摘要。它給了你眼前問題的答案，卻剝奪了你大腦理解下一個問題所需的周邊生態知識。
Chavrusa 模式：對戰式的 Pair Programming && 會反擊的橡皮鴨
這讓我想到一種古老的教學模式，它至今仍存在於世界各地的猶太學院（Yeshiva）中，而軟體工程現在非常需要這種模式。
在傳統的猶太學院裡，你很少會看到有人安靜地獨自坐著讀書，或被動地聽講。相反地，整個空間通常很吵、很有活力，到處都是成對激烈辯論的人。
這種學伴制度稱為 Chavrusa（來自阿拉姆語，意思是「朋友」或「夥伴」）。
當你和 Chavrusa 一起學習時，你的夥伴不是來替你念文本的，也不會點頭如搗蒜地附和你有多聰明。真正的 Chavrusa 會經常挑戰你的邏輯、戳破你的論證、反駁你站不穩的假設，總之不會讓你輕易逃過智識上的懶惰。
你不是靠讀摘要或聽一場精彩演講來精通塔木德（雖然那也有幫助）；你是透過 Yegiah 來精通它——這個希伯來詞指的是強烈的智力勞動與汗水。
如果你仔細想想（正如我在 2021 年 RailsConf 演講 中提過的），pair programming 其實就是科技業對 Chavrusa 的重現。
而這套系統最重要的一點是：真正的 Chavrusa 裡，學習並不只是由 pair 中較資淺的那一方在進行。
不管你是和一位有十年資歷的 Staff Engineer 配對，還是和一位剛從訓練營畢業的初階工程師配對，學習永遠都是雙向的！
當你的夥伴扮演一隻會反擊的橡皮鴨（而且真的會回嘴！），他們會逼你放慢速度、把隱藏假設講清楚，並且從頭到尾為你的程式邏輯辯護。你們雙方都會從這份摩擦中受益，也都會帶著比原先更完整的心智模型離開。
拉比 Ḥama，拉比 Ḥanina 之子，說：經上所寫的「鐵磨鐵，朋友相感也是如此」是什麼意思？（箴言 27:17）這節經文要告訴你：正如鐵刀彼此摩擦時會互相磨利，當妥拉學者一起學習時，也會彼此磨礪。
—Ta'anit 7a
在我們追求 10 倍速度的狂熱中，我們試圖用 AI 副駕駛取代人類的 pair programming。但在這麼做的同時，我們忘了一個關鍵依賴：我們把有對抗性的 Chavrusa 與 Yegiah，換成了一隻諂媚的機器橡皮鴨。
有同理心的平衡術
我常從科技圈聽到的一種回應是：「那我們就用更好的系統提示詞來解決啊！建立一些護欄，指示 AI 扮演蘇格拉底式導師，而不只是直接把答案給出去！」
現在有很多工具都在嘗試這件事，但我非常懷疑技術性的護欄能解決一個本質上屬於人的問題。
首先，依賴提示詞來刻意不給答案，需要的是頂級學習者的自律。有些學生可以做到，但這種意志力很罕見，尤其是在你的認知電池快耗盡的時候。
當一位初階開發者在凌晨 2 點盯著一個晦澀的 NullPointerException，而他的大腦已經燒乾時，要求他「思考這個物件的生命週期」的提示詞，幾乎會立刻被跳過。如果只要輸入 /solution 或開一個新的瀏覽器分頁，就能得到那種可以複製貼上的程式碼所帶來的多巴胺快感，我認識的大多數人都不會咬牙撐過去。
更重要的是，LLM 的基本架構就是為了取悅人。即使你用提示工程把它們調成嚴格的蘇格拉底式導師，只要使用者流露出真實的挫折感，AI 仍然會像便宜的折疊椅一樣立刻垮掉，然後還是把語法答案交出來。
為什麼？因為 LLM 缺少教育者最重要的品質：同理心。
導師是一種人性的教學平衡術。好的導師知道，何時該讓學生經歷有益的掙扎，何時又會變成打擊士氣的苦難。好的教育者能讀懂現場氣氛。他們會注意到那些沉重的嘆息、逐漸升高的恐慌，以及純粹的疲憊。
沒錯，身為學生，我在被給予能自行解決問題的工具時學得最好。但有時候，我也會把全部精力都耗在那個蠢錯誤訊息上，而老師提出的所有引導式問題，都只會讓我一直繞著那個能讓一切運作起來的唯一洞見打轉；偏偏那個洞見，我的大腦就是碰不到。
到了那個時候，好的老師就知道該退一步，笑一笑，說聲「嘿，JavaScript 有時候就是很怪」，然後把我需要的那一行程式碼直接給我，讓我終於能脫困，去睡上一覺。
演算法無法讀懂學習者的情緒狀態。它無法在高難度陪練夥伴與支持性的安全網之間動態切換。程式碼永遠無法複製那種關係。
尚未解開的兩難
那麼，這把我們帶到哪裡？老實說，我現在的問題比答案多得多（我知道，這大概不是你想從科技部落格裡聽到的！）。
我們正站在一個巨大的、全產業級的兩難局面上：
一方面，若禁止初階開發者使用 AI，幾乎可以說是職業上的失職。它就是現代的 IDE（而當我還在學寫程式時，守門人也曾爭論初階開發者不該用 IDE——那時我不同意，現在我仍然不同意）。如果未來工作上本來就會要求他們使用這些工具，那不訓練他們有效使用，實在說不過去。
另一方面，那些在不引入會摧毀架構的 bug 之下，仍然獲得巨大 10 倍速度提升的工程師，是那些已經在 沒有 這些工具的情況下寫了很多年程式的資深工程師。
我們之所以知道 LLM 在用錯誤前提空轉，是因為我們有一個內建的 BS 偵測器，而那是靠多年手動除錯辛苦磨出來的。
今天，沒有那段 AI 之前經驗的人，要怎麼培養這種直覺？他們不會從一個諂媚的應聲蟲聊天機器人那裡得到。至於手動發明自己的認知摩擦，則需要相當高程度的自律，而這在緊迫的截止日期前通常很難維持。
也許未來的新人導入，會更依賴強化人類的 pair programming——讓初階工程師跟著資深工程師好幾個月，透過旁觀與浸泡，間接吸收那些 AI 出現之前的直覺。畢竟，就算在 Claude 出現之前，pair programming 也一直是最好的導入方式之一。但並不是每家公司都願意投入全職配對所需的資源，尤其在這個總是急著昨天就要上線的產業裡。
我確定的是，我們不能忽視這個問題，也不能假設更好的 LLM 模型會神奇地修好我們的人才管線。
如果我們只是把一個神諭交給初階開發者，卻沒能保留 Chavrusa 那種有同理心、又嚴謹的掙扎，我們幾年後醒來時，可能會面對一個可怕的系統錯誤：整個產業有一大堆 AI 生成的程式碼要維護，卻沒有足夠的資深工程師知道該怎麼維護它。
你和你的團隊正在做些什麼，來維持那種有生產力的摩擦？我很想聽聽你的想法。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
