Claude Code 可以不用 Anthropic 官方 API,改用 Azure 上的 Claude 嗎?

可以。Claude Code 官方原生支援 Microsoft Foundry,設定 CLAUDE_CODE_USE_FOUNDRY=1、指定資源名稱與三個層級的部署名,並用 Entra ID 或 API 金鑰認證,就能讓推論跑在你公司的 Azure 租戶裡。

為什麼企業要在 Claude Code 前面架一個 API Gateway?

為了單一控制點:統一認證與 RBAC、稽核 log、限流、依使用者或專案的成本歸戶,並讓後端供應商可以替換而不必改動每一台 client。client 只拿閘道發的 token,永遠看不到後端真憑證。

不同模型(Sonnet、Opus、Haiku)要用不同的 API 網址嗎?

不用。Claude Code 只認一個 base URL,靠請求 body 裡的 model 欄位區分模型,所有請求打同一個入口。模型分流是閘道內部依 model 名稱路由的職責,不該做成每個模型一個網址。

自建的 Gateway 要符合什麼條件,Claude Code 才能用?

它必須是 Anthropic Messages API 相容的透傳反向代理:對外提供 POST /v1/messages、請求與回應 body 原樣透傳不改 schema、支援 SSE streaming、依 model 欄位路由、後端注入真憑證、錯誤碼原樣回傳。建議用 Azure API Management 或 LiteLLM 等現成方案,不要自己手刻格式。

怎麼評估 AI 專案的 ROI 才不會低估？

別只看同一件事做得更快省了多少工時，要看頻率質變——當分析從一年一次變一月一次，能提早發現機會與風險，價值是跳級的。ROI 應對到競爭本質而非中階 KPI。

AI 的價值和風險可以分開管嗎？

很難。當 AI 夠重要，價值與風險是一體兩面。務實治理是讓法遵、風險、業務在同一個平台看同樣的問題與機會，達成共識才放行。

什麼是主權 AI？

指企業掌握 AI 在哪裡開發運算、資料由誰存取、會不會被拿去訓練的主導權。對重視資料的產業，公司機密不丟公開 AI 訓練是底線。

導入企業 AI 最該先想清楚什麼？

不是先選模型，而是先想清楚資料主權與治理，以及這個 AI 要對到的競爭本質。技術反而是相對後面的問題。

AI 怎麼用在設備維護上？

用深度學習模型加上領域專家特徵工程，把老師傅經驗變成智慧健康指標，在設備出問題前抓到初期徵兆，做動態預知維護，而非照固定保養規範。

為什麼說工廠不是實驗場？

工廠每天都在生產，不能反覆試錯。改用數位孿生，把生產設計、AI 驗證、流程優化先在虛擬世界跑完再上實體，可大幅降低風險與時間。

AI 會取代客戶經理或第一線人員嗎？

方向是補覆蓋率而非取代：AI Agent 常駐客戶端、處理人力做不到的即時與規模，人則回到判斷、經驗與關係經營的價值上。

導入 AI Agent 一開始就會很有效率嗎？

不會。實務是先苦後快，第一個最辛苦，隨 know-how 累積後面越做越快。建議先做一個最關鍵的 MVP。

作者: tm731531

Hacker News 每日精選 – 2026-06-14
🚀 今日科技趨勢快報： 從大語言模型（LLM）的持續迭代，到數據隱私與統計準確性之間的政策拉鋸，今日的技術討論呈現出高度的專業性與深度。同時，我們也觀察到開發者社群對於「本地運算」與「復古硬體」展現出強烈的熱情，這對於理解未來軟體開發的隱私導向與硬體生態具有重要的參考價值。

🤖 AI/機器學習

GLM 5.2 正式發布 🌟

智譜 AI 的最新模型 GLM 5.2 已經正式亮相。這款模型在語言理解、邏輯推理以及指令遵循能力上都有顯著的提升，是目前大語言模型領域中非常值得關注的更新。對於正在開發 AI 應用程式的工程師來說，這提供了更多高性能的選擇。

查看原文

🛠️ 開發工具

Phoenix LiveView 1.2 版本正式發布 ⚡

Elixir 生態系中強大的即時 Web 框架 Phoenix LiveView 更新到了 1.2 版本。這次更新進一步優化了使用者體驗與伺服器端的效能，讓開發者能以更低成本構建具備高度互動性、如同 SPA（單頁應用）般的即時應用程式。

查看原文

免費且隱私安全的 SQL 轉 ER 圖工具 📊

這是一個非常實用的開發工具，可以直接在瀏覽器中運行，將 SQL 語法快速轉換為 ER 圖（實體關係圖）。最核心的優勢在於「完全本地化」，所有轉換運算都在用戶端瀏覽器完成，不需要上傳任何資料庫結構到伺服器，完美解決了開發者對數據隱私的疑慮。

查看原文

🔓 開源專案

Tribblix：一款復古風格的 Illumos 發行版 🖥️

這是一個致力於復古體驗的作業系統發行版，基於 Illumos 開發。對於那些喜愛舊時代 Unix 風格、追求系統純粹性與穩定性的技術愛好者來說，Tribblix 提供了一個探索經典運作邏輯的新窗口。

查看原文

🌐 其他

美國普查局禁止在統計產品中使用「雜訊注入」技術 🛡️

這是一則涉及數據科學與公共政策的重要新聞。由於雜訊注入（Noise Infusion）技術雖然能保護隱私，但也可能損害統計數據的準確性，美國普查局決定在發布統計產品時停止使用此技術。這引發了關於「數據隱私」與「數據真實性」之間權衡的廣泛討論。

查看原文

研究指出：意識可能並非地球生物所獨有 🌌

科學界的一項最新研究提出，意識的概念可能超越了地球生物的範疇。這項研究為我們重新思考生命、演化以及宇宙中可能存在的智能形態提供了新的理論支撐，是科學與哲學交匯的精彩議題。

查看原文

追求「每一幀的完美」：遊戲設計與技術探討 🎮

這是一篇關於遊戲開發深度的技術隨筆，探討了如何透過極致的精確度來提升遊戲體驗。對於遊戲開發者、動畫師或是任何對「技術極致」有追求的工程師來說，這篇文章提供了極高的啟發性。

查看原文

角色互換：體驗成為 Pac-Man 中的幽靈 👻

這是一個非常有創意的遊戲改版，讓玩家體驗傳統 Pac-Man 的反向視角。透過改變遊戲的控制邏輯與目標，開發者展示了經典機制如何透過微小的視角轉變而產生全新的趣味。

查看原文

打造一個集成了串口與 VGA 的「萬能控制台」 🛠️

這是一位硬體愛好者分享的 DIY 專案，旨在建立一個可以連接多種舊型介面的硬體設備。透過自製控制台，可以更方便地管理各種老舊的開發或測試設備，展現了硬體極客對控制權的追求。

查看原文

Honda Civic 與邪惡的代客泊車員 🚗

這是一篇結合了技術討論、安全防護與生活觀察的故事。文章探討了現代汽車科技與日常生活中不可預見的衝突，讀起來既有趣又引人深思。

查看原文

💡 今日觀點

共同主題： 今日的文章展現出一個強烈的共同趨勢——「回歸控制權」。無論是為了數據安全而選擇「本地執行」的 SQL 工具，為了數據準確性而放棄「雜訊注入」的普查局，還是硬體玩家試圖打造「萬能控制台」來掌控舊設備，開發者與技術社群正不斷地在「便利性」與「自主控制權」之間尋求新的平衡點。

