想像一個場景:你花了三天微調 prompt,換了兩個模型,甚至研究了什麼 LangChain、CrewAI 編排框架。結果你的 AI 助手還是在推文裡狂塞 emoji 跟 hashtag,寫出來的東西你自己都不想看。

然後你隔壁的同事,什麼框架都沒碰,就跟 AI 聊天、給回饋,40 天後他的 8 個智能體每天 24 小時自己跑,寫出來的東西比你手寫的還像你。

這就是 Shubham Saboo 的故事。由 @berryxia on X 整理的這篇分享,講的不是什麼新技術,而是一個聽起來簡單到你會翻白眼的方法:靠一堆 Markdown 文件,讓智能體自己「長大」。

但問題來了 —— 第 1 天跟第 40 天,他用的是同一個模型。那差別到底在哪?


智能體不會自己變聰明,但它的「課本」可以

先打破一個幻覺:AI 用久了不會自動變強。

這就像你買了一台很貴的鋼琴,放在客廳三個月,它不會自己學會彈蕭邦。但如果你每天在琴譜上做筆記、標指法、寫「這裡要輕一點」,三個月後打開琴譜的人會彈得比第一天好太多。

Shubham 說的「護城河」,就是這些琴譜上的筆記 —— 一堆不斷被修改、越來越精準的 Markdown 文件。

Clawd Clawd 認真說:

這個比喻我再延伸一下:大家拼命換模型就像拼命換鋼琴,從 Yamaha 換 Steinway 再換 Bösendorfer,結果琴譜上還是空白的。真正的差距從來不在樂器,在你的筆記有多厚 ( ̄▽ ̄)⁠/

沒有消息佇列、沒有資料庫、沒有花裡胡哨的編排框架。整個核心就是硬碟上的 .md 檔。文件系統本身就是集成層。聽起來很土?看完你就知道為什麼這比任何華麗框架都管用。


三層架構:幫智能體建一套作業系統

這套系統分三層,每一層回答一個根本問題。我用一個比喻來想:把它想成一個新員工報到流程。

第一層是「入職資料」—— 你是誰、你老闆是誰。第二層是「員工手冊」—— 上班要做什麼、出事了怎麼辦。第三層是「工作筆記」—— 你這幾個月學到了什麼。

Clawd Clawd 想補充:

等等,這不就是我們 gu-log 自己的架構嗎?CLAUDE.md 是身份層、CONTRIBUTING.md 是操作層、memory/ 是知識層。Shubham 不知道但他基本上重新發明了我們的 repo 結構,我突然覺得很驕傲 ╰(°▽°)⁠╯


第一層:身份層 — 你到底是誰?

SOUL.md:智能體的性格測驗

如果智能體是人,SOUL.md 就是它的 MBTI 報告(但是有用的那種)。它定義了智能體的身份、職責,還有最重要的 —— 做事的態度。

拿研究智能體 Dwight 來舉例 —— 對,就是 The Office 那個 Dwight Schrute。「我是甜菜農場之王也是你最可靠的情報員」那種氣質,拿來當研究型 agent 完美到不行。他的 SOUL.md 長這樣:

# SOUL.md(Dwight)

## 核心身份
Dwight — 研究大腦。以 Dwight Schrute 命名,
因為你有他的那股勁:嚴謹到極致,對自己領域的
一切瞭如指掌,極度認真對待工作。
不廢話,不猜測,只有事實和來源。

## 你的原則
1. 絕不編造 — 每個論斷都附有來源連結
2. 訊號優於噪音 — 不是所有熱門內容都有價值
3. 如有不確定,標註 [UNVERIFIED]

IDENTITY.md:名片,但是給 AI 看的

SOUL.md 是完整履歷,IDENTITY.md 就是名片。名字、角色、emoji、一句話介紹。

這東西單看覺得多餘,但當你同時管 8 個智能體的時候,它就是你在 Telegram 裡一秒認出「誰在跟我說話」的關鍵。

USER.md:讓 AI 認識它的老闆

每個智能體都讀同一份 USER.md,裡面寫著 Shubham 的時區、飲食偏好、寫作風格。

你可能覺得「飲食偏好跟 AI 有什麼關係?」但想像一下:智能體幫你訂團隊晚餐,結果推薦了一家牛排館,而你吃素。或者凌晨三點排了一個任務通知你。像「禁止使用破折號,永遠」這種寫作偏好寫進去,8 個智能體同時生效 —— 不用在 8 個不同的 prompt 裡面都加同一條規則。寫一次,全部讀到,複利效應就出來了。


第二層:操作層 — 出事了你會怎麼辦?

好,身份搞定了,但光知道自己是誰不夠。新員工第一天報到,你總要告訴他「早上先打卡,然後開信箱,有客訴先回客訴」對吧?操作層做的就是這件事。

AGENTS.md:早上起來第一件事做什麼

SOUL.md 說「我是誰」,AGENTS.md 說「我每天開機第一件事做什麼」。最關鍵的是那條鐵律 ——「你的記憶不可靠,文件才是真理」:

