網站昨天能用，今天為什麼壞了？Vibe Coding 除錯不是猜答案

昨天網站還好好的，今天一打開，瀏覽器突然跳出安全警告，說伺服器無法證明自己屬於這個網域，甚至還出現電信業者的上網守衛頁面，換成行動網路測試，安全警告消失了，卻變成 404。這種時候對不熟悉系統的人來說根本惡夢！腦袋裡大概只會剩下一句話：我昨天明明沒有再動它啊！

你可能沒有改頁面、沒有換文案、沒有新增按鈕，也沒有碰資料庫，但只要做過重新部署、更新設定、搬動檔案、重建容器，甚至只是讓 AI 幫你順手整理一下，網站底下那一整套看不見的東西就可能已經被改動了！

更麻煩的是，你以為自己只有一套系統，實際上卻同時有好幾套機制在碰同一批檔案，iCloud 在同步，Git 在記錄版本，GitHub 在接收你推上去的狀態，部署平台在讀取 GitHub，伺服器上的容器又在使用另一份設定。AI 則在這些系統中間修改檔案、執行指令、重新部署，然後很有禮貌地告訴你已完成。

這也是我最近愈來愈確定的一件事，Vibe Coding 最容易讓人誤判的地方，不是 AI 會不會寫錯程式，而是它很容易讓你以為只要畫面做出來、部署顯示成功，事情就結束了，但真正的問題往往就是從你以為結束的那一刻才開始。

網站不是一個頁面，而是一整條鏈

很多人第一次做網站時，會把網站想成一個完成品，就像做完一份簡報，存檔、上傳，網址可以打開，事情就算完成，但網站不是一個檔案，它比較像一條鏈。

使用者輸入網址之後，先經過 DNS，接著找到伺服器，再進行 HTTPS 憑證驗證，然後由反向代理把請求送到應用程式。

應用程式可能再連接資料庫、物件儲存、第三方登入、寄信服務，最後才把畫面送回來。

這條鏈裡，每一段都可能正常，也可能出錯，所以同一個問題，才會出現看起來完全不一樣的症狀。

用公司網路打開顯示安全警告；換成 5G，卻變成 404；直接測試主網址可能正常，但加上 www 或某個子網址就失敗；主程式其實活著，資料庫也沒有掛，只是入口的憑證處理出了問題。

對使用者來說，這些都叫「網站不能用」，但對系統來說，它們根本不是同一個問題，這也是為什麼，看到錯誤畫面時最危險的反應就是立刻猜答案。

有人看到 404，就說一定是網址沒有綁定；看到安全警告，就說一定是憑證過期；看到網站昨天正常今天失效，就說一定是 DNS 傳播；只要用了某個資料庫服務，就開始懷疑資料庫連線。

這些都可能發生，但「可能」跟「就是」差很多啊！Debug 如果從你最熟悉的答案開始通常很花時間，所以應該要從證據開始 Debug。

最麻煩的不是改錯，而是看起來都改好了

這次最有意思的地方，是設定檔確實被修改了，驗證指令也顯示設定有效，重新載入時甚至出現了成功訊息，從畫面上看幾乎每一步都像是對的，設定格式正確，憑證檔案存在，憑證也還在有效期限內，後端服務正常，資料庫正常，甚至重新載入也會成功。

如果只看到這裡，大概會開始懷疑瀏覽器快取、電信業者攔截，或某種說不清楚的玄學問題需要夜用靠得住來幫挺！

我剛才甚至還打電話去 Hinet 花了二十幾分鐘解釋，因為第一個證據看起來很像是 Hinet 誤判了網域風險。結果後來發現問題根本不在 Hinet 那邊。

我對不起剛才那位 Hinet 工程師。真的！

最後找到的原因其實很刁鑽，設定中加入了需要特殊 DNS 驗證方式的萬用字元憑證，但目前環境並沒有配置相應的 DNS provider，因此 TLS 握手失敗。更麻煩的是單純執行重新載入，並沒有讓正在運作的容器真正換成我以為它正在使用的那份設定。

系統告訴你「成功」只能代表某個動作成功，不代表你的目標已經達成。Build succeeded 不等於網站正常，Deploy completed 不等於所有入口都能開，Valid configuration 不等於線上服務正在使用這份設定，Certificate exists 也不等於 TLS 握手一定會成功。

AI 很擅長產生這種「局部成功」，它可以把每一個步驟都完成，甚至每一步都有綠色勾勾，但你真正要的結果還是沒有出現。

除錯的過程中，我又發現了另一個風險

這次最後確認的問題並不是 iCloud 直接把網站弄壞，但我在追查檔案與設定差異的過程中突然意識到另一件原本沒有特別注意的事！我的開發專案，原本放在會經過 iCloud 同步的位置。

使用 Mac 的人很容易這樣做，因為平常照片、簡報、教材、文件都放在桌面或文件資料夾裡，換一台電腦也能看到，真的很方便！

