回想起當初決定參賽的那個晚上，我參加了 Google GDG 與 iThome 舉辦的「2026 iThome 鐵人賽說明會與實戰工作坊」。
老實說，那時候的我根本就像一隻迷途羔羊。看著現場感覺滿滿都是大佬，大家好像都有自己的專業、自己的想法，而我一邊聽著說明會，一邊在腦袋裡不斷思考：我到底可以做什麼？又有什麼是我真的想做的？
想著想著，我突然想到一件事：「為什麼現在的 AI 聊天機器人，學生一問問題，它就直接把完整答案告訴你了？」
身為一個資訊管理系的大學生，同時也是一個兼職家教，我其實不太希望我的學生遇到不會的題目，就直接問 AI，然後把答案抄下來。因為我知道，知道答案跟真正理解，根本就是兩回事。
我希望 AI 可以幫助學生學習，而不是讓學生越來越依賴它。如果 AI 永遠只會提供標準答案，那它頂多只能當作業的解答工具，卻很難真正成為一位老師。
就這樣，過了幾天，我終於打開電腦，想說不然先試著實作看看、寫幾篇文章、囤一些稿好了。如果能趁開學前多寫幾天，之後就可以減輕不少壓力。
殊不知，這一寫，我竟然真的連續寫了好幾天。
從一開始只是想先囤稿，到後來真的鼓起勇氣報名，寫下第一篇開賽宣告，我就這樣踏上了這場 30 天的 iThome 鐵人賽之旅，挑戰 Build on Google AI 組別，以「未來教育 AI for Education」為主題。
老實說，當初真的沒有想過，自己可以把這個專案一路做到今天。
現在終於來到 Day 30 了。回頭看這一路，除了完成了原本想做的 AI 虛擬助教，也累積了很多一開始根本沒想過自己能學會的東西。
所以，趁著最後一天，我想好好整理一下，這 30 天我們到底做了什麼，以及這個專案未來還有哪些發展的可能。
這 30 天，其實就是不斷把腦中的想法慢慢實現出來。從最初的構想開始，我們先以最小可行產品（MVP）的方式，逐步完成一個能夠實際操作的功能。
一開始，我們透過 Google AI Studio 設定 System Instruction，讓 AI 遵循蘇格拉底式教學原則。
簡單來說，當學生提出問題時，AI 不會直接把完整答案全部告訴學生，而是透過提示、反問和拆解問題，引導學生自己思考。
這也是整個專案最核心的設計：我們不是要讓 AI 替學生完成作業，而是希望 AI 能幫助學生學會解題。
接著，我們使用 Google Stitch 協助設計初版介面，再逐步串接前端、後端與 Gemini API。
原本只是散落在程式裡的 Prompt，開始變成使用者可以實際操作的功能。這也讓我第一次更具體地理解，一個完整的 AI 應用程式，不只是呼叫模型 API，還需要考慮介面、資料如何傳遞和整體系統架構。
透過 Structured Output，我們讓 Gemini 按照指定的資料結構回傳結果，除了判斷答案對錯，也能進一步分析學生可能出現的理解偏差與錯誤類型。
因為我覺得，如果學生每次都只知道自己答錯，卻不知道自己為什麼錯，那其實沒有解決真正的問題。
後來，我們加入 Gemini Vision，讓學生可以上傳圖片，協助辨識手寫算式或題目，不再只能透過文字提問。
另外，也透過 RAG（Retrieval-Augmented Generation）建立教材知識庫，讓系統可以先從指定教材中檢索相關內容，再根據檢索結果回答問題。
這是我很重視的一個功能，因為我希望 AI 在教學時，能夠盡量依據指定教材，而不是學生問什麼，它就憑印象回答什麼。
我們也逐步加入 Function Calling，並設計核心機制 Understanding Gate。
這個機制的目標，是讓 AI 判斷目前的教學情境，再決定應該繼續引導學生思考，還是使用計算工具等功能輔助教學。
我希望它不只是會回答問題的 AI，而是能根據學生的理解狀況，選擇適合的教學方式。
最後，我們使用 Firebase Firestore 儲存學習紀錄，讓系統可以保留學生的對話與學習歷程。
有了這些資料，未來就有機會進一步分析學生的學習狀況，實現 Adaptive Learning（適性化學習）。
例如，學生已經理解某個觀念，就可以繼續挑戰更進階的題目；如果一直在同一個地方出錯，就應該回到基礎觀念，換一種方式重新解釋。
這也是我們希望 AI 虛擬助教未來可以做到的事情。
如果要說這 30 天最有印象的事情，我覺得不只是成功串接了多少 API，而是那些一直出錯、一直想辦法解決問題的時刻。
像是遇到 503 伺服器忙碌、API 呼叫失敗、部署出問題，或是 AI 明明已經設定好教學規則，卻還是忍不住直接公布答案。
每次遇到這些問題，都必須重新檢查程式，想辦法找出原因。
例如，當模型服務暫時無法使用時，我們就需要思考，能不能透過錯誤處理、智慧重試，或是切換至其他可用模型，降低單一模型發生問題時對系統的影響。
這些事情在一開始真的沒有想得那麼簡單。
以前我可能會覺得，寫程式就是把語法學好，再按照步驟把功能寫出來。但實際做過一個完整的專案之後，我才發現，真正的開發不是讓程式成功執行一次，而是當它出問題時，你有沒有辦法找到原因並解決它。
另外，這次的開發經驗也改變了我對寫程式的想法。
我只是一個資訊管理系的大學生，坦白說，過去遇到不熟悉的語法，或是看不懂程式為什麼這樣寫時，有時候真的會感到迷茫，甚至不知道該從哪裡開始。
但透過這次的專案，加上 Google AI 生態系與各種開發工具的協助，我慢慢發現，就算一開始不是什麼都會，也可以先把需求想清楚，再一步一步學習如何實作。
當然，這不代表有了 AI 就不需要學程式。反而是當專案越做越大，我越能感受到理解程式、系統架構和除錯的重要性。
AI 可以幫我加快開發速度，但我還是必須知道自己做了什麼，以及出了問題該怎麼處理。
這 30 天讓我從原本覺得自己可能做不到，到現在開始願意主動嘗試以前不敢碰的東西。當一個原本只存在腦海中的想法，真的變成可以操作的系統時，那種成就感跟完成一份作業真的很不一樣。
雖然鐵人賽的 30 天到今天就結束了，但對我來說，AI 虛擬助教還有很多可以繼續改善的地方。
目前我最希望發展的方向有以下幾個：
目前的互動主要還是透過文字和圖片。如果未來可以加入語音轉文字（STT）與文字轉語音（TTS），學生就能直接用說的提出問題，也可以透過語音聽取解釋。
我希望未來的使用體驗，可以更接近學生真的坐在家教面前，透過對話慢慢釐清問題的感覺。
既然系統已經可以保存學習紀錄，下一步就可以將這些資料整理成學生專屬的錯題本。
例如，自動整理學生常犯的錯誤、反覆出現的觀念盲點，再根據這些紀錄產生適合的複習題目，讓學生可以針對自己最需要加強的地方練習。
如果未來希望系統可以應用在學校或補教現場，我認為老師和家長的角色也很重要。
透過儀表板，老師可以查看學生的學習進度與常見錯誤，家長也能更清楚了解孩子目前的學習狀況。
AI 負責協助教學與整理資料，而真人老師仍然負責觀察學生、調整教學方式。我希望 AI 最後帶來的不是取代老師，而是讓老師有更多時間真正照顧學生的學習需求。
未來也希望可以加入知識圖譜，讓系統能夠理解不同知識之間的關聯。
例如，當學生在某個進階觀念上一直答錯，AI 可以進一步追溯這個觀念需要哪些基礎知識。如果學生連前面的定義都還不熟悉，就應該先回頭補足基礎，再繼續往下學。
當然，這些都還是未來的規劃，接下來還需要透過實作與測試，才能知道哪些功能最值得優先完成。
打到這裡，真的有一種終於結束了的感覺。這 30 天中間當然不是每一天都很順利，也不是每個功能都能一次成功。有些問題甚至會卡很久，原本以為已經解決的事情，過幾天又會冒出新的問題。
但也因為這樣，我才更清楚知道，一個真正可以運作的系統，背後有多少需要考慮的事情。
這次的鐵人賽讓我重新思考自己未來想學什麼、做什麼。以前可能會因為覺得自己程式能力不夠好，就不太敢去想太大的專案；但現在我發現，至少可以先從一個自己真正想解決的問題開始，再想辦法把它一步一步做出來。
對我來說，AI 虛擬助教不只是一個為了參加比賽而完成的專案，也是我第一次這麼完整地把一個想法實際做出來的經驗。
我也希望未來它不會只停留在這 30 天，而是真的有機會幫助學生，讓他們遇到問題時，不只是得到答案，而是能夠真正理解答案背後的原因。
最後，謝謝這 30 天持續寫文章、修改專案的自己，也謝謝這段過程中使用到的 Google AI 工具，以及每一次除錯帶給我的學習機會。
Day 30，完賽。
但對 AI 虛擬助教來說，這只是另一個開始。
我們下個專案見！
iThome鐵人賽
看影片追技術