為什麼這樣教
AI 可以先提出做法，學員仍要判斷哪些可以採用、哪些該拒絕、哪些還要補充資訊才能判斷，並把判斷依據寫進需求決策文件，供後續流程設計與重做時對照。例如，有標示來源不代表內容一定可信，AI 整理出的資訊也不能直接當成待辦事項。
課程設計總覽
先看懂這堂課要練習什麼
怎麼帶學員思考
課程刻意不先給出完整規格。學員先面對品質不一的模擬災害通報，用 AI 做出第一版；下午由 AI 分別模擬回報者、資訊整理者與現場執行者，讓學員進行訪談。學員接著選定服務對象，寫下需求取捨，畫出資訊處理流程，再回頭重做早上的版本。白天三個主要階段各安排一次分享；最後一個階段先完成流程設計，再依流程製作重做版。分享時，學員要說明自己接受或拒絕了 AI 的哪些建議，以及為什麼。
學員實際做什麼
先做第一版
整理品質不一的模擬通報，用 AI 做出可操作的工作台，並記錄資料缺漏、AI 自行補上的假設與無法判斷之處。
起始實作（Phase 0）：第一版工作台＋觀察紀錄＋AI 使用紀錄寫下需求取捨
訪談由 AI 模擬的使用者角色，選定服務對象，判斷哪些資訊可以使用、哪些必須排除，以及這一版明確不做什麼。
需求取捨（階段 01）：需求決策文件畫出資訊處理流程
把資訊進入系統後的處理方式畫成流程，標明由誰確認、資料不足時要退回補充還是暫時保留。
流程設計（階段 02）：資訊確認與處理流程保留第一版再重做
使用同一份資料製作第二版，再執行課程提供的程式自動檢查，確認程式是否符合前面寫下的需求與流程。
重做版
從一個案例看懂四類成果
第一版、需求、流程與重做版
這個模擬專案要處理兩個問題：來自不同管道的資訊是否可信，以及資訊要由誰確認。以下以公開工作區 t3-m4 為例，依序查看第一版、需求決策、資訊確認與處理流程及重做版。
安全提醒：下列起始實作與重做版原型仍可互動；除頁面公開顯示的示範密碼外，請勿輸入其他資料，也不要啟動 AI 分析。若仍啟動，輸入與 API 金鑰（存取外部 AI 服務的憑證）會送往所設定的外部服務；金鑰、服務網址與草稿也會保存在瀏覽器中。
起始實作 · Phase 0整合頁面中的 Phase 0開啟後選擇「原始資訊」或「整理工作台」 ↗需求取捨 · 階段 01需求決策GitHub 文件：服務誰、哪些事不做 ↗流程設計 · 階段 02資訊確認與處理流程GitHub 文件：人工確認、拒絕與保留 ↗重做版資訊整理者介面可用頁面明示的示範密碼進入，再切換另兩個角色 ↗
先操作第一版，找出一個可能誤判資訊的地方；再看需求文件如何界定服務對象與不做的事、流程文件如何安排確認與資料不足時的處理方式；最後操作重做版，確認畫面和操作是否落實前面的決定。例如文件若寫著「未經人工確認的資訊不能顯示為已確認」，重做版也應該照這項規則運作。
教學背景
這是一堂什麼課？學生是誰？
這是 SITCON 2026 夏令營第二天的全天主要課程，為程式經驗差異很大的營隊學員重新設計軟體工程內容。共同專案把真實公共協作中「資訊能不能信、誰有權決定」的工程問題，轉成不連接真實災害資料或服務的教學原型。
SITCON Camp 2026（學生資訊夏令營）
第十屆學生資訊夏令營，於 2026 年 7 月 8 日至 12 日在國立陽明交通大學舉行，主要課程涵蓋軟體工程、人工智慧與資訊安全。本案例只聚焦 7 月 9 日的軟體工程主題日。
「拒絕脆弱的 Vibe Code」
官方課名中的 Vibe Code，指只憑感覺讓 AI 寫出難以理解、協作或維護的程式。課程目標是讓專案不只寫得出來，也能面對需求變動。
從真實協作經驗轉化的模擬工作台
課堂參考 2025 年花蓮光復地區馬太鞍溪災害期間的民間協作平台經驗，把多來源通報、資訊品質、人工確認與責任分工轉化為可在瀏覽器操作的網頁原型。課堂資料均經模擬或改寫，原型不會讀取或寫入真實事件資料。本次課程未邀請受災社群或現場協作者參與需求驗證，模擬情境只供課堂練習。
學員年級與自述程式經驗差異很大
48 位學員的課前自述顯示，學員橫跨國中到研究所，年齡介於 12–29 歲、中位數 16 歲；有人還沒有用文字式程式語言寫過程式，也有人已附公開作品。
年齡分布：中間一半落在 15–17 歲
盒狀圖 · 共 48 份手機可左右滑動圖表。
最小值12 歲第一四分位數15 歲中位數16 歲第三四分位數17 歲最大值29 歲
展開完整年級分布、經驗線索與分類方法
48份納入彙整的課前自述每人只計營隊當時即將升上的一個年級
15 / 48升國二至升高一以營隊當時即將升上的年級表示
25 / 48升高二至升高三班級中人數最多的年級區間
8 / 48升大一至升碩二以營隊當時即將升上的年級表示
學員橫跨國中、高中、大學與研究所，自述經驗與期待也很多元
去識別化後彙整 · 共 48 份營隊當時即將升上的年級（每人一類）
自述中提到的經驗與期待（可重複）
一天的節奏與現場
實作、分享與重做交錯進行
白天分成三段：09:00–12:00 先做第一版；13:00–約 16:00 訪談並寫下需求取捨；約 16:00–19:00 完成流程設計與重做。每段實作後都安排學員上台分享；20:00–21:00 則先分組交流，再回到全班整理使用 AI 寫程式的經驗。詳細課表、照片與 Git 版本紀錄可在下方展開對照。
展開 09:00–21:00 課表、照片與 Git 版本紀錄對照
一條時間軸看懂：課表、課程階段、分享、照片與成果
共同刻度 · 09:00–21:00手機讀者可左右滑動時間軸。
| 課表時段／依課後紀錄整理的時段 | 課程階段與學員任務 | 學員分享與交流時段 | 全班成果在 Git 版本紀錄中的出現時段 |
|---|---|---|---|
| 09:00–12:00 | Phase 0：先做第一版，讓問題浮現建立共同語言、快速做出第一版，再指出哪些資訊不能相信、不能判斷或不能直接變成任務。 | 11:04–11:35，14 人次上台說明 | 起始實作成果約在 10:00–12:30 出現 |
| 13:00–約 16:00 | 模擬訪談與需求取捨需求與流程教材版本約於 12:30 出現在 Git 紀錄；把假想使用者觀點當成待驗證的需求假設，由人決定服務誰、今天不做什麼。 | 15:16–15:50，12 人次上台說明 | 需求文件約在 13:30–15:30 出現 |
| 約 16:00–19:00 | 流程設計與重做畫出人工確認與退回分支；保留第一版，使用同一份輸入資料製作重做版。 | 18:22–18:58，12 人次上台說明 | 流程文件約在 14:00–17:30、各工作區重做版首次提交約在 14:00–20:30 出現 |
| 20:00–21:00 | 晚間延伸：AI 協作經驗交流比較有效與失效的 AI 協作方式，整理採用、拒絕與仍不確定的地方。 | 20:10–20:20 有 5 人次、20:47–20:57 有 8 人次上台；中間為小組交流 | 重做版與晚間後續變更持續到約 21:00 |
四張代表照片，看見講解、實作、分享與晚間交流
7 月 9 日相簿 277 張中精選 4 張
09:47｜Phase 0 說明：講師以投影中的災害資訊工作台畫面，向全班說明第一階段任務。
點選照片可開啟 Flickr 原頁
14:17｜實作與巡堂：學員在電腦前實作，講師俯身查看畫面並與學員對話。
點選照片可開啟 Flickr 原頁
18:44｜流程設計與重做版成果分享：學員在教室前方，以投影畫面向全班說明階段成果。
點選照片可開啟 Flickr 原頁
20:33｜晚間小組交流：學員把椅子圍成小圈，一人站立發言，其他人面向發言者。
點選照片可開啟 Flickr 原頁公開教材與起始專案都能直接檢視
全班留下什麼
不只看最後網站，也看需求、流程與檢查
48 個工作區從共同起始內容延伸出不同 Git 修改歷程
來源追查 61 個工作區 → 成果統計 48 個主要工作區每個圓點代表專案的一筆 Git 提交，線條顯示這筆提交接續自哪一筆既有提交；圓點由左到右大致依提交時間排列。
線條先聚在一起、後來分開，表示多個工作區曾共用一段內容，之後各工作區留下不同版本。共同內容會先排除，再檢查各工作區後來實際修改了什麼。
窄螢幕可左右滑動，先看共同修改歷程向外分開的區域。
需要查閱標示時，展開可放大的向量原圖
原圖保留完整尺寸，可左右及上下捲動，用於查閱日期、工作區與分支標示；理解成果數字不必讀完每一條線。
47／48起始實作可確認有實質修改
38／48需求取捨可確認有實質修改
38／48流程設計可確認有實質修改
38／48重做版可確認有實質修改
成果依實際內容判讀，不以 /v1/ 為唯一條件。三項統計都以 48 位學員的個人工作區為分母：38 個可確認有重做修改；33 個在起始實作、需求、流程與重做版四類成果中都可確認有實質修改；另有 3 個沿用同隊需求成果後，在流程與重做版留下實質修改，因此四類成果都有可追查紀錄的工作區共有 36 個。若只採計課程指定的檔案與路徑，五項成果都可確認有實質修改的工作區是 15 個。
展開資料來源與涵蓋範圍
資料來源與整理方式
本文呈現彙整後的資料-v1 結尾、並在複製後留下新修改紀錄的工作區，會併回原工作區計算，只納入接續後的新修改。22 份課後問卷回覆如何描述課程收穫與困難
48 位學員中收到 22 份回覆，其中 13 份包含具體課程內容，其餘 9 份未列入主題計數；以下主題以這 13 份為基礎，同一份回覆可歸入多個主題。
8 份回覆提到形式新穎、有趣或提升投入感
3 份回覆提到看見完整專案脈絡；2 份回覆提到審查與校正 AI 產出；2 份回覆提到需求與整體思考
4 份回覆提到節奏、長時段或疲勞；3 份回覆提到目標、方向或第一步不清楚
1 份回覆同時提到講解清楚，卻不知道如何開始
展開問卷作答分布與文字回覆分類方式
| 問卷項目 | 5 顆星（份） | 4 顆星（份） | 3 顆星（份） | 2 顆星（份） | 1 顆星（份） | 總回覆（份） |
|---|---|---|---|---|---|---|
| 軟工主線課程收穫 | 15 | 5 | 2 | 0 | 0 | 22 |
| AI 寫程式經驗交流課程收穫 | 14 | 3 | 4 | 1 | 0 | 22 |
開放式回覆如何分類與計數：以每一份回覆為單位，同一份可歸入多個主題，同一主題在同一份回覆中最多計 1 次；22 份中有 13 份包含具體課程內容。空白、「無」、未提及具體課程內容的正面評語，以及無法辨識具體主題的玩笑式回答，均未列入主題計數。
展開全班各階段成果與需求／流程文件的 Git 提交順序
各階段成果的修改情形
分母：48 個學員工作區33觀察紀錄 可確認有實質修改
44AI 使用紀錄 可確認有實質修改
28需求文件組 可確認有實質修改
29流程文件 可確認有實質修改
27課程指定的重做版 可確認有實質修改
33 / 48四類成果都可確認有實質修改成果位置不限於課程指定路徑，但每一類都必須能辨識出相對於共同起始內容的修改。
36 / 48四類成果都有可追查紀錄33 個工作區的四類成果都可確認有實質修改；另 3 個沿用同隊需求成果後，接手後的流程與重做版也可確認有實質修改。只有複製、沒有接手後修改的工作區不計入。
需求與流程文件是否較重做版首次提交更早出現在 Git 紀錄中？
可判讀提交順序 · 共 38 個工作區| 文件類型 | 可確認早於重做版首次提交（工作區） | 未能確認較早，包含較晚提交或順序無法判定（工作區） |
|---|---|---|
| 需求取捨文件 | 26 | 12 |
| 流程設計文件／流程圖 | 16 | 22 |
各工作區成果索引：依四類成果逐一檢視
公開學員工作區 · 核對日期 2026-07-10表格先標示連結類型：「網站」可直接操作，「文件」開啟課程內容，「首次修改紀錄」顯示該階段成果第一次出現在 Git 的修改內容，不一定是最後版本。成果留在根路徑、非標準位置或後來被其他內容覆蓋時，以首次修改紀錄作為可追查入口。接手案例另標示「沿用同隊」；t8-m3 沒有公開版本歷程，只列為外部成果。
47起始實作（Phase 0）
38需求取捨（階段 01）
38流程設計（階段 02）
3938 項重做修改＋1 項外部成果
展開 48 位學員的各階段成果索引
課後回看
會寫程式之外，也要看見軟體要服務的人
中午，講師與隊輔交換課堂觀察時，談到有些學員面對刻意不給明確答案的任務，會先從不同角色的處境與實際需要出發，區分需要協助的人、提供資源的人與不同專業的志工，再思考系統該怎麼做。
這個課堂片段也讓我們重新看見人文社會視角在軟體工程中的價值。當 AI 能更快生成程式，判斷要解決什麼問題、哪些人的處境需要被看見，以及衝突需求如何取捨，反而更不能外包給工具。人文社會領域長期重視的觀察、詮釋與反思，不是工程之外的點綴，而是現代軟體工程需要共同培養的能力。
軟體工程教育，需要同時練習三件事
教學主張理解人與情境釐清要處理的問題與取捨
＋掌握技術限制辨認系統限制與 AI 產出的錯誤
＋運用工程方法落實到需求、流程、狀態、權限與測試
成果檢視
部分成果寫下判斷原則，程式未必真的照著做
部分 Git 版本紀錄中的文件已明確寫出「有標示資料來源，不代表內容就可信；AI 整理出的內容不等於可以直接派工的任務；資訊未經確認前不能顯示為已確認」；但部分程式仍未遵守同一套原則。
畫面做得完整，資料就可信嗎？
原始資訊、AI 整理結果與確認狀態需要分開呈現，不能讓畫面完整感取代證據。
寫著交由人確認，就已經負起責任嗎？
還要說清楚由誰確認、根據什麼、有哪些權限、如何處理爭議，以及是否留下操作紀錄。
文件寫了規則，程式有真的擋住嗎？
文件中的規則需要落實為程式中的判斷條件，並以自動化測試驗證，才能擋下不符合條件的操作。
從「說得出來」到「守得住」
本課程原型的工程檢視文件層
- 有標示資料來源，不代表內容就可信
- AI 整理結果 ≠ 可直接派工的任務
- 在介面標記為已確認 ≠ 完成事實查核
- AI 建議不能取代人的判斷與決定
需要
可執行的
防錯機制
可執行的
防錯機制
課程原型的程式層
- 固定使用課程提供的測試資料
- 不新增資料，程式執行時也不連接外部服務
- 只有符合條件的資訊才能改為已確認
- 用自動化測試驗證程式是否符合需求與流程規則
開放教案與交流
歡迎取用與改編這份教案，也歡迎交流實際使用的經驗
我認為，AI 已經改變寫程式的方式，軟體工程教育也必須重新思考教學方式。這次使用的教案、投影片與起始專案及成果索引都已公開，歡迎依學員的年齡、經驗與需求，以及課程時數和授課環境取用或改編。
若你實際使用、發現問題，或發展出新的做法，歡迎在 GitHub 提出問題，或寄信到 [email protected] 與我交流。
