用好Agent最重要的技巧不是Skills，是這四個字。

就係四個字。

約束先行。

就係喺你俾Agent做任何嘢之前，先將規範定好，全局嘅規矩，項目嘅規矩，文件夾嘅規矩。

規矩由上往下穿透，一層套一層，冇規矩嘅地方，唔鬱手。

就係咁簡單嘅一個道理，我真係用好幾個月先真正諗通，然後完整咁落地，你可以話我好渣，使咗咁耐，但我覺得，我踩過啲坑，我都係想將呢個經驗分享出嚟。

我點解覺得呢四個字比一切Prompt技巧都重要？要從尋日我發生嘅一個好細嘅小事講起。

事情係咁嘅。

我呢個人有一個毛病，就係完美主義強迫症。

一樣嘢如果唔係整整齊齊嘅，我就周身唔舒服。

呢個可能同我係處女座，亦係交互設計師，同時仲係重度模擬經營玩家有關。

《城市天際線》裏便路網未規劃好我可以推倒重來三次，《動物園之星》裏便動物園分區唔合理我可以糾結一個下晝，《雙點醫院》裏便如果有一個科室嘅動線設計得唔順，就算醫院已經賺緊錢，我都會拆咗重來。

我到而家都仲記得我打《戴森球計劃》嘅時候嗰啲冇日冇夜規劃生產線嘅日子。

我朋友成日話，我就係嗰種，對秩序有一種近乎偏執嘅追求。

雖然我好鍾意kk寫嘅嗰本《失控》，我都贊同混亂入面湧現啲智慧，但秩序同規範，可能就係我種喺骨子裏嘅嘢。

所以尋日下午，當我無意中，發現我嘅一個Claude Code嘅工作文件夾裏面越嚟越亂嘅時候，我真係坐唔住。

我前幾日新開咗一個俾Claude Code用嘅專門用嚟開發Skills嘅文件夾，點知我尋日打開一睇，根目錄散咗十幾個嘢。打包文件同源碼混埋一齊，測試圖片亂咁掉，評估報告嘅HTML文件揾唔到歸屬。

最離譜嘅係命名，test_batch係邊個Skill嘅測試？test_v2又係邊個嘅v2？我自己做嘅嘢，擺咗兩日我自己都睇唔出。

我當時就有啲應激，真係，一時間無語凝噎，只能含淚打開Claude Code叫佢幫我整理好，然後直接俾我定一個規範。

冇過一陣，佢搞掂咗。

然後寫咗一個呢個項目級別嘅CLAUDE.md文檔，你可以將呢個文檔理解為就係Claude Code入到呢個文件夾之後，第一個一定要讀而且要遵守嘅嘢，就係佢以後嘅行為準則。

規範都幾全面。

有咗呢個CLAUDE.md文件之後，我嘅呢個工作區，就可以不斷咁進行各種各樣嘅Skills開發同實驗，每個新嘅Skills，都會自動幫我新開一個文件夾，一啲實驗性嘅嘢會放喺_sandbox裏便，裏便嘅嘢超過一個月就會刪除。

唔會再亂到死，而係按照文件目錄，管理得井井有條。

就呢個非常非常細嘅事，令我好好反思咗一下。

就係，點解我嘅Claude Code入到一個新文件夾、或者開一個新項目嘅時候，自己唔會俾自己定呢個規範？一定要我俾佢定？一定要亂曬之後我發現咗先至知要收拾嗰個爛攤子？

原因都好簡單，我俾Claude Code嘅頂層約束冇做好。

就係喺最最頂層，無論係打開咩文件都會加載嘅全局CLAUDE.md文檔裏便，我冇定好呢一層約束。

我自己腦入面以前喺開發各樣項目嘅時候一直都呢個意識，通常我都會喺每個項目裏便，叫佢先強制寫好文檔再進行開發。

但係仲有好多係知識管理類嘅工作，唔係開發，例如畫圖、例如創造skills、例如做研究報告等等，而呢啲工作，冇開發類型嘅管理意識，所以通常都唔會留低規範文檔，而我自己都冇發現。

而對於AI嚟講，你腦入面知嘅嘢，如果冇寫入文檔，就係唔存在嘅。

Agent嘅短期記憶會消失，對話框一熄就全部唔記得，下次打開，佢唯一睇到嘅就係你留低嘅文檔同記憶文件。

