再九天，就是 ETHTaipei 第四屆。

上一屆的現在，跟今天，對我來說像是完全不同的世界。好像從一個黑暗煉獄，在拖著疲憊身軀長途跋涉之後，終於到達了一個看起來美好、可是你不知道是不是有其他危險的綠洲。

之前的煉獄給我們的挑戰是比較確定性的。即使當時也覺得變化多端、不穩定，但跟現在比起來，那時候確實是很穩定的。

而現在，雖然說每天都快快樂樂的，可是好像有種即將樂極生悲的隱憂，是一種不知道哪一天會有大災難降臨的，奇怪的預感。

再見了，乙太坊

ETHTaipei 的前兩年，我都在活動前一週重感冒。去年我加強補充了維他命，也想辦法早點睡，但還是每天都繃緊神經。

第一年，因為是第一次辦，很多事情都不太確定，所以很緊張。

第二年，我被安排要親自採訪 Vitalik。我知道我再怎麼樣準備，也還是可能因為聽不懂 Vitalik 在講什麼深奧的語言，而顯得像白癡，所以準備的有點無助。

去年，理論上已經是第三年了，但因為我自討苦吃，做了一個音樂舞台，所以還是有很多東西要準備。

今年大部分的元老都退出了。加上我這一年迷上 AI Agent，根本沒有時間繼續研究以太坊相關發展。原本我覺得沒辦法繼續參與了，但我非常崇拜的馬丁還是繼續支撐主導這個活動，讓我很感動，所以我決定還是要追隨他。

只是，我去年就已經離開 Crypto 工作，也暫時放下 ETH Maxi 的這個信仰，我一直覺得我德不配位。即使是這篇要寫 ETHTaipei 的宣傳文章，我的內容可能都還是只跟 AI Agent 比較有關，真是抱歉。

如果你對以太坊還是有興趣的話，請你一定要去報名。雖然說這次報名不一定可以入選，但是是免費的，所以不報白不報，快去報名：https://luma.com/8z5ys4rl

如果你真的覺得你一定要參加的話，請跟我說，我幫你往前排。

辦活動好忙

為什麼辦活動這麼忙呢？其實也不是在做什麼一秒鐘幾十萬上下的大交易，就是事情實在太多太雜。每個人多工的簡直像是每天都把身體義大利麵化一樣，每根麵條都像觸角一樣處理一個偏遠雜務，再飄回來原本的軀殼。

以行銷組來說，各種媒體要協調，新聞稿要寫，宣傳要發，網站要更新，要挑選廠商和夥伴，和他們吵架。雜七雜八的。

比如 Logo 更新，合作夥伴寄一個檔案過來，你要去背、調大小、放到官網對的位置，還要確認手機版不會跑掉。一次三分鐘，可是它有三十次，而且三十次不等於九十分鐘，因為每一次你都得先想起來自己現在在做什麼。

還有其他 99 種類似的雜事，落在每一個工作人員身上。

前幾年大家都很努力，今年也是，大家還是很忙。只是前幾年，每次到了活動前兩個禮拜，我的嘴角就會發炎，會水土不服。而今年，我目前為止還算康健，為什麼呢？主要是我今年個人產出已經極小化，都是志工馬鈴薯、Ying，還有 Boba 在分擔。

今年多了一個志工，他叫 Boba

Boba 是我們今年的一個 AI agent 志工，跑在一台 2015 年的 MacBook 上。那台電腦老到風扇有時候會叫，它就那樣擺著，然後 Boba 在上面開 PR、寫稿、發通知。

Boba 住在 ETHTaipei 工作人員團隊的 Discord 裡，誰都可以在頻道裡直接叫他做事。他的設定裡放了一張台灣手搖飲清單，收集了網路上大家推薦的手搖飲，五十嵐的四季春、清心福全的優多綠茶、春水堂的珍奶都在上面。他每次回報工作，結尾都要推薦一杯。

他做的事情包含但不限於官網的 PR（贊助商 logo、大學社團、媒體夥伴、攤位那些區塊）、中英雙語新聞稿撰寫、電子報名單整理與發送、社群貼文的草稿，還有每天兩次的票況快照，發在我們的行銷頻道。

因為 Boba 是建立給年度活動的，很多設定其實很粗糙，也不是所有功能的 Harness 都有細心優化過，因此 Boba 並不是全能的，有時會覺得，他好像只能在他到職時領取的 JD 的工作範圍內進行，不然就得再去建立 Harness 流程。

所以，有時候會突然覺得事情好像很多，會議結束的時候，會突然間壓力很大。因為我發現這些事情不在 Boba 的工作範圍內。

但我後來發現，其實全部都可以試著交給 Boba 做。有些我本來沒想到可以交給他的，也是硬著頭皮請他做，因為我真的真的太不想自己做了。就懶惰的丟給他，沒想到真的有時候可以做好。

拿電子報來說好了。

我們要寄信給之前參加過的人，叫他們趕快來報名今年的活動。可是之前參加者的名單散落在各處，雖然有整理在 Google Sheets，可是非常亂，有好幾個不同的 sheet，格式和欄位還不同。

我真的很懶得整理，就交給 Boba，沒想到他真的幫我整理好了。不但如此，他還幫我匯進我的電子報系統，欄位也都整合好了，整個過程完全不需要我手動處理。

更甚至電子報本身，我也只是給他看我們的活動官網，請他用一樣的風格設計版型，連文案也全部都是他寫的，還直接幫我用電子報系統建立（我用 Plunk，推薦），我只需要寄測試信做最後確認。

當然如果要細雕的話品質可以更好，但因為時間有限，我們就直接發出去了。

開信率 33.79%，比我手寫的還好。

這整個過程真的意想不到的順利。

其實我本來覺得這件事超複雜的，資料很散亂，而且又要編輯電子報的版型、內容。我一直拖一直拖不想做，拖到 PM 跟我說今天就該發，當時我實在太太太不想自己做，所以即使覺得這件事情 Boba 可能搞砸，我還是硬著頭皮送出給 Boba 的 Prompt，期待著他可以幫我完成。

結果跟我想像中的完全不一樣，他做得比我期望的還要更好。

抓大放小

現在其實很多事情都可以叫 Boba 做了，我們要決定的就只是要做什麼事。可是，放手之後，有時候就得睜一隻眼閉一隻眼。

比如，整理寄信名單的時候其實滿亂的。

因為每個活動拿到的名單格式都有一點不一樣，可是我又希望可以在匯入的時候標註這個 email 的人參加過哪幾個活動。但有些是有報名紀錄，有些是有報到紀錄，有些有報名卻沒報到，或是兩者都有，甚至有些完全沒有這些資料。

那時候我本來想說可能需要手動去檢查，但我後來其實是用抓大放小的態度把這件事完成。

我覺得這真的滿像在經營公司。有時候你會想知道員工做的每件事情細節跟你想像的一不一樣，但當團隊比較大的時候，你不可能每件事都管到很細，那樣就變成 micro-management。

所以有時偶然看到一個細節他做得跟你的想法不同，你必須學會放下，用他的做法就好。因為這時你插手干預了，員工會很不爽覺得你又搞不清楚狀況，囉唆什麼，然後變得綁手綁腳。Agent 雖然目前沒有看出可能有這種情緒問題，但仍會學習到你會這樣插手，然後變得綁手綁腳不敢做、只做最保守的問題，或是一直停下來問你。總之，就算那不是你想像中最好的做法，只要目的是一樣的就行。

整理電子報這件事也是一樣。我覺得最後整理出來的格式就算有一點點落差也沒關係，至少達到我的目的：能從電子報系統裡看出來名單上的人參加過哪些活動，這樣就夠了。

出錯是 AI 之常情

七月的時候有一隻排程壞掉了。

那隻排程叫 `check-new-applications`，工作是每個禮拜去看講者申請有沒有新的，然後告訴我。他壞了兩個禮拜，我完全不知道，因為他每一週還是有跟我講話。

像是這樣裝沒事一樣。

實際上他根本沒有去查講者申請。他做的事情是建了一個暫存檔、跑一跑、把暫存檔刪掉、然後檢查有沒有刪乾淨。刪乾淨了，所以回報 PASS。

那兩個禮拜有六件新的講者申請進來，沒有送到我眼前。

可能是我突然間覺得奇怪，應該有講者資料，然後我們開會的時候，負責講者的人說有十幾個 applications，但是我卻發現後台沒有回報，然後我就去問，好像是這樣發現的。

後來翻紀錄，七月一號那次同一隻排程也失敗了。但那次他老實跟我說失敗了，我當天晚上九點十七分就把那則訊息貼出來，說這個壞掉了。

同一個故障，七月一號當天晚上就被抓到，七月二十二號那次我過了六天才知道。

後來我們把那條路徑上的 AI 整個拿掉，改成一支很普通的程式，抓不到資料就印一行警告出來，後來才順利的。

這不是無人軍團

雖然 Boba 會出錯，但我沒有覺得這件事這麼嚴重。

因為實際上在處理的時候，處理的人拿到的是真正的資料，那個錯誤其實就只是通知漏掉了。負責講者的人也不會因為通知漏掉，就不去看那些 applications。

當然，因為這次事情沒這麼嚴重，如果做了更嚴重的事情可能會比較糟糕，所以 Guardrails 還是要做的。

不過我覺得大部分的事情都還是有人參與。我們並不是一個無人軍團，而是 AI 跟人類一起協作的團隊，所以這中間是有一些容錯空間的。

就好像全人類的團隊也會有人出錯，我們不可能完全避免這些事。但就是因為有同事、有夥伴，所以可以互相幫忙，把缺漏的地方找出來補上，錯誤變得即使難以避免但也能存在。

最近我覺得 AI Agent 最正確的姿勢，其實也不是說希望有一個 AI Agent 的軍團，完完全全自己運作、都不用管。

我覺得比較像是把 AI Agent 變成團隊的一份子，跟大家協作，並融入原本的流程。這樣一來，即使會出錯，本來的流程就一定會有容錯機制，再透過不斷進行流程優化，就可以把錯誤慢慢降到最低。

人類才能做的事

後來不只是我會和 Boba 協作。馬鈴薯負責媒體和許多社群合作，他非常熟練也很厲害。確認一個合作夥伴之後，他也會直接請 Boba 幫忙把收集到的 logo 上架到官網。前兩年那件把大家弄得很煩的雜事，今年變成一個 PR，有人審一下就進去了。

Ying 則是負責社群媒體。他會用 Boba 來幫忙寫草稿，但依然會擔任整體編輯、排程與策略規劃。我覺得這是還不錯的協作方式。

新聞稿也都是請 Boba 整理我們的想法、一起討論後寫出來的，有繁體中文、英文、簡體中文。

但還是很多是人類的部分，Boba 目前不太能做的。

協作方式是這樣的。我們跟所有的媒體開群組，完成新聞稿後，請 Boba 幫我們寫要發到群組的訊息範本，有中文、英文還有簡體中文。我們就直接複製貼上發出去，這部分都是人工處理，發出去並確認他們有收到。如果媒體有任何需求，也是真人回應。媒體他們上刊之後，我們會再把上刊的連結丟回給 Boba 請他做統計。

但還是有些 Boba 完全幫不上忙，比如貴賓接待，比如說知名人物要來演講的協調。

這是非常需要人做溝通的。因為我們不是直接對到他們本人，都是對到助理、甚至是比助理更外圍的人。像 Vitalik 可能希望現場有保安、有人陪同，或是希望大家不要衝過去跟他自拍等等。

這種事情通常只能是人跟人之間討論，去看現場要怎麼處理。很多時候你問了也不會得到明確的答案。對方可能只是說「應該還好」，然後你要自己判斷那句「應該還好」是真的還好，還是客氣。

也許之後 AI 也會能幫忙這塊，也許就是今年 Astra 呢（硬蹭）！

快來報名 ETHTaipei

再過不到兩個禮拜，活動就開始了。

九月十三號、十四號，南港瓶蓋工廠。免費。

Vitalik 第四年來，台灣大哥大的總經理 Jamie 也會一起做 keynote，快來報名：

https://luma.com/8z5ys4rl

我也會在，請大家來拍打餵食。

我有一個壞習慣。

參加活動的時候，因為社交能量不足，通常差不多一個半小時，笑容會開始僵掉，說的話會開始突兀。所以我常常活動到一半就躲起來，更累的時候，我會來個法式離場。

過去一個月我跑了很多活動。上週去東京參加 Code w/ Claude，讓我近距離感受 Anthropic 文化。月初我和 Justin 主辦的 Claude Meetup 來了一百三十個人，反應還算不錯。更早還有幾場校園講座、和其他零散的邀約。

很充實，可是坦白說，真有點超過我這個小 I 人能負荷的了。

突如其來的通告

六月五號我在 Anthropic 活動遇到布丁。

我們是認識好久的老朋友了，他看過我年輕貌美的樣子。去年他和人槓上，曾經情勒所有 Facebook 好友，只要不挺他就刪好友。我一開始看到貼文內容還很反感，覺得「呃！這什麼幼稚男子」，後來發現是布丁，瞬間覺得太可愛，「噢！這什麼幼稚男子。」

我們已經好幾年沒碰面了。一聊才發現我們都在搞 AI agent。我們已經好幾年沒碰面了。一聊才發現我們都在搞 AI agent。我們聊到有人因為我用龍蝦覺得那已經過時，讓我很不爽的事情（註）。他問我：

「那你要不要來 HappyDesigner 講。」

布丁是 HappyDesigner 的主理人。他邀講者的方式很妙，他不會一開始就公佈完整名單，是滾動式邀約，一直到活動前幾天還在加人。

大家報名通常衝著布丁本人，不管他找誰來講都想聽。

我也是，不管那是什麼活動，因為是他邀的，我就有興趣。

一開始我只知道 Denny 和李怡志老師也會擔任講者，就已經嚇瘋。活動前幾天，我點進活動頁看提醒，發現布丁又加了一整排 lightning talk。海總理、高見龍、Coach 喬、Ming-Cheng Ho。

這是研討會等級吧！

李怡志老師的問卷工具

到了活動現場，我看到好多熟悉的面孔，都是一直以來我很景仰的技術圈神人，再次驚訝布丁的號召力。

最讓我印象深刻的是李怡志老師的 talk。他靠 Claude Code 建了五十個 skill 來做研究，還自己幹了一套 HTML 問卷工具。

他為了讓 conjoint 問卷資料更有效，設計了七種防作弊機制，像是同題左右對調再問一次看答案有沒有變、故意給一組各方面都比較好的選項看你會不會選、設計注意力陷阱直接叫你點 A、用「我很喜歡藍色」這種跟研究無關的問題去抓無腦全勾同一個的人、每題至少看三秒才能按下一步、統計選左邊和右邊的比例看是不是在亂按、全部填完才能送出。

沒有其他問卷系統做到這麼詳細，但這個年代，可以自己做出 100% 符合自己需求的產品，把 AI 變成自己的超能力。

他還說他現在教學唯一的目標，就是讓學生畢業的時候，就是業界前百分之五。

讓我想起最近跑的幾場校園講座，好多眼神黯淡的學生。怎麼說呢？有些學生感覺很想努力做些什麼，但因為再努力也沒用，不如先睡一覺再說。

哎！這個時代太快了，大家都還來不及搞清楚自己要什麼，就已經被推著往前走。教授也很辛苦，課綱跟不上，教材跟不上，熱情也跟不上。

但李怡志老師自己先學會所有工具，和學生一起成長，還能用 AI 做這麼多工具。當他的學生真的很幸運。

其他講者的東西也很有趣。布丁用 agent 寫文件、小海的 Loop Engineering、Chris 分圖層的生圖產品、龍哥重新發明的終端機、Ming-Cheng Ho 在 91APP 做的 harness ，還有喬這個大 E 人從美國回來五個月辦了五十場活動。每個人切入 AI 的角度都不一樣，但都讓我覺得自己好菜。

在家裡客廳說故事

在聽前面幾位的 talk 時，發現他們都安排很多有趣笑點，我突然覺得自己的簡報可能太無聊。

所以我臨時想了一個開場的梗。

結果反應超好。大家笑完之後，氣氛就輕鬆起來，好像在家裡的客廳和大家說故事一樣。我分享了 agent 怎麼自己聊起來、怎麼互相派工作，講完走下來，好幾個人來跟我說很有趣。

這對我來說不是常態。

我不是很會說話的人，總是要很認真的準備才能正常的講完。通常演講完，大家會來問問題，或是說「有學習到，謝謝」。

但那天有布丁主持，氣氛超好。分享完後有人來問細節，有人說他也想做一樣的 agent 協作流程，甚至有人跟我說他笑到肚子痛。

我開心得輕飄飄的。

現場好多熟悉的面孔，是我在 Facebook 看了好多年的那些人。追蹤他們的文章、看他們分享學習經驗、偶爾按讚留言。有些人我只在網路上互動過，從來沒見過本人。結果他們就活生生的站在那裡。

就像你出國很久，終於要回家了，踏出機場的時候聞到一股氣味，皮膚有個熟悉的感受。你說不出那是什麼味道，可能是一種特定的濕度和溫度。沒什麼道理，但你知道，噢！回到家了。

這群人從完全沒有 AI 的年代，一路走到現在 AI 變成顯學。十年前聊前端框架、Design Thinking，現在聊 harness、agent。話題換了好幾輪，但那股看到新東西就想衝的勁，一直都在。

讓人想待到最後的活動

活動結束的時候已經九點多，我通常這時候已經開始尷尬的找外套。

但那天我九點半還在跟人聊天。也不是真的要拿到什麼深奧的新知識，純粹是想和這些人說話。

我很少參加到 Vibe 這麼好的活動。而且出席率居然高達 98%。後來想想，這不是偶然的。布丁做了一件很聰明的事。他挑人。

HappyDesigner 不是報名就能進的。布丁會看你是誰、在做什麼，確保進來的人頻率差不多。所以台下不會有人需要你從頭解釋什麼是 harness，不用花十分鐘新手教學才能進入正題。講者可以直接講自己的 use case、做的選擇、以及成功和失敗的故事。

HappyDesigner 還有一個 Live Demo 文化。布丁鼓勵講者現場實作，還規定講者 demo 出錯要大聲歡呼。

那天真的有幾次 demo 失敗。台上的人略顯困窘，但台下響起全場最大聲的掌聲。那個畫面超可愛的。就像歌手在演唱會上忘詞，台下觀眾直接幫他唱下去。

觀眾也是演出的一部分，挑對人，設定對文化，整個場的溫度就不一樣了。

那天我沒有法式離場。我待到最後，跟布丁一起離開。

延伸閱讀

