來源：AI寒武紀(jì)

　　Eyad 曾作為軟件工程師（SWE）在亞馬遜、迪士尼和第一資本工作了7年，交付的代碼觸達(dá)數(shù)百萬用戶，構(gòu)建的系統(tǒng)不容有失。現(xiàn)在，他是一家為企業(yè)構(gòu)建智能體的創(chuàng)業(yè)公司的CTO，而 Claude Code 是他日常工作的核心驅(qū)動(dòng)力

　　這份初學(xué)者指南，濃縮了Eyad使用 Claude 構(gòu)建處理大型公司復(fù)雜工作負(fù)載的穩(wěn)健系統(tǒng)后，所學(xué)到的一切。希望能對你有所幫助

　　先思考，后動(dòng)手

　　大多數(shù)人認(rèn)為，使用 Claude Code 等 AI 工具時(shí)，第一步就是開始打字（或說話）。但這恰恰是你能犯下的最大錯(cuò)誤之一。你真正需要做的第一件事是思考。

　　十次里有十次，我在“規(guī)劃模式”下獲得的輸出，都遠(yuǎn)勝于我直接開口、把所有想法傾倒給 Claude Code 的結(jié)果。兩者效果天差地別。

　　對一些人來說，這可能說起來容易做起來難。你可能沒有多年的軟件工程經(jīng)驗(yàn)來自行思考。對此，我有兩點(diǎn)建議：

　　1.開始學(xué)習(xí)。如果你從不掌握這項(xiàng)技能，你就在限制自己，哪怕每次只學(xué)一點(diǎn)點(diǎn)。

　　2.與 ChatGPT/Gemini/Claude 進(jìn)行深入的來回交流。精確描述你想構(gòu)建什么，詢問 LLM 在系統(tǒng)設(shè)計(jì)方面有哪些選項(xiàng)，最終你們共同確定一個(gè)解決方案。你和 LLM 應(yīng)該互相提問，而不是單向灌輸。

　　這一點(diǎn)適用于所有事，包括像總結(jié)郵件這樣的小任務(wù)。在讓 Claude 構(gòu)建功能前，先思考架構(gòu)；在讓它重構(gòu)代碼前，先思考最終應(yīng)有的形態(tài)；在讓它調(diào)試前，先思考你對問題已知的確切信息。你在規(guī)劃模式中提供的信息越多，輸入質(zhì)量就越高，輸出質(zhì)量也自然會(huì)越好。

　　這個(gè)模式始終如一：先思考，再輸入，比先輸入、指望 Claude 自己搞明白，能產(chǎn)生好得多的結(jié)果。

　　這就引出了我的下一點(diǎn)：架構(gòu)。尤其在軟件工程中，只給出一個(gè)最終目標(biāo)而不提供過程，就像只告訴一個(gè)人目的地卻不給地圖。這為如何到達(dá)目的地留下了巨大的“自由發(fā)揮”空間，而這正是 AI 生成代碼問題的核心所在。

　　比較一下兩種說法的區(qū)別：寬泛的“給我建一個(gè)認(rèn)證系統(tǒng)”，與明確的“使用現(xiàn)有的 User 模型構(gòu)建郵箱/密碼認(rèn)證，將 session 存儲(chǔ)在 Redis 中并設(shè)置 24 小時(shí)過期，同時(shí)添加中間件保護(hù) /api/protected 下的所有路由。” 你會(huì)發(fā)現(xiàn)差異巨大。

　　連按兩次Shift + Tab鍵，即可進(jìn)入規(guī)劃模式。相信我，這會(huì)花掉你5分鐘，但能為你省下后續(xù)數(shù)小時(shí)的調(diào)試時(shí)間。

　　CLAUDE.md：你的項(xiàng)目專屬說明書

　　CLAUDE.md 是一個(gè) Markdown 文件。Markdown 是一種 AI 模型處理得非常好的文本格式，而 Claude 對它的處理能力尤其出色。