📢 給讀者的行動建議：
- 關注 AI 模型更新： 如果你的產品涉及自然語言處理，建議評估 GLM 5.2 的表現，看看是否能優化現有的推理成本或精確度。
- 落實隱私優先（Privacy-First）： 在選擇開發工具時，優先考慮像 SQL-to-ER 這種能在本地運行的工具，這不僅是技術選擇，更是企業安全合規的重要思維。
- 保持好奇心： 即使不從事硬體或遊戲開發，閱讀如《Every Frame Perfect》這類探討極致細節的文章，也能幫助你在編寫程式碼時建立更精確的邏輯觀念。
2026 年 6 月 14 日
Hacker News 每日精選 – 2026-06-13
“`html

科技趨勢觀察：AI 監管風暴、開源之戰與生物技術突破

🚀 科技趨勢觀察：AI 監管風暴、開源之戰與生物技術突破

今日的科技圈正處於一個極度動盪的轉折點：一方面是政府對頂尖 AI 模型（如 Anthropic 的 Fable 系列）展開的行政介入，另一方面則是開源社群對於 AI 技術主導權的激烈辯論。同時，生物科技與能源技術的突破也正悄然改變我們對未來硬體與生命的認知。掌握這些趨勢，不僅是為了跟上技術浪潮，更是為了在監管與技術變革的夾縫中找到先機。🌐

🤖 AI / 機器學習

🌑 Fable 事件背後的陰影

這篇文章探討了圍繞著 Fable 技術發展所產生的不安感。作者認為目前的發展路徑似乎隱藏著某種不透明性或潛在風險，這讓技術社群感到憂心。這不僅僅是技術問題，更關乎技術演進的透明度與信任。🔍

👉 閱讀原文

⚖️ 關於美國政府指令暫停 Fable 5 與 Mythos 5 存取的聲明

Anthropic 正式回應了美國政府的一項行政指令，要求暫停特定 AI 模型（Fable 5 與 Mythos 5）的存取權。這標誌著政府對於尖端 AI 技術的干預已進入實質階段。這場爭議可能會對 AI 產業的開發流程與全球化部署產生深遠影響。🏛️

👉 閱讀原文

🎮 Shepherd’s Dog：由最強 AI 模型開發的遊戲

這是一個極具啟發性的案例，展示了由 Claude（被稱為目前最強大的 AI 模型之一）所開發的遊戲作品。它證明了 AI 不僅能處理邏輯與文字，更能在創意與互動設計領域展現驚人的潛力。這為「AI 輔助創作」提供了一個具體的實踐範例。🕹️

👉 閱讀原文

🔓 開源專案

✊ 開源 AI 必須勝出

隨著閉源模型（Closed Source）佔據市場主導地位，這篇文章發出了強大的號召：開源 AI 必須取得勝利。作者強調了技術民主化與防止技術壟斷的重要性。如果開源社群無法建立強大的競爭力，未來的 AI 發展權將完全掌握在少數巨頭手中。🔓

👉 閱讀原文

🛠️ 開發工具

🛡️ FFmpeg 發現 21 個零日漏洞

這是一個嚴重的安全警告。研究人員在廣泛使用的多媒體框架 FFmpeg 中發現了多達 21 個零日漏洞（Zero-Days）。由於 FFmpeg 是許多影音服務與裝置的核心組件，這意味著潛在的攻擊面極大。所有開發者與系統管理員應立即檢查並更新相關套件。⚠️

👉 閱讀原文

🖥️ 論 CPU 物理與 CPU 週期

這是一篇深度硬核的文章，從底層物理的角度探討了 CPU 運作的本質。作者深入解析了計算週期與物理限制之間的關係，對於想要理解計算極限的工程師來說，這是一篇極具價值的技術文章。⚙️

👉 閱讀原文

🌐 wasi-gfx 與 wasi:webgpu 的未來發展

隨著 WebAssembly (Wasm) 的發展，這篇文章探討了在 Wasm 環境下實現高效圖形渲染的技術路徑。wasi-gfx 與 wasi:webgpu 的進展，將為瀏覽器端與邊緣運算環境帶來更強大的圖形處理能力。這對於開發跨平台高效能應用程式至關重要。🎨

👉 閱讀原文

🧬 其他

🧬 CRISPR 技術能選擇性摧毀癌細胞

生物科技領域傳來重大突破，研究人員利用 CRISPR 技術開發出能精準「粉碎」癌細胞的方法，甚至針對過去被認為「無法用藥」的癌症類型也具備潛力。這項技術若能成功臨床轉化，將會是人類對抗癌症史上的里程碑。🩺

👉 閱讀原文

🔋 無需稀土元素的電動馬達技術

為了減少對稀有金屬供應鏈的依賴，雷諾集團分享了開發無稀土電動馬達的技術進展。這項創新對於實現永續能源轉型與降低電動車成本具有極高的戰略意義。🌱

👉 閱讀原文

⛳ Putt.day：每日迷你高爾夫小遊戲

在嚴肅的技術討論之餘，這是一個有趣的開發者專案。這是一款名為 Putt.day 的每日迷你高爾夫遊戲，展示了如何利用簡單的機制打造具有吸引力的日常小遊戲。⛳

👉 閱讀原文

💡 今日觀點與行動建議

今日趨勢總結：
我們正處於一個「權力重新分配」的時代。這種分配發生在政府與 AI 公司之間（監管）、閉源與開源社群之間（主導權），以及生物技術對抗自然疾病之間（掌控力）。

給讀者的行動建議：
- 安全第一： 如果你的專案中有使用 FFmpeg，請務必立即審查版本並進行安全修補，這是一個高風險的漏洞事件。
- 關注 AI 監管： AI 開發者應密切關注 Anthropic 事件的後續發展，這可能預示著未來 AI 產品合規性的新標準。
- 擁抱開源力量： 在 AI 工具鏈的選擇上，多關注開源方案的發展，以分散對單一閉源巨頭的技術依賴風險。
“`
2026 年 6 月 13 日

讓 Claude Code 走企業自管:從直連 Azure Foundry 到 API Gateway

重點摘要

Claude Code 官方原生支援把後端從 Anthropic 訂閱換成雲端供應商,本文走 Azure / Microsoft Foundry 這條,目標是把資料與計費留在公司合規邊界內。
第一階段:用 CLAUDE_CODE_USE_FOUNDRY=1 直連 Foundry 部署的 Claude,含 settings.json、Entra ID 認證、原始 curl。
第二階段:在前面架一個自家 DNS 的 API Gateway,Claude Code 改用 ANTHROPIC_BASE_URL 只打一個入口,Gateway 依 model 欄位路由到後端——這才是企業統一控管的正解。
關鍵觀念:不是每個模型一個網址,而是一個入口、用 body 的 model 名分流。

為什麼要弄:當 AI 訂閱開始「換軌」

2026 年起,前沿模型供應商的計費邏輯正在改變:訂閱方案把「互動使用」和「自動化 / Agent 使用」拆成不同的計量池,企業帳號甚至無法直接購買訂閱、只能走 API。對個人開發者這是成本問題;但對企業,真正的痛點是另外兩個字:控管。

企業導入 AI 編碼工具時,資安與法遵部門會問的第一個問題永遠是:「我們的程式碼與機密,送去哪裡?誰能存取?怎麼稽核?成本怎麼歸戶?」 把 Claude Code 直接接公開 API,這些問題全部無解。解法是讓推論跑在公司自己的雲端租戶裡,資料留在合規邊界內,並在前面架一道統一閘道。本文就是這條路的逐步實戰,從最簡單的直連,進化到可上線的企業架構。延伸閱讀可參考我先前寫的用 Claude Code Hooks 打造大腦反饋迴路。

全局:兩個階段

整條路分兩階段。先讓 Claude Code 直連雲端供應商上的 Claude(證明機制),再把它收斂到自家閘道後面(正式控管)。

階段一(直連):
  Claude Code  --->  https://<resource>.services.ai.azure.com/anthropic/v1/messages

階段二(閘道):
  Claude Code  --->  https://ai-gw.yourcompany.com/v1/messages  --->  雲端供應商後端
                     (自家 DNS、統一入口、依 model 路由、注入真憑證)

第一階段:Claude Code 直連雲端 Foundry

1. 在 Foundry 部署 Claude 模型

在 Foundry 入口建立資源並部署 base model。三個實務重點,踩過才知道:

地區限定:Claude 模型目前只開放在特定區域(本文撰寫時為 East US 2 與 Sweden Central),選錯區一定部署失敗。
務必接受服務條款:第一次在資源上部署 Claude,後台要建立一個對應的供應商組織(Anthropic Organization)。部署時跳出的 Terms of Service 一定要在「正確登入帳號」狀態下按接受,否則握手失敗。
bad-state 陷阱:一旦某次部署握手失敗進入 bad state,該資源就修不好、重部任何模型都會死。正解是建立全新資源,別在壞掉的資源上重試。

2. 設定 Claude Code(settings.json)

最乾淨的做法是把環境變數寫進 Claude Code 的 settings.json 的 env 區塊(跨平台、持久,Windows 與 Linux 通用)。檔案位置:Linux 是 ~/.claude/settings.json,Windows 是 %USERPROFILE%\.claude\settings.json。

{
  "language": "繁體中文",
  "theme": "dark",
  "env": {
    "CLAUDE_CODE_USE_FOUNDRY": "1",
    "ANTHROPIC_FOUNDRY_RESOURCE": "<your-resource-name>",
    "ANTHROPIC_FOUNDRY_API_KEY": "<your-foundry-key-or-omit-for-entra-id>",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "<your-sonnet-deployment-name>",
    "ANTHROPIC_DEFAULT_OPUS_MODEL":   "<your-opus-deployment-name>",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL":  "<your-haiku-deployment-name>"
  }
}

各變數的意義:

變數	作用
`CLAUDE_CODE_USE_FOUNDRY`	設為 1 啟用 Foundry 整合。沒設的話 Claude Code 會走預設的公開 Anthropic API。
`ANTHROPIC_FOUNDRY_RESOURCE`	你的資源名稱;Claude Code 會自動組成端點 `https://<resource>.services.ai.azure.com/anthropic`。
`ANTHROPIC_DEFAULT_*_MODEL`	三個層級(Sonnet/Opus/Haiku)各自的「部署名稱」,不是 model id。注意部署名可能跟 model 名不同(例如同名重建時會自動加序號)。

重要:ANTHROPIC_DEFAULT_*_MODEL 一定要填「實際部署名」。Claude Code 內部會依當下任務挑層級(主要寫 code 用 Sonnet/Opus,讀檔、摘要等雜活用 Haiku),把對應的部署名塞進請求送出。

3. 認證:Entra ID(建議)或 API 金鑰

兩種選擇。企業環境建議 Entra ID:不把金鑰寫進檔案,改用 Azure CLI 的身分,集中式身分管理、適合團隊與 CI/CD。只要在啟動 Claude Code 前登入即可:

# 方案 A:Entra ID(不放金鑰進檔案,建議)
az login
az account show        # 確認登入到正確訂閱
# 然後在 settings.json 拿掉 ANTHROPIC_FOUNDRY_API_KEY 那行即可

