AI 導入的階段

翻譯 by 知識倉鼠

原作者：Boris Cherny 2026 年 7 月 16 日 原文推文 ↗

我每天都在跟其他公司的工程師聊，聽到的都是同一件事：有一個人用 Claude 把自己的產出做到了 10 倍，但組織裡其他人還沒跟上。

看著各團隊導入 AI，我一再看到同樣的這 4 個階段。

我把它們整理在這裡。

引言出自 Boris Cherny 的原推文（中文翻譯）

表格可左右滑動查看完整內容 →

階段與角色 Agent 數 實際樣貌 瓶頸在哪 各階段可用的產品 防護機制
0：受阻 0

只核准較舊或較輕量、較快的模型，延遲在 AI gateway 與自建認證上層層疊加，沒有 MCP 治理，內部想用 AI 工具都被卡關或流程繁重。

沒有 IT 基礎設施或核准路徑可以託管 Claude 產出的程式碼與成品，產出只存在本機。

老舊的資安與核准流程，只盯著「每個 token 的成本」而非實際成效，決策圈裡缺少真正懂技術的聲音。
  • Claude.ai 對話
  • SSO／SCIM 搭配角色權限控管
  • 組織層級的預算上限
  • 部署在既有的核准流程與 IAM 之內
  • 資料治理方案
如何從第 0 階段走到第 1 階段：對齊高層與採購決策者，並把阻礙往上呈報；建立安全導入 Claude 的框架。
1：輔助你 + 一個 agent（結對） 約 1

一位工程師搭一個 agent，大多在監督之下，像個很快的結對程式夥伴。你一次只跑一個 session，幾乎每一筆變更合併前都會親自審過。

解鎖：以前要耗掉一整個下午的變更，現在在會議空檔就能收掉。

你的注意力，以及每個回覆與程式修改都得檢查的需求。由於對模型輸出的信任度低、又缺乏自我驗證，你覺得每一行都得讀，於是眼睛從不敢離開。

工作是同步的：Claude 在做事時你只能坐著盯，沒辦法先去推進下一件事。
  • 桌面版、CLI 或 IDE 裡的 Claude Code
  • Claude Cowork、Claude Design
  • 透過 Anthropic API、Bedrock、Vertex 或 Microsoft Foundry 使用
  • Claude Code 分析儀表板 + Analytics API
  • Claude Enterprise 的 Compliance API
  • Plan mode，在動手改之前先審過意圖
  • 每席次的花費上限
  • 集中管理的模型與 effort 設定
  • 集中管理的政策
  • 把 OpenTelemetry 匯出到既有的 SIEM 與可觀測性堆疊
如何從第 1 階段走到第 2 階段：一次跑不只一個 agent；建立一套你信得過的自我驗證迴圈（測試 + build + lint，加上用真實開發環境跑 e2e）；開啟 auto mode，避免被權限提示卡住；把 code review 自動化。
2：並行協調者 約 10

一位工程師同時協調 5 到 10 個 agent，每個各在自己的 worktree 或 git checkout 上，在它們之間來回切換。Claude 在你看到之前會先檢查自己的成果，包括測試、build、lint 與資安掃描。Auto mode 全程開著，自動 code review 與資安審查預設開啟。產出倍增，你審的是最終的 diff 而不是逐個按鍵，維護工作的待辦開始縮短。大部分程式碼由 Claude 撰寫。

解鎖：以前整個團隊要好幾週的待辦，變成一位工程師一個下午的協調工作。

審查產出。你親手寫的程式變少，改成同時盯六股輸出，這反而更吃你的時間。

一邊在多個 session 之間切換，一邊還要下 prompt 與導引模型。
  • 用 Analytics 監看團隊用量
  • 自動化的程式品質把關：lint、自動化測試、typecheck
  • 由 Claude 驅動的端對端驗證（例如用 Claude Chrome extension 或 iOS／Android 模擬器 MCP）
  • 人工 code review、合併與資安審查。對人寫的與 agent 產生的程式碼守同一條品質線
  • 在 settings.json 裡預先核准常見且安全的 bash 與 MCP 指令
