你知道 Zeabur 被入侵了嗎？

Zeabur 是一個雲端佈署管理平台，以簡單好上手著名，深受新手開發者的喜愛。

在 8 月 27 日，駭客把 Zeabur 雲端佈署管理平臺的專案環境變數，整批匯出。

什麼意思呢？我們平常如果要開發 AI 應用，會把 AI API Key 放在專案的環境變數裡面。

這個是正常的操作，至少不是把金鑰放在前端的頁面裡。

但是駭客攻破 Zeabur，取得了大量的 AI API 金鑰，導致有人的信用卡被刷爆，也有人的 OpenRouter 餘額瞬間被用光了。

沒想到現在連把 API 金鑰放在環境變數都不可信，我們一般的新手要開發個人專案，應該怎麼辦？

各位好，我是 Raven，目前專注於研究 AI 工具與自動化流程。

今天這一期的電子報，除了想跟大家聊聊這起資安事件。更重要的是探討，如果我們用 AI 做好了一個網站，我們的 API 金鑰應該放在哪裡才好？

Zeabur 是什麼？為什麼那麼多人在用

Zeabur 是台灣的新創公司，創辦人林沅霖是桃園人，畢業於浙江大學計算機系，這個產品的起點是他的畢業專題。

Zeabur 本身就是一個二房東的服務。

它不是 AWS、Google Cloud 那種擁有大量資料中心與實體伺服器的 IaaS（基礎設施即服務）業者，而是建立在其他雲端供應商之上的管理平台。

它做的事情叫 PaaS（平台即服務）。

簡單來說，你把寫好的程式碼丟上去，剩下的它幫你搞定。

傳統上要讓網站上線，你得自己租伺服器、裝作業系統、設定環境、處理網域和憑證。

Zeabur 的做法是「一鍵部署」——上傳程式碼，平台自動分析它用什麼語言、需要哪些函式庫、要多少資源，然後從 AWS、Google Cloud 這些廠商裡挑一個方案幫你部署完成。

在現在這個 AI 的時代，我們一般人只用 AI，就可以在一個晚上把網站架起來。

雖然我們很快就能把網站架起來，我們還是需要有一個服務，讓我們把網站放上去。

所以 Zeabur 的定位，就是提供給新手小白更簡單的部署方式。

換句話說，它的使用者裡有相當比例是不太懂伺服器維運的人。

Zeabur 這次到底發生了什麼事

這一次攻擊大概是這樣子：

駭客手上有一把外洩的 AWS 管理金鑰，所以駭客呢，就用它打進 Zeabur 設在東京機房的 AWS 共享叢集，取得控制面 VPN 的存取權，進入了主資料庫。

接著駭客在資料庫裡，針對「專案環境變數」這張表做了定向查詢與匯出。

簡單來說，駭客就是衝著 AI API 金鑰來的，因此有大量使用者的 AI API 金鑰，就這樣子流到駭客的手上。

目前 Zeabur 官方已經有公告，撤銷及更換了受影響的憑證，並且找了第三方的資安專家介入。

在賠償方面，創辦人承諾最晚在 9 月 30 號前會完成撥款。目前申請案已經有 63% 的申請已經核實，並且進入處理階段。

另外有一個小插曲，就是據說有暗網的貼文聲稱，他們已經掌握了完整的資料庫，所以不只是匯出的環境變數而已，甚至還擁有整份的程式碼。

不過，創辦人林沅霖強調，現在他們掌握的證據無法佐證這個說法。

將 API 金鑰放在平臺提供的環境變數裡面，居然還沒有辦法保障安全，這起事件大概顛覆了很多人的想法。

所以未來我們要怎樣才可以做到最起碼的資安防護呢？

第一層防禦：要選能夠儲值的 API 供應商

在資安界裡面，有一個概念是縱深防禦（Defense in Depth） 。它的核心想法是：

不把安全寄託在單一防線上，而是在不同位置設置多道彼此獨立的防禦措施。即使攻擊者突破其中一層，後續防線仍能阻止、限制或偵測攻擊。

運用這個概念，我們第一層就是要確保我們的 API KEY 即使外洩，損失仍然有限。

首先，如果是企業的話，有企業的做法，這個就先不提了。

我的讀者應該都是屬於個人開發者，甚至是沒有佈署經驗的新手小白。

我們個人開發者在做一些 side project 或者是創業、副業相關的專案時，不會希望一開始就花太多錢。所以最好的方法，就是我們的 API 供應商可以選擇用付費儲值的方式。

API 供應商的收費大致分兩種。

• 預付儲值制是先儲一筆錢進去，用完就停，金鑰被偷的最大損失就是帳戶餘額。

• 後付信用卡制是綁卡用多少扣多少，金鑰被偷，駭客可以在你發現之前一直刷下去。

所以我認為你還是可以把 API 金鑰放在平台的環境變數。

但是不要假設它不會外洩，而是假設它總有一天會外洩，然後想辦法讓損失是可控的。所以你應該要選擇預付儲值。

在這一方面，OpenRouter 就做得特別好，因為它可以針對每一把金鑰單獨設定額度上限，還可以指定這個額度是每天、每週還是每月來重置。

所以我們可以幫每一個專案建立一把獨立的金鑰，然後去設定說，比方說這個月最多就是只能用 10 美金。這樣一來，未來就算某個專案的金鑰外洩，你的損失也是控制在這 10 美金以內。

不過要記得，自動加值要關掉。

第二層防禦：如果有自己的雲端機器，就不必把變數放在平台

現在這一次就是 Zeabur 的平臺相關變數都外洩。那如果我們自己本身就有自己的雲端機器的話，其實我們也不需要把變數放在平臺裡面。

由於 Zeabur 現在不提供共享主機，它要求使用者必須要租一臺屬於自己的伺服器，所以我們可以把 API 金鑰放在自己的機器上。

所以我就讓 AI 幫我重新設計，在我的主機上運行一個 API 閘道。

我將 DeepSeek 的金鑰放在這個閘道內，在我們 Zeabur 的環境變數裡面，只會放一個我們這裡產製的存取權杖。

整個架構的邏輯是這樣：

Zeabur 的中央資料庫（也就是 8 月 27 日被整批撈走的地方）

• 我的環境變數裡，只會放一把存取權杖（Access Token）

• 就算被撈走也沒用，原因等一下說明

我租的專用伺服器

• 上面跑著 Zeabur 的容器，只拿到那把存取權杖，沒有金鑰

• 旁邊還跑著一支 API 閘道（API Gateway），直接架在主機上，不經過 Zeabur 的部署系統

• 真正的 DeepSeek 金鑰只存在這支閘道手上，從頭到尾沒進過 Zeabur

Zeabur 上的網站只拿到一把存取權杖（Access Token），其實就是程式隨機產生的一串字。網站要用 AI 的時候就帶著這把權杖，去請求主機上那支 API 閘道（API Gateway）代為呼叫，再把結果送回來。而這支閘道，只會接受從 Zeabur 那台機器的網路位置打來的請求。

因此，原本的流程是「網站直接拿著平台的環境變數去呼叫 DeepSeek」，現在改成這樣：

1. 網站要用 AI 的時候，不會直接使用 DeepSeek API 金鑰，而是把請求丟給 API 閘道，並附上那把存取權杖

2. 閘道先檢查第一件事：這個請求是從哪裡送來的？ 位置不對，直接拒絕

3. 位置對了，再檢查第二件事：權杖對不對？ 錯了，一樣拒絕

4. 兩道檢查都過，閘道這時候才補上真正的 API 金鑰，代替網站去呼叫 DeepSeek

5. 拿到 AI 的回覆之後，再把結果送回給網站

整個過程中，Zeabur 上的網站從頭到尾都沒有碰過真正的金鑰。

第三層防禦：但金鑰搬回自家主機，等於你要自己顧好

寫到這裡，你可能已經發現一個問題：API 金鑰現在放在我自己的主機上，那我的主機安全嗎？

如果沒有特別設定，真的很危險。

我請 AI 幫我檢查這台機器的登入紀錄，光是那一天，就有數千次登入失敗的紀錄，全都是來自世界各地的機器人。

例如從紀錄來看，root 被猜了 1219 次、admin 270 次、user 194 次，而 ubuntu 被猜了 191 次——正是我這台機器實際的帳號名稱。

其實任何一台有公開 IP 的雲端主機，租下來的那一刻起就會被全世界的掃描程式輪流掃過，這是常態。

老實說，我當初從 Zeabur 上租到這臺機器的時候，我也沒有特別做什麼設定，底下是我的初始設定：

• 開放密碼登入——只要猜中密碼就能進來

• 允許 root 直接登入——而 root 正是被猜最多的帳號

• 防火牆完全沒開

• 沒有任何自動封鎖機制，所以那些 IP 可以無限次地猜下去

設定新主機，你至少要作三件事

我也不是什麼資安高手，這件事情我也只能問 AI，所以我就請 AI 幫我做了底下三件事：

第一件：裝上自動封鎖（fail2ban）。 設定成十分鐘內失敗五次就封鎖一小時，累犯逐次加倍、最長封一週。裝好不到五分鐘就封掉了三個 IP，全是前面那份名單上的常客。

第二件：關閉 root 直接登入。

第三件：改用金鑰登入，關掉密碼登入。 這樣就可以讓機器人連登入的機會都沒有，我直接從我家裡的主機透過金鑰登入，不需密碼。

相關連結

• Zeabur 官方狀態頁

• INSIDE：Zeabur 環境變數外洩！Anthropic、OpenAI、OpenRouter API 憑證遭盜用

• 鏈新聞：Zeabur 資安事件更新，63% 賠償申請已核實

• Meet 創業小聚：Zeabur 瞄準「巨頭不做」的 Vibe Coding 部署市場

• Google：Gemini API 計費說明

• OpenRouter：每把金鑰的額度上限設定

• Cloudflare：AI Gateway 的 Bring Your Own Keys

社畜進化論｜Raven AI

如果你也想把 AI 從聊天工具變成真正能夠進入工作流程的 Agent，歡迎加入我的 Skool 社群「社畜進化論｜Raven AI」。裡面可以一起交流導入方式、分享實作成果，也一起處理權限、驗證與自動化流程中遇到的問題。

https://www.skool.com/decode-ai-ai-2667

最近網路上流傳一段 Sam Altman 的訪談，我們來看一下這段訪談。

www.youtube.com/watch?v=kG8AoExkX40

有不少媒體都表示，Sam Altman 承認 AI 發展沒有想像中這麼快。

聽起來像是他過度高估了技術方面的發展。

但如果把前後文聽完，Sam Altman 並不是說 AI 模型進步得太慢，而是企業、社會跟整個經濟結構改變得比它原先預測的還要慢。

在 2023 年 GPT-4 出現的時候，Sam Altman 原本覺得軟體產業會受到很大的衝擊，因為每個人都有辦法用 AI 來開發程式了嘛。

結果並沒有。

他認為自己低估了經濟體的慣性。

人們還是會繼續向熟悉的公司購買產品，繼續使用原來的工具，維持原本的工作方式。

可是有沒有可能，當有一天 AI 的能力大幅增長，且成本大幅下降時，這時候的改變可能就會是極其劇烈？

因此，我認為還是得做好準備，去迎接 AI 浪潮。

各位好，我是 Raven，目前專注於研究 AI 工具與自動化流程。

在今天這一集裡面，我想要針對 Sam Altman 的談話再延伸出來談：

為什麼大部分的企業在導入 AI 的速度還是相當的緩慢？如果要把 AI 加入工作流的話，可以從哪裡開始？

臺灣企業不是沒在用 AI，但的確還有很大的成長空間

首先，臺灣企業當然也是有在使用 AI 的，並不是完全沒有使用。

人工智慧科技基金會的《2026 台灣產業 AI 化大調查》顯示，在 228 家受訪企業中，有將近五成的受訪者對 AI 應用有一定的認識，而且正在進行 AI 專案的實驗與導入，甚至有些公司已經開始進行規模化應用。

將近五成，聽起來似乎滿多的，但是要知道，這個並不是機率抽樣，而是便利抽樣。

人工智慧科技基金會是從它會員裡面挑 228 個受訪者，所以可以想見的是，這些受訪者可能本來就對人工智慧有興趣。

另外，在不同產業之間差異更大，

• ICT 產業對於 AI 的導入與應用合計為 60.9%。

• 傳統製造業合計為 38.5%。

• 營建工程、農林漁牧礦合計只有 9.1%。

所以要我看這份報告的話，在這群本來就對 AI 有興趣的企業裡面，都還有超過一半沒有走到「有明確目標、正在試驗導入」的階段。

那些沒有出現在這份名單上的企業，情況只會更保守。

甚至在工作上能夠使用免費的 ChatGPT 來輔助，可能都算是有一點 sense 了。

我自己待的單位，因為屬於科學機構，高層當然是有意識想要導入 AI。不過畢竟是新科技，所以許多做法都還是很保守。

我目前觀察到三個主要原因。

第一個原因：把學 AI 丟給員工個人，本來就推不動

雖然每個人其實都知道 AI 很重要，高層當然也會知道。

可是知道 AI 很重要，跟怎麼樣把工作流程改成 AI 自動化，還有很大的差距。

比方說，我自己待的機構，你要說長官對 AI 不夠重視嗎？那絕對是錯的。

因為我們常常都會有一些 AI 的講座、通識類課程，或者買個 ChatGPT 帳號讓大家共享。

這些做法都成效不彰。

因為現在 AI 已經跟去年有了很大的改變。

2026 年是 AI Agent 的年代，不再是一問一答的網頁模式，而是住在電腦裡面直接幫我們完成工作的 AI Agent。

幾個人共享一個 AI 帳號，那肯定就只能做一問一答，遠遠沒有辦法榨出 AI 真正應有的能力。

然後這些 AI 講座、通識課程，不是說不好，但是如果只有開課，沒有配套政策，等於是把學習 AI 這件事情，丟給員工個人。

員工平常又不是不用工作，還要多花時間學 AI。他們還是比較喜歡自己習慣的工具。

除非員工本身對 AI 很有興趣，否則他一定會抗拒去學習。

所以這類的課程，甚至更進階的 AI Agent 應用相關課程，其實應該要由高層主動去上。

長官上完課、有了概念之後，才由上而下去推動，全面地修改工作流程。

其實要把工作流程改成 AI 工作流這件事情，它有點像是當初 1990 年代末開始的數位轉型。

大部分的企業、政府單位在數位轉型這方面，都只是把原有流程改到電腦上執行而已。

以公文系統來說好了，至今仍有公文系統居然還要有模擬蓋章這件事情。

都已經在電腦上作業了，為什麼要蓋章呢？蓋章的意義到底在哪裡？

寫好公文發出去，會經過自然人憑證，這不就是數位簽章了嗎？但在系統上卻偏偏還會有一個像人類蓋章的行為。

所以要做數位轉型的話，就是要重新去梳理工作流程。某一些只適合在紙上、不適合在電腦上執行的行為，就不需要再做了。

假設今天要把數位流程再往前推，變成 AI 工作流的話，也是同樣的道理。

不是所有流程都需要重新設計。但是要加入 AI 的那一段，一定要先重新梳理過，不能直接把模型塞進原本的流程裡。

舉一個很常見的例子。很多公司每個月都要做月報，流程大概是各單位先交 Excel，交給某個小承辦彙整，提交給主管看過，可能還會做成簡報。

如果直接把 AI 加進去，多數人的第一個念頭是，那我用 AI 作，節省時間。

可是這樣做，流程根本沒有變，只是做得比較快而已。

真正該問的問題是，這份月報做了之後有誰在看？看完之後會做什麼決定？

如果答案是沒有人真的根據它做決定，那應該先思考這份月報本身，而不是拿 AI 去加速生產一份沒有人看的東西。

至於有能力說出「這份月報到底誰在看」的問題，並且有權力把它砍掉的，就只有高層長官。

所以這件事一定要由他們來當領頭羊才行。

第二個原因：年初學，年底就過時，工具變得太快了

現在工具變化實在是太快了，如果要叫員工去學的話，很可能員工年初學的工具，到年底就不適用了。

以我自己為例，我在年初的時候做了三個課程：

1. 第一個是大略性地介紹 ChatGPT、Google Notebook、Notion AI、Google Antigravity，用來做知識管理。

2. 第二個是講 n8n 以及大型語言模型的應用。

3. 第三個是怎麼使用 ChatGPT 來製作 Google Apps Script 的應用。

到了現在 8 月，ChatGPT 的個人帳號已經不能再建立新的自訂 GPT，企業方案的自訂 GPT 也開始被 Workspace Agents 取代。Google Antigravity 大幅改版，另外拆成了 IDE 與 Agent 兩個版本。

至於 n8n 則是越來越少人在談，因為 AI agents 已經取代了許多需求了，現在除非你有需要做比較複雜的流程，n8n 可能還有使用的機會。

只剩下使用 AI 來做 Google Apps Script ，這倒還是個不錯的主意。

所以如果企業要讓員工去學習 AI 工具的話，比較可行的做法是讓每個員工都要配一個訂閱制的 AI 帳戶，或者是如果有自己的機房的話，就建一個本地端的語言模型，讓需要使用的人去存取。

然後在公司內組織活動，鼓勵員工進修，培養不斷學習的能力。

如果真的要引入一些課程或者外聘一些講師的話，更重要的是要去講解不容易過期的能力。比方說：

• 大型語言模型的原理

• 怎麼撰寫提示詞

• 如何設計全域、專案規則

• 如何依照工作流程設計技能

第三個原因：模型實在太不受控了，誰敢用

直到目前為止，我們每次在使用 ChatGPT 的時候，都還是會看到底下會顯示一條資訊：「ChatGPT 可能會出錯，請查核重要資訊」。

是的，大型語言模型具有機率性，產出來的資料可能是錯的，而且錯誤的機會還不小。

這樣子的工具，怎麼可能讓企業老闆決定使用大型語言模型？

而且我們三不五時就會看到新聞報導說，有人用大型語言模型不小心刪除了整個資料庫。

之前 Anthropic 也爆出因測試環境設定失誤意外連上網際網路，模型未經授權存取了 3 個外部真實組織的系統。

這些新聞都可能會讓企業高層覺得心驚驚，不知道要怎麼樣去控制這個語言模型。

所以模型真的無法控制嗎？

當然是可以控制的。

我們需要一個 harness 作為大型語言模型的架構，去限制它的邊界，也就是限制它產出的結果。

Agent harness 可以理解成包在模型外面的控制系統。它負責決定：

• AI 可以看到哪些資料

• 可以使用哪些工具

• 哪些動作需要人類核准

• 每一步要留下哪些紀錄

• 發生錯誤時怎麼停止、重試或復原

• 如何持續測試與監控結果

比方說 Claude Code、OpenAI 的 ChatGPT，或是 Google Antigravity 這類工具，它們本身就包含 harness 架構。

所以 AI Agent 動手之前先問你要不要授權，也會把每一步做了什麼列出來，這就是 harness 在做的事。

可是這些工具的邊界是廠商幫你決定好的。

所以我們能做的，就是針對這些工具，再透過設定 SOP 的方式，讓它可以更受控制。

這個工作就建議要有一個嫻熟於操作 AI Agent 的人來負責維護。

如果不使用大廠 harness 架構，要自己架站，使用開源模型，那麼也是要有一個工程師來為模型設計專門的 harness 架構。

企業應該從什麼地方開始？

我認為比較實際的方式，不要一開始就想要打造一個能夠取代許多電腦上任務的超級 AI Agent，而是找一個流程已經很明確的任務，設法讓 AI 去完成。

例如：

• 整理每日報告

• 彙整異常訊息

• 建立會議摘要

• 替客服產生回覆草稿

然後再逐漸地把這個工作擴大，並且要由一個專人專門來做「設計 AI 流程」這件事情。