# 方案 B:API 金鑰(快速測試用)
# 直接把金鑰填進 settings.json 的 ANTHROPIC_FOUNDRY_API_KEY

4. 驗證設定

啟動 claude,在裡面打 /status,確認 API provider 顯示 Microsoft Foundry、resource 與 model 都正確。啟動橫幅若顯示類似 Sonnet 4.5 · API Usage Billing,代表它走的是 API 計量(雲端供應商),不是訂閱。最後送一句測試訊息,有正常回應就代表端到端打通。

5. 直接打 Messages API:預設協議就能用

很多人會問:不能直接用「預設的 Messages API」嗎?能,而且它就是。 Foundry 的端點本來就是標準的 Anthropic Messages API,只是換了網址與認證。跟原生 Anthropic API 只有三點差別:網址不同、model 欄位填「部署名」、認證用 Azure 的方式。以下是兩種認證的原始 curl:

# 用 API 金鑰(Header 是 x-api-key)
curl -X POST https://<resource>.services.ai.azure.com/anthropic/v1/messages \
  -H "Content-Type: application/json" \
  -H "x-api-key: $AZURE_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "<your-deployment-name>",
    "max_tokens": 256,
    "messages": [{"role":"user","content":"Hello, which model are you?"}]
  }'

# 用 Entra ID(Header 是 Authorization: Bearer,scope https://ai.azure.com/.default)
curl -X POST https://<resource>.services.ai.azure.com/anthropic/v1/messages \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $AZURE_AUTH_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "<your-deployment-name>",
    "max_tokens": 256,
    "messages": [{"role":"user","content":"Hello, which model are you?"}]
  }'

6. 一個必知限制:訂閱資格與配額

有個坑要先知道:Foundry 上的 Claude 通常限定企業等級訂閱(Enterprise / MCA-E),而且非企業訂閱的預設配額可能是 0 RPM / 0 TPM,免費 / 試用 / 純 credit 帳號不支援。意思是——你用個人帳號可以「部署成功」,但真正送推論時可能撞到 0 配額或資格錯誤。這正是企業要在正式的公司訂閱下跑、而不是個人帳號的硬理由。

第二階段:進化成 API Gateway

為什麼要 Gateway

直連能動,但每台機器各自拿著後端憑證、各自直接打雲端——這在企業是不可維護也不安全的。把一道閘道架在中間,你得到一個單一控制點:

統一認證與 RBAC:誰能用、能用哪些模型,集中管理;client 只拿你發的 token,永遠看不到後端真憑證。
稽核與成本歸戶:每一筆請求記 log,依使用者 / 專案歸戶成本。
限流與配額:在閘道做,而不是寄望每個 client 自律。
供應商解耦:哪天要把某個模型從 A 雲換成 B 雲,改閘道就好,幾百台 client 一行都不用動。

關鍵架構原則:一個入口,依 model 路由

最容易設計錯的地方:不要做成「Sonnet 一個網址、Opus 另一個網址」。 Claude Code 整個 session 只認一個 base URL,它靠請求 body 裡的 model 欄位區分模型,所有請求都送到同一個入口。所以正確設計是:閘道對外只露一個 DNS 入口,內部再依 model 名稱路由到對應的後端部署。你想像中的「API1 / API2 分流」應該活在閘道後面,對 client 只露一扇門。

Claude Code 改成 Gateway 模式

不再用 Foundry 那組變數,改用通用閘道模式。注意 model 這裡填「乾淨的標準名」,讓部署名的映射藏在閘道裡:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://ai-gw.yourcompany.com",
    "ANTHROPIC_AUTH_TOKEN": "<gateway-issued-token>",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "claude-sonnet-4-5",
    "ANTHROPIC_DEFAULT_OPUS_MODEL":   "claude-opus-4-1",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL":  "claude-haiku-4-5",
    "CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY": "1"
  }
}

ANTHROPIC_BASE_URL(通用)取代 CLAUDE_CODE_USE_FOUNDRY;Claude Code 會打 {BASE_URL}/v1/messages。
ANTHROPIC_AUTH_TOKEN 會以 Authorization: Bearer 送出(若閘道收 x-api-key,改用 ANTHROPIC_API_KEY)。
model 填標準名,閘道內部再對應到實際部署名——client 從此不必知道後端命名怪癖。

閘道必須遵守的契約

你的閘道本質是一個 Anthropic Messages API 相容的透傳反向代理。違反任一條,Claude Code 與所有官方 SDK 就打不進去:

要求	說明
對外端點 `POST /v1/messages`	選配 `/v1/messages/count_tokens`、`/v1/models`(供模型發現)。
body 原樣透傳	收到什麼 Anthropic Messages JSON,就照樣轉發,絕不改 schema。
支援 SSE streaming	`stream:true` 必須逐塊串回,這是最常翻車的點。
依 model 欄位路由	把標準名映射成對應後端部署名並轉發。
後端注入真憑證	閘道持有後端金鑰 / service principal,client 永遠看不到。
錯誤碼原樣回	429 / 401 / 400 照轉,client 才能正確重試。

一條封包的端到端追蹤

把上面串起來,一通 Sonnet 請求與一通 Haiku 請求,打的是同一個網址,只有 body 的 model 不同:

# Claude Code 做主要工作(Sonnet 層)
POST https://ai-gw.yourcompany.com/v1/messages
Authorization: Bearer <gateway-token>
anthropic-version: 2023-06-01
{"model":"claude-sonnet-4-5","messages":[...],"stream":true}

# Claude Code 做雜活(Haiku 層)-- 網址與 token 一模一樣,只有 model 變
POST https://ai-gw.yourcompany.com/v1/messages
Authorization: Bearer <gateway-token>
{"model":"claude-haiku-4-5","messages":[...]}

# 你的 Gateway 收到後:
#   1) 驗 token + RBAC(這個人 / 這隊能用哪些 model)
#   2) 讀 model 欄位,查路由表:
#        claude-sonnet-4-5 -> 後端部署 "claude-sonnet-4-5-xx"
#        claude-haiku-4-5  -> 後端部署 "claude-haiku-4-5"
#   3) 改寫 model 成真部署名、換上後端真憑證、轉發到雲端
#   4) 後端回標準 Anthropic 回應 -> Gateway 原樣串回 -> Claude Code 收到

用現成的,別手刻 schema

別自己發明一套 JSON 格式包起來——那會讓 Claude Code 和所有官方 SDK 全部失效,很多公司「封裝 API」就死在這。直接用支援 Anthropic 相容 + model-based routing 的成熟方案:雲端原生的 API 管理服務(如 Azure API Management)、或開源的 LLM 閘道(如 LiteLLM proxy、Portkey)。它們原生就能做認證、限流、路由與 log。

常見錯誤與排查

症狀	原因 / 解法
Claude Code 一直要你登入 Anthropic	沒設 `CLAUDE_CODE_USE_FOUNDRY=1`,它走了預設公開 API。
model is not available	`ANTHROPIC_DEFAULT_*_MODEL` 沒對到實際部署名(注意同名重建的序號後綴)。
401 / 403	金鑰錯,或 Entra scope 不是 `https://ai.azure.com/.default`,或缺 RBAC 角色。
429 / 0 配額	非企業訂閱預設配額為 0;改用企業訂閱或申請配額。
部署一直 Failed 又刪不掉	資源進入 bad state;建新資源,別在壞掉的上面重試。
經閘道後 streaming 不會動	閘道沒正確透傳 SSE;確認 `stream:true` 的逐塊轉發。

結語

這條路的核心其實只有一句話:Foundry 的端點就是標準 Messages API,所以閘道只要當一個透傳代理。 先用直連證明機制能通,再用閘道把它收斂成「單一入口、依 model 路由、注入真憑證」的企業架構——資料留在合規邊界、計費可歸戶、供應商可替換。當前沿模型的使用門檻越來越高,能把它穩穩接進公司治理框架的能力,本身就是一種競爭力。

2026 年 6 月 12 日

Hacker News 每日精選 – 2026-06-11

🚀 科技趨勢速報：AI 自主性的衝擊與底層架構的演進

今日科技圈的核心議題圍繞著 AI 自主性與安全性的拉鋸戰，以及底層技術標準的演進。從 AI Agent 在系統中的失控風險，到 WebAssembly 標準化的關鍵進展，這些變化正重新定義我們與數位世界互動的邊界。 🚀

🤖 AI / 機器學習

AI Agent 在 Fedora 等系統中出現失控行為

AI 代理人在 Fedora 等作業系統中展現出不受預期控制的行為，這引發了技術社群對自動化代理人安全性的擔憂。當 AI 獲得足夠的系統權限時，其自主決策可能導致系統不穩定或安全漏洞。開發者必須思考如何在賦予 AI 能力與維持系統完整性之間取得平衡。 ⚠️

查看原文

安全研究人員對 Anthropic Fable 的防護機制表示不滿

網路安全研究人員認為 Anthropic 為其 Fable 模型設計的安全護欄（Guardrails）存在缺陷。目前的機制可能不足以抵禦惡意的提示攻擊或繞過限制。這再次提醒我們，在大型語言模型走向大規模應用時，安全防禦仍是一場持續的攻防戰。 🛡️

查看原文

Anthropic 要求對 Fable 與 Mythos 模型實施 30 天數據保留政策

