這個月的 WordPress 小聚在萬華的「可能存在的遊樂園 CollaPlay」。講者是 Ruby Chuang，題目叫〈你在帶團隊：AI Agent 時代的專案協作思維〉——活動頁上她的介紹寫著「一位在開源 ERP（Odoo）專案裡幫大家把人話翻譯成程式碼語言的顧問」，後面還補了一句「或許她認識你老闆，老闆的老闆……」。

聽完之後我覺得這個題目下得很準：當 AI Agent 開始能寫程式、改網站、執行任務，你面對的就不再是一個工具，而是一個需要被「帶」的團隊。整晚兩場分享，一場講接案，一場講寫作，路數不一樣——一個教你在動工前把模糊打死，一個教你在產出後把誤差餵回去——但指向同一件事：帶 Agent，考的是你說不說得清楚需求、驗不驗得了收。

Ruby：把接案流程整條餵給 Agent

整場簡報做成闖關遊戲：一關一個 BOSS，打完集一枚徽章，四枚分別是「訊息擷取」「擋順便」「完成定義」「你來當 PM」。內容講的是接案裡最不性感但最要命的那些事：需求怎麼問、範圍怎麼守、完成怎麼定義，然後示範怎麼把這整套交給 AI Agent 接住。

打倒模糊大魔王

第一個 BOSS 叫「模糊大魔王」，出場台詞是每個接案的人都聽過的那句：「幫我用 AI 把粉專經營一下，做起來。」

玩法是現場當 PM 對客戶提問，問對一題模糊值 −1、驗收單多一條：這是貼給誰看的？一週發幾則？什麼調性、參考哪個帳號？有沒有禁詞或不能碰的題材？素材誰提供、多久給一次？「做起來」是指觸及還是名單？中間還埋了兩張陷阱卡：「好，交給我！」和「先做再說，錯了再改」，點下去直接扣血。

模糊值歸零的產出是一張能簽名的驗收單，六件事：對象、頻率、調性、禁區、素材、驗收標準（示意案例：3 個月粉絲 +500、私訊詢問每週 ≥10 則）。名詞全部定義完、驗收條件寫得出來，才叫可以開工。

配套的是 DoD（完成定義）翻卡：「手機能開嗎？」翻過來是「三種裝置正常＋表單實測收到」；「幾字？配圖了嗎？」翻過來是「800 字＋3 張圖＋含 CTA」。投影片上那句我抄下來了：

沒定義「完成」＝來回改十次的元兇。把完成先講死，AI 一次到位。

一張名片的旅程：Discord 直通 Odoo 的 live demo

最讓我開眼界的是 live demo。她的 Discord 裡有一個「Odoo 大本營」伺服器，agent 直接打通 Odoo 的 API。順帶一提選 Discord 而不是 Telegram 的理由很務實：Telegram 詐騙太多了，跟客戶的往來放在那上面，觀感就先扣分。流程是這樣的：

1. 拍下現場來賓的名片，丟進「業務助理」頻道給「PM 總管」agent，附一句「這是新商機，他想要詢問 Odoo」。
2. Agent 讀完名片就把商機建進 Odoo CRM：聯絡人、職稱、Email、網站全填好，成交機率保守起手抓 10%（名片掃描階段，聊過再往上調），摘要寫進內部說明欄。
3. 接著 agent 去驗客戶的背景：這間公司在做什麼、窗口是什麼屬性（demo 這位是技術型窗口——溝通不用翻譯技術，但會問底層、客製彈性、API，回覆的專業深度要撐得住）、可能的需求方向是什麼。
4. 根據查證結果產出導入規劃草案，六個階段從「需求訪談＋流程盤點」一路排到「維運訂閱（選配）」，每階段都帶交付物：可運作的 CRM 骨架、匯入完成＋比對報告、客製清單＋API 文件、教材＋上線 checklist；並給出分階段區間報價：階段 0–4 一次性打包 NT$120,000–220,000，上線後維運訂閱 NT$9,000–15,000/月，付款條件建議簽約 40%、上線前 40%、驗收 20%（「技術客戶吃里程碑鎖款，也保我們現金流」）。
5. 規劃拍板之後，agent 把後續工作開成一張張票（task），照著票把 POC 實際做出來——從名片到可以拿去談的 demo，整條是同一個流程。

