在科技產業，很少有人能像 Gokul Rajaram 一樣，親身參與並建構了網際網路時代最重要的幾具「營收引擎」。他曾被稱為「AdSense 之父」，在 Google 建立了價值數十億美元的廣告網絡；隨後轉戰 Facebook 主導廣告產品體系；接著在 Square 協助建立了中小企業的支付生態；並在 DoorDash 擔任高階主管。

在這場與 Patrick O’Shaughnessy 的深度訪談中，Gokul Rajaram 以其橫跨二十年的實戰經驗，剖析了在生成式 AI 爆發的當下，產品開發、商業模式、企業護城河以及人才職涯將面臨何種翻天覆地的變化。

本文將其核心洞察整理，旨在為產品經理、創業者及投資人提供一份在 AI 浪潮下的導航指南。

• 一、 產品開發的範式轉移：從「確定性」到「判斷力」
• 二、 在 AI 時代建立持久的商業護城河
• 三、 廣告商業模式的終極型態
• 四、 巨人的肩膀：向傳奇創辦人學習
• 五、 給 AI 世代人才的職涯建議
• 結語：在無限生產力中尋找價值

——————————————————————————–

一、 產品開發的範式轉移：從「確定性」到「判斷力」

AI 帶來的改變不僅僅是工具層面的優化，而是從根本上改變了軟體開發的邏輯與產品團隊的結構。

1. 軟體本質的改變：非確定性（Non-deterministic）軟體

過去十年，產品開發遵循著明確的邏輯：如果使用者做了 X，系統就會產出 Y。這是一個「確定性」的世界，產品經理（PM）、設計師與工程師的角色涇渭分明。然而，Gokul 指出，現在我們正在建構「非確定性」的軟體。如果你輸入 X，AI 可能會產出 Y，但在些微變數下，它可能產出完全不同的結果。

這種轉變導致了「評估」（Evaluation/Evals）變得至關重要。既然無法預寫所有規則，PM 的職責便從「定義功能」轉向了「定義並驗證結果」。PM 需要與研究人員合作，建立能夠判斷 AI 產出是否合理的評估機制，甚至需要撰寫 AI 程式來評估另一個 AI 的產出，因為人類無法手動檢查海量的生成內容。

2. 「AI Slop」危機與判斷力（Judgment）的價值

Gokul 提出了一個發人深省的觀點：在未來，真正能「抗通膨」且「防過時」（Future-proof）的能力，是判斷力（Judgment）。

隨著 AI 程式碼生成工具（如 GitHub Copilot, Cursor 等）的普及，工程師的產出效率將無限放大。但隨之而來的風險是「AI Slop」（AI 廢料）的氾濫——大量的、低品質的、甚至含有錯誤或漏洞的程式碼被快速生成,。在這個「什麼都能做」的時代，核心問題變成了「什麼才是值得做的？」以及「這段程式碼/設計是否符合我們的標準？」。

因此，無論是工程師審查 AI 寫的程式碼，還是設計師審查 AI 生成的介面，人類的核心價值將回歸到「編輯」與「判斷」。就像 Twitter 創辦人 Jack Dorsey 曾將 PM 定義為「產品編輯」（Product Editor）一樣，未來的產品人必須具備極高的品味與判斷力，從無限的可能性中刪減出最精華的部分。

3. 職能邊界的消融與「由下而上」的開發

傳統「PM 定義 -> 設計師設計 -> 工程師開發」的流水線正在崩解。Gokul 觀察到，現在的產品開發更多是「由下而上」（Bottoms up）的。由於模型能力迭代太快（每兩個月就推進一次邊界），過度嚴謹的規格文件反而會限制創新。

現在的趨勢是，PM、設計師與工程師圍坐在一起，直接針對程式碼或原型進行協作。PM 必須變得更親手實作（Hands-on），甚至需要能夠使用 AI 工具（如 Claude Code）來提交程式碼或製作原型。

更有趣的是設計師與工程師的比例變化。Gokul 指出，過去這個比例可能是 1:3 或 1:10，現在正走向 1:20。因為一旦設計系統（Design System）確立，AI 就能基於該語言自動生成大部分的設計工作，企業只需保留少數頂尖設計師來維護設計語言，而將資源投入更多能解決複雜問題的工程師身上。

——————————————————————————–

二、 在 AI 時代建立持久的商業護城河

對於創業者而言，這是一個既興奮又危險的時刻。Gokul 警告，如果你試圖建立一個「輕量級」的應用，基礎模型公司（Foundation Model Companies）或大型企業內部的工具很快就會吞噬你。那麼，如何建立一家能存活十年的 AI 公司？

1. 避開「實用性定價」的陷阱

Gokul 特別點名了像 Zendesk 這類依賴「席位」（Seats）計費的 SaaS 公司面臨的巨大風險。這類公司的價值建立在「實用性」（Utility）上，每個席位代表一個人類客服。然而，AI Agent（代理人）正在取代這些人類工作。客戶可以用 30 個 AI Agent 加上 20 個 Zendesk 席位，來取代原本的 50 個席位，這將導致老牌軟體公司的營收被慢慢抽乾。

未來的商業模式必須轉向**「成果導向定價」（Outcome-based pricing）**。例如，不是按人頭收費，而是按「成功解決的工單數」或「帶來的營收」收費。Palantir 就是這方面的佼佼者，他們敢於對客戶說：「如果我們沒解決問題，你不必付錢；解決了，我們要分一大筆」。

2. 五種新型態的護城河（Durability）

由於軟體的半衰期在 AI 時代變得極短，創業公司必須擁有以下至少一種「稀缺資產」才能確保持久性：

1. 網絡效應（Network Effects）： 如 DoorDash，擁有消費者、餐廳和外送員的三方網絡，這不是靠寫程式就能輕易複製的。

2. 金流掌控（Money Movement）： 當你的軟體不僅處理資訊，還處理金流（如 Square, Toast），轉換成本會大幅提高。

3. 硬體整合（Hardware）： 軟硬整合（如 Toast 的 POS 機）增加了替換的物理門檻。

4. 稀缺資產或人脈（Scarcity）： 例如 Sierra 這家公司，擁有像 Bret Taylor 這樣能讓任何 CEO 接電話的人物，這本身就是一種 Alpha。

5. 系統紀錄（System of Record）： 成為數據的最終歸屬地。

3. 與「系統紀錄」的戰爭：遷移成本是關鍵

過去，AI 新創喜歡依賴 Salesforce 或 Slack 等大公司的 API 來建立「行動系統」（System of Action）。但現在，這些老牌巨頭意識到了威脅，開始切斷 API 或提高收費（如 Slack 切斷 Glean 的存取權）。

因此，AI 公司別無選擇，必須建立自己的「系統紀錄」，成為全端平台（Full Stack）。但這裡最大的挑戰是數據遷移（Migration）。Gokul 強調，除非你構建了強大的遷移工具，否則客戶不會為了新功能而放棄累積了十年的數據。這往往需要耗時一兩年，甚至雇用外包團隊專門處理舊系統的數據搬運，這才是真正的競爭壁壘。

——————————————————————————–

三、 廣告商業模式的終極型態

作為廣告技術的權威，Gokul 對於 OpenAI 等新興巨頭進入廣告市場有著獨到的見解。他認為，要建立成功的廣告業務，只有三條路徑：

1. 擁有珍貴的第一方用戶與場景： 如 Google（搜尋）和 Facebook（社交）。

2. 極致的成果交付（Outcome Delivery）： 如 AppLovin，專注於推動「App 安裝」這一特定成果，並控制了供需兩端。

3. 排他性的需求端代理（Exclusive Provider）： 如 The Trade Desk，幫助大品牌管理在 Google/FB 圍牆花園之外的預算。

ChatGPT 的恐怖潛力：意圖 + 身份

Gokul 認為 ChatGPT 若進入廣告市場，將擁有無與倫比的優勢。Google 擁有「意圖」（Intent，用戶搜尋什麼代表想買什麼），Facebook 擁有「身份」（Identity，用戶是誰）。而 ChatGPT 兼具兩者。

透過多輪對話，ChatGPT 不僅知道你在找什麼（意圖），還能從對話脈絡中拼湊出你是誰（身份）。這結合了搜尋的高轉化率與社群媒體的精準定位，是廣告人的終極夢想。

然而，挑戰在於「平衡」。廣告會稀釋用戶的參與度（Engagement）。Gokul 回憶在 Facebook 時，他們有嚴格的「參與度預算」（Engagement Budget），即為了換取營收，最多只能容忍用戶活躍度下降多少百分比。OpenAI 等新玩家必須謹慎處理這一點，或許可以考慮對高端用戶維持「零廣告」的承諾。

——————————————————————————–

四、 巨人的肩膀：向傳奇創辦人學習

Gokul 的職業生涯讓他得以近距離觀察矽谷最偉大的幾位領導者。他分享了這些傳奇人物的獨特之處：

1. Larry Page & Sergey Brin (Google)：技術與規模的極致追求

Google 的基因是「技術優越性」與「規模」。Gokul 分享了 AdSense 的故事：當團隊為營收成長自豪時，Larry Page 卻感到失望，因為他們只佔了全網廣告的一小部分。Larry 在乎的不是賺多少錢，而是「Google 是否參與了全球每一個廣告的投放」。這種對 100x 規模的執著，造就了 Google 的霸業。

另一個經典案例是 AdSense 的審核機制。團隊原本花費半年建立了複雜的人工審核流程，卻被 Sergey Brin 一句話推翻：「為什麼要審核？讓他們直接上線，如果流量大了再審查。」Sergey 的邏輯是，不要在門口設卡，而是透過數據在事後進行風險控管。這奠定了 Google 自動化、自助服務（Self-serve）的基石,。

2. Mark Zuckerberg (Facebook)：成長駭客與「學習」的超能力

Zuck 被譽為消費產品成長與互動的頂級大師。他能一眼看出產品流程中哪裡會降低用戶互動。但 Gokul 對他印象最深的是「透過跟隨來學習」（Learning by following）。

當年 Zuck 為了搞懂廣告，親自參與廣告團隊會議長達一年。著名的「自訂受眾」（Custom Audiences）功能，就是 Zuck 從 Zynga（當時最大的遊戲廣告主）的抱怨中獲得靈感而提出的。他將「遊戲公司想找大鯨魚玩家」的需求，轉化為「廣告主上傳客戶名單進行匹配」的通用功能，這成為了現代數位廣告的基石,,。

3. Jack Dorsey (Square)：設計即是「消除摩擦」

Jack Dorsey 將設計提升到了商業策略的高度。好的設計不只是好看，而是「不需要說明書」。當時所有的 POS 機都需要培訓員工數天，只有 Square 是下載 App 就能用。

更重要的是，Jack 將設計思維應用到了「風險控管」上。傳統銀行在「申請時」進行嚴格審核（拒絕率高），Square 則是在「交易時」進行即時風控（接受率 95%）。這種將風險從「商家層級」轉移到「交易層級」的創新，本質上也是一種設計：消除了用戶進入的摩擦力,,。

——————————————————————————–

五、 給 AI 世代人才的職涯建議

在這個變動的時代，個人的職涯策略也需要調整。

1. 成為「AI 代理人的指揮官」

未來的管理者，管理的不是人類，而是 AI Agents。Gokul 預測，中階管理層將大幅減少。每位管理者應該要有「全職工作」，如果你的管轄範圍（Span of Control）少於 10 人，你就不該是個純管理者，而必須是個獨立貢獻者（IC）,。

最有價值的技能，是成為某個領域的專家，並懂得編排（Orchestrate）一組 AI Agents 來完成該領域的工作。

2. 拒絕「職位跳跳虎」，擁抱長期主義