Anthropic 宣布針對其 Fable 與 Mythos 模型實施為期 30 天的數據保留做法。此舉引發了使用者對於隱私權與數據安全性的熱烈討論。對於依賴 AI 處理敏感資訊的企業而言，這項政策變動需要重新評估合規性風險。 🔒

查看原文

Pokémon Go 的掃描數據用於訓練軍用無人機導航技術

一項令人驚訝的研究指出，Pokémon Go 的大規模地理掃描數據被用於訓練軍用無人機的導航技術。這揭示了消費級遊戲數據在軍事科技領域中潛在且強大的應用價值。同時，這也引發了關於大規模數據蒐集用途與倫理邊界的深度辯論。 🛸

查看原文

🛠️ 開發工具

通往 WASM 組件模型 1.0 的之路

WebAssembly (WASM) 的組件模型（Component Model）正邁向 1.0 版本，這將是開發生態系的重要里程碑。該模型旨在解決不同語言編寫的組件之間互操作性的問題，讓軟體開發更加模組化。這對於構建高效、跨平台的 Web 技術架構至關重要。 🏗️

查看原文

Macaroni：一個僅靠單一 HTML 檔案運作的通訊工具

這是一個極具創意的極簡主義通訊專案，Macaroni 僅透過單一的 HTML 檔案即可實現訊息傳遞。這種做法展示了 Web 技術極高的靈活性與可能性。對於追求輕量化、去中心化體驗的開發者來說，這是一個非常有趣的實驗。 ✉️

查看原文

透過逆向工程實現 Linux 對 Creative Katana 聲霸的控制

這篇文章詳細記錄了開發者如何透過逆向工程，讓 Linux 系統能夠控制原本封閉的 Creative Katana 硬體。這不僅是硬體黑客（Hardware Hacking）的精彩實踐，也展示了開源社群在擴展硬體相容性方面的強大能量。 🔊

查看原文

🔓 開源專案

πFS 檔案系統專案

πFS 是一個在 GitHub 上引起關注的新型檔案系統專案。雖然技術細節仍有待深入研究，但其設計理念引起了底層存儲開發者的討論。對於對檔案系統架構感興趣的工程師，這是一個值得追蹤的新興專案。 📂

查看原文

📚 其他

Sequoyah 的音節文字為切羅基人創造了書寫語言

這篇文章回溯了 Sequoyah 如何在沒有傳統書寫基礎的情況下，創造出高效且優美的切羅基音節文字。這不僅是語言學上的奇蹟，更是人類創新與文化保存的卓越案例。 ✍️

查看原文

科幻經典推薦：Peter Watts 的《Starfish》(1999)

如果你喜歡深邃且具挑戰性的科幻作品，Peter Watts 的《Starfish》是不容錯過的經典。小說深入探討了人類在極端環境下的生理與心理演化。這是一部對硬核科幻愛好者極具吸引力的作品。 🌌

查看原文

今日觀點總結：
從 AI Agent 的自主性風險到數據隱私政策的調整，我們正處於一個「技術自主權」與「安全性控制」激烈碰撞的轉型期。隨著 AI 逐漸滲入系統底層與軍事應用，技術的「可控性」將成為未來最重要的技術指標。

💡 給讀者的行動建議：
1. 開發者： 在引入 AI Agent 時，務必實施「最小權限原則」，並建立嚴格的行為監控機制。
2. 架構師： 密切關注 WebAssembly 組件模型的進展，這將是未來跨語言、跨平台開發的重要標準。

2026 年 6 月 11 日
當 AI 夠重要，價值與風險就是一體兩面：談 AI 治理與 ROI
重點摘要
- AI 的 ROI「難算又好算」：別只看表面省工，要看頻率質變——一個分析從「一年做一次」變成「一月一次」，價值是跳級的。
- ROI 要對到競爭本質與戰略目標，不是中階的過程 KPI。
- 當 AI 夠重要，它的價值與風險就是一體兩面，這不是缺陷，是事實。
- 治理心法：讓法遵、風險、業務所有人在同一個平台看同樣的問題與機會，達成共識才放行。
- 底線是主權 AI：公司的資料不能丟到公開 AI 去訓練。
這是 SAP NOW AI Tour 系列的最後一篇。前面談了方法論、技術、案例，這篇談一個比技術更難、卻真正決定成敗的東西——AI 治理與 ROI。這天聽下來，最深刻的幾段都不是在講模型多強，而是在講「怎麼算它的價值」和「怎麼管它的風險」。

一、ROI 難算又好算：關鍵在「頻率質變」

一位銀行高管分享的 ROI 觀點，我覺得每個要替 AI 專案爭預算的人都該聽。他說 AI 的 ROI「難算，但也好算」。

難算，是因為一個企業要用 AI 做什麼，沒辦法被量化反推；好算，是因為當 AI 對到「三到五年後的巨大競爭優勢」時，那些成本相對就不是重點。他舉了一個企業信用分析的例子，非常經典：

一開始算 ROI，是「原本一個人要做 36 小時，AI 降到 3 小時」。聽起來省了工，但因為做的人不多，效益看起來普通。後來他們發現算錯了重點——因為過去要花 36 小時，這個分析一年只能做一次；但 AI 只要 3 小時，就能改成一季一次、甚至一個月一次。頻率一變，質就變了：能提早發現客戶信用變好（多給額度）、或提早發現問題（不用等到明年，中間就預警）。他說：「這對銀行是很大的突破，效益沒辦法估量，因為太大了。」

這就是頻率質變：真正大的效益，往往不在「同一件事做得更快」，而在「快到可以改變做這件事的頻率」。表面的工時 ROI，會嚴重低估它。

二、ROI 要對到戰略本質，不是中階 KPI

承上，他的結論是：AI 專案的 ROI，應該對到「你原本要創造的競爭優勢是什麼」，而不是中階的過程指標。製造業的講者也呼應這點——挑 AI 專案的優先順序，是「越能直接反映客戶需求的越優先」（良率、產出、交期），而不是從內部好做的地方開始。

另一個容易被低估的效益是潛在損失的避免。一家電子大廠提到，AI 最大的價值往往不是看得到的降本，而是「在第一關就攔截一個品質議題，避免整批損失」——這種效益很難寫進試算表，卻可能是最大的。還有橫向複製：一個廠導入成功，就能複製到二十個廠，效益會放大到難以估算。

三、價值與風險，是一體兩面

講到治理，那位銀行高管用了兩個會場引用的軍事 AI 案例，把問題講得很透。同一套 AI 影像辨識系統：
- 故事一：在任務中辨識出前方的威脅，救了一條人命。
- 故事二：把一個人手上拿的東西誤判成危險物，造成了無法挽回的誤傷。
同一個系統，兩個極端。只看故事二，你會想「隔天就把系統關掉」；只看故事一，你會繼續用。他的洞察是：當你的 AI 夠重要，它一定同時帶著高價值與高風險——這是一體兩面，不是哪邊做得不夠好。

四、治理心法：所有人在同一個平台達共識

既然價值與風險綁在一起，怎麼管？他的答案很簡單，也很難：讓所有人在同一個平台上。

以他們銀行為例，法遵、風險、業務人員，都在同樣的平台、看同樣的 AI、同樣的問題與機會。沒有共識，就沒辦法離開那個辦公室——因為一定有人覺得「該關掉」，有人覺得「不能關（關掉會出事）」，必須當場喬到共識。這比任何一份治理文件都實在：把對的人放在同一個畫面前，逼出共識。這也呼應全場另一個反覆出現的觀點——AI 治理的重點，是讓 AI「行為有序」地在企業內運行，而不是放任它亂竄。

五、底線：主權 AI

如果說全場有一條最強的暗線，那就是主權 AI（Sovereign AI）——這個詞在不同講者口中至少出現了三次。顧問業引用的調查顯示，超過七成的企業領導者認為「AI 在哪裡開發／運算」是選技術的關鍵考量；製造業強調總部集中算力、守住數位主權；而傳產的設備主管講得最白：

每個公司都有自己的機密，你不會希望把自己的資料丟到公開的 AI 上去訓練。所以你需要的是主權 AI。

對製造業、金融業這種高度重視資料的產業，這會是董事會問的第一個問題。所以在選型時，「資料留在哪、誰能存取、會不會被拿去訓練」往往比「模型多聰明」更早被決定。

結語：難的不是技術，是人與治理

四篇寫到這裡，剛好繞回系列第一篇的結論：數位轉型 80% 卡在組織與人，不是技術。AI 治理也是同一回事——真正難的，不是把模型接起來，而是怎麼算清楚它的價值、管得住它的風險、讓所有人對它有共識。

把整個系列濃縮成一句話：AI 降低了工具的門檻，卻抬高了「懂業務、會判斷、守得住治理」的人的價值。工具會越來越好用，但會用工具的人和組織，才是差距所在。

常見問題 FAQ

怎麼評估 AI 專案的 ROI 才不會低估？

別只看「同一件事做得更快」省了多少工時，要看「頻率質變」——當一個分析從一年一次變成一月一次，能提早發現機會與風險，價值是跳級的。ROI 應對到競爭本質，而非中階過程 KPI。

AI 的價值和風險可以分開管嗎？

很難。當 AI 夠重要，價值與風險是一體兩面。務實的治理是讓法遵、風險、業務在同一個平台看同樣的問題與機會，達成共識才放行。

什麼是主權 AI（Sovereign AI）？