但 iCloud 本質上是同步系統，不是版本控制也不是獨立備份。同步的邏輯是讓每一台裝置盡量保持一致，所以新增會同步，修改會同步，刪除也會同步。當空間不足時，系統還可能移除部分本機下載，只留下雲端佔位狀態。

檔案顯示雲朵、處於「需要下載」的狀態，不等於檔案已經被刪除。當工具真的需要讀取檔案內容時，macOS 通常會嘗試下載。

所以 iCloud 把本機檔案移除，Git 就一定會把它當成刪除？這樣不精確。

真正需要擔心的，是另一種狀況：檔案真的被其他裝置同步刪除、同步發生衝突、內容無法正常下載，或是工作目錄正在變動時，又有開發工具、套件管理器、Git、建置系統與 AI Agent 同時讀寫它。

一個程式專案裡，可能有幾千甚至幾萬個小檔案。這些檔案不是靜靜躺在那裡而已，而是一直被掃描、比對、修改、產生、刪除。

這時候又多一套雲端同步機制介入，就多了一個平常不一定看得見的變數，這不一定會造成事故，但如果真的出現同步刪除、同步衝突、下載失敗，或工作目錄在不穩定的狀態下又被提交，那就有可能把不該進 Git 的變化一起送上去。

GitHub 不會替你判斷這是不是正確版本

我以前也很容易有一種感覺：沒關係，我有放 GitHub，很安全！但這次我重新想了一下，這句話只對一半，GitHub 保存的是你已經 commit 的內容，不 一定是你心裡認為正確的內容。

如果你把完整版本推上去，它可以幫你保留完整版本；如果你把缺檔版本推上去，它也會幫你保留缺檔版本；如果你在一次 commit 裡誤刪了幾百個檔案，GitHub 會很誠實地記錄：這一次，你刪了幾百個檔案。

Git 確實可以還原舊版本，但前提是你知道問題發生在哪個 commit，也知道該怎麼回復。

而且很多剛開始 Vibe Coding 的人，最危險的不是無法恢復，而是根本沒有意識到錯誤已經被 commit 了。

git add 只會根據當時工作目錄呈現的狀態，把新增、修改或刪除加入暫存區。git push 則只會把已經 commit 進 Git 資料庫的內容送到遠端。

它不會在 push 之前突然很貼心地說「等一下，我先幫你確認整個 iCloud 專案都已經下載完整，再幫你上傳」，沒有這回事！

所以需要你親自檢查的時間點不是 push 的時候，而是 commit 以前。

AI 的工作方式會讓這個問題被忽略

AI 通常會關注它剛修改的檔案，例如它改了登入頁、修了 API、調整了設定，接著告訴你測試通過可以提交，但工作目錄裡可能同時存在其他變化！可能是其他裝置同步過來的真正刪除，也可能只是某些檔案只存在雲端、尚未下載；兩者在 Finder 看起來都可能讓人緊張，但對 Git 而言並不是同一件事。

如果最後使用的是 git add .，那這些變化會全部一起進入提交。

所以安全的做法不是因為有 GitHub 就放心，而是每一次提交前都確認清楚這次到底提交了什麼。

至少要看：
git status
git diff --stat
git diff

你不一定要看懂每一行程式，但你至少應該知道這次改了幾個檔案？為什麼有檔案被刪除？是否出現大量不合理的變動？修改內容是否與這次任務有關？

如果你只是改一個按鈕，結果 Git 告訴你有兩百個檔案被刪除那就不應該繼續 push。

這種風險判斷的能力應該被建立起來！

Vibe Coding 最危險的幻覺是把操作當成結果

很多人使用 AI 寫程式時，會很自然地問你幫我修好了嗎？AI 也很自信的回答
已修正！

但已修正到底是什麼意思？是程式碼改了？是測試通過了？是 commit 完成了？是 GitHub 已更新？是正式環境已重新部署？是所有入口都能回應？是手機與電腦都正常？是登入、付款、寄信、資料寫入都沒有受到影響？

這些都是不同的層次的已修正。

AI 說已修正，很多時候只是我已經修改了一份檔案，至於那份檔案有沒有被正確保存、Git 是否包含不該出現的刪除、GitHub 是否收到完整版本、部署平台是否建置成功、容器是否真的使用新設定，它不一定知道。

不是 AI 說謊，是我們問得太模糊

當你問「修好了嗎」，人類心裡想的是「使用者現在可以正常使用了嗎？」但 AI 回答的可能只是「我已經執行了你要求的操作」。

這就是操作與結果的落差。

也是為什麼我一直覺得真正的 Vibe Coding 能力不是把需求講清楚而已，而是你必須知道做完之後，要怎麼證明它真的做完了。

不會寫程式不代表不能做工程判斷

很多人一聽到 DNS、TLS、容器、Git，就立刻覺得這已經是工程師的世界，自己不可能理解。

但我反而覺得這些名詞不是最重要的，重要的是你有沒有建立一套檢查順序。

