AI 在 10 分鐘內寫出了我功能的前 80%。
程式碼很乾淨。邏輯很合理。順利路徑第一次就跑通了。我執行了一下，看到它正常運作，心裡浮現出那種會讓人稍微往椅背靠一下的開發者成就感。
我很驚艷。我真的覺得自己很有效率。我以為再過 10 分鐘，最多 15 分鐘就能搞定。
那是星期二。到了星期四晚上，我還在處理同一個功能。不是因為 AI 失敗了，而是因為它剛好把最簡單的部分做得太成功，卻把真正困難的部分完整留給了我。
邊界情況。錯誤處理。空值檢查。只有當真實使用者做出順利路徑沒有預期到的操作時，才會浮現的那些情境。
AI 沒有寫那些。它甚至不知道那些東西存在。它很有信心、也非常完整地最佳化了「一切都順利」的世界——但那不是你的使用者所處的世界。
這就是 AI 寫程式的 80/20 法則。前 80% 很快、很驚人，甚至有點神奇。最後 20% 才是真正工作的所在。而它會吃掉你總時間的 80%。
以下是我對這段落差的體會，以及為什麼我認為它比你在星期二省下的那 10 分鐘更重要。
那 80%——快速、乾淨，而且真的很令人驚艷
在我開始講那些挫折之前，我想先誠實地說明這一部分。
AI 在前 80% 的表現相當驚人。你給它一個清楚的提示，它理解順利路徑長什麼樣子，然後產出能運作的程式碼。不是「大致上能用」，而是實際能用，而且變數名稱合理、邏輯也符合你的預期。
我第一次看到它實際運作時，真的有種自己像是作弊了的感覺。任務單在關掉，速度圖表在上升。我比好幾年來都更快地把東西交出去。
那種感覺是真的——我不是在諷刺。AI 之所以快，是因為它處在熟悉的領域裡。順利路徑就是那條大家都走過很多次的路。你的問題在訓練資料裡有某種形式的對應，也早已被解決過無數次，模型能很有把握地靠模式比對一路推進。
那 80% 真的存在。速度也真的存在。
問題是，我們開始把那 80% 當成全部了。但它不是。
那 20%——星期二如何變成星期四
AI 寫出了順利路徑。以下是它沒寫出來的東西：
空清單。 當使用者還沒有任何資料時會怎樣？新帳號，資料庫裡是空的，AI 以為一定會有專案的清單，結果其實是空的。AI 沒有檢查。你在上線三天後從使用者回報才發現，花了一個小時追查到這個未處理情況，然後補上你本該星期二就寫好的檢查。
錯誤處理。 AI 假設網路會有回應。它假設 API 會回傳你要的內容。它假設第三方服務是正常運作的。每一個 try-catch 區塊、每一個備援方案、每一個「如果失敗了要顯示什麼給使用者看」的決策，都是你的工作。AI 把它空著，因為「出錯」不在提示裡。
與領域相關的邊界情況。 這是每次都會讓我驚訝的部分。AI 不知道你的商業邏輯。它不知道在你應用程式的三個不同地方，「空」代表的意思不一樣。它不知道那些格式不同的舊資料。它不知道某個企業客戶會用一種沒人預料到的方式使用產品。你知道這些事。AI 從沒聽過。
效能瓶頸。 AI 會寫出在它被給予的範例中能運作的程式碼。它不會針對規模做壓力測試。等功能正式上線、而且對於大型資料集的使用者來說頁面突然要四秒才載入時，你才會找到瓶頸。程式碼沒錯，只是它沒有用真實負載的角度來寫。
維護成本。 這個最慢才會顯現。AI 寫的是解決今天問題的程式。三個月後，當需求稍微變動、你想要擴充它時，你才會發現這個抽象層並不完全符合新的形狀。這時候重構它所花的時間，甚至可能比當初直接重寫還多。
這些專案都要花時間。而且加總起來，對我所有使用 AI 生成程式碼的功能來說，它們穩定地大約佔總工時的 80%。
那 30 秒，卻讓我多花了 3 小時
我最近在看一個 Pull Request——大概 200 行 AI 生成的程式碼，是我大概花 30 秒提示出來的。
結果我接下來花了 3 個小時處理它。
不是因為程式碼壞掉了。程式碼其實沒問題。我花了 3 個小時補上 AI 默默決定「不是它的事」的所有東西：錯誤路徑、空值檢查、解釋那些不直觀決策的註解，以及我透過實際思考使用者會怎麼做而找到的邊界情況。
那 30 秒裡我覺得自己很快。那 3 小時裡我覺得自己很慢。
但我一直反覆想到的一件事是：那 3 小時才是真正的工作。那 30 秒只是鷹架。AI 並沒有減少工作量——它只是把工作搬家了。時間從「寫出結構」轉移到「讓它真的可上線」，而後者更慢，因為它需要一件 AI 真正沒有的東西：你這個特定情境、你的特定使用者、以及你和這個程式碼庫的特定歷史脈絡。
那一刻，我不再在乎生成花了多久，而開始追蹤一個更誠實的指標：到底多久之後，它才真的準備好可以上線。
為什麼這不是在抱怨 AI
我要講清楚一件事——這個 80/20 的分裂不是 AI 失敗，而幾乎就是它的設計本意。
AI 是針對常見情況最佳化的。常見情況就是順利路徑。快速生成常見情況確實很有用；我並不是在貶低這件事。
問題不在 AI，而在於我們開始怎麼衡量圍繞它的生產力。
我們衡量速度。關掉多少任務。生成了多少行。貢獻圖。這些指標都能非常漂亮地捕捉那 80%，因為那 80% 又快、又看得見、又會以綠色方塊的形式出現在介面上。
那 20% 對這些指標來說是隱形的。沒有任何儀表板會顯示你花多少時間在補錯誤處理。也沒有人在站立會一開始就說：「我昨天花了一整天處理 AI 沒有預想到的邊界情況。」它不會出現在任何地方。但實際上，大部分時間都花在那裡。
那 80% 能讓你做出 demo。那 20% 才能讓你進入正式環境。如果你沒有追蹤那 20% 花了多久，那你其實沒有在追蹤真正的生產力——你只是在追蹤你多快可以輸入一個提示，然後為此感覺良好。
我實際上做了哪些不同
我沒有放棄 AI，甚至也沒有停止使用它。但我改了幾件事：
我會先把那 20% 的成本算進去。 當我估算任何涉及 AI 生成程式碼的任務時，我會把生成時間大約乘上 4。AI 說「這是一個 10 分鐘的功能」，我會告訴自己這是 40 分鐘的功能，然後照此規劃。這不是悲觀，而只是模式本來就會這樣。
我會明確提示「非順利路徑」。 在我開始生成主要程式碼之前，我會先把這些內容加進提示：如果輸入是空的，應該怎麼處理？如果 API 失敗了，應該怎麼辦？這裡有哪些邊界情況？AI 不會自己想到這些。如果我把它們說出來，它至少會試著處理。
我會先寫會失敗的測試，再寫程式碼。 什麼會把它搞壞？惡作劇的使用者會怎麼做？我先寫這些測試，讓 AI 有一個目標。它不會抓到全部，但會比它自己亂猜抓到更多。
我會記得那 3 小時。 當我因為 demo 跑得通，就想快速把東西推上去時，我會想到那 3 小時。那 30 秒感覺很棒，但那 3 小時才是工作本身。
這些做法不會讓那 20% 消失，但它們會讓它變得可預期，而不是出其不意。這就是「管理它」和「被它突襲」之間的差別。
一個問題
你上一次在某個 AI 快速生成的東西上，花最久的最後 20% 是多久？
如果你有實際數字，我想知道。生成花了多久，和真正上線花了多久之間的落差——那就是我最好奇的數字。
我的答案：生成 30 秒，完成 3 小時。
你的呢？👇
提醒：這篇文章的結構與觀點整理有使用 AI 協助，但其中的經驗、故事與意見都來自我本人。
原文出處：https://dev.to/harsh2644/the-8020-rule-of-ai-code-why-the-last-20-takes-80-of-your-time-3pcg
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
