林俊銘老師專題的程式設計，以HTML+CSS+JavaScript為主，使用Github平台。
如果進入到資料庫的功能，採用 Supabase 資料庫。
學習這些工具，可以設計出很多很有趣的東西。
以下步驟，可以初步學習github平台，以及基礎的Html+css+javascript，預計1小時
註冊 GitHub 網站，免費版即可。
寫一個簡單的網頁，例如只有簡單的幾個字Hello World。然後找出這個網頁的網址。(為了後面解說方便，這個網頁取名字為index.html)
AI prompt：我要註冊github並且撰寫第一個網頁index.html，網頁內有Hello World。請給我詳細的步驟，提醒我注意的事項，以及最後哪裡可以找到網址。
新增一個資料夾images，上傳一張照片jpg，並且顯示在index.html網頁上。
AI prompt：我要新增一個資料夾 images，並且上傳一張照片到這個資料夾，如何新增資料夾？如何確認上傳照片到這個資料夾？剛剛的index.html裡面若要顯示該照片？路徑要怎麼寫？網頁如果修改，要怎麼儲存？請給我詳細的步驟與注意事項。
使用CSS檔案，將Hello改成紅色。
AI prompt：新增一個css資料夾，也請幫我設計CSS格式，要讓Hello這幾個字變成紅色。這些CSS的設定必須要用外部的CSS檔案，也請給我index.html的修改內容。以上這些步驟要怎麼做？要注意甚麼？請給我詳細的步驟和注意事項。
使用JavaScript檔案。在index.html當中多一個按鈕，按下去之後，會顯示對話窗
AI prompt：新增一個 js 資料夾，並且產生一個JavaScript檔案，讓index.html可以連結。在index.html當中有一個按鈕，按下去之後會顯示"JS練習成功"的訊息。請給我以上要求的詳細步驟和注意事項。
Json通常是一種資料檔案，可以放置大量資料，例如產品資料
AI prompt：新增一個 json 資料夾，並且產生一個 json 檔案，裡面有5筆產品編號和名稱資料。在index.html當中要顯示這五筆編號和名稱。請給我以上要求的詳細步驟和注意事項。
AI prompt：我要練習一個RWD網頁。功能是可以比較10筆產品資料的網頁呈現方式。網頁上方使用傳統表格，用每列5筆資料的表格方式呈現產品，表格內部設定背景顏色以利於辨識。網頁下方則用RWD的功能，在寬螢幕的時候也是每列5筆資料，表格內部設定背景顏色以利於辨識，當螢幕變窄的時候(例如使用手機)，則會自動使用RWD的功能縮減每列格子數。網頁檔名為index.html，10筆產品資料須寫在json檔案當中，資料夾為 json，RWD的功能請寫在css獨立檔案當中，資料夾為css。請給我以上要求的所有檔案的完整案例。
以下步驟，可以初步學習 supabase 資料庫平台，有了資料庫，我們的 github 程式設計就變成超強了。預計1小時。
註冊 supabase 網站。
建立第一個Project(專案)，並且在裡面建立一個Database(資料庫)，資料庫裡面有一個Table(資料表)，資料表裡面有兩個Column(欄位)。
AI prompt：我要在supabase 裡面建立一個 Project1 的專案，在裡面有一個資料庫，資料庫裡面有一個 TblMember 名稱的資料表。裡面有 MemberID、MemberName 兩個欄位，分別是會員編號和會員姓名，其中MemberID是主索引。請給我詳細的操作步驟。
--------------------------------------------------------------------------------------
備註：每個免費帳號，只能有一個Organizations (組織) ，每一個免費帳號的 Organizations 裡面可以有 2 個projects (專案)。
Project是甚麼意思，有哪些功能？
一、Supabase 的「Project」是什麼？
在 Supabase 裡，一個 Project 就相當於一個獨立的後端環境，包含以下主要組件：
功能模組 說明 對應技術
🗄️ Database 一個完整的 PostgreSQL 資料庫 PostgreSQL
🔐 Authentication 登入、註冊、權限管理（Email、OAuth、Magic Link 等） Supabase Auth
🪣 Storage 上傳與管理圖片、影片、檔案 Supabase Storage
⚙️ API 自動生成的 REST API 與 GraphQL API PostgREST / GraphQL
🧠 Edge Functions 用 JavaScript 撰寫後端邏輯 Deno Edge Functions
📊 Dashboard 視覺化管理介面，可操作資料表、設定安全規則、查看日誌等 Supabase Studio
🧩 二、可以怎麼理解「一個 Project」
你可以把 Project 想像成：
💡「一個網站或 App 的後端伺服器。」
例如：
你想開發一個學生管理系統 → 建立一個 Project 叫 student-app
裡面有一個資料表 students
可以註冊帳號登入
可以上傳學生照片
可以用 JavaScript 從前端讀取資料
📦 三、Project 的結構
每個 Project 都包含：
一個獨立的 資料庫（Database）
一組 API 金鑰（Anon / Service Role）
一個 URL（如 https://xxxxx.supabase.co）
一個 管理介面（Supabase Studio）
這些都讓它成為一個完整、可獨立運作的後端服務。
你可以同時建立多個 Project （例如 學生系統、問卷系統、部落格系統），互不干擾。
💰 四、免費版的限制（2025年最新）
項目 限制
專案數量 最多 2 個
資料庫儲存 約 500 MB
檔案儲存 約 1 GB
API 請求數 每月約 50,000 次
無伺服器函數 (Edge Functions) 可以用，但限制執行時間與次數
在GitHub裡面建立一個網頁，可以讀取這個TblMember表格的所有會員名字，顯示出來。
AI prompt：我要建立一個Github的網頁，可以讀取我現在建立的supabase的資料庫。可以把剛剛的TblMember裡面的MemberName都顯示在網頁上。請給我網頁，以及所有的操作細節。
(這個過程相對比較複雜，可能需要耐心和AI溝通)
以下步驟，學習請AI給指令，產生Supabase的資料表，以及資料。另外，請AI產生網頁，可以讀取Supabase的資料表並且顯示。
請嘗試以下的prompt
我想要建立一個二手物交換的網站，最簡單的雛型就好。可以上傳物品，以及查詢物品。先不需要有管理介面。請給我supabase的資料表格的schema建議。
(在確認AI給的建議，以及適當的確認之後，可以給以下的prompt)請根據修正過的schema，幫我產生SQL指令。可以產生表格和欄位。
請幫我設計需要的html或Javascript，讓我可以放在Github，可以讀取剛剛的supabase裡面的二手物表格的資料，並且顯示在網頁上。
建議您用 P107-codex-test 當第一個測試 repo，而不是直接動正式 P107。
根據 OpenAI 官方文件，Codex Web 可以連接 GitHub，讓 Codex 在 repository 中工作，並可從工作成果建立 pull request；一般 ChatGPT 的 GitHub 連接則主要是讀取與分析 repo 內容，若要產生、編輯並推送程式碼，應使用 Codex。(OpenAI 開發者)
建議名稱：
P107-codex-test
設定：
Public 或 Private 都可以
先不要放正式版機密資料
不要放 Supabase service_role key
不要放真正的 config.js
只放 config.sample.js
如果您目前只有 ZIP，做法是：
在電腦解壓縮 P107 ZIP。
檢查裡面有沒有 config.js 或 Supabase key。
若有正式 key，先刪除或改成 config.sample.js。
上傳到 GitHub 的 P107-codex-test repo。
進入 Codex 後，找類似：
Connect GitHub
Repositories
New task
(2026/6/14測試，如果要使用Codex APP，則下載Windows版，如果想要用Web版本，是藏在https://chatgpt.com/codex/的右上角，Cloud裡面，有一個GitHub的超連結，進去之後有一連串的授權設定，需要輸入GitHub的密碼，以及需要手機認證)
然後授權 GitHub。
第一次授權時，建議選：
Only select repositories
然後只勾選：
P107-codex-test
不要一開始授權所有 repo。
您可以直接貼這段：
請先閱讀這個 repository，但不要修改任何檔案。
這是 P107 Campus Busy Screen，中文名稱是「校園營運忙碌螢幕」。它是一個展示型 dashboard，用假資料模擬智慧校園與智慧商情研究室的大螢幕。
請先完成三件事：
1. 說明這個專案的檔案結構。
2. 說明主要功能與每個主要檔案的角色。
3. 找出最適合作為第一次小幅測試修改的 3 個項目。
請不要建立 PR，不要修改檔案。
這一步的目的，是確認 Codex 真的能讀 repo，而且能理解 P107。
等它完成分析後，再貼：
我想做第一個低風險測試：讓 dashboard 裡的數值變動更自然，不要突然大幅跳動。
請先不要修改檔案。請先提出修改計畫：
1. 可能需要修改哪些檔案？
2. 目前數值跳動的原因可能在哪裡？
3. 你會如何讓人流、車位、空氣品質等數值以較平滑、較合理的方式變動？
4. 這次修改的風險是什麼？
如果它的計畫合理，再貼：
請依照剛剛的計畫進行小幅修改。
限制：
1. 只修改必要的 JavaScript 檔案。
2. 不要改 HTML 結構。
3. 不要改整體視覺風格。
4. 不要新增外部套件。
5. 完成後請建立 pull request。
6. PR 說明請用繁體中文，列出修改內容、測試方式與可能風險。
不要追求它一次做出很大功能。第一次只確認四件事：
Codex 能不能讀到 P107-codex-test。
Codex 能不能理解檔案結構。
Codex 能不能只做小幅修改。
Codex 能不能建立 PR，讓您審查後再合併。
如果這四件事成功，您就已經完成最重要的入門測試。
先不要讓 Codex：
全面重構 P107
加入 Supabase
改成正式後台
重新設計整個版面
直接修改 main branch
處理所有 P 系列專案
第一天只要測試一個很小的變更就好。
您現在可以先建立 P107-codex-test repo，然後用上面「第一個指令」測試。
老師，這個判斷完全合理，而且您抓到一個關鍵：
對您而言，「開發效率」不是唯一目標，專案脈絡是否完整、日後是否能查詢、是否能教學回顧，反而更重要。
所以我會修正前面的建議：
以您目前的工作方式來看：
ChatGPT 專案討論 → 產生 ZIP → 您手動更新 GitHub main
這個流程雖然比較「人工」，但有幾個很大的優點：
第一，所有需求討論都留在 ChatGPT 專案裡。
您之後要查「為什麼 P107 這樣設計」、「P104 V2 為什麼不用手機導覽端 Web Speech API」、「P109 為什麼不錄音」，都可以回到同一個討論串。
第二，比較符合您的教學與研究管理習慣。
您的專案常常不是單純改程式，而是包含命名、管理意涵、教學說明、三摺頁、海報、研究敘事、學生分工。這些不是 Codex 的核心優勢。
第三，您可以掌握最後版本。
由 ChatGPT 產生 ZIP，您下載、測試、再手動上傳 GitHub main。雖然多幾步，但可控性高。
第四，對小型專案來說，成本不一定比較高。
P101、P104、P107、P109 這種 HTML/CSS/JS 小型展示系統，直接產生新版 ZIP 其實很有效率。Codex 的 PR 流程反而可能增加管理負擔。
所以您的感覺是對的：
如果 Codex 會造成脈絡分裂，那它未必比 ChatGPT ZIP 工作流更好。
不要把 Codex 當成「取代 ChatGPT 的主工作區」。
把它當成「特殊用途工具」。
也就是：
ChatGPT：主工作區
Codex：必要時才使用的程式維修工具
GitHub：正式發布與版本保存
Google Drive：素材與 ZIP 備份
我建議只有在以下情況才用 Codex：
例如 P101 已經有很多頁面、很多資料表、很多 JS 邏輯。
這時若只想修一個小 bug，用 Codex 直接針對 repo 改一兩個檔案，比整包 ZIP 重做更安全。
例如：
「只修 app.js 裡的計數器問題」
「只修手機版 CSS」
「只修 Supabase 查詢錯誤」
「只補 README 裡的安裝說明」
這類任務適合 Codex。
如果教學目標是讓學生理解：
branch
commit
pull request
code review
merge
那 Codex 很適合當示範工具。
如果某個系統未來真的要變成正式網站、正式展示、正式後台，例如 P101 或 P104 V3，那才值得導入 Codex + PR。
您的大多數情境其實可以繼續用原本方式：
例如 P110 新想法。
直接在 ChatGPT 討論完整概念，然後產生 ZIP，比較快。
例如：
「改成日式文青風」
「改成美式智庫風」
「做成 A3 海報感」
「dashboard 要更像電影駭客畫面」
這種整體美術與敘事設計，在 ChatGPT 裡討論比較自然。
這些一定留在 ChatGPT 比較好。
這一點最重要。
只要「脈絡完整性」比「自動建立 PR」更重要，就應該留在 ChatGPT。
ChatGPT 專案討論
→ 產生新版 ZIP
→ 老師下載測試
→ 手動更新 GitHub main
→ 在 ChatGPT 記錄版本摘要
這是您的主流程。
GitHub repo 已經穩定
→ 有局部 bug 或小功能
→ Codex 讀 repo
→ 建立 PR
→ 老師審查
→ merge
→ 把 PR 摘要貼回 ChatGPT 專案
這是輔助流程，不是主流程。
您可以很清楚地跟學生說：
我們有兩種 AI 協作開發方式。
第一種是 ChatGPT 原型開發：適合從零開始設計小型網站，產生完整 ZIP。
第二種是 Codex repo 維護：適合在 GitHub 上修改既有專案、修 bug、建立 PR。
本課程初期以 ChatGPT 原型開發為主，進階學生再練習 Codex 與 GitHub PR。
這樣非常合理，也不會讓學生一開始被 GitHub/Codex 流程嚇到。
老師，您現在不需要急著把工作流搬到 Codex。
更精確地說：
ChatGPT 仍然是您的主要專案工作室。
Codex 是將來針對 GitHub repo 做局部維修、PR 示範、進階維護時才使用的工具。
所以您原本的 ZIP 流程不但沒有落伍，反而很符合您的教學型、小型原型開發需求。
我會建議您現在這樣決定：
短期：繼續 ChatGPT 產生 ZIP。
中期：P107-codex-test 只當實驗，不作主流程。
長期：只有 P101、P104 這類會持續維護的正式專案，才逐步導入 Codex。