在實務上，許多團隊構建 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訪談]

在 2024 到 2025 年的 AI 浪潮中，無數企業湧入 AI 領域，試圖開發出下一個顛覆性的產品。然而，現實是殘酷的：大多數 AI 產品不一定能勝出。為什麼擁有最強大的模型（如 GPT-4 或 Claude）卻無法保證產品的成功？

本文整理自 OpenAI、Google 與 Amazon 的 AI 專家 Aishwaria Raanti 與 Kiti Bottom 的實務分享，他們參與過超過 50 次 AI 產品部署，並總結出一套「持續校準與持續開發」（CC & CD）框架。如果你正掙扎於讓 AI 產品落地，或者希望避免常見的陷阱，這份深度指南將為你揭示 AI 產品開發的真諦。

一、 AI 產品與傳統軟體的本質區別

許多開發團隊失敗的第一個原因，在於他們用「開發傳統軟體」的思維來處理 AI。專家指出，AI 產品具備兩個根本性的差異：

1. 非確定性（Non-determinism）

傳統軟體（如 Booking.com）的流程是確定的：使用者點擊按鈕，系統執行預設動作，結果完全可預測。但 AI 產品面臨的是輸入與輸出的雙重非確定性：

• 輸入端： 使用者可以使用自然語言以千萬種方式表達意圖。
• 輸出端： 大型語言模型（LLM）本質上是機率性的黑盒子，對提示詞（Prompt）極其敏感，同樣的請求可能得到不同的結果。

2. 自主性與控制權的權衡（Agency-Control Trade-off）

這是許多開發者忽視的關鍵：當你賦予 AI 系統愈高的決策能力（自主性），你就必須放棄愈多的控制權。團隊往往過於執著於建立「全自動化 Agent」，卻忽略了系統是否已經贏得了使用者的信任，或者其可靠性是否足以支撐這些決策。

---

二、 核心框架：持續校準與持續開發 (CC & CD)

為了應對上述挑戰，專家提出了 CC/CD (Continuous Calibration & Continuous Development) 框架。這可以看作是 AI 時代的 CI/CD。

1. 持續開發 (Continuous Development)

這是一個獲取基準與部署的循環：

• 定義能力範圍與數據策劃： 在動手前，先確定預期輸入與輸出。這有助於對齊團隊對產品行為的共識。
• 設計評估指標（Evaluation Metrics）： 針對不同維度定義衡量標準。
• 部署： 將系統推向測試或生產環境。

2. 持續校準 (Continuous Calibration)

這是 AI 產品最獨特的部分，旨在捕捉非預期行為：

• 分析行為與識別錯誤模式： 使用者在生產環境中的行為往往與測試時完全不同。
• 修正與迭代： 發現新的錯誤模式後，除了修復問題，還要設計新的評估指標來防止退化。
• 最小化驚喜： 校準的目標是讓系統行為變得可預測，直到團隊不再看到新的異常數據分佈，才考慮提升自主性。

---

三、 實務路徑：從低自主性到高自主性的進化

專家強烈建議不要試圖在第一天就達成「全自動 Agent」。相反地，應該採取「階梯式進步」：

案例研究：客戶支援 AI

1. V1 路由與分類（高控制、低自主）： AI 僅負責將工單分配給正確的部門。即使分錯，人類也能輕鬆修正。這階段的重點是解決企業內混亂的數據分類（Taxonomy）問題。
2. V2 協作助手（中自主）： AI 根據標準作業程序（SOP）產生回覆草稿，由人類審核並修改。這時系統可以免費獲得大量的錯誤分析數據，因為人類修改的部分就是 AI 的盲點。
3. V3 端到端解決方案（高自主）： 當 AI 的草稿幾乎不再被修改時，才開放自動回覆、自動退款或自動建立技術工單。

這種模式同樣適用於程式助手（從程式碼補全到自動提交 PR）或行銷助手（從草稿撰寫到自動 A/B 測試與優化）。

---

四、 成功的維度：領導力、文化與技術

成功的 AI 轉型不只是技術問題，而是「成功三角」的結合：領導力、文化與技術進步。

1. 領導力：親自下場（Hands-on）

AI 領域變化極快，領導者的直覺可能在三個月內過時。專家舉例，Rackspace 的 CEO 每天早上 4 到 6 點會固定排除所有會議，專門學習最新的 AI 技術與趨勢。領導者必須有勇氣承認自己可能是「房間裡最笨的人」，並重新建立對技術邊界的認知。

2. 文化：賦能而非取代

許多企業推動 AI 時會遭遇阻礙，因為領域專家（SME）擔心被 AI 取代而不願配合。成功的企業會建立「賦能文化」，強調 AI 是用來 10 倍化員工生產力的工具。

3. 技術：著迷於工作流程而非模型

