內(nèi)容轉(zhuǎn)載自知名 iOS/Unity 開發(fā)者王巍的個(gè)人博客。

王巍，圈內(nèi)人稱「喵神」，objc 中國項(xiàng)目發(fā)起人。曾開源廣受開發(fā)者喜愛的 Xcode 插件 VVDocumenter。作為一名資深開發(fā)者，王巍通過這篇文章記錄了他在持續(xù)使用 Claude Code 的實(shí)際感受以及使用編碼 AI 工具的一些經(jīng)驗(yàn)。 文中有一些反直覺且很有意思的實(shí)際感受，比如，「如果你真的想進(jìn)入深度的 vibe coding 狀態(tài)，讓 AI 發(fā)揮最大潛力，這種隨時(shí)準(zhǔn)備接管的心態(tài)反而會成為阻礙。人類開發(fā)者的干預(yù)時(shí)機(jī)和直接下場寫代碼的時(shí)候越少，最終呈現(xiàn)出的效率和效果反而越好。」 原文地址：https://onevcat.com/2025/08/claude-code/

六月中旬某個(gè)悶熱的夜晚，在初淺嘗試使用 API Key 幫我迅速完成了一個(gè)任務(wù)后，我毫不猶豫地點(diǎn)下了 Claude Max 的訂閱按鈕。

作為一個(gè)「買斷制」時(shí)代的遺老，每月一兩百美金的訂閱對當(dāng)時(shí)的我來說還是太超前了。

但是在一個(gè)半月之后回頭望去，看著那些按照 API 計(jì)價(jià)的被我燒掉的價(jià)值 3000 多美金的 token，我似乎撿到了一個(gè)超大便宜？不過最近 Anthropic 宣布了新的 weekly 限制，想來大概針對的就是我這種「重度」用戶吧。

所以近幾天來我也在研究有沒有其他替代方案，可以讓我從這種限制中解脫出來。不過嘗試了一圈下來（包括 CC 接其他 API，也包括像 Codex/Gemimi/Qwen/Crush/Amp/AugmentCode 等等），似乎一時(shí)半會兒在這個(gè)領(lǐng)域 Claude Code (后文用 CC 指代) 還是沒有競爭對手。

既然還得續(xù)費(fèi)，那不如階段性地做一個(gè)總結(jié)，來記錄下這一個(gè)半月使用 CC 的一些感受吧。

超 10000 人的「AI 產(chǎn)品市集」社群！不錯(cuò)過每一款有價(jià)值的 AI 應(yīng)用。

邀請從業(yè)者、開發(fā)人員和創(chuàng)業(yè)者，飛書掃碼加群：

進(jìn)群后，你有機(jī)會得到：

• 最新、最值得關(guān)注的 AI 新品資訊；
  

• 不定期贈送熱門新品的邀請碼、會員碼；
  

• 最精準(zhǔn)的AI產(chǎn)品曝光渠道

01Vibe Coding 的迭代速度

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

不光是 CC，整個(gè) AI 輔助開發(fā)領(lǐng)域都在以令人眩暈的速度前進(jìn)。幾天甚至幾小時(shí)完成一個(gè)產(chǎn)品，不再是不可能的任務(wù)。

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

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

02從傳統(tǒng) Editor AI 的轉(zhuǎn)換

在投身 CC 之前，我也算是各種 AI 編輯器的老用戶了。從最早期的 Cursor，到后來的 Windsurf，再到 GitHub Copilot 和各種 VS Code 插件如 Cline，基本上市面上叫得出名字的我都試過。但說實(shí)話，這些 Editor AI 工具并沒有像 CC 這樣給我?guī)砟敲创蟮臎_擊和震撼。。

我想，這類編輯器工具最大的問題是可能是缺少全局感。想象一下你使用這些編輯器 AI 時(shí)的經(jīng)典場景：打開一個(gè)文件，選中幾行代碼，然后讓 AI 幫你改改。這種交互模式天然就把開發(fā)者的思維框在了當(dāng)前文件甚至當(dāng)前這幾行的范圍內(nèi)。這種模式對于剛從傳統(tǒng)編程過渡到 AI 輔助編程的開發(fā)者來說，確實(shí)是個(gè)不錯(cuò)的起點(diǎn)。畢竟，你還保留著對代碼的掌控感：AI 寫得不好？沒關(guān)系，我隨時(shí)準(zhǔn)備自己上。但問題是，如果你真的想進(jìn)入深度的 vibe coding 狀態(tài)，讓 AI 發(fā)揮最大潛力，這種隨時(shí)準(zhǔn)備接管的心態(tài)反而會成為阻礙。人類開發(fā)者的干預(yù)時(shí)機(jī)和直接下場寫代碼的時(shí)候越少，最終呈現(xiàn)出的效率和效果反而越好。

