能讓人學到東西、又難到 AI 一次寫不完的作業，現在幾乎不存在了
TL;DR
- 教育最有效的部分是「卡住」。而現在只要一個 prompt 就能繞過卡住，難度剛好的練習題幾乎絕種
- Jane Street 有一個全職職位叫 developer educator，一半時間寫程式、一半時間教人，三年下來變成他們最會擴散的內部投資
- 「學習目標」這個框架的重點在動詞：不要寫「理解 property-based testing」，要寫「能寫出一個帶巢狀 record 型別輸入的測試」
- 資料顯示，AI 普及後工程師點「跳到定義」的次數反而變多了。寫得少，讀得多
- 產出一個看起來合理的 PR 成本掉到接近零，驗證它的成本完全沒降，有時候還更高
- 最有意思的實驗：讓 AI 寫到一半停下來，留一塊給人填。事後對程式碼的理解明顯比較紮實
- 他們今年的實習生課程整個重做，因為舊的四週專案現在一個 prompt 就寫完了
這集在二〇二六年九月二十三日播出的 Signals and Threads，是 Jane Street 自己做的技術 Podcast，主持人 Ron Minsky 在這家公司待了二十幾年，當年把整間公司搬到 OCaml 這個冷門函數式語言上的就是他。節目一向不談市場、只談工程，聊過時脈同步、FPGA、build system 這種冷門到不行的題目。
這次的來賓是 Aaron Bauer，Jane Street 的 developer educator（開發者教育工程師）。他二〇二二年加入，是這家公司第一個全職做這件事的人，在那之前是 Carleton College 的資工助理教授。博士論文研究的是 Foldit，那個讓一般玩家在遊戲裡摺蛋白質、結果真的解出實驗室卡了好幾年的結構的科學遊戲。
一個研究「怎麼讓完全不懂生化的人解出蛋白質結構」的人，現在的工作是教一群全世界最聰明的工程師寫程式。這個組合本身就夠有趣了。
一個一半寫程式、一半教人的職位
先講這個職位怎麼來的。Jane Street 的技術棧很怪，用 OCaml、不用 Git、有自己的程式碼審查系統，外面學到的東西進來有一半不能用。所以他們一直很重視內部教育，但過去都是拉現役工程師來兼著做。
後來他們想，不如直接開一個職位，一半時間寫程式、一半時間做教育。刻意設計成一半，是因為如果教的人自己不在同一套系統裡幹活，講出來的東西沒有說服力。
Minsky 很坦白地說，他原本以為這種「又酷又特別」的職位會有一堆好人選從天而降，結果完全沒有。他的原話是，如果當初這個缺晚三個月開出來，可能根本遇不到 Aaron。
原因不難猜。有教學經驗的人大多在學術界，而會選學術界的人通常就是不想離開學術界。再加上要同時是一個「完全合格的 Jane Street 工程師」，這個交集小得可憐。
但他們現在很滿意這個實驗。Aaron 自己的解釋是，過去大家也在教，差別在於「有一個人把這件事當成第一優先」是一個 step change（階段性的跳躍）。有專職的人在看，你才會不斷發現「這裡也該教一下」。他們現在還在找 OCaml 教育者、機器學習教育者，甚至考慮把教育者像設計師那樣，直接編制到各個團隊裡面。
「學習目標」這件事聽起來很廢，但它真的有用
Aaron 剛進公司接的第一個案子，是一個關於軟體測試的內部工作坊。當時這個案子推得很卡，每個人都投一點時間，但沒人把它收尾。
他做的第一件事是問 Minsky：這門課的 learning goals（學習目標）是什麼？
Minsky 的反應是：「這幾個英文單字湊在一起看起來有意義，但你顯然是在講一個更具體的東西。」
Aaron 的定義是這樣：學習目標不是描述你要教什麼，是描述「學生結束之後會有什麼不同」。而且要用「上完這堂課，學生將能夠⋯⋯」開頭，後面接一個具體到可以驗收的動詞片語。
「理解 property-based testing（一種自動產生大量測試輸入的測試方法）」不是好的學習目標，因為太模糊，你也無法衡量。「能寫出一個輸入是巢狀 record 型別的 property-based test」才是。
寫清楚之後，後面的設計會自己長出來。既然學生最後要能做這件事，那課程裡就該練這件事；既然要練這件事，那需要先鋪什麼背景、需要先給他們哪幾段現成的程式碼，答案就很清楚了。
還有一個被低估的副作用：它逼你想清楚「什麼不是目標」。哪些事情純粹是雜活，不值得佔用學生的時間，寫下來的當下就會浮現。
Aaron 自嘲說，他在 Jane Street 的教育工作有很大一部分，就是走進不同的會議室、對不同的人說出「learning goals」這四個字。
寫得變少，讀得變多
節目中段轉到 AI，這裡有一個我覺得最值得一講的資料點。
Aaron 的團隊在編輯器裡加了 telemetry（使用行為的量測資料）。他有個假設：如果 AI 把程式碼都寫好了，工程師應該比較少需要查 API，那「跳到定義」這個功能的使用次數應該會下降。
結果資料顯示，人均使用次數反而略為上升。
他的解讀是，大家現在需要讀懂的程式碼比以前更多了。寫的動作外包出去了，讀的動作反而加倍。
這跟節目裡引用的另一句話扣在一起：產出一個「看起來很合理」的 PR，成本已經掉到接近零，但驗證它的成本完全沒降，甚至更高。
Aaron 用了一個很精準的形容：LLM 寫出來的程式碼有一種 uncanny（詭異的熟悉感）。它很滑順、長得很漂亮，那些你平常用來偵測「這段有問題」的直覺訊號，全都不見了。但它還是可能整段壞掉。
這件事我之前在連手寫一個 HTTP 請求都不會了整理過類似的焦慮，差別在於這次是有公司真的拿資料出來驗證，不只是感覺。
讓 AI 寫到一半停下來
最有意思的一段實驗在這裡。
Aaron 試了 Claude Code 的 learning output style，那個模式會改掉系統提示詞（system prompt 的中文，就是給模型的預設指令），要求模型寫到一半停下來，在程式碼裡留一個 TODO 給人類，請你自己把那一塊填完。
他自己用完的感想是，體驗更愉快，而且結束的時候，他對這段程式碼的理解明顯更紮實。
然後他在跟實習生講程式碼審查的時候，突然把兩件事連起來了。
自己寫程式的時候，你的理解是一層一層疊上去的；每犯一個錯、修一次，你的心智模型就被校正一次。審查別人的程式碼很難，是因為對方直接把成品攤在你面前，你得從零硬生出一個心智模型。
而跟 LLM 一起寫程式，本質上就是後者。
這個觀察拉出一個很重要的推論：現在所有 AI 編程工具的預設互動模式，都是「模型生成完整結果、人類決定接受或拒絕」。這個形狀本身可能就是錯的。
這跟做筆記的道理一模一樣。節目前半有一段在聊，上課手寫筆記對記憶的幫助，跟你事後有沒有再看那份筆記幾乎無關。有些學習效果就是來自「你有參與生產的過程」，你一旦被移出這個過程，東西就過不去。
Aaron 也提到他在 Carleton 教書時刻意避開電腦教室。只要螢幕在人跟講者之間，就算學生真心想專心，大概有一半的人做不到。
舊的實習專案，現在一個 prompt 就寫完了
今年他們把實習生的訓練整個重做，原因講得很直白：AI 工具太強了，過去那個要做四週的專案，現在一個 prompt 就出來了。
那還怎麼評估一個實習生？
他們的答案有三塊。
第一，把專案改成更開放、更接近真實工作：需求不明確、要自己去問、要寫設計。他們甚至找了一群正職員工來角色扮演不同的 stakeholder（利害關係人），讓實習生自己去訪談、自己整理出需求。
第二，加了大量的設計文件評析。給你看幾份寫得爛的設計文件，一群人討論它爛在哪。
第三，也是變動最大的：讓實習生做程式碼審查。以前實習生基本上不會被指派審查別人的程式碼，今年他們排了三天的專門訓練，看預先準備好的功能、寫審查意見，然後對「答案卷」，四個人一組討論哪些意見他們不同意。
他們也承認踩了坑。早期有一批實習生，課程一開頭就強調多工跟 vibe coding（放手讓 AI 一次生一大段程式碼的做法），事後檢討覺得這個開場定錯調了，後面整個歪掉。改版之後改成從「把測試套件寫到很高品質」開始。
還有一個很誠實的觀察：如果你要求學生「這段程式碼是你的，你要負責讀懂、要改到夠好」，但同時又給他一個大到根本讀不完的任務量，那你想傳遞的訊息就傳不出去了。工作量跟教學訊息之間是會打架的。
我的幾個判斷
第一，「難度剛好」的練習題正在絕種，這件事會慢慢滲透到所有領域。
Minsky 在節目裡講了一句我覺得最重的話：簡單到適合初學者、又難到 LLM 沒辦法一次搞定的題目，交集已經接近空集合。
這不是程式教育專屬的問題。任何靠「作業」訓練人的領域都會遇到，寫作、會計、法律文件、財務建模都一樣。以前老師的工作是設計題目，以後老師的工作會變成設計「在什麼情況下不准用工具」。
第二，最值錢的能力從「產出」轉到「驗證」，而驗證這件事沒有捷徑。
Aaron 的立場很清楚：即使之後你讀的都是 AI 寫的東西，你至少要親手完整做過一次，才有資格評估它。這跟一份報價四百萬美金的工作，兩個人花三小時做掉了裡面講的分級框架是同一件事的兩面：能用工具的人很多，能判斷工具輸出好壞的人才稀缺。
第三，這集最能直接抄的一招，是「learning goals」的動詞測試。
不要騙自己，把你想教會別人（或想學會）的事情，改寫成「結束之後我將能夠⋯⋯」加一個具體動詞。如果你寫不出來，代表你根本不知道自己在教什麼，或在學什麼。這一招不用是老師才能用，帶新人、寫文件、做內訓、甚至規劃自己的學習，都適用。
最後留一個沒解的問題。Aaron 說他對「讓模型全部寫完、最後再一次讀完」這個流程開始感到懷疑，但他也沒有更好的答案。這個問題我自己也還在想，只是至少現在知道它是個問題了。
這類把 AI 講到實務層的內容我會持續整理，訂閱 wilsonhuang.xyz 就不會漏掉。
Sources:
推薦閱讀
喜歡這篇文章嗎？
訂閱電子報，每週收到精選技術文章與產業洞察，直送你的信箱。
💌 隨時可以取消訂閱，不會收到垃圾郵件