80% 的 AI 工程師其實應該花時間在理解工作流程（Workflow）上，而不是追求最酷的模型。你必須極度了解企業數據的混亂程度（如：各種重複的數據標籤、技術債），才能讓 Agent 真正發揮作用。

---

五、 關於評估（Evals）與監控的真相

目前業界對「評估」（Evals）存在一種錯誤的二分法：認為要麼靠評估解決一切，要麼只靠線上監控。

為什麼你不能只靠評估？

「評估」這個詞已經產生了語義擴散（Semantic Diffusion），每個人定義都不同。更重要的是，評估指標只能捕捉你「已知」的錯誤。

未來建議的監控方式：

• 顯性信號： 使用者點擊「倒讚」。
• 隱性信號： 使用者沒有給倒讚，但點擊了「重新產生」（Regenerate），這代表初次結果未達標。
• 回饋循環： 從生產環境中提取異常案例，將其轉化為新的評估數據集，這才是真正的進步。

---

六、 未來實務推薦：2026 的戰略佈局

對於希望在未來兩年保持競爭力的團隊，專家給出了以下前瞻性建議：

1. 痛苦是新的護城河（Pain is the New Moat）

現在開發 AI 的工具非常廉價，甚至可以靠 AI 寫出基礎 App。真正的護城河不再是功能，而是你經歷過多少次失敗迭代、對非確定性邊界的掌握、以及對特定業務場景的深度優化。那些願意經歷學習與實施痛苦的團隊，才能建立真正的優勢。

2. 主動型 Agent (Proactive Agents) 的興起

目前的 AI 多是被動回覆。未來的趨勢是 Agent 能夠理解背景並主動預測需求。

• 例如：程式碼 Agent 在你上班前就已經修復了五個 Bug 並準備好 PR 讓你審核。
• 例如：監控 Agent 發現網站流量異常，主動建議數據庫重構方案。

3. 多模態體驗 (Multimodal Experiences)

語言只是人類溝通的最後一環。未來的產品將整合影像、語音與環境理解。多模態理解將解鎖那些傳統上難以數位化的數據，如手寫文件或混亂的 PDF，這將帶來巨大的商業價值。

4. 專注於品味與判斷力

當「實現」變得極其廉價時，產品的設計（Design）、品味（Taste）與判斷力（Judgment）將成為核心競爭力。你必須具備重新思考端到端流程（End-to-end Workflow）的能力，而不是只在邊角料做自動化。

---

結語：回歸問題本質

在 AI 時代，最容易犯的錯就是「拿著錘子找釘子」。專家提醒我們，AI 終究只是一個工具。成功的關鍵始終在於：你是否極度著迷於客戶的問題？你是否理解他們的工作流程？

建立 AI 產品就像攀登險峻的山峰：你不會第一天就試圖攻頂，而是透過小規模的訓練、建立營地（低自主性階段），並根據天氣變化（數據回饋）不斷校準路線，最終才能安全到達終點。

如果你能擁抱「非確定性」，並在持續校準中保持耐心，你就能在這場 AI 競賽中脫穎而出。

參考資料

• 原影片：Why most AI products fail: Lessons from 50+ AI deployments at OpenAI, Google & Amazon

在生成式 AI 全面進入校園後，許多教師正面臨一個棘手卻真實的問題：
學生交出的作業愈來愈完美，但他們真的理解了嗎？

來自 紐約大學史登商學院 的資料科學教授 Panos Ipeirotis，最近就親身經歷了這種「詭異的幸福」。他的實驗不只是一門課的插曲，而是對整個高等教育評量制度的正面衝擊。

---

一、作業品質異常飆升，卻揭露更大的評量危機

在與 Konstantinos Rizakos 合開的《AI／ML 產品管理》課程中，Panos 發現學生的課前作業品質突然全面「升級」——
結構嚴謹、語言精煉，幾乎像顧問公司反覆修訂過的正式報告。

然而，當教師在課堂上隨機請學生解釋自己繳交的內容時，問題立刻浮現：
不少學生在被追問兩三個關鍵細節後，便無法清楚說明自己的決策邏輯，甚至完全當機。

結論非常殘酷：
如果學生連自己交出的作業都說不清楚，那這份作業就根本無法衡量其真實理解能力。

這已不只是作弊或投機，而是整個作業評量機制在 AI 時代失效。

---

二、為什麼「現在」必須重新思考口試？

核心原因其實很直接：
大型語言模型（LLM）已能即時完成大多數傳統作業與專題成果。

• 課後作業 → 可隨時請 ChatGPT 協助
• 小組專題 → AI 可生成完整簡報與講稿
• 課堂報告 → 即使未實際參與，也能講得條理分明

Panos 坦言，真正讓他感到無力的，不再只是「搭便車」，而是教師已無從判斷誰真正參與、誰真正理解。

此時，「口試」重新浮上檯面，因為它具備三項 AI 難以取代的特性：

