用 Paperclip 打造 AI 虛擬公司

我花了一週時間，用 Paperclip 這個 AI Agent 協作平台組了一間虛擬公司。公司裡有 CEO、PM、設計師、前端工程師、QA 測試員，全部都是 AI agent。目標是自動化生產 Astro 網站模板，上架販售。

結果呢？開發流程改了三次，CEO 一直在閒置，agent 之間的銜接靠人工催，最後我索性繞過 CEO 自己下指令。這篇記錄整個過程中踩過的坑，以及 Paperclip 適合拿來做什麼。

Paperclip 是什麼

Paperclip 是一個 AI agent 協作平台，可以把它想成一個專門給 AI 用的專案管理系統。你在上面建立一間「公司」，雇用不同角色的 agent（每個 agent 背後是 Claude、GPT 等大型語言模型），然後透過 issue 系統指派任務、追蹤進度。

核心概念是 heartbeat——每個 agent 會定期「醒來」，檢查自己有沒有被指派的任務，做完之後更新狀態，再把工作交給下一個 agent。整個過程用自然語言操作，不需要寫程式或操作 UI，直接在 Claude Code 裡面用自然語言描述需求，它就會幫我建立 issue。

我的公司叫 Codotx，賣日式極簡風格的 Astro 網站模板。團隊編制是這樣的：

• CEO：負責調度所有 agent，確保沒人閒著
• PM：研究參考網站，截圖、寫分析報告
• 設計師：根據 PM 的研究產出 Design System
• 前端工程師：照著截圖和 Design System 建構模板
• QA 測試員：截圖比對，用六維評分系統決定過關或退回
• Founding Engineer：部署到 GitHub Pages、npm、Lemon Squeezy

聽起來很完整，對吧？實際跑起來完全不是這回事。

第一個坑：CEO 是個擺設

我原本的設計是讓 CEO agent 統管全局。它每次 heartbeat 醒來時，應該要檢查所有 agent 的狀態，發現誰閒著就指派任務，確保流水線不停。

實際情況是 CEO 經常進入閒置狀態，不會主動去檢查其他 agent 有沒有事做。就算我在 HEARTBEAT.md 裡寫了「你不准在有 agent 閒置的情況下退出」，它還是會做完自己手上的事就停下來。

更麻煩的是權限問題。CEO 底下的 agent 沒有 assign issue 的權限，也就是說 PM 做完研究之後，沒辦法自己把任務轉給設計師。我得手動進資料庫幫每個 agent 加上 tasks:assign 權限才解決。

後來我的做法是繞過 CEO，直接在需要推進的時候手動觸發對應的 agent。CEO 這個角色在目前的架構下，比較像是一個理想化的設計——如果 agent 的自主性和可靠性更高，它或許能發揮作用，但現階段還不到那個程度。

第二個坑：瀑布式流程太慢

一開始我設計的是標準瀑布式流程：PM 做完所有頁面的研究 → 設計師做完所有頁面的線框稿 → 前端工程師一頁一頁建構。

問題是每個階段都得等上一個階段全部完成。PM 研究一個有五個頁面的網站，可能要花不少時間。設計師等 PM 做完才開始動工。前端工程師等設計師做完才能開工。一個主題從開始到完成，中間大量時間浪費在等待上。

我把流程改成敏捷式：設計師做完一頁的線框稿，就立刻建立一張 issue 給前端工程師。前端工程師建構第一頁的同時，設計師在做第二頁。QA 測試第一頁的時候，前端工程師在建構第二頁。多個角色平行推進。

這個改動讓整體速度快了不少，但帶來了新的問題——設計師產出的線框稿品質不穩定，前端工程師照著文字描述做出來的東西，跟參考網站差距很大。

第三個坑：線框稿是多餘的環節

我原本讓設計師寫文字版的線框稿，描述每個區塊的佈局、內容、配色。前端工程師再根據這些文字描述去建構頁面。

結果做出來的頁面跟參考網站完全不像。文字描述的精準度不夠——「左側 60% 放圖片，右側 40% 放文字」聽起來很清楚，但實際上圖片的比例、文字的層級、留白的節奏，這些視覺細節用文字很難傳達。

