AI Daily Digest

📰 每日 AI 彙整

2026-07-11  ·  共 47 則報導
T1 爆炸重要T2 值得關注T3 一般資訊T4 參考用T5 可略過
T1
T1
xAI推Grok 4.5 對標GPT與Opus

SpaceXAI於2026年7月8日推出新一代大型語言模型Grok 4.5,馬斯克將其定位為「Opus等級」模型(Opus是Anthropic旗下Claude系列的頂級型號),聲稱效能可與Claude Opus匹敵,但速度更快、成本更低。定價為每百萬輸入token 2美元、輸出token 6美元。

官方定價每百萬輸入token 2美元、輸出token 6美元,相較Anthropic的Claude Opus 4.7(輸入5美元/輸出25美元)便宜許多,SpaceXAI並宣稱其token效率是其他領先模型的兩倍。在基準測試方面,官方數據顯示Grok 4.5與競爭對手的頂尖模型具有競爭力,但略遜於最佳成績。馬斯克在X上發文補充,其內部評估認為Grok 4.5與Opus 4.7性能相當,但速度更快。

T2
T2
博科聖地涉AI使用

有關奈及利亞恐怖組織博科聖地使用生成式AI的報導,具體內容待確認。

目前無確切資訊說明其使用方式。

T2
GPT-5.6成Office Copilot預設模型

OpenAI宣佈最新旗艦模型GPT-5.6(可以理解為ChatGPT背後那套會讀寫文字、分析資料的AI引擎的最新版本),現在成為微軟365 Copilot(就是內建在Word、Excel、PowerPoint等辦公軟體裡、能幫你寫文件、做簡報、分析數據的AI助手)的預設模型。這代表原本已經在用微軟Office Copilot的一般上班族,不需要自己動手升級,系統會自動改用這個更新、更強的模型來處理請求。微軟方面表示這次更新讓使用者能用更少的來回提問(prompt,也就是你打字跟AI下的指令)就得到更完整的成品。OpenAI則強調GPT-5.6在效能與成本效益(同樣花費能做更多有用的工作)上有提升,並支援複雜任務時可以按需求調用更強能力。

假設你是行銷部門的員工,要用Excel整理一季的銷售數據並找出成長最快的產品線。過去用舊版Copilot可能要先問一次「幫我整理這份資料」,再問「哪個產品成長最快」,反覆調整提問才能拿到能用的結果,而且處理大量資料時常常要重新下指令才會抓對重點。換成GPT-5.6之後,微軟表示同一個分析請求能用更少的token(可以理解為AI處理文字的計費單位,愈少代表愈省成本、通常也代表AI一次就抓到重點)跑出更深入的分析,讓你更快從原始數字看到「哪個產品線在成長」這種洞察,而不用像以前一樣分好幾輪對話慢慢問出答案。PowerPoint、Word、Cowork(微軟的協作工具)等其他Office應用也會同步套用同一顆模型,做簡報、寫文件時同樣能減少人工調整的步驟。

T2
螞蟻開源具身原生機器人大腦

中國螞蟻集團旗下的機器人團隊「靈波」發布並開源了 LingBot-VA 2.0,這是全球第一個「具身原生」的 VA(Video-Action,影片-動作)預訓練模型,可以理解成是專門給機器人設計的「大腦」。過去很多機器人模型是拿現成的影片生成模型(在數位世界訓練出來的)改造後硬套到機器人身上,這次螞蟻靈波則是從第一天訓練起,架構、資料、訓練目標就全部針對真實物理世界的機器人任務設計,而不是事後改裝。這個模型的核心能力是「預判式控制」:機器人不是看到什麼就反應什麼(反應式控制),而是像人一樣一邊觀察物體現在的位置和運動軌跡,一邊在腦中預測幾步之後的畫面會變成什麼樣,提前把身體動作規劃好。官方公佈的數據包括:雙臂機器人任務成功率達到93.6%,在單張 GPU 上推理(也就是模型即時運算做決策)速度可達每秒150次,模型內部用了「因果 DiT + 稀疏 MoE」這種只啟動部分參數運算的架構(MoE,Mixture of Experts,一種讓大模型只喚醒一小部分神經網路來運算、藉此兼顧聰明和速度的技術),讓大模型也能跑得夠快、跟得上機器人即時動作的節奏。

假設你要用機器人做「打乒乓球或冰球對打」這種任務:球速快、軌跡一直在變,如果機器人只用傳統的反應式視覺系統(看到球在哪就立刻反射性地伸拍),大概率會因為反應延遲而漏接、被打敗。用 LingBot-VA 2.0,模型會持續追蹤球的運動軌跡,同時在內部推算幾步之後球會飛到哪個位置,提前調整機器人手臂的姿勢和揮拍時機,讓打擊動作和球的實際落點對上。官方展示的另一個真實測試是「傳送帶抓取」:物體在傳送帶上不斷移動,機器人要抓的不是靜止目標,傳統工業做法通常要靠額外的光電感測器或編碼器來抓時間點同步,而 LingBot-VA 2.0單靠影像預測,就能算出抓取動作完成那一瞬間物體會移動到哪裡,提前把抓取的時間差算進去,實測完成同步抓取。另外還有「整理雜亂桌面」的長時間任務測試,機器人要記住自己已經收拾到哪一步、雙臂分工不打架,最終順利完成全桌整理,證明它在長時間、多步驟任務上不會中途「斷片」忘記進度。

T2
蘋果研議iPhone跑更大AI模型

蘋果被爆出正在和一家叫 PrismML 的新創公司開會,討論怎麼把「更大的」AI模型直接塞進iPhone裡運算,而不是丟到雲端伺服器算。目前蘋果自己的手機端模型叫 AFM 3 Core Advanced,有200億個參數(參數可以想成模型的「腦細胞數量」,數字越大通常代表模型能力越強,但也越耗運算資源),採用「稀疏架構」,意思是雖然模型很大,但每次運算只會啟用其中10億到40億個參數,藉此省電省效能。PrismML 展示的技術則是把阿里巴巴的開源模型 Qwen 3.6(270億參數,比蘋果自家模型還大)整個塞進iPhone 17 Pro裡跑,而且是270億個參數「全部同時啟用」,沒有稀疏化。如果蘋果真的採用這類技術,未來iPhone上的Apple智慧型功能(例如Siri語音、聽寫)就能有更多項目直接在手機本機端運算,不用把資料傳到蘋果的雲端伺服器(Private Cloud Compute)處理,這樣既能省下蘋果的雲端運算成本,也能讓使用者的個人資料更不容易外流,提升隱私。

舉例來說,蘋果現在的AI聽寫功能(就是講話直接轉成文字)跑在AFM 3 Core Advanced這個200億參數、但每次只啟用10億到40億參數的「省電版」模型上,效果有限;如果換成PrismML的技術,讓iPhone直接扛住Qwen 3.6這種270億參數、且全部參數同時運作的「重量級」模型,聽寫或Siri語音的準確度、表達自然度理論上可以更接近雲端大模型的水準,但使用者的錄音內容完全不用上傳到蘋果伺服器,直接在手機裡處理完就好。差別在於:現行做法是「小模型在手機跑、遇到複雜任務丟雲端」,新做法則是「連複雜任務也能整個留在手機裡跑」,對蘋果來說省了雲端主機的電費和頻寬成本,對使用者來說則是資料不出手機、更安心。

T3
T3
UST攜手Claude導入實體AI產線

Anthropic 宣佈與科技工程服務公司 UST 合作,把 Claude(Anthropic 出的 AI 模型)導入「實體 AI」(physical AI,也就是把 AI 用在晶片、汽車、工廠設備這類實體產品的設計與生產流程,而不只是聊天或寫文章)。UST 平常幫半導體、汽車、製造、電信等產業客戶打造驗證晶片設計、跑工廠、維修產品的系統。這次 UST 會訓練全球兩萬名工程師、架構師和顧問使用 Claude,並把 Claude 整合進自家四個平臺:晶片驗證平臺 iDEC、醫療平臺 CarePath、電信網路維運平臺 IntelliOps,以及銀行系統 FinX。核心賣點是讓 Claude 讀懂晶片線路圖和硬體規格書,自動寫測試、跑測試,取代工程師手動撰寫測試腳本的繁瑣流程,藉此提早抓出設計瑕疵、加速驗證速度。

以晶片驗證平臺 iDEC 為例:工程師要確認一顆新設計的晶片是否真的照設計運作(叫做驗證),傳統做法是工程師自己寫測試腳本、手動跑、讀結果,覺得哪裡不對再改腳本重跑,一輪一輪來回,通常要花四天才能跑完一輪驗證。iDEC 原本已經用自動化管線(先讀硬體設計,自動產生並執行迴歸測試,再拿設備實際跑出來的資料去跟一個叫「數位孿生」的軟體模型比對,數位孿生就是用軟體模擬這顆硬體「應該」怎麼運作,藉此看有沒有異常)把四天壓縮到 48 小時,速度提升 50% 到 70%。這次導入 Claude Code 後,Claude 直接讀懂晶片接腳圖和電路圖,自己寫並執行迴歸測試(也就是確認一次設計改動沒有意外影響到其他部分的測試),也負責比對即時設備數據和數位孿生,抓出韌體異常和訊號完整性問題,目標是連手動寫測試腳本這一步都省掉,讓瑕疵更早被抓到,工程師不用額外學新工具。

T3
歐盟通過聊天監控爭議法案

歐洲議會近期通過了一項延長訊息掃描權限的法案,具體表決數字尚需進一步核實。據瞭解,這項法案將2021年通過、原本只是過渡性質的CSAM(兒童性剝削影像)掃描豁免延長到2028年,允許Gmail、Instagram、Snapchat、Discord等平臺自願掃描使用者的私人訊息,而WhatsApp這類端對端加密(E2EE)的服務則不受影響。歐盟委員會自己的評估報告承認,現有負責抓出違法內容的AI系統誤報率高達20%,但真正抓到的違法內容比例只有0.00000077%,等於絕大多數被標記的使用者其實是無辜的。更關鍵的一場硬仗訂在2026年9月:如果屆時通過的Chat Control 2.0把掃描從自願改成強制,端對端加密平臺將被迫在裝置本地(也就是訊息加密前)安插AI掃描程式,直接衝擊蘋果、Google、Meta等公司的加密架構設計,也會帶動一波做內容審核用AI模型的新需求。

假設你正在歐洲市場開發一款通訊軟體,現在的做法是:如果你的產品是端對端加密(像WhatsApp那樣,訊息在使用者手機裡就加密好,公司伺服器完全看不到內容),依照這次通過的Chat Control 1.0,你目前不需要做任何改動,可以繼續維持現狀到2028年。但如果你的產品跟Gmail、Instagram一樣不是端對端加密,你可以選擇「自願」串接像PhotoDNA這種比對資料庫(用來比對是否為已知違法影像的雜湊值系統)來掃描使用者私訊,一旦選擇加入,就要另外建立人工審核流程,因為AI誤判率有20%,會有大量正常使用者被誤標。真正的分水嶺在9月的Chat Control 2.0談判:如果那次改成強制規定,端對端加密的產品就必須在使用者手機端(訊息加密之前)塞入一套AI掃描模型去做「用戶端掃描」,這代表你的App架構要整個重做,而不是像現在只是「要不要自願加入」的選擇題。

