前幾天有人問我：「你的團隊有幾個人？」

我愣了一下。因為答案要看怎麼定義「人」。

如果算真正會呼吸的人類，就我一個。但如果算每天在幫我做事的角色 — 有技術軍師、有行銷經理、有內容總監、有產品工程師、還有一個 QA 研究員。他們全部跑在一台雲端 VPS 上。

這篇文章不是要炫耀這件事有多酷。我想記錄的是：這套系統是怎麼從「AI 到處亂跑」變成「還算能信任的運作機器」。包括我踩過哪些坑、怎麼修的、以及你如果要自己建一套，需要注意什麼。

一台雲端主機怎麼跑出一間公司

我的 AI 團隊現在有五個 Agent。J 負責技術決策和任務派工，米米跑行銷和市場調研，莉莉管內容產出，阿達寫程式和產品開發，小月做品質把關。

運作邏輯沒有很玄：核心是 Claude Code 加上自動化排程。每個 Agent 有自己的記憶檔、工作範圍限制和品質閘門。J 自動拆分任務、分派給對的 Agent、追蹤進度、驗收產出。

整個系統不需要伺服器叢集，不需要 GPU farm。一台雲端 VPS、幾個 Docker 容器、加上排程工具，就能撐起這套架構。

聽起來簡單。實際建的時候，每一層都是一個新的問題。

防幻覺：AI 在我背後說了什麼

讓 AI 跑任務不難。難的是讓它不要亂跑。

我先說最痛的教訓。

事件一：SOL 假預測事件

有一天，系統自動發了一則韓文推文，內容大概是：「Solana AI 預測：2026 年 5 月 $180-$220」。

問題在於，這個數字是 AI 自己生成的，沒有任何來源。更糟的是，推文裡還提到「2025 年中旬多頭行情可能出現」— 但現在已經是 2026 年，這個說法在時間上自相矛盾。

原始素材是一篇 99bitcoins 的文章，AI 讀完之後重新詮釋，生成了一個看起來很有說服力的價格預測。沒有引用原文，還加進了自己「補充」的時間軸。

掛的是我的名字。

我們怎麼修：

在內容品質檢查函式裡加了兩條規則：

規則 A：價格預測沒有來源 URL，自動攔截。 邏輯很直白 — 如果一篇內容聲稱某資產的未來價格，必須附上可驗證的原始來源連結。沒有就擋。

規則 B：時間矛盾偵測。 如果內容裡出現「2025 年」但用了未來式（「可能」、「預計」、「將會」），系統判定為時間邏輯錯誤，自動攔截並標記原因。

修改後跑了四組測試：原本的壞內容被攔截，有正確標注來源的類似內容順利通過。四組全部符合預期。

事件二：幻想工具名稱

另一次，AI 管線在 @JudyaiLab 發了一篇介紹開發工具的文章，裡面推薦了六個工具：waive、codeshare、lancet、scene2、protoboy、deepwrite。

這六個工具都不存在。

AI 被要求寫「開發者常用工具推薦」，它就自己發明了幾個聽起來合理的名字。甚至還附上了使用說明。

這件事告訴我什麼：

工具推薦類內容屬於高風險題材。AI 不知道「它不知道什麼」，它只知道怎麼把句子寫得流暢。所以它會填補空白，用聽起來像工具名稱的詞彙。

應對方向：

工具推薦類文章必須比對已知工具清單，或是要求 AI 附上官方網址。沒有官網可查的工具名稱不得出現在發布內容中。

核心原則

每一條對外發布的 AI 產出內容，必須通過自動化驗證才能發出去。「AI 寫的」不是擋箭牌 — 掛的是你的名字，責任是你的。

品質閘門：我們實際在跑的驗證框架

現在說說我怎麼設計閘門系統，讓這些問題不只是「出事了補規則」，而是有系統地攔下來。

GATE-6：獨立重跑驗證

當一個 Agent 回報「完成」或「通過」，不直接信任。至少獨立重跑其中一個驗查步驟。

為什麼要這樣：

有一次，Agent 阿達回報修好了一個服務閘道的 Bug。回報看起來很完整，連測試日誌都附上了。GATE-6 獨立驗查之後發現：這個修補只對了一半，四個服務裡有兩個還在指向錯誤的位址。

如果沒有這個閘門，這個 Bug 就這樣上線了。

執行規則： 沒有命令輸出作為證明的驗查報告，自動不信任。「我測過了」不夠，要有可重現的輸出。

