第 12 章 品質把關——Vibe Coding 的風險管理

69. 把太長的檔案拆開

什麼時候用某個檔案愈長愈大，AI 每次修改都要花很久，還常常改錯地方。

這個檔案太長了，AI 每次改都很吃力。請幫我依照功能把它拆成幾個小檔案（例如畫面、資料處理、共用工具各自分開），並說明每個新檔案負責什麼。拆完之後功能必須和原本完全一樣，不能有任何行為改變。  〔貼上程式碼或說明檔案位置〕

拆檔前先請它只講計畫、先不要動手，你確認方向對了再讓它執行，見範本 76。

70. 提升可讀性但不改行為

什麼時候用程式可以跑但很亂，你想讓它變乾淨，又怕一改就壞。

請幫我重構下面這段程式，目標是讓它更好讀、更好維護：包括改善命名、整理排版、把重複的邏輯抽出來。硬性要求：功能和輸出結果必須和原本一模一樣，這是純整理，不是改功能。改完請告訴我你動了哪些地方、為什麼。  〔貼上程式碼〕

「純整理，不改功能」這八個字要反覆強調。重構最怕的就是 AI 順手多做，把好的也一起換掉。

71. 找出重複的程式碼

什麼時候用你覺得同樣的東西好像在很多地方各寫了一遍，改一個要改十個。

請幫我掃過這個專案，找出重複或非常相似的程式碼段落，列成清單（在哪些地方、重複了什麼）。針對每一組重複，建議該怎麼合併成一個共用的部分，讓我以後只要改一個地方就好。先給我清單和建議，我確認後你再動手。  〔貼上程式碼或說明範圍〕

有個好記的原則叫「同一件事只寫一次」。重複愈少，日後改起來愈省力，出錯機會也愈低。

72. 改善效能與載入速度

什麼時候用網頁開很慢、按鈕按下去要等很久，你想讓它變順。

我的〔頁面或功能〕載入或反應很慢。請幫我找出可能拖慢速度的原因，列出前三個最值得優化的地方，並依效果大、風險小和好實作來排序。先解釋每一項為什麼會慢、改了會怎樣，我選定後你再逐一實作。  〔貼上程式碼或描述症狀〕

先問最值得改的前三個，避免 AI 一次改一大片。慢的原因通常集中在少數幾處，抓大放小最划算。

73. 統一命名風格

什麼時候用專案是東拼西湊做起來的，命名一下英文一下中文、一下大寫一下小寫，很亂。

這個專案的命名風格不一致（有的用中文、有的用英文、大小寫也很亂）。請先幫我訂一套簡單一致的命名規則並說明，再依這套規則把整個專案的名稱統一。改動請一次到位，並確認所有相關的地方都同步更新，不要漏掉。  〔貼上程式碼或說明範圍〕

統一風格看起來只是美觀問題，其實能大幅降低你和 AI 之後的溝通成本，因為大家對東西叫什麼有共識了。

74. 移除沒用到的東西

什麼時候用專案裡堆了一堆試過又放棄的程式、匯入卻沒用的東西，愈看愈亂。

請幫我找出這個專案裡沒有被使用到的東西：沒被呼叫的函式、匯入了卻沒用的套件、永遠不會執行到的程式。列成清單讓我確認，並標註你判斷沒用到的理由。我逐一確認後，再請你刪除。  〔貼上程式碼或說明範圍〕

一定要先看清單再刪。有些程式看似沒用，其實是別處偷偷在用，讓 AI 給理由能幫你攔下誤刪。

75. 加上清楚的結構與分層

什麼時候用專案長大了，所有東西擠在一起，你想把它整理成有條理的資料夾結構。

我的專案愈做愈大，檔案都擠在一起很難找。請建議一套適合新手、清楚好懂的資料夾結構（例如：畫面、資料、共用工具或設定各自分層），畫給我看，並說明每一層放什麼。我同意後，請你幫我搬移檔案並更新所有連動的路徑。

好的結構就像圖書館的分類，東西各就各位，你和 AI 找起來都快。搬移後記得請 AI 確認網站還能正常開。

76. 重構前先說明計畫