　　當(dāng)你啟動(dòng)一個(gè) Claude Code 會(huì)話時(shí)，它做的第一件事就是讀取你的CLAUDE.md文件。文件中的每條指令都會(huì)塑造 Claude 處理你項(xiàng)目的方式。這本質(zhì)上是 Claude 在每次對話前都會(huì)閱讀的“入職材料”。

　　大多數(shù)人要么完全忽略它，要么用一些垃圾信息把它填滿，結(jié)果反而讓 Claude 表現(xiàn)更差。信息過多或過少都存在一個(gè)閾值，超過或低于這個(gè)閾值都會(huì)導(dǎo)致模型輸出質(zhì)量下降。

　　以下是真正重要的幾點(diǎn)：

　　1.保持簡短。Claude 一次只能可靠地遵循大約150到200條指令，而 Claude Code 的系統(tǒng)提示本身已經(jīng)占用了約50條。你添加的每條指令都在爭奪它的注意力。如果你的CLAUDE.md像一本小說，Claude 就會(huì)開始隨機(jī)忽略某些內(nèi)容，而你無從知曉。

　　2.內(nèi)容要針對你的項(xiàng)目。不要解釋什么是“components”文件夾，Claude 知道。告訴它那些項(xiàng)目特有的、奇怪的東西，比如那些真正重要的 bash 命令。所有屬于你工作流的東西都應(yīng)該放進(jìn)去。