• 即時推理與臨場反應
• 對陌生問題的即時應用能力
• 能為每一個決策提出清楚、可追溯的理由

唯一的問題只有一個：
口試長期無法規模化——除非，考官本身也是 AI。

---

三、用語音 AI 代理，讓口試第一次得以規模化

為了解決人力與排程的後勤噩夢，Panos 團隊選擇使用 ElevenLabs 的對話式語音 AI 平台，打造一套「AI 口試考官」。

核心設計重點

• 動態變數注入：學生姓名、專題內容皆可個人化
• 工作流架構：由多個子 Agent 分工，而非單一泛用模型

口試流程

1. 討論學生專題：目標、資料來源、模型選擇依據、失敗經驗
2. 即時案例分析：隨機抽取課堂案例，測試知識吸收程度

背後由三個子 Agent 支撐：

• 身分驗證 Agent
• 專題討論 Agent
• 案例討論 Agent

這樣的設計，不只降低對話失控風險，也讓系統調校更清晰可控。

---

四、成本與成效：數據給出了明確答案

實際執行結果顯示：

• 36 名學生，9 天內完成所有口試
• 平均每人 25 分鐘
• 每位學生成本僅 0.42 美元
• 總成本約 15 美元（人工至少 750 美元以上）

此外，團隊引入「三模型評分委員會」：

• Anthropic 的 Claude
• Google 的 Gemini
• OpenAI 的 ChatGPT

經過交叉審議後，模型間評分一致度大幅提升，證實 AI 評量是可以被校準、被監督的。

---

五、AI 口試的關鍵價值：讓教學盲點無所遁形

透過結構化拆解成績，Panos 團隊發現：

• 「實驗設計」是全班最弱的能力項目
• 無任何學生達到精通等級

這迫使教師正視一個事實：
問題不只在學生，也在課程設計本身。

更有意思的是：

• 口試時間長短與成績完全無相關
• 真正理解者，往往回答更精煉、效率更高

---

六、學生真的接受 AI 口試嗎？

調查結果相當真實：

• 多數學生仍偏好傳統筆試
• 83% 認為 AI 口試壓力更大
• 但有 70% 認同它更能檢驗真實理解程度

換言之：
學生未必喜歡，但他們知道這樣更公平。

---

結語｜AI 正在讓「真正的學習」回歸本質

Panos 的總結相當明確：

作業的時代已經結束，
回到紙筆考試只是技術上的倒退。

AI，正在讓口試重新變得可行、可規模化。

更重要的是，這套系統甚至能開放給學生反覆練習——
不是背題，而是訓練思考與表達本身。

---

給專業教育工作者的未來趨勢與實務建議

1. 評量設計應從「成果導向」轉向「推理與決策歷程導向」
2. 將 AI 視為教學診斷工具，而非單純風險來源

---

參考資料

• 原文：Fighting Fire with Fire: Scalable Personalized Oral Exams with an ElevenLabs Voice AI Agent

2026 年新年第三天，Claude Code 的創建者與負責人 Boris Cherny 進行了一場「線上示範教學」，公開他自己日常使用 Claude Code 的實戰工作流。最讓人意外的是：他的設定其實非常「素」——因為 Claude Code 開箱即用就已經很強，他更在意的是把工作流流程化、把回饋閉環做扎實，而不是花大量時間做酷炫客製化。

以下整理成一篇面向專業開發者／工程主管／技術 PM 的實務筆記：你可以把它當成一套可直接套用的「AI 程式開發作業系統」。

1) 五線並行：同時跑 5 個 Claude 視窗，提升吞吐量

Boris 會在終端機同時開 5 個 Claude 視窗（分頁標上 1～5），並開啟系統通知。當某個任務需要他補充指令或做決策時，他能立刻被提醒，不會讓工作流卡住。

為什麼這招有效（給專業人士的觀點）

• AI 寫碼常見瓶頸不是「產出速度」，而是「等待你回覆」或「等待驗證結果」。多視窗等於把等待時間攤平，提升整體 throughput。
• 特別適合：多個 feature/bug 同時推進、同時跑測試或查資料的情境。

---

2) 多端無縫衔接：終端 + 網頁 + 手機，讓任務隨時續跑

除了本地終端，他也會在網頁端同時跑 5～10 個任務，並在不同端之間切換：

• 在終端寫碼時，會用 & 把會話丟到背景跑
• 或直接在 Chrome 開新會話
• 有時用 --teleport 在終端與網頁端之間「傳送」進度
• 甚至每天早上用手機（iOS Claude App）先開幾個會話，回到電腦再看成果

實務建議

• 把「需要長時間生成 / 搜集資訊 / 進行多步推理」的任務，放到你不在電腦前也能跑的地方。
• 把「需要你頻繁介入」的任務留在終端主工作區，降低切換成本。

---

3) 全力投入 Opus 4.5：寧可大一點，也要少引導、少返工