最戳我的是下一段。Agent 自己停下來說：「一件我必須跟妳確認的事（卡在這，我不敢自己填完）——上面那些區間數字是我猜的市場合理帶，不是我們的官方售價，我手上查不到正式的導入報價表。」 然後列出兩件「我還沒動，等妳一句話」：負責人要掛誰？要不要順手建 Customer 頁、先上網查這間公司是做什麼的？

一隻知道自己哪裡沒把握、會停下來要授權的 Agent，比什麼都會做的 Agent 可信多了。這就是「帶團隊」：它做到 80%，把需要決策的 20% 明確交回來。

她平常就是這樣工作的：走在路上跟 agent 聊天，聊完請它把草案建好；回到電腦前照著草案開發 Odoo 的客製化 addon、架 demo site。後台還有一面 AgentBot 看板，六隻具名的 agent（Ruby、Fynn、PGPG……）各自追蹤議題、統計本週回應和風險，底下是平台健康：Discord Bot 在線、4 個任務執行中、3 個等待、今日訊息 100 則。真的是在管一個團隊。

Demo 之所以有說服力，還有一層：agent 事先查完客戶背景——

我 demo 講的是客戶的語言，所以他們會更有感覺。

報價這件事，先收斂再交給 AI

Odoo 的模組範圍很固定：CRM、銷售模組，報價區間就是系統建置加工天計算的成本，計價方式明確，「照著填就好」。

她反過來問現場 WordPress 接案的人怎麼定價。大家的共識是：購物車、會員管理、金流這些常見需求，外掛生態已經收斂出大致行情，所以報價可以直接列出「這個功能多少錢」讓客戶自己選，做完之後額外的客製化再另外計價。

有趣的是下一步：把這份「報價單範例」當資料餵給 AI 之後，它在推敲客戶需求範圍時，會主動建議有沒有 upsell 空間、要不要再往前推進，產出可以直接拿去跟客戶談的建議事項。報價單從文件變成了 Agent 的知識庫。

很怕被告，所以流程長這樣

幾個實務細節我特別記下來：

• 客戶跟進偏好用 Email 而不是私人 LINE。她的原話是「我是一個很怕被告的人」，書信往來全留證據，每一版報價單 PDF 都留存 V1、V2、V3，日後有爭議拿得出來說明。
• CRM 商機跟進不用自己想：名片建檔之後，Agent 可以直接寫出一串跟進事項。

一隻 Agent 月費兩萬，然後呢

商業模式是訂閱制：一隻 Agent 一個月兩萬塊。現場聽到價格的時候我稍微抖了一下，但背後的設計聽完就說得通了。

他們不想被單一客戶綁住太久，所以刻意讓客戶有動機自己接手整套 ERP 和 AI Agent 的維護：你們越快能自己維護，就越早不用付這兩萬。好處是：初期導入成本壓低了、服務重心變成協助客戶熟悉和訓練操作，也不會因為客戶一直想加管理功能，讓客製化需求膨脹到無法脫身。

這種設計賣的與其說是軟體服務，不如說是讓客戶接手的能力。客戶最後要能自己當家，不用一直付錢請開發者當保姆。我覺得這比技術本身更值得抄。

Q&A：一定要用 Odoo 嗎？

有人問一定要有 Odoo 才能這樣玩嗎。答案是不用，重點是 Agent 身上的技能（skill）：做 HTML 簡報（她的簡報連音效都是 AI 生的）、遊戲化的呈現方式，還有專案管理技能——任務怎麼切、什麼時候啟動、開什麼 ticket，把需求切到夠細、可執行。

