先鋒小隊的一次聚會上，有位成員分享最近處理的一項工作。我一路聽下去，慢慢發現：他採用的還是原本那套做法，並沒有真正把前陣子教過的 Context Engineering 用進去。我當下沒有點破。心裡反而閃過一個念頭：**是不是我每次都急著介紹新東西，步調太快了？**我才剛講完一個概念，很快又覺得大家應該繼續往下一步走。可是，我講過了，不代表每個人已經有機會把它放進自己的工作裡。更何況，每個人的學習起點本來就不一樣。我卻好像一直用同一套節奏，帶著所有人往前。

有些人先理解原理，再尋找應用

這個念頭讓我想起以前合作過的幾位工程師。每當新的技術或架構出現，他們常常會先研究背後的原理：為什麼需要這個東西？原本的方法遇到了什麼限制？新的架構又是怎麼解決的？他們會自己查資料、動手測試，把整套運作邏輯搞懂，再回過頭來思考可以怎麼應用。先有架構，再有應用。不一定是因為眼前正好有某個工作問題非解不可。有時候，光是新技術本身，就足以讓他們產生興趣。這也是我過去很熟悉的學習方式。當我想教一個新概念時，很自然就會從原理、架構和技術演進開始說起。我以為，只要大家理解了這項技術為什麼出現，自然就知道可以怎麼使用。但先鋒小隊讓我開始看見，並不是每個人都從這個入口進來。

有些人要先知道：這跟我有什麼關係？

回頭看那次分享，我後來想通了一件事。那位成員不是不願意學，也不是沒有聽懂 Context Engineering 是什麼。他只是還沒有把這個概念，跟自己手上真正卡住的工作問題連在一起。如果一個人每天在意的是報表怎麼整理、活動怎麼規劃、個案資料怎麼處理，那麼「Context Engineering」本身並不會自然成為他的問題。他更可能先問：這跟我現在做的事有什麼關係？它能不能幫我少做一點重複工作？它會讓結果變得比較好嗎？如果這些問題還沒有答案，一個概念即使再新、再重要，也很難真正進入工作。這並不單純是工程師與非工程師的差別。比較像是兩種不同的學習入口。有些人會先被原理吸引，理解以後再尋找應用。有些人則需要先看到一個跟自己有關的問題，確定這項能力能幫上忙，才願意回頭理解背後的原理。而我原本的教法，明顯比較偏向前一種。

我以為自己在教得更完整，對方可能只覺得東西越來越多

想到這裡，我才意識到另一個問題。站在教學者的位置，我很容易覺得：既然 AI 持續進步，我也應該趕快把最新的概念帶給大家。Prompt Engineering 講完了，就往 Context Engineering 走；工具會用了，就應該開始理解 Agent、RAG 和 MCP。我以為自己是在替大家補上一張越來越完整的地圖。但對學習者來說，那張地圖可能只是出現了越來越多陌生的名詞。前一個概念還沒跟自己的工作產生關係，下一個概念就已經來了。久而久之，他可能記得自己聽過，卻不知道什麼時候該拿出來用。這時候，問題可能不在於他學得太慢。而是我教得太快。

先從正在發生的工作開始

那次聚會之後，我調整了先鋒小隊的進行方式。現在每次聚會，最優先的事情不是我準備了什麼新技術，而是讓每個人輪流分享：最近實際在做什麼？遇到了什麼狀況？哪個地方不順？現在是怎麼處理的？我先聽大家的工作，再根據每個人遇到的情境，補進相關的技術概念與方法。有時候，他缺的可能是更完整的脈絡；有時候，是還沒有把工作拆開；有時候，問題根本不需要新的 Agent，而是原本的流程還沒整理清楚。技術仍然會講，只是出現的順序改變了。不是先講完一套知識，再期待大家自己找到用途；而是先從正在發生的工作出發，等問題浮現，再把適合的概念放進來。

別人的案例，也可能成為我的入口

這樣的聚會還有另一個效果。因為所有人的分享和技術討論發生在同一個場合，學習不只來自我直接回應某一個人的工作。當一位同事說明自己怎麼使用 AI 整理資料，其他人可能突然想到：「我的工作裡好像也有類似的情況。」當我針對其中一個案例解釋 Context Engineering，原本覺得這個名詞跟自己無關的人，也可能因為看見具體用法，第一次理解它能解決什麼問題。一個概念與工作的連結，不一定只能由老師替每個人一對一完成。看見別人怎麼應用，也可能讓人找到自己的入口。

教學也許不是把所有人帶上同一條路

做法調整了，但我仍然沒有把握，這樣是否就能讓每個人都學得進去。有些人需要先看見應用，才會對原理產生興趣；有些人理解了原理，才有能力想像更多用法。即使是同一個人，面對不同題目時，進入學習的方式也可能不一樣。所以，答案或許從來不是找出一套最好的固定教法。而是持續觀察：這個人現在卡在哪裡？他需要的是先看見這件事跟自己的關係，還是先理解背後的原理？我能不能不要急著把所有新東西都教完，而是先陪他把一個概念，真正放進自己的工作裡？那次聚會讓我明白：教過一個概念，只代表資訊已經送出去；直到它和一個人真正在意的問題連起來，學習才算開始。