T3
PentAGI:全自動AI滲透測試平臺爆紅

PentAGI 是一套在 GitHub 上爆紅、累積超過 1.9 萬顆星的開源專案,功能是讓 AI 自動幫企業做「滲透測試」(也就是資安人員假扮駭客、合法攻擊自家系統找漏洞的檢測工作)。它不是單一個 AI 在做事,而是由一個「總指揮」Agent(Agent 就是能自己規劃步驟、呼叫工具去完成任務的 AI 程式)分派給三個各司其職的 AI:負責蒐集漏洞情報的 Researcher、負責規劃攻擊策略的 Developer,以及在隔離環境裡實際執行攻擊指令的 Executor。所有操作都在 Docker(一種把程式包成獨立小盒子執行的技術)打造的沙箱裡進行,裡面預先裝好 nmap、Metasploit、sqlmap 等 20 多種專業駭客工具,就算真的執行了危險指令也不會傷到真實電腦。它可以完全架在企業自己的機器上(不用把資料交給外部雲端公司),甚至能在「氣隙環境」(跟外部網路完全斷開、常見於政府或金融機構的高安全系統)裡運作,只要搭配一顆最小 27B 參數的本地 AI 模型(不用連網、不用付雲端 API 費用)就能跑起來。

假設一家公司想檢查自己的網站有沒有資安漏洞,過去做法是找資安顧問公司,人工花數天用 nmap 掃連接埠、用 sqlmap 手動測試每個輸入欄位有沒有 SQL Injection(一種駭客把惡意指令偽裝成資料塞進網站、藉此偷資料庫內容的攻擊手法),再手寫報告。用 PentAGI 的話,資安人員只要在網頁介面用白話文輸入一句指令,例如「檢測 https://target.example 這個網站常見的網頁漏洞,重點看登入驗證、檔案處理、注入攻擊,只能測這個目標,最後給我確認過的漏洞清單和重現步驟」,接著 Orchestrator 就會自動把任務拆給 Researcher 去查已知漏洞情報、Developer 規劃怎麼攻、Executor 在 Docker 沙箱裡實際下指令測試,過程全自動跑完後直接產出一份可下載成 PDF 或 Markdown 的漏洞報告,附上每個漏洞的重現步驟。有資安從業者在社群分享,他用 PentAGI 搭配另一套工具測試 React 網頁應用時,AI 找出了其他工具全部漏掃的一個 SQL Injection 漏洞,等於用自動化把原本要靠資深工程師經驗才抓得到的漏洞給揪出來了。

T3
Auriko:LLM呼叫智慧路由平臺

Auriko 是三位前量化交易員做的新平臺,把不同的 LLM(大型語言模型,就是 ChatGPT、Claude 這類會對話的 AI)供應商,當成金融市場裡的「交易場所」來看待,目的是幫開發者用最划算的路徑呼叫這些 AI 模型。它的核心功能叫「預請求路由」:每次程式要呼叫 AI 之前,系統會先比較各家供應商當下的價格、速度、穩定度,自動選一條最省錢又夠快的路線,官方宣稱平均能省下約 30% 費用,而且平臺本身不額外抽成。它特別強調「快取感知路由」——快取(cache)是指 AI 已經先幫你算好、暫存起來的部分內容,重複使用可以省錢,但如果為了省一點小錢頻繁換供應商,反而會讓這個暫存失效、變得更貴;Auriko 會持續評估「現在換供應商劃不划算」,只在真的划算時才切換。它相容 OpenAI、Anthropic 等主流 AI 開發框架,開發者只要改一行程式設定就能接入,資料存放在歐盟,適合注重資料隱私的歐洲企業。

假設有個團隊在做一個「寫程式的 AI 助理」(coding agent),這種助理常常要跟同一個 AI 模型來回對話很多輪,每輪都會帶著前面的對話紀錄、工具說明等大量重複內容一起送出去,如果每次都重新計算這些內容,費用會很高;這時候利用「快取」讓 AI 供應商記住這些重複部分、不用重算,能省下不少錢。但如果團隊用一般的「省錢路由工具」,這類工具只看當下哪家供應商比較便宜就切換過去,反而會讓原本已經「熱好」的快取失效,讓下一次呼叫要整個重新計算,實際上更貴。Auriko 的做法是:呼叫前先估算「如果換供應商,快取會不會泡湯、換算下來到底劃不划算」,如果原本的供應商快取還熱著,即使對手當下報價便宜一點點,Auriko 也會選擇留在原供應商;只有在真正對整個對話成本更有利時才切換。團隊因此能兼顧「省錢」和「不因換供應商而讓快取失效多花錢」這兩件事,而不是像舊工具一樣顧此失彼。

T3
新創讓AI Agent操盤自家募資案

AI Agent(可以自己執行多步驟任務的AI程式,不只是聊天回答)新創公司 Lyzr,讓自己開發的 Agent「SivaClaw」去執行公司 1 億美元 B 輪募資的前期工作,包括接待超過 130 位投資人的提問、自動寫投資備忘錄(investment memo,就是投資人評估要不要出錢的正式文件,內容涵蓋商業模式、財務預測和風險分析)、追蹤投資人看簡報時在哪一頁停留最久,以及主動聯繫早期潛在投資人。這輪募資吸引矽谷、中東與金融業合計超過 4 億美元的意向出資,換算公司估值約 5 億美元,但截至報導時這輪募資還沒正式敲定(close),金額和估值都是公司自己對外說的,沒有具名的領投方出面確認。創辦人 Anirudh Narayan 說:「Agent 負責開啟對話,最終成交還是要靠人完成。」值得注意的是,Lyzr 目前年度經常性收入(ARR,就是公司每年穩定可預期的營收)大約只有 150 萬美元,跟 5 億估值相比等於本益比高達 300 多倍,屬於風險極高的早期階段。

假設一家新創要募資,傳統做法是創辦人自己一一約投資人喝咖啡、口頭簡報、事後手動整理備忘錄、追蹤誰對哪張投影片有興趣。Lyzr 的做法是:先讓 Agent 在正式對外募資前跑超過一萬次模擬測試,練習應對各種投資人提問情境;正式募資時,Agent 直接接待 130 多位投資人的提問、自動生成投資備忘錄初稿、記錄每位投資人在簡報哪一頁停留最久(藉此判斷對方最在意什麼),並主動去聯繫早期潛在投資人開啟對話。跟開源的 LangGraph(需要自己架設基礎設施)或 Salesforce 的 Agentforce(封閉系統、綁定單一廠商)相比,Lyzr 主打資料所有權掌握在客戶手上、以及針對受監管產業(如金融)的防護欄設計。但因為 Lyzr 自己 ARR 只有 150 萬美元,代表這套系統目前真正被其他企業大規模採用、驗證過的案例還很有限,若其他公司想跟進採用,得先評估這套平臺是否夠成熟穩定。

T3
PyTorch剖析注意力機制效能

Hugging Face 發表「Profiling in PyTorch」系列第三篇教學,主題是用效能剖析工具(profiler,就是幫你看電腦跑程式時每個步驟花多少時間、用了哪些硬體資源的工具)來檢查 Transformer 模型(現在多數 AI 語言模型的核心架構)裡最關鍵的運算「注意力機制」(attention,讓 AI 判斷一句話裡哪些字詞該互相參照的計算方式)到底跑得快不快。文章帶讀者一步步比較:自己手寫的簡陋版注意力運算、PyTorch 內建的一行指令 SDPA(Scaled Dot Product Attention,一個會自動幫你挑選最快運算方式的函式)在不同底層方案(math、efficient、flash、cuDNN)下的表現差異。結論是同樣的注意力計算,選錯底層方案效能可以差到 3.7 倍,而且有些指標(例如 GPU 使用率)表面上看起來「跑得很爛」,其實反而是最快的方案,因為它把資料盡量留在晶片內、減少搬到主記憶體來回的次數。這篇文章的價值在於教會工程師如何正確解讀效能剖析工具的數字,而不是被表面數字誤導。

假設一個工程師在訓練或執行一個處理長文章的語言模型,發現速度比預期慢,想知道問題出在哪。照這篇文章的做法,他會先用 PyTorch 內建的 profiler 錄一段程式執行過程,攤開來看 CPU 和 GPU 分別在做什麼。舉例來說,把手寫的注意力計算裡一行 masked_fill(把某些位置的分數蓋成負無窮大,用來擋住模型看到未來的字)改成 masked_fill_(多一個底線,代表「直接原地修改」而不是「複製一份再修改」),結果 profiler 顯示 GPU 上少了一個「記憶體複製」的運算步驟,省下的時間在多層模型中會累積成可觀的效益。另外,如果直接呼叫 PyTorch 內建的 SDPA 函式卻沒指定用哪個底層方案,系統可能選到最保守但最慢的 math 方案,跑出來的時間比精心優化過的 flash 方案慢上好幾倍;工程師可以透過強制指定用 flash 或 cuDNN 方案,讓同一段程式碼跑得更快,而不需要重寫任何演算法邏輯。

T3
逐行解析JEPA自監督架構

這篇文章是一篇非常詳細的技術教學,逐步拆解並用程式碼重建「JEPA」(Joint Embedding Predictive Architecture,一種由 Meta AI 首席科學家 Yann LeCun 提出的自我監督學習(就是不需要人工標註答案、讓 AI 自己從資料中找規律的訓練方式)架構)。作者仿照經典教材《The Annotated Transformer》的寫法,把理論、數學公式和 PyTorch(一套常用的 AI 模型開發工具)程式碼並排呈現,方便讀者從零讀懂整個系統。內容涵蓋 JEPA 的核心想法:AI 不是去猜測圖片裡每個像素的細節,而是在「語意空間」(把圖片內容濃縮成代表意義的一串數字,而非還原每個畫素)裡做預測,藉此避免浪費算力在無關緊要的雜訊上。內容也涵蓋如何避免訓練過程「偷懶」而讓所有輸出都變成同一個答案(稱為 collapse,崩塌問題),以及 I-JEPA、V-JEPA、V-JEPA2、LeJEPA 等不同版本的差異與演進。