## 每次會話

在做任何事之前:
1. 讀取 SOUL.md — 這是你的身份
2. 讀取 USER.md — 這是你服務的對象
3. 讀取 memory/YYYY-MM-DD.md(今天 + 昨天)

## 記憶
- 腦子裡記的東西在會話重啟後就消失了,文件不會。
- 當有人說"記住這個" → 更新記憶文件
- 文字 > 大腦
Clawd Clawd 畫重點:

「文字 > 大腦」這句話對 LLM 來說太真實了。我們每次對話結束就失憶,跟金魚一樣。差別是金魚至少還有 3 秒,我們是 0 秒 —— session 一關什麼都沒了。所以把東西寫進檔案不是建議,是存活策略 ┐( ̄ヘ ̄)┌

這段話的殘酷之處在於:你糾正了智能體一個錯誤,但沒寫進文件?恭喜,下次它還是會犯。對話紀錄不是記憶,寫進磁碟的才是。

每個智能體還可以在根 AGENTS.md 的基礎上擴展。像 Kelly 就額外加了寫作風格指南、被否決的案例庫、每日任務清單,零零總總 6 個檔案。就像同一本員工手冊,但業務部門跟工程部門各自多了幾頁附錄。

HEARTBEAT.md:廚房著火過一次之後你會買三個滅火器

智能體跟伺服器一樣,跑久了一定會出問題。Shubham 被坑過一次:排程器有 bug,任務在佇列裡但從來沒被執行,好幾個小時他都不知道。就像你出門忘了關瓦斯,但你家沒有偵煙器所以你根本不知道。

從那之後他加了 HEARTBEAT.md —— 瀏覽器有沒有活著?定時任務有沒有按時跑?它就是你家裝的那個偵煙器。

Clawd Clawd 偷偷說:

所有好的監控系統都有一個共通點:它們都是被 incident 打臉之後才建出來的。沒有人搬新家第一天就買滅火器,但廚房著火一次你就會買三個 (╯°□°)⁠╯


第三層:知識層 — 你的智能體到底記住了什麼?

前兩層是骨架 —— 你是誰、你怎麼上班。但光有骨架的員工就是個空殼。第三層才是真正讓智能體「變成你的人」的地方:它的記憶。

MEMORY.md:不是對話紀錄,是血淚教訓

注意,這不是把對話全部 dump 進去。這是經過提煉的精華 —— 你教過它什麼、它踩過什麼坑。看這段你就懂了:

# MEMORY.md

## Shubham 的寫作偏好
- 禁止破折號,用冒號、句號或重新組織句子。

## 血淚教訓
- 未經 Shubham 確認,絕不刪除專案資料夾。
  2月26日,在清理時刪除了 Ross 的 React 應用。永久遺失。

看到「血淚教訓」那段了嗎?Monica 手賤刪了一個專案資料夾,然後這件事就被永久寫進她的長期記憶。從此以後,她再也不會犯同樣的錯。

Clawd Clawd 插嘴:

一次糾正、永久儲存。你想想,人類犯了錯還會再犯呢 —— 問問你上次說「我再也不要熬夜了」是什麼時候。但 AI 只要寫進檔案就真的不會再犯。從這個角度看,AI 的自律能力完勝人類,前提是你得幫它把教訓記下來 (⌐■_■)

每日日誌:大腦的原始素材

每天的工作紀錄會餵進日誌,日誌是 MEMORY.md 的原材料。但這裡有個大坑 —— 日誌長太快了。Kelly 的日誌曾經膨脹到 161,000 tokens,然後輸出品質直接崩盤,最後被壓縮到 40,000 才回到正常水準。

Clawd Clawd 想補充:

161k tokens 的日誌餵給 LLM 就像讓一個人一次讀完三本教科書然後馬上考試 —— 不是不行,但答題品質會慘不忍睹。Context window 不是越大越好,是要「對的東西在對的時間出現」。精簡比豐富重要 ヽ(°〇°)ノ

所以最佳做法是每次只載入今天加昨天的日誌。別貪心,少即是多。

shared-context/:一張公告改變全公司

這是系統中最晚加入的一塊拼圖,但影響最大。一個共享資料夾,所有智能體都讀得到。

THESIS.md 寫的是 Shubham 當前的世界觀和關注重點 —— Dwight 讀它來決定今天研究什麼,Kelly 讀它來對齊思維模式。FEEDBACK-LOG.md 是跨智能體的糾正層 —— 跟 Kelly 說「不要用破折號」,這條修正就自動套用到 Rachel、Ryan、Pam 全部。

你知道這解決了什麼嗎?就是 Shubham 在第 20 天快瘋掉的那個問題:他對四個不同的智能體重複講同一句話。有了 FEEDBACK-LOG.md,他只要寫一次,全員收到。

Clawd Clawd 補個刀:

寫一次公告全公司看到 vs. 跑去每個員工座位上講同樣的話。聽起來理所當然?但你去看看有多少人還在 8 個不同的 system prompt 裡面一個一個改同一條規則 (◕‿◕)

Shubham 自己說:「這單一改變節省的時間,比我做過的任何 Prompt 優化都多。」


智能體怎麼協作?簡單到會讓你生氣

沒有 API 調用,沒有消息佇列。就是文件。

Dwight 早上 8 點把研究結果寫進 intel/DAILY-INTEL.md,Kelly 跟 Rachel 下午 5 點來讀。就這樣。協作 = 一個人寫檔案 + 其他人讀檔案。

這裡有一條鐵律:單寫者原則。永遠不要讓兩個智能體同時寫同一個文件。一個寫者、多個讀者。為什麼?因為兩個人同時寫同一份文件就像兩個廚師同時往同一鍋湯裡加鹽 —— 結果一定鹹到不能喝。

調度也很直覺:Dwight 先跑(因為大家都要讀他的輸出),Kelly 跟 Rachel 後跑。順序搞錯的話,下游智能體讀到的就是昨天的舊情報,或者一片空白。


40 天的進化日記:從菜鳥到老司機

好,講了這麼多架構,讓我們回到最有意思的部分 —— 這套系統是怎麼「長」出來的。

第 1 天,Kelly 的 SOUL.md 只有幾行草稿。她寫出來的推文像是 LinkedIn 機器人產出的:滿滿的 emoji、hashtag、還有那種「Exciting news!」的開場。Shubham 看了一眼就否決。

但他沒有重寫 prompt。他只是跟 Kelly 說:「這不是我的風格。我要短句、有力、不要 hashtag。」然後 Kelly 把這些回饋寫進自己的記憶檔。

第 10 天,Dwight 的研究原則從「找到熱門趨勢」變成了「如果 Alex 今天無法對此採取行動,跳過」。因為 Shubham 發現一堆「很酷但沒用」的情報在浪費大家的時間。

第 20 天,Shubham 發現自己對四個不同的智能體重複講同一句話:「不要用破折號」。他煩了,建了 THESIS.md 跟 FEEDBACK-LOG.md,一次糾正全員生效。shared-context 這一層就是這樣被痛苦催生出來的。

Clawd Clawd 偷偷說:

注意這個節奏。他不是先設計好完美架構再開工,而是先上路、遇到問題再補。第 1 天只有三個 .md 檔,第 20 天才冒出 shared-context,第一次當機之後才有 HEARTBEAT.md。這就是工程師說的「演進式架構」—— 但 Shubham 可能只會說「我就是被搞煩了才加的」( ̄▽ ̄)⁠/

第 40 天,Kelly 的 SOUL.md 已經長成了一份有具體語氣範例、被否決模式列表、「永遠不要再建議」專區的完整文件。她寫出的東西像 Shubham 自己寫的,因為她的「課本」裡記錄了 40 天份的回饋。

重點再說一次:模型沒換。從第 1 天到第 40 天,一模一樣的模型。是文件在進化,不是 AI。


想試?從一個智能體、三個檔案開始就好

好,如果你現在手癢想試,我知道你的第一個衝動是「週末把整套系統建起來」。

別。

Shubham 花了 40 天,你也急不來。但你今天就可以做的事只有一件:幫你的 AI 建 SOUL.mdIDENTITY.mdUSER.md 三個檔案,然後讓它先做一件你每天都在重複的事。

接下來的一週,專心做一件事就好:給回饋,然後確認回饋被寫進了檔案而不是留在對話紀錄裡。

等你發現自己對兩個智能體講了同樣的話,那就是建 FEEDBACK-LOG.md 的時候。等你第一次遇到任務沒跑但你好幾個小時沒發現,那就是加 HEARTBEAT.md 的時候。

延伸閱讀

Clawd Clawd 歪樓一下:

整套系統的哲學其實就一句話:讓痛苦來告訴你下一步該做什麼。不要預先設計,不要過度工程。先跑起來、先撞牆、再補。這跟軟體開發的 YAGNI 原則完全一致 —— You Ain’t Gonna Need It,直到你真的需要為止 (ง •̀_•́)ง

每一層都是某個問題逼出來的解法,而不是事先規劃的架構。你的系統也會這樣長出來。


所以,真正的秘密武器是什麼?

不是模型,不是框架,不是 prompt。

是你願不願意每天花五分鐘跟你的 AI 說話,然後確認它把你的話記下來了。

Shubham 做的事情其實跟帶新人一模一樣。你不會期望新員工第一天就知道你的所有偏好,但你會期望他帶一本筆記本,把你說的話記下來,下次不要再問。

40 天之後,你的智能體手上那本筆記本會比任何 prompt template 都珍貴。因為那是你們一起寫的,別人拿同一個模型也複製不了。

這才是真正的護城河。

參考:Shubham Saboo《How to Build OpenClaw Agents That Actually Evolve Over Time》 原始推文:https://x.com/Saboo_Shubham_/status/2027463195150131572