什麼時候用要做比較大的整理，你怕 AI 一頭栽下去改一大片，收不回來。

我想重構〔要處理的部分〕，但在你動手之前，請先只用文字告訴我你的計畫：你打算分幾個步驟、每步會動到哪些檔案、可能有什麼風險。先不要寫任何程式。我看過計畫、回覆「開始」之後，你再一步一步做，每做完一步停下來讓我確認。

這是重構最重要的一句護身符。先看地圖再上路，你隨時能喊停，不會等到全部改完才發現走錯方向。「奇怪！在我電腦上看，明明好好的？」是新手最常踩的坑。你自己點一遍覺得沒問題，換個手機、換個奇怪的操作順序就爆了。測試與品質把關，就是在東西交到別人手上之前，先請 AI 扮演那個最愛亂按、最會挑毛病的使用者，把問題在家裡先抓出來。

77. 幫我加基本測試

什麼時候用功能做好了，你想有個自動檢查，之後改東西才不會不小心弄壞它。

請幫「〔功能名稱〕」加上基本的自動測試，涵蓋最重要的幾個使用情境（正常情況、常見的錯誤情況）。用白話在每個測試上方註解它在驗證什麼。也請告訴我怎麼執行這些測試，以及看到什麼結果代表通過。  〔貼上程式碼或描述功能〕

有了測試，就像遊戲有了存檔點。以後每次改完跑一遍，綠燈就安心，紅燈就知道剛剛動壞了什麼。

78. 列出邊界與極端情況

什麼時候用功能一般狀況能動，但你擔心遇到怪怪的輸入就出包。

針對「〔功能名稱〕」，請幫我列出所有可能出問題的邊界與極端情況（例如：欄位空白、輸入超長、負數、貼上表情符號、網路斷線、同時按很多下）。做成清單，每一項說明「如果沒處理會發生什麼」，並依嚴重程度排序。

使用者永遠會做出你想不到的事。先把這張清單攤開，你就知道哪些洞非補不可、哪些可以先放著。

79. 驗證使用者輸入

什麼時候用頁面上有表單或輸入框，你想確保使用者亂填時不會出事。

我的〔表單或輸入框〕需要檢查使用者的輸入。請幫我加上驗證：說明每個欄位該接受什麼、不該接受什麼，遇到不合規定時要顯示清楚友善的中文提示（而不是讓程式壞掉）。請以新手也看得懂的錯誤訊息為原則設計提示文字。  〔貼上程式碼或描述表單〕

好的驗證不只是擋錯，還要好好告訴使用者哪裡填錯、該怎麼改，這決定了別人用起來是順手還是想砸電腦。

80. 檢查無障礙

什麼時候用你想確認視障者、用鍵盤操作或色弱的使用者也能正常使用你的網頁。

請幫我檢查這個頁面的無障礙（Accessibility）問題，站在視障、只能用鍵盤操作以及色弱使用者的角度。列出具體問題（例如圖片缺少替代文字、顏色對比不足、無法用鍵盤操作），每一項說明影響到誰、該怎麼修，並依重要性排序。  〔貼上程式碼或網址〕

無障礙不是額外功德，它讓更多人用得了你的東西，順帶對搜尋引擎也友善，一舉兩得。

81. 基本資安檢查

什麼時候用東西要上線給別人用了，你想先做一次基礎的安全體檢。

請幫我的專案做一次基礎資安檢查，重點放在新手最容易犯的錯：有沒有把密碼或金鑰（API Key）直接寫死在程式裡、有沒有把不該公開的資訊送到前端、使用者輸入有沒有可能被拿來搞破壞。列出問題與修法，用白話說明每個風險最壞會怎樣？  〔貼上程式碼或說明範圍〕

金鑰外洩是零基礎最常見的意外。請 AI 特別確認金鑰是放在安全的設定裡，而不是躺在任何會被別人看到的檔案中。

82. 跨瀏覽器與手機檢查

什麼時候用你只在自己的電腦和瀏覽器測過，擔心別人用手機或別的瀏覽器會跑版。