網站打不開時，不要一次改十個地方，而是先分層確認：網址有沒有解析到正確位置？主機有沒有回應？HTTP 跟 HTTPS 的結果是否相同？主網址、www、子網址是不是都正常？憑證是不存在、過期，還是沒有被正確載入？服務的設定檔與正在執行的環境，是否真的是同一份？（嗯，我剛才就是檢查到最後一項才發現是 iCloud 檔案沒下載的問題🥲）

應用程式正常但入口掛掉，和入口正常、應用程式回 500，是兩種完全不同的問題。

準備把程式推到 GitHub 時也應該有另一套順序，專案是不是放在 iCloud、Dropbox、Google Drive 或 OneDrive 這類同步資料夾？這次 Git 顯示了哪些變化？有沒有大量不合理的刪除？.gitignore 是否正確？AI 修改的是哪些檔案？即將提交的內容，是否只包含這次任務？推上 GitHub 後，部署平台實際使用的是哪一個 commit？

這些判斷不需要你從零寫出伺服器，也不需要你背完所有 Git 指令，你只需要知道每一層負責什麼以及該用什麼證據判斷它是否正常。

說穿了，這跟醫師問診很像，發燒只是症狀不是病因，咳嗽、頭痛、肌肉痠痛同時出現，也不能只靠其中一個症狀直接下結論，還要量體溫、看血氧、聽呼吸音、驗血，逐步縮小範圍。

網站除錯也是一樣，404 是症狀，安全警告是症狀，某個網路可以、某個網路不行也是症狀，Git 突然出現大量刪除還是症狀。

所以應該把這些症狀排列起來，回推系統 TMD 到底在哪一層斷掉！

所以程式專案到底該放哪裡？

重新規劃了一下，等一下我要開始大搬檔案了，如果使用 Mac，正式開發中的程式專案最好不要放在 iCloud Drive、桌面或文件資料夾裡，尤其是已開啟桌面與文件夾同步的情況。

可以另外建立一個不經過雲端同步的本機目錄，例如：~/Projects 或 ~/Developer，程式版本交給 Git 管理，遠端版本放在 GitHub，資料庫使用資料庫本身的備份與快照，環境變數與重要金鑰另外加密保存。然後真正的重要資料再使用 Time Machine、離線硬碟或獨立備份機制。

這些工具的角色不能混在一起，iCloud 負責同步檔案，Git 負責記錄版本差異，GitHub 負責保存遠端版本與協作紀錄，部署平台負責根據指定版本建置並上線，備份系統則負責在資料損壞、誤刪或裝置故障時，提供獨立的恢復來源。

因為同步不是備份，版本控制也不等於完整備份，自動部署更不會替你判斷這個版本是不是正確。

我現在更在意的不是 AI 能不能做，而是它有沒有留下證據

以前做完一個功能，我們會問「能不能用？」，現在我會再多問幾個問題！

它是在哪個環境測試的？測的是本機還是正式站？測了主入口，有沒有測其他入口？測了首頁，有沒有測登入、API 與背景排程？服務重啟後，設定檔是否一致？Git 這次到底提交了哪些檔案？有沒有不合理的刪除？日誌裡有沒有新的錯誤？今天能用，重新部署後還能不能用？

這不是龜毛，而是 AI 時代最重要的工作習慣之一，因為 AI 讓「產生變更」變得太容易了！

以前要改一個設定，可能要查半天文件，所以人們會很謹慎；現在一句話就能讓 AI 幫你改三個檔案、重建服務、提交 Git、更新部署，速度快到你甚至來不及理解它動了什麼。

速度愈快，驗證就愈重要。能力越強，責任也越重大！否則你得到的不是效率，而是更快地把錯誤送上線。

所以昨天能用，今天為什麼不能用？

因為網站不是做好之後就可以安心放著的靜態成品，它是一個持續在運作的系統，只要重新部署、重建容器、改動設定、同步檔案、更新依賴、提交版本、調整網址或簽發憑證，任何一個環節都可能讓昨天成立的條件，今天不再成立。

Vibe Coding 並沒有讓這些問題消失，它只是讓我們更快碰到它們🙄

以前可能要寫半年程式，才會遇到部署、憑證、容器、同步與版本控制的問題；現在不會寫程式的人，一個下午就能把產品做到上線，自然也會在同一個下午直接撞進真正的系統工程現場。

這不是壞事，但你以為自己只是在做一個網站，所以完全沒有準備面對「系統」會發生的事，這是壞事！

AI 可以幫你寫程式，可以幫你查日誌，可以幫你產生修正指令，也可以一步一步陪你排除問題。但最後仍然需要有人問這份設定真的生效了嗎？這個成功訊息證明了什麼？Git 這次到底提交了什麼？雲端同步有沒有動到不該動的檔案？GitHub 上的版本，真的是我想要的版本嗎？還有哪些地方沒有測？如果明天再發生一次，我們能不能更快知道是哪一層壞掉了？

本文原發表於 2026/07/30 的 Facebook 貼文，原文照登，僅調整網頁排版；文中提及的產品、價格與活動以當時為準。