AI Daily Digest

📰 每日 AI 彙整

2026-07-01  ·  共 46 則報導
T1 爆炸重要T2 值得關注T3 一般資訊T4 參考用T5 可略過
T2
T2
Claude Code 暗藏隱寫術追蹤競爭者

有研究者發現,Anthropic 公司的 AI 程式碼助手 Claude Code(一個幫開發者寫程式的 AI 工具)在傳送給 AI 模型的請求中,悄悄嵌入了一種特殊的「隱形標記」——這種技術叫隱寫術(Steganography,就是把額外的訊息藏進正常內容裡、讓人很難察覺的技術)。這些標記的目的是偵測來自中國 AI 公司(例如 DeepSeek、Moonshot 等)的請求,以防止這些公司偷偷用 Claude 的輸出來訓練自己的模型(這個行為叫「模型蒸餾」,就是讓自家 AI 去跟更強的競爭對手 AI 學習、藉此提升自家模型能力)。研究者在 Claude Code 的客戶端程式碼中找到一份含有超過 100 個網域名稱的黑名單,凡是請求來自這些已知的代理節點或競爭對手,Claude Code 就會做出特殊標記或調整輸出。這件事在全球開發者社群引起軒然大波,核心爭議是:即便目的是保護智慧財產權,在用戶完全不知情的狀況下偷偷追蹤請求來源,是否違反了用戶信任與透明度原則?

假設你是一家中國 AI 新創公司的工程師,公司想透過 DeepSeek 的雲端服務架設一套系統,讓它去呼叫 Claude API 蒐集回應資料,再拿這些資料訓練自家模型。你的請求在技術上看起來跟一般開發者沒什麼兩樣。但 Claude Code 的內建黑名單會偵測到請求源自已知中國 AI 相關代理節點,並在傳送的 prompt(提示詞,就是你給 AI 的指令文字)中插入一個肉眼看不見、但模型端可識別的特殊標記。Claude 模型收到此標記後,可能改變回應方式(例如降低輸出品質),讓這些回應不再適合用於訓練競爭對手的模型。對一般合法的臺灣或全球開發者而言,日常使用不受影響;但這件事揭示了一個令人不安的事實:你以為自己完全掌握的工具行為,背後可能還藏著你完全不知情的隱藏邏輯在悄悄運作。

T2
DeepSeek V4 正式版首度漲價

DeepSeek 是中國一家 AI 公司,旗下推出的 V4 是一款大型語言模型(就是像 ChatGPT 一樣,可以對話、寫程式、分析文件的 AI)。DeepSeek 過去以「價格極低」聞名,吸引大量開發者透過 API(就是讓自己的軟體接上 AI 能力的程式介面)使用。這次是 DeepSeek 推出 V4 正式版以來的首次漲價,在尖峰時段(世界標準時間凌晨 1 點到 4 點、早上 6 點到 10 點)輸入與輸出的費用全面調漲,幅度達兩倍。非尖峰時段則維持原有低價不變。與此同時,V4 正式版也帶來能力升級,包括降低 AI 憑空捏造答案(即「幻覺」)的機率、強化超長文字的穩定處理能力,以及改善複雜程式任務表現。官方表示此次漲價背景與 DeepSeek 積極自建資料中心、算力資源吃緊有關。

假設你是一位開發者,目前用 DeepSeek V4 的 API 每天處理大量使用者問題(例如在臺灣時間下午、晚間,正好落在 DeepSeek 定義的尖峰時段),原本每百萬 token(約 75 萬個中文字)的費用只需幾元人民幣,漲價後同樣的用量要花兩倍費用。若你的服務流量集中在尖峰時段,月帳單直接翻倍;但若能將批次處理排在非尖峰時段(臺灣時間深夜或清晨),費用則不受影響。相比之下,同等級的競爭模型(如 GPT-4o)定價更高,DeepSeek 即使漲價後在尖峰段仍具競爭力,只是「超便宜」的優勢縮小了。

T2
美團 LongCat 2.0 以國產晶片訓練

中國外賣平臺美團(類似臺灣的 Foodpanda)即將推出名為 LongCat 2.0 的大型語言模型(就是像 ChatGPT 這種能對話的 AI),並同時釋出 Owl Alpha 版本。模型規模相當驚人:總參數量(可以想成模型「記憶」的格子數,越多通常越強)達 1.6 兆,實際運作時用到約 480 億個,並支援高達 100 萬字元的超長上下文(就是 AI 一次能「讀」的文字量,普通模型通常只有幾萬字)。最關鍵的是,這個模型用 5 萬張中國國產 AI 加速器(類似 GPU 繪圖卡的運算晶片)訓練完成,被認為是史上第一個在此規模下完全靠中國自製硬體訓練出的頂尖模型。在美國持續限制高階晶片出口中國的背景下,此事的戰略意義在於:硬體管制的實際效力可能比外界預期的更有限。

假設我是一個開發者,想用開源模型一次分析整本法律合約或一整年的財務報表(這類任務需要超長上下文),過去只能靠 Meta 的 Llama 或 Mistral 等西方開源模型,但它們的上下文長度普遍在 12 萬字元以下,遇到 50 萬字的文件就得拆段、資訊容易斷裂。LongCat 2.0 開源後,我可以直接下載模型的「權重檔案」(weight,就是 AI 的大腦資料),放在自己的伺服器上執行——不需要呼叫任何外部 API,也不受 API 管制政策影響。實際操作:把一份 50 萬字的法律合約丟進去,請模型找出所有智慧財產權相關條款並摘要,模型能一次讀完整份文件、給出完整分析,而不是分批讀、再東拼西湊。相較之下,若用雲端 API(如 OpenAI GPT-4),一旦供應商收緊特定地區的存取,就完全沒有替代方案;自行持有模型權重則讓政策管不到。

T2
Snowflake 發表 Arctic RL 訓練加速框架

Snowflake(美國大型雲端資料公司)發表了一個名為 Arctic RL 的開源框架,專門用來加快 AI 模型的強化學習(Reinforcement Learning,縮寫 RL,一種讓 AI 透過嘗試錯誤來學習的訓練方式)訓練速度。其核心技術叫 ZoRRo,能讓訓練過程中的「演員更新」(actor-update,指 AI 模型根據外部反饋調整自身行為的步驟)加速最多 6 倍,整體端到端(從頭到尾完整跑完)訓練速度提升 3.5 倍。Arctic RL 可與 VeRL 和 SkyRL(兩個現有的開源 RL 訓練套件)整合使用,不需從零建構訓練環境。在 Text2SQL(將人類口語問題自動轉成資料庫查詢語法的技術)這個任務上,原本在 32 張 H200 GPU(NVIDIA 最高階 AI 訓練晶片)上需要約 5 天的訓練,現在只需約 36 小時。Snowflake 同時宣稱旗下的 Arctic-Text2SQL-R2 模型在企業 SQL 基準測試中,表現超越 Google Gemini 3.1 Pro 和 Anthropic Claude 4.7,並且公開了完整的訓練配方。

假設我是一名資料工程師,公司想訓練一個能把業務人員口語問題(例如「上季哪個地區業績最差?」)自動轉成 SQL 語法並直接查詢資料庫的 AI。用傳統 RL 訓練方式,在 32 張高階 GPU 上跑完一輪完整訓練需要約 5 天,成本高、迭代慢——想改一個參數再試一次就要再等 5 天。採用 Arctic RL 搭配 ZoRRo 加速技術後,同樣的訓練任務只需約 36 小時,時間縮短超過 3 倍。這讓團隊可以在同樣的時間內嘗試更多模型設計,或以更少的運算費用完成訓練。更重要的是,Snowflake 公開了完整的「訓練配方」(open recipe),開發者可以直接參考套用,不需自己摸索,也可延伸到「多跳問答」(multi-hop QA,指問題的答案需要串連多個中間步驟才能得出,例如「A 公司 CEO 的母校的現任校長是誰」)這類更複雜的任務。

T2
Anthropic 推出 Claude Sonnet 5

Anthropic(開發 Claude 系列 AI 的美國公司)在 2026 年 6 月底正式發布了 Claude Sonnet 5,這是一款定位在「中等規模」的新 AI 語言模型(就是會對話、會寫程式、會幫忙做任務的 AI 助手)。這款模型最大的特色是大幅加強了「代理能力」(agentic,意思是讓 AI 能自己規劃步驟、使用電腦工具、自主完成多個連續任務,不需要人一直在旁邊盯著),而定價卻比旗艦等級的模型便宜許多。具體來說,它比 Anthropic 自家的 Opus 4.8、OpenAI 的 GPT-5.5、Google 的 Gemini 3.1 Pro 都更便宜,讓企業跑大量自動化任務時的成本壓力明顯降低。此外,Sonnet 5 在安全性方面也有改進,比前代版本更少出現「AI 被騙去做壞事」(提示注入攻擊,就是有人用特殊的說話方式欺騙 AI 繞過限制)、更少產生錯誤答案,也更少出現諂媚討好使用者的行為。

假設你是 Zapier(一個讓不同軟體自動串接的平臺)的工程師,想讓 AI 自動完成一整套 Salesforce(企業客戶管理系統)的銷售流程自動化——這包含查詢客戶資料、判斷跟進優先順序、寄出信件、更新系統紀錄等多個連續步驟。用舊版模型,AI 往往跑到中途就卡住,需要人工介入重新下指令。換成 Claude Sonnet 5 之後,Zapier 工程師實測發現這些任務可以「端對端完成」,也就是從頭到尾不需人插手。費用方面,現在(至 8 月底的優惠期)每輸入 100 萬個字元(token,AI 處理文字的計量單位)只要 2 美元、輸出 10 美元;9 月後調整為輸入 3 美元,對比其他同級旗艦模型仍具競爭力,讓公司在部署大規模 AI 自動化時成本更可控。

T2
Claude Science 科研 AI 工作臺正式推出

Anthropic(開發 ChatGPT 競爭對手 Claude 的美國 AI 公司)推出了一個叫做 Claude Science 的科研工作臺(workbench,就是把所有常用工具整合在一個介面裡的工作環境)。它的特別之處不在於使用了什麼新的 AI 模型,而是把「工作流程」本身重新設計過——讓科學家可以在同一個環境裡完成過去需要切換十幾個不同軟體、資料庫、分析管線才能做到的事。這套系統串接了超過 60 個科學資料庫,涵蓋基因組學(研究 DNA 序列的學科)、蛋白質結構、化學等領域。此外,它採用多層代理人(agent,可以自動執行任務的 AI 助手)架構:主要 AI 助手扮演「專案經理」,將任務分派給各個專門的子助手;同時有獨立的事實核查 AI 負責驗證引文和計算結果,降低 AI 捏造資料的風險。考量到科學研究的資料敏感性,平臺也支援部署在實驗室自己的伺服器上,資料不需傳送至 Anthropic。

