AI Coding：從「Vibe Coding」到專業開發

前言

本篇文章詳細整理了預計在 Tech-Verse 2025 發表的內容。根據我個人的實戰經驗，會分享 AI coding 現場獲得的洞見與手法。

在推動 AI coding 的過程中，我深受 LINE Yahoo 的價值「Lean & Mean Teams（少數精鋭團隊）」啟發。少人數開發團隊與 AI agent 緊密協作，目標是在縮短開發時程的同時，也守住品質，這正是我自己的 AI coding 策略核心。以高技術力為基礎，著重設計與實作高可靠性的 AI pipeline。

不過，幾行 prompt 就能跑出 prototype 的 “Vibe Coding” 甜蜜誘惑，往往會帶來技術債與 bug。本篇會介紹 8 個我在實戰中體會的實用做法，協助大家避開「快但亂」的陷阱。透過 AI-friendly 的任務細分、context 管理、超短測試迴圈等技巧，讓 AI 從「難以預測的實習生」昇華為「有紀律的隊友」，打造又快又乾淨、可長期維護的軟體。

什麼是 Vibe Coding？

請想像你是開發者 Tine，接到要做一個專案管理 app 的需求。你對 ChatGPT（或你愛用的 AI）下指令：「請用 React 寫一個專案管理 app」，一小時內 prototype 就出來了，AI 彷彿全自動幫你實作。這就是「Vibe Coding」——靠靈感衝刺、快速推進開發，卻沒細查 AI 產生的 code 就直接往下走的開發風格。

但事情不一定都這麼順利。根據 Simon Willison 的定義，「Vibe Coding」指的是用 LLM 產生軟體時，對產出內容缺乏檢查。結果就是 codebase 結構鬆散，東補西補的實作越來越多。當客戶要求加功能時，常常不知道該從哪裡下手，修 bug 也會卡關。

「Vibe Coding」並非全然有害，有時能在極短時間做出 prototype，效率大幅提升。Steve Yegge 在「Revenge of the Junior Developer」中甚至主張 vibe coding「比傳統寫 code 快 5 倍」，隨著 coding agent 等工具出現，這種風格還會更普及[1]。但風險也很真實。CSET（2024 年 11 月）報告指出，AI 產生的 code 有近半數含有 bug 或資安漏洞。只顧速度、基礎沒打好，很可能埋下安全隱患。Addy Osmani 也在「A Field Guide to Responsible AI-Assisted Development」強調「沒有品質，快也沒意義」，呼籲大家別把 vibe coding 當作低品質的藉口[2]。

那麼，要怎麼兼顧速度與品質？答案就在「AI 專業開發」上。

AI 專業開發

接下來登場的是開發者 Tan。Tan 不像 Tine 那樣急躁，而是規劃好架構，像 Scrum Master 一樣切分 sprint。兩週後，他完成了一個擴充與維護都很容易的穩健產品。雖然一開始比較慢，但他相信有價值的東西就該花時間打底。

AI 專業開發和「Vibe Coding」有什麼差別？重點不是「會不會用 AI」，而是「能不能控管好 AI」。請記住我歸納的兩大核心心態：

• Trust the Process（相信流程）：AI 在明確的流程裡才能發揮最大戰力。不是讓 AI 隨便發揮，而是要給它「地圖」。
• AI as Teammate（AI 是隊友）：AI 不是你的替身，而是你的同事。像帶隊友一樣，持續評估、調整 AI 的 output，一起前進。

這種想法也獲得 Anthropic CPO Mike Krieger 的支持。他認為未來開發者會變成「AI orchestrator」——負責協調 AI、設計系統、確保品質。在 Anthropic，他們把 PM 和 AI 研究員配對，效率提升 10 倍，人與 AI 當同事合作的威力就此顯現[3]。

下面這張圖，就是 AI 成為隊友的樣子：

