過去三個月我在工作上密集使用 Claude Code 處理維運任務——從日常巡檢、事件排查、規格撰寫、到跨雲服務的自動化。雖然時間不長,但這段密集的沉浸式經驗讓我意識到兩件事。第一件是,我自己一開始也在事後才意識到,市面上多數談 AI 工具的文章集中在「工具介紹」或「使用教學」的層級,從工程角度拆解運作機制的繁中資源不是那麼容易找。第二件是,從企業維運與合規視角談 AI 助理的繁中資源同樣不多見——這個視角需要結合對 AI 工具的技術理解、對企業資訊架構的實務經驗、以及對合規治理的敏感度,三者剛好同時關心的人不多。

這個系列想填補的,就是這個空缺。我寫的每一篇都有一個共同的預設——讀者是具備工程能力、對效率有要求、同時對合規與治理敏感的專業工作者。不論你是 DevOps、SRE、infra 工程師、還是需要評估 AI 工具的技術主管,這個系列希望提供一條相對完整的脈絡,而不是零散的技巧。

系列地圖

整個系列由十篇文章組成(第 8-10 篇正在準備中)。前半部(第 1-5 篇)聚焦於機制理解,幫你建立對 Claude Code 運作方式比較深入的認知。後半部(第 6-10 篇)轉向決策與治理,處理使用過程中的工具選擇、成本、商務、權限、以及跨階段的工作流整合。

**第 1 篇《為什麼 Claude Code 是不一樣的 AI 工具》**是系列的地基。許多人把 Claude Code、Copilot、Cursor、ChatGPT 當成同類產品比較,我覺得這是類別上的混淆。這一篇先把座標系統建立好,讓你看到 Claude Code 屬於一個完全不同的工具類別——Agentic CLI——它解決的問題、要求的使用方式、帶來的價值,跟 IDE 外掛式的 AI 助理有本質差異。

**第 2 篇《Agent Loop:AI 助理的心跳機制》**開始進入技術核心。你以為自己在「跟 AI 對話」,實際上是在驅動一個迴圈。這個認知的轉換很關鍵——不懂 Agent Loop,後面所有的成本優化、context 管理、權限設計都會是黑盒魔法。這一篇用一個具體情境,拆解從你按下 Enter 到 AI 回應完成之間的六個階段。

**第 3 篇《四層 Context 壓縮:200K 窗口的真實調度》**是整個系列技術密度較高的一篇。Context 管理是 Claude Code 設計上比較精巧、也比較容易被誤解的一塊,而且直接影響使用體驗。這一篇完整拆解四層壓縮管線——Pre-pipeline、Snip Compact、Micro Compact、Context Collapse、Auto Compact——並分析何時用哪一層、為什麼這樣排序、以及 1M context 出現之後這套系統發生了什麼變化。

**第 4 篇《Sub-agent 與 Agent Team》（分上下集)**是一組對照。上集是純技術篇,拆解 Sub-agent 的四種隔離模式、Fork 的 byte-identical prefix 設計、以及 Claude Code 為什麼能每週 spawn 數千萬個分身而不破產。下集是治理篇,談為什麼「一人分飾多角」會搞砸任務、如何用劇組式的角色分工建立可稽核的工作流、以及這套設計為什麼跨 AI 可攜、是你自己設計的工程資產。這兩篇合起來,處理了一個我在繁中資源中不太常看到被一起拆開講的主題。

**第 5 篇《Token 成本的真相》**是實務派讀者最關心的一篇。這篇用一個核心觀念貫穿全文——你不是在為「最近一句話」付費,而是在為「整段對話歷史每輪都重新送一次」付費。理解這件事之後,所有的成本優化策略(Prompt Cache、精簡 CLAUDE.md、主動壓縮、Agent Team 分工)都有了共同的底層邏輯。讀完這篇,你比較容易指出帳單上每塊錢花在哪、哪些可以省、哪些不能。

**第 6 篇《當工具自薦時:SSDLC 裡 Claude 各入口的角色與邊界》**處理一個比方案選型更上游的問題——在 SSDLC 的每個階段,該用哪個 Claude 入口?Claude Code、Claude.ai、API,同一個模型放在不同平台,擅長的事情不一樣。這篇從一次對照實驗開始,揭露 Anthropic 官方承認的 self-preference bias(自我偏好偏誤),並從中導出一組獨立於工具本身的判準——讓 SSDLC 流程本身告訴你答案。下一次 Anthropic 推出新入口、舊入口改版、整個產品結構大洗牌,這組判準應該還能繼續用。

