AI 在 30 秒內寫出了程式碼
三行，一個我提示它產生的簡單函式。我把它複製下來，看起來沒問題。語法乾淨，變數名稱也不錯，沒有明顯錯誤。
接下來的 5 小時，我都在除錯。
問題不在邏輯。AI 悄悄做了一個假設——清單永遠不會是空的。這在 99% 的情況下都能運作，但那 1% 在正式環境中當掉了。一個真實使用者，一個真實失敗，一段我生命中非常真實的 5 小時。
30 秒的生成，5 小時的除錯。
那不是效率，那是沒人願意談的取捨。
這不是一篇反 AI 的文章。我每天都在用 AI。它確實改變了我的工作方式。但我已經不再假裝「寫出來的速度」是唯一重要的指標。
以下是我在付出夠多次那種代價之後，對 AI 產生的程式碼隱藏成本的體會。
快速程式碼的迷思
我們被灌輸了一個故事：AI 讓你更快。提示、複製、上線、重複。這沒錯，寫的速度確實更快。原本要一小時的事，現在幾分鐘就能完成。這部分是真的。
但故事總是停在這裡，不會提到後面發生了什麼。
AI 用幾秒鐘把程式碼寫出來。你把它上線，然後繼續往前走。幾週後，一個 bug 冒了出來——細微、難以重現、埋在你沒寫也不完全擁有的程式碼裡。
這時候，你除錯的不是你理解的邏輯，而是在從一個無法解釋自己假設的系統裡，逆向工程程式碼。你像在看陌生人的字跡，試著搞清楚他到底想表達什麼。
快速程式碼不是免費的，它只是借來的時間。
這筆債之後才會出現——而到那時，你早就完全忘了 AI 在寫它時做了什麼假設。
AI 程式碼三次讓我花的成本比省下的還多
1. 看不見的假設（5 小時）
AI 假設清單永遠不會是空的。沒檢查，也沒加防護。它為什麼要這樣做？它只知道我問了什麼，不知道真實使用者實際會怎麼做。
這個 bug 在我上線兩週後出現在正式環境。一個沒有任何資料的使用者走到了這個流程，整個系統直接崩潰。
修正？一行程式，一個簡單的 if not list 檢查。
除錯？我花了五個小時，從困惑到越來越煩躁地追 log、加 print、懷疑自己是不是哪裡出了問題，最後才找到那個少掉的假設。
| 時間 | |
|---|---|
| ⚡ 寫作時省下 | 5 分鐘 |
| 🔥 除錯時花掉 | 5 小時 |
比例：60 倍。
2. 在我機器上沒問題的陷阱（整整 1 天）
AI 程式碼通過了我所有測試，在本機跑得完美無缺。我很有信心，所以就上線了。
結果正式環境？完全是另一回事。
AI 是針對我的測試環境做最佳化的——那些我一直在測的乾淨輸入、fixture 裡整齊的資料形狀、我寫的那些 happy path。它沒有想到真實資料，也沒有想到真實使用者會製造出來的奇怪邊界情況。
我花了一整天追一個只在真實世界才會出現的 bug。
| 時間 | |
|---|---|
| ⚡ 寫作時省下 | 10 分鐘 |
| 🔥 除錯時花掉 | 1 整天 |
3. 命名陷阱（3 小時）
AI 把一個變數命名為 data。
很通用，很模糊，技術上也算可以。而且對 AI 來說，這也很合理，因為它不知道什麼才重要。
三個月後，我完全不知道 data 裡裝的是什麼。是原始使用者輸入？轉換後的輸出？從資料庫快取來的結果？還是我過濾過的某些東西？
我花了 3 個小時追查一段原本 10 分鐘就應該能理解的程式碼，只因為 AI 選了方便而不是清楚，而我又沒攔下來。
| 時間 | |
|---|---|
| ⚡ 寫作時省下 | 0 分鐘（我本來會命名得更好） |
| 🔥 除錯時花掉 | 3 小時 |
AI 程式碼真正的成本
除了那些時間成本，還有一些不會出現在任何碼表上的代價。
認知負擔。 程式碼不是你寫的，所以你沒有完整的心智模型。每次碰到它，你都得從頭重建理解。就像回到一個你從沒看過的 codebase，只是理論上你應該是它的作者。
信心流失。 經歷太多次「在我機器上沒問題」之後，你開始不再信任自己的測試。你會帶著一種低強度焦慮去上線。你加 log 只是為了以防萬一。你寫額外的測試，不是因為程式真的需要，而是因為你不信任你沒親手寫的程式碼。
「以防萬一」的螺旋。 額外檢查、額外驗證、額外錯誤處理，不是因為需求真的要求，而是因為你在補償對這段你無法完全背書的程式碼的不確定感。這會悄悄吃掉時間，一點一點累積。
機會成本。 你花在 AI 產生程式碼上的每一個小時，都是沒花在真正需要你的判斷、你的脈絡、你的經驗的工作上。
這些成本是看不見的。沒有 ticket 追蹤它們，沒有 dashboard 衡量它們，回顧會議也不會把它們攤出來。
但它們是真的，而且會慢慢累積、默默加重，直到有一天你發現：除錯開始像是這份工作的本體了。
我現在怎麼做得不一樣
我沒有放棄 AI。那艘船早就開走了，而且我也不想它回來。
但我做了幾個小改變，悄悄地改善了這個比例：
1. 我不會上線自己無法解釋的程式碼。
如果我不能把邏輯完整走一遍，不是略讀，是逐行真的走一遍，我就不上線。就算它測試時沒問題也一樣。這能在正式環境出問題前，先抓出看不見的假設。
2. 我把 AI 輸出當成初稿。
AI 負責寫結構。我會重寫那些真正重要的部分：邊界情況、錯誤處理、變數名稱，以及那些某天凌晨 2 點出問題時，別人必須要看懂的內容。這樣比較慢。但這也是我真正擁有的程式碼。
3. 我會把缺少的假設明確補上。
AI 總是只會最佳化 happy path。所以我養成一個習慣：立刻問自己，這段程式在輸入是空值、null、格式錯誤、或不預期時會怎樣？我每次都自己把那些檢查補上。
4. 我會預留除錯稅。
每一個 AI 產生的函式，我都會在工時估算裡多加 30 分鐘，用來審查和加固。這不是悲觀，而是模式辨識。這筆稅在它阻止的第一個事故中就回本了。
這些做法都不能完全消除問題，但確實大幅降低了我個人的 10 倍代價。有些週甚至已經接近 3 倍。
這就是進步。
誠實的取捨
AI 程式碼寫得比較快，除錯卻比較慢。這個比例會變，某些時候是 2 倍，有些時候是 20 倍，還有一次是 60 倍，讓我懷疑人生。
問題從來就不是 AI 是好還是壞。那是沒有意義的爭論。
真正的問題是：對你的工作、你的 codebase、你的團隊來說，這個比例是多少？
如果只是一次性小工具？用 AI，別回頭。
如果是核心邏輯，而六個月後凌晨 2 點，某個人得去除錯？那就要小心，要刻意，要全神貫注。
這個取捨是真實存在的，而且不會消失。假裝它不存在，不會讓它不見；只會讓你在正式環境裡才發現它，而不是在上線前。
一個問題
你碰過最糟的「AI 寫很快、我除錯很慢」故事是什麼？
那個 bug 花了多久才找到？你漏掉了哪個假設？
我先在留言區說——空清單崩潰，5 個小時，只少了一個 if 判斷。
換你了。👇
原文出處：https://dev.to/harsh2644/i-spent-10x-longer-debugging-ai-code-than-writing-it-15h4
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
