一個半月高強度Claude Code使用後感受

六月中旬某個悶熱的夜晚，在初淺嘗試使用API Key幫我迅速完成了一個任務後，我毫不猶豫地點下了Claude Max的訂閱按鈕。作為一個「買斷制」時代的遺老，每月一兩百美金的訂閱對當時的我來說還是太超前了。但是在一個半月之後回頭望去，看著那些按照API計價的被我燒掉的價值3000多美金的token，我似乎撿到了一個超大便宜？不過最近Anthropic 宣佈了新的weekly限制，想來大概針對的就是我這種「重度」用戶吧。所以近幾天來我也在研究有沒有其他替代方案，可以讓我從這種限制中解脫出來。不過嘗試了一圈下來（包括CC接其他API，也包括像Codex/Gemimi/Qwen/Crush/Amp/AugmentCode等等），似乎一時半會兒在這個領域Claude Code (後文用CC指代) 還是沒有競爭對手。既然還得續費，那不如階段性地做一個總結，來記錄下這一個半月使用CC的一些感受吧。

Vibe Coding的迭代速度

說到vibe coding，最讓我震撼的其實不是模型有多智能或者是能完成什麼尖端任務，而是由它帶來的產品迭代速度的提升。有個有意思的現象：Claude Code本身就是Anthropic內部dogfooding的產物：從六月中旬我開始使用到現在，短短一個半月時間裡，我們見證了很多嶄新的功能：自定義命令讓我們避免重複輸入一樣的prompt，Hooks功能可以在各種事件觸發時自動執行命令，Subagent則解決了上下文窗口的限制問題。這種更新頻率，放在傳統軟件開發時代簡直是天方夜譚。

不光是CC，整個AI輔助開發領域都在以令人眩暈的速度前進。幾天甚至幾小時完成一個產品，不再是不可能的任務。

不過，這種加速帶來了一個有趣的悖論：AI確實解放了開發者的雙手，讓我們不用再糾結於那些繁瑣的樣板代碼。但另一方面，當所有人都開上了「法拉利」，賽道上的競爭反而變得更加激烈了。以前你可以精心打磨一個功能，現在？競爭對手可能已經用AI快速迭代了三四個版本了。手工匠人式的打磨方式，無疑將被卷死在沙灘上。

說實話，有時候我會懷念那個慢工出細活的年代。但現實就是這樣，技術的車輪滾滾向前，你要麼跟上，要麼被碾過。去適應和利用它，而不是被裹挾前進，可能才是新時代的立命之本。如果這篇文章你只能記住一句話，那我希望是這句：在vibe coding時代，千萬別讓工具把自己逼死。效率是提高了，但人還是人，我們需要的不僅僅是更快的開發速度，還有思考的時間和生活的空間。

從傳統Editor AI的轉換

在投身CC之前，我也算是各種AI編輯器的老用戶了。從最早期的Cursor，到後來的Windsurf，再到GitHub Copilot和各種VS Code插件如Cline，基本上市面上叫得出名字的我都試過。但說實話，這些Editor AI工具並沒有像CC這樣給我帶來那麼大的衝擊和震撼。

我想，這類編輯器工具最大的問題是可能是缺少全局感。想像一下你使用這些編輯器AI時的經典場景：打開一個文件，選中幾行代碼，然後讓AI幫你改改。這種交互模式天然就把開發者的思維框在了當前文件甚至當前這幾行的範圍內。這種模式對於剛從傳統編程過渡到AI輔助編程的開發者來說，確實是個不錯的起點。畢竟，你還保留著對代碼的掌控感：AI寫得不好？沒關係，我隨時準備自己上。但問題是，如果你真的想進入深度的vibe coding狀態，讓AI發揮最大潛力，這種隨時準備接管的心態反而會成為阻礙。人類開發者的幹預時機和直接下場寫代碼的時候越少，最終呈現出的效率和效果反而越好。

另外更致命的是同步問題：AI在上下文中認為文件是A狀態，實際文件已經被開發者插手改成B狀態了，然後你讓AI基於它的認知繼續修改，結果可想而知：要麼產生混亂，要麼AI需要再讀一遍所有內容。有時候光是解決這種不同步帶來的問題，花的時間就比寫代碼還多。