他會把所有任務都開 Opus 4.5（含 Thinking 模式），原因是：雖然它比 Sonnet 更大、更慢，但更聰明、更會用工具，不需要你費力「教它怎麼想」，最終反而更快完成任務（因為少走彎路、少重做）。

給技術管理者的判斷框架

• 如果你的工作型態是「需求模糊、整合多工具、需要端到端驗證」，大模型常常更划算。
• 如果是「明確需求、可拆很細、測試很完整」，小模型可能就足夠且更省成本。

---

4) 共享知識庫 CLAUDE.md：把錯誤變成規則，讓團隊越用越順

他們團隊共用一份 CLAUDE.md 放在 Git repo 裡，大家每週會更新多次。只要發現 Claude 哪裡做錯，就把規則寫進 CLAUDE.md，避免下次再犯。

這其實是把「個人提示技巧」升級為「團隊制度」

• 不靠每個人私藏 prompt，而是把最佳實務變成版本化文件
• 新人加入也能快速對齊風格、規範與踩雷點

---

5) 持續複利：Code Review 時把規範沉澱回 CLAUDE.md

在 PR code review 時，他會常用 @.claude 讓 Claude 把同事 PR 中出現的規範、慣例或踩雷點，整理沉澱回 CLAUDE.md。他們也透過 /install-github-action 裝了 Claude Code 的 GitHub Action——這就是他們版本的「複利工程（Compounding Engineering）」。

專業價值

• Code review 不只是「抓錯」，更是「更新組織記憶」
• 你每修一次，就等於把未來 N 次重複錯誤的成本砍掉

---

6) 先謀定而後動：Plan 模式把方案打磨到可一波完成

大多數任務都從 Plan 模式開始（連按兩次 Shift+Tab）。如果目標是做一個 PR，他會先在 Plan 模式跟 Claude 反覆確認方案，直到覺得可行、可落地，再切換到 auto-accept edits 讓 Claude 直接「一波帶走」。

重點：不是「讓 AI 寫碼」，而是「讓 AI 先設計好」

• 設計品質決定實作品質
• 方案越清晰，後面越少來回、越少不必要的 patch

---

7) 自製 Slash Commands：把高頻內環流程封裝成命令

他會把每天重複多次的「內環工作流」封裝成 slash commands，放在 .claude/commands/ 並提交到 Git。這能減少重複輸入 prompt，也讓 Claude 直接呼叫固定流程。

例如他們每天用數十次 /commit-push-pr：用內聯 Bash 預先計算 Git 狀態等資訊，跑得很快，避免反覆對話成本。

你可以立刻照做的方向

• 把「固定步驟」交給命令：建立分支、跑格式化、跑測試、寫 commit message、推 PR、生成 changelog
• 讓 prompt 變成「工具化」而不是「口語化」

---

8) 善用子智能體 Subagents：把常見流程模組化

他常用特定 subagents：

• code-simplifier：在完成後簡化程式碼
• verify-app：端到端測試

本質上就是把 PR 中最常見的流程模組化、自動化，避免每次從零描述。

專業觀點

• Subagent 是「角色 + 任務邊界」：讓 AI 知道自己要做的是簡化、驗證、重構或安全檢查，而不是「什麼都做一點」。
• 對團隊來說也更容易對齊：每個 subagent 就是一套可被 code review 的流程。

---

9) 自動程式碼美化：用 PostToolUse Hook 補最後 10%

他們用 PostToolUse hook 做格式化。即使 Claude 寫的程式碼格式已經不錯，hook 仍能補齊最後 10% 細節，降低 CI 因格式或 lint 失敗而紅燈的機率。

---

10) 權限管理：不跳過提示，而是預先授權安全指令

他不使用 --dangerously-skip-permissions（危險跳過權限提示）。相反會用 /permissions 先授權在當前環境下安全、常用的 Bash 指令，並把設定存進 .claude/settings.json 供團隊共享。

對企業/資安更友善的做法

• 把「可執行指令範圍」明確化、版本化
• 降低意外執行破壞性操作的風險，也更容易審計

---

11) 工具全家桶：讓 Claude 真的『在幫你做事』而不是只給建議

Claude Code 會幫他操作各種工具：透過 MCP 伺服器搜尋並發 Slack 訊息、跑 bq CLI 做 BigQuery 查詢、從 Sentry 抓錯誤日誌等。Slack 的 MCP 設定放在 .mcp.json，團隊共用。

專業重點

• 真正能提升生產力的不是「AI 會寫程式」，而是「AI 會把資訊與工具串起來，減少人肉搬運」。
• 這會直接影響 MTTR（平均修復時間）、交付速度、跨部門溝通成本。

---

12) 長時間任務：驗證智能體、Stop Hook、以及降低打斷的權限策略

對耗時任務，他會：