作為招聘經理，Gokul 直言「12 到 18 個月就換工作」是最大的紅燈,。在一家公司待的時間若不足 3-4 年，很難產生真正的影響力。在 AI 時代，建立深度、累積信任、並看到一個專案從頭到尾的成果，比以往任何時候都重要。

3. 在面試中展現「實作力」

別再只靠「說」來面試了。Gokul 建議，無論是設計師、PM 還是業務開發，都應該在面試中要求「工作專案」（Work Project）。給候選人一個實際的模糊問題（例如：Square 是否該收購這家公司？），看他們如何拆解問題。

最好的候選人甚至會「拒絕前提」。Gokul 曾遇過 PM 候選人被要求規劃某功能，結果他跑去街訪了 10 個客戶，回來報告說：「客戶根本不需要這個功能，我們應該做另一個。」這種具備客戶洞察與獨立思考的「代理權」（Agency），才是頂尖人才的標誌,。

——————————————————————————–

結語：在無限生產力中尋找價值

Gokul Rajaram 的分享為我們描繪了一個既充滿無限可能、又充滿雜訊的未來。當 AI 讓「製造」變得極其廉價，人類的價值便轉移到了「選擇」與「判斷」。

無論你是正在構建下一個獨角獸的創業者，還是試圖在職場中突圍的專業人士，核心問題不再是「我能建造什麼？」，而是「什麼值得被建造？」。在這個服務業的工業革命中，唯有深刻理解客戶痛點（Why）、具備獨特判斷力（Judgment）、並能善用 AI 槓桿的人，才能穿越週期，建立起真正的價值。

“The one thing that’s going to be truly future-proof is judgment.” — Gokul Rajaram

——————————————————————————–

(本文內容取材自 “Invest Like The Best” Podcast 訪談)

前言

為什麼我們Build School 的AI 與軟體人才培訓，除了軟體工程基礎(前/後端及DevOps)外，已完全擁抱 AI 及雲端呢? 從培訓起就開始上手 AI 工具及輔助開發呢? 以及為何 AI Agent 將會是軟體的未來延伸呢? 可看以下文章分析。

—————————-

在人工智慧技術飛速發展的今天，我們正處於一個技術典範轉移的關鍵時刻。OpenAI 的 API 與開發者平台工程主管 Sherwin Wu 近期在《Lenny’s Podcast》中進行了一場深度訪談，不僅分享了 OpenAI 內部的工程文化與 AI 使用現狀，更對未來 12 到 24 個月的 AI 發展趨勢做出了具體預測。

Sherwin 的觀點不僅僅是技術層面的分析，更涵蓋了管理哲學、創業生態系的重組，以及企業如何正確導入 AI 的策略。本文將這場長達一小時的訪談精華，整理為六大核心主題，為軟體工程師、管理者及創業者提供一份詳盡的未來指南。

——————————————————————————–

一、 工程師角色的演變：從「撰寫代碼」到「施展魔法」

軟體工程師的工作本質正在經歷前所未有的劇變。在 OpenAI 內部，這種變化已經成為現在進行式。

1. 驚人的內部數據：Codex 已經無所不在

Sherwin 透露了一個令人震驚的數據：在 OpenAI，95% 的工程師每天都在使用 Codex（AI 程式碼生成工具），且 100% 的 Pull Requests (PRs) 都會經過 Codex 的審查。這意味著每一行進入生產環境的程式碼，都有 AI 的參與。

這導致了一個顯著的生產力差異：經常使用 Codex 的工程師，其開啟的 PR 數量比不常使用的工程師多了 70%，而且這個差距正在持續擴大。這顯示出熟練掌握 AI 工具的工程師，其產出能力正在與傳統工作模式拉開巨大的鴻溝。

2. 工程師變身為「巫師」與「管理者」

Sherwin 引用了經典電腦科學教科書《SICP》（電腦程式的構造和解釋）中的隱喻，將程式設計比喻為「巫術」（Sorcery），而程式語言則是「咒語」（Incantations）。

在 AI 時代，這個比喻變得更加貼切。工程師不再需要逐行撰寫程式碼，而是向 AI 發出「咒語」（Prompt/指令），然後由 AI 去執行具體任務。這使得工程師的角色從「IC（獨立貢獻者）」轉變為「技術主管（Tech Lead）」或「管理者」。

現在的工程師更像是管理著一支「Agent 艦隊」的指揮官。他們可能同時開啟 10 到 20 個執行緒，指揮不同的 AI Agent 處理任務，並在過程中給予反饋和修正。

3. 「魔法師的學徒」與失控風險

然而，這種強大的槓桿效應也伴隨著風險。Sherwin 提到了迪士尼電影《幻想曲》中「魔法師的學徒」（The Sorcerer’s Apprentice）的故事：米老鼠偷戴了魔法帽，指揮掃把幫忙提水，結果卻因為無法控制而釀成大水災。

這正是當前「Vibe Coding」（憑感覺寫程式）的風險所在。當工程師讓 AI Agent 自動執行任務時，必須具備足夠的資歷與判斷力，以確保 AI 不會「脫軌」。這也是為什麼即便 AI 能寫程式，人類工程師的審查與架構設計能力反而變得更加重要。

——————————————————————————–

二、 「一人十億美元新創」的迷思與 B2B SaaS 的黃金時代

OpenAI 執行長 Sam Altman 曾預言，我們很快會看到由一人創辦的十億美元估值公司。Sherwin 對此提出了更深層的「二階與三階效應」分析。

1. 二階效應：B2B SaaS 的寒武紀大爆發

Sherwin 認為，如果一個人就能建立十億美元的公司，這意味著「建立軟體」的門檻已經大幅降低。這將導致一個**「B2B SaaS 的黃金時代」**。

為了支撐那一家「一人十億美元公司」，市場上可能會出現數百家小型新創，專門為這類公司打造客製化的軟體工具。我們會看到成千上萬家營收規模在 1000 萬到 5000 萬美元的小型軟體公司遍地開花。這些公司可能無法達到傳統創投追求的百倍回報，但對於創辦人個人而言，卻是極佳的財富自由途徑。

2. 支援服務的瓶頸與機會

儘管 AI 可以解決開發問題，但「客戶支援」（Customer Support）往往是擴張的瓶頸。Lenny 在訪談中質疑，光是處理大量的客訴單就足以讓一人公司崩潰。

Sherwin 則反駁，這正是上述「微型 SaaS」的機會點。未來可能會出現專門為特定利基市場（例如：專為 Podcast 經營者設計的 AI 客服系統）服務的新創公司。這些高度垂直整合的 AI 工具，將使得一人公司能夠外包絕大部分的營運工作，從而維持極精簡的人力編制。

——————————————————————————–

三、 AI 時代的管理哲學：賦能頂尖人才

隨著 AI 放大了個人能力的差距，管理者的角色與策略也必須隨之調整。

1. 10倍工程師變成 100倍工程師

AI 工具讓頂尖人才（Top Performers）的效率倍增。Sherwin 觀察到，那些積極擁抱 AI、具有高度主動性（High Agency）的員工，其生產力正在遠遠拋離其他人。

因此，管理者的策略應該是：將 50% 以上的時間花在這些頂尖人才身上，確保他們開心、沒有阻礙，並擁有所有需要的資源。這與傳統管理學有時強調「輔導落後者」的思維截然不同。

2. 外科醫生團隊模型

Sherwin 引用了《人月神話》（The Mythical Man-Month）中的「外科醫生團隊」概念：在手術室裡，只有主刀醫生在進行核心工作，其他護理師、麻醉師都是為了支援這位醫生而存在。

雖然軟體開發比手術更具協作性，但 Sherwin 傾向於讓團隊成員感覺自己就是那位「外科醫生」。管理者的工作是「預判轉角後的狀況」（Look around corners），在工程師遇到組織障礙或缺乏工具前，就先幫他們掃除障礙，就像遞上手術刀一樣自然。

3. AI 協助管理者擴大管理半徑

傳統軟體工程團隊的最佳管理跨度（Span of Control）約為 6-8 人。但在 AI 輔助下，管理者可以利用 AI 快速閱讀大量文檔、PR 和 Slack 訊息，掌握組織脈動與專案進度。這可能使管理者能夠有效帶領規模更大的團隊，甚至預測團隊未來可能遇到的瓶頸。

——————————————————————————–

四、 企業導入 AI 的陷阱：由下而上與「鷹架 scaffolding 」理論

許多企業在導入 AI 時面臨 ROI（投資報酬率）為負的窘境。Sherwin 指出，成功的關鍵在於導入的方式，以及對技術發展路徑的正確判斷。

1. 避免「由上而下」的強推

最糟糕的模式是 CEO 下令「我們要是 AI優先公司」，並強迫員工將 AI 納入績效考核，卻沒有實際的應用場景。

相反地，成功的企業通常結合了高層的支持與**「由下而上」（Bottom-up）的採用**。企業應該尋找內部對 AI 最有熱情的「傳教士」（可能是工程師，也可能是擅長 Excel 的營運人員），組成「老虎隊」（Tiger Team），由他們去探索具體的工作流，並在內部分享最佳實踐。

2. 警惕：「模型會把你的鷹架當早餐吃掉」

這是訪談中最具洞察力的金句之一。Sherwin 引用了 FinTool 創辦人 Nicholas 的觀點：「模型會吃掉你的鷹架（The models will eat your scaffolding for breakfast）」。

所謂的「鷹架」，指的是開發者為了彌補早期 AI 模型能力不足，而在模型周圍搭建的各種輔助框架（如複雜的 Agent Frameworks、向量資料庫 Vector Stores 等）。

• 歷史教訓： 2023 年時，大家認為必須依賴向量資料庫來提供上下文。但隨著模型 Context Window（上下文視窗）變大且檢索能力變強，直接將大量文件丟給模型處理（如 Skills / MD files）反而效果更好。

• 苦澀的教訓（The Bitter Lesson）： 不要過度設計複雜的邏輯來引導模型，因為隨著算力提升和模型迭代，這些人為的邏輯往往會被更強大的通用模型所取代。

3. 給開發者的建議：為未來的模型而建

Sherwin 強烈建議開發者：「要針對模型未來的發展方向構建產品，而不是針對它們今天的限制。」。

如果你發現某個功能現在的模型只能做到 80%，別急著放棄或建立複雜的補丁。因為在 6 到 12 個月後，下一代模型可能直接就能完美解決這個問題。那些賭對方向的產品，會在模型升級瞬間獲得巨大的體驗提升。

——————————————————————————–

五、 未來 12-24 個月的 AI 預測

站在 OpenAI 的視角，Sherwin 對未來兩年的技術發展給出了具體預測，這些將是開發者和企業必須關注的重點。

1. 長時間運行的 Agent (Long-running Tasks)

目前的 AI 工具（如 ChatGPT 或 Cursor）主要優化的是「分鐘級」的互動任務。但在未來 12-18 個月內，我們將看到能夠穩定執行**「數小時甚至數天」**任務的 AI 模型。

這意味著工程師可以指派一個 AI Agent：「去幫我重構這個模組，跑完測試，修好 Bug，明天早上再跟我回報。」這種長時間的自主運作能力，將徹底改變軟體開發的工作流。

2. 多模態與語音（Audio）的崛起

雖然目前大家聚焦於文字（Coding），但 Sherwin 認為語音（Audio）是被嚴重低估的領域。隨著原生多模態模型（Native Multimodal Models）的進步，語音互動的延遲與品質將大幅改善。

考慮到世界上大量的商業活動、服務與營運都是透過「對話」進行的，高品質的語音 AI 將解鎖巨大的商業價值，特別是在企業服務領域。