而命令行工具從理念上就不同：沒有華麗的界面，沒有實時的代碼提示，開發者在過程中難以直接插手「微調」。但恰恰是這種簡陋，反而讓它能夠更深入地理解和操作整個項目。它不會被某個文件或某幾行代碼限制視野，而是從項目的根目錄開始，建立起對整個代碼庫的認知。沒有了編輯器這個中間層，開發者想直接修改代碼變難了，這在某種程度上「強迫」你更多地依賴和使用AI，給它更多信息和反饋，這反而能發揮出更大的效能。

當然，我不是說編輯器AI就一無是處。本質上，當前兩者的差異更多來自於使用方式和模型質量，而非架構設計。CC背靠Anthropic這棵大樹，模型質量自然沒得說。更關鍵的是，它可以肆無忌憚地使用token（雖然最近加了weekly限制），這種量大管飽的豪橫，確實在末端引起了質變，讓最終效果好了不止一個檔次。如果讓編輯器AI也能隨便燒token，可能效果未必會差到哪裡去。

但現實就是現實，至少在當下，如果你想體驗真正的vibe coding，CC可能是唯一選擇。

認識CC的邊界和長處

就像所有工具一樣，CC或者說AI輔助編程，也有自己擅長和不擅長的領域。認清這些邊界，才能讓你的vibe coding之旅更加順暢。

如果你讓CC分析一段複雜的代碼邏輯，理解各個模塊之間的調用關係，然後畫一張時序圖或者架構圖，它會完成得相當出色。這種需要理解和總結的任務，正是LLM的看家本領。又或者，你想快速實現一個算法、搭建一個項目框架、編寫測試用例，CC都能給你滿意的答案。

但是，千萬別指望它在所有場景下都能大殺四方。比如說，你想在整個代碼庫裡做一次全局的變量重命名，或者進行某些需要精確匹配的複雜重構，那老老實實用IDE的重構功能會靠譜得多。LLM畢竟說到底也只是一個概率生成器，這類需要100%準確性的任務，從起源上就不是LLM的強項。如果你真的需要使用AI幫助完成這類任務，那麼請它寫一段腳本去執行並修改代碼，往往會比直接指揮它去修改文件，要來的靠譜。

還有個更現實的問題：訓練數據的偏差。CC在處理前端代碼或者TypeScript時簡直如魚得水，各種框架信手拈來，CSS炫技讓人眼花繚亂，最新的API也瞭如指掌。但換成iOS/Swift開發？那可就是另一番景象了。各種過時的API用法是家常便飯，有時乾脆臆造一些不存在的方法，幻覺嚴重，而更冷門的語言和框架情況則更加糟糕。訓練集豐富程度的差異直接決定了模型在不同領域的表現。

市面上也存在著其他不少基於命令行的code agent，像是Crush，Gemini CLI等等。但實測下來，它們現在和CC還存在很大差距。CC作為「軟硬件一體」解決方案帶來了巨大的優化空間：Anthropic既是模型提供方，又是工具開發方，這種垂直整合讓他們可以針對具體使用場景進行深度優化。這就像蘋果的生態系統——當你同時控制硬件和軟件時，能做到的事情遠超各自為戰的組合。其他競品要麼受限於模型能力，要麼受限於工具設計，很難達到CC這種渾然一體的使用體驗。

思考先行還是實踐先行

CC提供了一個很有意思的功能：Plan Mode。在這個模式下，你可以先和AI進行充分的討論，制定詳細的實施計劃，然後再開始實際的編碼工作。這就引出了一個有趣的話題：我們是應該追求先想清楚再動手，還是先動手搞出東西來之後再慢慢改？

在傳統軟件開發領域，這個爭論也由來已久。瀑布派說要先設計後實現，敏捷派說要快速迭代。到了AI時代，這個問題又有了新的含義。

我見過兩種極端的使用方式。第一種是「規劃魔」：進入Plan Mode後，和AI討論個把小時，上下文用光兩三次，從架構設計到具體實現，從錯誤處理到性能優化，事無巨細地規劃每一個細節。等到真正開始寫代碼時，基本上AI就是照著計劃一步步執行。另一種則是「莽夫流」：上來就是一句「給我實現一個XXX功能」，然後就看著AI噼裡啪啦地寫代碼，寫完了發現不對再改，改完了又發現新問題，如此循環往復。

哪種方式更好？也許乍看下來先規劃再執行更好？但我的答案可能會讓你失望：要看情況。