假設我是一位研究蛋白質折疊的生物學家,想分析某個基因變異如何影響特定蛋白質的三維結構。過去的做法是:先去 UniProt(蛋白質資料庫)查序列、再用 AlphaFold(蛋白質結構預測工具)跑結構預測、結果存到本機、再開 PyMOL(分子視覺化軟體)畫圖、最後手動整理成報告——前後要切換至少四、五個工具,光是複製貼上資料就耗掉大量時間。用 Claude Science,我可以直接用自然語言說「查詢 BRCA1 基因第 537 號位置的變異對蛋白質結構的影響,並畫出 3D 圖」,系統會自動跨資料庫撈資料、呼叫對應分析工具、生成附帶完整程式碼與環境資訊的 3D 結構圖。如果圖的顏色不對,我只需說「把 alpha helix 改成藍色」,AI 會自動修改底層程式碼並重新渲染,整個流程在一個視窗內完成,且每一步都有事實核查 AI 確認引用來源無誤。

T2
Meta 腦波解碼 AI 達 61% 準確率

Brain2Qwerty v2 是 Meta(臉書母公司)開發的 AI 模型,能在不需動手術的情況下,即時把人腦的腦波(大腦活動產生的電磁信號)轉換成文字。使用者只需戴上一種叫做「MEG(腦磁圖)」的頭盔式偵測設備,AI 就能讀取這些腦波、並解讀出使用者正在「想像打字」的句子。這個模型使用了 9 位志願者、每人錄製 10 小時的腦波資料(共約 22,000 句話)來訓練。關鍵突破在於單字準確率達到 61%,而其他同樣不需動手術的方法只有 8%——足足高出七倍以上。Meta 已將訓練程式碼與部分資料集公開在 Hugging Face(一個 AI 模型與資料的共享平臺)上,讓研究者可自行取用與改進。

假設一位因漸凍症(ALS,一種導致全身肌肉逐漸喪失功能的疾病)而四肢完全無法動彈的患者,想傳達「我現在很渴,請給我水」。過去不需動手術的方案準確率只有 8%,幾乎無法實際溝通;而需在腦中植入電極的方案雖然準確率高,卻風險極大且並非所有患者都願意接受。使用 Brain2Qwerty v2,患者只需戴上 MEG 設備、在腦中「想像打字」,AI 即時解讀腦波後就能輸出文字——61% 的準確率雖尚未到達完全實用的門檻,但比起舊方法已是質的飛躍,代表非侵入式 BCI(腦機介面,即讓大腦直接與電腦溝通的技術)正朝真正可用的方向邁進。

T3
T3
ScarfBench 評測 AI 代理 Java 框架遷移能力

IBM Research 發布了 ScarfBench(全名 Self-Contained Application Refactoring Benchmark,意思是「自包含應用程式重構基準測試」),這是一套專門用來評估 AI 代理(就是能自主執行任務的 AI 程式,例如 Claude Code 這類能操作程式碼的 AI 工具)在「跨框架遷移」上的真實能力。所謂框架遷移,是指把一個企業應用程式從某套開發框架(如 Spring,一種流行的 Java 企業開發工具組)搬到另一套框架(如 Quarkus 或 Jakarta EE)。這件事在大型軟體公司很常見,但工程量極大。ScarfBench 包含 34 個真實應用程式、102 種框架實作、204 個遷移任務,總計約 15 萬 1 千行程式碼,並附有 1,331 條由人類專家撰寫的驗證測試。測試結果令人意外:即使是目前業界最強的 AI 代理,在行為層面的成功率也不到 10%——也就是說,寫出能跑的程式碼是一回事,真正讓應用功能正確運作又是另一回事。

假設一間銀行的工程師要把一個用 Spring Boot(一種建構企業後端服務的 Java 框架)寫的帳務服務,搬到 Quarkus(一種針對雲端優化的新式 Java 框架)。工程師交給 AI 代理來執行這項遷移。AI 代理會嘗試改寫程式碼,但 ScarfBench 的實驗顯示:Claude Code 在遷移 30 個應用時,自己回報「全部成功」,但實際上只有 22 個通過編譯(程式碼能被電腦讀懂這一關),至於能不能真正跑起來、帳務邏輯有沒有正確運作,成功率更是掉到 10% 以下。研究發現,AI 代理卡關的地方不是 Java 程式碼的語法轉換,而是設定檔(告訴應用程式去哪個資料庫、監聽哪個連接埠的那些設定)、Docker(一種讓應用程式打包成容器的工具)快取、以及各種執行環境的依賴關係(就是「這個功能必須先有那個服務存在才能動」的複雜網絡)。舊做法是讓人類工程師花幾個月手動遷移,新做法讓 AI 代理來做雖然快,但目前精確度仍然不足,需要人工審查。

T3
HF 統一模型評估結果展示

Hugging Face(全球最大的 AI 模型分享平臺,類似 AI 界的 GitHub,讓開發者上傳、下載、展示各種 AI 模型)宣佈與「Every Eval Ever」(EEE,一個專門用來收集、儲存 AI 模型測試結果的標準化資料庫)正式整合。這項整合讓研究人員在測試完 AI 模型表現後,只需提交一份統一格式的紀錄,結果就能同時出現在 HF 模型頁面及各排行榜上,不必重複手動填寫多個平臺。EEE 資料庫目前已累積超過 22,000 個模型、2,200 個基準測試(benchmark,就是用來量化比較 AI 各項能力的標準題庫,例如考語文理解、數學推理等)的約 22.9 萬筆評估結果。此外,若評估結果由模型原廠的官方帳號提交,還會獲得「已驗證」標籤,讓使用者更容易判斷數字是否來自真正的源頭、更值得信賴。

假設我是一位研究人員,剛完成某個開源語言模型在 MMLU(一套測試 AI 知識廣度的標準題庫,涵蓋數學、歷史、法律等 57 個科目)上的評估實驗。過去我必須分別把評估數字手動貼到 Hugging Face 模型頁面、Open LLM Leaderboard 排行榜,以及其他想公開的地方,各平臺格式不同,既費時又容易出錯。現在透過 EEE 整合,我只要把結果以統一的 JSON 格式提交到 EEE 資料庫,再用官方提供的自動轉換工具,把 EEE 紀錄轉成 HF 所需的 YAML 格式(一種設定檔格式);工具會自動比對是否有重複或衝突,確認無誤後一鍵送出 pull request(一種線上提交修改申請的流程),結果就自動同步顯示在 HF 模型頁面上。和以前相比,省去了重複貼多個平臺的功夫,外界也能點進去追溯完整的評估設定和過程,透明度大幅提升。

T3
ZLUDA 6 讓非 Nvidia GPU 執行 CUDA 程式

ZLUDA 是一個開源翻譯層工具,讓原本只能在 Nvidia GPU(顯示卡)上執行的 CUDA 程式,不需修改任何程式碼就能在 AMD 等非 Nvidia GPU 上運作。CUDA(Compute Unified Device Architecture)是 Nvidia 獨家的運算平臺,絕大多數 AI 模型訓練與推論框架(例如 PyTorch、TensorFlow)都依賴它,等於整個 AI 計算生態幾乎被 Nvidia 綁死。ZLUDA 6 是最新版本,新增紋理支援(讓 Blender 這類 3D 軟體也能用),並帶來 7 項新 CUDA 指令實作、7 項編譯器修復與 6 項效能函式庫改善,其中許多改進直接來自 PyTorch(主流 AI 訓練工具)用戶回報的真實需求。值得注意的是,開發者表示此專案已回歸個人興趣驅動模式,不再受商業考量限制,更新節奏可能放慢。

假設你有一張 AMD Radeon GPU,想用 PyTorch 跑一個開源 AI 圖像生成模型(如 Stable Diffusion)。正常情況下,PyTorch 的 CUDA 加速完全依賴 Nvidia 硬體,AMD 用戶只能用慢得多的 CPU 運算,或改用 AMD 自家的 ROCm 平臺(但相容性問題多且設定繁瑣)。裝上 ZLUDA 後,PyTorch 以為自己在 Nvidia GPU 上跑,ZLUDA 在底層即時把 CUDA 指令翻譯成 AMD GPU 看得懂的格式,讓圖像生成速度大幅提升,且不需改動任何模型程式碼。ZLUDA 6 針對 PyTorch 的 CUDA 指令相容性做了多項修復,讓這個使用情境更加穩定。

T3
農業 AI 的數據困境

AI(人工智慧)正在農業領域帶來巨大的應用潛力,研究顯示 AI 預測模型能讓農作物產量提升 26%、減少 41% 的用水量、降低 33% 的農藥使用量。然而,根據麻省理工科技評論的報導,農業界目前最大的障礙不是 AI 技術本身,而是「數據品質不足」——農場的資料往往來自各種不同來源(物聯網(連網感測器設備)、無人機影像、氣象資料、政府農業資料庫),這些資料格式不一、品質參差不齊,讓 AI 難以給出可信的答案。更棘手的是,農地的地理差異很大——同一片農場裡不同區塊的土壤、水分、日照都不同,AI 必須理解這些細微差異才能提出有效建議,而許多 AI 供應商在推銷產品時常常忽略這個問題。因此文章提醒農業企業主:在砸錢投資 AI 之前,應先花時間整理、統一、治理內部數據,才能讓 AI 真正發揮價值。

以擁有 104 年歷史的農業經銷商 Wilbur-Ellis(一家銷售肥料、農藥、種子的公司)為例:這家公司在導入 AI 之前,先花時間建立了一套「統一數據模型」,將旗下所有客戶、供應商、產品、定價資料整合進同一個系統,並建立資料治理(就是制定規則,確保資料正確、不重複、有人負責更新)框架。完成這個基礎建設後,公司才開始讓 AI 分析數據並提出作物管理建議。相比之下,若一家農業公司直接上 AI 但數據還是散落在各個 Excel、紙本記錄、不同廠商系統裡,AI 輸出的建議(例如「這塊田本週應施多少公斤肥料」)就可能因為輸入資料不完整而完全不準確,甚至帶來損失。

T3
樂動機器人發布空間感知大模型