3. 商業流程自動化（Business Process Automation）

這是一個相對「無聊」但在矽谷以外卻擁有巨大潛力的市場。軟體工程是開放式的知識工作，但世界上絕大多數的工作其實是**「高重複性、標準作業程序（SOP）」**的商業流程（如水電費處理、保險理賠、行政流程）。

Sherwin 非常看好利用 AI Agent 來自動化這些高確定性的流程。這不僅能提升效率，更能將人類從繁瑣的行政工作中解放出來。

——————————————————————————–

六、 OpenAI 的平台策略：做航空母艦而非掠食者

對於開發者最擔心的問題：「OpenAI 會不會推出跟我一樣的產品，把我消滅？」Sherwin 給出了定心丸。

1. 生態系優先

OpenAI 將自己視為平台公司，目標是建立生態系。Sherwin 強調，OpenAI 的使命是造福全人類，而單靠 OpenAI 一家公司無法觸及世界的每個角落（例如為特定小眾需求開發工具）。因此，他們需要廣大的開發者來填補這些空缺。

2. 開發工具堆疊

OpenAI 正在構建不同層次的抽象化工具，幫助開發者構建 Agent：

• Responses API: 最底層的接口，適合需要完全控制權的開發者，用於構建長時間運行的 Agent。

• Agents SDK: 中層框架，幫助開發者管理 Agent 的循環、子任務委派和護欄（Guardrails）。

• Agent Kit & Widgets: 最上層的 UI 組件，讓開發者能快速打造美觀的 Agent 介面。

Sherwin 的建議是：市場大到難以想像，不要過度擔心 OpenAI 的動作。那些失敗的新創通常是因為產品沒人要用，而不是被大公司壓垮。只要打造出用戶喜愛的產品，這片藍海容得下所有人。

——————————————————————————–

結語：不要視為理所當然

在訪談的最後，Sherwin 感性地表示，我們正處於科技業最令人興奮的時期。從 2014 年進入職場以來，他從未見過如此充滿活力的時刻。未來 2-3 年將是 AI 創新最密集的階段。

他的最終建議很簡單：「參與其中（Engage with it）」。無論你是不是軟體工程師，都應該去下載 Codex、試用 ChatGPT 的進階功能、將 AI 連接到你的工作流中。不要只是旁觀，因為這波浪潮將重新定義工作的本質。

在這個 AI 的黃金時代，正如 Sherwin 所言，我們都是手握強大咒語的現代巫師。關鍵在於，你是否準備好拿起魔杖，去創造屬於你的價值？

(本文內容整理自 Lenny’s Podcast 訪談：OpenAI’s head of platform engineering on the next 12-24 months of AI | Sherwin Wu)

---

• 🎓 [精選 AI 課程] 這裏查詢更多 https://learn.build-school.com/zh-hant/filter-course-page/
• 【各行業領域知識工作者】商業應用及各領域工作情境 : ChatGPT / Gemini /M365 Copilot 產業應用情境與案例
• 【技術/工程人員】AI 驅動開發:從構思到上線 – GitHub Copilot 企業開發實戰
• 【AI 應用及AI Agent】Azure AI Foundry / OpenAI / Gemini / Claude 等模型與雲端平台
• 【認證課程】微軟 Azure AI 工程師(AZ102)、Azure 系統管理員(AZ104)、系統架構師(AZ300)、資安、GitHub 開發相關認證
• 完整微軟認證學習地圖：https://learn.build-school.com/zh-hant/microsoft-cert-learning-roadmap/

這篇文章深入探討了 AI 應用層的商業模式變革、護城河構建以及未來的投資邏輯。來源: 根據 Andreessen Horowitz (a16z) 合夥人 Alex Rampell 的觀點以及影片內容所整理的深度專業部落格文章。

由 AI 驅動的第五次軟體浪潮，指出我們正處於人工智慧應用發展的黃金時代。說明了 AI 原生公司 如何透過專有數據壁壘與端到端工作流，在法律、醫療與金融等領域建立強大的競爭護城河。專家強調，目前的趨勢已從單純的軟體工具轉向直接替代或增強勞動力，這將徹底改變企業的定價邏輯與獲利模式。此外，文中分析了圍牆花園策略的重要性，強調擁有大模型無法獲取的獨家數據是新創企業生存的關鍵。最終，這波變革不僅重塑了軟體產業的典範，更為消費者與企業端帶來了前所未有的市場擴張與生產力提升。

• 軟體業第五次浪潮與前四次有何不同？
• AI如何從「節省成本」轉向「創造收入」？
• 為何專有數據是AI時代最重要的商業護城河？

——————————————————————————–

前言：我們正處於「美好的舊時光」

如果你現在能擁有一台時光機，回到 15 或 20 年前，買入 Salesforce、Shopify、ServiceNow 這些公司的股票，你將擁有一個回報率驚人的投資組合。那是雲端計算（Cloud Computing）剛剛開始吞噬傳統本地部署軟體（On-Premise）的時代。

今天，我們正站在一個類似、甚至更為宏大的歷史節點上。

a16z 合夥人 Alex Rampell 將其稱為軟體行業的「第五次浪潮」。回顧 1977 年至 2023 年的納斯達克指數，我們可以清晰地看到前四次週期：PC 時代、網際網路時代、雲端計算時代，以及移動互聯網時代。每一次浪潮都誕生了新的基礎設施巨頭和應用巨頭。而現在，隨著 ChatGPT 等生成式 AI 的普及，我們正式進入了 AI 應用時代。

這不是未來的預測，而是正在發生的現實。這篇文章將深入剖析這場變革的核心邏輯，探討企業如何在這場範式轉移中建立真正的護城河，以及為什麼「替代勞動力」而非「軟體競爭」將成為最大的商業機會。

——————————————————————————–

一、 範式轉移：從 SaaS 到 AI Native 的「綠地機會」

AI 時代的到來並非憑空出現，它是建立在智慧型手機普及和雲端計算成熟的基礎之上的。這使得 AI 的採用速度遠超以往任何一次技術浪潮。然而，在這場競賽中，傳統軟體巨頭與新興 AI 原生（AI Native）公司之間的博弈顯得尤為精彩。

1. 為什麼傳統軟體難以轉身？

就像當年的本地部署軟體公司難以轉型為雲端公司一樣，現在的傳統 SaaS 公司在轉向 AI Native 時也面臨巨大挑戰。這不僅僅是技術問題，更是商業模式的衝突。傳統軟體習慣了一次性授權或基於「席位（Seat）」的訂閱模式，而 AI 的商業邏輯可能完全不同。

Alex Rampell 提出了一個「賓果卡（Bingo Card）」的概念：企業資源規劃（ERP）、客戶關係管理（CRM）、客戶支援、機器人流程自動化（RPA）等每一個傳統軟體類別，都存在被 AI 原生公司重新定義的機會。

2. 綠地（Greenfield）策略：不爭搶，只創造

對於新創公司而言，直接從 Salesforce 或 Workday 手中搶奪現有客戶（Brownfield 機會）是極其困難的。因為這些大公司擁有極強的「鎖定效應」——最好的公司擁有的是「人質」而非僅僅是客戶。一旦企業的記錄系統（System of Record）建立，遷移成本極高。

因此，AI 原生公司的機會在於「綠地」。

以 Mercury Bank 為例，它並沒有試圖從矽谷銀行手中搶走現有客戶，而是專注於服務那些剛剛成立的新創公司。同樣地，AI 原生 ERP 公司（如 Rippling 投資的相關企業）鎖定的是那些成長到 50 人規模、剛剛需要從 QuickBooks 遷移到更複雜系統的企業。在這個「轉折點」上，客戶會自然地選擇市場上最先進的產品，而不會被舊系統束縛。

——————————————————————————–

二、 商業模式的躍遷：軟體開始替代勞動力（Service-as-a-Software）

這是本輪 AI 浪潮中最令人興奮的變革：軟體的市場邊界正在被無限擴大，因為它不再只是與其他軟體競爭，而是在與人力成本競爭。

1. 突破價格天花板

傳統軟體市場受限於企業的 IT 預算，通常每個席位每年幾百到幾千美元。但勞動力市場的成本是每年幾萬甚至幾十萬美元。

讓我們看一個具體的例子：一家眼科診所招聘前台接待，年薪 4.7 萬美元。如果有一款軟體能完成其中 50% 的工作，診所絕不會只願意付 500 美元（傳統軟體價格），但也不會付 4.7 萬美元。他們可能願意支付 2 萬美元。這就創造了一個介於傳統軟體和全職人力之間的全薪定價區間，一個以前根本不存在的巨大市場。

2. 案例分析：EvenUp（法律科技的降維打擊）

a16z 投資的 EvenUp 是這一趨勢的完美註腳。它服務於人身傷害案件的原告律師。這是一個特殊的市場：律師按勝訴金額抽成，而非按小時計費。

• 痛點： 處理醫療記錄、起草索賠信需要大量高技能人力。

• AI 價值： EvenUp 不僅僅是節省時間，它能通過 AI 分析大數據，告訴律師哪個案子值 5 萬美元，哪個值 500 萬美元，並自動生成索賠文件。

• 收入增長而非成本節約： 如果 AI 能讓原告律師的效率提升 5 倍，他們的收入就能增長 5 倍。這種「增強人類」而非單純「替代人類」的模式，使得軟體可以直接分享業務增長的紅利。

• 擴大市場： 以前律師只接預期收益 5 萬美元以上的案子，現在因為 AI 降低了處理成本，5000 美元的案子也能接了，這解決了法律服務供需失衡的問題。

3. 案例分析：Sloane（解決高流失率的髒活累活）

Sloane 專注於汽車貸款催收和保險理賠。這是一份沒人喜歡的工作：員工整天被罵，流失率高達 40%-70%。

• AI 的優勢： AI 不會累，不會被罵哭，而且能精確記住全美 50 個州的每一條法律法規（這對合規至關重要）。

• 結果： 催收率提高了 50%。

• 價值主張： Sloane 賣的不是「催收軟體」，而是「更高的回款率」和「無法律風險」。這讓企業無法拒絕。

——————————————————————————–

三、 護城河的構建：圍牆花園與專有數據

在生成式 AI 時代，構建軟體變得異常容易。利用 Cursor 或其他 AI 輔助編程工具，競爭對手可以迅速複製你的功能。那麼，企業如何構建持久的護城河？

答案在於：專有數據（Proprietary Data）。

Alex Rampell 用了一個生動的「農場與餐廳」的比喻：OpenAI 就像種菜的農場，如果你只是買它的菜（API）來做菜（應用），那麼當農場決定自己開餐廳時，你就死定了。但如果你擁有獨家的食材（數據），也就是 OpenAI 訓練數據中沒有的東西，你就擁有了護城河。

1. 什麼是真正的專有數據？

這不僅僅是公開數據，而是經過數位化、整理、或通過獨家授權獲得的「高價值資訊」。

• Open Evidence（醫療）： 雖然 ChatGPT 閱讀過互聯網上的醫療資訊，但 Open Evidence 獨家授權了《新英格蘭醫學雜誌》等頂尖期刊。醫生需要的是基於權威文獻的「循證醫療」，而不是 GPT 可能產生的幻覺。這就是「獨家食材」。

• vLex（法律）： 這家公司收購並數位化了西班牙所有的法律記錄。如果律師需要一份基於西班牙判例的備忘錄，通用大模型做不到，只有 vLex 能做到。這讓他們從「按月收費」轉向了「提供高價值成品」的高溢價模式。

• Acel（採購）： 擁有成千上萬份舊合同數據，能告訴你在談判中該在哪些條款上施壓。這種隱性知識是大模型無法從公開網絡上獲取的。