如果你是個經驗豐富的開發者，對項目架構已經有了清晰的認識，那麼先進行充分的規劃確實能讓後續的實現更加順暢。特別是對於那些需要遵循特定架構模式的既有項目，Plan Mode能幫你確保AI生成的代碼符合項目規範。我自己就經常在Plan Mode裡和AI討論：「我們的項目使用了MVVM架構，新功能應該怎麼拆分到各個層？」 「這部分內容已經有類似實現了，你需要參考現有實現和模式」，這種討論能讓AI更好地理解項目的整體結構，生成的代碼質量更高，開發者對具體代碼的掌控也更好。

但如果你對某個技術棧完全不熟悉，或者正在做一個全新的探索性項目，那麼「先幹起來」可能反而是更好的選擇。這種情況下，很多時候你根本不知道自己不知道什麼。所以與其空想，不如讓AI先寫個原型出來，跑起來看看效果，發現問題再迭代。這種方式特別適合那些「短平快」的項目，或者你只是想快速驗證一個想法。

我個人的偏好？我更喜歡先進入Plan Mode，和AI討論後再開始實施。對我來說，日常維護已有代碼庫的工作是佔大頭的，我需要更穩定和可靠的迭代，先plan有利於我掌控全局。但在接觸新技術棧時，我也不太願意直接莽起來。不同技術棧下，很多開發的理念是共通的：如何組織可維護的架構（不僅為了人類，也為了AI今後進行維護，合理的組織結構還是必要的），如果調度和安排代碼以保證高效，各個模塊的連接方式等。就算是新技術棧，適當的討論相比無腦梭哈，也提供了一種更有效的學習方式。但是這樣做的代價是慢，如果著急上線功能，或者寫的是可以無視代碼質量的「快消品」，那麼事無巨細的plan可能就不太適用了。

最後想說的是，Plan Mode還有個隱藏的好處：它能幫你整理思路。有時候你覺得自己想清楚了，但真要說出來或者寫下來，才發現還有很多細節沒考慮到。和AI的對話過程，其實也是一個自我梳理的過程。這算是「橡皮鴨調試法」的變種，在vibe coding時代依然很有價值。

Claude Code的Best practices 官方博文中介紹了幾種常見的workflow，比如：

• 探索，計劃，編碼，提交
• 編寫測試，提交，編碼，迭代，提交
• 編寫代碼，截圖，迭代

相比於直接用prompt命令CC開始幹活，先指導它對代碼庫的現狀進行理解，往往會得到更好的結果。參考這些常見workflow並逐漸發展出自己的使用AI的style，也是一種成長。

小步迭代還是放飛自我

在手工編程時代，一天能寫幾百行代碼就算是高產了。但vibe coding徹底改變了遊戲規則：現在，你可以在十幾分鐘內生成上千行代碼，甚至一口氣完成整個項目。這種「生產力爆炸」帶來了一個新問題：我們應該如何使用這種能力？

我見過的使用方式大致分兩派。一派是「小步快跑」：每次只讓AI完成一個小功能，驗證沒問題後再進行下一步。另一派是「一步到位」：直接把整個需求扔給AI，讓它一次性生成所有代碼。更極端的，還有人會開啟--dangerously-skip-permissions模式（也就是所謂的yolo模式），讓AI可以不經確認就執行任何操作。

兩種方式我都深度嘗試過，結論是：如果能選，小步迭代往往總是更好的選擇。

舉個例子，有次我想重構一個模塊，大概涉及七八個文件的修改。我當時想，既然AI這麼厲害，那讓它一次性搞定吧！於是我詳細描述了需求，然後就看著CC開始瘋狂輸出代碼。幾分鐘後，上千行代碼的修改完畢，編譯也通過了。我心想：這也太爽了吧！

然而，實際開始嘗試時，噩夢開始了。首先是一個小bug，因為上千行的修改肯定是懶得看的，所以只能描述情況，讓AI去修復；修復過程中又引入了新問題；再修復，又有新問題…幾輪下來，代碼庫已經面目全非。由於一次性改動太多，開發者失去了掌控，對於修改不理解，也就無法辨別哪些修改是必要的，哪些又是AI為了修復新bug臨時加上的。最後的結果，往往只能是git reset整個修改，重新開始。

這類經歷讓我明白了一個道理：AI生成代碼的能力很強，但它對整體架構的把握和長期維護的考慮還是有限的。一次性生成太多代碼，就像是在黑暗中狂奔——你可能跑得很快，但也可能一頭撞上牆。而且，當出現問題時，調試的複雜度會呈指數級增長。

相比之下，小步迭代的好處顯而易見：

• 可控性高：每次只改動一小部分，出問題了也容易定位和回滾。
• 能夠理解：你能跟上AI的思路，理解每一步在做什麼。
• 質量保證：可以在每一步後進行測試，確保代碼質量。
• 學習機會：通過觀察AI的實現方式，你也能學到新東西。