另外更致命的是同步問題：AI 在上下文中認(rèn)為文件是 A 狀態(tài)，實(shí)際文件已經(jīng)被開發(fā)者插手改成 B 狀態(tài)了，然后你讓 AI 基于它的認(rèn)知繼續(xù)修改，結(jié)果可想而知：要么產(chǎn)生混亂，要么 AI 需要再讀一遍所有內(nèi)容。有時(shí)候光是解決這種不同步帶來的問題，花的時(shí)間就比寫代碼還多。

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

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

但現(xiàn)實(shí)就是現(xiàn)實(shí)，至少在當(dāng)下，如果你想體驗(yàn)真正的 vibe coding，CC 可能是唯一選擇。

03認(rèn)識 CC 的邊界和長處

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

如果你讓 CC 分析一段復(fù)雜的代碼邏輯，理解各個(gè)模塊之間的調(diào)用關(guān)系，然后畫一張時(shí)序圖或者架構(gòu)圖，它會完成得相當(dāng)出色。這種需要理解和總結(jié)的任務(wù)，正是 LLM 的看家本領(lǐng)。又或者，你想快速實(shí)現(xiàn)一個(gè)算法、搭建一個(gè)項(xiàng)目框架、編寫測試用例，CC 都能給你滿意的答案。

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

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

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

04思考先行還是實(shí)踐先行

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

在傳統(tǒng)軟件開發(fā)領(lǐng)域，這個(gè)爭論也由來已久。瀑布派說要先設(shè)計(jì)后實(shí)現(xiàn)，敏捷派說要快速迭代。到了 AI 時(shí)代，這個(gè)問題又有了新的含義。

我見過兩種極端的使用方式。第一種是「規(guī)劃魔」：進(jìn)入 Plan Mode 后，和 AI 討論個(gè)把小時(shí)，上下文用光兩三次，從架構(gòu)設(shè)計(jì)到具體實(shí)現(xiàn)，從錯(cuò)誤處理到性能優(yōu)化，事無巨細(xì)地規(guī)劃每一個(gè)細(xì)節(jié)。等到真正開始寫代碼時(shí)，基本上 AI 就是照著計(jì)劃一步步執(zhí)行。另一種則是「莽夫流」：上來就是一句「給我實(shí)現(xiàn)一個(gè) XXX 功能」，然后就看著 AI 噼里啪啦地寫代碼，寫完了發(fā)現(xiàn)不對再改，改完了又發(fā)現(xiàn)新問題，如此循環(huán)往復(fù)。

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

如果你是個(gè)經(jīng)驗(yàn)豐富的開發(fā)者，對項(xiàng)目架構(gòu)已經(jīng)有了清晰的認(rèn)識，那么先進(jìn)行充分的規(guī)劃確實(shí)能讓后續(xù)的實(shí)現(xiàn)更加順暢。特別是對于那些需要遵循特定架構(gòu)模式的既有項(xiàng)目，Plan Mode 能幫你確保 AI 生成的代碼符合項(xiàng)目規(guī)范。我自己就經(jīng)常在 Plan Mode 里和 AI 討論：「我們的項(xiàng)目使用了 MVVM 架構(gòu)，新功能應(yīng)該怎么拆分到各個(gè)層？」 「這部分內(nèi)容已經(jīng)有類似實(shí)現(xiàn)了，你需要參考現(xiàn)有實(shí)現(xiàn)和模式」， 這種討論能讓 AI 更好地理解項(xiàng)目的整體結(jié)構(gòu)，生成的代碼質(zhì)量更高，開發(fā)者對具體代碼的掌控也更好。

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