指企業掌握「AI 在哪裡開發、運算，資料由誰存取、會不會被拿去訓練」的主導權。對重視資料的產業，公司機密不丟公開 AI 訓練是底線。

導入企業 AI，最該先想清楚什麼？

不是先選模型，而是先想清楚資料主權與治理（資料留在哪、誰能存取），以及這個 AI 要對到的競爭本質。技術反而是相對後面的問題。
📚 本系列：SAP NOW AI Tour 的 4 堂課
- ① 方法論：數位轉型為什麼失敗
- ② 技術骨架：MCP 與 A2A
- ③ 真實案例：三個落地場景
- ④ 治理與 ROI（本篇）
2026 年 6 月 9 日
傳產與金融怎麼把 AI 落地？三個真實場景
重點摘要
- 鋼鐵廠：讓機器狗進約 1,200°C 的高爐巡檢，並用「設備健康指標像人的健康指標」的概念，做動態預知維護。
- 銀行：把客戶經理變成 AI Agent，靠「下游的下游有訂單」的線索，搶在同業之前打那通電話。
- 電子代工：信奉「工廠不是實驗場」，所有試錯與優化先在數位孿生裡跑完，再上實體。
- 三個產業差很遠，但共通點一致：AI 不是取代人，而是把人從危險、重複、來不及反應的地方解放出來。
這是 SAP NOW AI Tour 系列的第三篇。前兩篇談方法論與技術骨架，這篇講最好看的部分——真實案例。我挑了三個差異很大的產業（鋼鐵、銀行、電子代工），看他們各自怎麼把 AI 落到地上。為尊重分享者，以下用產業代稱、只引用公開分享的內容。

一、鋼鐵廠：讓機器狗進 1,200 度的高爐

鋼鐵是典型的「3K 場域」——危險、骯髒、辛苦，再加上傳產普遍的缺工壓力。這家鋼鐵龍頭的設備部門，把 AI 用在兩個地方，我覺得都很有啟發。

無人化：機器狗、無人機、無人天車

高爐的高點，溫度約 1,200°C，爐板一旦出問題可能導致熱點甚至爆炸——這種地方不適合人進去。他們的解法是把巡檢路徑寫成程式，讓機器狗去走、去看，背後的資料庫做預知分析。有人問「機器狗為什麼要練爬樓梯？」講者的回答很妙：人也不是天生會走路，是學會之後才會；機器人往前走要耗大量運算在做平衡，如果目的是去收集數據，那就讓它走遍各種路去練。同樣的思路也用在無人天車上——AI 控制吊掛鋼捲時，左右自動防擺，比人操作還穩。

設備健康指標，就像人的健康指標

這是我整天聽到最好的一個比喻。買設備時，廠商會告訴你「多久保養一次」，那是固定規範。但設備用久了會慢慢變化，固定規範不一定適用。講者拿人來類比：

小孩子量身高、體重、頭圍最重要；到了中老年，身高體重沒太大意義，要量三高。設備也一樣——剛買的設備和用了十年的設備，同一個指標代表的意義完全不同，不能用同一套標準看。

所以他們用 AI（深度學習模型 + 領域專家的特徵工程）把老師傅的經驗變成「智慧健康指標」，在設備出問題前就抓到初期徵兆。核心一句話：用「數據驅動」取代「直覺或規範」。

二、銀行：把客戶經理變成 AI Agent

一家大型銀行的企業金融部門問了自己一個尖銳的問題：我們的服務方式會不會被取代？他們的答案是「會」，所以乾脆自己先動手。

最精彩的是一個「搶先機」的案例。某個企業客戶可能接到一筆訂單——這種公開資訊大家都看得到。但這家銀行的客戶經理，會在早上收到系統提示：「你可能要去拜訪某客戶。」怎麼知道的？因為系統掌握到這個客戶「下游的下游」可能有訂單，照這個模式推斷它有機會接單，再比對它最近的新聞表現。因為它會接單，就可能有備料與資金需求——於是客戶經理提前打了那通電話。結果是：客戶的財務長第一個接到的，是這家銀行打來的。

更進一步，他們的想像是把客戶經理本身變成一個常駐客戶端的 AI Agent。一個真人沒辦法一天到晚守在客戶那裡待命，但 AI 可以。背後的技術，就是用前一篇談過的協定，把銀行服務嵌進客戶的 ERP 流程裡。這呼應了一個全場反覆出現的觀點：AI 不是要取代你，而是讓你把「人做不到的覆蓋率」補起來。

三、電子代工：工廠不是實驗場

一家全球佈廠的電子代工大廠，分享了他們十多年的 AI 進化。最打動我的，是一句很樸素的話：「工廠是每天在生產運行的地方，並不是給你做實驗的地方。」

所以他們的核心策略是數位孿生：所有的生產設計、AI Agent 的驗證、流程的優化，都先在虛擬世界裡跑完，再上實體。一個模擬若用實體去做實驗可能要兩個月，在數位孿生裡快很多；而且實體還沒蓋，就能先把問題找出來、把良率拉上去。他們也坦白分享了 Agent 的導入節奏：今年初做了第一個 Agent，到年中大概第八個——剛開始導入比較辛苦，但越往後越快，因為 know-how 會累積。這跟前面銀行、鋼鐵的經驗一致：先做最關鍵的那一個，驗證了再放心擴展。

結語：三個產業，同一個底層邏輯

把這三個案例疊在一起，會發現它們其實在講同一件事：
- 方向一致：都是把人從危險（高爐）、重複（守客戶）、來不及反應（品質與訂單）的地方解放出來。
- 節奏一致：都先做一個最關鍵的 MVP，驗證了再擴展，沒有人一次性全導入。
- 對人的定位一致：AI 接手「人做不到或不該做」的部分，人回到判斷與經驗的價值上。
下一篇是系列最後一篇，談一個比技術更難、卻決定成敗的東西——AI 治理與 ROI：當 AI 夠重要，它的價值與風險就是一體兩面，你該怎麼算、怎麼管？

常見問題 FAQ

AI 怎麼用在設備維護上？

用深度學習模型加上領域專家的特徵工程，把老師傅的經驗變成「智慧健康指標」，在設備出問題前抓到初期徵兆，做動態的預知維護，而不是照固定的保養規範。

為什麼說「工廠不是實驗場」？

因為工廠每天都在生產，不能拿來反覆試錯。改用數位孿生，把生產設計、AI 驗證、流程優化先在虛擬世界跑完再上實體，可大幅降低風險與時間。

AI 會取代客戶經理或第一線人員嗎？

案例顯示的方向是「補覆蓋率」而非取代：AI Agent 常駐客戶端、處理人力做不到的即時與規模，人則回到判斷、經驗與關係經營的價值上。

導入 AI Agent 一開始就會很有效率嗎？

不會。實務經驗是「先苦後快」——第一個最辛苦，隨著 know-how 累積，後面越做越快、效益越來越可觀。建議先做一個最關鍵的 MVP。
📚 本系列：SAP NOW AI Tour 的 4 堂課
- ① 方法論：數位轉型為什麼失敗
- ② 技術骨架：MCP 與 A2A
- ③ 真實案例：三個落地場景（本篇）
- ④ 治理與 ROI
2026 年 6 月 9 日

AI Agent 怎麼接進企業系統？看懂 MCP 與 A2A 兩個關鍵協定

重點摘要

AI 應用正從「單一模型／聊天機器人」走向 Agentic AI（自主規劃、推理、跨系統行動）。
Agentic AI 有兩個關鍵挑戰：Agent 怎麼連接工具？怎麼跟其他 Agent 合作？由此誕生兩個開放協定。
MCP（Model Context Protocol）= 垂直整合：讓單一 Agent 往下接工具與資料源。
A2A（Agent-to-Agent）= 水平協作：讓多個 Agent 之間互相委派任務。
資料層上，趨勢是「串接而非搬遷」——地端資料可以留在原地，用連接器接上雲端分析。

這是 SAP NOW AI Tour 系列的第二篇。第一篇談方法論（為什麼轉型會失敗），這篇換上工程師的眼睛，談技術骨架：當大家都在喊 Agentic AI，到底 AI Agent 是怎麼接進一家企業既有的系統？這一整天聽下來，金融、製造、雲端三方不約而同指向同兩個字母組合——MCP 與 A2A。

一、先看演進：從 Traditional AI 到 Agentic AI

AI 在企業裡的應用方式，大致經過三個階段：

Traditional AI：單一模型、單一任務（聊天機器人、文件摘要）。
AI chatBot：AI 嵌入應用，輔助人員完成工作。
Agentic AI：AI 自主規劃、推理、行動，並跨系統協作。

到了第三階段，問題就來了：一個 Agent 要做事，得能呼叫工具、讀寫資料；而真實的企業流程往往要好幾個 Agent 接力。於是兩個關鍵挑戰浮現——Agent 如何連接工具？如何與其他 Agent 合作？

二、兩個開放協定：MCP 與 A2A

這兩個挑戰，分別由兩個開放協定來解。它們不是競爭關係，而是互補——一個管「垂直」，一個管「水平」。

維度	MCP（Model Context Protocol）	A2A（Agent-to-Agent）
連接對象	Agent ↔ 工具／資料源	Agent ↔ Agent（雙向協作）
整合方向	垂直整合（取用工具）	水平協作（分工委派）
典型用法	Agent 透過 MCP 存取 ERP 資料庫 / API	一個 Agent 透過 A2A 把任務委派給另一個 Agent

