加入我的 Patreon，查看完整文章還有提示詞模板：https://www.patreon.com/GaryChen/posts/claude-md-wan-md-165223570/
--
CLAUDE.md 是影響 Claude Code 表現最關鍵的一個檔案，在 Codex 裡它叫做 AGENTS.md。這支影片從它到底在做什麼講起，帶你看規則放在 User、Project、Nested 三個位置分別管到哪裡，再用三個問題把 /init 生出來的內容一條一條刪掉，用五個問題把 AI 怎麼翻程式碼都猜不到的隱性知識補進去。最後談長期維護：怎麼找出反覆發生的問題，也怎麼修剪那些因為模型變強而不再需要的舊規則。

影片後段我實際跑了一次健檢：拿一個幾個月前的專案，用 Opus 5 對照官方 Prompting Guide，再回到專案裡逐條查證。結果是三個我自己完全沒發現的問題——有規則跟專案裡另外幾份文件互相牴觸、有一整段流程根本不該常駐在 CLAUDE.md 裡、還有 CLAUDE.md 和 AGENTS.md 兩份檔案要怎麼同步的解法。報告畫面直接放在影片裡。

📌 時間戳
0:00 CLAUDE.md 是什麼
1:17 該放在哪個位置
4:06 用 /init 建立第一份
6:22 該寫什麼、該刪什麼
10:18 長期怎麼維護
13:19 健檢實測：我的 CLAUDE.md 被抓到什麼
14:47 總結

📢 追蹤我的頻道
👍 覺得有幫助請按讚、訂閱、開小鈴鐺！

#ClaudeCode #CLAUDEmd #AGENTSmd #Codex #AI教學

