軟體開發的寧靜革命：Vibe Coding 與自動化 MVP

軟體開發領域正在發生一場寧靜的革命，這與新的 JavaScript 框架毫無關係。重點在於誰——或者說什麼——在承擔繁重的工作。

想像這樣一個場景：你在候機。你有一個點子。當你落地時，你手機裡不只是記滿了筆記；你有一個完整部署的 MVP（最小可行產品），包含資料庫、身份驗證和前端介面，並且已經在一個公開的網址上運行。你沒有寫任何一行語法。你只是管理了整個流程。

這不是科幻小說。這就是人們開始稱之為「Vibe Coding」（氛圍編碼）的現象，它正在從根本上改變新創公司的經濟學。

大多數創辦人仍然被困在舊的循環中：點子 -> 招聘/寫程式 -> 除錯 -> 部署。這個循環太慢了。新的循環是這樣的：語境 (Context) -> AI 代理 (Agent) -> 驗證 (Verification)。

過去幾週，我一直在優化一套技術堆疊，旨在自動化開發過程中那些混亂的中間環節。它讓我能夠在平行的週期中同時運行十個潛在的 MVP。以下是具體的配置、工作流程，以及關於它在哪裡會崩潰的誠實真相。

「Vibe」技術堆疊 (The "Vibe" Stack)

要讓這套流程運作，你需要能夠互相溝通的工具。我們尋求的不是最複雜的企業級解決方案，而是速度與整合性。這是我的工具箱：

1. 框架：create-t3-turbo（一個基於 Turborepo 構建的 monorepo 設定，將前端和後端處理在同一個地方。包含 Next.js、tRPC、Tailwind 和 Prisma。非常適合 MVP）。
2. 大腦：Claude Code（充當你首席工程師的 CLI 工具）。
3. 專案管理：Linear（單一事實來源）。
4. 追蹤：GitHub Issues（與 Linear 同步）。
5. 基礎設施：Vercel（託管）+ Neon（Serverless Postgres）。

Vercel 和 Neon 都有很大方的免費額度，這意味著你的實驗成本實際上是零。

設定階段

在你寫下任何一行程式碼之前，你需要先接通這台機器的線路。以下是確切的設定過程：

1. 初始化專案

首先建立一個新的 create-t3-turbo 專案。這會給你一個準備好上線的 monorepo 結構，所有配置都已完成：

npx create-turbo@latest -e https://github.com/t3-oss/create-t3-turbo

這個指令會搭建一個完整的技術堆疊：前端使用 Next.js，型別安全 API 使用 tRPC，資料庫管理使用 Prisma，樣式使用 Tailwind CSS——全部都在一個 Turborepo monorepo 結構中。

2. 安裝 Claude Code

接下來，安裝 Claude Code，這是你的 AI 開發助理。請按照 code.claude.com 上的安裝指南操作。安裝完成後，你可以從專案目錄啟動它：

claude

3. 設定 GitHub Actions 整合

在 Claude Code CLI 內部，執行以下指令來安裝 GitHub Actions 整合：

/install-github-app

這個指令會設定 GitHub Actions 機器人，讓 Claude 能夠建立 Pull Requests (PR)、執行 CI/CD 工作流程，並與你的儲存庫互動。這個整合允許 Claude 透過自動化工作流程來執行程式碼變更，而不僅僅是提出建議。詳細設定說明請參閱 GitHub Actions 官方文件。

4. 連接 Linear 與 GitHub

當你將 Linear 連接到 GitHub 進行雙向 Issue 同步時，魔法就發生了。步驟如下：

1. 前往 Linear 的 GitHub 整合頁面
2. 點擊「Add Integration」並授權 Linear 存取你的 GitHub 帳號
3. 選擇你想要同步的儲存庫 (Repository)
4. 設定同步選項：
   • 雙向同步 (Bidirectional sync)：在 GitHub 建立的 Issue 會自動出現在 Linear 中，反之亦然
   • 狀態對應 (Status mapping)：將 Linear 的工作流狀態（Todo, In Progress, Done）對應到 GitHub Issue 的狀態
   • 優先級同步 (Priority sync)：保持兩個平台間的優先級同步
   • 自動連結 (Auto-linking)：使用 Issue ID 自動將分支 (Branch) 和 PR 連結到 Linear Issue

設定完成後，當你在 GitHub 建立 Issue 時，它會出現在 Linear 中。當你在 Linear 更新優先級或狀態時，變更也會反映在 GitHub 上。這創造了一個統一的工作流，讓你可以在任一平台管理任務。

5. 部署基礎設施

最後，部署到 Vercel 並搭配 Neon 資料庫：

• 將你的 GitHub 儲存庫連接到 Vercel
• 配置一個 Neon serverless Postgres 資料庫（有免費層級）
• 將資料庫連接字串 (connection string) 新增到你的 Vercel 環境變數中