圖中你（Product Owner）負責指方向，AI 幫忙規格、調查、寫 code。重點是 feedback loop ——你和 AI 一起評估、調整，真正落實「AI as Teammate」精神。

8 個實戰做法

有了正確心態，接下來要介紹從「Vibe Coding」進化到 AI 專業開發的 8 個實戰做法，並依軟體開發常見 4 階段（Preparation、Planning、Development、Troubleshooting）分類說明。

Preparation（事前準備）

準備階段就像蓋房子的地基，基礎不穩一切都會倒。先從兩個做法開始。

Practice 1: 多 AI 工具協作

別只靠單一 AI，要建立每個 AI 各司其職的 pipeline。例如：

• Reasoning AI：寫需求、設計、實作指南
• Internet Search AI：搜尋框架新知、社群經驗
• Coding AI Agent：專心寫 code

把一個 AI 的 output 當作下一個 AI 的 input，確保品質與一致性。團隊合作比單打獨鬥更強。Steve Yegge 也預測「agent clusters」（AI agent 集群）、「agent fleets」（AI agent 艦隊）會成為主流[1]。

Practice 2: 詳細需求準備

需求就是 AI 的導航圖，地圖模糊 AI 就會亂走、產生一堆 bug。把 AI 當 brainstorm 夥伴，像同事一樣對談，挖出初步需求的盲點與新觀點。這部分未來會寫專文深入介紹。Addy Osmani 也強調，AI 應該輔助實作，基礎架構還是要由人類決定，需求要定義清楚[2]。

這階段心態是「Preparation is the foundation of success（準備是成功的基礎）」。別急，組好隊，明確定義你要做什麼。

Planning（計畫）

規劃階段就是把「要做什麼」具體化，對應 Scrum 的 sprint planning。這裡介紹兩個做法。

Practice 3: AI-friendly 任務切分

AI 最適合處理小而獨立的任務。切分時記得「AI-friendly tasks」原則：

• 每個任務 100～200 行以內
• 輸入／輸出明確
• 盡量少依賴其他任務
• 有驗證用 test case

把任務清單和實作計畫放進 repo，讓 Coding Agent 隨時掌握 context。Steve Yegge 也提醒，太大的任務會讓 agent「撞牆」（卡關）[1]。

Practice 4: 制定 Implementation Rule

幫 AI 做一份「內部手冊」：Implementation Rule。定義 coding style、推薦 pattern、workflow。有明確規則，AI 才不會亂猜，可以專心 business logic。Addy Osmani 也建議標準化，AI 產生的 code 進 repo 前一定要整理、調整[2]。心態是「Structure enables creativity（有結構才有創意）」，好架構不是束縛，而是助力。

Development（開發）

Development 是你和 AI 把想法變成實體的階段，這裡有兩個重要做法。

Practice 5: Edit-Test 迴圈

Edit-Test 迴圈是和 AI 合作最有效率的方式。每一輪 15～30 分鐘：

1. 決定一個小目標（15～30 分鐘）
2. 先寫這個目標的失敗測試
3. 請 AI 實作通過測試的 code
4. AI 自動跑測試
5. 失敗就請 AI 分析修正，成功則人工 review 後 commit

Addy Osmani 推薦 AI code 要徹底測試[2]，Mike Krieger 也分享在 Anthropic 用 AI 互審 code，人只做驗收測試的案例[3]。

圖示展現短迴圈控管進度。心態是「Small iterations（小步快跑）、continuous feedback（持續回饋）」。別讓 AI 一次背太多，一步一步來。

Practice 6: Context 管理

Context 就是 AI 的「記憶」。太長 AI 會「混亂」失去一致性。管理方式：

• 用 @ 加入檔案
• 對話超過 50～100 則就開新 chat
• 常同步 codebase
• Git commit 當 checkpoint
• 每次 session 結束寫小結

Troubleshooting（排解問題）

AI 不是萬能，遇到卡關時別慌，照這兩個做法來。

