OpenCode 創辦人的清醒劑：AI 讓我們出了十倍功能，但沒有變快

本文整理自《The Pragmatic Engineer》2026 年 5 月播出的單集。

{{< youtube 1VqKUrxR2C8 >}}

{{< spotify "episode/10InvdH4AqOfZGCMTyzqiM" >}}

{{< apple-podcast "tw/podcast/building-opencode-with-dax-raad/id1769051199?i=1000769854268" >}}

---

做出最多人用的 AI 工具，然後承認自己沒有變快

OpenCode 是目前全球使用量最大的開源 AI 程式碼工具。去年 6 月上線，12 月累積到 65 萬月活躍使用者，今年 1 月暴增到 250 萬，5 月已經逼近 800 萬。支援超過 75 家模型供應商，GitHub 星星數突破 16.5 萬顆，成長速度是 Claude Code 的 4.5 倍。照理說，打造出這種等級產品的人，應該最有資格宣揚 AI 讓開發者生產力飛升。但 OpenCode 共同創辦人 Dax Raad 在 Gergely Orosz 主持的 The Pragmatic Engineer Podcast 上，做了一件很少有 AI 新創創辦人願意做的事：承認 AI 並沒有讓他的團隊真正變快。

「很多東西確實變簡單了，」Raad 說，「但我還是跟以前一樣苦。以前我花 94% 的精力想該做什麼、5% 去做。現在變成 96% 在想、4% 在做。算一算大概進步了 20%，但每天的感覺跟以前一樣辛苦。」這不是謙虛的場面話。幾個月前，他發了一封內部備忘錄給團隊，直接點出三個問題：功能出太多、hack 太多、整理太少。備忘錄裡最扎心的一句是：「最糟糕的是，我不覺得我們用這些來換到了速度。我覺得我們的速度跟平常一樣。」一個做出全球最熱門 AI 程式碼工具的人，自己用了之後的結論是「感覺快了，但其實沒有」。這個反差值得每個正在導入 AI 工具的工程團隊認真想想。

消失的刺痛感

Raad 在訪談中提出了一個概念，可能是整場對話裡最值得記住的東西：消失的刺痛感（muted prickle）。

在 AI 之前，工程師寫出一段爛程式碼的時候，身體會有一種微微的不舒服。你知道自己在走捷徑，你知道這段 hack 遲早會出事，你甚至隱約記得上次這樣做之後花了多少時間善後。這種不適感聽起來像是缺點，其實是工程師最珍貴的品質管控機制。它讓你在敲下那一行妥協的程式碼之前多猶豫一秒，讓你在第二次走同樣的捷徑時比第一次更不安，讓你在「先這樣吧」和「我真的該重構了」之間做出比較正確的判斷。

現在，AI agent 幫你寫了那段爛程式碼。你沒有親手打那些字，沒有一行一行感受到自己在妥協，只是看了一眼 diff 就按下 approve。刺痛感消失了，因為痛的不是你。但地雷還是埋下去了。「問題還是在那裡，地雷遲早會爆，」Raad 說，「只是你不再覺得那麼難受了。你的判斷力被扭曲了，因為你失去了那個回饋迴路。」

這個比喻之所以準確，是因為它指向一個 AI 工具討論中很少被觸及的層面：工具不只改變了生產的速度，還改變了使用者感知品質的能力。當寫程式碼的是你自己，每一個妥協都伴隨著身體記憶。當寫程式碼的是 agent，妥協變成了一個你瞥一眼就滑過去的 pull request。Orosz 補充了一個類比：這就像 CEO 把所有麻煩都委派出去，對第一線的問題完全失去觸感，直到有一天自己走進現場才發現情況有多糟。AI agent 正在對每一個工程師做同樣的事，把他們變成自己程式碼庫裡的「不接地氣的高層」。

十倍功能，零倍進步

刺痛感消失帶來的直接後果，就是 Raad 在內部備忘錄裡指出的三個問題。

第一個最直覺：出太多不該出的功能。使用者反映一個問題，prompt agent 就好了。競爭對手做了一個功能，prompt agent 也行。需求來了就做，每個看起來都合理，加起來卻是一場災難。「你以為你出了一千個功能，等於做了一個好產品，」Raad 說，「其實你做出了一個什麼都有但什麼都不對的爛東西。沒有一致性，到處都是你不該支援卻得繼續維護的功能。」每出一個功能，就多了一個未來每次改動都必須考慮的連鎖影響。能出十倍功能，不代表團隊有十倍的好點子。