　　3.解釋原因，而不僅僅是做什么。在這方面，Claude 有點(diǎn)像人。當(dāng)你給出指令背后的原因時(shí)，它會(huì)比只被告知做什么時(shí)執(zhí)行得更好?！笆褂?TypeScript 嚴(yán)格模式”是可以的，但“使用 TypeScript 嚴(yán)格模式，因?yàn)槲覀冊螂[式的 any 類型導(dǎo)致過生產(chǎn)環(huán)境的 bug”則更佳。這個(gè)“為什么”為 Claude 在處理你未預(yù)料到的判斷時(shí)提供了上下文。你會(huì)驚訝于這種方法的有效性。

　　4.持續(xù)更新。在工作時(shí)按下#鍵，Claude 會(huì)自動(dòng)將指令添加到你的CLAUDE.md中。每當(dāng)你發(fā)現(xiàn)自己第二次糾正 Claude 同一個(gè)問題時(shí)，這就是一個(gè)信號：它應(yīng)該被寫進(jìn)文件里。隨著時(shí)間的推移，你的CLAUDE.md會(huì)成為一份關(guān)于你代碼庫如何運(yùn)作的活文檔。

　　一個(gè)糟糕的CLAUDE.md看起來像為新員工寫的文檔。一個(gè)好的CLAUDE.md看起來像你為明天失憶的自己留下的筆記。

　　理解上下文窗口的局限性

　　例如，Opus 4.5 擁有20萬 token 的上下文窗口。但大多數(shù)人沒有意識到的是：在遠(yuǎn)未達(dá)到100%使用率時(shí)，模型的性能就開始衰退了。（具體情況取決于你是通過 API 還是桌面應(yīng)用使用）

　　當(dāng)上下文使用率達(dá)到20-40%左右時(shí)，輸出質(zhì)量就開始下降，即使下降得不明顯。如果你曾遇到 Claude Code 進(jìn)行壓縮后（通過/compact命令）仍然給出糟糕輸出的情況，這就是原因。在壓縮發(fā)生前，模型性能已經(jīng)退化，而壓縮并不能神奇地恢復(fù)質(zhì)量。

　　你發(fā)送的每條消息、Claude 讀取的每個(gè)文件、它生成的每段代碼、每個(gè)工具的返回結(jié)果——所有這些都會(huì)累積。一旦質(zhì)量開始下降，增加更多的上下文只會(huì)讓情況變得更糟。以下是一些避免上下文質(zhì)量糟糕的有效方法：

　　?限定對話范圍。每個(gè)功能或任務(wù)使用一個(gè)獨(dú)立的對話。不要在同一個(gè)對話中既構(gòu)建認(rèn)證系統(tǒng)又重構(gòu)數(shù)據(jù)庫層。上下文會(huì)混雜在一起，讓 Claude 感到困惑。

　　?使用外部記憶。如果你在處理復(fù)雜問題，讓 Claude 把計(jì)劃和進(jìn)展寫到實(shí)際文件中（我使用SCRATCHPAD.md或plan.md）。這些文件可以跨會(huì)話持久存在。當(dāng)你第二天回來時(shí)，Claude 可以讀取文件，從你離開的地方繼續(xù)，而不是從零開始。

　　?復(fù)制-粘貼重置法。這是我經(jīng)常使用的一個(gè)技巧。當(dāng)上下文變得臃腫時(shí)，我從終端復(fù)制所有重要的內(nèi)容，運(yùn)行/compact獲得一個(gè)摘要，然后用/clear完全清空上下文，最后只把關(guān)鍵信息粘貼回去。這樣既保留了關(guān)鍵信息，又獲得了清新的上下文，遠(yuǎn)比讓 Claude 在退化的上下文中掙扎要好。

　　?知道何時(shí)清空。如果一個(gè)對話已經(jīng)偏離軌道或積累了大量不相關(guān)的上下文，直接用/clear重新開始。這比試圖在混亂中繼續(xù)工作要好。Claude 仍然會(huì)讀取你的CLAUDE.md，所以你不會(huì)丟失項(xiàng)目上下文。十次中有九次，使用/clear實(shí)際上是更好的選擇。

　　有效的心智模型是：Claude 是無狀態(tài)的。每次對話都從零開始，除了你明確提供給它的信息。請據(jù)此進(jìn)行規(guī)劃。

　　Prompt 即一切

　　人們花數(shù)周時(shí)間學(xué)習(xí)框架和工具，卻花零時(shí)間學(xué)習(xí)如何與那個(gè)實(shí)際生成他們代碼的東西進(jìn)行溝通。

　　Prompt 工程不是什么神秘藝術(shù)，它可能是最基本的溝通形式。和任何溝通一樣，清晰明確總比含糊不清能獲得更好的結(jié)果。每一次都是如此。

　　真正有幫助的做法是：

　　?具體說明你想要什么。“構(gòu)建一個(gè)認(rèn)證系統(tǒng)”給了 Claude 它會(huì)濫用的創(chuàng)作自由。“使用這個(gè)已有的 User 模型構(gòu)建郵箱/密碼認(rèn)證，將 session 存入 Redis，并添加中間件保護(hù) /api/protected 下的路由”則給了 Claude 一個(gè)清晰的目標(biāo)。

　　?告訴它不該做什么。Claude 有其傾向性。特別是 Claude 4.5 喜歡過度工程化——額外的文件、不必要的抽象、你沒要求過的靈活性。如果你想要最簡化的東西，就說：“保持簡單。不要添加我沒要求的抽象。如果可能，只用一個(gè)文件?！?同時(shí)，一定要交叉檢查 Claude 的產(chǎn)出，你不想最終背上技術(shù)債。

　　?提供“為什么”的背景。“我們需要這個(gè)功能速度快，因?yàn)樗诿總€(gè)請求上都會(huì)運(yùn)行”會(huì)改變 Claude 解決問題的方式?！斑@是一個(gè)我們會(huì)扔掉的原型”則會(huì)改變它在權(quán)衡取舍時(shí)的考量。Claude 無法讀懂你心中那些未提及的約束。

　　記住：輸出決定一切，但輸出只來源于輸入。如果你的輸出很差，那說明你的輸入很差。別無他法。

　　壞輸入 = 壞輸出

　　當(dāng)?shù)玫讲缓玫慕Y(jié)果時(shí)，人們會(huì)責(zé)怪模型。“Claude 不夠聰明”或者“我需要一個(gè)更好的模型”。

　　現(xiàn)實(shí)是：問題出在你身上。如果你用像 Opus 4.5 這樣的好模型卻持續(xù)得到糟糕的輸出，那意味著你的輸入和你的 Prompt 很差。就是這樣。

　　模型固然重要，但模型質(zhì)量如今已是基本門檻。瓶頸幾乎總是在人這一邊：你如何構(gòu)建 Prompt，如何提供上下文，如何清晰地傳達(dá)你真正想要什么。

