Claude Code 2026：AI 開發新術語值得追嗎

如果你看到「prompt engineering 結束了」這個標題第一個反應是「又是新術語嗎」，我懂——我自己看到時也停了一下。但這次背後有個很具體的故事：Claude Code（Anthropic 的 AI 寫程式工具）的負責人 Boris Cherny，在 2026 年 6 月的 Meta @Scale 大型技術研討會上說這話的同一週，微軟因為 token（AI 處理文字的計費單位）費用失控，把五千名工程師的 Claude Code 授權取消了。這篇要拆的是：你是否需要現在就學 loop engineering？

AI 自動迭代迴圈是什麼？

Loop engineering 是由 Google 工程師 Addy Osmani（任職 Google Chrome DevRel 技術傳教士）正式命名的 AI 開發方法論，核心概念是讓 AI agent（可以自己執行任務的 AI 助理）系統設計成可以自動迭代的完整迴路——不是人工一問一答式的 prompt（給 AI 的指令）互動，而是 AI 自己生成 prompt、自己跑迭代、自己評估結果。
Osmani 定義的五段架構：discovery（發現工作）、task decomposition（分解任務）、orchestration layer（協調層，負責任務調度）、verification（驗證輸出）、persistent memory（持久記憶，讓 AI 跨階段保留學到的東西）。
把它放到 AI 三階段框架裡理解更清楚：第一階段是工具化（用 ChatGPT 回答問題）、第二階段是生產系統化（把 AI 接進工作流程）、第三階段是自動優化與高速迭代。Loop engineering 是第三階段的東西。它不是新概念，而是對現有 agent 工作鏈實踐的重新命名。

高採用率不等於正回報

這是這整件事最值得盯住的地方。
微軟 Experiences & Devices 部門（負責 Windows、Microsoft 365、Teams、Surface，約 5000 名工程師）在 2025 年 12 月導入 Claude Code，使用率達到 84 到 95%。按照一般的 AI 導入評估標準，這是成功案例——員工真的在用。但 token 費用提前耗盡年度預算，2026 年 6 月 30 日全數取消授權，轉回 GitHub Copilot CLI（微軟自家的 AI 寫程式助手）。
Uber 的情況類似，在 2026 年前四個月就燒完全年 AI coding 工具預算。
BCG（波士頓顧問集團）2026 年的企業 AI 調查數據（非 Anthropic 自有資料，大規模全球企業研究）：
指標｜數字｜含義
計劃繼續增加 AI 投入的企業｜94%｜投入還在增加
真正重新設計了工作流程的採用者｜21%｜但大多數只是加了工具
員工花更多時間管理 AI 工具的比例｜47%｜工具本身變成了工作
有 AI 策略的公司 vs 無策略的效益差距｜+25 個百分點｜策略比工具更關鍵
數量是給人看爽的，回報才是該被管理的。

Cherny 說的是廣告嗎？

說清楚背景：Boris Cherny 是 Claude Code 的創建者，他的工作職責就是推廣 Claude Code。Claude Code 的年化營收目前已超過 25 億美元（來源：Fortune 2026 年 6 月訪談）。他說「prompt engineering 結束了、loop engineering 時代來了」，這個宣稱直接服務於 Anthropic 的商業目標。
這不代表他說謊，是說他的預測需要以利益衝突角度評估。他描述的技術方向是對的——AI 確實在往「讓 AI 自己設計 prompt、自動迭代」走。但他對落地條件的輕描淡寫，跟微軟和 Uber 的真實帳單之間，存在一個很大的落差。
他的具體建議「給員工自由用 token 去實驗，在後端管控成本」聽起來合理，但前提是你有精細的度量機制。在沒有度量機制的情況下，前端自由和後端管控，是本質矛盾的。

AI 程式碼品質掉了多少？

AI 寫更多程式碼，不代表生產力提升，這有具體數據支撐。
CodeRabbit（2025 年 12 月，獨立程式碼審查工具的實際分析）數據：AI 生成程式碼的算法錯誤頻率是人工的 2.25 倍，整體問題率是人工的 1.7 倍，exception handling（例外狀況處理）缺口翻倍。行數增加 40% 只代表程式碼更囉嗦，負擔從「寫」轉到了「驗」——審查和 QA 的工作量同步上升。
Faros AI 2026 年的分析更直接：raw LOC（原始程式碼行數）已經失去意義作為 AI 導入後的度量指標。Garry Tan（Y Combinator 執行長）用 logical code change（邏輯變更量，而非純行數）衡量 AI 輔助產能，算出 2026 年他自己的產出是 2013 年的 810 倍——但他本人明確標注，這是 greenfield（全新、沒有舊系統包袱）專案、資深開發者的最佳條件下的自述，不代表平均情況，也不能外推到企業環境。

我實測 AI 工作鏈的踩坑