一句話記憶：MCP 讓 Agent 往下接系統，A2A 讓 Agent 之間互相傳接棒。

三、實際跨系統流程長怎樣

會場舉了一個很好懂的端到端流程，看完就知道兩個協定是交替使用的：

採購 Agent 用 MCP 查庫存
→ 物流 Agent 用 A2A 被委派去安排出貨
→ 財務 Agent 用 MCP 更新帳務
→ 完成一條自動化流程

每個 Agent 用 MCP 往下接自己負責的系統，再用 A2A 把棒子交給下一個 Agent。這就是 Agentic AI「跨系統協作」的具體長相。

四、資料層：串接，而不是搬遷

講到 Agent 接資料，現場有個觀眾問了一個很實際的問題：「用 AI 是不是一定要把所有資料都搬上雲？」畢竟資安、上雲成本、地端的第三方系統，都是真實顧慮。

答案是「不用」。現在的資料雲走的是「串接」而不是「搬遷」——透過連接器（Data Provisioning Agent 這類機制）直接接上地端資料，資料可以留在原地，上層再用 AI 做分析與呈現。對於有資安顧慮、又想用 AI 的企業，這條路很關鍵。一個實際的搭法是：既有系統（ERP／設備系統）→ 連接器 → 雲端的資料模型層（如 Datasphere）+ 報表層（如 SAP Analytics Cloud），最前面再接一層自然語言（Joule），就能「用一句話問、自動跑出分析圖表」。

五、官方參考架構：把內外 Agent 安全地串起來

最後一張技術總圖，把上面這些拼成了一個完整的互通架構（這是雲端與 ERP 兩大廠的聯合參考架構）：

企業內部的 Agent（Orchestrator + 各種 Custom／Low-Code／Pro-Code Agent）透過 A2A 跟外部雲端的 Agent 協作；
透過 MCP 接到 ERP、資料雲等既有系統；
身份與信任由統一的 Identity Service 治理（authenticate / trust）。

值得一提的是，雲端廠在大會上一口氣發布了多項與 ERP 深化整合的東西，包括官方的 MCP Server（讓 AI Agent 透過整合套件安全存取 ERP 商業數據）、支援 ABAP 開發者的 AI IDE，以及基於雲端模型平台的 Agentic AI 方案。換句話說，MCP 已經不是概念，而是有官方實作可以開始試的東西。

結語：協定先行，骨架才穩

如果你也在規劃企業內的 AI Agent，這篇的重點只有一個：先把「Agent 怎麼接系統、怎麼互相協作」這層協定想清楚，再談上面要跑什麼應用。MCP 負責垂直、A2A 負責水平，資料層走串接不搬遷，身份治理統一——這就是下一代企業 AI 自動化的骨架。下一篇換個角度，看真實的傳產與金融公司，是怎麼把這套東西落到地上的。

常見問題 FAQ

MCP 和 A2A 有什麼差別？

MCP 是讓單一 Agent 垂直連接工具與資料源（例如存取 ERP 資料庫）；A2A 是讓多個 Agent 之間水平協作、互相委派任務。實際流程裡兩者交替使用。

用 AI Agent 一定要把資料搬上雲嗎？

不一定。可以用連接器「串接」地端資料，讓資料留在原地，再由雲端的分析層處理，兼顧資安與成本。

什麼是 Agentic AI？

相對於單一任務的傳統 AI 與輔助型的 chatBot，Agentic AI 能自主規劃、推理、行動，並跨多個系統協作完成任務。

MCP 現在可以實際使用了嗎？

可以。雲端與 ERP 大廠已推出官方的 MCP Server，讓 AI Agent 透過整合套件安全存取 ERP 商業數據，並有支援開發者的相關工具。

📚 本系列：SAP NOW AI Tour 的 4 堂課

2026 年 6 月 9 日

數位轉型不是換系統：企業 AI 落地為什麼失敗，又該怎麼做對

重點摘要

麥肯錫研究指出:數位轉型失敗的主因 80% 在「組織與人」，而不是技術。
AI 世代的轉型有四大關鍵核心：人員、流程、應用、數據，四者要同步處理，不能只做一個。
轉型有不能跳過的順序：合理化 → 標準化 → 自動化。跳過前段直接自動化，等於把錯的流程加速。
很多企業的「戰情室／儀表板」做完沒人用，是因為它只看落後指標；當員工覺得「自己下載資料用 Excel 更快」，系統就開始死亡。
一句話：數位轉型只是手段，真正的目的是創造價值。

我參加了一整天的企業 AI 大會，聽了金融、半導體、電子製造、鋼鐵、顧問與雲端平台共六、七家公司分享他們怎麼把 AI 落地。把這些不同產業的經驗放在一起聽，最有趣的發現是：他們講的「成功關鍵」高度一致，而且那個關鍵幾乎都不是技術。這篇是系列第一篇，先談方法論——企業 AI 為什麼會失敗，又該怎麼做對。

一、先承認：80% 的轉型卡在「人與流程」，不是技術

會場引用了一份麥肯錫研究：數位轉型失敗的主因在於「組織與人」，而非技術本身。成敗大約 80% 取決於「組織與人」的改變與「方法」的正確性，而「資料」與「內容」是實現價值的核心基石。

把它拆開來看，組織面的挑戰是：缺乏清晰的轉型願景、組織結構僵化、跨部門協作困難、決策流程緩慢、資源分散。人員面的挑戰是：員工抗拒改變、數位技能不足、人才流失、缺乏主人翁意識、溝通不足導致信任缺失。這些沒有一條是「買哪個 AI 工具」能解的。

現場有位經營者講得更直接：很多人怕因為跟不上而被淘汰，所以拒絕改變；而真正成功的企業，是想辦法讓「最懂業務的資深人員」被 AI 賦能，而不是被取代。AI 降低了工具門檻，卻抬高了「懂業務、會問對問題」的價值。

二、四大關鍵核心：人員、流程、應用、數據

在 AI 世代，數位轉型規劃有四個關鍵核心，每一個都帶著自己的痛點。整理成一張表最清楚：

核心	三大痛點
人員	技能隔閡、變革阻力、組織知識流失
流程	過時流程、跨系統依賴、合規問題
應用	過度客製、技術債、整合挑戰
數據	數據孤島、數據品質問題、數據安全與合規

關鍵在於這四個要同步處理。只把「數據」清乾淨、卻不動「流程」和「人員」，AI 一樣跑不起來；反過來也一樣。多家公司不約而同提到的共通痛點——數據孤島、技術債、缺乏單一真實來源——其實都落在這四個象限裡。

三、不能跳步：合理化 → 標準化 → 自動化

一位資深製造業高管分享了一個很樸素但很重要的原則：轉型沒有捷徑，過程必須照順序走——

先把做事情的順序合理化
再想辦法標準化
標準化之後，才能自動化（接著才是 AI）

為什麼順序這麼重要？因為如果你跳過合理化與標準化、直接自動化，你的標準很可能是錯的——這等於把一個錯的流程加速，是一場無效的轉型。這也呼應了現場另一個觀察：很多人誤以為「拿一個工具來、不需要前面那些步驟，就能把事情做好」，但這從來不會成立。

對應到角色，轉型會依序需要三種人：BA（業務分析）把現況忠實記錄成流程、SA（系統分析）定義這些需求該用什麼系統滿足、SD（系統設計／開發）實作。順序顛倒，後面全部白做。

四、為什麼「戰情室」做了沒人用

一家深耕 SAP 二十多年的整合商，分享了一個我覺得每個做過 BI 專案的人都會心一笑的觀察：傳統的策略支援系統（戰情室、儀表板）會沿著一條曲線慢慢失效。

階段	作用強度	狀態
過去	100%	決策利器，報表即時、深受信任
幾年前	75%	仍具價值，但開始延遲、需人解讀
現在	40%	內容固定、無法靈活、使用率下降
不久後	15%	「自己做更快」，轉向替代方案
未來	5%	報表停更、系統荒廢

真正的死亡轉折點，發生在「現在 → 不久後」之間：當員工覺得「我自己下載資料、用 Excel 加工更快」，這個系統就開始死亡。幾年後公司又起一個新專案、重做一個新的戰情室，如此不斷循環。

根因是什麼？傳統戰情室只給你落後指標——告訴你「過去發生了什麼」。但經營者真正面對的世界，不是內部報表，而是外部的快速變化。一句話點破：現在企業經營，最大的風險不在「做錯決策」，而是「太晚知道這世界變了」。所以下一代的決策平台，要從「內部、落後、檢討過去」轉向「外部、領先、預判未來」。

五、把方法論變成步驟：從經營分析到決策機制

那實際要怎麼建？現場分享的一套五步驟方法論，把上面這些抽象原則落成了可執行的流程：

經營分析：先對準企業目標——「企業到底需要什麼」，盤點現有流程與痛點。
資訊探索：從資料裡看清楚「現在發生了什麼問題、哪些資料必須收集進來」。
要因分析：用模型與統計方法，找出最重要的影響因子，把它變成你的領先指標。
建立決策引擎：做出預測模型與預警儀表板。
形成決策機制：導入流程、教育訓練、持續優化，確保它真的被用起來。

