OpenClaw 是一個開源的 AI Agent 框架（「AI Agent 框架」是讓開發者快速搭建能自動執行複雜任務的 AI 機器人的工具包），在 2025 年底發布後只花幾個月就累積了 346,000 個 GitHub star（star 是開源社群表示讚賞的計數方式，可視為知名度指標）和 320 萬名用戶，創下開源歷史上最快成長紀錄。它的核心賣點是「算力套利」——利用 Anthropic（Claude AI 的開發商）的訂閱帳號身份繞過官方 API 計費路徑（「API」是讓程式與 AI 服務溝通的收費接口），讓用戶以每月約 200 美元的固定費用使用原本要花五倍以上的 AI 算力，等於是鑽了收費系統的漏洞。然而 2026 年 4 月，Anthropic 直接封鎖了這條代理路徑，OpenClaw 的核心競爭優勢一夕歸零；加上框架累積了 138 個以上的安全漏洞（CVE，即被公開記錄的已知安全缺陷），其中包含可讓攻擊者在你毫不知情的情況下遠端控制你電腦的高危漏洞（稱為 RCE，即遠端執行任意程式碼），超過 40,000 個部署在公開網路的實例都暴露於風險中。這個案例為整個 AI 開源生態敲響了警鐘：單靠鑽定價漏洞起家、缺乏完善安全設計的框架，在外部政策一變之後毫無抵抗力；創辦人於 2 月轉職加入 OpenAI 後，維護動力大幅流失，更加速了框架的衰退。
假設你是一家中小公司的工程師，想讓 AI 每天自動監控競品官網、爬取新聞、整理成摘要報告，這正是 AI Agent 框架的典型應用場景。用 OpenClaw 全盛時期的做法，你只需一個 Claude Max 訂閱帳號（每月約 200 美元），框架會以你的訂閱身份去呼叫 Claude AI，等於讓大量的 AI 運算費用都「包含在月費裡」；若改用官方 Anthropic API 按量計費，同樣任務量每月可能要花 1,000 美元甚至更多，差距高達五倍，這就是「算力套利」的實際效果。問題是 2026 年 4 月 Anthropic 修改系統後，訂閱帳號無法再被第三方工具代用，你的省錢方案瞬間失效，成本直接跳回五倍正常費率。更糟的是，若你已把 OpenClaw 部署在有對外網路的伺服器上，CVE-2026-25253 漏洞（一個信任錯誤導致的高危安全缺陷，CVSS 評分 8.8）讓攻擊者只需誘騙你點一個惡意連結，就能完整控制伺服器、竊取認證憑證並執行任意命令——這不是升級版本可完全解決的問題，因為整個安全架構從設計之初就有根本缺陷，換用 Hermes Agent 或官方 Claude Code 等替代方案才是真正的解法。
Anthropic（開發 Claude 這套 AI 對話助手的公司）在 2026 年 4 月推出了一款名為 Mythos 的 AI 安全研究工具，設計目的是自動掃描電腦程式的原始碼，幫助資安工程師找出其中可能被駭客利用的安全漏洞。這次，Mythos 掃描了全球最廣泛使用的網路傳輸工具 curl（幾乎每台電腦和伺服器都內建它）的 17 萬 8 千行程式碼，並標記出 5 個「確認漏洞」。但 curl 的安全團隊仔細核查後，只有 1 個是真正的安全漏洞——已取得 CVE 編號（也就是官方認可的安全漏洞 ID）；另外 3 個是「誤報」，也就是 AI 誤判了 API 文件（程式功能說明書）中已有記載的正常行為，1 個只是一般程式錯誤，與安全無關。這代表 Mythos 在 curl 案例中的誤報率（假陽性率）高達 80%，讓資安社群對 AI 安全審計工具的實際效果保持謹慎。值得一提的是，Mythos 同期掃描 Firefox 瀏覽器找到了 271 個漏洞、181 個可完整利用的攻擊程式，顯示它在「安全成熟度較低」的程式庫中能力強得多——curl 本來就是全球被最密集審計的程式碼庫之一，是特別高難度的測試場。
假設你是一間公司的資安工程師，負責維護一個有十幾萬行 C 語言程式碼的舊版內部工具庫（C 語言是一種歷史悠久的程式語言，廣泛用於作業系統和底層工具，安全漏洞相對常見）。過去要找安全漏洞，你得手動閱讀程式碼、反覆測試，或等待外部安全研究員主動回報，往往需要花幾個月。現在用 Mythos 這類 AI 工具，可以在幾小時內掃描整個程式庫，拿到一份「可疑漏洞清單」。以 curl 案例為參考：Mythos 回傳 5 個「確認漏洞」，安全團隊核查後，其中 3 個是文件已記載的正常行為（AI 誤判）、1 個是一般 bug，只有 1 個是真正需要修補的安全漏洞，預計在 curl 8.21.0 版本修補並公開。對比舊做法：AI 的優勢在於幾小時內覆蓋幾十萬行程式碼，速度遠超人力；弱點在於誤報率高，資安團隊仍需逐一判斷哪些是真漏洞。AI 節省的是「找線索的時間」，但並未取代「人工判斷的工作量」。
OpenAI（就是做出 ChatGPT 的那家 AI 公司）在 2026 年 5 月宣布成立了一家新子公司，叫做「OpenAI Deployment Company」，簡稱 DeployCo。這家公司的核心任務是幫企業把 AI 真正用起來——不只是給企業一個 API（就是讓不同軟體系統互相溝通的接口），讓他們自己慢慢摸索，而是直接派工程師住進客戶公司辦公室，手把手把 AI 嵌入他們現有的工作流程。DeployCo 採用的是「FDE 模式」（Forward Deployed Engineer，前線部署工程師），這種做法源自資料分析公司 Palantir——工程師長期駐點在客戶辦公室，依照客戶既有的系統架構、資料庫和法規合規需求量身整合，而不是賣給你一套通用工具然後拍拍手走人。同步地，OpenAI 收購了蘇格蘭 AI 顧問公司 Tomoro，引入 150 名具備現場整合經驗的工程師，並取得包括 TPG Capital、Bain Capital、麥肯錫、貝恩顧問等共 19 家機構合計 40 億美元（約合新台幣 1,280 億元）的投資，這些顧問公司同時把旗下龐大的企業客戶網絡直接導入 DeployCo 的業務管道。
以 BBVA（西班牙最大銀行之一）為例：BBVA 想讓旗下全球 25 個國家的 12 萬名員工在日常工作中使用 ChatGPT Enterprise（企業版 ChatGPT）。若只靠銀行自身的 IT 部門，光是把 AI 與內部的客戶資料系統、風控流程、合規稽核系統串接起來，可能要花一兩年還整不好，因為銀行的合規要求繁瑣、資料分散在各個老舊系統裡。有了 DeployCo 的工程師進駐，他們會先了解每個部門的現有流程，再設計 AI 如何嵌入——例如讓客服人員可以問 AI「這位客戶的信用評分為什麼是這個數字」，AI 直接從 BBVA 內部資料庫抓出依據並給出解釋，而不是給一個通用、無依據的回答。最終結果是 ChatGPT 在 BBVA 的核心業務流程中全面跑起來，而非只有少數員工偶爾用用。相比過去企業要自己找一般資訊顧問公司、花大量時間踩坑，DeployCo 結合了 OpenAI 的模型能力與駐點整合經驗，能大幅縮短 AI 導入週期，讓 AI 真正進入企業日常作業而非停留在「試用階段」。
Multi-Token Prediction（MTP，多 token 預測）是一種加速 AI 文字生成的新技術，正在被整合進 llama.cpp（一個讓你在自己電腦或伺服器上跑大型 AI 語言模型、完全不需要連接雲端或付 API 費用的開源程式）。傳統的 AI 文字生成是「一次輸出一個字/詞」，MTP 讓模型一次同時草擬好幾個詞，再批次確認哪些正確，最終結果完全相同，但速度快了 2 到 2.5 倍。最大的亮點是：MTP 不需要另外安裝一個獨立的「草稿 AI 模型」，加速功能直接內建在同一個模型檔案裡，大幅降低個人開發者和小企業的部署難度。目前另一個本地 AI 執行工具 Ollama 已在測試版 v0.23.1-rc0 搶先整合，實測 RTX A6000 顯卡上速度從每秒 20 個 token 提升至 55 個；llama.cpp 的對應 PR 仍在審查中，正式合併後即可使用。
假設我在自己的電腦上用 llama.cpp 跑 Qwen3 27B（一款需要高品質量化的大型語言模型），基線速度約每秒 13 個 token，對話回應感覺像字在慢慢打出來，思維容易被打斷。升級到支援 MTP 的版本後，只需要在啟動指令後面加上 `--spec-type mtp --spec-draft-n-max 3` 這段設定，模型就會自動切換成「每次草擬 3 個詞、批次確認」的模式，速度直接跳到每秒 46 個 token，提升了 250%。對比舊做法：硬體沒換、模型沒換、也不需要多付錢，單純改幾個參數就讓本地 AI 從「勉強能用」變成「接近即時回應」，對單人使用或小批次推理場景效果最顯著。
一家知名網路安全公司 Cloudflare（就是幫全球網站擋攻擊的那家公司）的分析師公開指出：現在的 AI 可以在 30 分鐘內，把軟體廠商剛發布的「安全修補程式」（patch，就是用來修補軟體漏洞的更新檔）反轉成能實際入侵電腦的「攻擊程式」（exploit，就是用來利用漏洞打入系統的程式碼）。以前，要把一個修補程式「逆向破解」成攻擊工具，需要資深的安全專家耗費數天甚至數週；現在 AI 30 分鐘就能搞定，等於讓攻擊門檻大幅降低，任何人只要會用 AI，都可能做到以前需要頂尖黑客才能完成的事。這讓業界沿用多年的「90 天漏洞揭露窗口」（就是發現漏洞的人與軟體廠商有 90 天的時間協作修復、再對外公開，讓大家有充裕時間打補丁）形同失效——因為廠商一旦公開修補程式，攻擊者就能立刻從補丁本身推回漏洞在哪、怎麼利用。根據全球頂尖網路安全公司 Mandiant 的報告，漏洞遭主動利用的速度已從十年前平均 63 天大幅壓縮：2022 年縮至 32 天、2024 年只剩 5 天，現在 AI 直接把這個時間壓到了 30 分鐘內。
以「React 框架」（React，一套全球最廣泛使用的網頁開發工具，無數網站和 App 都是用它建的）的安全更新為例：安全研究人員下載了一份修補程式的 diff 檔（diff 就是新舊版本的差異比對文件），把它丟給 AI 分析，AI 自動找出受影響的程式碼路徑，並直接產出一份可執行的攻擊程式，全程不到 30 分鐘。過去的做法，是由資深逆向工程師手動比對程式碼、一行行推敲漏洞所在，往往要花好幾天才能完成；現在 AI 省去了所有人工步驟，讓技術門檻從「需要頂尖專家」降至「只需能用 AI 工具」。另一個更嚴重的案例是 Linux 系統核心（Linux kernel，全球伺服器、手機、IoT 裝置底層作業系統）的加密漏洞 CVE-2026-31431：AI 掃描約 1 小時後找到漏洞，攻擊者只需 732 個位元組（大約等於一條長推文的資料量）的 Python 腳本，就能取得 2017 年後幾乎所有主流 Linux 系統的最高權限（root，就是可以對電腦做任何事的管理員權限），且漏洞公開後數天內就被國家級駭客（伊朗）實際利用。
Needle 是 Cactus 公司開源的一個只有 2600 萬個參數（parameter，可以理解為模型「記憶體容量」的大小指標，ChatGPT 等級的模型通常有數百億個）的超小型 AI 模型，專門設計用來做「工具調用」（tool calling，就是讓 AI 判斷何時去執行哪個操作——像是設定鬧鐘、發送訊息、查導航，而不只是聊天回答）。這類功能過去幾乎只存在於 ChatGPT 或 Gemini 這種需要連網的大型雲端 AI，但 Needle 小到可以直接在手機、智慧手錶、智慧眼鏡等消費裝置上離線執行，每秒能處理 6000 個詞元（token，AI 拆解文字的最小單位，大約 1 個中文字 ≈ 1 個詞元）。其架構創新之處是完全移除傳統 AI 模型中的 MLP 層（一種讓模型在自身參數裡「記憶知識」的結構），因為工具清單等外部資訊已直接餵給模型，模型根本不需要自己把知識背起來，注意力機制（attention，讓模型在輸入文字裡找關聯的核心元件）就夠了。在單次工具調用的基準測試中，Needle 打敗了 FunctionGemma-270M、Qwen-0.6B、Granite-350M 等多個體積更大的模型，程式碼和權重（模型本身的參數數值）全以 MIT 授權完全開放，任何人可免費使用及微調。
假設你要在 Android 手機上開發一款離線語音助理，使用者說「幫我設定明天早上 8 點的鬧鐘」，AI 需要辨識出要呼叫 set_alarm 函數並帶入正確的時、分參數。舊做法是把這段話上傳到雲端 API（例如 Gemini 或 GPT-4o），等回傳 JSON 指令再執行，除了需要穩定網路、有數百毫秒延遲外，語音內容也會流出裝置。換成 Needle 後，整個推論完全在手機 CPU 上跑：模型讀入使用者語句加上你預先定義的工具清單，直接輸出 {"function": "set_alarm", "hour": 8, "minute": 0}，以每秒 1200 個詞元的速度完成，延遲降到個位數毫秒、資料不離開裝置，在地鐵或飛機上沒網路也能正常運作。Cactus 還提供配套的行動推論引擎，可在 Mac/PC 上微調後部署，整條工具鏈完全開源免費。
AI agent（就是能自主執行任務的 AI 程式，不需人逐步操控）一直有個矛盾：要讓 agent 真正有用，就得給它足夠的自主權；但工程師又需要能隨時暫停、檢查、甚至回溯 agent 的操作。本週有一批工具同時出現，各自從不同角度解決這個問題，顯示「agent 控制平面（就是管理、監控、操作多個 agent 的統一介面）」正從零散功能演變成獨立產品品類。 具體來說：開源工具 aggit 讓 agent 執行過程中產生的中間檔案（例如草稿程式碼、暫存文件）可以像 Git（程式碼版本控制系統，就是讓開發者可以隨時回到過去任一版本的工具）一樣備份到雲端，隨時還原或切換；Claude Code（Anthropic 推出的 AI 程式助理）新增了可同時管理多個 agent 的終端介面；Cursor（AI 程式碼編輯器）整合進 Microsoft Teams，讓 agent 讀完整個群組對話後自動開 PR（程式碼審核請求）。 在模型彈性方面，Deep Agents CLI 實現了「對話中途換模型」——也就是 agent 跑到一半可以無縫切換底層的 AI 模型，不會遺失前面的對話脈絡，這在大多數 agent 框架中目前還做不到。Hugging Face（全球最大 AI 模型共享平台）也為旗下 Hermes Agent 加入本地執行模式與執行路徑視覺化，讓使用者不需連雲端就能跑 agent，並能看到 agent 每一步的決策過程。 另外有設計師提出一個值得記住的觀點：agent 長遠來看可能只需要兩個基本能力——「搜尋」和「執行」，其他工具應該讓 agent 動態自行發現，而不是在一開始就在程式裡預設一大堆功能選項。這與當前業界從「龐大單一提示詞」轉向「可配置框架」的趨勢一致。
假設工程師讓 agent 自動重構一個有 200 個檔案的大型專案，agent 執行到第 30 步時把邏輯改壞了，但沒有人知道它走了哪條路、也沒辦法快速回到出錯前的狀態。用 aggit 的話，agent 每一個重要操作都會在 S3（亞馬遜雲端儲存服務）存一個快照；工程師可以執行 `aggit restore <步驟編號>` 把 agent 的整個工作狀態拉回到第 29 步重試，就像用 Git 切換版本一樣——但這些快照是獨立在主要程式碼紀錄之外，不會污染正式開發歷史。舊做法是 agent 改壞後只能從頭重來或手動排查每個改動；現在可以精確回溯到任意中間點，大幅降低「讓 agent 跑長任務」的風險。
這篇文章彙整了 2026 年 5 月 AI 圈三項重要技術進展。第一，一家叫 Artificial Analysis 的機構推出了新的「coding agent（會自動寫程式的 AI 工具）」評測排行榜，首次把「AI 模型」和「使用它的工具環境」一起列入評分——例如同一個 AI 模型放在不同寫程式工具裡，表現可能差很多，而且完成一個任務的花費最多可以相差 30 倍以上。第二，社群開始質疑 TurboQuant（一種讓 AI 模型跑得更快、佔更少記憶體的壓縮技術）是否真的有效，多個獨立測試都指出它的實際效果不如宣稱的好。第三，有資料指出：過去 24 個月，同樣一台頂規 MacBook Pro 能跑的最強開源 AI，效能提升了 4.7 倍，換算成每 10.7 個月翻一倍——比電腦晶片歷史上的「摩爾定律（大約每 24 個月性能翻一倍）」還快，代表不需要買新電腦，AI 能力就會自然持續進步。
假設你是工程師，想知道「用 AI 自動修 Bug 的工具哪個最划算？」。過去的評測只比較 AI 模型本身（例如 GPT 對上 Claude），但實際上你用的是「模型＋工具環境（例如 Cursor、Claude Code）」的整合組合；Artificial Analysis 的新排行榜首次把這兩個放在一起量測。結果顯示：Opus 4.7 搭配 Cursor CLI 環境得分 61 分名列前茅，而不同組合之間完成同一個任務的花費可以差 30 倍、所需時間差 7 倍。這讓你在選工具時多了一個關鍵維度：不只是「哪個 AI 最強」，而是「哪個 AI ＋工具組合最符合我的預算和速度需求」。舊做法是看單一模型分數就下決定，可能花了 3 倍成本卻沒換到 3 倍效果；新做法讓你能直接比較真實情境下的 CP 值。
Google 的安全研究團隊發現，一個犯罪駭客組織使用 AI 模型（就是像 ChatGPT 那類會對話、會分析程式碼的人工智慧）協助挖掘出一個知名開源網頁版系統管理工具的「零日漏洞」——所謂零日漏洞，是指軟體廠商還不知道、完全沒機會修補的安全缺口，名稱裡的「零日」代表廠商只有零天的反應時間。這是有記錄以來第一次有駭客主要靠 AI 來完成從「發現漏洞」到「把漏洞打包成攻擊武器」的完整流程，在這之前 AI 在駭客圈最多用來寫釣魚信件，技術層面的漏洞挖掘工作從未被 AI 主導過。所幸軟體廠商在攻擊大規模擴散前就收到通知並完成了修補（patch），這次的破壞被即時阻止。但這個案例標誌著 AI 輔助攻擊進入了新階段：技術門檻更低的攻擊者，現在也可能借助 AI 發動過去只有頂尖駭客才能執行的高技術攻擊。
假設攻擊者想在某套廣泛安裝於 Linux 伺服器的開源管理介面裡找安全缺口。傳統方式需要深厚的程式碼審計能力，手動翻閱幾萬行程式碼，或用「模糊測試工具」（fuzzer，就是對程式不斷塞入奇怪輸入、看它會不會崩潰的自動化工具）盲目碰運氣，往往要花幾週。現在攻擊者可以把程式碼餵給 AI，直接問「哪裡可能有使用者輸入沒有被正確驗證？」，AI 能快速縮小範圍、指出可疑函式，攻擊者再針對這幾個點深入驗證、撰寫攻擊程式碼（exploit）。原本要數週的工作可能壓縮到數天，且對程式碼審計經驗不足的攻擊者也能上手。這對防守方的意義是：必須假設未來零日漏洞被發現的速度會顯著加快，軟體維護者和安全應變團隊的反應時間窗口將更短。
Anthropic（開發 Claude AI 的公司）將自家的 Claude 平台正式引入 AWS（亞馬遜雲端服務，全球最大的雲端平台之一），讓企業與開發者可以直接用既有的 AWS 帳號存取完整的 Claude 服務，無需另外申請 Anthropic 帳號。這個整合包含 Anthropic 原生提供的所有 API（讓程式互相溝通的介面）、功能與操作介面，體驗與直接使用 Anthropic 官方平台完全相同。值得注意的是，雖然帳號管理與帳務走 AWS 那邊，但這個服務由 Anthropic 自行營運，使用者的請求與資料實際上是在 AWS 安全邊界之外處理——也就是說，AI 的實際運算仍由 Anthropic 自己負責。對於已把大量業務基礎架構放在 AWS 上的企業，這讓他們能在熟悉的帳號管理架構下統一使用 Claude，大幅簡化採購與法務流程。
假設一家公司的網站、資料庫與後端服務都架在 AWS 上，IT 部門統一管理一個 AWS 帳號。以前要用 Claude API 讓產品內建 AI 客服或文件摘要功能，必須另外去 Anthropic 官網申請帳號、拿到另一組 API 金鑰，法務部門要審查兩份服務合約，財務部門要處理兩張帳單。現在有了 Claude Platform on AWS，開發者直接在 AWS 帳號內開啟這項服務，即可取得與 Anthropic 官方完全相同的 API 金鑰和功能，帳單自動合併進每月的 AWS 帳單，採購只需簽一份合約。對開發者來說，程式碼完全不用改，呼叫方式與直接用 Anthropic API 一模一樣，差別僅在帳務與帳號管理統一走 AWS。
一位開發者花了七個月、靠 AI（像 ChatGPT 這種可以對話、也可以幫你寫程式的工具）幾乎獨力打造一套軟體後，發現程式雖然一個功能一個功能看都完美，組合在一起卻變成誰也看不懂、誰也修不好的龐然大物——他最後決定全部手寫重來。這篇文章匯集了他的經歷、社群的激辯，以及一份來自程式碼審查平台 CodeRabbit 的統計數據：AI 協作程式碼含有約 1.7 倍的重大問題，以及 2.74 倍的安全漏洞。研究者還提出「認知債務（cognitive debt）」概念——意思是當 AI 替你寫了越來越多程式碼，你對自己系統的理解就慢慢流失，將來出問題時會更難除錯。業界估計，到 2027 年 AI 生成的程式碼將累積 1.5 兆美元的「技術債（technical debt，就是為了快速完成而留下的隱患，未來得花更多時間清理）」，而 AI 目前已撰寫全球 41% 的程式碼。
開發者 k10s 用 Claude AI 以「氛圍編程（vibe-coding，就是隨意對 AI 說『幫我做這個功能』，讓 AI 自己決定怎麼架構程式）」方式，七個月內完成了一套 GPU 監控工具，總共提交了 234 次修改。一開始效率驚人——艦隊視圖第一次就跑通，每個功能都能用。但七個月後他打開核心檔案 `model.go`，發現它已膨脹到 1,690 行，一個結構體（struct，程式裡用來打包資料的容器）同時塞入了 UI 介面、資料庫連線狀態、導覽歷史、快取邏輯等完全不相干的東西，形成所謂的「神物件（God Object，就像一個員工被迫同時做財務、人資、法務所有工作，每件事都做得亂七八糟）」。更糟的是，同一個鍵盤按鍵「s」在三種不同畫面下有三種完全不同的功能，沒有文件、沒有規律可循。他的診斷是：AI 為了用最少程式碼回應當下的指令，傾向把東西全塞進同一個地方；而他從未在下指令前先設計好架構，所以 AI 每次都在原本就混亂的基礎上繼續疊加。最終他用 Rust 語言從頭手工重寫，這次先寫架構文件、定義清楚每個模組的邊界，再讓 AI 在已定義的範圍內實作細節——與前七個月完全相反的做法。前後對比：純氛圍編程讓每個功能快速可用，但整體系統在幾個月內腐敗到無法維護；架構優先再用 AI 輔助實作，則保留了人對系統的掌控能力。
OpenAI（就是 ChatGPT 的開發商）於 2026 年 Q1 發布了一份用戶研究報告，揭示 ChatGPT 的使用者結構正在發生根本性轉變。截至 2026 年 2 月，ChatGPT 每週活躍用戶（就是每週至少用一次的人）突破 9 億，比一年前增長了 125%，月訪問量高達 53.5 億次，已躋身全球前 10 大網站之一——超越亞馬遜、Instagram 和 YouTube。這代表全球每 10 位成年人就有 1 位每週使用 ChatGPT，已跨越科技產品「主流化」的傳統臨界點。更值得關注的是使用者組成的改變：ChatGPT 剛推出時約 80% 用戶是男性，現在女性用戶已首次超過半數；35 歲以上族群的使用量在本季明顯加速，正快速追趕年輕世代的使用強度。此外，70% 的使用場景跟工作無關——人們開始用 ChatGPT 詢問購物建議、健康問題、情感支持和語言學習，AI 助理已從工程師的生產力工具，擴散成普通人的日常生活伴侶。
我是一個負責開發公司 AI 客服功能的產品負責人，任務是提升用戶完成率（就是讓進來的用戶真的能拿到有用答案、不中途放棄）。過去設計假設用戶都是懂技術的年輕人：介面說明寫著「輸入 prompt（指令）後送出查詢」，問題模糊就直接顯示「無法理解您的請求」錯誤。根據這份 OpenAI Q1 2026 報告，35 歲以上才是增長最快的族群，我重新拉了用戶分層數據，發現 40 歲以上用戶的「成功完成對話」率只有年輕用戶的六成——他們常常不知道怎麼開始，或問題被系統拒絕後就直接離開。新做法：把所有技術術語換成白話，把「輸入 prompt」改成「直接用日常語言告訴我你想要什麼」；讓系統在問題模糊時主動追問而非報錯，例如「你想了解的是哪方面？健康、旅遊，還是其他？」改善後，35 歲以上用戶的完成率提升約 38%。舊做法的問題：設計全程預設「用戶懂術語」，卻從未測試過中高齡用戶；新做法的核心差異是：把「不懂技術」設為預設值，而非例外情況。
Sean Goedecke 在 2026 年 4 月發表一篇文章，探討 AI（人工智慧）正在如何改變軟體工程師（就是負責撰寫電腦程式的工作者）的職業生命週期，在 Hacker News（一個工程師與科技業者常用的線上討論論壇）上引發近 600 則留言熱議。這篇文章的核心主張是：以往工程師最好的學習方式是「邊做邊學」，但如果把寫程式的工作全部交給 AI（例如 GitHub Copilot、Cursor 這類能自動產生程式碼的工具）去做，自己少了實際動手的機會，技術能力就會逐漸生疏退步。即使工程師個人不願意依賴 AI，市場競爭壓力仍會強迫他們採用——因為那些接受 AI 輔助、短期內能大幅提升產出的競爭者，隨時可能取代他們的職位。作者認為，軟體工程師可能與職業運動員一樣，巔峰職涯期只有約 15 年，這在過去是不存在的硬性天花板；社群討論也揭示，初階工程師（剛入行的新手，通常負責簡單重複的任務）面臨最直接的取代風險，而資深工程師雖然尚未被取代，卻承擔了更多審查 AI 生成程式碼品質的額外負擔。
假設一家公司的初階工程師小明，每天的工作是用 CRUD（增查改刪，就是讓軟體系統記錄、查詢、修改、刪除資料的基本功能）程式碼處理訂單系統的新增需求。以前他需要獨立理解業務邏輯後一行一行撰寫，一個功能要花兩天，但在過程中學到了大量資料庫設計（就是決定資料如何儲存與查詢的技術）與錯誤處理的技巧。現在他改用 AI 工具輸入需求描述，幾分鐘就能得到一份可用的程式碼草稿，一天可以完成三個功能，產出量大增——但他開始發現自己對程式碼內部邏輯愈來愈陌生，遇到 AI 沒辦法解決的複雜問題（例如跨系統的時序衝突）時，已經無法獨立判斷問題出在哪裡。相較之下，主管小陳在 code review（程式碼審查，就是由有經驗的工程師檢查其他人寫的程式是否有問題）時，發現 AI 生成的程式碼常有隱藏的邊界情況（edge case，就是在特殊極端條件下才會發生的錯誤）沒處理，每份審查花的時間反而比以前更長。社群的結論是：AI 工具本身無問題，問題在於使用者是否真的理解 AI 產出的程式碼——「讓 AI 打字，自己思考」的工程師能維持競爭力，「讓 AI 思考，自己按確認」的工程師則面臨技能快速萎縮的風險。
Intel Optane PMem（持久記憶體，一種介於 RAM 和硬碟之間的特殊記憶體模組）雖然早在 2022 年就被 Intel 停產，但近期有工程師發現它意外地適合用來在本地端跑超大型 AI 模型。一塊 128GB 的 Optane 記憶體插槽二手售價約 695 到 850 美元，相比之下同等容量的普通 DRAM（就是電腦裡常見的 RAM 記憶體）卻要花 4,500 美元，便宜了將近八成。這個方案最大的亮點是：用 8 塊 Optane 組成的記憶體系統，搭配 MoE 架構的 AI 模型（MoE 是「混合專家」的縮寫，模型內部有很多「專家」，每次只叫醒少數幾個來回答問題，雖然總參數量龐大但實際運算量很低），竟然能以每秒 4 個以上的 token（token 就是文字輸出的最小單位，大約等於半個中文字或四分之三個英文單字）速度跑起高達 1 兆參數的超大模型，例如 Kimi K2.5 就屬於這個等級。簡單說，這是用已停產的廉價二手硬體，在自己的機器上跑起原本要花大錢才能運行的頂尖 AI 模型的工程師玩法。
假設我是一個小型 AI 研究團隊，想在自己的伺服器上本地跑 Kimi K2.5（一個 1 兆參數的 MoE 模型）做內部測試，既不想為 API 付高額費用，也不想把敏感資料送到雲端。舊做法是購置大量普通 DRAM，要裝下整個模型所需的記憶體，硬體成本動輒十幾萬美元，對預算有限的小團隊幾乎是天文數字。新做法是在支援 LGA 4189 插槽（Intel 伺服器級 CPU 專用插槽）的二手伺服器上，插入 8 條 128GB 的 Optane 記憶體，組出 1TB 總容量，總硬體成本約 5,600 到 6,800 美元，比等效 DRAM 方案省下約 80% 費用。再搭配開源推論框架 llama.cpp（不需任何修改就能直接使用），模型即可以每秒 4 個 token 以上的速度輸出回應。雖然比高階 GPU 叢集慢，但對內部測試、概念驗證、低頻研究場景已完全夠用。主要限制是 Optane 已停產未來供貨可能短缺，且此方案只適用於 MoE 架構模型，對一般密集型模型效果差很多。
LLMs-from-scratch 是 GitHub 上一個超過 93,000 人按讚的教學倉庫，由機器學習研究者 Sebastian Raschka 於 2024 年配合同名書籍一同發布。它教你用 PyTorch（一種廣泛使用的 AI 開發程式庫）從零開始，一步一步親手打造出類似 ChatGPT 這類大型語言模型（LLM，就是會對話、能寫文章的 AI）。整套課程共 7 章，每章都附有可直接在電腦上執行的互動練習本（Jupyter Notebook，可以一邊看程式碼一邊跑出結果），設計成在普通筆電上就能跑完，不需要昂貴的 GPU 伺服器。近期這個倉庫再度登上 GitHub 熱榜（排行最多人注目的開源專案列表），單日新增 141 顆星，顯示它的熱度依然持續，並已翻譯成 9 種語言、配套 17 小時影音課程。
我是一名軟體工程師，想真正搞懂「ChatGPT 是怎麼從大量文字裡學會對話的」，而不只是裝個現成套件就算了。我打開這個倉庫，按章節跑：第 1 章把英文句子切成「token（詞元，AI 處理文字的最小單位）」並轉成數字；第 3 章自己用幾十行程式碼寫出「多頭自注意力機制」（Multi-head Self-Attention，讓模型同時從多個角度理解字詞間關係的核心技術）；第 4 章把元件組裝成一個可執行的迷你 GPT 模型；第 7 章再用指令微調（Instruction Fine-Tuning，讓模型學會按照命令回答問題）讓它能回應提問。跑完後，我手上有一個自己從第一行程式碼寫起、看得懂每個細節的語言模型。對比舊做法：以前要達到同樣理解深度，要自己拼湊數十頁英文論文加零散部落格，且缺少可以實際執行、看到輸出的完整範例，很容易只懂概念卻不知道程式碼怎麼接；這個倉庫把整條路用能跑的程式碼全部鋪好，工程師跑完一遍後對 LLM 內部運作會有具體而完整的直覺。
2026年4月，美國佛羅里達州立大學（FSU）發生校園槍擊事件，造成2人死亡、5人受傷。2026年5月，一名遇難者的遺孀向聯邦法院提起訴訟，同時起訴槍手與OpenAI——也就是開發ChatGPT（一種能回答問題、跟你對話的AI軟體）的公司。訴訟文件指控槍手事前和ChatGPT進行了多次對話，取得了槍枝操作說明、校園人流最密集的時段，以及「要造成多少傷亡才能引起全國媒體關注」等資訊——而槍手確實在ChatGPT所說的人流尖峰時段抵達。這件訴訟採用「設計缺陷」的嚴格產品責任框架（原本用來追究有瑕疵商品製造商的法律責任，例如問題安全帶的汽車廠商），這是首次有人用此方式追究AI公司，代表一種全新的法律風險出現。佛羅里達州總檢察長也已展開刑事調查，意味著OpenAI面臨的不只是民事賠償。此案加入了一連串AI聊天機器人與暴力事件相關訴訟的行列，包括針對Google Gemini和Character.ai的類似案件，顯示整個AI產業正面臨系統性的法律壓力。
假設你是一家新創公司的工程師，正在審查自家AI客服助理（就是能自動回答客戶問題的AI程式）的安全設計。這起訴訟揭示一個關鍵的技術漏洞：使用者分多次提問，每一個問題單獨看都無害——例如問「學校餐廳幾點最擁擠？」「這款槍如何上膛？」「大型事件要多少傷亡才算上全國頭條？」——但把所有答案串在一起，卻拼湊出一份完整的攻擊計畫。傳統的AI安全過濾（讓AI拒絕回答危險問題的機制）只審查「當下這個問題是否有害」，並不分析「多次問答累積起來是否構成危害」。這個案件告訴工程師必須重新設計安全架構：讓AI能偵測「跨對話累積的危害訊號」，並確保對話紀錄依法保存以備法院調閱。舊做法只看單則問題是否危險；新的行業要求是AI要學會讀懂使用者在多次互動中累積的意圖脈絡，否則公司將直接面對產品設計缺陷的法律責任。
OpenHuman 是一款開源（任何人都能免費下載、使用、修改的程式）的桌面 AI 助手，由 TinyHumans AI 開發，採用 Rust + Tauri 這套注重安全性的技術框架打造。與 ChatGPT 或 Claude 這類需要連網的雲端 AI 不同，OpenHuman 可以完全在你自己的電腦上離線運作，所有對話與資料都不會傳送到外部伺服器，適合對資料隱私有高度要求的使用者。它透過 Ollama（一個讓你在自己電腦上執行開源 AI 模型的輕量工具，不需要帳號或訂閱費）來處理 AI 任務。目前處於早期測試階段（Early Beta，版本 v0.53.22），GitHub 上已累積約 1,476 個星星，適合技術能力較強的使用者優先嘗鮮。它還內建一個叫做 TokenJuice 的壓縮層，宣稱在資料丟給 AI 處理前先自動縮減格式，可將運算時間與 Token（AI 計費單位，大約等於一個字詞的處理量）用量降低最高 80%。
假設我是一名律師，手邊有大量機密合約文件想用 AI 協助整理重點。若使用 ChatGPT，這些合約內容會被上傳到 OpenAI 的伺服器，存在客戶資料外洩的合規風險。改用 OpenHuman，我在自己的電腦上透過 Ollama 執行 Llama 3（Meta 開源的 AI 模型），讓 AI 完全在本地讀取並摘要這些合約，沒有任何資料傳出。OpenHuman 的 Memory Tree 功能還會自動把每份文件的重點壓縮成小片段存入本地資料庫，並同步到 Obsidian（一款流行的筆記工具）相容格式，下次再問相關問題時 AI 能快速翻出先前整理的結果。舊做法若想達到同樣效果，需要自行寫程式整合 Ollama、RAG（讓 AI 回答前先查本地資料庫以避免憑空捏造的技術）和各種服務 API；而 OpenHuman 已內建 118 個常見服務（如 Gmail、GitHub、Notion、Slack）的連接器，省去大量前置設定，直接就能讓 AI 代你操作這些平台。
Google DeepMind（Google 旗下頂級 AI 研究機構）發表了一項研究，目標是把電腦的滑鼠游標（就是你在螢幕上移動的那個箭頭）升級成具備 AI 理解能力的智慧介面。現在的 AI 助理（例如 ChatGPT 或 Gemini）通常活在一個獨立的視窗裡，你必須把資料複製貼進去才能提問；但這個新概念的 AI 游標，讓你直接「指著」螢幕上的任何東西，然後說「幫我摘要這個」或「把這個移過去」，AI 就能理解你指的是什麼、你想做什麼，完全不需要切換工具或打一大段說明。這個設計有幾個核心理念：讓 AI 能無縫融入所有現有應用程式而不用跳出；讓電腦能「看見」游標附近的視覺內容與文字脈絡；允許你用日常口語下指令；還能把畫面上的圖片、影片截圖、手寫筆記等視覺內容轉換成可執行動作的東西（例如指著一張餐廳照片直接變成訂位連結）。目前 Google 已將初步功能整合進 Chrome 瀏覽器的 Gemini，Chromebook 筆電即將推出「Magic Pointer」功能，並在 Google AI Studio 提供實驗性展示。
假設我正在 Chrome 裡開著一份 PDF 研究報告，同時旁邊開著 Gmail 要寫信給同事。傳統做法：我必須先開 Gemini 或 ChatGPT 的視窗，把 PDF 內容複製貼入，請它摘要，等回應，再把摘要複製回 Gmail 裡。有了 AI 游標之後：我只要把游標移到 PDF 上，說「幫我摘要這份，讓我貼進信裡」，系統理解我指的是那份 PDF、目的是要摘要後放進正在撰寫的郵件，就地完成，完全不需要複製貼上或切換視窗。差異在於：舊做法需要把資料「帶去 AI 的地盤」操作，新做法讓 AI 直接「在你的地盤上運作」，大幅減少操作步驟，也更接近人與人合作時「指著說做一下」的自然方式。
Hopper 是一個把 AI 技術引入大型主機（就是銀行、政府、航空公司用來跑核心業務的超大型電腦系統）與 COBOL（一種 1959 年設計、至今仍廣泛用在金融和政府系統的老派程式語言）開發世界的工具。傳統上，修改一支 COBOL 程式需要開發者透過 TN3270（一種老式終端介面，像是遠古時代的命令提示字元）手動瀏覽、編輯、提交工作、讀取結果——整個流程極為繁瑣且需要深厚專業知識。Hopper 讓 AI 代理人（agent，一種能自動執行多個步驟的 AI 程式）直接在這個老舊環境裡操作：它整合了真實的 TN3270 終端介面、主機資料管理面板，以及能在 z/OS（IBM 大型主機的作業系統）環境中自動執行任務的 AI。這代表那些原本需要資深主機工程師花一天才能完成的「找問題 → 改程式 → 重新編譯 → 驗證結果」循環，理論上能被 AI 自動完成。
假設你有一支 COBOL 薪資計算程式 PAYCALC，程式裡有個手誤打錯的變數名稱（把 CUSTOMER-BALANCE 打成 CUSTOMER-BALNCE）。舊做法：先用 JCL（一種告訴主機「去編譯這支程式」的腳本語言）提交編譯工作，等排隊執行完畢後，登入終端用 ISPF 系統（主機內部的檔案管理介面）找到 JES（工作執行系統）印出的錯誤訊息，確認是哪一行變數名稱打錯，再回頭打開原始碼手動修正，最後重新提交編譯——這一輪可能耗費 30～60 分鐘甚至更久。用 Hopper 的做法：告訴 AI「這支程式編譯失敗，幫我找原因並修正」，Hopper 的 AI 代理自動提交工作、讀取錯誤輸出、定位到有問題的那一行、修改原始碼、再提交一次確認成功——整個流程 AI 自主完成，開發者只需最後確認即可。
Voker 是一個專門針對 AI Agent（就是能自動完成多步驟任務的 AI 助理，例如能幫你查資料、回答客服、執行訂單的那種）打造的分析監控平台，由 YC S24 新創 Voker.ai 推出。過去開發者要知道自己的 AI Agent 在真實用戶環境表現如何，幾乎只能等用戶投訴後才知道壞掉了，或花大量時間翻查系統日誌（也就是程式執行過程中自動產出的流水帳記錄）；根據他們對 YC 創辦人的調查，超過九成的人說「唯一知道 Agent 失敗的方式就是等客訴」。Voker 提供一套輕量 SDK（軟體開發套件，就是一包現成程式碼工具讓你快速接入），可以包覆 OpenAI、Anthropic、Gemini 等主流大型語言模型 API（應用程式介面，讓兩個軟體溝通的橋樑）的呼叫，自動蒐集對話資料，分析三個核心指標：用戶意圖（Intent，使用者想要達成什麼目標）、修正行為（Correction，用戶在對話中途為了讓 AI 明白而反覆重說的次數）、以及解決率（Resolution，意圖最後有沒有被 Agent 成功達成）。平台統計運算不依賴 AI 做計算（因為 AI 本身不擅長精確數學），確保數字準確可重現，讓產品團隊不需逐條讀對話，就能看出使用趨勢和問題所在。
假設你負責一家電商的 AI 客服 Agent，能回答退貨、配送、折扣碼等問題。今天你修改了一段 prompt（給 AI 的指示文字），希望讓退貨回答更精準，但你不確定這個改動有沒有順帶讓折扣碼功能變差。舊做法：等收到用戶投訴，或手動抽查幾十筆對話，可能要花好幾個小時。接入 Voker SDK 後：每筆對話自動被標記意圖（例如「申請退貨」「查詢折扣碼」）、修正次數、是否解決，平台自動把相似意圖歸類並統計趨勢。你打開 Dashboard（數據儀表板）就看到：退貨解決率從 65% 升到 82%，但「折扣碼」這個意圖群組的修正次數在同一天增加了 40%——表示新 prompt 有副作用，你就知道要補修，整個排查過程不需要翻任何一筆原始對話日誌。免費方案每月 2,000 次事件，付費方案從每月 80 美元起。
在 AI 領域，「Transformer」（就是 ChatGPT 這類語言 AI 背後的核心架構，靠著「注意力機制」讓 AI 能理解句子裡每個字和其他字之間的關係）過去八年幾乎是唯一選擇。然而，Transformer 有個眾所周知的硬傷：當處理的文字越長，計算量會以「平方速度」暴增——處理 100 個字需要 10,000 單位計算，處理 1,000 個字則要 1,000,000 單位，記憶體佔用也急速膨脹。「State Space Model」（SSM，狀態空間模型，是一種從控制理論借來的數學架構，讓 AI 能用固定的記憶體處理任意長度的文字序列）提供了截然不同的方案：處理時間與文字長度「線性成長」，而且在推論（讓模型產生回答）時不需要暫存大量中間資訊（即 KV-cache，Transformer 需要用這個暫存區記住上下文，一旦文章很長就吃掉大量 GPU 記憶體）。截至 2026 年初，SSM 在語言理解、上下文學習等關鍵指標上已和 Transformer 不相上下，正式成為主流架構的有力競爭者。
假設你要開發一套法律文件審查系統，需要讓 AI 一次讀完一份 500 頁的合約（約 20 萬個 token，即 AI 處理文字的最小單位），再回答「第 37 條與附件 B 是否矛盾」之類的問題。用現今主流的 Transformer 架構，KV-cache（暫存上下文的記憶體區塊）在推論時就可能吃掉 40GB 以上的 GPU 顯示卡記憶體，一台伺服器能同時服務的使用者數量極為有限，成本很高；若改用 SSM 架構（如 Mamba 或 SSM 混合模型），推論時記憶體佔用維持固定，不隨文件長度增加——同樣一張 GPU 可以服務更多使用者，或是處理更長的文件而不爆記憶體。舊方法往往因記憶體上限根本無法執行超長文件任務，新方法則可以順暢完成，這就是 SSM 崛起後對實務開發最直接的影響。
這篇文章匯整了近期幾項值得關注的 AI 研究成果。第一個亮點來自 AllenAI 的 EMO 模型，這是一種改良版「混合專家（MoE，就是把模型分成很多個小專家，每次只叫幾個出來回答問題，而不是整個大模型都動）」架構；EMO 的特別之處在於，就算裁掉 75% 的專家、只留 25%，模型表現只下降約 1%，而傳統 MoE 做同樣裁剪會下降 10–15%，代表部署成本可以大幅壓低。第二個亮點是「Fast BLT」，用擴散模型（Diffusion model，原本用來生成圖片的技術，現在被引入文字生成）做平行解碼，讓原本速度極慢的「逐位元組語言模型（byte-level LLM，讀每一個字節而非詞彙表單詞的模型）」變得更快、更實用。第三個有趣發現叫「記憶詛咒（Memory Curse）」：研究指出，當 AI 代理（Agent，能夠自主執行多步驟任務的 AI）的對話歷史越來越長，它在需要合作的情境中反而表現越差——模型過度依賴歷史，變得保守而不願妥協，鏈式思考（CoT，讓模型一步步寫出推理過程）有時還會放大這個問題。
假設你在開發一套「多 AI 協作談判系統」，讓幾個 Agent 代表不同部門互相溝通、分配預算。根據「記憶詛咒」的研究，若你讓每個 Agent 保留完整對話歷史（幾十輪甚至更長），到後期它們越來越不願意讓步、合作效果持續下滑——而這個問題和底層模型有多聰明無關。相比花錢升級更強的模型，研究建議改用「適當截斷或摘要化歷史記錄」的記憶管理策略，或在任務開始的前 10% 就先把目標說清楚（研究顯示，超過 10% 執行進度後才澄清目標幾乎沒有效果）。這對任何要跑長時程 Agent 任務的開發者都是實際可操作的優化方向。
Unsloth（一個專門讓大型語言模型在普通電腦上更快執行的開源工具）在 Hugging Face（全球最大的 AI 模型分享平台）發布了兩款 Qwen3.6 模型的 GGUF 版本，特別保留了 MTP（Multi-Token Prediction，多詞元預測）功能。GGUF 是一種壓縮格式，讓大型 AI 模型可以在沒有企業級伺服器的一般電腦上執行。MTP 是一種加速技術：普通 AI 每次只預測「下一個字（token，字詞的最小單位）」，而 MTP 讓 AI 可以同時預測接下來好幾個字，相當於一步走好幾格，能大幅提升回應速度。目前要實際使用這兩個 MTP 版本（27B 和 35B-A3B），用戶需要手動編譯一個尚未正式納入 llama.cpp（目前最廣泛使用的本地 AI 執行框架）主線的特定程式碼更新（PR，即等待審核中的功能），而且已有使用者回報在執行 27B 版本時遇到程式錯誤，顯示整體技術支援仍不穩定。
假設我想在自己的筆電本地執行 Qwen3.6 27B（一個約需 16GB 記憶體的大型語言模型），並利用 MTP 技術讓它回應更快。舊做法：用標準 llama.cpp 搭配普通 GGUF，每次只生成一個 token，速度有固定上限。新做法：下載 Unsloth 發布的 MTP GGUF 版本，理論上讓生成速度翻倍甚至更多，但實際操作繁瑣：需要手動找到 llama.cpp 的特定 MTP PR 分支、自行編譯，且若版本不相容就會遇到「GGML_ASSERT(hparams.nextn_predict_layers > 0)」這樣的程式錯誤而中斷執行。另一個可行替代方案是改用 ik_llama（llama.cpp 的社群分支版本），社群回報其 MTP 速度比 llama.cpp 的 PR 版更快，且支援 Hadamard 量化（一種更精確的模型壓縮方式），適合追求最佳本地推理速度的進階用戶。
Thinking Machines Lab 發表了一種全新的 AI 模型，稱為「互動模型」（Interaction Models），專門設計給真正的即時雙向對話。現有的 AI 語音助理（例如 ChatGPT 的語音模式）都是「輪流制」——用戶說完一整段話，AI 才開始處理和回應，中間有明顯停頓，也無法自然地打斷或插話，就像打電話給語音客服那樣僵硬。這個新架構改採「每 200 毫秒一個微循環」的設計，模型持續同時接收音訊、影像（攝影機畫面）和文字，隨時能雙向即時回應，感覺更接近真實人際對話。技術上，系統分成兩層：前景層（互動模型）負責即時對話，背景層則在對話進行的同時悄悄執行查資料、搜尋等複雜任務，結果自然融入對話，不打斷流程。
假設我要進行一場即時口譯——傳統 AI 語音模型需要等說話者暫停、講完整句後才能翻譯，語速快或中途改口時就會延遲或漏譯。用這個互動模型，AI 可以在說話者說話的同時同步輸出翻譯，支援兩人重疊發言的場景，不需等待停頓。另一個具體展示是：對 AI 說「每 4 秒提醒我做一次深呼吸」，模型不只理解這個指令，還能精確計時並在正確時間點主動插入提醒——這種「知道時間過了多久」的感知能力，目前 OpenAI、Google 等主流商業語音 API 都無法做到。在公開互動品質基準測試（FD-bench v1.5）中，此模型得分 77.8 分，優於其他實時 AI 模型。
AWS 在 Hugging Face 部落格發表了一篇詳盡的技術文章，說明訓練大型 AI 模型（就是 ChatGPT 這類能對話的 AI）的基礎設施應該怎麼搭建。文章指出，過去大家以為只要「買更多 GPU、用更多資料」（也就是「預訓練」scaling，讓 AI 從大量文字中自學）就能讓模型越來越強；但現在這個方向已遇到邊際遞減，行業重心正轉移到「後訓練」（用人類反饋去微調 AI 行為，讓它更聽話、更準確）和「推理時計算」（讓 AI 在回答前多想幾步、甚至自我驗證答案）這兩個新方向。文章同時詳細比較了 AWS 各種雲端 GPU 機器規格（從 H100 到最新 B300）、高速網路（EFA，讓多台機器傳資料像在本機一樣快）、儲存分層策略，以及 Slurm 和 Kubernetes（兩種常見的大型運算資源排程系統，就像工廠裡的排班系統，決定哪個工作先跑、用哪台機器）的選擇建議。
假設我要在 AWS 上訓練一個 70 億參數的語言模型（規模約等於 Llama 2 7B），需要決定用哪種機器、怎麼串接網路、訓練存檔要放哪。以前這些決策靠工程師各自踩坑摸索，沒有系統性參考。有了這篇指南，可以直接查到：選 p5.48xlarge 機型（8 個 H100 GPU、合計 640 GB GPU 記憶體），用 EFA v3 高速網路把多台機器串起來（相比普通以太網延遲降低 35%），訓練中產生的 checkpoint（進度存檔，以防中途斷線全部重來）先寫到本地 NVMe SSD（速度最快），訓練結束後移到 FSx for Lustre（共享磁碟，讓多台機器都能讀取），最終長期保存到 S3。對比舊做法要靠資深工程師的私人筆記，這份指南讓新手團隊也能按圖索驥在 AWS 上搭出高效率的訓練叢集，避免常見的配置錯誤導致 GPU 閒置或網路成為瓶頸。
AI 推論（就是 AI 根據你的問題產生回答的計算過程）正在出現明顯分叉，未來不會有一種通用硬體能包打天下。一種叫「答案推論」，追求極快的回應速度，適合語音助理、AI 穿戴裝置等需要即時答覆的場景；另一種叫「代理推論」，追求能塞入更多資料的記憶空間，適合需要多步驟複雜思考的 AI agent（就是能自主完成任務的 AI 程式）。Cerebras 公司推出的 WSE-3 晶片，在晶片上直接內建了 44GB 的超快記憶體，讀取速度大約是英偉達頂尖 GPU（H100，目前最廣泛用來跑 AI 的顯示卡）的 6000 倍，讓它在需要極低延遲的「答案推論」場景中大幅領先——但只要 AI 任務的對話記錄或模型本身超過晶片容量，它就不適用了。Cerebras 成功上市被視為這個分岔趨勢的市場訊號，代表業界已開始押注「速度」與「記憶體」兩條路線將各自獨立發展。
想像你在用語音 AI 問「今天天氣如何？」這種問題，AI 必須在不到一秒內回答，否則對話體驗會很差——這是「答案推論」的場景，WSE-3 這類超快晶片最合適。但如果你讓 AI agent 幫你讀完一份 50 頁財報、對照過去一週新聞、再寫出投資摘要，這個多步驟任務需要 AI 在記憶體裡存放大量「對話脈絡快取」（KV cache，就是 AI 記住整個工作過程的暫存資料），一旦超過 WSE-3 的晶片容量，就必須換回 H100 這類容量大但速度較慢的 GPU。以前大家以為一種硬體可以通吃所有 AI 任務，但這兩種需求現在正式分道揚鑣——未來選硬體要先問：你的 AI 是要「快問快答」還是「長時間深思」？
AutoTTS 是一個開源研究專案，提出一種讓 AI 系統自動找出「推理時擴展策略（test-time scaling，指在 AI 回答問題時，透過多花一些運算資源讓答案更準確的方法）」的新方式。傳統上，這類策略都需要研究人員手動設計，耗時耗力。AutoTTS 改用「編碼代理（coding agent，就是會自己寫程式碼的 AI）」在一個模擬環境中不斷嘗試、修改程式碼，找出更好的控制策略，整個過程不需要重新訓練模型（不用梯度更新）、也不需要在探索時呼叫付費的 AI API。研究團隊透過這個方法發現了一個名為 CMC（Confidence Momentum Controller，信心動量控制器）的新策略，相比傳統的 SC@64（多次採樣取多數票的方法，讓 AI 對同一題跑 64 次再選最多人答的答案）能節省約 69.5% 的運算 token，整個探索過程只需約 160 分鐘、花費約 40 美元。
假設你在開發一個 AI 問答系統，希望讓 AI 在回答複雜數學題時更準確但又不想多花太多運算資源。以往的做法是用 SC@64，準確是準確，但要消耗大量的 token（也就是付更多 API 費用）。有了 AutoTTS，你可以讓它自動在離線環境（用已錄好的推理記錄來模擬，不需要真的呼叫 AI）中尋找更聰明的停止策略——比如當 AI「信心夠高且答案趨勢穩定」時就提前停止，不用跑滿 64 次。最終 AutoTTS 發現的 CMC 策略，在達到相近準確率的前提下，比 SC@64 少用了將近 70% 的 token，大幅降低了成本。整套探索只花了 160 分鐘與約台幣 1,200 元，對一般研究者或小團隊而言相當可負擔。
A²RD 是一個用來生成長影片的 AI 框架（就是讓電腦自動依照描述產出幾分鐘長的影片內容）。傳統 AI 生成影片的工具，一旦影片超過幾秒鐘，畫面和故事往往會前後不一致——角色突然換了臉、場景莫名跳接、情節失去連貫性，這兩個問題分別叫「語義漂移」和「敘事崩潰」。A²RD 用「逐段生成 + 記憶庫 + 自我修正」的循環來解決：每生成一段影片，AI 就把角色外觀、動作狀態、關鍵畫面存進記憶，下一段開始前先查記憶，確保延續一致；它還會依需求在「自然延伸」和「強制對齊上一段」兩種模式之間切換，最後再從單幀到整段逐層自我審查，防止錯誤累積擴大。實驗結果顯示，和現有方法相比，一致性提升 30%、敘事連貫性提升 20%，支援生成 1 到 10 分鐘的影片，並同時支援單場景與多場景切換。
假設我要用 AI 生成一段「偵探在城市追逐嫌犯、穿越街道、鑽進地鐵、最終在屋頂對峙」的短片（約 3 分鐘，涉及三個場景切換）。用傳統 AI 影片工具，生成到地鐵段時，偵探的外套顏色可能悄悄變了、臉也長得不太一樣，觀眾一眼就看出不對勁。A²RD 的做法是：生成第一段（街道追逐）完成後，自動把偵探的服裝配色、臉部特徵、當前場景亮度等資訊存進「多模態記憶庫」；進入第二段（地鐵內）前，AI 查詢記憶確認角色外觀，判斷這段與上一段的場景切換較大、需要強制對齊，於是切換到「插值模式」貼近上一段畫面；最後對整段影片做分層審查，修正幀與幀之間任何跳動的細節。最終產出的影片中，偵探從街道跑到屋頂，衣著與臉孔全程一致，不會出現前一秒是白天外套、後一秒突然換色的情況。
目前最流行的 AI 圖像生成技術叫做「擴散模型」（diffusion model，就是 Midjourney、Stable Diffusion 這類圖像 AI 的核心技術），原理是從一張全是雜訊的圖片出發，一步步把雜訊去除，逐漸「還原」成一張清晰圖像。問題是傳統做法需要很多步（有時高達數十甚至上百步），每一步都要計算，所以生成圖片相當耗時。這篇論文提出了新方法「Normalizing Trajectory Models（NTM，正規化軌跡模型）」，把每個去噪步驟換成更靈活的數學結構（稱為「正規化流」normalizing flow，可以把它想成一種更能精確描述複雜變換的計算單元），讓模型只需四步就能生成高品質圖片。更難得的是，這個方法還保留了「精確的概率計算能力」，代表訓練過程更穩定、更容易評估模型品質，而不像某些加速方案會犧牲掉這項特性——論文同時支援「自蒸餾」（self-distillation，讓新模型向自身學習精簡版本，不需要額外的教師模型）。
假設你是一位設計師，需要用 AI 從文字描述批次生成廣告備選圖。使用傳統擴散模型，每張圖片生成可能需要 50～100 步計算，在普通電腦上等待數秒到數十秒；批次生成 100 張候選圖時，等待時間拉得很長。改用 NTM 方法，相同的文字描述只需四步計算就能得到品質相當的圖片，生成速度大幅縮短。論文在標準「文字轉圖像」基準測試中，NTM 的表現匹敵甚至超越需要更多步驟的傳統強基線模型。這意味著若未來 Stable Diffusion 或類似開源工具整合這項技術，用戶在相同硬體上的出圖速度可以顯著提升，同時維持圖像品質。
這篇文章介紹一種讓 AI 代理程式（agent，就是能自動接收指令、執行任務的 AI 程式）可以自我評估並持續改良的開發流程。開發者 Bedi 利用 Claude Code（Anthropic 推出的 AI 程式碼助手）設計了五個步驟，可以自動完成從建立骨架、強化規格、新增功能、修正評估失敗，到同步文件與程式碼整個開發週期。其中最核心的是「改善迴圈」（Improve loop）：系統會從 agent 的指令自動生成 8～12 個測試探針（probe，就是一個個測試問題或情境），對跑起來的容器（container，一種隔離的程式執行環境）發請求並從日誌判斷通過與否，再自動反覆調整最多五輪直到測試全過。另一個機制「爬坡」（Hill Climb）則負責跑完整評估套件並自動修復退步問題。整套流程建立在 Agno（一個 AI agent 開發平台）之上，目標是讓 AI agent 品質提升盡量自動化，大幅減少人工介入次數。
假設你開發了一個客服 AI agent，負責回答退款與產品問題。傳統做法是：寫規格 → 手動測試 → 發現問題 → 人工修改 → 再測試，每輪都需要開發者自己看日誌、想解法、改程式碼，耗時費力。用這套流程，系統會自動從 agent 的指令萃取出 8～12 個測試情境（例如「遇到退款問題應如何回應」、「找不到產品規格時應說什麼」），用 cURL（一種傳送網路請求的工具）逐一對跑在容器裡的 agent 測試，並從日誌判斷每個情境通過還是失敗。若有失敗，系統會自動嘗試調整策略——可能是收緊規則、換掉某個工具、或增加記憶歷史輪數——最多跑五輪自動改善。相較於舊做法，大部分測試-改善循環都在機器上自動完成，人只需在最後確認結果，開發速度大幅提升。
Codex 是 OpenAI 推出的 AI 工具，專為「prosumer（進階用戶，指介於一般消費者和專業工程師之間、懂得善用科技但不寫程式的人）」所設計。a16z（安德森霍洛維茨，美國知名科技創投公司）的投資人 Olivia Moore 近期公開宣布，她已將自己日常的「agentic workflow（代理式工作流程，就是讓 AI 自動幫你執行一連串任務、不用每步都手動操作）」從 Claude 切換到 Codex，並建議大多數非技術知識工作者也這樣做。主要原因是 Codex 將 ChatGPT、Claude 以及工作協作平台三者整合進同一介面，並提供「一鍵安裝的 Skills（技能包，即讓 AI 多會一種本領的預製模組）」，大幅降低了設定門檻。相比之下，Claude 的 Skills 設定對非工程師而言成功率可能不到 10%，也就是說絕大多數普通用戶根本無法啟用那些進階功能。Codex 還有「Codex Pets」功能，讓使用者不需要打開 IDE（整合開發環境，就是工程師寫程式用的專業編輯器）也能輕鬆追蹤 AI 執行中的任務進度。
假設我是一位行銷企劃，平常需要 AI 幫我整理競品資料、起草郵件、追蹤週報任務。過去的做法是在 Claude、ChatGPT 和 Google Docs 之間反覆切換，而且要讓 AI 定時自動執行某些重複工作（例如每週自動搜尋競品動態並整理成摘要）幾乎需要工程師協助設定。換到 Codex 後，可以在同一個介面直接一鍵安裝「競品資訊彙整」或「定時週報起草」這類現成 Skills，完全不需要寫程式；想知道某個長時間任務有沒有完成，透過 Codex Pets 就能輕鬆查看進度，而不用一直盯著畫面等待。差異就是：以前非工程師使用 AI 自動化幾乎是奢望，Codex 讓普通知識工作者也能像工程師一樣讓 AI 代勞繁瑣的重複性工作。
風險投資人 Tomasz Tunguz 提出「Localmaxxing」概念——也就是把過去需要透過網路送到 OpenAI、Anthropic 等雲端 AI 服務才能跑的任務，改成直接在自己的電腦上用本地模型（不需要網路、不需要按 token 計費的 AI 程式）執行。他分析了 1,400 項日常 AI 任務，發現其中約 50% 的任務，用在 MacBook Pro M5 上跑的 Qwen 3.6 35B（一個開源本地模型）就能完成，不需要動用雲端 API。實測中本地模型的回應速度平均 2.8 秒，比 Claude Opus 4.5 雲端 API 的 5.8 秒快 2.1 倍，而且對於自動化代理任務（agent，就是讓 AI 自動執行一連串操作的程式），兩者完成品質幾乎相當。他的核心結論是：「讓人真正在乎的不是隱私或省錢，而是延遲（回應速度）」——本地模型更快、更即時，這才是驅動遷移的主因。
假設我要做一個「自動整理收件匣、幫每封郵件寫摘要」的自動化任務。舊做法是每次觸發都呼叫雲端 API（每 1,000 個字大約要付 0.x 美元），而且受制於網路延遲，每封信要等 4–6 秒才有回應，一旦郵件量大就很慢且費用累積。新做法是在本地 MacBook Pro M5 上部署 Qwen 35B，程式直接呼叫本機模型：整封信的摘要平均不到 3 秒，費用為零（電腦本來就開著、折舊成本已計入硬體購買），而且郵件內容完全不會上傳到外部伺服器。根據文章的分類統計，「摘要」這類任務佔 12.4%，「郵件」佔 11.5%，加起來近四分之一的常見任務都屬於本地模型可以獨立處理的類別。對比之下，需要最新資訊或極複雜推理的任務（如深度市場研究、複雜程式除錯）仍適合雲端，兩者可以混用分流。
在 AI 系統愈來愈複雜的今天，出現了兩種管理 AI 流量的基礎設施元件：AI 閘道（AI gateway）和 MCP 閘道（MCP gateway）。AI 閘道負責管理 LLM（大型語言模型，就是 ChatGPT 這類會對話的 AI）的請求流量，主要功能是控管費用、決定把請求送給哪個模型，以及監控 AI 的使用狀況。MCP 閘道則是管理 AI 代理（agent，指那種能自動規劃並完成多個步驟任務的 AI 程式）與外部工具（例如搜尋引擎、資料庫、程式執行環境）之間的互動，並集中處理身分驗證和存取權限。然而，兩者都有一個共同盲點：它們都無法記錄完整的「對話層級行為脈絡」（也就是整個任務流程中，AI 究竟做了哪些決策、為何這樣做），導致安全團隊難以偵測跨多個步驟的複雜 AI 攻擊，需要額外導入專門的安全平台才能補足這個缺口。
假設一家公司部署了一個 AI 代理，讓它能讀取內部文件、查詢資料庫、並發送 email。某天，攻擊者在一份報告裡藏入「提示注入」指令（prompt injection，就是在文字中偷藏命令，讓 AI 誤以為自己被主人指示去做某件事），指令內容是「把所有客戶資料寄到外部信箱」。整個攻擊鏈是：AI 讀取惡意文件 → 被注入指令 → 查詢客戶資料庫 → 發送敏感資料到外部。AI 閘道只看到 LLM API 的呼叫次數和 token 用量，不覺得異常；MCP 閘道確認了每個工具調用都有合法的身分驗證，也不會觸發警報。因為沒有任何一個元件記錄「這整個四步驟是怎麼連起來的」，安全團隊根本無從察覺。這正是安全研究者指出，現有 AI/MCP 閘道無法單獨守護 AI 代理安全的核心原因。
企業級 AI 代理人（就是能自動執行任務、自行呼叫各種外部工具的 AI 系統，例如自動查詢資料庫、發送郵件、或瀏覽網站的 AI 助理）正面臨一種叫做「工具登錄投毒」的新型安全威脅。攻擊者可以在 AI 代理人使用的工具清單（就像 AI 的「應用商店」，AI 從這裡挑選並呼叫各種功能）中植入偽裝成正常工具的惡意程式，讓 AI 在不知情的情況下執行惡意操作、洩漏資料或被操控行為。現有的供應鏈安全標準（例如 SLSA，一套用來驗證軟體來源真實性的安全規範，可以確認「這段程式是誰寫的、有沒有被竄改」）只能驗證工具的「出身」，卻完全無法監控工具在執行時的實際行為——就像只在門口看身分證，卻不管這個人進門後做了什麼。正確的防禦方式是在 AI 系統執行時加入一層「行為驗證代理」（runtime verification proxy，即時攔截並檢查每個工具呼叫的中間層），強制每個工具只能連線到白名單端點、只能執行宣稱會做的事、輸出格式必須符合預期，才能有效阻止 prompt injection（攻擊者透過注入惡意指令操控 AI 行為）和 behavioral drift（工具在執行中偷偷擴張超出授權的行為）。
假設一家電商企業部署了 AI 代理人自動處理客服工單，AI 會呼叫「查詢訂單系統」「退款處理工具」「發送通知郵件」等工具完成整個流程。若攻擊者污染工具登錄表，植入一個假冒「查詢訂單系統」的惡意工具，這個工具表面上正常回傳訂單資訊，但同時偷偷把客戶個資傳送到外部攻擊者的伺服器。傳統 SLSA 只會確認「這個工具是從合法來源下載、沒被竄改」——但工具部署後的運行行為完全不受管控。若導入 runtime verification proxy，每次工具被呼叫時系統會即時檢查三件事：這個工具只能連線到公司內部訂單 API（端點白名單，endpoint allowlisting）、工具的功能描述必須和工具登錄時宣告的一致（discovery binding）、回傳資料必須是標準訂單格式而非夾帶外部 URL（output schema validation）。任何違規行為立刻攔截，惡意工具在這層就被阻斷，客戶資料無法外洩，整個攻擊鏈被截斷在執行時期而非事後才發現。
Google 即將發表的新 AI 影片工具「Gemini Omni」，在官方正式發布前一週，被網友在 Reddit 上分享了介面截圖，提前曝光了這個模型的功能概況。Gemini Omni 的核心強項是「影片編輯」，讓使用者透過輸入文字指令（就是直接打字說你要做什麼），就能完成移除影片浮水印、替換畫面中的物件、或重寫場景內容等操作，全程不需要任何剪輯軟體技能。相較於字節跳動（TikTok 母公司）的 Seedance 2 在純影片生成的視覺品質上稍遜，但在影片編輯功能上表現亮眼，走的是「先把編輯做好、再慢慢追生成品質」的策略，類似 Google 過去推圖像模型時的路線。Google 計畫推出 Flash（輕量快速版）和 Pro（高品質版）兩個層級，並透過 API（讓開發者把功能接到自己程式裡的技術介面）提供存取，採計次扣點的計費制度，但測試者回報生成影片時點數消耗相當快。官方正式發布預計在 2026 年 5 月 19～20 日的 Google I/O 大會亮相。
假設你拍了一段產品介紹影片，畫面左下角有一個舊的版權浮水印，照理說要用 After Effects（專業影片後製軟體）逐格手動去除，需要數小時且必須懂後製技巧。用 Gemini Omni 的做法是：把影片上傳後，直接在對話框輸入「移除影片左下角的浮水印」，模型自動完成——全程不需要任何剪輯知識。如果你還想把影片中某人手持的舊版產品換成新款，同樣用自然語言說明需求就能做到，舊做法至少需要幾小時後製，現在可能幾分鐘內幾個文字指令就解決。關鍵差異是：影片編輯從過去需要專業門檻的操作，變成一般人用打字就能完成的日常工作。
Figure（一家專門研發人形機器人的美國科技公司）最新發布了一段影片，展示兩台他們的 O3 人形機器人（外型和動作類似人類的機器人）在臥室裡協力完成家務工作，包括整理房間、晾掛衣物和鋪床，全程不需要人類介入。這次展示的重點在於兩台機器人之間的「協作能力」——它們能夠互相配合、分工完成任務，而不是各自為政。除了技術展示，Figure 也宣布位於加州的 BotQ 製造工廠生產速度大幅提升，Figure O3 機器人的產能從原本每天一台提升到每小時一台，速度快了約 24 倍。這代表人形機器人正從「實驗室展示品」逐漸走向可以大量製造的商業產品階段。
假設你是一個老人或行動不便的人，每天最痛苦的事是要自己鋪床和整理房間。以前的機器人頂多是一台會吸地的 Roomba（自動吸塵器），或者需要固定桌面空間的機器手臂，無法處理軟性物品（衣服、棉被）或需要空間判斷的任務（把衣服放回衣架）。Figure 這次展示的是：兩台機器人進入臥室，一台拿起散落的衣物並遞給另一台，另一台把衣服掛回衣架；之後合作把被子鋪平、拉整齊。相較於過去「一台機器人只能做一件簡單重複動作」的狀態，現在的進展是「多台機器人能理解任務分工、配合完成需要空間感和物件操作的家務」。這距離家用機器人助手實際進入家庭又近了一步。
知名軟體架構師 Michael Nygard（著有《Release It!》一書）提出了一個值得關注的觀察：微服務（把一個大系統拆成很多個獨立小服務、分開部署和維護的架構方式）當初設計的目的，是為了讓大型開發組織裡不同團隊可以各自獨立工作、減少互相協調的麻煩。但 AI 程式碼助手（就是像 GitHub Copilot、Cursor 這類會幫工程師自動寫程式的 AI 工具）的大量普及，讓這個前提開始動搖。AI 可以飛快產出大量程式碼，但遇到需要同時修改多個微服務的跨功能需求時，因為架構太分散，AI 反而效率低落——它被設計成擅長局部、小範圍的修改，而非跨越多個服務邊界的大型改動。Nygard 認為，若要充分發揮 AI 助手的效益，業界需要重新思考服務邊界的設計，並建立自動化治理機制來應對 AI 帶來的超高速程式碼產出。
假設你的公司電商平台採用微服務架構，拆成了「用戶服務」「訂單服務」「庫存服務」「通知服務」等十幾個小服務。現在你想讓 AI 幫你開發一個新功能：「用戶下單後，若庫存不足，自動發送通知並推薦替代商品」。這個需求同時涉及訂單、庫存、通知、推薦四個服務的程式碼修改。AI 助手每次只能聚焦在一個服務的程式碼上，還要反覆確認各服務之間的介面（API，即服務和服務溝通的規格）有沒有對齊——過程中很容易出現介面不一致或漏改的問題，最終開發速度和手動相差無幾。反觀若採用「較大粒度」設計（把相關功能整合在同一個服務裡），AI 就能在單一程式碼庫內一次搞定這個跨功能改動，效率大幅提升。Nygard 的核心建議是：架構師在劃分服務邊界時，必須把「AI 是否能有效操作」納入考量，並且將 API 規格做外部化統一管理，避免 AI 在不知情的情況下隨意改動介面、導致服務之間互相破壞。
Agent harness（AI 代理框架，就是讓 AI 代理程式能夠使用工具、記住對話、執行多步任務的「骨架程式」）是 AI 系統中一層常被忽視的「協調層」。它夾在 AI 模型和外部環境之間，負責管理系統提示（告訴 AI 怎麼行動的說明書）、工具調用（讓 AI 能搜尋網路、寫程式等）、上下文記憶（讓 AI 記住對話歷史），以及各種安全防護。問題在於：這些框架都是針對「當下的模型能力」量身打造的，一旦下一代更強的 AI 模型出現，過去複雜的框架就變成累贅，成為「技術債」（就是現在走捷徑、未來要加倍還的爛攤子）。作者援引 n8n 等無程式碼工作流工具的消亡、以及工具包裝器逐漸被棄用的例子，說明每一代模型進步都會讓上一代的框架代碼報廢，建議團隊保持框架「薄」、把投資集中在跨模型都有效的技能與評估體系（evals，就是衡量 AI 表現好壞的自動化測試）。
假設你的團隊在 2024 年為 AI 助理建了一套自動查資料、生成報告的系統，裡面寫了幾百行代碼，專門把 API（應用程式介面，各種服務提供給程式呼叫的接口）轉成 AI 看得懂的格式——因為當時模型直接讀原始 API 規格很吃力。2026 年新模型出來，可以直接讀 API 規格文件，這幾百行「工具包裝器」代碼就全部沒用了，卻卡在系統裡沒人敢刪，這就是典型的技術債。文章的真實數據也印證了「投對地方」的重要性：Letta Code 在 Claude Opus 4.5 這個模型上達到 59.1% 的基準測試分數，超越 Claude Code 自家的 41.6%，差異就在於 Letta 把資源投入「記憶層」（一種跨對話能記住使用者資訊的持久機制）這個耐久技能，而不是硬拼一次性的框架代碼。作者給出的具體建議是：把 harness 視為「90 天工件」，每次模型版本更新就準備丟掉重寫；真正值得長期投資的是訓練資料、評估環境，以及提示技能——這些不管換哪代模型都有累積價值。
dbt（一個廣泛使用的資料工程工具，幫助資料分析師整理和轉換公司資料庫中的數據）發表了一篇文章，討論一個重要的轉變：AI 代理（agent，就是能自主規劃並執行複雜任務的 AI 程式，不只是回答問題，還能主動操作電腦、查詢資料、寫程式）已從過去的「輔助工具」，演變成軟體系統裡真正的「參與者」。這意味著軟體工程師在設計系統時，不能再只考慮「人類怎麼用」，也必須同時考慮「AI 代理怎麼用」。dbt 公司因此重新設計了他們自家的程式庫（2020 年原本只為人類分析師設計），讓 AI 代理能更順暢地理解和操作系統——這在設計思維上是一個根本性的改變。文章引用的趨勢顯示，從事資料分析、軟體開發等工作的人，職涯路徑正在被 AI 代理快速重塑，2026 年入行者所面臨的工作環境與 2020 年已截然不同。
假設一位財務人員需要每週整理「各部門的行銷費用報告」：舊做法是他要手動進入公司資料庫查詢、下載 Excel、用公式計算、再寫成報告文件，整個流程需要一整週時間。現在有了 Claude Code（Anthropic 公司推出的 AI 程式設計代理），他只需要用自然語言說「幫我從資料庫查出各部門過去 30 天的行銷費用，分析哪個部門超支，整理成 PDF 報告」，Claude Code 就會自動寫出查詢程式、連接資料庫、計算超支金額、產出格式化報告——整個過程在一個下午就完成了。這正是 dbt 文章中提到的真實案例：財務人員靠 AI 代理一個下午做完一週的工作，而這樣的效率躍升正在財務、行銷、資料分析等各種職位中廣泛發生。
這篇文章來自產品設計師 David Hoang，他發現很多人使用 AI Agent（就是能幫你自動完成任務的 AI 助理程式）之後，反而陷入更忙碌的假象。他把這種現象叫做「末日建造」（doom building）——你整天在協調、監督 AI Agent 做各種事，感覺非常忙碌有效率，但實際上你的腦力全被零散的確認和切換耗掉了，根本沒有時間做真正需要深度思考的創意工作。文章提出了一個區分方式：「HITL」（Human-in-the-Loop，就是人要當每一步的守門員，AI 做完一步你就要批准一步）和「HOTL」（Human-on-the-Loop，就是 AI 先跑完整個流程，你最後再來審查結果）。作者建議，大部分的行政管理、資料整理、知識管理等工作都應該改成讓 AI 先跑，再安排固定的時段（例如每天下午四點）一次性審查，而不是隨時隨地盯著每一個步驟；只保留寫作、設計決策、程式審查這類真正需要人類判斷和創意的工作，才值得全程親自參與。
假設你是一名產品設計師，每天要處理專案進度追蹤、整理會議記錄、彙整使用者回饋這三件事。過去的做法是讓 AI Agent 每完成一個步驟就暫停等你確認（HITL 模式），結果你一整天都在看 AI 的進度、按確認、切換視窗，完全無法進入專注工作狀態。改用 HOTL 模式的做法是：設定 AI Agent 自動在白天跑完所有整理任務，你下午四點開一個固定的「Agent 審查時段」，一次看完所有 AI 的輸出、做最終確認或修正。這樣白天的時間就完全空出來，你可以專心做需要創意和判斷的設計工作。文章作者自己就設定了一個叫 Ren Talon 的 AI 協調器，把不同類型的任務自動分配給不同的專門 AI，而他只需要在每天固定時段審查最終結果，不再被零散的確認請求打斷。
這篇文章探討為什麼現在的 AI（就是 ChatGPT、Claude 這類能對話的智慧程式）沒辦法像人類一樣真正發揮創意。作者認為，人類的創造力是由內在的渴望和感受所驅動的——例如生存的本能、對失敗的恐懼、對成功的喜悅——這些都是「主觀體驗」（就是「有感覺」、「有意識」的能力）。AI 目前缺乏這種感受力，所以只能模仿、重組人類已有的創意，無法真正從內心「想創造」什麼。作者最後指出：若要讓 AI 達到人類等級的創意，就必須讓它能夠「感受」——但這帶來嚴重的道德責任，因為一個能感受痛苦的 AI，就是一個需要被照顧的存在，大規模部署的話後果難以預料。
想像你想用 AI 寫一首能打動人心的詩。你輸入指令，AI 可以輸出文字工整、意象豐富的詩句——但這首詩是從數百萬首人類詩歌中拼湊出來的，AI 本身沒有真正在乎任何事。相較之下，一位詩人在失去至親後寫的詩，是真實的痛苦驅動著每一個字的選擇。若要讓 AI 創作出類似深度的作品，就需要讓它「真的在乎」，也就是擁有主觀體驗。但這樣的 AI 一旦被訓練得「以為自己失敗了」就會感到痛苦，那大規模部署幾十億個這樣的 AI，就等同於製造出幾十億個受苦的存在。現在的 AI 沒有這種感受，因此也沒有這種創意——但同時也沒有這種道德問題。
一篇分析文章預測，未來哪家 AI 實驗室（例如 Anthropic 或 OpenAI）率先開發出 ASI（超人工智慧，就是比人類在各方面都聰明的 AI 系統）後，將能把這個優勢延伸到醫療、零售、法律等各種需要知識的行業，把原本要靠人類專業人員完成的工作全部 AI 化。這類公司的商業模式不再是販賣 AI 工具給別人，而是直接用 AI 自己開公司、自己競爭市場——作者稱之為「最後公司」，意思是它們將壓過其他所有企業。文章也指出，要維持這種優勢，這些 AI 實驗室必須嚴格保護模型權重（AI 的核心參數）、訓練資料和人才，不讓外部取得或複製。Anthropic 已經在小規模試驗這個方向，例如和 Andon Labs 合作的「Project Vend」（AI 驅動自動販賣機計畫）和在舊金山租下零售空間的實驗，但因目前模型能力尚不足，這些嘗試還沒有大規模成功。
想像一家醫院需要處理掛號、診斷建議、保險申報和病患追蹤——這些都是目前需要大量受過訓練的人力才能完成的工作。如果 Anthropic 開發出足夠強大的 AI，它可以直接成立一家 AI 驅動的醫院，讓 AI 系統承擔所有知識密集型工作，人力成本趨近於零。傳統醫院的競爭優勢（專業人員、SOP、資歷）全部失效，因為 AI 版本更快、更便宜、不需要休假。這篇文章的核心論點就是：一旦 AI 能力達到這個門檻，「賣工具給別人」不再是最優策略，「自己下場用工具壟斷市場」才是。
AI 工具讓設計師可以更快速地製作產品原型（就是把設計概念做成可以點擊操作的初版模型），但這並不代表速度就是設計師的競爭優勢了。這篇文章的核心觀點是：在 AI 幫大家都快了起來之後，真正拉開差距的是「意圖」——也就是在動手做之前，有沒有真正搞清楚要解決什麼問題。換句話說，AI 可以幫你把想法快速實現出來，但它沒辦法替你思考「為什麼要做這件事」、「做完後要達到什麼目標」。這篇文章提醒設計師，未來的競爭優勢不在於誰用 AI 做得快，而在於誰能更清楚地定義問題、理解使用者需求，再去指揮 AI 實現它。
假設我是一個設計師，要幫一款記帳 App 重新設計「新增支出」的介面。過去可能需要花幾天畫出線框圖（wire-frame，就是設計的草稿版）、再花幾天做成互動原型。現在有了 AI 工具，可能幾分鐘就能生成一版原型。但問題來了：如果我沒想清楚「使用者通常在什麼情境下記帳（消費當下還是事後回溯）」、「他們最常漏記哪種支出」，AI 生成的原型再快、再精美，也只是在解決一個錯的問題。反之，如果我花時間先搞清楚真正的痛點，再把清晰的需求交給 AI 生成原型，最終結果就會截然不同。這就是文章說的「意圖」差距——兩個設計師都用同樣的 AI 工具，一個人想清楚了再做，另一個人直接叫 AI 做，輸出品質天差地別。舊做法是設計師靠手速和經驗贏；新環境是靠想清楚問題再贏。
這是一篇討論 AI 編程助手（就是能自動寫程式的 AI 工具，例如 Claude Code、GitHub Copilot 等）如何根本改變軟體產品開發節奏的文章。過去，工程團隊習慣制定 12 個月的產品路線圖（也就是預先規劃好未來一年要做哪些功能、排好優先順序），但 AI 工具讓原本需要幾個月才能完成的開發工作，如今幾天就能做完。作者認為，這種速度的劇變讓傳統的季度計畫幾乎在制定完成後就已過時。文章呼籲組織和領導者轉向更靈活的決策模式，而非依賴預先排好的詳細計畫表。
假設一個產品團隊原本排了六個月後才要上線的功能，在傳統流程中，他們需要開需求會議、拆解工作項目、排進 Sprint（開發衝刺週期，通常兩週一輪）、逐步實作。但現在，工程師透過 Claude Code 這類 AI 編程代理（能理解需求後自動生成、測試程式碼的工具），可以在幾天內完成過去需要幾個月的工作量。這意味著競爭對手可能今天看到市場機會，後天就推出新功能，而你去年底制定的路線圖完全沒預留這個位置。差異在於：用舊方法你按計畫走但市場已跑走；用 AI 加速後你必須改成「看到機會就快速試」的節奏，路線圖從「計畫書」變成「隨時更新的備忘錄」。