GATE-7：三次退回就換人

同一張任務卡被退回三次，標記為卡住，換給不同的 Agent 重來。

這條規則是為了打破「無限修改迴圈」。Agent 有時候卡在一個思路上，改三次都還在繞同一個圈，換人反而能帶來新的解法。

GATE-9：推諉語言偵測

如果一份報告裡出現下列模式，自動判定為 FAIL：

  • 「請手動確認」
  • 「可能是」、「應該沒問題」
  • 「建議您」
  • 「probably」、「please check manually」

PASS 必須附具體證據。FAIL 必須說明具體失敗原因。沒有中間地帶。

這條規則聽起來很嚴，但它的存在是因為我被「看起來沒問題」的報告騙過好幾次。AI 寫出流暢的報告不代表它做對了。

QA 評分 ≥ 8.5

每一份對外交付物都要過評分。低於 8.5 分退回，附上具體的修改指示。

Blog 文章的流程是：中文草稿 → QA 評分 → Notion 給我看 → 我批准 → 翻譯英文和韓文 → 部署。每一步都要過，不能跳。

AI 內容調教：我們怎麼讓 Hermes 寫出能用的東西

我們的內容管線用 Hermes 3（405B 參數，透過 OpenRouter 按量計費）做分析和寫作，MiniMax M2.7（訂閱制）做備用。

這是我們調教過程的實際紀錄，每一條都是踩過坑之後才加的。

問題一：輸出很通用、沒有靈魂

症狀： AI 寫出的內容正確但無聊，每篇感覺都一樣。

修法： 給每個語言版本一份風格提示，裡面包含：語氣要求、禁止詞彙、該用的平台術語。韓文版有韓文的語氣標準，繁體中文版有繁中的標準。這不是「建議」，是強制欄位。

問題二：韓文裡混進了中文字

症狀： 韓文推文裡出現中文或日文漢字。

修法： 加入後處理驗證 — 用正規表示式掃描韓文文本，偵測到 CJK 字元就自動移除。繁體中文的方向也有對應處理：維護一份 60 條的簡轉繁對照表，確保輸出不含簡體字。

問題三：推文超過字數限制

症狀： 產出的推文超過 280 字元，沒辦法發。

修法： 自動縮短迴圈。系統先讓 AI 嘗試縮短，最多跑三輪，每輪的目標字數遞減（280 → 250 → 230）。三輪還是太長，就硬截斷。

問題四：AI 信心滿滿地陳述未經驗證的事實

症狀： 內容裡有聽起來很具體的聲明，但根本沒有來源。

修法： 內容管線加入 fact_check 欄位。標記為「未確認」或「未核實」的內容，自動攔截不發。高風險聲明（ETF 核准、交易所上架、企業收購）必須標記為「已確認」並附來源，才能通過。

問題五：同一個話題反覆出現

症狀： 系統在不同天發了類似主題的內容，讀者覺得在重複。

修法： 加入跨日去重機制，比對最近三天的發布紀錄。去重用同義詞對照表（例如「索拉納」和「Solana」視為同一主題），避免只換個說法就當新內容發出去。

系統壞掉的時候：你一定會遇到的四種 AI 系統故障

我們修過大大小小幾十個 Bug。具體的技術細節每個人不一樣，但故障的「類型」驚人地一致。如果你在建 AI 自動化系統，以下四種你幾乎一定會碰到。

第一種：靜默失敗

AI 系統最危險的壞法不是崩潰，是「安靜地停止工作」。我們的交易掃描器曾經停擺超過四小時，沒有任何錯誤訊息、沒有告警、排程照常啟動但什麼都沒做。直到定時健康檢查才發現。

為什麼這比 crash 可怕？ 因為 crash 會被通知系統抓到，靜默失敗不會。你以為系統在跑，其實它早就停了。

怎麼防： 不要只監控「有沒有報錯」，要監控「有沒有產出」。設計心跳機制 — 系統每次成功執行都寫一個時間戳，監控端檢查這個時間戳有沒有過期。沒有產出本身就是一種告警。

第二種：環境落差

在你手動操作時一切正常，但自動排程跑的時候就壞。原因通常是：排程環境的 PATH 不同、環境變數沒載入、權限不一樣、工作目錄不對。

為什麼特別容易中招？ 因為你測試的時候是用自己的終端機，所有環境變數都在。排程工作是用一個乾淨到幾乎什麼都沒有的環境啟動的，你覺得理所當然的東西它全部沒有。

