AI 商業觀點：Vibe Coding 成本結構

．作者：Jollen
．日期：July 23, 2026 at 8:00 AM

AI 軟體開發的成本，不能只看模型單價。

延續前文 (AI 商業觀點：Vibe Coding 存在成本不對稱問題)[https://www.jollen.org/blog/2026/07/ai-business-vibe-coding.html]：AI 模型價格，以每百萬的輸入與輸出 token 數來計價格。

Agentic Coding 隱形成本

Token 費用包含隱形的「實際開發成本」，開發成本來自於「開發活動」，例如：任務拆解、上下文讀取、程式生成、錯誤修補、測試驗證與回歸檢查等；這些活動會在不同開發模式中產生不同的 token 消耗。

因此，討論 AI 開發成本時，應先區分開發方式。一次生成、逐步 Patch、Agentic Coding、Multi-Agent 與 Loop Engineering，都有不同的成本結構。

相關研究指出，Agentic Coding 任務的 token 使用高度變動。同一任務的不同執行結果，總 token 可相差到 30 倍。高 token 使用量也未必帶來更高準確率，準確率常在中等成本區間達到穩定。

成本不只來自模型輸出，也來自 AI 如何反覆讀取上下文與修補錯誤。

Agentic Coding

Agentic Coding 讓 AI 自主讀取檔案、分析專案結構（例如 Claude Code 的 /plan）後，再進行修改、測試、與修補。這個模式的優點是能處理複雜任務，與進行長任務。

但風險是「AI 可能會過度探索」，因而消耗 token 成本；也有相關研究顯示，Agentic Coding 的token 消耗變數多，長期呈現高度變動，「不易管理預算」。

在 Claude Code 中，Plan Mode 是典型工具。Plan Mode 會讓 Claude 先閱讀專案、理解檔案關係、整理修改步驟，再進入實作。常見操作方式包含使用 /plan 指令，或在 prompt 輸入框中按兩次 Shift+Tab 切換模式。也可以用 claude --permission-mode plan 啟動唯讀規劃 session。

Plan Mode 的價值在於降低盲目修改。它讓 AI 先形成任務地圖，接著再進入 patch。對大型 codebase、陌生專案、跨檔案重構與 release 修補而言，這個階段很重要。

可採用的操作流程如下。

1. 進入 Plan Mode
2. 要求 AI 讀取專案結構
3. 要求 AI 列出修改範圍
4. 要求 AI 標示風險檔案
5. 人工確認計畫
6. 切回執行模式
7. 進行小範圍 patch
8. 執行 build 與 test
9. 依 log 進行 repair

這個流程的重點在於「先界定修改邊界」。修改邊界愈清楚，AI 讀取的上下文愈少，後續修補成本也會下降。

上述提到，Agentic Coding 的最大風險是「過度探索」。過度探索代表 AI 讀取過多無關檔案、嘗試多條解法、反覆重寫架構，最後造成 input token 與 tool call 成本升高。

研究也指出，agentic tasks 的 token 消耗可達 code reasoning 的千倍量級，且 input tokens 是主要成本來源。

因此，Agentic Coding 應搭配三項限制。

限制讀檔範圍
限制修改範圍
限制 repair 輪數

在實務上，Agentic Coding 適合處理跨檔案修補、未知錯誤定位、release QA 與架構 review。小型文案、單一畫面、簡單 bug，使用逐步 patch 通常更容易控制成本。

Multi-agent Coding

再來是近期流行的 Multi-agent 模式。這個模式將 AI 打造成一支軟體開發團隊，讓 planner、coder、reviewer、tester 分工；多個 AI agents 之間可以併行或 Pipeline 運作。

在這種模式中，planner 負責拆解任務，coder 負責產生修改，reviewer 負責檢查問題，tester 負責讀取測試結果。整體流程接近軟體團隊的分工。

此模式除了同樣成本高之外，還有一「Input token 極高」與「Input token 數量高度變動」的風險。筆者觀察網路上的討論發現，不少採用 multi-agent 模式的專案，可能 2~3 天「無腦跑 AI」下來，就要消費至少 $2,000 的 token 成本。

Multi-agent 的成本風險極高。每個 AI agent 都要讀取任務詞示詞與上下文

當 reviewer 多次要求 coder 修改時，agents 之間會形成反覆協調，因為每個 agent 都還要讀取前一個 agent 的結果。簡而言之，Multi-agent 的 token 成本來自三個來源：

每個 agent 的上下文讀取
agents 之間的訊息傳遞
review 與 repair 的循環

相關研究指出，在 multi-agent software engineering 中，Code Review 階段會消耗最大比例 tokens。因此，Reviewer Agent 是潛在的成本地雷。

Reviewer Agent 的任務通常需要讀取完整 patch、比對需求、分析風險、提出修改建議。當 review 規則過寬，AI 會產生大量建議。這些建議再交給 coder 修補，又會形成下一輪 review。

綜以上述，此模式目前較適合於：

大型產品規劃
安全審查
架構 review
高風險 release
安全漏洞偵測
互打模式的軟體測試

總結來說，Multi-agent 模式就像是一支軟體開發團隊，其 token 成本，還會因為 agents 之間「反覆協調溝通」而放大。相關研究也指出：Multi-agent software engineering 的 Code Review 階段會消耗最大比例 tokens；因此，此模式也比較不適合小 patch 式的修補。

Skills

Skills 是 Multi-agent 模式的大腦。

更白話來說，AI agent 的基本的形式是「一份 Skill 檔案」，這份 Skill 檔案（Markdown 格式）是給 LLM 的提示詞，讓 LLM 根據提示詞來運作。

例如，你可以撰寫一份「短影音剪輯 Skill」，內容是告訴 LLM 如何使用 ffmpeg 來編輯影片；這份 Skill 就是 LLM 的專業知識。多份 Skills 整合在一起，就變成 Multi-agent 平台。

在 AI 開發流程中，Skill 代表一組可重複使用的工作方法，也包含 validators。它通常包含任務說明、輸入格式、輸出格式、檢查規則、工具使用方式與失敗處理原則。

在 Multi-agent 模式中，每個 agent 都需要自己的 Skill。Planner 需要 Planning Skill，Coder 需要 Coding Skill，Reviewer 需要 Review Skill，Tester 需要 Log-analysis Skill。

因此，Skill 的品質會直接影響 token 成本。模糊的 Skill 會產生模糊的行動。模糊的行動會帶來更多 review 與 repair。清楚的 Skill 會讓 agent 更容易收斂。

Loop Engineering

近期討論熱絡的 Loop Engineering，是 Multi-agent 開發的延伸。

傳統軟體工程看重測試後回饋。Tester 將 log 訊息回報給 developer，developer 根據 log 修正下一個版本。Log 訊息通常是高度結構化的文件，例如 build log、test report、coverage report、crash report 與 screenshot report。

Loop Engineering 延續這個精神，讓 Multi-agent 開發也形成這種「循環」。這個循環包含計畫、修改、測試、觀察、修補與記錄。

因此，Loop Engineering 的精神，是讓 Multi-agent 間形成一個開發循環：

Plan
→ Patch
→ Build
→ Test
→ Observe
→ Repair
→ Review
→ Record
→ 回到 Plan

在這個流程中，Observe 是關鍵。Observe 代表 AI 讀取外部結果，例如 compiler error、unit test failure、screenshot diff、App Store metadata validator 與 CI log。

當 Observe 結果夠結構化，AI 就能進行更準確的 repair。當 Observe 結果混亂，AI 就會用猜測方式修補，token 成本也會升高。

Loop Engineering 並非新技術，它比較接近傳統軟體工程中的 Telemetry Pipeline Engineering。

Loop Engineering 的最終目的，是降低 Agentic Coding 的不確定性，進而「降低開發成本」。

Also read

Tags: vibe, agentic, skills, claude