• 完成後啟動背景智能體做驗證
• 使用 Stop hook 做確定性檢查
• 使用 ralph-wiggum 插件
  並在需要長時間不中斷輸出時，視情況使用 --permission-mode=dontAsk，或在沙盒環境使用跳過權限模式，避免被權限彈窗卡住節奏。

---

最關鍵：建立回饋閉環，品質可提升 2～3 倍

Boris 強調：要拿到高品質結果，關鍵是讓 Claude 有辦法驗證自己的工作。一旦有回饋閉環，品質能提升 2～3 倍。

例如：Claude 更新網頁端程式碼時，會透過 Chrome 插件實測每次改動——自動開瀏覽器、測 UI、迭代直到跑通且互動順暢。

驗證方式因領域而異：

• 可能是跑 Bash 腳本
• 跑測試套件
• 在模擬器跑 App
  請務必把「驗證流程」打造得足夠堅固，因為這會直接決定你能不能放心把修改交給自動化。

---

未來趨勢／實務建議（給專業人士）

1. AI 工程會從「提示技巧」走向「可版本化的流程資產」
   像 CLAUDE.md、slash commands、subagents、hooks、permissions 白名單，這些會逐漸變成新一代工程團隊的「流程基礎建設」。建議你把它們當成 repo 的一級公民：可 review、可追溯、可迭代。
2. 驗證（Testing/Observation）會成為 AI 開發效率的第一優化點
   當 AI 參與程度越高，你越需要把測試、lint、E2E、可觀測性（Sentry/Logs/Tracing）串成一條穩定的回饋管線。想提升交付速度，不要只盯模型與 prompt，優先投資在「更快、更可靠的驗證」。

---

參考資料

• 建議參考：Anthropic 官方文件（Claude、Claude Code、MCP 相關）
• 建議參考：GitHub Actions 官方文件（CI/CD 與自動化工作流）
• 建議參考：Sentry 官方文件（錯誤追蹤與可觀測性）
• 建議參考：Google BigQuery CLI（bq）官方文件（資料查詢與指令操作）
• 建議參考：端到端測試框架官方文件（例如 Playwright / Cypress，用於建立 UI 驗證閉環）

為什麼專業人士應該關注 Anthropic Interviewer？

在使用者研究、組織行為、科技政策與產品策略等專業領域中，「質性訪談」始終是不可或缺的方法。然而，傳統訪談高度依賴人力，成本高、規模受限，也難以快速反映大規模趨勢。

由 Anthropic 推出的 Anthropic Interviewer，正是為了解決這個瓶頸而生。這項研究型工具結合大型語言模型 Claude，嘗試將「深入對話」從數十人擴展到 上千名專業人士，為質性研究開啟全新尺度。

本文將以專業角度，解析 Anthropic Interviewer 的設計理念、研究發現，以及它對未來研究實務的啟示。

---

一、Anthropic Interviewer 是什麼？

AI 驅動的大規模質性訪談工具

Anthropic Interviewer 是一套 AI 輔助訪談與研究系統，其核心目標並非取代研究者，而是：

• 放大研究規模
• 提升訪談一致性
• 加速洞察產出

不同於傳統問卷調查，它採用「動態對話式訪談」，能根據受訪者的回答即時追問，保留質性研究最珍貴的「深度」。

---

二、研究設計概覽：1,250 位專業人士的深度對話

在首次公開研究中，Anthropic 使用 Interviewer 與 1,250 位專業人士進行訪談，涵蓋三大族群：

• 一般職場工作者（約 1,000 人）
• 創意工作者（約 125 人）
• 科學研究人員（約 125 人）

每位受訪者進行約 10–15 分鐘 的 AI 訪談，主題聚焦於「AI 在工作中的實際使用方式、信任程度與心理感受」。

這種規模，若以傳統人工訪談執行，幾乎不具可行性。

---

三、關鍵研究發現一：一般職場人士如何看待 AI？

效率工具，而非決策主體

多數一般職場工作者對 AI 抱持 務實且正向 的態度：

• 樂於將 重複性、行政性工作 交給 AI
• 期望 AI 協助整理資訊、加快產出
• 同時希望 最終決策權仍掌握在人類手中

這反映出一個清楚的分工想像：

AI 是「助理」，不是「老闆」。

---

四、關鍵研究發現二：創意工作者的矛盾心態

創造力放大器，還是專業認同威脅？

創意工作者對 AI 的態度明顯更為複雜：

• 多數人承認 AI 能提升效率、激發靈感
• 同時擔心過度使用 AI，會影響外界對其「專業性」的評價
• 部分受訪者出現 創作者身份焦慮

這顯示 AI 在創意領域的影響，早已超越工具層次，進入 文化與認同層面。

---

五、關鍵研究發現三：科學家期待的是「研究夥伴」

從輔助工具走向共同思考者

科學研究人員對 AI 抱持高度期待，但也最為謹慎：

• 目前主要用途：
  • 文獻整理
  • 程式除錯
  • 寫作輔助