我個(gè)人的偏好？我更喜歡先進(jìn)入 Plan Mode，和 AI 討論后再開始實(shí)施。對我來說，日常維護(hù)已有代碼庫的工作是占大頭的，我需要更穩(wěn)定和可靠的迭代，先 plan 有利于我掌控全局。但在接觸新技術(shù)棧時(shí)，我也不太愿意直接莽起來。不同技術(shù)棧下，很多開發(fā)的理念是共通的：如何組織可維護(hù)的架構(gòu)（不僅為了人類，也為了 AI 今后進(jìn)行維護(hù)，合理的組織結(jié)構(gòu)還是必要的），如果調(diào)度和安排代碼以保證高效，各個(gè)模塊的連接方式等。就算是新技術(shù)棧，適當(dāng)?shù)挠懻撓啾葻o腦梭哈，也提供了一種更有效的學(xué)習(xí)方式。但是這樣做的代價(jià)是慢，如果著急上線功能，或者寫的是可以無視代碼質(zhì)量的「快消品」，那么事無巨細(xì)的 plan 可能就不太適用了。

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

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

• 探索，計(jì)劃，編碼，提交

• 編寫測試，提交，編碼，迭代，提交

• 編寫代碼，截圖，迭代

相比于直接用 prompt 命令 CC 開始干活，先指導(dǎo)它對代碼庫的現(xiàn)狀進(jìn)行理解，往往會得到更好的結(jié)果。參考這些常見 workflow 并逐漸發(fā)展出自己的使用 AI 的 style，也是一種成長。

05小步迭代還是放飛自我

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

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

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

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

然而，實(shí)際開始嘗試時(shí)，噩夢開始了。首先是一個(gè)小 bug，因?yàn)樯锨械男薷目隙ㄊ菓械每吹?，所以只能描述情況，讓 AI 去修復(fù)；修復(fù)過程中又引入了新問題；再修復(fù)，又有新問題…幾輪下來，代碼庫已經(jīng)面目全非。由于一次性改動太多，開發(fā)者失去了掌控，對于修改不理解，也就無法辨別哪些修改是必要的，哪些又是 AI 為了修復(fù)新 bug 臨時(shí)加上的。最后的結(jié)果，往往只能是 git reset 整個(gè)修改，重新開始。

這類經(jīng)歷讓我明白了一個(gè)道理：AI 生成代碼的能力很強(qiáng)，但它對整體架構(gòu)的把握和長期維護(hù)的考慮還是有限的。一次性生成太多代碼，就像是在黑暗中狂奔——你可能跑得很快，但也可能一頭撞上墻。而且，當(dāng)出現(xiàn)問題時(shí)，調(diào)試的復(fù)雜度會呈指數(shù)級增長。

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

1. 可控性高：每次只改動一小部分，出問題了也容易定位和回滾。

2. 能夠理解：你能跟上 AI 的思路，理解每一步在做什么。

3. 質(zhì)量保證：可以在每一步后進(jìn)行測試，確保代碼質(zhì)量。

4. 學(xué)習(xí)機(jī)會：通過觀察 AI 的實(shí)現(xiàn)方式，你也能學(xué)到新東西。

當(dāng)然，我不是說「放飛自我」就完全不可?。涸谶M(jìn)行新功能實(shí)現(xiàn)時(shí)，如果已經(jīng)進(jìn)行了充分討論和規(guī)劃，那么確實(shí)不太需要人類的監(jiān)督，CC 就可以完成大部分工作。如果你真的想嘗試「放飛自我」的開發(fā)方式，我有幾個(gè)建議：

1. 必須有完善的測試：采用 TDD 的方式，先寫測試（當(dāng)然這也是 AI 來寫），再讓 AI 實(shí)現(xiàn)功能。這樣至少能保證基本的正確性。

2. 做好版本控制：在開始之前創(chuàng)建新分支，隨時(shí)準(zhǔn)備回滾。

3. 分模塊進(jìn)行：即使要一次性完成很多功能，也盡量按模塊來組織，不要把所有東西混在一起。

4. 交叉評審：AI 生成的代碼看起來能跑，但可能隱藏著各種問題，對于生成的代碼，不要照單全收。最簡單的方式，就是找到另一個(gè) AI，將變更喂進(jìn)去，看看有什么需要改進(jìn)的地方，這種迭代往往能收獲不錯(cuò)的結(jié)果。

06任務(wù)規(guī)模和上下文制約