第二個問題更微妙：hack 比以前多太多了。系統本來不支援某個功能，正確做法是重新設計架構，讓系統從根本上能承載新需求。但現在有另一條路：讓 agent 塞一個 hack 進去，反正 agent 以後也能幫你處理 hack 帶來的副作用。這條路的誘惑力比以前大了十倍。在 AI 之前，走捷徑至少還伴隨著體力上的疲憊和心理上的刺痛。現在連這些阻力都沒了，工程師的判斷天平嚴重傾斜，大量本該被重新設計的系統就這樣帶著 hack 繼續跑。

第三個問題是整理時間不夠。每天醒來有一千個使用者在喊你做這做那，每天都有新的競爭對手冒出來。在這種壓力下，很少有人會主動說「今天不出新功能，我要花一整天整理程式碼」。但 Raad 觀察到一個有趣的翻轉：清理技術債現在比以前容易多了。你想到一個新的設計模式，可以叫 agent 把舊模式全部替換掉。刪除過時的程式碼、統一命名規範、重構模組結構，這些以前要花一週的苦差事，現在可能半天就搞定。工具不是問題，問題是你願不願意把時間花在看起來沒有產出的事情上。Raad 的答案很明確：如果五年後這個地方變成一個大家不想待的公司，招不到好人，整天在啃舊程式碼，那現在省下的每一天整理時間，未來都會加倍奉還。

備忘錄裡最讓人停下來想的是這句話：「最糟糕的是，我不覺得我們用這些來換到了速度。」團隊感覺自己在飛，但回頭一看，進度跟競爭對手差不多。沒有任何一家同行因為更會用 AI 就遙遙領先。「而且我們可是做 AI 程式碼工具的公司，」Raad 苦笑，「如果連我們都做不到用 AI 把對手甩開，誰能？」

AI 省下的時間去哪了

這就帶出了一個更深層的問題：AI 確實讓很多事情變簡單了，那省下來的時間和精力，到底流向了哪裡？

Raad 的觀察很直接。大部分工程師把省下的時間拿來讓自己輕鬆一點，而不是做更多的事。這不是批評，他完全理解為什麼。多數軟體工程師的工作環境不是那種讓人想拼命的地方。薪水固定、升遷有限、做多做少差別不大。給他們一個按鈕能讓工作變輕鬆，合理的反應就是按下去，把省下的時間留給自己。公司得到的是同樣的產出，只是員工比較開心。Raad 強調，如果你的團隊本來就不是那種被使命感驅動的團隊，那 AI 帶來的效率提升，大概率會被個人舒適度吸收掉，而不是轉化成組織的競爭力。

問題出在那些還在意品質的人身上。每個組織裡都有少數幾個人是出於對技術的熱愛在拼，他們會在別人下班後多看兩眼 code review，會為了一個不完美的實作跟人爭論。現在，這些人正在被 AI 產生的劣質 PR 淹沒。Raad 說他最近招到幾個人，前公司的狀況就是這樣：他們是團隊裡唯一還在乎品質的人，其他人都用 agent 快速交差，他們被迫一個人扛起所有的 code review、除錯、善後。時間一久就燒乾了，然後離職。組織因此失去了最不該失去的人。

Raad 的解法出乎意料：少請人，但付更多。與其請兩個工程師、開兩份普通薪水，不如把兩份薪水合在一起請一個真正厲害的人。他說在這個價位出現的人，能力和動力會直接跳一個層級。「我們不需要一千個人，我們需要二十個對的人。」

護欄比功能重要：工程領導力的重新定義

如果 AI agent 是一群全年無休、沒有判斷力的實習生，工程主管的角色就不再是寫程式碼，而是讓這群實習生不會把東西搞壞。

Raad 觀察到一種說法正在工程領導圈裡流行：工程師的角色要從「寫程式碼」轉變成「讓程式碼能安全地被出貨」。你要建立測試機制、制定命名規範、在程式碼庫裡植入 agent 看得懂也會遵循的模式。他認為這個方向是對的，但也提醒大家這不是什麼新問題。「我們一直都想搞清楚怎麼讓資淺工程師不出包，」他說，「只是以前那個資淺工程師是人，現在換成了一群全天候工作的笨蛋 agent。」

有趣的是，這個轉變正在讓一些曾經被業界嫌棄的做法重新翻紅。OpenCode 團隊過去就採用領域驅動設計（Domain-Driven Design），只是用得比較輕量。現在他們刻意加重了這套方法的實施力度，因為這種「無聊的企業級設計模式」對 agent 特別管用。嚴格的模組邊界、清楚的職責劃分、明確的介面契約，這些都是讓 agent 不會亂改東西的護欄。2000 年代流行的那些設計模式之所以後來被嫌棄，主要原因是太囉嗦、打字打到手痠。但現在打字的是 agent，人類可以享受模式帶來的安全性，卻不用承受手動輸入的痛苦。Raad 用一個簡潔的比喻總結了這個轉變：以前好的工程師不需要訓練輪，靠手感和經驗就能寫出乾淨的程式碼。但 agent 沒有手感，你必須把訓練輪裝回去。

