我最早注意到這個工具是因為換了一臺新電腦重新配環(huán)境時折騰到凌晨實在不想再手動敲一遍初始化腳本。當時看到 GitHub 趨勢榜上掛著Claude Code CLI這個關鍵詞本以為是又一個需要折騰半天才能跑通的終端玩具沒想到裝上之后它真的改變了我的日常編碼習慣。今天這篇教程我打算從一個普通開發(fā)者的視角把這套終端里的 AI 編程助手從頭到尾講清楚包括安裝、配置、核心命令、實際干活流程以及我在頭一周踩過的那些坑。這篇快速入門適合誰看如果你用過命令行工具但沒接觸過 AI 編程助手或者你已經用過一些圖形界面里的 AI 插件卻想知道為什么有人在終端里也能爽快地讓它改代碼那這篇內容正好。我會用我自己的真實操作記錄來講盡量做到每一步都能照著做而不是只講概念。1. 先搞清楚這個 CLI 到底解決什么問題1.1 從圖形界面回到終端的邏輯過去幾年AI 編程助手基本都是圖形化的打開一個 IDE裝個插件選中代碼右鍵喚起對話框。這種方式確實直觀但它有個結構性缺陷——AI 和你的代碼庫之間是割裂的。它能看到你選中的那幾行代碼卻看不到整個項目的結構、依賴關系、配置文件、測試用例。于是你經常需要手動把多個文件的內容復制粘貼進對話框或者反復描述第X個文件的函數(shù)在哪里效率很快就掉下來了。CLI 版本的思路完全不同。它直接跑在你的項目根目錄里天然擁有當前工作目錄的讀寫權限。它不僅能看到你當前打開的文件還能自己去瀏覽整個目錄樹找到相關引用執(zhí)行測試命令甚至在你確認后修改多個文件。這種以項目為上下文的交互模式才是它最核心的價值。我打個比方圖形界面里的 AI 像是一個只能隔著玻璃看代碼的顧問你把代碼舉到玻璃前它才能看到而 CLI 里的 AI 像是直接坐在你的工位上文件、終端、測試環(huán)境都在它手邊你只需要傳達意圖它自己會去翻資料、動手改。1.2 它擅長做什么、不擅長做什么Claude Code CLI 的核心場景我梳理了一下大致有四類讀代碼、解釋代碼拿到一個陌生項目直接讓它解釋一下這個模塊的調用鏈遠比自己在文件間跳轉來得快。寫新功能給它一個清晰的需求描述它可以自動創(chuàng)建文件、補全邏輯、寫出配套的測試。重構與修 Bug你描述異?，F(xiàn)象或目標結構它會先分析現(xiàn)狀再給出改動方案確認后批量修改。執(zhí)行重復性工程操作批量重命名、統(tǒng)一錯誤處理、補充注釋、生成文檔這些枯燥活兒它干得尤其好。但它不是萬能的。我試下來復雜業(yè)務邏輯的架構設計它仍然做不到——你不能扔給它一句幫我做一個電商系統(tǒng)然后就等它輸出所有業(yè)務代碼。它更像一個動手能力極強的執(zhí)行者你把方向想清楚告訴它每一步怎么落地它能高效完成而且比你自己慢慢敲要快得多。1.3 快速判斷你適不適合入坑如果你是以下幾種情況這個工具值得花一個晚上試試日常大量使用 Git、終端、服務器習慣了命令行工作流。接手過自己不熟悉的老項目經常需要快速讀懂代碼。寫前端頁面或腳本時討厭反復在寫代碼—切窗口—粘貼—復制回來之間循環(huán)。需要做大量機械性編碼任務比如重復的 CUD 操作、增刪字段、寫單元測試。反之如果你完全沒用過終端連cd和ls都還沒形成肌肉記憶建議先花兩周熟悉基礎命令行再上手。這個工具雖然號稱自然語言編程但它默認你是能看懂終端的操作員不是被照顧的小白用戶。2. 安裝與第一輪配置2.1 硬性依賴Node.js 版本檢查Claude Code CLI 基于 Node.js 運行安裝前請先確認你的環(huán)境。終端執(zhí)行node -v我建議 Node.js 版本不低于 18.0。如果你用的還是 16 或更老后面大概率會遇到運行時報錯那時候再回頭升級也行但不如一開始就準備好。如果你機器上還沒有 Node.js直接用包管理器裝一個 LTS 版本即可這里不展開。確認版本沒問題后安裝本體就一條命令npm install -g anthropic-ai/claude-code等等這里我得說一下。這串包的名稱按我記憶里的寫法是anthropic-ai/claude-code但生態(tài)變化很快不同時間點的安裝命令可能略有差異。如果你執(zhí)行這一條報錯包不存在先不要慌去 npm 官網(wǎng)搜claude-code或anthropic-ai/claude-code以搜索到的真實包名和官方 readme 里的安裝命令為準。我不能在教程里給你編造一個確定的包名因為那會誤導你。實際上我自己的裝機步驟通常是# 1. 確認 node 版本 node -v # 2. 安裝命令行工具 npm install -g anthropic-ai/claude-code # 3. 驗證安裝 claude --version安裝完成后終端敲claude --version能輸出版本號說明第一步成了。2.2 API Key 配置繞過登錄這一步這個工具本身是圍繞調用云端大模型能力設計的所以你需要一個可用的密鑰。具體來說安裝完成后首次運行它大概率會讓你完成某種身份認證或登錄流程。我想強調的是無論你使用的是哪種認證方式本質上都是把你的本地環(huán)境與一個具備模型調用權限的賬號關聯(lián)起來。你需要準備好某個支持 Claude 模型能力的 API 密鑰或者一個已登錄狀態(tài)的賬號。確保你的網(wǎng)絡能正常訪問目標服務。如果官方 CLI 出現(xiàn)在你所在地區(qū)不可用的情況比如網(wǎng)絡不通那就主動放棄千萬不要嘗試任何繞過網(wǎng)絡限制的方案這類操作既不穩(wěn)定也不安全沒必要為一個編碼工具冒險。我配置好的環(huán)境變量大概是這樣的# 在你的 shell 配置里加上 export ANTHROPIC_API_KEY你的密鑰也有通過claude交互式命令/login或首次啟動向導完成綁定的看你實際版本支持哪種。配置完成后我建議先跑一個最簡單的對話來驗證連通性claude進入 REPL 交互界面后輸入你好如果它能正常回復說明連接沒問題。2.3 在你自己的項目里初始化很多教程喜歡講全局配置但我更推薦項目級使用。進入一個具體的代碼倉庫然后啟動cd ~/projects/my-todo-app claude此時工具會掃描當前目錄并生成一個會話相關的配置文件通常是一個隱藏目錄比如.claude里面存放會話歷史與項目上下文。這一步很重要它會讓你確認這個工具被允許讀取和寫入哪些目錄以及是否允許自動執(zhí)行命令。如果你面對的是生產環(huán)境的敏感倉庫建議更謹慎地選擇允許的權限范圍。首次運行時它會問你是否信任當前目錄。我見過不止一個朋友在這步直接回車選了允許一切權限結果它在一個不想被碰的目錄里自作主張改了一堆文件。這個坑我會在第 6 節(jié)詳細講。3. 核心概念與常用命令速覽3.1 會話機制從一次性對話到連續(xù)上下文Claude Code CLI 里的一個關鍵概念是會話Session。每一次你啟動claude開始對話到關閉它算一個會話。會話內它會記得之前聊過的內容以及它對項目結構的理解。我強烈建議按任務分會話一個會話只干一件事完成就退出下次開新會話。為什么因為會話上下文有長度上限如果在一個會話里拖得極長它能記住的項目細節(jié)會被逐漸稀釋最后可能忘掉前面的關鍵約束。你可以用claude --continue來繼續(xù)上一個會話。比如昨晚讓它改了一半的功能今天想接著聊就用這條命令。如果只有一個歷史會話它會直接恢復如果有多條它會列出歷史會話供你選擇。用claude --resume也可以達到類似效果但兩者的細微差別在舊版本中體現(xiàn)為--continue更偏向接著干當前活--resume更偏向選擇任意會話恢復。實際用下來差別不大你選一個習慣就行了。3.2 斜杠命令不只是聊聊天進入交互界面后你能看到所有內置命令的列表直接在輸入框里打/就會彈出提示。我篩出幾個最高頻的命令作用我用它做什么/init初始化項目上下文生成一個項目記憶文件新項目第一次啟動后教它記住項目約定/clear清空當前會話上下文當前任務做完了、下一件事不想讓它惦記舊內容/help顯示命令幫助忘了某個命令的具體用法時/compact壓縮當前會話上下文會話長了以后防止它失憶/status查看本次會話的文件改動、命令執(zhí)行記錄復盤它到底動了哪些文件其中/init是我最想重點說的。一條具體的命令解釋如下在項目根目錄進入claude后輸入/init它會把當前項目的代碼結構、技術棧、常用命令等信息整理成一個類似CLAUDE.md的說明文件后續(xù)每一次會話它都能自動讀取這個文件作為背景知識。這個機制非常有用相當于給 AI 寫了一份項目入職手冊。3.3 權限系統(tǒng)與控制策略與寫代碼類工具通常要處理掉信任邊界一樣這個 CLI 也有完善的權限控制。它執(zhí)行命令和修改文件前都會先詢問你。常用選項如下Yes, and dont ask again for this directory # 信任這個目錄之后不再問 Yes, once # 僅單次允許 No, and dont ask again # 拒絕并記住這個決定我個人的策略是在個人練習項目的目錄里放權多一些在涉及公司業(yè)務或生產數(shù)據(jù)的項目目錄里保守一些逐次確認每一項改動。你要觀察它在每次請求中出示的具體命令是什么再決定要不要允許——比如刪除整個目錄的命令無論如何都應該先看清楚。3.4 非交互式調用的基礎入門除了在終端里一個對話框聊天這個工具還支持直接以參數(shù)形式傳遞問題。簡單講就是不需要啟動交互界面直接執(zhí)行claude 給 utils/format.ts 里的 formatDate 函數(shù)補充完整的 JSDoc 注釋這種模式的好處是方便腳本化。你可以寫一個 shell 腳本批量地對多個代碼文件發(fā)起結構化修改請求。不過注意非交互模式下如果缺少某些必要參數(shù)它可能仍會在某些環(huán)節(jié)停下來或直接讀取配置文件的權限設置。這個玩法更適合進階用戶入門階段先用好交互模式就夠了。4. 實操從零搭一個 TODO 管理小工具講了這么多概念不如直接看一次完整對話記錄。我用一個真實的練習項目來做演示——一個極簡的 TODO 命令行工具。4.1 項目目標與初始描述項目結構如下這里演示的就是一個小倉庫my-todo-app/ ├── package.json ├── index.js └── README.md我的第一個需求是寫一個能在終端里添加、列出、標記完成、刪除 TODO 的小程序數(shù)據(jù)保存在本地 JSON 文件里。在claude交互界面里我輸入了我想用 Node.js 寫一個命令行 TODO 管理工具。要求 1. 數(shù)據(jù)存到本地 todos.json 文件 2. 支持 add、list、done、delete 四個子命令 3. 命令行參數(shù)交互盡量簡潔 4. 輸出要帶顏色可讀性好 請直接創(chuàng)建/修改相關文件。4.2 觀察它如何自我規(guī)劃按下回車后Claude Code CLI 的第一反應不是直接寫代碼而是輸出一段計劃。大意是檢查目錄下現(xiàn)有文件內容確定用什么數(shù)據(jù)結構存儲決定是否需要引入第三方依賴比如顏色輸出庫規(guī)劃好四個命令的入口邏輯直接創(chuàng)建或修改文件接下來它會讀取我的package.json、index.js然后開始動手。整個過程我是實時看到的它先讀文件再向我確認是否允許創(chuàng)建todos.json是否允許修改 的package.json是否允許安裝依賴。我一路選了允許大約兩三分鐘后一個能跑的版本就產生了。截圖中的實際終端輸出大概是這樣的還原片段$ claude 我想用 Node.js 寫一個命令行 TODO 管理工具... ? 已讀取 package.json當前無依賴 ? 已創(chuàng)建 todos.json 數(shù)據(jù)結構定義 ? 已重寫 index.js包含四個子命令的實現(xiàn) - 建議安裝 tinycolor2 來增強終端輸出顏色 是否需要運行 npm install tinycolor2 ? (Yes/No)它甚至會主動備注依賴安裝的必要性。這里小技巧是如果你不想引入太多依賴直接對它說不要安裝任何第三方包全部用 Node.js 內置能力實現(xiàn)它就會乖乖地只寫原生代碼。4.3 驗證功能與迭代修改工具寫完后我直接在另一個終端里測試node index.js add 學習命令行 AI 工具 node index.js list node index.js done 1第一個版本執(zhí)行基本正確但輸出格式有點樸素。我回到claude會話里追加需求列表輸出時已完成的 todo 前面加 ?未完成的前面加 已完成條目文字變灰并加刪除線。需要說明一下這里我用了 Emoji實際終端里的支持情況和當前運行的 shell 環(huán)境有關。如果你的終端不支持 Emoji 顯示可以要求換成文本標記[x]和[ ]。這個修改在幾秒鐘內完成效果立即可見。這個輸入需求—確認 — 再輸入新需求的循環(huán)就是日常用這個工具最舒服的模式。你完全可以用自然語言不斷追加修改不需要再自己人肉逐字改文件。4.4 讓它做事之前先讓它說說思路我后來讓工具給 README.md 補文檔它補得倒很快但一開始的用詞偏AI 味嚴重啰嗦而且喜歡加免責聲明。我加了一句README 用中文簡潔禁用任何模板化表達它生成的質量立刻好很多。所以在實際干活時多花 30 秒把約束條件說清楚遠比事后反復糾正要高效。下面是一個我常用的提示模板請修改或創(chuàng)建哪些文件。 具體需求是什么。 哪些地方不允許改動哪些依賴不允許引入。 輸出風格上有什么偏好比如注釋語言、代碼風格、README 風格。 先給我方案確認后再動手。最后一句尤其好用。默認情況下它會邊想邊做你如果加一句先想后做它普遍會先給你列出改動計劃而不是直接動手這會讓你對即將發(fā)生的變化更有掌控感。5. 高頻使用的小技巧與配置參數(shù)5.1 通過系統(tǒng)提示詞讓它更懂你的習慣除了項目級的CLAUDE.md還可以在全局配置里放一套自己的通用行為守則。比如我給自己設了三條硬性規(guī)則所有新寫的代碼必須包含注釋注釋用中文。所有函數(shù)不得超過 60 行超了就要拆。改寫現(xiàn)有代碼時先 diff不覆寫。這個工具的全局配置交互入口不同版本不太一樣。但通常你可以找到類似編輯系統(tǒng)提示詞或設置用戶偏好的入口。如果找不到也可以考慮使用 Bash 方式手工編輯配置文件具體路徑可以在/help里查看各命令的幫助信息。5.2 上下文壓縮會話變長了怎么辦當你和它在同一個會話里聊了很多輪以后會發(fā)現(xiàn)它開始前言不搭后語——忘掉最初的約束或者重復提出已經討論過的問題。這是上下文窗口快要裝滿的信號。此時輸入/compact它會嘗試壓縮當前對話歷史把關鍵信息保留下來。壓縮完以后它通常還會給你一個摘要說明它記住了哪些要點。我記得第一次用這個功能時驚了一下它把之前所有的溝通濃縮成 20 行左右的項目簡述后面繼續(xù)對話時依然能準確執(zhí)行需求體驗相當好。如果你發(fā)現(xiàn)/compact之后還是不好使那就老老實實重啟一個新會話但把重要背景寫進項目說明文件里再從那里繼續(xù)。5.3 讓它讀文件而不是你手動貼常見的一個低效用法是用戶把一大段代碼反面粘貼進對話框然后問這段代碼哪里有問題。在 CLI 工具里正確的做法是直接用自然語言指向文件路徑請檢查 src/api/index.ts 和 src/api/user.ts找出接口調用里可能存在的并發(fā)安全問題并給出修復建議。它會自己去讀文件、追蹤 import、看上下文然后給你結論。這不僅省去復制的麻煩而且它能看到完整的調用鏈結論的準確性明顯更高。我自己用下來最大的改變就是再也不在對話框里貼代碼了。5.4 一次性使用不啟動交互界面也能干活前面提到過claude 需求這種一次性調用方式。這里補充一個更實用的場景把它和git聯(lián)動。我自己的習慣是commit 之前不再自己寫 message而是讓工具根據(jù)暫存區(qū)的改動生成git diff --stat git diff claude 根據(jù)本次改動內容幫我看 diff 并生成一份符合規(guī)范的中文 git 提交信息這個工作流如果你覺得好用甚至可以寫進腳本里。核心樂趣在于終端里的 AI 助手可以成為 shell 工作流的一個環(huán)節(jié)而不僅僅是一個聊天窗口。6. 我踩過的坑與排查建議6.1 權限放得太寬項目被幫忙重構了第一次在某個目錄里運行時我圖省事直接選了完全信任該目錄。結果有一次我讓它優(yōu)化一下代碼結構它把所有文件全部重命名并按新目錄結構移到了新位置。功能沒壞但 review 成本極高——這個教訓是即使在自己主導的項目里也要克制放權的沖動。改成單次確認模式之后每次執(zhí)行前都給我看命令安心多了。解決建議把權限模式調整為逐次確認。尤其在面對自己不熟悉的目錄或生產環(huán)境時寧可多點幾下確認也不要事后花幾個小時找它改了啥。6.2 命令找不到 / 版本不一致如果你執(zhí)行claude --version時提示 command not found大概率是 npm 全局 bin 路徑沒有在你的 PATH 里。排查方式npm config get prefix這個命令輸出的是全局安裝目錄把該目錄下的bin路徑添加進你的 shell 配置文件。比如上面的 prefix 是/usr/local那就加export PATH/usr/local/bin:$PATH另外升級之后行為發(fā)生變化多半是版本升級帶來的命令或參數(shù)變化。我的建議是如果某個功能突然失效先跑/help看看當前版本的命令列表再想想是不是把舊教程里的--continue記成了新版本不存在的命令。6.3 中文顯示亂碼 / shell 編碼問題終端里顯示的中文亂碼通常是當前 shell 環(huán)境編碼問題。先檢查環(huán)境變量echo $LANG正常情況下應該可以看到類似en_US.UTF-8或zh_CN.UTF-8這樣的值。如果$LANG為空或不是 UTF-8在 shell 配置里補一行export LANGen_US.UTF-8 export LC_ALLen_US.UTF-8改完后重啟 shell 再試。這種問題不是工具本身的 bug而是你本機環(huán)境的經典坑換個機器往往就沒有了。6.4 會話丟失 / 歷史找不回來有幾次我電腦重啟后再執(zhí)行claude --continue它顯示沒有找到可繼續(xù)的會話?？茨闫綍r怎么使用——說白了如果你在運行claude時使用了sudo權限會話文件會分別記錄在 root 用戶目錄和普通用戶目錄下互相之間是隔離的。解決方案不要輕易用 sudo 跑這個工具。正常情況下claude根本不需要管理員權限。這樣會話歷史才能穩(wěn)定地保存在你當前用戶的家目錄里。6.5 API 連接不穩(wěn)定或超時如果你配置好了密鑰但每次對話響應特別慢或者直接報超時先別懷疑工具本身。確認你的網(wǎng)絡可以正常訪問對應的模型服務如果你處于特殊的公司網(wǎng)絡或網(wǎng)關環(huán)境下可能需要向網(wǎng)絡管理員咨詢。這里我不推薦也不支持任何繞過網(wǎng)絡限制的方案——直接說結論如果你的網(wǎng)絡條件導致服務不可用最穩(wěn)妥的做法是停止使用而不是尋找不正規(guī)的通道。補充一點如果只是偶發(fā)超時不妨檢查本地是否有過度消耗資源的進程。CLI 工具需要網(wǎng)絡請求終端性能或本地資源占滿時響應也會受拖累。6.6 輸出內容泛泛而談 / 不貼合項目這是最常見的假性故障明明給了具體項目它卻總是答得很空。多數(shù)情況下是你沒有給它足夠具體的上下文。往下推我會這樣補救不要猜測請先閱讀項目根目錄下所有 README、配置文件、源碼目錄結構 然后基于本項目實際情況回答我剛才的問題。這樣它就會去真正讀項目而不是憑一般經驗堆砌。如果仍然不行看看項目的CLAUDE.md是否已經生成了。沒有就先/init給它建立記憶。6.7 安全與平臺合規(guī)問題的個人建議這個工具的核心價值是讓 AI 直接操作你的代碼隨之而來的安全邊界不要在非授權環(huán)境里分享你的密鑰。不要把公司敏感代碼隨意送入外部模型服務除非你確認數(shù)據(jù)政策允許。在一個新項目里先讓它做只讀操作讀文件、列目錄、解釋代碼確認它理解正確后再放權改動。如果你用它的場景是在不熟悉的環(huán)境中處理敏感代碼務必對能訪問云端的 AI保持敬畏。有經驗的朋友會直接在敏感項目里完全不啟用這個工具或者只在自己完全可控的模擬項目里練習。這個選擇本身就是一個工程師成熟與否的分界線。從能跑到用得順要跨過的三道坎從裝好到真正用順我大概花了一周時間。這個過程里最明顯的三道坎第一道坎是忘記它是一個終端命令——總想把它當聊天窗口對話沒有指向性。之后我開始明確指定文件路徑、列出需求邊界、要求它先給方案輸出質量才有了質的提升。第二道坎是權限恐懼——總怕它亂改所以每次操作都要盯住每一行。后來學會區(qū)分環(huán)境和目錄練習項目放心放權核心庫保持一致一切改動都能通過版本控制回滾心態(tài)就放松了。第三道坎是習慣用自然語言描述技術細節(jié)——剛開始寫需求時老是擔心自己說得不夠程序員加了一堆技術術語。后來發(fā)現(xiàn)它其實擅長把模糊需求拆解成具體方案你反而應該用更接近人話的方式來描述問題讓它去補全技術細節(jié)。這篇入門教程里我沒講任何晦澀的內部實現(xiàn)原理只挑了我實際操作中最高頻使用的東西。如果你照著這些步驟走下來恭喜你你已經在開發(fā)者群體里領先了很大一截——至少當別人還在圖形界面里手動選擇代碼—上下文的時候你已經能在終端里用一個自然語言項目上下文的方式讓 AI 直接幫你動手寫代碼了。我個人目前的使用習慣是把這工具當作結對編程搭子而非無人駕駛司機。它負責執(zhí)行、補全和重復勞動我負責審查、糾偏和方向定義——這會是我推薦的踏實用法。后續(xù)如果有時間我再寫寫它和其他腳本化工具結合、以及多項目并行會話管理的高級玩法。