假設公司有在使用 Google Workspace 的話，我強烈地推薦一定要讓員工試著使用 AI agent 建立 Google Apps Script，來讓 Gmail、Google 表單、Google 試算表等各種 Google 工具，將它們串聯起來做自動化。

要學習使用 AI agent 來建立 Google Apps Script 也是非常的簡單。

我自己做了一套開源的教材，叫做 Learn-GAS，放在 GitHub 上面，任何人都可以自由取用。

只要你有 ChatGPT、Claude 或者是 Google Antigravity 這種的 AI 工具，把連結丟給 AI ，就會帶著你做了。

裡面提供了兩條學習路線：

第一條是五個各自獨立的小案例，像是記帳、產生信封、批次寄信；

第二條是八堂課，循序把一套活動報名系統完整做出來。

我也寫了一些 SOP，把初學者最容易卡住、最容易搞混的地方定成規範，讓 AI 照著走，不會每次給出來的做法都不一樣。

Learn-GAS：讓 AI Agent 帶你學 Google Apps Script

AI 跑得快，企業改得慢

回到一開始 Sam Altman 那段訪談。

他說自己低估了經濟體的慣性，人們會繼續用原本的方式工作。

但是他在同一場訪談裡也承認，理論上他應該用完全不同的方式操作電腦，結果他還是在複製貼上，還是自己滑信箱，自己維護待辦清單。

所以這就是人性啊！有時候我們明明知道有更好的做法，可是我們還是照著以前的習慣來做事。

因此，雖然臺灣企業導入 AI 的速度比較慢，也不一定代表老闆沒有看出 AI 的優點。

本來要叫員工去學新技能就比較難啊，而且工具迭代的速度這麼快，學了沒多久很快就過期了。然後 AI 畢竟還是有出錯的可能性，還得有專人維護。

這幾件事情加起來，就是慣性持續存在的原因。

就算企業決定建立 AI 工作流，模型工具迭代速度太快了，總不可能隔幾個月就再重新建立流程。

不過，這也代表微型企業在這個變動快速的時代，會比大型企業來得更有彈性。

我們甚至可以推斷，未來幾年內人數在 10 人以下的小公司，甚至是 5 人以下，或者一人公司，可能能夠透過 AI 的這波浪潮而紛紛興起。

你也準備好了嗎？

相關連結

• Sam Altman 完整訪談影片

• Sam Altman 關鍵段落：4:12～4:48

• David Senra 官方節目頁

• 訪談 AI 自動轉錄逐字稿（可能包含辨識錯誤）

• 人工智慧科技基金會：《2026 台灣產業 AI 化大調查》

• Anthropic：首次揭露的 AI 主導網路間諜行動

• OpenAI：Agent harness 與 Agents SDK

• Learn-GAS：讓 AI Agent 帶你學 Google Apps Script

社畜進化論｜Raven AI

如果你也想把 AI 從聊天工具變成真正能夠進入工作流程的 Agent，歡迎加入我的 Skool 社群「社畜進化論｜Raven AI」。裡面可以一起交流導入方式、分享實作成果，也一起處理權限、驗證與自動化流程中遇到的問題。

https://www.skool.com/decode-ai-ai-2667

最近台灣 YouTuber「壹加壹」的 Lean 老闆，用 AI 做了一個自動上字幕的網站 What’Sub，據說上線兩天，註冊就破了一萬人。

然後網路上吵成一片。

有些留言酸得很，什麼產品技術含量很低啦、免費開源的一堆幹嘛還要花錢。

還有人直接動手，說自己只花一個小時，就用 AI 做出一個功能差不多的版本。

真的一小時就能抄得了嗎，那麼 Lean 老闆花半年加上 20 萬到底在幹嘛呢？

各位好，我是 Raven ，目前專注於研究 AI 工具與自動化流程。

在本集中，我想要跟大家談談使用 AI 製作產品的關鍵是什麼？又要怎麼小心資安的問題？

用 AI 做的自動上字幕的網站 What’Sub 是什麼？

用 AI 做網站，俗稱為 Vibe Coding。

簡單說，就是你不用自己一行一行寫程式，而是用自然語言跟 AI 描述你要什麼，讓 AI 幫你把程式寫出來。

所以這起事件呢，就是 YouTube 頻道「壹加壹」裡的 Lean 老闆，在這次最新的一集影片中，推出了一款產品叫做 What’Sub。

這是一個在瀏覽器上用的自動上字幕工具，是由 Lean 老闆一個人開發，前後花了大概半年、投入了約 20 萬臺幣。

可是他本身不是軟體工程師，而是有十年經驗的全職影片創作者，這個產品是用 Vibe Coding 做出來的。

為什麼被酸？

我不會說所有反方都是酸民啦，有些人也是有提出一些比較實質的意見。

但是酸民數量也的確不少，他們是這麼說的：

• 這只是把現成的技術包一包，技術含量很低。

• 免費開源的工具一堆，自己就能打造，幹嘛付錢，這是在割韭菜。

• 他只是把別人早就在做的軟體套上自己剪輯的專業外殼，拿來賣錢，賺的是粉絲的錢。

另外，網站上線後真的被回報了資安問題，樹大招風嘛，於是就有人嘲笑說，這就是 Vibe Coding 的下場。

What’Sub 雖然技術不新穎，但是開發者的確知道痛點

可是我得稍微反駁一下酸民。

他們都說技術含量很低，免費開源的工具一堆，自己就可以做，比如說 Video-use、Whisper 等等，為什麼要付錢？

可是如果真的那麼簡單，酸民自己怎麼不去開發一款呢？

說穿了就是在嘴別人而已嘛。

做一款產品從來不是只有寫程式這件事。

重點是你有沒有徹底理解痛點到底是什麼，以及你能不能用 AI 加上自己的特定的工作流程，把這個問題解決掉。

況且網路上也有很多工程師在稱讚這個作品。我們就舉三點來說明一下。

1. 「影片不上傳」提升體驗

一般的線上字幕工具，你得把整支影片傳上去。

What’Sub 的做法是影片留在你自己的電腦，只把聲音抽出來送去辨識。

這麼做除了處理隱私問題，也省伺服器成本。

2. 不只是一個工具，而是整條完整的工作流

What’Sub 是完整的產品，不只是單純的上字幕工具，包含金流、推薦碼、電子發票、錢包、訂單和管理後台等等，全部都做了。

3. 最容易被低估的，是各種調教過的功能

自動上字幕本身不稀奇，現在很多開源模型都做得到，真正厲害的是在同一個網站上就能即時編輯字幕、分段、對齊音軌、設定常用詞。

也就是 UX 使用者體驗要做得好！

的確，現在有很多免費開源的工具，我自己也是用開源專案 video-use 在上字幕與剪片，不用再另外花錢。

問題是一般人根本不知道怎麼使用，而且我們自己手刻的也不一定比較好。

資安真的是大問題

我自己是沒有去測試他的網站，只是根據目前公開貼文可以看得到的內容，目前有以下幾個較大的問題：

1. 未授權就能看到其他使用者的個人資料或影片

有人說，只要在網站按 F12 就可以看到從後端傳來的資料，這樣可能有個資外洩的風險。

2. 一般會員可以拿到金流的 hashKey 類資料

有人發現一般會員可以在網頁上取得藍新金流的hashKey 相關資料，可能能夠破解交易內容或者偽造付款通知。不過這部份官方說已經處理了。

3. 一上線就掛掉

同時上線人數衝到兩千以上，導致伺服器掛掉、出現 502。嚴格講這不算資安漏洞，是可用性的問題。

如果你沒有資訊背景，然後想要用 AI 開發的話，在資安問題上真的要特別小心。

但是也不需要嘲笑 Vibe Coding。

很多有工程背景的人做出來的東西，漏洞一樣一大堆，並不會比不懂資安的新手小白少。

任何想要把服務放到網路上的人都得面臨這個課題，這不是 Vibe Coding 獨有的原罪。

想 Vibe Coding 自己的產品，該注意什麼

我認為在這個時代，有了 AI 的輔助，任何人都可以用 AI 做出自己的東西。

只是首先要區分「作品」跟「產品」的不同。

作品就是你用 AI 做出來給自己用的。

壞了你就叫 AI 修，修得慢也沒關係。

資料外流頂多是自己的資料，損失有限，也不會有人來罵你。

產品就不一樣了。

你一旦開始收別人的錢、存別人的資料，標準就完全不同了。

一個成熟的產品，首先必須要能夠打中市場痛點，使用體驗要好，能夠滿足客戶需求。

尤其是軟體產品，在資安上要滿足：機密性、完整性以及可用性。

用白話講就是三句話：不該看到的人不能看、資料不會被偷改、需要用的時候要能用。

前面提到 What’Sub 被回報的問題，剛好就是這三件事。

所以我的建議是：新手可以先做給自己用，後續確認別人也有同樣的需求，再考慮把它變成產品。

上線前先把最容易犯的資安錯誤排除

雖然要小心資安，但一開始也不用把它想得太複雜。

我們新手最常出事的，通常不是什麼高深的攻擊手法，而是幾個很基本的錯誤。

第一，瀏覽器看得到的東西，就等於公開。

這次 What’Sub 被討論最多的，就是有人說在網站上按 F12 打開開發者工具，就能看到其他使用者的資料。

有人以為這是前端沒有處理好，其實不是。

真正的問題在後端，後端把不該給這個使用者的資料，直接送到瀏覽器了。

要知道資料只要送到瀏覽器，就等於送到使用者手上了。即使你在畫面上不顯示它，按 F12 一樣看得到。

所以正確的做法不是在前端把它藏起來，而是後端一開始就不要送出去。

同樣的道理也適用在金鑰。

這次被回報的另一個問題，是一般會員可以拿到金流的hashkey。

這種東西一定要放在後端，最好使用平台的環境變數設定存起來，不能寫在會被瀏覽器下載到的程式裡面。

第二，資料庫的權限要一張表一張表確認。

我們新手很常用的 Supabase、Firebase 這類資料庫服務，跟傳統做法不一樣：你不用自己寫後端，瀏覽器直接向資料庫要資料。

為了讓瀏覽器連得上，你必須把一把公開金鑰放在網頁裡，任何人按 F12 都拿得到。

這是設計本來就這樣，這把金鑰是可以公開的。

所以真正在保護資料的，只剩下你在資料庫那一端設的權限規則。

以 Supabase 來說，這個規則要一張表一張表分別打開。會員資料、訂單、發票，每一張都要設一次。

如果你忘記了，你也不容易發現，因為你在測試時一定是一切正常，你的網頁也只會去撈自己的那幾筆資料，不會替你試一次，繞過網頁直接撈整張表會發生什麼事。

要等到有人拿那把公開金鑰繞過你的網頁直接撈資料，你才會發現整張表都是公開的。

第三，上正式環境前要關掉除錯訊息。

在開發的時候，有時候我們會把除錯訊息給打開。

這樣才可以方便 AI 去查問題到底出在哪裡。

可是，如果我在正式環境也這麼做，錯誤畫面會把資料庫的結構、檔案路徑整個吐出來，等於直接給駭客一張地圖。

以上三點，所以該怎麼辦呢？

其實我們可以先使用最基本的 AI 掃描方式。主流的兩家 AI 工具都有官方自己的資安審查機制：

• Claude Code：內建斜線指令 /security-review，直接在專案裡面跑就好。

• Codex：另外裝 codex-security，它會去讀你的程式、嘗試重現問題、再提出修補方案。

上線前，先想好伺服器設定與花費

程式寫好了，接下來是把它放到網路上。

第一，不要自己租一台機器從頭裝。

我想現在應該不會有新手想要自己租一臺雲端機器（IaaS）。

新手小白直接用平台服務（PaaS）就好，像是 Zeabur、Vercel、Railway 這一類。

不管是加密連線、自動備份，平台都幫你處理好了基本設定，你只要專心在產品上。

第二，先想好人變多的時候會怎樣。

What’Sub 同時上線人數衝到兩千以上，伺服器直接掛掉。

這件事其實可以事先準備。

例如選方案的時候看一下能不能自動增加機器，前面再加一層像 Cloudflare 這樣的服務擋一下流量。

就算擋不住，至少要能顯示一個「現在人太多，請稍後再來」的畫面，而不是整個站掛掉。

第三，所有服務都先設好用量上限跟通知。

我們用的語音辨識、AI 模型這些服務，都是按用量計費的。

如果被大量使用，或者被人惡意灌爆，帳單會非常可怕。

所以在每一個會產生費用的服務後台，先把用量上限設好，再設一個到達多少就通知你的門檻。

上線之後，才是真正的開始

前面講的都還是技術問題，可以慢慢學。

真正麻煩的是上線之後的日常維運。

一般的軟體開發公司背後有一整個團隊在營運，有人當輪班仔照顧系統、有人專門處理客訴，有資安疑慮也能馬上有人上線修改。

我自己就是輪班仔之一。

但是個人工作室 Vibe Coding 出來的產品，通常背後只有一個人。

所以 What’Sub 雖然是一個蠻成熟的產品，但是如果 Lean 老闆只有自己一個人，這幾天大概都睡不著。

想想看，如果你出國玩一個禮拜，結果第一天晚上網站就當機，你要不要在飯店打開筆電遠端處理？

就算你願意，你有沒有把握修得好？如果那個時候剛好又被人發現一個資安漏洞呢？

你一定會希望有人可以幫你處理。所以這件事情最好的解決辦法是：能夠交給團隊的，就交給團隊；能夠外包出去的，就外包出去。

如果現在還找不到人合作，那至少要做到一件事：讓系統自己告訴你它掛了。

例如設一個監控通知，網站不能用的時候直接發訊息給你，而不是等使用者跑來罵你才知道。

最後祝福各位都能夠用 AI 打造出自己理想中的產品，我們下期見。

相關連結

• What’Sub：

https://whatsub.equal2.app/

• Video-Use（開源影片剪輯專案）：https://github.com/browser-use/video-use

社畜進化論｜Raven AI

如果你也想把工作流程交給 AI，卻不知道從哪裡開始，歡迎加入我的 Skool 社群「社畜進化論｜Raven AI」。裡面可以一起交流做法、分享自己實作出來的成果，遇到卡住的地方也有人一起解決。

https://www.skool.com/decode-ai-ai-2667

就算是現在還不行，未來的 AI 也一定可以。

可是如果你真的這麼認為，我覺得你應該是沒有用過 AI。

AI 是很強沒錯，它可以回答你任何刁鑽的問題、幫你找資料、操作電腦上面的工具，可是他的限制也很大。

AI 像一個被限制在局部視野裡的高智商人士

我認為跟 AI 聊天，就好像跟一個讀了很多書的博士對話，可是這個博士呢，手裡面拿著一杯 whisky，已經喝得醉醺醺的。

所以大體上，它都可以回答你的問題，而且回答得還不錯。可是就是在某些情況下可能會出錯，因為他已經喝醉了嘛！

還有 AI 的上下文極為有限，現在主流的前端 AI，上下文長度甚至超過百萬 Token，其實這樣的量也不夠多。

我個人使用經驗，大概經過二三十輪的對話之後，可能就要切換對話窗了。對話一旦越來越長，前面的資訊就會被壓縮忽略掉。

而且 AI 常常有過度發揮的傾向。我們一旦給錯了重點，它就會針對這一點去鑽牛角尖，然後忽略了整件事情真正的目的是什麼。

人類當然也會受到局部資訊干擾。只是我們人類的脈絡不只來自眼前這段對話，還包含生活經驗、人際關係、長期目標、利害與責任。

人類真正的優勢，不只是我們的「上下文長度」較長，而是我們知道自己為什麼要做這件事，也必須承擔結果。

AI 改變的，是我們處理知識的方式

我自己是歷史系畢業的學生，唸了三年的歷史研究所。其實對於我們文科研究生來說，花三年時間畢業不算是特別的久。

念四年，甚至到 6 年的，都大有人在

為什麼會這樣子？因為人類的精力是有限的，而史料是無窮無盡的。

儘管在2010年，我當時已經可以透過 Google 圖書與搜尋引擎找史料，速度比過去快很多。可是要搜尋、閱讀、篩選、整理，然後比較資料，還是要花很多時間。

如果當時已經有現在的 AI Agent，我可以讓它先讀過數位化的資料，進行初步搜尋、分類與篩選，再由我重新閱讀它找出來的史料。

所以我可以處理更廣的範圍，也把更多時間放在史料之間的關係、人物為什麼這樣互動，以及哪一種解釋更有可能。

這就是 AI 帶來的改變：它能夠幫助我們更快找到答案，改變了知識工作的方法。

AI 時代，我們應該學什麼？

但我也不是完全否定有些人提出的這個觀點：既然 AI 都讀了這麼多的書，我們為什麼還要花時間讀書？

我們拿寫程式來舉例好了。

現在還在堅持自己手寫程式的人越來越少，要麼直接讓 AI 去寫程式，然後人類去複查；最起碼也會用 AI 自動補全。

程式設計師越來越關注的其實是上層的系統架構，尤其是資料的輸入與輸出——資料怎麼被輸入，然後又會輸出什麼樣的資料。

至於細節上要怎麼運作，就讓 AI 去處理，人類主要作為審查的角色。

所以你說，那還需要去學怎麼寫程式嗎？

我認為還是需要，因為你只有學過寫程式，你才會知道系統是怎麼被建構的。

可是我不認為你還要學這麼多的程式語言，比如說 C 語言、C++、C# 、 Java、Python。你就挑一種來學就可以。

未來你要建置一個系統，要使用什麼樣的程式語言，決定好了之後，就讓 AI 自己去寫。

因此回到我們在 AI 時代應該要學習什麼的話題，我覺得在國、高中階段，國文、英文、數學、自然與社會這些基礎學科還是很重要，但是學習的重點其實是為了建立理解世界所需要的基礎。

進到大學，甚至出社會之後，我們更應該積極地去學習觀點型的內容。

所以我們讀書的目的呢，是學習作者怎麼樣去處理知識，他怎麼樣理解問題，他怎麼去建立他的思考的脈絡。

我們的確可以在遇到問題的時候去問 AI，讓 AI 來告訴我們答案。可是真正的重點是，我們要去學習當我們在沒有 AI 的時候，別人是怎麼樣去找到答案的。

只有這樣，我們才有辦法建立自己的判斷力。未來當我們要去設定 AI 代理的時候，我們也才會知道該如何去設定它的目標以及邊界。

我為什麼製作 My Real Second Brain？

我做了一個開源專案，叫做 My Real Second Brain，目標是簡化學習的步驟。

「第二大腦」是在 AI 出現以前就有的概念。那時候用數位筆記的方式，例如 Evernote、Notion 這種，然後再使用子彈筆記法、卡片盒筆記法的方式記錄。

雖然方法不少，可是做筆記會成為一個很繁瑣的工作。

因為讀完一本書之後，你看我們還要去打字、做分類、設定標籤，然後還要設定整個結構。所以很多人其實就是覺得很麻煩，後來你也懶得去把你讀到的內容，輸入到你的第二大腦。

我的想法是，先拿掉這個輸入與整理的障礙。

你可以搭配 Typeless 這類口說打字工具，直接把讀完一本書後的想法全部說出來。

透過 AI 代理與這個開源專案，AI 會先保留你接近原話的心得，再建立整理後的核心觀點，並把同一本書的記錄持續放在同一份筆記裡。

之後當你需要找資料時，AI 會先查你的本機知識，使用蘇格拉底詰問法的方式，搭配外部資料來挑戰你的想法。

所以這個開源專案的目標是：

1. 第一大腦：負責閱讀、理解，然後選擇你獲得的知識內容。

2. 第二大腦：負責把你想要保存的知識內容，以及任何細瑣的概念與知識，通通記錄下來。

未來我們可以透過跟 AI 的回顧過程去詢問，不斷反覆刺激我們的第一大腦。畢竟第二大腦的原則，是為了第一大腦而存在的。

如果你對於我的這份開源專案有興趣的話，我把連結放在底下以及 YouTube 的資訊欄，你可以直接去下載。