**第 7 篇《選型與合約》**是商務決策的一次性整理。Anthropic 提供四種服務管道,各自解決不同的問題,不是「由小到大的階梯」。這一篇分享我整理的每個方案差異、訓練政策的觀察、資料保留期的官方不一致現象、不同規模使用者的可能路徑,還有一個進階的「去識別化閘道」設計。對我而言,選對方案的一次性決策,常常比後面的技術優化更值得提早花時間想清楚。

閱讀路徑建議

這些文章是一個連貫的整體,但我理解不是每位讀者都有時間通讀。以下是三種路徑建議,你可以依自己的角色挑選最適合的切入方式。

技術深入派如果你最想要理解 Claude Code 的內部機制,建議依序讀第 1、2、3、4 篇。這四篇是純技術篇,看完你應該會對這個工具的運作方式有比較完整的認知,之後讀其他相關文章可能也會更快吸收一些。

實務導入派如果你已經在使用 Claude Code,想解決實際問題——尤其是成本爆炸、行為失控、合規疑慮——建議讀第 1、5、6、7 篇,加上第 4 篇下集。這五篇處理的都是我自己在 POC 中遇到、我猜也是很多人會遇到的問題,原理面的內容被我壓縮到最必要,主要是給你可執行的決策依據。

主管決策派如果你是評估是否要導入、或如何規範團隊使用 AI 工具的主管,建議讀第 1、5、6、7 篇。這四篇包含了我覺得主管視角最需要的資訊——第 1 篇讓你理解這個工具的真實價值,第 5 篇讓你能比較準地估成本,第 6 篇幫你思考不同 SSDLC 階段該用哪個入口,第 7 篇讓你能較有把握地做採購決策。如果連續讀,大約一個下午可以讀完。

系列中的承諾

寫這個系列的時候,我對自己設了幾條明確的邊界。

內容必須真實可驗證,避免 AI 幻覺。所有對 Claude Code 內部機制的描述,都基於公開的逆向工程資料與我自己的實務觀察,每一個具體數字都有來源。寫作過程中我刻意迴避了一些連我自己都不敢確定的細節——寧可用「通常」、「大約」這類框定性語言,也不杜撰精確數字。具體閾值(例如 Auto Compact 的 167K threshold)則標示了計算方式,讓讀者可以自己驗證。

文中引用的案例來自真實的 POC 專案,但敏感細節已全部匿名化。這個系列的內容根基於我目前進行中的一個 POC 專案——把 AI 助理深度導入日常維運工作——所發生的真實事件。這讓文章中的教訓不是純理論推演,而是第一手觀察。但真實事件的組織名稱、人員身份、IP 位址、系統識別碼、客戶資訊都已經全部移除。保留下來的是通用的技術教訓,不是組織內部的 know-how。讀者從案例裡學到的模式應該可以套用到自己的環境,但無從反推原始事件的任何識別資訊。

不代表任何組織立場。所有觀點都是我個人的學習與實務心得整理,跟任職組織的立場無關。如果某個觀點讓你覺得「這跟我認知的主流說法不一樣」,那可能就是我真實的觀察,不是鸚鵡學舌。

內容創作方式是「人類主導、AI 協同」,我坦誠說明這件事。每一篇的觀點、案例、技術判斷都來自我自身的學習,以及在 POC 專案中累積的真實維運實務經驗;文字的組織與表達的打磨則由 AI 協助完成。這也是我寫這個系列時想傳達的一個觀察——對我而言,AI 比較適合用來放大工程師的判斷力,而不是取代它。

最後,技術世界變化非常快。這個系列的某些細節(特別是方案定價、模型規格、API 行為)可能隨時間改變。撰寫時是 2026 年第二季的狀態,讀者如果在之後的時間點閱讀,建議重要決策前再次驗證當時的官方資訊。

接下來

前七篇建立了我目前摸索到的認知輪廓,從機制到治理都接觸了一輪。但整個系列還有三篇正在準備中——第 8 篇《Hooks 與權限系統:讓 AI 聽話的三道關卡》會進一步深入技術性的安全治理;第 9 篇《把 Claude Code 接進維運日常》會是一個 infra 工程師的真實工作流整合;第 10 篇則會專門處理「架構分析」與「飄移檢查」這兩類橫跨 SSDLC 的元活動——它們的工具分工邏輯比單一階段複雜,需要獨立展開。這三篇完成後,整個系列會擴充到十篇,讓「從理解到落地」這條路線能走得更完整一些。

在這之前,如果你有任何建議、疑問、或發現任何不準確之處,歡迎來信 st333117@gmail.com。這個系列的每一篇都會持續改進,你的回饋會讓它更好。

現在,從你最有感的那一篇開始讀吧。

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

本文為《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