人類和 AI 在某個(gè)方面驚人地相似：處理小任務(wù)時(shí)游刃有余，面對大項(xiàng)目就容易手忙腳亂。對 CC 來說，這個(gè)問題更加明顯，因?yàn)樗€要面對一個(gè)硬性限制——200k 的上下文窗口。在當(dāng)前動輒模型給 1M 窗口的年代，這個(gè)限制又是確實(shí)相當(dāng)痛苦。

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

所以，如何在有限的上下文窗口內(nèi)完成復(fù)雜任務(wù)，就成了使用 CC 的一門必修課。

任務(wù)拆解是關(guān)鍵

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

我：我想實(shí)現(xiàn)一個(gè)用戶認(rèn)證系統(tǒng)，幫我拆解需求 AI：好的，讓我們拆解一下需要完成的任務(wù)： 1. 設(shè)計(jì)數(shù)據(jù)庫表結(jié)構(gòu)（用戶表、會話表等） 2. 實(shí)現(xiàn)注冊功能（驗(yàn)證、加密、存儲） 3. 實(shí)現(xiàn)登錄功能（驗(yàn)證、生成 token） 4. 實(shí)現(xiàn)中間件（驗(yàn)證 token、刷新機(jī)制） 5. 添加測試用例 ...

對于一個(gè) session 難以完成的任務(wù)，可以讓 AI 把討論內(nèi)容進(jìn)行文檔化，保存到項(xiàng)目里（比如dev-note/auth-implementation-plan.md）。這樣，即使換了新的 session，你也可以讓 AI 讀取這個(gè)文檔，快速恢復(fù)上下文。

使用 Subagent

CC 最近推出的 Subagent 功能在一定程度上緩解了這個(gè)問題。在以前，當(dāng) CC 使用 Task 工具進(jìn)行任務(wù)時(shí)，實(shí)際上是在一個(gè)全新的上下文中進(jìn)行工作。這相當(dāng)于擴(kuò)展了主 Session 的上下文窗口。

以前我們只能通過 prompt 技巧來「誘導(dǎo)」CC 使用 Task 工具，效果時(shí)好時(shí)壞?，F(xiàn)在有了專門的 subagent 配置，穩(wěn)定性大大提升。你可以為不同類型的任務(wù)創(chuàng)建專門的 agent：

• 代碼分析 agent：專門負(fù)責(zé)理解現(xiàn)有代碼結(jié)構(gòu)

• 代碼審查 agent：檢查代碼質(zhì)量和潛在問題

• 測試 agent：編寫和運(yùn)行測試用例

• Git agent：處理代碼提交和 PR