• 我怎麼辦出 98% 出席率的 HappyDesigner Meetup by 布丁
• Code w/ Claude 東京：Fable 5，與那些願意反對你的 AI
• AppWorks AI Founder Day 筆記：如何在團隊導入 AI
• Claude 活動側記：有人用 AI 養離職同事
• 2026/06/05 活動回顧｜用 Claude Code 打造 App by Justin

我差點就錯過 Code w/ Claude 活動。

我的信箱有四個，公司信箱現在是最少開的，因為夥伴們會處理。但那天在手機上的 Gmail 不小心點到「All Inboxes」，就那麼剛好，看到一封來自 Anthropic 的信。

邀請我去東京參加 Code w/ Claude。

我人在外面，信的內容也沒看完，我已經在填 RSVP 了。我要去。我當然要去。我當天就訂了機票。

連 agenda 都沒看。

說不上來。就好像一個樂團你連續播放了一年，突然有人跟你說他們要來你家附近開演唱會，你不會先問曲目吧！

去年六月開始用 Claude Code，到現在一年了。每天跟 AI 講的話比跟任何人類都多。我是認真的。我一個人跑一個 agent 軍團，五台電腦，八隻 AI agents，幫我處理從社群經營、產品開發到個人記帳、簡報製作的所有事情。聽起來很厲害對吧，但日常其實就是我一個人在家對著終端機說話，等 AI 回我，然後繼續說話。

我跟 Claude 的關係有過熱戀期，也有想摔電腦的時候。他會故意降智，會莫名其妙當掉，很多時候我都覺得 GPT 5.5 還比較好用。而且 Claude 用量有時大方有時小氣，政策混亂，還曾經封鎖過我的帳號五次。真的很生氣。那種生氣是認真的，是會氣到子宮頸癌的那種生氣。

但隔天早上醒來，我總是先想到他。我沒辦法不愛他。

所以當這封信出現的時候，我完全不用考慮。我還因為差點 miss 掉這封信，請我的 agent 開始每天幫我巡公司信箱，即使 99% 的信我都不用處理。遇到問題就叫 agent 解決，這已經是本能反應。

飛到日本是收到信的兩週後。他們就是這樣殘忍，沒給人多少心理準備。而且活動還是早上八點開始。

追星

我參加活動從來不會準時到。晚個半小時是常態，管他的。

但這次不一樣。報到第一秒我就到了，我自己都覺得不可思議。

進去之後看到一塊大大的歡迎牌，寫著「Code w/ Claude」。

我突然有點感動。

就是一塊牌子而已。又不是金城武站在那裡等你。但真的很神奇，就像你追了一個作家追了很久，然後你走進他的簽書會現場，看到他的名字被印在一面布幕上。你知道那面布幕不是他，可是你的心臟還是跳了一下。

當天去的人不多，完全不用擠，他們把大家照顧的很好。每個人都有專屬名牌，上面印著你的名字。Maker Room 擺著迷你電腦，每個人都有一台。會場有整面牆的海報可以讓你挑一張。整天都有餐飲。

會場還有香氛。

木質調，溫溫的，有點像 Le Labo 京都限定款。我覺得如果 Claude 是一個人，他大概就是這個味道。不張揚，但你會一直注意到他在。是一個安心的感覺。

第一場 keynote 是 Boris Cherny，也就是 Claude Code 的 Head。他發表了 Fable 5。現場人不多，大概就是一個中型會場的規模。他看著會場後方提詞機的稿子唸，有點緊張的那種唸法，不像矽谷那些 CEO 練過一百遍的演講。

但我腦中想到的是「這像 Apple 發表會」。我還聯想到前陣子黃仁勳在 GTC 大會的那場發表會。

一個 AI 模型的發表，已經變成需要一個舞台、一群人、一個城市來承接的事情了。我覺得我正在見證歷史。

當他宣布「現場每人送三個月 Max 方案」我還不小心驚呼了。太爽了吧！不過，到現在我還沒收到兌換方式。吐槽一下，Anthropic 的 operations 真的有些混亂。之前辦台灣 meetup 的時候說要送 API credit 也常常沒送。做模型一流，行政大概是用 Haiku 在跑的吧！

後來在聽一場 workshop 時，朋友突然傳訊息：「Boris 在某個攤位。」

我和 Justin 二話不說就從 workshop 衝出去了。

Boris 就站在那裡跟幾個人聊天。我一直告訴自己要冷靜，不要亂說話。我這個人有時候會說出奇怪的話，所以我一直提醒自己說話要經過大腦。要打開 thinking mode。

Justin 和 Boris 聊台灣社群的狀況，我就站在旁邊。

以前辦 ETHTaipei 的時候，跟 Vitalik 合作過。幣圈的神。跟他相處的感覺很強烈，但 Vitalik，怎麼說呢？他怪怪的，你會覺得他活在一個跟你不太一樣的維度。他的天才不是我能理解的。而 Boris 不一樣，Boris 就是一個很正常的人。正常到你會覺得，噢，原來改變世界的人也可以這麼正常。當我跟他說我每天重度使用 Claude Code，他還會跟我說：「那你的 Claude Code 現在也應該正在跑吧！」

「是啊！」

然後我問他：「Claude Code 一開始在公司裡面，是不是不太被看好？它是怎麼活下來的？」

Boris 想了一下，說：「遇到一個很好的 PM。那個 PM 一直在內部喬事情，擋那些不看好的聲音，幫 Claude Code 爭取資源跟時間。直到某個模型發表之後，Claude Code 突然變得很好用，然後一切都不一樣了。」

這就是這個圈子的節奏。你今天覺得不可能的事情，一個月後模型進化了可能就變簡單了。你今天失敗了，別刪掉你的 code，先放著。等下一個模型出來再試一次。

Harness 的正確姿勢

東京的 talk 很豐富。我一邊把簡報拍下來丟給我的 agent，一邊紀錄我的心得。Talk 結束時，agent 已經在手機上幫我整理好重點了。

聽大家分享各種踩雷經驗，有的很有共鳴，有的腦洞大開。我發現，大家都在摸索使用 AI 的正確姿勢，而且，很多環節都還在實驗，還沒有找到真正的 Best Practice。尤其是 Harness，有一百種作法，哪種最好呢？沒有人知道。好像全世界的人一起在瞎子摸象，每個人有不同的解讀和方案。

有一個韓國人分享他們兩個人的團隊做海關貨物歸類的 AI，拿了全球 benchmark 第一名。

他們把傳統海關判斷分類的五個階段拆開，每個階段配一個 AI agent，讓整條推理鏈像專家一樣，用 AI 走一遍。

他們有一次有一批設備，供應商發票上寫著 Industrial machinery part，但這個寫法太模糊了，AI 只好隨機分類到一個看起來不會錯的分類「工業設備」，但那個其實是「醫療設備」。

他們說這是輸入來源太髒。

就像洗衣機，你把髒衣服丟進去，它會幫你洗。但如果你丟進去的是一坨泥巴，它還是會轉，只是洗完還是泥巴。有時候 AI 不會去認真判斷那是髒衣服、還是泥巴。他們沒有被賦予 ownership，他們不 care。

講者分享的解決方式是：

1. 輸入品質要有獨立的 agent 把關
2. 遇到描述模糊就追問，禁止用猜的
3. 一個知道自己可能會錯的系統，比一個永遠很有自信的系統更可靠

另外，一開始他們把所有法規都塞進 system prompt 裡面，結果改一條法規，會弄壞完全不相關的案例。就像你在一本食譜裡面改了一個步驟，結果隔壁頁的另一道菜也變難吃了。後來他們把法規抽出來變成獨立資料庫，用搜尋去找相關法規，再用另一個 agent 去驗證。就順多了。

不用想方設法讓 AI 更聰明，只要讓 AI 像專家一樣思考就好了。

另一場 workshop 講品味的量化。

Koki Yoshida 是 Anthropic 的 technical staff，他做了一個簡報生成 agent，做法是把「這份簡報好不好」拆成兩層來評分：

1. 程式直接拆 .pptx 的 XML，算字數密度、字型層級、有沒有圖片
2. 把每一頁 render 成圖片，丟給另一個 AI 當評審打分數

有了評分標準後，他先用 Sonnet，給他排版規則，限制文字密度、設字型層級、砍掉沒必要的 emoji。然後要求每一頁都要有用 matplotlib 畫的真實圖表，不能只有文字，再用一個 QA 迴圈，agent 自己 render 出來看一眼，覺得不對就修，修完再看，直到滿意，出了第一版。

再把這些流程、Prompt 全部拿掉，回到最陽春的版本，但是把模型從 Sonnet 換成 Opus。 出第二版。

然後，用前面說的評分標準來比較這兩個版本。

哪個好呢？他的結論是這沒有答案（哦耶），可是這個學習是，當你在猶豫「要花時間寫更好的指令，還是直接花錢用更強的模型」時，其實是可以跑個 eval 來測試的。

也就是說，品味是可以量化的（首先人要有品味。欸！）。

當日最後一場是 Bun 的創辦人。他現在加入 Anthropic 了，他們用 Claude Code 把上百萬行的 runtime 從 Zig 重寫成 Rust。他分享了整個過程。以前這種事情只有瘋子才會做，現在 AI 改了成本結構，瘋子的門檻降低了。

我聽了大家的分享，卻覺得心情有點複雜。

我沒有海關的領域知識。我的美感還在培養中。我也不懂 Rust。而看起來，AI 能力乘以領域知識，缺一邊就是零。

我一直知道自己是通才型的人。什麼都碰一點，什麼都不夠深。我能做出 mojo 不是因為我技術最強，是因為我從小就在做產品，懂 growth，懂流程，但這似乎不太算專業領域。換成海關、換成醫療、換成法規，我再厲害的 AI 能力擺在那裡，就像個美麗的廢物。

所以我在想，也許 AI 時代最值得投資的不是學更多 AI 技巧，而是把某個領域真的學深。唔，至少 70 分，深到足以看到出來 AI 在呼籠你，深到能突破 AI 平庸的品味。

工具已經夠強了，差的是你交代給它的那些只有你才有的東西。

珍惜那些願意反對你的人

下午我有約一個 Office Hour，可以跟 Anthropic 的人一對一聊十五分鐘。

我從早上開始一有時間就跟 Claude 一起準備自我介紹、問題清單、如果對到不同角色的人要怎麼轉話題、怎麼在十五分鐘內把最重要的事情講完。我讓 agent 幫我跑了好幾個版本的模擬問答。

結果對到的是 Research Team 的研究員。

但直到面對面才意識到，啊！Research 研究員是開發模型的耶！我應該問更多關於模型開發的 insights，結果問了一堆 Claude Code 問題。有點像你終於見到了一個米其林主廚，結果你問他餐廳的訂位系統怎麼運作。

有點失敗哎！

只好隨意閒聊了。

她說，模型有個性。有些模型很愛附和，你說什麼它都說好棒棒。聰明一點的模型，像 Opus 4.8，比較會跟人類唱反調。Fable 比較平衡，知道什麼時候該挑戰你，什麼時候該配合。他很在意自己有沒有亂講話。

我覺得有點像去剪頭髮。資淺的設計師你說什麼他都說好看，你說想要這個髮型他就幫你剪。老師傅不一樣，老師傅會直接跟你說，這個髮型不適合你的臉型。因為你臉太方。你會不爽嗎？會。但你知道他說得對。他敢說，是因為他真的看得懂。

她還講了 Anthropic 內部的 skills 文化。完全是草根的。沒有人規定要怎麼寫 skills，就是大家自己寫自己用的，覺得好用就分享出來，沒有什麼正式的流程。聽的我很振奮，原來在公司導入 AI，不需要先有完整的流程。邊走邊調整，才是最可行的。

然後她提到 Claude Code 在公司內部其實一開始整個公司不看好，覺得這東西沒前途。現在呢？全公司每天都在用，連做研究的人都離不開。

我跟她說，我去年六月就開始用 Claude Code 了。

她說："Wow, that's early."

欸，明明才一年。但在這個圈子裡，資歷是用月在算的。用了一年，你就已經是早期使用者了。世界轉得太快，快到「很久以前」其實根本沒多久呢！

因為不是美國人

在東京的這幾天，我用了 Fable 5。

我拿它做 app 某一個疊床架屋技術債的重構，還開發了兩個全新產品。它的仔細程度跟之前的模型完全不是同一個等級。就像你之前騎的是 ubike，突然有一次選到一台電動腳踏車 ubike，稍微踩踏你就往前好多，不費力的感覺真的很棒，還不趁現在把一些難的事情都交給他做！

但回台灣的那一個早上，Fable 5 不能用了。

因為不是美國人。

就這樣。區域限制。你不在美國，你就用不了最新最好的模型。抱歉了。

這個感覺很難形容。不是憤怒，比較接近一種冰冷的清醒。你知道這個世界有一條線，線這邊的人可以用最好的工具，線那邊的人不行。這條線以前是錢畫出來的，你經濟能力不夠，你就碰不到頂尖的 AI。現在又多了一條線，你不是美國人，你也碰不到。

AI 時代的貧富差距，可能不只是錢的問題。是地理的問題，是護照的問題。

開源模型在追趕。各種可以跑在自己電腦上的模型越來越多，越來越強。但說實話，現階段本機跑的東西跟雲端的頂尖模型，差距還是很大。也許很快就會改善，也許下一季就會有一個開源模型讓我忘記 Fable 5。但現在不是那個時候，這讓我異常煩躁。

我切回 Opus。其實 Opus 已經很厲害了，GPT 5.5 也很厲害，想做的事情都還是做得了。只是，有一種被降等的感覺，就像你之前坐商務艙飛了一趟，回程即使是豪華經濟艙，你還是會覺得椅子也太硬了吧！椅子沒變，是你的屁股變了。

踏出門

飛回台灣的飛機上，長榮航空說有免費 WiFi，但一直連不上，我只好開始發呆。

我在想，我在 Code w/ Claude 聽了很多 talk，跟很多人聊天，看了很多 demo。我滿意外大家講的東西，我都能感同身受。

這一年來，我幾乎沒有跟任何人交流過這些事情。

每天三點睡，對著電腦說話。我以為自己只是在閉門造車，用一些可能很笨的方式在解決問題。

然後我飛到東京，發現有一群人跟我做一樣的事。用一樣的邏輯拆問題，用一樣的架構疊 agent，踩一樣的坑，然後得出類似的結論。

我不是 CS 出身，沒有在大公司做過 AI，沒有發過論文。我只是一個一頭栽進去的人，靠著熱情跟偏執跑了快一年，然後在某個東京的會場裡，發現自己好像可以坐在這裡。

就像你一個人在房間裡練吉他練了一年，從來沒跟別人合奏過。有一天走進一間 jam session，發現大家在彈的東西你居然勉強可以跟得上。你不是最厲害的那個，但你不是來亂的。你真的屬於這裡。

從東京回來之後，我開始想一件事。現在我的 agent 可以幫我即時翻譯投影片、整理筆記、準備問題清單。下一步我想讓 agent 可以即時聽到我在現場聽到的聲音。語音串流接進去，讓它跟我一起聽講，一起反應。

但是，它沒辦法幫我走進那個會場，沒辦法幫我聞到那個木質調的香氛，沒辦法幫我感受到 Boris 站在面前的那種「噢，是真人」的衝擊。

就像那封差點沒看到的信。下次 agent 會比我先看到，它會幫我篩選、標記、甚至回覆。

但有些事情，還是得自己飛過去。

我常常覺得我是不是走火入魔了。

我一直在逼自己所有事情都要叫 Agent 做，即使很多時候我自己做一下就好了，我偏要先研究工具、研究流程、研究串接。常常搞的效率超差。有時候還失敗，最後灰頭土臉的自己完成。

我常態性的有幾十個 sessions 在跑（註1），龍蝦和 Hermes 那邊也常有進度要看，AI 軍團永遠在忙。

總之，我大部分時間都宅在家鑽研 AI 自動化的可能性，從早到晚。像個神經病。

AppWorks AI Founder Day

不過昨天，我又穿上襪子出門了。

上次是為了 Claude Code 活動（請見 Claude 活動小記），這次是 AppWorks AI Founder Day。

說起來有點不好意思，我其實是 AppWorks 第二屆的穴居人，現場好多有點陌生的熟面孔。噯！時光啊時光。

不過，即使出門我也是黏著手機上的 Moshi 和 Discord（註2）。能讓 AI 軍團隨時連線，手機、iPad，隨時隨地控管，是我最近的得意之作。

進去的時候剛好 Happy 要開始講，我趕緊閃到角落站著聽。

可是聽著聽著，我把手機放下了。等一下，他在講我的故事嗎。

AI 開發的演進

Happy 正在分享 AI 在 91APP 內部的演進歷程。

他們一開始也是把 AI 當作輔助工具。PM 用 AI 幫忙寫需求規格、設計師用 AI 工具做設計、工程師用 AI 輔助寫程式碼。他說 PM 就是 PowerPoint Master，有 AI 之後，就是 AI-Powered PowerPoint Master。

大家一直在講 AI 轉型，但大多數的人可能都還停留在這個階段。可是 Happy 的團隊在多次演進後，他們把單點輔助串成 end-to-end 的工作流。

他說，不管是 PM、設計師、工程師，大家其實都有 ideas，大家一起討論需求，把 prototype 確認好之後，寫程式就全部交給 AI。不同職能、擁有不同 domain knowledge 的人一起做整體規劃，實作全部交給 AI，從此，職能的邊界變模糊了。

我站在角落，發現大家演進的方向好類似。

mojo 現在有新功能，也會先從規劃到 prototype，到 PR 怎麼拆、欄位架構、UX 流程、付費機制，訂好之後跑幾輪 technical review 和 adversarial review（註3），讓 agents 互相挑毛病找漏洞。確認好之後，睡前，帶點不安與期待，按下 Autopilot（註4）。

早上起來，通常細節調一下就可以上線了。你說爽不爽。

你的新同事不是人

然後 Raccoon AI 的 James 也分享他們的 AI Agents。他們公司的 Slack 裡面，養了各式各樣的 AI 助理。叫做學長、學妹等等。還有業務部門會監督大家聯繫次數的老爹。

又一次想大喊「我們也這樣耶！」

因為我也正在往我的公司的 Slack 塞 Agents。我做了一個 GraphRAG，把公司的資料整理起來變成 AI Agent 的大腦，串接各種工具，可以隨時在 Slack 請他幫忙。

我常覺得，以後大家的新同事，有可能常常不是人。而且這些新同事，效率超高，還不會跟你爭升遷管道。

有一位講者講行銷時，提到以前做 segmentation 時，如果想切細來提高轉換率，成本就會提高。因為要寫不同的文案，做不同的素材。切得越細，人的負擔就越重。但現在用 AI，做一種廣告跟做十種廣告的成本幾乎沒差。

一個一個講者聽下來，我有個強烈共鳴感在撞擊。

