Vibe Coding 的隱藏帳單：為什麼 AI 寫的 1200 行比你手寫的 200 行更貴

2026 年，AI 寫了全球 41% 的程式碼。

92% 的美國開發者每天都在用 AI coding tools。如果你還沒用，你大概已經被同事用「你怎麼還在手打」的眼神看過了。Andrej Karpathy 去年定義了 vibe coding -- 「完全交給 AI，擁抱指數成長，忘掉 code 的存在」。一年後，這已經是主流開發方式。

但有一個數字沒有人在算：這些程式碼的持有成本是多少？

大家都在談 Time-to-Prototype。「一個下午就做出來了！」「三天 MVP！」「Demo Day 驚艷全場！」LinkedIn 上每天都有人在秀 AI 幫他從零到一的速度。

沒有人在談 Total Cost of Ownership。

而那張帳單，已經悄悄到了。

先破一個幻覺：AI 讓你更快了嗎？

在談帳單之前，先說一個反直覺的事實。

METR（Model Evaluation & Threat Research）在 2025 年做了一項隨機對照實驗：讓資深工程師在自己熟悉的成熟 codebase 上用 AI 工具做維護工作。結果？平均慢了 19%。

不是新手。不是不熟的 codebase。是在自己的地盤上，用 AI 反而變慢。

2025 Stack Overflow Developer Survey 也指出：近半數開發者表示，debug AI 產生的 code 比自己從頭寫還花時間。

CIO.com 的 〈The AI productivity trap〉 把這個現象叫做「生產力幻覺」-- 你覺得自己做了很多事，因為螢幕上確實出現了很多 code。但那些 code 需要被理解、被驗證、被整合進既有架構，而這些隱藏工時往往比省下的時間更長。

Output 不等於 outcome。生產不等於生產力。

帶著這個認知，來看三張帳單。

帳單一：認知債務（Cognitive Debt）

技術債這個詞大家都聽膩了。但 AI 時代帶來了一種新型態的債務，叫做認知債務——程式碼存在，能跑，但團隊裡沒有任何一個人完全理解它為什麼這樣寫。

Margaret-Anne Storey 這樣描述：「Technical debt lives in the codebase. Cognitive debt lives in the developer's head.」當系統演化速度快於團隊更新心智模型的速度，認知債務就開始累積。表徵是 review 摩擦力上升、onboarding 變慢、團隊疲勞——儘管系統表面上仍「運作」。

傳統的技術債是「我們知道這段寫得爛，但趕不及改」。認知債務更陰險：「我們不確定這段在做什麼，但它能動，所以不要碰。」

這種場景你一定見過：有人用 AI 花了一個下午，生出了超過一千行的 prototype。速度確實驚人——需求丟進去，code 就噴出來，整個過程行雲流水。但問題是：這些 code 沒有一行是那個人從頭構思的。AI 生成、AI 補完、AI 重構。當這個人換專案、離開團隊、或單純三個月後回來看——那一千多行就變成了黑箱。

不是寫得差。是沒有人知道「為什麼這樣寫」。

CodeRabbit 的研究分析了 470 個 GitHub PR，數據更直接：AI co-authored code 出現 major issues 的機率是人寫的 1.7 倍，安全漏洞率更高達 2.74 倍。

這不是在說 AI 寫的 code 品質差。而是在說：沒有人類深度理解的 code，維護成本是指數級的。

The New Stack 在討論 agentic engineering 時特別點名：當 AI 成為主要的 code 生產者，人類的角色從「寫 code 的人」變成「讀 code 的人」。但諷刺的是，AI 生成的 code 往往比人寫的更難讀——因為它沒有意圖、沒有設計脈絡、沒有「為什麼選 A 不選 B」的決策記錄。

你的 codebase 裡有多少行是這種狀態？能跑，但沒人敢碰的？

帳單二：範圍蠕變加速器

AI 讓加功能變得太容易了。

以前，PM 說「加一個報表頁面」，工程師會在心裡默默算工時，然後用「排不進這個 sprint」來優雅拒絕。這是一種健康的摩擦力——開發成本夠高，自然會逼團隊做取捨。

現在呢？「讓 AI 加一下嘛，五分鐘的事。」

你一定看過這種演化軌跡：最初的需求是「一個簡單的數據看板」。合理、清晰、五個人用。