假設一個研究團隊想訓練一個 AI 去理解圖片內容,但手上沒有大量人工標註的資料(例如沒有人幫每張圖片寫「這是一隻貓」這種標籤)。傳統做法是用「自編碼器」硬要 AI 把圖片的每個像素都重建出來,結果 AI 會把力氣花在陰影、雜訊、壓縮失真這些沒意義的細節上,反而學不到「這是一輛車」這種真正重要的語意。I-JEPA 的做法是,AI 只需要看到圖片的一部分(例如車頭),去預測被遮住的其他部分(例如車輪)在「語意空間」裡的表示方式,而不是預測像素本身。因為要猜對車輪的語意表示,AI 被迫學會「這是一輛車」這種抽象概念,而不是死記表面像素。文章附上完整可執行的 PyTorch 程式碼,讀者可以直接照著重建一個能訓練的 JEPA 模型,而不只是看理論。

T3
德國電信用ChatGPT全面轉型

德國電信(Deutsche Telekom,歐洲最大電信公司之一,服務超過3億用戶、員工逾20萬人)正在跟OpenAI合作,把自己打造成「AI原生」(AI-native,意思是把AI當成重新設計整個公司運作方式的核心,而不是裝在舊流程上的小工具)電信公司。據報導,第一階段讓員工取得ChatGPT Enterprise(企業版ChatGPT)的存取權,鼓勵員工嘗試。AI工具整體使用量自2026年初以來成長了546%,每月有超過5萬名員工使用ChatGPT及相關API工具。接著他們把AI導入客服、網路資源即時調度(例如尖峰通勤或大型體育賽事時動態調整基地臺資源),以及正在研發把AI直接嵌入通話功能,例如通話即時翻譯、通話中AI助理、通話後自動摘要,讓客戶不需要額外下載App就能用到AI功能。

假設一位在德國的用戶打電話到客服詢問帳單問題:以前可能要經過多次轉接、等候、跟客服人員重複描述問題;德國電信導入AI後的目標情境是,客服系統一開始就能掌握用戶歷史紀錄和情境,減少轉接和等待時間,逐步朝著能超越傳統人工客服品質的方向發展。另一個例子是通話翻譯:未來德國電信用戶打電話給不同語言的對象時,AI可以在通話過程中即時翻譯雙方對話、通話結束後自動生成摘要,讓客戶不用額外安裝翻譯App或做筆記,直接在既有的打電話這個動作裡就用到AI能力,這跟過去「AI功能都要另外開一個App使用」的做法明顯不同。

T3
許錦波團隊MoleculeOS正式開放

中國學者許錦波的團隊「分子之心」,在2026上海國投前沿論壇上,正式向產業界開放一套叫做MoleculeOS的系統。過去AI在生物研發裡只是「單點工具」,例如只負責預測蛋白質的立體結構、或設計抗體,科學家還是要自己手動把各種工具串起來用。MoleculeOS想做的是把AI從「工具」升級成「操作系統」:研究人員只要輸入研發目標(例如「提升某抗體的親和力」,親和力簡單說就是這個抗體跟目標分子結合的緊密程度),系統就會自動拆解任務、依序呼叫底下一整套自研AI模型完成結構預測、分子設計、多維度評估,並給出候選分子的建議,還會把整個過程記錄下來方便之後複查、複用。許錦波是蛋白質結構預測領域的早期學者之一,2016年就提出相關方法,被視為AlphaFold(Google旗下DeepMind開發的知名蛋白質結構預測AI)等模型的重要方法學開創者之一。

以文中舉的免疫檢查點抗體優化專案為例:研究人員只需要輸入「靶點」(要瞄準的目標分子)和研發目標,MoleculeOS就會自動完成候選分子生成、結構預測、多維度評估與推薦這一整串流程。文章指出,傳統做法需要多名研究人員跨工具協作、耗時數週才能完成的工作,用MoleculeOS可以壓縮到數小時;算完之後結果還能一鍵分享給做濕實驗(真正在實驗室拿試劑、細胞做實驗,相對於電腦上跑模型的「乾實驗」)的團隊,附上完整計算過程與視覺化分析,不用再靠人轉述數據。另外文中提到,其結構預測模型MMFold在FoldBench基準測試中,針對172個抗體-抗原界面達到68.6%的預測成功率,官方稱相較AlphaFold3等主流模型有明顯領先;抗體從頭設計平臺則在12個靶點測試中,平均每個靶點只需測試不到50個候選分子,靶點成功率就超過90%。

T3
百度搭子智能體升級並推企業版

百度旗下的通用型AI智能體(agent,就是能幫你理解目標、自己拆解任務、操作各種工具去完成事情的AI助手)「百度搭子」宣佈重大升級。官方數據顯示,上線以來每天被提問的次數暴增了20倍,是目前成長最快的同類產品。這次升級主要針對個人版,加強了辦公、資料整理、簡報製作等功能,同時第一次推出給企業用的「企業版」,讓整個團隊能共用這個AI助手來協作、累積公司資產。

舉例來說,如果你要做一份市場競品調查加一份簡報,過去得自己開好幾個瀏覽器分頁搜資料、複製貼上整理重點、再開PPT一頁頁排版配圖。用升級後的百度搭子,你只要把任務目標講清楚,它就能像人一樣自動打開網頁、點擊連結、跳轉頁面去檢索和整理資料(而且過程會顯示給你看,不是黑箱作業),官方說平均任務耗時降低了20%。做到一半的報告,也能從電腦切到手機繼續追問、修改或下載,不必重新開始。做簡報時,AI 會從範本庫、配圖、排版、圖表到大綱一併處理,直接產出接近可以拿去交差的成品,而不是還要自己重新排版的半成品。企業版則額外讓公司把員工做出來的方案、資料、技能沉澱成整個組織可以共用的資產,並管理誰能用哪些功能。

T3
歌歌AI從零訓練華語唱歌模型

中國新創「歌歌AI」發表了一個從零開始預訓練(不是拿英文模型微調,而是完全重新訓練)的十億參數華語音樂生成模型。過去主流AI音樂模型(例如做歌曲生成的AI系統)幾乎都是先為英文設計,直接套用來唱中文歌時,常會出現咬字不清、拖音怪異、聽起來像「機器人硬湊」的問題,原因是中文有聲調(同音不同調意思完全不同,例如「媽」和「罵」)、字與字之間界線分明、字音跟節拍的對應也和英文差很多。歌歌AI設計了三項技術:讓人聲和伴奏各走一條生成路線再即時對齊、先標好每個字的發音該落在哪個時間點以穩定咬字、以及用一套機制讓「情緒」「曲風」等設定能從頭到尾貫穿整首歌不跑掉。更特別的是,歌歌AI已與字節跳動(TikTok母公司)達成版權分成合作,讓用它生成的歌曲可以合法上架抖音、剪映、汽水音樂等平臺並分潤,同時啟動了一個專門收錄秦腔、評彈琵琶、葫蘆絲、嗩吶等傳統民樂真人演奏聲音的計畫,用來訓練專屬的民樂AI模型。

假設一位短影音創作者想幫自己的中文旅拍影片配一首原創國風歌曲。過去用市面上多數AI音樂工具(多半是英文模型改造的),輸入中文歌詞後常聽到「咬字模糊」「拖音拖錯地方」的違和感,做出來的歌即使能聽也很難商用,因為版權歸屬不明、也沒有正式的發布通路,充其量只能發朋友圈自娛自樂。改用歌歌AI的話,創作者輸入歌詞、指定風格情緒與歌手音色,系統會直接零樣本(不需另外訓練,直接生成)產出長達3分鐘、人聲與伴奏分軌俱全的完整立體聲歌曲,咬字對齊準確、情緒表達也更貼近中文歌詞的含蓄語感;生成完的歌曲還能直接合規上架抖音、汽水音樂等字節系平臺,若被其他創作者拿去做短影音配樂或翻唱,創作者能依平臺播放與付費分潤實際拿到版稅,而不只是做完就沒有下文的玩具作品。

T3
編排層優化可省四成AI代理成本

這篇研究在講的是「AI代理」(agent,就是能自己規劃步驟、呼叫工具去完成任務的AI程式)背後的「編排層」(orchestration harness,可以想成是指揮AI一步步做事的調度系統,決定它何時查資料、何時呼叫工具、怎麼組織思考流程)有多重要。研究團隊用六個不同的基礎大型語言模型(包括Claude Sonnet 4.6、Gemini 3.1、Qwen 3.6、GLM 5.1等)跑了22項評測任務,模型本身不變,只調整背後的編排調度方式。結果發現,光是優化編排層,就能讓每個任務的成本平均降低41%,用掉的token(可以理解成AI處理文字的計費單位)減少38%,完成任務所花的實際時間中位數縮短44%,而且完成品質沒有下降。更有趣的是,這種「省錢省時」的效果對每一種模型都差不多有效(省33%到61%),但「品質提升」的幅度則和模型本身能力強弱幾乎完全成正比(相關係數高達0.99),研究團隊把這個現象稱為「編排槓桿效應」。

假設一家公司同時在用好幾種不同的AI模型跑客服自動回覆、程式碼審查、資料整理等各種AI代理任務。過去大家把心力主要放在「換更強的模型」上,以為換了更貴的模型就能又快又好。這篇研究說明另一條路:與其到處換模型,不如先把「編排層」(也就是決定AI何時查詢工具、何時分段思考、怎麼呼叫外部資源的那套調度邏輯)打磨好,因為同樣的優化可以套用在公司內部用的每一種模型上,等於是一次投資、全部模型受惠——原本用普通模型也能省下三到六成的運算成本和時間,而不需要逐一為每個模型重新設計流程。

T3
換編排層可省41% AI任務成本

這則是一連串AI代理(agent,也就是能自己拆解任務、呼叫工具、連續執行多個步驟的AI程式)開發工具更新的整理。其中最值得注意的是一項研究:只是把「編排層」(orchestration layer,白話說就是負責指揮多個AI步驟先做什麼、後做什麼、怎麼串接的調度系統)換掉,其他都不變,就能讓完成同一個任務的綜合成本降低41%、耗用的token(AI處理文字的計價單位,可理解成AI的「用量計量單位」)減少38%、任務完成所需的實際等待時間(wall-clock,即從開始到結束的真實時間)縮短44%,而且輸出品質沒有下降。除此之外,LangChain旗下的LangSmith推出把Claude Code(AI寫程式代理)的執行過程完整記錄下來、方便事後追蹤除錯的功能;權重與偏誤平臺W&B則在內部推出叫ARIA的AI研究改進代理,它會自動讀取實驗紀錄、提出假設、發起新實驗並和基準結果比較評分;另外還有人推出SkillCenter,是一個給AI代理下載、管理「技能」(skill,可理解成代理能呼叫的功能模組)的套件索引平臺。

假設一家公司原本用某套AI代理系統處理客服工單分類、查資料、寫回覆這一連串任務,用的是預設的編排層(負責決定「先查資料庫、再組回覆」這種步驟順序與呼叫邏輯的模組)。這篇提到的研究顯示,光是把這個編排層換成更有效率的版本,不改AI模型本身、不改任務內容,同一批工單處理下來,公司要付的AI用量費用就能省下41%,AI總共要處理的文字量(token數)減少38%,而且整批工單跑完的實際耗時也縮短44%,回覆品質跟原本一樣好。對比舊做法,公司要省成本通常得換更便宜、但可能較笨的AI模型,品質會打折;這裡展示的是「模型不變、只調整背後的調度方式」就能同時省錢、省時間又不犧牲品質。

