為什麼要用 AI CLI？

0 · 從零開始：你真正需要先準備什麼？↑ 回本頁選單

0.1 第一次開始前，先確認這四件事（Git 可稍後補）

1. 一台電腦與終端機：Windows PC 請用「Windows Terminal 裡的 PowerShell」；Mac 開「終端機」；Linux 開你的 Terminal。它就是之後貼安裝指令、執行工具的地方。
2. 網路與一套工具的帳號路線：先選一套即可。已經有對應帳號就從那套開始；四套都沒有帳號時，先選你願意使用的服務，到官方登入或方案頁建立／確認帳號，再回來安裝。Codex 要能使用 OpenAI／ChatGPT 的登入方式；Copilot 要有可用訂閱；Google 的一般個人帳號先依 Antigravity CLI 的瀏覽器畫面與帳號資格登入，組織／學校、API key 或 Vertex 情境才依指定的 Gemini CLI 流程；Claude 則依官方登入方式開始。不要為了比較一次註冊四個帳號，也不要借用別人的帳號、驗證碼或 API 金鑰。
3. Git（強烈建議，但不是今天不能開始的門票）：第一次可以先完成安裝、登入與唯讀練習；在第一次讓 AI 修改檔案前，再安裝 Git、確認 git --version，並建立可回復點。它能讓你查看改動、保留紀錄，必要時回到先前狀態。還沒有 Git 時，先從 Git 官方下載頁裝對應系統的版本。
4. 一個不怕弄壞的練習資料夾：第一次不要直接把公司專案、客戶檔案或唯一一份重要文件交給 AI。可以用空資料夾；若要練習「讀懂資料夾」，請先在裡面放一個自己寫的 README.md，寫兩三句「這是我的練習資料夾」。沒有檔案也沒關係，第一次任務就改成請它確認資料夾是空的，且不要建立或修改任何檔案。

0.2 Node.js 到底要不要裝？先看這張表

關鍵觀念：「npm 可以安裝某個 CLI」不等於「所有 CLI 都必須先裝 Node.js」。npm 只是一種安裝通路；是否需要 Node.js，要看你選的工具與安裝法。

0.3 當你選的安裝法要自行準備 Node.js 時，照這樣做

1. 先確認你是主動選了某套工具的 npm／npx 安裝法，或該工具的官方安裝頁明確要求你自行提供 Node.js。一般個人帳號使用 Antigravity CLI 不需要 Node.js；只有已確認使用 Gemini CLI 的限定路線，再依官方指定的安裝方式準備 Node.js／npm。不要還沒選路徑就先手動裝一輪。
2. Windows／Mac：到 Node.js 官方下載頁選目前的 LTS 安裝程式；照預設選項安裝即可，npm 會一起提供，不必另外找一個「npm 安裝檔」。安裝前也回看你選的 CLI 官方頁，確認它的最低版本要求。
3. Linux／WSL：同樣從 Node.js 官方下載頁選目前 LTS，依你的發行版使用官方列出的安裝方式。不要直接複製不明部落格的 sudo 指令；Node 版本與套件來源會過期。
4. 安裝完成後，關掉再重新開終端機，逐行輸入下面兩個檢查。兩行都有版本號，才代表 Node.js 與 npm 已可用。

node --version
npm --version

0.4 選到安裝工具前，先確認它真的存在

winget、brew、npm 不是三個都要裝的東西，而是三條不同安裝路。只檢查你想走的那一條：有印出版本號才繼續；出現「找不到指令」不是叫你改加 sudo，而是回上一節換一條官方支援的路徑。

Windows：只有選 WinGet 時

winget --version

Mac／Linux：只有已選 Homebrew 時

brew --version

npm／npx 路線：只有已選 Node.js 安裝法時

npm --version

例如 Copilot 的 Windows 原生路線才需要 winget；它的 npm 路線才需要 Node.js。Homebrew、MacPorts、Anaconda、WSL 都是已經知道自己在用哪個環境的人可選的分支，不是第一次安裝時必做的清單。

0.5 Git：先驗證，再做第一個可回復點

Git 不是每套 CLI 的登入門票，但你只要準備讓 AI 改檔，就很值得先裝。裝好後開一個新的終端機視窗，輸入 git --version；看到版本號才算可用。第一次要 commit 時，Git 可能問「我是誰」：這是 commit 紀錄顯示的名字與 email，不是 CLI 登入，也不要填公司或他人的資料。下面第二、三行是範本：先把兩組引號內文字改成你自己的值，不能原樣複製。

git --version
git config --global user.name "先改成你的公開顯示名稱"
git config --global user.email "先改成你要寫入 commit 的 email"

Git commit 通常會公開或分享給協作者；在意 email 隱私時，先依你使用的 Git 服務官方說明選適合的 noreply email。空資料夾沒有任何檔案可 commit，不是錯誤：先建立一個 README.md，或先跳過 commit 練習。

