CLI 是什麼？AI 工具時代的新手命令列入門教學
CLI（Command-Line Interface，命令列介面）是用一串文字指令操作電腦、軟體或服務的方式；與用滑鼠點資料夾、按按鈕的 GUI 圖形介面相對，CLI 是直接打字告…
CLI 與 GUI 的本質差異
CLI（Command-Line Interface，命令列介面）是用一串文字指令操作電腦、軟體或服務的方式；與用滑鼠點資料夾、按按鈕的 GUI 圖形介面相對，CLI 是直接打字告訴電腦要做什麼，例如輸入 git status 看版本狀態、輸入 python --version 確認安裝。根據 Stack Overflow 2024 開發者調查，超過七成開發者每週都會使用命令列，而在 AI 工具普及後，這個數字只會繼續往上爬。
很多非工程師第一次被嚇到，是因為被要求打開 Terminal 安裝 Claude Code、Codex CLI、Gemini CLI 這類 AI Agent。黑黑的視窗、游標一直閃，看不懂自己在幹嘛，就怕一個 Enter 按下去把檔案弄壞。這個焦慮很真實，值得花點時間把它拆開來看。
重點先看：CLI 不是新科技，只是「用文字說」取代「用滑鼠點」。但 AI 時代讓它重新變重要，因為像 AI 寫程式這類工具要進到你的專案資料夾做事，只有透過 Terminal 才碰得到本機檔案；超過七成開發者每週使用命令列（Stack Overflow 2024 開發者調查）。
講白一點，CLI 不是黑科技。你平常在 ChatGPT 網頁上打字問問題，那也是一種「用文字跟機器溝通」。差別在於 GUI 是用滑鼠點，CLI 是用文字說：你輸入 ls，它就列出資料夾內容；你輸入 claude，它就啟動 Claude 的命令列工具。想把它從啟動到上手走一遍，可以參考這份 Claude Code 完整教學。
把 GUI 跟 CLI 放在同一張表上比較，差異會更具體。GUI 把操作封裝成按鈕、選單、對話框，你點得到的功能就是全部；CLI 把操作寫成一行行文字，你能組合的指令幾乎沒有上限。GUI 適合重複性高、視覺導向的日常工作，CLI 適合批次、自動化、需要精準控制檔案與流程的場景。AI 工具之所以落在 CLI 這一側，是因為它要讀整個專案、改一堆檔案、跑測試、操作 Git，這些動作用按鈕根本包不起來。
| 比較項目 | GUI 圖形介面 | CLI 命令列介面 |
|---|---|---|
| 操作方式 | 滑鼠點選、按按鈕 | 輸入文字指令 |
| 能做的事 | 被封裝好的功能 | 可任意組合指令 |
| 批次與自動化 | 受限於軟體設計 | 天然支援批次與腳本 |
| 接觸本機檔案 | 需要透過應用程式開啟 | 可直接讀寫整個資料夾 |
| 學習曲線 | 直覺、所見即所得 | 要先記幾個基本指令 |
| AI 工具為何選這邊 | 裝不下「讀專案、改檔案、跑測試」 | 能完整操作開發環境 |
那為什麼過去十年你幾乎沒碰過它？因為 GUI 把大多數日常操作包得好好的，點一點就能完成。但 MCP 模型上下文協定、AI Agent、Prompt 提示詞這波工具的設計邏輯，是把 AI 帶進你的工作環境，而不是把你帶到 AI 的網頁裡。這個方向一反轉，CLI 就從「工程師專屬」變成「AI Agent、AI Coding、開發自動化的入口」。
三個你一定會在 AI CLI 入門看到的指令範例，先把樣子記起來就好，不用背：git status（看版本狀態）、python --version（確認安裝）、claude 或 codex 或 gemini（啟動 AI 工具）。第一個管版本、第二個管工具、第三個啟動 AI。能分到這個程度，比九成自學新手都清楚了。
Terminal、Shell、CLI 是三個不同層次
Terminal 是讓你輸入指令、看到結果的視窗；Shell 是負責解讀你輸入內容的程式（例如 bash、zsh、PowerShell）；CLI 則是「用文字指令操作」這件事本身；CLI 工具是你實際執行的工具，例如 Git、npm、Codex CLI。三者是不同層次，不是同一個東西，把它們混為一談，是新手最常卡住的原因。
一個比喻講完：Terminal 像櫃台窗口，Shell 像窗口裡處理事情的人，CLI 工具是被叫來處理特定任務的專員。你（客戶）把需求交給窗口，窗口裡的人讀懂你的話，再叫對應的專員動手。把 網頁原始碼與 F12 開發者工具的概念搬過來想：你看得到的是 Terminal 這層皮，真正做事的是後面的 Shell 與工具。
用 git status 拆一遍就很清楚。你在 Terminal 輸入這串字，Terminal 只負責接收與顯示；Shell 讀懂這是個指令，把它交給 Git 這個工具；Git 真正去檢查版本狀態，再把結果送回 Terminal 給你看。你在 Claude Code 與 Cowork 差異這類工具裡輸入 claude，背後是同一套流程：Terminal 接、Shell 讀、AI 工具執行。
| 名詞 | 角色 | 具體例子 |
|---|---|---|
| Terminal 終端機 | 輸入與顯示的視窗 | macOS 的 Terminal.app、Windows Terminal、iTerm2 |
| Shell | 解讀指令的程式 | bash、zsh（macOS/Linux 預設）、PowerShell（Windows） |
| CLI | 「用文字操作」這件事 | 輸入 git status 這個行為 |
| CLI 工具 | 實際執行的程式 | Git、npm、Docker、Claude Code、Gemini CLI |
為什麼要分這麼細？因為你會踩到的第一個坑就藏在這裡。同一個 ls 指令，在 macOS 的 zsh 可以直接用，到了 Windows 的 PowerShell 雖然多半也能跑，但官方對應的寫法是 Get-ChildItem。bash、zsh、PowerShell 是不同 Shell，指令寫法不完全一樣。知道這點，你才不會在網路上抄了一段指令卻跑不出來，以為自己電腦壞了。
Shell 的差異會在幾個地方具體咬人。第一個是設定檔：bash 讀 .bashrc，zsh 讀 .zshrc，PowerShell 讀它的 profile 腳本，當你要把環境變數或別名寫進去「每次開 Terminal 都自動生效」時，寫錯檔案就等於沒寫。第二個是萬用字元與語法：rm *.log 在 bash、zsh 可以，但部分寫法在 PowerShell 要改用 Remove-Item *.log。第三個是路徑分隔符號：macOS、Linux 用正斜線 /，Windows 傳統上用反斜線 \，複製貼上路徑時常常因此在這邊卡半小時。記住一個原則：先確認對方用的是哪種 Shell，再決定指令怎麼寫。
這層認知還關係到一件更重要的事：知道 AI CLI 工具是「被叫進 Terminal 的專員」，你才會理解它是在「哪個資料夾」工作。它在 Terminal 啟動的那一刻，工作範圍就被你所在的資料夾決定了。這就是為什麼後面會一直強調 pwd 這個指令。
為什麼 Claude Code、Codex CLI、Gemini CLI 都要你打開 Terminal
因為這些工具的核心能力是「進入你的專案資料夾做事」，讀取程式碼、修改檔案、執行測試、操作 Git，這些動作只有透過 Terminal 才碰得到你的本機檔案。網頁版聊天 AI 只能回答問題，AI CLI 才能真正動手改你的專案。這是兩個完全不同等級的能力。
把差別講到最白：你跟 ChatGPT 聊天，它講錯了，你關掉視窗就沒事；但你讓 Claude Code 進到正式專案，它改錯了，是真的會動到你硬碟裡的檔案。這個「後果不對稱」，是 CLI 在 AI 時代重新變重要的真正原因，也是新手必須先懂一點命令列的根本理由。一般入門文把 CLI 當成「另一種跟電腦溝通的方法」輕描淡寫帶過，但真正的差異不在溝通方式，而在出錯的代價；這也是為什麼 AI 時代該怎麼做 SEO 會把「理解工具在做什麼」放在很前面。
CLI 適合做的事，可以列成一份清單，這也是 AI CLI 工具為什麼選擇待在 Terminal 的原因：讀取整個專案結構、修改檔案與修 Bug、執行程式與跑測試、操作 Git 工作流程、產生文件、批次自動化重複任務。這六件事，網頁版聊天 AI 一件都做不到，因為它根本碰不到你的資料夾。
三個工具的官方定位，依各自官方說明整理：Claude Code 是 Anthropic 在 Terminal 裡理解 codebase、編輯檔案、執行命令的 AI coding tool；Codex CLI 是 OpenAI 提供的本機終端機 coding agent；Gemini CLI 是 Google 把 Gemini 帶進 Terminal 的開源 AI Agent。共同特徵是：它們都被設計成「進入你的開發環境」。
這裡要升級一個觀念。這種能自己讀取環境、規劃並執行多步驟任務的 AI，業界叫 AI Agent。它不是「你問一句它答一句」的聊天機器人，而是你給它一個目標，它會自己拆步驟、自己讀檔案、自己決定要不要改東西。想把 AI Token 與 LLM 大型語言模型的能力用到極限，這種「能動手」的模式就是主力；而它實際讀進去的素材品質，會直接影響輸出，這點跟 BM25 如何決定餵給 LLM 的素材背後的篩選邏輯是相通的。
說到底，以前你可以不懂 CLI，只用 ChatGPT 聊天、摘要、寫文案；但只要你想讓 AI 協助寫程式、改專案、操作本機檔案，CLI 就不再是工程師的專利，而是「安全使用 AI 工具的基本能力」。這不是潮流問題，是工具架構決定的。這也正是 Vibe Coding 用 AI 驅動程式設計能成立的底層前提。
CLI、網頁版 AI、API 三種使用方式的取捨
把使用 AI 的方式分成三類，你會更清楚 CLI 在整張版圖裡的位置。第一類是網頁版聊天 AI，像 ChatGPT、Claude.ai、Gemini 網頁，你在瀏覽器打字、它回話，碰不到你的檔案。第二類是 API，你或你寫的程式透過一串金鑰呼叫模型，把 AI 嵌進自己的應用或自動化流程，門檻最高、彈性最大。第三類就是 AI CLI，介於兩者之間：它在你的 Terminal 裡、能動你的檔案，但你仍然是用對話的方式驅動它，不需要自己寫程式去接 API。
這三種方式的差別，可以用三個維度來判斷：能不能碰你的檔案、要不要寫程式、出錯的後果落在誰身上。網頁版碰不到檔案、不用寫程式、出錯頂多答錯；API 能碰（你設計流程去碰）、要寫程式、出錯由你的程式碼負責；AI CLI 能碰你的資料夾、不用寫程式、出錯會直接改到檔案。把這三個維度想清楚，你就知道為什麼 AI CLI 特別需要「懂一點命令列」當保險。
| 使用方式 | 能碰本機檔案 | 需要寫程式 | 出錯後果 | 適合的任務 |
|---|---|---|---|---|
| 網頁版聊天 AI | 否 | 否 | 答錯可忽略 | 問答、摘要、寫文 |
| API | 視你設計的流程 | 是 | 由你的程式碼承擔 | 把 AI 嵌進產品、自動化 |
| AI CLI | 是 | 否 | 直接改到檔案 | 改專案、修 Bug、批次處理 |
一份簡單的決策建議：如果你只是要問問題、要靈感、要潤飾文字，留在網頁版就好，根本不必碰 Terminal；如果你要把 AI 變成產品的一部分、要它能持續在背景跑，走 API；如果你想讓 AI 直接幫你動手改一個現成的專案、整理一堆檔案、跑測試，但又不想自己寫接 API 的程式，那就是 AI CLI 的主場。多數非工程師會從網頁版走到 AI CLI 這一步，因為它的學習成本比 API 低很多，又能拿到「真的動手」的能力。如果你對 RAG 檢索增強生成這類把 AI 接上自有資料的做法有興趣，會發現 AI CLI 常常是踏進那個領域的第一個練習場。
常見的 AI CLI 工具有哪些（不是排名，是建立基本認識）
目前最常被提到的四款是 Codex CLI（OpenAI 本機終端機 coding agent）、Claude Code（Anthropic 終端機 AI coding tool）、Gemini CLI（Google 開源 AI Agent）、GitHub Copilot CLI（在 Terminal 裡用 Copilot）。它們的共同點不是聊天，而是「AI 進入你的開發環境」，差別在背後的模型、定位與使用門檻。
先提醒一件無法迴避的事：AI CLI 工具更新非常快，功能、價格、可用地區、模型與權限設計都可能隨時改變。最穩的做法是養成「看到陌生指令先查官方文件或 --help」的習慣，比死記某個版本的設定更耐久。這張表只幫你建立基本認識，也不是推薦你立刻裝哪一套。
| 工具 | 簡單理解 | 適合誰 | 屬性 |
|---|---|---|---|
| Codex CLI | OpenAI 本機終端機 coding agent | 想用 AI 協助寫程式、改專案的人 | 開源 |
| Claude Code | Anthropic 終端機 AI coding tool | 已有專案、想讓 AI 理解與修改的人 | 官方產品 |
| Gemini CLI | Google 把 Gemini 帶進 Terminal 的開源 AI Agent | 想在命令列用 Gemini、做開發與研究的人 | 開源 |
| GitHub Copilot CLI | 讓你在 Terminal 裡用 GitHub Copilot | GitHub 與 Copilot 使用者 | 官方產品 |
四款裡頭，Codex CLI 與 Gemini CLI 是開源，原始碼可以在 GitHub 上看，社群能貢獻、能審查；想把 Gemini 這條線摸得更深，可以搭配 Gemini AI 從入門到進階攻略一起看；Claude Code 與 Copilot CLI 是官方產品，版本與功能由公司主導。開源不等於比較安全，但至少多了一層能被外部檢視的機會，對重視 E-E-A-T、講究來源可信度的人，這個差異值得知道。
挑工具時，先問自己三個問題，答案會比看「哪一款最好」更有用：你打算讓它動哪一種檔案（網站、Python 腳本、文件）、你已經習慣哪一個生態（OpenAI、Anthropic、Google、GitHub）、你的預算與用量型態適合訂閱還是按用量計。這三題答完，候選名單通常只剩一兩款。沒有跨所有情境都最強的工具，只有對你的任務最順手的工具。把 搜尋引擎運作原理這類底層邏輯弄懂一點，會比追著工具排名更能幫你做判斷；想知道自己的頁面有沒有被收進索引，動手做一次 Google 網頁收錄查詢最快。
定價部分不寫死數字。這類工具的計費方式從訂閱到按用量計算都有，而且改得很勤。想知道當下價格，直接到各工具官方網站看即時資訊最準。如果你還在比較「ChatGPT、Claude、Gemini 哪個適合自己」，建議先想清楚你的任務型態再決定，讓需求來帶價格，價格跟在最後面即可。
這些工具的共同點比差異更值得記住：它們本質上是會讀你的資料夾、會改你的檔案、會執行命令的 Agent，聊天只是表面介面。裝任何一款之前，先確定你看得懂它在做什麼，這比挑哪一款更重要。如果你對 GEO 能見度監測工具、RAG 檢索增強生成、GEO 生成式搜尋優化這類名詞有興趣，CLI 幾乎是它們共同的入口。
AI CLI 工具能幫你做什麼：從低風險到高風險
把 AI CLI 能做的事依風險由低排到高，會比一份平行的功能清單更實用，因為新手真正需要的是知道「哪幾種可以先放手做、哪幾種要先備份再碰」，至於總共有幾種功能反而是次要問題。它與聊天 AI 最大的差別是「真的會動到你的檔案」，所以風險高低直接決定你該用什麼節奏去用它。
讀懂專案與產生文件：只讀不改的安全區
接手別人的專案、從 GitHub 下載一個開源專案，一開始往往連資料夾結構都看不懂。你可以讓 AI CLI 工具讀取目前資料夾，請它解釋架構；同樣的只讀能力也適合用來產生 README、安裝步驟、使用範例。這兩類任務共同的好處是只讀不改，是新手最安全的起手式，問得越具體產出越能用。把這個場景用好的訣竅在於「分段問」：一次丟整個專案給它，容易得到又長又籠統的總結；先問大架構，再針對單一資料夾或單一檔案深入，每層都讓它指著具體檔名說明，你才能回頭查證它講得對不對。若它說「這個檔案負責路由設定」，你就真的打開那個檔案看一眼，這個查證動作能擋掉絕大多數看起來合理卻其實講錯的回答。
修改程式碼與修 Bug：風險最高，要先建立回復機制
AI CLI 工具可以根據錯誤訊息或需求描述，協助修改檔案，例如修正某個 function、補上錯誤處理。這也是風險最高的一項，因為它真的會改到你的檔案。在正式專案裡，改之前一定要先看 diff、先備份。對照 Grounding 被 AI 引用的邏輯，AI 修改前你有責任確認它改對地方；遇到看不懂的錯誤訊息，善用 Google 搜尋技巧先查證，比直接讓 AI 動手穩得多。
一個常見的「安全槓桿比」可以幫你決定要不要讓 AI 直接動手：把「出錯能回復的速度」除以「它一次會碰的檔案數」。比值越大，越適合放手讓它改；比值接近 1 或更小，就回到逐項詢問。實務上常見的翻車情境是這樣：你在一個有 Git 的正式專案裡，請 AI「順手把所有 import 排序一下」，這句話看似無害，但它會一次碰數十個檔案；若你還沒 commit，回復就變成在大量未提交改動裡挑揀，分不清哪一行是它改的、哪一行是你自己改的。把這種整批任務限定在「剛 commit 完、工作目錄乾淨」的狀態下做，出錯時一個 git restore 就能整包退回，這才是把槓桿用對地方。
用一個典型的新手專案來體會這個槓桿比怎麼運作。假設你有一個大約 8 到 20 個檔案的小型網站或腳本專案，還沒建立 Git 習慣，工作目錄裡同時混著你自己手改的內容與測試用註解。這時你請 AI「把整個專案的錯誤處理統一補上」，這類任務依典型表現大約會一次碰掉 5 到 15 個檔案，數量本身不算誇張，但問題出在順序：因為工作目錄不乾淨，AI 的改動會跟你先前未提交的修改疊在一起，一旦跑起來出錯，你很難分辨是它改壞的還是你原本就有的問題。依這類情境的常見狀況，事後要把改動拆開回溯，往往得花上 20 到 60 分鐘逐一比對，比從乾淨狀態出發多出好幾倍時間。換個做法：先 git init、commit 一次當基準點，再讓 AI 動手，出錯時 git diff 直接給你一份乾淨的變更清單，判讀成本降到幾分鐘。這個落差就是槓桿比的全部意義。要誠實點出限制：AI CLI 對依賴循環、跨檔案命名衝突這類需要全域理解的錯誤，判斷常常不準，它可能改完一處卻在另一處埋下新的問題；所以遇到錯誤訊息牽涉多個檔案互相引用時，建議先請它只解釋錯誤從哪裡來、再由你決定改哪一個檔案，把決策權留在自己手上會更穩，整批自動交給它跑反而是次要選項。
測試、Git、批次自動化：中等風險要靠流程控制
比起只把錯誤訊息貼到聊天視窗，AI CLI 工具有機會直接在專案裡跑測試（npm test、pytest、go test），看到錯誤再修正，把開發者最常做的「看錯誤、改、再測」循環加速。它也能幫你看修改差異、整理 commit message：你先自己看 git diff、git status，再請 AI 把這包改動整理成清楚的提交訊息，這也是新手最該養成的習慣之一。風險落在高檔的是批次自動化，大量檔案整理、批次改名、格式轉換本來就很適合 CLI，但這類任務一旦出錯，通常是整批一起錯，務必先用測試資料夾練習。三者的共同特徵是風險來自「執行而不只是回答」，所以控制方式落在你先備好的回復機制與測試範圍上。
把這幾類任務用「風險」與「可回復性」兩個軸交叉來看，比單純列高低更實用：
| 任務類型 | 是否碰檔案 | 出錯影響範圍 | 回復成本 |
|---|---|---|---|
| 讀懂專案 / 產生文件 | 只讀 | 無 | 不需回復 |
| 跑測試 / 整理 commit | 讀為主、少量寫 | 單檔或暫存 | 低，git restore 可解 |
| 修改程式碼與修 Bug | 改多檔 | 正式專案 | 視工作目錄是否乾淨而定 |
| 批次自動化 | 改整批 | 整批一起錯 | 高，常需逐一比對 |
Approval Mode 與權限確認：AI CLI 的安全閘門
多數 AI CLI 工具都設計了一套「執行前先問你」的機制，業界常稱為 approval mode、permission prompt 或 plan mode（各工具命名不同，精神一致）。當 AI 打算改檔案、執行命令、讀取敏感資料時，它會停下來，把要做的事攤給你看，等你同意才動手。這層閘門是你防止「AI 自作主張改壞檔案」的最後一道防線，理解它的幾種模式，比記住任何單一指令都重要。
常見的運作模式大致可分三種。第一種是逐項詢問，AI 每次要改一個檔案或跑一條命令，都會問你一次，最安全也最慢，適合新手、適合正式專案。第二種是計畫模式，AI 先把它打算做的整串步驟列出來讓你審核，你確認後它才開始執行，適合中大型任務，能讓你在動手前看到全貌。第三種是全自動或自動接受，AI 不再逐項問，直接執行，速度最快、風險最高，只適合用在你完全可丟掉的測試資料夾，或你非常確定流程的批次任務上。把這三種模式想成「安全、平衡、快速」的三段開關，依任務風險切換即可。
| 模式 | 行為 | 速度 | 適用情境 |
|---|---|---|---|
| 逐項詢問 | 每次改檔或執行都問 | 最慢 | 新手、正式專案 |
| 計畫模式 | 先列出全盤步驟再執行 | 中等 | 中大型任務 |
| 全自動 | 不再詢問直接執行 | 最快 | 可丟棄的測試資料夾 |
操作上有一個實用原則：越靠近正式資料，閘門要開越緊。在你還沒習慣一個工具之前，一律維持逐項詢問，把每一次「它想改什麼」當成學習材料，看久了你就會發展出對它行為的直覺。等到你能在腦中預測它下一步會做什麼，再慢慢放寬到計畫模式。全自動模式留給那種「就算全刪掉也無所謂」的練習資料夾。這套漸進放寬的節奏，跟 Google 對 AI 內容的看法裡強調「人類保留判斷權」的精神完全一致。
另一個跟權限綁在一起的觀念是「工作範圍」。AI CLI 工具多半讓你指定它能在哪個資料夾、能碰哪些檔案類型、能不能連網、能不能執行特定指令。把這些邊界先設好，等於在出事之前就限縮了爆炸半徑。例如你只讓它讀一個子資料夾、不讓它碰設定檔、不讓它對外連線，那麼就算它判斷失準，影響範圍也被你事先框住。直接用預設值跑等於把整台電腦的工作範圍都交給它，這在正式專案上風險偏高。
怎麼跟 AI CLI 工具說話：提問技巧與 Prompt 結構
AI CLI 工具的輸出好壞，很大一部分取決於你怎麼提問。它跟網頁版聊天 AI 共用同一套語言模型的原則：任務要明確、脈絡要給夠、邊界要畫清楚。但因為它能動你的檔案，提問還多了一層「安全措辭」的考量。把幾個關鍵技巧記下來，你的產出品質會立刻拉開一個檔次。
- 先給目標，再給限制：「幫我把這個函式加上錯誤處理，但不要動到其他檔案，也不要改函式名稱。」目標讓它知道要做什麼，限制讓它知道不能碰什麼。
- 指定範圍：明確說「只看 src/ 這個資料夾」「只改 utils.py」，避免它把整個專案都翻過一遍甚至動到無關檔案。
- 要求先講計畫：「先告訴我你打算怎麼改，等我確認再動手。」這句話會把工具切換到計畫模式，強迫它先攤牌。
- 要它引用檔名與行號：「說明時請附上你指的是哪個檔案、大致第幾行。」這讓你事後能查證，也降低它憑空捏造的空間。
- 分次推進：把一個大任務拆成「先解釋、再小改、再驗證」幾個步驟，每步都確認，比一次要它改一大包更可控。
- 明確表達不要什麼：「不要新增套件」「不要改測試檔」「不要重構」，負面條件往往比正面要求更能框住它的行為。
這些技巧背後是同一個邏輯：你給的約束越具體，AI 自由發揮、自由犯錯的空間就越小。新手最常犯的錯，是丟一句很模糊的「幫我修一下這個專案」，然後期待它做出你要的樣子。模糊的指令只會換來模糊且常常偏離的產出。把每一次提問都當成在寫一份迷你規格書，目標、範圍、限制、驗收條件都講清楚，產出會穩定很多。這份「把問題問對」的能力，跟 Prompt 提示詞背後的原則互通，也跟操作 搜尋意圖時「先搞清楚自己到底要什麼」的思路一致。
新手用 AI CLI 前，至少要懂這 6 個指令
至少要懂六個：pwd（確認目前資料夾）、ls（看資料夾內容）、cd（切換資料夾）、--version（確認工具安裝成功）、--help（查指令用法）、sudo（高權限執行，要小心）。其中 pwd、ls、cd 是你確認「AI 在哪裡工作」的基礎，--version 與 --help 是你「查答案」的能力。
- pwd：印出目前所在資料夾的完整路徑。使用 AI CLI 前，先打 pwd 確認自己在哪，因為 AI 工具通常以目前資料夾當工作範圍。
- ls：列出目前資料夾裡的檔案。在 Windows PowerShell 裡，對應的官方寫法是 Get-ChildItem。
- cd：切換資料夾，例如
cd my-project。要讓 AI 處理某個專案，通常得先進到那個資料夾。 - --version：確認工具有沒有裝成功，例如
git --version、node --version、python --version。 - --help：查指令用法，例如
git --help。真正熟 CLI 的人不是背指令，是知道怎麼查。 - sudo：用較高權限執行命令。看不懂命令就不要亂加 sudo，它不是解決所有錯誤的萬用按鈕。
pwd、ls、cd 這三個決定了 AI 的工作範圍，重要性排在第一位。為什麼？因為你在「家目錄」啟動 AI，跟在「某個客戶專案資料夾」啟動，它看到的檔案完全不一樣。在錯誤的資料夾啟動，AI 可能讀錯專案、改錯檔案，這是最常見也最危險的錯誤。
cd 還有一個新手常踩的細節：路徑寫法。相對路徑像 cd my-project 是從目前位置往下走；絕對路徑像 cd /Users/你的名字/projects/my-project 則不管你現在在哪，直接跳到指定位置。如果你剛開 Terminal 不確定自己在哪，用絕對路徑最保險，因為它不依賴你目前的位置。另外，路徑裡有空白或特殊字元時，要用引號包起來或加脫逸符號，不然 Shell 會把空白當成分隔，切錯資料夾。
--version 解決的是「到底裝成功沒」這個疑問。如果你輸入 claude --version 卻跳出 command not found，通常有三個原因：工具還沒安裝、PATH 環境變數沒設好、或你開錯了 Shell。前兩個要回去看安裝文件，第三個要確認你現在用的是 bash、zsh 還是 PowerShell。這也是為什麼前面要花力氣把 Terminal、Shell、CLI 分清楚。若你打算從零開始用 Claude Code，這份 Claude Code 新手入門全攻略把安裝設定一次講清楚。
PATH 是這裡最容易讓人卡住的概念。簡單說，PATH 是 Shell 用來「找到指令對應的程式」的資料夾清單。當你輸入 claude，Shell 會照著 PATH 列出來的資料夾一個一個找，找到就執行，全部找不到就回 command not found。所以明明裝了卻找不到，常常是裝在一個 PATH 沒包含的資料夾裡，安裝程式忘了幫你把路徑寫進設定檔。解法是回到該工具的安裝文件，照它指定的方式把路徑加進 .zshrc 或對應的設定檔，再重開 Terminal 讓它生效。這一步搞懂，你會少掉一半的 command not found 焦慮。
--help 是你往後用得最多的一個。CLI 不像 GUI 有按鈕可以點，所有功能都藏在參數裡，你不可能全背起來，也不需要。看到陌生指令，先 --help 或查官方文件，這個習慣比背任何指令都值錢。想更系統化理解 AI 怎麼拆解任務，可以回頭看 查詢擴展 Query Fan-Out這類把一個需求展開成多步驟的技術；要驗證 AI 究竟幫你做了什麼，搭配 Google Search Console 安裝教學建立監測習慣會更踏實；想進一步量化 AI 帶來的流量，再用 GA4 追蹤 AI 流量的篩選器設定把它拆出來看。
sudo 要單獨講。它在 macOS 與 Linux 上代表用系統管理員權限執行命令，能改的東西比一般指令多很多。新手常把 sudo 當成「指令跑不起來就加一下試試」，這非常危險。看不懂命令會做什麼，就不要加 sudo。這跟 HTTPS 網站安全性背後的權限控管觀念是同一回事：權限給越大，出事越難救。
新手第一次用 AI CLI 的安全流程與常見錯誤
掌握了基本指令與提問方式之後，接下來的安全流程是把這些零碎動作串起來：先建測試資料夾、用小專案練習、先請 AI 解釋檔案不要馬上改、要看 AI 打算改哪裡、權限確認不要無腦同意、不放 API Key 與正式資料、每次改完用 Git 備份。下面把幾個最常見的錯誤逐一拆開，每個都附上對應的防範動作。
- 先建一個測試資料夾，不要放重要檔案。
- 用簡單小專案練習，例如待辦清單、簡單網頁、測試用 Python 檔。
- 先請 AI 解釋檔案，不要馬上請它修改。
- AI 要改檔案前，先看它打算改哪裡（看 diff）。
- 工具有權限確認、diff review、approval mode 時，不要全部無腦同意。
- 不要把 API Key、密碼、正式客戶資料放進測試專案。
- 每次改完後，用 Git 或備份確認可以回復。
這樣做會比較慢，但對新手安全很多，第一次絕對不要直接放正式專案。前面提過的「後果不對稱」（聊天 AI 講錯話可以忽略，AI CLI 做錯事會真的改到檔案）就是這套流程存在的理由。接著把幾個常見錯誤逐一拆開，每個都附上對應的防範動作。
錯誤一：不知道自己在哪就啟動 AI
在錯誤的資料夾啟動 AI CLI，它可能讀錯專案、改錯檔案，甚至碰到你不想讓它看的資料。防範動作很簡單：啟動前先 pwd、ls，確認自己位在哪裡。這兩個指令花你三秒鐘，卻能擋掉大多數災難。
錯誤二：一看到權限要求就按同意
AI CLI 工具常在修改檔案、執行命令前要求確認。這是保護你的機制，不是煩人的流程。每次看到確認訊息，都要看清楚它要做什麼；看不懂就先拒絕，或請 AI 解釋這個命令的作用。這跟 Google 對 AI 內容的看法裡強調的「人類需要保留判斷權」是同一個精神。
錯誤三：不看 diff 就接受修改
如果 AI 改了程式碼，你應該看它改了什麼，尤其是正式專案，更不該直接接受一大包改動。用 git diff 檢查差異，看完再決定要不要保留。diff 是你最後一道防線，跳過它等於把決定權完全交出去。想理解 資訊增益與 搜尋意圖這類觀念的人，應該對「看清楚再決定」特別有感。
錯誤四：把 API Key 放在專案裡
很多 AI 工具、雲端服務、開發工具都會用到 API Key 或 Token。這些東西不要放在程式碼裡，也不要貼到公開專案、截圖或文章裡。如果 AI 工具能讀你的專案，它也可能讀到你放在專案裡的機密資訊。正確做法是放進環境變數或專用的設定檔，並且把那個檔案加進.gitignore。這跟 網域與 網址 URL 基礎裡講的「公開與私密要分清楚」一個道理。
錯誤五：亂執行網路上的安裝指令
有些安裝教學會出現類似 curl https://example.com/install.sh | bash 這種命令，意思是從網路下載一段腳本，然後直接執行。如果來源是官方文件，可能是正常安裝方式；如果來源不明，就很危險，因為你等於把電腦控制權交給一段你沒看過的程式碼。新手看到這種命令，先確認來源是不是官方文件，再決定要不要跑。這跟判斷 Google Search Console、新手網站平台是否可信的邏輯一致。
如果你想更系統化地學好 SEO 與 AI SEO，可以參考我與知識衛星合作的線上課程：《SEO 排名攻略學》、《AI SEO 流量變革》。透過《SEO 排名攻略學》獲得穩定的 SEO 流量與實戰經驗，再搭配《AI SEO 流量變革》看懂 Google AI Overviews、Google AI Mode、AI 搜尋引擎的趨勢，搶佔 AI 搜尋紅利。
不適合用 AI CLI 的情境
AI CLI 很強，但它並非所有任務的最佳解。把「不該用」的情境列出來，你才不會把好工具用在錯地方，反而製造風險或浪費時間。遇到下列幾種情況，建議改用網頁版聊天 AI、查文件，或交給專人處理。
- 你連目前資料夾都還搞不清楚：這個情況下啟動 AI CLI 等於盲飛，先花十分鐘把 pwd、ls、cd 操作到熟，再回來。
- 任務只是純問答、純文字潤飾：改一封 email、整理一段會議記錄，網頁版更快更安全，根本不必動到 Terminal。
- 沒有備份、沒有 Git 的正式專案：在還沒有可回復機制的專案上讓 AI 動手，等於沒有安全網走鋼索，先建好備份再說。
- 涉及機密或客戶敏感資料：除非你完全清楚資料會送到哪、會被誰看到，否則不要把含個資、財務、合約的資料夾交給任何 AI 工具讀取。
- 你完全看不懂它打算執行的命令：看不懂就先停下來查，硬按同意只會把風險往後挪，不會消失。
- 需要高度精確、零容錯的關鍵操作：例如正式環境的部署、刪除大量資料，這類動作交給你親自一步步做、或交由有審核流程的專責人員，比交給 AI 自動化更穩。
辨識這些情境的方法很樸素：問自己「這件事出錯，我能不能承受、能不能回復」。答案是不能，就不要在這個情境下用 AI CLI，或至少先把備份、權限、工作範圍這三道保險補齊。工具的價值在於用在對的場合，把 AI CLI 用在它擅長的開發、整理、批次場景，你才會真的享受到它的槓桿；硬把它塞進不適合的情境，只會放大風險。這份判斷力，跟 部落格平台租屋風險裡強調「先看清楚代價再行動」的態度是互通的。
誰該學 CLI、誰可以先放著
不是每個人都需要立刻深入 CLI。如果你只用 ChatGPT 寫文章、摘要、翻譯、做簡報，可以先不急；但只要你想用 AI 協助寫程式、用 Claude Code 或 Codex CLI 這類工具、學 Git/Python/Node.js、部署網站或做自動化，CLI 就會變成繞不過的基礎能力。連 用 Claude Code 搭建專業網站這類從無到有架站的任務，CLI 也是第一步。
AI 工具的採用速度確實很快。根據 HubSpot 2026 行銷現狀報告，約 80% 的行銷人員已在內容產製流程使用 AI，約 94% 計畫在 2026 年把 AI 納入包含部落格文章在內的內容產製流程 [來源：〈HubSpot 2026 State of Marketing Report〉〈https://www.hubspot.com/state-of-marketing〉〈2026〉]。這組數字說明一件事：AI 已經從「少數人的嘗試」變成「多數工作流程的標配」。當你身邊的人都在用 AI 動手做事，CLI 作為「安全使用這些工具的基本能力」的價值只會更高。
把「要不要學」跟「你的目標」綁在一起看，可以省掉很多無謂的學習焦慮。這張判斷表幫你快速對號入座：
| 你的需求 | 是否需要學 CLI |
|---|---|
| 只用 ChatGPT 聊天、寫文、翻譯 | 不急 |
| 想用 AI 協助寫程式 | 建議學基本 CLI |
| 想用 Claude Code、Codex CLI、Gemini CLI | 很建議學 |
| 想做開發、自動化、部署 | 一定要學 |
我的立場很明確：CLI 不是用來炫技的。它是你「安全使用 AI 工具」的基本能力，門檻沒你想的那麼高，會 pwd、ls、cd、--version、--help 這五個，就比九成只會點滑鼠的人更有掌控力了。如果你連 Typeless AI 語音輸入、BEO 購買引擎優化、Google UCP 與 AI 購物這類新工具都願意試，CLI 其實沒有比較難。
相對地，如果你目前的工作完全不碰檔案、不碰程式碼、不碰部署，那真的不用為了學而學。把心力放在 SEO 是什麼、SEO 關鍵字、長尾關鍵字、內部連結這些對你現階段更有產出的能力上，更划算。CLI 會在你看見需要的那一刻，自動變得值得學。
學習路徑建議：從零到能安全操作
給已經決定要學的人，把過程拆成四個階段，循序漸進比較不會迷路。每個階段都有一個明確的「通過標準」，達到了再往下一步走，不要跳級。
| 階段 | 學什麼 | 通過標準 |
|---|---|---|
| 一、認識環境 | Terminal、Shell、CLI 的差異；pwd、ls、cd | 能說出自己目前在哪個資料夾 |
| 二、基本操作 | --version、--help；安裝一個 AI CLI 工具 | 能獨立裝好工具並回報版本 |
| 三、安全實作 | 建測試資料夾；看 diff；Git 備份 | 能讓 AI 改一個小專案並安全回復 |
| 四、日常整合 | 提問技巧；approval mode；批次任務 | 能把 AI CLI 穩定用在自己的真實工作 |
階段一最容易被低估，卻最關鍵。很多新手直接跳到「裝工具、跑指令」，結果連自己在哪個資料夾都講不清楚，後面所有操作都建立在模糊的地基上。這一階段不要急，反覆操作 pwd、ls、cd 到你能在腦中建立「資料夾樹狀結構」的空間感，後面的學習會快很多。階段二的重點是建立「查答案」的能力：--help 與官方文件是你的兩大靠山，遇到任何陌生指令都先查再說。階段三把安全流程跑順，重點是養成「動手前先看 diff、改完後先備份」的反射動作。階段四才進入日常整合，開始把 AI CLI 當成你工作流程的一部分穩定使用。
給已經決定要踏進來的人，這份新手避坑清單可以當作操作前的檢查表，直接被當成 how-to 使用：
- 執行命令前，先確認目前資料夾（pwd、ls）。
- 不要在正式專案第一次測試 AI CLI。
- 不要無腦複製網路上的命令。
- 看到 sudo、rm、curl | bash 要特別小心。
- AI 要改檔案前，先看它打算改哪裡。
- AI 改完檔案後，記得看 diff。
- 不要把 API Key、密碼、Token 放在專案裡。
- 不懂的命令，先請 AI 解釋，再決定要不要執行。
- 重要專案一定要用 Git 或其他方式備份。
CLI 很強大，AI CLI 又讓它變得更強，但越強大的工具，越需要多一點判斷力。你可以讓 AI 幫你加速，但最後按下同意的人，永遠是你自己。這也是為什麼懂一點命令列，在 AI 時代不再只是工程師的事，而是每個想安全使用 AI 工具的人都該有的基本盤。先會 pwd、ls、cd，會看 diff，會在跑陌生指令前先查一下，你對自己檔案的掌控力就會比只點滑鼠的人多出一大截。
如果你想把視野拉大一點，CLI 之外還有幾條值得走的路：理解 GEO 與 SEO 差異、GEO AEO LLMO 概念、品牌成為被推薦的答案，這幾個方向跟 CLI 看似無關，其實都是同一個問題的不同切面：在 AI 重新分配流量的時代，你能不能看懂機器在做什麼，並且保有判斷權。對 Entity SEO、Perplexity AI、代理式搜尋與資訊代理、Agentic Browsing、llms.txt 這類主題有興趣的人，會發現它們背後都假設你能理解「AI 在讀什麼、改什麼」，CLI 給你的正是這層理解力的入口。
想再往應用層走，可以把工具鏈串起來：Claude Cowork、Claude Desktop 與 MCP、Claude Skills、Claude Design、Claude Fable 5 各自補上不同能力。最後，如果要把這些能力變成穩定產出，AI SEO 流量變革、SEO 排名攻略學、SEO 課程推薦與免費資源、GEO 與 AEO 課程學習資源這幾條路徑，會幫你把技術能力轉成實際的流量與成果。
新手 CLI 常見問題
搜尋與論壇上最常出現的問題整理成 FAQ，答案刻意比正文更精煉，方便你快速查閱。
輸入指令出現 command not found 怎麼辦？
通常是三個原因之一：工具沒安裝、PATH 環境變數沒設好、或開錯了 Shell。先回安裝文件確認步驟，再檢查目前用的是 bash、zsh 還是 PowerShell。
PATH 環境變數是什麼？為什麼會找不到指令？
PATH 是 Shell 用來尋找指令對應程式的資料夾清單。輸入指令後，Shell 會照著 PATH 逐個資料夾找，全部找不到就回 command not found。明明裝了卻找不到，多半是程式裝在 PATH 沒包含的資料夾，把路徑加進設定檔再重開 Terminal 即可解決。
sudo 跟 curl pipe bash 為什麼危險？
sudo 是用系統管理員權限執行命令，能改的範圍很大；curl install.sh 管線接 bash，是從網路下載一段你沒看過的腳本直接執行。看不懂命令就不要亂加 sudo，來源不明就不要跑 curl 管線 bash。
Approval Mode 是什麼？新手該怎麼設？
Approval Mode 是 AI CLI 工具在改檔案、執行命令前先停下來問你的機制，常分逐項詢問、計畫模式、全自動三種。新手與正式專案建議維持逐項詢問，等熟悉工具行為後再放寬到計畫模式，全自動只留給可丟棄的測試資料夾。
AI CLI、網頁版 AI、API 要怎麼選？
純問答潤飾留在網頁版；要把 AI 嵌進產品或長期自動化走 API；想讓 AI 直接改現成專案、整理檔案、跑測試又不會寫接 API 的程式，就用 AI CLI。判斷標準是能不能碰檔案、要不要寫程式、出錯後果落在誰身上。
AI CLI 工具有哪些？差別是什麼？
常被提到的四款是 Codex CLI、Claude Code、Gemini CLI、GitHub Copilot CLI。共同點是「AI 進入你的開發環境」，差別在背後模型、定位與開源與否：Codex CLI 與 Gemini CLI 為開源，Claude Code 與 Copilot CLI 為官方產品。