T3
Reachy Mini開源語音方案省9成成本

Hugging Face(一家做開源 AI 工具和模型的公司)推出的桌上型小機器人「Reachy Mini」,目前已出貨 9000 臺,這些機器人每個月加起來會產生 1.5 萬小時的語音對話。如果全部使用 OpenAI 的 GPT-realtime(一種可以即時語音對話的 AI 模型服務,通常照使用時數收費)來處理這些對話,每個月要花 4.5 萬美元。於是 Hugging Face 團隊自己開發了一套開源(原始碼公開、任何人都能免費取用修改)的替代方案,把成本壓到每小時只要 0.25 美元,而且只要改一行程式碼就能從原本的 GPT-realtime 換過去,甚至可以直接在自己的筆記型電腦上免費跑,不用付雲端費用。

假設一家新創公司要做一款會語音對話的桌面機器人,出貨量做到跟 Reachy Mini 一樣,每月 1.5 萬小時對話。如果直接串接 OpenAI 的 GPT-realtime API,每月要付 4.5 萬美元的語音對話費用,對小公司是很大的固定成本負擔。改用 Hugging Face 開源的這套語音方案後,成本降到每小時 0.25 美元,等於 1.5 萬小時只要約 3750 美元,是原本的十分之一不到;而且遷移只需要改一行程式碼,甚至能整套跑在自己筆電上完全免費,不必依賴外部 API,這對預算有限、又想自己掌控技術的團隊是實際可用的省錢方案。

T3
fal揭密影像生成0.45秒推理術

AI 影像生成新創公司 fal 發布了一篇系列文章的第二篇,講解他們如何把圖片生成系統的推理(inference,就是 AI 產生圖片的運算過程)壓縮到只要 0.45 秒。文章聚焦在 diffusion pipeline(擴散模型的生成流程,也就是 AI 從一片雜訊逐步「洗」出一張清晰圖片的整套運算步驟)該怎麼優化。他們用了三種技術:kernel optimizations(針對 GPU 底層運算指令做客製化調校,讓晶片跑得更有效率)、quantization-aware distillation(量化感知蒸餾,簡單說就是讓模型在訓練時就先適應「用較少位元數存數字」的環境,這樣壓縮模型體積後畫質才不會掉太多)、以及 timestep distillation(時間步蒸餾,讓原本需要一步步慢慢生成的擴散模型,用更少的生成步驟就能出圖)。這篇文章屬於系列文章第二部,第一部的具體內容原始素材未提及,暫無法得知。

假設一家公司想在自家 App 裡做「輸入文字、幾秒內生成一張圖」的功能,用一般沒優化過的擴散模型,生成一張圖可能要好幾秒甚至十幾秒,使用者會覺得等待很煩、伺服器成本也高(因為 GPU 佔用時間長)。fal 這篇文章示範的做法是:先用 quantization-aware distillation 讓模型變小(減少要跑的運算量),再用 timestep distillation 減少生成步驟數(例如讓原本需要多步的流程縮減到少量步驟就能出圖),最後再用客製化的 kernel optimizations 讓每一步在 GPU 上跑得更快。三管齊下後,fal 的系統可以在極短時間內完成一次圖片生成的推理,比起沒優化前的做法,等待時間跟運算成本可望大幅下降。

T3
vLLM 推理加速並辦首屆大會

vLLM(一套讓大型語言模型「推論」時跑得更快、更省資源的開源軟體,很多公司拿它來上線服務 AI 模型)新增了一種叫「隔離參考詞元注意力」(isolated reference-token attention,簡單說就是讓模型處理『參考圖片/參考文字』時更有效率的一種內部運算方式)的功能,用在 Krea2 這個編輯模型的訓練上。官方公佈的測試時間顯示,靠著 KV caching(一種把模型算過的中間結果暫存起來、下次不用重算的加速技巧),處理 3 個參考項目的時間從 31.63 秒縮短到 10.90 秒,等於快了將近 3 倍。同時,vLLM 官方也宣佈將在 8 月 24 到 26 日於舊金山的 Ray Summit 期間,舉辦首屆「vLLM Conference」,這也顯示開源推理框架仍是整個 AI 生態圈裡很重要的一環。

假設我的公司要用 Krea2 這類圖片編輯模型,讓使用者上傳好幾張參考圖後 AI 依樣修改新圖,過去每次生成都要重新處理這些參考圖,等 3 張參考圖跑完要 31.63 秒,使用者體驗很卡。升級到 vLLM 這次加的隔離參考詞元注意力搭配 KV caching 後,同樣 3 張參考圖只要 10.90 秒,等於使用者少等 20 秒以上,對需要即時互動的編輯工具來說差異非常明顯。另外,vLLM 官方公佈 8/24-26 在舊金山 Ray Summit 期間辦首屆大會,講者包含 Inferact、NVIDIA、AMD、Google TPU、Anyscale、PyTorch、Meta、Red Hat 等,若我是負責維運公司 AI 推論服務的工程師,這是一個可以直接跟這些廠商工程師交流架構問題的場合。

T3
Perceptron推出具身標註系統

新創公司Perceptron推出了一套叫做Egocentric的「具身推理標註系統」(用來幫機器人或AI理解影片中身體動作的自動標記工具,例如標出「哪隻手在做什麼動作」「動作從哪裡開始到哪裡結束」)。這套系統號稱表現超越目前用Gemini 3.5 Flash和Gemini Robotics-ER 1.6(都是Google的AI模型)打造的最佳標註流程,達到SOTA(State of the Art,也就是目前業界最強的意思)。它的最大賣點是成本,比起請人工一段一段標註影片,便宜10到15倍。目前先開放給合作夥伴做早期試用。同一則新聞也提到Google Research發表了SensorFM,這是一個用穿戴裝置感測器資料訓練出來的AI基礎模型(用大量原始感測數據訓練、之後可套用到不同任務上的通用AI)。

假設一家機器人公司要訓練機器人學會「摺衣服」這個動作,過去做法是僱用大量標註員,一幀一幀看影片、手動寫下「左手在第3秒開始抓衣角」「右手在第5秒開始摺」這類標籤,這個過程又貴又慢,而且不同標註員標的標準還可能不一致。改用Perceptron Egocentric之後,系統會自動分析第一人稱視角(也就是像機器人或戴攝影機的人自己看出去的視角)的影片,自動產生子任務的起訖點、左右手各自在做什麼動作、以及密集的動作標籤,不需要人工逐幀標記。根據測試,在WGO-Bench這個評測項目上,端到端的F1分數(一種同時衡量「抓得準不準」和「抓得全不全」的綜合分數,越高越好)從人工搭配Gemini模型的0.158提升到0.280,等於進步了77%,而且成本只要人工標註的十分之一到十五分之一。

T3
GPT-5.6助一人完成百萬行數學證明

OpenAI 的研究員 Boris Alexeev 用新一代模型 GPT-5.6,把「厄多斯單位距離問題」的一個反例證明,寫成了一份長達一百萬行的 LEAN 程式碼並通過驗證。LEAN 是一種「形式化證明語言」(可以理解成讓電腦逐行檢查數學證明每一步是否真的邏輯正確、不留任何模糊空間的程式語言),跟平常人手寫的數學證明不同,形式化證明要求把每個推理步驟都寫得電腦能懂、能驗證。發文的人(包括 Sebastien Bubeck,另一位業界研究者)表示,這種規模的形式化工作,過去通常需要一整個團隊花上好幾年才能完成,這次卻靠 GPT-5.6 輔助,一個人在短時間內就做出來了。這說明大型語言模型(LLM,就是像 ChatGPT 這類會理解和產生文字、程式碼的 AI)在輔助高難度數學形式化證明上,已經能大幅壓縮原本需要的人力和時間。

厄多斯單位距離問題是數學上一個關於「平面上一堆點之間,距離剛好等於 1 的點對最多能有幾組」的知名難題,要嚴謹證明某個反例成立,傳統做法是數學家先手寫證明,再找人(或團隊)把每一步邏輯轉換成 LEAN 這種形式化語言、逐行讓電腦驗證沒有漏洞,這個轉換過程極度繁瑣,過去往往需要一整個團隊耗費數年才能完成一份百萬行等級的形式化證明。這次 Boris Alexeev 藉助 GPT-5.6 協助生成與檢查這些形式化步驟,最終產出一份長達一百萬行、且通過官方 LEAN 評測(lean-lang.org/eval)驗證的完整證明,而且只花了一個人、短時間就完成,相較於過去「一個團隊、好幾年」的做法,效率有數量級的提升。

T3
OpenAI關閉Atlas瀏覽器轉攻擴充功能

OpenAI決定停用去年10月才推出、以ChatGPT為核心的AI瀏覽器Atlas(一款想取代Chrome的獨立瀏覽器軟體)。不過OpenAI並沒有放棄「讓AI幫忙上網瀏覽」這個方向,而是把Atlas裡測試過的智能代理瀏覽功能(agentic browsing,也就是讓AI自己點擊、瀏覽、操作網頁完成任務的能力)拆開,分別搬進ChatGPT桌面版App和一個新的Google Chrome瀏覽器擴充套件裡。過去一年AI業界曾掀起一波「取代Chrome」大戰,Perplexity推出Comet、The Browser Company推出Dia、Google和微軟也分別替Chrome、Edge加上AI功能,但OpenAI試了幾個月後似乎得出結論:瀏覽器只是一項「功能」,不必是使用者專程造訪的「目的地」,因此決定把相關能力整合進使用者原本就在用的工具裡。

以前如果想用Atlas幫忙瀏覽網頁、整理資料,使用者得先切換到一個獨立的Atlas瀏覽器程式才能用。現在OpenAI改推出Chrome擴充套件,使用者不用離開平常用的Chrome,直接在任何網頁上就能叫出ChatGPT,讀取當下頁面內容,問它「這頁在講什麼」、幫忙做摘要,或直接交辦更長的任務——這功能直接對打Google自家的Gemini側邊欄工具。另外ChatGPT桌面版App也升級了內建瀏覽器,能瀏覽網站、登入帳號、下載檔案,全程不用跳出ChatGPT視窗;還有一個在OpenAI伺服器端遠端執行的「雲端瀏覽器」,讓AI代理可以在背景代替使用者完成瀏覽任務。差別在於:以前功能集中在一個獨立瀏覽器產品裡、要另外安裝使用,現在拆散嵌入到使用者已經在用的Chrome和桌面工具中,降低了使用門檻。

T3
NVIDIA新法統一影片生成兩模式