2. 數據的飛輪效應

以 EvenUp 為例，它處理的每一個案件都在生成新的、非公開的數據（比如某類案件的平均賠償額）。這些數據反過來優化了模型，使其估值更準確，從而吸引更多律師使用。這是一個大模型公司無法觸及的數據閉環。

——————————————————————————–

四、 戰略格局：模型會吞噬應用嗎？

這是一個讓所有創業者焦慮的問題：OpenAI 或 Google 會不會親自下場做應用，把大家都滅了？

a16z 的觀點是：應用層不會被模型層吞噬，聚合器（Aggregator）將成為贏家。

1. 聚合器的價值

就像買機票時，我們更喜歡用 Expedia 或 Skyscanner 而不是單獨去每一家航空公司網站搜索一樣，用戶需要一個能訪問所有模型的統一介面。 不同的模型有不同的專長（有的擅長寫程式碼，有的擅長創意寫作）。在開發工具或創意工具中，用戶希望能在同一個工作流中調用最佳的模型。這種「模型聚合」本身就創造了巨大的價值，而單一模型廠商（如 Google 或 OpenAI）受限於自身利益，很難做到這一點。

2. 企業與消費者的並行機會

在消費者（Consumer）AI 領域，我們看到了同樣的趨勢：

• AI 原生工具的崛起： 年輕的設計師開始首選 Kittl 或 Canva 這樣的 AI 原生工具，而不是 Photoshop。就像雲端時代的新用戶首選 Google Docs 一樣。

• 品類創造： ElevenLabs 創造了「語音 AI」這個全新的消費級品類，這在五年前根本不存在。

• 數據驅動的垂直整合： Slingshot 透過 AI 抄寫員收集治療師的對話數據（在隱私保護下），訓練出專門的心理治療模型，進而推出面向消費者的 AI 治療師應用。這種從 B 端數據積累反哺 C 端產品的路徑，是通用模型無法複製的。

——————————————————————————–

五、 結論：軟體主導的未來

我們正在經歷的這場變革，速度之快前所未有。在傳統軟體時代，一家公司從主導到被淘汰可能需要五年，但在 AI 時代，如果沒有真正的護城河，被顛覆可能只在朝夕之間。

未來的贏家將具備以下特徵：

1. AI 原生（AI Native）： 從第一天起就基於 AI 架構設計，而不是在舊系統上打補丁。

2. 擁有專有數據（Proprietary Data）： 構建「圍牆花園」，擁有大模型無法獲取的獨家資訊。

3. 重新定義工作流（End-to-End Workflow）： 不只是提供工具，而是接管整個工作流程，直接交付結果（Outcome）。

4. 按價值定價（Value-Based Pricing）： 擺脫席位費的束縛，根據創造的經濟價值或節省的勞動力成本收費。

正如 Alex Rampell 所言，很多時候我們並未意識到自己正生活在歷史的關鍵時刻，直到時光流逝。AI 驅動的產品週期不再是中心化的，而是由軟體主導的，這賦予了技術人員前所未有的創造力。

對於投資者和創業者來說，這不是關於「AI 是否會取代人類」的恐慌，而是關於如何利用 AI 擴展服務邊界、解決供需失衡、並創造全新市場類別的機遇。

AI 應用的黃金時代，才剛剛開始。

——————————————————————————–

本文取材自 a16z YouTube 影片 – https://youtu.be/3XVDtPU8xKE

如果你過去用過「會寫程式的 AI」，大概都遇過同一種痛：小段程式碼很神，但一進到真實專案（要跑測試、要改設定、要看 log、要部署、要修回歸），就開始卡在流程與工具鏈。OpenAI 在 2026/02/05 推出 GPT‑5.3‑Codex，傳遞的訊息很直接：Codex 不再只做「寫/審程式碼」，而是往「可以在電腦上完成幾乎所有開發者與專業人士日常工作」的方向前進。

一、先用一句話理解：它想成為你的「代理型同事」

GPT‑5.3‑Codex 被描述為把 GPT‑5.2‑Codex 的程式設計能力，加上 GPT‑5.2 的推理與專業知識能力，再把速度提升約 25%，目標是處理研究、工具操作、複雜執行流程等長時間任務。你可以一邊讓它做事、一邊插話調整方向，而不太容易把前面討論的脈絡弄丟。

把它想成一位「你可以隨時打斷、請它回報進度、讓它拆子任務」的同事，會比把它當成聊天機器更貼近它的設計目標。尤其當你要做的事不是單一檔案的修改，而是跨 repo、跨環境、跨多步驟（例如：修 bug→補測試→跑 CI→調整設定→打包→部署→驗證），代理能不能穩定地把流程跑完才是重點。

二、基準測試不是炫技：它們對應到你每天在做的苦工

原文點名 SWE‑Bench Pro、Terminal‑Bench 2.0、OSWorld 與 GDPval。你不需要死背每個名字，但可以把它們對應到「你每天在做什麼」。

1) SWE‑Bench Pro：把你丟進真實專案，看你能不能修到 test 過

SWE‑Bench Pro 以真實世界軟體工程為基礎、評估嚴謹，涵蓋四種程式語言（不像只測 Python 的 SWE‑bench Verified）。這類測試更像：給你一個既有 repo、一堆上下文，請你修 bug 或完成變更，並讓驗收條件成立。

你會感受到的提升場景：

• 修回歸：某個 PR 合併後出現邊界 bug，得找根因、補測試
• 升級依賴：框架大版本升級導致多處破壞性變更
• 跨語言協作：後端/前端/腳本混在一起的專案維護

2) Terminal‑Bench 2.0：終端機能力才是「代理」能不能落地的關鍵

Terminal‑Bench 2.0 用來評估編碼代理的終端操作能力。講白一點：會不會用 terminal 跑指令、看輸出、改設定、重試、逐步逼近成功。這個能力一旦上來，你就能把「我貼給你錯誤訊息，你回我一段建議」升級成「你自己跑、自己看、自己修、自己再跑一次」。

原文也提到它在達成成果時使用的 Token 更少，代表在長任務的成本與可持續性上更有利（同樣預算可跑更多輪迭代）。

3) OSWorld：它開始能「看著桌面」做事

OSWorld 是讓智慧體在視覺化桌面環境中完成生產力任務的基準。工程師不一定每天都在桌面上拖拉點按，但你一定做過類似事情：打開工具、找資料、填表、整理輸出、把結果貼回系統。當代理能處理這類「電腦操作」能力，許多零碎但耗時的工作就有機會被半自動化。

4) GDPval：不只寫程式，還要做簡報、試算表與各種交付物

GDPval 用來衡量跨 44 種職業的明確知識工作任務表現（例如建立簡報、試算表等成品）。對工程團隊來說，這意味著你可以把「交付物」一起交給代理：PRD 初稿、風險清單、測試計畫、上線公告、指標報表草稿、RCA 模板等。

5) 直接看數字（同為 xhigh 推理強度）

原文給了一個清楚的對照表，這裡用工程師常用的「重點列點」整理：

• SWE‑Bench Pro（公開）：GPT‑5.3‑Codex 56.8%（略高於 GPT‑5.2‑Codex 56.4%、GPT‑5.2 55.6%）
• Terminal‑Bench 2.0：77.3%（相較 64.0%、62.2% 是顯著提升）
• OSWorld‑Verified：64.7%（相較 38.2%、37.9% 大幅提升）
• GDPval（勝出或平局）：70.9%（與 GPT‑5.2‑Codex 持平）
• Capture‑the‑Flag：77.6%（相較 67.4%、67.7% 提升）
• SWE‑lancer IC Diamond：81.4%（相較 76.0%、74.6% 提升）

你可以這樣解讀：程式能力是穩定進步，但更「有感」的提升會出現在終端操作與桌面任務這種代理必備能力，因為那直接影響你能不能把任務整段丟給它跑。

三、網頁開發示例：為什麼它看起來更像「可直接上線的起點」

原文展示它能在數日內從零建立複雜遊戲與應用，並且能靠通用跟進提示詞（像「修正錯誤」「改善遊戲」）反覆迭代，甚至使用數百萬 Token 自主打磨內容。你不一定要拿來做遊戲，但你一定做過這些事：

• 做一個 landing page、加上收信表單與 FAQ
• 做個內部工具介面、串 API、加權限與日誌
• 做個 demo 讓 PM、設計、業務可以快速對齊方向

原文也提到一個很貼近產品工作的細節：在同樣「登陸頁」需求下，GPT‑5.3‑Codex 會自動把年費換算為「折扣後月費」的呈現方式，讓優惠更直覺；也會做出更完整的推薦輪播，讓初版看起來更接近可上線狀態。這種「預設更懂產品語境」的差異，會讓你在第一輪就少很多來回。

工程師實作建議：把需求寫成「可驗收」的清單，而不是只有風格描述。舉例：

• 必須有 E2E 測試覆蓋主要路徑（登入、付款、設定等）
• 可及性基本盤（鍵盤可操作、focus state、語意化結構）
• 效能預算（例如首屏資源大小、圖片壓縮策略）
• 事件追蹤規格（曝光、點擊、轉換）

四、互動方式的改變：更像 pair programming，但對象是「會跑流程的代理」

OpenAI 強調互動協作：模型會更頻繁提供更新，讓你不用等到最後才發現走偏；你可以在過程中提問、討論做法、調整方向。這對工程師很重要，因為代理做長任務時最怕兩件事：

• 悶著頭跑太久：最後結果不符合你要的，回頭全砍重來。
• 在關鍵點做了高風險操作：例如改了權限、動了資料、部署到 production。

比較務實的做法是：把「你一定要看的點」插到流程裡。像是：開始前先確認任務拆解、動到資料前先列出 migration 計畫、部署前先列出回滾方案、上線後先看監控儀表板與告警門檻。

五、OpenAI 內部怎麼用：把代理拿來除錯訓練流程、追問題、做資料分析

原文提到 GPT‑5.3‑Codex 是第一個在打造自身過程中發揮關鍵作用的模型：早期版本被用來除錯訓練流程、管理部署、診斷測試與評估結果；工程面也拿來找上下文渲染錯誤、追快取命中率偏低原因、甚至在發布期間協助動態擴展 GPU 叢集以扛住流量高峰。

如果你想在公司內複製這種收益，建議選一個你們真的痛、而且每週都在發生的工作當切入點，例如：

• 把「CI 失敗分類 + 建議修法」半自動化（先從建議開始，不要直接自動 merge）
• 把「事件後 RCA 草稿」自動產生（log/指標/時間線整理）
• 把「版本升級影響範圍掃描」自動化（找 API 變更、deprecated 用法）

六、資安段落務必讀：能力變強，同時也更需要「可信存取」與監控

原文指出，GPT‑5.3‑Codex 在應變整備框架下被歸類為可用於資安任務的「高能力」模型，也提到它是第一個直接受訓用來識別軟體漏洞的模型。即使目前沒有明確證據顯示能端到端自動化網路攻擊，仍部署了更全面的防護機制（安全訓練、自動化監控、進階功能的可信存取、結合威脅情報的執行管道等）。

工程師角度的重點是：你在公司內把代理接上工具鏈（repo、CI、雲端、資料庫）之後，它就具備「實際影響系統」的能力。此時你應該把它當成新成員 onboarding 一樣，給它最小權限、把操作都記錄下來、在高風險動作前要確認、並且要能回滾。

最小可行的安全做法（建議從第一天就做）：

• dev/staging/prod 權限分離，prod 預設只讀或禁止寫入
• 金鑰與機密資料不直接暴露給代理（用短時效憑證、代管存取）
• 所有外部寫入（推 PR、發版、改設定、建立資源）都要有審核點
• 保留完整操作記錄，包含它「為什麼這樣做」的理由與替代方案