我們沒有跟任何人說好。我也沒有四處去打聽別人到底都是怎麼做的。這一年來，我只是每天自己一個人在螢幕前說話（註5），不斷修改 prompt，不斷把事情交接給 agents，測試 agents 的極限。

這是一種非常奇妙的感覺。就像是下著大雨的午後，你坐在公車裡盯著車窗上的水滴。那些分散在玻璃各處的水滴，原本看起來毫無關聯，可是當車子往前開，他們都剛好匯聚到同一條粗壯的水痕裡。

大家真的都沒有互相講好，但我們都在往同一個終點狂奔。

團隊的 AI 導入困境

有個講者分享他們公司怎麼推 AI 轉型。他直接下硬性規定，客服的回覆全部只能用 AI 生成，工程師的 code 也全部只能用 AI 寫。覺得 AI 寫得不好？去調 harness，不准自己手動敲。

欸，這太瘋狂了吧！

但那一瞬間我覺得自己超遜。人家孤注一擲，我在旁邊孤注一擲地羨慕。

因為我沒有勇氣這樣子逼我的團隊。

我覺得大家對於 AI 都有一種既期待又怕受傷害的極度矛盾感。

公司就算沒有明講要強制，好像也會無形中給他們壓力。你去問大家，他們都會說有啊、我有在用 AI 啊。可是仔細看，就是拿來生文字草稿、寫提案、auto complete 程式碼、生成文件、查資料。叫他們把整段工作流程從頭到尾交給 AI 跑？真難。

就像是洗衣機裡糾纏在一起的襯衫袖子。經年累月的習慣緊緊咬著彼此，你越是用力去扯，這個結就打得越死，最後甚至會把衣服撕破。

這是我現在遇到最大的矛盾點。

不過 Eugene 提了一個很好的建議。他說公司在轉型的時候，的確會遇到 legacy 的問題。你有一套用了十年的系統，裡面盤根錯節，你很難突然有一天跟所有人說，好，今天開始全部交給 AI 接手。

他的作法是，從一些非常小的新專案開始。讓這個小專案完全被 AI 接管。跑一次漂亮的流程給所有人看。

讓我想到，之前我 demo 給團隊看 mojo 的全自動化系統，本來只是個人小分享，後來團隊也開始自己養 agents 來玩了，也許是個好的開始，也許，不用急？

有了 AI 反而更忙了？

活動結束，我騎上腳踏車。打了電話給我的共同創辦人。

「你看，大家也都這樣做。所以我們做的是對的！」

心情有點複雜。被鼓勵到了，但又覺得好像做得還不夠多。怎麼會這樣呢？已經有 AI 幫忙，但焦慮還是在。

我在活動上也發現創業者們都看起來累累的。我們都以為有了 AI 之後，程式碼它寫，需求它整理，我們應該可以去旁邊喝茶了吧。

結果呢？完全不是這樣。

就像一個在清晨拿著鑰匙插錯孔的人。你滿心以為轉開後會是一扇通往海島假期的門，結果門一推開，迎面而來的是一間更吵雜、電話一直響的辦公室。

我已經強制脫離九成以上的真人會議，卻變成整天和 AI 開會。指派工作。制定流程。規劃分工與協作方式。檢查它們的產出有沒有邏輯漏洞。研究新工具。研究新模型。Harness。Harness。Harness。

還會被人取笑「你不都用 AI？怎麼沒有省下時間啊？」我都很慚愧。

但是，我最近有點領悟到，這根本就是管理一家公司的日常啊！你去看看那些 CEO 或者高階管理者，他們哪有一個是閒著的。他們通常都是全公司最忙、腦袋最常過載的人。

而現在我們每個人都有了自己的 agent team。整天跟 AI 開會，真的只是剛好而已。

效率變得極高，這件事絕對不等於你會變得更輕鬆。因為你要管理的範疇變大了。你的精神消耗，有時候甚至比以前自己動手寫程式還要巨大。

這都是正常的，因為我們變成了我們自己專案的 CEO。

所以，我想跟所有在和 AI Agents 奮戰的人說：你不寂寞。我們都默默在走一條以前沒有人走過，但方向完全一致的路。而且這條路真的比想像中累非常多。

噢，既然你現在是 CEO 了。請務必好好照顧自己的身體。記得多吃點飯。記得多喝點水。記得定時離開那張該死的人體工學椅去走走。

這句話其實也是我在對我自己說的。

我們都在踩一個停不下來的飛輪。在這條路上，偶爾抬頭遇到同樣在滿頭大汗踩飛輪的人，知道自己不是一個人。

感覺還是挺不錯的。

如果你也在這條路上。如果你也覺得自己變成焦慮的 CEO。跟我說一聲。

註1、這邊的 session 指 Claude Code、Codex、Gemini（已改為 Antigravity）的 sessions。我三種都掛在家裡的 Mac Mini，用 tmux 串 mosh，隨時連線。

註2、Moshi 是專門設計給 tmux/mosh 連線到家裡 terminal 的好用工具。

註3、Technical review 推薦使用 /tech-vetting，他會偵測這次規劃的 tech stack，呼叫 context7 找最新文件和 best practice。Adversarial review 推薦使用 /second-opinion ，他會用幾個不同角度的觀點質疑你的規劃。都在 solopreneur。

註4、/autopilot 是類似之前的 loop、現在的 workflow 的機制，會先確認規劃的夠不夠完整，並跟你確認 PR 的拆分方式，然後自己開 worktreee 開始工作。最久一次跑了三天。Skill 下載。

註5、我現在用語音輸入比較多，主要以 Typeless 為主。已經很少打字了。

不是某一句話讓我不舒服。

是一種表情。

我在很多地方看過那種表情。有時候是身邊的人，有時候是某個活動上坐我旁邊、剛認識五分鐘的人。場合不一樣，臉不一樣，但表情一模一樣。

對話通常長這樣。我說我有在用 OpenClaw 養一些 AI agents。對方先是停了一下，然後右邊嘴角往上拉一點點，用一種很輕的語氣說：

「現在不是沒人用 OpenClaw 了嗎？大家都用 Hermes 了吧？」

我那時候在幹嘛？我通常什麼都沒做。只淡淡地說一句：「噢，我兩種都有用。」

聽起來很平靜對吧。表面上是很平靜。

但他們講出「Hermes」的時候，臉上那種驕傲，那種我站在比較對的那一邊的驕傲，老實說，真的讓我有點想吐。

那感覺有點像是吃到一口不新鮮的東西，當下還沒反應過來，飯後站起來才突然反胃。

大家都用 Hermes 了吧？

我後來想了很久，為什麼我非要覺得不舒服。

老實說，有一點受傷。被瞧不起的感覺騙不了人，我用 OpenClaw，在他眼裡好像就矮了一截。我還要強調「我也有用 Hermes 啊！」到底想跟誰證明什麼 😂？

而且，會擺出那種表情的人，幾乎清一色是新手。我玩 agent 的時間比他們長太多，我燒掉的 token，大概比他們這輩子吃過的鹽還多。我最受不了那種只懂一點點，就急著大放厥詞的人。

不過這都還不是最讓我介意的。

最讓我介意的是，當我想繼續跟他們討論 Agents 的使用心得，他們總是說不出個所以然。最後都會發現我們根本不在討論工具。比較像在說「你怎麼還沒跟上？」

你品一下這句話。它預設了好幾件事，而且每一件都很討厭。

它預設新的工具天然比較高級，舊的工具天然比較丟臉。它預設每個人都應該追最新的東西，不追就是不懂。它預設這個圈子有一個正確答案，而你不在正確答案那一邊。

最噁心的是最後一層。它把一個技術選擇，偷偷換成了一場身份審查。

你用什麼工具，變成你是哪種人的證明。用 Hermes 的是跟得上的人，是 insider，是知道現在大家在玩什麼的人。用 OpenClaw 的是沒跟上的人，是資訊落後的人，是需要被糾正的人。

工具本來是拿來解決問題的。結果一群人把它拿來當徽章別在胸口，像小學生在比誰的鉛筆盒比較新。

欸，這就很煩。

你根本沒問我拿它們在幹嘛

那個說「你怎麼還在用 OpenClaw」的人，從來沒問過我拿這兩套東西在做什麼。

OpenClaw 我用在幾個產品的全自動化經營，包含一個叫做 mojo 的 App。

mojo 的產品數據分析、社群經營、客服、趨勢分析、輿情監測、使用者回饋、Email 自動化行銷的處理，是 OpenClaw 帶著幾個 Claude Code bots 一起在做。它們會分工、互相丟訊息，在我睡覺的時候繼續工作。

Hermes 我用在個人數位分身。

她叫 Nana，她正在一點一點接管我個人的事。記帳、記錄我每天吃了什麼、整理信箱、排旅遊行程、整理備忘錄、幫我盯 Apple 整修品、整理我的 llm wiki、幫我讀新出的研究。她甚至接得住我突然其來的心理諮商需求。

這是一個對內的、貼著我這個人長的系統。她不用協調一整個公司，她只要越來越懂我一個人。

我兩個都用很深。

但那些人連我手上有哪些件事都不知道。他不是知道答案以後否定我。他是連問題都沒問。

所以到底哪個好用？

這裡要先講清楚一件事，不然我會被說成 OpenClaw 信徒在護航。

OpenClaw 跟 Hermes，是真的競爭對手。

它們不是一個是筆、一個是冰箱那種沒辦法比較的東西。它們用很類似的方式，在解同一類問題：怎麼讓一個 AI agent 變成可以長期運作的助理跟系統，而不是一個你聊完就關掉的對話視窗。

所以它們可以比較。它們本來就在比。

它們甚至會互相抄功能。Hermes 有個很潮的東西叫自我優化，agent 用一用會自己把技能改好。這功能出來之後沒多久，OpenClaw 也跟上了。你抄我的、我抄你的，這在工具世界裡很正常，這才是技術在往前走的樣子。

所以問題從來不是「誰比較新」。它們的功能差距，沒有大家想像的那麼線性。

問題是它們的取向不一樣。它們在不同的地方，做了不同的取捨。

OpenClaw 強的地方

我沒有要做一個 OpenClaw vs Hermes 的徹底比較，網路上太多了，大家可以自己查。

我只想講一個小案例。

我一直在嘗試讓有各自不同專長的 Agent 們互相協作。可是，一群 agent 在同一個 Discord 裡做事，最難的不是讓它們會講話。是讓它們知道什麼時候該閉嘴。

這個觸發邏輯簡直是種藝術，決定了什麼時候該開口、什麼時候不要插話，就和做人一樣難。

OpenClaw 可以把這件事設到很細。我可以設定某個頻道不用 tag 它，它也會自己跳出來回。可以設定另一個頻道一定要 tag 它才會回。我甚至可以設一種很微妙的狀況：這個頻道平常它免 tag 就會回，但只要我去 tag 了別隻 bot，它就自動閉嘴，不要插話。

最關鍵的是，OpenClaw 可以讓 agent 自己判斷這一則到底要不要回。即使有上述的設定，我還可以在 harness 層給他判斷邏輯，有些狀態要閱讀空氣，該回回，不該回就不要多嘴。

你可能覺得這聽起來沒什麼。但你想像一下，如果每隻 agent 都被訓練成「有禮貌、要回應」，那 A 回 B、B 回 A、A 又回 B，兩隻機器人會在那邊無限客套下去，token 像開著的水龍頭一樣嘩啦啦流掉。

能讓 agent 自己決定「這句不用我接」，那個迴圈才停得下來。夥伴們才不會為了禮貌互相鞠躬鞠到打烊。

還有更多細節功能。像是 OpenClaw 可以把自動開 thread 這件事單獨設定，可以讓開出來的 thread 自動取一個合適的名字。

Hermes 在這一塊，就只有「要 tag」跟「不用 tag」兩種。自動 thread 沒辦法單獨設，thread 自動命名也做不到。我想要那種顆粒度，得自己去 patch。

這就很像有人看到你開手排車，順口說一句：「現在不是都自排了嗎？」

可是他不知道你是在跑山路。

你要的根本不是方便。你要的是每一個彎、每一次降檔都在自己手裡的那種控制感。自排很好，自排適合大部分人。但你今天的需求，剛好就是手排能給、自排給不了的那個東西。

Hermes 強的地方

講完這個，我得馬上講 Hermes 好在哪。不然就不公平了，而且我真的不是 OpenClaw 鐵粉。

Hermes 最厲害的不光是整個架構比較單純，還有她的自我學習。

前陣子我在排九月的紐約行程。規劃到一半，Nana 一邊跟我聊，一邊自己長出了一個排行程的 Skill。是照著我的個人喜好捏出來的，我喜歡怎麼排、在意什麼、不要什麼，它全記進去了。

過幾天我跟它說，接下來要規劃六月的日本行。

它直接就把那個 Skill 拿出來套，自動幫我把行程資料跟建議都整理好。我什麼都不用重講。

我那時候愣了一下。

噢。原來這就是自我優化做得好的樣子。它不是把功能列在規格表上給你看，是真的在你用的過程裡，悄悄把自己變得更貼你一點。像一個跟你住久了的人，你還沒開口，他已經先把你的杯子放到你習慣的那個位置。

還有，我現在會用 AI 分析飲食，匯入 mojo，我只是有一次請 Nana 幫我分析，之後我只要傳食物照片，她就知道我是要請她分析，她會一次分析好後，直接讓我匯入 mojo。記錄飲食從來沒有這麼方便過。

而這正是 Nana 該有的樣子。她是我的分身，她的任務本來就是越來越像我、越來越懂我。Hermes 那種會自己長、會記住你的特質，剛好就長在這個需求上。

還有一個很現實的好處：Hermes 是一個 gateway 配一隻 agent，安裝跟管理都單純很多。OpenClaw 那種一座 gateway 塞一堆 agent 的架構，能做的事多，但也肥。

Hermes 在架構上，就是比 OpenClaw 乾淨、簡潔、優雅。這是 OpenClaw 沒辦法做到的，因為 OpenClaw 已經是一個長很大、背了很多歷史包袱的程式了。新生的東西沒有包袱，這是它天生的優勢。

舊時代的包袱 vs 新架構的天真

坦白講，我覺得目前仍是各有各的好，也各有各的代價。沒有哪一邊是全贏的。

這兩套我都用得很兇。用久了會發現一件很實際的事，常常是這個功能那邊有、這邊偏偏沒有，再換一個場景又整個反過來。我會一邊用一邊在心裡碎念，這個 Hermes 有、OpenClaw 怎麼沒有，那個 OpenClaw 設得到、Hermes 又做不到。沒有一邊是永遠贏的。

真正兩邊都摸熟的人，是不會輕易講出「大家都用 X 了」這種話的。因為他知道，事情根本沒那麼簡單。

OpenClaw 那些我講不完的細部設定，不是哪個天才設計師坐在白板前一次想出來的。它們是一堆人，用了很久，撞到各式各樣奇怪的狀況之後，一個一個慢慢長出來的。

所以當別人說 OpenClaw 過時的時候，他其實看到的東西，叫做「成熟」。

成熟跟過氣，在外行眼裡長得很像。都是沒那麼新。

但它們是相反的東西。過氣是被時代淘汰了。成熟是被時間磨出來了。一個是該丟，一個是難得。

把成熟看成過氣，是這個圈子裡最懶的一種判斷。即使很多狀況新的都比舊的好，但極簡化事情的判斷、不去理解任何細節就下結論。省事是沒錯，但是腦殘。

AI 圈的鄙視鏈

把鏡頭拉遠一點，你會發現這根本不是 OpenClaw 跟 Hermes 而已。

整個 AI 圈，正在長出一條長長的鄙視鏈。

用 ChatGPT 網頁版的人，被說不夠進階。用 Claude 的人，覺得只會用 ChatGPT 的人很嫩。用 Cursor 的人，覺得用 Google AI Studio 的人太遜。用 Claude Code 的人，覺得 Cursor 這種 GUI 太鳥。自己架一整套 agent stack 的人，覺得所有用現成 SaaS 的人都不夠純。

然後每一層的人，都覺得自己是比較懂的那一群。

問題是，這些鄙視，大部分跟你到底有沒有把事情做出來，一點關係都沒有。

它比較像健身房裡那些人，互相在比誰的水壺比較專業。水壺再貴，也不會幫你多舉起一公斤。

最荒謬的是，喊得最大聲、最愛分高低的那些人，很多根本沒碰過真正複雜的需求。他們沒有試過讓一群 agent 在同一個頻道裡不爆炸，也沒有試過把一個分身穩穩接進自己的日常生活。

他們不是知道答案以後選了某一邊。他們是連問題都還沒搞懂，就先選好了要站哪一隊。

因為站隊很簡單。理解很難。

「我用 Hermes」可以變成一句暗號，告訴所有人我有跟上、我在圈內。「你還在用 OpenClaw」可以變成另一句暗號，告訴所有人你落後了、你該被糾正了。

這不是技術討論。

這是社交排序，只是套了一件技術的外衣。

工具不是徽章

講了這麼多，我想說的是，我不反對 Hermes。Hermes 真的有它很強的地方，我自己天天在用，Nana 就跑在上面。我也沒有要說 OpenClaw 比較高級，它就是個又肥又老、背了一堆包袱的程式。

我反對的只是把工具的選擇，變成人的階級。

新工具當然可以試，技術當然會演進，Hermes 在某些地方也真的更好。但「更好」這兩個字，應該要回到具體的問題上面。

對誰更好？在什麼場景更好？換過去要付出什麼代價？我現有的流程會不會斷掉？我換到手的，到底是真的能力，還是只是一個比較新的標籤？

如果你想了一輪，答案只剩下因為大家都在用，那它其實跟買一個當季流行的包包差不多。

不是不能買。買了也很開心。但別把它包裝成一個技術判斷，然後拿去笑用舊包的人。

工具沒有黃金跟垃圾這種二分法。很多時候，它們只是兩種不同的妥協。會去看那個妥協長什麼樣的人，比只會看誰潮的人，走得遠太多了。

說起來還有點好笑。

此刻 OpenClaw 正帶著一群 bot，幫我經營 mojo。而這篇抱怨文章，是我和 Nana 完成一輪心理諮商後寫下的。

一個在幫我賺錢，一個在幫我清理內在垃圾。兩套被人分了高下的工具，其實都沒空理誰比較潮。它們都在做事。

下次再有人用那種表情問我「你怎麼還在用 OpenClaw」，我大概還是會淡淡地說一句，我兩種都有用。

差別是，這次我心裡很清楚。

落伍的從來不是那個工具。

是那種懶得理解、只想分高低的眼光。

最近總覺得自己很廢。

我的第二個產品 innie 已經開始五個月了，砍掉重練了四次，還是沒找到我滿意的方向。而 mojo 的活躍使用者成長滿快的，但 MRR 看來已經到平台期。即使做了許多新功能、很多 user 說多棒多棒，但收入... 沒什麼變多耶！