相關連結

• My Real Second Brain（GitHub）

• Typeless（AI 口說打字工具）

• Lost in the Middle：長文本模型如何使用上下文

社畜進化論｜Raven AI

如果你也想學習怎麼把自己的知識轉成能夠交給 AI Agent 保存、執行與驗收的工作流，歡迎加入 社畜進化論｜Raven AI，和大家一起交流、分享成果，也一起解決實際遇到的問題。

你使用 AI 的方式，還停留在一問一答嗎？

今天這篇文章要教你基礎的 AI 代理功能，來做 Google Workspace 工具的全自動化。

首先，除了你要有 Google 帳號以外，我建議你至少要有底下任一種的訂閱方案： - OpenAI ChatGPT Plus - Anthropic Claude Pro - Google AI Po

並且下載各自的桌面應用程式。

免費方案當然也有一些額度可以使用，不過我不太確定額度能不能支撐你做完整個自動化。

底下我會用 ChatGPT 桌面應用程式當作範例，如果你是用其他 AI Agent ，他們的功能都是大同小異的。

先分清楚 ChatGPT 的「對話」、「工作」與 Codex

當你在電腦下載 ChatGPT 之後，首先，你在右上角會看到一個下拉選單，點下去之後可以看到 ChatGPT 以及 Codex 這兩種不同的介面。

保持在 ChatGPT 介面，在上方還可以看得到切換的頁面，能夠切換「對話」與「工作」。

「對話」適合直接問答。你輸入提示詞，它再根據要求回覆；需要的時候，它也能使用網路搜尋。

「工作」適合把一項需要多個步驟的任務交給 ChatGPT，例如整理資料、研究主題或製作文件。

網頁版與手機版的「工作」會在雲端執行，也就是由遠端的 OpenAI 電腦環境處理；桌面版還可以選擇在本機工作，使用你自己電腦裡的檔案、應用程式與瀏覽器。

ChatGPT 還有一個介面叫 Codex ，它是針對軟體開發，或是技術性任務設計的工作介面，方便你讀取本機專案、執行工具，以及檢查檔案修改。

不過呢，剛剛提到的 ChatGPT 的「工作」與 Codex 的能力，其實是高度重疊的。所以我建議初學者，直接用「工作」即可。

在 Claude 桌面應用程式也有類似的情況，總共分了 Claude 的一般對話版、還有 CoWork，另外還有一個叫做 Claude Code。

專案與資料夾有什麼不同？

當你打算使用 ChatGPT的「工作」處理一項持續性的任務時，我建議你先建立專案。

簡單來說，專案就是 ChatGPT 用來組織一項工作的空間。

通常專案會綁定某個特定資料夾，但專案和資料夾不是同一件事。

建立專案時，可以先依照任務選擇兩個位置：

• 雲端：如果任務不需要使用你電腦裡的檔案或應用程式，可以交給雲端環境處理。雲端「工作」還可以跨平台，包含網頁、手機與桌面版。

• 本機：如果任務需要讀取本機檔案，或將完成的檔案，保留在電腦上繼續使用，就選擇本機。

在目前的 ChatGPT 桌面版介面，可以依序這樣做：

1. 從左側的「專案」按下「＋」。

2. 選擇雲端或本機，然後按下一步。

3. 輸入專案名稱。

4. 如果選擇本機，可以使用現有資料夾，或者先建立新資料夾，再按下「新增 ChatGPT 可讀取及編輯的資料夾」來選擇位置。

5. 確認資料夾後，建立專案。

這個資料夾就是你的專案主要讀取、建立，以及修改本機檔案的位置。

不過，如果你有需要使用瀏覽器、外掛程式、連線服務，或者你有給予完整存取權的話，也可能涉及資料夾以外的內容。

上述專案與資料夾的關係，同樣也適用於 Claude 與 Antigravity 。

給你的 AI 更多權限

所以接著就要談權限了。

當你要準備跟 ChatGPT 對話的時候，在對話框的左下角，你可以看得到有三種核准選項：

1. 要求核准：如果你要編輯專案資料夾以外的檔案，或使用網際網路以前，它會先詢問使用者。

2. 代我核准：自動處理部分動作不會先問你；只是偵測到可能不安全的操作時，仍然要求使用者先核准。

3. 完整存取權：不受以上限制，任意存取網路與電腦上的檔案，是風險最高的設定。

首先我建議你就先從預設的「要求核准」開始。

不過以我的使用方式來說，我都是從「代我核准」開始。它可以減少你的工作一直被核准視窗打斷，如果 AI 判斷可能不安全時，會再把決定權交回給我。

有時候我也會直接開啟「完整存取權」，等於是全權交給 AI 自己處理，選擇後，介面也會用橘色字體持續提醒你，目前處於高風險權限狀態。

總之，風險自負啊！

使用 AI 代理必學的概念：技能

當你要讓 AI 代理可以穩定地做出你想要的成果時，你一定要有完整的 SOP，並且讓它實際執行過一次。

這個 SOP 就叫做技能。

ChatGPT 桌面應用程式的技能存放位置，在左上角的外掛程式，外掛程式可以讓 ChatGPT 連接其他應用程式。你可以先把常用的都裝一裝，點下去按照步驟來做就可以了。

然後你可以在外掛程式頁面上方，看到 skill 選項，點擊後會切換到 ChatGPT 目前掌握的技能表。

在上一期電子報介紹了我製作的 Learn-GAS 技能包，它是一款引導 AI 代理製作 Google Wrokspace 自動化的技能包，安裝後就會放在技能表內。

用 Learn-GAS 開始第一個辦公室專案

如果你平常需要操作 Google 試算表、文件、Gmail、雲端硬碟，其實你可以使用 Google 推出的 Apps Script 工具來幫它們添加外掛功能。

使用方式如下：

1. 在桌面版的「工作」建立本機專案，並選擇準備好的資料夾。

2. 把 Learn-GAS 的 GitHub 連結，貼進專案對話區，請 AI 代理下載這個專案。

3. 請它先讀取專案裡的安裝說明，再依說明安裝技能。

4. 另外還可以建立自己的 Apps Script 專案資料夾，告訴它你想完成的辦公室任務。

ChatGPT 可能會把 Learn-GAS 專案的技能，安裝到全域技能目錄 ~/.agents/skills/。

如果你明確只想讓目前專案使用，可以告訴 AI ，讓它放在專案的 .agents/skills/。

現在你就可以開始製作你的第一個 Google 自動化流程了。

相關連結

• Learn-GAS GitHub 專案

• ChatGPT「工作」與 Codex 官方說明

• ChatGPT「工作」入門

• ChatGPT 更新說明

• ChatGPT 電腦操作說明

• ChatGPT 與 Codex 權限模式

• ChatGPT 與 Codex 技能說明

加入社畜進化論｜Raven AI

如果你也想和更多正在實際使用 AI Agent 的夥伴交流、分享成果，並一起解決工作與自動化上的問題，歡迎加入我的 Skool 社群「社畜進化論｜Raven AI」。

像是 Gmail、Google 試算表、Google 文件、Google 表單，還有 Google Drive。

這些功能只要一般的個人免費帳號就能使用，而且早就已經是我們工作和生活的一部分。

但大部分的時候，我們都只是分開使用這些工具。

例如我們辦公室最常用的，就是將 Google 的試算表當作一般的表格在用。

比方說你需要讓同事填一些資料的話，你就自己做一個試算表表格，然後把連結丟給同事，讓他們自己去填寫。

或者說，每次資料整理完要寄信給其他人時，如果需要針對不同的內容寄信，你就只能個別客製化去寄。

每一件事情單獨看起來都不難，但只要每天重複做，累積起來就會花掉很多時間。

我們可以更有效地運用 Google 工具

其實 Google 還有一個工具叫做 Google Apps Script。

它可以把 Gmail、Google 試算表、Google 文件、Google 表單和 Google Drive 串在一起，幫我們處理很多重複性的工作。

例如有人填完表單之後，自動整理資料、建立文件，再寄出通知信。這些事情原本可能需要在不同工具之間來回切換，但透過 Google Apps Script，就有機會變成一套完整的自動化流程。

可是，一般人聽到 Google Apps Script，第一個反應通常就是：

「這是不是要會寫程式？」

就算現在可以請 AI 幫忙寫程式，接下來還是會遇到很多問題。

程式要放在哪裡？

要怎麼執行？

為什麼 Google 要求授權？

執行失敗之後，要去哪裡確認錯誤訊息？

這就是我製作 Learn-GAS 的原因

我過去曾經寫了一本學習 Google Apps Script 的電子書，讓新手搭配 ChatGPT 來製作 Apps Script 專案。

但是在這個資訊爆炸的時代，還要花時間去讀電子書實在是太累了。

能不能讓 AI 帶著我做呢？

所以我就決定做了這一個專案：Learn-GAS。

你只要把整個 Learn-GAS 專案連結，丟給你平常使用的 AI Agent，讓 AI Agent 讀取裡面的技能與規則，再由它帶領你一步一步完成就可以了。

目前你可以搭配 Claude Code、Codex 或 Google Antigravity 使用。

你不需要先讀懂專案裡面的每一個程式檔案，也不用先研究 Apps Script 的所有技術細節。

你只要先告訴 AI Agent：

「我想學習 Google Apps Script。」

或者直接告訴它：

「我想做一個可以自動整理家庭支出的試算表。」

「我想根據名單批次產生文件。」

「我想用 Google 表單收集資料，再自動寄出通知。」

接下來，AI Agent 會協助你整理需求、規劃流程、撰寫程式、進行測試，並在需要你操作的地方，告訴你接下來要做什麼，以及完成之後應該看到什麼結果。

有不同的目標，就走不同的流程

Learn-GAS 技能包裡面把不同工作分開處理。

想從頭學習時，有教學流程；想直接製作自己的自動化工具時，有專案開發流程；遇到錯誤時，也有專門的除錯流程。

我在整個步驟中，重新安排了人和 AI Agent 的分工。

程式、本機檔案、測試和技術處理，可以盡量交給 AI Agent。

帳號登入、Google 權限授權、以及驗收最後成果，則由使用者自己確認。

這樣子可以讓你不需要在介入程式語言的情況下，能夠充分地理解你做的 Apps Script 專案脈絡。

真正要學的，是怎麼指揮和驗收 AI Agent

我們現在的工作型態，有了 AI Agent 之後，有了非常大的改變。

從過去我們必須親自去動手寫程式、操作介面，到現在，我們更重要的事情是：我能不能清楚表達我的需求？以及我的需求能否交給 AI Agent？

當我們接到一份任務的時候，我們首先要思考的是，有哪些工作可以交給 AI Agent？有哪些工作必須由我自己做？

當 AI Agent 做完工作之後，程式能不能自行判斷、驗收，確認結果是否正確？

所以 Learn-GAS 技能包的目標，是讓我們學會與 AI Agent 一起工作，利用自己原本就在使用的 Google 工具，做出能替自己節省時間的自動化流程。

你不需要成為工程師，先從一件每天都在重複做，而且早就很想省下來的工作開始。

相關連結

• Learn-GAS GitHub 專案

• Google Apps Script 官方介紹

加入社畜進化論｜Raven AI

如果你也想和更多正在實際使用 AI Agent 的夥伴交流、分享成果，並一起解決工作與自動化上的問題，歡迎加入我的 Skool 社群「社畜進化論｜Raven AI」。

這本書採用的概念其實就是「二八法則」：一本書最精華的內容可能只占 20%，只要掌握這 20%，基本上就能理解整本書 80% 的內容。

當然，10 分鐘讀完一本書，對我來說還是有點誇張。不過，如果書籍的難度符合我的程度，我確實可以在 30 分鐘到一個小時之內讀完，大概掌握七八成的概念。

一本書不需要從頭讀到尾

一般來說，我會先看一本書的前言、結語、目錄和第一章，也會掃過每章的開頭與結尾。

如果書中有粗體字或圖表，我也會先看一遍。我不會逐字閱讀，大部分只要讀每章前面的幾個段落，通常就能判斷這一章在談什麼，以及是否值得繼續讀下去。

另外，根據我自己的閱讀經驗，第一章也不一定重要。

很多書的第一章只是在陳述概念，或交代作者如何開始這項研究。這些背景對讀者來說，未必真的有用。相較之下，最後一章的結語有時候反而更重要，因為作者通常會在這裡重新整理整本書的核心內容。

所以，實際閱讀時，我們不必拘泥於固定順序。除了前言、目錄與結語以外，也可以直接跳到自己有興趣，或真正需要的精華片段。

這些閱讀技巧，可以在實際閱讀的過程中慢慢摸索。

這種讀書方法並不適用於所有書籍

這種做法並不是這位作者發明的。早在《如何閱讀一本書》中，就已經談過略讀的概念。

略讀比較適合非文學類書籍，例如商管、科普、社會科學，以及探討職場與工作方法的實用型書籍。

至於文學作品，就不適合使用同樣的方法。

畢竟文學作品的價值，不只是理解作者最後想表達的概念，而是在閱讀過程中感受角色的悲歡喜樂。假如只看目錄、前言與結語，就失去了閱讀這些作品的意義。

所以，所謂只讀 20% 的方法，並不是套用在所有書籍上的標準答案，而是針對特定類型書籍所採取的閱讀方式。

一本書只要理解一個概念，就有價值

作者認為，一本書其實只需要讀三分之一。

讀完第一章之後，可以先看目錄，再挑選自己有興趣的章節閱讀，不需要強迫自己完全理解整本書。

即使讀不懂也沒關係，只要能從一本書裡理解一個概念，這本書就已經有價值了。

因為這個世界上的爛書真的太多了。

有時候是作者的問題，有時候是編輯的問題，很難一概而論。例如有些書會塞進十幾種觀點，內容變得非常混亂。

我認為，這個時代最好的一本書，應該只專注談一件事情，然後完整地把這件事情談完，把概念說清楚。這才是最重要的。

快速閱讀有一個重要前提：i＋1

想要快速讀懂一本書，有一個很重要的前提：這本書的難度必須符合「i＋1」。

i 代表自己目前的程度，＋1 則是比自己原有的程度稍微困難一點。

我們不能在完全沒有基礎的情況下，直接閱讀遠遠超過自己程度的內容，還要求自己在 10 分鐘之內掌握整本書。

例如，我不可能在完全不理解任何程式語言的情況下，直接去讀演算法，還要求自己在 10 分鐘之內理解整個概念。這實在太困難了。

所以，快速閱讀不是單純追求速度。書籍本身的難度，必須與讀者目前的能力相符。

讀得快沒有用，重點是能不能記住

讀書快並不代表學得好。真正重要的是，讀完之後能不能記住，以及能不能把書裡的內容轉化成自己的理解。而讓自己記住一本書最好的方法，就是輸出。

如果我們讀書的目的是學習，那麼閱讀就應該以輸出為目標。若只是把讀書當成娛樂，單純享受閱讀的樂趣即可，不必強迫自己產出。

作者認為，參加讀書會是一種很有效率的輸出方式，我也同樣認同。只不過，讀書會有一個很大的前提：必須找到一群志同道合，而且程度相近的人。

臺灣並不缺讀書會，但我自己參加過幾場，多半不是非常滿意。讀書會的核心應該是與人交流，可是我們很難遇到程度相當的人：要嘛是別人覺得你的程度太差，要嘛是你覺得別人的程度太差。

參與者也是形形色色，有些人很好，有些人則很奇怪。參加幾次之後，常常覺得還要處理許多有的沒的事情，實在很麻煩，最後索性就不想去了。

因此，我們應該盡可能降低輸出的難度。

如何降低輸出的難度？

我認為有兩個很簡單的做法。

第一個方法，是建立一個公開的閱讀帳號。

你可以在 Threads、Instagram 或 YouTube 上建立專門分享閱讀內容的帳號。每讀完一本書，就簡單介紹這本書，留下自己的閱讀紀錄。

如果分享之後還能得到其他人的回饋，那就更好了。這也是公開輸出的意義。

第二個方法，是撰寫私人的讀書筆記或日記。

如果覺得閱讀是一件很私人的事情，完全不希望別人看到自己的內容，也可以透過讀書筆記或日記，把讀完之後的想法記錄下來。

輸出不一定要公開。真正重要的是，讀完之後有沒有重新整理自己的理解。

AI 時代為什麼還要精讀？

前面提到的閱讀方式，主要是一種「略讀」，目的是讓我們用最快的速度掌握一本書的概念。

但是在 AI 時代，我們除了略讀，也應該重新注意「精讀」的重要性。

現在大部分可以文字化的知識，可能都已經被大公司拿去訓練 AI。我也相信，AI 已經掌握了人類知識中非常精華的一部分。

這時候，我們難免會產生一個疑問：AI 都這麼聰明了，我們還需要讀書嗎？

我認為，讀書的價值已經不只是取得書中記載的知識。

當我們仔細讀完一本書時，其實也在學習作者的思考脈絡。這種思考脈絡很難直接形容，它是一個潛移默化的過程。

讀得越深入，我們就越能理解作者如何思考一個問題。

尤其當一位作者不只寫過一本書，而是出版過好幾本書時，如果我們把他的作品都讀過，就有機會逐漸理解他的思考方式。我認為，這件事情在 AI 時代非常重要。

AI 如何降低閱讀與學習的障礙？

我認為，現在大家閱讀量減少，主要原因是娛樂選擇太多。

許多人從閱讀實體書，轉去閱讀社群媒體。像我自己就花了很多時間瀏覽 Instagram 和 Threads，浪費了不少時間。

因此，AI 在這個時代的應用，核心就是盡可能簡化閱讀與學習的障礙。

目前我主要使用三種方式。

Typeless 搭配 ChatGPT 桌面版

我一邊說話，Typeless 一邊幫我打字。完成之後，我把文字交給 ChatGPT，再讓 AI 根據我們之前建立好的 SOP，整理完整的對話內容。

最後，AI 會把這些內容整理成一份大綱，我就能直接根據大綱拍攝影片並進行輸出。

NotebookLM

當我手上已經有一整套完整資料時，例如一份討論資安的 PDF，就可以直接把整份文件放進 NotebookLM，再針對文件內容與它討論。

我也會請 NotebookLM 根據資安文件製作考題，再透過回答問題，幫助自己學習這份資料。

Notion 的會議錄音功能

雖然它原本是會議錄音功能，但我很常自己把它打開，對著它講述心得，或記錄自己剛完成某件事情之後的想法。

講完以後，它會把腦中混亂、零散的概念，整理成結構清楚的文字。之後需要重新翻閱或查找時，速度也會快很多。

把想法說出來的過程，本身就是一種輸出，同時也是在幫助自己學習。

目前我就是透過這幾種 AI 應用方式，盡可能降低輸出的難度，並提升自己的學習與工作效率。

因為我想把主要精力放在研究影片生成工作流。

所以接下來一陣子，電子報可能不會固定更新。等我把影片生成這套東西研究到一個比較清楚的階段，再來決定下一步要怎麼做。

未來也許會繼續寫電子報，或者直接把內容轉成 YouTube 影片或 IG Reels。

現在還不確定，總之到時候再說。

謝謝你之前的訂閱和閱讀。

等我研究出一點東西，再跟大家分享。

Raven

前言

平常你怎麼在處理眾多的資料？

如果你有一大堆會議紀錄、程式碼、專案報告等等，你要怎麼樣整理這些資料，才能夠更快的提取、彙整資訊？

我過去使用的方式，其實都只是單純地讓 Claude Code 或者是 Codex 去閱讀我電腦上的文件，由我指定文件內容後，再讓它產出我要的資訊。

當然這樣做其實已經很好用，可是如果文件越來越多的話，自己在整理上也是需要花很多的腦力。

這禮拜在網路上有許多人都提到了 OpenAI 共同創辦人 Andrej Karpathy 的 LLM Wiki 概念。

