一段 AI 寫出來的程式碼，要先被誰看懂：vibe coding 轉長期專案的維護觀察

9 月 8 日，V2EX 上出現一則提問：「vibe coding 後想轉成長期專案，哪種維護方式更好？」發文者自述喜歡可讀性強、耦合低、不提前過度設計的程式碼，但一口氣用 AI 生成的程式，風格始終達不到他要的標準。跑原型的時候不看程式碼，現在想把東西上線，問題就來了：是在既有基礎上重構，還是照著文件從架構重新出發。

這個問題表面上是工程選擇，實際上是一場關於「程式碼被誰閱讀」的設計討論。

兩條路徑，兩種成本結構

發文者把選項列得很清楚。在現有基礎上改，優點是不會漏功能，缺點是要先看懂 AI 的程式碼，而且 AI 常把簡單的東西拆成很多類別、很多狀態機，徒增複雜度。重新出發則相反，可維護性高、沒有理解成本，但可能漏掉 AI 在原型期補上的小細節。

這其實是兩種不同的排版邏輯。重構既有程式，等於拿到一份別人排好的版面，字級、欄寬、行距都已固定，你只能局部調整；重新出發則是自己重排，先定網格再放內容。前者省規劃、費理解；後者費規劃、省理解。發文者的困擾在於，AI 的版面看起來工整，實際上處處是繞路。

回覆裡最受認同的做法來自網友 xujinkai：持續重構。不斷問 AI 某個模組的邏輯，給出自己的重構方案，同時測試要跟上，「其實和人寫程式很像」。他另外補了一句務實的判斷：如果程式碼太多，先讓 AI 總結出功能文件，再讓另一個 AI 另起爐竈；但過程中還是要持續重構，「目前不存在 AI 一錘子能幹好的可能，除非專案很小」。

這句話點出了核心：vibe coding 的產出是一種「一次性生成物」，要變成長期專案，中間必須插入一層由人定義的結構，就像介面設計裡的約束條件。沒有約束的生成，無論文字或程式，都會朝裝飾過度的方向漂移。

信任的介面：誰為上線負責

討論裡最有張力的，是 chjqpmain 那則回覆。他指出這其實是心理與現實的問題：如果是老闆或 CTO 管人，人不會過度擔心，因為人可以承擔責任；但自己讓 AI 做的專案，「可不自己親自審過的總是不放心」，真上線出了問題，模型也只能被說幾句，跟人是不一樣的。

這段話把「程式碼審查」講成了一種責任介面。人寫的程式碼之所以讓人安心，一部分來自它的可歸責性；AI 的程式碼缺少這一層，於是閱讀理解的成本被放大了。發文者說「要相信後人（AI）能解決現在解決不了的問題」，TirionHo 這樣回，聽起來豁達，但 JasonYip 的回覆正好相反：「對程式碼失去掌控以後，很難再掌控回來。就好像古法時代一開始沒有控制複雜度和耦合，後續複雜度上來了幾乎沒法下手。」

這與我們先前觀察過的字節秋招二面把 AI coding 講解制做成評估介面是同一組張力：當生成變得便宜，理解與解釋反而成了稀缺的能力，於是組織開始把「能不能講清楚程式在做什麼」設計進流程裡。

一個極端樣本：完全不看程式碼的人

討論後半出現了一個對照組。網友 milkleeeeee 說自己的專案已經 100% vibe coding 快一年，「好好的」。追問之下，他的做法是：不看程式碼，AI 寫完自己也不測，讓 AI 自己起開發伺服器、驅動瀏覽器測，上線前接入線上資料庫再讓 AI 測一遍，「它說沒問題我就上線」。

發文者去看了他的產品 getcheapai.com，評價是「很乾淨克制的風格，又不失互動感」，但隨即發現兩個問題：一是產品幾乎沒有複雜狀態管理的需求，借鑑意義不大；二是做了響應式，小螢幕上文字明顯疊在一起。

這個小瑕疵很說明問題。視覺上的字疊在一起，和程式裡的狀態機繞彎子，是同一種病：生成物在表面上成立的機率很高，在邊界條件上成立的機率低。原型看起來乾淨克制，不等於結構乾淨克制。milkleeeeee 自己也承認：「用 AI 做就是會有很多瑕疵，程式碼風格也不能（保證）。」

對發文者這種在乎可讀性的人來說，這個樣本正好劃出了光譜的兩端。一端把 AI 當外包，交付標準是「它說沒問題」；另一端把 AI 當初稿產生器，每一行都要過自己的眼。前者適合小而簡單、壞了就重做的產品；後者適合要長期活著的系統。大多數認真想「轉長期」的專案，落在中間。

地基先於生成

ttkit 的回覆提供了另一個視角：實際業務裡功能模組本來就不會全耦合在一起，新專案一開始把地基打好，包括專案架構說明、工作流、每實現一個功能就寫文件，維護起來並不難。

這基本上是 spec-driven 的思路：先寫規格，再讓 AI 在規格內生成。就像做視覺設計先定設計系統，字級、間距、元件都約束好了，生成的頁面才不會各自為政。vibe coding 之所以容易失控，往往是因為規格這一層完全缺席，AI 每次生成都在重新發明自己的慣例。

發文者的困境由此有了比較清楚的答案輪廓。原型已經完成、準備上線的專案，與其糾結「重構或重寫」的二選一，不如先做 xujinkai 說的那件事：讓 AI 把現有功能總結成文件。這份文件就是新的地基，之後無論是局部重構還是另起爐竈，都有一個可核對的基準，「漏功能」的風險也從記憶問題變成核對問題。

而更根本的轉變在於心態：從「AI 幫我寫」轉成「我定義結構，AI 填內容」。sickworm 說得直接，你需要一個乾淨的架構支撐程式品質，減緩程式腐化的速度。架構這件事，在 AI 時代沒有變便宜，反而變貴了，因為生成的速度越快，缺乏架構的代價累積得也越快。

程式碼終究是要被未來的人（或未來的自己）閱讀的文件。AI 可以寫得很快，但「什麼值得被留下來」這個編輯判斷，目前還是人的工作。