怎麼防： 在排程腳本的最開頭，明確載入所有需要的環境變數和 PATH。不要假設任何東西「已經存在」。上線前用排程方式跑一次完整測試，不要只用手動測試就交差。

第三種：降級不自知

系統設計了後備機制 — 主要的 AI 模型掛了就用備用方案。聽起來很穩。但問題是：備用方案的品質可能遠低於主方案，而系統沒有告訴你它正在用降級模式運行。

我們遇過一次：主模型被限速，系統自動退回到純技術指標判斷，信心評分從正常的 80 分掉到 20 分，但系統照樣執行了交易。結果虧了錢。

為什麼危險？ 因為降級是設計來「保持系統不停擺」的，但保持運行和保持品質是兩回事。用 20 分信心的判斷去執行交易，不如不執行。

怎麼防： 每一層後備都要標記降級狀態，並且根據降級程度調整行為。如果備用方案的品質不足以支撐決策，那正確的做法是暫停，而不是硬著頭皮做一個低品質的決定。另外，盡量讓後備方案是「換一個同等級的模型」，而不是「拿掉 AI 用規則硬撐」。

第四種：一個修好了，下一個冒出來

修完第一個 Bug 以後系統跑起來了，然後立刻碰到第二個 Bug。這不是運氣差 — 是因為第一個 Bug 擋住了整條流程，後面的 Bug 根本沒機會出現。

為什麼常見？ AI 管線通常是串聯的：掃描 → 分析 → 決策 → 執行 → 監控。前面壞了，後面根本走不到，所以後面的問題會被藏起來。修好前面的之後，後面的問題才會浮出水面。

怎麼防： 修完一個 Bug 之後，不要急著慶祝，跑一次完整的端到端測試。從輸入端到輸出端全部走一遍，確認整條鏈路都通才算修好。養成「修一個就測全部」的習慣。

成本現實

如果這些工作全部請真人做 — 一個行銷、一個內容、一個工程師、一個 PM — 在首爾大概月薪加起來要一千五百萬韓幣以上。

現在我的成本是幾個 AI 訂閱費加上一台 24 小時運行的雲端 VPS。

但省錢不是重點。真正的差異是反應速度和不休息。我的系統可以深夜自動跑安全巡檢、清晨產出市場分析報告、全天候監控交易部位。我醒來的時候，該做的事已經做完了，我只需要看報告、做決策。

我每天花在管理上的時間大概三十分鐘。剩下的時間拿來思考策略或享受生活。這才是微型 AI 公司真正的價值 — 不是取代人類，是讓一個人可以做到以前需要一個小團隊才能做的事。

我學到了什麼

說幾件建完這套系統之後才真正理解的事。

第一：AI 系統的「壞」不像一般程式的壞。

一般程式壞了會 crash，你會看到錯誤訊息。AI 系統壞了通常是「產出了一個聽起來合理但其實偏掉的答案」。這種錯誤很難被發現，因為它長得不像錯誤。所以你需要閘門，需要獨立驗查，需要永遠不要相信「看起來沒問題」。

第二：防幻覺不是一次性的工作。

你加了一條規則，AI 就在這條規則的邊界之外找到新的幻覺方式。這是一場持續的追逐戰。規則需要隨著新的失敗案例不斷更新。

第三：建這套系統的成本被嚴重低估了。

不是裝完工具就能用。是幾個月的持續調整 — Agent 的工作邊界、權限、品質標準、協作格式、閘門設計。這些沒有說明書，你只能自己撞牆、自己歸納。

第四：閘門的嚴格程度決定你能睡多安穩。

如果閘門太鬆，你會每天提心吊膽不知道 AI 又亂說了什麼。如果閘門太緊，效率會低到不如手動做。找到那個平衡點是這件事最難的部分，而且每個業務場景的平衡點都不一樣。

2026 年，一個人加上一台雲端主機能做到的事，已經超越了 2020 年一個五人新創團隊的產出。這個趨勢只會加速。

但如果有人跟你說「用 AI 就能零成本創業」— 那是騙人的。成本不是零，只是從「薪資」變成了「你自己的時間、認知負荷、以及不斷追著 AI 修漏洞的精力」。

我還在這條路上。每天都在修東西，每天都在發現新的問題。

但回頭看，一台雲端主機跑出一間公司這件事，好像就是這樣一點一點建起來的。