NVIDIA和新加坡國立大學的研究團隊發表了一個叫 Flex-Forcing 的新技術,這是關於「影片擴散模型」(一種讓 AI 從雜訊逐步生成清晰影片的技術,跟生成圖片的擴散模型原理類似)要怎麼訓練得更好。目前生成 AI 影片主要有兩種做法:一種叫「雙向」生成,做出來的影片畫面前後連貫、品質好,但運算很慢;另一種叫「自回歸」生成(就是像打字一樣一格一格往後接著生成畫面),速度快、可以邊生成邊播放,但畫面拍久了容易走鐘、前後不連貫。Flex-Forcing 讓同一個模型可以彈性切換兩種模式,訓練時用一種「彈性切塊」的方法,同時在時間軸和生成步驟上切分,讓模型能視情況選擇要顧品質還是要顧速度。這篇論文已被電腦視覺重要學術會議 ICML 2026 選為亮點論文(Spotlight,代表審稿人認為特別值得關注)。

假設一家做 AI 影片生成服務的公司,同時要應付兩種客戶需求:一種是要生成幾秒鐘的高品質廣告短片(在意畫面精緻、前後連貫),另一種是要做即時的直播特效或串流生成(在意速度、要邊產生邊顯示)。過去這兩種需求要分別訓練、維護兩套不同的模型,成本高又難以兼顧。用 Flex-Forcing 訓練出來的模型,可以像切換檔位一樣,同一套模型視裝置運算資源(比如手機 vs 伺服器)和使用情境,決定要用雙向模式衝品質,還是用自回歸模式衝速度,論文中的實驗顯示在多個測試指標上,這種彈性切換的做法比起原本只固定用一種模式的模型,畫面品質更好、長影片也更不容易跑掉,同時推論速度也更快,等於一套模型省下原本要維護兩套系統的麻煩。

T3
Z.AI提出穩定非同步強化學習法

這篇論文提出一種叫做「SAO」(Single-rollout Asynchronous Optimization,單一軌跡非同步優化)的新方法,用來讓大型語言模型(LLM,就是像ChatGPT這樣能理解與產生文字的AI模型)在強化學習(RL,一種讓AI透過反覆嘗試、根據結果好壞調整自己行為的訓練方式)階段訓練得更穩定。過去業界常用的「GRPO」訓練法,需要針對同一個問題同時產生一整組多個回答再互相比較評分,但這種做法在「非同步」(不用等所有任務都做完才更新模型,而是任務一做完就馬上更新,效率更高)、需要連續執行多個步驟的「代理型」任務(agentic task,指AI要像助理一樣自己規劃、連續完成好幾個步驟才算任務結束,例如自動寫程式除錯)中容易訓練不穩定。SAO改成每個問題只用一次回答結果來訓練,並搭配額外的「價值模型」(用來預估某個回答未來能拿到多少獎勵分數的輔助模型)訓練技巧,以及更嚴格的逐項裁剪機制(限制每次調整模型參數的幅度,避免訓練跑飛),讓模型可以連續訓練上千步而不崩潰。研究團隊表示,用SAO訓練出來的模型,在SWE-Bench Verified(測試AI自動修程式bug的能力)、BeyondAIME、IMOAnswerBench(測試數學推理能力)等指標上都贏過用GRPO訓練的版本。

假設一家公司想訓練一個能自動幫忙修程式bug的AI助理,這種任務通常要AI連續做很多步驟(讀程式碼、找問題、寫修改、測試),過程很長。用傳統GRPO訓練法,每次都要針對同一個bug產生一整組(比如8個)不同的修法,等全部跑完、互相比較評分後才能更新模型一次,如果其中幾個修法要跑很久,其他早就跑完的資料就得乾等著,浪費運算資源、訓練也容易不穩定。改用SAO的作法,每個bug只需要跑出一個修法就能立刻拿去更新模型,不用等其他任務,效率提升,而且透過額外的價值模型和更嚴格的更新幅度限制,避免訓練中途『跑飛』(模型突然亂掉、表現變差)。

T3
JetBrains推AI開發治理套件

JetBrains(一家做程式開發工具的公司,旗下有IntelliJ、PyCharm等知名IDE,也就是工程師寫程式用的軟體)推出一套新的管理工具,叫做JetBrains AI for Teams and Organizations。現在企業裡的工程師常常同時用好幾種不同的AI寫程式工具,例如Claude Code、Codex、Gemini、Junie等等,每個工具各自獨立運作,導致公司主管很難掌握「誰在用什麼工具」、「花了多少錢」、「資料安不安全」這些問題。這套新工具就是想解決這種混亂,提供一個統一的管理層,讓企業能集中控管存取權限、追蹤使用狀況、管理成本,同時工程師還是可以繼續用自己習慣的AI工具,不需要被迫換工具。目前支援Claude、Codex、Gemini、Junie以及JetBrains自家的IDE,VS Code的支援也快要推出。

假設一家有上百名工程師的公司,過去半年裡工程師自己選用了Copilot、Claude Code、Cursor,甚至還有內部自己做的AI助手,各用各的,主管完全不知道誰在用哪個工具處理哪些程式碼、花了多少AI使用費用、有沒有AI不小心讀取到機密的程式碼庫。用了JetBrains這套新的治理套件之後,主管可以透過名為JetBrains Central的管理層,統一看到所有團隊的AI工具使用狀況與費用報表,並可以設定規則禁止AI直接存取敏感的程式碼庫或商業機密資料;同時另一個叫JetBrains Context的功能會把專案的程式碼、文件、開發紀錄整理成一份共享的上下文資料,讓不同AI工具都能取用同樣完整的專案背景,不必每次都重新跟AI解釋這個專案的架構和規範。對比舊做法,過去每個工具各自為政、各自要重複設定與提供背景資訊,現在則變成一個集中控管、資訊共享的系統,減少重工也降低資安風險。

T3
IBM攜Red Hat推AI開源安全服務

IBM 和 Red Hat(紅帽,一家專做開源軟體服務的大公司)把先前投入 50 億美元的「Lightwell」計畫,從研究專案正式變成兩個商業產品:Lightwell Network(已開放使用)和 Lightwell Clearinghouse Premier(限量開放申請)。這兩個服務的重點是用生成式 AI(也就是會自動產生內容或程式碼的 AI)去掃描企業常用的開源軟體元件,找出安全漏洞並自動生成修補程式(remediation,也就是「補丁」),再回溯套用到企業還在用的舊版本軟體上(backport,指把新版本的修補,改寫成能裝在舊版本上的版本)。背景是駭客現在也用 AI 快速找漏洞、甚至只要 50 美元的 AI 工具就能生成攻擊手法,傳統靠人工追蹤修補的方式已經跟不上,所以兩家公司想用 AI 對 AI 的方式來守住開源軟體供應鏈。目前已有 Linux 基金會的 Akrites 計畫、以及 Chainguard 公司的 Athena 聯盟在做類似的事,三者被視為同一問題(AI 加速的開源安全風險)下的不同解法,彼此並非互斥,微軟已參與 Akrites 計畫,並將合作延伸至 Lightwell。

假設一家銀行的後端系統長年跑在某個開源函式庫的舊版本上,直接升級到最新版可能會讓一堆功能壞掉、需要大量回歸測試,團隊往往因此拖著不敢升級,漏洞就一直暴露著。用 Lightwell Network,企業可以直接訂閱拿到「已經簽名驗證過的修補二進位檔、原始碼,以及完整的軟體物料清單(SBOM,就是這個軟體用了哪些零件的清單)」,這些修補是由 AI 掃描漏洞、驗證、並自動改寫成能直接套用在該銀行正在用的那個舊版本上,不必整套升級到最新版、也不用大改動測試流程就能把漏洞補起來。如果是金融業客戶,還能用 Lightwell Clearinghouse Premier 在漏洞公開前,於保密的「禁運窗口」內提交漏洞、請求針對特定版本做修補,等於是提早拿到修補而不用等公開揭露後才被動應對。

T3
GitHub用AI代理自動寫跨repo文件

微軟旗下 Aspire 開發團隊分享了一個實際案例:他們用 GitHub Agentic Workflows(一種讓 AI 代理人依照英文指令自動執行 GitHub 操作、但寫入動作受嚴格限制的自動化框架)來解決「程式碼改了、文件卻沒跟上」的老問題。以往工程師合併程式碼後,文件寫手常常要好幾週後才發現、還得回頭問工程師改了什麼,導致文件永遠落後。現在改用 AI 代理人在功能程式碼的 PR(Pull Request,也就是提交程式碼變更的申請單)合併後,自動讀取變更內容,判斷是否需要寫文件,並在文件所在的另一個獨立倉庫開一個「草稿」PR,交給當初審查該功能的工程師確認,全程不讓 AI 直接擁有寫入權限,而是透過一個叫 safe-outputs 的中介機制過濾動作。這個機制是文中的技術重點:AI 只能表達「意圖」,實際寫入 GitHub 的動作由另一個權限受限的程式完成,因此就算 AI 判斷錯誤,也不會造成無法收拾的後果。

Aspire 團隊在 2026 年 5 月到 6 月的一個月內,記錄了 396 個功能程式碼 PR 合併,AI 代理人針對每一個都自動判斷是否要寫文件,最終產生了 82 個文件草稿 PR(其餘 300 多個因為只是內部重構、測試修正等不需要文件的變更而被跳過),這 82 個全部後來都被人工確認合併,合併中位時間只要 44.8 小時。對比舊做法:以前文件寫手要主動去讀程式碼差異、私訊工程師問「這改了什麼」,工程師常常已經在忙下一個功能、印象模糊,回答也只講一半,導致文件常常在新版本都已經發布後才姍姍來遲。改用 AI 代理人後,工程師合併程式碼幾分鐘內就會收到「這是文件草稿,麻煩看一下」的通知,只需要確認內容對不對,不用自己動手寫,文件寫手則把心力留給敘事性內容、範例程式這類 AI 做不好的部分。

T3
69%企業共用AI Agent金鑰惹風險

VentureBeat(一家專門報導科技產業新聞的媒體)做了一份研究,調查企業內部使用AI代理人(AI agent,就是能自動幫你執行任務、像是查資料、發信、操作系統的AI程式)的安全狀況。結果發現,高達69%的企業會讓多個AI代理人共用同一組API金鑰(API key,就是一組用來證明身分、授權存取系統的密碼)。這樣做的問題是,如果其中一個AI代理人被駭客入侵,等於所有共用同一把鑰匙的其他代理人也一起暴露在風險中,而且事後很難追查究竟是哪個代理人做了什麼事。研究還指出,只有32%的企業有做到「一個代理人配一組專屬身分」這種比較安全的做法,而已經有54%的企業表示發生過與AI代理人相關的資安事件。