通過合理鏈?zhǔn)秸{(diào)用這些 agent，即使是大型任務(wù)也有機(jī)會能在同一個(gè) Session 里有條不紊地完成。每個(gè) agent 都在獨(dú)立的上下文中工作，不會相互干擾，也不會耗盡主 session 的上下文。

在合適的時(shí)機(jī)手動 compact

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

另一個(gè)技巧是：對于相對獨(dú)立的任務(wù)，干脆新開一個(gè) session。反正你已經(jīng)把任務(wù)計(jì)劃文檔化了，新 session 讀取文檔就能快速上手。這比在一個(gè)快要爆炸的 session 里硬撐要明智得多。

當(dāng)前在 AI 輔助編程中，上下文窗口依然是稀缺資源，要像管理內(nèi)存一樣管理它。合理規(guī)劃、及時(shí)清理、必要時(shí)「換個(gè)房間」，才能讓 vibe coding 的體驗(yàn)保持流暢。

07善用命令和周邊工具Command 和 Hooks

我有個(gè)暴論：凡是重復(fù)了兩次以上的類似 prompt 都應(yīng)該用命令來表述！

每次都輸入類似的 prompt 真的非常無趣：「運(yùn)行測試并修復(fù)失敗的用例」、「提交代碼時(shí)請使用規(guī)范的 commit message」…如果你發(fā)現(xiàn)自己在重復(fù)類似的請求，立刻停下來，花一分鐘配置一個(gè) command。

Command 相比 subagent 有個(gè)巨大的優(yōu)勢：它擁有完整的當(dāng)前會話上下文。如果你的任務(wù)和當(dāng)前正在進(jìn)行的工作高度相關(guān)，那么 command 的效率會更高。比如我常用的幾個(gè)：

• /test-and-fix：運(yùn)行測試，如果有失敗自動嘗試修復(fù)

• /review：對當(dāng)前修改進(jìn)行代碼審查，給出改進(jìn)建議

• /commit-smart：分析改動，生成合適的 commit message 并提交

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

MCP

通過 MCP 補(bǔ)充模型不知道的知識。我最常用的幾個(gè)場景：

最新的 Apple 文檔

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

項(xiàng)目管理集成

通過 mcp-atlassian 連接 JIRA，可以讓 CC 直接讀取和更新任務(wù)狀態(tài)，或者自動將分析的情況和實(shí)現(xiàn)進(jìn)行回復(fù)，保持溝通暢通。

LSP 支持

CC 暫時(shí)還原生支持 LSP，但通過 mcp-language-server，可以獲得準(zhǔn)確的代碼補(bǔ)全和類型信息。特別是對于那些 CC 不太熟悉的語言，這個(gè)功能價(jià)值巨大。

配置 MCP 可能需要一點(diǎn)時(shí)間，但絕對物有所值。它讓 CC 從一個(gè)通用的工具變成了為你量身定制的助手。

編譯、分析和測試

永遠(yuǎn)記?。篈I 生成的代碼，未經(jīng)測試都是廢品。

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

1. 在 CLAUDE.md 中詳細(xì)列出項(xiàng)目的編譯命令、測試命令、linter 配置

2. 每完成一個(gè)小功能，立即編譯

3. 編譯通過后，運(yùn)行相關(guān)測試

4. 測試通過后，運(yùn)行 linter 和 formatter

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

如果你的項(xiàng)目支持 TDD，那就更好了。先讓 AI 根據(jù)需求寫測試，然后再實(shí)現(xiàn)功能。這樣生成的代碼質(zhì)量通常會高很多，因?yàn)?AI 有了明確的目標(biāo)。

當(dāng)然，根據(jù)編譯器的廢柴程度（你們大概應(yīng)該知道我在說誰..）和項(xiàng)目的規(guī)模，編譯一次的時(shí)間代價(jià)可能會很大。這種情況下，我會拆分模塊，盡量只去編譯改過的模塊。如果這比較困難，那么也可以使用git worktree來創(chuàng)建多個(gè)工作目錄：這樣你可以讓多個(gè)任務(wù)并行進(jìn)行，互不干擾，也算是彌補(bǔ)等待編譯所帶來的時(shí)間損失。

Code 之外，大有可為

別把 CC 只當(dāng)成寫代碼的工具，它的能力遠(yuǎn)不止于此。

我現(xiàn)在的日常使用場景：

• 代碼提交和 PR：寫完代碼后，直接讓 CC 分析改動、生成 commit message、推送代碼、創(chuàng)建 PR。它生成的 PR 描述往往比我自己寫的還要清晰。

• 撰寫技術(shù)文檔和 wiki: 讓 CC 分析代碼生成 API 文檔、更新 README、編寫使用示例。它的文檔往往更加規(guī)范和完整，甚至不會出現(xiàn)語法錯(cuò)誤。

• JIRA 更新：完成任務(wù)后，讓 CC 更新 ticket 狀態(tài)、添加評論回復(fù)用戶、甚至創(chuàng)建新的子任務(wù)。再也不用在網(wǎng)頁上點(diǎn)來點(diǎn)去了。

• 數(shù)據(jù)處理：需要批量處理文件、轉(zhuǎn)換格式、清洗數(shù)據(jù)？以前我會寫腳本，現(xiàn)在直接描述需求讓 CC 來做。而且每次需求不同時(shí)，不用維護(hù)一堆一次性腳本了。

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

最后，個(gè)人強(qiáng)烈推薦配一個(gè)好的麥克風(fēng)。在 vibe coding 時(shí)代，用語音輸入描述需求，比打字更加自然流暢。現(xiàn)在的語音識別已經(jīng)很準(zhǔn)確了，而中英文混雜也能處理得很好。想不到當(dāng)年為了當(dāng)游戲主播買的麥克風(fēng)，吃灰這么多年后，終于在今天找到了真正的用武之地。

