拉霸 vs. 氣圍開發（AI 開發）
你以為你在做「工程」，但你也可能在做「賭局」。 差異不在於你用不用 LLM，而在於你是否把它當成可控流程的一部分。
講者：吳相勳｜元智大學 終身教育部 主任
你以為你在寫程式，
但你其實是在跟一台極度聰明、極度不穩定的系統協作。
如果你沒有流程、沒有驗證、沒有停手點，那很容易會變成：買 token → 點生成 → 期待奇蹟。
一句話 一致性可以提高，但黑盒子不會自動變白盒子；你要做的是把不確定性放進「可管理流程」。
你以為你在做「工程」，但你也可能在做「賭局」。 差異不在於你用不用 LLM，而在於你是否把它當成可控流程的一部分。
(5,3) → add(a,b) → 8
你知道它怎麼算，你能追溯邏輯，你能重現結果。
Add(5,3) → LLM → 8
你可能拿到正確答案，但你難以說清楚它為何如此回答。
你無法控制 LLM。
這代表你面對的是黑盒子
給我兩個一月北海道玩雪的景點 → LLM →
看似合理，但你不知道它為何選這兩個、也不保證下次相同。
給我 2 個一月北海道玩雪的景點 → LLM →
同一任務，不同答案；你得到的是「樣本」，不是「定理」。
這就是黑盒子問題：LLM 的輸出是機率導向，它在嘗試生成「看起來最合理」的答案，而不是以可追溯演算法推導。 因此你需要把它放進流程：固定輸入規格、記錄版本、要求來源、設計驗證與停手點。
這個實驗的目的不是說「LLM = 賭博」，而是讓學生真正記住：你面對的是一個機率系統。 若你把它當 deterministic function，就會在不一致出現時，不斷用「再一個提示」去賭下一次輸出。
教師可控 用拉桿調一致性（像調參數），或直接輸入連拉次數與目標大獎率，示範「一致性可以提升，但仍非白盒子」。
你可以這樣講給學生：
當然不是。
LLM 的限制很清楚：黑盒子、機率導向、可被誘導、偶爾會幻覺；但它的優勢也很清楚：資料量、語言能力、組合能力與產出速度。 真正的關鍵，是把它放進可管理的流程裡，而不是把它當成一次性的神諭。
「LLM 讓你得到一個以前拿不到的技能，但那不是內化能力；你需要流程，才能把它變成穩定產出。」
你要傳遞的不是「不要用」，而是：把它變成可控流程的一部分。 讓學生知道哪裡需要驗證、哪裡需要版本化、哪裡需要停手，哪裡需要回到「問題定義」。
你可能會中大獎，也可能什麼都沒有。閃爍的燈光，引人注目的動畫。
你可能會得到一個無錯誤的應用程式，或者毫無意義的垃圾代碼。
下面三個拉桿，讓你把自己的狀態量化，並立刻看到「下一步該做什麼」。
這個技能包的目的很單純：把 LLM 的黑盒子特性變成你能管理的流程。 你會看到不同 LLM 的個性差異、輸出波動、以及你如何用「指令設計＋驗證」把結果拉回可用。
你需要先下載以下字幕檔案，並上傳到對話介面中：
https://1drv.ms/w/c/3c9ecae1ec80a222/IQAZ84eWVpQxTqs4buW3O7k-AQ7zHgG1rFRzq3GoL1KCfio?e=4l0mzW
為什麼要上傳？因為你要讓 LLM 在同一個可控上下文裡做事，避免它自行腦補外部細節。
Gemini 對話指引
建議做法：同一份字幕，用兩個 LLM 跑一次；記錄差異；把「可重現」與「可驗證」當成評分標準，而不是把「寫得像」當標準。
如果你想知道這些話是不是只停留在概念，最直接的方法就是看實作。 我把許多課程、工具與研究成果，做成可操作、可互動、可被一般人理解的呈現方式。
這些都是你可以做得到的。你不必一次做到全部，你只要從一個小頁面、一個小工具、一個可驗證的教學模組開始。
所以，我說這是教學者的「黃金時代」。
你會在實作中看見五件事：
在學生方面，你無法阻止學生使用 LLM 完成作業、專案。這不是立場問題，而是現實問題。
這個時代你需要教導學生：如何利用 LLM 學習，而不是如何利用 LLM 偷渡。
學生不能只是當 LLM 的搬運工（複製輸出貼到報告）。我會要求附上與 LLM 互動的完整過程。
工具：Chrome Web Store 可找 Exporter（例如 ChatGPT Exporter）。
依教學主題設計小型練習題：每題揭露一個限制與一個修正方法。
例：教財務比率時，讓學生比較「LLM 文字接龍」與「LLM Call Out Python」的品質差異，並要求寫出驗證 checklist。
在 AI 時代，許多「可被標準化、可被大量複製」的工作會快速被水位線淹沒。 真正的差異，不在於你用不用 AI，而在於你是否把自己的價值往水位線以上移動：往「原理、判斷、意義、現場複雜度」移動。
重新定義研究價值：在 AI 時代，學術界的「水位線」上漲得最快。 文獻回顧、數據清理、基礎程式碼撰寫、甚至標準化的論文結構，都逐漸淹沒在水位線下。
對於現在的大學生來說，情況最為險峻。他們入學時學的技能（如初級程式設計、基礎文案寫作）， 可能在畢業時剛好被「水位線」淹沒。
對抗水位線：拒絕成為「標準化零件」
「水位線」不是靜止的，它在上升。
在這個時代，最悲哀的不是「被取代」，而是你手中握有神燈，卻許不出一個偉大的願望。
在嚴肅研究中，LLM 不是聊天機器人，而是認知鷹架：它替你撐起「推理、整理、格式化」的暫時結構， 但證據與可追溯仍要由你來建立。
一句話：Gemini 讓你跑得快；NotebookLM 讓你跑得穩。
NotebookLM 的價值在於：它只基於你上傳的資料回答。你可以把它當成研究的「書房」： 你把資料放進去，它用引用把答案綁回資料。
提示：你越嚴格要求「出處」，幻覺越難混進來。
目的：把問題拆到「可驗證」的形狀。
目的：用引文把話說死（或說明資料不足）。
重點：先得到「可驗證」的假設，而不是漂亮段落。
你要的不是「像論文」，而是「能被引用、能被反駁」。
指令：
產出：Yin, R. K. (2014). Case study research: Design and methods (5th ed.). SAGE Publications.
過去談「自動化流程」，往往會想到 n8n 這類需要較多設置與維運的工作流平台；但對大學教師與學生而言，真正需要的是：在既有、熟悉的Google 生態圈裡，把可重複的學習/研究步驟固化成「可追溯、可改寫、可分享」的小流程。
Google Opal負責把任務拆解、串接資料與生成初稿；Google Vids負責把研究/學習輸出轉成可被觀看與傳遞的短影片（微課、方法教學、讀書會摘要），並與 Drive / Docs / Slides 無縫協作。
定位：Opal 不是要取代研究者，而是把你從重複工作解放出來，讓你把力氣花在方法、驗證與判斷。
Google Vids 的核心不是「剪輯技巧」，而是把文件/投影片快速變成一段結構清楚的影片：可用提示詞與 Drive 檔案生成分鏡與腳本，加入素材、配樂、旁白，並像文件一樣共同編輯。
定位：Vids 讓「研究輸出」變成「可分享的學習資產」，並保留在 Drive 裡方便版本控管與協作。
提示：把「不得腦補」寫成硬規格，才會把黑盒子收進可控流程。
下一頁：在「自動化產線」可以跑起來之後，最需要的是策略警語：如何避免知識被快速生成後，反而更快變得平庸。
你設計完一個前端互動頁面（表單、精靈式 Wizard、投票、作答…）之後，下一步通常是：把使用者輸入「寫進後台」，讓你能在同一張表裡做統計、彙整、追蹤。 在 Google 生態圈裡，最輕量的做法是把 Google Sheets 當成資料庫，再用 Apps Script 當成後端 API（同時也能放前端頁面），完成「收集 → 記錄 → 統計」的最小閉環。
這個例子故意選得很「俗」：因為規則簡單、欄位固定、很好統計。學會之後，你只要把欄位替換成研究或教學題目，就能舉一反三。
若你的前端頁面也放在 Apps Script（HTML Service）裡，前端就能用 google.script.run 直接呼叫後端函式寫入 Sheets。
這是教學場景最穩定的路徑：設定少、權限清楚、不容易踩到跨網域（CORS）問題。
const SPREADSHEET_ID = '你的 Sheet ID';
const SHEET_NAME = 'orders';
function appendOrder(data){
const ss = SpreadsheetApp.openById(SPREADSHEET_ID);
const sh = ss.getSheetByName(SHEET_NAME) || ss.insertSheet(SHEET_NAME);
// 建議欄位：時間｜填寫者｜品項｜杯型｜甜度｜冰量｜數量｜備註
sh.appendRow([
new Date(),
data.userId || '',
data.drink || '',
data.size || '',
data.sugar || '',
data.ice || '',
Number(data.qty || 1),
data.note || ''
]);
return { ok:true };
}
function submitOrder(){
const data = {
userId: document.querySelector('#userId').value.trim(),
drink: document.querySelector('input[name="drink"]:checked')?.value || '',
size: document.querySelector('input[name="size"]:checked')?.value || '',
sugar: document.querySelector('#sugar').value,
ice: document.querySelector('#ice').value,
qty: Number(document.querySelector('#qty').value || 1),
note: document.querySelector('#note').value.trim()
};
google.script.run
.withSuccessHandler(() => alert('已送出！'))
.withFailureHandler(err => alert('送出失敗：' + err.message))
.appendOrder(data);
}
教學時可把「userId」改成學號/員編；也可加上課程代碼、題目版本、分組代碼，方便後續清洗資料。
若你希望前端頁面維持為獨立檔案（例如放在學校網站、GitHub Pages、或任一靜態主機），可以把 Apps Script 部署成 Web App，
用 doPost 接收 JSON 後寫入 Sheets，再由前端用 fetch 送出。
注意：跨網域呼叫可能遇到瀏覽器限制（CORS）。在教學場景，若要最穩定，仍建議用上面的「同一個 Apps Script Web App 放前端＋後端」做法。
const SPREADSHEET_ID = '你的 Sheet ID';
const SHEET_NAME = 'orders';
function doPost(e){
const data = JSON.parse(e.postData.contents || '{}');
const ss = SpreadsheetApp.openById(SPREADSHEET_ID);
const sh = ss.getSheetByName(SHEET_NAME) || ss.insertSheet(SHEET_NAME);
sh.appendRow([
new Date(),
data.userId || '',
data.drink || '',
data.size || '',
data.sugar || '',
data.ice || '',
Number(data.qty || 1),
data.note || ''
]);
return ContentService
.createTextOutput(JSON.stringify({ ok:true }))
.setMimeType(ContentService.MimeType.JSON);
}
const SCRIPT_URL = '你的 Apps Script Web App URL';
async function submitOrderFetch(){
const data = {
userId: 'A1234567',
drink: '紅茶拿鐵',
size: 'L',
sugar: '半糖',
ice: '少冰',
qty: 2,
note: '不要吸管'
};
const res = await fetch(SCRIPT_URL, {
method: 'POST',
headers: {'Content-Type':'application/json'},
body: JSON.stringify(data)
});
const json = await res.json();
if(json.ok) alert('已送出！');
}
你不需要先引入 BI 工具，就能做出第一版管理報表：
=QUERY(orders!A:H, "select C, sum(G) where C is not null group by C order by sum(G) desc label sum(G) '數量'", 1)
LLM 很擅長歸納，但原創性的理論突破仍需要你掌握：問題定義、反例設計、證據鏈的品質。 所以，你需要把「人機協作邊界」寫進你的方法論。
下一頁：把上面的方法，落在你自己的「教學／研究產線」上。
最後，在今天的分享之後，你有哪些 Lesson Learned？
你會開始採取行動是什麼？你的第一個小型專案會是什麼？
寫下來。就從現在開始。