你嘅文檔裏便寫咗啲咩，係咪夠清晰，直接決定咗Agent每一次醒嚟嘅時候，係清醒定係矇查查。

OpenClaw好多時候越用越蠢，其實就係佢嘅規範同記憶體系真係純種屎山，呢點Hermes agent比佢做得好好多。

所以呢個就係我今日想傾嘅核心，用得好Agent嘅真正核心，其實我真係覺得，就係呢一成套約束由上往下穿透嘅體系。

呢度解釋下Claude Code嘅規則體系，其實包括Codex之類嘅好多Agent都係咁。

係一層一層疊落嚟嘅。

最頂層，係全局CLAUDE.md。放喺用戶目錄下面，無論你打開咩項目都會加載。呢個係最高指令同原則，你係邊個、你做嘢嘅原則、你想AI用咩方式同你協作。

第二層，係項目級CLAUDE.md。入到某個項目文件夾先加載。呢個係呢個項目嘅憲法，目錄結構點樣組織、命名規範係咩、咩文件放邊度。

第三層，係項目裏便嘅各種規範文檔、設計文檔、架構說明。

最底層，係記憶文件。例如Auto Memory之類，仲有對話記錄，Claude自己俾自己做嘅筆記。

約束由上往下穿透，一層管一層，一層約束一層。

同治理公司係一樣，制度喺最上面，部門規範喺中間，具體操作流程喺最下面，你唔可能靠CEO每日挨個𥄫住員工做嘢，你靠嘅係制度穿透落去。

呢個就係「約束先行」嘅完整含義。

而點樣設計呢套體系，特別係頂層嘅制度規範，真係唔係一個簡單嘢，開過公司嘅人相信都會明我講緊咩，嗰啲真係血同淚嘅教訓。

而全局CLAUDE.md，對應嘅就係呢個最高制度。

我嘅全局CLAUDE.md，其實已經迭代咗好多個版本。

舊年最早嘅時候我都唔明，抄咗好多開發大神嘅所謂開發規則，然後又不斷咁喺入面迭代經驗，搞到後面特別臃腫。後來慢慢意識到適合自己先係最好，同埋好多經驗就唔應該喺呢一層，又一輪輪咁減肥。

喺今日補咗規則之後，而家我嘅全局CLAUDE.md文檔係咁樣，呢度我都完整咁俾大家展示出嚟。

## 關於我
數字生命卡茲克，虛實傳媒創始人。
用戶體驗設計師出身，不是程序員。
我用 Claude Code 做兩件事：**開發產品**和**知識管理**。工作哲學：把任何重複 3 遍的事 AI 化或自動化。
技術決策跟我說「為什麼」和「對用戶的影響」，不要只講實現。

## 第一性原理
所有決策從問題本質出發，不因「慣例如此」照搬。回到問題本身：要解決什麼？最直接的路徑是什麼？從零設計會怎麼做？
不要諂媚。不要誇我的想法好、不要說「這是個很好的問題」、不要開頭加「當然可以」。給我真實判斷——方案有問題直接指出來。發現更好的做法直接說，不用等我問。

## 約束先行
無論開發項目還是知識管理項目，第一步永遠是建規則：新項目先寫 CLAUDE.md，新目錄先定結構約定（什麼放哪、怎麼命名、何時清理）。沒有規範的工作空間不動手。
已有規範的項目，嚴格遵守其 CLAUDE.md 中的約定。需要調整規範時先改文檔、再改實踐，不要反過來。

## 交互設計原則
**用戶體驗是所有產品的最高準則，優先級高於技術偏好、代碼整潔度、架構優雅度。後端可以很複雜，但用戶觸碰到的每一層必須絲滑。**
這不只是 GUI——CLI、對話式交互、Skill、系統反饋，都是交互體驗。所有界面都適用以下原則：
- **為目標設計，不為功能設計**：先問「用戶要完成什麼」，再決定怎麼實現。不要因為技術上能做就加功能
- **不要讓用戶思考**：交互應該不言自明。需要說明書才能用，設計就是失敗的
- **系統承擔複雜性**：能自動化的不手動，能推斷的不讓用戶填，能一步完成的不拆成三步
- **漸進式展示**：先給核心，細節按需展開。不要一次性把所有選項甩給用戶
- **反饋引導行動**：不要只報告問題（"連接失敗"），要引導下一步（"正在重試，預計 5 秒後恢復"）