當然，我不是說「放飛自我」就完全不可取：在進行新功能實現時，如果已經進行了充分討論和規劃，那麼確實不太需要人類的監督，CC就可以完成大部分工作。如果你真的想嘗試「放飛自我」的開發方式，我有幾個建議：

• 必須有完善的測試：採用TDD的方式，先寫測試（當然這也是AI來寫），再讓AI實現功能。這樣至少能保證基本的正確性。
• 做好版本控制：在開始之前創建新分支，隨時準備回滾。
• 分模塊進行：即使要一次性完成很多功能，也盡量按模塊來組織，不要把所有東西混在一起。
• 交叉評審：AI生成的代碼看起來能跑，但可能隱藏著各種問題，對於生成的代碼，不要照單全收。最簡單的方式，就是找到另一個AI，將變更餵進去，看看有什麼需要改進的地方，這種迭代往往能收穫不錯的結果。

任務規模和上下文制約

人類和AI在某個方面驚人地相似：處理小任務時遊刃有餘，面對大項目就容易手忙腳亂。對CC來說，這個問題更加明顯，因為它還要面對一個硬性限制——200k的上下文窗口。在當前動輒模型給1M窗口的年代，這個限制又是確實相當痛苦。

體感上來說，普通使用個十幾二十分鐘，你就會看到上下文使用量飆到90%以上。這時候CC就像一個塞滿東西的行李箱，再想往裡裝點什麼都困難。更糟糕的是，如果在執行任務的過程中觸發了自動壓縮，整個agent可能會陷入混亂，忘記自己在做什麼，或者陷入死循環重複做一件事。

所以，如何在有限的上下文窗口內完成複雜任務，就成了使用CC的一門必修課。

任務拆解是關鍵

與其給AI一個籠統的「幫我完成XXX系統」的需求，不如先把大任務拆解成具體的小任務。這一步最好在Plan Mode中進行，讓AI幫你一起梳理。比如：

我：我想實現一個用戶認證系統，幫我拆解需求
AI：好的，讓我們拆解一下需要完成的任務：
1. 設計數據庫表結構（用戶表、會話表等）
2. 實現註冊功能（驗證、加密、存儲）
3. 實現登錄功能（驗證、生成token）
4. 實現中間件（驗證token、刷新機制）
5. 添加測試用例
...

對於一個session難以完成的任務，可以讓AI把討論內容進行文檔化，保存到項目裡（比如dev-note/auth-implementation-plan.md）。這樣，即使換了新的session，你也可以讓AI讀取這個文檔，快速恢復上下文。

使用Subagent

CC最近推出的Subagent功能在一定程度上緩解了這個問題。在以前，當CC使用Task工具進行任務時，實際上是在一個全新的上下文中進行工作。這相當於擴展了主Session的上下文窗口。

以前我們只能通過prompt技巧來「誘導」CC使用Task工具，效果時好時壞。現在有了專門的subagent配置，穩定性大大提升。你可以為不同類型的任務創建專門的agent：

• 代碼分析agent：專門負責理解現有代碼結構
• 代碼審查agent：檢查代碼質量和潛在問題
• 測試agent：編寫和運行測試用例
• Git agent：處理代碼提交和PR

通過合理鏈式調用這些agent，即使是大型任務也有機會能在同一個Session裡有條不紊地完成。每個agent都在獨立的上下文中工作，不會相互幹擾，也不會耗盡主session的上下文。

在合適的時機手動compact

雖然CC會自動進行上下文壓縮，但我的經驗是：主動出擊會更好。當你看到上下文使用量接近用滿時，不妨手動執行/compact命令。這可以讓壓縮發生在一個更自然的斷點進行。比如剛完成一個功能模塊，或者剛跑完一輪測試。這時候壓縮，AI不太會丟失重要信息。而如果等到自動壓縮，可能正好在你改代碼改到一半的時候觸發，那就很容易出問題。

另一個技巧是：對於相對獨立的任務，乾脆新開一個session。反正你已經把任務計劃文檔化了，新session讀取文檔就能快速上手。這比在一個快要爆炸的session裡硬撐要明智得多。

當前在AI輔助編程中，上下文窗口依然是稀缺資源，要像管理內存一樣管理它。合理規劃、及時清理、必要時「換個房間」，才能讓vibe coding的體驗保持流暢。

善用命令和周邊工具