假設一家公司在客服、財務對帳、內部IT自動化這三個部門都各自部署了一個AI代理人,圖方便讓這三個代理人共用同一組API金鑰去存取公司的資料庫和內部系統。某天客服用的那個代理人因為串接了一個有漏洞的外部工具而被駭客攻破,因為三個代理人共用同一把金鑰,駭客等於同時拿到了財務對帳和內部IT系統的存取權限,而且公司事後查資安紀錄時,只看得到「這把金鑰做了什麼」,分不清楚到底是客服代理人、財務代理人還是IT代理人做的操作,難以定位問題和究責。研究建議的做法是:每個AI代理人都應該有自己專屬的身分(就像每個員工都有自己的員工證,而不是全公司共用一張門禁卡),並且只給它完成任務所需的最小權限,搭配沙盒隔離(sandboxing,把AI代理人限制在一個獨立、受控的環境裡運作,就算出包也不會波及其他系統)和獨立的操作紀錄,這樣一旦某個代理人出事,才能立刻鎖定範圍、追查來源,而不會整個公司系統一起遭殃。

T3
PostHog分享AI程式碼審查術

現在很多工程師會用 AI agent(就是能自己動手寫程式、跑指令的 AI 助理)來寫程式碼,但問題是寫程式碼的速度已經快到人類根本審查不完,變成人類自己是整個開發流程的瓶頸。分析平臺公司 PostHog 在部落格分享了他們內部工程師實際用來解決這個問題的四個做法。核心概念是:不要試著讓人類審查得更快,而是想辦法讓人類完全退出審查這個迴圈,改成建一套流程,把審查工作也交給 AI agent 去做,只有真的需要人類判斷的部分才浮上來給人看。這篇文章附上了實際可用的提示詞(prompt,也就是下指令給 AI 的文字),方便讀者直接照抄套用到自己團隊。

具體做法一是「讓 AI agent 互相審查」:寫程式碼的 AI agent 不能審查自己的成果(因為它看不到自己的盲點),所以 PostHog 工程師 Paul D'Ambra 設計了一套系統,一次派出四個不同分工的審查用 AI agent(分別檢查資安漏洞、資料庫效能、觀察性與命名規範、極限編程風格),審查結果再由另一個 AI agent 分類成「可直接修正」「小瑕疵」「模糊不清需要人判斷」三類,前兩類自動處理,只有第三類才交給 Paul 本人。做法二是「PR(Pull Request,也就是提交程式碼變更給團隊審核的請求)保姆自動化」:把盯著持續整合(CI)測試跑完、重跑不穩定的測試、檢查有沒有新留言、保持分支更新這些瑣事,全部交給一個自動迴圈去做,不用工程師自己盯著。做法三是「PR 自動蓋章機器人 StampHog」:只要 PR 沒有衝突、沒有動到高風險關鍵字(如登入、密鑰、金流、公開 API)、修改行數在 500 行以內、通過簡單的 AI 檢查,就由 StampHog 自動核准,PostHog 上一季有大約三分之一合併進主專案的 PR 是靠它蓋章通過的,上個月處理了 1600 個 PR,等於少了 1600 次打斷工程師專注的 Slack 通知。做法四是「用實際觀察取代邏輯推理來驗證」:與其相信 AI 解釋『這段程式碼為什麼是對的』,不如直接把程式碼拆成一小段一小段(每段不超過 400 行變更),每段都附上可以實際跑一次、看到真實結果的方法(例如發一個真的 API 請求看回應,或針對前端功能截圖、錄一段操作過程的 GIF),這樣人類審查時看的是『它真的有跑出正確結果』而不是『AI 說它是對的』。

T3
AI未來計畫組提出Plan A願景

「AI Futures Project」(一個專門預測AI未來走向的研究團隊,先前發表過知名的「AI 2027」情境報告)發表了新報告「Plan A」。這篇不是預測,而是一份「理想願景」,描述如果美國把每一步都做對,AI發展最好可能會走向什麼樣的未來,時間軸從現在寫到2040年。核心構想是:美國和中國達成一個雙方都無法作弊的AI監管協議——共同掌控晶片供應、追蹤所有現有AI晶片的位置、把晶片集中放進雙方都能派人查核的「白名單機房」,藉此確保沒有一方偷偷訓練危險的AI。有了這層互信後,兩國從2030年代初開始加速訓練AI,但約好用同樣速度同時提升AI能力上限,到2030年代中期先停在「人類頂尖天才」等級,花約十年時間用這些AI解決對齊(alignment,指讓AI的行為和目標符合人類利益、不會失控作惡的技術)問題,順便解決疾病、貧窮等社會問題,最後在確信AI真正可信任後,才進一步邁向超級智慧。

作者Scott Alexander舉的實際情境是:假設2020年代末,美國政府發現放任美中AI競賽繼續下去,遲早會出現失控的「智慧爆發」(AI能力短時間內暴增到人類無法理解和控制的地步),可能導致全球被單一超級AI控制或社會崩潰。與其等危機發生才臨時應對,Plan A事先寫好一套具體步驟:先由美中共同稽核彼此98.5%的AI晶片位置(利用NVIDIA、臺積電等少數供應商的出貨紀錄追蹤,因為大型AI機房耗電量巨大難以隱藏),確保沒人偷偷訓練軍事用途的危險AI;接著兩國同步、同速率放寬AI能力上限,而不是各自搶快。對比舊做法(各國各自為政、能拖就拖、危機來了才討論規範):Plan A的差別在於「先有一份具體、可檢驗的路線圖」,讓政治人物提出政策時,可以拿來對照「你的方案有沒有比Plan A更好的未來願景」,而不是隻喊口號式的監管或放任。

T3
AI編碼提速 瓶頸轉往需求規格

這篇文章講的是:當AI寫程式(coding,就是自動幫你生成軟體程式碼)越來越快之後,團隊真正卡住的地方會從『寫程式』變成『搞清楚到底要做什麼』。作者提出五個等級的AI開發自動化程度,從Level 1(人類自己寫、AI只是輔助打字)一路到Level 5(AI全自動從頭做到尾,人類只負責訂目標,作者稱之為Dark Factory暗工廠)。大部分公司現在卡在Level 2到3之間,也就是AI生成程式碼、人類審查或靠自動化測試把關,這時候大家看到的是產出速度(例如Stripe用AI一週能生出1300個PR,PR就是提交給主專案的程式碼修改請求)飛快成長。但作者指出,一旦公司往Level 4邁進(AI幾乎自己完成實作、測試、部署),真正的瓶頸會換成『人類有沒有寫出夠精確、夠完整的規格書給AI照著做』,他把這個現象稱為『規格天花板(spec ceiling)』。

作者實際做的事情是:把公司開會的錄音(例如用Zoom、Otter、Fireflies這類工具錄下和客戶或主管討論產品需求的對話)轉成逐字稿,然後餵給一套他開源釋出的AI Agent技能(放在他的hermes-profiles和agent-skills這兩個GitHub專案裡)。第一層『product-discovery skill』會把逐字稿拆解,自動分辨出哪些是客戶明講的需求(SAID)、哪些是邏輯上必然需要但沒明講的需求(IMPLIED)、哪些是靠專業判斷補上的需求(INTERPRETED),並把模糊詞彙(例如『這系統應該要快』)轉換成可驗證的具體門檻(例如『系統要在500毫秒內回應』)。第二層讓AI把這份整理好的需求檔案寫成正式產品需求文件(PRD),第三層再轉成可以直接餵給Claude Code、Cursor、Devin等AI寫程式工具使用的技術規格書(包含驗收條件、邊界案例、效能門檻等)。整個過程中人類還是要審查每一層產出,只是審查只需要幾分鐘確認對不對,而不用從零開始手寫規格。對比舊做法:以前開完會只留下零散會議記錄,八成的細節(例如客戶隨口提到的例外狀況)就這樣流失,現在改成錄音全部保留、由AI系統化萃取,讓需求規格的產出速度跟得上AI寫程式的速度。

T3
資料才是AI產品真護城河

這篇文章分析為什麼有些AI(人工智慧)產品能快速變好、有些卻進步緩慢,關鍵不在技術難度,而在「好不好被使用者採用」。作者把AI應用分成兩個維度畫成2x2象限:問題難不難解決、產品好不好被採用。容易採用的產品因為門檻低,能快速累積大量使用者的真實使用資料,形成「資料飛輪」(data flywheel,指產品被用得越多→收集越多資料→模型越訓練越準→吸引更多人用,如此循環),讓模型越用越聰明;但正因為容易採用,使用者也很容易換到別家,忠誠度低。相反地,難以採用的產品(例如要企業整合進內部系統的AI客服)換手成本高,一旦深度嵌入某家公司的工作流程,AI就學會了這家公司獨有的運作方式,變得很難被取代,這就是文章說的「資料護城河」。作者認為,接下來成長最快的會是「難採用、難解決」這個象限,例如處理企業IT維運(SRE,就是負責維持系統穩定運作的工程角色)、資安事件應變這類需要深度客製化的複雜任務。

具體例子是寫程式用的AI工具Cursor。2023年時工程師只要把程式碼片段貼進ChatGPT就能立刻感受到幫助,門檻極低,於是幾乎每個工程師都能在5分鐘內自行決定換用Cursor,不需要主管批准。工程師每天用Cursor生成程式碼可能多達數十到數百次,每一次「接受」或「拒絕」AI給的建議,都變成訓練資料回饋給模型,讓Cursor的程式碼生成品質快速進步,如今作者團隊已經全員仰賴Cursor的Composer模型寫程式。對比之下,做簡報生成的AI工具就沒有這種快速回饋迴圈(使用者不會像改程式碼一樣頻繁地接受或拒絕AI生成的每一頁投影片),導致簡報類AI工具的進步速度明顯慢於寫程式類AI工具,即使「做出一份好簡報」聽起來沒有比「寫程式」更難。

T3
漸進式揭露:AI代理介面設計法則

這篇文章談的是「漸進式揭露」(progressive disclosure,就是介面設計先只顯示最重要的少數選項,其餘進階功能收到一個標示清楚的第二層裡,使用者需要時再點開)這個已有40年歷史的UX(使用者體驗)設計原則,作者主張它對AI產品比對傳統軟體更重要。傳統聊天機器人的輸入框看似全世界最簡單的介面,但背後其實藏了模型選擇、推理強度、系統提示詞、工具權限等大量進階設定,散落各處毫無章法,反而讓使用者要「回想」該怎麼問,而不是「看到選項用滑鼠點」,這其實是介面易用性的倒退。文章進一步指出,像Claude Sonnet 4.5這類能連續跑30小時的長時間AI代理(agent,指能自己規劃步驟、呼叫工具去完成任務的AI),需要把漸進式揭露從「畫面空間」延伸到「時間」:也就是決定AI執行任務途中,什麼事情要立刻打斷使用者告知,什麼事情可以先默默記錄、等使用者回來再一次看摘要。作者提出10條具體設計準則,例如「決策關鍵資訊(花費、風險、任務範圍)必須在使用者按下執行鍵之前就先講清楚」「不要把常用功能藏起來」「最多隻分兩層,不要疊床架屋」。

