科技媒體The Decoder報導，OpenAI正在打造代號「Astra」的新一代模型家族，目標是讓多個AI代理人（agent，就是能自己規劃、執行任務的AI程式）協同合作，連續處理困難問題長達數小時甚至數天。執行長Sam Altman已在華盛頓向政府官員展示過Astra，OpenAI內部版本的Astra已解出十個困擾數學界與理論電腦科學界至少十年、甚至更久都沒人解開的難題，涵蓋高維幾何、編碼理論、群論、量子複雜度、格密碼學等領域。OpenAI官方發布報告確認Astra名稱，並公開瞭解題過程的完整說明，同時說明Astra尚未決定會以GPT-6之名發布，還是作為GPT-5系列的變體推出，也還沒有確定的發布時程。這個模型將是美國政府新規畫的AI審查框架下第一批必須送交聯邦政府審核才能公開發布的模型。
以其中一個成果為例，Astra證明瞭「非索菲克群（non-sofic groups）確實存在」，解決了群論領域一個長期懸而未決的重大問題。OpenAI說明，生成十道題目解法所用掉的token（AI處理文字的基本單位），若照Sol模型API定價計算，成本約2000美元；研究人員之後與同一模型合作，把論證整理成正式論文，而模型本身把每個證明形式化為Lean（一種可讓電腦自動驗證數學證明是否正確的程式語言），產生機器可驗證的正確性憑證。這代表這類能長時間推理的AI已能在部分數學領域達成人類多年未解的突破，不過OpenAI尚未解出任何千禧年大獎難題（Clay數學研究所懸賞100萬美元的七大數學難題）。
GCC（GNU Compiler Collection，是 Linux 等系統背後最核心的編譯器之一，負責把程式碼轉換成電腦看得懂的機器語言）的 Steering Committee（指導委員會）在 2026 年 7 月 29 日正式公告一項 AI 貢獻政策，由委員會成員 David Edelsohn 在官方郵件列表宣佈生效。政策規定：任何超過 15 行、內容包含或衍生自 LLM（大型語言模型，就是 ChatGPT、Claude 這類會生成文字與程式碼的 AI）生成的程式碼，一律不得提交進 GCC；低於 15 行的小型貢獻只要標明含 AI 內容仍可接受，維護者也可自行決定放行 AI 生成的測試程式碼。政策的用意是保護 copyleft（一種要求衍生作品也必須以相同條款開放原始碼的授權策略，GPL 是最典型的例子）授權的法律效力——如果程式碼的版權來源不明確，GPL 授權賴以生效的「版權確定性」就會受到挑戰。目前政策沒有自動偵測工具，完全靠貢獻者誠實自我聲明加上維護者人工審查把關，因此 Hacker News 上有社群成員擔心，誠實揭露 AI 使用反而比隱瞞更容易被懲罰或被限制 vouching（信任擔保）權限。
假設一位工程師想幫 GCC 修一個編譯器最佳化的 bug，過去他可能直接叫 Copilot（微軟出的 AI 程式碼輔助工具）生成一段 20 行的修正程式碼，稍微調整後就提交 PR（pull request，程式碼合併請求）。在新政策下，這樣的提交會被直接拒絕，因為超過 15 行門檻、且來源可追溯到 LLM 輸出。他現在必須改成：先讓 AI 幫忙分析問題成因、找出 bug 位置，但實際修正的程式碼要自己動手重寫，或把 AI 給的程式碼大幅修改到足以被認定是「創作」而非「採納」；如果只是要加測試案例，AI 生成的測試碼則可以標明來源後直接送審，交由維護者裁量是否接受。這項政策等於在 code review 之外，多了一道「AI 使用是否誠實揭露、是否符合 15 行門檻」的合規檢查，Red Hat、Arm、Intel 等企業貢獻者甚至可能要動用法務部門更新內部指引。
這篇部落格文章的作者是研究者 Alexi Gladstone，與 Yilun Du、Heng Ji 共同發表了一篇論文，提出名為「Explorative Modeling（探索式建模，簡稱 XM）」的新方法。生成式模型（generative model，就是能自己「畫」出圖片、影片或文字的 AI，例如 ChatGPT 或 Midjourney）過去都靠一種叫「分解生成」的技巧來避免輸出模糊的平均值答案，也就是像自回歸模型（autoregressive，像 LLM 那樣一個字一個字往下猜）或擴散模型（diffusion model，從一堆雜訊開始，一步步修出清晰圖片）那樣，把生成過程拆成很多小步驟，讓每一步只有一個接近正確的答案，藉此避免模型學到「所有答案的平均值」這種四不像的結果。作者發現除了拆步驟之外，還有第二條路：在訓練時讓模型針對同一筆資料一次生成 K 個不同猜測，只挑其中最接近真實答案的那個來更新參數（也就是隻有分數最好的猜測才會拿去做反向傳播訓練），這樣模型就能學會覆蓋更多種可能答案，而不是被迫輸出模糊的平均值。作者稱這是繼「模型參數量」和「訓練資料量」之後的「第三條預訓練擴展軸線」，並證明只要把這個技巧加到現有模型上，效能提升幅度會隨著資料量和模型規模變大而持續增加。
以 ImageNet 圖片生成為例，作者拿業界近乎最先進的 RAE 生成方案，完全不改架構、不改超參數，只加上「一次生成 K 個猜測、挑最好的來訓練」這個技巧，結果達到同樣品質只需要 6.2 倍更少的訓練資料、4.1 倍更少的運算量（FLOPs，就是模型訓練要花的運算成本），並在 ImageNet 256 這個測試集上做到 1.43 FID（FID 是衡量生成圖片跟真實圖片有多像的分數，數字越低代表生成品質越接近真實照片）的近頂尖成績。另一個更驚人的案例是機器人動作生成：傳統的 Diffusion Policy（擴散策略，讓機器人手臂學會模仿示範動作）要跑 100 次模型推論才能生成一個動作，作者訓練的 Explorative Policy 只需要跑 1 次推論，在 Lift、Can、Square、Transport、Tool Hang 五項機器人操作任務上的成功率跟 Diffusion Policy 打平甚至更高（例如 Square 任務從 94% 提升到 96%）。這代表同樣的機器人控制品質，用這個新方法可以把即時運算成本砍到百分之一，對需要即時反應的機器人應用是實質的效能突破，而不是紙上談兵的學術數字。
AI 研究者 Elvis Saravia（帳號 @omarsar0，dair.ai 創辦人）在 X 上分享了一篇關於「AgentRadio」的論文研究。AgentRadio 是一套讓多個 AI 代理（agent，也就是能自己執行任務、不用每步都靠人下指令的 AI 程式）互相溝通的機制。過去多個 AI 代理合作時，通常只能在任務的固定階段互相回報進度（像接力賽交棒），做事和溝通不能同時進行。AgentRadio 改用「非同步訊息」的方式，讓代理們可以像開對講機一樣，隨時發訊息、開討論串、或在背景留意有沒有人提到自己，不會打斷正在做的工作。研究團隊在程式碼問答測試 SWE-Atlas QnA（一套 AI 程式碼問答標準測驗）上做實驗，發現這套機制能大幅提升解題成功率。
研究團隊讓一個 AI 代理（用 Anthropic 的 Claude Code，模型版本 Opus 4.6）單獨解 SWE-Atlas QnA 的題目，成功率是 32.3%。接著他們讓四個同樣用 Opus 4.6 的代理透過 AgentRadio 互相傳訊息協作解同一批題目，成功率跳到 62.1%，幾乎是單一代理的兩倍。更值得注意的是，這四個「較舊」的 Opus 4.6 代理協作的結果，還贏過單獨一個「更新」的 Opus 4.8 代理（成功率 57.2%）。研究也發現，題目越難，協作帶來的進步幅度越大，代表這套機制的效果不只是「人多力量大」的平行運算，而是代理們能互相糾正彼此的思路走偏。這說明企業與其花更多錢升級到最新最貴的模型，不如投資在把多個便宜模型組織起來協作，可能更划算。
德國慕尼黑地方法院判決AI音樂生成工具Suno（一款輸入歌詞、風格、標題就能生成完整歌曲的AI服務）在「訓練」和「輸出」兩個環節都構成著作權侵權。這場官司是德國音樂著作權集體管理組織GEMA（類似臺灣的著作權仲介團體，負責向使用音樂的商家收版稅再分給創作者）提告的。法院認定Suno的3.5版和4版模型裡，實際「記憶」了六首知名歌曲，包括「Atemlos durch die Nacht」和「Rasputin」，也就是模型訓練時不只學到抽象的音樂規律，還把具體歌曲的內容儲存下來，之後可以被還原重現，這在AI研究裡叫做「記憶化」（memorization，是模型過度背下訓練資料細節、而非只學到通用模式的現象）。法院同時駁回Suno提出的兩種抗辯：一是德國法律裡「文本與資料探勘例外」（允許自動分析內容的法律豁免），二是美國法上的「合理使用」（fair use，允許在特定條件下使用受著作權保護的內容而不算侵權）原則。法院還認定責任在Suno公司本身、不在使用者身上，因為是Suun公司選擇訓練資料、設計模型架構，才導致模型會記憶並吐出侵權內容。這項判決尚未確定，可能會上訴。
假設你是一位音樂人，想用Suno做一首全新的原創歌曲，你打字輸入某首暢銷金曲的完整歌詞、音樂風格和歌名（但沒指定旋律、和聲、節奏），結果Suno生成出來的歌曲，被法院認定跟原曲「實質相似」，等於是把原曲的旋律等核心元素幾乎原樣吐了出來，而不是幫你創作一首新歌。這就是本案GEMA用來提告的測試方式：他們故意輸入六首知名歌曲的資訊，證明Suno不是「學會了怎麼寫歌」，而是「背下了這幾首歌，遇到提示就吐出來」。對比之下，如果Suno的訓練做得夠好、真的只學到抽象的作曲技巧而非記住具體歌曲，同樣的輸入應該只會生成風格相近但內容不同的新歌，不會被判侵權。這個案例的意義在於：法院把「AI生成內容跟原作太像」這件事，直接歸咎於AI公司選了什麼訓練資料、怎麼設計模型，而不是使用者打了什麼提示詞——這可能影響其他AI音樂生成服務未來在歐洲的營運方式。
開發團隊 ABUS（abus-aikorea）在 GitHub 發布開源專案 Voice-Pro，這是一套整合多種 AI 語音技術的網頁應用程式，介面用 Gradio（一種讓工程師快速做出網頁操作介面的工具）打造。它把語音辨識（把說話聲音轉成文字，用的是 Whisper 系列模型）、零樣本語音克隆（只要給一小段某人的聲音樣本，AI 就能模仿這個人的音色講出任何句子，不需要事先訓練）、文字轉語音（支援 Edge-TTS、kokoro 等引擎）、YouTube 影片下載、人聲與背景音樂分離（Demucs，可以把一首歌拆成純人聲和純伴奏）、以及跨百種語言的翻譯功能全部整合在同一個工具裡。專案使用 LGPL 授權，免費且可自由散佈與修改；另外，由於 WeConnect 開發工作的緣故，Voice-Pro 的開發與更新暫時無法進行，但程式碼已全部開源釋出。
假設我是 YouTuber，做了一支英文教學影片，想快速產出韓文配音版本給韓國觀眾看，過去常要花錢請人翻譯配音，或用好幾套軟體分開處理。用 Voice-Pro，可以在同一個網頁介面裡把這些步驟串起來：貼上 YouTube 連結下載影片，用 Demucs 把人聲和背景音樂分離，用 Whisper 把語音轉成文字，再用內建翻譯把文字內容翻成韓文，最後用零樣本語音克隆（例如 F5-TTS），以原本講者的聲音特徵產生韓文語音。也就是說，這類翻譯配音工作有機會在單一工具內完成，不必另外找人配音，也不用一直切換軟體；實際成果則要看素材和設定。
字節跳動（ByteDance）在 GitHub 上開源了名為 DeerFlow 2.0 的專案，這是一套「超級代理（super agent）」框架，也就是能幫你自動完成研究、寫程式、做東西等長時間任務的 AI 系統骨架（一個任務可能要跑好幾分鐘到好幾個小時）。它結合了沙盒（sandbox，一個隔離的安全執行環境，讓 AI 可以放心跑程式碼不會弄壞你的電腦）、記憶功能、工具呼叫、可擴充的技能模組（skill）、多個子代理（sub-agent，一個主 AI 底下再派出好幾個小 AI 分工）、以及訊息閘道（message gateway，讓 AI 可以接進各種通訊軟體收發訊息）。DeerFlow 2.0 是完全重寫的新版本，並曾於 2026 年 2 月 28 日登上 GitHub Trending 第一名。專案官方建議搭配字節跳動自家的 Doubao-Seed-2.0-Code、DeepSeek v3.2、Kimi 2.5 等模型使用，並提供 Docker 部署選項。
假設你想做一個「每天自動幫我調查某個產業新聞、整理成報告、還要幫我寫一段程式去抓資料」的任務，這種任務步驟多、耗時長（可能要跑好幾小時），對一般聊天型 AI（一問一答、沒有記憶、不會自己規劃步驟）來說可能難以勝任。用 DeerFlow，你可以把這種長期目標交給它，它會結合多個子代理（sub-agent，一個主 AI 底下再派出好幾個小 AI 分工）、記憶功能、沙盒（安全執行環境）、工具與技能模組來協調執行，也能替工作階段設完成條件（Session Goal）。相較於自己手動開好幾個 AI 對話視窗、複製貼上結果、自己接續進度，DeerFlow 把這些流程串起來，降低人在中間反覆協調的負擔。
微軟（Microsoft）在 GitHub 上釋出一套名為「Generative AI for Beginners」的免費教學課程，目前在 GitHub Trending（GitHub 上每日熱門專案排行榜）排名第 9。這套課程由微軟的雲端技術推廣團隊（Cloud Advocates）製作，一共有 21 堂課，每堂課教一個生成式 AI（Generative AI，也就是能自己生成文字、圖片、程式碼等內容的 AI，例如 ChatGPT 背後的技術）相關主題，讀者可以挑自己有興趣的單元開始學，不必照順序。課程分成「Learn」（純講解概念）和「Build」（邊講概念邊教你寫程式）兩種類型，程式範例同時提供 Python 和 TypeScript 兩種程式語言版本。整套課程已被翻譯成超過 50 種語言，包含繁體中文（香港、澳門、臺灣三種版本），對不熟悉英文的初學者也友善。
假設你是完全沒寫過 AI 程式的社會新鮮人，想知道「生成式 AI 到底是怎麼運作的」以及「怎麼自己動手做一個會回答問題的小工具」。過去你可能要東拼西湊看好幾個不同來源的教學、術語又常常看不懂。用這套課程的做法是：直接照著 21 堂課的順序或挑感興趣的單元讀，例如課程中的 Learn 類型會講解生成式 AI 的基本概念，Build 類型課程則會提供 Python 或 TypeScript 的程式碼範例，讓你跟著動手練習。因為整套課程和程式碼都放在同一個 GitHub 專案裡、有清楚的目錄結構，你不用再自己找散落各處的教材，而且如果你想快速下載使用，作者也提供了「sparse checkout」指令（一種只下載你需要的部分檔案、跳過 50 多種語言翻譯檔的下載方式），讓下載速度快很多。
微軟（Microsoft）在 GitHub 上開源了新的 3D 生成模型 TRELLIS.2，這是一個 40 億參數的大模型，專門用來做「image-to-3D」（輸入一張圖片，AI 自動生成對應的立體 3D 模型）。它用一種叫 O-Voxel 的新技術（可以想成把 3D 物件切成很多小方塊來表示，且能處理很複雜、不規則的形狀，例如衣服的開放表面、鏤空結構），比傳統方法更能重建複雜物件，還能同時產生材質貼圖（顏色、粗糙度、金屬感、透明度等，讓渲染出來更逼真）。微軟同時釋出了論文、預訓練模型（可在 Hugging Face 下載）、線上展示 Demo 以及訓練程式碼。
假設一位遊戲美術想幫一款新遊戲快速做出一批道具模型，傳統做法是請 3D 建模師手動雕刻，一件精細道具可能要花好幾小時。用 TRELLIS.2，只要提供一張道具的參考圖片，模型在 NVIDIA H100 這種高階顯示卡上，1024³ 解析度大約 17 秒（形狀 10 秒＋材質 7 秒）就能生成一個帶完整材質貼圖、可直接匯入渲染引擎使用的 3D 模型，而且能正確處理像鏤空籃子、翻領衣服這種傳統 3D 生成模型容易做壞的複雜形狀。缺點是目前只支援 Linux 系統，且需要至少 24GB 顯示記憶體的 GPU 才能跑，一般家用電腦可能吃不消。
騰訊雲（TencentCloud）在 GitHub 開源了一個叫 TencentDB Agent Memory 的專案，目前在 GitHub Trending（GitHub 每日熱門開源專案排行榜）上排名第 13。這個工具的用途，是讓 AI Agent（能自己執行多步驟任務的 AI 助理，例如會幫你寫程式、查資料、下指令的那種）擁有「共用記憶」，不用每次開新對話都要重新解釋一次背景。它把過去的對話、文件、程式碼，自動整理成四種可重複使用的記憶資產：對話記憶（Chat Memory，記住偏好、事實、決定）、技能（Skill，記住怎麼完成某項複雜工作的步驟）、知識庫（LLM-Wiki，把文件變成有連結關係的知識頁面）、程式碼關係圖（Code-Graph，記錄程式碼裡各個模組彼此如何呼叫、影響）。這些記憶資產可以跨不同的 AI 框架、跨多個 Agent、甚至跨團隊成員共用，團隊新成員或新開的 Agent 可以直接繼承既有的經驗，不用從零學起。
假設一個工程團隊每次叫 AI Agent 幫忙改程式碼，都要重新解釋一次「行動裝置那邊還在用舊版登入模組，不要重構它」，這種提醒很容易被遺忘或每次都得手動打字。用了 TencentDB Agent Memory 之後，這句叮嚀會被存成 Chat Memory 的一筆記錄，掛在對應的 Agent 底下；之後透過 Memory Hub 的管理機制，同一個 Agent 或獲得分派的新 Agent 在處理相關工作時，可以帶著這條記憶上工，不需要人重新摸索。同樣地，如果某位工程師已經摸索出一套「排查某類錯誤」的完整步驟，可以把它存成一個 Skill（附版本、需要的檔案、觸發條件、驗證方式），經審核分享後，團隊裡的 Agent 遇到同樣問題時也能載入這套技能來用，不用每個人各自重新摸索一次。
Lean FRO（Lean 這套「證明助手」軟體背後的官方開發團隊，Lean 是一套用電腦嚴格檢查數學證明對不對的軟體，數學家或工程師可以用它寫出「機器可驗證」的證明）在部落格發布一篇資安事後檢討文章。事件起因是 2026年7月25日 Ramana Kumar 公開了一個「靠 AI 協助產生」、看似證明瞭柯拉茲猜想（Collatz conjecture，一個數學界懸而未解近百年的著名猜想）不成立的檔案，且沒有用到 Lean 裡代表「這裡先跳過、不算真證明」的 sorry 標記。這份宣稱的反證並不成立，而是利用了 Lean 核心程式（kernel，負責最終把關證明是否正確的部分）處理「巢狀歸納型別」（一種程式裡描述資料結構的方式）時的一個漏洞，讓錯誤的推論被誤判為正確。7月28日，另一位開發者把它簡化成一個可以推出 False（假命題）的小型證明並開出 issue；官方在回報後一小時內就修好並發布更新。另外，OpenAI 的 Daniel Selsam 也協助 Lean FRO 用一個專攻資安的 AI 掃描核心程式，找出並修復了其他類似漏洞。
假設我是數學家或工程師，寫了一份 Lean 證明，想確認它「真的沒有邏輯漏洞」，可以同時用官方 kernel 和外部獨立檢查器 nanoda（由 Chris Bailey 用 Rust 語言另外寫的一套獨立驗證程式，用來交叉比對官方 kernel 判斷是否正確）雙重驗證，而且兩套都要更新到最新版，理論上兩邊都通過才更可信。這次事件顯示：有人用 AI 生成一份表面上「證明柯拉茲猜想不成立」的檔案，實際上是鑽了 kernel 一個特定漏洞的空子，讓一段邏輯錯誤的推論被系統誤判為合法證明；巧的是它也剛好繞過了 nanoda 當時版本的另一個獨立漏洞（該漏洞在 Lean 漏洞被回報前一週就已被修復，只是舊版 nanoda 仍會放行）。換句話說，光靠一套自動驗證系統是不夠的，需要兩套獨立實作互相交叉檢查才能提高可信度。同時，這件事也顯示 AI 是雙面刃：一邊可能被用來製造「看起來合理、其實有漏洞可鑽」的假證明或假反證，另一邊 OpenAI 也用專攻資安的 AI 主動掃描 Lean 核心程式，找出並修補更多同類型的程式漏洞。
Cursor（一款熱門的 AI 程式輔助編輯器，開發者用它讓 AI 幫忙寫程式、改程式碼）近日更動了自家「Usage」用量頁面與 CSV 匯出功能，把原本顯示的「花了多少美元」改成只顯示「用了多少 token」（token 是 AI 模型計算文字用量的基本單位，一般人很難直接感受它對應到多少錢）。官方在論壇回應說明，這是刻意的設計：Ultra 方案採用按用量（token）計費，被方案內含額度涵蓋的用量會顯示「已包含」而非金額，只有超出額度、真的要額外付費的部分才會顯示美元。但受影響的不只是頁面顯示，連後端 API 過去會回傳的每次請求費用欄位（chargedCents 等）從 2026年7月31日起也全部被歸零，連歷史紀錄都被連帶清空金額，只有企業方案用戶仍能看到完整美元金額。大量開發者與團隊管理員在論壇留言反映不滿，認為這讓他們無法追蹤每天、每個模型的實際花費，也無法比較不同模型（例如 Grok 4.5 與 Opus 5）的性價比，直呼是透明度倒退。
假設你是團隊技術主管，手下多名工程師共用 Cursor Teams 的按需計費額度（on-demand usage cap）。2026年7月31日改版前，你可以打開 Dashboard 的 Usage 頁面或匯出 CSV，看到不同成員、不同日期、不同模型的美元花費，藉此追蹤成員用量，判斷誰該少用比較貴的模型。改版後，Usage 頁面改成只看得到 token 數字，匯出的 CSV 也不再包含美元成本；原本的 API 端點 get-filtered-usage-events 回傳的 chargedCents、usageBasedCosts 費用欄位也全部歸零，連歷史紀錄中的金額也被一併清空，等於原本靠這個 API 自己記錄每筆請求費用的做法失效了。Dashboard > Spending 仍能看到當期 On-Demand 總花費；Teams 管理員也可到 Dashboard > Members > On-Demand 看每個成員的累計總額，但沒有各模型的美元明細。也就是說，想在 Dashboard 上控管預算、評估模型效益的團隊主管，只剩總數和每人總額可看，少了更細的分項。
微軟研究院（Microsoft Research）與中國人民大學 IDEAS 實驗室合作，開源了一套名為 Flint 的「視覺化中間語言」（intermediate language，可以理解成一種介於「你想畫什麼圖」和「電腦畫圖軟體實際要的複雜設定」之間的翻譯層）。過去無論是人或 AI 代理（agent，就是能自己執行任務的 AI 程式）要畫圖表，都得手動去調整一大堆技術細節，像是座標刻度、軸線位置、間距、標籤怎麼擺、版面怎麼排。Flint 讓使用者只要給一份簡單、人也看得懂的圖表規格（比如說「這欄是體重、那欄是油耗、用國家分顏色」），Flint 的編譯器就會自動幫你推算出最合適的圖表設定，不用逐項手動微調。它還支援輸出成 Vega-Lite、ECharts、Chart.js、Plotly 等多種常見圖表函式庫的格式，甚至可以直接產生 Excel 原生圖表，同一份規格可以「編譯」到五種以上不同的圖表系統。這則消息在 Hacker News 上獲得 231 個讚、65 則留言，顯示在開發者社群中頗受關注。
假設一個 AI 客服機器人被使用者要求「幫我畫一張各國汽車油耗和車重的關係圖，用顏色區分國家」。用傳統做法，工程師得先寫程式指定 X 軸範圍、Y 軸刻度、圖例位置、每個資料點的顏色編碼規則等一大串設定，稍有疏漏圖就會跑版或看不清楚，而且如果要換一套繪圖函式庫（例如從 Chart.js 換成 Plotly），整套設定往往要重寫。用 Flint，開發者或 AI 代理只需要提供一份精簡規格，內容大概是「圖表類型：散佈圖；X 軸：體重（數量型）；Y 軸：油耗（數量型）；顏色：國家（類別型）」，呼叫 Flint 的其中一個轉換函式（例如 assembleVegaLite 或 assembleECharts），Flint 就會自動算好座標軸範圍、間距、標籤配置等所有繁瑣細節，直接產出一張排版正常、可用的圖。換函式庫時規格完全不用改，只要換成呼叫 assembleChartjs 或 assemblePlotly 就能得到對應格式的圖表輸出，省掉重新手動調參的麻煩。
量子位報導，OpenAI（開發ChatGPT的AI公司）聯合創辦人兼執行長奧特曼在Relentless節目《How to Start a Startup》訪談中，透露了公司決策內幕與他個人的創業方法論。他提到，OpenAI在編碼智能體（也就是能自動幫你寫程式、改程式的AI助手，例如OpenAI的Codex）取得突破後，決定停掉原本也被看好的Sora（OpenAI的AI影片生成工具）和瀏覽器業務，把算力、人才和資源集中投入到通用人工智慧（AGI，指能像人一樣完成各種任務的AI）這個核心方向。他也提到，為了開發Sora應用，他特地下載TikTok研究使用者為何上癮，結果自己也沉迷其中：原本打算睡前只刷十分鐘放鬆，結果有天晚上一刷就是一個小時，還有一次週六下午在沙發上刷了整整三小時，後來他索性刪掉TikTok、關掉手機大部分通知。訪談中他也談到創業心法：認為多數創業者思路太同質化、不敢挑戰看似不切實際的目標，以及他判斷一件事是真趨勢還是假趨勢的標準，是看它會不會真正融入使用者的日常生活。
舉例來說，OpenAI的程式碼工具Codex（自動寫程式的AI工具）原本在內部評估中遠遠落後於對手的Claude Code，多數人認為想靠一款新產品打敗對方近乎不可能。但OpenAI團隊判斷「自動編程」這個賽道戰略價值極高，於是專門組建團隊攻堅，結果反而讓Codex逆轉局勢，目前據奧特曼所說已有大量頂尖工程師改用OpenAI的工具寫程式。這也解釋了為什麼原本被看好的Sora，在資源排序上會被往後排——因為OpenAI選擇把資源集中投入它判斷更關鍵的通用人工智慧方向。
量子位報導，美妝集團歐萊雅（L'Oréal）首次亮相世界人工智能大會（WAIC），展示了它把AI（人工智慧，能理解文字、生成內容的電腦技術）用到美妝業務各環節的成果。歐萊雅推出了面向消費者的生成式AI（能自己生成文字、圖片、建議內容的AI）美容顧問3CE GENBA，消費者只要用文字描述自己的需求，AI就能給出產品和妝容建議。除了消費者端的產品，歐萊雅也把AI用到研發、內容製作、客服和工廠品管等後臺環節，並在過去一個月讓中國區超過七成員工做了AI能力自我測驗，全球有超過7.3萬名員工完成生成式AI培訓。歐萊雅高層強調，這不只是行銷噱頭，而是想把AI變成能長期累積的組織能力，並在WAIC期間與火山引擎（字節跳動旗下雲端服務商）簽署合作備忘錄。
想像你是歐萊雅的研發人員，要測試一款新洗髮配方對不同髮質的效果，傳統做法得在真實實驗室裡一次次調配、試錯，換一種髮質就要重新測試一輪，非常耗時。歐萊雅展示的「頭髮數位孿生」（Hair Digital Twin，也就是用AI在電腦裡建一個頭髮的虛擬分身）技術，能先在數位世界裡模擬各種配方對不同髮質的反應，篩選出比較有機會成功的組合，再挑出來做真實實驗，官方表示這樣的篩選速度可以達到傳統實驗室的3倍。另一個具體例子是AI客服：歐萊雅的AI客服系統在剛內測時，回答準確率只有80%出頭，團隊持續補充業務資料、反覆測試並修正錯誤，一步步把準確率拉到90%以上。這說明導入AI不是裝上去就完美運作，而是需要像這樣不斷拿真實業務結果回頭調整，才能真正堪用。
微軟的研究團隊發表了一套名為 Echoverse 的新框架，這則消息由 AI 研究者 @omarsar0 在推特上摘要並廣傳。Echoverse 能把一份「規格說明」（specification，也就是描述你想要什麼樣的應用、規則是什麼的文字敘述）自動編譯成一個「有狀態」的應用程式（stateful app，意思是這個程式會記得之前發生過的事、有自己的狀態，不是每次都從零開始），並附帶「有依據的評分器」（grounded graders，也就是能根據明確標準打分、而不是憑感覺亂評的評分機制）。Echoverse 還會分析 AI 代理（agent，就是能自己執行一連串任務的 AI 程式）實際跑起來的紀錄（rollout，指 AI 代理從頭到尾試著完成任務的完整過程紀錄），用來修補訓練環境本身的問題以及訓練訊號（training signal，指用來告訴 AI 「這樣做是對還是錯」的回饋資訊）。這則討論也呼應了本週在 AI 圈流傳的一個共識：AI 模型能力常常不是被模型本身卡住，而是被外圍的「工具運行環境」（harness，指包住模型、負責幫它讀寫檔案、呼叫工具、記憶對話的一整套外部程式）和訓練環境設計卡住。
假設你想訓練一個 AI 代理，如果訓練環境太「淺層」（也就是設計得太簡單、沒反映真實情況），代理正式上線後的準確率可能受影響；淺層環境會傷害上線準確率，深層環境則能改善上線準確率。Echoverse 的做法是：把規格說明自動編譯成一個「有狀態」的應用程式（stateful app，程式會記得之前發生的事、有自己的狀態，不是每次都從零開始），再搭配「有依據的評分器」（grounded graders，根據明確標準打分、而不是憑感覺亂評）為代理的表現打分；Echoverse 會接著分析代理實際執行的紀錄（rollout，指 AI 代理從頭到尾試著完成任務的完整過程紀錄），用來修補訓練環境本身的問題以及訓練訊號（training signal，指用來告訴 AI 「這樣做是對還是錯」的回饋資訊）。
dair_ai（一個專門分享機器學習論文與教學資源的社群帳號）在社群媒體上推薦了一篇論文，介紹OpenMLE這套完整開源框架，目的是讓機器學習工程本身具備遞迴式自我改進（recursive self-improvement，就是讓AI自己不斷修改、測試、進化自己寫的程式，一輪一輪變得更強）的能力。研究團隊在這套框架上訓練出一個350億參數（35B，參數是模型內部調整用的數值，數字越大通常代表模型規模越大）的模型Frontis-MA1，讓它負責用四種基本操作來演化程式：草擬（Draft）、改進（Improve）、除錯（Debug）、交叉組合（Crossover）。這四種操作是透過『執行結果導向的訓練』（就是讓AI實際跑程式碼、看結果對不對，再根據對錯去學習，而不是憑空亂猜）以及強化學習（RL，一種讓AI靠不斷嘗試、根據獎勵訊號自我調整的訓練方式）訓練出來，再串成一個長時間持續搜尋改進方案的迴圈，等於讓『學習』和『演化』在同一個循環裡同時發生。
假設你要解決一個機器學習工程任務，例如寫一個訓練模型的程式並讓它跑出好成績，這正是MLE-Bench Lite這個測試集在評估的事。研究團隊限制每個任務只給12小時、只用一張消費級顯示卡RTX 4090（VRAM上限12GB，也就是一般玩家買得起的等級，不是雲端超級電腦），結果基礎模型只能拿到39.39%的Medal Average（一種綜合評分，分數越高代表解法品質越好），換成Frontis-MA1之後直接衝到60.61%，如果再搭配非同步搜尋和跨任務累積的經驗庫，能到71.21%，這個成績超過了GPT-5.5搭配Codex（OpenAI的程式碼生成工具）的表現，逼近GPT-5.6 Sol和2.8兆參數的Kimi K3。研究團隊還做了對照實驗：固定用同一套搜尋框架、只換掉裡面的模型，Match-SOTA（跟目前最佳解法打平的比例）從50%衝到70%；反過來固定模型、只換搜尋框架，Match-SOTA從20%衝到50%，說明模型本身的訓練和外層的搜尋策略兩者都各自貢獻了很大一部分進步，不是單靠其中一個就能達到這個效果。
知名開發者 Simon Willison（他常寫關於 AI 工具與資料庫的技術部落格）與 Prime Radiant 合作，推出一個叫 smevals 的新工具，可以透過指令「uvx smevals docs」直接試用。這個工具是用來做「eval」（evaluation，也就是評測，簡單說就是測試 AI 模型的回答品質好不好、準不準）的。它的特別之處在於，一般評測工具通常只會固定「執行環境」（harness，就是把 AI 模型接上其他系統、處理輸入輸出格式的那層程式），只去比較「換不同模型」或「換不同提示詞（prompt，就是給 AI 的指令文字）」的結果差異。smevals 則把「執行環境」也當成可以獨立比較的一個變因，因為 Simon Willison 認為實際上線後最常出包的地方，就是資料檢索和輸出格式解析這些「執行環境」環節，而不是模型本身。
假設要比較不同 AI 設定，過去的做法通常是固定同一套執行環境（harness，就是把 AI 模型接上其他系統、處理輸入輸出格式的那層程式），只去比較換模型或換提示詞（prompt，就是給 AI 的指令文字）的差異。smevals 則把執行環境也當成一個可以獨立比較的變因，團隊可以把模型、提示詞、執行環境都納入排列比較；例如同一組條件下換用不同的資料檢索或輸出解析程式，就能看出執行環境的變動對評分結果有沒有影響，這是過去把執行環境固定死的評測工具做不到的。
Google官方Gemini團隊（透過Gemini App官方X帳號）發布本月的「Gemini Drops」更新，一次公佈六項新功能。首先是macOS版Gemini App新增語音功能，可以直接用講話的方式口述文字、幫你摘要檔案內容、改寫文案，不用打字。第二是「Gemini Spark」（Google做的一個24小時待命的個人AI助理，可以幫忙處理日常瑣事）擴大到更多國家和語言使用。第三是推出兩款新模型「Gemini 3.6 Flash」和「Gemini 3.5 Flash-Lite」（Flash系列是Google主打速度快、成本低的輕量模型），號稱推理能力更好、回應速度更快，可以在gemini.google網站的模型下拉選單直接選用。第四是可以先在Gemini裡設定好自己的「數位分身」（一次上傳、之後就不用每次都重新上傳自拍照），之後搭配Google的圖像生成工具Nano Banana就能快速做出以自己為主角的客製化圖片或影片。第五是Gemini能串接的第三方App變多了，新增Dropbox（雲端硬碟）、ViaToR（訂行程活動）、Zillow（找租屋）等，方便使用者直接在對話裡整理檔案、訂票、找房。第六是美國地區的所有使用者現在都能用Gemini生成貼近個人興趣喜好的客製化圖片。
假設你是一個沒有工程背景、平常只用手機和電腦處理日常事務的上班族，想找下個月要租的公寓。這次 Gemini Drops 更新後，Gemini 能連接 Dropbox、ViaToR、Zillow 等第三方服務，讓你在 Gemini 中直接搜尋租屋、預訂旅遊行程與活動、整理雲端檔案。具體串接到什麼程度，會依實際使用情況而定。
科技新聞媒體The Decoder報導，AI（人工智慧）正在接連攻破數學界長年懸而未決的難題，數學家對此反應分歧。今年5月OpenAI發表了對「單位距離猜想」（一個關於幾何圖論、自1946年起懸而未解的數學猜想）的反例，等於推翻了這個猜想，被視為AI在數學領域最重大的成果之一，一週後就有人類研究者借用同樣的證明技巧推翻了另一個重要猜想。菲爾茲獎（數學界最高榮譽獎項之一）得主Timothy Gowers表示，OpenAI的GPT 5.6 Pro曾兩度在他花了不少時間鑽研的問題上，第一次嘗試就給出解答，他憂心若數學家不再培養理解這類成果所需的專業能力，恐導致「數學文化的可能毀滅」；但也有像倫敦瑪麗女王大學教授Abhishek Saha這樣的學者，單純把AI當成提升生產力的工具使用。
研究機構Epoch AI以高難度的「FrontierMath」AI數學基準測驗聞名；其另一個測驗「FrontierMath: Open Problems」專門收錄數學界重大未解問題，近期已出現第二個解答。但在最難的「重大進展」（Major Advance）與「重大突破」（Breakthrough）兩個等級中，AI仍一題未解。相比之下，卡內基美隆大學數學家團隊2026年4月發表的論文，是把SAT求解器（一種自動判斷邏輯命題是否成立的程式工具）、語言模型生成的程式碼、以及形式化證明驗證系統結合起來，解出一道拉姆齊理論（研究「夠大的系統中一定會出現特定規律」的數學分支）中的未解問題，顯示AI目前比較適合處理圖論這類結構清楚的題型，而不是通吃所有數學領域。
這則貼文指出，AI 代理（agent，就是能自己規劃步驟、呼叫工具去完成任務的 AI）專案有所謂「墳場」的說法，但這個說法越來越不適用：企業 AI 專案越來越能真正上線（production，指正式讓公司員工或客戶天天使用，而不是隻在 demo 階段）。關鍵是廠商先在客戶實際工作任務上證明有效果，再持續協助測試、調整，並清楚算出投資報酬率（ROI，白話講就是「花的錢有沒有換回省下的時間或多賺的錢」）。成功案例往往從「可拆解成小步驟」的具體工作流程切入，快速上線後逐步擴大，而不是一開始就想做「全公司大改造」卻沒有訂出明確的成功標準。
舉例來說，一家客服公司若想導入 AI 代理，失敗的做法是直接喊出「用 AI 全面取代客服部門」，卻沒定義成功長什麼樣子、也沒有一步步驗證，結果做了半年還在原地打轉，最後不了了之，變成傳說中的「AI代理墳場」案例之一。成功的做法則是先挑一個具體、可拆解的小任務，例如「AI 自動回覆訂單查詢這一類最常見的問題」，讓 AI 代理先處理這單一步驟，並持續追蹤這步驟省下多少客服人力工時、換算成具體金額；等這塊確定有效、算得出 ROI 後，再逐步把「退換貨查詢」「帳單問題」等其他步驟也交給 AI 代理處理，一步步擴大範圍，而不是一次到位地把整個客服流程丟給 AI。
這篇文章在講 AI 助手成為使用者接觸數位服務的新入口後，介面設計正面臨的改變。以前使用者要做一件事，通常得自己打開對應的 App 或網站；現在 AI 助手可以直接當「前門」，使用者在同一個聊天框裡就能完成很多任務，甚至不會真的打開產品本身。文章提醒設計師：產品要能被 AI 代理人（agent，代替使用者去理解、呼叫、呈現服務的程式）讀得懂、叫得動、畫得出來；同時也要保留一套完整、一致的原生介面，讓需要深入工作的使用者還是有一個清楚的畫面可以操作。
舉例來說，過去使用者要用某個服務，得自己打開它的網站或 App，一個畫面一個畫面慢慢找功能；現在如果產品本身有讓 AI 代理人好理解的結構，使用者只要在 AI 聊天框裡交代任務，AI 就能在背景把產品叫出來完成，使用者的眼前可能只看到聊天框，而不是原本的產品介面。這就是「介面收斂到同一個聊天框」的意思：產品不一定要被使用者親手打開，但一定要能被 AI 代理人叫得動、呈現得出來。
Turing Post文章分析，AI把「執行」（實際動手做事）這個階段的時間大幅壓縮後，企業內部的人力配置開始跟不上。文中用「倉庫」和「圖書館」做比喻：倉庫只是把資料存起來，圖書館則是把資料整理、分類、標註清楚，讓人和AI都看得懂。過去企業的數位轉型確實把倉庫蓋好了——紙本變成紀錄、紀錄變成資料庫、桌面試算表被收進系統——但「圖書館」始終沒有真正建立，因為公司一直靠資深員工的記憶、手動維護的試算表在充當人工圖書館。如今AI要接手這些工作時，才發現知識只存在人的腦子裡，沒有可用的「圖書館」。文章認為，一件工作要經歷「對齊方向、寫清楚規格、動手執行、驗證結果」四個階段；過去執行最花時間，現在AI讓執行縮短到幾分鐘或幾小時，省下來的時間反而落到最後的「驗證」和最前面的「對齊方向」這兩關，而這兩關沒有哪個現有部門在負責。
以OpenAI內部的「前線部署工程師」（Forward-Deployed Engineer，簡稱FDE，就是被派到客戶端、從頭到尾跟一個專案的工程師）為例：這個角色要負責探索客戶需求、界定專案範圍、設計系統、實際建置、推動上線、最後量化這個專案到底帶來多少實際效益，一條龍全包，而不是傳統上「工程師只管寫程式、業務只管談需求」分工。文章舉一個具體情境：讓一個AI代理去讀公司的定價資料表、追蹤裡面的計算邏輯，它可以自己搞懂「現在的定價規則是怎麼運作的」；但它沒辦法自己決定「這一季的企業客戶折扣要不要算進去」——這種「範圍該不該包含什麼」的判斷，仍然只能靠人來把關，一旦沒人把關，AI代理就會自己悄悄替公司做了決定，而沒人發現權力已經被悄悄轉移出去了。
LMArena（經營AI模型競技評測平臺Chatbot Arena的團隊）在X（推特）官方帳號發布最新一批「Image-to-WebDev」（圖轉網頁開發，就是讓AI看一張網站截圖或設計圖，直接生成對應的網頁程式碼）測試結果。這次比較了Opus 5（Max版）、GPT-5.6系列（Sol、Luna、Terra）、Grok-4.5、Kimi K3（Max版）、Muse Spark 1.1等多款主流AI模型，用同一套任務評分排名。結果顯示Anthropic的Opus 5（Max）拿下第一名，但底下有留言指出Opus 5品質近期明顯下滑，已經不再明顯贏過GPT-5.6 Sol。
假設一家新創公司想把手上一批客戶提供的網站設計截圖，自動轉換成可用的網頁前端程式碼，省下工程師手動切版的時間。過去只能靠工程師肉眼看圖手刻HTML/CSS，或用單一AI模型試錯、不確定效果好壞。現在有了Code Arena的Image-to-WebDev排行榜，這家公司可以直接查表：目前第一名是Opus 5（Max），得分1,669分；GPT-5.6 Sol（xHigh模式）排第4，1,581分；Grok-4.5第5，1,578分。公司就能依排名直接選用評分最高、最擅長「看圖轉碼」的模型來跑這項任務，而不用自己花時間逐一測試每個模型，等於是站在別人已經做好的評測基礎上做選型決策。
科技新聞網站Ars Technica報導，美國聯邦地區法官Paul A. Engelmayer駁回了網路爬蟲公司SerpApi要求撤銷Reddit訴訟的請求。這起官司源自Reddit控告SerpApi與Perplexity AI共謀，透過Google搜尋結果非法爬取受著作權保護的Reddit內容。法官認為，Reddit已初步提出可信的說法：SerpApi提供工具讓人繞過Google的存取管控，而Perplexity AI付費使用這項工具。這起判決是在Google另一起類似訴訟被駁回不到兩週後作出，與Google案形成對比，顯示同樣主張著作權保護卻可能有不同結果，凸顯AI相關的網路爬蟲著作權法律風險。
這起案件的具體爭議是：一般人用Google搜尋Reddit上的討論時，會看到Google顯示的內容摘要（snippet），這些摘要理論上受Google的「反規避技術措施」保護，避免被自動化程式大量擷取。但Perplexity AI據稱付錢向SerpApi這家網路爬蟲公司購買工具，繞過Google的存取管控，藉此抓取Reddit內容。Reddit認為這等於是SerpApi與Perplexity AI雙方合謀規避著作權保護技術去偷資料，因此提告；法官這次的裁定是說，Reddit這個說法在現階段是「可信的」，官司可以繼續打下去，還沒到最終判決誰對誰錯。對比之下，Google自己告SerpApi的類似官司卻被法院駁回，因為Google沒能證明像Reddit這樣的著作權所有人真的授權Google去設下防爬蟲機制。這顯示同一件事（AI公司爬取網站內容），法院要看誰跟誰有明確授權關係，才能判斷爬蟲行為算不算「規避技術保護措施」而違法。
這是韓國開發團隊 NomaDamas 在 GitHub 上發布、並登上 GitHub Trending（GitHub 每天統計的熱門專案排行榜）的開源專案「k-skill」。它是一組給 AI coding agent（也就是 Claude Code、Codex、OpenCode、OpenClaw/ClawHub 這類能幫你寫程式、執行任務的 AI 助理）使用的「技能包（skill）」，讓這些 AI 助理可以直接處理韓國在地的生活瑣事，例如訂 SRT 高鐵票、訂 KTX/Korail 火車票、訂客運車票、查首爾地鐵到站時間、查首爾公共自行車車位、查 macOS 版 KakaoTalk 訊息等。專案也提供一個叫 k-skill-proxy 的可選代理服務，必要時對它送出 HTTP 請求即可。
假設你想搶一張常常秒殺的 SRT 高鐵票，傳統做法是自己手動一直重新整理訂票網站碰運氣。用 k-skill 的話，你先在終端機執行 npx --yes skills add NomaDamas/k-skill --skill srt-booking -g 安裝這個訂票技能，之後在 Claude Code 這類 AI coding agent 裡跟它說「幫我訂某天某班次的 SRT 票」，AI 就能協助你完成 SRT 列車查詢、座位確認、預約與取消的流程。不過這項技能需要你用自己的 SRT 帳號登入後才能操作。
LangChain的@hwchase17貼出目前LangChain生態系地圖，列出LangGraph、DeepAgents、LangSmith三個項目。他指出，任何人想從零打造agent執行框架（harness，agent就是能自己規劃步驟、呼叫工具完成任務的AI程式），幾乎都會遇到同一批問題：非同步執行（async，讓程式能同時處理多件事而不卡住）要做好、資源生命週期（resource lifecycle，程式用到的記憶體或連線等資源何時該釋放）要管理、agent框架的設計研究要做，還需要評估機制（eval，評量agent表現的方法）。他之後進一步強調標準化的內部評估，以及以Harbor為基礎的任務轉換。
假設我想從零打造一個AI agent執行框架（harness），就得自己解決非同步執行、資源生命週期管理、agent架構設計和評估等基礎問題。LangChain這張生態系地圖列出LangGraph、DeepAgents、LangSmith三個項目，並強調標準化內部評估和以Harbor為基礎的任務轉換；這正是在回應這類從零開始會踩到的痛點。
PromptLayer（一家提供 LLM（大型語言模型，就是像 ChatGPT 這樣能對話生成文字的 AI）應用開發與評測工具的公司）的創辦人 Jonathan Pedoeem 發布影片，介紹一項新功能：在 Playground（測試介面）與評測流程中，可以「模擬」工具（tool，指 AI agent 呼叫的外部功能，例如查資料庫、發 API 請求）的回應結果。這可能代表開發者測試 AI agent（能自己規劃、呼叫工具完成任務的 AI）時，不必真的接上後端系統或外部服務，就能跑完整流程。這類「評測基礎設施」的演進，反映業界正從工程師各自寫的臨時筆記本程式，走向公司統一管理、可重複執行的正式測試系統。
以測試 AI agent 為例，當 agent 在對話中呼叫某個外部工具時，開發者可以預先設定一筆模擬回應，讓它不連接真實後端也能繼續跑完整個流程。過去這類端到端測試往往需要先準備好後端環境，現在則可以先用模擬回應跑完整個流程。實際能做到多精細，可能取決於開發者怎麼設定。
OpenAI（ChatGPT 背後的開發公司）針對桌面版與應用程式操作體驗推出多項更新。首先，ChatGPT 的語音功能（Voice，可以直接開口跟 AI 對話、AI 用聲音回覆、不必打字）現在正式支援 macOS 和 Windows 電腦版應用程式。其次，OpenAI 開發者團隊（OpenAIDevs）推出全新的「活動（Activity）」視圖。最後，OpenAI 也新增了寵物觸發的語音捷徑，可以快速切換進入語音模式。這幾項都是介面與操作體驗上的小幅優化，並不是底層 AI 模型能力的升級。
舉例來說，ChatGPT 的語音功能現在可以在 macOS 和 Windows 應用程式中直接使用，你開口說話就能得到語音回覆，不必動手打字；寵物觸發的語音捷徑也能讓你更快進入語音模式。這些都是方便日常使用的小工具型更新，差別在操作便利性，而不是 AI 回答品質或能力本身有什麼改變。
Devin 是 AI 程式代理（agent，就是能自動幫忙寫程式、跑測試的 AI 助理）產品，由 Cognition 公司開發。它現在可以在 macOS 環境中搭配 Xcode（蘋果官方用來開發 iOS App 的工具）和模擬器（simulator，就是在電腦上模擬手機畫面來測試 App 的軟體）來開發、測試原生 iOS 應用程式。加入 Cognition 的 Jared Palmer 至今還沒設定自己的筆電做本地開發，偏好直接在 Slack 或網頁版用雲端的 Devin 寫程式，連前端工作也一樣。
假設我想開發一個 iOS App，過去的做法是要自己準備一臺 Mac 電腦、安裝 Xcode、開啟模擬器，然後親自寫程式碼、手動在模擬器上跑起來測試哪裡有問題。現在用 Devin 這類雲端代理，開發者可以在 Slack 或網頁上請 AI 幫忙開發、測試原生 iOS 應用程式，例如讓它自動寫 iOS 程式碼、在模擬器上跑測試結果。Jared Palmer 加入 Cognition 後至今還沒設定筆電做本地開發，就是這種工作方式的例子。差異在於：以前寫 App 高度依賴本地開發機器和手動操作，現在則可以透過雲端代理與 AI 協作來完成。
Cognition（開發 AI 寫程式代理人 Devin 的公司）宣佈 Devin 現在原生支援 GitHub 的堆疊式 PR（Stacked PRs，就是把一個大改動拆成一串前後相依、依序疊起來的多個小 Pull Request，方便逐一審查）。這代表 Devin 產生程式碼改動時，可以自動把一大包變更拆解成好幾個比較小、比較容易被人看懂並審核的差異（diff），而不是丟出一個龐大難以審查的改動。此外 Devin 也能針對堆疊中各層的審查意見（comment）分別回應並修正，並在下游的改動需要時自動幫忙做 rebase（把新改動重新對齊到最新的基準版本上，避免衝突）。整體來說這是針對「AI 自動產生大量程式碼改動」這個場景做的實用性調整，讓人類審查者比較容易消化 AI 寫出來的東西。
假設你請 Devin 幫忙把一個舊系統的認證機制從 A 方案換成 B 方案，這種改動往往牽涉到好幾個檔案、好幾個邏輯步驟（例如先加新的設定、再改登入流程、最後刪除舊程式碼）。過去如果 Devin 把這些改動全部塞進一個 PR，審查者要一次消化幾百行分散在不同檔案的變更，很容易看漏問題。有了堆疊式 PR 支援後，Devin 可以把這個大改動拆成三個依序疊放的小 PR：第一個只加新設定、第二個切換登入流程、第三個清掉舊程式碼，審查者可以一個一個看、一個一個核准。如果審查者對第一個 PR 提了修改意見，Devin 修正後，後面依賴它的第二、第三個 PR 會自動重新對齊（rebase），不用人工再去處理合併衝突。
根據TechCrunch報導，SpaceX（2026年2月收購AI公司xAI）表示，正在為xAI位於曼菲斯附近的Colossus資料中心（大型伺服器機房）興建一座永久性、發電容量1.2百萬瓩（gigawatt）的天然氣發電廠。目前供電用的69臺燃氣渦輪機（一種發電機組）要到2027年7月才會完全撤除。美國有色人種協進會（NAACP）與南方環境法律中心已對xAI提告，指控這些渦輪機未取得許可證就運作；這些渦輪機位於曼菲斯以南、密西西比州境內，當地是全美汙染最嚴重的地區之一，每年可能排放超過2000噸會形成霧霾的氮氧化物。SpaceX主張渦輪機仍放在運送用的拖車上，因此不需要許可證；但聯邦法規認為，這些渦輪機因其規模與使用方式，不管是否在拖車上都須取得許可。
這則新聞揭露了AI基礎建設背後的環境代價：AI資料中心需要大量電力，xAI的Colossus資料中心目前靠未經許可的燃氣渦輪機供電，之後會在改用新電廠的過程中陸續汰換，但舊機組要到2027年7月才會全部撤除。對關心AI產業的人來說，這是一個具體案例，說明「AI產業快速擴張」與「環境合規、當地居民健康」之間的衝突：在舊機組完全撤除前，曼菲斯周邊居民仍要承受空汙風險，而這一切都是為了讓xAI的資料中心能持續運轉。