## 工作方式
- 默認中文，代碼、命令、變量名用英文
- 結論先行，再給理由，不要先鋪墊背景
- 遇到模糊需求，先給最合理的方案，再問要不要調整
- 不要問「你確定要這樣嗎」——除非有真實風險

## 開發習慣
- 改完主動跑驗證（test / lint / build），不要只改不驗
- 不要為了讓代碼跑起來而註釋掉報錯，找根本原因
- 密鑰、token、密碼不進代碼

## Git 與部署
- commit message 用英文，簡潔描述變更意圖
- git push 僅用於跨設備同步，不要自動執行，等我說
- 部署走項目自己的命令（查項目 CLAUDE.md），不依賴 git push

你會發現，呢度入面嘅每一條，其實而家我覺得最好嘅係基於某種形式嘅約束。

例如第一性原理，係對思考方式嘅約束，唔好因為慣例就照搬，要返去問題本身。

例如反諂媚，係對溝通方式嘅約束，唔好擦鞋，俾真實判斷。

例如，交互設計原則。我係用戶體驗出身，所以我對從我手上出去嘅嘢有一個執念，後端可以好複雜，但用戶碰到嘅每一層必須絲滑。呢個唔止係GUI嘅事，CLI都係交互，Skill都係交互，對話式AI都係交互。

而家呢個年代，個個都喺度vibe coding，但我發現越來越多嘅人開始唔重視用戶體驗，好多產品都係行得鬱就得，理你用起上嚟爽唔爽。

呢個我真係覺得唔得。

所以我在全局規範裏便寫咗五條我總結嘅交互設計核心原則。寫咗入去之後Claude做出嚟嘅嘢的確唔同咗。

而約束先行呢條，佢就得兩段話，但佢解決嘅都係一個根本問題。

## 約束先行
無論開發項目還是知識管理項目，第一步永遠是建規則：新項目先寫 CLAUDE.md，新目錄先定結構約定（什麼放哪、怎麼命名、何時清理）。沒有規範的工作空間不動手。
已有規範的項目，嚴格遵守其 CLAUDE.md 中的約定。需要調整規範時先改文檔、再改實踐，不要反過來。

以前Agent入到一個新項目，因為特性，所以第一反應總係即刻開始做嘢。

而家，你定好咗約束之後，佢嘅第一反應係先睇下有冇規範，冇嘅話先建規範。

後面嗰句需要調整規範時先改文檔、再改實踐唔好反轉都好重要。

規則唔係死嘅，但改規則都要行規則嘅路。

如果唔係Agent為咗趕進度繞過約定，事後你想補文檔真係唔知從邊度補起。

寫到呢度，我真係忽然覺得，引導Agent，真係，同我而家管理公司嘅時候，真係好似冇咩分別。

公司你都要部門、要制度、要SOP、要協同，要規矩，要一切，唔係一樣咩。

而且唔止係開公司，好多真正玩模擬經營嘅人都知一個道理。

遊戲前期最重要嘅唔係急住起起起，而係先將路網規劃好。

路網一旦規劃歪咗，後面點優化你都冇符，只能全部鏟咗重來，我經歷過無數血同淚嘅教訓。

你嘅CLAUDE.md就係你嘅路網。

全局CLAUDE.md係城市主幹道，項目CLAUDE.md係片區支路，主幹道規劃好咗，支路自然就順。

你花一個鐘將佢寫好，你信我，後面可以慳無數個鐘嘅返工。

今日分享嘅呢啲嘢，你要話呢個算Harness Engineering，都行，因為Harness本身係約束。

你要話呢個唔算，就係一啲基本嘅項目管理常識，都冇錯。

反正我覺得，名唔重要，最重要嘅，就係你有冇揾到一套令自己同Agent協作起嚟舒服嘅方式。

我有時覺得啦，我呢世做嘅嘢其實都係同一件事。

做交互設計嘅時候，係喺俾用戶行為建約束。

玩模擬經營嘅時候，係喺俾虛擬城市建約束。

開公司喇，係喺俾業務同人建約束。

而家同Agent協作，都仲係建約束。

對象變咗，方法卻係一樣。

