我當 User，Claude 當 PM — AI Agent 團隊重建部落格實戰
開場：六年沒更新的部落格，該動了
我的部落格 Ray’s Notes 是用 Hexo 3.9.0 建的，最後一次更新停在 2020 年。六年了，Hexo 的生態圈早就不是當年的模樣，每次想寫點東西都被過時的工具鏈勸退。終於下定決心要重建，但這次我不想自己寫 code — 我想試試讓 AI Agent 團隊來搞定這件事。
我當 Key User，負責提需求和最終驗收；Claude 當 PM 兼 Product Owner，負責需求分析、任務拆分、協調團隊。工程師、Code Reviewer、QC 全部交給 Teammate Agent。結果呢？一個早上就看 Agent 們自行表演，我只需要坐在旁邊喝咖啡偶爾點頭就好。
團隊組成：每個人都有明確的角色
先來看看這個 AI Agent 團隊長什麼樣子：
| 角色 | 負責人 | 職責 |
|---|---|---|
| Key User | 我（Ray） | 需求提出、最終 Approve |
| PM / Product Owner | Claude | 需求分析、自主提案、任務拆分、協調 |
| 工程師 | Teammate Agent | 開發實作 |
| Code Reviewer | Teammate Agent | PR 審查（規範/安全/效能/漏洞） |
| QC | Teammate Agent | 連結/版面/功能/跨瀏覽器測試 |
這個團隊有幾個特別的地方：
PM 不只是執行者，他會自主提出建議。 比如我只說「我要重建部落格」，Claude 就主動提出了三個技術方案的比較、建議視覺風格、規劃 12 個開發階段。他不是等我下指令才動，而是像一個真正的 PM 一樣主動思考。
團隊成員可以自行招募 Subagent 平行作業。 工程師覺得某個任務可以拆成三個獨立部分，他就直接派三個 Subagent 同時處理，不需要回頭問 PM。
所有成員都具備 OpenSpec 技能。 每位成員在動手之前，必須先讀完相關的 proposal、design、specs、tasks 文件，確保理解需求後才開始。
OpenSpec 開發流程：禁止跳過任何階段
我們採用 OpenSpec 的四階段流程，每個 change 都必須走完整個循環：
Explore（探索）→ Propose（提案）→ Apply（實作）→ Archive（歸檔）- Explore：調查問題、釐清需求、探索可行方案
- Propose：產出完整提案，包含 proposal.md、design.md、specs/、tasks.md
- Apply：工程師讀完 spec 才能動手寫 code
- Archive：歸檔已完成的 change，留下完整紀錄
嚴格規則：禁止跳過 Propose 直接寫 code，禁止未經 Explore 就提案。這聽起來有點官僚，但實際執行下來，它確保了每個決策都有跡可循。
以這次重建為例，PM 產出的 tasks.md 包含了 12 個 Phase、48 個任務，從專案初始化、佈局元件、內容遷移，一路到 CI/CD Pipeline 和上線前檢核。每個任務都標注了受影響的檔案範圍，工程師拿到就能直接開工。
實戰過程
技術選型：三個方案的正面對決
PM 主動提出了三個靜態網站框架的比較：
| 項目 | Astro | Next.js | 11ty |
|---|---|---|---|
| 學習曲線 | 中等 | 較高 | 低 |
| 建置速度 | 極快 | 中等 | 快 |
| JS Bundle | 預設零 JS | 較大 | 預設零 JS |
| 生態圈 | 成長中 | 龐大 | 小眾 |
| Island 模式 | 原生支援 | 需額外設定 | 不支援 |
| 適合場景 | 內容為主 | 互動為主 | 純靜態 |
PM 推薦 Astro，理由很明確：部落格是內容導向的網站，Astro 的 Island Architecture 讓頁面預設零 JS，只在需要互動的地方（搜尋、深色模式切換）載入 React 元件。建置速度快，而且對 Content Collections 的支援非常成熟。我同意了。
視覺設計：從 3 個到 10 個方案
這段過程很有趣。PM 一開始給了我 3 個視覺方案，我覺得不夠，要了 6 個。看完還是沒有特別滿意的，再要了 10 個。PM 用瀏覽器視覺化伴侶即時展示 mockup，我可以直接在瀏覽器裡看到每個方案的實際效果。
最後我選了第 H 個方案 —「奶油暖甜」風格。米色暖底搭配深棕文字，整體氛圍溫暖舒適。這個風格後來演化成現在你看到的這個部落格。某些設計決策還是需要人類的審美介入，AI 生成的方案品質都不錯，但「哪個最對味」這件事，還是得自己來。
平行開發：PM 同時指揮多位工程師
12 個 Phase 的開發過程是整個專案最精彩的部分。PM 會根據任務之間的依賴關係，同時派 2-3 位工程師平行作業：
- Phase 1（專案初始化）完成後，立刻同時啟動 Phase 2（佈局元件）和 Phase 3（內容遷移）
- Phase 4（頁面路由）、Phase 5（文章頁功能）、Phase 6（深色模式）三位工程師同時開工
- PM 在過程中發現
@astrojs/sitemap的相容性問題，直接自己修復，沒有等工程師回報
每完成一個 Phase，PM 就會向我回報進度，告訴我目前完成了什麼、下一步要做什麼、有沒有遇到問題。整個流程就像在看一個真正的開發團隊運作。
遇到的問題與解決
過程不是完全順風順水，遇到了幾個典型的技術問題：
Sitemap 套件不相容。 @astrojs/sitemap 3.7.1 跟 Astro 4.x 有版本衝突，build 時直接報錯。PM 快速診斷後降版至 3.2.1，問題解決。
文章圖片路徑斷裂。 從 Hexo 遷移過來的文章，圖片路徑格式完全不同。工程師從 Hexo source 目錄複製了 14 張圖片到 public/images/，並逐一更新文章內的圖片路徑。
Content Collection 的 slug 保留字衝突。 Astro 的 Content Collection 內建 slug 欄位，我們自定義的 slug 跟它撞名了。解法是改用 postSlug 作為欄位名稱，避開保留字。
成果數據
| 項目 | 數據 |
|---|---|
| 文章遷移 | 27 篇 |
| 總頁面數 | 69 頁 |
| 圖片遷移 | 14 張 |
| Build 時間 | 3.52 秒 |
| Unit Tests | 9 passed |
| E2E Tests | 5 passed |
| 功能 | 搜尋/深色模式/留言/RSS/SEO/CI-CD |
| 技術棧 | Astro 4.x + Tailwind CSS + TypeScript + React Island |
27 篇文章、69 頁的部落格，build 時間只要 3.52 秒。從需求討論到主體開發完成，一個早上搞定。
反思：AI Agent 協作的真實感受
這些地方讓我驚豔
開發速度驚人。 一個早上完成主體開發，這在傳統團隊中大概需要一到兩週。不是因為 AI 寫 code 比人快多少，而是它不需要休息、不需要開會、不需要溝通成本。
PM 的自主性很強。 Claude 不只是被動接收指令，他會主動發現問題、提出解決方案、甚至自己動手修。這是我沒預期到的。
平行作業大幅提升效率。 人類團隊很難真正做到三個工程師同時開工且互不干擾，但 AI Agent 可以。每個 Agent 專注在自己的任務上，不會被 Slack 訊息打斷。
OpenSpec 流程確保品質和可追溯性。 每個決策都有文件記錄，出問題時可以回頭查看當初為什麼這樣設計。
這些地方需要注意
Key User 需要有足夠的技術背景。 AI 產出的程式碼和架構決策，你得有能力判斷對不對。如果完全不懂技術，可能會被帶偏而不自知。
設計決策需要人類介入。 視覺風格、用戶體驗這些帶有主觀判斷的部分，AI 可以給你很多選項，但最終決定還是得靠人。
Agent 之間偶爾會有檔案衝突。 多個 Agent 同時修改同一個檔案時，會產生 merge conflict。PM 需要即時協調，確保不會互相覆蓋。
結語
用我當時的一句感想來總結：「笑著笑著就哭了，是不是快失業了。」
但認真想想，AI Agent 不是取代工程師，而是讓工程師變成「指揮官」。你不再需要親手寫每一行 code，但你需要有能力定義需求、評估方案、驗收品質。角色從「寫程式的人」變成了「指揮程式被寫出來的人」。
未來我會繼續用這個模式開發新功能、寫更多文章。事實上，你正在讀的這篇文章，也是用同樣的方式產出的。