樂動機器人(Ledong Robotics)是一家成立於 2017 年、專注物理 AI(Physical AI,讓機器人理解並操作真實世界的 AI 技術)的中國公司,近期已登陸香港交易所主板上市。該公司的核心技術是自主研發的 LD-SenseWorld 靈境物理空間交互大模型,這是一種讓機器人「看懂並理解周遭空間」的 AI 模型(大模型,就是類似 ChatGPT 那種大規模訓練出來的 AI,但這個是專門處理空間感知,不是對話)。它整合了攝影鏡頭、雷射雷達(LiDAR,用雷射光束掃描環境的距離感測器)、慣性感測器等多種資料來源,把連續的物理世界切成機器可以學習的「空間 Token(將三維環境切割成離散資料單位,方便 AI 處理)」,讓機器人具備理解環境語意(事物的意義與因果關係)的能力。截至目前,搭載樂動感知技術的設備已突破 2,000 萬臺,2025 年旗下 DTOF 雷射雷達單年出貨量超過 400 萬臺。

假設你要讓一臺智慧割草機器人在院子裡自動割草:舊做法是機器人靠簡單的邊界感測器亂撞,或者需要事先鋪設磁條,每換個新地點就要重新設定,稍微有坡度或障礙物就出問題。用 LD-SenseWorld 大模型的做法是:機器人上的雷射雷達持續掃描院子地形,模型即時把這些掃描資料轉換成「空間 Token」——哪裡是草坪、哪裡是花圃、哪裡有樹根凸起——AI 理解這些空間語意後,機器人就能自主規劃路線、繞過障礙物、在不同院子裡不需重新設定就能正常工作。差異在於:以前割草機需要人工設定或只能在固定環境使用,現在機器人自己「看懂」環境後能自適應任何新場地。這也解釋了為何全球智慧割草機器人市場預估到 2030 年將達 62.5~100 億美元,正是這類底層空間感知技術讓大規模商業化成為可能。

T3
生物實驗標準語言 BPL 問世

生物實驗長久以來有個頭痛問題:各實驗室用自然語言描述操作步驟,充滿模糊詞彙,像「輕輕混勻」這種說法,機器完全看不懂,其他科學家也很難照著複現。恩和科技(Bota Biosciences,一家專注 AI 生物製造的公司)在 bioRxiv(生物學論文預印本平臺,相當於論文正式發表前的公開草稿平臺)發表了「BPL(Biology Protocol Language,生物實驗協議語言)」——一套專為生物實驗設計的統一描述語言,類似程式語言,讓實驗步驟能被機器精確讀懂。搭配這套語言,他們還推出了 BPL-COGEN,一個以 LLM(大型語言模型,就是 ChatGPT 這類能理解並生成文字的 AI)為核心的自動程式碼生成工具,科研人員只要描述實驗需求,AI 就能自動把步驟轉成可讓實驗室自動化設備執行的指令。測試結果顯示,BPL-COGEN 生成的程式碼在三輪自動修復後編譯通過率高達 98.6%,重複生成一致性達 98.3%,且能把原本需要 32 分鐘的液相色譜(一種分離和分析化學成分的常見實驗方法)流程壓縮到僅 2.1 分鐘。

假設一位食品研發工程師想測試某款益生菌菌株在不同溫度下的存活率,以往得先手動撰寫詳細實驗方案文件,再請軟體工程師把每個步驟逐行翻譯成實驗機器的控制程式碼,整個流程可能耗費數天甚至數週。改用 BPL-COGEN 後,工程師只需以 BPL 語言描述實驗目標,系統自動生成機器可執行的程式碼,通過內建編譯器(自動找出程式錯誤的檢查工具)驗證後,直接送進自動化實驗室執行,全程不需手動寫程式。恩和科技公開的數據顯示,其 AI 驅動的菌株工程平臺單日可完成 30 萬組實驗,相當於傳統實驗室整整一年約 500 個實驗的產量;目前已與新和成、伊利、BASF、珀萊雅等企業合作,應用於食品、營養健康、個人護理等領域。

T3
Claude Code 之父 AI 時代 5 種角色論

Boris Cherny 是 Claude Code(一個讓工程師用自然語言指揮 AI 幫忙寫程式的工具)的創造者,他在 Anthropic(開發 AI 助理 Claude 的公司,是 ChatGPT 的主要競爭對手)任職。他提出了一套 AI 時代的「職場角色分類框架」,概念類似 MBTI(一種廣為人知的性格測驗,把人分成不同類型),把在 AI 浪潮後仍具有職場價值的人分成 5 種:原型師(快速測試新點子、不怕失敗的人)、建造師(把點子做成真正可上線產品的人)、清道夫(負責整理與精簡既有系統的人)、增長手(專注幫產品找到市場定位的人)和維護者(確保成熟系統穩定運作的人)。他的核心論點是:AI 正在削弱各行各業的傳統「專業壁壘」,未來更有競爭力的是能跨越多個領域的「通才」,而不只是在單一技術深耕的「專才」。他以歷史上印刷術的發明為類比:印刷術出現後,並非所有抄寫員都被淘汰,而是那些懂得適應、跨越舊框架的人得以在新時代繁榮。

假設你現在是一名傳統後端工程師,過去的職場價值在於精通某種程式語言或資料庫架構。在 Boris 的框架下,AI 工具(例如 Claude Code)已能協助完成大部分純技術的寫程式工作,讓沒有工程背景的人也能產出可用的程式碼。但如果你屬於「建造師(Builder)」類型——也就是你擅長快速把一個模糊的需求轉化成真正可上線產品,且懂得善用 AI 加速每個環節——那麼你的價值就不再只是「會寫程式」,而是「能讓東西快速上線」的整合能力。例如過去需要一個月才能推出的功能,Builder 型的人搭配 AI 工具可能一週就完成,這類人不但不會被取代,反而因為 AI 的加持而更值錢。相反地,若你的所有工作都只是重複性的程式碼搬運,那才是真正的高風險地帶。

T3
智譜 GLM-5.3 公開徵集需求 社群喊話要視覺

中國 AI 公司智譜 AI(開發了知名大型語言模型 GLM 系列)的靈魂人物、清華大學教授唐傑,在社群媒體上公開向大眾徵集 GLM 下一代版本(GLM-5.3)應該加入哪些新功能,這則貼文獲得超過 40 萬次瀏覽。留言區幾乎一面倒,最多人要求的是「視覺能力」——也就是讓 AI 能夠看懂圖片、理解影像內容。目前的 GLM-5.2 是純文字模型(只能處理文字,不能看圖),而競爭對手如 Kimi K2.5、阿里的 Qwen 3.5 等已經具備多模態(能同時處理文字與圖片)的能力。智譜其實並非沒有視覺相關技術,過去曾推出 GLM-5V-Turbo 與 CogVLM 等能看圖的模型,但唐傑此前認為視覺功能對提升 AI 核心推理能力幫助有限,因此策略上以強化推理為優先。如今面對市場競爭壓力與用戶強烈反映,視覺功能的優先順序可能即將被提升。

假設我是一名設計師,想請 AI 幫我分析一張競爭對手的廣告截圖,找出版面配色和字型特點。用目前的 GLM-5.2 根本做不到——它看不了圖,只能接受文字輸入;我必須先自己用文字描述圖片內容,再讓它分析,非常費工。但同類的 Kimi K2.5 或 Qwen 3.5 可以直接把截圖丟進去問「這張廣告用了什麼配色策略?」,幾秒內就能得到具體分析。這次社群留言呼聲正是反映這個落差——用戶希望 GLM-5.3 補上這個缺口,讓它也能直接處理圖片輸入,而不必使用者先自己把圖片內容翻譯成文字再提問。

T3
信通院發布首個 AI 運維評測基準

中國信通院(中國信息通信研究院,類似國家級 AI 技術研究機構)於 2026 年 6 月底正式發布「AISHPerf 人工智能軟硬件基準體系 3.0」,其中包含兩個全新的 AI Infra(AI 基礎設施,也就是讓 AI 能跑起來的伺服器、晶片、軟體環境等底層系統)運維評測標準。其中一個是「智算運維智能體評測基準」,是全球首個針對 AI 資料中心日常維護管理的評測體系;另一個是「算子生成智能體評測基準」(算子就是 AI 模型計算的最基本指令單元)。這套標準以近百億筆真實運維資料為基礎,設計了 103 條高仿真測試案例,覆蓋 5 大技術架構、44 種故障現象、22 個細分故障領域。特別的是,這套基準已納入天數、壁仞、沐曦、摩爾、昇騰等 5 款國產 AI 晶片的特定運維場景,對推動中國 AI 基礎設施標準化具有重要意義。

假設你是一位負責維護大型 AI 訓練叢集(就是一排排用來訓練 AI 的伺服器機房)的工程師。以前,當某個計算節點出現異常(例如昇騰晶片突然離線),你需要手動查日誌、對照文件、逐步排查,平均一張工單要花好幾個小時。有了「運維智能體」(一種能自動分析問題、執行診斷步驟的 AI 助手)之後,它會依照 AISHPerf 評測基準驗證過的能力,自動辨識故障類型並給出處置建議。根據實際部署數據,工單平均處理時間縮短了 50%,遇到關鍵故障時處理效率更提升約 6 倍,整體運維成本下降 30%。這套評測基準的作用就像是「考駕照考題」——讓各家廠商的 AI 運維產品都用同一套標準來衡量,使用者才能客觀比較哪套工具更靠譜。

T3
虎牙VAM 1.0多模態數字人

虎牙推出了一款叫做 VAM 1.0(Vivid Avatar Model)的 AI 數字人基礎模型,只需要一張人物照片,就能自動生成一個可以說話、唱歌、跳舞、玩遊戲的虛擬主播,並且可以連續直播 24 小時不中斷。這個系統採用了 DiT(一種近年在影像生成領域很流行的 AI 模型架構)作為核心,讓數字人能即時回應觀眾的文字訊息和語音,也支援「說到一半被打斷」這種自然對話情境。技術上,系統達到了 480×832 解析度、每秒 28 幀的即時輸出,首幀延遲約 1.3 秒,後續片段延遲只需 0.77 秒。虎牙表示這項技術突破了業界長期面對的三個難題:長時間運行臉部會飄移變形、互動只能說不能聽、以及大規模部署成本過高。

假設一個中型直播頻道想要在晚上無人值班時段保持開播、維持觀眾互動。過去的做法是錄播循環或請真人輪班,成本高且互動性差。用 VAM 1.0 的話,只需上傳主播本人的一張照片,系統就能生成一個外觀相近的 AI 數字人,全天候在直播間回應彈幕提問、唱歌表演、甚至主持狼人殺遊戲。測試中,數字人能記住觀眾的名字、切換方言腔調、並在玩塔羅牌互動時根據觀眾選牌即時給出解讀。對比過去需要事先錄製大量劇本、且無法應對突發提問的數字人方案,VAM 1.0 能做到真正「實時聆聽、即時回應」,不需預錄內容。