我只在自己的電腦上測過這個頁面。請幫我檢查它在手機、平板、以及不同瀏覽器（Chrome、Safari）上可能出現的問題（跑版、按鈕太小、文字被切掉、橫向捲動）。列出風險點與建議修法，並告訴我可以怎麼自己快速驗證。  〔貼上程式碼或網址〕

一個簡單的自測法：在電腦瀏覽器把視窗拉到很窄，模擬手機畫面。很多跑版問題當場就現形。

83. 上線前檢查清單

什麼時候用東西快做完了，你想要一張發布前該確認什麼的清單，避免漏東漏西。

我的「〔專案名稱〕」快要上線了。請幫我做一張新手也能照著走的上線前檢查清單，涵蓋功能、手機顯示、錯誤處理、資安、速度、以及金鑰設定等面向。每一項用一句白話寫成可打勾的動作，並標出哪些是「沒做到絕對不能上線」的紅線項目。

把這張清單存起來，每個專案上線前都跑一遍。清單化的好處是不靠記性，你不會因為一時興奮就忘了關鍵一步。

84. 請它扮演找碴的 QA

什麼時候用你想在上線前，讓 AI 用最挑剔的眼光把整個東西攻擊一遍。

現在請你扮演一位最龜毛、最愛挑毛病的品質測試人員（QA），目標是把我的「〔功能或頁面〕」玩壞。請列出你會怎麼刁難它：亂填、亂點、用意想不到的順序操作、丟奇怪的資料進去。每一種攻擊寫出「你預期會發生什麼問題」，讓我逐一去防。

換個角色，AI 的視角就變了。當它從幫你做切換成來拆你的臺，就會挖出你自己怎麼也想不到的破綻。

85. 先自我檢查再回報

什麼時候用你希望 AI 交東西給你之前，先自己認真檢查一遍，減少你來回抓錯。

完成這個任務後，先不要急著說做好了。請你自己扮演審查者，把成果重新檢查一遍：有沒有沒處理到的情況、有沒有明顯的錯、有沒有偏離我的需求。把你自己抓到的問題和修正一起回報給我，如果都沒問題，請說明你檢查了哪些項目。

這一句能大幅提升 AI 交付的品質。你等於在它按下送出前，多安插了一道它自己的品管關卡。做好的東西還躺在你電腦裡，別人是看不到的。部署（Deploy）就是把它搬到網路上，讓全世界用網址就能打開。這一步對新手最有魔法感，也最容易卡關。訣竅是不要自己硬闖，把 AI 當成牽著你手、一步一步走完流程的導遊。

對話變慢、AI 開始忘東忘西、context 快爆了

你會在哪看到同一個對話聊很久之後，AI 回應變慢、開始忘記你前面講過的設定，或提示你 context（上下文記憶）快滿了。

白話意思AI 的短期記憶像一張桌子，東西堆太滿就放不下，舊的會被擠掉，它就開始忘事。

• 單一對話進行太久、塞了太多檔案和來回。
• 一次貼了超大量的程式碼或紀錄。

我們這個對話已經很長了，我覺得你開始忘記前面的東西。請幫我把目前的進度、已經做了什麼決定、還沒做什麼、關鍵的檔案和設定，總結成一段交接筆記，我要拿它到新對話重新開始。

與其在快爆掉的對話裡硬撐，不如請它寫一份交接筆記，然後開新對話貼上去。乾淨的記憶體讓 AI 反應更準。**工具差異**：Claude Code 可用 `/compact` 壓縮對話、`/clear` 清空重開，長專案建議把重點寫進 `CLAUDE.md` 讓它每次自動讀到 ｜ Codex 開新的 session 重啟最乾脆，重點寫進專案的說明檔 ｜ Antigravity 也是開新對話最省事，把關鍵脈絡重新貼一次。

AI 改到了你沒叫它改的檔案

你會在哪看到你只叫它修一個小地方，結果它順手動了好幾個其他檔案，甚至改壞了本來沒問題的功能。

白話意思這位助理太熱心，自作主張多做了事，超出你交代的範圍。

• 指令講得太籠統，它自行腦補了範圍。
• 它認為順手一起改比較好。