部署完成後，你就擁有了一個從你的想法直通線上 URL 的持續整合 (CI) 管道。每一次合併到 main 分支都會自動部署到生產環境。

自動化工作流程

這就是傳統產品經理 (PM) 角色開始淡出的地方。

1. 語境會議 (The Context Session)

如果你有一個點子，不要打開 IDE。打開一個聊天視窗。跟 ChatGPT 或 Claude 對話，傾倒你原始的想法。讓 AI 挑戰你。在這個環節結束時，要求它生成一份 Markdown 格式的 PRD（產品需求文件）。

你得到的結果通常比大多數中階 PM 寫的還要好。它詳細、結構化且專業。

洞察：我相信專職的「產品經理」角色將是第一個被 AI 顛覆的。我們正在邁向一個由「產品設計師」或「全端創作者」主導的世界，他們掌控願景，而 AI 處理規格。

2. 交接 (The Handoff)

將那份 Markdown PRD 餵給你的本地端 Claude Code。這是關鍵的一步，AI 將需求轉化為可執行的工作項目。

在 Claude Code CLI 中，指示它解析 PRD 並生成 GitHub Issues。Claude Code 在底層使用 GitHub CLI (gh) 與你的儲存庫互動。過程如下：

1. 解析：Claude 分析 PRD 並將其分解為獨立、可執行的任務
2. 建立 Issue：對於每個任務，Claude 執行如下指令：

   gh issue create --title "Implement user authentication" \
     --body "Details from PRD..." \
     --label "feature" \
     --assignee "@me"
   

3. 分配元數據：Claude 會根據 PRD 中描述的複雜度，自動分配標籤（feature, bug, enhancement）、優先級，甚至預估時間
4. 依賴關係映射：如果設定了 GitHub Actions 整合，Claude 還可以建立 Issue 的依賴關係和里程碑

使用 gh CLI 的美妙之處在於它是可程式化的——Claude 可以在幾秒鐘內批量建立數十個 Issue，每個都有格式正確的 Markdown 描述、驗收標準和技術註釋。

突然間，你的 Linear 看板亮了起來。多虧了你之前設定的 Linear-GitHub 同步，你會看到 10 到 20 張票自動生成——標題正確，附帶詳細描述、優先級和狀態。原本 PM 需要數小時手動建立的整個待辦事項清單 (Backlog)，現在不到一分鐘就生成了。

3. 執行 (The Execution)

現在，你扮演工程經理 (EM) 的角色。你在 Issue 中標記 @claude 開始處理票務。Claude 在 GitHub Actions 中編寫程式碼，建立 Pull Request，並等待審查。

你按下合併 (Merge)。

Vercel 的 CI/CD 啟動。幾分鐘後，變更就上線了。

這一切的美妙之處在於它可以在你的手機上發生。你可以在計程車上或咖啡廳裡審查 PR 並管理看板。你不再是輸入通用的 React 樣板程式碼；你是在指揮一個高速運轉的施工團隊。

「最後一哩路」問題

如果你讀到這裡就停下來，你可能會以為 AI 已經解決了一切。並沒有。

雖然「Vibe Coding」很強大，但我們必須誠實面對它的局限性。AI 非常擅長處理「髒活」和「枯燥的工作」。它可以比任何人類都快地搭建資料庫架構、構建登入表單和設定 API 路由。

但它在處理產品的靈魂時會遇到困難。

把它想像成蓋房子。AI 是你的結構施工隊。他們可以用創紀錄的時間灌漿、立柱和封板。但他們是糟糕的室內設計師。他們不知道那個角落的燈光開關手感不對，或者廚房的動線會讓人們撞在一起。

在軟體中，這就是「最後一哩路」。那些讓使用者感到愉悅的互動、微妙的 UI 動畫、商業邏輯中的邊緣情況——這就是你，作為人類構建者，必須介入的地方。

如果你 100% 依賴 AI 來完成產品，你最終會得到一個技術上可行但在情感上空洞的軟體。它將缺乏那種區分偉大產品與平庸產品的「工藝感」。

實用建議

如果你今天想嘗試這個，這是我的建議：

• 從 PRD 開始：永遠不要要求 AI「直接寫程式」。程式碼的品質取決於 PRD 的品質。把你的精力花在完善需求文本上，而不是程式語法上。
• 信任但要驗證：AI 程式碼代理可能會產生依賴關係的幻覺或寫出不安全的邏輯。閱讀 diff（差異比對）。把 AI 當作一個有天賦但資淺的開發者。
• 擁抱數量：利用這種速度來測試更多點子。如果你能在一個週末而不是一個月內建立一個 MVP，你找到產品市場契合度 (PMF) 的機率就會呈指數級增長。

構建產品的障礙已經消失了。剩下的只有你的品味和你的堅持。