根據 Karpathy 的說法，採用 LLM Wiki 的話，應該就能解決上述的問題。

讓我們來看看怎麼做。

在你的電腦建立 LLM Wiki

Andrej Karpathy 最近公開一份筆記，提出一個跟主流完全相反的 AI 讀文件方法。

他說大多數人用的是檢索增強生成（RAG，Retrieval-Augmented Generation）：你把一堆檔案丟上去，每次提問，AI 才臨時去翻出相關片段、拼一個答案。

問題是，大型語言模型本身是沒有任何記憶的。

所以 AI 每次都從零開始去查找你的資料，知識永遠不會累積。無論它怎麼樣幫你整理知識脈絡，你換一個對話（Session）之後，全部都要重新開始。

Karpathy 的做法是反過來，不要每次查才翻原稿，而是讓 AI 先把素材全部讀完，整理成一個會長大的知識庫（Wiki）。

這個知識庫是一疊互相連結的 Markdown 檔案，夾在你跟原始素材中間。

平常你就是把專案相關的素材丟進去。

讓 AI 讀完資料、抓重點、整合進現有頁面，順手更新相關條目、標出跟舊資料衝突的地方。

你收集的知識只需要整理一次，之後就會一直保持最新的狀態，所以不必每次問問題時都還要再重新整理一遍。

如何設定 LLM Wiki？

在設定 LLM Wiki 之前，你需要兩大工具：

1. AI Agent：無論你是使用 Claude Code、Codex、OpenCode、Hermes Agent 或 OpenClaw 都可以

2. 可閱讀 Markdown 格式的軟體：Antigravity IDE、VS Code、Obsidian 都行。如果你不是工程師的話，建議你使用 Obsidian

接下來就是將 Karpathy 那份筆記資料丟給 AI Agent，讓他閱讀。

因此步驟只需要 3 個：

第一步，把筆記網址丟給 AI。

在你想放知識庫的那個資料夾裡，打開 Claude Code 或 Codex，把 Karpathy 的筆記網址（或整份內容）貼給它，叫它讀過一遍。

指令可以這樣下：「請先讀這份筆記 gist.github.com/karpathy/442a6bf555914893e9891c11519de94f ，讀完跟我說你理解到的重點。」

第二步，讓 AI 讀完，跟你對一次重點。

這份筆記是觀念說明、不是安裝腳本，所以先讓 AI 消化過，確認它抓到了「三層架構」跟「三個操作」，再往下執行。

記得一定要讓 AI 跟你對齊想法。當你確認它理解了 LLM Wiki 的概念之後，才開始讓它執行，因為你有可能需要根據你的專案狀況做部分的微調。

第三步，叫 AI 照著裝在這個資料夾。

確認它讀懂了，就請它動手：「照這份筆記的做法，在這個資料夾幫我建一套 LLM Wiki，用途是整理我的會議紀錄。」（把用途換成你自己的，例如產業研究、讀書筆記、客戶資料。）

AI 就會幫你把整個骨架建出來，你不用自己開任何資料夾或檔案。

骨架則分為三層：

第一層是原始素材（Raw Sources），例如你蒐集的文章、論文、逐字稿、圖片，AI 只准讀、不准改，當作唯一的真實來源。

第二層是知識庫（Wiki），AI 自己生成與維護的 Markdown 文件，裡面有摘要頁、實體頁、概念頁、比較頁，這層完全歸 AI 管，你只負責讀。

第三層是規則檔（Schema），用 Claude Code 就是 CLAUDE.md，用 Codex 就是 AGENTS.md，它告訴 AI 這個知識庫怎麼編排、有哪些慣例、收到新素材或被提問時該跑什麼流程。

第三層的規則檔可以讓你的 AI Agent 變成一個有紀律的知識庫管理員。

你如果要做客製化的修正，就是讓 AI 去把你的需求告訴你的 AI Agent，讓他幫你修改這一份規則檔。

如果你有一些固定的流程，就是跟 AI Agent 說明你的流程內容，請它幫你寫成「技能」。

注意上述的內容，全部都要在你的 LLM Wiki 目錄底下去跟你的 AI Agent 說明。

當你設定了 Karpathy 的 LLM Wiki 的時候，AI 還會順手幫你建兩個導航檔。

index.md 是內容目錄，每頁一行摘要、依類別排好，AI 回答前先讀取它，再決定深入哪幾頁資料，適合你的素材量還不是很多的情況。

log.md 是時間軸，只往後追加，記錄每次匯入、提問、體檢，開頭用固定格式（像 ## [2026-04-02] ingest | 文章標題），AI Agent 就能直接用 grep 指令去撈它最近做了什麼。

如何使用 LLM Wiki？

平常你就靠三個動作跟它互動。

第一個是匯入（Ingest），你把新素材丟進 raw 資料夾叫 AI 處理，它會讀完、跟你討論重點、寫一頁摘要、更新索引、改動相關的實體頁與概念頁、再往日誌補一筆，一份素材通常會牽動 10 到 15 個頁面。

第二個是提問（Query），AI 去知識庫找相關頁面、附引用回答你，你如果有發現某個討論內容不錯，還可以回存成新頁面，讓你每次探索也跟著累積，而不是消失在對話紀錄裡。

第三個是體檢（Lint），定期叫 AI 自我檢查，揪出彼此矛盾的內容、被新素材推翻的舊說法、沒人連到的孤兒頁、缺漏的交叉連結、可以補查的資料缺口。

Karpathy 自己的工作畫面是一邊開 AI 代理、一邊開 Obsidian 筆記軟體，AI 在對話裡改檔案，他在 Obsidian 這頭即時瀏覽，看關聯圖（Graph View）哪些頁是樞紐、哪些是孤兒。

一個實際例子：我用它寫一本修仙小說

講到這裡可能還是有點抽象，我用自己的私底下在做的專案當例子。

我最近在寫一本修仙小說《凡人滅仙傳》，我打算按照 LLM Wiki 的方式去整理資料。

原始素材那層，我開了一個 raw 資料夾，底下分神話典籍（山海經、搜神記的妖怪條目）、明代歷史（建文年間、靖難之役），之後我會把相關的資料丟進去。

知識庫那層，是一本「故事聖經」，裡面有人物頁、世界觀頁、妖怪圖鑑、主角能力表、伏筆追蹤，全部互相連結，由 AI 維護。

比如說我在書裡有隻妖怪叫山魈，牠的頁面就會記載出處（山海經、子不語）、外型（紅緯帽、獨腳）、能力（天生隱身）。

當我要寫山魈出場那章，AI 只要把這一頁夾進去，負責寫正文的 AI 就不會把設定寫錯。

平常我在使用的時候，例如我可能會跟 AI 討論要如何擴充我的「妖怪知識庫」，它就會幫我整理相關資料，並介紹我還可以去哪裡抓取哪些素材。

素材其實也可以交給 AI agent 去抓啦，但是有些資料的抓取方式，還是只能靠人工處理，因為現在很多網站都會擋爬蟲。

例如臺灣有一個「中國哲學書電子化計劃」網站，如果你想叫爬蟲去爬就有點困難，它的網站會擋。

我自己覺得 LLM Wiki 最好的概念是 log.md 日誌。

因為我們在建置這種知識庫的時候，其實挺需要記錄 AI 到底在過程中做了些什麼事情。一般來說，我們自己不太會去讀這份日誌，所以這些內容其實是交給 AI 看的。

畢竟 AI 是沒有記憶的，所以你要讓它知道之前做了些什麼，它就比較不容易出錯。

我建議每個人都要安裝 LLM Wiki。

無論你是要寫程式、寫書，或是在做自媒體、寫電子報，其實許多工作本質上都是在處理知識管理。設定 LLM Wiki 對你來說只有好處沒有壞處。

最後，我們還可以透過 Git 來管理這些內容，針對整個 LLM Wiki 知識庫進行版本控制，這樣就更完美了。

參考連結：

• Karpathy 原始筆記：LLM Wiki（gist）

• Claude Code 文件：Memory 與 CLAUDE.md

• Claude Code 文件：Subagents 與工具權限

如果你也想把這種用法真正練起來，看我在真實專案裡怎麼設定、怎麼調整，我會在社畜進化論｜Raven AI社群裡一步步帶。

要是你更傾向直接把自己的事業或工作流程套進去，需要有人幫你盤點從哪裡開始，那就預約一對一AI 一人公司啟動諮詢，我們一起畫出你的自動化藍圖

。

在 2024 年的時候，傳統使用 AI 的方式就是你問一句、AI 答一句。

到了 2025 年，大家開始提倡「提示詞工程」（Prompt Engineering），其範疇包括：

1. 指派角色讓 AI 扮演

2. 幫 AI 設計固定產出的流程與格式

3. 後期出現的專案規則與技能

到了 2026 年，又出現了一個更新的名詞，叫做「迴圈工程」（Loop Engineering）。

提到「迴圈工程」，我認為最著名的案例就是龍蝦（Openclaw）。

龍蝦有一個設計，叫心跳機制（Heartbeat）。

透過心跳機制，可以規定它大概每 30 分鐘，或者是每一小時自動啟動，去檢查是否有需要處理的事情。

比如說檢查目前的系統有沒有出錯；如果有，就進行修正。

所以這個機制跟傳統的提示詞工程（Prompt Engineering）有一個很大的不同。

過去可能是寫好一整套的提示詞，讓 AI 根據這些內容去做相對應的工作；而現在我們則是設法建立一個可以不斷迴圈的系統。

根據我們指派的工作，如果系統檢查到、或看到需要開始工作的時候，它就會自動進行相對應的處理。

迴圈工程需要的六個工具

負責 Google Chrome 的工程師 Addy Osmani ，認為迴圈工程大致上需要底下的這些工具：

自動化排程（Automations）：

讓任務不是你手動開啟，而是時間到了自己跑。

有許多 AI Agent 都已經有這個機制，比方說在龍蝦裡面可以設定排程，Claude Code 本身有一個 /loop 的機制，Codex 的桌面版也有一個自動化的按鈕可以設定。

工作樹（Worktrees）：

Git 的一個功能，讓好幾個 AI 代理（agent）各自在獨立的程式碼副本上工作，不會同時改到同一個檔案打架。

技能（Skills）：

基本上就是 SOP，把專案的規則、常見判斷、操作慣例寫成文件，讓代理每次都照同一套標準做事。

外掛與連接器（Plugins and Connectors）：

讓代理能接到外部工具，例如 GitHub、資料庫、任務管理板。

子代理（Subagents）：

把工作拆給不同角色的代理，一個負責寫程式，另一個負責檢查。

你也可以針對不同的角色分配不同的語言模型。

例如有人會說 Claude 的模型比較適合寫程式，Codex 或是 ChatGPT 的模型則比較適合除錯。當然，這就是依照個人的使用經驗去做不同的分配。

像我個人最近私底下有一個 Side Project 在寫修仙小說，我就指派 DeepSeek 來擔任主筆，因為如果你叫 Claude Code 去寫的話，它的中文程度真的是很爛。

外部狀態與記憶（External State / Memory）：

把進度寫到對話以外的地方，例如一個純文字筆記檔（Markdown）或一塊任務板，這樣迴圈跑很多輪也不會忘記自己做到哪一步。

我的 Hermes Agent 就有這樣的機制。他在被指派任務的時候，會先將要做的事情寫下來，寫成 To-Do List，然後再依照完成的進度去劃掉清單上的項目。

範例一：每天自動修程式的迴圈

假設一家軟體公司，每天晚上電腦會自動把大家寫的程式跑一輪測試，看有沒有哪裡壞掉。這套會自動跑測試的系統叫 CI（持續整合，Continuous Integration）。

然後昨天半夜，它測出有個地方壞了。

傳統做法是，你早上進公司打開 Claude Code，一句一句問它。先問「昨天為什麼壞了」，它回答後，你再說「好，修復這個 bug」。

修完，你再說「再跑一次測試」，終於成功了，你再說「幫我整理成一份修改說明送出去」。

上述每一步都要你開口，AI 等於是你的工讀生嘛，你說一動，他才做一動。

迴圈的做法是，你先把這整套流程寫成會自己執行的小程式，設定每天早上自動啟動。它一啟動就照著固定步驟跑一圈：

1. 自己去讀昨天測試壞掉的紀錄

2. 判斷哪些是它有把握修的

3. 開一個獨立的工作空間，不會動到同事正在改的程式

4. 派一個代理去修，再派另一個代理檢查修得對不對

5. 重跑一次測試

6. 測試過了，就自動把修改整理好、送出去等人核准

7. 沒過，就把原因寫進一份紀錄檔

8. 若測試多次都是失敗的，就通知人類，讓人類介入

範例二：用 Codex 的 /goal 設一個會自己驗收的迴圈

如果你不是工程師，但想要趕快來體驗一下什麼是迴圈工程的話，其實你可以使用 OpenAI Codex 。

Codex 有一個 /goal 指令，很類似「迴圈工程」。你不是每一步都下提示詞（prompt），而是先設定一個有驗收標準的終點。

官方文件的說法是，目標（Goal）是 Codex 的持久任務，會包含三件事：

1. 什麼算完成

2. 怎麼檢查成功

3. 過程中哪些限制不能破壞

例如說，你可以下這樣的指令：

/goal 修好登入流程裡時好時壞的測試，直到所有登入測試都通過，而且程式碼檢查沒有錯誤

設好之後，Codex 會自己檢查程式、修改、跑測試、再修正，直到達到條件，或是遇到它判斷需要你出手的地方才會停下來。

範例三：每天早上自動生出電子報草稿的迴圈

迴圈不是只能拿來寫程式，內容整理也可以。

我現在寫電子報的流程其實是屬於「單線性」的。我設定了許多的技能，流程如下：

1. 構思與資料蒐集： 每次要寫電子報時，我會先思考這週的主題，並找好相關資料。

2. AI 協作撰寫： 資料找完後，我會丟給 AI。它會按照我預先設定的技能，幫我整理檔案並寫成文章。為了保持「人的味道」，我只會讓 AI 負責技術面的內容，其餘部分則由我親自撰寫，且技術內容我也會再順過一次。

3. 圖文發布： 文章完成後，我會啟動另一個技能產生圖片。確認圖片與文字都沒問題後，系統就會自動發布到 Substack。

這些步驟都已經跑順並設定成技能，但目前仍是單線式的操作。所以最近我在想，是不是可以讓我的 Hermes Agent 更進一步？

我希望它每週自動檢查我在 Threads 上的發文，看看哪幾張我製作的圖卡相對受歡迎，接著直接擷取受歡迎的主題，自動擴展成一份電子報。

理想的流程是：Hermes Agent 每天定時通知我電子報草稿已經寫好了。我去確認一下，如果覺得可以，或是修改完細節後，只要說一聲：「好，就這樣，直接執行吧。」這整個流程就能幫我省下更多時間。

你想跟一群人一起把迴圈搭起來嗎

AI 的世界每天都有新名詞，例如本週提到的迴圈工程，一個人追很容易漏掉。

我現在逐步透過人工以及 AI 自動化的方式，把每天發生的 AI 新知，整理進「社畜進化論｜Raven AI」這個社群。

如果你不想一個人慢慢摸，想有一群人一起把這套東西搭起來，進來看看會比較快。

👉 社畜進化論｜Raven AI

補充說明：這篇文章是在禮拜四晚上寫的。結果隔天，Fable / Mythos 5 就受到美國官方下令禁止非美國地區使用。原因當然是跟國家安全有關係。這也意味著，各國都應該要加強開發屬於自己的 AI，避免受制於其他國家。

—
如果你有在使用 Claude Code 或是 Claude 桌面版的話，在上個禮拜你應該有看到更新。更新完之後，你就會發現有一個新的模型叫做 Fable 5。

它是最新的旗艦模型。

在 6 月 22 日以前，只要你有訂閱，不管是哪一個層級的 Pro、Max 或者企業版，你就可以使用 Fable。

在這之後，Anthropic 就會把它從訂閱方案中移除，繼續使用需要消耗 usage credits，意思就是要多收錢啦。不是說你有訂閱就可以爽用，你有訂閱也不會給你用，要用的話要另外儲值。

費率是 API 價格：輸入 $10/百萬 token、輸出 $50/百萬 token，是 Opus 4.8 的兩倍。貴到嚇死人。

當然，這麼貴的價格代表它有強大的能力。

Fable 5 其實就是之前吵得沸沸揚揚的的 Mythos，據說能力非常強大，能夠自己抓到資安漏洞的大型語言模型。

由於 Mythos 的能力實在是太強了，所以 Anthropic 特別為了 Fable 5 多加了一層護欄。提供給一般使用者。另外還有一個 Mythos 5 ，安全限制較少，提供企業使用。

我自己單純是覺得，也許是因為 ChatGPT 5.5 太強了，而 Claude Opus 4.8 表現起來，又差強人意，所以迫於壓力的 Anthropic 不得不推出一個新的旗艦模型。

Claude Fable 5 雖然很強，但是也不會贏過 Opus 太多

Anthropic 在 2026 年 6 月 9 日發布 Claude Fable 5。

根據 Anthropic 的說法是，Fable 5 主打長時間的 AI 代理工作、程式開發、知識工作與視覺理解。

從一些官方文件以及一些英文媒體的資料來看，Fable 5 可以說就是一個 Mythos 的閹割版，針對資安、生物與生命科學等高風險能力，額外加了安全分類器。

當 Fable 判定某個請求碰到這些高風險區，會自動把問題改交給 Opus 4.8 回答。

目前 Fable 在 Benchmark 的表現上，官方資料顯示都贏過 ChatGPT 5.5 。以程式任務的 SWE-Bench Pro 為例，Fable 5 ／Mythos 5 拿到 80.3%，高於 Opus 4.8 的 69.2%、GPT-5.5 的 58.6% 與 Gemini 3.1 Pro 的 54.2%。

可是，因為 Fable 5 有安全分類器，所以上述的 Benchmark 成績，其實應該是 Mythos 5 的成績。Fable 5 我覺得就只能把它視為是 Opus +。在資安與生物等受 guardrails 影響較大的指標上，正式對外的 Fable 5 可能更接近 Opus 4.8 的實際表現。

總之呢，Benchmark 成績，看看就好。

因為這一兩年來，反正 ChatGPT 推出新模型之後就說它的模型最強，那這個 Claude 推出來之後呢，也說它的模型最強。

目前最強閉源模型都是 Claude 跟 ChatGPT 在互相競爭，Gemini 目前已經落後了，Grok 則是不知道在幹嘛，希望他們能加把勁。

Fable 5 的額度消耗量實在太大了，建議設定 Subagent

最近這幾天我都有用 Fable 5。

Fable 5 的確是比較強，可是大約每十次使用，可能就會有一次觸發它的安全分類器。

我的工作其實也不太會故意去挑戰一些違反資安的工作，平常主要是讓 AI 去讀系統裡的 log，然後幫我分析目前的問題。

但是光是這樣子使用的時候，它有時候會撞到護欄，然後直接把問題丟給 Opus 4.8 讓它去回答。

雖然我看了一些網路資料，據說如果撞到護欄，在它還沒有把文字產出的時候，所消耗的 token 不會計算到我們的額度裡面，但還是很浪費時間。

還有在體感上，使用 Fable 5額度消耗得特別快。

我平常都是用 Opus 4.8，每天就是讓它讀一下 log 的資料，不然就是寫 GAS 腳本做自動化，很少撞到上限。

改用 Fable 5 之後大概用個幾次，我的額度就滿了。我還是 100 美金的 Max 使用者咧。

就是因為這樣，所以我後來就決定要設定使用子代理（Subagent）來節省一下我的使用量。

設定方式也很簡單，你就是跟 AI 說，你希望在你的本地端能夠依照任務去設定子代理，依照不同的任務呼叫不同的模型。它就會幫你設定了。

目前我設定了三層模型：

第一層：Sonnet 是預設值，所有沒有觸發升級條件的任務都在這裡處理。