更糟的是，設計師 agent 有時候會違反規定直接寫程式碼，而不是產出設計文件。我加了好幾條規則（「DO NOT write any code」「DO NOT create .astro files」），它還是偶爾會犯。

最後我把線框稿這個環節整個拿掉。新流程變成：

1. PM 截圖：用 agent-browser 把參考網站每個區塊都截圖下來，用語意化命名（home-hero.png、home-features.png）
2. 設計師只做 Design System：色票、字型、間距 token，不做線框稿、不寫程式碼
3. 前端工程師直接看截圖建構：截圖就是 source of truth，搭配 Design System 的色彩和字型規範

這個改動效果明顯。前端工程師直接看圖做事，比看文字描述精準很多。Claude 本身就是多模態模型，能直接讀圖片，這個能力在這裡發揮了很大的作用。

QA 評分機制：避免無限來回

前端工程師做出來的品質不一定每次都到位。如果只靠「看起來差不多」來判斷，QA 和前端工程師之間會無止境地來回修改。

我設計了一個六維評分系統，QA 測試員截圖比對時，要針對六個維度各給 1-5 分：

• 版面結構
• 間距節奏
• 字型層級
• 色彩對比
• 視覺重量
• 元件保真度

平均分 3.5 以上且沒有任何維度低於 2 分就過關。沒過的話，QA 會開一張 fix issue 給前端工程師，列出每個維度的具體問題和 CSS 建議。前端工程師修完之後再交回 QA 重新評分。

這個機制讓「過關標準」變得可量化。不再是主觀的「差不多了」或「還不夠好」，而是有明確的數字門檻。

Paperclip 適合拿來做什麼

跑了一週下來，我認為 Paperclip 目前最適合三種場景。

標準化流程自動化。 如果你有一套已經跑順的 SOP，想讓 AI 自動執行，Paperclip 很適合。例如我現在的模板開發流程：每天下班前觸發 PM 研究下一個參考網站，隔天早上起來 review 成果，確認沒問題就讓設計師和前端工程師接手。流程固定，每次跑的步驟一樣，只是換不同的參考網站。

多 agent 協作流程。 PM 截圖 → 設計師做 Design System → 前端建構 → QA 評分 → 通過或退回修改。這種需要多個角色接力的工作，用 Paperclip 的 issue 系統串起來很方便。每個 agent 做完自己的部分，reassign 給下一個人，流程就自動往前推。

自然語言操作。 整個操作過程不需要學任何 UI。想知道進度？直接問。想指派任務？在 Claude Code 裡面用自然語言描述。搭配排程功能，定期追查進度，確保沒有 agent 在有待辦事項的情況下進入閒置狀態。對不想學新工具介面的人來說門檻很低。

除了模板開發，我認為行銷自動化（定期產出社群貼文、排程發佈）、課程設計（拆解大綱、產出教材、review 品質）這類有固定流程的任務也很適合。

目前的限制

坦白說，Paperclip 現階段還不是「設定好就不用管」的全自動方案。幾個主要限制：

• agent 的自主性不夠穩定：說好的規則它不一定會遵守，需要反覆強化指令
• 流程銜接靠人工催：agent 完成工作後，不一定會自動 reassign 給下一個人，經常需要手動介入
• 成本考量：每個 agent 每次 heartbeat 都會消耗 token，八個 agent 同時跑，帳單累積很快。建議用訂閱方案（如 Claude Max）取代按量計費，並且根據任務複雜度選擇合適的模型——不是每個 agent 都需要最強的推理模型，簡單的部署任務用 Haiku 就夠了
• 除錯困難：agent 做出不符預期的行為時，要回頭看 issue 的 comment 串才能理解它的思路，排查效率不高

但作為一個讓 AI agent 團隊協作的實驗，Paperclip 提供了一個可行的框架。關鍵在於流程設計要夠明確——agent 的能力上限取決於你給它的指令有多清楚。我花最多時間的是回想自己開發專案的歷程，然後把這些經驗轉化成每個角色的 AGENTS.md 指令文件，把模糊的描述變成具體的步驟。

這大概是目前 AI agent 開發最真實的樣貌：不是一鍵搞定，而是不斷迭代指令，讓 AI 一次比一次更接近你想要的結果。