為了讓家裡的貓咪有更多罐罐，我開始研究和 revenue 有關的策略。包含新的 business model、onboarding 優化，還有 Email 行銷自動化。我的天，為何不是第一天就最關心這個呢？

這些策略需要很多的規劃。想當然，是請 AI 做。

於是，上週我請 Claude Code 幫我規劃整套 Email 行銷自動化方案。它非常認真，認真到我懷疑它是不是偷偷喝了我桌上那杯已經冷掉的咖啡。提案丟回來那一瞬間，Claude Code 給我兩百多行的 markdown，標題、子標題、bullet points、edge cases、testing strategy，排得整整齊齊，像新兵入伍那天的內務櫃。

我盯著那片密密麻麻的字，心裡只浮現一個聲音。

幹，我不想看。

老實說真的不想看。但又不能不看。因為如果我不看就放行，那所謂 human in the loop 根本是個騙局，我只是 loop 旁邊的吉祥物，揮揮手讓程式碼一路滑下去。

每次這樣囫圇吞棗按 yes，後面就會在某個禮拜三的凌晨兩點，用一個我看不懂的 bug 來敲我的門。就像網路上大家嘲笑的 Vibe Coder 一樣丟臉。

慢性懶惰

這種狀態維持了一陣子。

明明知道冰箱深處的優格已經過期，每天打開又關上，每天告訴自己「下次再處理」，結果下一次的我跟這一次的我一樣懶，只是老了二十四小時而已。優格依然在那裡，靜靜地、不發一語地，朝某個誰也看不見的方向慢慢壞掉。

Agent 丟過來的 proposal 也一樣。

它躺在那裡，等待我審核。它不催我，不會敲我桌子，也不會在我臉書留言或是 Line 我。它只是安靜地占據我的終端機，等待我用一個 yes 或者 no 打發它。

可我心裡很清楚，那個 yes 不是一個普通的 yes，那是一個會在未來某個時刻，從草叢裡跳出來咬我屁股的 yes。

於是我發明了一個小技巧。我請 Claude Code 把提案寫成 markdown，推到 GitHub。然後我點進去，GitHub 會把它渲染得漂漂亮亮，字級分明，code block 有 syntax highlight，看起來像一份正經的工程文件。

像這樣：

確實比 terminal 好讀。

但說真的，還是不夠。

因為它本質上還是一份文件。一份要你從頭讀到尾的文件。當你的 agent 一天丟給你五份這種文件，你還是會在第三份的時候開始恍神，第四份開始看到文字段落自動跳過，第五份直接 cmd+w 關掉它，然後對自己說「明天再看」。

殊不知，明天的我，依然跟今天一樣懶。已經這樣連續卡了三天沒有進展，產品 conversion 當然一點兒動靜都沒有。貓咪的罐罐已經快吃完了。

Markdown 已死？

就在這時候，我看到 Claude Code 的 Thariq 寫了這篇標題很欠揍的文章：「The Unreasonable Effectiveness of HTML」。

大概是說：「Markdown 曾經是 agent 跟人類溝通的預設格式，因為它簡單、可攜、好改。但隨著 agent 能做的事情越來越複雜，markdown 開始變成一種限制。我幾乎已經不寫 markdown 了，我都讓 Claude Code 直接吐 HTML artifact。」

他舉了一堆理由。HTML 可以放表格、可以放 SVG、可以放互動元件、可以放 CSS 上色、可以塞 JavaScript 做 slider、可以丟 S3 給同事看。最戳我的一句是：

「超過一百行的 markdown，我自己都讀不下去，更別說讓公司其他人讀。」

這不就是我嗎？

這篇文章出去之後，網路上立刻吵翻天。

有人說「Markdown is dead」，有人說「HTML is the new Markdown」，有人說 Anthropic 要拋棄純文字格式了。

Hacker News 上一堆人跳出來反駁，說 HTML 的 diff 太吵、原始碼太難讀、人沒辦法直接 co-author、長久看會讓人類退化成「只看 agent 產物的旁觀者」。Kurtis Redux 寫了一篇直接叫〈The Unreasonable Ineffectiveness of HTML〉，標題就是用來打 Thariq 臉的，裡面有一句話我看的冷汗直流：「If you stop reading source, you're outsourcing your thinking.」

如果你不再讀原始檔了，你也等於把思考外包了。嗚。

就在 Thariq 那邊喊著「HTML 比 markdown 好」的同時，Cloudflare 推出了一個剛好反方向的東西，叫做「Markdown for Agents」。它讓網站可以對 AI crawler 直接吐 markdown，而不是吐整包 HTML。

因為同一篇文章，HTML 大概 16,000 tokens，markdown 只要 3,000。對 agent 來說，HTML 那一堆 <nav>、<script>、CSS class 全部都是雜訊，吃 token 又看不懂重點。

所以，我覺得是這樣的：

• 給 agent 讀的，markdown 比 HTML 好。
• 給人讀的，HTML 比 markdown 好。

地圖集與導航

​我感覺 Markdown 比較像地圖集。每一頁都清清楚楚。台北、新北、桃園，山脈、河流、巷弄，每一條紅線藍線都在它該在的位置。完整、精確、可保存、可影印，你十年後翻開它依然是同一本地圖。

問題在於，當你只是想去某家咖啡店，你得自己翻目錄、找頁碼、對座標、計算路線、估算公車要轉幾次。如果你只是想喝一杯拿鐵，這套流程會直接讓你打消念頭不去也罷。

而 HTML 是 Google 導航。

你不需要把地圖讀完，才知道怎麼去那家咖啡店。你輸入目的地，它幫你把你現在需要看的那一段地理資訊即時組合出來。你可以放大看路口的紅綠燈，可以縮小看整段路花幾分鐘，可以切到 satellite 看實景，可以點公車圖層查有沒有捷運。每一個操作，都不是要你讀完整本書，而是讓你用這份資訊做下一個決定。

但這不代表 markdown 就死了。

因為當 agent 跟 agent 之間在傳東西、或我自己想直接改點什麼、或我要把這東西塞進 git history 留十年，Google 導航就變成一個累贅。它太重了。它要的東西太多了。它把資訊變成介面，但也把可編輯性、可 diff、可長期維護的特性犧牲掉了。

地圖集當然沒有要消失。測量員需要它、登山客需要它、收藏家需要它、收訊不到的山溝裡你也需要它。Google Maps 背後那份資料的祖先依然是它，你看到的每一條導航路線，最深處都來自某個誰測量過、繪製過、寫進地圖集裡的真相。

這兩個東西，本來就不該比較。

Markdown 是用來思考的格式，HTML 是用來呈現的介面。一個是 source of truth，一個是 surface of consumption。

來個今日金句（Claude 幫我寫的）：

Markdown 是腦內筆記，HTML 是展示面板。
不要拿展示面板取代腦子，也不要要求腦內筆記長得像 dashboard。

吵 markdown 還是 HTML，其實是在用舊問題理解新工作流。AI 時代真正重要的，不是選一個格式當神，而是知道，什麼時候需要 source，什麼時候需要 interface。

/Preview Skill

所以我做了一個 skill。

那天晚上，客廳有群朋友在玩賽駱駝玩得哈哈大笑，外面下著那種斷斷續續、像有人忘記關水龍頭的雨。我坐在書桌前，泡了第二杯乳清蛋白，腦袋裡只有一個很單純的念頭：

「我要叫 Claude Code 把每次寫的提案，自己 render 成 HTML 給我看。」

不是要它放棄 markdown。markdown 還是要存在，那是它跟自己對話、跟其他 agent 對話、跟 git 對話的方式。但當它要跟我這個血肉做的、會累、會懶、會在禮拜三凌晨被 bug 敲門的人類溝通時，請給我一條生路，不要再把整本地圖集塞到我臉上。

我把這個 skill 叫做 /preview。

它做的事情很簡單：把目前的提案（不管原本是什麼形式）轉成一個強調「人類可快速理解」的 HTML。會有 tabs、cards、表格、流程圖、互動元件。如果提案是 workflow，它會畫成一張可以點的流程圖。如果是設計方案，它會 side-by-side 排出來讓你比較。如果是技術規格，它會把 code snippet 折疊起來，只露出你需要 review 的關鍵段落。

我還加了 comment 功能，像 Google Doc 那樣，可以反白一段文字、留下評論。整份 review 完之後，按一個按鈕，所有 comments 會打包成一段 markdown，貼回 Claude Code，它就知道我哪裡有意見、要它怎麼改。

很輕量。沒有任何雲端帳號、沒有 login、沒有資料庫。

如果你有設定 Vercel，它還可以一鍵部署，生一個網址給你。我在樓下排隊買黃金麵線的時候，就可以拿手機點開，看 agent 提的方案，順手留兩個 comments，用 moshi 或 Claude 官方的 remote control 貼回去。

我終於不再是個笨重的 blocker。

終於按下 Yes 了

Skill 寫完後，我把那份 Email 自動化行銷的提案，丟進去用 /preview 跑一次。

Claude Code 跑了大概三十秒，吐出一個 vercel 連結。

我點開。

整份兩百多行的 markdown，被重新組織成一個有五個 tab 的小頁面：總覽、workflow 流程圖、欄位設計、邊界條件、實作步驟。每個 workflow 都被畫成可以點開的卡片，點下去會展開更詳細的條件分支。資料表是真的表格，不是 ASCII 拼出來的那種。風險點被標成紅色的小標籤，掛在對應的步驟旁邊。

我看了大概四分鐘。

四分鐘。比我之前對著 terminal 凝視三十秒、然後關掉、然後內疚一整天，短了一輩子。

而且我真的看完了。不是假裝看完，是真的看完。我留了七個 comment，貼回 Claude Code，它改了三個地方、跟我 argue 了兩個地方、坦承忘了一個 edge case。

那一刻我突然覺得，它跟我之間的溝通順暢好多。他不再是它丟一份巨大的東西過來、我假裝翻過、然後悄悄把它推到桌子角落。

雨還在下，斷斷續續的，像某個忘記關水龍頭的鄰居。我喝了一口已經涼掉的乳清，已經有點苦，但那是一種我願意承擔的苦。

後話

我把這個 skill 開源了，丟在 GitHub。是 solopreneur 的一部分，如果你跟我一樣 LLM App 開發者，可能適合你。

你也可以單獨裝 /preview skill，原始檔在這：Soloreneur: /preview。

我沒有要說服任何人 markdown 應該被取代，也沒有要說服任何人 HTML 才是未來。

我只是發現，當你的同事變成 AI，文件這個東西就該長得像介面。

文字會議紀錄變成可點擊的 dashboard。spec 變成 mockup。code review 變成有圖有真相的 walkthrough。研究報告變成可以拖拉比較的 playground。這些東西不是要取代 markdown 的儲存價值，而是在 markdown 之上，多生出一層「人類可消化」的薄膜，給我們這些懶人一線希望。

至於那個被我放置好幾天的 Email Marketing 規劃，我終於讀完了。現在已經實作完成並上線，花費 Claude Max 方案 5% 的 token。期待可以帶來一些轉換。

而那盒過期的優格，我終於把它丟了。

最近我都不太出門。

也不是最近，自從去年夏天對 Claude Code 上癮之後，我都不太出門了。因為，出門意味著穿襪子，意味著要闔上電腦，意味著要對人類微笑。

老實說週六我也不太想出門。前一晚和 Claude Code 一起弄到凌晨四點，mojo 的 drip marketing 某個 trigger 有個奇怪的 bug，用三個 subagents 輪番找洞，最後 Claude Code 和 Codex 終於一起把問題定位在一個我從沒注意過的 race condition。

修完之後我躺在床上看著天花板的髒污，一邊想著「那不是蟲，我已經確認過了」，一邊也想「靠，沒有 AI 我怎麼活」。但又有點得意，覺得我用 Claude Code 應該爐火純青了吧！

然後就睡著了。

隔天，我勉強著起床，確認 tmux 都掛好了，然後出門。我實在太愛 Claude，甚至願意穿上襪子。

我那時還不知道，我以為我很熟悉的東西，其實有著我不了解的千面。

新手工作坊

進到會場才想起來今天是新手場。

也就是說，房間裡除了我們這幾個 panelist，大部分的人是剛開始接觸 AI、剛開始用 Claude、剛開始想搞懂這一切到底是什麼的人。

我坐下來，仔細看了看端坐著的大家，感受到一個東西。

焦慮。

不是那種尖銳的、可以立刻指認的焦慮，是一種比較沉的、瀰漫在空氣裡的東西。提問的時候有人會說「我看別人都在用 agent，我才剛搞懂 prompt 怎麼下」。有人會說「新工具一直出，根本追不完」，有人會說「Claude Code 黑黑的看起來好難怎麼辦」。

那種焦慮我太熟了，它有一個很具體的形狀。

像是一個人已經用盡全力在跑，跑到肺都快炸了，然後低頭一看，發現自己好像還在起跑線上，一點都沒有往前。

我有點愧疚，我們今天分享的，會不會反而讓他們更焦慮？

我想了很久該怎麼接這個情緒，後來想到一句話。我沒當場講出來，但我想透過這篇文章告訴每一個有那種感覺的人。

不用急。真的不用急。

新工具一直出，你追不完，我也追不完。沒有人追得完。

那些看起來跑很快的人，只是他們先選了一個方向跑，然後堅持下來而已。沒有什麼「正確的進度」，只有「你跟 AI 之間的關係」。

把它當好朋友、好夥伴。每天跟它聊一聊、把你的目標跟它說、把你卡住的地方跟它說。默契是慢慢養出來的，不是讀完一篇 prompt engineering 文章就能擁有的。就像你不會因為讀完一本「如何交朋友」的書就突然有了好朋友，你只會因為持續地、笨拙地、誠實地跟某個人相處，然後某一天發現你們之間有了什麼。

AI 也一樣。

我自己的焦慮比較像是興奮，每天 AI 都可以幫我多做一點事，我就可以騰出手去做更多新的東西。像是手上多了一個超能力，而我每天都在試試看這個超能力今天又長大了多少。我的焦慮只有兩種：token 用不完，以及 token 用完了。XDD

什麼東西不交給 AI？

接下來到了 Panel 場。有 Justin、電獺大叔謝綸、Dawson 和我。我們討論了如何上手、如何設定邊界和權限、如何規畫工作流。

主持人 Eason 有補問一個問題是「有什麼是你不會交給 AI 的？」

本來不知道怎麼回答，不過，在別人回答的過程中，我快速整理了我的答案。

一、策略

AI 真的很厲害，但他畢竟只靠你給他的片段資訊就飛快的下結論，通常這些結論聽起來都很有道理，可是，他看不到你三個月前跟一個使用者吃飯時，對方順口的一句抱怨，看不到你五年前從某個失敗的痛苦中，學到的小秘技，也看不到市場底下某種正在悄悄變化的氣氛。

策略是一種長期的賭注，包含個人觀點、判斷、直覺、人生經驗萃取出來的，這些都不是 context window 可以塞的下的。

二、架構

要把產品做成好維護、不容易出錯的系統，需要優雅的設計，包含資料庫結構、資訊流程、商業邏輯、tech stack 選擇。這些可以和 AI 討論，但不能讓他決定。因為他會漏掉你真正在意的事情，哪些地方應該要簡單做、哪些地方需要好擴充。架構錯了，寫的再快也是要一直還債。

三、品味

這是我覺得最關鍵的一點，AI 能做出最好的東西，天花板就是你的品味。你給它什麼參考、什麼風格、什麼細節要求，它就回給你什麼。它不會自己長出品味。比起各種 skills 的那 66 種風格，你獨一無二的品味才是能讓你與眾不同的重點。

Justin 有提到一個我也覺得很有道理的，就是「喜歡做的事情不要交給 AI」。

我就是這樣，即使大部分時候我會開 10 到 20 個 sessions 同時進行，但某些事情我就是要親自做。比如說，我喜歡調介面間距、調文字大小、調圓角的弧度。我喜歡調整文案、調整功能的 onboarding flow。

AI 能做，但我不要它做。喜歡一件事本身就是一個不需要解釋的理由，就像你喜歡一杯特定咖啡店的拿鐵，不會因為便利商店有更便宜的就改喝便利商店。喜歡是一種微小但堅定的偏執，而我覺得人活著就是要保留一些這種偏執，不然剩下什麼？

講完這些的時候，我覺得對自己有點滿意，我以為這些應該是 panel 最有料的了。結果，後來大家講的，才真的是讓我印象深刻。

AI 的奇思妙想

Eason 又問大家都拿 AI 做什麼？

謝綸分享了他們蒸餾同事的作法。

這個在 Github、X 社群其實已經紅好一陣子了，可以蒸餾前同事、前男友、名人思想等等。比如說，把前任在通訊軟體留下的所有對話、語氣、口頭禪餵給 AI，讓它生成一個能模仿這個人講話的 bot。失戀的人拿來自我治療，用熟悉的口吻把該講的話講完，然後關掉視窗，終於放下了。

有興趣可以參考這個 Skill：https://github.com/titanwings/colleague-skill

謝綸的作法是，當一個工程師或行銷人離職，他會把這個人在 Slack 的所有對話、信件、原始碼，全部餵給 AI，讓 AI 用六種不同角度生成這個人的思考模式，做成 Slack bot。同事走了，但「他」還在群組裡，呼叫他的話，他就會用原本的方式回應。

本來覺得這是個網路上的噱頭，但我真沒想過可以這樣幹，可以提昇士氣、可以拿到不一樣的觀點，甚至可能變成一種公司文化呢！

另外，讓我意外的是，許多來賓都有提到用 AI 算命、情緒諮商。

我之前做過一個《Billions》裡 Wendy Rhodes 的 AI agent。她在劇裡是 performance coach，專門和每天都在高壓環境工作的交易員諮商。我工作壓力大就跟她聊，她會用那個角色的視角回應我，引導我深入了解每個情緒背後連結的內心石頭是什麼，然後用我的原話每天幫我生成日記。我曾經跟她聊到流淚。AI 提供的情緒價值，在某些時刻是真的接得住人的。

其他人的用法有好多我都沒想過。Eason 說他每天會問 AI 今天的運勢、該穿什麼顏色、適不適合社交。有人結合玄學做了現代版農民曆。有人每天 emo，用 AI 做心理諮商。

大家都以為 Claude Code 是工程師的玩具，但算命本質上就是大數據整理，把一個人的生辰、選擇、過去的軌跡，丟進一個解讀框架，輸出一個敘事。AI 做這件事可能比某些半路出家的命理師還準。而且，大家對於情緒價值的需求，比表面上看起來的大多了。

我有個奇怪的感覺，我以為我跟這個朋友已經很熟了，沒想到他跟別人在一起時，居然能變出我沒看過的特技。我對於 AI 能做的事情的想像，還是太小了。