七、我該怎麼開始試？一個工程團隊可落地的試點清單

原文提到 GPT‑5.3‑Codex 可透過付費 ChatGPT 方案使用，支援 Codex 平台（應用程式、CLI、IDE 擴充功能、網頁版），並正準備在確保安全前提下開放 API。這意味著你可以先用「非侵入式」方式試點：先不接 production，不給高權限，先從輸出建議與草稿開始。

兩週試點建議（工程師版）：

1. 選一條穩定痛點流程：例如 CI 失敗診斷、回歸修復、依賴升級。
2. 定義成功指標：修復時間縮短、來回澄清次數減少、PR throughput 提升。
3. 把需求寫成模板：輸入（log/錯誤/限制）→輸出（修法、測試、風險、回滾）。
4. 建立審核點：只允許它產生 PR 草稿，合併必須人工批准。
5. 回收案例：把成功與失敗的提示詞整理成團隊內部手冊。

未來趨勢

• 代理會從「寫 code」走向「跑完整流程」：包含工具操作、文件產出、測試與部署，逐步變成可重複使用的工作流。
• 資安與合規會跟著代理一起產品化：可信存取、審計、監控、最小權限將成為標配，不再是選配。

給專業人士的實務建議

• 先把它當成「很會做事的實習生」：讓它做草稿與建議、你做審核與決策；等流程穩了再逐步給更多權限與自動化範圍。
• 把品質門檻寫出來：測試、效能、可及性、回滾、風險清單都要在同一份輸出裡，否則你只是把工作換個地方做。

參考資料

• OpenAI Blog – https://openai.com/zh-Hant/index/introducing-gpt-5-3-codex/
• GPT‑5.3‑Codex 系統說明卡（2026/02/05）

如果你用過 coding agent，應該遇過這種瞬間：它看起來很順，下一秒卻開始改到你不想動的檔案；或是你本來想手動核准每一步，但任務一長就覺得「一直按同意」根本不現實。於是問題變成：我們到底讓 AI 自己跑多久？怎麼盯？盯到什麼程度才算安全？

本文把一份針對 Claude Code 與公開 API 的大規模互動觀測研究，用更貼近工程團隊日常的角度重寫：從「怎麼定義 Agent」、到「怎麼量測自主性」、再到「風險在哪裡開始冒出來」。你可以把它當作建立內部治理指標與監控儀表板的參考模板。

先講結論：多數 Agent 行為仍偏低風險、可逆；但自主性正在上升，且資安、金融、醫療等高風險領域已出現早期使用。想要安全擴大自主性，靠「每步都人工核准」不夠，得靠部署後監控與更好的介入機制。

先把話講清楚：什麼算 Agent？不是聊天機器人就算

工程師最怕概念空轉，所以直接用可落地的定義：Agent = 會用工具、能採取行動的 AI 系統。工具可能是：

• 跑程式碼、改檔案、下指令
• 呼叫外部 API（查資料、建票、觸發工作流）
• 發訊息或協調其他 Agent

為什麼這樣定義重要？因為你只要能把「工具呼叫」當成基本事件，就能做監控、做審計、做風險分級，不需要先把 Agent 的內部架構講得像論文一樣完整。

兩種觀測視角：API 看廣度、Claude Code 看深度

要研究「大家在真實世界怎麼用 Agent」，有兩個常見痛點：

• 供應商未必看得到客戶完整系統（你用什麼 orchestrator、外面還接了什麼人審流程）。
• 就算看得到流量，也不一定能把零散請求串成同一個 Session。

因此研究採用兩個互補資料源：

• 公開 API（廣）：可以看到很多不同客戶、很多領域，但多半只能以單次工具呼叫分析，無法完整重建長任務的「連續行為」。
• Claude Code（深）：因為是第一方產品，能把一次任務從頭到尾串起來，看它連續跑多久、何時停、停的原因是人類打斷還是它自己問問題。

而且研究使用隱私保護的分析方法，只做彙總與分類，不直接用人工逐筆看內容。

自主性怎麼量？用一個直覺但有用的指標：它連續工作多久才停

在 Claude Code 這種互動式 coding agent 裡，有個很直覺的量法：從它開始動手到它停下來（完成、被打斷、或自己問問題）的時間，當成每一回合的「自主工作時長」。它不是完美指標，因為模型速度、並行子代理、任務難度都會影響，但對理解真實使用很有幫助。

觀測結果有兩層：

• 多數回合很短：中位數大約 45 秒，幾個月內大致在 40–55 秒浮動。
• 長尾在變長：最長那批使用案例，在三個月內，停止前的自主工作時長幾乎翻倍（以 99.9 百分位衡量，從不到 25 分鐘到超過 45 分鐘）。

如果你是帶團隊導入的人，這很像一個訊號：當大家越用越熟、越敢把任務丟大，Agent 就會被允許跑更久。更妙的是，這個變長趨勢跨模型更新很平滑，暗示「信任、工作流、產品設計」的影響，可能不亞於模型本身能力提升。

資深使用者的監督策略很「現實」：少按核准、多用中斷修正

很多治理制度直覺會走向「每一步都要人核准」，但實際使用不一定這樣。觀測顯示：

• 使用者越資深，全自動核准（auto-approve）越常開：新手大約 20% 的 Session 使用全自動，資深可到 40% 以上。
• 同時，使用者越資深，中斷（interrupt）也越常發生：新手約 5% 的回合中斷，資深約 9%。

這其實超像工程師的日常：一開始不放心，想逐步看；但任務變長後，你會改成讓它跑，自己盯進度、看到不對就喊停、補上下文、修正方向。也就是從「事前核准」轉成「過程監看 + 必要時介入」。

對團隊流程的啟示：不要把「按不按核准」當成唯一安全指標，反而要問：你是否提供足夠可觀測性（它現在做什麼、要做什麼、為什麼）、以及足夠低成本的介入方式（中斷、回滾、鎖權限、改目標）。

不只是人類在盯：Agent 自己停下來問問題，其實也是一種安全機制

另一個很實用的觀測是：在複雜任務中，Claude Code 會更常停下來問澄清問題，而且頻率比人類中斷更高，最複雜任務甚至是人類中斷的兩倍以上。

把常見原因翻成工程師語言，大概是：

• 它自己停下來：要你選 A/B 方案、要你提供測試結果或診斷資訊、需求不清楚要你補、缺 token/權限、或它覺得該先確認再動手。
• 你把它喊停：你發現上下文錯了、你想改需求、它卡住/太慢、或你已經拿到足夠提示想自己做下一步（例如跑測試、部署、commit）。

落地建議：把「會停下來問對問題」視為 Agent 的核心能力之一。你可以要求它在高風險工具前先輸出計畫與假設，並把不確定點變成明確的確認清單。

風險在哪裡？大多低風險可逆，但右上角（高風險/高自主）不是空的

公開 API 的部分，研究用模型去估每次工具呼叫的兩個分數（1–10）：風險與自主性，並把相似行為聚成群集。整體看起來「還算安心」：大多數行為偏低風險，且很多動作可逆；Agent 行為目前高度集中在軟體工程（約接近一半）。

但同時也看到一些值得工程主管注意的訊號：

• 在醫療、金融、資安等領域，開始出現使用案例。
• 高風險或高自主的群集雖少，但確實存在；而且一次失誤就可能成本很高。

研究也提供幾個「防護現況」的估計值，方便你對照自家系統：

• 約 80% 的工具呼叫看起來至少有某種 safeguard（權限限制或核准要求）。
• 約 73% 看起來有人類介入（研究同時提醒可能偏高估，可視為上限）。
• 約 0.8% 看起來是不可逆動作（例如對外寄信）。

另外一個很務實的提醒：供應商未必知道「看起來的行為」是否真的落地執行（例如下單交易可能只是測試），也可能是紅隊演練。這代表風險分數更適合當趨勢雷達，用來看右上角是否變密，而不是用來一刀切判定合規。

把研究翻成你可以做的事：三個「不用等政策」就能開始的工程改造

1) 先把不可逆行為抓出來，建立硬門檻

比起要求所有步驟都人工核准，更有效的做法是：對不可逆或高影響行為設門檻，例如：

• 對外發送（寄信/訊息）、下單交易、刪除資料、權限提升、寫入正式環境
• 存取敏感資料（醫療、財務、身分資料）

這些行為可以採用更嚴格策略：強制二次確認、人審、或僅允許在 sandbox 執行。

2) 把「中斷」做成一等公民，而不是當成失敗

資深使用者更常中斷，代表中斷是一種正常的監督方式。建議你在產品或內部工具上確保：

• 一鍵停止、暫停、回滾
• 停止當下能保留狀態與上下文（方便續跑或改方向）
• 中斷原因可被記錄（方便事後改善 prompt、工具或權限策略）

3) 投資部署後監控：你需要的是「看得見」而不是「按得多」

要讓團隊敢放手，關鍵是可觀測性。最低限度你應該能回答：

• 它用哪些工具做了哪些事？耗時多久？結果如何？
• 哪些動作是高風險/不可逆？誰授權？是否有回滾？
• 它停下來問了哪些澄清問題？人類中斷發生在哪些任務型態？

未來趨勢

• 自主性會繼續上升，而且不是只靠模型變強：更可能是使用者信任、工作流成熟、產品互動改善一起推動長尾變長。
• 高風險領域會從「少量嘗試」走向「流程化」：當 Agent 變得更容易接入各種業務工具，右上象限（高自主/高風險）會更常見，監控與審計的重要性會快速上升。

給專業人士的實務建議

• 把「風險分級 + 不可逆門檻」寫進工程規範：例如定義哪些工具必須先計畫再執行、哪些必須人審、哪些只能在 sandbox。
• 用「interrupt/clarify/rollback」當作流程體感指標：這些指標往往比成功率更能早期反映：上下文是否不足、工具是否不穩、權限是否設太寬或太窄。

參考資料

• Measuring AI agent autonomy in practice（Anthropic，2026-02-18）

如果你最近開始做「工作型」agent（不是聊天而已，而是要跑腳本、處理資料、寫檔案、產出報告、還要能多輪續跑），大概很快就會遇到三種痛：提示詞越寫越長、環境跑起來不一致、對話一變長 agent 就開始忘東忘西。

解法其實不是再多塞幾段 prompt，而是把能力拆成三塊：Skills 負責「怎麼做」、Shell 負責「在哪裡做」、Compaction 負責「怎麼讓它一路做到完」。下面整理一些比較不直覺、但在長流程特別有用的技巧。

先想清楚：你的 agent 不是在聊天，是在跑一個工作流程

Skills：把流程寫成「可重用的作業手冊」

Skill 可以想像成你幫 agent 準備的一份資料夾：裡面有 SKILL.md（像 README + SOP）、還可能放模板、範例輸出、檢查清單。重點是它能版本化、可重用，而且只有在需要時才載入。

• 你不必把所有規則塞進 system prompt。
• 模板與範例放在 skill 裡，不用時不花 token，用到時直接拉品質。
• 流程更新就改 skill 版本，少一點「某段 prompt 在哪個服務裡」的追查地獄。

Hosted Shell：給 agent 一個能安裝、能執行、能寫檔的終端

很多知識工作最後都需要「落地」：例如跑一段 Python 清理資料、輸出 CSV，再寫一份報告。Shell 工具讓 agent 真的進到終端環境做事。你可以：

• 用 Hosted Shell：平台代管容器，可重現、隔離、適合上線。
• 用 Local Shell：你自己執行 shell 呼叫，超適合開發期除錯或接內網工具。