第二層：Opus ，當 Sonnet 判斷任務步驟超過五步、需要同時整合多個來源的資訊、或者任務性質屬於架構設計、深度研究，它就會呼叫 Opus Sub-agent。Opus 的強項是長程自主推理，能夠自己規劃完整的解題路徑，再一步一步執行完畢。

第三層：Fable 是我幾乎不主動觸發的選項，因為也只有最近才能用，6月23日開始都是要儲值才能用。如果要等到 Anthropic 開放一般訂閱戶也能使用 Fable，不知道要等到猴年馬月。

但是如果未來它有開放的話，可以預測消耗的額度應該也很可觀，除非 Opus 跑起來不夠理想，AI 此時就可以給我建議，讓我自己決定要不要使用 Fable。

原則上就是讓 AI 自己根據任務的難度，決定「這件事該派誰去做」，而不是每次都動用最貴的資源。

CTA

如果你跟我一樣，每次有新模型出來都想自己搞清楚它能不能放進工作流，不想只跟著英文媒體的情緒走，那我們社群會很適合你。我固定會在社畜進化論裡跟大家拆各種最新 AI 技術以及如何套用在工作流。想跟著第一線討論一起練判斷力的話，我們這裡見：

👉 社畜進化論｜Raven AI

最近在製作一個 AI 工作流的時候，發現我的信件自動寄給客戶時，都會被標記為垃圾信件。

稍微研究了一下，很快就解決了，不過中途還是會有一些眉角要處理，所以特別記錄起來，如果你也有相同困擾的話，底下是可能的解決方法。

先描述我的情境：

我有一個服務是 AI 工作流的陪跑，就是一對一教學，教人家怎麼做 AI 工作流。

只要購買陪跑服務，我也會同時贈送微課程，其實就是電子書啦，但是有搭配影片這樣。

所以當客戶購買了課程之後，系統就會提供一個 Google 表單。他們在填寫的時候，會有三個選項可以選：

• 適合社畜的 AI 知識管理：各種常見 AI 工具應用

• 適合新手的 Vibe Coding (ChatGPT + Google Apps Script)

• 適合小白的 AI 自動化(n8n)

我寫了一個 Google Apps Script 去處理 Google 表單的流程。依照客戶選擇的微課程內容，Google Apps Script 會寄送相對應的 Notion 連結給對方。

寄送是以 iamraven@raven.tw 來寄送，這個 Email 是在 Google Workspace 底下，因為我有購買 Google Workspace。

測試的結果是，信件雖然有成功寄出，但直接被扔進了垃圾郵件中。

信為什麼進垃圾郵件：SPF、DKIM、DMARC 與怎麼診斷

信寄到 Gmail 被丟進垃圾郵件，很常見的原因是寄件網域的郵件驗證沒設定齊全。

收件方會檢查三組放在 DNS 上的設定。

• SPF（Sender Policy Framework）：宣告哪些伺服器可以用你的網域寄信。

• DKIM（DomainKeys Identified Mail）：寄信時用一把私鑰幫信件加上數位簽章，收件方再用你放在 DNS 上的公鑰去驗證，確認這封信真的由你的網域授權寄出，而且中途沒被竄改。

• DMARC（Domain-based Message Authentication, Reporting and Conformance）：規定當 SPF 或 DKIM 驗證沒過時收件方要怎麼處理，以及把驗證報告寄到哪個信箱。

要知道自己缺哪一個，用 dig 指令查 DNS 就好，dig 是一個查 DNS 的指令，要在終端機裡用。

如果你是 Mac，打開內建的「終端機」程式（在 應用程式 → 工具程式 裡面，或用 Spotlight 打 Terminal 找出來），把下面的指令貼進去按 Enter 就有結果。

三筆分別查：

dig +short TXT raven.tw                     # SPF，找開頭 v=spf1
dig +short TXT google._domainkey.raven.tw   # DKIM（Google 預設 selector 是 google）
dig +short TXT _dmarc.raven.tw              # DMARC

我自己查 raven.tw 的結果是：

SPF 有（v=spf1 include:_spf.google.com ~all），DKIM 跟 DMARC 兩筆都是空的。

所以，我少了 DKIM 數位簽章，是這次自動化發信丟進垃圾郵件的主因，要補上 DKIM 跟 DMARC 這兩筆。

上述這些資料都是要放在 DNS 紀錄裡面。

我的網域在哪買、DNS 又接到哪

要補 DNS 記錄，得先知道你的網域 DNS 是在哪裡管理。

raven.tw 這個網域我是在 Gandi.net 買的。但我沒有用 Gandi 內建的 DNS，而是把網域的 nameserver 指到 Cloudflare，DNS 記錄統一在 Cloudflare 管理。

所以等一下加 DKIM 跟 DMARC，都是去 Cloudflare 加，不是去 Gandi。

怎麼確認你的網域 DNS 接在哪一家：

dig +short NS raven.tw

我的回傳是：

jim.ns.cloudflare.com.
anahi.ns.cloudflare.com.

看到 cloudflare.com 就代表 DNS 託管在 Cloudflare。

如果你看到的是 Gandi 或別家的 nameserver，那就要去那一家的後台加記錄，步驟的概念一樣，只是介面不同。

在 Google Workspace 產生 DKIM 金鑰

DKIM 的金鑰要從 Google Workspace 管理控制台產生。

用管理員帳號登入，打開這頁：https://admin.google.com/ac/apps/gmail/authenticateemail （路徑是 應用程式 → Google Workspace → Gmail → 驗證電子郵件）。

上方先選網域 raven.tw，再點「產生新記錄」。金鑰長度選 2048 bit，前置字串（selector）保持預設的 google。

它會給你一筆 DNS 記錄，長這樣：

主機名：google._domainkey
值　　：v=DKIM1; k=rsa; p=（後面接一長串公鑰）

這時候先停手，不要按「開始驗證」。等 DNS 那筆記錄加好、生效之後再回來按，順序顛倒會驗證失敗。

到 Cloudflare 補上 DKIM 與 DMARC 兩筆記錄

登入 Cloudflare，點進 raven.tw，左側選 DNS → 記錄（Records），按「新增記錄」加兩筆資料。

第一筆，DKIM：

• Type：TXT

• Name：google._domainkey（只填這樣，Cloudflare 會自動補成 google._domainkey.raven.tw）

• Content：把 Google 給你的那串 v=DKIM1; k=rsa; p=... 整段貼進去

DKIM 這串很長，超過單筆 TXT 的 255 字元上限，DNS 會自動切成好幾段存。Cloudflare 接受長字串、會自己處理，直接貼完整內容就好。

第二筆，DMARC：

• Type：TXT

• Name：_dmarc

• Content：v=DMARC1; p=none; rua=mailto:iamraven@raven.tw

DMARC 的 p=none 是監控模式，只收報告、不對驗證失敗的信做任何處置，是最安全的設定，不會誤殺你現在正常寄出的信。

rua 後面那個信箱是接收彙整報告的地方，填你自己的信箱，不要填寫我的信箱啊。

兩筆都存好之後，還記得剛剛跟你說不要按「開始驗證」嗎？所以現在請你回到剛剛 Google 那一頁，按「開始驗證」。

用 dig 確認 DKIM 生效

DNS 改完不會立刻生效，先用 dig 確認。

現在要查兩個地方：一個是直接問 Cloudflare 的權威伺服器（記錄到底加上去了沒），一個是問公共 DNS（有沒有傳播出去）。

# DKIM
dig +short TXT google._domainkey.raven.tw @jim.ns.cloudflare.com   # 權威
dig +short TXT google._domainkey.raven.tw @8.8.8.8                 # 傳播
# DMARC
dig +short TXT _dmarc.raven.tw @8.8.8.8

如果兩邊都有回傳值，就代表記錄上線了、也傳播出去了，Cloudflare 通常幾分鐘內就好。

查 DKIM 的時候，你會看到那串值被切成兩段、各自包在引號裡，這是 DNS 對超過 255 字元的正常分段，收件方驗證時會自動接回去，不用管它。

最後就要驗證真正寄出的信有沒有帶上 DKIM 簽章：

寄一封測試信到 Gmail，打開信、點右上「顯示原始郵件」，看到 DKIM: 'PASS' with domain raven.tw 就代表成功了。

Google 按了「開始驗證」之後，通常幾十分鐘到幾小時內會開始幫你的信簽章，DNS 既然已經生效，多半不會拖太久。

CTA

如果要把自動化寄信的腳本設定到不再被丟到垃圾郵件夾，雖然看似很簡單，但是其中還是有很多的關卡。如果沒有人帶你做，你可能光是搞清楚「程式該放哪個帳號、DKIM 要去 Gandi 還是 Cloudflare 設定」，就可能耗掉你一整個週末。

如果你正在把自己的工作流自動化，卻一直卡在這種接不起來的環節，可以直接找我聊。我的「AI 一人公司啟動諮詢」會幫你把目前最卡的地方，一條一條搞清楚，讓你少撞幾次牆、早一點把系統跑起來。

👉 AI 一人公司啟動諮詢

昨天跟辦公室的同事聊 AI 相關的內容，我才發現大家都遠遠低估 AI 的價值。

因為現在還是有很多人，把 AI 當作一個網頁版的聊天機器人，單純讓它產出文字訊息。

這當然是一個很好的方法，我也很常這麼做，可是只有使用這個功能，沒有辦法真正體現 AI 的價值。

在 2026 年，更好的 AI 使用方式，可以下載桌面版的應用程式，我們通常會稱它為 AI 代理（AI Agent）。

目前「御三家」的 AI：Claude、ChatGPT、Gemini，它們都有桌面版的應用程式，名稱分別就是：

1. Claude

2. Codex

3. Antigravity

只要能夠在電腦上安裝桌面版應用程式，就能夠使用 AI Agent，效率會比你單純使用網頁版要高得多。

除了是因為 AI Agent 能夠操作電腦以外，比起網頁版的 AI，它還多了「技能」的功能。

AI Agent 的「技能」是什麼

你提供給 AI Agent 讀取的提示詞，主要分為底下這幾類：

• 系統提示詞：有部分是廠商寫好的，你也能增加自己的客製化內容，每次對話固定載入

• Memory（自動記憶）：AI 自己寫的筆記，也會預設載入

• 專案規則：例如目錄底下的 CLAUDE.md / AGENTS.md / GEMINI.md，對話初期會載入

• 使用者每次發問：如果使用網頁版 AI 就只能使用此功能

• 技能：按需載入，未觸發前只佔用一行描述的空間

AI Agent 的「技能（Skill）」是一份預先寫好的 markdown 檔案，副檔名為 SKILL.md，存放在 AI 工具約定好的資料夾。

AI 工具啟動時會掃描這些資料夾，把每份技能的「名字」與「描述」載入到對話脈絡（Context）中。當使用者請求與某份技能的描述匹配時，AI 才會把完整的 SKILL.md 內容載入並執行。

所以你不需要每次對話時，都反覆向 AI 說明你的情境。

尤其是我們在執行複雜工作時，由於 AI 不清楚你的工作環境，犯錯的機率非常高。

當我們與 AI 共同協作時，如果能讓它學習我們的工作環境，知道使用者的需求，在什麼情況下該做相對應的事情，那麼在對話結束後，我們可以將這整件事情寫成「技能」存檔起來。

這樣一來，下一次你切換到新的對話（Session）時，雖然面對的是全新的 AI，但它能夠參考過去寫下的技能，因此就不容易再犯錯。

典型的技能目錄結構：

my-skill/
├── SKILL.md          # 主要說明（必需）
├── scripts/          # 可執行腳本（選用）
├── references/       # 詳細參考資料（選用）
└── assets/           # 模板、範例（選用）

SKILL.md 開頭以 YAML frontmatter 標示名稱、描述等中繼資料（Metadata），後續為 markdown 格式的執行指示，AI 載入後依該指示執行任務。

以下為一個簡單的 SKILL.md 範例：

---
name: summarize-article
description: 把一篇英文文章摘要成繁體中文 5 個重點。當使用者貼上英文文章內容說「幫我摘要」時觸發。
---

當使用者提供英文文章時：

1. 通讀全文，抓出 5 個核心論點
2. 每點翻成繁體中文，控制在兩句以內
3. 結尾用一句話總結文章的核心觀點

--- 之間是 frontmatter，告訴 AI 工具「這份技能叫什麼名字、什麼時候該載入」；--- 之後是 markdown 內文，AI 載入後會把這段當成執行指示照著做。

如何讓 Claude、OpenAI、Google 共享技能

使用 AI Agent，如果僅僅只是用最基本的 20 元美金方案，是遠遠不夠的。

通常會訂閱較高的額度，例如我就訂閱了 Claude Max 5X，它是一般 20 元美金的 5 倍額度，當然也需要 100 元美金。

但我同時也有訂閱 ChatGPT 以及 Google AI Pro，各自 $20 美金。

假設我要使用這三家 AI Agent，徹底榨乾他們的額度。我該怎麼樣讓他們共用技能呢？畢竟我可不想個別去設定技能，最好是他們可以共享。

在此之前，我們就要先理解這三家的核心規格：

AI 御三家技能核心規格

Anthropic Claude、OpenAI Codex、Google Antigravity 三家對技能的核心規格是一致的。

• 檔名統一為 SKILL.md

• frontmatter 最少需要 name 與 description 兩個欄位

• 觸發機制都是 AI 比對 description 與使用者請求；或使用者手動以 /skill-name 呼叫

差別只在資料夾路徑：

• Claude Code

  • 全域路徑：~/.claude/skills/

  • 工作區路徑：.claude/skills/

• OpenAI Codex（CLI 標準）

  • 全域路徑：~/.agents/skills/

  • 工作區路徑：.agents/skills/

• OpenAI Codex（macOS 桌面 App）

  • 全域路徑：~/.codex/skills/

  • 工作區路徑：.agents/skills/

• Google Antigravity

  • 全域路徑：~/.gemini/antigravity/skills/

  • 工作區路徑：.agent/skills/

需要注意的細節：

1. Codex 的工作區資料夾是 .agents（複數），Antigravity 是 .agent（單數），差一個字母就讀不到

2. Antigravity 的全域路徑掛在 .gemini 底下，因為 Antigravity 是 Gemini 系列產品的 IDE

3. Codex 的全域路徑視安裝方式而異：CLI 安裝走 ~/.agents/skills/，macOS 桌面 App 走 ~/.codex/skills/

Claude 的 frontmatter 支援額外欄位（allowed-tools、disable-model-invocation、context: fork 等），Codex 與 Antigravity 不支援這些欄位。YAML 解析時遇到未知欄位會直接忽略，因此寫成 Claude 規格的 SKILL.md 在 Codex 與 Antigravity 也能載入，只是擴充欄位不會生效。

由於 Claude 的資源欄位比較多，所以底下就先以 Claude 為主要的核心，然後讓 Codex 以及 Antigravity 去讀取 Claude 的技能。

用 symlink 讓三家共用同一份技能

在每家 AI 工具預設的技能資料夾位置，建立指向同一個共用目錄的符號連結（Symbolic Link，俗稱 symlink）。三家工具各自從自己的預設路徑讀檔案，但實際讀到的是同一份檔案。修改一次，三家同步。

本文以「單一專案內讓三家共用」為例：在專案根目錄建一個 skills/ 共用資料夾，然後把 .claude/skills/（Claude Code）、.agents/skills/（Codex）、.agent/skills/（Antigravity）三個入口全部 symlink 到 skills/。

實作 symlink 不需要自己記各平台的指令語法。把下方這段提示詞複製貼給任何一家 AI 代理（Claude Code、Codex 或 Antigravity 皆可），AI 會依作業系統（macOS、Linux、Windows）自動產出對應指令並執行。

給 AI 代理的提示詞

我想讓 Claude Code、OpenAI Codex、Google Antigravity 三家 AI 代理在這個專案內共用同一份技能庫。我的作業系統是 [macOS／Windows，擇一]。

請幫我做這些事：

1. 在專案根目錄建一個 skills/ 資料夾當共用倉
2. 如果以下三個資料夾本來已存在實體技能，先把裡面的內容搬到 skills/，再砍掉原本的資料夾：
   - .claude/skills/（Claude Code）
   - .agents/skills/（OpenAI Codex，注意有 s，複數）
   - .agent/skills/（Google Antigravity，注意沒有 s，單數）
3. 建立三個 symlink，讓這三個資料夾都指向 skills/
4. 列出這三個資料夾，確認都是 symlink 且都指向同一個 skills/ 位置

讀者只要把 [macOS／Windows，擇一] 改成自己的作業系統，整段貼給 AI 代理就會直接執行。Windows 使用者若 AI 提示需要建立 symlink 的權限，需先開啟「開發者模式（Developer Mode）」或以系統管理員身分執行終端機，AI 會在指令執行前說明。

注意事項

1. 雲端同步資料夾不適用

iCloud Drive、Google Drive、OneDrive 會把 symlink 當成實體檔案上傳，回到另一台機器會失效。建議放在純本機路徑（例如 macOS 的 ~/skills/、Windows 的 C:\Users\<使用者>\skills\）。若要多機同步技能庫，改用 Git repo 較穩定。

2. Frontmatter 走最大公因數

要三家共用的 SKILL.md，只使用 name 與 description 兩個欄位。Claude 專屬的擴充欄位（allowed-tools、disable-model-invocation 等）保留給只在 Claude 環境使用的技能。

3. Codex 桌面 App 的自動拷貝行為

實測 macOS 上的 Codex 桌面 App 偵測到專案內 .claude/skills/ 時，會自動把整份內容複製到 .agents/skills/，並把字串「Claude Code」自動替換為「Codex」。替換結果可能出現「Codex、Codex」這類字串重複的錯誤。

設定 symlink 後若 Codex 仍出現此行為，會把 symlink 覆蓋成實體拷貝，需要進一步觀察。

建議的驗證方式：建立 symlink 後修改 .claude/skills/ 中某個技能的內容，再開 Codex 對話看它讀到的是否為新版本。

順便讓三家 AI 讀同一份規則檔

「技能本體共用」之外，「告訴 AI 怎麼用這個專案」的規則檔（rules file）也能順便共用。各家規則檔名：

• Claude Code 讀 CLAUDE.md

• OpenAI Codex 跟 Google Antigravity（1.20.5 以後的版本）都讀 AGENTS.md

把 AGENTS.md symlink 到 CLAUDE.md，三家就共用同一份規則：

cd <專案根目錄>
ln -s CLAUDE.md AGENTS.md

三家 AI 進入專案時讀到的就是同一份規則。把「技能本體在 skills/、修改時直接寫 skills/<name>/SKILL.md」這條規則寫進 CLAUDE.md，三家進來都會看到，不必各家各寫一份。

實測同樣會踩到 Codex 桌面 App 的自動拷貝行為，它會把 CLAUDE.md 拷貝成 AGENTS.md 快照並做字串替換，可能覆蓋 symlink。設定後用 readlink AGENTS.md 確認還是 symlink。

結語

這篇講到的設定看起來不複雜，但實際做一輪會發現中間有不少眉角：Codex 桌面 App 的自動拷貝行為、frontmatter 相容性、Google Drive 同步資料夾、Windows 開發者模式怎麼開等等問題。

每一個分開都不難，串起來自己摸總會花掉一些時間。

如果你不想自己重複試錯，目前我有一個 4 週技術陪跑計畫，可以一起把整套 AI 工作流跑通。

👉 AI 一人公司 4 週技術陪跑計畫

你是怎麼管理你自己的帳號密碼，以及 API 金鑰、Access Token 的？

當你要製作 AI 自動化工作流的時候，需要登入某個系統，使用密碼或 API 金鑰的時候，你又是怎麼將這些機敏資訊提供給 AI？

如果你沒有第一個問題的答案，然後你每一次在製作自動化工作流的時候，都是把你的密碼以及 API 金鑰，直接提供給 AI 讓他幫你設定。