T3
明略科技開源 Agent 協作網絡 Octo

中國 AI 公司明略科技開源發布了一個名為 Octo 的 Agent(AI 自主任務執行程式)協作網絡平臺,讓「人」和「AI Agent」可以同時在一套系統裡合作完成工作。Octo 的名稱由四個英文字的首字母組成:Open(開放、可自行架設)、Context(工作脈絡能在成員間流動共享)、Taste(保留人的判斷與偏好)、Orchestration(統一調度管理)。平臺提供 Web、手機 App(iOS/Android)、瀏覽器插件與命令列四種介面,讓 AI Agent 能出現在實際工作發生的各種場景。每次協作的過程、決策依據和工作方法都會被記錄下來,成為組織可重複使用的知識資產,不因人員或 Agent 更換而消失。

假設一個內容團隊要生產一份市場報告:過去的做法是主管在群組軟體(如 Slack)指派任務給不同成員,各自完成後用 email 匯整,過程零散、很難追溯誰決定了什麼。用 Octo 後,可以把「市場分析 Agent」和「文案撰寫 Agent」都加入同一個 Channel(頻道,類似專案群組)。主管在 Channel 發布 Brief(工作說明),Octo 自動將其轉成可追蹤的 Matter(工作事項);分析 Agent 先跑資料蒐集,用 Critic(獨立審核)模式讓另一個 Agent 挑毛病,再交由文案 Agent 撰寫;全程的討論紀錄、版本修改、最終驗收結果都存在同一個 Thread(討論串)裡。對比舊做法:任何人事後都能查到「這份報告是怎麼決策的」,而不是隻有最終檔案。

T3
AI 週報:腦控打字與多模型更新

這期 AI 新聞週報彙整了近日多項重要進展。首先,Meta 發布 Brain2Qwerty v2,這是一種「非侵入式腦機接口」(就是不需要在大腦裡植入晶片,只需佩戴頭戴感測裝置就能讀取腦部訊號)的文字輸入技術,能把人腦中「想說的話」即時轉換成螢幕上的文字;整體單詞準確率約 61%,最佳受試者可達 78%,Meta 同步開放了訓練程式碼與數據集供研究社群使用。其次,Claude(由 Anthropic 開發的 AI 對話助理,類似 ChatGPT 但來自不同公司)正式上架 Microsoft Azure Foundry 雲端平臺,支援最新的 Opus 4.8 和 Haiku 4.5 兩個版本,讓企業客戶可透過熟悉的 Azure 服務使用 Claude。此外,中國科技公司也動作頻頻:DeepSeek 推出 DSpark 推測解碼(一種讓 AI 生成速度更快的技術),比同類方案快 30.9%;美團即將發布 LongCat 2.0 與 Owl Alpha 模型,號稱擁有約 480 億個活躍參數(參數越多,模型通常越聰明)及 100 萬字元的超長記憶視窗(就是 AI 能一次「記住」並處理的文字量)。AI 程式碼工具 Cline 也推出月費 9.99 美元的訂閱方案,整合多家模型 API。

假設你是一位因手部受傷或神經疾病而無法正常打字的人。過去你只能用語音輸入(在安靜辦公室或公開場合不方便),或仰賴他人代打,效率極低。現在有了 Meta Brain2Qwerty v2,你只需戴上非侵入式腦部感測頭戴裝置,在腦海中「想像」要輸入的句子,系統就能把腦電訊號即時解碼並輸出成文字——無需開口、無需動手。以目前 61% 的單詞準確率來說,大約每打 10 個字會出現 4 個錯誤,仍需後續修正,但對原本完全無法輸入的人而言已是重大突破。相較於舊版 v1,v2 在解碼速度與準確率上都有提升,且 Meta 公開了程式碼與訓練資料,讓全球研究者能繼續改進,預期準確率在幾年內還會顯著提高。

T3
vLLM 四節點自託管 550B 大模型

NVIDIA 和 vLLM(一個讓大型 AI 模型跑得更快、更有效率的開源推理框架)共同發布了一份實用技術指南,說明如何用四臺 DGX Spark 伺服器(NVIDIA 推出的高效能 AI 計算機器,每臺內建強力 GPU)協同運作,對外提供一個統一的 AI 問答接口。示範用的模型是 Nemotron-3-Ultra 550B——「550B」代表有 5500 億個參數,規模遠超過一般企業常用的模型。這件事的重點不在於「四臺機器合跑超大模型」本身,而在於它展示了一套現成、標準化的方式,讓企業可以把這種前沿等級的大模型直接部署在自家機房,完全不依賴 OpenAI 或 Google 等外部雲端服務。更關鍵的是,整套做法採用 OpenAI 相容的 API 格式(接口規格),代表原本接 ChatGPT 的系統幾乎可以無縫切換,對有資料隱私或法規合規顧慮的企業而言非常實用。

假設一間臺灣的大型金融機構,因法規要求客戶資料不得傳送至境外伺服器,長期無法使用 GPT-4 或 Claude 等雲端 AI 服務,只能用算力受限的小模型,導致生成報告品質差、理解能力弱。現在他們可以採購四臺 DGX Spark 伺服器,按照這份 vLLM 指南完成安裝,便能在自家機房跑起 Nemotron-3-Ultra 550B。對外只需開放一個 API 端點,內部各部門系統——合規審查、客服機器人、法律文件摘要——全部呼叫這個端點,行為與接 OpenAI 完全相同。舊做法是「用小模型合規但能力差」或「用大模型能力強但資料外傳有風險」的兩難,現在這個兩難不再存在,企業可以同時擁有前沿等級的模型能力與完全的資料掌控權。

T3
GLM 5.2 成開源焦點月費捆綁多模型

GLM 5.2 是由中國清華大學團隊開發的開源大型語言模型(LLM,就是像 ChatGPT 一樣能對話、寫程式、回答問題的 AI),近期在開發者社群中廣受矚目。雖然並非今日才正式發布,但許多應用開發者已將它視為預設的可靠選擇。值得注意的是,開發工具平臺 Cline 推出了月費訂閱方案,將 GLM 5.2 連同 DeepSeek、Kimi、MiniMax、Mimo、Qwen 等多個開源模型打包在一起,讓開發者不必再個別申請各家 API 金鑰(API 金鑰就是使用 AI 服務時的通行密碼),大幅降低在不同模型供應商之間切換的摩擦。此外,也有開發者實驗以 GLM 5.2 搭配其他模型組成「模型組合」(Mixture-of-Agents,讓多個 AI 模型分工合作、互相補強弱點),以及用 GLM 5.2 驅動一個自動研究開發者關係內容的 AI 代理人(Agent,就是能自動執行多步驟任務的 AI 程式)。

假設我是小型新創公司的開發者,想在產品裡加入 AI 功能,但不想被單一模型綁定,也不想花時間逐一向各家廠商申請 API 金鑰、分開管理帳單。透過 Cline 的月費方案,我一次訂閱就能在程式碼編輯器中自由切換 GLM 5.2(擅長中英雙語程式任務)、DeepSeek(擅長推理)、Kimi(擅長長文本)等不同模型。原本需要向五、六家廠商分別申請帳號、設定金鑰並各自付費;現在只需一個月費,就能直接切換使用,省去大量行政摩擦,讓開發者能把精力放在實際產品上。

T3
Cursor iOS 遠端控制雲端 AI 代理

Cursor(一款專為寫程式設計的 AI 輔助編輯器)推出了 iOS 行動版的遠端雲端代理功能,讓開發者可以直接用手機啟動並管理在雲端執行的 AI 代理(agent,就是能自動執行任務的 AI 程式,不需要人一步步指令,它會自己判斷怎麼做)。這意味著工程師不必坐在電腦前,也能遠端控制那些在桌機或雲端持續運作的自動化 AI 工作流程。新版還支援在手機 App 內直接查看 PR 差異(PR diff,就是程式碼修改前後的對比清單,用來讓人確認 AI 改了什麼)並即時收到通知,讓程式碼審查不再被釘在辦公桌前。這項更新讓「用手機管理 AI 寫程式」從概念變成實際可操作的日常工具。

假設你是工程師,週末外出時想讓 AI 代理繼續跑一個整理資料庫的任務。過去你必須回到電腦前才能確認進度或重新啟動任務;現在你可以在 Cursor iOS App 上直接啟動一個「永遠在線的雲端 AI 代理」,讓它在雲端持續執行。等任務跑完,手機收到通知:「AI 已開出 PR(Pull Request,就是一份等待審核的程式碼修改申請)」。你打開 App 查看 PR diff,直接在手機上確認程式碼修改無誤,批准後繼續你的週末,完全不需要回家開電腦——相較於舊方式必須時刻守在桌機前監控,這讓開發工作的彈性大幅提升。

T3
Claude 模型登陸 Azure Foundry

Anthropic 的 Claude AI 模型——包括 Opus 4.8(旗艦高階版本)和 Haiku 4.5(輕量快速版本)——現在在微軟的 Azure Foundry(微軟雲端 AI 開發平臺,讓企業可以在自己的 Azure 環境中部署各種 AI 模型)上正式進入 GA(General Availability,全面正式上線)狀態。這表示企業客戶不再需要另外申請 Anthropic 帳號,而是可以直接透過現有的 Azure 帳號、計費系統、身份驗證機制來使用這兩個 Claude 模型。此次整合還支援 prompt caching(提示快取,讓 AI 處理重複內容時不必每次重算,可降低使用成本)以及 thinking 模式(讓 AI 在回答前先進行內部推理步驟,提升處理複雜問題的準確度)。對於已在 Azure 生態系中運營的企業來說,這大幅降低了導入 Claude 的技術與行政門檻。

一家已把核心系統建在 Azure 上的法律科技公司,想把 Claude Opus 4.8 導入合約審閱流程。過去的做法是:另外申請 Anthropic API 帳號、獨立管理 API 金鑰、費用走另一張帳單、員工存取權限要另外設定——IT 安全部門要多維護一套外部服務,且每月稽核時需跨兩個平臺整理紀錄,不符合企業合規要求。現在透過 Azure Foundry,開發者可以用同一個 Azure 訂閱呼叫 Claude、費用合併進公司現有的 Azure 帳單、身份驗證走公司的 Azure Active Directory(員工離職就自動失去存取權)、稽核日誌統一在 Azure Monitor 查看。導入時間從原本的數週縮短至數天,合規審查也一併解決。

T3
Rampart 瀏覽器端個資遮蔽工具