我通常把它當成「把推理和執行切開」的開關：模型負責規劃與檢查，shell 負責跑程式、產檔、存中間結果。

Compaction(壓縮)：長流程不崩壞的秘密武器

做長流程最討厭的一件事：跑到一半上下文爆掉，agent 開始重問問題、重抓資料、甚至忘記剛輸出的檔案在哪。Server-side compaction 的方向是：上下文長到某個程度就自動壓縮，把「重要狀態」留下來，讓任務能繼續跑。

你可以把它視為長流程的基本配備，而不是「快爆了才手動整理對話」。如果你有里程碑節點，也能用獨立的 compact endpoint 在 checkpoint 後做一次更可控的壓縮。

三個一起用的直覺：把輸出變成 artifacts，讓流程可續跑

如果你只用 prompt，最後常變成「它說它做了」，但你沒有任何檔案能驗證。三件事一起上，整個工作流會變得更工程化：

• Skills：把流程與品質標準寫死（怎麼做）。
• Shell：把結果寫到檔案（做到什麼）。
• Compaction：讓它在多輪中不失憶（怎麼續跑）。

技巧 1：Skill 描述要像路由規則，不要像介紹文

我見過最常踩的坑：skill description 寫得很漂亮，但模型不知道什麼時候該用它，結果要用時不觸發、不該用時亂觸發。把 description 當成路由邏輯會更有效，至少回答三件事：

• Use when：什麼輸入/情境該用？需要哪些工具？
• Don’t use when：哪些狀況不要用？改用什麼？
• Outputs：會產出哪些檔案、放哪裡、如何驗證成功？

描述越具體越好，例如直接寫「輸出 /mnt/data/report.md，且包含結論、方法、風險與建議四段」。

技巧 2：加負向範例與邊界案例，路由會突然變穩

有個反直覺現象：你把 skills 開起來後，觸發率可能先下降，因為模型在「看起來都差不多」的技能之間猶豫。補救方式很土但很有效：寫負向範例。

• 「不要在使用者只是問概念時呼叫本 skill」
• 「不要在沒有資料來源或沒有權限時呼叫本 skill，改先回覆需要哪些輸入」
• 「如果偵測到資料欄位缺失，先輸出缺失欄位清單並停止寫最終報告」

像 Glean 這類早期使用者也提過：加入負向範例與邊界案例後，路由命中能拉回來。工程上你可以把這件事當成一種「規格測試」：技能不是寫完就完，要靠迭代把邊界補齊。

技巧 3：模板與範例別塞 system prompt，塞進 Skill 才划算

很多人一開始為了讓輸出一致，會在 system prompt 放一大段模板，結果：

• token 變大 → 成本/延遲上升
• 不相關問題也被模板干擾
• 模板要改時很難找、很難控版本

把模板、範例輸出、檢查清單放進 skill 幾乎是「白拿」的優化：不用時不載入，用到時直接有標準格式。特別適合：週報、稽核摘要、事故復盤、支援單 triage、資料清理後的分析稿。

技巧 4：長流程要先設計「續跑」：容器重用 + previous_response_id + 預設 compaction

如果你的任務分成多步驟（安裝→抓資料→清理→分析→寫報告），最怕每一步都像重新開始。實作上我會做三件事：

• 重用同一個容器：依賴不用重裝，中間檔案留著，快取也留著。
• 用 previous_response_id 延續：把它當作「同一條 thread 繼續跑」，讓模型保持任務狀態。
• compaction 當預設：不要等快爆上下文才救火，會更常失去關鍵狀態。

你會明顯感覺到：agent 不再一直重問「資料在哪」「我該從哪一步開始」，而是像一個真的在做專案的人。

技巧 5：想要更「可預期」就明講：請使用某個 Skill

預設狀況下模型會自己決定要不要用 skill。這很方便，但在生產任務（尤其是有合約輸出的）我會更偏向明確指定：

「請使用 <skill name> skill 完成本次任務。」

好處是把路由不確定性降到最低，你也更好寫測試與監控。

技巧 6：Skills + 網路存取很危險，先用最小權限把它關起來

如果 skill 裡有很強的程序（例如會自動抓資料、整理後回寫系統），再加上開放網路，就可能變成資料外洩的高風險通道。建議的安全姿勢：

• 網路預設最小 allowlist：只允許必要網域，而且每個請求的 allowlist 要更小。
• 假設外部內容不可信：外部資料可能夾帶提示注入或惡意內容，skill 內要有清理與驗證步驟。
• 消費者流程更要保守：避免在缺少確認機制的情境下，讓強程序 + 開網路直接執行敏感動作。

技巧 7：把 /mnt/data 當作交付邊界，你會更好做產品化

Hosted Shell 的輸出，建議統一寫到 /mnt/data，把它當成標準交付區：

• 工具寫檔（報告、清理後資料、程式碼）。
• 模型基於檔案內容做檢查與總結。
• 你的服務端把 artifacts 拉回去展示/下載/存檔/做 diff。

這會讓整個系統更像「可驗收的 pipeline」，而不是「一段不可重現的對話」。

技巧 8：allowlist 有兩層（組織層 + 請求層），運維上要故意做小

網路控管通常分兩層：

• 組織層 allowlist：管理者設定的「最大可去目的地」集合。
• 請求層 network_policy：每次任務指定，必須是組織層的子集合。

這其實很適合拿來做治理：組織層保持小而穩、請求層更小更精準。當請求想去不在組織層的網域時，直接報錯阻擋，反而是好事。

技巧 9：有驗證需求就用 domain_secrets，別把 API key 直接給模型看

要打受保護 API 時，最怕憑證被模型輸出到 log、或意外出現在 artifacts。用 domain_secrets 類機制的好處是：

• 模型只看到占位符（例如 $API_KEY）。
• 執行時才對核准網域注入真實密鑰。
• 就算 prompt 或工具輸出被記錄，也較不容易外洩。

技巧 10：同一套 Skills/工具語意，先本地快跑，再搬到雲端求穩

很推薦的開發節奏是：

1. 先用本地 shell：快速迭代、好除錯、可以接內網工具。
2. 成熟後換 hosted 容器：追求可重現、隔離、部署一致性。
3. Skill 保持不變：流程才是核心資產，執行位置只是載體。

這樣你會同時得到「開發速度」與「上線穩定」。

三種常見組合模式：照著做就能做出可交付的 agent

模式 A：Install → Fetch → Write Artifact（最基本、最實用）

這模式超像你自己在終端做事：裝套件、抓資料、寫出報告。差別是 agent 幫你做完並把檔案放在 /mnt/data。

• install 幾個必要套件
• fetch：爬資料或呼叫允許的 API
• write：輸出 report.md、cleaned.csv 等 artifacts

模式 B：Skills + Shell（讓成功案例可以重複成功）

當你做出第一個能跑的工作流，下一步就是「不要讓它因為 prompt 漂移而壞掉」。把流程寫進 skill（含護欄、模板、檢查清單），再讓 agent 在 shell 裡照 SOP 跑，會穩很多。

• 資料清理 + 產出摘要
• 試算表分析或編修
• 例行標準報告（固定章節、固定輸出）

模式 C（進階）：把 Skills 當企業工作流的載體（會越用越像 SOP 系統）

多工具編排時，最容易掉準確率的是「從 A 工具結果推到 B 工具操作」這段。skills 的價值在於把這段變成程序化步驟：該查什麼、怎麼檢查、失敗怎麼降級、最後產出什麼。

像 Glean 這樣的團隊也分享過：針對特定企業系統（例如 Salesforce）的 skill，配合更好的路由描述、負向範例與模板內嵌，能提升評測表現並改善延遲。對工程師來說，這意味著你不是在「教模型變聰明」，而是在「把流程寫清楚讓它照著做」。

未來趨勢

• Skills 會更像「可執行流程資產」：未來會更常看到 skill 搭配版本控管、回歸測試、審核流程，變成組織級 SOP 的一部分。
• 長流程記憶管理走向自動化：compaction 會更深度地與 artifacts、checkpoint、觀測指標整合，減少人工整理上下文的成本。

給專業人士的實務建議

• 先做「可驗收」再追求「更聰明」：把輸出固定成 /mnt/data 的 artifacts（檔名、格式、成功判準），你會更容易測試、除錯與產品化。
• 安全從第一天做：網路用兩層 allowlist 做最小權限；需要授權就用 domain_secrets；外部內容一律當不可信，skill 內要有驗證與降級策略。

參考資料

• 參考來源：OpenAI 官方文件：https://developers.openai.com/blog/skills-shell-tips

導言

Anthropic 於 2026 年發表的教育報告提出「AI 流利度指數」（AI Fluency Index），透過分析近萬筆與 Claude 的多回合對話，量化使用者在與 AI 協作時展現的可觀察行為。此報告為企業與技術主管提供一個基準，用以評估組織在導入生成式 AI 時的實作成熟度與風險點。

重點速覽：研究以 4D AI Fluency Framework 中可直接觀察的 11 項行為為主，發現「迭代與精進（iteration and refinement）」與其他流利度行為高度關聯；另外在產出 artifact（如程式碼或文件）時，使用者雖更具指令性，但對 AI 產出的評估行為反而下降。

如何量化 AI 流利度（方法與指標）

本研究採用由學者與 Anthropic 共同提出的 4D AI Fluency Framework，將 AI 流利度切分為多項可觀察行為。報告聚焦於在 Claude.ai 或 Claude Code 聊天介面中可直接辨識的 11 項行為（例如：迭代與精進、質疑模型推理、指出缺失情境、設定格式、提供範例等）。

研究資料來自 2026 年 1 月一週內的 9,830 筆多回合對話，採用隱私保護的分析工具逐一標註每場對話是否出現特定行為，並檢驗結果在不同日與不同語言間的一致性，以確認樣本的穩定性。

核心方法要點：

• 樣本：9,830 筆在 Claude.ai 上的多回合對話
• 可觀察指標：11 項行為（每場對話可同時呈現多項）
• 分析方式：逐條對話二元標註（有/無該行為），檢驗週期與語言一致性

研究限制（方法面）：僅能觀察聊天介面內的行為，無法涵蓋框架中另外 13 項在對話外發生的重要行為（例如對 AI 輸出負責任的使用決策）；此外以二元分類忽略行為強度或部分展現的細節。

圖片：一張流程圖示意 4D 框架到 11 項可觀察行為的關聯。

主要發現：迭代帶動流利度，產出情境降低評估行為

報告揭示兩大重要模式：

1. 迭代與精進是流利度的核心

85.7% 的對話包含迭代與精進（即以先前回覆為基礎反覆修正），而這類對話平均展現 2.67 項流利度行為，相較於非迭代對話的 1.33 項，幾乎多一倍。尤其在評估面向（如質疑模型推理、識別缺失情境）差距更大：迭代對話在質疑模型推理上的發生率高出約 5.6 倍，在識別缺失情境上高出約 4 倍。

此結果對企業意義重大：鼓勵使用者在 AI 互動中維持多回合、以迭代為導向，能顯著提高整體的甄別與驗證行為，降低因過度依賴單次回覆而產生的風險。

圖片：柱狀圖比較有無迭代之下各行為的相對頻率。

2. 在產出 artifact 時使用者更具指令性，但評估行為下降

約 12.3% 的對話涉及生成 artifact（程式碼、文件或互動工具）。在這類對話中，使用者更常進行：

• 明確說明目標（+14.7 個百分點）
• 指定輸出格式（+14.5 個百分點）
• 提供範例（+13.4 個百分點）
• 進行更多迭代（+9.7 個百分點）

