所有專案共用
專案工具包：把一個專案從提案帶到完成
六步建站法告訴你「怎麼做出網站」；這套工具包告訴你「怎麼把專案做完」。每個專案都用同一套六份文件，期末專題也是。
| 文件 | 什麼時候寫 | 花多久 | 回答的問題 |
|---|---|---|---|
| ① 提案書 | 專案開始前 | 30 分鐘 | 為什麼值得做？做到什麼程度算完成？ |
| ② 時程與里程碑 | 提案通過後 | 15 分鐘 | 每週要完成什麼？ |
| ③ 每週進度紀錄 | 每次上課最後 10 分鐘 | 10 分鐘 | 做了什麼、卡在哪、下週做什麼？ |
| ④ 測試紀錄 | 每完成一條功能 | 隨時 | 怎麼證明它是對的？ |
| ⑤ Demo 發表 | 專案最後一週 | 3 分鐘發表 | 別人看得懂、用得到嗎？ |
| ⑥ 專案回顧 | 發表之後 | 15 分鐘 | 下次怎麼做得更好？ |
Word 版範本在課程資源的「專案工具包」資料夾，可以列印或上傳到 Google Classroom。
① 提案書
提案書只有一頁。重點不是寫得多，而是逼自己在動手前想清楚。提案書的前三格，正好就是 PROJECT.md 的前三段。
| 欄位 | 寫什麼 | 吃貨評分站的範例 |
|---|---|---|
| 專案名稱 | 一句話就懂的名字 | 台南吃貨評分站 |
| 要解決的問題 | 誰遇到什麼困擾、現在怎麼處理 | 同學找午餐只能看網路評論，常有業配 |
| 使用者 | 具體到一種人 | 學校附近找午餐的學生 |
| 三個核心功能 | 第一版只做這三個 | 看排行榜、打分數寫短評、依類別篩選 |
| 不做的事 | 明確寫下本次不做什麼 | 不做登入、不做照片上傳、不做地圖 |
| 資料從哪來 | 是否涉及個資 | 使用者自己輸入，只存暱稱，不存個資 |
| 完成的定義 | 可以檢查的條件 | 三個功能可用、測試全過、有公開網址 |
「不做的事」是最常被跳過、也最重要的一格。學生的專案失敗，大多是因為範圍一直膨脹。提案時就寫下不做什麼，之後想加功能時，要先回來修改提案。
② 時程與里程碑
把六步建站法排進可用的週數。每個里程碑都要有一個看得到的產出，而不是「繼續開發」。
| 里程碑 | 對應步驟 | 產出（可檢查） | 預計完成 | 實際完成 |
|---|---|---|---|---|
| M1 規劃完成 | ①②③ | PROJECT.md 前三段、草圖、建表 SQL 可執行 | 第 1 週 | |
| M2 第一條功能 | ④ | 最重要的功能可以在瀏覽器操作 | 第 1 週 | |
| M3 所有功能 | ④ | 三個核心功能都完成並存檔 | 第 2 週 | |
| M4 驗收通過 | ⑤ | 自動測試全過、一位同學試用 | 第 2 週 | |
| M5 上線 | ⑥ | 公開網址、Demo 發表 | 第 3 週 |
落後時怎麼辦：不要延後上線，而是刪減功能。回到提案書，把一個核心功能移到「不做的事」，並寫下原因。
③ 每週進度紀錄
每次上課最後 10 分鐘寫。也可以直接請 AI 幫你整理：
提示詞 Antigravity
請讀 PROJECT.md 與這個專案的 git log，幫我草擬本週進度紀錄，包含：本週完成的功能、對應的存檔點、PROJECT.md 中還沒打勾的項目。 「遇到的問題」與「AI 犯的錯」這兩格請留白，我自己寫。
| 欄位 | 範例（吃貨站第 4 週） |
|---|---|
| 本週完成 | 專案骨架、首頁排行榜、店家頁（2 個存檔點） |
| AI 犯的錯 | 排行榜用了 JOIN，模組肉燥飯消失；同分時依店名排序，沒有依評論數 |
| 我怎麼發現的 | 對答案時只有 11 間店；前兩名順序和標準答案相反 |
| 卡住的地方 | PowerShell 無法啟動虛擬環境，用 Set-ExecutionPolicy 解決 |
| 下週要做 | 新增評論、新增店家、自動測試 |
| 進度狀態 | ☑ 照計畫 ☐ 落後（原因： ） |
「AI 犯的錯」與「我怎麼發現的」是評量 AI 協作能力最直接的證據，也是專案評分中「AI 協作紀錄」的主要依據。
④ 測試紀錄
自動測試證明「程式照規格運作」；測試紀錄則補上自動測試測不到的部分：真人操作、手機畫面、使用者的反應。
| # | 測試項目 | 方式 | 預期結果 | 實際結果 | 通過 |
|---|---|---|---|---|---|
| 1 | 評分 6 分 | 自動測試 | 400、顯示錯誤、不寫入 | 同預期 | ☑ |
| 2 | 手機上送出評論 | 手動 | 表單不跑版、可以送出 | 下拉選單太小 | ☐ |
| 3 | 同學第一次使用 | 使用者測試 | 30 秒內找到想吃的類別 | 沒注意到篩選連結 | ☐ |
使用者測試的做法
- 找一位沒看過你專案的同學，只給他一個任務，例如「找出評價最好的麵店，替它寫一則評論」。
- 在旁邊觀察，不要提示。記下他停頓、皺眉、問問題的地方。
- 每一個卡住的地方，都是下一版要改的項目。
⑤ Demo 發表（3 分鐘）
| 0:00–0:30 | 問題：誰遇到什麼困擾？用一個具體的情境開場。 |
| 0:30–2:00 | 現場操作：用公開網址，依使用者故事的順序實際操作，不要講程式碼。 |
| 2:00–2:30 | AI 協作：一個你抓到的 AI 錯誤，以及你怎麼發現的。 |
| 2:30–3:00 | 下一步：使用者測試發現了什麼、下一版要改什麼。 |
| 評分項目 | 看什麼 | 配分 |
|---|---|---|
| 問題清楚 | 聽完開場就知道為誰、解決什麼 | 20 |
| 功能完整 | 核心功能現場操作成功 | 30 |
| 品質 | 測試全過、錯誤輸入有處理、手機可用 | 20 |
| AI 協作 | 能具體說出 AI 的錯誤與發現方法 | 20 |
| 時間控制 | 3 分鐘內完成 | 10 |
發表前一天用手機打開公開網址完整操作一次。也確認線上資料庫（Neon）裡有示範資料，並準備一份畫面截圖，萬一現場網路不穩可以備用。
⑥ 專案回顧
回顧不是寫心得，而是找出下次可以直接用的改進。每一格都要具體。
| 問題 | 好的回答範例 |
|---|---|
| 哪一步做得最好？為什麼？ | ③ 設計資料：先用 SQL 試過 JOIN，第 ④ 步幾乎沒有改資料表 |
| AI 的錯誤中，哪一個差點沒發現？ | 排行榜同分的排序。畫面看起來很正常，是對答案時才發現 |
| 哪一段提示詞最有效？ | 「不要為了讓測試通過而修改 app.py；有測試失敗先告訴我原因」 |
| 下一個專案的 PROJECT.md 要多寫什麼？ | 在驗收標準寫清楚同分時的排序規則與每個欄位的長度上限 |
| 時程準確嗎？落後在哪裡？ | M3 晚了 3 天，新增評論的錯誤處理比預期花時間 |
回顧的最後一題「下一個專案要多寫什麼」，請學生直接寫進下一個專案的 PROJECT.md 模板。這樣經驗才會真的累積，而不是停在紙上。