本文為《AI 輔助維運工程:從 Claude Code 機制到企業落地》系列第 1 篇。全系列共十篇(第 8-10 篇正在準備中),從原理到落地完整涵蓋。

一個工程師的困惑

我手上已經有 GitHub Copilot,每天打開網頁版 Claude 問東問西,偶爾用 Cursor 改 code。為什麼還要在 terminal 裡裝一個 Claude Code?

這是我一開始的疑問。我猜很多人也是。

答案我花了一段時間才真的想清楚:這些工具不是在競爭同一件事,它們解決的根本就是不同類別的問題。把它們擺在一起比較,就像把「螺絲起子、電鑽、CNC 加工機」拿來問「哪一個比較好?」——問題本身就設定錯了。

這篇文章不是要告訴你 Claude Code 比其他工具「更好」,而是要說清楚它是什麼種類的東西。理解這件事之後,後面幾篇的技術細節你才能真的吸收。

先把座標定好:四種工具在做四件事

我用自己的理解把市面上常見的 AI coding 工具分成四類。分類標準是「它主要在幫你做什麼層級的事」:

這張表不是要排名高下。每一種工具都有它最適合的場景:寫前端切版,Copilot 行內補全超好用;討論一個演算法,網頁版 Claude 反而最合適;想在 IDE 內一次改 20 個檔案,Cursor 是最舒服的選擇。

Claude Code 屬於第四類,也是目前繁中圈討論相對少、但對 infra 與後端工程師可能很有價值的一類。

Claude Code 在做什麼:三個關鍵特徵

把 Claude Code 定位成「Agentic CLI」之後,它的設計選擇就變得合理了。我整理三個讓它和前三類工具根本不同的特徵。

特徵一:它是真正的 Agentic Loop,不是 Autocomplete

Copilot 在幫你打字,Claude Code 在幫你完成任務。

差異在哪?行內補全是「輸入 → 猜測 → 輸出」的單次循環。Agentic loop 是:

接收任務
  → 讀取 context(檔案、git 狀態、past conversation)
  → 呼叫模型決策
  → 執行工具(讀檔、寫檔、跑 bash、搜尋)
  → 把結果餵回給模型
  → 判斷任務是否完成
  → 完成 or 進下一輪

這個迴圈可以跑 5 次、20 次、甚至 100 次,直到任務真的完成或者達到上限才停。你不需要每一步都手動點「繼續」。

我第一次真正體會到這個差異,是請 Claude Code 幫我處理一個「從 production 撈最近 7 天的 nginx log、找出回應時間異常的 request、產出 markdown 報告」的任務。我給它的 prompt 很短,但它自己:

1. 先問我 log 放在哪
2. 用 grep 和 awk 篩出候選行
3. 發現時間格式有兩種版本的 log,自己調整 parser
4. 產出表格,還主動附上我沒要求的「建議下一步」

整個過程我只回了「在 /var/log/nginx/」這一句。這就是 agentic loop — 它把分解任務、執行、驗證結果這些原本是工程師在做的事,也一起接手了。

這個能力是 Claude Code 的技術基礎,也是後面所有章節的前提。如果這件事沒發生,權限系統、context 管理、token 優化都是假議題。

特徵二:權限系統是 First-Class Citizen,不是事後補的

一旦工具可以執行 bash,風險就來了。

這是所有 agentic 工具必須面對的問題。Claude Code 的設計選擇是:把權限管控放在架構的第一層,而不是事後用規則補。

它的權限模型有三個層次(這是後面第 8 篇會細講的主題,這裡先建立印象):

• CLAUDE.md:指導性約束(軟)。你用自然語言告訴 AI 「不要修改 migrations/ 目錄」。
• Permission Rules:聲明性約束(中)。settings.json 裡寫 allow / deny / ask 規則,例如 "Bash(rm -rf:*)": "deny"。
• Hooks:可編程約束(硬)。在 tool 執行前插入腳本,可以做任意檢查、修改、甚至攔截。

三層不是任選其一,是縱深防禦。CLAUDE.md 可以被模型繞過,但 permission rules 擋得住;permission rules 匹配不到的模糊情境,hooks 可以用程式判斷。

這件事聽起來理所當然,但很多 AI coding 工具是先做功能,再補權限,導致你得自己用外圍手段(例如另開容器、限制帳號權限)去防。Claude Code 把這件事當設計地基處理,我覺得對需要在企業環境下使用的人比較有感。

特徵三:Context 管理是工程問題,不是黑盒子

