使用 AI 進行 Vibe Coding 時，功能很快就能看到成果。畫面可以正常開啟、API 有回應、測試資料也順利通過，眼前的結果容易讓人產生工作已經可以交付的感覺。
從維護角度來看，可執行只代表程式在目前條件下能產生預期結果。規則是否完整、例外情境是否涵蓋、資料邊界是否明確，以及下一次需求變更是否方便修改，仍需要逐項確認。
Vibe Coding 容易讓注意力集中在功能是否成功執行。AI 產出的內容一旦讓畫面正常運作，開發者就可能直接接受結果，沒有深入理解邏輯為何這樣拆分、狀態為何這樣判斷，以及資料轉換為何安排在這一層。
可維護的程式需要讓接手的人看得懂、改得動，也能透過測試確認修改結果。功能可以成功執行，只代表完成了一次驗證，不代表涵蓋了長期維護所需要的理解、結構與驗證能力。
短期成功可能讓團隊低估後續維護成本。需求變更時，AI 可以協助快速修改程式，產生新的條件判斷、測試案例或替代實作。這會降低改動的執行成本，讓團隊不必從空白開始處理每一次變更。
AI 能協助修改，也需要足夠清楚的背景作為輸入。若第一次生成時沒有留下需求假設、規則邊界、設計理由與測試依據，後續再要求 AI 調整時，它會根據目前程式碼與提示詞推論新的做法，或自行填補資訊空白。團隊為了確認修改符合原本的業務限制與系統脈絡，仍得重新補上情境、規則與例外條件。
長期成本來自團隊缺少判斷修改是否正確的依據。AI 可以減少修改速度上的負擔，團隊仍需要保留需求脈絡、驗證基準與設計說明，讓後續每一次 AI 調整都有明確依據可以檢查。
程式碼排版整齊，仍不足以支撐後續維護。命名、分層、責任邊界、依賴關係與測試方式，都會影響理解與修改的難度。AI 可以協助產生這些內容，開發者仍需要確認每項產出是否符合系統脈絡。
清楚的設計能讓接手的人看出每段程式負責的工作。資料驗證在哪裡執行、業務規則集中在哪一層、外部服務如何隔離、錯誤如何回傳，這些安排會決定新需求進來後該從哪裡開始修改。
除了程式能正常執行，團隊還需要確認設計意圖是否清楚、程式是否容易測試，以及各項實作是否能安全替換。這些檢查會直接影響下一次需求變更的修改範圍與風險。
若缺少主導設計的維護基準，團隊頻繁使用 AI 快速修改程式，容易讓架構變得零散。AI 會專注處理提示詞提出的局部問題，未必能顧及全域架構的一致性、模組責任與長期演化方向。
程式出現缺陷時，團隊需要先釐清這段程式原本要處理的問題，再追查它實際執行了哪些邏輯。
若程式由 AI 生成，生成時使用的背景、假設與取捨又沒有被留下，除錯就會變成反向考古。
開發者需要從命名、流程、條件判斷與資料變化中，重新推測設計意圖。單一表單驗證或簡單資料處理，影響可能有限。複雜業務系統中的狀態流程、權限規則、金流計算與跨系統資料同步，會牽涉更多規則與相依關係。
例如一段程式表面上處理待付款、已付款、已出貨與已取消等訂單狀態。客服回報部分訂單無法退款後，團隊才發現退款條件藏在多層條件判斷中，還混入活動折扣與物流狀態。導致修正問題前，團隊需要先拆解整段邏輯，確認每個條件對應的業務規則與影響範圍。
除錯時間拉長後，團隊能投入新需求、品質整理與技術改善的時間也會減少。
程式責任邊界不清楚時，開發者很難判斷一次修改會影響哪些功能。理解能力一旦下降，這種不確定性也會隨著功能增加而持續擴大。
AI 經常把眼前需求需要的處理集中在同一個區塊。資料驗證、業務規則、格式轉換、錯誤訊息與外部服務呼叫若沒有適當分層，修改其中一段邏輯時，就需要連帶確認周圍程式是否受到影響。
多次局部修補也會讓業務規則散落在不同地方。今天在 A 功能加入特殊條件，明天在 B 功能複製相近寫法，後續每一次需求變更，都需要投入更多人工確認與回歸測試。
除錯變慢、影響範圍難以判斷時，團隊會開始避開某些程式區域。
這類區域常有幾個共同特徵：沒有人能完整說明邏輯，文件沒有留下設計背景，測試只覆蓋部分情境，小幅修改也曾引發線上問題。需求碰到這些區域時，開發者會提高警戒，排程估算與交付承諾也會變得保守。
大量內容由 AI 生成後，風險還會再增加一層。過去團隊還能找原作者說明設計原因，生成內容若沒有留下背景與說明，接手的人只能面對一段表面完整、脈絡不足的程式碼。程式仍然存在，設計當時的判斷依據卻已經無從追查。
團隊即使繼續使用 AI 修改程式，在缺少背景情境的情況下，也無法保證 AI 生成的功能完全正確，或確認它不會影響其他正常功能。
AI 生成的程式經常帶著完整的外觀。命名合理、結構清楚，註解看起來像是理解了需求，錯誤處理與測試案例也一併產生。這種乾淨一致的外觀，容易讓人認為內容已經過充分思考，也符合既有設計與開發慣例。
表面合理不代表設計正確。AI 可以根據提示詞與訓練資料產出看似完整的內容，卻未必理解現有架構限制、資料演進歷程、例外流程與業務規則。
檢查強度下降後，錯誤的假設就會跟著進入系統。
AI 能快速產出程式碼後，省下的理解時間容易被解讀成效率提升。開發者不再閱讀完整模組、整理業務規則或推導流程，直接把需求描述交給 AI，再取得一段可執行的內容。
任務完成速度變快，待辦事項移動得更快，會議上也有進度可以回報。理解工作不會消失，只是延後到程式出錯、需求變更或其他人接手時才開始。
這種情況還會被完整的產出掩蓋。拉取請求（Pull Request, PR）裡有完整實作與幾個測試案例，開發者在說明時卻只能回答「AI 是這樣產生的」或「我有跑過測試」。這些說法描述的是操作過程，沒有交代設計判斷與取捨依據。
長期採用這種工作模式後，開發者會愈來愈熟悉如何讓 AI 產出結果，拆解問題、判斷邊界、辨識風險與說明取捨的能力卻會不斷下降。
資料是否正規化、邏輯要放在哪一層、例外流程要集中或分散處理、服務邊界要切分到什麼程度，這些設計選擇都伴隨不同取捨，也會影響後續維護方式。
AI 產生解法後，團隊若沒有評估並記錄採用理由，後續接手的人只能看到最後留下的程式碼。他們不知道當時考量過哪些限制、評估過哪些方案，也無法判斷哪些風險是有意識地接受。
重構討論也會因此缺少判斷依據。有人想調整流程時，很難分辨哪些行為來自業務需求，哪些只是 AI 套用的一般做法。程式碼開始被拿來反推需求和邏輯，時間一久，就成為唯一能查到的資訊來源。
第一步是讓開發者能清楚說明自己提交的內容。AI 可以協助產生程式碼、測試案例與重構建議，進入系統的每一項變更，仍應由提交者確認與負責。
程式碼審查（Code Review）時，開發者應說明這次變更要解決什麼問題、AI 協助產生哪些內容、哪些地方經過人工調整，以及可能影響哪些既有流程。這些說明能讓開發者回到設計與判斷的位置。
「AI 這樣建議」或「我有跑過可以動」都不足以說明這次變更已被充分理解。提交者需要能交代邏輯為何放在這裡、主要業務規則有哪些、哪些例外情境尚未處理，以及需求變更後應重新檢查哪些區域。
審查者可以先根據這些說明掌握變更方向，再確認程式是否符合預期。說明與程式內容不一致時，問題就有機會在合併前被發現。
AI 生成內容後，開發流程應進入驗證階段。生成負責提供草稿，驗證負責判斷這份草稿是否能成為可信的變更。
驗證可以分成幾個層次。開發者先確認內容是否符合需求、架構與既有慣例，再透過自動化測試驗證主要行為，接著由其他成員審查風險、系統邊界與程式可讀性。高風險功能還需要納入安全檢查、效能測試，以及業務人員確認。
驗證完成前，AI 產出的內容都僅是一份待確認的草稿。這項共識能讓測試、審查與業務確認留在交付流程中。
開發者在對話中嘗試不同提示詞，AI 產生多個解法，最後選擇其中一版放進程式碼。拉取請求（Pull Request, PR）只看得到最後的結果，需求如何被理解、評估過哪些方案，以及接受了哪些限制，常在這個過程中消失。
一般的小幅修改，只要在 PR 描述補上簡短背景即可。架構選型、資料模型調整、跨系統整合或高風險業務規則，則適合使用架構決策紀錄（Architecture Decision Records, ADR）或輕量設計紀錄，保留當時的判斷依據。
紀錄可以說明團隊面對的問題、評估過的方案、採用的做法、主要取捨，以及需要後續追蹤的風險。內容不必冗長，只要接手的人能理解這段設計從何而來，就有足夠線索繼續維護。
新成員可以透過這些紀錄理解系統演變的原因。後續讓 AI 分析程式時，也能把這些背景放進上下文，成為生成時的約束。
iThome鐵人賽
看影片追技術