• 未來期待 AI 能參與：
  • 假設生成
  • 實驗設計
  • 跨領域推論

然而，「可驗證性與可靠性」仍是他們是否信任 AI 的關鍵門檻。

---

六、Anthropic Interviewer 的方法論意義

Anthropic Interviewer 真正的突破，不只是技術，而是研究方法的重組：

1. AI 規模化訪談：突破人力限制
2. 人類保留詮釋權：避免黑箱結論
3. 質性與量化之間的新平衡

這種模式，對以下領域尤其具有吸引力：

• 使用者研究（UX Research）
• 組織與人資研究
• 科技政策與倫理研究
• 產品與市場洞察

---

未來趨勢與專業實務建議

1️⃣ 專業研究者需培養「AI 訪談設計能力」

未來的關鍵競爭力，將不只是「會不會訪談」，而是 能否設計出高品質、可由 AI 執行的訪談架構。

2️⃣ 質性研究將走向「大樣本 × 深對話」

Anthropic Interviewer 預示了一種新常態：

不再只是在「深度」與「規模」之間二選一。

---

參考資料

• Anthropic 官方研究文章：Introducing Anthropic Interviewer

AI 技術在軟體工程領域的競爭已不再只是「誰能寫更多程式碼」，而是誰能更有效處理複雜工程需求、提升安全性與維運效率。OpenAI 最新推出的 GPT-5.2 Codex，正是以此為核心目標，將焦點從「代碼生成」進一步推進到「真正能落地的工程生產力」。
對於工程主管、企業技術決策者與專業開發者而言，這不僅是一款工具更新，而是 AI 在軟體生命週期中的角色升級。

GPT-5.2 Codex 的實際能力與測試表現

更接近「真實工程世界」的模型

OpenAI 表示，GPT-5.2 Codex 是在 GPT-5.2 能力基礎上的強化版本，重點提升 長上下文處理、跨步驟任務穩定性、代碼重構能力、Windows 開發體驗與資安輔助能力。

測試亮點

• SWE-Bench Pro：56.4% 準確率 → 目前最佳紀錄
• Terminal-Bench 2.0：64% → 在終端編譯、部署、訓練等任務上表現領先
• 視覺理解提升：能看懂 UI、流程圖、設計稿，甚至轉成可執行原型

這代表 GPT-5.2 Codex 已不只是「寫程式碼」，而是逼近資深工程師的工作模式，能參與設計、理解系統架構與支援整體工程決策。

長上下文、跨任務推理與大型程式庫支援

從寫代碼 → 理解與維持系統

對大型專案與企業級應用而言，AI 是否能「記住足夠多資訊」至關重要。GPT-5.2 Codex 透過上下文壓縮與增強推理，使其能：

• 處理長時間、多階段任務
• 在大規模代碼庫中進行整體分析
• 跨檔案、跨模組理解依賴關係
• 支援系統重構、模組遷移、新功能擴增

更成熟的重構能力

OpenAI 特別強調：

這是一個能幫你做「工程師最不想做、但又必須做」工作的模型。

也就是：

• 提升代碼可維護性
• 降低資源消耗
• 優化效能回應
• 改善架構一致性

AI 與企業級安全：GPT-5.2 Codex 的資安能力

安全已經是核心能力，而不是附加條件

在 CTF 安全測試中，GPT-5.2 Codex 的 pass@12 表現顯著提升，並展現出：

• 輔助漏洞分析
• 支援模糊測試（Fuzzing）
• 協助修復流程
• 降低工程團隊錯漏風險

雖然 OpenAI 仍將其定位在安全「可用但受控」階段，但這已顯示 AI 在資安領域的實務價值。

實際案例

研究員 Andrew MacPherson 曾使用 GPT-5.1 Codex-Max 分析 React CVE-2025-55182 漏洞，不僅協助修復，甚至發現額外隱藏問題，顯示 AI 能協助：

• 多輪評估
• 漏洞推導與模擬
• 修復建議
• 風險降低

企業導入層面的價值與應用場景

對企業工程團隊的實際意義

GPT-5.2 Codex 將可能影響：

• DevOps 自動化
• 技術債處理速度
• 維運成本
• 產品開發週期
• 安全審核與補強效率

可用場景

• CLI、IDE 插件
• Web 與 Mobile 端
• GitHub Code Review
• API 整合
• 安全測試輔助

同時，OpenAI 也推出企業級 信任存取計畫（邀請制），特別面向防禦型資安團隊。

未來趨勢與實務建議

1️⃣ 企業應開始規劃「AI 工程工作流」
不只導入工具，而是重新設計：

• Review 流程
• 安全審核制度
• 權限控管
• 代碼品質標準
  → AI 會逐步成為標準工程角色的一部分。

2️⃣ 安全與治理將成為 AI 競爭核心
未來工程決策不再僅考慮效能與效率，而是：