　　如果你持續(xù)得到糟糕的結(jié)果，解決方法不是換模型，而是提升以下能力：

　　?你如何編寫 Prompt：具體 > 模糊，約束 > 開放，示例 > 描述。

　　?你如何組織請求：將復(fù)雜任務(wù)分解成步驟，在實(shí)現(xiàn)前先就架構(gòu)達(dá)成一致，審查輸出并迭代。

　　?你如何提供上下文：Claude 需要知道什么才能做好這件事？你做了哪些 Claude 看不到的假設(shè)？

　　話雖如此，不同模型之間確實(shí)存在差異：

　　?Sonnet更快、更便宜。它非常適合執(zhí)行路徑明確的任務(wù)——編寫樣板代碼、根據(jù)具體計(jì)劃進(jìn)行重構(gòu)、實(shí)現(xiàn)你已做出架構(gòu)決策的功能。

　　?Opus更慢、更貴。它更擅長復(fù)雜的推理、規(guī)劃以及需要 Claude 深入思考權(quán)衡的任務(wù)。

　　一個(gè)有效的工作流是：用 Opus 進(jìn)行規(guī)劃和架構(gòu)決策，然后切換到 Sonnet (在 Claude Code 中按Shift+Tab) 進(jìn)行實(shí)現(xiàn)。你的CLAUDE.md確保兩個(gè)模型在相同的約束下運(yùn)作，使得交接過程非常順暢。

　　善用工具與配置：MCP、鉤子和命令

　　Claude 擁有大量的功能：MCP 服務(wù)器、鉤子（Hooks）、自定義斜杠命令、settings.json配置、技能（Skills）、插件（Plugins）。

　　你不需要全部都用上。但你應(yīng)該去嘗試和實(shí)驗(yàn)，因?yàn)椴粚?shí)驗(yàn)，你可能就在浪費(fèi)時(shí)間或金錢。

　　?MCP (Model Context Protocol)讓 Claude 連接到外部服務(wù)，如 Slack、GitHub、數(shù)據(jù)庫、API。如果你發(fā)現(xiàn)自己總是在從一個(gè)地方復(fù)制信息到 Claude，很可能有一個(gè) MCP 服務(wù)器能自動(dòng)完成這件事。

　　?鉤子 (Hooks)讓你在 Claude 進(jìn)行更改前后自動(dòng)運(yùn)行代碼。想讓 Prettier 在 Claude 碰過的每個(gè)文件上運(yùn)行？用鉤子。想在每次編輯后進(jìn)行類型檢查？用鉤子。這能立即捕獲問題，而不是讓它們堆積起來。

　　?自定義斜杠命令是你重復(fù)使用的 Prompt，被打包成了命令。創(chuàng)建一個(gè).claude/commands文件夾，添加包含你 Prompt 的 Markdown 文件，然后你就可以用/commandname來運(yùn)行它們。

　　如果你有 Pro Max 計(jì)劃（我每月支付200美元），為什么不試試 Claude 提供的所有功能呢？看看哪些有效，哪些無效。反正你已經(jīng)付了錢。

　　而且，不要因?yàn)槟硺訓(xùn)|西第一次嘗試失敗就放棄。這些模型幾乎每周都在改進(jìn)。一個(gè)月前行不通的東西，現(xiàn)在可能就可以了。

　　當(dāng) Claude 卡住時(shí)怎么辦

　　有時(shí) Claude 會(huì)陷入循環(huán)。它嘗試同樣的事情，失敗，再試，再失敗，如此往復(fù)?；蛘咚孕诺貙?shí)現(xiàn)了一個(gè)完全錯(cuò)誤的東西，你得花二十分鐘去解釋為什么錯(cuò)了。

　　發(fā)生這種情況時(shí)，人的本能是繼續(xù)推進(jìn)：給更多指令、更多修正、更多上下文。但現(xiàn)實(shí)是，更好的做法是徹底改變方法。

　　?清空對話。累積的上下文可能正在迷惑它。/clear給你一個(gè)全新的開始。