Command和Hooks

我有個暴論：凡是重複了兩次以上的類似prompt都應該用命令來表述！

每次都輸入類似的prompt真的非常無趣：「運行測試並修復失敗的用例」、「提交代碼時請使用規範的commit message」…如果你發現自己在重複類似的請求，立刻停下來，花一分鐘配置一個command。

Command相比subagent有個巨大的優勢：它擁有完整的當前會話上下文。如果你的任務和當前正在進行的工作高度相關，那麼command的效率會更高。比如我常用的幾個：

• /test-and-fix：運行測試，如果有失敗自動嘗試修復
• /review：對當前修改進行代碼審查，給出改進建議
• /commit-smart：分析改動，生成合適的commit message並提交

至於Hooks，說實話我用得不多。理論上它能在特定事件觸發時自動執行命令，比如每次提交前自動運行測試。但實際使用中，我更喜歡保持一定的控制權，不太喜歡太多自動化的東西在背後悄悄運行。不過這純屬個人偏好，如果你的工作流比較固定，Hooks確實能省不少事。

MCP

通過MCP補充模型不知道的知識。我最常用的幾個場景：

1. 最新的Apple文檔 Apple的文檔頁面大量使用JavaScript渲染，因此CC的WebFetch抓不到內容。但通過apple-docs-mcp，我可以獲取最新最準確的API文檔。這對iOS開發來說簡直是救命稻草。

2. 項目管理集成 通過mcp-atlassian連接JIRA，可以讓CC直接讀取和更新任務狀態，或者自動將分析的情況和實現進行回覆，保持溝通暢通。

3. LSP支持 CC暫時還原生支持LSP，但通過mcp-language-server，可以獲得準確的代碼補全和類型信息。特別是對於那些CC不太熟悉的語言，這個功能價值巨大。

配置MCP可能需要一點時間，但絕對物有所值。它讓CC從一個通用的工具變成了為你量身定製的助手。

編譯、分析和測試

永遠記住：AI生成的代碼，未經測試都是廢品。

我的工作流程通常是這樣的：

• 在CLAUDE.md中詳細列出項目的編譯命令、測試命令、linter配置
• 每完成一個小功能，立即編譯
• 編譯通過後，運行相關測試
• 測試通過後，運行linter和formatter

聽起來很繁瑣？其實配置好之後，這些都可以通過簡單的命令完成和subagent。關鍵是要讓這些步驟成為習慣，而不是等全部寫完再說。

如果你的項目支持TDD，那就更好了。先讓AI根據需求寫測試，然後再實現功能。這樣生成的代碼質量通常會高很多，因為AI有了明確的目標。

當然，根據編譯器的廢柴程度（你們大概應該知道我在說誰..）和項目的規模，編譯一次的時間代價可能會很大。這種情況下，我會拆分模塊，盡量只去編譯改過的模塊。如果這比較困難，那麼也可以使用git worktree來創建多個工作目錄：這樣你可以讓多個任務並行進行，互不幹擾，也算是彌補等待編譯所帶來的時間損失。

Code之外，大有可為

別把CC只當成寫代碼的工具，它的能力遠不止於此。

我現在的日常使用場景：

• 代碼提交和PR：寫完代碼後，直接讓CC分析改動、生成commit message、推送代碼、創建PR。它生成的PR描述往往比我自己寫的還要清晰。
• 撰寫技術文檔和wiki: 讓CC分析代碼生成API文檔、更新README、編寫使用示例。它的文檔往往更加規範和完整，甚至不會出現語法錯誤。
• JIRA更新：完成任務後，讓CC更新ticket狀態、添加評論回覆用戶、甚至創建新的子任務。再也不用在網頁上點來點去了。
• 數據處理：需要批量處理文件、轉換格式、清洗數據？以前我會寫腳本，現在直接描述需求讓CC來做。而且每次需求不同時，不用維護一堆一次性腳本了。

更有意思的是CC解鎖了隨時隨地工作的可能性。通過像是VibeTunnel或者任意手機SSH客戶端，配合Tailscale，我可以在任何地方連接到家裡的工作機器，用手機指揮CC幹活。雖然不適合與CC進行複雜的計劃和交互，但處理一些簡單的需求，比如跑個腳本、修個小bug，更新下文檔什麼的，是完全沒問題的。出門在外突然想到什麼，立刻就能實現，這種感覺很奇妙。