然後事情開始膨脹。「既然有數據了，不如加個趨勢分析？」好。「分析完要有行動，加個任務追蹤。」嗯...好吧。「任務多了要有流程，加個狀態管理。」等等。「流程要有紀錄，加個日報週報。」呃。「報表要有洞察，加個 AI 助手。」...

每一步都合理。每一步都只要「讓 AI 加一下」。回過頭來，一個原本只需要幾個圖表的看板，已經膨脹成一個全功能平台。使用者還是那五個人，但系統複雜度已經翻了十倍。

這不是任何人的錯，這是系統性問題。 AI 是放大器——它等比放大你的生產力，也等比放大你的過度設計。工程師天生想多蓋一點，PM 天生想多要一點，老闆覺得「既然都做了不如再加一個」。以前，開發成本是天然的煞車。現在 AI 把煞車拆了，scope creep 就像下坡失控——每一步都合理，但回頭已經回不去了。

每多一個功能，維護表面積就多一塊。每多一塊表面積，就多一個未來某天會壞掉但沒人記得它存在的東西。

AI 不會幫你說「不」。它只會幫你說「好，還要什麼？」

帳單三：殭屍 Prototype

這是最貴的一張帳單。

殭屍 Prototype 的定義：介於「夠好能用」和「不夠好能棄」之間的半成品。

它永遠佔著路線圖上的一個位置。你已經 demo 過了，老闆覺得不錯了，甚至可能已經有兩三個人在「試用」了。但誠實問自己：

• 做過需求驗證嗎？
• 跑過使用數據嗎？
• 有人真的每天在用嗎？
• 如果明天砍掉，有人會抱怨嗎？

殭屍 Prototype 之所以危險，是因為它有一種「已經投入了沉沒成本」的心理慣性。「AI 都幫我們做好了，不用可惜」——但事實上，AI 做這些東西的成本接近零，你持有它們的成本才是真的。

每一個殭屍 Prototype 都在消耗：

• 注意力：它出現在每次路線圖討論裡，即使沒人打算做下去。
• 信譽：你 demo 過了，別人會問「那個後來怎麼樣了？」
• 機會成本：它擋住了本來可以用同一個 slot 做的、真正被驗證過的需求。

而且殭屍 Prototype 會繁殖。因為生產成本低，團隊很容易同時養著五六個半成品，每個都「先放著之後再看」。結果真正有價值的那個也被淹沒在殭屍群裡，拿不到足夠的資源。

解方：200 行原則

我不是在說別用 AI 寫 code。那是反智。

我在說的是：在讓 AI 狂飆之前，先問一個問題。

「這個需求，用 200 行能不能解決 80% 的問題？」

• 能 → 手寫那 200 行。你會完全理解每一行。你會在寫的過程中自然地做取捨。你會因為「寫起來很煩」而砍掉不重要的功能。這些都是好事。
• 不能 → 才考慮讓 AI 全量生產。但此時你已經想清楚了核心需求是什麼，AI 是在幫你加速，不是在幫你發散。

200 行不是教條。它是一個思考框架：

生產成本低不代表持有成本低。 寫 code 是一次性的，讀 code、改 code、除 bug、教新人看懂這段 code——這些是持續性的。AI 幫你省掉了第一項，但後面四項一毛都沒省。

這個原則的核心其實很老派：你寫的每一行 code 都是負債，不是資產。 只有被使用者驗證過、持續產生價值的 code 才是資產。其餘的都是等著爆炸的負債。

AI 只是讓你欠債的速度變快了。

結語

下次打開 Cursor 或 Copilot 之前，花 30 秒做一件事：

算一下你手上有幾個 AI 生的殭屍 Prototype。

那些 demo 過但沒上線的。那些「先放著之後再說」的。那些你已經不記得 code 在幹嘛但還在 repo 裡的。

然後問自己：如果這些東西明天全部消失，有人會發現嗎？

如果答案是「不會」，恭喜你，你剛找到了隱藏帳單的來源。

Vibe coding 很爽。但爽完記得看帳單。

引用來源：METR 2025 RCT、2025 Stack Overflow Developer Survey、CodeRabbit State of AI vs Human Code Generation、CIO.com — The AI Productivity Trap、Andrej Karpathy — Vibe Coding 定義、The New Stack — From Vibes to Engineering、Margaret-Anne Storey — Cognitive Debt