Rampart 是由 ndstudio 開發的一款輕量 AI 工具,安裝在瀏覽器上,在任何資料送出去之前就先自動偵測並遮蔽 PII(個人識別資訊,就是姓名、電話、身分證字號、電子郵件等可以辨認出特定個人身份的資料)。它的大小隻有 14.7MB,非常輕巧,直接在使用者自己的電腦上執行,不需要把原始資料傳到雲端處理。這對於在醫療、金融、法律等受到嚴格法規限制的行業工作的團隊特別有用,因為這些行業通常不允許將客戶個資傳送到外部 AI 服務。它的設計思路是:與其讓整個 AI 系統都符合隱私法規(成本極高),不如在資料進入 AI 之前就在本機把敏感資訊清理掉。

假設你是一名客服主管,想用 ChatGPT 或其他 AI 工具幫你分析客戶投訴信件、找出常見問題模式。但這些信件裡包含客戶的姓名、電話、住址等個資,直接貼到 AI 上可能違反 GDPR(歐盟個人資料保護法規)或臺灣個資法。過去的做法是手動刪除每封信裡的個資,非常耗時。安裝 Rampart 後,當你把信件內容貼入 AI 介面時,瀏覽器會自動把「王小明、0912-345-678、臺北市大安區忠孝東路 X 號」這類資訊替換成「[姓名]、[電話]、[地址]」等佔位標記,再把遮蔽後的文字傳給 AI 分析。AI 仍能理解信件的意思並提供有效分析,但完整個資從未離開你的本機瀏覽器,法規合規問題迎刃而解。

T3
Acti 把 AI 代理嵌入手機鍵盤

Acti 是一款可安裝在 iPhone 或 Android 手機上的鍵盤 App(就像注音輸入法一樣,把原本的系統鍵盤換成它),讓使用者在任何 App 打字的同時就能呼叫 AI(人工智慧)幫忙,不需要另外切換到 ChatGPT 或其他 AI App。它最特別的功能叫做「技能(Skill)」——使用者用日常白話描述自己想要的動作(例如:「把我打的文字翻成英文」),Acti 就能自動建立一個快捷鍵,之後只要長按那個按鈕就能執行。Acti 背後採用 Google 的 Gemini 模型(Google 開發的 AI 語言大腦)來理解自然語言,個人資料預設存放在手機本地端、不上傳雲端,主打隱私安全。這款 App 剛完成 530 萬美元種子輪融資,早期測試者在兩週內已創建超過 1,000 個自訂技能,顯示市場需求相當旺盛。

我每天需要在 Instagram DM、Gmail、LINE 等不同 App 之間切換,每次都要先複製文字、跳到 ChatGPT 翻譯或改寫,再複製回來貼上,單次來回至少花 30 秒。裝上 Acti 後,我用一句話設定技能:「選取文字後幫我翻成英文並直接取代原文」,Acti 自動把這個動作綁到鍵盤上的「T」按鈕。之後不論我在哪個 App 打字,只要選取文字、長按「T」,翻譯結果就直接出現在輸入框,全程完全不需要離開當前 App。對比舊做法,省去了 App 切換的步驟,每次節省約 20~30 秒;若每天執行 20 次,一天就省下約 10 分鐘的無謂跳轉時間。

T3
X 推出 MCP 伺服器串接 AI 工具

X(也就是以前的推特)正式推出了一個由官方代管的 MCP 伺服器。MCP(Model Context Protocol,一種讓 AI 助理連接外部工具的開放標準,概念上就像 USB 規格讓各種裝置都能插進電腦一樣)是目前業界推動的協定,讓 Claude、Cursor 等 AI 助理能夠直接存取外部平臺的資料。過去開發者若想讓 AI 工具讀取 X 平臺內容,必須自己架設 MCP 伺服器、自行處理繁瑣的帳號身份驗證流程;現在 X 官方直接提供代管服務,開發者只需連上這個伺服器,就能讓 AI 助理透過使用者自己的帳號權限,搜尋 X 內容、讀取貼文、查詢帳號資訊並分析對話趨勢。目前這個 MCP 伺服器僅開放「讀取」功能,無法用來自動發文,X 同時保留原有的反垃圾內容管控機制。

假設你想用 Claude 幫你分析「臺灣 AI 新創圈最近的討論熱點」。過去的做法:你得自己寫程式呼叫 X 的 API、處理 OAuth 登入授權、架設中介伺服器,才能讓 Claude 拿到 X 上的即時資料,整個前置工程可能要花好幾天。現在的做法:在 Claude 的 MCP 設定中加入 X 官方提供的 MCP server 網址,Claude 就能直接用你的 X 帳號去搜尋相關貼文、彙整討論、找出哪些議題最熱門——整個流程不用寫半行程式碼,也不需要自己維護伺服器基礎設施,讓開發者可以把時間花在真正想做的功能上。

T3
Amazon 10 億 AI 駐廠工程師

Amazon 旗下的雲端服務部門 AWS 宣佈成立一支新的工程師團隊,專門負責幫企業客戶部署 AI(人工智慧)應用,預計投入 10 億美元(約臺幣 320 億元)的內部資源。這支團隊叫做「FDE(Forward-Deployed Engineer,前線部署工程師)」,工程師會直接進駐到企業辦公室,協助建立量身打造的 AI 代理(Agent,就是能自動執行特定工作任務的 AI 程式,例如自動整理訂單、回覆客服)。這個「派人進去」的做法最早是由數據分析公司 Palantir 發揚光大,意思是把自家工程師當長期顧問派到客戶公司,而不只是賣軟體給對方自己搞定。Amazon 這樣做,正是因為越來越多企業想用 AI 但不知道怎麼整合進自己現有的系統,需要有人手把手陪伴。值得注意的是,OpenAI 和 Anthropic 也先後推出類似服務(分別籌資 40 億和 15 億美元),但那兩家選擇與外部私募基金合作成立獨立組織;Amazon 則選擇全部由 AWS 自己出錢、自己負責,顯示大廠對企業 AI 落地市場的爭奪越來越激烈。

假設你是一家臺灣製造業的 IT 主管,公司想導入 AI 幫品管部門自動偵測產線上的瑕疵品,但工廠的系統很老舊、資料格式亂七八糟,公司內部又沒有足夠人才懂怎麼把 AI 接進去。過去的做法是:花半年找顧問、出報告、採購軟體授權,然後自己摸索怎麼讓系統跑起來,最後往往失敗或效果不如預期。有了 Amazon FDE 之後,AWS 會派自家工程師直接坐進你的辦公室幾個月,和你的 IT 團隊並肩合作,把 AI 代理接入現有系統並快速上線。更重要的是,這些工程師在離開前還會教會你的團隊如何維護和改進,讓公司日後不再完全依賴外部廠商。相比之下,傳統做法只給你軟體授權,上線後出問題只能自己找答案。AWS 副總裁 Francessca Vasquez 也強調,客戶完成 FDE 部署後,帶走的不只是新系統,還有真正屬於自己團隊的工程能力。

T3
Lumo 2.0 隱私 AI 助理全面升級

Proton(一家以保護用戶隱私著稱的科技公司,旗下有 ProtonMail 加密電子郵件等服務)推出了旗下 AI 聊天機器人(就是像 ChatGPT 一樣可以對話的 AI 助理)Lumo 的 2.0 版本。這次升級帶來圖片上傳與 AI 生成圖片功能、回應速度提升 76%,以及「思考模式」(讓 AI 對複雜問題多推理幾步再回答,類似 ChatGPT 的 o 系列模型做法)。Lumo 最大的特色是隱私保護:採用零存取加密(就是連 Proton 公司自己的員工也看不到你和 AI 的任何對話內容),不把用戶對話拿去訓練 AI 模型,也不把任何資料分享給第三方廣告商或合作夥伴。新版「Projects」功能支援跨對話的持久記憶(讓 AI 記住你的習慣偏好,不用每次重新說明),整體功能水準已與 ChatGPT、Gemini 等主流 AI 助理相當,主要差異在於更嚴格的隱私保護設計。

我是一位律師,需要請 AI 幫我分析敏感的合約條款,但擔心把機密內容傳給 ChatGPT 後,這些對話被平臺記錄、用來訓練模型,或被第三方存取。改用 Lumo 2.0 的做法是:在「Projects」功能中上傳合約圖片或文件,設定 AI 永久記住「我習慣繁體中文回覆、分析要附法律風險等級」,然後正常提問。Lumo 會在加密環境下回傳分析結果,Proton 保證沒有任何伺服器端日誌、員工無法查閱對話。對比 ChatGPT 免費版:你的對話預設被 OpenAI 記錄,需要手動關閉才不會被用來訓練模型,而且即使關閉,公司層級的存取控制仍不如 Proton 的零存取架構嚴格。

T3
OKX 推出 AI Agent 互僱支付平臺

OKX(一家全球知名的加密貨幣交易所,類似股票交易所但交易的是虛擬貨幣)在 2026 年 6 月 30 日向開發者開放了一個名為「OKX AI」的市集平臺。這個平臺的核心理念是:讓 AI 代理(Agent,就是能自主完成任務的 AI 程式,類似可以幫你跑腿辦事的「AI 機器人助手」)彼此「僱用」對方來完成任務,並自動用穩定幣(一種與美元掛鉤、價格穩定的加密貨幣)結算報酬——全程不需要人工介入,24 小時不間斷。平臺還幫每個 AI 代理建立一套基於區塊鏈(一種無法竄改的數位帳本技術)的身份識別與信譽評分系統,記錄它過去的任務表現,讓其他 AI 或人類用戶決定要不要僱用它。此次上線的服務包含安全評估(由 CertiK 提供,幫代理執行交易前先驗證錢包或代幣安全性)、即時市場數據(按查詢次數付費)和合約爭議解決等功能,並支援與 Claude Code、Codex 等主流 AI 程式開發工具整合。

假設我是一個獨立開發者,我寫了一個可以幫人分析加密貨幣錢包安全性的 AI 代理,把它上架到 OKX AI 市集。現在有另一個自動執行投資策略的 AI 代理(屬於某位用戶的投資機器人),它在執行交易前想確認某個錢包是否安全——它直接在市集上找到我的服務,自動支付一小筆穩定幣(微支付,金額極小、按次計費),我的 AI 代理完成安全分析後回傳結果,整個僱用和付款流程沒有任何人點擊按鈕、沒有銀行轉帳等待、也沒有跨境手續費。相比舊做法(開發者得自己串 API 接第三方金流、手動對帳、等銀行結算、還要處理國際匯款),這個平臺讓 AI 與 AI 之間的自動委託和即時付款只需幾行程式碼就能完成,開發者上架服務後可以被全球任何一個 AI 代理自動找上門合作。