• 可信度
• 可追蹤性
• 法規與合規支援
• 風險管理

參考資料

• OpenAI 官方發布

2025 年底，OpenAI 公開了一段實務的工程案例：
一支由 4 名工程師組成的團隊，在短短 28 天內完成從 0 到上線的 Sora Android App，而約 85% 的程式碼由 AI 智能體 Codex 自動生成。

這不是學術實驗、也不是概念 Demo，而是一款正式商用產品：

• 上線當日登上 Google Play Store 榜首
• 安卓用戶在 24 小時內生成超過 1,000,000 條影片
• 實現 99.9% 無崩潰率 的高品質交付

本文以工程視角全方位拆解這次 AI × 軟體開發的實際運作方式，以及對未來開發流程的深度啟示。

一、Sora Android 開發關鍵統計與成果

這次開發的核心數據如下：

指標	數值
開發期間	2025/10/08 – 2025/11/05（28 天）
開發人員	4 位工程師
AI 參與	Codex 負責約 85% 程式碼實作
Token 用量	約 50 億 tokens
內部版本交付	18 天完成
公測發布	10 天後正式上線
無崩潰率	99.9%

官方指出，他們採用的正是對所有開發者開放使用的 GPT-5.1-Codex 版本，並非內部封閉模型。

二、精簡團隊＋AI 協作：效率的真諦

在發展 Sora Android 時，OpenAI 並未如傳統擴大人力，而是選擇與 AI 密切協作。這背後反映了一個核心理念：

「添加更多工程師並不一定使專案更快完成。」
這正是 Brooks 定律（Brooks’ Law）在現代 AI 開發場景下的另一種展現。

一般情況下，工程團隊會：

• 增派人力
• 加上更多流程與同步機制

但這會提升溝通與集成成本；反而 OpenAI 反其道而行：
固定小隊 × AI 智能體 = 高密度協作效率。

三、將 Codex 當成「資深工程師」而非工具

OpenAI 將 Codex 的定位比喻為：

「剛加入但能力強大的資深工程師。」

這一定位意味著：

• 人類工程師主要負責 決策、架構、整體把控
• Codex 則負責 大部分實作、單元測試、自動修正建議

工程師給 Codex 的不是單純指令，而是：

• 專案上下文
• 架構模式
• 既有程式庫與規範

這樣 Codex 才能在大尺度任務中「知道什麼是該做的」。

四、AI 的限制：為什麼人類仍無可取代

儘管 Codex 很強，但它不能：

1. 感知實際執行狀態 — 它無法在真機上感受交互是否流暢。
2. 推測隱性規範／優雅架構 — 若無明確指示，它會選擇「能跑」而非「最潔淨」的實作方式。
3. 自行學習產品策略與使用者行為 — 需人類提供導向與框架。

因此，在開發流程中必須建立：

• 明確的 AGENTS.md 指南
• 模組化架構
• 測試與程式風格規範

才能確保 AI 產出的品質與團隊一致。

五、Codex 的強項：實作、測試與平行協作

Codex 在以下方面表現尤為突出：

✅ 大型代碼庫解析能力

因為熟悉多種語言，能快速理解現存架構與模式。

✅ 測試產出密度大

Codex 熱衷生成不同情境的測試，有益於防止回歸 Bug。

✅ 反饋效率高

CI Fail 時直接把 log 給 Codex ，它能提出修復建議。

✅ 多會話平行實驗

多個 Codex 會話可同時測試不同模組，如播放功能、搜尋、錯誤處理等。

✅ 提供設計與優化建議

在設計記憶體優化等議題時，Codex 可掃描 SDK 並提出人類未曾深入的見解。

六、先規劃再執行：AI 開發的黃金流程

OpenAI 採用了如下流程：

1. 先讓 Codex 讀懂現有系統
2. 與工程師一起制定計畫（如微型設計文件）
3. 逐步讓 Codex 執行計畫
4. 針對計畫而非代碼進行 Code Review

這種方法讓：

• 長任務可跨 session 延續
• Review 更有依據
• 出錯時可先檢查計畫再檢查執行結果

讓 AI 的「無監督運作」變得更可控。

---

七、跨平台開發的 AI 超能力

OpenAI 在 Sora Android 的開發中充分利用了：

• 已有 iOS 版本作為「語義參考」
• 同時提供 iOS 與 Android 程式碼上下文

Codex 能將：Swift 的應用邏輯 → 對應的 Kotlin 實現
這意味著：

AI 不再只是工具，而是跨平台邏輯遷移的橋樑。

八、工程師的未來新技能

這次經驗帶來的核心結論是：

AI 不會取代工程師，但會重塑工程師的工作內容

未來工程師的價值：

• 深刻理解系統架構
• 精確定義工程規範
• 與 AI 長期協作與監督
• 將注意力從打字轉向決策與品質

未來趨勢／實務建議

1. AI 協作流程制度化

