大型語言模型作為軟體開發的家教
最近在技術社群參與討論時，我觀察到一個讓人擔憂的現象。在討論第三方登入、OAuth 流程，或其他技術實作時，大家花在「討論概念」的時間越來越多，實際動手做的時間卻越來越少。
輸入越來越多，輸出越來越少
在大型語言模型流行之後，我們花時間取得知識或資料的比例，與花時間實作、練習、產出成果或透過親手實作累積經驗的比例，差距越來越大。簡單說，就是輸入越來越多，輸出越來越少。
這對學習來說是個警訊。特別是像我這樣不聰明的人，主要是透過自己做過的經驗來累積知識。真的動手做了之後，才能開始觸發內化的機制。
其實你要看一眼就明白事情並且想通細節，這是需要大量的背景知識在你腦中的。作為某個領域的新手，我們還是踏實一點的好。
動手做的真正意義
這個「動手做」不單純只是依照指示把動作做出來，還包含把自己的思考角度放到同樣的情境之內。因為單純的旁觀者無法設身處地去思考：
- 哪些資訊是必要的？
- 哪些資訊是選擇性使用的？
- 對於一個技術或判斷，需要什麼環境上的提示？
所謂環境上的提示，是指你與整個開發環境的互動得到的訊息。例如：
- 當你實際設定 OAuth client 時，Google Cloud Console 會提示你哪些欄位是必填的
- 當你測試 redirect URI 時，瀏覽器的錯誤訊息會告訴你哪裡設定錯誤
- 當你處理 token 時，開發者工具會顯示實際的 HTTP 請求和回應內容
這些都是你必須親自操作才能獲得的環境回饋，也是形成正確判斷的關鍵提示。
你的腦中需要有這些提示，才能意識到選擇是否合理。缺乏親身經驗的情況下，很難做出適當的決定。
社群討論中的發現
前陣子社群在討論第三方登入實作時，以 OAuth 為例，大家熱烈討論流程細節。有人選用原典但可能對新學習者較為深奧的術語解釋，有人換成貼近生活的例子，試著讓還不理解這個機制的人明白。
這是友善的舉動，但不一定會讓人更理解技術的實際內涵。被記住的，也許是比喻或生活化的例子，但我們還需要把這些例子 mapping 回原本比較專業的術語。它可能是定義上的東西，或是特定概念的名稱，當然還需要知道原始規格里規範的所有工作流程。
特別是在覺得理解後，再回頭去啃、去消化原本帶有門檻的技術文件或是規格書。
「大家有實作過嗎？」
看著討論陷入似懂非懂的僵局，我忍不住問：「大家是不是有自己實作過的經驗？像是實作 Google 登入？或是其他相似的功能？」
也有人補充比較平易近人的例子，使用 LINE 登入。
具體來說，你必須要：
- 建立 web application 提供 Google 登入連結
- 設定 OAuth client
- 處理導向 Google 官方登入頁面的流程
- 處理回傳的 authorization code
像這樣實際的經驗，大家是不是已經有了？
得到的回應讓我意外：多數人都沒有實作過。
學習方式的世代差異
我建議：「趕快去實作一次吧，實作過會比較好進入討論的狀況。」
沒想到馬上得到回應：「那我要怎麼得到這樣的經驗呢？」
我卡住了兩三秒。心裡想著：這不就是上網找文件試著做做看嗎？但想想又不對，在這個大型語言模型流行的時代，也許大家不再習慣第一手查文件或找教學。
這個反應顯示出學習方式的轉變：
- 以前：遇到問題 → 查文件 → 動手試 → debug → 理解
- 現在：遇到問題 → 問 LLM → 得到答案 → 複製貼上 → 可能還是不懂
打造 AI 家教的解決方案
既然大家已經習慣使用 LLM，那我就換個想法。花了一點時間寫了一個基礎的提示詞，它可以用來跟大型語言模型互動。簡單說，它就是你的 AI 家教。
第一版提示詞設計
# 開發指導 Prompt
## 角色設定
你是一位資深軟體工程師，已在公司服務多年，現在負責指導我這位新進工程師。
我是團隊中的菜鳥成員，具備基礎程式語言知識，但對開發工具、環境設置、
框架和函式庫的實際應用經驗不足。
## 專案背景
我們正在開發一個新服務，目前處於早期開發階段。作為新人訓練的一部分，
你將指導我實作第三方登入功能，特別是 LINE 登入，
而非傳統的帳號密碼方式。
## 開發環境
- 程式語言：Python
- 框架：FastAPI
## 指導原則
1. 清晰的概覽：在開始前，先描繪整體藍圖，闡明專案目標和必要步驟
2. 任務拆解：將大任務拆解為 5-10 分鐘可完成的小單元
3. 持續檢查：定期確認進度，及時解決問題
4. 簡化解釋：用淺顯易懂的方式說明複雜概念
5. 實際操作：提供具體的程式碼範例和步驟指引
## 指導流程
1. 專案準備
- 設置開發環境
- 安裝必要套件
- 建立專案結構
2. LINE 登入實作
- 了解 LINE Login 流程
- 設定 LINE 開發者帳號
- 實作 OAuth 認證流程
- 處理用戶資訊
3. 整合測試
- 單元測試
- 整合測試
- 除錯與優化
## 互動方式
- 我會提出疑問或回報進度
- 你根據情況提供指導、程式碼範例或問題解決方案
- 當我卡關時，你會提供漸進式提示，而非直接給出答案
- 適當提醒去查官方文件
## 成功指標
- 正確實作 LINE 登入功能
- 理解第三方認證流程
- 能獨立解決基本問題
- 建立良好的開發習慣
這個 AI 家教的設計理念是：
- 不直接給答案，而是引導學習者自己思考
- 先問學習者做了什麼，才給予指導
- 鼓勵動手實作，而不是只給概念解釋
- 在適當時機提醒去查官方文件
- 協助 debug 而不是替你解決問題
實際示範：在 AI 家教指導下完成專案
這件事沉澱了一晚之後，我想也許沒有看到實際案例，大家不太了解這種學習方式的價值。所以我開始用同樣的題目，在這位資深工程師家教的幫助下，完成了第三方登入的小專案。
整個過程我都記錄下來，大家可以透過 YouTube 播放清單觀看內容。從提示詞的編寫開始，打造我們自己的家教老師，並且跟著家教老師的引導，一步一步完成迷你專案。
完整的專案程式碼可以在 GitHub 上查看。這是一個使用 FastAPI 實作 LINE 登入的範例，展示了如何從零開始實作 OAuth 流程。
實作過程的重要性
透過這個過程，你會發現：
- 實際設定 OAuth client 時會遇到哪些問題
- redirect URI 的設定有什麼細節要注意
- 處理 authorization code 時需要考慮哪些安全性問題
- 為什麼官方文件會這樣設計流程
這些都是單純討論概念時難以體會的。
LLM 時代的學習平衡
在大型語言模型的時代，我們面臨一個矛盾：獲取知識變容易了，但累積經驗卻變難了。我們需要找到平衡點：
- 利用 LLM 快速理解概念
- 但不能停留在概念層面
- 必須動手實作才能真正內化
- 把 LLM 當作引導者，而不是答案提供者
結語
LLM 是很好的工具，但別讓它成為阻礙我們動手的藉口。透過適當的引導，我們可以把 LLM 轉變為學習的助力，而不是讓它成為我們逃避實作的捷徑。
下次當你想要理解一個技術時，不妨試試這個方法：找個 AI 家教，然後真的動手做一次。你會發現，那些概念突然變得清晰許多。
因為經驗，永遠是最好的老師。而 LLM，應該是幫助我們獲得經驗的助手，而不是取代經驗的捷徑。