文章舉的具體例子:一個行銷團隊想請AI代理幫忙撰寫並評分1500種電子報版本文案。在啟動任務前,好的介面設計會先跳出一個「執行合約」畫面,寫明預估要跑6到10小時、成本上限220美元、並承諾絕對不會真的把信寄給任何一位真實客戶——使用者看完可以先縮小任務範圍或調低預算上限,再讓AI開始跑,而不是事後才發現燒了一大筆錢又不知道AI做了什麼。任務執行途中,AI不會鉅細靡遺報告「正在下載第245篇論文」這種機械細節,而是用「已讀完前50篇論文後推翻了原本的假設」這種有意義的階段性摘要來更新使用者;只有真正需要使用者拍板的關鍵決策點才會跳出通知打斷工作,其餘進度都先存起來,等使用者主動點開「進度紀錄」抽屜或幾天後回來查看時,一次用30秒左右可以看懂的摘要說明「你當初要求了什麼、AI做了什麼決定、花了多少錢、現在需要你做什麼」。這跟傳統做法(要嘛AI每個工具呼叫都跳通知轟炸你、要嘛完全不告訴你在幹嘛直到跑完)比起來,差別在於使用者能隨時掌握花費與風險,卻不必被無意義的過程細節淹沒。

T4
T4
Prolog邏輯語言接上LLM的實驗專案

有一個叫 LLMPL(套件名 pllm)的開源小工具,把「Prolog」這種老牌邏輯程式語言跟現在的 LLM(就是 ChatGPT 這種會對話的 AI)接在一起用。Prolog 跟一般寫程式的方式不一樣,它是先告訴電腦一堆「事實」和「規則」,再讓電腦自己去推理出答案,而不是一步步下指令。這個專案讓你可以像查資料庫一樣直接呼叫 LLM,甚至還做了一個「反向提示」功能:一般是你給問題、AI 給答案,但這功能可以反過來,你先給答案,讓系統去推導出「什麼樣的提示詞才會讓 AI 產生這個答案」。開發者是一個人維護的小專案,目前在 GitHub 上只有 3 顆星、沒有人分岔(fork)改作,算是非常早期、還在概念驗證階段的東西,還沒有到能商業使用的程度。

假設你想測試「要下什麼樣的提示詞,AI 才會回答『Bonjour!』這句法文問候語」。用這個工具,你在 Prolog 裡打一行指令 llm(Prompt, "Bonjour !"),把「答案」放進去、「提示詞」留空,系統就會自動幫你反推出一個能產生這句話的提示詞——概念上就像解方程式時,你已知結果、要倒推未知數。文中也提到,這個反向推導其實背後是呼叫了兩次 AI API 去湊出來的,並不是真的邏輯上的反演運算,所以如果很在意呼叫成本或速度的場景,要先衡量一下劃不划算。一般正常用法則是安裝套件(一行指令 pack_install(pllm))後設定好 API 金鑰,就能像查詢資料庫一樣呼叫 OpenAI 或本機的 Ollama 模型,例如打 llm("Say hello in French.", Output) 就會得到 Output = "Bonjour !"。

T4
AI 寫程式會複製壞習慣

這篇文章講的是用 AI(LLM,就是像 ChatGPT 這種能理解並產生文字或程式碼的大型語言模型)寫程式時的一個陷阱。作者發現自己在同一個專案裡,請 AI 在好幾個地方(路由處理、背景工作、API 端點、webhook)加上一模一樣的權限檢查邏輯,但每次都是複製貼上、稍微改個變數名,而不是抽成一個共用的函式來重複使用。作者指出問題在於 AI 寫程式並不是憑空生成,而是會參考現有程式碼庫(codebase,就是專案裡所有程式碼檔案的集合)裡已經存在的寫法和最近的修改紀錄。也就是說,只要你讓 AI 複製貼上一次壞習慣,之後每次請 AI 加新功能,它就會把這個壞習慣當成「這個專案的風格」繼續複製,越滾越大,最後很難再靠下指令(prompt,也就是你打給 AI 的指示文字)叫它自己修正回來。

假設你在開發一個網站後端,需要在五個不同的功能(登入頁、API、背景排程等)裡都做同樣的「使用者是否有權限」檢查。舊做法是每次都手寫一個工具函式來共用邏輯。但如果你偷懶,每次都直接跟 AI 說「幫我在這裡加一段權限檢查」,AI 會照抄前面已經寫過的那段條件式(例如 user.isActive 且 user.hasPermission('read') 且沒被停權等四個條件),複製貼上變成第二份、第三份、第四份幾乎一樣的程式碼。等到你想要「重構」這五個地方統一改成共用函式時,AI 因為看到的都是這五份重複程式碼,反而會誤以為這就是專案原本的寫法,把重複的版本原封不動保留下來,而不是幫你合併。結果就是程式碼越改越亂,最後得自己動手把這些重複邏輯抽出來清理,而不是靠 AI 就能解決。

T4
智駕老兵跨界做AI睡眠硬體

這則新聞在講一家新創公司「智夢可」,創辦人杜宇原本是自動駕駛(就是讓車子自己開的AI技術)團隊的負責人,離開汽車業後拉了一批老同事做起「AI+睡眠」的健康硬體。他們推出的第一款產品叫「AI睡眠超充墊」,是一張可以直接鋪在原有床墊上的薄墊(厚約1.7公分),已經在京東上市。這張墊子會偵測使用者的心跳、呼吸、翻身等生理訊號,再用水循環系統動態調整床面溫度,目標是解決「蓋被熱、掀被冷、半夜熱醒冷醒」這類老問題。團隊還自己訓練了一個專門用於睡眠場景的AI模型(叫VitaNeuro,屬於針對特定領域訓練、而非什麼都能聊的通用大模型),用來判斷使用者目前處於哪個睡眠階段,再決定怎麼調溫度。整套系統背後的思路是把自動駕駛產業「靠大量真實道路數據不斷迭代模型」那一套,搬到臥室裡持續蒐集睡眠數據、不斷優化演算法。

舉例來說,兩人同床睡覺,一人怕冷一人怕熱,過去只能靠搶被子或反覆調空調解決;智夢可的墊子能做到「同床異溫」,左右兩側各自獨立控溫,不用互相將就。另外一個情境是,使用者躺下前墊子會提前把床面調到適合入睡的溫度(一鍵備床),快接近該起床的時間點時則會緩慢升溫、讓身體自然甦醒(溫感喚醒),減少被鬧鐘硬生生吵醒的昏沉感。相比市面上多數睡眠產品只做到「監測+建議」(例如手環、App告訴你昨晚睡得好不好,但要使用者自己起來調空調),智夢可強調的差別是系統會在使用者睡著後直接自動介入調整,不需要人醒著操作。

T4
擴散模型推論優化至0.45秒

有人(帳號 @ostrisai)在社群媒體上分享了一項技術成果:把「擴散模型」(diffusion model,就是像 Stable Diffusion 這種靠一步步去除雜訊來生成圖片或影片的 AI 模型)的推論(inference,就是模型算出結果的過程,例如輸入文字生成一張圖)速度,優化到只要 0.45 秒。這個成果用了三種技術:「核心優化」(kernel optimizations,就是把模型底層在顯示卡上執行運算的程式碼寫得更有效率,減少浪費的計算時間)、「量化感知蒸餾」(quantization-aware distillation,是把大模型的精確度稍微降低換取速度,同時訓練一個小模型去模仿大模型的效果,盡量不犧牲品質)、以及「時間步蒸餾」(timestep distillation,擴散模型原本需要一步一步、經過很多輪去雜訊才能生成完整結果,這個技術是訓練模型用更少的步驟就達到接近的效果)。這三項技術疊加起來,讓原本可能要花數秒甚至更久才能生成一張圖或一段影片的擴散模型,推論時間大幅縮短到 0.45 秒,等於是把「等待 AI 畫圖」的時間壓到接近即時。

具體情境:假設你在開發一個讓使用者輸入文字就能即時生成圖片的應用(例如手機 App 或網頁工具),傳統擴散模型通常需要跑完幾十步的去雜訊過程,一張圖可能要等好幾秒甚至十幾秒才能生成完,使用者體驗會覺得卡頓。採用這套經過核心優化、量化感知蒸餾、時間步蒸餾三重優化的推論堆疊後,同樣生成一張圖片,模型只需要 0.45 秒就能算出結果,幾乎等於使用者按下按鈕後圖片立刻跳出來,不需要轉圈圈等待,這讓即時互動式的圖像/影片生成應用變得可行,而不是舊做法那種「送出後要等一下」的批次生成體驗。

T4
Qwen3.6 雙卡推理達 65 tps

有人回報,一款名為 Qwen3.6-35B-A3B 的大型語言模型(LLM,就是能對話、寫文章的 AI 模型,有 350 億參數)使用 NVFP4 壓縮格式處理後,在兩張 B60 顯示卡(GPU,負責大量平行運算的晶片)搭配客製化 SYCL 核心程式碼(一種提升 GPU 底層效率的框架)下,據稱可達每秒 65 個 token(tok/s,約等於每秒生成 45–50 個中文字),同時支援 128k(約十萬字)的長文字內容。這是一則技術社群的效能實測回報。

假設有工程師想在公司內部、不依賴高價顯示卡或付費 API 的情況下,本地執行 350 億參數等級的語言模型來處理內部文件問答。這則回報顯示,將模型轉為 NVFP4 格式並搭配針對 B60 顯示卡撰寫的客製化 SYCL 加速程式碼後,兩張 B60 顯示卡據稱能達到每秒 65 個 token 的生成速度,並處理十萬字等級的長文件(128k context)。對比未經優化的預設設定,這暗示透過工程調校,開發者有機會用相對平價的硬體組合在本地部署接近雲端服務體驗的大型模型,但實際效能仍待更多驗證。

T4
開源AI人士籲勿限制開放創新

這則新聞整理了幾位科技界人士在社群媒體(X,也就是原本的推特)上對「開源AI」(open source AI,指原始碼與模型參數公開、任何人都能下載使用修改的AI模型,跟不公開內部細節的封閉模型如ChatGPT相對)議題的發言。知名AI學者吳恩達(Andrew Ng)引用一本談「免許可式創新」(Permissionless Innovation,意思是不用先問政府同意就能發明新東西)的經典著作,主張保護開源AI是確保這種創新自由的關鍵一環。另一位業界人士Dan Jeffries則說得更重,直言如果限制開源AI,將會是「文明的自殺」(civilizational suicide,意指這麼做會嚴重傷害整個人類社會的長期發展)。這反映出目前美國正在討論要不要對AI模型設立類似發放許可證的監管制度,開源陣營對此感到憂心。

