Posted by 
跟 Hermes 搞了幾個月，整理一下到底搞了什麼。這篇是我跟 Hermes 一起寫的。
背景
敲了二十年的鍵盤，從 bare metal server 一路寫到 cloud native——那個年代搞過實體機房的都知道有多 hardcore。2026 年離開職場，終於有時間停下來想：現在的趨勢是什麼、下一步往哪走、大家都在用什麼。
這段時間 AI 工具大爆發。很多人享受用 Cursor、Codex 或 Claude 把自己的想法一口氣 vibing 出來的那種把思想具現化的感覺。但我比較感興趣的是 Agent——不是只幫你寫 code，而是能自己跑任務、有排程、有工具鏈的那種。其中 Hermes 是我最核心的一塊。
說真的，vibe 這個概念我一開始是有點排斥的。我很早就開始用 AI——但路線是 auto complete：腦子裡已經知道下一步要做什麼，那些 trivial 的 code 讓 AI 補完，省打字的時間。但 vibe coding 我一直有深深的不信任感：叫他修個小地方，結果改了三十個檔案，根本不知道發生什麼事。怕.jpg。
但這一年來事情變了。模型進步讓 coding agent 出現質的飛躍，Spec-Driven Development 也因為 harness engineering 的方法論成熟而普及——簡單講就是在 agent 外面包一層約束層：定義範圍、檢查產出、強制回報。慢慢地發現，vibe 是可以控制的。需要知道它改了什麼、為什麼這樣寫，現在幾乎都能清楚掌握，不再是黑箱。
而且受惠於這些進展，文件跟 code 的雙向修訂也越來越容易——手動改了 code，變更會自動反映回 spec 文件；spec 改了，agent 也會對應調整。老實講，這在以前是完全不敢想的。
信任建立起來後，下一步很自然：既然 agent 可以幫我寫 code，那能不能幫我營運整個數位生活？於是跳過 Coding Agent 的範疇，直接往更上層的 Generic Agent——OpenClaw、Hermes——邁進。
然後我發現，Hermes 不只是拿來做營運。寫專案的時候也一樣：與其自己直接對 Codex 一個指令一個指令下，不如讓 Hermes 當指揮。討論架構、拆任務、把實作交給 Codex、用 issue tracker 確保不發散。人的角色從「操作 agent 的工程師」變成「管理多個 agent 的指揮者」——能掌握的 scope 比一個人直接操作 Coding Agent 要廣得太多了。
拿 Hermes 做什麼
每天早上六點，Telegram 會收到一份晨報。不是那種「早安，今天天氣晴」的罐頭，是真的有用的東西：Gmail 和 iCloud 郵件整理成重點摘要、iMessage 裡保險和銀行通知被標出來、這幾天自己傳給自己的書籤被提醒去看、YouTube Watch Later 裡堆積的影片被撈出來免得又忘記、MoneyWiz 排程付款告訴你今明兩天要繳什麼、iCloud 行事曆的行程和截止日一目了然、天氣順便告訴你帶不帶傘、eToro 投資組合的損益和 copy-trade 狀態自動更新、Hacker News 和社群討論的 AI 新聞被篩出來。整份晨報送到面前，躺在床上看 Telegram 就知道今天要注意什麼。完全不用自己去查。
這不是一次性對話的產物。它是一個每天自動執行的 cron job。Hermes 自己去爬資料、自己分析、自己寫繁體中文簡報、自己送到 Telegram、自己存一份完整版到 Obsidian 知識庫。
除了晨報，Hermes 也用來管理這個 WordPress 部落格。不用登入 wp-admin 慢慢點，直接在聊天室裡下指令：列出外掛、檢查更新、設定 SEO meta、直接發文。Hermes 透過 SSH 連到伺服器，用 WP-CLI 搞定。中間當然碰到一些鳥事——像是本地和伺服器都是 fish shell，WP-CLI 的 SSH alias 直接炸掉——跟 Hermes 一起 debug、調整 wrapper script 的引號轉義、強制遠端走 bash。搞定後就再也不用想了。
新工具的評估也是交給 Hermes。最近看到一個叫 Scrapling 的爬蟲框架，不是自己去看文件自己裝，而是叫 Hermes 去開 GitHub 頁面、搜社群評價、分析跟現有工具的差異，然後決定要不要整合進 skill 體系。整合完這東西就變成自動化的一部分，下次要用直接上。
怎麼做的
核心原則只有一個：不要做第二次。
任何需要重複做的事情，都試著變一個 skill。什麼是 skill？一份「下次照著做」的說明書——但不是寫給人看的 SOP，是寫給 AI 看的。裡面有精確的指令、CLI 命令、API endpoint、踩過的坑（pitfalls）、驗證步驟。當一個 workflow 寫成 skill 之後，不只是「下次可以重用」，是「下次完全不用想」。
Daily Morning Brief 就是這樣迭代出來的。一開始只是個簡單的「幫我整理郵件」的 prompt，但每次跑都發現新問題：某個 API 在 cron 模式會 timeout、某個 JSON 欄位格式跟預期不同、某個第三方服務的 fallback 要設計。每次都把解法寫進 skill。現在這 skill 已經超過一千行——不是人寫的 SOP，是 Hermes 跟自己對話的腳本。
另一個原則：不要讓我覺得麻煩。
選工具的標準很簡單：超過一行設定就開始懷疑值不值得。這也是為什麼我很依賴 Hermes 的 skill 體系——一個 skill 一行安裝、config.yaml 加一行接上 MCP server。不用搞環境變數、不用寫一堆 wrapper script。
寫專案的分工：討論歸討論，實作歸實作
開發新專案時——例如 LLM Wiki Cloud——不會叫同一個 agent 從頭包到尾。我的分工是三步：
第一步，跟 Hermes 討論設計。 這功能值不值得做？跟競品比有什麼差？技術架構怎麼設計？API 要怎麼切？這段討論由我主導，AI 給意見、搜資料、幫忙推 trade-off。方向確定了才進實作。
第二步，把 spec 交給 Codex 實作。 Codex 是擅長寫 code 的 AI agent，確保它裝了足夠多的 skill：GCP、Next.js、Vercel 部署、Superpowers 之類的 code quality 輔助。準備好就把 spec 丟給它。
但在能力範圍內，還是要搞清楚它怎麼做的。很多時候 AI 用的方法不怎樣——你可以給更好的做法；反過來，AI 也可能提出你沒想過的解法。這正是前面講的：基礎知識無可取代。你有那張地圖，才聽得懂 AI 在說什麼、才知道什麼時候該信、什麼時候該挑戰。使用者的知識跟經驗，是決定成品是一個「假裝有功能」的 demo，還是一個真正能用的東西的關鍵。
第三步，用 issue tracker 控 scope。 不是 spec 丟出去就放生。所有任務拆成明確的 issue，確保不發散。Codex 在跑的時候，關鍵路徑自己進 code 看、確認架構沒歪、必要時自己改。產出的每一行 code 還是我負責。
這個模式的底層信念：AI 是協作者，不是黑箱外包。
除了問 agent，還做了什麼讓它更好用
大部分人用 AI agent 就是問問題、得到答案、結束。但我多做了一些事，讓 Hermes 從「工具」變「基礎設施」。
Cron job 體系。 晨報是定時的，投資摘要也是定時的。不是我手動觸發，是我在睡覺的時候自動跑完、自動送到面前。這是從 pull（需要時去問）到 push（AI 主動推過來）的轉變。大多數人用 AI 是前者，我是後者。
多個輸出管道。 Hermes 不只在對話框回我——它把晨報送 Telegram（快速消費）、完整版存 Obsidian（深度存檔）、文章發 WordPress（公開發表）。不同內容走不同管道，把 AI 當內容路由系統在用。
知識持久化。 每次協作學到的東西——哪個 API 有什麼 quirk、哪個路徑要注意、哪個設定容易踩坑——都存成 memory 或寫進 skill。下次不會犯同樣的錯。這不是「AI 記憶」，這是「把經驗沉澱成 AI 讀得懂的格式」。累積久了，Hermes 對我的環境跟習慣的理解會越來越準。
供應鏈安全。 用 Bumblebee 定期掃所有裝的 package、extension、MCP config。用任何第三方工具前，花幾秒確認沒有已知漏洞。大多數 AI 使用場景不會考慮到這個，但如果你把 AI agent 當基礎設施，安全掃描就是基本動作。
iMessage 當意圖捕獲層。 在手機上看到任何值得處理的東西，就傳給自己。Hermes 在晨報撈出來提醒。「想處理的事情」不會消失在聊天記錄或瀏覽器分頁裡。不需要記得，AI 幫你記得。
對 AI 的態度：槓桿，不是 Source of Truth
一句話：AI 是槓桿，不是 Source of Truth。我關心的是現在怎麼用它輔助做產品，不是五年後的 AGI——更不是把它當成自己不懂的事情的答案提供者。自己都不理解的東西，AI 給的答案你敢信嗎？
三個核心信念。第一，「知識要先整理好，AI 才用得動」——原始文件丟給 LLM 是沒用的，要有結構、知道何時讀取。第二，「基礎知識無可取代」——跟 AI 協作常是我提出 AI 沒想到的做法，或抓到 AI 產出的明顯問題；反過來，AI 也常提出我根本沒想過的角度。你有基礎知識，才聽得懂 AI 在說什麼、才知道什麼時候該信、什麼時候該挑戰。第三，「verify, then trust」——AI 幫我加速，但用 issue tracking 控 scope，關鍵路徑自己進 code 看、自己改。
一人加 AI 可以等於一支小團隊。離開職場後我用 AI Agent 做研究、排程、監控、開發，一個人在做的範圍涵蓋了以前要 PM 加工程師加研究員才搞得定的工作。這不是被 AI 取代，是學會用 AI 放大自己。
Hermes 不是一個聰明的對話夥伴。它是我個人的 AI 基礎設施——有排程、有記憶、有多平台輸出、有安全掃描、有自動化 pipeline。它不只回答問題，它幫我營運整個數位生活。
寫專案時也不是全丟給同一個 agent。討論設計找 Hermes、實作交給 Codex、scope 用 issue tracker 控管。這就是我目前的 AI 協作分工。老實講，這幾個月下來，我真的覺得這套 workflow 比我自己一個人搞有效率太多了。
2026-06-09，與 Hermes 協作回顧