從動手做到 Agentic AI 驗證
AI 算出答案，就代表答案正確嗎？
資料來源：UCI Online Retail
當 AI 已經能寫出公式、產生 Python 程式碼，甚至協助完成資料分析，我們還需要讓學生親手操作嗎？
在設計這套課程時，我一直思考這個問題。如果課堂只剩下「把題目貼給 AI，再把答案交出來」，學生可能很快就能完成作業，卻不一定知道自己算的是什麼。同樣一份交易資料，有人算出明細筆數，有人算出發票張數，兩個數字都能順利產生，但它們回答的其實是不同問題。
因此，我把這次的教學影片命名為「從動手做到 Agentic AI 驗證」。
這條學習路徑不急著從最自動化的工具開始，而是先讓學生親手理解資料、經歷操作中的困難，再逐步引入 AI 生成程式碼與代理工具。最後，回到一個最重要的問題：
這個結果，我們有什麼證據可以相信？
第一站：Feel the Pain，先知道自己在算什麼
我把傳統手動操作的階段稱為「Feel the Pain」。
這裡的 Pain，不是刻意讓學生做繁瑣的工作，而是讓那些容易被自動化掩蓋的問題，先被看見。
例如，打開一份交易資料，看到同一個發票編號出現七次，這七列究竟代表七张發票、七位客戶，還是同一張發票中的七筆商品明細？
如果這件事沒有弄清楚，即使後面的公式完全正確，最後得到的也可能不是題目要的答案。
又例如，要計算一張發票的金額，不能只把單價加起來。學生必須先理解每筆商品的數量與單價，逐筆計算金額，再將同一張發票的明細合計。當題目進一步變成「平均每張發票金額」，分母也必須是發票張數，而不是商品明細筆數。
這些看起來很基本的操作，其實正是在建立資料分析最重要的基礎：先定義一筆資料代表什麼，再決定如何計算。
我希望學生先經歷這個過程。之後交給 AI 的，才是一個自己理解過的任務，而不只是一句模糊的要求。
用真實交易資料，讓問題自然浮現
這套實作使用 UCI Machine Learning Repository 的 Online Retail 資料集。它收錄一家英國線上零售業者在 2010 年 12 月至 2011 年 12 月間的交易，包含 541,909 筆紀錄，原始 Excel 有發票編號、商品編號、商品說明、數量、日期、單價、客戶編號與國家等八個欄位。資料來源：UCI Online Retail
選擇這份資料，不只是因為它有足夠多的紀錄，而是因為它能讓學生接觸到真實資料處理中的判斷問題。
在實作中，我們會遇到缺少客戶編號的明細、負數量、零單價，以及看起來相同的交易紀錄。這些情況不能一律被視為「髒資料」，更不能為了讓表格整齊，就全部刪除。
缺少客戶編號，是否代表這筆交易不應計入金額？同一張發票出現相同商品，是否就一定是重複輸入？看到負數，應該保留、排除，還是另外分類？
這些問題沒有辦法只靠按下一個「清理資料」按鈕解決。我希望學生練習的，是先說明分析目的，再決定處理規則，並且保留能夠回查的原始資料。
從 T00 到 T08，逐步建立查核能力
課程從 T00 的資料認識開始，再透過 T01～T08，將計算、資料品質與驗證連成一條完整的學習路徑。
先分清楚「筆數」與「不同編號數」
前面的任務先處理最基本、也最容易混淆的問題：全部商品明細有幾筆？有填客戶編號的明細有幾筆？不同商品、不同發票與不同客戶各有多少？
「有填客戶編號的明細筆數」不等於「不同客戶人數」。一位客戶可能購買多次，一次購買又可能包含多種商品。如果把這些層級混在一起，後面的平均數、比例與客戶分析就會失去意義。
再處理金額、重複與缺漏
接著，學生開始計算交易金額，檢查完全重複的明細，以及「發票編號＋商品編號」相同的紀錄。
這兩種重複的意義並不相同。八個原始欄位完全一致，是一種查核情況；同一張發票出現相同商品，則是另一種。程式可以幫忙找出候選資料，但是否應該刪除，仍然需要進一步判斷。
缺漏檢查也不只停在「少了幾筆資料」。我們會繼續問：缺少客戶編號的交易，涉及多少金額？如果直接排除，分析範圍會改變多少？
讓學生看到缺漏對結果的影響，比單純記住一個刪除空白值的指令，更有學習價值。
最後，用分類與分組檢查數字是否對得回來
當資料依照規則分成不同類別，或依國家、年月、商品重新分組後，還需要做一次很重要的檢查：各部分能不能加回原始總數？
這就是控制總數的用途。
例如，分類後的筆數加總，應該能與原始明細筆數核對；國家分組的金額再加總，也應該能與相同範圍的全檔金額對上。
如果對不上，我們就有理由追問：是不是漏掉空白分類？篩選條件前後不同？金額單位混用了英鎊與分？還是某一步不小心重複計算？
在這個階段，學生開始從「我有算出一個數字」，走向「我知道如何檢查這個數字」。
Pareto 80/20：不要把常見說法當成預設答案
最後的 Pareto 分析，是我很希望學生停下來思考的一個練習。
我們經常聽到「少數商品貢獻大部分銷售」或「80/20 法則」。但面對手上的資料，不能先假定結果一定符合八二比例，再畫一張看起來合理的圖。
在課程中，我把它拆成兩個不同問題：
第一個問題是：將商品依金額由高到低排列，累積到總金額的 80%，需要多少個商品？
第二個問題是：取排名前 20% 的商品，它們實際貢獻多少比例的金額？
兩個問題方向不同，答案也不必然相同。
這個練習讓學生理解，圖表不只是呈現工具。在畫圖之前，必須先決定資料範圍、排序方式、累積方法與分母。否則，即使畫面漂亮，也可能只是把錯誤包裝得更有說服力。
第二站：讓 AI 產生程式碼，但保留學生的操作與判斷
理解手動流程之後，我們再把 AI 放進來。
這次我刻意把 Colab 的操作拆開，讓提示詞、AI 回覆、計算程式碼與答案欄各自有清楚的位置。
每一題都先提供可修改的提示詞。學生可以直接複製到自己使用的 AI 工具，也可以調整要求，再請 AI 產生 Python 程式碼。取得回覆後，先閱讀它採用的範圍與方法，再把檢查過的程式碼貼回 Colab 執行。
程式執行之後，學生還需要把結果填進對應的答案欄，最後才進行核對。
我保留這些步驟，是希望學生能分辨幾件不同的事情：提出問題、產生程式、執行計算，以及確認答案，不能被混成同一個動作。
AI 說它算好了，不代表程式真的執行過；程式執行成功，也不代表計算口徑正確。
提示詞因此不只是「幫我算一下」，而是一份簡短的工作規格。它需要交代使用哪些資料、保留哪些紀錄、如何處理缺值、金額用什麼單位，以及最後應該輸出哪些欄位。
當學生開始能夠寫清楚這些條件，也就開始具備與 AI 合作的能力。
第三站：從生成程式碼，走向有工具邊界的 Agentic AI
在這套課程裡，我也把「請 AI 寫程式」與「讓代理使用工具」分開說明。
前者是 AI 提供程式碼，由學生檢查並執行；後者則是讓代理在事先設定的範圍內，呼叫計算與驗證工具，再根據工具回傳的結果進行說明。
這個差別很重要。
如果只是讓模型自行產生一段「分析已完成、結果正確」的文字，並沒有增加可信度。因此，這裡的 Agentic AI 設計不讓模型任意執行所有操作，而是限制它可以使用的工具與任務範圍。
計算交給計算工具，驗證交給驗證器，AI 則負責協調流程與解釋結果。
即使接上 API，也不能把失敗當成成功。服務無法回應、模型設定不接受，或工具沒有完成驗證，都應該明確呈現，而不是換一段流暢的文字，把問題掩蓋過去。
我希望學生理解：自動化的程度越高，越需要清楚的權限、狀態與紀錄。
最後一站：不是問 AI「你確定嗎」，而是建立獨立驗證
這套課程最核心的安排，是把獨立驗證放在最後一道關卡。
所謂獨立驗證，不是再問同一個 AI 一次：「你確定答案正確嗎？」而是透過另外的計算與檢查流程，重新回到原始資料，確認結果是否符合事先定義的規則。
在這份實作中，驗證器會重新讀取原始 Excel，檢查各項任務結果，而不是根據 AI 的說明文字決定是否通過。
這也不代表驗證器永遠不會出錯。驗證程式本身仍然需要測試，規則也需要被理解。它的價值，是讓我們多了一條可檢查、可重現的證據路徑，而不是只依賴模型的自信語氣。
對會計與商業資料分析而言，最後真正需要交付的，不只是一張表或一個數字，還包括來源、處理規則、計算过程，以及發現問題時可以往回追查的紀錄。
配套教材：讓不同起點的學生都能跟上
配合這條學習路徑，我整理了中英文 Colab 筆記本，並區分學生版與教師版。
學生版的重點是清楚的任務說明、已預填且可修改的提示詞、獨立的程式碼操作區，以及逐項填答與核對。教師版則提供參考數值顯示，方便課堂引導與討論。
兩種語言使用相同的任務編號與計算規則。中文說明協助學生理解操作，Python 變數與資料欄位名稱則保留英文，避免翻譯造成執行上的混淆。
在教學安排上，也不必一開始就要求每位學生申請 API。先透過外部 AI 工具完成「提示詞 → 程式碼 → 執行 → 核對」的流程，再進一步介紹 API 與代理工具，就能讓學生逐步看懂自動化增加了什麼能力，又帶來哪些新的責任。
我們要培養的，不只是更快得到答案的能力
「從動手做到 Agentic AI 驗證」想傳達的，不是手動操作比較好，也不是所有工作都應該交給 AI。
我更在意的是：學生能不能理解自己正在處理的問題，能不能把要求說清楚，以及在收到結果之後，知道應該怎麼查核。
手動練習，讓我們看見資料與規則；AI 生成程式碼，讓我們練習描述需求與檢查方法；Agentic AI，讓我們思考工具協作與權限；獨立驗證，則提醒我們不能把專業責任交給一段看似合理的回覆。
工具可以幫我們減少重複操作，但對結果的理解與判斷，仍然需要自己建立。
歡迎透過這支影片，跟著同一份資料走過這條路徑。也歡迎老師、助教與同學分享實作中的問題：哪一步最容易混淆？哪一個 AI 產生的結果看似合理，實際上卻需要重新檢查？
這些問題，正是把 AI 帶進課堂後，值得一起學習的地方。