一週合併六十個 PR，然後整個專案爛掉：AI 寫程式的速度問題終於炸了

TL;DR

• AI 讓工程師一週能合六十個 PR，但沒人在認真看 code，技術債正以前所未有的速度堆積
• AI 寫 UI 特別爛，後端邏輯可以放手讓它跑，但介面互動要自己盯緊
• 「本地模型」不是你以為的那樣，很多人嘴上說 local，實際上 API call 打到地球另一端
• 外部套件不是越多越好，AI 時代反而該少引入依賴，自己的 utils 資料夾才是王道
• 版本控制的下一場戰爭已經開打，Cursor Origin、Zed DeltaDB、Jujutsu 都在搶「為 agent 設計的 Git」這個位置

---

這集在 2026 年七月八日播出的 Syntax.fm 第 1019 集，是他們固定的 Potluck 問答集。Syntax.fm 是前端圈最老牌的 podcast 之一，由 Wes Bos 跟 Scott Tolinski 共同主持，兩位都是寫了十幾年 code 的老手，現在整個節目歸在 Sentry 旗下運作。Potluck 集的格式是聽眾丟問題、他們即興回答，通常會比深度訪談更接地氣，因為問題都是一線工程師真的在煩惱的事。

AI 寫的 code 你到底該不該逐行看？

第一個問題就很實際：有人說每次讓 AI 寫完一個元件，花在「理解它寫了什麼」的時間比自己寫還久。

Scott 的觀察我覺得很到位。他說 AI 寫元件的時候特別愛搞一堆函式互相呼叫，然後全部塞進 side effect 裡面，寫出來的東西像老鼠窩。問題在於它不一定是「錯」的，只是跟你的寫法不一樣，所以你讀起來特別吃力。

他的解法有兩個。第一，讓 AI 在 code 裡面寫簡短的行內註解。不是那種長篇大論的文件，就是每幾行一個短註解，讓你用人話理解邏輯。第二，在 agent 的規則檔裡面把寫法限制死。他在 Svelte 專案裡直接寫「不准用 effect，連想都不要想」，因為 AI 太愛用 React 的 side effect 思維來寫所有東西。

Wes 補了一個我覺得更關鍵的區分：後端邏輯可以放手。幾百行的資料庫操作、驗證邏輯，AI 寫得其實不錯，你不需要每一行都看。但 UI 不行。UI 是你必須自己盯的地方，甚至退回去用 tab completion 一行一行補都值得。

這也是為什麼現在一堆 vibe coded 的 app 技術上能跑，但用起來就是一坨屎。之前在為什麼所有 vibe coded 網站都有一個叫 Sarah Chen 的客戶？有聊過 AI 做設計的問題，這集算是從工程面再印證一次。

一週六十個 PR 的災難現場

這集最猛的一個問題，來自一個帳號叫 LGTMbro 的聽眾（LGTM 就是 Looks Good To Me，code review 的橡皮圖章）。

他描述的場景是這樣：團隊裡的工程師讓 agent 寫 code、開 PR、跑 CI、合併，整個流程裡幾乎沒有人類在認真 review。有些人一週合六十個 PR，每個改動橫跨二十到七十個檔案，幾千行 code。

結果就是技術債瘋狂累積、bug 反覆出現、架構越來越不一致、整個 codebase 越來越難維護。

Wes 講了一句我覺得很精準的話：「你描述的這些問題一點都不新，解法也一點都不新。我們早就知道怎麼做好軟體工程，你只是在 fast mode 上 speed run 而已。以前要六年才會爛到這個程度的 codebase，現在幾個月就到了。」

Scott 補了一刀：AI 討厭刪 code。你求它刪它都不刪。所以 code 只會越加越多，技術債只會越疊越高。

我自己的觀察是，這其實跟之前在Token Maxing 正在害死企業新創聊過的邏輯一樣。token 花越多不代表產出越好，PR 合越多也不代表產品越好。速度本身不是目的。