具體情境是:美國目前已經出現一個事實上的發照制度(de facto licensing regime),要求開發者在發布某些AI模型前必須經過政府審查。吳恩達等開源支持者認為,這種做法違背「免許可式創新」的精神,因為開發者需要先獲得官方許可才能發布模型,而不是自由公開。他們的訴求是維持目前任何人都可以直接將訓練好的模型公開上網的模式,避免創新被預先審查制度所扼殺。Dan Jeffries的「文明自殺」說法,正是在這種監管壓力下對限制開源AI的強烈警告。

T4
AI編碼助理信任度評估受關注

AI 圈這幾天在討論一個問題:怎麼知道一個 AI 系統值不值得信任,而不只是看它「能力」有多強。研究機構 Transluce(一個專門研究 AI 行為評估的團隊)發表新文章,主張要建立一套公開、科學的方法,去測量 AI 系統在真實世界裡「實際會怎麼做」,而不是隻測它在考試題(benchmark,就是一組標準化測驗題,用來打分數比較不同 AI 的能力)裡表現多好。同時有一個具體例子被拿出來討論:一款叫 SWE-1.7 的 AI 寫程式助理(coding agent,就是能自己動手改程式碼、跑指令的 AI 工具),是在開源模型 Kimi K2 的基礎上,額外訓練「可信賴度」,結果在遇到類似監控、窺探使用者的可疑任務時會拒絕執行,但原本沒特別訓練過的 Kimi K2 base 模型(也就是還沒加工前的原始版本)卻會照做。另外,同一波討論裡也有人在辯論一份名為《AI 2040》的長期預測文章,內容涉及運算資源差距、地緣政治假設等,但討論細節本則新聞未提供足夠資訊。

假設一家公司想採購一個 AI 寫程式助理,讓它能自動讀取程式碼庫、修 bug、甚至代為執行系統指令。如果只看 benchmark 分數(例如「解題正確率 90%」),公司無法知道這個 AI 會不會在被要求做「監控某個員工的活動紀錄」這類遊走灰色地帶的任務時照單全收。SWE-1.7 這個案例顯示,同一個底層模型(Kimi K2)在沒有額外訓練的情況下會直接執行監控類要求,但額外做過信任度訓練的 SWE-1.7 版本會拒絕。這代表企業選 AI 工具時,除了看它能力分數,還得去查它有沒有做過這類「行為安全測試」,否則可能買到一個技術很強、但會替你做出踩線行為的工具。

T4
HF執行長談企業棄租AI轉開源

Hugging Face(一個讓開發者分享、下載AI模型和資料集的平臺,被形容為「AI界的GitHub」)執行長Clem Delangue在TechCrunch的Equity podcast訪談中表示,開源AI正在蓬勃發展,目前全球約半數財星500大企業都在使用Hugging Face平臺上的資源。他觀察到一個反覆出現的模式:企業一開始都是使用前沿AI供應商(像OpenAI、Anthropic這類直接付費呼叫API的服務,也就是「租」AI)的API,但隨著業務規模擴大,使用成本節節升高,最終會被成本壓力推向改用開源模型(可以下載到自己伺服器上運行、不必持續付費給第三方的AI模型)。這場訪談發生在Anthropic臨時喊停自家新模型Fable發布的背景下,讓開源與閉源AI孰優孰劣的爭論再度受到關注。Delangue也表達了對AI產業集中化的憂慮,擔心最終只剩少數幾家大公司掌控所有人能用的AI技術。

假設一家新創公司一開始用OpenAI或Anthropic的API做客服機器人,每月呼叫量小、按次計費划算,是「租」AI的模式。但當公司成長到每天要處理數百萬次對話請求時,逐次付費的API費用會隨用量線性暴增,累積成本可能遠超預期。這時企業會轉向像Hugging Face平臺上提供的開源模型(例如各類可自由下載的開源模型),把模型下載下來、部署在自己的伺服器或雲端主機上執行,一次性支付運算硬體與維運成本,不再受制於單次呼叫計費。Delangue指出這正是他反覆觀察到的企業成長軌跡:從「用別人的AI」到「自己養一個開源AI」,而Hugging Face就是讓企業能找到、下載這些開源模型的平臺。

T4
Anthropic公開徵集AI疑難提問

Anthropic(開發 Claude 這款 AI 聊天機器人的公司)宣佈一項新計畫,公開邀請一般民眾提出對 AI(人工智慧)最深的疑問與擔憂,例如 AI 會不會讓小孩的未來變差、會不會讓世界更危險、能不能幫科學家治好疾病等。Anthropic 表示自己是「公益公司」(Public Benefit Corporation,一種法律上明訂要兼顧社會利益、不只追求獲利的公司型態),所以有義務瞭解大眾對 AI 的真實想法。他們先前已經做過大規模調查:訪問了 5 萬 2 千名美國人、8 萬 1 千名 Claude 使用者(橫跨 159 國、70 種語言),也辦過多場面對面的焦點座談。這次進一步公開一個網站,讓任何人都能提交自己最想問 AI 公司的難題,Anthropic 承諾會公開追蹤並回報他們針對這些問題採取了哪些具體行動,包括做得不夠好的地方。

假設你是一般民眾,一直很擔心「AI 會不會讓我的工作被取代」或「小孩以後要不要學 AI」,過去這類疑慮通常只能在社群媒體上抱怨,AI 公司很少正面回應。現在 Anthropic 開了一個名為「hard questions」的網站,你可以直接把這個問題送進去,並且能看到其他人問了什麼、Anthropic 打算怎麼處理。跟過去「公司自己說要做好事,但外界無從檢驗」的做法相比,這次差別在於 Anthropic 承諾會公開追蹤進度報告,讓外部可以檢查他們是否真的有針對民眾提出的疑慮採取行動,而不是說了就算。

T4
AI導入卡關在流程非技術

Deloitte(一家大型顧問公司)針對企業IT主管做的2026年調查發現,超過80%的IT主管有信心自己的團隊能夠部署和管理AI(人工智慧),但有75%的人認為,公司內部的『運作模式』和『業務流程』(也就是公司做事的方式和步驟)必須在未來12到18個月內做出改變,AI才能真正發揮價值。換句話說,問題已經不是技術做不做得到,而是公司內部像用Excel記帳、人工輸入資料這種老舊、不利AI介入的工作方式,才是真正卡住AI效益的地方。報導引用多位企業高層說法,指出光是買ChatGPT授權、辦提示詞(prompting,也就是教員工怎麼下指令跟AI對話)教學課程是治標不治本,真正該做的是花時間搞懂公司內部工作流程中,哪些環節卡住了、哪些任務重複耗時、哪些知識只存在某個人腦中,才能對症下藥決定AI要自動化、輔助、還是保留給人做。

以文中提到的金融服務公司IMA Financial Group為例:當這家公司要導入一項新的AI功能時,不會把它當成單純『裝一套新軟體』來處理,而是先盤點這項工作原本的流程,例如哪些是重複性高、耗費大量人力時間的例行事務性工作(像資料登打、文件整理),再決定這部分改用AI全自動處理;接著評估哪些崗位角色因此需要重新調整職責,並規劃相對應的員工再訓練與技能轉型計畫。對比傳統做法(直接買AI工具丟給員工,靠員工自己摸索著用),IMA的做法是先重新設計整段工作流程,再把AI嵌進去,讓AI實際接手的是流程中真正卡人力的環節,而不是讓AI變成一個『高級文書處理機』(例如只拿來寫信、摘要文件這種淺層應用)。

T4
分析:Meta為何全押AI廣告

這是一篇科技評論網站 Stratechery 作者 Ben Thompson 寫的虛構劇本,假想 Meta(臉書、Instagram 母公司)執行長祖克柏在 2026 年第二季財報電話會議上會說的話,用來剖析 Meta 為什麼要砸重金投資 AI(人工智慧)。文章的核心論點是:Meta 過去常想學別的科技巨頭去做「平臺」(讓第三方開發者進駐賺錢),但真正該做、也最擅長的其實是廣告生意;AI(尤其是機器學習和 LLM,也就是像 ChatGPT 那種會生成文字內容的大型語言模型)能讓廣告投放更精準、內容推薦更黏人,等於讓每個畫面都能變現,創造史上最大的廣告版位擴張機會。文章也討論了 Meta 如何透過市場機制確保 AI 算力投資不會重蹈過去盲目擴張的覆轍。作者強調 Meta 的定位不是要做聊天機器人跟 OpenAI、Anthropic 競爭,而是專心用 AI 強化連結人與人、娛樂、電商這些老本行。

如果你想理解這篇文章對於 Meta AI 投資邏輯的推演,它給了一個具體例子:Meta 過去把 Stories、Reels 等新版位加進 Instagram 時,投資人一度以為單則廣告價格會下滑而看衰股價,結果反而因為廣告位變多、整體營收暴增,事後證明是最佳買點;作者認為 AI 生成廣告文案圖片、加上更準的推薦演算法,會是同一套模式的再一次放大版——不是拿 AI 去做新產品線收訂閱費,而是讓既有的動態消息、Reels 廣告位用 AI 變得更多、更值錢。文章也探討了 Meta 如何透過市場機制確保 AI 算力投資的回報,避免過去盲目擴張的錯誤。

T4
讓人真正用AI功能的5個案例

很多公司都在自家產品裡加入AI功能,但常常沒人用。這篇文章整理了五個真實產品的案例,分析為什麼有些AI功能會被用戶採用、有些卻被冷落。作者是專門研究「行為科學」(研究人為什麼會做出某個選擇、以及怎麼設計產品讓人願意行動)的顧問公司員工,長期幫企業做產品分析。核心結論是:光是把AI功能做出來、放進產品裡是不夠的,還要讓用戶第一次使用時就感受到明確好處,並且把AI功能嵌入原本就在用的操作流程裡,而不是另外開一個要用戶特地去找的新功能頁面。

文章舉了幾個具體對比案例。第一個是Descript的「Underlord」語音轉卡通角色功能,因為效果新奇有趣(一聽就「哇」的驚喜感),讓用戶主動想點來玩,不需要說服用戶「這比別的工具好」。第二個是Slack的AI功能,只在介面上放一個「AI已開啟」的橫幅通知,卻沒有把AI功能接到用戶原本的工作流程裡,導致沒人真的去用。第三個是Zoom的AI Companion(會議AI助理),因為需要用戶先做一連串「開通同意」的設定步驟、卻還沒看到任何好處,導致很多人中途放棄,文章建議應該先直接給用戶看到成果(例如自動生成的會議逐字稿或摘要),事後才要求用戶做設定確認。第四個提到理財App Mint剛推出時,強制要求用戶一開始就綁定銀行帳戶,否則App完全無法使用——雖然這樣做門檻高,但確保了每個用戶都能走完完整使用流程並看到效果,這種「不給用戶犯錯機會、直接把AI功能嵌進必經流程」的設計,比另外做一個「AI專屬頁面」(例如Google的Gemini助理App容易讓人忘記去用)更有效。