我自己跑過 agent-to-agent pipeline（多個 AI 角色接力的工作鏈）——一個負責研究、一個負責起草、一個負責品質把關，串接在一起自動跑。
最早一版我沒有定義每個環節「完成長什麼樣子」。結構化 handoff（任務交接鏈，一個 AI 步驟做完、把結果直接交給下一個步驟接手）做完了，流程看起來很順，但輸出有個系統性偏差，我沒有在第一關就攔到它，結果後面幾個環節接連放大了這個錯誤。
那次讓我學到：沒有驗收標準的自動化，只是讓問題跑得更快。後來我強迫每個 skill（把特定能力封裝成獨立模組）在定義的時候都要回答兩個問題：「這個步驟不能做什麼」跟「輸出長什麼樣才算完成」。這兩個問題回答清楚之前，不能接到 pipeline 裡。
那之後流程才真正穩定，也才有辦法去追「每一百萬 token 換回了什麼產能」，而不是只看 token 有沒有燒完。

loop 迭代的四個前提

BDTechTalks（2026 年 6 月 22 日分析）點出了 loop engineering 值得投入的四個前提條件，缺任何一個，投入只會加速燒錢：
任務夠重複：loop 的設計成本很高，只有高重複性任務才能回收設計成本
終止條件可機械驗證：stop condition（讓 loop 知道什麼時候停）必須能被程式自動判斷，而不是「AI 覺得夠好了」。沒有可驗證的終止條件，loop 只是高速生產看起來合理但品質未知的輸出
token 成本可管控：BDTechTalks 把不受控的 loop 擴張稱為 loopmaxxing，微軟和 Uber 的案例就是 loopmaxxing 的企業規模版本
有充裕的 token 預算：loop 每輪消耗多輪 token，初期設計階段更是要燒大量 token 做實驗
大多數開發者現在面對的是 legacy 程式碼（舊系統，有技術債）和非重複任務。這四個前提，你的團隊現在符合幾個？
如果答案是「不確定」或「一兩個」，loop engineering 現在對你來說是第三階段的東西，你的當務之急是把第二階段做紮實——也就是把現有 AI 工作流程系統化，先把度量衡換對。

度量衡該怎麼換？

從「看行數、看 token 消耗量」換成這兩個維度：
第一，logical code change（邏輯變更量）：不看增加了多少行，看實際有多少邏輯被修改或新增。這個維度能分辨「AI 寫了很多囉嗦的包裝程式碼」和「AI 真的解決了一個邏輯問題」。
第二，每一百萬 token 換回的產能回報：以 token 為分母，分子是你定義的業務產出（完成功能的數量、解掉 bug 的數量、減少的 code review 輪次）。這個指標逼你回答：投入這筆 token 費用，我拿回了什麼？
McKinsey 的分析（來源：Master of Code 2026 彙整 McKinsey 報告）指出，工作流程重新設計才是與 EBIT（稅前息前利潤）相關性最強的單一因素——不是工具本身，是工具後面的系統設計。
把度量衡換對之前，loop engineering 或任何新術語都是在虛胖的基礎上加速。
方法論收尾：不要被術語的節奏牽著走。判斷框架是：先確認你在 AI 三階段的哪個位置，第二階段沒做紮實之前不追第三階段；每次導入新工具前先定義「完成長什麼樣子」和「怎麼衡量回報」，這兩個答案沒有之前不下單。
自我檢查三問：
你現在衡量 AI 產出的指標是什麼？行數、token 消耗、還是實際邏輯變更量？
你的 AI 工作流程有明確的驗收標準嗎——「完成」長什麼樣子有定義嗎？
你的團隊在 AI 三階段裡的哪個位置？工具化、生產系統化、還是已經在做自動優化？

常見問題

• loop engineering 跟 prompt engineering 差在哪？
  prompt engineering 是人工設計每一輪給 AI 的指令，loop engineering 是讓 AI 系統自己設計指令並自動跑多輪迭代。前者是人主導，後者是系統主導。技術方向是真實的，但落地條件更嚴苛。
• 現在學 loop engineering 晚不晚？
  不是時間點問題，是前提條件問題。如果你的 AI 工作流程還沒有可機械驗證的終止條件、成本管控機制、高重複性任務，現在學等於在沙地蓋樓。先把這些前提滿足再學。
• 微軟取消 Claude Code 代表 Claude Code 不好嗎？
  不代表。微軟是因為 token 預算管理問題，不是產品品質問題。Claude Code 年化營收超過 25 億美元，它有其價值——問題在於沒有配套度量機制的大規模導入。
• Garry Tan 的 810 倍產出可以參考嗎？
  他本人明確標注：這是 greenfield（全新專案、無舊系統包袱）、資深開發者條件下的自述，非第三方驗證數據，不代表平均情況。這個數字可以當「最佳情境上限」的參考，不能當一般企業的 ROI 預測。
• token 成本真的能「後端管控」嗎？
  可以，但要有精細的度量機制作為前提。微軟和 Uber 的案例顯示，在企業規模下，沒有精細度量機制的「後端管控」是來不及的。

【 查看更多 AI 工具懶人包 】

💬 Danny Facebook

💬 ​​​​​​Danny Instagram

💬 Danny Threads