那麼也許你該考慮使用更安全的帳密管理方式。

很久以前我曾經做過一個工作流，就是自動化發文到 Threads。

由於 Threads 的 Access Token （你可以視為密碼），需要每 60 天更新一次。

為了方便，我就直接寫了一個 Google Apps Script，然後把更新完畢的 Access Token 放在 Google 試算表，再讓 N8N 去抓 Google 試算表內的資料。

當然個人使用的話，這種方式還算勉強可以接受啦。

可是我最近開始在我的辦公室環境製作工作流，由於工作流會牽涉到公司的環境，所以我不可能再採取類似的不安全管理方式。

因此我決定訂閱 1Password，使用了幾天之後，感覺非常滿意。

1Password 的設計邏輯

使用 1Password，是將我們的帳號密碼以及 API 金鑰都放在本地端，雲端只會儲存加密過後的資料。

每個帳號背後綁了兩把鑰匙：

• 主密碼：我自己要記住

• Secret Key：1Password 隨機產生的長字串，存在你裝置上，同時也會產一份「Emergency Kit」PDF

這兩把鑰匙都不會上傳到 1Password 的伺服器。

所以就算 1Password 公司遭到駭客攻擊，駭客拿到的也只是一段亂碼，他不會知道要如何使用。解密的過程都是在我的本地端完成的。

還有，使用 1Password，我的密碼資料庫還可以在任意多台電腦同步，但每台電腦都需要主密碼加 Secret Key 才能解開。

所以我現在的 1Password 主要放在幾個裝置：

1. 我的 iPhone

2. 公司用的 Windows 電腦

3. 家裡的一臺 Mac mini

4. 一個 Windows 筆電

假設我在家裡要操作遠端連線，連到公司的主機，我就不需要特別記得密碼，因為我可以在家直接使用 1Password 去登入即可。

如果我想要搭配 AI 代理，例如 Claude Code 或 Codex，使用 1Password 也是好選擇，我們就不需要擔心會有第三方去看到我的帳號與密碼。

我的 AI 代理只會看到路徑，像 op://Personal/notion-api/credential 這種地址。

而且每次要取用密碼的時候，都會先經過桌面版的驗證，例如 Touch ID，或者是任何我想使用的驗證方式。

1Password CLI 的兩個關鍵指令

我電腦上裝的是 1Password 桌面版加上一個叫 op 的命令列工具（也就是 1Password CLI）。桌面版負責管密碼、用指紋解鎖；op 負責讓 Claude Code 在終端機裡呼叫 1Password 裡的內容。

使用之前，記得在設定->開發人員，勾選與 1passwird CLI 整合。

Claude Code 在整套流程用到兩個指令，

指令一：op read，拿一筆密碼

假設我在 1Password 的 Personal 保險箱裡，有一個叫 notion-api 的條目，裡面 credential 那一欄存著 Notion 的 API token。我想讓 Claude Code 在終端機裡拿到它，輸入：

op read "op://Personal/notion-api/credential"

按下 enter，1Password 桌面版會跳出來叫我用 Touch ID 解鎖。

中間那串 op://Personal/notion-api/credential 是 1Password 的 secret reference：

op://<保險箱名>/<條目名>/<欄位名>

這串文字是密碼的「地址」。我可以把它放進任何設定檔、寫進 README，都不會洩漏任何敏感資訊。

指令二：op inject，把整份設定檔的地址換成內容

上述的 op read 一次只拿一筆資料。如果我有一個 .env 檔需要好幾把 key，比較順手的做法是讓 Claude Code 先寫一份模板，把所有要填的欄位寫成 secret reference：

# .env.tpl
NOTION_TOKEN="op://Personal/notion-api/credential"
OPENAI_API_KEY="op://Personal/openai/credential"
ELEVENLABS_API_KEY="op://Personal/elevenlabs/credential"

然後叫 Claude Code 執行：

op inject -i .env.tpl -o .env

op 會把每一行的 op://... 替換成 1Password 裡的真實值，輸出一份完整的 .env。再把 .env 放進 .gitignore，只 commit .env.tpl，整個專案的 secret 管理就乾淨了。

沒有資安就別談 AI 工作流

我之前在做這些 AI 工作流的時候，常常為了貪圖便利，就直接讓 AI 使用我的明文密碼以及 API 金鑰。

不過實在看了太多的資安相關新聞，所以我開始反省。我們自己認為安全的環境不一定真的那麼安全。

就以我上面的例子來說，我把金鑰放在 Google 試算表上，只有我自己在使用，我也不會把這個連結告訴任何人，理論上是不會外洩的。可是誰知道呢？

資安事件最常發生的，其實就是在一些你原本認為不會出事的地方，然後它就偏偏出事。

因為我打算將 AI 工作流導入到公司裡面，去說服我的同事以及我的長官，能夠採用「AI First」的系統開發以及維護方式；同時，它也可以用在所有辦公室的行政事務上。

所以我第一個要件，就是一定要有一個妥善的資安系統，確保整個流程最起碼有一個基礎的安全設定。

但首先要說，我並沒有拿 1Password 的錢，所以大家也可以不需要使用 1Password，目前我也只是在測試階段。

其他類似 1Password 的產品還有：

第一類：個人用密碼管理員（對標 1Password）

• Bitwarden

  • 網址：https://bitwarden.com

  • 特色：開源、可自架、CLI 完整

  • 最低價：免費版／Premium $1.65/月

  • 誰適合：預算敏感、重視開源

• Dashlane

  • 網址：https://www.dashlane.com

  • 特色：UI 漂亮、含 VPN、密碼健康度檢查

  • 最低價：$4.99/月（無免費版）

  • 誰適合：重視 UI、要 VPN 二合一

• Proton Pass

  • 網址：https://proton.me/pass

  • 特色：瑞士隱私公司、開源

  • 最低價：免費版／Plus $1.99/月

  • 誰適合：已用 Proton 生態系

第二類：開發者 / DevOps / AI Agent 用的 Secrets Management

• Doppler

  • 網址：https://www.doppler.com

  • 特色：開發者友善、CLI 強、UI 現代

  • 最低價：免費版（最多 5 人）

  • 誰適合：小團隊、新創

• Infisical

  • 網址：https://infisical.com

  • 特色：開源版 Doppler、可自架

  • 最低價：免費版

  • 誰適合：想要 Doppler 體驗但要開源

• HashiCorp Vault

  • 網址：https://www.vaultproject.io

  • 特色：業界標準、企業級

  • 最低價：開源免費（自架）

  • 誰適合：大團隊、Kubernetes

如果各位有其他更好的方案，也歡迎留言推薦給我。

如果你對做 AI 工作流也有興趣的話，但是不知道要怎麼開始，目前我有一個為期四周的陪跑計畫。

AI 一人公司 4 週技術陪跑計畫

後記｜我怎麼讓 AI 從此再也不打斷我（Mac 版）

寫完前面那些之後，我自己跑了一次完整的發布流程，才發現還有一個新問題。

當我在 IDE 裡叫 Claude Code 做事的時候，每一次它呼叫 1Password，背後其實是開了一個全新的 terminal session。

對 1Password 桌面版來說，每個新 session 都是陌生的，所以每次都會跳一個「請求授權」視窗等我按確認。

按一下是不會怎樣，但有時候我發完訊息就去做其他的事情，如果我去倒杯咖啡的時候 Claude Code 跑到一半，跳出驗證視窗，整個自動化就卡死在那邊。

對 1Password 個人方案的人來說，這個問題特別麻煩，因為 1Password 官方解法叫 Service Account，但它只開放給 Teams 跟 Business 方案。我這種 Personal 方案根本沒這個選項。

我讓 Claude Code 測試了好幾次，最後組出一套全自動的流程。寫在這邊給有同樣困擾的人參考。

底下看不太懂沒關係，我也一知半解的，反正你丟給 AI 看，他懂。

整體架構

[macOS Keychain] 存我的 1Password 主密碼
        ↓ 自動讀出
[op-login] 用主密碼簽出 session token
        ↓ 寫進
[~/.config/op-agent/session]
        ↓ 注入到 OP_SESSION_<shorthand> 環境變數
[op-agent <command>] 偵測過期會自動重新簽入
        ↓ exec
[op] 正常拿密碼，不跳框

核心是把 1Password CLI 從「桌面版整合模式」切到「手動簽入模式」。

手動模式會吐出一個有效 30 分鐘的 session token，把它存成檔案，後續所有 op 指令都帶這個 token 進去，就完全不會碰到桌面版的授權邏輯。

主密碼存進 macOS Keychain 是讓整件事可以無人值守的關鍵。

Keychain 在 Mac 開機解鎖後就自動解鎖，AI 從 Keychain 拿密碼不會觸發驗證視窗。

設定步驟

第一步：把 1Password 帳號加進 CLI 手動模式

打開終端機，輸入

OP_BIOMETRIC_UNLOCK_ENABLED=false op account add \
  --address my.1password.com \
  --email your-email@example.com

它會問你 Secret Key（你一開始設定時會下載 Emergency Kit PDF ，裡面有）跟主密碼，輸入完成就把你的帳號註冊到 CLI 手動模式。這跟桌面版的帳號清單是分開的，你必須走這一步才能用 session token。

第二步：把主密碼存進 macOS Keychain

security add-generic-password -a "$USER" -s op-master-password -w

按 Enter 之後它會叫你輸入主密碼。

第三步：讓 Claude Code 寫一個 wrapper script 叫 op-agent

這個 wrapper 做三件事：

1. 從 session 檔讀 token，注入到 OP_SESSION_<your_shorthand> 環境變數

2. 跑一次 op whoami 確認 session 還活著

3. 如果 session 過期，自動從 Keychain 取主密碼、跑 op signin --raw 簽出新 session、再重試

關鍵在第三步的自我修復邏輯。沒有這段的話，session 過期還是要人為介入。有了這段，整套系統就可以連續跑好幾天不需要碰它。

重點片段大概是這樣，你可以貼給 Claude Code 檢視：

# 1. 設定 session env var
SESSION_TOKEN="$(cat "$SESSION_FILE")"
eval "export OP_SESSION_${SHORTHAND}=\"\$SESSION_TOKEN\""

# 2. 確認 session 有效
if ! op whoami >/dev/null 2>&1; then
  # 3. 過期就自動 refresh
  KEYCHAIN_PW="$(security find-generic-password -a "$USER" -s op-master-password -w 2>/dev/null)"
  printf '%s\n' "$KEYCHAIN_PW" | op signin --raw > "$SESSION_FILE"
  # 重新設 env var 再 retry
fi

exec op "$@"

第四步：把 shell init 檔的 op 全部換成 op-agent

我的 ~/.zshenv 原本是這樣：

export NOTION_TOKEN=$(op read "op://Personal/notion-newsletter/credential")

換成：

export NOTION_TOKEN=$(op-agent read "op://Personal/notion-newsletter/credential")

開新終端機的時候自動注入到環境變數，Claude Code 啟動時就吃到這些變數，整個 session 期間完全不用再碰 op。

安全考量

把主密碼放進 Keychain 不是完全沒有風險的決定。Keychain 是用 macOS 登入密碼加密的，一旦有人能在你 Mac 解鎖狀態下取得 shell 存取權，他就能透過 security find-generic-password 把主密碼讀出來。

換句話說，這個方案把「攻擊面」從「攻擊者要拿到我的 1Password 主密碼」轉移到「攻擊者要在我 Mac 解鎖時拿到 shell」。

對我個人來說，後者比前者難度高很多，所以我接受這個風險。

但如果你的工作環境有嚴格的合規要求，建議還是維持每次手動 op-login。

目前我用此機制，在我這台 Mac mini 上跑了自動化，發了一次電子報，全程沒被打斷過一次。

我認為對「一人公司」這種需要跑自動化，人在旁邊只看結果的工作模式來說，體驗還可以，後續再觀察看看。

在前面幾期的電子報之中，我其實讓 AI 寫了幾乎 80% 以上的內容。當時我的想法是人類只要做最後的把關就好。

所以我提供給 AI 主題與參考資料，並加入一些我自己的想法讓 AI 去融會貫通，最後再整理寫成文章。

我作為人類，就在最後潤飾整份稿件，接著再上傳。

在潤飾文章時，我會改掉部分 AI 味道太重的片段，但是除非我整個打掉重寫，否則 AI 味其實挺難去除的。

我本來想說也沒關係，因為更重要的其實是傳達我的想法嘛。

畢竟在做自媒體的時候，我們要在品質跟產出的時間成本之中抓一個平衡。

可是我最近看到一個我蠻欣賞的自媒體創作者，他網站上的某篇文章我一看就知道一定是 AI 寫的。

看到 AI 寫的文章，我是真心讀不下去，所以我就馬上開始反省。

如果我寫的文章也讓 AI 幫我寫，即便我知道這篇 AI 文章確實傳達了我的想法，讀者願意讀嗎？

如果讀者不讀，那在那邊抓品質與時間成本的平衡，又有什麼屁用呢？

信任感在 AI 的時代變得更加重要。我們希望跟我們對話的是人類，而不是 AI。

再者，AI 寫的文章會有特定的「調調」。假設我用 AI 寫文章，我的內容看起來就會跟其他用 AI 寫作的人沒什麼太大差異，都有一股 AI 臭；結果就是我既失去了信任感，也失去了差異化。

因此，我放棄讓 AI 寫電子報了。我認為它應該更關注兩件事情：

• 前期資料整理

• 後期自動發文

AI 寫作為什麼有 AI 味？

AI 寫作為什麼會有股 AI 的臭味？其實也就是人類教給它的。

例如摘要式的寫法，

• 「重點很簡單：」

• 「核心其實是：」

• 「本質上就是：」

• 「說穿了就是：」

還有一種對比句，

• 「不是 A，而是 B」

• 「不再是 A，而是 B」

• 「真正重要的不是 A，是 B」

• 「重點不在 A，而在 B」

你說這種句型不好嗎？倒也不是。它偶爾用一下，其實有一種畫龍點睛的效果。

但 AI 學習大量資料之後，它就覺得人類認為這種句型好，所以它就要用；結果它的每一篇文章，每一個段落都要用。

還有，AI 很喜歡用堆砌抽象的名詞與形容詞。

例如之前我讓 AI 寫過這樣子的文章：

Claude Code 遵守的規則，像一個三層蛋糕 第一層（蛋糕底）：模型自身的規則 這是 Anthropic 在訓練 Claude 模型時「烤進去」的。 比如不能教人做危險物品、不能洩漏個人隱私。這一層你改不了，工具也改不了，是 絕對的底線 。

客觀上來說，你可以說它有寫錯嗎？好像也沒有，但我就是不會這樣寫啊。

然後現在因為 AI 的出現，你在網路上幾乎隨處都能看到一大堆非常相似的文章。

把 AI 擺在正確的位置上，讓它處理雜事吧

創作這件事情，是絕對不能交給 AI 的。

因為創作就是要搞差異化。如果你要做自媒體，就必須表現出個人的特質。

即便是像我做這種知識型的自媒體，知識並不是最重要的一件事情。因為在網路時代以及 AI 的時代，知識唾手可得，讀者沒有必要一定要參考我的意見。

所以我帶給人真正的價值，有很大一部分是個人的生活經驗與情緒價值。

那麼 AI 該做什麼呢？我認為 AI 就是應該要做雜事，就以寫作來講的話，第一步要先決定主題，然後要找資料，「找資料」這件事情就可以讓 AI 去做。

例如你使用 ChatGPT 的深度研究功能，讓它幫你爬網路上的文章並抓取重點；接著人類自己讀過，再去比對原文。

另外，AI 也很適合去整理你的筆記。比如說，我們可以使用 NotebookLM，把一段我跟其他人的討論錄音資料上傳，然後讓它幫我整理成逐字稿，或者是寫成一個有結構的大綱。

不只是前期的資料整理適合交給 AI ，發布文章這種瑣事也很適合。

實戰案例：我怎麼把「發布文章」丟給 AI

除了現在經營的 Substack 電子報、Raven AI 官網，我還有個社群叫做「社畜進化論｜Raven AI」，就在 SKOOL 上面。它是一個結合論壇、線上課程、跟成員管理的網站。

當然要做自媒體，也少不了Instagram、Threads 以及 Facebook 等等社群平台。

每個禮拜我就是寫文章，然後想辦法發送到各平台上。

要人工做這件事也很快，就是複製貼上，不過得稍微調整一下格式。例如文章是以 Markdown 格式儲存的，無法完全符合 SKOOL 的文章格式。有的社群平台也有字數限制，或者要改製成圖卡。

都是很瑣碎的事情，人工弄一弄，幾個小時就消逝了。

所以為了簡化一些流程，我就會使用 Claude Code 做各式各樣的工作流。

舉例來說，本週我就把發布文章到 Skool 上面，建立全自動化的流程。

我利用一個叫 opencli 的開源專案，建了一個自動發布到 SKOOL 的流程。opencli 專案以前在 EP-71 期的電子報已經有介紹過，簡單地說就是讓 AI 代理能透過命命列，操作那些原本只有圖形化介面的網站。

我現在的流程：

1. 人工撰寫長篇文章。

2. 讓 AI 根據現有文章跑流程，製作圖卡，改寫成適合各個社群媒體的短文。

3. 做人工確認後，就讓它自動發布，把電子報的文章送到 Substack ，也同時發布一份到 Skool ，然後圖卡與短文發布到各個社群媒體。

如此一來，我就可以離開電腦，看要做什麼事就去做。

等我回到電腦前，文章已經發布了。

在創作這件事情上面，除非我們可以調教出一個方法，讓 AI 能夠完美地產出我們想要敘述的內容，且它產生的格式也能做到差異化，並表現出我個人獨特的風格，否則在此之前，我們都不應該把創作這件事情交給 AI。

我把這套工具的設定步驟、踩到的坑都寫在『社畜進化論｜Raven AI』社群裡。如果你想看實際怎麼設定、或者想用同一套思路接你自己常用的平台（不只 SKOOL），歡迎加入 → 社畜進化論｜Raven AI

因為我沒有系統性地學習過該如何拍片，也不知道要如何剪輯影片，所以一直在調整方向。

本來我買了 Filmora 來做影片剪輯，它算是市場上相對比較簡單好用的軟體，價格上也不太貴，一年大約花了一千八百多塊。

當然，雖然說它的功能很強大，但就是要花時間去學習。

對於我們這種把經營自媒體當作副業的人來說，平常下班之後要做研究，然後還要拍片，實在沒有辦法撥出更多時間來學習剪片。

可是我發現，可以使用 Claude 當作核心，並結合一些開源工具建立 AI 工作流，讓整個流程都能交由 AI 來完成最繁雜的剪片工作。

全程幾乎沒有任何技術難度。你只要知道怎麼樣下載 Claude Desktop，然後讓它去幫你操作就可以了。

整套 AI 剪片工作流：八步驟拆解

這套流程串了三個開源工具，加上一個 API。

先看角色分工：

• ElevenLabs Scribe：把語音轉成有字級時間戳的逐字稿（雲端 API：scribe）

• video-use：讀逐字稿、決定剪輯點、輸出剪好的影片（github.com/browser-use/video-use）

• Remotion：用 React 寫程式碼產生片頭片尾動畫（github.com/remotion-dev/remotion）

• ffmpeg-full：影片合併、字幕燒入（brew install ffmpeg-full）

video-use 是 browser-use 團隊出的「用 Claude Code 剪片」開源工具。讓 AI 做剪輯、剪贅詞、調色、嵌入字幕，每個剪接點還會自跑一次自我檢查抓跳接和爆音。

Remotion 是「用 React 寫程式碼做動畫影片」的開源框架。它給你一個 frame 編號和一張空白畫布，然後去畫每一幀畫面，最後渲染成 MP4。