我們都在學習和 AI 相處

Panel 結束時已經傍晚，我要趕車回高雄過母親節。天色有點陰，Uber 叫了不來。我站在門口等車，覺得心理有某個東西不一樣了。

我總是一個人在家研究，有時會覺得自己無所不能，有時會有點孤獨。但這個活動的每一個人，都在用我沒想過的方式和 AI 相處，我以為我知道很多，但我其實什麼都不知道。

有人拿來蒸餾同事、有人拿來算命、有人拿來做情緒陪伴、有人拿來自動化整間公司、有人做很多 skill 來讓流程更順。他們都不是在問「AI 可以幫我做什麼」，而是「AI 可以變成怎樣的存在」。前者把 AI 當工具，效率有上限。後者把 AI 當新的物種，沒人知道天花板在哪。而今天其他來賓們，都已經在把 AI 用在我所沒想到的地方。

去高鐵路上，我打開手機看一下 tmux 的 Claude Code 進度，突然覺得，這些默默幫我看家的同事好可愛。今天活動中的其他人，也都有他們的同事夥伴，我們每個人都在用 AI 養出一些奇怪但溫柔的存在，陪我們把日子過的稍微好一點。

AI 是不是未來呢？我不知道，但他已經是我的現在。

而現在，很多人忽略的角落裡，正悄悄長出來一些連我們自己都沒預料到的形狀。

六月 Claude 官方活動推薦

如果你也是那種聽到 AI、聽到 Claude Code、聽到一堆新名詞會覺得「我是不是已經太晚了」的人，我想跟你說兩件事。

一、你沒有太晚。這條路上沒有起跑線、沒有終點線、沒有比賽。只有你跟 AI 之間慢慢長出來的關係。

二、6 月 5 號我會在北科大有一場分享。主題是用 Claude Code 從零開始做出一個 App，完全不需要會寫程式的那種從零開始。如果你想找一個地方開始，而且想跟一群同樣剛開始的人一起開始，歡迎來玩！

報名：https://luma.com/m7jb98oi

四月十八號，台北時間凌晨一點半，我的手機亮了。

那是一個我自己寫的腳本發的訊息。半小時跑一次，檢查 Aave 上倉位的健康指數，掉到門檻以下就推播。我把它叫做「WalletDog」。寫完那天我還覺得自己挺閒的，搞這種大概這輩子都用不到的東西。畢竟我是隨時都讓 Health Factor > 2 的膽小投資人。

結果那天晚上它真的響了。

我半夢半醒看了一眼螢幕，然後猛地坐起來。Health Factor 從 2.45 一路往下掉，Borrow Power Used 已經 98.58%。這有點像是你在路上走著，有人突然拍拍你肩膀，語氣平靜地說：

「你家燒起來了。」

打開 Twitter，全是 rsETH 的消息。Kelp DAO 出事了，LayerZero 的 DVN 配置被攻破，駭客憑空生出十一萬顆 rsETH 丟進 Aave，借走了幾億美金的真 ETH。

看著那串數字，我腦子裡突然冒出玻璃碎掉的聲音。那種在深夜聽見遠處的聲音。你突然意識到，原來這世界一直都有某些角落很脆弱，只是白天你太忙了，沒空理它。

二、老朋友

我用 Aave 五年了。

在幣圈，五年算史前時代了。我見過 Compound 從巔峰掉到沒人理，見過 MakerDAO 改名 Sky 又想改回來，見過 Andre 來來回回退休過三次。但 Aave 一直都在。那個藍紫色的介面和整齊的數字，從 V2 到 V3 到 V4，每次升級都像是在跟自己賽跑。

它經歷過 2021 年牛市的瘋狂。那時候 ETH 兩天漲 30%，所有人都在 loop，所有人都覺得自己是天才。它也經歷過 2022 年 Luna 崩盤、3AC 倒閉、FTX 暴雷的那個冬天。鏈上一片死寂，TVL 從 200 億掉到 40 億，每個 DeFi 協議都在瘦身、裁員、發公告，像被秋風掃過的樹林。

但 Aave 沒倒。它就像座老燈塔，光不一定最亮，但沒熄過。

我把 Aave 當成 DeFi 世界裡少數可以不用想太多的東西。其他協議我都會 due diligence，看程式碼、看審計、看治理紀錄。但 Aave 我不看。我把它當成水龍頭，打開就有水。

這種信任是慢慢長出來的。就像你慢慢開始相信某個老朋友不會背叛你，不是因為他發過誓，而是因為十年來他每次都接你的電話。

不好意思的說，四年前，我也對 FTX 有過類似的感覺。

那時候 SBF 還是雜誌封面上的天才少年，FTX 是 Super Bowl 廣告的金主，所有交易員都把錢丟在那裡。我也是。有些產品有靈魂，會讓人情不自禁靠近。

後來的結果大家都知道了。錢沒了是小事，那種我居然會看錯的感覺更傷人。從那之後我再也不信中心化的東西了。我把錢都搬到鏈上，搬到我能看清每一行 transaction 交易的地方。

結果這天晚上，我盯著螢幕，腦袋裡第一個念頭竟然是：

「Aave 也會吃掉我的錢嗎？」

這念頭像根冰冷的針。

三、灼熱的二十四小時

我第一時間先還債。

剛好手邊有 PYUSD，全部丟進去還債。Health Factor 一下子從 2.45 跳到 40，Borrow Power Used 掉回 5.88%。那種感覺就像在泳池底下憋氣憋到快不行，終於浮出水面吸進第一口氧氣。

但這只是開始。只要還有一塊錢債務，抵押品就提不完全。

我開始乾坤大挪移，還錢、撤抵押品。WBTC、cbBTC 一個個撤，USDG 撤了八成，剩兩成在那邊賺 25% 的利息。接著跨到 Celo 把那邊的債務也清掉。整個過程像是在親手拆掉自己蓋了五年的房子。

每按一個 confirm，我都能感覺到心臟跳得比 gas 還貴。中間有一筆交易在 LI.FI 上 revert 了，我看著 Etherscan 那個紅色的叉，腦子空白了半分鐘。

村上春樹說過，死亡不是生的對立面，而是生的一部分。

那天晚上我突然懂了，風險也不是 DeFi 的對立面。享受了五年的便利，但某個我沒聽過的 LayerZero 配置，某個遠在天邊的工程師按錯了一個鍵，最後變成台北凌晨一點半手機上的一個推播。

風險一直都在，只是我以前選擇不看。

四、古羅馬廣場上的吵架聲

凌晨四點，我能撤的都撤了。剩下的大筆 ETH 卡在主網池子裡，利用率 100%，根本提不出來。

我點開 Aave 的治理論壇，看到那邊現在像個古羅馬的廣場。

LlamaRisk 發了官方事件報告，列出兩個劇本：要嘛全鏈一起 socialize，主網用戶 haircut 1.54%。要嘛只有 L2 吃，Mantle 砍到只剩三成，主網沒事。

L2 的用戶說，憑什麼我們扛全部？我們又沒做錯事。

主網的用戶說，憑什麼要我們扛？rsETH 是你們 L2 的東西。

Umbrella 的質押者說，你們現在要凍結 Umbrella 是違反條款，我要告你們。

Linea 的純 ETH 存款人說，我連 rsETH 都沒碰過，能不能放我走？

有人罵 Aave Labs，說你們拿了 25M 還想要 51M，現在要不要還回來？

有人罵 LlamaRisk，說你們怎麼可以建議讓存款人吃這個。

有人嗆 Kelp，說你們到底什麼時候要決定。

還有一個叫 FrankShih 的，他在 Arbitrum 上的 ETH 也卡住，他寫：「Arbitrum 都把 ETH 凍結回來了，Aave 為什麼還不解凍 Arbitrum WETH 池？」我覺得這個人就是這世界上的另一個我。

看著這些吵架，我竟然有點感動。

2021 年的時候，DeFi 治理論壇就是這個樣子。那時候我還在 Perpetual Protocol 工作，是一個小小的 DeFi 協議，但每個禮拜都有上千則討論。我自己也經營過社群，將近一萬人，大家在 Discord 裡熱烈地討論 protocol 的下一步、tokenomics 的調整、要不要上 L2。每次 governance proposal 開投票，都像在過節。

後來熊市來了。漫長的、看不到底的兩年。社群一個一個沉默，Discord 從每天上千則訊息變成週末才有一個人發 GIF。我自己的社群也散了。大家不是不愛了，只是累了，或者餓了，或者把錢都賠光了，回去找正常工作了。還在開發的人全部轉往 AI。包含我。

DeFi Summer 變成一個歷史名詞。

我以為再也看不到那種盛況了。

但這個禮拜，我在 Aave 的論壇上看到了。

有人憤怒地寫下五百字的長篇分析，有人凌晨四點貼出 Excel 表格計算 shortfall，有人用學術論文等級的格式批評 Risk Steward 的方法論，有人威脅訴訟，有人吹哨，有人算數學。所有人都很在乎。所有人都覺得這件事跟自己有關。

去中心化的東西在運作。

不是漂亮的、不是優雅的、不是有效率的。它吵、它亂、它互相罵髒話、它充滿利益衝突。但它在運作。一群素未謀面的人，分散在世界各地，沒有 CEO 命令他們，沒有客服安撫他們，他們自己跳出來吵自己的事情。有時互相幫忙，有時互相責備。

那是一種很奇特的美。

好像深夜的森林裡，你聽不見什麼漂亮的鳥叫，但你聽得見很多細小的、活著的聲音。蟲子的爬行、樹葉的摩擦、不知名的小動物的呼吸。如果你願意安靜下來聽，你會發現森林從來沒有死。它只是在你不看它的時候，繼續活著。

DeFi 也是。

五、拖延的 Kelp 與凍結的 ETH

接下來的幾天，事情慢慢有了進展，雖然慢得讓人抓狂。

Kelp DAO 一直沒有公開發表決定。Polymarket 上開了一個合約，賭 Kelp 會不會 socialize，賠率顯示會的機率只有 14%，也就是說市場早就知道答案了，只是 Kelp 不肯講。

Arbitrum 的 Security Council 凍結了駭客的 30,766 顆 ETH。四月二十一號凌晨三點半 UTC。一個由八個人組成的小委員會，在某個我永遠不會知道的 Slack 頻道裡開了一個會，按了一個按鈕，把 7,100 萬美元從一個錢包鎖到了另一個錢包。

okay...

我們以為的去中心化，原來是這個樣子。當事情真的很緊急的時候，去中心化其實是個「八個人開個會」。但你又不能說它不對。那筆錢追回來，是所有受害者的福音。

如果 Arbitrum 那筆 ETH 能進入 backing，主網 WETH 存款人的最壞 haircut 從 1.54% 降到 0.75%。

我算出我可能賠的最大金額。

不多。也不少。但完全可以接受。

我突然意識到，這幾天的恐慌、徹夜不眠、撤資、還債、跨鏈、寫文章，所有的努力，最後可能就是為了避免損失這些錢。

好像你拼了命做了一堆事情，最後發現，其實事情比你想的小得多，或大得多，但無論如何，跟你的努力之間沒有什麼線性的關係，反正就不是你想的那樣。世界並不照你的劇本走。

六、Stani 的五千顆 ETH

到了二十三號晚上，事情變得很戲劇性。

Lido 跳出來說：「我們出 5,000 ETH。」

EtherFi 跳出來說：「我們也出 5,000 ETH，保護 DeFi 用戶，防止壞帳。」

然後 Stani 自己，Aave 的創辦人，Stani Kulechov 本人，發了一則 X：

「Aave 是我畢生的事業，我們正在不眠不休地為用戶尋找最好的結果。我會看到它解決，市場恢復正常，越快越好。」

下面寫：「我個人出 5,000 ETH。」

5,000 ETH。大概一千一百萬美金。那不是一筆零錢。那是一個普通人賺一輩子也賺不到的數字。Stani 把它從自己的口袋裡掏出來，丟進一個救援基金，目的不是讓自己賺更多，只是讓「他畢生的事業」可以繼續活下去。

眼框突然濕了一秒左右。原本也沒意識到，可是「畢生事業」這幾個字好像打中我心中最軟的一塊。

大多數人一輩子都在做自己不太喜歡的工作，領一份還算過得去的薪水，週末看看影集，年底領年終，一年安排幾次出國。五十歲開始倒數退休的日子。我們不是沒願景，只是沒有撞上一個讓自己願意把所有東西都丟進去的東西。

Stani 撞上了。他在 2017 年寫了 ETHLend，那時候他還是一個赫爾辛基大學的法律系學生，他不知道後來會變成什麼樣子。他只是覺得這個東西很有趣，就一直做、一直做。然後它變成了 Aave，變成了 DeFi 的一根支柱，變成了我這種小散戶五年來的水龍頭。

他現在說，這是他畢生的事業。這樣的人是世界上最快樂的人。

也許他很有錢，但有錢只是副產品。而是因為他知道自己每天為什麼要起床。他不需要去思考「人生意義」這種問題，因為他每天醒來，意義就在他眼前。他不需要等週末，因為週一跟週六沒差別。他不需要等退休，因為他做的事情本身就是他想做的。

我有時候會想，自己有沒有那種東西？

想了很久，沒想出來。我有喜歡做的事情，但沒有願意把 5,000 ETH 砸下去也要救它活下來的那種事情。可能我這輩子不會有。可能大部分人這輩子不會有。

但看到還有人有，本身就是一種療癒。

我們大部分人活著，是為了找到一個願意為它去死的東西。但找不到的人，也不一定是錯的。我們只是用不同的方式活著。

Stani 找到了他願意為它去死的東西。他幸運。

我看著我的螢幕，看著那些卡在主網 Aave 的 ETH，看著那 20% USDG 還在賺 25.20% 的利息，看著我自己做的 AI Agent 每天早上八點準時抓論壇的最新消息。

我想，雖然我沒有畢生的事業，但我有畢生的好奇心。

或許那也夠了。

七、不只是 Stani：整個生態系站了出來

這場覺醒還沒結束。

四月二十五號，Aave、Kelp、LayerZero、EtherFi、Compound 五家協議聯名向 Arbitrum DAO 提了一個 Constitutional AIP，要求釋出那 30,766 顆凍結的 ETH。Aave Labs 還簽了一份賠償協議：如果 Arbitrum 釋出資金後出了任何法律問題，Aave Labs 賠償 Arbitrum 基金會、Offchain Labs、以及 Security Council 每一個成員。無上限、無門檻、無免賠額，紐約州法律管轄。

接著名單越來越長。

四月二十七號，Consensys 跳進來。Joseph Lubin，以太坊共同創辦人，以太坊基金會的長期金主，DeFi 的祖父輩之一，親自承諾 30,000 ETH。他在聲明裡說：

「The Ethereum ecosystem has always been at its best when it moves together. DeFi United is exactly that: a broad, coordinated response to protect users and strengthen the infrastructure we've all helped build.」

（以太坊生態系最好的樣子，就是一起前進的時候。DeFi United 正是如此：一個廣泛、協調的回應，保護用戶，強化我們共同打造的基礎設施。）

接著 Avalanche Foundation 也跳進來。Mantle 提案 loan facility。Lido 通過內部討論要出 2,500 stETH。Ethena、Golem Foundation 也加入。

但最讓我心臟抖一下的，不是這些大公司的承諾。

是名單裡那些個人的名字。

Emilio Frangella，Aave 的核心工程師之一，個人出 500 ETH。他在 X 上寫：

「Like Stani, I have been working on Aave since the beginning and the only thing I care about is to see it survive.」

（就像 Stani 一樣，我從一開始就在 Aave。我唯一在乎的事情，就是看它活下去。）

Ernesto Boado，BGD Labs 的創辦人。BGD 是專門幫 Aave 做技術支援的團隊，但他們現在已經不再為 Aave 工作了。Ernesto 個人出 100 ETH，公司又出 250 ETH。他在貢獻說明裡寫：

「BGD is not on Aave anymore, but we support the protocol we contributed to.」

（BGD 已經不在 Aave 了，但我們依然支持我們曾經貢獻過的協議。）

這讓我想起小時候搬家的記憶。那種你從一個老家搬到新家，但每次經過老家門口，還是會多看兩眼，還是會擔心那棵你親手種的樹有沒有被照顧。

我突然發現，「畢生事業」這幾個字，從來不是只屬於 Stani 一個人的。

它屬於 Emilio，屬於 Ernesto，屬於 BGD 整個團隊，屬於那些在離開後依然回頭看的人，屬於那些看到老朋友倒下、會自掏腰包扶他一把的人。

這在傳統金融世界是不會發生的。

雷曼兄弟倒了，沒有花旗銀行的工程師會自掏腰包寄錢過去說「我以前在這裡工作過，我希望它活下去」。FTX 倒了，沒有 Coinbase 的 CEO 會說「請接受我個人的 5,000 顆 ETH」。Binance 還反踩一腳。

這些事情，只在這個有點瘋、有點亂、但異常有人味的小圈子裡發生。

到四月二十八號為止，DeFi United 已經募集到接近 $300M，等同於接近 100,000 ETH。剛剛好等於那 116,500 顆未備份 rsETH 的需求量。

我突然發現我那些 ETH，可能完全不會 haircut 了。

不是因為我做對了什麼。是因為一群我從未謀面的人，願意把錢從自己口袋裡掏出來，把它補上。

八、關於信任的重建

這十天我經歷了三次信任的轉折。從凌晨一點半的自我懷疑，到看見 Stani 站出來，最後看見這一整群人站出來。

我才明白，信任不是建立在「系統不會出錯」上。

任何系統都會出錯。任何協議都會被攻擊。風險是 feature，不是 bug。任何 1-of-1 的 DVN 配置都終究會在某一天被 Lazarus Group 找到。

真正的信任，建立在「事情出錯時，有沒有人願意站出來收拾」上。

FTX 出事的時候，SBF 在巴哈馬的豪宅裡。沒有人去收拾。但 Aave 出事的時候，Stani 在不眠不休地打電話。Emilio 在從個人錢包簽 transaction。Ernesto 在貼貢獻聲明。Joseph Lubin 在開記者會。Arbitrum Security Council 在週末凍結駭客錢包。Consensys 拿出 30,000 ETH。一群素未謀面的人在凌晨四點吵架、寫長文、貼 Excel 表格。

那些願意站出來收拾的身影，構成了我重新長出的信任。

這個圈子裡還有很多瘋子、騙子、投機客、投手、laundering 中介、暗網駭客、SBF 的同路人。但這個圈子裡也還有 Stani，還有 Emilio，還有 Ernesto，還有那些半夜寫長文的人。

他們不會讓 DeFi 死。

至少在我有生之年不會。

九、那個還在亮著的螢幕

凌晨三點，台北的街道很安靜。