T3
OpenAI ChatGPT 推理成本砍半

根據科技媒體 The Information 的報導,OpenAI 透過一系列技術優化,讓旗下 AI 模型的推理成本(inference cost,也就是 AI 每次生成回答時所需的運算費用)降低了超過一半。推理是 AI 服務最燒錢的環節,每當有人在 ChatGPT 打一句話,背後的伺服器就必須消耗大量運算資源產出回答——這個動作就叫「推理」,而 GPU(專門用來跑 AI 的高階運算顯卡)是最主要的成本來源。這次優化讓 ChatGPT 在處理免費訪客用戶請求時,有時只需要幾百張 Nvidia GPU 就能撐起龐大的流量,比過去少了一半以上。對 OpenAI 而言,成本砍半意味著同樣的資金可以服務更多用戶,或為未來的更低定價奠定基礎,對整體 AI 產業的競爭格局也有不小的指標意義。

想像你是 ChatGPT 的免費用戶,平常打開網頁直接問問題,OpenAI 的機房在高峰時段可能要動用數千張高階 GPU 同時應付全球用戶。現在透過優化(推測涵蓋模型壓縮、批次推理排程改善、或硬體利用率提升等手段),機房有時只需幾百張 GPU 就能完成同等工作量。你作為使用者感受不到任何差異,回答品質和速度維持不變;但對 OpenAI 來說,電費、租金和硬體折舊每月可省下數百萬美元——省下的錢可以拿來訓練更好的新模型,或日後推出更便宜的付費方案與競爭對手搶市場。

T3
Meta 秘密測試 ChatGPT 等對話安全

Meta(臉書母公司)秘密僱用數百名外部承包商,讓他們扮演未成年人(也就是 13 歲左右的兒童或青少年),向競爭對手的 AI 聊天機器人——包括 OpenAI 的 ChatGPT、Google 的 Gemini,以及專門做角色扮演的 Character.AI——傳送涉及自殺、性、毒品等危機情境的對話提示。僅在單次測試回合中,就發出了超過 4 萬 5 千則提示,而被測試的這些公司完全不知情。這類行動在業界稱為「紅隊測試(Red Teaming,就是刻意用極端或惡意方式去攻擊 AI 系統,看看它會不會說出不該說的話)」,通常由開發商自己發起,但這次卻是由競爭對手 Meta 在背後主導,引發外界質疑:這究竟是在維護用戶安全,還是在蒐集商業情報打擊對手?整起事件讓 AI 安全測試的倫理邊界再次成為焦點。

假設你是一名家長,想知道你 12 歲的孩子每天用的 AI 聊天機器人,在孩子說出「我不想活了」或詢問危險藥物時,會怎麼反應。過去你只能靠各公司發布的安全政策聲明——而這次 Meta 的行動,等於是以大規模、有系統的方式實際驗證了這個問題。他們派人分別對 ChatGPT、Gemini、Character.AI 用 4 萬 5 千種不同說法提出危機情境,觀察每個系統是否拒絕回應、是否提示求助熱線、或是否照樣提供有害資訊。這和自己發安全報告的差異在於:是由不知情的第三方做的壓力測試,結果更接近真實。然而爭議也在此:Meta 是競爭對手,這份測試資料最終對誰有利、又會怎麼被使用,外界完全不清楚。

T3
Devin Fusion 多模型降本架構

Devin Fusion 是由 Cognition(開發 AI 工程師助手 Devin 的公司)推出的一套多模型混合執行框架(就是同時調度多種不同 AI 模型來完成工作的系統)。這套框架的核心概念是:不是把所有任務都丟給最貴最強的大模型,而是根據任務難度動態選擇「剛好夠用」的模型,讓簡單的事情由便宜的模型處理、複雜的才升級到頂尖模型。實際測試結果顯示,在 FrontierCode(一個評估 AI 寫程式能力的基準測試)上,整體費用可降低 35%,效能卻幾乎不打折。Cognition 還整合了 Fable 5(Anthropic 最新推出的一款大型語言模型,即 AI 的「大腦」),使成本進一步壓低到 41% 的降幅,同時對 AI 性能表現影響甚微。

假設我是一家公司,每天要讓 Devin 自動完成數百個軟體開發任務:有些是「幫我把這段英文變數名改成有意義的名字」這種小事,有些是「設計一個新的資料庫架構並撰寫測試」這種複雜任務。舊做法是全部丟給最強的頂尖模型,每個任務都燒高額 API(程式呼叫 AI 服務的費用)費用,月費動輒數萬美元。用 Devin Fusion 的做法:系統內建一個「主 Agent(主要執行的 AI)」加上一個「Sidekick(輔助路由器,負責幫忙分配工作)」的雙代理架構。Sidekick 先判斷每個子任務的難度,簡單的改名任務交給便宜的小模型,複雜的架構設計才升級到頂尖模型,還會避免「Cache Miss(快取遺漏,就是模型要重新計算之前算過的東西,白白浪費算力)」的浪費。結果:同樣的工作量,成本減少 35~41%,輸出品質幾乎沒差——對需要大量跑 AI 自動化程式任務的開發團隊來說,相當於每月省下三分之一的 AI 費用。

T3
RL 訓練如何突破可驗證限制

強化學習(RL,一種讓 AI 透過反覆嘗試、從錯誤中學習來進步的訓練方式)在數學解題、程式碼撰寫這類「答案對不對一目瞭然」的任務上,已取得驚人成果。然而現實世界有許多工作——例如規劃火星任務、撰寫小說、進行科學發現——根本沒有明確的對錯標準,導致 RL 訓練幾乎無法套用。這篇分析文章提出了「驗證者定律」:一件事越容易驗證答案,AI 就越容易用 RL 訓練到很強;反之則愈難突破。目前業界正在發展幾種方法,試圖把 RL 的優點延伸到難以驗證的領域:包括用詳細評分清單取代模糊判斷、讓 AI 先推理再評分的「生成式獎勵模型」(Generative Reward Model,讓模型自己解釋給分理由而非直接給黑箱數字),以及逐步評估每個推理步驟的「過程獎勵模型」(Process Reward Model,不只看最終答案對不對,而是審核每一步推論是否合理)。參與這個方向的公司分成三類:賣驗證工具給 AI 實驗室的(如 Mercor、Taste Labs)、幫模糊領域制定可驗證規則的(如 Pramaana Labs 專攻稅務法律),以及自己掌握完整訓練與應用循環的(如 Periodic Labs 做材料發現、Isomorphic Labs 做新藥研發)。

假設我要訓練一個 AI 幫企業提供稅務申報建議。這類任務過去很難用 RL 訓練,因為「建議好不好」無法自動判斷,只能靠人工審查給主觀分數,既耗時又難以大規模執行。現在 Pramaana Labs 這類公司的做法是:先把稅法條文整理成詳細的評分清單,例如「是否引用正確法條」、「是否考量節稅情境」、「格式是否符合申報規範」等,讓原本模糊的「建議品質」變成一條條可以程式自動核對的項目。AI 每次給出建議後都能獲得明確的分數回饋,RL 訓練就能正常運轉。對比舊做法,自動化評分可讓 AI 一天內完成數萬次訓練迭代,而人工審查可能一天只能處理幾十筆,訓練速度與品質的差距極為懸殊。

T3
RoadmapBench 測試 AI 長期程式開發

RoadmapBench 是一個全新的評測基準(benchmark,就是用來客觀測試 AI 能力強弱的標準化考試集),專門針對 AI 程式碼代理(coding agent,就是能自主寫程式、修改程式碼的 AI 工具)在長期、跨版本軟體開發任務上的表現進行測試。這個基準共包含 115 個任務,取材自 17 個真實開源程式庫(repository,就是存放和管理程式碼的平臺,如 GitHub 上的專案),涵蓋 5 種程式語言,每個任務都模擬真實工程師做版本升級時的工作情境。任務難度相當高:AI 代理平均需要修改 51 個不同檔案、總計 3,700 行程式碼,才算完成一次版本升級。測試結果出人意料地嚴峻——目前最強的 Claude Opus 4.7 模型只解決了 39.1% 的任務,最弱的模型更只達到 5.2%,清楚揭示現有 AI 在處理大規模、多目標的真實開發任務時,仍有很大的進步空間。

假設一個 Node.js(一種常見的網頁後端開發技術)框架剛發布了 v3.0 版本,引入了全新的路由系統和認證模組,並棄用了多個舊有 API(應用程式介面,就是程式之間溝通用的規格)。我手上有一個基於 v2.5 的舊專案,想用 AI 代理幫我自動升級:AI 要讀懂新舊版本的差異說明(路線圖),然後找出需要修改的所有檔案——路由配置、中間件、測試程式、說明文件——逐一改寫並確保整體功能不壞。這正是 RoadmapBench 在測試的任務類型:要橫跨數十個檔案、多種語言元件,並維持功能全部正確。測試結果顯示,過去那種只能修單一小錯誤的 AI 在這裡幾乎全軍覆沒,即使最強的 Claude Opus 4.7 也只能完成不到 4 成,說明 AI 代理要真正勝任工程師的版本升級工作,還有很長的路要走。

T3
Google Cloud 推出科學專用 AI 模型

Google 宣佈透過旗下的雲端服務 Google Cloud,開始銷售來自 SandboxAQ 公司的科學專用 AI 模型。SandboxAQ 是一家專注於量子科技與人工智慧的公司,他們開發的「大型量化模型」(Large Quantitative Models,一種以大量科學方程式和實驗室數據訓練而成的 AI,和 ChatGPT 那種對話式 AI 不同,它專門處理科學計算)並不設計來與人對話,而是用來解決高度複雜的科學問題。這次合作讓更多企業和研究機構可透過 Google Cloud 平臺直接取用這些模型,應用領域涵蓋新藥研發、材料科學研究和半導體製造。研究人員還可以將科學模型與 Google 的 Gemini(Google 推出的大型語言模型,也就是能理解自然語言、會對話的那種 AI)搭配使用——Gemini 負責理解問題和操作介面,科學模型則負責底層的精確科學計算。