如何從第 2 階段走到第 3 階段：給 Claude 一條拉進脈絡的路（讓它讀程式碼、wiki 與討論串）；提升自主權與 code review 速度（agent 可能會動到其他團隊擁有的程式碼）；把工作拆成 loop 與 routine；讓 Claude 去啟動 Claude。
3：受監督的自主管理者的管理者（一棵組織樹） 約 100

Claude 撰寫全部或幾乎全部的程式碼。「你讀過程式碼了嗎？」變成「模型缺了什麼脈絡，我們下次怎麼幫它補上？」

解鎖：以前要你手動啟動的工作，Claude 現在會主動去做。過去要等有人有空才處理的維護與清理，現在在背景持續不停地跑。

對這套迴圈的信任，以及團隊的決策吞吐量。agent 樹太深，沒辦法一個個盯著，而你的陷阱是：在這套迴圈還沒贏得普遍信任之前，就先把 agent 數量衝上去。

隨著用量上升，要確保 token 用得有效率。這需要監控（透過 OTel 或 Analytics），以及一種在內部使用情境找到 PMF 後、一邊鼓勵實驗一邊控制成本的文化。問問自己：這件事是工程師本來也會做的嗎？
  • 具 worktree 隔離的 subagent（讓並行的 agent 不會互相撞車）
  • Routines、/loop、/batch 與 /goal，把重複性工作展開分派
  • 動態 workflow
  • Claude Tag（讓它監看某個頻道或資料來源，主動啟動任務）
如何從第 3 階段走到第 4 階段：把特定領域的使用情境做到規模化的自動化（例如程式碼遷移、fuzzing、功能開發、回饋修補）。
4：AI 原生以意圖掌舵的副總 約 1,000+

迴圈完全閉合，大多數 agent 由 Claude 啟動。數百到數千個 agent 同時在跑，你以意圖掌舵，只在例外時介入監看。

解鎖：一個原本要做一整季的遷移，變成一條你按下啟動、之後只需查看進度的 workflow。

大規模地辨識並自動化工作，並為每一種工作套上對的防護機制。
  • 用 Claude Agent SDK 以程式化方式建立並排程 agent
  • Claude Tag（活躍於大多數 Slack 頻道，自動回應貼文）
  • 自動化的成本控管
  • 自動化的模型選型

作者補充

Boris Cherny 在原推文下方接續的說明串（中文翻譯）。

  1. 這些階段沒有唯一正確的走法。每個團隊、每家公司都不一樣。但在每一階段，光靠 token 並不足以推你前進：要走到下一階段，你得找出並拆解下一組瓶頸，再建立起下一組防護機制。
  2. 具體來說，這代表要給 Claude 一套能端對端驗證自己成果的方法。代表把權限的 auto mode 打開、預設開啟自動 code review 與資安審查，並使用能讓你同時管理多個 agent 的介面（CLI、桌面版、iOS 與 Android app 裡的 Agent view，以及 Tag）。要再往更高階走，代表用上 /loop、/batch、動態 workflow，以及 subagent 的 worktree 隔離。重點不在單一功能，而是用對的功能搭配對的防護機制，讓 Claude 能以團隊信得過的方式，把一整類工作自動化。
  3. 等團隊都買單之後，你要怎麼追蹤成效？用量值得看（例如儀表板），但它衡量的是活動量，不是回報。有個更好的問題：這件事你原本就會投入工程人力去做嗎？如果會，要投多少、換算成人工工時又要花多少成本？
  4. 更大的回報，出現在修復與維護都在背景自動發生、團隊得以專心開發的時候。那時你會開始做以前根本搆不著的事。Anthropic 目前在第 3 階段、正往第 4 階段推進；我個人則剛踏進第 4 階段。很好奇你在哪裡：你的團隊在第幾階段？

有讀者留言說「這串看起來像是 Claude 做的」，Boris 回覆：這張表格是他本人做的，貼文串則是他和 Claude 一起完成。

本頁由 知識倉鼠 翻譯自 Boris Cherny 的〈Steps of AI Adoption〉（2026 年 7 月 16 日），原文出處為他的 X 貼文。版面沿用原作，內文文件連結已改指向 Claude Code 官方繁體中文文件。產品與功能名稱（如 Claude Code、Auto mode、MCP 等）保留英文原名。