不用寫計(jì)劃，但先做這件事

大多數(shù)人用Claude Code的方式是auto mode。這很方便，但有個隱患：沒有刻意習(xí)慣的auto mode，本質(zhì)上就是加速版的vibe coding——感覺對了就往下寫，寫到哪算哪。

我用的也是auto mode，但有一套方法讓它保持"scribe"屬性：計(jì)劃驅(qū)動、先寫再想、刻意推進(jìn)。上一篇文章講了骨架——一個四步計(jì)劃循環(huán)，讓跨會話的工作不跑偏。這篇講肌肉——三個具體做法讓骨架動起來。

先說第一個，也是最重要的一個。它發(fā)生在創(chuàng)建計(jì)劃之前。

在讓Claude寫計(jì)劃之前，我會先喂給它所有相關(guān)材料：Jira工單、GitHub討論、現(xiàn)有的設(shè)計(jì)文檔。然后讓它去調(diào)查：讀我們要改動的代碼，追蹤接口，看看代碼庫里類似問題是怎么解決的。調(diào)查完之后，我才要設(shè)計(jì)方案。

這時候回來的不是計(jì)劃，而是一場設(shè)計(jì)討論。Claude會給出幾個選項(xiàng)，帶上置信度估計(jì)："70/30，我傾向選項(xiàng)A，因?yàn)樗鼜?fù)用了現(xiàn)有的中間件。"我可能會反駁，可能會同意，可能會要第三個選項(xiàng)。來回幾輪，方案才會收斂。

這靠的是我全局CLAUDE.md里的一條指令：

"當(dāng)有多個備選方案時，不要自動假設(shè)用戶想要最可能的那個。把備選方案展示給用戶，列出優(yōu)缺點(diǎn)，讓用戶選。給出你對每個選項(xiàng)的置信度估計(jì)。"

沒有這條指令，Claude會直接選最可能的方案開干。有了它，設(shè)計(jì)討論自然發(fā)生。Claude變成呈現(xiàn)權(quán)衡的協(xié)作者，而不是猜你想要什么的助手。

設(shè)計(jì)方案確定后，我才運(yùn)行/gh-create-plan。這是claude-plan-skills里的一個自定義技能，把對話轉(zhuǎn)成結(jié)構(gòu)化的GitHub issue。計(jì)劃里包含決策、執(zhí)行步驟、驗(yàn)收標(biāo)準(zhǔn)。對比很明顯：沒有上下文的"實(shí)現(xiàn)功能X"會讓Claude猜設(shè)計(jì)、碰錯模塊；完整的上下文、代碼調(diào)查、設(shè)計(jì)對話，才能產(chǎn)出貼合代碼庫的計(jì)劃。

第二個做法關(guān)于持續(xù)性。Claude Code的對話有上下文窗口。窗口滿了，auto-compaction會靜默丟棄早期內(nèi)容。對話繼續(xù)，但質(zhì)量下滑：早先做的決定被遺忘，風(fēng)格漂移，重復(fù)勞動開始出現(xiàn)。

我解決這個問題的辦法是：把計(jì)劃當(dāng)成錨點(diǎn)。不是讓對話無限延伸，而是在關(guān)鍵節(jié)點(diǎn)主動結(jié)束當(dāng)前對話，用/gh-create-plan把狀態(tài)固化成GitHub issue，然后新開一個對話繼續(xù)。每個新對話以計(jì)劃issue為起點(diǎn)，Claude先讀計(jì)劃，再讀相關(guān)代碼，然后繼續(xù)執(zhí)行。這樣上下文窗口的壓縮就不會丟失關(guān)鍵決策。

第三個做法是關(guān)于反饋循環(huán)。計(jì)劃執(zhí)行過程中，我會讓Claude在關(guān)鍵步驟后做迷你復(fù)盤：這一步做了什么，遇到了什么意外，下一步是否需要調(diào)整計(jì)劃。這些復(fù)盤不寫在計(jì)劃里，而是作為評論追加到GitHub issue。它們成為下一輪對話的上下文，讓計(jì)劃進(jìn)化而不是僵化。

這三個做法的共同點(diǎn)是：把思考過程外化。不是讓Claude替我想，而是讓它幫我結(jié)構(gòu)化地想。vibe coding的問題不是用AI寫代碼，而是用AI代替思考。scribe coding的區(qū)別在于，你在markdown里做思考，AI只在代碼里做打字。

auto mode讓后者變得太容易，以至于前者被跳過。這三個做法是強(qiáng)制把思考環(huán)節(jié)加回來的機(jī)制。