大多數人聽到「AI 寫程式」，第一反應是打開 Cursor 或 GitHub Copilot，然後把整個開發環境搬過去。但如果你已經習慣自己的編輯器、熟悉現有的終端機工作流，每次為了試用新 AI 工具就得重新配置快捷鍵和插件，這種「搬家成本」其實比想像中高。
Claude Code 的切入點不太一樣——它不是要你換編輯器，而是直接住進你的終端機裡，成為一個「會寫程式、會讀檔案、會執行指令」的 AI 代理人。我實測了兩週，發現它特別適合已經有開發習慣、不想被工具綁架的一人公司或自由工作者。
為什麼需要「住在終端機」的 AI？
傳統 AI 編程助手有個共同問題：它們通常綁定特定 IDE 或編輯器。Cursor 再好用，你也得把專案搬進去；GitHub Copilot 雖然支援多種編輯器，但主要還是圍繞 VS Code 生態設計。
但實際工作場景是什麼？你可能同時在跑本地開發伺服器、監看 log、切換 Git 分支、偶爾 SSH 進遠端機器調整設定。這些動作大多發生在終端機，而不是編輯器裡。
Claude Code 的設計哲學是「在你原本的工作流裡插一個 AI 夥伴」。你可以繼續用 Vim、Neovim、Sublime 或任何編輯器，Claude Code 在終端機裡待命，隨時可以叫它讀檔案、寫程式、執行測試、甚至幫你 debug 執行結果。
實際怎麼運作？三個真實場景
場景一：快速重構舊專案的 API 回傳格式
我有個三年前寫的 Node.js 小專案，當時 API 都直接回傳 JSON 物件，沒有統一的 response wrapper。現在要改成 { success: true, data: ... } 格式，手動改會碰到 20 幾支檔案。
我在終端機輸入：「幫我把 /api 資料夾裡所有 route handler 的 res.json（） 改成統一的 response wrapper 格式，保留原本的錯誤處理邏輯。」
Claude Code 會先列出它打算修改的檔案清單，確認後一次性完成。整個過程我不用離開終端機，也不用把專案匯入新編輯器。改完我直接 npm run dev 測試，發現有兩處錯誤處理邏輯它理解錯了，再補一句「auth.js 的 401 錯誤要保持原本格式」，它就修正了。
場景二：讀 log 檔找出效能瓶頸
某個客戶反應網站後台載入變慢，我拿到一份 3MB 的 server log。以前我會用 grep、awk 慢慢篩，或者貼進 ChatGPT 但又超過字數上限。
這次我直接在終端機：「讀 server.log，找出所有 response time 超過 2 秒的 request，按時間排序並統計是哪幾支 API。」
Claude Code 會直接在本地執行分析（不用上傳敏感 log 到雲端），產出一份清單告訴我「/api/products/search 在 14:23-14:45 之間有 37 次請求超過 3 秒」。我再追問「這個時間區間資料庫有什麼異常嗎」，它會建議我去檢查對應的 DB slow query log。
場景三：一次性生成測試資料腳本
要幫新功能準備測試資料，需要產生 200 筆符合特定格式的假資料。我給 Claude Code 看一份範例 JSON，請它「寫一個 Node.js script 產生 200 筆類似結構的測試資料，名字要台灣常見姓名、email 要合法格式、日期要在過去三個月內隨機分佈」。
它產出腳本後我直接 node generate-data.js 執行，發現日期格式跟資料庫欄位不符，再補一句「日期改成 YYYY-MM-DD HH:mm:ss」，不用重開檔案或切換視窗，改完立刻重跑。
什麼情況下 Claude Code 不適用？
不是所有開發場景都適合叫 AI 代理人。以下三種情況我會覺得它幫倒忙：
- 需要深度理解業務邏輯的核心功能開發——例如金流串接、權限設計這類「出錯會出大事」的部分，我還是會自己手寫並仔細 review，而不是丟給 AI 生成後再來除錯。
- 多人協作專案的 coding style 統一——Claude Code 會按它的理解寫，但團隊可能有特定的 linter 規則或命名慣例，這時候用 GitHub Copilot 搭配專案既有的 ESLint 設定反而更省事。
- 完全不熟悉的語言或框架——如果你連基本語法都看不懂，AI 生成的程式碼你也無法判斷對錯。Claude Code 比較適合「你知道要做什麼、只是不想手刻重複邏輯」的場景。
跟 Cursor、GitHub Copilot 該怎麼選？
| 工具 | 最適合場景 | 需要改變的工作習慣 |
|---|---|---|
| Cursor | 從零開始的新專案、需要 AI 深度參與架構設計 | 需要切換到 Cursor 編輯器 |
| GitHub Copilot | 在編輯器內即時補全程式碼、寫 unit test | 需安裝插件，主要支援主流編輯器 |
| Claude Code | 既有專案的批次重構、log 分析、腳本生成 | 幾乎不用改，繼續用原本的編輯器與終端機 |
我自己的搭配方式是：新專案或需要大量程式碼生成時開 Cursor，日常維護既有專案時用 Claude Code 在終端機待命，偶爾寫複雜邏輯時讓 GitHub Copilot 在編輯器裡補全。工具不是二選一，而是不同情境下的最佳拍檔。
兩週使用後的真實感受
最明顯的改變是「減少上下文切換」。以前碰到要批次修改檔案或分析 log，我會先在終端機跑指令、再把結果複製到 ChatGPT、然後回到編輯器手動修改。現在這些動作可以在同一個終端機視窗裡完成，Claude Code 會記得前幾輪對話的上下文，不用每次都重新解釋專案架構。
另一個意外收穫是「可以把它當成會寫程式的 CLI 工具」。例如我要快速統計某個資料夾裡各種檔案類型的行數佔比，以前會去查 find + wc 的語法，現在直接問 Claude Code「統計 src 資料夾各副檔名的總行數」，它會生成並執行對應指令，我連語法都不用記。
但它也不是萬能。遇到需要頻繁 UI 預覽的前端調整（例如 RWD 斷點微調），還是在 VS Code 配合 Live Server 比較直覺。Claude Code 比較適合「邏輯重於畫面」的開發任務。
一人公司為什麼需要這種工具？
如果你是接案者或一人公司，很可能同時維護 3～5 個不同技術棧的專案。切換專案時最耗時的不是寫新功能，而是「回想這個專案的資料夾結構、API 設計慣例、部署流程」。
Claude Code 的優勢在於「每次對話都可以重新建立上下文」。你可以一開始就丟給它「讀 package.json 和 README，告訴我這個專案的主要功能和架構」，讓它快速進入狀況。這種「隨傳隨到但不綁定特定專案」的彈性，對需要頻繁切換專案的一人團隊特別實用。
另一個隱藏價值是「降低學習新工具的成本」。當客戶要求用特定 CMS 或框架，你不用花整天讀文件，可以直接問 Claude Code「這個專案用的是 Strapi，幫我解釋 /api 資料夾的路由設計邏輯」，它會結合專案實際程式碼給你情境化的說明，比看官方文件更快進入狀況。
實際導入建議
如果你想試試看，我會建議從「低風險的重複性任務」開始。例如批次重新命名變數、產生測試資料、分析 log 檔、寫簡單的自動化腳本。這些任務就算 AI 出錯，你也能快速發現並修正。
不要一開始就丟核心業務邏輯給它。先建立信任感，了解它在哪些情境下可靠、哪些情境下會理解錯誤。我自己大概用了一週，才開始放心讓它處理資料庫 migration script 這類比較關鍵的任務。
另外記得定期檢查它生成的程式碼。AI 很會寫「看起來對」的程式，但可能忽略 edge case 或效能問題。把它當成「初階工程師夥伴」而不是「資深顧問」，你還是需要 review 和把關。
結語
Claude Code 不會取代你的主力編輯器，也不是要你把整個開發流程交給 AI。它的價值在於「在不改變現有習慣的前提下，插入一個會寫程式的助手」。
對一人公司或自由工作者來說，這種「低侵入性」的工具特別重要——你不需要為了試用新 AI 就重新配置整套開發環境，也不用擔心哪天訂閱取消就得全部搬回來。它就是終端機裡的一個指令，需要時叫它、不需要時也不礙事。
如果你也在找「不綁編輯器、能融入既有工作流」的 AI 協作方式，或者想了解怎麼把 AI 工具實際落地到網站開發或維護專案的日常，歡迎找我聊聊你的使用情境，我很樂意分享更多實測心得。