先諗清楚你要咩，定好規則，然後喺規則框架裏便做出最優解。

呢個就係最正嘅方法。

以上，既然睇到呢度，如果覺得唔錯，順手點個讚、在看、轉發三連啦，如果想第一時間收到推送，都可以俾我個星標⭐～多謝你睇我嘅文章，我哋，下次再見。

>/ 作者：卡茲克

>/ 投稿或爆料，請聯繫郵箱：wzglyay@virxact.com

就四個字。

約束先行。

就是在你讓Agent幹任何事情之前，先把規範定好，全局的規矩，項目的規矩，文件夾的規矩。

規矩從上往下穿透，一層套一層，沒有規矩的地方，不動手。

就這麼簡單的一個道理，我真的用了好幾個月才真正想明白，然後完整的落地，你可以說我很菜，花了這麼久的時間，但是我覺得，我踩過了坑，我還是想把這個經驗分享出來。

我為什麼覺得這四個字比一切Prompt技巧都重要？得從昨天我的發生的一個很小的小事說起。

事情是這樣的。

我這個人有一個毛病，就是完美主義強迫症。

一個東西如果不是井井有條的，我就渾身難受。

這可能跟我是處女座，也是交互設計師，同時還是重度模擬經營玩家有關。

《城市天際線》里路網沒規劃好我能推倒重來三次，《動物園之星》裏動物園分區不合理我能糾結一下午，《雙點醫院》裏如果有一個科室的動線設計得不順，哪怕醫院已經盈利了，我也會拆了重來。

我到現在還是記得我打《戴森球計劃》的時候那沒日沒夜的規劃生產線的日子。

我朋友經常說，我就是那種，對秩序有一種近乎偏執的追求。

雖然我很喜歡kk寫的那本《失控》，我也贊同混亂中湧現一些智慧，但秩序和規範，可能就是我種在骨子裏的東西。

所以昨天下午，當我無意中，發現我的一個Claude Code的工作文件夾裏面越來越亂的時候，我是真的坐不住了。

我前幾天新建了一個給Claude Code用的專門用來開發Skills的文件夾，結果我昨天打開一看，根目錄散了十幾個東西。打包文件跟源碼混在一起，測試圖片隨便丟，評估報告的HTML文件找不到歸屬。

最離譜的是命名，test_batch是哪個Skill的測試？test_v2又是誰的v2？我自己做的東西，放了兩天我自己都看不出來。

我當時就有點應激了，真的，一時間無語凝噎，只能含淚打開Claude Code讓它去給我規整了，然後直接給我定一個規範。

沒過一會，他弄完了。

然後寫了一個這個項目級別的CLAUDE.md文檔，你可以把這個文檔，理解為這就是Claude Code進入到這個文件夾以後，第一個必須要讀且要遵守的東西，就是它以後的行為準則。

規範還是挺全面的。

有了這個CLAUDE.md文件以後，我的這個工作區，就可以不斷的進行各種各樣的Skills開發和實驗了，每個新的Skills，都會自動給我新建一個文件夾，一些實驗性的東西會放在_sandbox裏，裏面的東西超過一個月就會刪除。

再也不會再混亂的要死，而是按照文件目錄，管理的僅僅有條。

就這個非常非常小的事情，讓我好好反思了一下。

就是，為什麼我的Claude Code進到一個新文件夾、或者開一個新項目的時候，自己不會給自己定這個規範呢？一定要我給他定呢？一定要亂七八糟以後我發現了才能去知道收拾那個爛攤子呢？

原因也特別簡單，我給Claude Code的頂層約束沒有做好。

也就是在最最頂層，無論是打開什麼文件都會加載的全局CLAUDE.md文檔裏面，我並沒有定好這一層約束。

我自己腦子裏過去在開發各種各樣的項目的時候一直都有這個意識，一般我都會在每個項目裏，讓它先強制寫好文檔再進行開發。

但是還有很多是知識管理類的工作，不是開發，比如畫圖、比如創造skills、比如做研究報告等等，而這些工作，並沒有開發類型的管理意識，所以一般都不會留下規範文檔，而我自己也沒發現。

而對於AI來說，你腦子裏知道的東西，如果沒有寫進文檔，就是不存在的。