Practice 7: Problem Report System

AI 解不開時，請它產生 Problem Report，內容包含狀態、錯誤訊息、已嘗試的解法。再交給另一個 Search AI，獲得新思路。Addy Osmani 也建議反覆利用 AI，必要時要有自己動手寫的彈性[2]。

Practice 8: Context Reset 策略

AI 太亂時就要「重啟」。重啟是 AI 走偏時的緊急剎車。判斷點包括對話超過 100 則、hallucination（AI 胡亂產生錯誤資訊）變多、陷入無限迴圈。有效 reset 方法：把進度整理成 Problem Report，用乾淨 context 重新開始。

這裡的心態是「Systematic beats random（有系統比亂槍打鳥強）」。不要隨便亂試，要記錄、分析、討論、用結構化方法解決。

Trust The Process

請看這張「Trust the Process」全流程圖，從 Preparation 到 Troubleshooting 的完整架構都在裡面。

如圖所示，重點不是 AI 為中心，而是「流程」為中心。AI 只是流程中的一個執行工具。Context 會被保存與重用，確保 AI 隨時有足夠資訊。Mike Krieger 也指出，Anthropic 有 9～9.5 成 code 都靠 AI 產生，真正瓶頸反而變成功能決策與 merge queue，顯示流程再設計的重要性[3]。

結語

軟體開發已經進入新時代。AI 不再只是被動工具，而是和我們一起寫每一行 code 的夥伴。是時候回顧一下，我們過去是怎麼協作的。

組開發團隊時，沒人會只把大家湊在一起說「你們去做點酷的吧」。一定會適才適所：UI 交給前端，API 交給後端，基礎建設給 DevOps。明確定義每個人的 input/output，設計師交 mock 給前端，前端根據 API spec 給後端。最重要的是，每個成員的 output 一定會及早被 review。不論是 code review、daily standup、sprint demo，沒有人可以「完全自由發揮」不被回饋。

和 AI 合作也一樣。AI 不是萬能解題機，要像帶新手工程師一樣細心給步驟，像審同事 code 一樣調整每個 AI 的產出。給「AI 團隊」每位成員明確職責與 input/output，成果都要嚴格把關才進下一步。只要方法正確，AI 在專長領域會比人類更快、更高品質。每個「AI 成員」都能發揮作用，整個專案產出也會大幅提升。

為了有效協作，請記住這兩大心態：Trust the Process 與 AI as Teammate。相信流程，願意花時間規劃、測試、持續改善。把 AI 當真隊友，分享目標、給回饋、一起解決問題。

你能否用 AI 成功，關鍵不是你自己 code 寫得多強，而是你管理團隊與流程的能力。試著實踐上面8 個實戰做法，你不只寫 code 速度會變快，還會發現自己能更深入理解問題、有效解決挑戰。Steve Yegge 說過：「AI 不需要證明比你聰明，你要讓 AI 幫你變更聰明」[1]。他也預測，未來開發者會往「agent fleets（AI 艦隊）」管理者轉型，沒跟上的人會被淘汰。特別是，擁抱 AI 的開發者已經大幅領先，排斥 AI 的開發者很可能會被時代拋下（Sourcegraph Blog）。你準備好成為 AI orchestrator，協調整個 AI 生態系了嗎？

就從今天開始吧！和 AI 的旅程和帶人一樣，需要規劃、協作、還有耐心。祝大家 coding 順利！

參考資料

[1] Steve Yegge. "Revenge of the Junior Developer". Sourcegraph Blog. https://sourcegraph.com/blog/revenge-of-the-junior-developer
[2] Addy Osmani. "A Field Guide to Responsible AI-Assisted Development". Addy Osmani Blog. https://addyo.substack.com/p/vibe-coding-is-not-an-excuse-for
[3] Mike Krieger. "Interview with Mike Krieger". Video. https://www.youtube.com/watch?v=DKrBGOFs0GY