當(dāng)然，Mac 系統(tǒng)自帶的語音輸入是幼兒園級別，從準(zhǔn)確性和易用性上都不值一提。你肯定需要一款 AI 轉(zhuǎn)譯的 app，我也試用過一些，總結(jié)幾個(gè)當(dāng)前市面上的優(yōu)秀選擇：

• MacWhisper：以前買的，現(xiàn)在在用，原生 macOS app，作者支持速度很快。

• VoiceInk：提供開源以供確認(rèn)，隱私安全，付費(fèi)省心。

• Wispr Flow：訂閱制，小貴，但勝在 UI 漂亮，UX 流暢。

它們都是很不錯(cuò)的選擇，功能也都類似。除了基礎(chǔ)的語音識別和輸入外，再配合轉(zhuǎn)譯后接入 LLM 進(jìn)行文本潤色/修改的能力，根據(jù)不同場景將我的語言自動轉(zhuǎn)為合適的文字和格式。這些 app 把人機(jī)交互提升了一個(gè)檔次，語音輸入的內(nèi)容往往比我自己勞心勞力組織的文字還要清晰精確?，F(xiàn)在，絕大多數(shù)情況下，我和同事用不同語言交流時(shí)，以及自己在書寫 PR 和各種文檔時(shí)，我?guī)缀跻捕际钦f中文，然后讓 AI 當(dāng)我的「同傳」轉(zhuǎn)換為合適的目標(biāo)語言，以此確保準(zhǔn)確和及時(shí)。

08體感降智和更多限制

接下來要說的內(nèi)容，有些是我自己的感受，有些是社區(qū)里朋友們的吐槽。很多東西無法證實(shí)或證偽，大家權(quán)且一聽。

Opus 遠(yuǎn)強(qiáng)于 Sonnet

這幾乎是板上釘釘?shù)氖聦?shí)：Opus 的效果比 Sonnet 好很多。畢竟價(jià)格擺在那里，Opus 是 Sonnet 的 5 倍。100 美金的 max 訂閱，5 小時(shí)時(shí)間窗口的 Opus 只能跑幾個(gè)小任務(wù)額度就用光了。200 美金的訂閱也只是勉強(qiáng)夠用。

如果你是 100 美金檔的用戶，建議養(yǎng)成手動切換模型的習(xí)慣。日常用 Sonnet 處理簡單任務(wù)，遇到復(fù)雜的架構(gòu)設(shè)計(jì)或者棘手的 bug，再切到 Opus。

時(shí)間玄學(xué)

這個(gè)聽起來很離譜，但確實(shí)有體感：美國半夜（也就是北京時(shí)間的白天）的效果比美國白天要好。實(shí)際上軟件開發(fā)最活躍的還是中美兩國，而 Anthropic 在中國其實(shí)是沒有正規(guī)渠道能用的。所以可能是因?yàn)槊绹估锸褂玫娜松?，服?wù)器壓力小，從而模型性能不會退化？總之，如果北京時(shí)間大清早遇到無法解決的問題，留到下午時(shí)段處理，可能會有驚喜。

降智疑云

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

限制的陰霾

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

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

一些應(yīng)對策略

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

1. 分級使用：簡單任務(wù)用 Sonnet，復(fù)雜任務(wù)才上 Opus

2. 錯(cuò)峰使用：避開美國工作時(shí)間，選擇服務(wù)器負(fù)載低的時(shí)段

3. 提高 prompt 質(zhì)量：一次說清楚，減少來回對話消耗的 token

4. 合理使用 subagent：把消耗大的任務(wù)分配給 subagent

5. 保持多個(gè)選擇：雖然 CC 目前最強(qiáng)，但保持對其他工具的關(guān)注

09總結(jié)和未來展望

一個(gè)半月的 CC 使用經(jīng)歷，有驚喜，有擔(dān)憂，有對未來的憧憬，也有對現(xiàn)實(shí)的無奈。但總的來說，我感受到的是自己切實(shí)地站在在歷史的進(jìn)程之中。Vibe coding 不僅僅是一種新的編程方式，更是一種全新的思維模式。它要求我們重新思考什么是編程、什么是創(chuàng)造、什么是價(jià)值。在這個(gè) AI 與人類共舞的時(shí)代，愿我們都能找到屬于自己的節(jié)奏。

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

轉(zhuǎn)載原創(chuàng)文章請?zhí)砑游⑿牛篺ounderparker