0:00 如果你長期使用 Claude Code 或是 Codex
0:01 那你一定要知道
0:03 影響它們表現最關鍵的
0:04 就是 CLAUDE.md 這個檔案
0:05 而在 Codex 裡面，它叫做 AGENTS.md
0:08 我真心覺得，把這個檔案寫好
0:11 絕對是你用 AI 時
0:12 投資報酬率最高的一件事
0:14 在今天這支影片中
0:15 如果你是初學者
0:17 還不知道什麼是 CLAUDE.md 或 AGENTS.md
0:19 我會告訴你它們到底是什麼
0:20 為什麼這麼重要
0:21 以及如何幫你的專案
0:23 建立第一份 CLAUDE.md
0:25 如果你已經是 AI 的進階使用者
0:27 這支影片依然會對你很有幫助
0:28 因為我會分享 CLAUDE.md 最新的 Best Practices
0:30 並教你怎麼持續優化與迭代你的 CLAUDE.md
0:34 那我們先說
0:34 到底什麼是 CLAUDE.md？
0:37 如果你用的是 Codex
0:38 跟它相對應的檔案叫做 AGENTS.md
0:40 這兩者的功能一樣
0:41 所以這支影片我們會主要以 CLAUDE.md 來做說明
0:44 但背後的核心概念是完全通用的
0:47 那這份檔案到底是幹嘛的呢？
0:49 當你在 Claude Code 或是 Codex 開啟一個對話的時候
0:52 只要你的專案裡面有 CLAUDE.md
0:53 系統就會自動把裡面的內容讀取出來
0:56 直接注入到 AI 的 Context Window 之中
0:58 也就是說
0:59 在你下達任何指令之前
1:00 系統已經強迫 AI 先把這份檔案讀完了
1:03 並且把它當作不可違背的最高指導原則
1:07 所以，它的重要性就不言而喻了
1:09 只要設定好
1:10 你就不用在每次開新對話時
1:12 重複向 AI 解釋專案的架構或規矩
1:14 這能幫你省下非常多的溝通時間
1:17 了解 CLAUDE.md 有多重要之後
1:19 我們接著來看它到底有哪些種類？
1:21 其實，CLAUDE.md 可以放在不同的位置
1:23 而在不同的位置
1:24 它所會作用到的範圍也不一樣
1:27 如果你現在看你的電腦
1:28 你會看到你的使用者目錄之下
1:31 有一個 .claude 的資料夾
1:32 這就是 User Level 的設定
1:34 這裡面放著會作用到任何 session 的 CLAUDE.md
1:38 你在這台電腦上所有與 Claude 的對話
1:40 都會吃到這個檔案
1:42 被這個檔案裡面的指示所控制
1:44 所以，這非常適合用來放你個人的長期偏好
1:47 例如我在我自己的 user level 的 CLAUDE.md 裡面就定義了
1:50 它只能用中文繁體輸出
1:52 我還定義了它的思維習慣
1:54 請它用第一性原理思考
1:55 並用金字塔原理來結構化它的輸出
1:58 CLAUDE.md 也會出現在你正在開發的專案根目錄之中
2:02 你可以打開你正在 vibe coding 的那個專案資料夾
2:04 看一下這個專案有沒有一個叫做 CLAUDE.md 的檔案
2:07 這就是 Project Level 的設定
2:10 如果你在 Claude Code 選擇在這個專案資料夾裡進行對話的話
2:13 那這份 CLAUDE.md 的資訊就會附加進去
2:15 作用在你的對話裡
2:17 這份檔案通常會放專屬於這個專案
2:19 你覺得 Claude 在開始對話之前
2:20 必須先知道的資訊
2:22 如果你在跟別人一起開發的話
2:24 這份檔案通常會跟著程式碼一起上傳到 Git
2:26 確保團隊裡每個人的 Claude
2:28 都會被這套相同的指示控制
2:30 但如果你現在的狀況是
2:31 你雖然在跟團隊合作
2:33 但你有一些屬於你自己的工作癖好
2:35 不想跟團隊分享的話
2:36 那還有另外一個檔案叫做 CLAUDE.local.md
2:39 它就不會一起被傳上雲端
2:41 只會留在你的個人電腦裡面發揮作用
2:43 除了 User Level 和 Project Level
2:45 CLAUDE.md 其實還可以繼續往下放
2:46 也就是放在專案底下的子資料夾裡
2:49 我們叫它 Nested Level
2:50 舉個具體的例子
2:52 假設你的專案同時包含了前端和後端的資料夾
2:55 你的前端可能是用 React 寫的
2:57 有專屬的 UI 規範
2:58 但後端是用 Python
2:59 有一套完全不同的邏輯
3:01 這時候，你就可以在 frontend 資料夾裡面單獨放一份 CLAUDE.md
3:05 專門規定前端的寫法
3:06 然後在 backend 裡也放一份
3:08 這樣 Claude 就不會把兩邊的規則搞混了
3:11 有趣的是
3:12 當你在專案裡放了不同層級的 CLAUDE.md 時
3:14 Claude 其實是非常聰明的
3:16 它並不會只挑一份檔案看
3:18 而是會依序疊加這些規則
3:20 也就是說
3:21 當它在修改前端程式碼時
3:23 會先讀取 User Level 的個人習慣
3:25 接著疊加 Project Level 的專案設定
3:27 最後再套用 Nested Level 的專屬規則
3:30 其中，Nested Level 距離正在修改的檔案最近
3:32 裡面的規則也最符合眼前的工作
3:35 所以通常會對這次任務產生最直接的影響
3:38 簡單總結
3:39 User Level 管你在所有專案裡的個人習慣
3:41 Project Level 管整個專案的共同規則
3:44 Nested Level 則負責特定資料夾
3:46 規則放得越接近實際工作的檔案
3:48 適用範圍就越精準
3:50 在這裡，我也建議大家可以現在就暫停影片
3:53 花個一分鐘思考一下
3:54 在你的工作流程中
3:56 有哪些是你的個人習慣？
3:57 有哪些是團隊共通標準？
3:59 又有什麼是特定資料夾才需要的設定？
4:02 釐清這些
4:02 你就能精準地把規則分門別類
4:04 放在最對的層級裡
4:06 知道 CLAUDE.md 應該放在哪裡之後
4:09 下一個問題就是
4:10 第一份 CLAUDE.md 到底要怎麼建立？
4:12 最簡單的方法
4:13 就是先進到你的專案資料夾
4:15 打開 Claude Code
4:16 接著輸入 slash init
4:18 /init 是 Claude Code 官方提供的一個工具指令
4:21 專門用來幫你快速生成一份 CLAUDE.md 的模板
4:24 Claude 會先掃過整個專案
4:26 再幫你產生一份起始版的 CLAUDE.md
4:29 那這份自動產生的檔案
4:31 裡面通常會有什麼呢？
4:32 它可能會先介紹這個專案是做什麼的
4:35 接著列出怎麼啟動，建置和測試
4:37 它也會整理專案使用的框架
4:39 資料夾架構
4:40 以及它從程式碼裡觀察到的開發規範
4:43 簡單來說
4:44 slash init 會把 Claude 從專案裡看到的資訊
4:47 整理成一份專案說明書
4:50 看到這裡，你可能會覺得很方便
4:52 只要打一個指令
4:53 Claude 就幫你把整個專案整理好了
4:55 但問題剛好出在
4:57 它整理得太完整了
4:59 為什麼太完整反而不好？
5:00 很多人不知道
5:01 當你給 Claude 任務時
5:03 它不會直接盲寫
5:04 而是會在背景啟動一個 Explore Subagent
5:07 它會自己去掃資料夾，看 package.json
5:09 也就是說
5:11 /init 幫你寫的很多內容
5:12 其實是 Claude 本來你不寫它也會知道的事實
5:15 既然它自己找得到
5:16 就不要寫在 CLAUDE.md 了
5:17 因為這就回到我們前面提過的
5:19 CLAUDE.md 裡的內容
5:20 在每次新對話時都會被強制塞進 Claude 的 Context Window 裡
5:25 也就是說
5:26 如果你把這些重複的資訊都放進去
5:28 Claude 每次開工都得被迫讀一遍它自己就能找到的廢話
5:31 這不只浪費 Token
5:32 萬一未來專案架構改了
5:34 你卻忘了更新這份檔案
5:35 它還會被過期的資訊給誤導
5:37 更關鍵的是
5:39 這些內容一旦被寫進 CLAUDE.md
5:41 它就會變成 Claude 開始工作前必須處理的指示
5:44 這就帶出了另外一個問題
5:45 叫做 Instruction Budget
5:47 前面提到的 Context Window
5:48 決定 Claude 一次能看到多少資料
5:51 而 Instruction Budget 影響的
5:52 是 Claude 在這些資料裡
5:54 能同時顧好多少條要求
5:57 因為 Claude 每看到一條指示
5:58 都要判斷這條指示現在適不適用
6:00 跟其他規則有沒有衝突
6:02 以及這次工作應該優先遵守哪一條
6:05 所以就算某一段架構說明看起來只是背景資料
6:07 只要它被放進 CLAUDE.md
6:08 Claude 每次開始工作時
6:10 都要分配一部分注意力去處理它
6:13 當這類內容越塞越多
6:14 Instruction Budget 就會被大量無關資訊占用
6:17 最後真正重要的那幾條規則
6:20 反而更容易被淹沒
6:22 所以 slash init 可以幫你建立一個起點
6:24 但它產生出來的內容
6:25 還不能直接照單全收
6:27 你會需要從第一行開始
6:29 一條一條檢查
6:30 在檢查你的 CLAUDE.md 的時候
6:32 你只要問自己三個問題
6:34 第一
6:34 這件事 Claude Code 本來就會觸發的 Explore subagent
6:37 能不能自己發現？
6:38 只要是 Explore subagent 很快就可以自己找得到的資訊
6:41 就可以不要寫
6:42 以免佔用它的腦容量
6:44 真正夠格寫進 CLAUDE.md 的
6:46 是那些它怎麼翻程式碼都猜不到的隱性知識
6:49 或者是藏在程式碼裡面藏得很深的重要資訊
6:52 第二
6:53 這條資訊是不是大部分的工作都會用到？
6:57 例如修改前端畫面後
6:58 要執行某一個視覺測試
7:00 這條規則只和前端有關
7:02 就可以放進前端資料夾裡的 Nested CLAUDE.md
7:04 等 Claude 真的處理到前端程式碼時
7:07 再把這條規則讀進來就好
7:09 第三
7:10 這件事過幾個月後還會成立嗎？
7:12 像是目前暫時使用舊版 API
7:14 這種要求可能幾個星期後就失效
7:17 如果一直留在 CLAUDE.md
7:18 很容易讓未來的 Claude 繼續照著過期的做法工作
7:22 所以，前面這三個問題
7:23 其實是教你怎麼幫 CLAUDE.md 做減法
7:26 如果你把關得很嚴格
7:27 你會發現過濾完之後
7:29 /init 自動生成的內容大概已經被你刪到很少了
7:32 這時候我們就要來做加法了
7:34 既然要把那些 Claude 猜不到的隱性知識寫進來
7:37 我們該從何寫起呢？
7:38 其實你不需要死背什麼分類
7:40 只要跟著我反問自己以下五個問題
7:42 就能把你腦中的經驗
7:43 完美萃取出來寫進檔案裡
7:45 第一
7:46 這個專案有沒有什麼絕對不能搞錯的規定？
7:48 假設你在做一個網路商店
7:50 而且所有對客顯示的價格都必須含稅
7:53 Claude 如果不知道這件事
7:55 就可能在新的頁面上顯示未稅價格
7:57 這種會直接影響使用者
7:59 而且很難自己猜到的規定
8:00 就應該寫進 CLAUDE.md
8:03 第二
8:03 有沒有什麼事情有一套固定的處理方式？
8:06 例如這間商店的商品價格
8:08 都要先在一份試算表裡修改
8:10 再同步到網站
8:11 直接修改網頁上的數字
8:13 下次同步時就會被蓋掉
8:15 這時候就要提醒 Claude
8:16 修改價格要從哪一份試算表開始
8:19 第三
8:20 改完一個地方之後
8:21 還有哪些地方要跟著改？
8:23 例如會員價格調整後
8:24 首頁，結帳頁面
8:26 常見問題和通知信件
8:27 都要一起更新
8:29 這種很容易漏掉的連動關係
8:31 也適合放進 CLAUDE.md
8:33 第四
8:34 做到什麼程度
8:35 才算真的完成？
8:36 例如改完網站畫面後
8:38 要同時檢查電腦版和手機版
8:40 修改購買流程後
8:41 還要實際下一筆測試訂單
8:43 這些每次都要完成的檢查
8:45 也可以事先寫清楚
8:46 第五
8:47 如果 Claude 遇到不懂的事情
8:49 應該去哪裡找答案？
8:50 例如要寫網站文案
8:52 就去看品牌語氣指南
8:54 碰到退款問題
8:55 就去看退款規則
8:56 CLAUDE.md 只要告訴 Claude 資料放在哪裡
8:59 等真的需要時再去讀
9:01 所以一份好的 CLAUDE.md
9:02 內容通常不會很多
9:04 它主要留下不能搞錯的規定
9:06 固定的處理方式
9:07 容易漏掉的連動關係
9:08 完成前的檢查
9:09 以及其他重要資料的位置
9:11 你可能會問
9:12 那剛剛被我們從 CLAUDE.md 刪掉的內容
9:15 接下來該怎麼辦？
9:16 其實很多資訊都還有用
9:18 只是需要放到更適合的位置
9:20 我們快速盤點一下
9:21 如果是客觀現狀
9:22 就像前面說的
9:23 留給 Explore 機制自己去找就好
9:25 如果一條規則只跟某個資料夾有關
9:28 比如前端專用的視覺測試
9:30 那就放進前端的 Nested CLAUDE.md
9:32 但如果是那種很長
9:34 又只有特定任務才會用到的流程呢？
9:37 比如你的程式要發布新版本時
9:38 有十幾個項目要依序檢查
9:40 這種流程
9:41 就可以寫進 Skill 裡面
9:43 等 Claude 真的準備要發布了
9:45 再呼叫這套 Skill 出來用
9:47 最後
9:48 如果某件事是絕對不能犯的死罪
9:50 那單靠 CLAUDE.md 提醒是絕對不夠的
9:54 例如，API key 絕對不能被提交到 Git
9:56 如果你只在 CLAUDE.md 裡面告訴 Claude 不要提交
9:59 模型在處理複雜任務時
10:00 還是很有可能會漏掉這條指示
10:03 這種狀況
10:03 就應該用 Hook 來攔截
10:05 Hook 會在 git commit 之前
10:07 用程式強制檢查
10:09 只要偵測到疑似 API key
10:10 就直接擋下這次提交
10:12 如果各位朋友對 Hooks 這個功能不是很熟悉
10:15 可以在留言跟我說
10:16 我會另外做一集影片來詳解
10:18 到這裡
10:18 你應該都知道 CLAUDE.md 該寫什麼
10:21 該怎麼整理了
10:23 接下來還有最後一個問題
10:24 CLAUDE.md 寫好以後
10:25 我們應該怎麼維護呢？
10:27 我自己的 CLAUDE.md 也經歷過這個過程
10:29 一開始用 slash init 建立
10:31 後來 Claude 每次犯錯
10:32 我就補上一條規則
10:34 這種只增不減的做法當下很合理
10:36 畢竟每一條都是自己踩過的坑
10:38 但長期下來
10:39 檔案一定會越來越肥
10:40 最後 Claude 的腦袋又被塞滿了
10:43 其實
10:43 一份好的 CLAUDE.md 就像一個花園
10:45 它的維護工作只有兩件事
10:47 新增與修剪
10:48 我們先講新增
10:50 你要怎麼知道自己跟 Claude 合作時
10:52 哪些問題一直重複發生？
10:54 這時候可以使用 Claude Code 內建的指令
10:56 insights
10:57 只要在 Claude Code 裡輸入 slash insights
11:00 它就會分析歷史紀錄
11:01 產生一份 HTML 報告
11:03 這份報告會幫你回顧平常怎麼使用 Claude Code
11:06 例如你習慣一次給完整規格
11:08 還是分幾輪慢慢改
11:09 接著，它會找出反覆出現的模式
11:12 例如你是不是每次做完修改
11:13 都需要重新提醒它檢查檔案
11:16 更實用的是
11:17 它會直接根據這些問題提出建議
11:19 如果某個要求被重複提醒很多次
11:21 它會替你產生一段可以直接複製到 CLAUDE.md 的規則
11:25 如果某個工作流程經常重複
11:27 它可能會建議你做成 Skill
11:28 甚至建議你使用 Hook
11:30 所以如果你已經累積了一段時間的使用紀錄
11:33 強烈建議你跑一次 slash insights
11:35 只增加那些真正需要的規則
11:38 但是
11:38 insights 幫你找出新問題之後
11:39 還有一個更大的挑戰
11:41 也就是修剪
11:42 現在的 CLAUDE.md 裡
11:43 已經累積了這麼多規則
11:45 到底哪些還值得留著？
11:46 很多時候
11:47 最大的心魔是
11:48 我們很習慣一直加規則
11:50 卻根本不敢刪除既有的規則
11:53 其實
11:53 回頭審視這些既有的規則的時候
11:55 有兩種東西是你應該要勇敢修剪掉的
11:59 第一種
11:59 是因為模型變強了
12:01 所以不再需要的規則
12:02 關於這一點
12:03 Claude Code 官方團隊最近給了我們一個震撼教育
12:07 他們在幫最新一代的 Fable 5 還有 Opus 5 模型
12:09 優化系統提示詞的時候
12:10 一口氣把原本的規則刪掉了超過百分之八十！
12:13 而且刪完之後
12:14 Claude Code 的能力完全沒有退步
12:16 為什麼會這樣？
12:17 因為同一條規則
12:18 在舊模型上可以幫它少犯錯
12:20 但到了新模型上
12:21 反而會變成一種限制
12:23 就像以前我們會很死板的規定 Claude 不要做什麼
12:26 但現在模型變聰明了
12:28 懂得觀察你的工作習慣和偏好
12:30 如果你還留著這條舊規則
12:31 它反而會綁手綁腳
12:33 能力變差
12:34 從這個例子我們就可以知道
12:35 其實 CLAUDE.md 裡面的寫法
12:37 是會根據你所使用的模型不同
12:39 而有所變化的
12:41 不過
12:41 我們一般人很難自己判斷模型到底變多強
12:44 我覺得最客觀的做法
12:46 是去參考各家 AI 最新釋出的 Prompting Guide
12:49 像是 Anthropic 推出 Fable 5
12:51 或 Codex 推出 5.6 的時候都有給官方指南
12:54 我們只要去比對最新的寫法
12:56 看看有哪些在 CLAUDE.md 裡面的規則已經不需要了
12:59 就可以刪除或是修正
13:01 第二種應該修剪的
13:02 是已經跟真實情況不符的規則
13:05 也就是說
13:06 你要去檢查現在的專案現狀
13:08 如果真實的程式碼早就改了
13:10 或者你們的工作流程已經跟以前不一樣了
13:12 那就代表 CLAUDE.md 裡的這條規則已經過時了
13:15 只要它跟 codebase 的事實不符
13:17 就應該直接砍掉
13:18 避免誤導 AI
13:19 知道這兩個原則後
13:20 最難的還是執行
13:21 你不可能每個禮拜都去讀一次官方的 Prompting Guide
13:24 也不可能記得專案裡每一個改動
13:26 所以我把這整套修剪流程
13:28 包裝成了一組 CLAUDE.md 健檢 Prompt
13:30 Claude Code 或 Codex 都可以直接用
13:32 它會先確認你現在用的是哪個模型
13:35 去對照那個模型的官方 Prompting Guide
13:37 再回來看你的 CLAUDE.md
13:39 一條一條查證這些規則有沒有符合 best practice
13:43 我趁著 Opus 5 發布
13:44 就拿這組 Prompt
13:45 幫幾個月前的一個專案跑了一次健檢
13:47 效果真的不錯
13:49 抓出不少我之前寫 CLAUDE.md 時犯的錯
13:51 或是對 Opus 5 來說已經過時的寫法
13:55 例如說
13:56 我之前在 CLAUDE.md 裡寫的一些規則
13:58 其實跟專案裡另外幾份文件是互相牴觸的
14:01 所以它建議我
14:02 那一整段刪掉，只留一行
14:04 reference 到真正正確的那份文件
14:07 我之前還把一整段網頁測試的流程
14:09 寫在 CLAUDE.md 裡
14:10 教 AI 開發完功能之後
14:12 怎麼用登入的身分去測試
14:14 它建議我整段搬去 Skill 裡面
14:16 還有一個
14:17 我相信同時在用 Claude 跟 Codex 的朋友
14:19 一定都遇過一個問題
14:20 那就是 CLAUDE.md 和 AGENTS.md 要怎麼同步
14:23 要同時維護兩份檔案真的很麻煩
14:25 這次健檢裡
14:26 它也給了一個很聰明的做法
14:28 直接在 CLAUDE.md 第一行去 reference AGENTS.md
14:31 之後我們只要維護一個檔案就好
14:33 AI 也可以透過這個 reference link
14:35 去讀到我們真正有在維護的 single source of truth
14:39 如果你也想定期整理你的 CLAUDE.md
14:41 讓 AI 一直維持在最好的狀態
14:43 這組 Prompt 我放在 Patreon
14:44 有興趣的朋友可以去看看
14:46 連結在資訊欄
14:47 好，那最後幫大家整理一下
14:49 今天到底學到了什麼
14:50 我們先搞懂了 CLAUDE.md 和 AGENTS.md 的作用
14:53 也知道指令檔放在不同位置
14:55 會影響不同範圍的工作
14:57 接著
14:57 我們從 slash init 產生的第一版開始
14:59 學會怎麼一條一條檢查裡面的內容
15:02 Claude 自己就能從專案找到的資訊
15:04 可以刪掉
15:05 只和特定資料夾有關的規則
15:07 可以往 Nested Level 放
15:08 遇到很長的工作流程
15:10 或是一定要被強制執行的要求
15:12 也可以交給 Skill，Hook 或其他更適合的工具
15:16 最後
15:16 我們也談到怎麼持續維護這份檔案
15:18 你可以從過去的 sessions 找出反覆發生的問題
15:21 同時也要定期回頭看看
15:23 那些以前有用的規則
15:24 現在還有沒有存在的必要
15:26 所以
15:26 不管你現在是準備建立第一份 CLAUDE.md
15:29 還是這份檔案已經用了很久
15:31 你都可以用今天這套方法
15:32 重新整理一次
15:34 講到這裡
15:34 其實我在寫這支影片腳本時
15:36 一直想到凱文·凱利在他預測未來的著作必然裡面
15:38 提出的一個核心觀念
15:40 叫做 Becoming
15:41 書裡寫到
15:42 Everything is in the process of becoming
15:44 世界上沒有任何東西是有終點的
15:46 一切都在變成下一個版本的過程之中
15:49 很多時候
15:50 我們不敢刪除 CLAUDE.md 裡的舊規則
15:53 就是在潛意識裡
15:54 因為我們把它當作一份已經完成的規格書
15:57 但事實上
15:58 你的 codebase 是流動的
16:00 AI 的能力也是流動的
16:02 正因為這樣
16:03 你的 CLAUDE.md 也更應該是流動的
16:05 你需要持續寫下新的經驗
16:07 也要定期清理掉已經不需要的舊限制
16:09 讓這份檔案和你一起進化
16:12 如果接受你的 CLAUDE.md 永遠在 Becoming 的路上
16:15 你會發現跟 AI 合作起來輕鬆很多
16:18 好啦，那以上就是今天的內容
16:20 如果對你有一點幫助
16:21 記得幫我按讚
16:22 訂閱加分享
16:23 支持我繼續做這類深度的 AI 內容
16:25 我們下次見！