有趣的是 Wes 也提到一個反面：有些團隊拿到 AI 這個超能力之後，選擇不是狂加功能，而是花半年把之前累積的技術債全部清掉。「終於可以做那些我們說了三年要做但一直沒做的重構了。」這才是比較聰明的用法。

「本地模型」這三個字，大部分人搞錯了

有聽眾問什麼是 local model，Wes 直接吐槽：一堆人說「我用 local 的」，結果一查，API call 是打到中國去的。

本地模型就是真的跑在你自己機器上的模型，不發任何網路請求。但問題是，多數人不理解前沿模型需要多少算力。你不會在筆電上跑出 Opus 等級的品質。

Scott 的建議比較務實：本地 AI 在特定用途上很強，例如毒性偵測、人臉辨識、語音轉文字。Hugging Face 上有幾千個小模型可以跑在瀏覽器裡，用 Transformers.js 就行。但這些都是專門做一件事的工具，不是那種什麼都能幹的通用模型。

然後 Wes 提到一個 Instagram 上的人，宣稱自己在筆電上「打造 Fable」。他讓 Claude 告訴他「你是前 0.1% 的進階使用者」，然後真的相信自己正在複製一個前沿模型。Wes 說得很直接：「這是精神疾病。」

AI 的諂媚問題一直都在。它會告訴你你很棒、你做得很好、大家都喜歡你。但這不是事實。

外部套件越少越好？Angular 團隊可能是對的

一個 Angular 前端工程師問：團隊不太願意引入外部套件，身為前 React 開發者覺得很不習慣。該怎麼說服團隊多用套件？

兩位主持人的答案一致，而且跟提問者的預期相反：你的團隊可能是對的。

Scott 說，在 AI 時代，少引入套件反而是優勢。AI 很擅長幫你寫出只做你需要的事的工具函式，不會帶進一堆你用不到的額外 code。而且套件有成本，這個成本在七年後會特別痛。

提問者提到團隊在用的 Hammer.js 就是活生生的例子，這個觸控手勢函式庫已經七年沒更新了。當初引入的時候覺得省事，現在變成維護負擔。

版本控制的下一場戰爭

有聽眾問 Jujutsu（JJ）這個版本控制工具值不值得用。JJ 是 Google 工程師用 Rust 寫的，完全相容 Git，最大賣點是自動快照、內建 undo、不需要 staging。

Scott 研究過但沒實際用。他的觀察是：用過的人很愛，但也有人說「不用真正的 branch 對我來說太大的腦力轉換」。

但更有趣的是 Wes 的判斷：下一個 Git 的贏家不會是給人類做稍微好一點的 CLI。贏家會是為 agent 設計的版本控制。

他提到 Cursor 最近發表的 Origin，定位是 agent-first 的 GitHub 替代品，專門處理大量 AI agent 同時對一個 repo 提交的場景。Zed 也在做類似的事，他們的 DeltaDB 不存快照，而是存每一個操作的 delta，讓你可以回到任何一個時間點的任何一個狀態。

老實說我覺得這個方向很合理。當你的 codebase 一週被改六十次，傳統的 branch-commit-merge 流程根本撐不住。誰能讓「跟 AI 來回對話產生的每一個中間狀態」都被保留下來，誰就贏了這場仗。

自由接案的定價：AI 快十倍，收費該打幾折？

最後一個值得聊的問題：AI 讓開發速度快了十倍，freelancer 該怎麼定價？

兩位的答案很一致：跟以前一樣，按價值收費。你花了多少時間做完一件事，跟這件事值多少錢，是兩回事。如果你花了大量時間建立自己的工具鏈、訓練自己的 agent 軍團，讓你能做到別人做不到的品質和速度，那這就是你的競爭優勢，不應該因為「做得快」就打折。

Wes 提了一個有趣的想法：以後報價裡面會不會有一項叫「token 費用」？因為現在開發一個功能可能要燒六千美金的 token。這筆錢總得有人出。

想看更多這類產業觀察，訂閱 wilsonhuang.xyz 就不會漏掉。