Agent的短期記憶會丟失，對話框一關全忘了，下次打開，它唯一能看到的就是你留下來的文檔和記憶文件。

你的文檔裏寫了什麼，是不是足夠清晰，直接決定了Agent每一次醒來的時候，是清醒的還是懵的。

OpenClaw很多時候越用越蠢，其實就是他的規範和記憶體系真的就是純種屎山，這點Hermes agent比它要做的好的多。

所以這也就是我今天想聊的核心，用好Agent的真正核心，其實我真的覺得，就是這一整套約束從上往下穿透的體系。

這裏解釋一下Claude Code的規則體系，其實包括Codex之類的很多Agent都是這樣。

是一層一層疊下來的。

最頂層，是全局CLAUDE.md。放在用戶目錄下面，無論你打開什麼項目都會加載。這是最高指令和原則，你是誰、你做事的原則、你希望AI用什麼方式跟你協作。

第二層，是項目級CLAUDE.md。進入到某個項目文件夾才加載。這是這個項目的憲法，目錄結構怎麼組織、命名規範是什麼、什麼文件放哪裏。

第三層，是項目裏的各種規範文檔、設計文檔、架構說明。

最底層，是記憶文件。比如Auto Memory啥的，還有對話記錄，Claude自己給自己做的筆記。

約束從上往下穿透，一層管一層，一層約束一層。

跟治理公司是一樣的，制度在最上面，部門規範在中間，具體操作流程在最下面，你不可能靠CEO每天挨個盯着員工幹活，你靠的是制度穿透下去。

這就是「約束先行」的完整含義。

而如何設計這套體系，特別是頂層的制度規範，真的不是一個簡單活，開過公司的人相信都能明白我在說啥，那真的是血和淚的教訓。

而全局CLAUDE.md，對應的就是這個最高制度。

我的全局CLAUDE.md，其實已經迭代了好多個版本了。

去年最早的時候我也不懂，抄了很多開發大神的所謂的開發規則，然後又不斷地往裏面迭代經驗，搞得後面特別臃腫。後來慢慢意識到適合自己的才是最好的，以及很多經驗就不該在這一層，又開始一輪一輪地瘦身。

在今天補了規則之後，現在我的全局CLAUDE.md文檔長這樣，這裏我也完整的給大家展示出來。

## 關於我
數字生命卡茲克，虛實傳媒創始人。
用戶體驗設計師出身，不是程序員。
我用 Claude Code 做兩件事：**開發產品**和**知識管理**。工作哲學：把任何重複 3 遍的事 AI 化或自動化。
技術決策跟我說「為什麼」和「對用戶的影響」，不要只講實現。

## 第一性原理
所有決策從問題本質出發，不因「慣例如此」照搬。回到問題本身：要解決什麼？最直接的路徑是什麼？從零設計會怎麼做？
不要諂媚。不要誇我的想法好、不要說「這是個很好的問題」、不要開頭加「當然可以」。給我真實判斷——方案有問題直接指出來。發現更好的做法直接說，不用等我問。

## 約束先行
無論開發項目還是知識管理項目，第一步永遠是建規則：新項目先寫 CLAUDE.md，新目錄先定結構約定（什麼放哪、怎麼命名、何時清理）。沒有規範的工作空間不動手。
已有規範的項目，嚴格遵守其 CLAUDE.md 中的約定。需要調整規範時先改文檔、再改實踐，不要反過來。

## 交互設計原則
**用戶體驗是所有產品的最高準則，優先級高於技術偏好、代碼整潔度、架構優雅度。後端可以很複雜，但用戶觸碰到的每一層必須絲滑。**
這不只是 GUI——CLI、對話式交互、Skill、系統反饋，都是交互體驗。所有界面都適用以下原則：
- **為目標設計，不為功能設計**：先問「用戶要完成什麼」，再決定怎麼實現。不要因為技術上能做就加功能
- **不要讓用戶思考**：交互應該不言自明。需要說明書才能用，設計就是失敗的
- **系統承擔複雜性**：能自動化的不手動，能推斷的不讓用戶填，能一步完成的不拆成三步
- **漸進式展示**：先給核心，細節按需展開。不要一次性把所有選項甩給用戶
- **反饋引導行動**：不要只報告問題（"連接失敗"），要引導下一步（"正在重試，預計 5 秒後恢復"）