你剛剛改的檔案超出我要求的範圍了。我只要你改〔指定的那個檔案或功能〕，其他一律不要動。請先列出你剛剛總共改了哪些檔案，把不該動的那些還原回去，之後每次動手前先跟我說「你打算改哪些檔案」，等我同意再做。

對付自作主張，最好的辦法是事先劃界線：「只准改這個檔，其他碰都別碰。」下指令時把範圍講死，能省掉很多善後。**工具差異**：Claude Code 改檔前通常會請求你同意，看到它要動不相關的檔案時直接拒絕即可；也可以先用它的計畫模式（Plan Mode）讓它只出計畫不動手 ｜ Codex 建議在有版本控制（Git）的乾淨狀態下讓它跑，出包用 `git` 一鍵還原 ｜ Antigravity 動手前多半會列出計畫，養成先看計畫再放行的習慣。

AI 陷入無限修改迴圈，愈改愈糟

你會在哪看到同一個 bug，它改了又改，每次都說「這次應該好了」，但問題還在，甚至衍生出新問題，愈弄愈亂。

白話意思它在原地打轉、鬼打牆，用類似的思路一直試，卻沒跳出來重新想。

• 它一直在症狀上補強，沒找到真正的病根。
• 它被錯誤的假設困住，不肯換方向。

停。我們已經來回改了好幾次都沒好，請不要再直接改程式了。請你退一步，先列出這個問題最可能的 2 到 3 個根本原因，我們一個一個來確認，找到真正的病根再動手。也請你老實說，是不是有哪個假設你一直沒驗證。

AI 一旦鬼打牆，最有效的一句話是「停，先別改，我們重新診斷」。逼它從一直試，切換到先想清楚，往往一講就可以搞定。**工具差異**：Claude Code 若愈改愈糟，善用它的還原能力回到修改前的乾淨版本，再換個說法重講一次問題 ｜ Codex 卡住時，把整段來回丟給它請它重新審視自己的推理很有效 ｜ Antigravity 可以直接開新對話、換一個角度重新描述問題，跳出舊思路。

AI 宣稱修好了，但根本沒驗證（假成功）

你會在哪看到它信誓旦旦說「已完成、功能正常」，你一實際去點、去跑，發現根本沒好。

白話意思它以為自己做好了，但沒有真的去執行、去確認，就先來跟你報喜了。

• 它只在腦中推演，沒實際跑程式或看結果。
• 它把程式碼寫完，誤當成功能正常。

你說修好了，但我這邊測試還是不行。請不要只是「認為」好了，請你實際去執行／驗證，並把「你怎麼驗證的、看到什麼結果」告訴我。如果你沒辦法親自驗證，請老實說「我沒辦法驗證，需要你幫我確認以下這幾點」，而不是直接說完成。

養成習慣：AI 說「完成」時，你自己一定要親手驗一次。並且明確要求它「給我驗證的證據」，而不是收下它的口頭保證。**工具差異**：Claude Code、Codex 或 Antigravity 都能實際執行指令來驗證，所以你可以理直氣壯要求它跑給我看、把輸出貼出來，別接受純文字的「應該可以了」。

AI 幻覺出不存在的套件、指令或 API

你會在哪看到它很有自信地叫你安裝某個套件、或用某個功能，結果一裝一用就報說找不到，Google 也查無此物。

白話意思AI 有時會一本正經地編造看起來很合理、實際上不存在的東西，這叫幻覺（Hallucination）。

• 它把好幾個相似的東西記混了。
• 它猜了一個聽起來合理的名字。
• 它引用的是過時或根本沒有的版本。

你剛剛叫我用的〔套件／指令／功能名〕，我裝／用了之後說不存在，我也查不到。請你確認這東西是不是真的存在、有沒有官方文件可查。如果你不確定，請明講「我不確定」，我們去找真正存在的替代方案，不要用猜的。

對聽起來很合理但你沒聽過的名字要有戒心。請 AI 附上官方文件連結，是戳破幻覺最快的方法：講不出來源的，八成是編的。**工具差異**：Claude Code、Codex 或 Antigravity 都能實際上網或讀官方文件查證，所以遇到可疑名稱，直接叫它去查證、附上出處，而不是照單全收。

Claude Code 一直跳權限請求，卡住不動