品味是最後的差異化武器

品味是這場訪談裡反覆出現的關鍵詞。Raad 被問到怎麼看待「品味」這個概念時，沒有給出那種抽象的宣言，而是指出一個更根本的問題：你真的相信品質重要嗎？

業界現在瀰漫著一種論調：程式碼不需要多好，產品不需要多精緻，反正有些公司產品很爛照樣賺大錢。Raad 認為，這個念頭一旦進了腦子，你就不會再做出好產品了。因為品質是一種感染力，它會從一個地方蔓延到整間公司。你在某個角落開始偷懶，很快就會在每個角落都偷懶。而且 AI 正在加速這種腐化。產品爛掉的速度比以前快多了，大公司的產品如此，新創公司也不例外。一個一年前上線的產品，現在可能已經開始腐爛了。

OpenCode 早期的一個決定完美體現了這種「不理性」的品質追求。在所有競爭對手都用現成的終端機渲染套件拼湊出堪用的介面時，OpenCode 團隊決定自己從頭打造一套終端機渲染框架。這是任何技術團隊會告訴你「絕對不要做」的事情：不要造輪子。但他們是重度終端機工具使用者，用過 NeoVim，看過 HashiCorp 創辦人 Mitchell Hashimoto 在 Ghostty 上展示的可能性，知道終端機體驗可以多好。結果，OpenCode 早期跟 Claude Code 競爭時，很多使用者第一個提到的差異就是「OpenCode 用起來感覺不一樣」。那個不一樣不是因為底層的 AI 模型比較強，而是因為介面不閃爍、不跳動、不會讓人覺得這東西是拼湊出來的。Raad 自己也承認，他離自己設定的品質標準還很遠。他說自己還在學，還有很長的路要走。這種「我知道好的標準在哪裡，我知道自己還沒到」的自覺，本身就是品味的展現。

軟體工程師的終極職涯建議

訪談尾聲，Raad 給了一個出人意料的職涯建議。他沒有說「學最新的 AI 框架」或「趕快掌握 prompt engineering」，而是說：去深入了解一個產業。

軟體工程是一種可以套用到任何行業的技能。你可以只當一個很好的工程師，職涯也不會差。但如果你同時深入了解一個特定產業，不管是農業、醫療還是物流，你就會成為一種極其稀缺的人才。一個懂農業又會寫程式的人，全世界可能排得進前十名。那個產業裡的每一家公司都會搶著要你。而且軟體工程師有一個別人沒有的優勢：你不必被一個產業綁死。醫生很難轉行做農業，但工程師可以在醫療領域深耕十年，累積了足夠的產業知識後，如果覺得膩了，完全可以跳到另一個產業重新來過。技術能力帶得走，產業知識重新學就好。Raad 認為這是軟體工程師最被低估的職涯策略，不管 AI 怎麼發展，這個邏輯都不會過時。

我的觀察

Raad 在這場訪談裡最難能可貴的，不是他的觀點多深刻，而是他的位置和他說的話之間的張力。這個人做出了近八百萬人在用的 AI 程式碼工具，但他不賣你「AI 讓一切更好」的故事。他傳達的是一個更細膩、也更誠實的訊息：工具變強了，但人的判斷力沒有跟上，甚至在退步。

「消失的刺痛感」這個概念，我覺得是今年關於 AI 輔助開發最精準的比喻。它解釋了一個很多團隊隱約感覺到但說不清楚的現象：明明 AI 在幫忙，為什麼程式碼庫的品質反而在下降？不是因為 AI 寫的程式碼特別爛（其實跟普通工程師差不多），而是因為人類用來判斷「該不該接受這段程式碼」的直覺被消音了。我們把品質管控外包給了一個沒有品質意識的工具，然後困惑為什麼品質下降。

他在備忘錄裡寫的「我們並沒有變快，只是感覺變快」，應該貼在每一間正在導入 AI 工具的公司牆上。特別是在臺灣，很多公司正在經歷這個階段：主管看到國外的案例和數據，急著宣布「全面導入 AI 工具」，要求團隊每個月回報「AI 使用率」和「效率提升百分比」。但很少有人願意停下來問：我們真的做出了更好的產品嗎？還是只是出了更多東西？

Raad 的職涯建議也值得臺灣的工程師聽進去。在一個人人都在學 AI 框架和 prompt 技巧的時代，真正的差異化可能不在技術層面，而在你對某個產業有多深的理解。臺灣有半導體、有醫療器材、有精密機械，這些領域裡懂技術又懂產業的人才缺口比你想像的大。與其焦慮 AI 會不會取代你的工作，不如去找一個你真正有興趣深入了解的產業，然後讓你的技術能力和產業知識形成別人無法複製的組合。