大語言模型有個硬性限制:context window。目前 Claude 系列模型的上下文窗口通常以數十萬 tokens 計,聽起來很多,但如果你跑一個兩小時的維運任務,它會填滿得比你想像快。

Context 滿了會發生什麼?模型開始忘東西,回答品質下降,最後乾脆拒絕繼續。

大多數 AI 工具對這件事的處理方式是「看運氣」—— 希望模型自己記得關鍵資訊。Claude Code 的做法是把 context 當成要主動管理的工程資源,設計了多層壓縮管線,在不同階段用不同策略釋放空間。

這件事的細節會在第 3 篇完整展開(那一篇會是整個系列最燒腦的一篇)。這裡先記一個結論:Claude Code 的 context 管理不是黑盒,它是一套可觀察、可調控、可最佳化的系統。理解這套系統,對後面「如何省 token、如何讓長任務跑得穩」這些實務問題比較有幫助。

它適合誰,不適合誰

設計哲學釐清之後,適用場景也就清楚了。以下是我的判斷,不是官方說法:

適合的人

• 後端工程師 / DevOps / SRE / infra 工程師:你有大量跨檔案、跨服務、需要 shell 才能完成的任務。
• 有版控習慣的人:Claude Code 會直接改檔案,沒有 git 你會救不回來。
• 能接受 CLI 的人:它的主要介面就是 terminal,不會有人想把它弄成圖形介面。
• 想把 AI 當協作者而不是神諭的人:你需要檢查它的產出、給它 context、設計工作流。

暫時不適合的人

• 純前端切版 / 純 UI 調整的工作:Cursor 這類工具視覺化支援更好。
• 完全不看 terminal 的人:學習曲線會卡很久。
• 一次性問答需求:「幫我解釋這段 code」這種需求,網頁版 Claude 反而快。
• 想要「一鍵產生完整專案」的人:Claude Code 可以做,但你得先搞懂權限、context、hooks 這些基礎,否則會失控。

這不是貶低任何一群人。工具有適用場景,選對工具比硬用同一個好。

給主管的一段話

如果你是主管,在決定要不要讓團隊用 Claude Code,我自己的看法是:把它當成工程生產力工具來評估,我覺得比當「試試看的 AI 玩具」來看更走得遠。

• 它不是要取代工程師。以我自己這三個月 POC 的觀察,它讓一位工程師的單日產出能被放大。
• 它確實有學習成本。我自己初期幾週也是越用越順手、並不是一上手就看出明顯效益。
• 它需要配合組織層面的規範(權限設定、敏感資料保護、產出審查),不是裝了就能用。
• 它的費用在團隊理解 token 消耗邏輯之後是可預測的(第 5 篇會詳談)。

評估投資報酬時,我自己不太看「AI 寫了幾行程式碼」這類指標,覺得那比較容易誤導。我比較看的是「工程師完成同樣任務需要的總時間」和「產出的品質與可追溯性」。

這個系列會回答什麼

這是系列第 1 篇。已經上線的六篇依序展開機制、成本、與決策:

系列還有三篇正在準備中——第 8 篇《Hooks 與權限系統》會深入技術性的安全治理,第 9 篇《把 Claude Code 接進維運日常》是一位 infra 工程師的真實工作流整合,第 10 篇則專門處理「架構分析」與「飄移檢查」這兩類橫跨 SSDLC 的元活動。

如果你是純技術派,我建議讀 1、2、3、4 就夠。 如果你是實務派,讀 1、5、6、7 就夠,加上第 4 篇下集。 如果你是主管,讀 1、5、6、7 就夠。

一句話收尾

Claude Code 不是「比較強的 Copilot」。對我而言,它是一種讓工程師從執行者變成指揮官的工作方式,代價是你需要理解它的運作機制,不能當黑盒用。

下一篇我們從最基礎的 Agent Loop 開始拆解。

本文作者:鄧景仁 (Scott Teng) | 資訊服務業 infra 工程師,專注於 Azure / Linux / 安全維運。如需討論可聯繫 st333117@gmail.com。

本系列所有內容為個人學習與實務心得整理,不代表任職機構立場。

本文原刊於 https://eeit.github.io/ai-devops-blog/posts/01-why-claude-code-is-different/，作者：鄧景仁 (Scott Teng)。
授權條款：CC BY-NC 4.0 · 禁止商業使用；分享請署名並註明原文 URL。
商業授權請聯絡：st333117@gmail.com