這篇要記錄的，不是「AI 怎麼幫我做出一個網站」，而是我怎麼跟 AI 溝通、下指令、糾正它、確認細節，一路把一份陽春清單變成一個真的上線給人用的活動周邊指南網站，也就是Taiwan Salsa Carnival 周邊指南。做網站這件事本身，AI 早就做得到；真正決定成品好不好用的，是溝通的方式。
起因很簡單、也很真實。合作方丟了一份 Google 文件過來，標題是「北流周邊 Guide book」，內容是一堆條列的地點和連結：伴手禮、住宿、交通⋯⋯格式很陽春，就是一份團隊內部整理的清單。我當下反問了三個問題：
這個要做什麼用？做成傳單？網頁？
對方回了一句：
一個連結可以給外國人看。
這個網站真正的起點，就是這段對話。
這三句反問，其實就是我後續跟 AI 溝通的起手式：先搞清楚「這東西要幹嘛用」，再決定怎麼做，而不是拿到一份清單就急著動手生成。
確定要做成網頁之後，我選擇直接用 Claude Code 來做，理由很單純：這是一個純靜態網頁的需求，沒有帳號系統、沒有資料庫、不需要複雜的後端邏輯，內容就是幾個分類的地點卡片。這種規模的網站，對 Claude Code 來說幾乎是最快的路徑，不用找工程師排時間、不用自己學怎麼寫網頁，我只要把內容和目標講清楚，很快就能看到能動的成品，改東西也是當下講當下改。如果是複雜到需要會員系統、金流、後端資料庫的專案，我可能會考慮別的做法，但像這種一頁式的資訊整理網站，直接讓 AI 處理是最省時間的選擇。
實際上線的成品，直接點進去看：https://tsc-2026-guide-book.zeabur.app 因為終究是要傳連結給外國參加者在手機上看，我從一開始下指令就特別強調「手機瀏覽」這個使用情境，不是等桌機版做完才回頭補響應式。
我只講「要什麼」，不講「怎麼做」
第一句指令，我給的是那份 Google 文件加上一句話：場館周邊有哪些住宿、交通、吃的、景點，希望做成一個連結、方便手機瀏覽、給外國人看。我沒有講要用什麼技術、要不要做成伺服器、檔案怎麼分。這是我跟 AI 溝通時刻意維持的分工：我負責講清楚「這東西是給誰用、要達成什麼效果」，技術上怎麼選、怎麼搭，交給 AI 自己評估。
後來網站從純靜態 HTML 檔案改成用 Node.js + Express 起一個小伺服器來跑，這個決定我完全沒有介入，我甚至到後來整理這篇文章的素材時才注意到有這回事。對我來說這正是好用的分工方式：我不需要懂什麼是 Express、什麼時候該用伺服器而不是純靜態檔案，只要我把「要什麼」講清楚，技術細節不用我操心。
內容不夠，我請 AI 自己去找更多地點
那份 Google 文件裡的清單其實不夠完整，只有零星幾類。商圈購物、鄰近景點、手搖飲、特色店這幾個後來補上去的分類，裡面實際的店家和地點都是我請 AI 自己去找的，不是我一個一個列出來給它。我只要講清楚類別和範圍，例如場館附近還有哪些值得去的景點、哪些手搖飲店，AI 就會自己去搜尋、篩選出候選名單，我再從裡面確認要留哪些、砍掉不合適的。找地點這件事跟找照片剛好相反：找照片我不放心讓 AI 自己上網找，但找「這附近有哪些店家」這種資訊性的搜尋，我反而放心交給它自己去查，畢竟這類資訊比較不涉及版權風險，錯了也容易在後續驗收階段抓出來。
「特色店」這個分類就是這樣補上的，不在北流步行範圍內，但值得專程安排一趟的台灣特色體驗。
不放心的地方我親自看，其他交給 AI 自己確認
雖然不管技術細節，但每次改版要放行進到下一步之前，一定要有人確認過版面沒跑掉、圖片載得對不對、手機版排版順不順，不會改完程式碼就直接部署上線去賭。這個「確認」不是每次都得我自己盯著螢幕看，很多時候我會直接請 AI 自己在本機打開頁面檢查一輪，我只在比較關鍵的改動、或是不太放心的地方才會親自過目。
視覺、排版這種東西光靠我自己一個人的審美判斷，容易看習慣了就忽略掉問題。我下的指令很簡單：「找一個 agent 用設計師的角度看一下目前的設計。」不是要它照我的想法逐項檢查，而是換一個角色、換一個審美標準重新看一輪整體版面，配色、間距、卡片排版這些細節是不是舒服、一致，而不是只有我自己覺得「看起來還行」。這也是我在溝通上的一個習慣：同一件事，換一個身分或角度重新看一遍，會比我一個人從頭看到尾更容易抓到盲點。
地點、地址這種需要判斷的事，我要求它先問、不要自己腦補
網站裡每個地點都要附 Google 地圖連結，中間有幾次 AI 抓到查詢結果模糊、可能對不到正確地點的情況。我明確要求的做法是：遇到不確定的地點，先把候選選項列出來問我，不要自己猜一個答案就寫進網站。實際發生過的例子：
- 「四獸山步道」查出來的地圖連結是模糊搜尋結果，AI 把象山、拇指山這幾個候選丟回來問我，我確認要收斂成「象山」這個大家熟悉、也真的好找的地標，才拍板寫進去；「老張炭烤燒餅店」、「靜心苑」這類有多間分店或多種稱呼的地名，也是同樣先問我要哪一間，我確認後才定案。
- 地址要放在卡片的哪個位置、要不要加一行提醒文字，我來回要求調整了好幾次擺放方式，最後拍板成「每個區塊只出現一次，放在區塊介紹文字後面」，不是每張卡片都放、也不是整頁只放一次。
- 做英日韓版本時，AI 一開始把地址也順手翻譯成當地語言。我把這個決定推翻了：地址一律要維持原始中文，不能翻譯或音譯。理由很直接：外國旅客到了現場，要攔小黃、問路人、或是把地址拿給不會英文的司機看，一串翻譯過的英文地址完全沒用，唯一有用的是那串原始中文門牌。這條規則我後來要求固定下來，之後每次改地址都要確認中文地址沒被誤翻。
- 後來我自己找到兩個更準確的 Google 地圖短連結（象山登山口、CITYLINK Nangang 分店），直接丟給 AI 取代原本用查詢字串猜的連結。我發現，只要我肯花時間找到真正對的來源丟給它，永遠比讓它自己用地名去猜的搜尋連結準。
這幾件事的共通點是：我把「這是不是使用者想要的那一個」這種需要判斷、不是純技術問題的決定權握在自己手上，AI 的角色是把選項列清楚、把我拍板的規則貫徹到底，而不是自己一次到位地替我做決定。
找圖：先試了別的工具，發現不行，再換方式
每張地點卡片都需要一張照片，這部分我一開始沒有讓 Claude Code 自己處理，而是另外找 ChatGPT 上網搜圖，因為在「上網找東西」這件事上，ChatGPT 那邊的彈性比較好，我想說分工讓比較擅長的工具去做。結果做出來的成果並不理想，圖片跟地點對不上、品質也不夠好，這條路我後來放棄了。
最後改成我自己動手：親自到 Google 地圖或店家的 Facebook 粉專找到正確的照片網址，直接貼給 Claude，請它把網站上對應的圖換掉。這中間也不是貼了連結就結束，有幾次直接下載會失敗（伺服器擋掉沒有瀏覽器標頭的請求），我要求它改用模擬瀏覽器的方式重新抓；抓到的圖如果是 WebP 格式，我也要求統一轉成 JPG，並且每張圖處理完都要我自己打開來看過一次確認顯示正常，才算放行、寫進頁面。這條路走下來的心得是：不是每件事都要硬塞給同一個 AI 工具做，「找圖」這種需要辨識現場實景是不是真的對應到那個地點的事，交給我自己動手找來源，反而比讓任何一個 AI 自己上網亂找更可靠。
過程中稽核也發現有幾張照片品質不夠好、需要換掉，我特別交代一條規則：不能直接把「這張圖有問題」的提示疊印烙在圖片檔案本身上，要用一層額外的網頁標記蓋在上面提醒待處理，圖片檔案原始的樣子要維持乾淨。
四種語言，我是中文版定稿之後才請它翻
網站要做中/英/日/韓四個版本，我的順序是先把中文版內容全部確認、定稿，才請 AI 翻成英日韓三個語言，而不是中文邊寫邊同步翻譯。翻譯這件事我要求不要一個一個排隊做，而是同時開三個獨立的 agent 分別負責英日韓、平行處理，這樣才不會等到天荒地老。這件事我是直接跟主線的 Claude 講需求，實際上怎麼拆給多個 agent、怎麼協調它們，是 Claude 自己去安排、我沒有一個一個親自對每個翻譯 agent 下指令。
就算中文版是先定稿才拿去翻譯，之後我還是會不斷回頭調整中文版內容，例如某個小標題文案、頁尾文字臨時改一下，一旦中文版再被我改動，先前翻好的三個語言版本就會跟最新中文版對不上。這件事我沒有一次講死一條規則，而是每次中文版有更動、我在跟進度時發現其他語言版本沒跟上，就會當下要求重新對齊，Claude 也會主動注意到這個落差，之後同樣情況再發生時會自己處理，不用我每次都重新提醒。
這種「我只定規則、細節交給 AI 自己處理」的做法，比我自己一份一份對照著手動翻譯四種語言省下很多時間，我要花心思的，是把「不能翻到舊版本」這種容易被忽略的坑先講清楚，而不是自己去盯每個 agent 在做什麼。
重複交代過的事，我要求它寫下來，之後不用再講一次
有些規則我不想每次都重講一遍，例如「部署要用 git push 觸發，不要另外跑 CLI 部署指令」「地址一律保留原始中文」這類。我的做法是要求 AI 把這些規則寫進專案的設定文件裡，變成之後每次對話都會自動套用的常駐指令，而不是全部靠我當下的記憶去複述。這樣做的好處很實際：專案拖了一段時間、來回改了很多輪之後，我不需要記得「上次是不是講過這件事」，只要規則已經寫進去，AI 就會自己照著做，我只需要在它做錯的時候糾正一次，之後就不用再糾正第二次。
驗收：地圖連結真的打開過一次，不是憑感覺
網站好看能動之後，我要求的下一件事不是內容，而是驗收。每個地點都附了 Google 地圖連結，但我知道地圖搜尋連結有個問題：同一個查詢字串，有時候會準確跳到單一地點，有時候卻會跳出一整排搜尋結果列表。我不滿足於「連結看起來有放對地名就好」，我提的要求很單純：把每一個地圖連結都檢查過一次，確認點進去是單一的地點資訊，不是一整排搜尋結果列表。至於怎麼檢查，後來是 AI 自己決定寫一支腳本，把全站的地圖連結真的都打開一次，用頁面上的文字特徵去判斷是不是精準跳到單一地點。
這一輪檢查抓出了 6 個容易解析成模糊列表的連結，大部分是 AI 自己動手改成更精確的店名加門牌號碼、或換成 Google 地圖短連結；只有前面提到那幾個真的需要判斷是哪一間店、哪個地標的案例，才回頭問我確認。我同時也要求順便做另外兩件事：
- 把全部地點頁面的文字都掃過一次，檢查有沒有「永久停業」或「暫停營業」，真的抓到一間已經歇業的店，我要求直接把卡片從四個語言版本移除；
- 逐張卡片檢查有沒有漏填地址，補齊了 9 張缺地址的卡片，也順手抓到兩間飯店的地圖連結被彼此對調的烏龍，我要求一併修正。
我很清楚 AI 寫網頁很快，但「內容是不是正確、連結是不是真的可用、店家是不是還開著」這種需要實際驗證的細節，如果我不主動要求系統性的檢查流程，它不會自己想到要做，生成完看起來對，不代表真的對。
部署：我定的規則，它照著做
網站程式碼是獨立的 git repo，接到 GitHub，我要求把 Zeabur 設定成 GitHub 自動部署。明確講清楚我要的流程之後，這條規則也寫進了常駐設定裡：本機確認沒問題後，commit、push 到 GitHub 的 main branch 就好，不要再額外跑一次 CLI 部署指令。push 之後 Zeabur 會自動觸發建置與部署，我會再要求檢查一次部署狀態、確認服務正常啟動，才算真正完成一次更新。
先講清楚「做完」是什麼樣子，AI 才知道要做到多細
只講「要什麼」不代表什麼都不用講清楚。跟 AI 溝通我覺得最容易被忽略、但其實很關鍵的一件事，是先把「definition of done」講清楚：這件事完成的標準是什麼、要做到什麼程度才算真的做完，而不是丟出一個任務就等它回報「做好了」。如果我沒講清楚驗收標準，AI 很容易用它自己的標準判斷「做完了」，可是那個標準不一定是我要的，結果就是我拿到一個看起來完成、實際上還有一堆細節沒到位的東西，然後又得回頭一輪一輪挑毛病。所以我養成的習慣是，交代任務的同時，盡量把「怎樣算做完」一起講清楚，而不是等做完了才發現標準對不上，前面提到的地圖連結驗收、內容補齊，其實都是這個習慣的具體案例。
這套溝通方式，你自己也做得到
整理起來，我跟 AI 之間其實是一套很具體的溝通習慣：先問清楚目的、只講結果不管技術細節、把「怎樣算做完」講清楚、關鍵或不放心的地方親自確認、遇到需要判斷的地方要求它先問不要自己猜、把重複的規則寫下來變成常駐指令、驗收要有憑有據不能只憑感覺。這些不是什麼技術門檻，是任何人都可以練習的溝通方式。
如果你也想自己動手做類似的網站，這套溝通方式直接照搬就可以用。如果你沒空練習、或想要有人直接幫你把整個過程跑完、產出一個能上線的成品，歡迎透過「合作洽詢」找我聊聊；如果你想學的是這套怎麼跟 AI 溝通的方法本身，而不是要一個現成的網站，一樣歡迎找我聊聊。
附註：這個網站的製作成本
講了這麼多溝通細節，順便附上實際花費，讓有興趣自己動手的人心裡有個底。很多人看到「用 AI 做網站」會直接聯想到很貴的開發費用，實際上這個專案的花費很單純，抓個大概：
這個網站真正黏在電腦前做的時間，粗抓大概是兩次工作段落，加起來抓個十幾個小時：一次是最初建置＋隔天重新命名，一次是後來的稽核修正，都是晚上到凌晨這種時段斷斷續續做完的。中間也穿插了不少 AI 自己在處理的時間，像是跑腳本驗證地圖連結、批次處理圖片這種事，丟給它跑，我不用一直盯著螢幕看。
開發階段（一次性，做完就不用再付）
| 項目 | 費用 |
|---|---|
| Claude Code（AI 助手） | 最低 US$20／月（Claude Pro） |
| 素材整理（合作方提供的 Google 文件、圖片） | 無額外花費 |
上線後持續運作（每個月）
| 服務 | 費用 |
|---|---|
| 主機（自租 Tencent 伺服器，跟另外 2 個專案共用分攤） | 整台約 US$3-4／月，這個網站只是其中一部分 |
| Zeabur（部署平台訂閱） | 目前是 Free 方案，$0 |
| GitHub（程式碼版本控管、觸發自動部署） | 免費 |
| Google 文件 / Sheets（內容協作） | 免費 |
粗抓下來，開發階段大概花一個月的 Claude Pro 訂閱（US$20，約新台幣 650 元）。網站做好上線之後，Zeabur 平台本身現在是免費方案，真正持續要付的是自己租的那台主機，每月大概 US$3-4，而且是跟另外兩個專案一起分攤，不是這個網站獨自扛下來的費用。