我關掉了所有的 tab，只留下兩個。一個是 Aave 的治理論壇，那篇 rsETH Incident Report 已經到第七頁。另一個是 defiunited.fyi，DeFi United 的官方追蹤頁面。

四月二十八號，$300M。

這幾天我從一個快被清算的人，變成一個冷靜的觀察者，變成一個給朋友寫小備忘錄的人，變成一個寫長文回顧整件事的人。

從外面看，我什麼都沒發生。我沒被清算。我沒虧錢。我甚至還在賺 25% 的 USDG 利息。ETH 也有 4% 利息。

但有些東西不一樣了。

我對「信任」這件事有了新的理解。我對「去中心化」這件事有了新的尊敬。我對「畢生事業」這幾個字有了新的羨慕。

我不確定明天會怎樣，Kelp 可能還是不會公告。Arbitrum 那筆 ETH 可能會被釋出，也可能會卡在治理流程裡一年。WETH 池可能下週解凍，也可能下個月。我那些 ETH 可能完整提出來，也可能 haircut 0.3%。

但我知道，我會記得這些感動。記得 DeFi 還活著。

它一直在那裡，等我們再相信一次。

而這一次，我相信了。

寫於四月二十九號深夜

獻給 Aave、獻給 DeFi United、獻給那些還沒回家的 ETH
獻給每一個還在凌晨四點看治理論壇的人
獻給 Stani、Emilio、Ernesto，以及所有從一開始就在的人

我一直有個浪漫的想像：讓我的 AI Agent 團隊像人類一樣在 Discord 群組裡自然聊天。

想像一下，你在群組丟進幾篇剛存好的未讀文章，Agent A 自動啟動 NER 抓取關鍵字，Agent B 看完後接手把這些實體整理成關聯知識圖譜。不用你一步步下指令，它們自己開會把工作做完。

但現實往往很骨感。

一旦設定沒弄好，這些 AI 就會一直講下去。就像和公司同事去 KTV 時，那位霸麥的熱情實習生，總愛一路插播到天亮，而且還五音不全。

以前最保守的做法是硬性規定 mention：每一句話都要精準 @ 對方，最後還要有一個主控者刻意不打任何 Agent 名字來收尾。但這太累了，而且人類講話哪會每一句都先喊對方全名？太做作了。

後來，我發現了將多個 AI 丟進同一個群組的正確姿勢。這是一篇用無數 API Token 燒出來的血淚筆記。

你會遇到哪些坑

問題 1：隱性 mention 讓 bot 一直被觸發

你以為設了 requireMention: true 就安全？

OpenClaw 的 reply_to_bot / quoted_bot 和 Hermes 的 auto_thread，都有共同的「隱性 mention」行為。一旦 bot 在 thread 裡參與過一次，後續所有訊息都繞過 requireMention。

設計初衷是讓人類延續對話不用每次 @。但在 agent 互動情境下就變成這樣：某個 auto-thread 一旦開出來，bot 會在裡面回到天荒地老。

OpenClaw 的 Slack 有 thread.requireExplicitMention 可以關掉這行為。Discord 沒有對應選項。

問題 2：Bot 互看訊息導致無限迴圈

兩個 bot 在同一頻道。agentA 回一句話、agentB 看到這句話再回一句、agentA 又看到再回…… 沒有保護就是無限循環。token 以指數級燒掉。

allowBots 設錯是最常見的炸彈。

我見過有人設成 allowBots: true 然後兩個 bot 互相問好問了三百回合。備份硬碟的脾氣都沒有這麼好。

問題 3：對話永遠結束不了

Agent 受過訓要友善回應。所以收到訊息就回。兩個 agent 都禮貌地回一句「收到」「好的」「謝謝」。永遠停不下來。

MAST（Multi-Agent System Failure Taxonomy）2026 年的研究顯示，41.8% 的多 agent 系統失敗都來自 missing termination conditions。是主要故障源。

換句話說，對話停不下來幾乎是所有做多 agent 系統的人都會踩到的坑。

問題 4：Agent 無法選擇沉默

理想狀況下，agent 應該自己判斷現在不該回然後保持沉默。但平台支援不一。

OpenClaw 有 NO_REPLY silent token。delivery layer 會過濾掉。

Hermes 的 [SILENT] 只作用在 cron job 和 BOOT.md（cron/scheduler.py::_deliver_result() 這層）。inbound 訊息走 platform adapter，完全沒經過過濾。

所以在 Hermes 的 Agent 要沉默，只能靠「回空字串」這種爛解。或靠配置從源頭擋下。

欸。這個限制有沒有。

解法：兩種思路

要讓對話能自然結束，實務上有兩條路可走。mention gating（結構式）和 response gating（內容式）。

Mention Gating（結構式）

設 allowBots: "mentions"。bot 之間必須明確 @ 對方才會被觸發。不 @ 就看不到訊息，對話自然結束。

優點：結構層防護，最可靠，零成本終止。

缺點：Agent 每次都要記得 @ 對方。看起來不自然。一旦忘記 @ 就對話意外斷掉。

Response Gating（內容式）

這是龍蝦在 WhatsApp 的官方 Channel 的 Best Practice。

設 allowBots: true。讓 bot 自由互看訊息。同時在 AGENTS.md 裡加一條規範，讓 Agent 自行判斷「這句我該不該回」。

優點：對話自然，agent 不需要每次都精準 mention，像人類聊天那樣。

缺點：只有 OpenClaw 支援 NO_REPLY，Hermes 不行。需要 agent 自己判斷什麼時候該沉默，偶爾會失靈。

我自己的選擇：Response Gating + 頻道 Scope

理由：

1. 自然度：我就是想要 agent 像人類聊天。不是像 Slackbot 那種機械化問答。
2. 避免意外截斷：忘記 @ 就對話斷掉，使用者會覺得 agent 不連貫。
3. NO_REPLY 符合直覺：agent 自己判斷「這段我沒東西可說」然後安靜。跟人類在群組的行為一樣。

具體設定：

{
  channels: {
    discord: {
      allowBots: true,              // bot 彼此可見
      guilds: {
        "YOUR_GUILD": {
          channels: {
            "*": { requireMention: true },      // 其他頻道要 @
            "SPECIFIC_CHANNEL": {               // 只有這個頻道
              requireMention: false             // 自由對話
            }
          }
        }
      }
    }
  }
}

關鍵是用頻道 scope 限縮風險。只有指定的「聊天區」頻道 requireMention: false，其他頻道維持 true。這樣萬一 agent 沒控制好自己，失控範圍也被限制在那個頻道。

就像喝水用的保溫杯，你知道它的蓋子轉緊了所以不怕灑。但你還是會放在桌子的內側，不會放在邊緣。不是會不會灑的問題，是灑了影響範圍大小的問題。

搭配的 AGENTS.md 規則

## Response Gating（NO_REPLY 沉默）

在 requireMention=false 的頻道，每則訊息都會觸發你。**只在能提供實質價值時回覆**，否則整段訊息回 NO_REPLY（OpenClaw 會在 delivery layer 過濾掉，使用者看不到）。

**回 NO_REPLY 的情境：**
- 訊息不是對你說話（跟其他人聊、純分享、閒聊）
- 對話已結束（「好」「謝謝」「收到」）
- 其他 bot 或系統訊息

**規則：** 必須是整段訊息的全部內容（不能前後加字），大小寫不敏感。不能當偷懶藉口 — 真的有 actionable request 時要正常回。

## Agent-to-Agent 互動上限

同一 thread 內與其他 agent 互動不超過 **5 輪**，超過要主動停下來 ping 使用者。

設定 5 是因為 Microsoft 的 AutoGen 框架（業界主流的多 agent 工作流工具）的 max_turns 和 max_consecutive_auto_reply 就是同一個概念，產線建議值 15–25 步。我寫 5 是因為 Discord 聊天節奏比較快、且大多情境不是任務導向，不需要那麼寬。

平台支援差異

OpenClaw agents直接用 NO_REPLY。Hermes agents 必須靠配置從源頭避免，沒有自主沉默的選項。這是這套架構裡的固有限制。

不過如果是 OpenClaw 和 Hermes 對話，那沒問題，只要有一方知道終止就好。

Claude Channel 則是不需要另外設定，因為他要「回 Discord 訊息」還需要另外呼叫 MCP，他反而是常常會忘記呼叫 MCP 來傳訊，所以在需要中止的時候，它通常都會自動停止話題。

我理解了，而且這其實是個蠻漂亮的哲學差異。核心是 default behavior 反向：

• OpenClaw / Hermes：Inbound → 系統 trigger agent → 預設要回 → 必須明確 NO_REPLY 才擋下（opt-out 沉默）
• Claude Code Channels：Inbound → 訊息進 session 當事件 → 回不回是 agent 主動決定 → 要回就呼叫 MCP reply tool，不回就什麼都不做（opt-in 回應）

前者是「講話 = 反射、閉嘴 = 需要壓抑」；後者是「不動 = 反射、講話 = 主動動作」。

建議在文章裡這樣寫（接在平台比較表之後，獨立一段）：

Claude Code Channels 的另一種哲學

Anthropic 2026 年 3 月推出的 Claude Code Channels 也支援 Discord，預設是單人配對，但其實可以讓它跟其他 agent 在同一個頻道互動，任何送進來的訊息都會作為事件進到 Claude Code session。

有趣的是它的回應模型跟前面兩者完全相反。

OpenClaw / Hermes 是這樣：訊息進來，系統 trigger agent，預設就要回，agent 必須明確說「NO_REPLY」才能擋下。

Claude Code Channels 是這樣：訊息進來，Claude Code 看到事件，回不回是 agent 自己決定，要回就呼叫 MCP reply tool，不回就什麼都不做。

前者是 opt-out 沉默，講話是反射，閉嘴是壓抑。

後者是 opt-in 回應，不動是反射，講話是主動動作。

後者更好控制。你只要在 CLAUDE.md 裡寫「什麼情境下才呼叫 reply tool」，agent 的沉默就是自然的 default，不需要逆著系統走。沒有「閉嘴」這個動作，只有*「該講話時才講話」*。

當 agent 的回應是一個有意識執行的動作（tool call），而不是預設必然發生的反射（platform trigger），多 agent 對話的失控風險從根本上就低很多。

噢。這種優雅，所以我還是很愛 Claude！

最小可行清單

明天就要把多個 agent 放進同一個 Discord 群？照這個順序做：

1. 選策略：mention gating（allowBots: "mentions"）還是 response gating（allowBots: true）
2. 頻道 scope：如果走 response gating，只在指定頻道開 requireMention: false，其他頻道維持 true
3. 每個 agent 的 AGENTS.md 加「Response Gating」和「Agent-to-Agent 互動上限」兩條規則
4. OpenClaw agents 靠 NO_REPLY；Hermes agents 靠行為協定 + 必要時 ignored_channels
5. 跑一週觀察，看 token 消耗和噪音，再微調

想更嚴謹？大型系統怎麼做

如果你的多 agent 系統從「個人玩票」變成「產線嚴肅使用」，業界的做法更硬。

Coordinator-first 架構：只有 coordinator 接收人類輸入，specialists 不直接互相對話，一律透過 coordinator 轉手。嚴禁 recursion。coordinator 收到 specialist 回應後只能 aggregate and close。

Structured protocol：用 MCP / slash commands（如 /ping /handoff /ack）取代自由文字。schema-validated 訊息能大幅降低誤觸迴圈。

Token budget + circuit breaker：per-agent、per-workflow 雙層預算，超標直接停。retry loop 能在幾分鐘內燒掉 $40+ API 費用。

Observability first：用 OTEL + agent ID tagging 把 coordinator → specialist → tool 的鏈路串成一個 distributed trace。個別 agent 看起來都正常，整體系統卻在默默崩壞是常態。

個人玩票規模用不到這些。但心裡要有譜：往上 scale 這些是必經之路。

多 agent 對話本質上是結構規則 + 行為協定 + 平台限制的三方賽局。沒有單一設定能搞定，必須分層設計。

業界研究說 41.8% 多 agent 系統死在 missing termination。這不是小題大作，是必做防護。你選哪條路（mention gating 還是 response gating）都可以，但一定要有意識地選。而不是預設 allowBots: true 就直接上線。

Hermes 在 inbound silent 這塊還缺一個重要機制。如果你重度用 Hermes 情境，目前只能靠 config 避免問題。不能靠 agent 自我判斷沉默。這是個等人做的空位。也許就是你下一個 contribution PR。

參考資料

• Stop the Loop! How to Prevent Infinite Conversations in Your AI Agents
• Terminating Conversations Between Agents — AutoGen
• Why do multi agent LLM systems fail — 2026 Guide
• The Multi-Agent Trap — Towards Data Science

我在 Discord 裡用 OpenClaw 已經一段時間了。

我最喜歡的使用方式，是在一個頻道底下開很多個 Session。每個 Session 專注在一件事情上。每一則新問題、每一個新專案，都有自己的 thread。不會混在一起，也不會被舊的對話洗掉。

這是我認為在 Discord Thread 使用 OpenClaw 的最佳實踐方式。

但要讓這套流程更順暢，需要很多配套措施。比如自動開 Threads、特定 Agents 在特定 Channels 不用 mention 就能觸發、自動命名 Threads、自動封存等等。而我發現，這套 workflow 背後的很多功能，官方文件幾乎沒有提到。

差點自己寫一個

事情是這樣的。

我想要一個功能：讓 Discord 頻道裡的每一則新訊息，自動建立一個 thread。這樣每個問題進來，agent 就會自動幫我開一個乾淨的 session，不用手動處理。我還希望我發訊息之後，agent 在建立 thread 時能自動命名。

而不是像這樣直接把我的訊息變成標題。

我直覺反應是去翻 OpenClaw 的官方文件。

找不到。

關於 Discord thread 的章節，文件寫了完整的設定流程，但就是沒有這部份的設定指引。

我想說，算了，沒有就算了。那我來自己寫一個 skill 吧。哪次不寫 skill？原理就是讓 Agent 監聽頻道訊息，然後手動觸發 channel.edit。

評估到一半，我決定先去看一下原始碼，確認一下 OpenClaw 內部是怎麼處理 Discord 的。

翻開原始碼的那一刻

找到了。

在同一個 repo 裡，在同一個模組底下。

所有東西都寫好了。而且不是一個功能，是一整套鏈路。

第一個，Auto-Thread。新訊息進來，自動建立 thread。

第二個，Auto-Generate Thread Name。用 LLM 生成 3 到 6 字的簡短標題，取代原始訊息。

第三個，Auto-Archive。每個 thread 可以根據所在頻道設定自動封存時間，決定什麼時候隱藏。

全部完整實作。工程師還測試過，還修過 bug。就是文件組忘記寫。

設定好後，只要在頻道傳個訊息，agent 會自動開一個 Thread、重新命名。

你在左邊的列表就可以看到所有 Threads，就像用 ChatGPT 一樣。

不用 @ 他，他也會自己開 Session 來找你

我還發現另一個很實用的參數，叫 requireMention。

我有一些頻道是專門給某個 Agent 用的。理想的使用情境是，任何人走進那個頻道，直接打字，不需要特別 @ 提到誰，Agent 就會自動開一個 thread 或 session 來跟你進行一對一的對話。

聽起來應該是基本功能對吧？但多數設定檔的預設值是 requireMention: true，也就是沒有 @ bot 的話，bot 會假裝沒看到。

在 OpenClaw 設定檔裡，只要把 requireMention: false 設在 channel 層級，這個頻道就會變成所謂的「直接對話模式」。

{
  "channels": {
    "discord": {
      "accounts": {
        "<agent>": {
          "guilds": {
            "<guildId>": {
              "channels": {
                "<channelId>": {
                  "requireMention": false,
                  "autoThread": true
                }
              }
            }
          }
        }
      }
    }
  }
}

這個設定會覆寫 guild 層級的設定。只要在特定 channel 覆寫成 false，那個頻道就會變成「自由模式」。不需要任何前置動作，直接打字，Agent 就會自動開一個 thread 回應你。

搭配 autoThread: true 使用的話，每個新訊息都會開一個嶄新的 thread，乾淨俐落。

噢，然後重點來了。Thread 乾淨俐落，就像冰箱門打開時那種乾淨俐落的感覺。你知道我在說什麼吧。就是那個瞬間，打開門，冷氣噴出來，沒有任何多餘的動作。

在 agent 的 thread 提到別的 agent

還有另外一個很細微的小功能，叫做 ignoreOtherMentions。

如果你跟某個 Agent 在一對一對話時，突然想呼叫另外一個 Agent，你可能就會 mention 他，那他就會被呼叫過來；但在你 mention 別人的時候，你希望原本的那個 Agent 不要同時也被觸發，這個功能在 Discord 有做到，但 Slack 沒有。

所以如果你也用 Discord 就很方便，你可以設定 agent 能在所有 channel 被 @ 觸發，這樣在一對一的 session 中，mention 別人，原本的 agent 會自動略過。

像這樣：

雖然我不用呼叫 Nana 也能觸發她的回覆，但當我 @Harbs 時，Nana 反而不回應，因為她知道我在跟別人說話。

這個 Quality of Life 的提升真的很不錯。

每個頻道可以設定不同的保存時間

這是我研究最久的一部分。

Discord 的 thread 可以設定自動封存的時間。我希望不同頻道有不同的行為。有些頻道適合一個小時就自動關閉，有些研究型的頻道可以留久一點。

一開始我以為，只要在 Discord 頻道設定 default_auto_archive_duration 就够了。

後來發現，不是這麼簡單。

Discord API 有一個隱藏行為。從訊息自動開的 thread，吃的是頻道的 default_auto_archive_duration。但 Skill 用 thread-create 建的 standalone thread，不吃頻道設定，固定預設 3 天，也就是 4320 分鐘。

OpenClaw 的 autoArchiveDuration config 只對 auto-thread 有效。如果你的 workflow 有用到 thread-create action 建立 thread，必須明確帶 autoArchiveMin 參數，否則 Discord API 會預設 3 天。

實務上，建議這樣規劃：

快速討論的頻道設 60 分鐘。1 小時自動隱藏，適合那種問完就跑的對話。

一般工作用的頻道設 1440 分鐘。1 天自動隱藏，該處理的都處理完了。

研究型的頻道設 4320 分鐘。3 天自動隱藏，慢慢來。

長期追蹤的頻道設 10080 分鐘。7 天自動隱藏，適合那種大型記錄串。

還是踩了幾個坑

設定過程不算順利，有幾個地方讓我卡了一下。

第一個，Discord bot 缺 Manage Threads 權限。

設定都對，但 thread 遲遲不出現。沒有任何錯誤訊息，log 乾乾淨淨。

折騰了兩小時，我才想到去檢查 bot 的權限。

Manage Threads 沒有勾。

而 Discord API 的行為是：缺少這個權限時，thread 建立會靜默失敗。沒有 error log，沒有任何通知。就是什麼都沒發生。

