網站連結：https://ai-shot-eight.vercel.app/index.html
昨天，我做完了一件以前我大概會先拖很久才開始的事。
我不是先把所有技術都學會，才開始做網站；而是在做網站的過程中，讓 Codex 成為我的技術搭檔。最後，我不只做出一個「AI 素養主題網站」，還一路把網站部署到 GitHub 和 Vercel，並且完成 GA4 的事件追蹤。
這篇文章想記錄我怎麼和 Codex 一路共創，從需求、內容、網站架構、部署到追蹤，把整個流程真的做完。對vibe coding初學者而言，這次經驗對你可能會很有參考價值。
一開始，我不是先想技術，而是先把任務講清楚
這次的起點其實很明確：我要做一個兼具教育意義與活動推廣功能的「AI 素養主題網站」。
它不是單純的形象頁，也不是純資訊整理頁。我希望它同時承接幾個目標：
- 推廣 AI 素養觀念
- 提供學生拍片與創作靈感
- 承接活動或競賽報名
- 讓網站內容能正式對外使用
我後來很明顯地感受到，這一步超級重要。因為和 Codex 協作時，要把目標、受眾、風格、內容範圍、輸出格式都盡量講清楚。
換句話說，這一步比較像企劃工作，不是工程工作。
第一版先做出來，再慢慢修，不要求一步到位
我一開始是直接請 Codex 生成 HTML 網頁，先把網站骨架做出來。這個做法後來證明很有效，因為只要有第一版，就能開始看到問題，也比較知道下一步要怎麼修。
整個節奏大概是這樣：
- 先提出網站目標與受眾
- 讓 Codex 協助整理頁面與內容結構
- 先產出第一版網站
- 根據回饋持續修正
- 把單頁逐步調整成正式可用的多頁網站
這裡有一個很重要的心得是：不要一開始就要求完美
如果一開始就想一次做到最好，反而會很難推進。先有一個可以看的版本，再明確指出哪裡不對、哪裡要補，Codex 的修正效率會非常高。
真正的共創，不是生成完就結束，而是不斷重構內容
網站做出第一版之後，接下來最花力氣的，反而是內容重構。
一開始的內容比較像企劃說明，對內部討論很有用，但如果是正式要給學生、老師或外部訪客看的網站，就很奇怪，因為有很多註明為什麼這麼設計的說明文字。
所以我後來一路調整了很多內容方向，像是：
- 拿掉不該直接出現在網站裡的企劃式說明
- 補上規則、簡章、FAQ、案例與 AI 素養說明
- 把網站從單頁式導覽，改成比較正式的多頁網站
- 把學生真正會遇到的情境補進來
例如我後來特別要求補強這些主題：
- 學生直接拿 AI 產出交作業的風險
- 假評論、假聲音、假圖像、假資訊等常見誤用情境
- 隱私、版權、校園霸凌、職場判斷與政府錯誤建議等可能後果
我也要求把中文案例放前面，並增加「適合拍成哪種類型短片」這種更貼近學生創作的欄位。這些調整很關鍵，因為它讓網站不只是「看起來完整」，而是真的更接近教學現場與學生使用情境。
AI 幫我做的不只是網站，還包括內容判斷的整理與轉譯
這次我覺得很有感的一件事，是我不需要先把所有頁面文案都自己寫好，才開始做網站。
我其實是邊想、邊補、邊修。只要我能說清楚「哪裡不對」、「想往哪裡調」、「應該補什麼」，Codex 就能很快幫我把這些想法轉成新的頁面結構與文字內容。
後來我還要求Codex先去研究我以前看過的OECD對AI素養的說明文件，追加了一個「什麼是 AI 素養」的說明頁。再手動搜尋幾個適合學生參考的網站一起整理進去，像是公共媒體與教育平台的相關文章。這一步很像是把原本分散的教學觀點，整理成一個對學生更友善的入口。
接上 GitHub 和 Vercel，才是從作品變成網站
接著就是要把網站上線。我沒用過Codex，但有使用Github和Vercel的經驗。因此，直接問Codex，跟據它的指示，一路做到 git init、設定 GitHub repo、整理部署流程，最後把網站放到 Vercel 上。
真的接上 GitHub 和 Vercel 之後，整個工作流才建立起來。之後只要網站有更新，Codex 可以協助整理、提交、推送，Vercel 就會自動部署。
當然，每一個案例都要點進去確認一下，Codex幫我收集的30個案例是不是真的存在。
最有感的一段，是把 GA4 也串進去
如果說網站上線是第一個跨越，那 GA4 應該是第二個。
一開始我只是問：「有辦法在這個網站植入 GA4 嗎？」接著提供 gtag 程式碼，Codex 就協助我把追蹤碼加進網站頁面裡。
但更有價值的不是「有裝碼」，而是後面我開始追蹤真正重要的行為。
像是我要求追蹤：
- 點擊「立即報名」
- 點擊「查看簡章」
- 外部案例連結
- AI 素養延伸閱讀
- scroll depth
這時候我才真正感受到，GA4 不是一段貼上的程式，而是網站開始變得可觀察、可分析。以前要做這些事情，我都要很麻煩的串GTM，現在完全是一句話就解決的是事，真的很神奇。
從此，我可以知道：
- 有多少人真的點了報名
- 有多少人會去看簡章
- 哪些案例最常被點開
- 哪些延伸閱讀有人看
- 使用者有沒有把內容看完
這次過程中，我也踩了幾個很典型的坑
回頭看，這次最值得分享的，不只是順利的地方，也包括幾個很典型的卡點。
1. 一開始內容太像企劃書
這是最早出現的問題。對內部來說合理，但對外網站不適合。後來把那些過於「設計過程導向」的說明拿掉後，整個網站才變得更正式。
2. 單頁網站不一定適合資訊量大的正式內容
單頁式設計在展示型網站很好用，但如果資訊變多、頁面功能變複雜，會開始出現導覽不清楚、維護不方便、閱讀節奏混亂的問題。後來改成多頁之後，穩定很多。
3. 只有基本追蹤碼不夠
真正重要的是事件命名與行為設計。你想知道什麼，就要先把追蹤設計好。這一步如果沒有想清楚，GA4 就只會停留在「看得到流量」，但看不到真正有價值的互動。
我最後怎麼理解 Codex 的角色
做完這一輪之後，我對 Codex 的理解有一個很大的改變。
它不是單點工具，也不只是寫程式的輔助器。
在這次經驗裡，它同時扮演了幾種角色：
- 幫我把模糊需求整理成可執行任務的協作對象
- 幫我把內容轉成網站結構的前端助手
- 幫我處理 GitHub 與 Vercel 流程的部署助手
- 幫我規劃 GA4 事件邏輯的追蹤顧問
它最適合的情境，是我知道我要做什麼時，它就會幫我完成技術細節。而且，我慢慢形成一種習慣。
我不必先學會所有技術才開始；而是在做網站的過程中，讓 Codex 幫我補上技術。
這句話很像這次經驗的總結。
以前我們常常會把「開始做」這件事往後延，因為總覺得還沒準備好、技術還不熟、工具還沒摸透。但這次我發現，如果有一個能夠陪你一路把流程做完的 AI 搭檔，你其實可以先開始，再在過程中把能力補上。
而且這裡最重要的，不是 AI 幫我生出了什麼，而是 AI 幫我把整個流程真的推進下去。
如果你也想試試看，這是我覺得最實用的三個建議
1. 先把任務講清楚
不要急著問工具怎麼用，先說清楚你要做什麼、給誰看、希望最後長什麼樣子。
2. 先做出第一版，再靠回饋修正，小步快跑，用不斷迭代來優化
不要追求一次到位。能看到畫面、能指出問題，比空想完整架構更有效。
3. 把 AI 當成流程搭檔，不只是內容生成器
如果只拿來生文案，很可惜。真正有價值的是讓它陪你一起走完需求、內容、技術、部署、追蹤這整條路。
結語
這次和 Codex 共創網站的過程，讓我看到一件事：AI 最有價值的地方，不是取代人，而是幫人跨過那些本來會讓專案停住的技術門檻。
我還是要負責方向、內容、判斷與發布，但我不需要再一個人卡在每一個細節裡。
如果要把這次經驗濃縮成一句話，我會這樣說：
不是 AI 幫我做了一個網站，而是我和 AI 一起，把一個想法做成了真的可以上線、可以追蹤、也可以持續優化的作品。