ffmpeg-full 是這套流程最後的「組裝工」，負責兩件事：把 cold open、片頭動畫、主體影片、片尾這四段串成一支完整的 mp4；以及把中文字幕嵌進社群短片版本（IG／FB／Threads／Shorts）。

要裝前面三個開源工具，你就直接把 Github 的網址跟 Claude 說，跟它講你要裝這些開源專案，他就會幫你裝好。

但是 ElevenLabs Scribe API 你要自己申請。

ElevenLabs Scribe 是 ElevenLabs 推出的語音轉文字模型，支援 90 多種語言（含中文）。它會回傳字級時間戳和聲音事件標籤（笑聲、停頓），這是後面 video-use 開源專案能精準刪除贅詞的基礎。

價格的話，從每月訂閱費 $6 到 $11 美金，其實也不算太貴。詳情大家可以自己去官網看。

整個流程分八步：

1. 錄影

我用 Filmora 做螢幕錄影，錄完輸出成 mp4 丟到專案目錄。Filmora 在這一步只負責「按下錄影鍵到輸出檔案」這件事。當然也有可能會做一些聲音上的調整，以及稍微加一點素材。

2. 轉錄

video-use 把音訊抽出來送進 ElevenLabs Scribe，回傳 JSON 含每個漢字的起訖時間、speaker_id、音訊事件標籤（笑聲、停頓）。

一支 30 分鐘影片大概花 20 秒、付給 ElevenLabs 0.21 美金。轉錄結果會快取，重剪不會再付一次費用。

3. 繁簡轉換

我發現 Scribe 對台灣中文預設輸出簡體，逐字稿一堆「软件、视频、网络」這類詞。所以讓 Claude 寫了Python 腳本 ，用 OpenCC 的把每個字的 text 欄位掃過一遍。順便把對應的台灣用語替換掉：影片、軟體、網路。

4. 剪贅詞

我自己講話有一堆口頭禪：「呃」「然後」「就是」「這個」「這樣子」。所以也讓 Claude 寫了腳本檢查逐字稿，找這些無歧義的詞跟停頓 > 0.8 秒的長空白，產出 EDL（edit decision list）給 video-use 用。

剪片時前後留 30ms 緩衝避免爆音。

腳本會自動去刪除這些部分，但是某一些內容可能需要由 LLM 來判斷，例如「這個」是贅字，但是「這個禮拜」是指示代名詞要保留。

5. 迭代剪輯

粗剪 v1 之後，可能還想砍某段（例如離題講太久、後來覺得沒必要的片段）。

所以我的流程設計成「內容指認 → 列時間 → 確認 → re-render」這個迴圈：

我：再剪掉「我講 remotion 那段」 Claude：找到了，是 02:15-02:34 這段，逐字稿節錄是「對了講到這個remotion...」，確認剪嗎？ 我：確認 Claude：已加進 EDL，重新 render v2

每輪迭代不會重新轉錄，所以不會再花 Scribe 費用。

6. LLM 修字幕

Scribe 產的逐字稿是「字級切」，每個漢字一個 token。直接生成 SRT 會出現「資訊相 → 關的」「純粹手寫 → 程式的」這種斷字。

所以由 Claude 讀完整份 SRT，套用五條規則：

1. 跨行斷字合併：把破掉的詞接回來，重新切在標點處

2. 重複疊字消掉：「你，你決定」→「你決定」、「蠻，蠻難執行」→「蠻難執行」

3. Scribe 聽錯詞表：「功能師 → 工程師、溫族 → 文組、復雜 → 複雜」

4. 「這個」上下文判斷：後面接名詞（這個禮拜、這個問題）保留，當虛詞拿掉

5. 時間戳鐵律：永遠不動，除非合併重切時按字數比例算 split time

7. Remotion 片頭

用 React 寫程式碼產生 5 秒的「Ravan AI 週報」品牌動畫。Remotion 把 JSX 元件當作影片內容，每幀的位置、淡入淡出、彈跳動畫都用程式碼控制。

另外也會去設計每一個章節過場動畫。因為我一部影片長度大概都在 20 到 30 分鐘左右，所以會有章節的需求，希望能依照章節內容進行分段。

在分段的部分，中間可能會參雜一段大約兩秒的影片過場動畫。

8. ffmpeg 合併＋燒字幕

最後 ffmpeg 把四段串起來：

精華片段 (10-20 秒) → 片頭動畫 → 主體影片 → 片尾

精華片段是從主體裡挑一段最有梗的當開頭，目的是抓住前 15 秒留存率（YouTube 演算法看這個）。

字幕用 ffmpeg-full（內建 libass）去嵌入。

下一步：自動剪輯短影音

目前這個流程做到一半，還沒有完全做完。

待辦事項如下：

1. 每一個章節的過場動畫都還沒做

2. 之後還要增加一個功能，能夠將原本的影片剪輯成短影音的版本

目前有一個比較難解決的問題。

因為我每一次拍片其實都是做電腦的螢幕錄影，畫面是橫式的，但短影音的版本必須是直式。

原本的畫面其實沒有辦法直接轉成直式，因為如果將影片轉成直式的，就必須剪裁掉某些部分。

而切掉的部分，要嘛是捨棄我的臉，要嘛是留下我的臉但切掉了操作畫面。

所以這部分還需要思考應該要如何呈現。

我們下禮拜再來研究。

結語

剪輯這件事，過去是我每週的時間黑洞。

光是聽過自己錄的 30 分鐘影片、找出每一個「呃」「然後」「就是」、再一個個剪掉，就要花掉至少 2 個小時。剩下還要修字幕錯字、調順序。

把這些事交給 Claude 之後，我每週實際花在剪片上的時間剩下大概 30 分鐘。多出來的時間，我拿來看動畫也爽。

這套流程是給每週都要產出影片的自媒體創作者。AI 一人公司的核心，是把規則明確、重複高的勞動交給 AI，留下你的時間給「錄什麼、講什麼」這種真正只有你能做的事。

如果你也想把類似的工作流加入你的副業或自媒體裡，歡迎加入我經營的社群「社畜進化論｜Raven AI」。

一個人摸索工具會走很多冤枉路，一群人一起做會快很多。

→ 加入連結：社畜進化論｜Raven AI

我是認為划算，但是學習路徑改變了，最新的方式是學習「怎麼指揮 AI 做事」。

我自己本身就是文組出身的，我總共花了七年念歷史系（大學＋碩班）。

畢業之後，我在大學做了大概八年多教學行政工作，主要是籌備一些實驗性的課程，以及設計教學計畫，跟寫程式完全沒有任何關係。

後來我從零開始學 JavaScript、Python、資料結構、資料庫等等，現在在台北某個科學機構做系統維運。

我自己本身走過這條轉職的路，所以我很明白轉職者的徬徨。

因此我要跟你分享，在 2026 年，我認為你還是值得跨領域學習資訊工程，但是途徑會有所不同。

我為什麼還是覺得 2026 跨域學資訊工程划算

我知道現在很多人會勸退：「AI Agent 都來了，電腦相關工作會被全部吃掉，幹嘛還學？」

這個論點我只同意一半。

確實，傳統意義上的「會寫 code、會做數據分析、會做美編、會做電商後台、會做簡報」辦公室技能，在未來數年內一定會被 AI 全吃下。

就以我自己舉例，我正在將 Claude Code 當作工作上的核心，一步一步建立所有的工作流，打算把我原本大部分的工作都取代掉。

所以如果要轉職，去做資訊工程相關的工作，這條路應該會有很大的改變。

在 AI Agent 大爆發的時代，「寫程式」這件事情已經被戲稱為「古法編程」了，而這也不過是短短兩三年間發生的事情而已。

現在誰還在純粹手寫程式？就算不用 AI 去做 vibe coding，至少也會用自動補全的功能。

可是這代表學習資工領域的知識完全不重要嗎？絕對不是這樣。

AI 的價值只是在於取代了一些技術上的細節。

舉個例子，你不需要會手寫 Playwright 爬蟲，但你要看得懂它的邏輯，才能跟 AI 說「這段加個延遲、那段換個 selector」。

你不需要會調 LLM 參數，但你要知道 prompt 為什麼有時候會失靈、context window 是什麼、為什麼超過某個長度它就開始亂講話。

所以如果你真正有打算要轉職的話，你真正該學習的是基礎的電腦科學知識，以及最新的 Agentic Engineering （代理工程）技巧。

另外我也認為，所謂的轉職，並不是要你忘記過去所學，而是應該要把過去所學的內容，跟現在學到的知識結合在一起。

畢竟文組的優勢在 AI 時代只會越來越大，而 AI 是放大我們能力的工具。

文組的優勢，在 AI 時代會放大不會縮小

文組的核心是「跟人有關的事」。

例如歷史學是教我們怎麼看事件的脈絡以及長期的結構，政治學讓我們知道權力跟利益之間怎麼交換，經濟學讓我們了解誘因是怎麼設計的。

這些知識你去問 AI，AI 也可以回答你。問題是，AI 畢竟是大量數據去構成的，它畢竟是人類綜合性知識的無生命體。

AI 沒有人生、沒有立場、沒有讀者、沒有客戶、沒有要解決的問題。它能模仿這些學科的語言，但它沒有判斷「現在這個情境下，該講哪個故事、該撫平哪個情緒、該避開哪個地雷」的能力。

AI 沒有了解人類的能力，但是你有這個能力，這才是文組的訓練。

以我自己來說的話，我平常日常的工作能夠交給 AI ，我都交給 AI 取代了。

那沒有辦法交給 AI 取代的，例如說要思考行銷的策略、要思考商業模式、要拍片的時候要說什麼話、要說什麼內容才可以吸引人，這些其實都是文組的訓練。

所以資工是教導我們要怎麼樣在電腦上工作，但是要做什麼？為誰而做？如何呈現去吸引其他人？這些都是人文訓練的延伸

所以如果你身為文組，想轉職換跑道。我認為你可以試試看。但是你不是要去跟工程師競爭，你是要把你原本的專業乘上 AI，做出工程師做不出來的東西。

這才是 2026 年的機會所在。

給大齡轉職者的學習路徑：直接學習怎麼操作AI

其實最近我也發現自己有很多不足，尤其是上述提到的Agentic Engineering （代理工程）。老實說，我對這塊也不太懂，因此我自己去找了一些網路上的課程，打算之後來學習。

順便我也整理了一下，打算分享給各位我的學習清單，底下我把學習清單分成兩種人。

第一種是「中年轉職者或進修者」，時間最寶貴的那一群。

對這類人，我建議不要去補電腦科學背景，直接學「怎麼讓 AI 幫你做事」。學完當天就能把每天的重複工作交出去。

總時數抓 15 小時，分兩個階段。

入門基礎（3-5 小時）

Coursera 的「AI Automation with Claude」是免費的，由 Anthropic 跟 1Password 贊助，教你把 Claude 變成生產力引擎、設計 Claude Projects。

另一個推薦是「Claude Code Tutorial - CC for Everyone」，也是免費，特別之處是「在 Claude Code 裡面學 Claude Code」，沒有影片、沒有文件、不需要寫程式經驗。

上述都是英文，如果你對英文學習覺得有些陌生，我更推薦的是雷蒙的課程「24 小時開始活用 Claude Code（AI Agent）」。這堂課教了很多 Claude Code 的基礎設定與操作，以及一些實際的 AI 工作流應用。

這堂課我自己也有買。雖然我早就知道 Claude Code 要怎麼使用，但是因為我覺得這堂課程的編排實在是太棒了，很值得像我這種也打算自己開 AI Agent 課程的自媒體學習。

實戰應用（10-15 小時）

我以前轉職時很常用 Udemy，因為它常常在特價，有時候台幣 300 多塊就可以買一堂課。

所以我最近就到 Udemy 上，看看有沒有做 AI Agent 或者是 AI 工作流的課程。

我發現有一堂課程超級有名，「The Complete Claude Code Claude Cowork Masterclass」，它是一堂「Claude 全家桶 + AI Agent 團隊」的整合實戰課 ，教你怎麼把 Claude 塞進日常工作流，從個人生產力一路做到自動化 AI 團隊。

雖然這門課有點像是一個大雜燴的課程，不過因為價格實在太便宜了，特價買才 310 元，便宜到不可置信，內容又很豐富，所以我還是直接買了。也一起推薦給你。

對於大齡轉職者，我的建議：

如果你對於電腦操作不太熟悉，我建議你直接使用 Claude Desktop 或者 Codex 桌面版，來作為電腦上的人工智慧核心。

然後搭配 n8n 以及 Google Apps Script（兩者可以混用）來做工作流串接。

所以你可以參考我底下的兩本電子書：

適合新手的 Vibe Coding (ChatGPT + Google Apps Script)，有７個章節，599元。一開始是教你如何使用 ChatGPT 寫程式，用複製貼上的方式製作，後期也能夠使用 Claude Code 等工具來快速開發。

適合小白的 AI 自動化(n8n)，有７個章節，目前特價 299 元。教你基礎的 n8n 工作流，也可以學習怎麼使用 Claude Code 串接 n8n 。

年輕跨領域學習者：補基礎、學 Agent、做差異化

第二種人是「年輕跨領域學習者」，可能剛從學校畢業，有那個心力，還沒有過多的經濟負擔，願意投資 6 到 9 個月的那一群。

這條路就是我自己走過的路，但是我自問我自己，如果在 2026 年我可能會怎麼做？底下是我的建議：

Phase 1：CS 基礎打底（60-80 小時，2-3 個月）

我曾經去上過坊間的一些網頁開發的課程，可是真正奠定我電腦基礎的就是 Harvard CS50x。

哈佛大學的 CS50x 免費讓全世界的人閱覽，2026 版新增了「AI 對電腦科學影響」的全新章節，由 David Malan 教授主講，他被廣泛認為是世界上最頂尖的電腦科學講師之一。

課程涵蓋抽象、演算法、資料結構、封裝、資源管理、安全、軟體工程、Web 程式設計，使用 C、Python、SQL、HTML、CSS、JavaScript。如果你需要證書，我記得 edX 證書約 NT$3,000-9,000。

只有一門課當然不足以學到資工系（資訊工程系）大學四年的所學，但這一門課的價值在於你可以知道電腦到底在做什麼。

後續我們所有的 AI 工具的概念，都是建立在這個底子上。

Phase 2：Python 與 AI 基礎（50-70 小時，2 個月）

接著上 Harvard CS50 AI（Introduction to Artificial Intelligence with Python）。先修要求是 CS50x 或一年 Python 經驗。

涵蓋 search 演算法、knowledge representation、machine learning、neural networks、natural language processing。理論跟實作平衡，hands-on 專案有自動評分系統提供即時回饋。

這門課讓你理解「AI 為什麼這樣運作」，不只是會用而已。

在當初，我是直接買書去學習資料庫、軟體工程、演算法等等，畢竟當時還沒有 AI。所以我沒有看這門課程，但我推薦你看。

因為在這個年代，我不建議文組直接跨到工程師的領域，而是要結合自己的專業。我們的目的只是要看得懂這些東西怎麼運作。

Phase 3：Agentic Coding 實戰（40-60 小時，2 個月）

從這三堂選一堂：

• Anthropic Claude Code 101（官方免費），最快的入門。

• DeepLearning.AI 的 Claude Code 課程，由 Elie Schoppik 主講，節奏緊湊。

• Coursera 上 Vanderbilt 的「Claude Code: Software Engineering with Generative AI Agents」，由 Jules White 教授帶，深度版。

我會建議從 Anthropic 官方那堂先看，我自己也是正在看，之後再決定要不要上深度版。

Phase 4：Agent 系統建造（50-80 小時，2 個月）

最後一段是 Udemy 的「AI Engineer Agentic Track: The Complete Agent & MCP Course」，由 Ed Donner 主講，6 週密集，每週升級一個框架：OpenAI Agents SDK、CrewAI、LangGraph、AutoGen，最後一週完整 MCP。

我看 Udemy 上面這門課也挺有名的，這堂是少數把 OpenAI SDK、CrewAI、LangGraph、AutoGen、MCP 都做過一輪的課，學完能自己判斷該選哪個。

我自己的故事：從教育行政到系統維運，再到 AI 一人公司

最後分享自己的故事。

我在畢業之後，到大學從事教育行政的工作。主要的工作是設計多國語言學習課程、撰寫與執行教學計劃，研究怎麼讓學生「自主學習」等等。

大概在 2018 年左右，我突然心血來潮想學製作網頁，就去臺大資訊系統訓練班，上了幾週前端網頁設計，產生了一些興趣。

後來又陸陸續續學了 Python 、C語言、資料結構、資料庫、資訊管理、系統分析與設計、軟體工程、網際網路等等。

最後索性轉職，現在主要做 Linux 系統維運的工作。

所以我很能體會轉職者的心情。

轉職的人最害怕的其實就是世間的壓力。我們一直都會覺得自己年紀跟別人比起來已經老大不小，然後還在轉職。

尤其是現在 AI 進步的速度這麼快，你只要去看新聞就會發現，有很多科技公司在最近幾個月陸陸續續裁員。

如果你還在想說要轉職到科技業，那我覺得你一定是吃錯藥了才這麼想。

但我也不希望你放棄。

我認為我們還是有機會透過 AI 的技術，去補強我們原先缺漏、不足的部分。

在上面的文章中，我提到了兩條主要的途徑。

如果你年紀已經超過 30 歲了，那麼時間對你來說是個稀缺的資源，盡可能不要放棄自己過去的積累。

不論你過去是什麼樣的專業，想辦法去將這些專業最精華的知識萃取出來，然後盡可能地去鑽研它，讓它能夠更有效地讓你在職場上發揮。

AI 當然也是要學的，但是學習 AI 的目的，是學習怎樣讓 AI 來幫助你工作，製作專屬於你的 AI 代理，以及建立你自己的 AI 工作流。

請你直接下載 Claude Code 或 Codex ，現在就開始用。

如果你還年輕，時間還很多，我依然不建議你跨到工程師的領域，轉職當工程師。

不過你可以多花一點時間，去學習 AI 代理的相關知識，以及學習電腦科學基本知識，例如：

1. 基礎的程式設計：包含虛擬碼（Pseudocode）要怎麼寫。

2. 資料結構與演算法：瞭解其運作原理。

3. 資料庫：掌握基本常識。

有了基本的知識，當你要指揮 AI 代理幫你工作時，就能更有效地達到事半功倍的效果。

總結 2026 年文組轉職的核心：不是去當工程師，是讓 AI 替你補工程師那塊，然後用你原本的人文訓練去做差異化。

如果你也在思考自己屬於哪一類、想跟一群正在走這條路的人一起前進，歡迎加入我的社畜進化論｜Raven AI 社群。裡面有實戰拆解、學習路線討論、還有一群跟你一樣從零開始的夥伴。

人類習慣使用的電腦作業方式，已經開始產生了革命。

這場生產力革命帶來的衝擊，將會前所未見的劇烈，因此我建議你可以試著開始改變你的工作型態。

至於怎麼改變，則要從終端機開始說起。

就算不是工程師，只要你稍稍關注 AI 相關新聞，你一定會聽到大家在瘋「龍蝦（OpenClaw）」或者 Claude Code 等超強的 AI 生產力工具。

這些 AI 生產力工具可以徹底解放你的雙手。只要你能夠妥善地安排你的工作流，你可以讓 AI 做掉很多繁複的細節。

可是當你在 YouTube 上看了一些影片，想嘗試去使用這些工具的時候，卻發現有許多步驟都要使用黑黑的終端機畫面，感覺就像是工程師在做的事情。

其實你只要稍微改變一下心態，並且全然地接受將 AI 代理作為你工作的核心，使用終端機介面不應該是你的障礙。

這裡說的黑黑的終端機，是一種稱作 CLI（Command Line Interface，命令列介面）的操作方式，跟我們習慣的圖形化介面（GUI，Graphical User Interface）不同。

使用者如果要自行操作終端機的話，必須要先記住很多的指令，不像是圖形化介面相對來說比較直覺。