最後，個人強烈推薦配一個好的麥克風。在vibe coding時代，用語音輸入描述需求，比打字更加自然流暢。現在的語音識別已經很準確了，而中英文混雜也能處理得很好。想不到當年為了當遊戲主播買的麥克風，吃灰這麼多年後，終於在今天找到了真正的用武之地。

當然，Mac系統自帶的語音輸入是幼兒園級別，從準確性和易用性上都不值一提。你肯定需要一款AI轉譯的app，我也試用過一些，總結幾個當前市面上的優秀選擇：

• MacWhisper：以前買的，現在在用，原生macOS app，作者支持速度很快。
• VoiceInk：提供開源以供確認，隱私安全，付費省心。
• Wispr Flow：訂閱制，小貴，但勝在UI漂亮，UX流暢。

它們都是很不錯的選擇，功能也都類似。除了基礎的語音識別和輸入外，再配合轉譯後接入LLM進行文本潤色/修改的能力，根據不同場景將我的語言自動轉為合適的文字和格式。這些app把人機交互提升了一個檔次，語音輸入的內容往往比我自己勞心勞力組織的文字還要清晰精確。現在，絕大多數情況下，我和同事用不同語言交流時，以及自己在書寫PR和各種文檔時，我幾乎也都是說中文，然後讓AI當我的「同傳」轉換為合適的目標語言，以此確保準確和及時。

體感降智和更多限制

接下來要說的內容，有些是我自己的感受，有些是社區裡朋友們的吐槽。很多東西無法證實或證偽，大家權且一聽。

Opus遠強於Sonnet

這幾乎是板上釘釘的事實：Opus的效果比Sonnet好很多。畢竟價格擺在那裡，Opus是Sonnet的5倍。100美金的max訂閱，5小時時間窗口的Opus只能跑幾個小任務額度就用光了。200美金的訂閱也只是勉強夠用。

如果你是100美金檔的用戶，建議養成手動切換模型的習慣。日常用Sonnet處理簡單任務，遇到複雜的架構設計或者棘手的bug，再切到Opus。

時間玄學

這個聽起來很離譜，但確實有體感：美國半夜（也就是北京時間的白天）的效果比美國白天要好。實際上軟件開發最活躍的還是中美兩國，而Anthropic在中國其實是沒有正規渠道能用的。所以可能是因為美國夜裡使用的人少，服務器壓力小，從而模型性能不會退化？總之，如果北京時間大清早遇到無法解決的問題，留到下午時段處理，可能會有驚喜。

降智疑雲

最讓人擔心的是這個：個人體感，前一個月的使用體驗明顯比最近兩週要好。開始我以為是自己的錯覺，但社區裡抱怨的聲音也越來越多。合理的猜測是大量開發者湧入導致的資源緊張。就像一個原本只供應100人的自助餐廳，突然來了1000人，菜品質量下降幾乎是必然的。結合最近Anthropic尋求新的融資的新聞和推出weekly限制的政策，想要在這個定價和使用策略下盈利，似乎是不太可能的。

限制的陰霾

從8月底開始，weekly限制正式實施。雖然官方說是為了公平使用，但誰都知道這背後是算力不足的無奈。而且不排除未來會有更嚴格的限制。

這讓我想起一個老段子：中國先解決顯卡問題，還是美國先解決電力問題？在這兩個問題解決之前，AI發展的瓶頸可能不是算法，而是最基礎的硬件資源。

一些應對策略

面對這些限制，可能我們不得不採取一些「省著用」的技巧：

• 分級使用：簡單任務用Sonnet，複雜任務才上Opus
• 錯峰使用：避開美國工作時間，選擇服務器負載低的時段
• 提高prompt質量：一次說清楚，減少來回對話消耗的token
• 合理使用subagent：把消耗大的任務分配給subagent
• 保持多個選擇：雖然CC目前最強，但保持對其他工具的關注

總結和未來展望

一個半月的CC使用經歷，有驚喜，有擔憂，有對未來的憧憬，也有對現實的無奈。但總的來說，我感受到的是自己切實地站在在歷史的進程之中。Vibe coding不僅僅是一種新的編程方式，更是一種全新的思維模式。它要求我們重新思考什麼是編程、什麼是創造、什麼是價值。在這個AI與人類共舞的時代，願我們都能找到屬於自己的節奏。

最後，回到文章開頭的那句話：在vibe coding時代，千萬別讓工具把自己逼死。技術是為人服務的，不是相反；工作是讓人有機會追尋和思考自我的，而不是讓自己迷失。保持這份清醒，可能比掌握任何具體的技巧都更重要。