90%的人用Claude Code都踩了這個坑，特別是第3個
整理版優先睇
用Claude Code要當心對話上下文污染，4個技巧大幅提升代碼質量
呢篇文章係軍哥分享佢用Claude Code嘅親身經驗。佢一開始覺得呢個AI工具好勁，可以自動寫代碼同改bug，但後來有一次加用戶權限模塊嗰陣，佢發現Claude Code寫嘅代碼風格同之前完全唔一致，變量命名由camelCase變咗snake_case，錯誤處理都唔同曬，甚至邏輯衝突。佢先至明白，原來Claude Code唔係一個普通嘅聊天機械人，而係一個有狀態嘅系統。對話愈長，佢嘅注意力就愈分散，早期建立嘅上下文會慢慢被稀釋，結果就係越寫越偏離原本嘅項目。
為咗解決呢個問題，軍哥總結咗4個核心技巧：第一，每次開新項目都先用/init生成一份CLAUDE.md，好似「勞動合同」咁，清楚記低項目結構、技術棧、編碼規範，咁樣Claude Code每次都會自動讀取，唔使重新解釋。第二，用Plan Mode（Shift+Tab）先規劃再寫代碼，等佢講清楚點改、改邊啲文件、影響啲乜，確認冇問題先開始寫。第三，將大改動拆成細步，每一步都驗證一次，仲要定期用git commit checkpoint，萬一出事可以即刻回滾。第四，日常用多啲小技巧，例如直接貼截圖調UI、用!行終端命令、對話長咗就用/compact壓縮、做完一個功能就/clear清空、改多個文件之前叫佢出diff。
總括嚟講，Claude Code嘅不穩定唔係模型問題，而係使用方式問題。佢唔係一個「你講佢做」嘅客服，而係一個需要你主動管理嘅程序員。你用得好，佢就係最…
- Claude Code嘅「不穩定」源於對話上下文污染，唔係模型本身問題；管理好上下文，輸出就會穩定。
- 用/init生成CLAUDE.md做項目說明書，記錄技術棧、編碼規範等，係最重要嘅第一步。
- 先切Plan Mode規劃方案，確認方向先寫代碼，可以大幅減少改動出錯。
- 將大功能拆成細步，每一步驗證一次，並用git commit checkpoint，避免一次過踩坑好難追查。
- 善用截圖、!命令、/compact、/clear、diff等功能，提升日常使用效率，保持對話清爽。
踩坑實錄：對話太長，模型走曬樣
軍哥一開始用Claude Code嘅時候，覺得佢好勁，幫手寫代碼同改bug，仲諗住可以慳返IDE插件。點知有一次加用戶權限模塊，佢直接將需求掉畀Claude Code，對方唰唰唰寫咗一大輪，變量命名好規範，註釋又清楚，佢就冇仔細睇，繼續做下一個功能。
嚟回傾咗大約兩個鐘，突然發現新寫嘅代碼同之前風格完全唔一致
camelCase變咗snake_case，try-catch變咗Result模式，甚至邏輯同前面衝突。佢先意識到，原來Claude Code係有狀態嘅系統，對話愈長，注意力愈分散，初期建立嘅上下文慢慢被稀釋，結果就係「幫你寫一個佢自己腦補出嚟嘅項目」。呢個就係「上下文污染」嘅問題。
技巧一：寫份項目說明書，同Claude Code「簽合同」
軍哥話，最重要嘅一件事就係用/init生成CLAUDE.md。呢個命令會自動掃描成個代碼庫，生成一個文件記錄項目結構、技術棧、目錄約定、編碼規範。以後每次新開會話，Claude Code都會自動讀取，唔使你重新介紹一大輪。
加咗CLAUDE.md之後，生成嘅代碼質量係兩個層次
佢仲加咗具體約定，例如API路由參考邊個檔案、數據庫查詢統一用repository模式、修改核心檔案之後要跑測試、組件命名用PascalCase等等。咁樣代碼風格就穩定好多。
CLAUDE.md就係你同Claude Code之間嘅「勞動合同」
另外，軍哥推薦用Plan Mode（Shift+Tab）先規劃再寫。以前佢會直接掉需求等佢生成，生成完先發現問題；而家佢會先切到Plan Mode，等Claude Code分析要改邊啲文件、點改、影響到邊度，確認方向先開始寫。
技巧二：小步走，隨時有得返轉頭
軍哥話呢個技巧最易被忽視。好多人一次過叫Claude Code寫曬成個功能，然後一運行就發現一堆問題，仲要唔知邊步出錯。佢自己就係咁中過招，寫咗兩個鐘權限模組，改咗幾十個文件，最後報錯完全追查唔到源頭。
小步走唔係慢，係為咗行得更穩
佢而家嘅做法係：第一步只起database schema，驗證無問題先下一步；第二步起repository層；第三步起API端點；第四步起前端組件。每一步都係一個可驗證嘅節點，出錯即刻知邊度。
每次大改動之前，我一定會git commit一個checkpoint
呢個習慣救過佢好幾次，發現方向唔啱就直接回滾，唔使慌。
技巧三：日常小技巧，用過就返唔到轉頭
軍哥分享咗幾個日常操作：直接貼截圖調UI，唔使再用文字講「左邊啲」「顏色深啲」；喺消息前面加!就可以行終端命令，例如!git status；對話長咗就用/compact壓縮，保留關鍵決策；做完一個功能就/clear清空，避免上下文污染；改多個檔案之前叫佢出diff，逐個確認先實際修改。
好多時代碼出問題，唔係Claude Code嘅問題，係你自己啲上下文太亂
總括嚟講，Claude Code係一個需要你主動管理嘅協作者：你畀清晰上下文，佢就穩定輸出；你叫佢先諗後做，佢就少踩坑；你小步推進，出錯都揾得到原因。用得好係最佳編程夥伴，用得唔好就係昂貴玩具。
講真，我第一次用 Claude Code 嘅時候，內心戲係咁嘅：
"嘩，呢個嘢太勁啦！幫我寫 code，仲幫我改 bug，簡直係 programmer 救星！IDE 插件都慳返，以後靠曬佢！"
嗰段時間我見到人就吹："你用咗 Claude Code 未？正到爆！"
直至有一日——
我個 project 畀佢玩謝咗。
具體過程係咁嘅：我想幫個 project 加個用戶權限模組，就咁將個需求掉畀佢，佢唰唰唰就寫咗一大堆 code。我睇一睇，咦，又好似幾似樣喎，variable 命名好規範，comments 都寫得幾清楚，就冇仔細睇，繼續叫佢做下一個功能。
傾咗大概兩個鐘，突然發現——
佢寫嘅新 code 同之前嘅 code 風格完全唔一致。
Variable 命名換咗一套：之前我用 camelCase，而家佢畀我搞個 snake_case；
錯誤處理方式都變咗：之前我用 try-catch 包裹，佢就畀我搞咗個 Result 模式；
甚至有個位嘅邏輯同前面嘅實現直接衝突——前面用同步方式處理，後面又異步又 callback。
我嗰陣時嘅心態係咁嘅：
我完全淆底。
呢個仲係我識嗰個 Claude Code 嗎？仲係嗰個幫我寫 code 嘅小幫手嗎？點解好似一個同我有牙齒印嘅同事，特登嚟玩我咁？
後來我先搞明白：我一直當佢係 chatbot 咁用，但其實佢係個有狀態嘅系統。
對話越嚟越長，佢嘅「注意力」就越嚟越分散。早期建立嗰啲 context——個 project 用咩語言寫、用咩 framework、code style 係點——會慢慢被沖淡。結果係，佢越到後面越唔似幫你寫呢個 project，而係幫你寫一個佢自己腦補出嚟嘅 project。
就好似你同一個 product manager 傾偈，佢一開始仲記得你要做啲乜，做到後來佢可能就自顧自咁諗咗一個完全唔同嘅 product 形態，然後跟住嗰個方向同你提需求。
呢種感覺，你哋有冇試過？
乾貨到！4 個令到我 code 質量翻倍嘅技巧
經過呢半年幾嘅踩坑，我總結咗 4 個核心技巧。每一個都係我用無數次教訓換返嚟，睇完一定值。
1️⃣ 先畀佢一份「項目說明書」
呢個係最重要嘅一件事，冇之一。
而家每次開新 project，我第一件事就係喺 Claude Code 度執行 /init。
佢會自動 scan 你成個 codebase，然後生成一個叫 CLAUDE.md 嘅檔案，將 project 結構、技術棧、目錄約定、編碼規範全部記低。以後每次新開 session，佢自動讀呢份檔案，唔使你重新介紹一次「我哋用 TypeScript，interface 放喺 src/api 目錄，樣式用 Tailwind，component library 用 antd......」
就係呢一步，已經可以慳返大量重複解釋嘅時間。
而且你會發現，加咗呢份說明書之後，佢寫嘅 code 質量同之前完全係兩個層次。
我後來仲喺 CLAUDE.md 入面加咗啲更具體嘅約定，例如：
src/api/example-route.ts 的寫法src/repositories/ 目錄下嘅 repository 模式src/core 下嘅檔案之後必須行測試
加咗呢啲之後，佢生成嘅 code 風格就穩定好多，唔會成日突然走出一個同 project 格格不入嘅寫法。
CLAUDE.md 就係你同 Claude Code 之間嘅「勞動合約」，先講清楚規則，後面嘅合作先會愉快。
2️⃣ 唔好畀佢邊諗邊寫
有段時間我發現一個規律：叫佢直接寫 code，十次有六次要改。但如果我叫佢先「講嚇打算點做」，佢講完我覺得冇問題，先叫佢寫，出錯嘅機會就少好多。
點解會咁？
因為當佢開始寫 code 嘅時候，佢嘅「注意力」就全部集中喺 code 生成上面，可能會忽略咗你之前提過嘅一啲需求細節。但如果你叫佢分析嚇、規劃嚇，佢會更加有條理咁將需求拆解清楚，你哋可以喺「點樣做」呢個層面先達成共識。
後來我發現 Claude Code 有個內置功能叫 Plan Mode，快捷鍵係 Shift + Tab。撳入去之後，佢只分析、只俾方案，唔鬱 code。你覺得方向啱，再按一次 Shift + Tab 返出嚟，佢先開始寫。
呢個功能簡直係我救星。
以前遇到一個稍微複雜啲嘅功能，我會成個需求掉曬畀佢，然後等佢生成，生成完再發現問題。而家我會先切去 Plan Mode，叫佢將要改邊啲檔案、點改、影響到邊度全部講清楚。
特別係嗰啲要鬱多個檔案嘅改動——數據庫加 field、同時 update repository layer、update API route、update TypeScript type definition、可能仲要改 frontend component——唔提早過一次，好容易漏咗某個位，然後運行報錯你都揾唔到係邊度嘅問題。
記住一句話：先唔好開始，淨係俾我方案。呢七個字值好多錢。
3️⃣ 細步走，隨時可以回頭
呢條我覺得係最容易被忽略嘅，亦係踩坑最多嘅。
好多人用 Claude Code 嘅方法係：描述一個完整嘅功能，叫佢一次過寫曬，然後運行，發現一大堆問題，再開始改。
呢種方法表面睇好似好慳事，實際上係將所有風險都積累到最後一刻。
而且最恐怖係：出咗問題你甚至唔知係邊一步錯。
就好似我之前遇到嗰個權限模組，寫咗兩個鐘，幾十個檔案，改咗幾百行 code，最後運行報錯，你叫我點查？根本唔知係邊一步埋咗炸彈。
我而家嘅方法係切開細塊：
第一步，淨係整 database schema，其他咩都唔做。
行一次，冇問題：
第二步，整用呢個 schema 嘅 repository layer。
再行一次，冇問題：
第三步，整 API endpoint。
再行一次，冇問題：
第四步，整 frontend component。
......如此類推。
每一步都係一個可以驗證嘅節點，出咗問題即刻知道喺邊度，唔使反向追查。呢個先係真正嘅效率最大化。
另外，每次要做比較大嘅改動之前，我都會先 commit 一個 checkpoint：
git add . && git commit -m "checkpoint: 大改動前備份"
聽落好老土，但真係救過我好幾次。改嚇改嚇發現方向唔啱，直接 rollback，由嗰點重新嚟過，一啲都唔慌。
細步走唔係慢，係為咗行得更穩。
4️⃣ 幾個小技巧，用咗就返唔到轉頭
呢部分係一啲日常使用嘅小技巧，屬於「知道咗就返唔到轉頭」系列。
Screenshot 貼入去執 UI 問題。
頁面樣式唔啱，直接 Ctrl+V 將 screenshot 貼入去，話「呢個 button 位置唔啱，幫我調整嚇」。比用文字描述位置關係快好多。咩「左邊啲」「再落少少」「顏色再深啲」——呢種溝通簡直係惡夢，但係有咗 screenshot，一切唔係問題。
Terminal command 唔使開新 window。
Message 前加 ! 就可以直接行 command，例如 !git status、!npm test、!ls -la。細微嘢唔使 switch 嚟 switch 去，chat window 裏面直接搞掂。而且運行結果仲可以直接出現喺對話入面，方便 context 理解。
Session 快變長就壓縮嚇。
行咗半個幾鐘，輸入一次 /compact，佢會將成個對話濃縮成 summary，只保留關鍵嘅 decision 同狀態。唔做呢步，佢後面嘅回答會越嚟越走樣，仲以為佢變蠢咗——其實唔係，係 context 太長，佢自己都亂咗。
一個功能一次對話。
/clear 做完一個功能，下一個功能之前完全清空。唔好將「context pollution」當成慳時間嘅方法，嗰啲只係緊自己挖坑。好多時 code 出問題，唔係 Claude Code 嘅問題，係你自己個 context 太亂。
善用 diff 功能。
每次佢要改好多檔案嘅時候，叫佢先 output diff，你確認冇問題先實際修改。咁樣你可以睇到每一處改動係啲乜，唔會唔小心改咗你唔想改嘅地方。
寫喺最後
Claude Code 呢個工具，裝咗之後大多數人會經歷一個階段：覺得佢幾好用，但總有啲講唔出嘅唔穩定。有時好準，有時完全走樣；有時好似神，有時好似智障。
呢種「唔穩定」嘅感覺，會令到好多人對佢又愛又恨，最後掉咗唔用。
但我想講句說話：呢種感覺通常唔係 model 嘅問題，係使用方式嘅問題。
佢唔係一個「你講、佢做」嘅工具。佢更加似一個需要你主動管理嘅 collaborator——
你當佢係客服，佢就係客服——問你答，唔問唔答，你問多咗佢仲答得唔好；
你當佢係 programmer，佢就係 programmer——你要指揮佢、審查佢、管理佢，佢先可以幫你寫出好 code。
所以呀，唔好再當佢係 chatbot 咁用。佢係一個 需要你指揮嘅 programmer，唔係嗰個 你問乜佢答乜嘅客服。
用得好，佢係你最好嘅 programming buddy；
用得唔好，佢就係個貴價玩具。
啱呀，你哋用 Claude Code 嘅時候有冇遇到過類似嘅問題？踩過啲乜嘢坑？後來點樣解決？Comment 區傾嚇，話唔定就拯救咗一個同你一樣咁困惑嘅兄弟！
如果覺得有用，俾個 like、睇嚇、分享都隨意，你哋嘅支持係我繼續更新嘅動力！
~ 我係軍哥，下期想睇咩主題？Comment 區話我知~
說實話，我第一次用 Claude Code 的時候，內心戲是這樣的：
"哇塞，這玩意兒太強了吧！幫我寫代碼，還幫我改 bug ，簡直是程序員救星！ IDE 插件都省了，以後就靠它了！"
那段時間我逢人就吹："你用 Claude Code 了嗎？太香了！"
直到有一天——
我的項目被它玩壞了。
具體過程是這樣的：我想給項目加個用戶權限模塊，直接把需求扔進去，它唰唰唰就寫了一大堆代碼。我一看，嘿，挺像那麼回事，變量命名挺規範的，註釋也寫得挺清楚，就沒細看，繼續讓它做下一個功能。
來回聊了大概兩個小時，突然發現——
它給我寫的新代碼和之前的代碼風格完全不一致。
變量命名換了一套：之前我用 camelCase ，現在它給我整個 snake_case ；
錯誤處理方式也變了：之前我用的是 try-catch 包裹，它給我搞了個 Result 模式；
甚至有個地方的邏輯和前面的實現直接衝突——前面用的同步方式處理，後面又是異步又是回調。
我當時的心態是這樣的：
我完全懵了。
這還是我認識的那個 Claude Code 嗎？這還是那個幫我寫代碼的小幫手嗎？這怎麼感覺像是一個和我有仇的同事，故意來搞我的？
後來我才搞明白：我一直把它當聊天機器人用，但它其實是個有狀態的系統。
對話越來越長，它的"注意力"就越來越分散。早期建立的那些上下文——項目是用什麼語言寫的、用的什麼框架、代碼風格是什麼——會慢慢被稀釋。結果就是，它越到後面越不像在幫你寫這個項目，而是在幫你寫一個它自己腦補出來的項目。
就像你和一個產品經理聊天，他一開始還記着你要做的是什麼，做到後來他可能就自顧自地想象了一個完全不同的產品形態，然後按照那個方向給你提需求。
這種感覺，你們有過嗎？
乾貨來了！ 4 個讓我代碼質量翻倍的技巧
經過這半年多的踩坑，我總結出了 4 個核心技巧。每一個都是我用無數次教訓換來的，看完絕對值。
1️⃣ 先給它一份"項目說明書"
這是最重要的一件事，沒有之一。
現在每開一個新項目，我第一件事就是在 Claude Code 裏運行 /init。
它會自動掃描你整個代碼庫，然後生成一個叫 CLAUDE.md 的文件，把項目結構、技術棧、目錄約定、編碼規範全都記進去。以後每次新開會話，它自動讀這份文件，不用你重新介紹一遍"我們用的是 TypeScript ，接口放在 src/api 目錄下，樣式用 Tailwind ，組件庫用的是 antd......"
光是這一步，就能省掉大量重複解釋的時間。
而且你會發現，加上這份說明書之後，它寫的代碼質量和之前完全是兩個水平。
我後來還在 CLAUDE.md 里加了一些更具體的約定，比如：
src/api/example-route.ts 的寫法src/repositories/ 目錄下的 repository 模式src/core 下的文件之後必須跑測試
加了這些之後，它生成的代碼風格就穩多了，不會動不動就冒出一個和項目格格不入的寫法。
CLAUDE.md 就是你和 Claude Code 之間的"勞動合同"，先把規則說清楚，後面的合作才能愉快。
2️⃣ 別讓它邊想邊寫
有段時間我發現一個規律：讓它直接寫代碼，十次有六次需要改。但如果我先讓它"說說打算怎麼做"，它說完我覺得沒問題，再讓它寫，出錯的概率就少很多。
為什麼會這樣？
因為當它開始寫代碼的時候，它的"注意力"就全部集中在代碼生成上了，可能就會忽略一些你之前提到的需求細節。但如果你讓它先分析、先規劃，它會更有條理地把需求拆解清楚，你們可以在"怎麼做"這個層面先達成一致。
後來我發現 Claude Code 有個內置的功能叫 Plan Mode，快捷鍵是 Shift + Tab。切進去之後，它只分析、只給方案，不動代碼。你覺得方向對了，再按一次 Shift + Tab 切回來，它才開始寫。
這個功能簡直是我的救星。
以前遇到一個稍微複雜點的功能，我會一股腦把需求扔進去，然後等它生成，生成完再發現問題。現在我會先切到 Plan Mode ，讓它把要改哪些文件、怎麼改、影響到哪裏都說清楚。
特別是那種要動多個文件的改動——數據庫加字段、同時更新 repository 層、更新 API 路由、更新 TypeScript 類型定義、可能還要改前端組件——不提前過一遍，很容易漏掉某個地方，然後運行報錯你還找不到是哪裏的問題。
有一句話記住：先不要開始，只給我方案。 這七個字值很多錢。
3️⃣ 小步走，隨時能回頭
這一條我覺得是最容易被忽視的，也是踩坑最多的。
很多人用 Claude Code 的方式是：描述一個完整的功能，讓它一口氣全寫完，然後運行，發現一堆問題，再開始調。
這種方式看起來省事，實際上是把所有風險都攢到最後一刻。
而且最可怕的是：出了問題你甚至不知道是哪一步錯的。
就像我之前遇到的那個權限模塊，寫了兩個小時，幾十個文件，改了幾百行代碼，最後運行報錯了，你讓我怎麼查？根本不知道是哪一步埋的雷。
我現在的方式是切成小塊：
第一步，只建數據庫 schema ，其他什麼都不做。
跑一下，沒問題：
第二步，建使用這個 schema 的 repository 層。
再跑一下，沒問題：
第三步，建 API 端點。
再跑一下，沒問題：
第四步，建前端組件。
......以此類推。
每一步都是一個可以驗證的節點，出了問題立刻知道在哪裏，不用反向追查。這才是真正的效率最大化。
另外，每次要做比較大的改動之前，我都會先提交一個 checkpoint ：
git add . && git commit -m "checkpoint: 大改動前備份"
聽起來很土，但真的救過我好幾次。改着改着發現方向不對，直接回滾，從那個點重新來，一點不慌。
小步走不是慢，是為了走得更穩。
4️⃣ 幾個小技巧，用了就回不去
這部分是一些日常使用中的小技巧，屬於"知道了就回不去"系列。
截圖粘貼調 UI 問題。
頁面樣式不對，直接 Ctrl+V 把截圖粘進去，說"這個按鈕位置不對，幫我調一下"。比用文字描述位置關係快太多。什麼"左邊一點""再往下一點""顏色再深一點點"——這種溝通簡直是噩夢，但有了截圖，一切都不是問題。
終端命令不用開新窗口。
消息前加 ! 就能直接跑命令，比如 !git status、!npm test、!ls -la。小事不用切來切去，聊天窗口裏直接搞定。而且運行結果還能直接出現在對話裏，方便上下文理解。
會話快變長就壓縮一下。
跑了半個多小時，輸一次 /compact，它會把整個對話濃縮成摘要，只保留關鍵的決策和狀態。不做這一步，它後面的回答會越來越跑偏，你還以為是它變笨了——其實不是，是上下文太長了，它自己也暈了。
一個功能一次對話。
/clear 做完一個功能，下一個功能之前徹底清空。不要把"上下文污染"當成節省時間的方式，那只是在給自己挖坑。很多時候代碼出問題，不是 Claude Code 的問題，是你自己的上下文太亂了。
善用 diff 功能。
每次它要改很多文件的時候，讓它先輸出 diff ，你確認沒問題再實際修改。這樣你可以看到每一處改動都是什麼，不會一不小心改了你不希望改的地方。
寫在最後
Claude Code 這個工具，裝上去之後大多數人會經歷一個階段：覺得它挺好用，但總有些說不清的不穩定。有時候很準，有時候完全跑偏；有時候像神一樣，有時候像智障一樣。
這種"不穩定"的感覺，會讓很多人對它又愛又恨，最終棄之不用。
但我想說句話：這種感覺通常不是模型的問題，是使用方式的問題。
它不是一個"你說、它做"的工具。它更像一個需要你主動管理的協作者——
你把它當客服，它就是客服——問你答，不問不答，你問多了它還答不好；
你把它當程序員，它就是程序員——你得指揮它、審查它、管理它，它才能幫你寫出好代碼。
所以啊，別再把它當聊天機器人用了。它是個 需要你指揮的程序員，不是那個 你問啥它答啥的客服。
用好了，它是你最好的編程夥伴；
用不好，它就是個昂貴的玩具。
對了，你們用 Claude Code 的時候有沒有遇到過類似的問題？踩過什麼坑？後來怎麼解決的？評論區聊聊，說不定就拯救了一個和你一樣困惑的兄弟！
如果覺得有用，點個贊、在看、轉發都隨意，你們的支持是我繼續更新的動力！
~ 我是軍哥，下期想看什麼主題？評論區告訴我~