對齊一件事情的時候，需求是最難切的。

大概是全場最接案魂的一句話。

結尾投影片把四枚徽章收攏成一句主旨：把「接得到」變成「交得出」：模糊是兇手，具體＝可驗收；六件事＋DoD，一次到位；擋掉「順便幫我……」，守住利潤；教會一隻 Agent，它幫你接住。最後一行是「敢接案，就是有結案能力」。

閃電講：用魔法打敗魔法的鐵人賽量產線

閃電講由 Recca Chao 帶來——Kotlin 社群的領導人，也是台灣技術圈的熟面孔。講怎麼用 AI Agent 寫 iThome 鐵人賽的 30 天文章。順帶一提，Ruby demo 裡那張被拍去建商機的名片，就是他的——當晚被 agent 建檔，又上台講怎麼訓練 agent，大概是全場跟 AI 糾纏最深的人。

第一步不急著寫文章，先請 Agent 幫自己寫出三個 skill：生產長文的 skill、生產中等文（400–2000 字）的 skill、生產標題的 skill。

第二步，拿自己過去的鐵人賽文章當範本餵給 AI，結果被 AI 嫌：以 2000 字長文的標準來看太水，層次至少要進到第四層，你過去的文章只到第二層，濃度太低。全場大笑。

之後人要監督的只剩一件事：決定要寫什麼題目。標題 skill 一次生 30–50 個，review 連貫性、把不喜歡的字調掉，再一篇一篇生成、逐篇修正錯誤，最後把 30 天累積下來的錯誤「逆著回去修 skill」——因為你這個產出，我發現 skill 的缺漏，你要補齊這塊。

金句是這句：

AI can outsource your thinking, but not your understanding.

細節可以外包給 AI 想，鑑別力不行。後端工程師想寫 Flutter 題目當然可以，AI 也會寫得頭頭是道，但寫得對不對，你判斷得出來嗎？「技術文章裡的範例程式碼必須全部能跑」這種認知，有人有、有人沒有；有這個認知、並且有能力把它灌進 skill 的人，才有下一輪的競爭力。

Q&A 還有兩個實用結論：

• Skill 不到位怎麼辦？自己動手把產出修好一版，丟回去叫 Agent 比較「我改了什麼」，再讓它自我調整 skill。語氣會越來越不像 AI、越來越有自己的風格。
• 要不要用 RAG 做文章範本檢索？講者建議不要——vector search（語意相似度檢索）撈回來的東西彈性太雜、精準度不夠，需求如果是更精確、更條列式的產出，用 MCP server（讓 agent 用明確定義的工具拿結構化資料）或 few-shot 範例的方式更準，服務架構也更簡單；複雜的部分挪到 multi-agent 去做。

結尾的祝福我抄下來了：「期待今年鐵人賽的評審忙到吐血——用魔法打敗魔法，讓他的 Agent 耗盡他的 token。」

我帶走的東西

把兩場分享疊在一起看，剛好補成一個完整的迴圈：

• Ruby 管前半段，閃電講管後半段。 動工前用驗收單和 DoD 把「完成」講死（Ruby），產出後拿誤差逆著回去修 skill（閃電講）。前者是規格，後者是回饋；帶 AI Agent 跟帶人一樣，兩端都得有人把關——說清楚需求、做好交辦、控制變更、驗收成果。
• 好的 Agent 知道哪裡該停。 報價數字沒有官方依據就不敢自己填完、掛負責人之前先確認 user id。這種「做到 80%、把決策交回來」的設計，比全自動更值得抄。
• 商業模式也可以「以終為始」：與其把客戶綁成長期飯票，不如設計一個讓客戶畢業的機制。
• Odoo 值得找時間研究。

酒水謝謝阿腸數位 Barry 和哈拉設計，場地謝謝 Kinsta 和 Akamai。下個月小聚見。