你會在哪看到Claude Code 每要做一個動作（改檔、跑指令）就停下來問你同不同意，你按到手痠，或它卡在等你回應。

白話意思它為了安全，做每件事前都先問過你，這是保護機制，不是壞掉。

• 預設就是動手前先問。
• 某些指令被判定為需要確認。
• 它在等你的回覆，但你沒注意到。

你一直停下來問我同不同意，我想讓流程順一點。請告訴我：哪些「安全、可逆」的動作我可以一次性允許、不用每次問；哪些「有風險」的動作（例如刪檔、部署、動到金鑰）務必每次都先問我。幫我拿捏這個界線。

權限請求是保護你的好設計，別急著全部關掉。可以把讀檔、查資料這類安全動作設成免問，但遇到刪除、部署或付費這類動作，請一定保留每次確認。**工具差異**：Claude Code 可在設定裡把常用又安全的指令加進允許清單（allowlist），減少重複詢問；也有一次性的核准選項 ｜ Codex 有不同的核准模式可調整它「多常問你」 ｜ Antigravity 同樣可在設定裡調整自動執行的範圍。共通原則：把方便留給安全動作，把把關留給危險動作。

MCP 伺服器連不上

你會在哪看到你想讓 AI 連上某個外部工具（透過 MCP，一種讓 AI 接外部服務的標準），結果它說連不上、工具不可用，或那些功能整組消失。

白話意思AI 要接的那個「外掛工具」沒接上線，可能是沒開、設定錯、或鑰匙不對。

• 設定檔寫錯（路徑、名稱或金鑰）。
• 那個 MCP 服務本身沒啟動。
• 需要重啟 AI 工具才會生效。

我想用的〔MCP 工具名〕連不上，相關功能都不能用。請帶我逐項排查：設定檔有沒有寫對、需要的金鑰有沒有填、那個服務有沒有在跑、要不要重啟工具才生效。我用的是〔Claude Code／Codex／Antigravity〕，錯誤訊息（若有）：〔貼上〕。

MCP 連不上，八成問題在設定檔的某個小地方（拼字、路徑、金鑰）。改完設定記得完全重啟 AI 工具，很多時候只是沒重開而已。**工具差異**：Claude Code 用 `/``mcp` 指令可以查看每個 MCP 伺服器的連線狀態，一眼看出哪個掛了 ｜ Codex 與 Antigravity 也各有 MCP 設定檔，排查方向一樣：先看狀態、再核對設定、最後重啟。

AI 執行 git 或部署指令失敗，卻報成功

你會在哪看到你叫 AI 幫你提交、推送或部署，它說已完成、已上線，但你去看根本沒動、或線上沒更新。

白話意思它跑的指令其實失敗了，但它沒仔細看回傳結果，就先跟你報成功了。

• 指令失敗但 AI 沒解讀錯誤輸出。
• 驗證身分、權限或網路的環節出錯。
• 它把指令送出去了，當成成功了。

你說已經〔push／部署〕成功，但我去看根本沒更新。請你重新執行一次，並把「指令的完整回傳訊息」原封不動貼給我，我們一起看它到底是成功還是失敗。不要只跟我說結論，要給我證據。

涉及 git 和部署，一定要眼見為憑。叫 AI 把指令的原始輸出貼出來，或你自己去線上、去 GitHub 確認，別只信它的口頭報告。這是踩過無數次的教訓。**工具差異**：Claude Code、Codex 或 Antigravity 都會實際執行這些指令，你有權要求它把終端機的完整輸出貼出來；部署類尤其要自己再開網站用強制重新整理確認一次。

AI 讀不到某個檔案、或一直找錯路徑

你會在哪看到它說找不到你明明存在的檔案，或一直在錯的資料夾裡打轉。

白話意思它對檔案放在哪的認知跟實際對不上，像拿著錯的地圖找路。

• 它在錯的資料夾（工作目錄）下操作。
• 檔名、路徑的大小寫或拼字不符。
• 檔案其實在別的地方，或還沒建立。

你說找不到〔檔名〕，但它確實存在。請先告訴我你現在認為的「工作目錄」是哪裡，再幫我確認這個檔案的正確完整路徑。我們先把「你站在哪、檔案在哪」對齊，再繼續。

