這篇導讀整理自 Matt Pocock 的原始影片，聚焦 /teach 如何把一次性 AI 回答改造成可跨 Session 延續的學習系統。
010. 把十年教學經驗寫成 Skill｜真正的主角不是 Prompt
Matt Pocock 在影片開頭做了一個很有個人色彩的盤點：六年聲音教練，加上四年教授開發者，合計十年教學經驗。某次前往倫敦的長途巴士上，他嘗試把這些經驗寫進一個名為 /teach 的 Skill，再用它學習自己一直想會、卻遲遲沒有投入的 Rubik's Cube。依他的描述，這次體驗不像得到一份一次性的教學回答，而像遇到一位記得目標、知道進度，也會依偏好安排下一課的一對一老師。
這種「像老師」的感受當然屬於講者的主觀經驗，不能直接推論成所有使用者都會獲得相同效果。影片真正有意思之處，也不在於 AI 能解釋魔術方塊。今天任何主流模型都可以列出步驟、術語與公式；困難的是，單次回答往往不知道學習者為何而學、先前練過什麼、哪裡只是看懂、哪裡真的能做，以及下一次開啟新 Session 時該從何處接續。
因此，/teach 的主角不是一句神奇 Prompt，而是一套被寫入 Skill 的教學流程。這裡的 Skill，可以理解為提供 agent 一組持續遵循的任務規則、檔案結構與操作方法。它不只告訴模型「請當老師」，還規定先釐清 Mission、蒐集可信 Resources、建立課程、記錄回饋、更新參考資料，再根據進度調整下一步。教學理念因而不只停留在語氣設定，而被轉譯成可執行的工作流。
這項轉譯很重要。許多 AI 教學產品仍把焦點放在回答品質：說明是否清楚、例子是否足夠、語氣是否親切。但真正的學習跨越時間，還包含反覆練習、遺忘、誤判、修正、動機變化與目標收斂。若系統只處理眼前的一輪對話，再流暢的解釋也只是教材生成器。Matt 的實驗則把問題改寫成：如何讓 agent 擁有一個可持續運作的學習工作區？
這也解釋了為什麼影片雖然以 Rubik's Cube 為示範，最值得帶走的卻是系統設計。無論學的是程式語言、codebase、棋類、聲樂和聲，甚至人類語言，都可以追問同一組問題：目標如何定義？來源如何選擇？進度如何留下？能力如何驗證？下一課如何不太難也不太簡單？最後又如何讓學習者離開 agent，進入真正的實作與 community？這些問題，比「Prompt 要怎麼寫」更接近教學本身。
021. Stateful 才能教下去｜Skill 為什麼需要記住學生
影片先建立一個基礎區分：Stateless Skill 與 Stateful Skill。Stateless 指每次執行都近似重新開始，不會把上次結果保存到檔案系統，也沒有可供未來讀取的學習歷史；Stateful 則會將資料留在本機，或交由 MCP server 等外部系統保存，讓後續 Session 能恢復脈絡。這裡的 MCP 是 Model Context Protocol，可讓模型連接外部工具與資料來源。
Matt 用自己的其他 Skill 說明兩者並無高下之分。grill-me 的用途是針對某個主題追問使用者，直到對方準備好實作；它可以是 Stateless，因為任務邊界就在當次互動。grill-with-docs 則會建立 ADR（Architecture Decision Record，架構決策紀錄）、glossary 等 repo 文件，成果會累積並影響後續工作，因此屬於 Stateful。設計者真正該問的不是「有記憶是否比較高級」，而是任務是否需要跨時間延續。
學習幾乎天然符合 Stateful 條件。老師之所以能教下去，不只因為熟悉學科，也因為知道學生目前的位置。相同的「解釋 TypeScript generics」請求，對剛接觸型別系統的人、熟悉 Java 卻不熟 TypeScript 的人，以及正在設計函式庫 API 的資深工程師，合理答案應該完全不同。若每次 Session 都重問背景，學習者會負擔重複交代的成本；若乾脆不問，系統便容易退回平均化、看似完整但不貼近需要的教材。
/teach 選擇把狀態外部化，而不是假設模型會永久記住。這是整套設計中最務實的一步。模型的 context window 再大，也不等於穩定的長期記憶；不同 Session、不同 agent 或不同模型，更不保證共享完整脈絡。相較之下，檔案系統中的 Mission、Learning Record、glossary 與課程都是可見、可讀、可版本控制的狀態。使用者能檢查 agent 記錯了什麼，也能修改不再適用的目標。
不過，Stateful 也不是免費升級。保存越多資料，越需要處理過期資訊、互相矛盾的紀錄、隱私與刪除機制。學習者說「我懂了」可能只是當下感覺，不一定代表一週後仍能完成；agent 的診斷也可能錯誤。若系統把每次回報都當成永久真相，記憶反而會放大偏差。因此可靠的 Stateful 教學，不只要會寫入，也必須容許覆寫、降級信心、重新評量，以及清楚區分「使用者自述」和「經由任務觀察到的能力」。
影片沒有完整解決這些治理問題，但提出了一個重要設計方向：把長期教學看成狀態管理，而非聊天風格。當任務跨越多個 Session，Skill 的品質就不只取決於生成內容，還取決於它保存哪些狀態、何時更新、下次如何讀取，以及使用者是否能掌控這些紀錄。
032. 學習工作區｜Mission、Resources 與 Learning Record
/teach 在空目錄啟動後，首先建立的不是 Lesson，而是 Mission。影片中的 Mission 非常具體：Matt 想至少一次在無人協助下，把打亂的 3×3 Rubik's Cube 解開；目標是完成本身，不追求速度，也不追求理論。這段看似簡單的文字，實際上替後續課程劃出邊界。若目標改成參加競速賽，教材就必須重視 finger trick、計時與效率；若目標是理解群論，內容又會走向完全不同的抽象層次。
Mission 的作用，是把「學某主題」轉成可以判斷是否接近完成的任務。它也保護學習者免於內容無限擴張。生成式 AI 很擅長補充更多知識，卻不自然地知道何時該停；一份明確 Mission 能讓 agent 篩掉與當前成就無關的理論。這不是降低知識價值，而是承認學習資源有限，順序與取捨本來就是教學的一部分。
第二個元件是 Resources。Skill 在首次執行時搜尋 primary source 與高可信來源，之後再持續更新。這個設計把「找資料」從每堂課的臨時動作，提升為工作區中的共享基礎。若運作良好，Lesson 不必每次重新拼湊網路資訊，術語與步驟也較容易保持一致。不過，「高可信」仍不能只靠 Prompt 宣告；不同領域需要不同的來源層級、日期要求與衝突處理方式。醫療、法律或快速變動的軟體文件，尤其需要來源可追溯與更新時間。
第三個元件是 Lessons。影片中的課程依序編號，存放在 lessons 資料夾，每一堂都是獨立 HTML。第一課只處理結構、記號與白色十字，刻意限制在當下需要。這種切分讓學習路徑不是預先生成一整套固定課綱，而是根據後續回饋逐步展開。Matt 形容它像是一門「邊走邊形成的課」；較精確地說，它是一套滾動規劃的 curriculum。
第四個元件是 Learning Record。當 Matt 回報自己已能完成白色十字，agent 將結果記錄下來，供日後診斷。除此之外，工作區還會逐漸長出 glossary、solve card、cheat sheet 與 notes.md。glossary 收納 anatomy、notation、solving grip、daisy 等術語，讓後續課程可以簡寫而不必反覆解釋；solve card 把完整流程濃縮成練習時可快速查閱的單頁；notes.md 則留給 agent 記錄偏好與注意事項。
這套檔案結構的價值，在於把不同生命週期的資訊分開。Mission 相對穩定，Resources 需要查核更新，Lesson 是一次學習介面，Learning Record 隨練習累積，glossary 與 cheat sheet 則是跨課程重用的參考層。若全部塞在一份長對話裡，重要資訊很快會被淹沒；拆成有角色的文件，agent 才能在下一次工作時選擇性讀取。
編輯上仍要提醒：建立檔案不等於建立可靠的學習模型。Learning Record 的格式若只有「會／不會」，容易忽略提示程度、正確率、完成時間與保持度。更成熟的版本可以記錄證據來源、觀察日期、信心值與待複習時間。但影片已經示範一個清楚起點：好的 AI 學習工作區，不只是教材倉庫，而是目標、證據、來源與參考資料各自有位置的可檢查系統。
043. HTML 教材｜從文字回答走向互動練習
Matt 明確選擇 HTML 而非 Markdown，理由是 HTML 更有表現力，也能提供互動。他展示的 Lesson 包含圖解、短說明、提示框、常見陷阱、測驗，以及可點按的動作練習。到了角塊循環課程，頁面甚至提供 guided mode，讓使用者逐步操作 U、R、U prime 等記號。講者看到成品時的驚喜很真實，但對系統設計而言，重點不是「頁面很酷」，而是教材開始能承載行為。
純文字回答主要處理 knowledge：概念是什麼、步驟有哪些、為什麼成立。學習卻還包含 skills，也就是在情境中完成動作的能力。知道 Rubik's Cube 公式，不代表雙手能流暢執行；讀懂 API 文件，也不代表能在真實 codebase 找到修改位置。HTML 讓 agent 能把說明、視覺提示、操作元件與測驗放在同一介面，縮短「讀到」與「做到」之間的距離。
影片把 quiz 視為一種基本 feedback loop。這個定位相當合理：測驗不是目的，而是在沒有更豐富觀察方式時，用來取得學習訊號。選擇題可以檢查辨識，填答可以檢查回憶，但若目標是解魔術方塊，最好的證據仍是實際完成；若目標是學程式，最好的回饋可能來自執行測試、閱讀錯誤、修改程式與 code review。HTML 可以包裝 quiz，卻不能保證評量測到的正是 Mission 所需能力。
因此，互動教材應依學習目標選擇 feedback loop。對記號，可用辨識與轉換練習；對動作序列，可用逐步提示後逐漸撤除；對除錯，可提供有缺陷的最小案例與測試；對架構判斷，則可能需要比較方案、說明取捨，再由人類 reviewer 回饋。技術上的互動性只有在對應能力時才有教學價值，否則只是把靜態文字換成更多按鈕。
HTML 還帶來另一項優勢：Lesson 可以成為獨立、可重開的學習物件。它不依賴聊天畫面仍保留在原處，也能沿用既有 house style。下一次 agent 生成新課時，可以先讀前一課的版型與互動習慣，維持一致性。對 codebase onboarding 而言，頁面甚至可以連到 repo 中的實際檔案、嵌入小型練習，或呼叫本地測試工具。
相對地，完整瀏覽器能力也增加風險與成本。生成的 JavaScript 是否安全？外部資源能否長期存取？無障礙、鍵盤操作與行動裝置是否可用？錯誤互動會不會強化錯誤答案？若每堂課都生成大量客製前端，維護負擔可能反過來吞噬好處。較穩健的方向，是建立受限制、可測試的元件庫，讓 agent 組合既有練習模式，而非每次自由生成整個應用。
所以，HTML 並非天然優於 Markdown。當任務只需要閱讀、查詢或快速參考，Markdown 更輕、更透明；當技能需要操作、模擬、逐步提示與可觀察回饋時，HTML 才真正展現價值。/teach 的貢獻，是把輸出格式視為教學設計的一部分，而不是單純的視覺包裝。
054. 跨 Session 延續｜AI 如何讀取進度再設計下一課
影片最能顯示 Stateful 差異的片段，發生在一次新的 Session。Matt 只執行 /teach，再回報自己現在幾乎可以完成 Rubik's Cube，但角塊循環仍未完全記住。由於當下 context 是空的，agent 沒有假裝記得；它先讀取教學工作區、查看 solve card 與先前 Lesson，再判斷使用者目前的位置。
agent 給出的診斷是：角塊循環在概念上已經理解，缺的是 muscle memory。接著它查看既有的記憶課程與較早 Lesson，以配合原有 house style，最後生成一堂只聚焦該演算法的新課。這個流程可以整理成一個循環：讀取狀態、接受近況、形成診斷、選擇下一個學習目標、生成練習、取得回報、更新 Learning Record。
真正的個人化發生在「選擇不教什麼」。如果 agent 因為使用者提到角塊循環，就重新解釋整套 Rubik's Cube，內容即使正確也會浪費注意力。這次它接受「概念已懂」的前提，把任務縮成動作記憶，並提出「四步動作重複兩次」的 mental model。依 Matt 的現場反應，這個重新分組對他很有幫助；但它仍是單一案例，不能證明同一策略適合所有學習者。
跨 Session 的延續也改變了人與 agent 的分工。使用者不是被動等待系統測量，而要像面對一對一老師那樣描述困難：「哪裡做得到、哪裡不穩、用了哪些提示、練習時發生什麼。」agent 則把自述與工作區紀錄結合，提出下一步。這種合作比「AI 自動知道一切」更現實，也提醒我們，自我觀察與精確回報本身就是學習能力的一部分。
然而，診斷環節最容易產生過度自信。使用者說「我懂概念」，可能只是熟悉說法；agent 看見完成紀錄，也未必知道當時用了多少提示。若下一課完全建立在錯誤診斷上，個人化反而會把人帶往錯誤方向。因此系統應保留小型驗證：請學習者先無提示完成一次、解釋關鍵選擇，或在延遲一段時間後重新測試。狀態是推論材料，不是不可質疑的事實。
另一個工程問題是 context selection。工作區使用越久，Lesson、紀錄與參考文件越多，不可能每次全數塞進模型。Skill 需要知道哪些檔案是目前決策的最小充分資訊：Mission 決定方向，近期 Learning Record 顯示變化，glossary 提供共同語彙，相關 Lesson 維持銜接。影片中 agent 主動選讀 memorization lesson 與一堂較早課程，正是這種檢索策略的雛形。
因此，跨 Session 延續不是把聊天紀錄永久保存那麼簡單。它需要結構化狀態、可修正的學習證據，以及一套在每次啟動時重新建構情境的程序。/teach 讓我們看到：所謂 AI 記得學生，實際上可以是 agent 可靠地閱讀一個由雙方共同維護的工作區。
065. ZPD 難度甜蜜點｜不無聊，也不被嚇退
Matt 用 Zone of Proximal Development（近側發展區，以下簡稱 ZPD）描述 /teach 的難度原則。依他在影片中的說法，理想課程應讓學生受到恰當挑戰，卻不感到恐懼；內容必須精簡、緊湊，準確落在既不無聊、也不致被嚇退的範圍。這個概念成為 agent 選擇下一課時的共同語言。
ZPD 原本不是一個只靠「調低難度」就能實現的按鈕。它關心的是：學習者目前能獨立完成什麼，以及在適當協助下能完成什麼。這裡的協助可以是提示、示範、分解步驟、工具、同儕或老師；當能力提升，支架應逐步撤除。角塊循環 Lesson 的 guided mode 正好提供一個直觀例子：先讓使用者按提示完成，再關閉引導，轉向獨立回憶。
把 ZPD 寫進 Skill 的好處，是迫使 agent 抵抗兩種常見傾向。第一種是百科全書式完整：一次傾倒所有背景、例外與進階知識，讓課程看似權威，卻超過當下可吸收範圍。第二種是過度簡化：為了友善而反覆說明已經會的內容，沒有提供足以成長的挑戰。ZPD 要求 Lesson 同時參考 Mission 與 Learning Record，只挑下一個可達成、又能推進能力的步驟。
但「甜蜜點」不能只靠模型猜測。比較可靠的調節需要觀察訊號，例如完成正確率、是否依賴提示、反應時間、錯誤類型、主觀負荷與延遲後保持度。若使用者連續成功，可以減少支架或增加變化；若反覆在同一步失敗，則應縮小任務、換一種表徵，甚至回頭補先備知識。這是一個持續校準的控制問題，而非第一次建立個人檔案後就永久解決。
此外，動機也不是單純由難度決定。有些人願意先看完整地圖再拆解，有些人偏好立刻動手；有人受明確進度鼓舞，也有人會被頻繁測驗消耗。notes.md 記錄偏好，可能幫助 agent 調整表現形式，但不應把偏好僵化成標籤。學習者在不同階段需要的節奏可能改變，系統最好定期確認，而不是因為一次回饋便永遠採用同一模式。
ZPD 最值得移植到 Skill 設計的地方，是它提供一項可操作的審查問題：這個輸出究竟對準使用者「下一步能學會的事」，還是只展示模型知道多少？前者需要狀態、診斷、支架與回饋；後者只需要生成。/teach 尚未證明 agent 能穩定找到每個人的 ZPD，但它至少把難度調節放到系統中心，而不是把個人化縮減為稱呼姓名或改變語氣。
076. 從 Onboarding 到跨領域學習｜價值與邊界
影片最後把 /teach 從 Rubik's Cube 推向更廣的使用情境。最具體的是工程 onboarding：新人可能熟悉技術棧，卻不了解公司的 problem domain；也可能熟悉業務，卻從未使用 TypeScript。傳統文件通常面向假想的平均讀者，難以同時適配這些差異。Matt 設想替每位新人建立獨立工作區，讓 agent 指向 codebase，依其背景安排概念、檔案與練習。
這項構想的吸引力很明顯。穩定的 Mission 可以定義新人需要完成的工作；Resources 可以連到原始碼、ADR、runbook 與正式文件；Learning Record 可以記錄已走過的模組與仍待釐清的概念；HTML Lesson 則能結合 repo 導覽、測驗和小型修改任務。相較於一次讀完整份 onboarding 手冊，逐步、依背景展開的學習路徑，確實值得團隊試驗。
不過，影片所說的「以創紀錄速度得到有生產力的員工」是講者的期待，不是經驗數據。企業導入還會面臨權限邊界、專有程式碼外洩、文件與實作不一致、錯誤建議、評量壓力，以及誰負責審核教材等問題。若 agent 根據過時 ADR 教新人，個人化只會更有效率地傳播錯誤。合理做法是把它定位成 onboarding 輔助層，並由 code owner、mentor 與實際任務提供校正。
跨領域學習也有相同邊界。Matt 想用它學西洋棋開局、聲樂和聲、程式語言與人類語言。工作區、回饋迴圈與 ZPD 的原則確實可移植，但每個領域的有效證據不同。棋類可以用對局與局面分析，程式可以用測試與 review，發音需要聲音輸入和專業聽辨，身體技能則涉及安全與姿勢。通用 Skill 可以管理流程，卻不能抹平領域專業。
影片中另一個值得保留的限制，是 knowledge、skills、wisdom 的區分。Resources 與解說協助取得 knowledge；互動 Lesson 與練習發展 skills；wisdom 則來自與其他學習者、實務工作者和真實情境互動。Matt 主張，當問題需要 wisdom，agent 可以先協助回答，但最終應把學習者引向 community。這形成了一種退出機制：成功不是讓人永遠依賴 /teach，而是讓人有能力離開它。
這也為「把老師裝進 Skill」補上一個必要修正。真正被封裝的不是完整教師，而是一部分可形式化的教學工作：釐清目標、整理來源、安排小步驟、留下紀錄、生成練習與提醒下一步。老師與 community 的其他功能，例如理解沉默、建立信任、處理身份與情緒、示範專業判斷、承擔評量責任，並不會因為工作區有了幾個 Markdown 和 HTML 檔就消失。
Matt 對開發者的最後期許是：工程師正率先在 AI 擅長的 coding domain 中累積合作直覺，未來可以把這些模式帶到程式以外。這仍是一項帶有立場的預測，但 /teach 確實提供了具體例子。可移植的不是「AI 什麼都能教」，而是開發者已熟悉的系統思維：明確狀態、可信輸入、可觀察回饋、漸進任務、失敗復原與人類升級路徑。
若把影片當成產品宣傳，容易停在「AI 像真人老師」的驚喜；若把它當成設計草圖，收穫則更扎實。一次回答如何變成跨 Session 的學習系統？答案不是更長的 Prompt，而是把 Mission、Resources、Learning Record、互動介面、ZPD 與 community 組成閉環，並對每個環節保留檢查與修正的權利。這才是 /teach 最值得延伸的部分。