然而，相對地，對評鑑/辨識面的行為（例如：識別缺失情境、事實查核或要求模型說明推理）卻顯著下降（分別約 -5.2pp、-3.7pp、-3.1pp）。換言之，使用者在要求具體產出時傾向把重心放在指令性與格式化，而非批判性驗證。

對企業而言，這可能影響產品或服務品質：當 AI 生成看起來「完成」的工件時，若缺乏驗證流程，錯誤或不一致性可能被忽略。

圖片：雙柱圖比較 artifact 與非-artifact 對話在描述/委派行為與辨識行為的差異。

對企業導入的風險與機會（策略性觀點）

根據上述發現，可以從風險治理與效率增進兩面來思考：

• 機會：透過設計鼓勵迭代的使用流程（如內建回饋回圈、範本化的追問提示），可提升使用者在驗證與辨識上的行為頻率。
• 風險：在需要高正確性或法遵的場景（法務文件、財務分析、關鍵程式碼），若僅依賴 AI 所產生的「完成品」而缺少審核，將增加錯誤、偏誤或責任歸屬模糊的風險。

因此企業在導入生成式 AI 時應同時投資於使用者訓練、流程設計與檢核機制，以確保可觀察行為與不可觀察但關鍵的倫理實務同步提升。

發展使用者 AI 流利度的建議（企業視角）

基於研究中的行為模式，對企業與技術主管的建議包括：

1. 把「迭代」納入標準作業流程：在工具或內部培訓中強制或鼓勵多回合互動與逐步驗證。
2. 在產出導向的使用情境中設計驗證檢查點：即便輸出看似完成，也應強制事實查證、同行審閱或自動化測試。

研究限制（面向與解讀）

Anthropic 報告指出多項限制，對企業解讀此指數時應謹慎：

• 樣本為單一週期（2026 年 1 月）且偏向多回合使用者，可能高估早期採用者的成熟度。
• 僅可觀察對話內行為，無法衡量對話外的關鍵行為（如透明揭露 AI 參與、後續風險評估與責任分配）。
• 採用二元標註方式忽略了行為強度與部分表現的差異。
• 研究為相關性分析，無法直接斷定某行為會造就另一行為的因果性。

未來趨勢

1. 隨著模型產能與可用性提升，企業會更仰賴 AI 產生可交付物，但同時會發展更多自動化的驗證工具（如自動化事實核查、靜態分析與合規掃描）。
2. AI 流利度的衡量將從可觀察對話行為擴展到整個協作生態，包括責任揭露、使用者外部驗證與跨工具的能力指標。

給專業人士的實務建議

1. 在團隊內建立「迭代文化」：推動多回合互動與持續回饋，避免把 AI 回覆當成一次性答案。
2. 為關鍵產出設計強制性驗證：包含事實查核流程、同儕審查或整合測試，確保 AI 產物在上線前被檢驗。

參考資料

本文整理自 Anthropic 的《Education Report: The AI Fluency Index》（2026-02-23）。如需延伸閱讀

（來源若需逐條引用，建議以 Anthropic 原報告為主）

2025 年，是 AI coding agent 從「實驗工具」走向「正式上線」的一年。2026 年，則可能是軟體開發模式被重新定義的開始。

根據 Anthropic 公司所發佈的《2026 Agentic Coding Trends Report》指出，軟體開發正從「人類寫程式」演變為「人類協作與指揮 AI 寫程式」的新階段。

這不只是效率提升，而是一場結構性的改變。

---

一場結構性轉變：Software Development Lifecycle 正在重寫

過去，工程師的核心工作是：

• 寫程式
• 除錯
• 測試
• 維護

現在，AI agent 可以：

• 自動撰寫與重構程式碼
• 自動產生測試
• 自動除錯
• 自動生成文件

這讓整個 SDLC（軟體開發生命週期）壓縮。

工程師角色的轉變

工程師不再只是執行與實作者(implementer)，而是：

• 架構設計者（Architect）
• Agent 協調者（Orchestrator）
• 品質判斷者（Evaluator）
• 問題定義者（Strategic Thinker）

真正的價值，從「寫出程式碼」轉向「決定該寫什麼，以及如何讓多個 agent 正確完成」。

---

趨勢 1：單一 Agent 將演變成「多 Agent 協作團隊」

2025 年，多數工作流程仍是單一 agent sequential 處理任務。

2026 年的關鍵突破是：

Multi-agent systems 取代 single-agent workflow

架構將變成：

• 一個 Orchestrator agent
• 多個專職子 agent（測試、文件、分析、前端、後端）
• 平行處理
• 最後整合輸出

這種架構能顯著提升：

• 並行推理能力
• 上下文管理能力
• 複雜任務處理能力

AI 不再只是工具，而是可被編排的團隊。

---

趨勢 2：長時間運作的 Agent 會建構完整系統

早期 agent 只能處理幾分鐘的任務。

現在開始出現：

• 連續運作數小時
• 自動規劃
• 多階段迭代
• 自我修正

2026 年，agent 甚至可以：

• 連續工作數天
• 建立完整應用系統
• 自動清理技術債
• 從 idea 到 deploy 只需數天

這將改變創業門檻與產品開發速度。

---

趨勢 3：人類監督將變得「更聰明，而不是更累」

一個重要觀察：

雖然工程師約 60% 工作使用 AI，
但「完全委派」的比例只有 0–20%。

原因很簡單：

AI 協作不是放手，而是智慧分工。

2026 年的關鍵能力將是：

• Agent 自動做品質檢查
• Agent 知道何時「請求人類協助」
• 人類只專注在：
  • 風險決策
  • 架構判斷
  • 商業影響

不是審查全部，而是審查重要部分。

---

趨勢 4：Coding 不再只屬於工程師

Agentic coding 將擴展到：

• 法務
• 行銷
• 業務
• 營運
• 資安
• 研究團隊

未來的變化不是「人人都變工程師」，
而是「人人都能用 agent 解決問題」。

技術門檻正在快速下降。

---

趨勢 5：生產力將呈現倍數成長，而非線性提升

報告指出一個關鍵現象：

工程師花在每項任務的時間略減，
但整體輸出量大幅增加。

換句話說：

AI 帶來的不是「更快做同樣事情」，
而是「做更多原本做不到的事情」。

包括：

• 修小 bug（papercuts）
• 建立內部工具
• 實驗性專案
• 自動化流程

約 27% 的 AI 工作，是「原本不會做的事」。

這將改變軟體經濟學：

• 更低 TCO
• 更短上市時間
• 更多可行專案

---

趨勢 6：安全性成為雙面刃

Agentic coding 讓：

• 每位工程師都能進行安全審查
• 自動化防禦系統可以 machine-speed 回應攻擊

但同時：

• 攻擊者也能用 agent 擴大攻擊規模

因此：

Security-first architecture 將成為標準配置，越早把安全納入 agent 設計，就越有優勢。

---

2026 年的 4 個戰略優先事項

報告建議企業聚焦四件事：

1. 建立 multi-agent 協作能力
2. 設計 AI + Human 的審查架構
3. 將 agentic coding 擴展到全公司
4. 從第一天就嵌入安全設計

---

最重要的轉變：從寫程式到「編排智能」

軟體開發正在發生根本改變：

寫程式不再是核心價值
定義問題、設計架構、協調智能才是

AI 不是替代工程師，
而是放大工程師的影響力。

未來的工程師會：

• 管理多個 agent
• 同時推進多條產品線
• 將精力投入高價值決策

這是一種角色升級，而不是淘汰。

---

結語

2026 年的 agentic coding 不是效率工具升級，
而是一場開發典範的轉移。

那些把 AI 當作戰略能力的組織，
將在新規則下競爭。

那些只把它當作「自動補全工具」的公司，
將逐漸落後。

問題已經不再是：

AI 會不會改變開發？

而是：你是否準備好成為指揮 AI 的人？

參考原始文章 : Anthropic 公司發佈的《2026 Agentic Coding Trends Report》

在實務上，許多團隊構建 AI Agent 的流程大致相同：選模型 → 接工具 → 寫提示詞 → 手動測幾次 → 發布。
但這樣的流程，往往只能產出「看起來可用」的 Demo。一旦進入真實生產環境，各種預期外的錯誤、退化（regression）與品質不穩定問題就會接連出現。

真正被忽略的關鍵環節，其實只有一個：評估（Evaluation）。

近期，Anthropic 發布了一份重量級工程指南〈Demystifying Evals for AI Agents〉，深入拆解 AI Agent 評估的系統性方法。AI 開發工程師 Joe Njenga 也從開發者視角對這份指南進行了實務導讀。

本文將以「專業工程與產品團隊」為核心讀者，重構這份內容，幫助你建立一套能支撐長期演進、可規模化的 Agent 評估體系。

---

為什麼沒有評估，Agent 只會越改越糟？

Anthropic 在文章一開始就點出痛點，並以 Claude Code 的開發經驗為例：

當使用者反饋「改版後變更差」，但團隊卻只能靠猜測與反覆檢查，問題其實不在模型，而在 沒有評估機制。

在缺乏評估的情況下，團隊只能被動循環：

1. 等使用者抱怨
2. 嘗試手動重現
3. 修一個 bug
4. 祈禱沒有引入新的回歸問題

結果是：

• 無法區分「真回歸」與「隨機噪聲」
• 無法在發版前自動測試上百種場景
• 無法量化「這次到底有沒有變好」

Claude Code 早期也曾如此。直到團隊引入 結構化評估（從簡潔度、檔案編輯行為，到後期的過度設計等複雜行為），才讓產品改進開始變得可衡量、可討論、可協作。

---

Agent 的整個生命週期，都離不開評估

評估不是後期補丁，而是全生命週期工具：

• 早期階段：
  評估用例能迫使團隊明確定義「成功是什麼」，避免工程師各自解讀規格。
• 成熟階段：
  評估用來維持一致的品質門檻，確保產品不隨著優化而退化。

更重要的是：
當新模型出現時，有評估的團隊幾天就能完成升級；沒有評估的團隊，往往需要數週人工測試。

---

為什麼 Agent 評估，不能照抄傳統測試？

傳統測試 vs Agent 評估的根本差異

• 傳統函式：相同輸入 → 相同輸出
• Agent：同一任務 → 多條合理路徑

例如，一個「建立 GET API」的編碼 Agent，可能：

1. 先寫路由再查資料庫
2. 先分析既有架構再動手
3. 先反問需求再實作

三條路都可能是「正確解」。
如果你的測試只接受其中一條，就會錯殺真正好的 Agent 行為。

Agent 評估的三個關鍵特性

1. 多步驟、跨工具、跨環境
2. 錯誤會累積（複利效應）
3. 有時「沒照規則走」，反而更好

這也是為什麼 「評結果，而不是評路徑」 是 Anthropic 一再強調的原則。

---

Anthropic 內部通用的 Agent 評估術語

在設計評估前，先對齊語言：

• 任務（Task）：單一測試案例與成功標準
• 試驗（Trial）：同一任務的一次完整嘗試
• 評分器（Grader）：負責判斷表現的邏輯
• 執行記錄（Transcript）：完整對話、工具呼叫與中間狀態
• 結果（Outcome）：環境中的最終真實狀態
• 評測框架（Evaluation Harness）：負責跑測試、收集與彙總
• Agent 框架（Agent Harness）：模型 + 工具編排系統
• 評測套件（Evaluation Suite）：一組針對特定能力的任務集合

---

三種評分器（以及實務怎麼搭配）

1️⃣ 基於程式的評分器（Code-Based）

• 單元測試、靜態分析、狀態驗證
• 適合：客觀、可驗證結果
• 盲點：無法判斷可讀性與設計美感

2️⃣ 基於模型的評分器（Model-Based）