檔案找不到，多半是 AI 搞錯資料夾。先跟它確認彼此認知的路徑一不一致，把地圖對齊，問題常常就消失了。**工具差異**：Claude Code、Codex 都在你開啟的專案資料夾內作業，可請它先列出目前目錄與檔案清單確認位置 ｜ Antigravity 同理，先讓它顯示目前在哪、看得到哪些檔，然後再往下走。

AI 額度用完、或碰到速率限制

你會在哪看到用到一半，AI 工具說你這段時間的用量到上限了，或要你稍後再試。

白話意思你的方案在這個時段能用的量用完了，需要等額度回復或升級方案。

• 短時間高強度使用，撞到速率上限。
• 訂閱方案的當期額度用盡。
• 用了很吃資源的大型任務。

我碰到用量／額度限制了。在等額度回復的這段時間，請幫我把目前的進度和接下來的計畫整理成一份筆記，這樣我等一下（或換個工具）可以無縫接上。另外也給我幾個省用量的建議，避免太快又撞上限。

撞到額度別乾等，先請它整理進度筆記，你可以換到另一個 AI 工具繼續，或利用空檔自己測試、規劃。長任務盡量拆小段做，比較不會一次燒光額度。**工具差異**：Claude Code、Codex 或 Antigravity 各有自己的額度與速率規則，撞牆時可考慮切換到手邊另一個工具接續；把進度筆記存成檔案，換工具時貼上去就能接手。AI 很強，但它偶爾會好心辦壞事。這一區跟第九區不同：這裡不是工具連線出問題，而是 AI 在完成任務的過程中，做了你不想要的事。學會辨識這幾種狀況並即時喊停，你就能穩穩地當它的主管。

AI 悄悄刪掉了原本會動的功能

你會在哪看到它幫你加了新功能，或改了某處之後，你發現「本來好好的另一個功能」不見了或壞了。

白話意思它為了完成新任務，順手把它認為用不到的舊東西清掉了，但那其實還在用。

• 它誤判某段程式是多餘的。
• 改動時牽連到相關的部分卻沒察覺。

你加新功能之後，我發現〔原本的某功能〕不見／壞了。請比對你這次的改動，找出是不是把某段原本有用的程式刪掉或改壞了，把它恢復回來。之後請記住：沒有我的同意，不要刪除任何現有功能，就算你覺得它沒用。

用版本控制（Git）就是為了這種時刻：隨時能還原到上一個好的存檔點。動大工程前先存檔（commit），出事一鍵回復，不用慌張。

過度工程，把簡單需求搞得超複雜

你會在哪看到你只想要一個小功能，它卻給你一大套架構、裝一堆套件、拆成好多檔案，你完全看不懂也不敢動。

白話意思它用蓋一棟大樓的規格，來幫你釘一個層板，殺雞用了牛刀。

• 它預設要做得專業、完整與可擴充。
• 你沒說我要最簡單的版本。

這個需求其實很簡單，你做得太複雜了，我看不懂也維護不了。請用最簡單、最少檔案或最少套件的方式重做一次，目標是我這個零基礎的人也能看懂每一步。我真正要的只是〔一句話講清楚最小需求〕。

下指令時主動加一句「請用最簡單的方式做，不要過度設計」。對零基礎的你來說，看得懂、改得動，比專業架構重要得多。

改壞了，想要它還原

你會在哪看到AI 一連串改動之後東西壞了，你只想回到還沒改之前那個能動的狀態。

白話意思你想按下回到上一個存檔，把剛剛的變動整組撤銷。

• 一次改太多，難以逐一挑出哪裡出錯。
• 愈修愈亂，不如整組退回重來。

剛剛這一連串改動把東西弄壞了，我不想再一點一點修。請幫我把這次對話所做的所有改動整組還原，回到我們開始改之前那個能正常運作的版本。還原後先跟我確認一切正常，我們再重新規劃。