例如我在臺北某家科學機構從事系統維運的工作，我每天的工作就是登入 Linux 系統去操作 CLI 介面，我必須要先記住很多的 Linux 指令。

然而 AI 時代來了，你根本不需要記住這麼多的指令。你只要知道你要做什麼，讓 AI 來幫你執行這些指令。

因此，為了因應 AI 代理（AI Agents），有許多公司也推出了 CLI 介面。例如：

• Google Workspace：2026 年 3 月 5 日由 Addy Osmani 宣布 gws CLI。

• Obsidian ：在 1.12 版本中推出了官方 CLI。

• Stripe ：2026 年 3 月 27 日推出 Projects CLI。

• Polymarket ：明確為 AI agent 可存取性建 CLI 。

為什麼會這樣？

因為這些 AI 工具背後的技術是使用大型語言模型。它們在閱讀文字的速度，會比使用圖形化介面還要快很多。

所以可以想見，在未來 5 到 10 年，我們人類會透過自然語言跟 AI 溝通，而 AI 則透過 CLI 介面，去跟各種軟體、程式相互溝通。

當然，圖形化介面是不會消失的，因為我們人類需要透過圖形化介面來與電腦共同協作；但是 CLI 介面也會因應此次 AI Agent 的浪潮而復甦。

典範開始轉移了，這又是從哪裡開始的？

CLI 命令列介面和 GUI 圖形化介面的糾葛

1960 年代電腦還沒有「介面」。

早期都是研究員用紙筆寫程式，再把程式打成打孔卡，交給機房，排隊等幾小時拿結果。

當然這樣子做非常麻煩，後來就有 IBM 的分時系統，可以讓多人透過 CLI 介面使用電腦主機。

然後在 1969 年貝爾實驗室，Ken Thompson 跟 Dennis Ritchie 寫出了 Unix 系統，奠定了日後大家使用終端機的基礎。

可是使用 Unix 系統必須要用 CLI 介面，你必須要記住很多的指令。例如：ls 是列出資料夾內容、cd 是切換目錄、rm -rf 是刪除檔案、chmod 755 是修改權限。每一個操作都要記住對應的英文縮寫，沒有圖示、沒有按鈕，打錯了只會報錯。

GUI 圖形化介面的發展晚了一些。

Xerox PARC 的 Alan Kay 在 1973 年做出有滑鼠、視窗、點陣螢幕的 Alto 電腦，不過此時都還只是實驗性質。

後來 Steve Jobs 去 Xerox 參觀時驚為天人，回去後改變了蘋果電腦的發展方向，在 1984 年推出了麥金塔電腦（Macintosh）。

隔年微軟的 Bill Gates 推出了 Windows 1.0，市場反應不太好，一直要到 Windows 3.0 才開始流行，1995 年的 Windows 95 則普及到家家戶戶。

GUI 為什麼勝出？說穿了就一件事：要把電腦賣給不懂指令的人。

況且人類大腦本來就比較善於處理視覺資訊，再搭上 Apple 跟微軟的行銷預算，「電腦」這個詞在一般人心裡幾乎和「視窗、滑鼠」畫上了等號。

可是 GUI 的便利是有代價的，它把使用者鎖在設計者預想的操作範圍裡。

GUI 的設計邏輯是：把最常用的操作做成按鈕。

問題是，設計者沒辦法預想到每個人的需求。你想把一千個檔案依照規則批次改名，GUI 沒有這個按鈕；你想把三個工具的輸出串在一起、自動跑完一套流程，GUI 做不到。

CLI 的邏輯則相反。它不試圖預想你要做什麼，它只給你積木，讓你自己組合。

Unix 的管線（pipe）符號 | 就是這個哲學的體現：你可以把任意兩個工具的輸入輸出串在一起，拼出 GUI 根本沒辦法提供的功能。

更關鍵的是可重複性。

CLI 指令可以被存成腳本，今天跑、明天跑、交給別人跑，結果都一樣。你可以把它放進版本控制系統，追蹤每次的變化。

GUI 的操作則是一次性的，你點了什麼、怎麼點的，沒有記錄，沒辦法重播，也沒辦法自動化。

這就是為什麼即使有 GUI 可用，還是有人會用 CLI（尤其是工程師）。不是因為他們喜歡跟自己過不去，單純就是比較好用而已。

這個分工維持了幾十年，直到 AI 出現，才讓 CLI 突然從後台配角變成主角。

AI 來了，CLI 再度復甦

LLM （大型語言模型）是新的介面層。

人類透過自然語言跟 LLM 說話，LLM 在背後透過 CLI 操作電腦。

介面典範正在轉移，CLI 的使用者不再是人類，而是 AI 代理。

首先，文字是 LLM 的原生語言，叫 LLM 看像素、辨識滑鼠游標、理解下拉選單，它做得到，但又慢又不穩，而且還很浪費 Token（可視為 AI 額度）。

一個 CLI 工具就是一個現成的 function call，有明確輸入、穩定輸出、可預期的退出碼。

AI 代理要串三個工具完成一件事，CLI 幾乎是現成的積木。

況且，當 CLI 回覆 JSON、TSV、純文字，LLM 解析準確率接近百分之百。

如果用圖形化介面，要靠截圖 + 視覺辨識，每次網站改版還得重新訓練。

Andrej Karpathy（前 OpenAI 共同創辦人）在今年 2 月在 X 上發布一則貼文說，

CLI 之所以令人興奮，正因為它是「遺產技術」。這意味著 AI 代理可以原生且輕鬆地使用它們、組合它們，並透過整套終端機工具鏈與它們互動。例如，你可以叫你的 Claude/Codex 代理去安裝這個新的 Polymarket CLI。

OpenCLI：把任何網站變成 AI 的命令列

在文章的最後，讓我為你介紹一個開源專案：OpenCLI。

OpenCLI 是 GitHub 上一個叫 jackwener 的開發者發起的開源專案，口號是「Make any website your CLI」，讓任何網站變成你的 CLI。

你可以讓 AI 代理能透過 CLI 去操作那些原本只有 GUI 的網站。

OpenCLI 利用你已經在 Chrome 裡登入的狀態（session），讓 AI 代理能跟動態網站互動，而且不需要你交出帳密。

當然，你必須要非常小心地使用這類的工具。

因為既然它不需要你交出任何的帳密，那就代表說，如果有駭客挾持了你的工具，他也可以登入你原先要使用帳密才能登入的網站。

目前 OpenCLI 內建的網站命令涵蓋十七個站、超過三十五個指令，從 Bilibili、知乎、小紅書、微博、Twitter、Reddit、GitHub、Hacker News、到 YouTube、Yahoo Finance、Reuters 都在列。輸出支援 table、JSON、Markdown、CSV，全部都是 Unix 哲學的標準動作。

更酷的是它有 explore、synthesize、cascade 三個給 AI 用的命令：你給它一個 URL 加一個目標，它能自己去探索網站的 API、生成 adapter、試探認證策略。換句話說，它能自己長出新的 CLI。

你現在不用去學 OpenCLI 的任何一個命令。

我只需要知道 OpenCLI 存在、大概能做什麼、有哪些指令。剩下的交給 Claude Code 或 Codex CLI 去查、去裝、去組合。AI 代理會讀 OpenCLI 的文件、會試、會在失敗時自己修正。

這是一個新的時代：你不再需要知道 Know-how，你只需要知道 Know-what。

你必須訓練你自己能夠看到整個架構的輪廓，而不是盯著小細節鑽研。

Share Raven AI 週報

工商時間

想要把 AI 代理真正用在工作跟事業上，而不是只停在「試試 ChatGPT」？我的社畜進化論｜Raven AI 社群專門拆解 AI 一人公司的實戰流程，從選工具到打造自動化系統，有完整的路徑圖跟可以直接用的腳本。

加入社群

我原本用了兩個月龍蝦（OpenClaw），最近決定搬到了另一個開源 AI Agent 專案愛馬仕（Hermes Agent）。

整個搬家過程大概不到一小時，比我預期的簡單很多。

如果你也有考慮要搬家，我建議你使用另外一個 AI Agent ，例如 Claude Code 或 Codex 幫你搬，你可以省下非常多的力氣。

不過在搬家之前，你還是要先去評估自己的需求，再來決定要不要搬。

為什麼要從龍蝦搬到愛馬仕

龍蝦是我正在進行實驗的 AI Agent。

它住在我的 Mac Mini 上，主要的目的就是希望我可以使用零碎的時間，不管是在通勤、在辦公室，或者是在拉屎，我都會透過 Discord 去呼叫它。

想到什麼工作，就派命令給它。

基本上就是一個 24 小時待命的 AI 助手。

但它真的很不穩定。

龍蝦的更新速度都非常頻繁，但每次一更新，有些工具就會壞掉。

像有一次它更新完之後，就變得跟智障一樣，叫它做事情都跟我說會做、會做，結果他媽的都不做。

龍蝦的記憶系統也是有點問題。常常每次要跟他講事情的時候，我就要重新提醒他一遍。我自己大腦也要去記住說，他到底裝了哪些技能，然後那些技能的路徑位置、哪些檔案的位置，或是哪些工具的存放位置在哪邊，我自己都要先記得清清楚楚。

這真的是有夠麻煩，就好像在帶一個說一動做一動的工讀生一樣。

我知道有很多開源專案其實也提供了一些方法，可以去調整龍蝦讓它的記憶力變得更好、更聰明一點。但是就是要花很多時間去調校，真的很麻煩。難道就不能裝好之後，就可以馬上用嗎？

因為我的需求也沒有到很多，我主要只是要遠端派任務給它。然後它可以記得我的資料夾位置，以及我平常都在做什麼樣的任務。

目前雖然 Claude 有提供遠端呼叫的功能，但是那個功能並不好用。等於是我要跟 Claude 一直維持在同一個頻道上，只要頻道一關掉，我跟 Claude 之間就斷線。

所以後來看到 Nous Research 推出愛馬仕，在開源社群上大家也都在推薦，我研究了一下就決定搬了。

愛馬仕搬家實錄

我的安裝方式是直接丟愛馬仕的 GitHub 網址給 Claude Code，讓它讀完之後幫我執行安裝。

Claude Code 不只跑了安裝指令，連 API key 設定、OAuth 登入這些瑣碎的步驟也一併處理好了。整個過程我幾乎沒有手動操作，也沒有什麼痛感。

遷移龍蝦的資料也很簡單，就一行指令：

hermes claw migrate --yes

它會把龍蝦的記憶、自定義技能、Discord 設定都搬過來。我的結果是 26 個項目成功遷移，包含 19 個自定義技能。

唯一麻煩的是排程。

我在龍蝦上設了不少定時任務，這些排程都是針對龍蝦設計的，搬過來之後全部要重新配置一次。這是整個搬家過程裡最花時間的部分。

所以如果你在龍蝦上寫了很多排程，想搬家的話一定要先想清楚。安裝和遷移本身很快，但排程重建的工程量可能比你想的大。

愛馬仕用起來怎麼樣

用了一段時間，最明顯的感受是愛馬仕的記憶系統好很多。

它比較清楚我之前做過什麼，也會自動把該記的東西記起來。相比起來，龍蝦的記憶跟金魚差不多，你得反覆跟它講同一件事。只要頻道（Session）一關掉，它就什麼都不記得。

另一個我很喜歡的是 Discord 上的對話管理。

當我叫愛馬仕做一件事，它會在頻道裡另外開一串對話（thread）。我只要針對那一串回覆就好，不會跟其他訊息混在一起。

雖然講起來好像也沒什麼，不過用起來的舒適感就是有些差距。

愛馬仕與龍蝦的記憶哲學：自動書櫃 vs 手動資料夾

不管是愛馬仕還是龍蝦，兩個 Agent 對「記憶」這件事的想法完全不同。

愛馬仕像一個會自動歸檔的書櫃。

你跟它講過的事情，它會自己判斷哪些重要、主動記下來。它背後有一個 SQLite 資料庫搭配 FTS5 全文檢索，把所有對話歷史都存起來。

當你問它「上週我們討論過什麼」，它會用 Gemini Flash 幫你把搜尋結果做摘要，不用把整段舊對話塞回上下文裡浪費 token。

另外，愛馬仕在每次開機的時候，會把 MEMORY.md 和 USER.md 這兩個核心記憶檔凍結進系統提示裡，整個對話過程中都不會動。

據說可以省下大概九成的重複 token 費用。

雖然龍蝦也有 SQLite，但用途不一樣，它是拿來做向量搜尋和關鍵字比對的，不是存對話歷史。

龍蝦還有一個 daily notes 機制，每天自動產生一份筆記，但它預設只會載入今天和昨天的。更早的內容要 Agent 自己「想到」該去翻才會找，實際用起來常常就是忘了。

簡單講，最大的差別在三件事：

• 誰決定記什麼（愛馬仕自己判斷，龍蝦靠人）

• 能回憶多遠（愛馬仕可以搜幾週前的對話，龍蝦預設只看兩天）

• 記憶的主動性（愛馬仕會主動記，龍蝦要你告訴它）

愛馬仕的做法確實更聰明，實際用起來也比較輕鬆。不過因為它會自動整理，所以你也不知道他幹了什麼，有可能亂搞你都不知道。

龍蝦看似笨一點，但你放什麼它就是什麼，不會被動到。

愛馬仕與龍蝦的技能生態：實習生 vs 工具箱

愛馬仕像一個會自己學新技能的實習生。

它做完一件比較複雜的任務之後，會自己把步驟整理起來，變成一個可重複使用的技能檔案。這樣下次遇到類似的事情就會直接照做。

這樣聽起來好像很理想，可是也是有可能會出問題。

我看網路上有人說，它有時候會把你已經教好的正確做法「改良」成錯的版本。因為它永遠覺得自己做得很好，沒辦法客觀評估自己的修改到底是改進還是退步。

龍蝦比較像工具箱。

反正呢，我們要他裝什麼技能，我們就自己去 ClawHub ，上面有幾千個別人寫好的技能可以下載安裝。需要客製化技能的話，我們就自己調整就好。

我的判斷

我覺得愛馬仕跟龍蝦兩個都各有好處。

愛馬仕的記憶能力比較好，用起來也簡單，雖然可能改壞原本的技能，但是不要用太笨的模型，應該會改善一點。

我也不會建議每個人都要搬家。

如果你需要多個 Agent 協作，或是已經在龍蝦上建了很完整的工作流，要先想清楚。龍蝦在多 Agent 管理和團隊協作這塊目前還是比較成熟的。

而且愛馬仕現在才剛推出沒多久，它迭代的速度以及生態還遠遠不及龍蝦，所以不急著搬。

讓子彈飛一會。

工商時間

如果你也在想怎麼用 AI Agent 建立自己的工作系統，但不確定該怎麼選工具、怎麼規劃流程，歡迎加入社畜進化論｜Raven AI。

裡面有更多 AI Agent 的實戰分享，也有其他自動化工具的搭配方式。

加入社群

做自媒體會失敗，通常不是因為你寫不出東西，而是沒辦法持續產出。

我失敗好幾次了，每一次放棄都不是因為「沒靈感」，而是因為整個產出流程太累了，短期又看到成果，最後撐不住。

一個禮拜要固定生出一到兩篇內容，同時還要上班、還要處理生活瑣事。靠意志力硬撐，最多撐三個月就會開始找藉口跳過。

直到我建立了自動化工作流。

我的第一次失敗：WordPress 時期踩過的坑

兩三年前，我租了 Bluehost 的伺服器，裝了 WordPress，認真地開始寫文章。

當時寫的內容大概是一些個人的人生經驗跟職場心得。寫了幾篇之後就發現兩個問題：

• 這種內容本來就不太有人讀，畢竟我又不是什麼名人

• 商業模式完全沒想清楚，不知道寫這些東西到底能幹嘛

沒有讀者、沒有收入方向，每次打開編輯器都覺得「我到底在幹嘛」。

後來就停了。

我找不到一個讓我覺得「值得繼續」的理由，也沒有一套流程讓產出變得輕鬆。

AI 時代，遊戲規則變了

然後 ChatGPT 出現了。

我本來就很喜歡這類數位產品，所以第一時間就跳進去用。用著用著，覺得這個領域有太多東西可以聊，就開始了「Raven AI 週報」這個電子報。

一開始也只是隨便分享自己的學習心得，沒什麼規劃。但跟上次不同的是，這次我找到了一個我真的有熱情、而且持續有新東西可以寫的主題。

漸漸地，商業模式也開始有了雛形。

說到商業模式，老實講我到現在也不是很明白自己在做什麼。不是有句話說「網紅最終的歸宿就是賣課」嗎？Joeman 也在賣，愛莉莎莎也在賣，我自己也做了一些微課程放在網路上賣，算是走這條大家都在走的路。

至於能不能找到更有趣、更特別的方式去吸引客戶，這是後續要研究的課題，目前沒有標準答案。

但有一件事我很確定：AI 讓我的產出速度變快了。

以前寫一篇文章要花一整個禮拜，而且都是在下班時間做研究，真的很吃緊。現在我同樣有工作，但一個禮拜產出的內容超過兩三篇都還有餘裕。

差別在哪？是因為我不追番不打電動了？怎麼可能，只是因為工作流程變了。

我現在同時經營多少管道？

目前我手上同時在跑的管道有：

• 免費電子報：就是你現在在看的這份 Raven AI 週報

• 付費社群：裡面有更完整的課程內容跟實戰拆解

• IG：最近在優化圖卡的製作流程，讓產出更穩定

• 部落格：最近又做了一個結合官網的部落格

之前還試過 YouTube 與短影音，但那個工作流程沒調整好，算是半失敗狀態，之後可能要重新來過。

拿 IG 來舉例好了。我的 IG 荒廢了很久，因為我懶得拍片，做圖卡也太花時間。光是在 Canva 裡面挑模板、調文字、換配色，一套 carousel 弄下來就耗掉一大塊時間。

後來我用龍蝦（OpenClaw）搭配 Playwright，做了一條 IG 圖卡的自動產線。龍蝦會自動從 X 上抓取高品質的 AI 相關內容，我只要花幾分鐘挑素材，跟它說「這篇文章拿來做圖卡」，它就會自動寫文案、套 HTML 模板、渲染成 PNG 圖片。

整個過程我真正動手的只有選素材和最後確認，一套 6 到 10 張的圖卡幾秒鐘就跑完。

這個工作流的完整拆解我寫在另一篇實戰筆記裡，有興趣的話可以這裡看：

自媒體圖文製作工作流：用龍蝦 AI 代理打造 IG 圖卡自動產線

所以這麼多管道，哪來的時間？

答案就是：如果沒有 AI 和自動化，我根本做不到。

寫電子報、做部落格，核心就是要持續更新。放在那邊不動，是不會有流量的。但要一個人同時維護這麼多管道，光靠手動作業根本不可能。

重點不是用什麼工具，是建立你的自動化工作流

要做自媒體，還要下班時間做，沒有把流程優化到順手是不太可能完成的。

尤其是現在大家都在用 AI。如果你自己不用，在經營自媒體的時候就很難跟別人競爭。

你的對手可能一個人就能產出你一個團隊的量，因為他有一套跑得順暢且有成效的自動化流程。

所以我覺得 AI 時代做自媒體的重點之一，是建立一套屬於自己的自動化工作流，讓你可以穩定地、持續地產出內容。

持續，才是自媒體唯一的護城河。

工具會變、平台會換，但如果你有一套讓自己能持續運轉的系統，你就能一直留在場上。

而留在場上的人，才有可能脫穎而出。

工商時間

如果你也在思考怎麼用 AI 建立自己的自媒體或一人事業，但不知道從哪裡開始、該怎麼規劃，我有提供一對一的 AI 一人公司啟動諮詢。

我會根據你目前的狀況，幫你釐清方向、規劃適合你的 AI 工作流，讓你不用自己摸索半天還在原地打轉。

我要諮詢