0.6 WSL 是另一台 Linux，不是 Windows Terminal 的必備設定

Windows 新手先在 PowerShell 完成第一輪即可。只有你主動選擇 Linux 開發環境、或公司／工具文件要求時，才安裝 WSL。它會在 Windows 裡建立一套獨立的 Linux；你在 PowerShell 裝的 Node、Git、CLI，Ubuntu 裡看不到，反過來也一樣。

1. 決定要走 WSL 時，按 Microsoft 的 WSL 官方安裝說明在系統管理員 PowerShell 執行安裝，並依提示重新啟動。
2. 第一次開 Ubuntu 時，建立它自己的 Linux 使用者名稱與密碼；輸入密碼時畫面不會顯示字元是正常的。
3. 從此選一邊做入門練習：要嘛 Windows Terminal 的 PowerShell，要嘛 Ubuntu／WSL。不要在一邊安裝、另一邊找不到指令時又同時重裝。

0.7 PATH、設定檔與 API key：遇到時先保護資料，不要硬修

安裝成功卻顯示「找不到指令」時，先把整個終端機視窗關掉再重新開；許多 PATH 問題到這一步就結束。仍失敗時，先依該工具顯示的實際安裝位置與官方疑難排解處理，不要猜著改 ~/.zshrc、~/.bashrc 或 Windows PATH。

API key、token、公司 proxy URL 與憑證都是敏感資料。只有你選了 API／企業路線且知道帳務與資料權限時才建立；從官方控制台取得、只存本機受保護設定，不貼進 prompt、聊天截圖、Git repo、.env 範例或公開文件。懷疑外洩時先到原服務撤銷並重建，不要把 key 再貼給人幫你診斷。

0.8 看到這些字樣先停一下

/path/to/project、YOUR_API_KEY、vX.Y.Z、你的名字 都是示意字，不能原樣貼上。sudo、rm -rf、Set-ExecutionPolicy、curl | bash 則可能改權限、刪資料或下載執行程式；只有在你已確認官方來源、知道它會改什麼、且目前在自己的練習資料夾時才考慮執行。公司電腦遇到憑證、proxy、管理員權限或帳務問題，先問 IT／管理員，不要猜值繞過限制。

0.9 裝好後，不要立刻叫它改真實專案

先在練習資料夾啟動你選的 CLI，完成登入後只交一個唯讀任務：「先確認目前資料夾是否為空；若不是空的，用三點說明它的用途、主要檔案與可能的執行方式。不要建立、修改或執行任何檔案。」能看懂它讀了什麼、怎麼回報，再進入本頁的第一次安全練習。這個順序比多裝一個套件更能避免第一次就失控。

✅官方 版本門檻、帳號資格與安裝方式會改；請以 Claude Code、Codex CLI、GitHub Copilot CLI、Google 的產品轉換公告、Antigravity CLI 安裝與登入 與 Node.js 的目前官方頁面為準。本站把耐久的判斷順序放在前面，逐字指令留給各工具安裝章節。

1 · AI CLI 到底是什麼？↑ 回本頁選單

CLI 是「命令列介面」（Command-Line Interface）的縮寫，也就是終端機裡用文字操作工具的方式。AI CLI 則是在這個環境裡加上一個會使用工具的 AI 代理。你用平常說話的方式交代目標，它可以自己決定該讀哪些檔案、該跑什麼命令、該怎麼修改，再從執行結果判斷下一步。

真正關鍵不是「打字的地方從網頁換成黑色視窗」，而是下面這個迴圈可以在同一個環境裡持續運作：

1. 看真實現況：讀目前檔案、設定、Git 歷史、錯誤紀錄。
2. 決定下一步：先釐清需求與影響範圍，再選修改方式。
3. 真的動手：改檔、建立檔案、執行既有工具。
4. 取得回饋：讀 build、lint、test、瀏覽器或程式執行結果。
5. 修到有證據：失敗就根據新資料繼續修，通過後交出 diff 與驗證紀錄。

✅官方 OpenAI、Anthropic、Google 與 GitHub 的文件都把讀取專案、使用工具、規劃與驗證放在核心工作流裡。👤達人 Simon Willison 把 coding agent 歸納成「模型加工具，在回饋迴圈裡反覆工作」；本站用上面的五步翻成新手能直接操作的版本。

2 · 聊天網頁、IDE、CLI、雲端代理怎麼選？↑ 回本頁選單

現在產品界線已經愈來愈重疊：有些 IDE agent 也能跑終端機，有些 CLI 也能開瀏覽器，有些桌面 app 能直接讀本機專案。所以下表比較的是最自然的工作方式，不是宣稱某個入口絕對做不到另一個入口的事。