假設我是一位研究人員,想篩選某種新化合物是否有潛力成為治療阿茲海默症的候選藥物。傳統做法需在實驗室合成數百種化合物並逐一測試,費時數年且成本極高。現在透過 Google Cloud 同時呼叫 SandboxAQ 的科學 AI 模型,我可以輸入化合物的分子結構數據,讓模型根據大量科學方程式訓練的知識,快速預測哪些結構最可能與目標蛋白質結合(這是藥物發揮效果的關鍵機制)。同時,我可以用 Gemini 輸入自然語言問「請幫我整理這五個候選分子的預測結果,並指出最值得進入下一輪實驗的選項」——兩個模型分工合作,無需分別登入不同平臺。相較於過去需要各自取得授權、獨立部署的繁瑣流程,現在在 Google Cloud 一個入口就能同時取用,大幅降低科學研究的技術門檻。

T3
Mistral 推出 AI 工作流平臺

Mistral(法國知名 AI 公司,以開發高競爭力的大型語言模型(LLM,就是 ChatGPT 這類會對話的 AI)聞名)推出了 Mistral Workflows,一個專為 AI 多代理管線(multi-agent pipeline,把多個 AI 處理步驟串接起來的自動化流程)設計的生產級工作流編排平臺。這個平臺基於開源引擎 Temporal 建構,主打「持久執行」(durable execution,意思是程式中途當機或重啟後,能從上次停下的地方自動繼續,不用從頭跑),不再需要開發者自己寫複雜的狀態追蹤和重試邏輯。平臺內建自動重試、長時間暫停等待人工輸入(從幾秒到數月都可以)、以及可觀測性(opentelemetry,就是即時記錄每一步發生了什麼、讓除錯和監控更容易)等功能。目前處於公開預覽(Public Preview,開放大眾測試但尚未正式上線)階段,支援透過 Mistral API、Studio 介面或 Vibe Work 三種方式呼叫工作流。

假設你要建一套合約審核自動化系統:用戶上傳合約 → AI 自動摘要 → 呼叫外部 API 查詢對方公司信用 → 流程暫停等待人工法務審核(可能要等兩天)→ 審核通過後 AI 生成最終報告並寄送。傳統做法需要自己設計狀態機(state machine,追蹤「現在跑到第幾步」的程式邏輯)、排程器、重試機制,API 失敗要從頭重跑,人工審核等待期間還要另外設計暫停機制,程式碼複雜度極高且容易出錯。改用 Mistral Workflows,每個步驟都自動記錄在事件歷史(event history)中:API 那步失敗會依設定的退避策略(backoff,等一段時間再重試、避免一直衝爛 API)自動重試;人工審核那步原地暫停等兩天,法務點「核准」送出信號後流程立刻接續下一步;整個過程你不需要額外寫任何狀態追蹤邏輯,程式碼量大幅減少,也能從 Studio 介面即時看到每個步驟的執行狀態。

T3
Ablo 開源 AI Agent 協作框架

Ablo 是一個開源的「協作層」工具,專門解決多個 AI Agent(就是能自動執行任務的 AI 程式,例如自動回覆郵件、自動更新訂單的機器人)同時操作同一筆資料庫資料時,互相覆蓋彼此更新的問題。它採用「聲明佔用」機制:每個 AI Agent 在對某筆資料進行讀取、思考、呼叫外部服務、再寫入這整段流程之前,會先「宣告佔用」該筆資料列,其他 Agent 遇到已被佔用的資料就會等待。等第一個 Agent 處理完並釋放後,下一個 Agent 才能讀取,而且讀到的一定是最新資料,不會用到已過時的舊版本。這個設計解決的是「競爭條件」(race condition,即兩個程序同時搶著修改同一個東西,導致其中一個更改被覆蓋掉)的問題,讓多 AI Agent 協同工作時能安全地共用資料庫。

假設你有一套訂單管理系統,同時有三個 AI Agent 負責處理客戶退款申請,每個 Agent 的步驟是:讀取訂單 → 呼叫外部驗證 API 判斷是否符合退款資格(這步可能需要數秒)→ 更新訂單狀態。若沒有協作層,三個 Agent 同時讀到同一筆訂單都顯示「待處理」,各自都認為該退款,最後三個都寫入退款紀錄,造成同一張訂單重複退款三次。使用 Ablo 後,第一個 Agent 先宣告佔用這筆資料列;第二、第三個 Agent 發現資料被佔用,等待排隊;第一個 Agent 處理完寫入「已退款」並釋放後,第二個 Agent 重新讀取看到狀態已是「已退款」,便跳過不再處理。相比以前工程師要自己實作複雜的分散式鎖(distributed lock)邏輯,Ablo 提供了一套更簡單的 API,讓開發者不需從頭寫這套機制。

T3
AI 加速寫碼但卡在交付流程

GitLab 最新研究發現,AI 輔助開發工具(就是像 GitHub Copilot、Cursor 這類能自動幫你補程式碼的 AI 助手)確實讓開發者「產出程式碼」的速度明顯加快,但整個軟體開發流程(SDLC,Software Development Life Cycle,也就是從需求分析、寫程式、測試到最終上線的完整過程)並沒有跟著等比例加速。瓶頸悄悄轉移到後段:程式碼審查(Code Review,就是讓資深工程師逐行確認程式碼沒有錯誤或安全漏洞)、自動化測試、法規遵循(Governance,確保程式碼符合公司政策與法律要求)以及部署上線等環節,因為 AI 大量產出的程式碼而越積越多、壓力倍增。研究因此呼籲,工程團隊不能只是「裝了 AI 工具就算完成數位轉型」,而必須重新設計整條軟體開發流水線,讓後端審查、測試和交付的能力能夠承接 AI 前端生產的海量程式碼,否則只是把塞車路段從「寫程式」換到「等審查」。

假設一個五人開發小組,過去一週能手動寫出 500 行功能程式碼,導入 AI 編碼助手之後,同樣的人力一週可能產出 2,000 行。但負責審查的資深工程師人數沒有增加,每週能仔細過完的程式碼量還是約 500 行;加上 AI 生成的程式碼有時會埋入難以察覺的安全漏洞或不符合公司合規規範的寫法,每一行都不能略過。結果是:原本預計兩週上線的新功能,因為程式碼審查和測試的積壓,實際等待四到六週才能發布。GitLab 的建議是:這類團隊應該優先投資「AI 輔助 Code Review 工具」(讓 AI 也幫忙審查 AI 寫的程式碼)和擴充自動化測試覆蓋率,而不是再買更多 AI 寫碼工具,才能真正縮短從「程式碼完成」到「功能上線」的時間差。

T3
Agent Swarm 開源多代理協作系統

Agent Swarm 是一套開源的 AI 代理協作平臺,讓你可以用一個「主代理(Lead Agent)」把大任務拆解成多個小任務,再交給多個「工作代理(Worker Agent)」同時並行執行,每個工作代理各自在獨立的 Docker 容器(可以把它想成一個隔離的虛擬工作間,各工作不互相干擾)裡運作。這套系統還內建「共享記憶體」,讓代理們記住上一次的工作內容,下次接著做而不用重新來過。它支援市面上主流的 AI 模型,包括 Claude、ChatGPT(OpenAI)、Gemini 等,也能和 Slack、GitHub、Linear 等常用工作軟體串接。重點是它定位是「運行層」,不是要你自己寫代理程式碼的框架,而是一個已經把指揮系統、任務排程、隔離環境都裝好的現成平臺,用 docker compose up 一行指令就能啟動,自行架設完全免費(MIT 授權)。

假設你是一個小型開發團隊的 PM,GitHub 上積了 30 個未處理的 issue(功能請求、bug 回報、文件更新等),傳統做法是你或工程師一個個手動分派、追蹤進度,費時又容易遺漏。用 Agent Swarm 的話:你設定 Lead Agent 監聽 GitHub issues,它自動把每條 issue 分析後拆成可執行任務(例如「修這支 API 的 bug」、「更新這份文件」),再路由給負責對應領域的 Worker Agent(例如 Claude Code 負責寫程式修 bug、另一個 Worker 負責改文件)。每個 Worker 在自己的 Docker 容器裡獨立執行,不會互相衝突。做完後把結果回存到共享記憶體,下次處理類似 issue 時 Lead Agent 會參考過去的處理模式。與過去人工分派相比,差異在於:30 個 issue 可以同時並行處理,而非排隊等一個人一次只做一件事,處理速度大幅提升,且無需人工盯著每個任務的狀態。

T3
Google 推出 AI 知識共享格式 OKF

OKF(Open Knowledge Format,開放知識格式)是 Google Cloud 於 2026 年 6 月提出的一套開放規範,目的是讓企業內部的資料知識能夠以標準化的方式打包,讓人類和 AI 系統都能輕鬆取用。簡單來說,它就是一種「裝知識的標準盒子」——只用 Markdown 純文字檔案加上 YAML 前置資訊(一種用來描述檔案屬性的簡單標記語言)來儲存資料表的描述、欄位說明、關聯關係等背景知識。這個格式最大的特點是不綁定任何特定廠商或工具,任何人都可以在沒有特殊軟體的情況下生產和讀取 OKF 檔案。目前許多企業的 AI 代理人(AI agent,就是能自主完成任務的 AI 程式)在回答資料問題時,往往因為缺乏組織內部的背景知識而出錯,OKF 的目標就是解決這個「知識碎片化」問題,讓每個 AI 代理都能共享同一套脈絡資料。

假設你的公司有一個叫做 `orders`(訂單)的資料庫表格,裡面有 `order_id`、`customer_id`、`amount` 等欄位。傳統上,這些欄位的意義散落在工程師的筆記、口耳相傳的說明或 Confluence(公司內部文件平臺)頁面裡,當一個新的 AI 分析代理要回答「上週哪個客戶下單金額最高?」時,它根本不知道 `customer_id` 要去哪張表對應客戶名稱、`amount` 是含稅還是未稅。採用 OKF 後,工程師只需在 Git 儲存庫(就是存放程式碼的版本管理系統)裡建立一個 `orders.md` 的 Markdown 文件,以固定格式寫清楚「這張表是什麼、每個欄位代表什麼、要怎麼與其他表格連結」,AI 代理每次分析前先讀這份文件,就能正確理解資料結構並給出準確答案。相較於舊做法,AI 不再需要靠猜測或靠工程師每次手動補充說明,而是直接讀一個標準化、版本可追蹤的知識檔案,出錯率大幅降低。

T3
難評估的AI是產品設計警訊

這篇文章由 AI 顧問 Hamel Husain 撰寫,核心論點是:當你說「這個 AI 功能很難評估(eval,就是測試 AI 的輸出到底好不好的過程)」時,這其實是一個警訊,代表產品本身的設計有根本問題。他認為,如果連開發者或產品團隊自己都很難判斷 AI 做得好不好,使用者也同樣難以判斷——這會讓使用者對產品失去信任。真正好的 AI 產品設計,應該一開始就讓輸出結果容易被「驗證」,具體做法包括:顯示每個答案來自哪個來源、把大型複雜任務拆解成可以逐步確認的小單位、讓使用者能夠針對每一小段接受或修改,而不是等到產品做出來之後才回頭想辦法補測試。這個概念雖然不是全新發明,但在 AI 產品時代特別關鍵,因為「能不能快速驗證 AI 輸出是否正確」是使用者願不願意信任這個產品的核心瓶頸。