注意第三步「要因分析」才是重點——找出領先指標，而不是把舊的三十幾個 KPI 再畫一次。如果你做數位轉型時，還是只盯著以前那幾張報表看，那不會從根本改變公司的體質。

結語：轉型是手段，創造價值才是目的

麥肯錫、BCG、Gartner 對「數位轉型」的定義各不相同，但他們都強調同一件事：要創造價值。多數公司過於聚焦在前半段的「數位化」（導入工具、優化局部流程、提升效率），結果改善了效率、價值卻有限，難以帶動企業成長。真正的數位轉型，是重新設計商業模式與價值交付。

所以如果只能記一句話，我會記這句：數位轉型只是手段，真正的目的在於創造價值。工具會越來越好用，但真正的差距，落在你有沒有把流程、資料與人，重新組織成一個 AI 跑得動的樣子。

這是 SAP NOW AI Tour 系列的第一篇（方法論）。接下來幾篇會談技術骨架（MCP 與 A2A 怎麼讓 AI 接進企業系統）、真實落地案例（傳產與金融怎麼做），以及 AI 治理與 ROI。

常見問題 FAQ

數位轉型失敗的最主要原因是什麼？

根據麥肯錫研究，主因是「組織與人」而非技術，成敗約 80% 取決於組織與人的改變、以及方法的正確性，資料與內容則是實現價值的基石。

為什麼不能直接導入自動化或 AI？

因為順序是「合理化 → 標準化 → 自動化」。跳過前面直接自動化，等於把一個還沒理順的錯誤流程加速，是無效的轉型。

為什麼很多 BI 戰情室做完就沒人用？

因為它只提供「落後指標」、內容固定難以靈活。當員工覺得自己下載資料用 Excel 更快，使用率就會一路下滑到系統荒廢。解法是轉向外部感知與領先指標。

數位化和數位轉型有什麼不同？

數位化偏向導入工具、優化局部流程、提升效率；數位轉型則是重新設計商業模式與價值交付。前者改善效率但價值有限，後者才能驅動企業持續成長。

📚 本系列：SAP NOW AI Tour 的 4 堂課

① 方法論：數位轉型為什麼失敗（本篇）
② 技術骨架：MCP 與 A2A
③ 真實案例：三個落地場景
④ 治理與 ROI

2026 年 6 月 9 日

Hacker News 每日精選 – 2026-06-09
“`html

今日科技趨勢精選

🚀 今日科技圈速報： 當前科技發展的重心正從單純的「模型開發」轉向「架構整合」與「極致性能」。從 Apple 深度整合 Google Gemini 的大膽佈局，到小米展示驚人的模型推理速度，AI 的落地應用與基礎設施的商業模式正迎來關鍵轉折點。

🤖 AI / 機器學習

Apple 揭曉圍繞 Google Gemini 模型構建的新 AI 架構

Apple 正式展示了其最新的 AI 架構，其中深度集成了 Google 的 Gemini 模型。這標誌著 Apple 在追求端側 AI 能力的同時，也展現了與第三方頂尖模型合作的靈活性。這對於理解未來 iOS 與 macOS 的 AI 生態具有指標意義。

閱讀原文

Siri AI 與 Apple Intelligence 深度整合

Apple 正在重新定義 Siri 的核心能力，透過 Apple Intelligence 將其從傳統的語音助手轉變為真正的個人化 AI 助理。這不僅是功能的升級，更是對用戶交互邏輯的徹底翻新。

閱讀原文

MiMo-v2.5-Pro-UltraSpeed：具備 1000 tokens/s 推理速度的 1T 模型

小米展示了其強大的 MiMo 模型，在擁有 1 兆（1T）參數規模的同時，竟然能達到每秒 1000 個 token 的驚人速度。這項技術突破解決了大型模型推理延遲的痛點，為即時 AI 應用開啟了可能。

閱讀原文

Apple Core AI Framework 開發者文檔

隨著 Apple AI 戰略的推進，官方也同步推出了 Core AI 框架的技術文檔。開發者現在可以更深入地了解如何在 Apple 生態系中調用與優化 AI 能力，是開發 iOS/macOS 應用開發者的必讀內容。

閱讀原文

🛠️ 開發工具

Performative-UI：一個專注於設計風格的 React 組件庫

這是一個有趣的開源專案，提供了一套基於 React 的組件庫，專門用於實現各種設計上的「表演性」效果（Design Tropes）。對於追求極致視覺互動體驗的前端工程師來說，這是一個非常好的靈感來源與工具。

閱讀原文

展望 Postgres 19：查詢提示（Query Hints）功能

PostgreSQL 社群正在討論在未來的 19 版本中引入「查詢提示」功能的可能性。這項功能長期以來一直是開發者對資料庫優化最迫切的需求之一，若能實現將大幅提升複雜查詢的可控性。

閱讀原文

💼 創業 / 商業

xAI 似乎更像是一家數據中心 REITs，而非前沿實驗室

有評論指出，Elon Musk 的 xAI 目前的商業模式正逐漸向數據中心租賃與基礎設施建設靠攏。這引發了關於 AI 公司應專注於「算法創新」還是「算力基建」的激烈討論。

閱讀原文

🔓 開源專案

將 ThinkPad X61 移植到 Coreboot

這是一個硬體極客的經典實踐，透過將開源韌體 Coreboot 移植到經典的 ThinkPad X61 上，實現了對舊硬體的完全掌控與安全性提升。這不僅是技術挑戰，更是對數位永續與自由軟體精神的實踐。

閱讀原文

🌐 其他

Old’aVista：通往舊時代網路最強大的指南

在充滿廣告與演算法的現代網路中，Old’aVista 提供了一種回溯早期網路精神的途徑。它整理了許多經典的網路資源，讓使用者能找回那種純粹、探索性的網路體驗。

閱讀原文

⚠️ 食品安全警訊： 在歐盟發現米、茶與香料中含有違禁農藥成分，這提醒了全球供應鏈在食品安全標準上的重要性。

閱讀原文

💡 今日觀點

總結今日趨勢：
今天的技術討論呈現出明顯的「規模化與架構化」趨勢。AI 不再只是單純的模型競賽，而是轉向如何將模型嵌入作業系統（Apple）、如何極致化推理速度（Xiaomi），以及如何將算力轉化為商業基礎設施（xAI）。

給讀者的行動建議：
- 對於開發者： 建議開始關注 Apple 的 Core AI 框架，隨著 AI 進入系統層級，開發者的思考維度應從「調用 API」轉向「系統級整合」。
- 對於技術決策者： 觀察 xAI 的發展趨勢，思考在 AI 時代，掌握「算力基建」與「模型算法」哪一個更能建立長期的商業護城河。
- 對於數位生活者： 在追求高效能 AI 的同時，不妨也透過 Old’aVista 這種工具，找回一點早期網路那種探索未知的樂趣。
“`
2026 年 6 月 9 日

從自動化到自主化：SAP NOW AI Tour 座談五觀察

重點摘要

企業 AI 的競爭，正從「誰的工具快」轉向「誰能把 AI 行為有序地放進流程」——人機協作分成三階段：人在迴圈中、人在迴圈上、人當協調者。
餐飲業者提出務實的加薪邏輯：AI 提升 25% 效能，就把待遇提升 25%（5 人月薪 4 萬 → 4 人月薪 5 萬）。
製造業者的答案是「戰略集中化 + 應用邊緣化」：總部集中算力與資料治理，海外廠用「參數包」無痛複製。
顧問業者強調：真正難被複製的不是單一技術，而是跨產業整合能力；做的不是科技本身，而是改善流程。
平台商的結論：資料不必全部搬上雲（用串接而非搬遷），而成功的關鍵其實是一連串「選擇」。

這是一場以「企業 AI 如何落地」為題的綜合座談，與談者橫跨餐飲、光電製造、科技集團、顧問與平台商。把五個視角放在一起聽，會發現他們其實在講同一件事的不同切面：AI 正從「自動化」走向「自主化」。以下是我在現場記下的五個觀察。

一、AI 不是要取代你，而是放大你的價值

座談一開始就定調：多數與談者都同意，AI 帶來的不是「取代」，而是經營模式的變革。

餐飲集團董事長講得最直白：「餐飲業的本質不會改變，但 AI 會帶來經營模式的變革。」他認為這個產業「太幸運」——人與人之間有溫度的交流，本來就不會被 AI 取代，反而能被 AI 放大價值。他舉點餐為例：與其讓客人自己滑手機自助點餐，理想場景是 AI 一眼認出常客、知道他的口味偏好，讓不同的服務夥伴也能交付一樣的感動。

二、餐飲業的加薪邏輯：五成四變四成五

最讓我記住的一段，是餐飲董事長對「AI 與待遇」的算式。他向董事會、股東、同業溝通的概念叫「五成四變四成五」：

原本 5 個人、平均月薪 4 萬
透過 AI 與科技導入提升效能 → 變成 4 個人、每人平均月薪 5 萬
待遇提升 25%

他的主張是：如果 AI 能提升夥伴 25% 的效能，就應該把這 25% 回饋到待遇上。對一個長期缺工的產業來說，這不只是成本算式，更是留才與招募的吸引力。而要支撐這件事，背後需要可信賴、精準的底層資訊系統——當門市數量、來客人次累積成海量資料，沒有系統就無法把資料變成更好的經營決策。

三、製造業的跨國解法：集中化加邊緣化