3 · CLI 實際幫你省下哪六件事？↑ 回本頁選單

最重要的變化不是「AI 幫你多打幾行程式碼」，而是你可以從每一步的操作者，慢慢轉成定義目標、提供邊界、檢查證據的人。但省掉手動搬運，不代表可以省掉理解需求、風險判斷與最後 review。

4 · 哪些情況適合？哪些情況先不要？↑ 回本頁選單

🌐獨立研究 目前沒有可靠證據能保證每個人使用 coding agent 都固定快上幾倍。效益會被任務類型、專案品質、使用者經驗、review 成本與錯誤代價大幅影響。本站不使用「一定 10 倍」當賣點。

5 · 你的第一次成功：先走一個 15–20 分鐘安全迴圈↑ 回本頁選單

第一次不要挑「做完整 App」。選一個可以復原、可以看懂差異的小練習，重點是親手走完 CLI 的基本迴圈。

1. 1
   ✋動手做

   準備一個練習資料夾與 Git

   用新資料夾或你不怕弄壞的練習 repo。先確認沒有重要的未提交改動；如果還沒用 Git，先跟著工具教學的 Git 章節完成初始化。

2. 2
   ✋動手做

   先叫它只讀，不要改

   先請它確認資料夾是不是空的；若不是空的，再用三點說明用途、主要檔案、可能的執行方式與不確定處。明講「先不要建立、修改或執行任何檔案」。你會先看到它如何自己找資料。

3. 3
   ✋動手做

   只交一個很小的修改

   例如補 README 的「如何啟動」、替一個函式補測試，或修正一段明確文字。限制它不要重構、不加套件、不碰其他檔案。

4. 4
   ✋動手做

   讓它自己執行最小檢查

   有測試就跑相關測試；只有 README 就檢查 diff、連結與格式。不要接受「應該可以」，要求它說出實際跑了什麼、結果是什麼。

5. 5
   ✋動手做

   你自己看 diff，再決定保留或復原

   確認只改到答應的範圍、文字與行為符合期待。滿意就 commit；不滿意就請它修或還原。走到這裡，你已經完成一次「讀 → 改 → 驗 → review → 留紀錄」。

第一次可直接貼這段，不綁任何一家 CLI

這是我的第一次 AI CLI 練習。請分兩階段進行：

第一階段先唯讀，不要改任何檔案：
1. 先確認目前資料夾是否為空；若不是空的，用三點說明它的用途、主要檔案與可能的執行方式。不要建立、修改或執行任何檔案。
2. 告訴我你實際讀了哪些檔案，哪些地方還不確定。

第二階段等我同意後再開始：
1. 只改善 README 裡「如何啟動」的小節；沒有這個小節就新增。
2. 不加套件、不重構、不改其他檔案。
3. 完成後檢查 git diff，列出實際改了什麼。
4. 執行能證明這次修改沒問題的最小檢查；沒有自動測試就誠實說明。
5. 不要 commit，最後讓我自己決定保留或復原。

6 · 長一點的任務，怎麼交代才不容易走偏？↑ 回本頁選單

不用學神祕咒語。官方最佳實務和高手工作流反覆出現的核心，其實就是把四件事講清楚：

目標：
讓使用者可以在設定頁切換深色模式，重新整理後仍保留選擇。

背景：
先讀現有設定頁、主題 token、localStorage 用法與相關測試；沿用專案現有模式。

限制：
不要新增 UI 函式庫，不改無關頁面，不自行升級套件。先提出計畫，確認影響範圍後再改。

完成條件：
1. 切換、重新整理、系統偏好三種情境都符合規格。
2. 相關 build、lint、test 通過。
3. 以實際瀏覽器檢查桌機與手機畫面。
4. 最後列出改動、驗證命令、結果與仍未驗證的項目。

範本是起點，不是表格作業。小任務可以只寫一句；答錯代價高、牽涉多檔案或需求有歧義時，才值得把四段補齊。更多可直接使用的句型見官方 Prompt Library與跨 CLI 進階提示技巧。

7 · 從新手到高手，不是把自動化一次開滿↑ 回本頁選單

還沒準備好碰終端機？先從 Cursor 練手感

還不敢碰終端機，可以先在看得見檔案的地方練「讀 → 改 → 驗」：先讀 Cursor 完整教學，在編輯器裡看懂 Diff、開一個安全練習場，練到敢接受也敢拒絕。練順了，再照下面選一套終端機開始。

終端機四套：選一套開始

• Claude Code：你已在 Anthropic 生態，想從完整規格、專案記憶、驗證一路學到平行 session。
• Codex CLI：你已有 ChatGPT／OpenAI 使用習慣，想把 AGENTS.md、sandbox、codex exec 與多代理學完整。
• GitHub Copilot CLI：工作高度依賴 GitHub，或希望在同一套 CLI 裡切換多家模型。
• Google AI CLI：一般個人帳號先走 Antigravity CLI，不必先裝 Node.js；只有已確認組織、API key 或 Vertex 路線的人才使用 Gemini CLI 限定內容。