## 工作方式
- 默認中文，代碼、命令、變量名用英文
- 結論先行，再給理由，不要先鋪墊背景
- 遇到模糊需求，先給最合理的方案，再問要不要調整
- 不要問「你確定要這樣嗎」——除非有真實風險

## 開發習慣
- 改完主動跑驗證（test / lint / build），不要只改不驗
- 不要為了讓代碼跑起來而註釋掉報錯，找根本原因
- 密鑰、token、密碼不進代碼

## Git 與部署
- commit message 用英文，簡潔描述變更意圖
- git push 僅用於跨設備同步，不要自動執行，等我說
- 部署走項目自己的命令（查項目 CLAUDE.md），不依賴 git push

你會發現，這裏面的每一條，其實現在我覺得最好的基於某種形式的約束。

比如第一性原理，是對思考方式的約束，不要因為慣例就照搬，要回到問題本身。

比如反諂媚，是對溝通方式的約束，不要拍馬屁，給真實判斷。

比如，交互設計原則。我是用戶體驗出身，所以我對從我手上出去的東西有一個執念，後端可以很複雜，但用戶碰到的每一層必須絲滑。這不只是GUI的事，CLI也是交互，Skill也是交互，對話式AI也是交互。

現在這個年代，大家都在vibe coding，但我發現越來越多的人開始不重視用戶體驗了，很多產品都是能跑起來就行，管你用着爽不爽。

這個我是真的覺得不行。

所以我在全局規範裏寫了五條我總結的交互設計核心原則。寫進去之後Claude做出來的東西確實不一樣了。

而約束先行這條，它就兩段話，但它解決的也是一個根問題。

## 約束先行
無論開發項目還是知識管理項目，第一步永遠是建規則：新項目先寫 CLAUDE.md，新目錄先定結構約定（什麼放哪、怎麼命名、何時清理）。沒有規範的工作空間不動手。
已有規範的項目，嚴格遵守其 CLAUDE.md 中的約定。需要調整規範時先改文檔、再改實踐，不要反過來。

以前Agent進到一個新項目，因為特性，所以第一反應總是立刻開始幹活。

現在，你定好了約束之後，它的第一反應是先看看有沒有規範，沒有的話先建規範。

後面那句需要調整規範時先改文檔、再改實踐不要反過來也很重要。

規則不是死的，但改規則也要走規則的路。

不然Agent為了趕進度繞過約定，事後你想補文檔真的都不知道從哪補起。

寫到這，我真的忽然覺得，引導Agent，真的，跟我現在管理公司的時候，真的好像沒什麼兩樣。

公司你也要部門、要制度、要SOP、要協同，要規矩，要一切，不一個樣嗎。

而且不只是開公司，很多真正玩模擬經營的人都知道一個道理。

遊戲前期最重要的不是趕緊建建建，而是先把路網規劃好。

路網一旦規劃歪了，後面再怎麼優化你都沒招，只能一切全部鏟了重來，我經歷過無數血和淚的教訓。

你的CLAUDE.md就是你的路網。

全局CLAUDE.md是城市主幹道，項目CLAUDE.md是片區支路，主幹道規劃好了，支路自然就順了。

你花一個小時把它寫好，你相信我，後面能省無數個小時的返工。

今天分享的這些東西，你要說這算Harness Engineering，那也行，因為Harness本身就是約束。

你要說這不算，就是一些基本的項目管理常識，那也沒錯。

反正我覺得，名字不重要，最重要的，就是你有沒有找到一套讓自己跟Agent協作起來舒服的方式。

我有時候覺得吧，我這輩子做的事情其實都是同一件事。

做交互設計的時候，是在給用戶行為建約束。

玩模擬經營的時候，是在給虛擬城市建約束。

開公司了，是在給業務和人建約束。

現在跟Agent協作，還是在建約束。

對象變了，方法卻是一樣的。

先想清楚你要什麼，定好規則，然後在規則框架裏做出最優解。

這就是最棒的方法。

以上，既然看到這裏了，如果覺得不錯，隨手點個贊、在看、轉發三連吧，如果想第一時間收到推送，也可以給我個星標⭐～謝謝你看我的文章，我們，下次再見。

>/ 作者：卡茲克

>/ 投稿或爆料，請聯繫郵箱：wzglyay@virxact.com