• 使用 LLM + Rubric 打分
• 適合：主觀品質、開放式任務
• 實務技巧：允許模型回傳「未知」，避免亂判

3️⃣ 人工評分器（Human）

• 黃金標準，用來校準模型評分器
• 缺點：慢、貴、不可規模化

👉 最佳實務：混合使用
例如除錯 Agent：

• 單元測試（是否真的修好）
• 靜態分析（有沒有新問題）
• LLM 評分（品質）
• 狀態檢查（有沒有改錯檔）

---

能力評估 vs 回歸評估：別搞混目的

能力評估（Capability Evals）

• 問題是：「它到底能做到什麼程度？」
• 通過率太高，代表測試太簡單
• 用於探索邊界與學習方向

回歸評估（Regression Evals）

• 問題是：「它還能不能持續做到？」
• 期望接近 100%
• 用於確保優化不退步

📌 順序很重要：
能力通過後 → 才「畢業」成回歸測試。

---

非確定性下的關鍵指標：pass@k 與 pass^k

• pass@k：k 次中至少成功一次
  → 適合探索、研發階段
• pass^k：k 次必須全部成功
  → 適合生產環境

如果單次成功率是 73%：

• pass@10 看起來很好
• pass^1 代表 27% 使用者會失敗

👉 結論：

• 研發看 pass@k
• 上線看 pass^k

---

8 步可落地的 Agent 評估行動路線

0. 從 20–30 個真實失敗案例 開始
1. 把「發版前必看 3 件事」自動化
2. 消除任務歧義，對齊成功定義
3. 同時測「該做什麼」與「不該做什麼」
4. 評結果，不評路徑
5. 引入部分分數（不是非黑即白）
6. 讀執行記錄，驗證是 Agent 還是評分器錯
7. 通過率 100% 時，加難度
8. 持續迭代，評估本身也要演進

---

瑞士起司模型：分層防禦才撐得住生產

沒有任何單一評測能抓到所有問題：

• 部署前：
  • 自動化評測（單元測試、靜態分析、LLM rubric）
  • 人工抽查 transcripts
• 部署後：
  • 生產監控（成功率、延遲、token）
  • 使用者回饋 → 轉為新測試用例

每一層，都在補另一層的洞。

---

結語：評估結果，而不是限制 Agent 的創造力

對原型來說，手測或許夠用；
但對任何 面向客戶、影響業務的 Agent，沒有評估，就注定陷入被動循環。

最重要的實務結論：

• 從真實失敗案例開始
• 評「結果」，不是「過程」
• 有策略地組合評分器
• 生產環境重視 pass^k
• 建立多層防線，而非單點信仰
• 定期閱讀 transcripts，確保你「評對問題」

---

給專業人士的未來趨勢與建議

1. Agent 評估將成為 AI 工程的核心基礎設施，就像 CI/CD 之於傳統軟體。
2. 模型越強，評估越重要：否則你無法分辨是模型進步，還是系統退化。

---

參考資料

• Anthropic Engineering Blog（官方）
• Medium｜Joe Njenga（實務解析）

以下訪談為節錄自原影片：AI on campus [Anthropic 公司YouTube訪談]

如果要用一個詞來形容現在的大學校園，那就是「混沌」（Chaos）。但這是一種充滿了創造力與可能性的混沌。

根據一項針對大學生的調查，已有高達 90% 的學生在日常工作流程中使用 AI。從倫敦政經學院（LSE）到柏克萊大學（UC Berkeley），從普林斯頓（Princeton）到亞利桑那州立大學（ASU），AI 已經不再是一個遙遠的概念，而是學生們用來摘要講座、解決習題、甚至編寫程式碼的日常工具。

然而，這種快速的普及也帶來了巨大的灰色地帶。教授與行政單位仍在摸索如何規範，有些課程明令禁止，有些則積極鼓勵，導致學生們處於一種不得不自我導航的尷尬處境。

本篇文章整理了來自全球大學的四位學生代表——Zayn (LSE)、Chloe (Princeton)、Marcus (Berkeley) 和 Tino (Thunderbird/ASU)——的深度訪談，帶你一窺 AI 如何重塑校園生活，以及對於未來職涯的關鍵實務建議。

---

一、 現狀：不只是作弊，而是「賦能」

大眾對學生使用 AI 的刻板印象往往停留在「作弊」或「偷懶」。確實，用 AI 快速生成測驗答案的情況依然存在，但對於許多積極進取的學生來說，AI 帶來的改變遠比這更深遠。

1. 降低技術門檻，成為想法的原型開發者

最令人興奮的突破在於「可及性」（Accessibility）。過去，只有計算機科學（CS）背景的學生有能力開發應用程式。現在，透過 Claude 等 AI 工具，心理學、政治學甚至純文科的學生，都能在幾天內從構思到做出一個可運行的原型。

• 實例分享： LSE 的學生社團現在能透過 AI 輔助架設功能完整的網站，而不僅僅是依賴 Instagram 頁面。
• 創意應用： 有學生開發了「圖書館座位偵測器」，分析教室數據來告訴同學哪裡有空位；還有人開發了「課程註冊提醒器」，當熱門課程一有空缺就立刻通知，省去了手動刷新的時間。

這些案例證明，AI 正在將「想法」與「實踐」之間的距離縮短。

2. 個性化的私人導師

AI 扮演的另一個重要角色是「個性化學習助手」。大學課堂往往是大班制，教授無法顧及每個人。學生現在會將講義上傳給 AI，要求它在每一頁投影片旁生成「教授註釋」，解釋抽象概念或補充背景知識。

---

二、 陰暗面：AI 廢話（Slop）與所有權的迷思

然而，AI 的普及並非全是陽光。韋氏字典（Merriam-Webster）將「Slop」（意指劣質、糊狀的廢料）列為年度詞彙，這在 AI 生成內容中尤為貼切。

1. 什麼是「AI Slop」？

對學生來說，「AI Slop」指的是那些一看就知道是機器生成的、缺乏靈魂的內容。

• 特徵： 充滿了像 “delve into”（深入探討）、過多的破折號，或是像「你說得完全正確」這類標準化的客套話。
• 後果： 當學生使用 AI 生成求職信（Cover Letter）時，這些千篇一律的內容不僅無法讓你脫穎而出，反而會讓你顯得平庸且缺乏誠意。

2. 「所有權羞恥」（Ownership Shame）

這是一個有趣的心理現象。即便學生在專案中使用了 AI 進行頭腦風暴或架構梳理，當被問及「你是如何完成這個專案」時，許多人會下意識地隱瞞 AI 的參與，或者感到羞愧。這是因為目前缺乏一套明確的語言或框架，來定義「人機協作」的界線——到底用了多少 AI 才算過度依賴？

3. 批判性思考的流失

如果遇到困難就直接問 AI 答案，學生將失去培養「韌性」（Resilience）的機會。正如 Tino 所言，研究所本該是擴展批判性思維、學習果斷決策的時期，過度依賴 AI 可能會剝奪這些成長的機會。

---

三、 職場衝擊：與演算法的博弈

AI 對學生的焦慮不僅限於課業，更延伸到了畢業後的求職市場。

1. 殘酷的 AI 履歷篩選

現在的求職過程變得更加「非人化」。許多公司使用 AI 來篩選履歷，甚至進行初步面試。

• 現狀： 學生可能花費數小時客製化履歷，卻在提交後 15 分鐘內收到一封顯然也是 AI 生成的拒信。
• 面試體驗： 與螢幕上的文字對話、對著鏡頭錄影回答問題（HireVue），讓求職過程缺乏人與人之間的化學反應。

2. 機會：AI 流暢度（AI Fluency）成為新優勢

儘管篩選過程令人沮喪，但市場對人才的需求也在轉變。頂尖諮詢公司現在更傾向於招聘具備「AI 流暢度」的 MBA 畢業生，而不僅僅是通才。如果你懂得如何將 AI 應用於不同產業場景，你將成為首選候選人。

---

四、 未來實務推薦：如何在 AI 時代保持競爭力？

基於這四位來自頂尖學府的 AI 大使與重度使用者的經驗，我們整理出以下針對學生與教育工作者的實務建議。這不僅是關於如何使用工具，更是關於如何調整心態。

給學生的實戰建議

1. 轉變心態：從「獲取答案」到「協作思考」

不要只把 AI 當作搜尋引擎或代筆者。

• 推薦做法： 在寫報告時，可以請 AI 幫你生成大綱（Outline）或進行思維發散（Thought Dumping），將雜亂的子彈筆記整理成結構化的段落，但最後的撰寫與語氣修飾必須由你自己完成。
• 意圖設定（Intentionality）： 在按下 Enter 鍵發送提示詞之前，先問自己：「我是要它幫我完成任務，還是要它提供不同視角？」。

2. 利用「學習模式」與「蘇格拉底式對話」

如果你想真正學到東西，不要讓 AI 直接給出程式碼或論文。

• 推薦做法： 使用 Claude 的「學習模式」或透過 Prompt（提示詞）要求它：「請不要直接給我答案，而是透過反問的方式引導我思考。」。
• 複習神器： 為每一門課建立一個專屬的 AI Project（專案），上傳講義與筆記。在考前，要求 AI 用「簡潔模式」（Concise Mode）幫你快速梳理核心概念。

3. 建立「防禦底線」（The Defense Line）

如何判斷自己是否過度依賴 AI？這裡有一個黃金法則：「你必須能夠像向五年級學生解釋一樣，清楚解釋你產出的內容」。

• 實務檢測： 如果你在課堂報告或面試中被問到某個細節，而你因為那是 AI 生成的而無法回答，那你就越界了。AI 可以是你的助手，但你必須是那個能站上台捍衛觀點的「最終魔王」（Final Boss）。

4. 擁抱「AI 流暢度」作為核心技能

不要害怕學習新工具。現在的趨勢是，非技術背景的學生也能透過自然語言（Natural Language）來控制終端機（Terminal）或寫程式。

• 行動呼籲： 去關注那些在 Substack 或開源社群分享 AI 新玩法的專家（如 Nate Jones），像海綿一樣吸收新知，並嘗試將其應用到你的旁類專案（Side Projects）中。

給教育者與機構的建議

1. 擁抱而非禁止，引導而非漠視

禁止學生使用 AI 是徒勞的。LSE 的一門課程示範了極佳的轉型：

• 案例： 課程不再要求學生寫傳統論文，而是要求學生提交與 AI 的對話紀錄。教授評分的重點在於：你問了什麼問題？你如何與 AI 互動？你是否有批判性地評估 AI 的回應？最後，學生需錄製影片來口頭闡述觀點，確保他們真的理解內容。

2. 將 AI 納入課程設計

像 ASU 這樣的大學已經開始積極擁抱 AI，甚至由職業中心建立「提示詞庫」（Prompt Bank）來幫助學生模擬面試與職場情境。未來的課程應該教導學生如何負責任地使用這些工具，而不是假裝它們不存在。

---

結語：我們會找到出路的

這場 AI 帶來的校園革命，既混亂又迷人。我們看到了作弊的隱憂，但也看到了前所未有的創造力爆發。

正如訪談結束時 Greg 所觀察到的，儘管面臨不確定性，學生們並沒有陷入「末日論」（Doomerism）。相反地，大家抱持著一種「我們會搞定它」（We’ll figure it out）的務實樂觀主義。

在這個時代，學生的責任回到了最根本的問題：你為什麼來上大學？ 如果你只是為了混張文憑，AI 可以幫你輕鬆作弊過關；但如果你是為了學習與成長，AI 將是你最強大的外骨骼，幫助你走得比任何時代的學生都還要遠。

選擇權，始終在你的手中。

參考資料

• 原影片：AI on campus [Anthropic 公司YouTube訪談]