Cursor 只是先陪你把「看 diff、跑檢查、留紀錄」的習慣練熟；練熟之後，終端機用的是同一套紀律——看 diff、跑檢查、留紀錄，再決定接受或復原，不是切換到另一套。

8 · 長時間開發的全貌：別把希望全壓在一條超長對話↑ 回本頁選單

長任務真正的敵人通常不是「AI 不夠努力」，而是目標開始漂、舊錯誤汙染後續判斷、做過的決策沒有留下來、下一個 session 只能猜。對話壓縮與 resume 能幫忙延續，但不等於可靠的專案記憶。

1. 1

   先定義需求與不做的事

   把使用者目標、範圍、非目標、風險與驗收寫進 SPEC.md。需求不清楚時先讓 AI 訪談你，不急著實作。

2. 2

   唯讀盤點，再把計畫寫成檔案

   先找現有模式、測試方式與影響範圍。把可逐項勾選的工作、依賴順序與完成條件寫進 PLAN.md，不要只留在聊天紀錄。

3. 3

   一次只做一個可驗證切片

   每個切片都能在幾十分鐘到兩小時內說清楚、執行檢查並 review。做完更新計畫，不要一次叫 AI 改完五十項再回頭找問題。

4. 4

   讓驗證形成回饋壓力

   build、typecheck、lint、單元測試、整合測試、真實瀏覽器與安全檢查各證明不同事情。先跑既有測試建立基線，修改後再跑；綠燈不代表不必人工看行為。

5. 5

   用小 commit 留下可回復狀態

   一個概念一個 commit，訊息說明完成什麼與為什麼。平行任務放到不同 branch／worktree，避免兩個代理同時踩同一份工作目錄。

6. 6

   在 context 變髒之前主動交棒

   更新 HANDOFF.md：已完成、實際命令與結果、目前 Git 狀態、已排除方向、殘留風險、下一個最小動作。開新 session 先讀這些檔案與最近 commit。

7. 7

   最後用乾淨視角 review

   由沒參與實作的 session、另一家 CLI 或人類重新對照 spec、diff 與實際行為。生成者和審查者共用同一脈絡時，容易一起漏掉同一個假設。

四種「記憶」不能混為一談

長任務收工前，可請任何 CLI 產生這份交棒

請替下一個全新的 session 更新 HANDOFF.md。不要假設它看得到這段對話。

至少包含：
1. Goal／Non-goal：目標與明確不做的事。
2. Done：已完成項目、重要決策、實際修改檔案。
3. Evidence：執行過的完整驗證命令、結果、日期；沒驗的要標 UNVERIFIED。
4. Git state：目前 branch、最後相關 commit、未提交 diff 與是否乾淨。
5. Failed paths：試過但不採用的方向，以及不採用原因。
6. Risks：已知風險、外部依賴、版本敏感資訊。
7. Next first action：下一個 session 開始後，第一個可直接執行的小步驟。

最後重新讀一次 HANDOFF.md，確認只靠這份檔案、SPEC.md、PLAN.md 和 Git 歷史就能接手。

✅官方 Anthropic 的長任務實驗明確指出：只靠 context 壓縮仍可能一次做太多、留下半成品、遺失進度或過早宣告完成；需求清單、進度檔、描述清楚的 commit、乾淨交棒與端到端驗證才是更穩的做法。GitHub 官方也把複雜任務整理成 explore → plan → review → implement → verify → commit。

9 · 自主程度與權限：全自動不是「更高級的新手模式」↑ 回本頁選單

自動化至少有兩個不同問題：它要不要先問你，以及作業系統實際允許它碰到哪裡。Codex 把 approval 與 sandbox 分成兩個旋鈕；其他工具的模式名稱也不一樣。不要把某一家旗標貼到另一家。

本站給新手的推薦很單純：先用第 1 級看懂，再用第 2 級做小事；只有任務已重複成功、能自動判斷對錯，才升到第 3 級。第 4 級不是能力徽章，而是把更多風險交給外部隔離環境承擔。

10 · 為什麼要同時讀官方與民間高手？↑ 回本頁選單

兩條線回答的問題不同。官方文件最適合確認「現在真的有哪些功能、旗標、安全限制與支援範圍」；具名高手與工程團隊比較常公開「實際怎麼安排工作、哪裡卡住、怎麼建立驗證與接棒」。社群討論能提早暴露地雷，但最容易混入版本過時與單一案例誇大。

這頁採用的核心資料

查證日期：2026-08-01。CLI 更新很快，逐字指令請回到官方文件與本機 --help。這頁刻意只保留比較耐久的工作原則。