• 建立 AI Friendly 的程式庫與風格規範
• 可重複的 AI 任務模板與 AGENTS.md

1. 工程師技能升級

• 從寫程式轉向架構與設計能力
• 強化測試、品質與產品感知能力

---

參考資料

• OpenAI 官方工程師部落格：How we used Codex to build Sora for Android in 28 days
  
• Ars Technica 報導摘要：How OpenAI is using GPT-5 Codex to improve the AI tool itself

OpenAI 在 2025 年 12 /12日正式推出 GPT-5.2 系列，定位為迄今最強大的「專業知識工作模型」（professional knowledge work model）。官方指出，這款模型不僅在智力與推理能力上超越前代，而且能在實際商業與科學任務中顯著提升產能與經濟價值。

對於企業用戶、金融分析師、工程師與研究人員而言，GPT-5.2 不只是更聰明，而是更像一位能直接上線產出的專業同事。

GPT-5.2 系列概覽：三種版本與推出策略

OpenAI 這次推出了三個版本：

• GPT-5.2 Instant：快速回覆與日常任務
• GPT-5.2 Thinking：深度推理與複雜工作處理
• GPT-5.2 Pro：最高品質與專業級任務

1. 專業工作能力全面提升

GPT-5.2 的定位與目標

OpenAI 明確提出 GPT-5.2 是為了「解鎖更多經濟價值」而設計，尤其是在試算表、簡報、程式碼、影像理解、長文上下文、工具調用與多步驟專案管理上有全面進步。官方強調，這些能力都是在真實、專業工作場景中實用的。

用戶效率提升實際數據

根據官方數據：

• 一般 ChatGPT Enterprise 用戶表示每天可省 40–60 分鐘
• 重度使用者每週可省 超過 10 小時
  這顯示 GPT-5.2 已開始為日常商務流程帶來經濟效益。

2. 商業與高經濟價值任務的跳躍

GDPval 測試成績（知識工作基準）

GPT-5.2 在官方 GDPval 基準測試（涵蓋 44 種職業）中：

• GPT-5.2 Thinking 在與人類專家比較中勝出或並列 70.9%
• 平均產出速度超過人類 11 倍
• 成本低於人類專家 不到 1%
  這代表它在多種知識工作任務（例如試算表、簡報等）中不僅更快，而且更具成本效益。

3. 高階金融與試算表建模能力

在投資銀行分析任務中，例如：

• 財務三表建模
• 杠杆收購（LBO）模型
  GPT-5.2 Thinking 得分 68.4%，相比 GPT-5.1 的 59.1% 有顯著提升。這意味著 GPT-5.2 在專業定量建模方面更可靠。

4. 程式語言能力：跨語言與真實場景應用

GPT-5.2 在程式能力測試中的表現如下：

• SWE-bench Verified：80%
• SWE-bench Pro（更難測試）：55.6%
  涵蓋 Python、JavaScript、TypeScript、Go，顯示模型在多語言開發與複雜前端、UI 工作上都有實質進展。

5. 長文上下文處理：接近「一篇長文分析」

GPT-5.2 在 MRCRv2 長上下文理解測試中：

• 在 256k token 上的 4-needle 版本達近 100% 正確率
  這代表它能處理超大規模文件，例如合同、研究報告與多來源內容綜合分析。

6. 視覺理解提升：不只是看圖，而是「理解結構」

GPT-5.2 在高解析度圖形與科學圖表理解上：

• 錯誤率大幅降低
• 空間與元素位置理解更準確
  例如在辨識主機板元件時，其標註與空間定位明顯優於 GPT-5.1。

7. 工具呼叫與多步驟代理任務

GPT-5.2 在工具呼叫評測中表現優異：

• Tau2-bench Telecom：98.7%
• 展現出能夠可靠進行跨系統流程、從查數據到生成結論全流程。
  實例場景：處理飛機延誤後的整套旅客服務安排，從重新訂票到特殊座位與補償安排皆可自動處理。

8. 科學與數學：切入科研前線

GPT-5.2 也將科學研究作為重點：

• 在 GPQA Diamond（研究生級問答）中，Pro 版本達 93.2%
• 在 FrontierMath（高階數學）中 First Time 破新高
  模型甚至曾提出「可經同行評審的數學證明框架」。

9. 事實準確性與安全性進展

GPT-5.2 在減少幻覺（hallucination）方面有改善，但仍需人類複核。官方也強化了敏感議題處理與年齡判斷等安全措施，以提升對話的合規性與可靠性。

未來趨勢與實務建議

1. 專業工作流程重新定義：企業與專業人士應將 GPT-5.2 視為可協同生產的「數位同事」，重新規劃工作分工。
2. 安全與合規能力逐漸成熟：在處理敏感議題與長文內容時，AI 的安全性與可靠性提升可減少人工後處理工作量。

參考資料

• Introducing GPT-5.2