　　?簡化任務(wù)。如果 Claude 難以處理一個(gè)復(fù)雜任務(wù)，把它分解成更小的部分。在組合之前，確保每個(gè)部分都能正常工作。但實(shí)際上，如果 Claude 在復(fù)雜任務(wù)上掙扎，這通常意味著你的規(guī)劃模式做得不夠充分。

　　?展示而非告知。如果 Claude 一直誤解你的意圖，自己寫一個(gè)最小化的例子?！翱?，輸出應(yīng)該長這樣。現(xiàn)在把這個(gè)模式應(yīng)用到其余部分?！?Claude 非常擅長理解成功的范例并遵循它。

　　?創(chuàng)新思路。嘗試一個(gè)不同的角度。有時(shí)你描述問題的方式與 Claude 的“思維”方式不匹配。重新表述——比如從“處理這些狀態(tài)轉(zhuǎn)換”變?yōu)椤皩⒋藢?shí)現(xiàn)為一個(gè)狀態(tài)機(jī)”——可能會(huì)打開僵局。

　　這里的元技能是及早識別出你正處于一個(gè)循環(huán)中。如果你已經(jīng)把同一件事解釋了三遍而 Claude 仍然不明白，更多的解釋是無濟(jì)于事的。改變點(diǎn)什么吧。

　　構(gòu)建系統(tǒng)，而非一次性任務(wù)

　　從 Claude 獲得最大價(jià)值的人，不是用它來完成一次性任務(wù)，而是構(gòu)建以 Claude 為組件的系統(tǒng)。

　　Claude Code 的-p標(biāo)志支持無頭模式（headless mode）。它會(huì)運(yùn)行你的 Prompt 并輸出結(jié)果，而無需進(jìn)入交互界面。這意味著你可以用腳本調(diào)用它，將輸出通過管道傳遞給其他工具，與 bash 命令鏈接，將其集成到自動(dòng)化工作流中。

　　企業(yè)正在用它來實(shí)現(xiàn)自動(dòng) PR 審查、自動(dòng)支持工單回復(fù)、自動(dòng)日志記錄和文檔更新。所有這些都被記錄、可審計(jì)，并根據(jù)有效和無效的反饋隨著時(shí)間推移而改進(jìn)。

　　這是一個(gè)飛輪效應(yīng)：Claude 犯錯(cuò) -> 你審查日志 -> 你改進(jìn)CLAUDE.md或工具 -> Claude 下次做得更好。這種改進(jìn)是復(fù)合式的。我現(xiàn)在正在嘗試讓 Claude 能夠自我改進(jìn)它的CLAUDE.md文件。

　　如果你只在交互模式下使用 Claude，你就在浪費(fèi)它的價(jià)值。思考一下，在你工作流的哪些環(huán)節(jié)，Claude 可以在沒有你監(jiān)督的情況下運(yùn)行。

　　要點(diǎn)總結(jié)

　　先思考，后動(dòng)手。規(guī)劃比直接開聊能產(chǎn)生好得多的結(jié)果

　　CLAUDE.md 是你的杠桿點(diǎn)。保持簡短、具體，解釋原因，并持續(xù)更新。這個(gè)文件影響每一次交互

　　上下文在30%使用率時(shí)就開始退化，而不是100%。使用外部記憶，限定對話范圍，并善用“復(fù)制-粘貼重置”技巧

　　架構(gòu)比任何事都重要。你不能跳過規(guī)劃。沒有預(yù)先思考結(jié)構(gòu)，輸出就會(huì)很糟糕

　　輸出源于輸入。如果你用好模型得到壞結(jié)果，是你的 Prompt 需要改進(jìn)。提升你的溝通能力

　　實(shí)驗(yàn)工具和配置。MCP、鉤子、斜杠命令。如果你是付費(fèi)用戶，把所有功能都試一遍

　　卡住時(shí)，改變方法。不要陷入循環(huán)。清空、簡化、展示、重新構(gòu)思

　　構(gòu)建系統(tǒng)，而非一次性任務(wù)。利用無頭模式、自動(dòng)化，并隨時(shí)間記錄和改進(jìn)。

　　source：

　　https://x.com/eyad_khrais/status/2010076957938188661?s=20