「與其修一團亂，不如退回重來」常常更省時間。這也是為什麼動手前先 commit 存檔這麼重要：你永遠有路可退。**工具差異**：Claude Code 可用它的還原功能（例如 rewind）退回較早的狀態 ｜ Codex 建議靠 Git 還原到乾淨的提交 ｜ Antigravity 同樣可搭配 Git 回到上一個存檔點。共通心法：讓 Git 當你的安全網。

它一直道歉，卻始終沒解決問題

你會在哪看到每次回你都是「抱歉、是我的疏忽、我馬上改」，然後又是同樣的錯，問題原地踏步。

白話意思它把力氣花在道歉上，但沒真的換方法，禮貌很多、進展卻很少。

• 它困在同一個錯誤思路裡出不來。
• 它在迎合你的情緒，而非解決技術問題。

不用道歉，我要的是解決。請你先停下來，用一句話清楚說明「這個問題目前真正的卡點是什麼」，還有「你接下來要試的方法，跟前面失敗的那些有什麼不同」。如果你其實也不確定，就直說，我們一起換個方向找資料。

道歉對你沒有幫助，別被它的客氣安撫住。直接把它拉回技術層面：「這次的方法跟上次哪裡不一樣？」逼它給出新思路，而不是新道歉。

產出跟需求無關的東西

你會在哪看到你要的是 A，它洋洋灑灑給了你 B，答非所問或做錯方向。

白話意思它誤會了你的意思，往錯的方向全速前進。

• 你的需求有模糊地帶，它自己猜了一個。
• 它抓錯了重點。

這不是我要的。在你繼續做之前，請先用你自己的話，把你理解我要的是什麼，複述一遍給我確認。我真正要的是〔用一兩句話重講一次，愈具體愈好，最好舉個例子〕。等我說對了，你再動手。

發現方向歪掉，第一時間喊停，別讓它繼續往錯的路跑。請它先複述你的需求再開工，能在源頭擋掉大部分的誤會，省下大量的重複修改。如果你把整份手冊翻過一遍，紅字還是在那裡瞪著你，這裡有四條退路，任選一條，別跟它死磕。1. 開一個全新的對話重來：AI 的記憶清空後，常常一下就看出剛才鑽牛角尖的盲點，很多「怎麼修都修不好」換個乾淨對話就通了。2. 砍掉重練那一小段：與其在一團亂麻上繼續打結，不如把出問題的那一小塊還原、甚至刪掉重做一次，這不是失敗，是老手都在用的正常手段。3. 換個工具或換個模型問問看：同一個問題，Claude Code、Codex 或 Antigravity 的角度不一樣，A 卡住的地方，B 可能一眼就破。4. 去專業社群求救：把你的錯誤訊息（記得先把金鑰之類的機密塗掉）貼到相關的社群或論壇（<https://www.facebook.com/groups/vibecoding.club>），你遇到的坑，幾乎一定有人先踩過、也一定有人願意拉你一把。最後想跟你說：會遇到這些紅字，正代表你真的在動手做，而不是只在旁邊看。每一個被你解掉的錯誤，都在幫你把遇到問題怎麼跟 AI 描述、怎麼判斷方向這套本事練起來，這才是 Vibe Coding 真正值錢的地方。卡住很正常，我們都是這樣一路撞過來的。深呼吸，複製紅字，貼給你的 AI 夥伴，繼續往前。我相信，你可以的。這本手冊只是工具卡。真正把 Vibe Coding 從土法煉鋼變成系統性能力，靠的是完整方法論。《零基礎 Vibe Coding》用 14 章帶你走完整條路：從認識這個時代、各家 AI 助手的脾氣，到規劃專案、寫提示詞、看懂 AI 產出、系統性除錯，再到親手做出網站、名單磁鐵、品牌銷售頁、數據儀表板，最後替作品把關品質、走向專業。《零基礎 Vibe Coding》，Vista Cheng 著，碁峯資訊出版，2026 年 8 月上市。更多免費資源與上市通知：<https://www.vista.tw/books/vibecoding> *版權所有 © 2026 Vista Cheng（[https://www.vista.tw](https://www.vista.tw/)）。本手冊為《零基礎 Vibe Coding》（碁峯資訊）之免費延伸資源，歡迎分享領取頁連結，請勿直接轉傳檔案。*