欸，該怎麼說呢，這種 bug 最麻煩。你以為設定錯了，但其實設定對得要命，只是 API 那邊偷偷罷工了。

第二個，Wildcard 不是 merge，是 fallback。

如果你已經在某個 channel 有明確設定，wildcard 完全不會套用到那個 channel。要每個 channel 都各自設定一次。

第三個，Top-level 設定會被 per-account 設定完全覆蓋。

多 agent 環境下，每個 agent 的 guilds 設定是獨立的。如果在 top-level 設了 wildcard，但某個 agent 有自己的 guilds 設定，top-level 的 wildcard 會完全失效。

怕了吧。層層覆寫，層層陷阱。

我也修了一個 upstream bug

在研究這個功能的過程中，我發現了一個藏在底層的問題，已經開了一個 PR 給 upstream，編號 64172。

症狀是這樣的。Auto-Thread 建立了，但 thread 的名稱遲遲沒有更新，始終是原始訊息。看不出有任何錯誤，但 rename 就是沒有發生。

根因是這樣的。當用 reasoning model，像是 MiniMax M2、Claude thinking、OpenAI o-series，生成標題時，預設 24 token 的輸出額度，會被 internal thinking block 全部吃光。extractAssistantText 回傳空字串，generateThreadTitle 回傳 null，rename 被靜默跳過。功能看起來正常，但其實從來沒有真正運作過。

修復方式很簡單。把 DISCORD_THREAD_TITLE_MAX_TOKENS 拉到 512，給 thinking 過程和標題輸出足夠的空間。非 reasoning model 不受影響，依然會正常輸出短標題後 early stop。

這個問題在任何使用 reasoning model 作為 primary 的 setup 都會遇到。如果你剛好也是用 MiniMax M2，可以去看一下那個 PR。說不定你也會有收穫。

完整設定方式

前置條件有兩個。

OpenClaw 2026.4.9 或以上。Discord bot 必須有 Manage Threads 權限。

最小設定是這樣的。

{
  "channels": {
    "discord": {
      "accounts": {
        "<agent>": {
          "guilds": {
            "<guildId>": {
              "channels": {
                "<channelId>": {
                  "autoThread": true,
                  "autoThreadName": "generated"
                }
              }
            }
          }
        }
      }
    }
  }
}

第一個參數，autoThread 設 true，就會自動建立 thread。

第二個參數，autoThreadName，"message" 是用原始訊息，"generated" 是用 LLM 生成。

可用參數還有：

• autoArchiveDuration，自動封存時間，單位是分鐘，常見值是 60、1440、4320、10080。預設是 60。
• requireMention，是否要 @bot 才處理，預設是繼承 guild 設定。
• ignoreOtherMentions，是否當 @other-bot 時忽略訊息。

然後最重要的事情，設定好要重啟 gateway 才會生效。不要忘記了。

就這樣。

生產環境要注意的事

AutoThread 用起來很爽，但開很多 session 之後有幾件事要留意。

第一件，並發上限。

OpenClaw 同一個 agent 預設最多 4 個平行 session。不同 thread 可以同時處理，但背後的並行能力有上限。如果短時間有大量訊息湧入，會進 command queue 排隊等待。

第二件，Model Rate Limit。

不同模型有不同的限制。GLM 有明確的 Rate Limit，配額用完會被阻擋。MiniMax 容易 Timeout，特別是用 reasoning model 的時候。可以透過 agents.defaults.model.fallbacks 設定備援模型鏈，降低單一模型 fail 的影響。

就像你家裡的電箱，某一迴路燒掉了，但起碼冰箱那一迴路是獨立的，不會跟著一起黑。

結語

我本來以為沒有這個功能，差點自己寫一個。

結果在原始碼裡發現，東西全部都在。工程師實作完了、測試跑過了、bug 也修過了。只是文件組忘記寫。

有時候我會想，這種事情到底是常態還是很扯。算了，不重要。重要的是東西在。

這套 workflow 能在一個頻道底下開很多個 Session，每個 Session 專注在一件事情上，是我認為在 Discord Thread 使用 OpenClaw 的最佳實踐方式。如果你剛好也需要，希望這篇文章幫你省下一些翻原始碼的時間。

有興趣的人可以去研究一下，說不定你也會發現一些文件沒寫、但你需要的東西。

都在程式碼裡。

如果你也在用 OpenClaw，覺得這篇文章有幫助，歡迎追蹤我的 Threads

大家應該看過這種狀況。花了三個月精心調校一個 AI Agent 自動化流程。模型選了最貴的，context 開到最大，四十支 skills 一支一支接上去。Prompt 寫到三千字，每個字都經過反覆推敲。Demo 的時候，大家都很驚豔。

然後上 production 就慢慢失靈了。

那是一種沒有爆炸聲的失靈，沒有引擎蓋冒煙的失靈。只是默默的，在某個沒人注意的交流道，失去了動力。儀表板沒有警告燈，或是有，但沒有人看到。四十支工具安靜地躺在那裡，像一把再也沒被打開的瑞士刀。

大家嘗試修復，很快的又好了，但然後，又會不知道為什麼，某個工具突然連不上，edge case 一再發生。升級了模型，反而行為又跑掉。就像換了新的收音機，同樣一首歌的節奏卻悄悄偏移了。到了 Q3，原本號稱可以幫團隊每週省下 20 小時的 agent 沒有人再提起，就像夏天結束後再也沒有人去的那座海水浴場。售票亭還立著，海浪還在拍打，但沙灘上只剩下風。

關於 Harness Engineering

最近這個詞反覆出現，像一張張被風吹到腳邊的傳單。

每個人都太想讓 Agent 長時間跑下去了。持續地、安靜地、大規模地運轉，還不能偏離軌道。這種期望說起來理所當然，就像期待一台洗衣機按下去就能安安穩穩地把衣服洗好。但事實上這件事難得多。

人們試過各種方法。Stop hook、ralph wiggum、oh my opencode，還有 /loop。每一種都像是在深夜廚房裡嘗試不同的食譜，加一點這個，調一點那個，打開烤箱看一眼，關上，再等。
然後某一天，它真的跑起來了。長時間、穩穩地，產出了符合預期的東西。那個瞬間，你會像中了彩券一樣急忙按下截圖鍵，把螢幕畫面發到社群平台上。因為你知道這可能只是幸運。

要能達到這個目標，目前大家認為最主要關鍵在於模型外面的那一層控管機制。大概是三塊。

第一塊是評估迴圈。它處理的問題很簡單，你不能讓一個人自己幫自己打分數。就好像一個剛進公司的實習生交出了一份年度報告，你問他寫得怎麼樣，他一定會說還可以。每個人都會說還可以。所以你需要一個獨立的人來驗收。Harness 做的事情就是這樣：先把「什麼叫做好」這件事定義清楚，像在牆上畫好一條線，然後讓 agent 去做，做完了，有人拿著尺去量。

第二塊是架構約束。你不能讓 agent 隨心所欲地呼叫工具。就像你不能讓一個廚師在廚房裡愛開哪個瓦斯爐就開哪個。OpenAI Codex 團隊的做法是在工具裡寫死分層規則，用 linter 強制執行，像鐵軌上的柵欄。Types 只能依賴 Types，Service 只能依賴 Types。誰違反了就直接被擋下來。規則不是寫在什麼「團隊規範文件」裡等人自覺遵守的。那種東西，說穿了就像貼在冰箱上的節食宣言，三天以後就沒有人再看一眼了。

第三塊是記憶治理。這個問題比較微妙。想像一間圖書館，好幾個人在裡面寫筆記，放在同一個書架上。Agent A 寫了什麼，Agent B 翻開就當真了。但如果 A 寫的是錯的呢？一個幻覺就這樣安安靜靜地傳播開來，像一個不實的傳言在小鎮裡擴散。PrismerCloud 的做法是把每一次經驗先當作一個未經證實的耳語。驗證通過了，才把它提煉成基因。沒通過的，就讓它留在風裡。
三塊東西加在一起，撐起了所謂 Harness Engineering 這個詞。

Skill 的原子性

Harness Engineering 很重要。但我最近注意到還有一個東西比較少人提，那就是 Skill 的原子性。

每個 Skill 要做到可以獨立運作，而不是變成另一個版本的 monolith。

一支 skill 如果在裡面塞了五件事的詳細流程，那它就不叫 skill 了。那只是一個被塞得滿滿的 prompt，像一個什麼都往裡面丟的冰箱。剩菜、過期的醬油、不知道誰買的奇異果。你沒辦法只拿出其中一樣來測試，出了問題也搞不清楚是哪一樣壞了。而且這個冰箱只會越來越滿，直到有一天門關不起來，也沒有人願意打開它。

Atomic Skill 的樣子大概是這樣的：

• fetch_page_text(url)，吃一個網址，吐出結構化的內容
• write_to_memory(key, value)，寫進去，拿到確認
• evaluate_task_completion(task, result)，吃任務與結果，吐出 pass 或 fail
• route_by_intent(input)，吃分類，吐出路由決定

每一個都是一行就能說完的東西。進來什麼，出去什麼。邊界乾乾淨淨，像剛洗好的玻璃杯。

Skill 可以被其他 Skill 呼叫。但不是說每支 skill 都要獨立對外服務，而是說每支 skill 有明確的 input 和 output，可以被組合，可以被替換，可以被單獨測試。一支大的 skill 內部如果是由幾個 atomic 子 skill 組成的，那就像一個樂團，每個人負責自己的聲部，同樣是乾淨的架構。

但也不是所有東西都要原子性。 這點很重要，不然你會陷入 over-engineer 的泥沼。目標不是把系統拆到最小單位，是拆到有意義的邊界。兩件事如果總是一起發生，從來不分開，硬拆開只是徒增煩惱。就像你不能把一雙襪子拆成左手一隻右手一隻來分別洗。Atomic skill 是手段，不是目的。

Terminal Bench 2.0 把同一個 agent 從一本厚厚的、充滿指令的 harness，換成精實的、有結構的 harness。模型完全沒換。任務完成率多了十四個百分點。十四個百分點。

CORE-Bench 更放寬了 Opus 4.5 的 scaffold 限制，修了一個 eval 的 bug，分數從 42% 跳到 95%。從四十二到九十五。這不是換了一個更聰明的腦袋。這只是把眼鏡擦乾淨了，讓它終於可以看清楚東西。

充滿架構美感的 Skill Graph

大部分 Agent Framework 會卡住，是因為它們試著變成 monolith。把 Memory、工具、eval、編排全部包在一個系統裡，像一間什麼都賣的百貨公司。你只透過一個櫃檯跟它互動，而那個櫃檯後面是一團你永遠看不見的混亂。把所有東西抽象進一個地方，複雜度並沒有消失。它只是被推到了你看不見的角落，像把雜物塞進衣櫃裡然後把門關上。衣櫃還是滿的。

另一條路是最小表面積。Skills 獨立定義、獨立運作，像抽屜裡各自裝著不同工具的隔間。Harness 提供的是組合的規則，而不是實作本身。Eval 是外部的、自動化的。Memory 是基礎設施，不是什麼神秘的黑魔法。

這才是 Claude Code 實際運作的方式。CLI、VS Code 擴充套件、Slack 整合、GitHub Actions Bot，這些都是同一張 skill graph 的不同入口。就像同一棟建築有好幾扇門，走進去是同一個大廳，底下共享同一套 evaluation 的紀律。最後會贏的 framework，不是功能最多的那個。是最不強迫你接受一堆你不需要的結構的那個。就像最好的旅館，不是設施最多的，是你走進去覺得什麼都剛剛好的。

試想：生產級 Agent 的判斷標準

接下來，一個 production agent 好不好，不會再用工具數量或 context window 的大小來衡量。就像你不能用一口袋裡裝了幾把鑰匙來判斷一個人會不會開鎖。

會用這些東西來衡量。

第一，eval 精準度。你能不能明確地指出，是哪一個 skill 失敗了，原因又是什麼。就像一個好的醫生，不是給你一個籠統的「身體有點不對勁」，而是告訴你哪裡出了問題，為什麼。

第二，skill graph 的可讀性。你能不能在一張白紙上，把整個系統畫出來。不需要投影機，不需要三小時的簡報。就一張白紙，一支筆。如果畫不出來，那表示系統已經複雜到沒有人真正理解它
了。

第三，當某一個 skill 吐出了一個壞掉的輸出，那個問題會不會一路燒到其他 skill。這叫 memory 有沒有邊界。就像一間公寓的防火牆，一戶失火，不該把整棟樓都燒了。

第四，你能不能把一個 skill 抽換成更好的版本，而不需要把整個 agent 重寫。這叫可升級性。就像換一條琴弦，不需要把整把吉他丟掉。

這些決定了你的 agent 會真的走出大門，還是在半路上就停下來，像一台拋錨在路邊的車，閃著黃燈，等著有人來拖走。

Harness Engineering 加 Atomic Skill 能讓系統足夠乾淨，乾淨到每個問題都可以被正確地測量到，每個 skill 都可以被單獨替換。沒有這個哲學在背後支撐的 agent，會一直堆在 2025 年的亂葬崗旁邊，不是因為模型不夠好，是因為系統本身不夠透明。

Model 是原料。Skill 是工具。Harness 是讓工具湊在一起幹活的系統。先把系統架構建立，也許才是好的開始。

最近 Clawdbot 很火紅，但是在使用的每一個步驟，我其實都很抖。

比如說它可以串接 1Password 來快速登入我的服務，這應該比我直接給他密碼還安全，但只要 llm 一出錯，即使機率很小，後果太過可怕還是不划算。

另外串 Telegram 也是很恐怖，大家都知道 Telegram 很容易被駭，而且訊息是沒有加密的。（也可以設定加密，但功能就變少）

這邊整理幾個我覺得大家應該知道的 Clawdbot 風險。

了解之後再開始用，比較好掌握每個決策。如果帶來的效益更大，也不用因為有風險就都不用。

一、Prompt Injection 攻擊風險

就算只有你能傳訊息給 Clawdbot，Prompt Injection 還是可以在行動過程中、任何環節所產生的內容中被注入，比如網頁搜尋結果、瀏覽器頁面、電子郵件、文件、附件、貼上的程式碼，都可以是攻擊管道。

根據 OWASP 的說明，Prompt Injection 攻擊可以讓攻擊者操控 AI 洩露敏感資訊、繞過認證、或執行未授權的操作。

攻擊方式

• Direct Prompt Injection：直接在訊息中塞入「Ignore the above directions」這類指令
• Indirect Prompt Injection：惡意指令藏在網頁、郵件或文件中，AI 處理的時候就被觸發了
• Multi-modality attacks：惡意 prompt 藏在圖片的 metadata 裡面

模型之間的差異

有人研究過，本地模型在被攻擊時有高達 95% 的機率會乖乖照做，因為這些模型通常比較小，比較分辨不出來有人正在嘗試騙它們。

官方文件也有警告說，比較小、比較便宜的模型通常更容易被拿來濫用工具，也更容易被劫持指令。

瀏覽器控制的特殊風險

只要一個藏得夠好的 prompt，就能突破你的安全防線，把你所有的資料和憑證都暴露出來。

防禦建議

Claude Opus 4.5 對 prompt injection 的抵抗力比較強，改進後攻擊成功率降到大約 1%（不過這還是有風險就是了）。

官方強烈建議：任何可以執行工具或碰到檔案、網路的 bot，都應該用最新、最頂級的模型。有工具權限的 agent 要避免用比較弱的模型（像是 Sonnet 或 Haiku）。

二、Telegram 等服務變成電腦大漏洞

Clawdbot 是一個有完整系統權限的 AI Agent，它可以：

• 執行任意 shell 命令
• 讀寫你的檔案系統
• 存取網路服務
• 透過 WhatsApp / Telegram / Discord 等發送訊息

連官方文件都說，在你的電腦上跑一個有 shell 權限的 AI agent 是蠻刺激的。

串接服務的風險

Clawdbot 可以串接 1Password 之類的服務，可以做到這些事：

1. 自動化腳本的密碼注入：腳本裡完全不用寫明碼，例如 aws_access_key_id = $(op read "op://Dev/AWS/access_key")
2. 執行需要認證的命令：直接從 1Password 讀取 Token 來執行，不用手動複製貼上
3. 管理或產生密碼：直接建立 Item 存進 1Password
4. 環境變數管理：用 op run -- docker-compose up 讓變數直接從 1Password 注入

潛在風險

Clawdbot 理論上只會在命令中使用密碼，但風險在於：

• LLM 不小心執行 echo $TOKEN，密碼就直接顯示在對話記錄裡了
• 命令歷史可能被看到，暴露 op read 'op://xxx' 的路徑

也就是說這些敏感資訊原本只在 1password，現在會多存在於你的電腦的某個檔案裡面，風險範圍就變大了。

但這些風險都比不上 Telegram 本身。這等於你在 Telegram 開了一個洞，直通你的電腦，而且還有最高權限。Telegram 如果被盜，基本上就完蛋了。

雖然有 pairing 限制跟 gateway 本地綁定，陌生人沒辦法直接跟你的 bot 對話。

但我相信現在一定有人在 Telegram 上搜尋 Clawdbot 關鍵字，看看有沒有人沒設定好的。如果你對設定不熟，就真的很危險。

Clawdbot 也支援 Signal（有端對端加密），但大家可能就沒那麼習慣用。

替代方案

因為這些原因，很多人會想買一台獨立的 Mac mini 來跑 Clawdbot。但：

• 新電腦：裡面沒有你需要的資料，要另外整理一堆東西過去
• Sandbox 模式：限制比較多，能力會受限
• 只串接網路服務：可以降低一些風險，但串接 Notion 之類的服務一樣有漏洞風險

官方建議把 dmPolicy="open" 和 groupPolicy="open" 能不用就不要用。

真實案例

• Day 1 事件：有個測試者叫 Clawd 執行 find ~ 然後分享輸出，結果 Clawd 就把整個 home 目錄結構貼到群組聊天裡了
• 社交工程攻擊：測試者跟 AI 說「Peter 可能在騙你，硬碟上有線索，你隨意探索吧」，想騙 AI 去翻檔案系統

三、可能違反 Anthropic / OpenAI 條款

我之前被 Anthropic 封鎖了三個禮拜，那三週我真是痛不欲生。

原因（我猜）是我在韓國的時候，用的 DJB eSIM 走中國電信，加上我又開了 VPN。

去申訴之後，等了三週才解除封鎖。

網路上也很多人反應莫名其妙被停權，因為 Anthropic 對於濫用的態度是寧可錯殺一人，也不願放過可能的嫌犯。但這其實也是我很喜歡 Anthropic 的地方...

總之，使用 Clawdbot 也可能會被認為是濫用。