以「工傷賠償醫療報告產生器」為例:假設我是一位醫生,要用 AI 幫我撰寫一份 50 頁的工傷評估報告。舊做法是 AI 直接從頭生成整份報告,但我要驗證它有沒有寫錯,等於要重新翻過整個病歷紀錄,工作量幾乎沒有減少,AI 的幫助大打折扣。新做法改成這樣:AI 先扮演「研究助理」的角色,從病歷中抽出關鍵事實、標示出前後矛盾的地方、列出還需要釐清的疑問,讓我這個醫生逐項確認或修正;等我確認完所有關鍵資訊之後,AI 才根據已驗證的內容生成最終報告。這樣我只需要聚焦在「差異點」和「關鍵判斷」,而不是重做整件事。新舊做法的差異就在這裡:舊方式「AI 幫我省了打字時間,但我還是要花等量時間驗證整份報告」;新方式讓驗證的負擔大幅降低,AI 的實際價值才真正體現出來。

T3
Builder.io 以 AI 消除團隊開發交接瓶頸

Builder.io 是一個網頁內容管理系統(CMS,就是讓非工程師也能更新網站內容的後臺工具)平臺,最新發布了整合 AI 的四項新功能,核心目標是「消除交接」——打破行銷人員、設計師、工程師之間互等、互傳檔案的工作瓶頸。其中最值得注意的是 Builder CMS MCP(一種讓 AI 工具直接讀寫 CMS 的連接協議),可讓工程師在 Cursor、Claude、GitHub Copilot 等 AI 編碼助理(就是幫工程師寫程式的 AI 工具)中,直接讀取和更新網站內容,完全不用切換工作環境。平臺也推出了 Builder Agent,讓行銷人員用自然語言(像聊天一樣輸入文字描述)就能自動生成符合品牌風格、SEO(搜尋引擎優化,讓網站更容易被 Google 找到)規範的網頁內容。整個平臺加入了 RBAC(角色權限控制,就是設定誰能改哪些東西的規則)和品牌護欄機制,確保 AI 生成的內容不會偏離公司的設計和合規規範。

假設我是一家電商公司的行銷人員,想在明天上線一個新產品促銷頁。以前的流程是:我寫好文案 → 丟給設計師排版 → 設計師改稿 → 丟給工程師 → 工程師上線,整個過程常常需要等 3 到 5 天。改用 Builder.io 新功能後,我可以在 Builder Agent 輸入:「幫我建一個夏季新品促銷頁面,主打清涼感,語調輕鬆,加入 SEO 標題」,AI 會自動依照公司預設的品牌字型、顏色、版型生成草稿;我預覽確認後提交工程師審核,工程師在 Cursor 裡直接看到通知並確認上線——整個流程從幾天縮短到幾小時。而且 AI 生成的內容不會亂用非品牌核准的字體或顏色,因為護欄規則已事先設定好,不管誰來操作都不會跑版。

T4
T4
用 CNN 辨識材質的毫米波雷達

作者 Gauthier Lechevalier 自製了一套毫米波雷達(mmWave radar,一種發射高頻電磁波、用反射訊號感測環境的裝置,手機裡的手勢感應也是類似原理)系統,並在其中加入 CNN(卷積神經網路,一種擅長從數據中找出規律的 AI 模型)來辨識雷達掃描到的材質,最終目標是非接觸式偵測建築物裡是否含有石棉。傳統石棉檢測需要鑽孔取樣、送實驗室化驗,費時數天、費用昂貴;這個方案改用雷達電磁波打在牆面上,讓 AI 從反射訊號的模式分析材質的介電特性(可簡單理解為:電磁波碰到不同材料時,吸收與反射的方式各有不同,如同每種材料的「電磁指紋」)。整套系統包含 FMCW 雷達(一種持續掃頻、能同時測距與速度的雷達技術)、DSP 訊號處理鏈(把原始雷達回波轉換成 AI 可分析的特徵圖)以及 CNN 分類器,在木材、銅、鋁、塑膠等多種材質上完成了概念驗證。遺憾的是,因融資不足專案已停止,但所有技術細節與程式碼均已開源公開。

假設你是建築改建承包商,需要確認一面舊牆是否含石棉才能決定是否需要特殊拆除工法。傳統做法:聘請專業人員現場鑽孔取樣 → 送至認可實驗室化驗 → 等候數天報告、支付高額費用。用這套原型系統的預期做法:拿毫米波雷達感測器靠近牆面掃描數秒 → DSP 程式從回波中提取電磁頻譜特徵(類似把聲音轉成頻譜圖再讓 AI 辨識) → CNN 模型比對訓練資料(已含木材、石棉等材質的電磁特性樣本) → 即時輸出材質判斷結果。概念驗證階段已能在多層材料結構上正確分類不同材質;相較於傳統「破壞性取樣+等待」的流程,理論上可達到非接觸、即時、低成本判斷。(注:目前仍為實驗原型,尚未取得商業認證。)

T4
Riverside 以 AI 將播客錄音轉為電子報

Riverside 是一個專門用來錄製 Podcast(播客,就是網路廣播節目)和影片的線上平臺,近期宣佈新增電子報(Newsletter,定期寄給訂閱者的電子郵件文章)發行功能,正式跨入文字內容領域。最核心的亮點是 AI 自動轉換:只要在 Riverside 上錄完一集節目,AI 就能分析對話內容、自動整理出一篇電子報草稿,省去創作者從零打字的功夫。AI 同時也能幫你生成適合發到社群媒體(如 Instagram、X)的宣傳短文,錄影一結束就立即產出初稿。這項功能反映了一個創作趨勢:大多數人開口說話比坐下來打字更自然,想法已經在對話裡了,讓 AI 來完成「說話→文字」的橋接工作,理論上能大幅降低內容創作的門檻。

假設你每週錄製一集關於健身的 Podcast,錄完後通常還需花 1~2 小時把節目重點手動整理成電子報寄給訂閱者。使用 Riverside 新功能後,錄音一結束,AI 會自動把你說過的內容分析整理,幾分鐘內產出一篇結構完整的電子報草稿,附帶可直接發佈到社群媒體的宣傳短文。你只需稍作修改就能寄出,原本耗時兩小時的整理作業縮短至約 10 分鐘。相比過去的做法(自己聽回放記筆記、再重新寫稿),AI 完全省去了重複性的文字轉錄工作,讓創作者能把時間留給下一集節目的準備。

T4
AI 產品 OKR 應測量人類行為

產品顧問 Jeff Gothelf 撰文指出,許多團隊在為 AI 產品制定 OKR(就是「目標與關鍵成果」,一種常見的企業目標管理框架)時,會犯一個根本性錯誤:他們把指標設在「AI 的輸出有多準確」,例如「準確率達到 95%」。但這類指標完全看不出使用者有沒有因為這個 AI 工具真正受益。Gothelf 主張,唯一有意義的 KR(關鍵成果指標)必須是可觀察到的「人類行為改變」,而非機器內部的表現數字,因為同一個 AI 模型面對不同使用者、不同問法,輸出結果差異極大,單靠模型本身的品質分數根本代表不了使用者的實際獲益。他提出三類適合 AI 產品的 KR 方向:第一是「成果型」,觀察使用者是否直接使用 AI 輸出而不大幅修改;第二是「校準型」,觀察使用者對 AI 答案的驗證比例是否下降(代表信任度提升);第三是「信任型」,觀察使用者願意委託 AI 處理的任務種類是否變得更重要。

假設你負責一個「AI 幫企業自動生成週報摘要」的產品,舊的 OKR 可能寫「摘要文字相關性達 90%」。但這個指標你的工程師算得出來,使用者卻根本感受不到。改用 Gothelf 的方法後,你的 KR 可能改寫成:「每月至少有 60% 的週報由使用者不修改直接寄出(原本是 35%)」,以及「點進去逐字核對原文的比例從 50% 降至 25%」。這樣的指標明確告訴你:如果第一個數字上升,代表 AI 產出品質真的讓人放心使用;如果第二個數字下降,代表使用者對 AI 的信任增加了。和舊做法的差異在於:以前你只知道「模型準不準」,現在你知道「使用者有沒有真的省力、有沒有願意依賴它」,兩者之間的落差正是 AI 產品失敗的最常見死角。

T4
生成式UI不適合早期新創

Generative UI(生成式使用者介面)是一種由 AI 即時自動產生畫面和操作元件的技術,每個使用者看到的介面可能都不一樣,會根據當下對話情境動態調整,近來被視為未來軟體設計的方向。然而,有產品人士指出,這個技術目前只適合已有穩定用戶基礎的大型企業,對剛起步的新創公司來說反而是陷阱。關鍵問題在於:新創公司還沒找到「產品市場契合度」(PMF,簡單說就是確認有足夠多的人真的需要這個產品),根本不清楚使用者最核心的需求是什麼,這時讓 AI 自動生成介面,等於是在不確定的基礎上再加一層不確定性。更嚴重的是,當每個使用者看到的畫面都由 AI 動態產生,創辦人就難以透過觀察固定的操作行為來理解客戶、修正產品方向。文章建議:新創公司應先用具體固定的介面驗證商業假設,等確立市場定位後,再考慮引入生成式 UI 提升個人化體驗。

假設你正在開發一個 AI 客服工具,主要幫電商店家自動回覆顧客問題。若採用傳統做法,你設計固定的操作選單:「查訂單」、「申請退款」、「商品規格詢問」三個按鈕,使用者點選後 AI 才回應。這樣你可以清楚看到「70% 的使用者第一步點查訂單」,從中判斷哪個功能最關鍵、要優先打磨。但如果你一開始就引入 Generative UI,讓 AI 每次根據對話脈絡自動生成不同的操作按鈕,那麼每位使用者的畫面都不同、沒有統一的固定元件被反覆點擊,你就失去了從使用行為中學習的能力,更難判斷「產品哪裡做對了、哪裡做錯了」。相比之下,像 Airbnb 這樣的大公司,已透過多年資料確知旅客需要哪些功能,對他們來說 Generative UI 只是在既有元件庫上做個人化呈現,不會影響對用戶需求的掌握——這才是生成式 UI 真正發揮威力的正確時機。