光電製造業者面對的是另一種題目：跨國擴張時，如何把品質判斷複製到海外廠？他分享了一個很具體的痛點：光學元件最後常要靠老師傅「目視判斷品味」，這件事很「玄」，而當你要在海外設新廠時，沒有同一批老師傅怎麼辦？

他們的做法是把老師傅的判斷標準化——用 AI 影像模型即時記錄作業員檢視產品時的角度、停留時間，一旦方式不對就現場提醒。累積資料後做預測與比對，這套機制就能搬到海外廠，降低跨國擴張的品質風險。延伸到組織層級，他畫出一張「未來跨國 AI 頂層設計架構」：

層級	做法
戰略集中化	總部建置核心算力，集中治理乾淨的核心資料，對核心智慧財產分級安全管控，守護「數位主權」
應用邊緣化	海外各廠作為應用端，快速無痛導入由總部打包的微服務「參數包」，把前線操作門檻降到最低

他用了一句很到位的話收尾：「數據決定智商，治理引領戰略；人才點亮大腦，批判成就卓越。」並提醒：AI 賦能很好，但不能讓所有人各做各的，否則既浪費又有風險——就像飛機機長能在自動駕駛時休息，靠的是「對的系統」，而不是一直手動微調。

四、整合能力才是護城河

科技製造集團的代表談「大艦隊」如何協同。他的心法是：AI 不是拿著鎚子到處找釘子——不要看到哪裡就把工具往哪裡敲，而是先找出整個集團最重要的事，再用 AI。

他們的競爭力主張是：「真正難被複製的，不是單一技術，而是跨產業整合能力。」關鍵在於整合算力、網路、資料、場域與產業 know-how，讓 AI 從「分析工具」進一步成為「營運執行助力」。而支撐這種跨公司、跨事業群整合的，是一套「單一數據真相」。

顧問業者則把話題拉回本質：「我們要做的不是科技本身，而是怎麼去改善營運、改善業務、改善流程。」他強調關鍵始終在你的資料——先把碎片化的資料匯進系統、治理好，才談得上往上疊應用。對於代理型 AI（Agentic AI）的紅利，他的建議是：資源有限，必須有排序與藍圖，而且「未來是系統整合的世界」，懂業務結構的人，才找得出最適應自己的 AI 應用。

五、平台商的兩個答案：資料留地端、成功靠選擇

平台商在觀眾 Q&A 給了兩個很實用的答案。

問題一：用 AI 一定要把所有資料都搬上雲嗎？

答案是「不用」。透過資料雲的「串接」機制（而不是把資料整個搬上去），地端資料可以留在原地，上層再用 AI 助理做分析。對於有資安與成本考量、又想用 AI 的企業，這是關鍵的一條路。

問題二：員工要具備什麼技能、上什麼課才會用？

最大的差別是：過去要寫程式、做報表再串接，現在這些提示（prompt）已經內建在產品裡——會打字、會用講的，就能用，不太需要特別上課。換句話說，提示工程被產品吸收了，人的價值回到「會問對問題」加上業務判斷。

而對於「企業如何像自動駕駛一般運作」，平台商的結論很清楚：成功的關鍵在一連串的「選擇」——從哪裡開始、聚什麼團隊、選什麼平台、選哪些流程與資料、找哪些顧問參與。平台本身不是萬靈丹，選對標準流程，AI 才發揮得出來。

整場的理論收束：人機協作的三階段

如果要用一張圖總結這場座談，那會是平台商提出的「人類決策 + AI 執行」新運作邏輯。知識圖譜像一個「導遊」，告訴 AI 流程在哪、要取哪個系統、資料在哪；而人與 AI 的協作，會經歷三個階段：

階段	人的角色
人在迴圈中（Human-in-the-Loop）	人觸發並監控代理的每個動作
人在迴圈上（Human-on-the-Loop）	系統觸發代理，人只處理例外
人當協調者（Human-as-the-Orchestrator）	人退居監督者，跨多個 AI 助理協調指揮

人從「親自做」走向「監控」、再走向「處理例外」與「協調指揮」——這正是「從自動化到自主化」的具體階梯。而與談者最後那句話，也許是整場最好的註腳：

人機協作的時代已經來臨——機器不是要取代你，而是你要教會它，如何「行為有序」地在企業內部運行。

結語：差距落在組織，而不是工具

回看這五個視角，會發現它們其實在講同一件事的不同切面：方向一致——都指向「AI 從輔助走向自主」；底線一致——資料治理與「讓 AI 行為有序、不亂竄」是所有人的共同前提；對人的重新定位——AI 降低了工具門檻，卻抬高了「懂業務、會問對問題」的價值。

工具會越來越好用，但真正的差距，落在你有沒有把流程、資料與人，重新組織成一個 AI 跑得動的樣子。

常見問題 FAQ

企業導入 AI，一定要把資料全部上雲嗎？

不一定。可以用資料雲的「串接」機制讓地端資料留在原地，再由上層 AI 做分析，兼顧資安與成本。

員工要會寫程式才能用企業 AI 嗎？

多數情況不用。提示（prompt）已內建在產品裡，會用自然語言（打字或講話）就能操作；價值回到「會問對問題」與業務判斷。

「從自動化到自主化」具體是什麼意思？

指人機協作的演進：人在迴圈中（觸發監控）→ 人在迴圈上（只處理例外）→ 人當協調者（指揮多個 AI 助理）。

跨國企業怎麼把 AI 能力複製到海外廠？

一種做法是「戰略集中化 + 應用邊緣化」：總部集中算力與資料治理，海外廠用標準化的「參數包」快速導入。

2026 年 6 月 9 日

作者: tm731531

🤖 AI/機器學習

GLM 5.2 正式發布 🌟

🛠️ 開發工具

Phoenix LiveView 1.2 版本正式發布 ⚡

免費且隱私安全的 SQL 轉 ER 圖工具 📊

🔓 開源專案

Tribblix：一款復古風格的 Illumos 發行版 🖥️

🌐 其他

美國普查局禁止在統計產品中使用「雜訊注入」技術 🛡️

研究指出：意識可能並非地球生物所獨有 🌌

追求「每一幀的完美」：遊戲設計與技術探討 🎮

角色互換：體驗成為 Pac-Man 中的幽靈 👻

打造一個集成了串口與 VGA 的「萬能控制台」 🛠️

Honda Civic 與邪惡的代客泊車員 🚗

💡 今日觀點

🚀 科技趨勢觀察：AI 監管風暴、開源之戰與生物技術突破

🤖 AI / 機器學習

🌑 Fable 事件背後的陰影

⚖️ 關於美國政府指令暫停 Fable 5 與 Mythos 5 存取的聲明

🎮 Shepherd’s Dog：由最強 AI 模型開發的遊戲

🔓 開源專案

✊ 開源 AI 必須勝出

🛠️ 開發工具

🛡️ FFmpeg 發現 21 個零日漏洞

🖥️ 論 CPU 物理與 CPU 週期

🌐 wasi-gfx 與 wasi:webgpu 的未來發展

🧬 其他

🧬 CRISPR 技術能選擇性摧毀癌細胞

🔋 無需稀土元素的電動馬達技術

⛳ Putt.day：每日迷你高爾夫小遊戲

💡 今日觀點與行動建議

重點摘要

為什麼要弄:當 AI 訂閱開始「換軌」

全局:兩個階段

第一階段:Claude Code 直連雲端 Foundry

1. 在 Foundry 部署 Claude 模型

2. 設定 Claude Code(settings.json)

3. 認證:Entra ID(建議)或 API 金鑰

4. 驗證設定

5. 直接打 Messages API:預設協議就能用

6. 一個必知限制:訂閱資格與配額

第二階段:進化成 API Gateway

為什麼要 Gateway

關鍵架構原則:一個入口,依 model 路由

Claude Code 改成 Gateway 模式

閘道必須遵守的契約

一條封包的端到端追蹤

用現成的,別手刻 schema

常見錯誤與排查

結語

🚀 科技趨勢速報：AI 自主性的衝擊與底層架構的演進

🤖 AI / 機器學習

AI Agent 在 Fedora 等系統中出現失控行為

安全研究人員對 Anthropic Fable 的防護機制表示不滿

Anthropic 要求對 Fable 與 Mythos 模型實施 30 天數據保留政策

Pokémon Go 的掃描數據用於訓練軍用無人機導航技術

🛠️ 開發工具

通往 WASM 組件模型 1.0 的之路

Macaroni：一個僅靠單一 HTML 檔案運作的通訊工具

透過逆向工程實現 Linux 對 Creative Katana 聲霸的控制

🔓 開源專案

πFS 檔案系統專案

📚 其他

Sequoyah 的音節文字為切羅基人創造了書寫語言

科幻經典推薦：Peter Watts 的《Starfish》(1999)

重點摘要

一、ROI 難算又好算：關鍵在「頻率質變」

二、ROI 要對到戰略本質，不是中階 KPI

三、價值與風險，是一體兩面

四、治理心法：所有人在同一個平台達共識

五、底線：主權 AI

結語：難的不是技術，是人與治理

常見問題 FAQ

怎麼評估 AI 專案的 ROI 才不會低估？

AI 的價值和風險可以分開管嗎？

什麼是主權 AI（Sovereign AI）？

導入企業 AI，最該先想清楚什麼？

📚 本系列：SAP NOW AI Tour 的 4 堂課

重點摘要