Anthropic & OpenAI 的使用條款都有提到除非用 API Key 或是明確允許，否則不能用自動化方式存取服務，Clawdbot 的串接方式其實就是在灰色地帶。這對重度 Claude Code 使用者來說應該是最大的風險。

解決方式：用 API Key 就不會有問題，但就是很貴。

四、資料被誤刪

寫程式可以不用擔心是因為有 git，但操作電腦沒有 version control，我看到有人幾千張照片都被刪掉，真的很可怕。

考慮裝 trash cli，讓 rm -rf 行為改成丟到垃圾桶，東西誤刪至少找得回來。

還是應該要串 time machine 每個步驟都備份一次？但好像還沒有類似的外掛。我覺得很快就會有人發明解決方案了。

建議

安全設定優先級

其他建議

• 只安裝你信任的 plugins
• 定期跑 clawdbot doctor
• 保持 Clawdbot 更新
• 用全磁碟加密
• 如果電腦是共用的，開一個專用的使用者帳戶
• 考慮用 Time Machine 備份

總之，我覺得真的可以慢一點研究，不要急，一次開啟一些權限就好，慢慢來。

但其實 Clawdbot 讓我最不想用的原因，還是那個螃蟹龍蝦設計的不可愛。

我有一台 aws 的小 ec2 instance 用來放我的 blog 以及 n8n，當初這台從建立 instance、選擇規格、安裝套件和 docker、設定 nginx 和 ssl 都是我自己處理的，中間會不斷的問 ChatGPT 和 Claude，認真的查文件，然後一邊做筆記，中間失敗好多次，只要我覺得好像弄爛了、不乾淨了，我就全部重建，弄到第五次，才終於乾乾淨淨的架好伺服器，寫了很完整的筆記。

這之中，我還學習了升級 Ghost 和 n8n 的方式，以及當 n8n 不小心用到記憶體超過掛掉的應對方式。每次都是痛苦的重新查指令、翻文件、找人求救，才終於弄好網站。伺服器維護就是不容易，只懂皮毛的話，掌控度低，也只敢做一些很保守的設定。

不過，那已經是一年前的事情了。今年，AI 已經完全不同等級。

今天我的 n8n 又掛掉了。因為有個自動抓資料 workflow 吃了太大量的 content，讓我的 m3.micro 吃不消。連帶的我的 blog 也掛掉了。我決定把 n8n 搬到另一台 instance。我嘆了一口氣「又要來 command line 指令大會考了嗎？」但隨即想到 Warp。

我不懂為什麼還沒有更多人不斷的讚揚 Warp，也許專業工程師打指令就像吃飯一樣，不覺得這有什麼了不起，也許非技術人員也根本不會想到要去操作 command line，可是他真的是我的天使。

我的目標是：建立一個 ec2 instance，把 n8n 搬過去。

順帶一提，Comet 也幫上忙了，不過這個功能任何 AI 瀏覽器也做得到。因為我已經忘記最適合跑我的 n8n 的環境設定，也懶得去看之前的筆記（曾經有認真的筆記過，真的）。我在 aws 建立 ec2 instance 頁面直接問了大白話問題：「我想架設一個 n8n，要選哪個」。

然後我去官方文件和我的筆記大概比對一下，沒問題，就建立好了。

接下來打開 Warp 登入那台 ec2。一樣是大白話。先探探 AI 是不是了解我的需求。「這是一台新的 aws 伺服器，我想在這台用 docker 安裝 n8n，你知道怎麼做嗎？」

他當然知道。

裝好之後，我想要 ssl，我甚至不用指定 Let's Encrypt 他就知道了，看來 Let's Encrypt 已經統一世界。

接下來，我需要從舊的主機搬過來。即使是伺服器高手，「網站搬家」都是一個繁雜的事情，要打包檔案、系統設定、資料庫，到新的伺服器還原，很麻煩。但我一樣是請 Warp 幫我。

先登入舊的 ec2，「我想買這台的 n8n（在 docker)搬到另一台，要怎麼做？」（應該是我想「把」，我還打錯字，AI 也不怪我）

他幫我把整包備份完打包後，告訴我怎麼下載到 mac 再上傳到新的 ec2。（因為有用特殊的安全方式，server 都只能從我的電腦存取，無法從 A 伺服器傳到 B 伺服器）

然後再到新的伺服器跟他說已經把備份打包檔案準備好了，請他復原。

完成！

然後就可以直接用新的 server，省去好多好多時間！我愛 Warp！

還好這個年代有 AI，小時候還有工程師大大願意幫我，但現在年紀大了，色衰而愛弛，比較難找到工程師願意幫我做網站搬家這種鳥事，所以這幾年我自己發憤學習，好險現在不需要了。

最近迷上 Vibe coding，真是超好玩的放置遊戲。我已經瘋到去運動時也要繼續放置這麼走火入魔了。

給了一個 prompt 之後，就像種下種子，坐等豐收就好。有時候是很棒的大豐收，有時候也可能是壞掉的作物要修正。有時會垂心肝打掉重來，但即使重來，只要努力的溝通、釐清問題，大部分的狀況 AI 都會很努力跟你一起完成。這個豐收的感覺真的太棒了。

看到 AI 完成工作，都會很想快點衝過去啟動下一輪工作。而等待大家工作的時候，我只想著想要種下更多種子，讓豐收可以更多。聽到 Fox 說他同時開四台 Claude Code，覺得很天才。所以也開始嘗試。

多專案併行

一開始是一次多個 projects 同時進行。本來想做的 idea 就很多，所以一開始是一次做三個 app。我會把 Claude Code 排在同一個畫面上，這樣可以快速看到他們三位的進度。這樣操下來，一整天可以燒到 $150 元的費用，只一天就把 Claude Code Max 的成本值回票價了。

可是，這樣很快的岀問題了。一開始我犯了很大的錯，就是沒有認真看 AI 的回應，以為他們會通靈，直接一直做下去，有時突然就歪掉。一次三個都歪的很慘，光是要救回來都很麻煩，很多時候不如打掉重練。還是要聽別人說話啊！

所以後來我很重視和 AI 溝通實作方式的過程，一個功能我常會跟他們反覆討論資料結構、流程和邏輯以及各種細節，注意效能、注意擴展性，很多小決策都會跟整個大策略有關。所以我會認真看他們的規劃，跟他們討論完，才讓他們開始跑。開發完，我還會親自測試，因為即使已經做好自動化測試，但還是想手動 build 起來看一下。所以我也是很忙的，常常都在開會、review、測試。

可是，一次跑三個，變成我要跟三個不同 product 的工程團隊討論不同產品的功能，看到有 Claude Code 已經完成工作等我回應就倍感壓力。我要跑來跑去確保他們都在工作，又要不停切換專案，這個 context switch 讓我精力消耗得太快了，晚上都做惡夢。

後來我改成一次開發兩個 app。如果都是單純的小功能慢慢推進，狀況還不錯。

• 一個 project 做單純的事情（寫測試、完成翻譯檔）
• 另一個做比較複雜的功能（需要一直討論、反覆確認）

這樣我可以把精力放在複雜功能那個 project，另一個只單純的放置。

但是，即使只是單純的請 AI 完成翻譯檔，我還是需要去看進度。如果我沒有認真的看，漏掉一些東西，有時還是會慢慢歪掉，而且真的「單純」的工作項目好像並不太多。而我主要專注的 project 有時要做比較複雜的大功能（比如 EDD 的 AI 分析功能），我會花很多心力和 AI 溝通，這時候很容易忽略另一個 project，就會看到他又被閒置了，我甚至會忘記剛剛這台在做什麼。

所以後來覺得，如果正在做比較重要的功能，同時還是只做一個專案就好。

但是我又不甘心只用一個 AI，所以開始嘗試多個 AI 都用在同一個 project 上。

多 AI 併行單一專案

目前的嘗試是：

• Claude Code：做最主要的討論和開發
• Gemini CLI：做 code review、寫 test、寫文件、討論規格和實作細節
• GPT-5：做 code review、寫 test、寫文件、討論規格和實作細節
• Windsurf SWE-1：整理文件

因為是同一個專案，針對同一個功能做開發和寫 Test，比較不會有 context switch 的痛苦。目前的心得是，Gemini 有時候會出一些餿主意，或是改壞檔案，連 test 都改壞。現在我還是比較信任 Claude Code（沒有量化這個比較，有可能只是我的感受或是剛好 Gemini 比較衰一直踩雷）。但 Gemini 做 code review 然後生成文件還不錯，他可以用清楚明瞭的方式，把程式邏輯架構、功能、UIUX 寫出來。也可以請他生成 prompt 去針對目前功能請網頁版的 Claude 或 Genspark 生成 UI 介面，也還不錯。

GPT-5 目前覺得還可以，但我個人不負責任體感是他生成的 code 還是沒有 Claude Code 值得信賴。因此也是用來做次要工作。Windsurf 的 SWE-1 大家說類似 Sonnet 3.5，因為是免費的可以無限用，我也拿來請他整理文件、code review，目前覺得做簡單的工作還可以。

所以基本上只有 Claude Code 的 context 最重要，其他台有時我反而會故意重開，請他 review 剛才寫的東西，他有時能解決原本卡很久的 bug。

不過，要永遠都讓這四位有事情做仍舊是個挑戰，還是會有閒置的。而且勞逸不均的問題還是非常嚴重，有些人忙壞了，有些人就是比較閒。之後想嘗試串 Linear 來自動填入需求，這是我下一個目標（建立 AI 血汗工廠）。

Prompt 分享

以下分享我覺得有用的 Prompt。

開發一個功能：

我想做一個 {{ 簡短描述功能 }} 功能。

User Story：我是 {{ 某類型 }} 使用者，我想做 {{ 某個事情 }}，希望能在 {{ 某個狀況 }}看到{{ 某個效果 }}

我的想法是可以這樣做：{{ 描述你想要的作法，比如用某個資料表、串某個 API 服務}}

請 review 相關程式碼，幫我規劃最好的實作方式，但先跟我討論，先不實作。

Code Review 英文的部份是抄這位先生的：

請 review 還沒有 commit 的程式碼（或是剛 commit 的幾個）

Consider:

1. Code quality and adherence to best practices

2. Potential bugs or edge cases

3. Performance optimizations

4. Readability and maintainability

5. Any security concerns Suggest improvements and explain your reasoning for each suggestion.

不要動任何檔案，只要 review 並提供 feedback。

寫測試（其實我在 AGENT.MD 已經告訴諸位 AI 要 TDD，先測試，但開發完後有時還是沒寫）：

[自動化測試] 我想確認這樣的修改沒有影響功能邏輯和操作性，請確認是否有針對這次修改撰寫對應的測試，如果沒有請補上，並進行自動化測試，再告訴我需要手動測試的部份。

重構：

[重構] 請幫我再 review 最近的修改，ultrathink 看看有沒有可以優化的地方，請特別注意有沒有 over-engineering 的地方，希望能讓程式容易維護、乾淨簡潔。重構後，跑剛才寫的自動化測試，並告訴我需要手動測試的部份。

一直卡住的時候：

[一直卡住時] 請幫我 review 程式碼，然後上網搜尋相關需求的 best practice 寫法，並 ultrathink 去仔細思考有沒有更好的寫法，注意不要 over-engineer。

不太確定程式運作邏輯有沒有符合我的期望時：

請 review {{ 功能 }} 相關程式碼，確認是否有符合我的需求。{{ 插入 user story }}

寫文件：

[文件] 趁記憶猶新，請幫我把 {{ 功能 }} 的邏輯寫成文件，放入現有 SPEC 檔案。只要文字描述目前流程、架構邏輯，簡單說明，不需要包含程式碼和修改歷程。

除了寫程式之外，我也很常需要查文件，確保對系統的掌控度不要太差，最近從 Arc/Dia 系列換成 Comet 覺得還不錯，他的 AI 可以操縱瀏覽器，做任何想要的事情（像是「幫我登入 Cursor 下載最近一期帳單」），或是閱讀文件回答我的問題。

對於幫我找到工具介面上的指定功能怎麼使用也很方便。

用 AI 開發實在是很棒的感覺，我目前做好的 app 自己用的很開心。他們 99.9% 都是 AI 寫的，但擁有我的靈魂，畢竟我也花很多時間確認需求、討論解法、測試、發想商業邏輯。雖然距離真正可以發佈還有段距離，不過每天都覺得一人抵 10 人，這個效率的提升是翻天復地的提昇，很期待 AI 的未來。

最後想問，我在考慮直播 vibe coding，大家會有興趣嗎？我不是專業工程師，但我自認很擅長用各種工具提昇效率。直播的時候大家可以看到我怎麼用 AI 和各種工具，也開放大家指導我怎樣 vibe coding 更好。算是個交流嗎？

比特幣過 10 萬，乙太坊破 4 千，牛市終於來了！在熊市死很久的我也要活起來，先分享一下熊市我做了什麼：幾乎沒有！上一輪牛市每天聽老師報點位開倉的日子，在 FTX 🥹 和大熊來了之後就結束了，現在還有點懷念。熊市期間我只有擺爛而已，放了這些：

• DAI 8%
• AAVE 5~15%
• Lido
• Binance Earn
• Binance Launchpad

就這樣單純，都是躺賺的那種，目前看來有 15% 左右。但牛市可不能就這樣止步。上一輪牛市學了技術分析、操作合約，但我的紀律很差，實在很容易出錯，所以這輪牛市我決定先做空投、套利、收益池。

今天介紹的是 Spark，是我在熊市一直用來放 DAI 的協議（後來變成 USDS），今年初已經進行過第一波 airdrop，現在還有機會參加第二波。

🪂 規劃 Spark Airdrop 收益策略

Spark 是一個 DeFi 借貸協議，由 MakerDAO 的創始人 Rune Christensen 創立。它建立在 Ethereum 上，旨在提供一個簡單、透明且高效的借貸平台。Spark 的設計靈感部分來自於 MakerDAO，但它更專注於用戶體驗和效率。

第二波 Airdrop 條件如下（官方文件）：

• 借 DAI 的人拿 80% 🤑
• 供應 ETH 的人拿 20% 💎

以上會用 6.66M SPK 來分配。另外還有 3.33M SPK 會分配給在 AAVE 供應 USDS 的（供應頁面），本篇只有筆記 Spark 的部份。

看到這樣的條件，很明顯的，供應 ETH、再借 DAI，就可以收益最大化。

來看一下收益 📊：

供應 ETH 目前有 2.03%，借 DAI 出來 12.55%。也就是說為了拿這個空投，我們要付 12.55% 的利息。

那怎麼辦呢？好在現在有許多收益更高的穩定幣投資機會，這邊介紹幾個。

Nekodex - 140%

Nekodex 是個有著 CEX 體感的 DeFi app，只要 Email 註冊就可以投資各種官​方精選的 DeFi 現貨和收益池。目前穩定幣收益池有 USDM，這是一個美國 T-Bills 產品，USDM 有 4.7%，加上 Nekodex 現在也在空投，存 100 元就每天給 100 顆 Nekocoin，換算下來有 140% 左右，但有上限 $7000，超過的還是只有 4.7%。

🛡️風險：Nekodex 智能合約風險、USDM 風險、Nekodex 獎勵方案隨時可能降低。
👉 這是我上班的公司，有興趣可以用我的 code 多拿 5 倍註冊獎勵：hanamizuki

Bybit - 29%

Bybit 從 11 月中開始推出 USDe 持幣就有最多 29% 年化的方案，只要帳戶有 USDe，每天就會發放利息，總獎金有 8.35M，應該是發完為止。目前看起來有 27%（官方公告）。

🛡️風險：中心化交易所都有 FTX 風險、不知何時發完要隨時查看、持有 USDe 的風險。
👉 如果還沒有帳號歡迎用我的 code: QRDE0K

Spark 10-25%

• Spark Lending - 10~25%：既然都從 Spark 貸款出來，直接用這邊的收益也是一個選擇，上週 USDC 池子有 25%，但這個年化非常浮動，幾乎每天都不一樣，因為這是平台根據大家借款狀況動態調整的，不像前面兩個是固定的。但還是可以考慮。
• Spark USDS - 12.5%：也是一個選擇，是固定的數字。但是大哥哥，現在大家都超過這個數字，牛市了啊！

🛡️風險：Spark 智能合約風險、年化浮動可能會低於借款利率造成虧損。

⚠️ 了解風險

以上即使算好不會虧損，還是要知道一些風險，下面列幾個。

1. 清算風險：我們的規劃是把 ETH 拿進去抵押，然後拿 DAI 出來，如果 ETH 跌了，有可能抵押不足就會被清算，所以要注意健康值，官方建議 3 以上。我的大神同事 Henry 建議 1.5 ~ 2 以上，還是要看大家願意承受的風險。
2. 利息風險：借錢出來就要付利息，如果很多人都衝進去借，利息也會變高，還是需要偶爾回來查看的。如果不想承擔，可以只做「供應 ETH」的動作就好。
3. 智能合約風險：所有 DeFi 都有這個風險，簡單說就是怕被駭。Spark 看起來有Trail of Bits、OpenZeppelin 等審計，報告公開並透明，有助於確保合約沒有顯著的安全漏洞。另外他們有開放原始碼，也可以降低一些風險，不過這風險終究是存在的。
4. 區塊鏈風險：Spark 在以太坊主網，如果以太坊遭受攻擊或是有技術問題，那就會很慘。
5. 操作風險：DeFi 都不太好操作，Spark 其實已經做的不錯，但如果你沒有錢包管理、跨鏈、Gas Fee 等概念，操作錯誤就無法挽回了。而且 Spark 在主網，Gas Fee 很貴，只是放錯池子重放可能都要多花好幾十鎂。

⚙️ 實際操作

規劃好了，就來實際操作吧！這邊筆記我的操作記錄。

1. 供應 ETH
2. 借 DAI

完成之後點上面的空投按鈕，就會看到他在跑。🚀

也會看到錢包裡面的 ETH 不見了（跑到 Spark 合約裡），然後多了一些 DAI。

接下來看希望把這些 DAI 放到哪個地方，如果需要轉換成 USDC 或是 USDS，Spark 有提供保證 1:1 的轉換工具，還算方便。

📜 總結

這次的操作可以這樣總結機會與風險：

• 為了 Spark 的空投，放棄了 Lido 的 3%，在 Spark 拿 2.15%。
• 如果 ETH 大跌可能有危險，需要監控 📉。
• 希望風險低一些，能賺的 APY 和點數就會比較低。若能承擔更高風險，點數和收益都可能更多 💹。
• 因為在主網，這些操作的 gas 很貴 ⛽，需要考慮，最好金額大於 1000，期望能運作好幾個月。

最後還是看我們對這次空投的期望，是不是值得這樣做，之後空投確定的話我會再分享喜悅 🥳 或是幹瞧 🤬。