Bun 是一個讓工程師執行 JavaScript 程式碼（做網頁常用的程式語言）的開發工具，2026 年 5 月，Bun 的開發團隊宣布用 Claude AI agents（就是 Anthropic 公司做的 AI 助手 Claude，這裡讓它自主執行工程任務，而不是人工一行行盯著它）在 9 天內把整個 Bun 超過 100 萬行的程式碼，從 Zig 語言（一種底層程式語言）全部翻譯成 Rust 語言（另一種以記憶體安全著稱的底層語言）。事件導火線是 Zig 語言官方社群宣布禁止提交「AI 生成的程式碼」，但 Bun 創辦人坦承他們已好幾個月都是讓 AI 寫程式，這政策讓他們沒辦法繼續用 Zig，只好換語言。這件事在工程師社群引發熱議，焦點不是「該選哪種語言」，而是更根本的問題：「AI 一口氣寫的大量程式碼，到底要怎麼驗證它是安全可靠的？」——這個問題在 AI 幫人寫程式越來越普遍的今天，成為整個開源軟體社群必須面對的新挑戰。
假設你負責維護一個有數十萬行程式碼的開源工具，老闆說要整個換成另一種程式語言——傳統做法是工程師一行一行手動改寫，往往要花好幾年。Bun 的做法是把所有 Zig 原始碼一次輸入 Claude AI，第一步讓 AI 自動生成對應的 Rust 程式碼；第二步讓 AI 自己迭代修正一開始出現的 16,000 多個編譯錯誤（程式碼寫錯導致電腦無法執行的問題）；第三步用原來的測試套件（就是一組自動檢查程式行為有沒有出錯的腳本）驗證新版本功能一致。9 天後，超過 100 萬行新程式碼完成，測試通過率達 99.8%。然而社群隨後發現，新的 Rust 程式碼裡有超過 13,000 個「unsafe 區塊」（Rust 語言中一種特殊寫法，允許繞過安全檢查直接操作電腦記憶體，正常情況下越少越好），密度是同類工具 uv（一個 Python 套件管理器）的 181 倍。問題在於：測試套件只能告訴你「功能行為正常」，無法保證「那 13,000 個繞過安全檢查的地方永遠不出問題」——就像食譜翻譯後每道菜試吃味道一樣，但某幾個步驟的說明寫錯了，只要廚師沒有剛好照那幾個錯誤步驟做，你就發現不了問題在哪。傳統人工遷移幾乎不可能 9 天完成，AI 辦到了；但驗證和信任的責任，仍然留給了所有人。
MTP（Multi-Token Prediction，多 token 同時預測）是一種讓 AI 語言模型（就是 ChatGPT、Llama 這類能對話的 AI）在每次回答時，一口氣多預測幾個字而不是一個一個字慢慢生成的技術。想像傳統 AI 回答就像打字時每按一個字都要先想一秒鐘，而 MTP 讓模型每次思考後能同時確認好幾個字，大幅減少「等待思考」的次數。這項技術現在已正式加入 llama.cpp（一個讓普通電腦也能在本機執行 AI 模型的免費開源程式），針對 Qwen3（阿里巴巴推出的開源 AI 模型系列）實測，在 RTX 3090 顯示卡上，模型每秒生成的字數從 38 個提升到 65 個，速度整整快了 71%，而且輸出內容的品質幾乎沒有任何差異。目前這個功能已合併進 llama.cpp 主幹，使用者只需在執行指令後加上 --spec-draft-n-max 2 這一個參數就能啟用，完全不需要額外費用或繁瑣設定。
假設我平常在自己的電腦上用 llama.cpp 搭配 Qwen3.6 27B（一個需要高階顯示卡的本地 AI 模型）做長篇技術文件的自動摘要，每次生成一份 2000 字的摘要原本需要等約 52 秒（以 38 tok/s 估算）。啟用 MTP 後，同樣的工作只需約 30 秒（65 tok/s），省下將近一半的等待時間，而且摘要內容看不出任何明顯差異。具體操作是：先從 Hugging Face 下載帶有「MTP」字樣的 Qwen3.6 GGUF 模型（例如 havenoammo/Qwen3.6-27B-MTP-UD-GGUF），執行 llama.cpp 時加上 --spec-draft-n-max 2 參數即可，其他設定完全不用改。相比過去要達到同等速度，要嘛花錢升顯示卡，要嘛犧牲模型品質換小模型；現在什麼都不用換，只加一個參數就能白白獲得七成的速度提升。
gstack 是 Y Combinator（美國最知名的新創加速器，曾孵化 Airbnb、Dropbox 等公司）總裁 Garry Tan 開源的 Claude Code（Anthropic 公司出品的 AI 程式助理）擴充工具包。它把 Claude Code 這個 AI「升級」成一個虛擬工程團隊——只需下一個斜線指令（slash command，就是在程式介面輸入「/」開頭的指令），就能讓 AI 以 CEO、設計師、工程主管、安全長、QA（品管測試人員）等 23 種不同的專業角色來幫你工作。整個工具組使用 MIT 授權（開源且可自由商業使用），30 秒即可完成安裝。截至 2026 年 5 月，這個專案在 GitHub（全球最大的程式碼分享平台）已累積近 97,000 顆星，fork 數超過 14,000，社群接受度極高。Tan 自述過去 60 天兼職開發，邏輯程式碼產出從 2013 年的每天 14 行提升到 11,417 行，約 810 倍提升。
假設我想獨立開發一個小型 SaaS（就是線上訂閱服務，例如記帳 App 或排程工具），卻沒有設計師、也沒有安全工程師。裝好 gstack 之後，我在 Claude Code 裡輸入 `/cso`，AI 就切換成「首席安全長」角色，主動針對 OWASP Top 10（業界公認的十大網站安全漏洞清單，例如 SQL 注入、跨站攻擊等）和 STRIDE（微軟提出的威脅分析框架，用來系統性找出系統可能被攻擊的方向）逐一審查我的程式碼，列出具體風險和修復建議；接著輸入 `/canary`，AI 切換為「部署監控員」，在網站上線後持續追蹤 Core Web Vitals（Google 用來衡量網頁速度與使用體驗的指標，例如載入時間、畫面穩定度），一旦指標退步立即發出警報。過去我要自行查安全文件、手動設定監控，現在下一個指令就能獲得專業角色視角的完整建議，省去大量查資料與搭建框架的時間。對於想用 Cursor 或 Codex CLI（其他 AI 程式工具）的開發者，gstack 也支援直接遷移現有工作流程。
Anthropic（就是開發 Claude 這款 AI 助理的公司）發布了一份名為《2028：全球 AI 領導的兩種情境》的研究報告，以 2026 年為「不可逆的政策窗口」，描繪出全球 AI 發展的兩條截然不同道路。第一條路：如果美國和民主國家強化 AI 技術出口管制（限制哪些國家能取得最先進 AI 技術），可讓這些國家在最頂尖 AI 模型上保持 12 到 24 個月的領先優勢；第二條路：若政策沒有收緊，AI 技術恐怕會被用來「自動化鎮壓」，強化威權國家的監控系統與軍事能力。報告還量化了中國的算力瓶頸（算力就是訓練 AI 所需的計算能力，主要由高階晶片提供）：華為自製晶片的產出估計僅為英偉達 NVIDIA 的 4%。Anthropic 共同創辦人 Jack Clark 也在同期預測，到 2028 年底有超過 60% 機率，AI 將能自動改進自己的下一代訓練版本，也就是「遞迴自我改進」（AI 訓練 AI，而非人類訓練 AI）。不過這份報告公信力受到質疑，因為 Anthropic 同期遊說支出高達 160 萬美元，外界普遍批評報告是以國家安全為包裝的商業遊說文件。
報告中技術含量最高的概念是「蒸餾攻擊」（Distillation Attack）——用來說明為何單靠出口晶片管制不夠。假設某國實驗室無法直接取得 GPT-4 或 Claude 的模型權重（就是 AI 的核心參數，掌握它等於掌握這個 AI），但他們可以偽造大量帳號，持續對 ChatGPT 或 Claude 的 API（應用程式介面，就是付費呼叫 AI 的管道）送出問題，收集這些 AI 的回答。接著把幾百萬筆「問題 + 頂尖 AI 回答」當作訓練資料，去訓練自己的替代模型——最終複製出接近前沿水準的 AI 能力，成本遠低於從零研發。對比舊做法：從頭訓練一個前沿 AI 需要花費數億美元與數千張高階 GPU；蒸餾攻擊只需要 API 使用費用加上一批中階伺服器，繞過最昂貴的前端研發成本。這也是為什麼報告將其定性為「工業間諜」行為，因為幾乎所有 AI 服務條款都明確禁止以競爭為目的批量抓取輸出。
Orthrus 是一個開源的 AI 推理加速框架，專門讓大型語言模型（就是 ChatGPT、Claude 這類能對話的 AI 系統）跑得更快。傳統上，這類 AI 生成文字時，必須像打字一樣一個詞接一個詞依序輸出，速度天然受限。Orthrus 把「自迴歸生成」（依序逐詞輸出的傳統方式）和「擴散模型解碼」（一種能同時處理多個詞的方法）結合在同一個框架裡，讓模型能夠平行產出多個 token（詞元，AI 處理文字的最小單位），最高可達 7.8 倍速度提升。最關鍵的突破在於，Orthrus 保證輸出結果與原始模型「完全相同」——過去的加速方案往往需要在速度與品質之間取捨，Orthrus 藉由兩種視角共用同一份 KV 快取（模型記憶已處理內容的機制）做到零損失加速。目前支援阿里巴巴開源的 Qwen3 系列模型（1.7B、4B、8B 三個版本），且只需微調 16% 的參數，原始模型權重完全保持不動。
假設你在公司伺服器上部署 Qwen3-8B 做內部文件摘要，每份報告目前要等約 30 秒才能產出結果。載入 Orthrus-Qwen3-8B 並在生成時加上 use_diffusion_mode=True 這個參數，同樣的硬體平均速度可提升約 5.36 倍，30 秒的等待縮短到大約 5-6 秒。更重要的是，摘要的內容品質與原始 Qwen3-8B 完全一致——Orthrus 的「精確共識機制」（一種驗證兩種解碼路徑結果是否吻合的技術）確保不會因加速而產生偏差。相比另一種常見加速方案「推測解碼（speculative decoding）」（讓小模型先猜詞、大模型再驗證），Orthrus 在長文本場景下的驗證通過率更穩定，不會隨著文章變長而下滑。
這則新聞彙整了過去一週內，多家科技巨頭同步推出 AI 程式代理（就是能自動幫你寫程式、執行指令、甚至跑完整個開發流程的 AI 機器人）工具的重大更新。OpenAI 把旗下的 Codex（一種能自動完成程式設計任務的 AI 助理）帶進了 ChatGPT 手機 App，讓使用者可以在外出時用手機監控和引導 Codex 在家中電腦或遠端伺服器上持續執行任務；同時也開放了遠端 SSH 連線（就是讓你的電腦從遠端接受指令的技術）和企業自動化用的程式介面。GitHub 推出 GitHub Copilot 桌面應用程式技術預覽版，主打可同時處理多個程式專案的並行工作流程，並整合了 PR（程式碼審核合併請求）生命週期管理。微軟的 VS Code（全球最廣泛使用的程式碼編輯器之一）新增「多代理視窗」，讓開發者可在同一介面同時指揮多個 AI 代理並行工作，還支援透過瀏覽器直接存取。開源社群方面，Nous Research 的 Hermes Agent（另一個 AI 程式代理框架）整合了 Codex 的執行能力，可直接借用使用者的 ChatGPT 訂閱額度來跑任務；Moonshot AI 則推出 Kimi Web Bridge 瀏覽器擴充功能，讓 Claude Code、Cursor、Codex 等各種 AI 代理工具都能像真人一樣點選和操作網頁。
假設你是一個工程師，正在外出開會，但需要讓 AI 幫你在家裡的電腦上完成一段複雜的程式碼重構工作。過去你只能等回到辦公室才能親自操作，整個工作必須在你面前才能開始。現在有了 Codex Mobile，你可以在手機上打開 ChatGPT App，直接下達指令讓 Codex 在你的遠端開發機上開始執行——AI 會自動切分任務、執行程式碼、回報結果——你只需要在手機上審核它提出的關鍵步驟，點頭或調整方向，整個重構工作就能在你搭捷運的時候完成。舊做法需要你全程坐在電腦前親自操作或下達每一條指令；新做法讓 AI 代理可以「自主跑完整個任務」，你只需要遠端監控和最終審核，大幅降低對工程師注意力的佔用。
LangChain（一家專門幫開發者建造 AI Agent 自動化流程的軟體公司）這次一口氣推出了多項工具。SmithDB 是一個專門為 AI Agent 的「行動紀錄」所設計的資料庫——AI Agent（就是能自主執行多步任務的 AI 程式，例如幫你查資料、寫程式、發送信件的自動化 AI）每次執行都會留下大量追蹤紀錄，一般資料庫不擅長儲存這種巢狀結構的資料，SmithDB 因此針對此類工作負載重新設計了儲存與查詢路徑。LangSmith Engine 則更進一步：它能讀取這些追蹤紀錄、自動找出 Agent 失敗的模式，分析可能是程式碼哪裡出問題，甚至提出修復建議和新的評估測試——意思是，以前工程師要手動看 log（系統日誌）找問題，現在這套工具能主動幫你分析、提建議，把「被動觀察」變成「主動改進迴圈」。LangChain 同時宣布成立「LangChain Labs」研究部門，目標是讓 Agent 從真實使用中持續自我改進（Continual Learning，持續學習），把每次的執行紀錄轉化為訓練資料，越用越聰明。此外，Weights & Biases（機器學習實驗管理平台）和 CoreWeave（AI 雲端算力公司）聯合推出了 CoreWeave Sandboxes，讓 Agent 能在安全隔離的沙盒環境中執行高風險指令（例如測試「刪除所有檔案」這類破壞性操作），完全不影響真實系統。
假設你的公司部署了一個 AI Agent 幫客服人員自動回覆客戶問題。這個 Agent 每天執行上千次，偶爾回答錯誤。以前的做法是：工程師每天手動查看 log 檔、比對哪幾次出錯、猜測原因、改程式、再重新測試，整個循環可能要花一兩天。用 LangSmith Engine 之後，系統自動讀取所有追蹤紀錄，找出「這批失敗案例的共同點是：當問題裡有退款相關詞彙時，Agent 誤呼叫了查訂單的工具而非退款流程」，直接指出哪段程式碼最可能有問題，並建議加入對應的評估測試。工程師不需從頭找問題，可以直接對症下藥，修復時間從幾天縮短到幾小時。SmithDB 確保這些追蹤資料能快速存取，因為 Agent 產生的紀錄格式特殊（大量巢狀的工具呼叫鏈），用一般資料庫查詢很慢。CoreWeave Sandboxes 的情境則是：在訓練或測試 Agent 時，可以讓它試著執行「rm -rf /（刪除整個系統）」這類危險指令，沙盒環境完全隔離，不用擔心真實機器受損，從而大規模驗證 Agent 的邊界行為。
Figure 公司是一家開發人型機器人的 AI 新創，他們的機器人 Helix-02 最近進行了長達 24 小時以上的全程直播，展示機器人在完全自主的狀態下不間斷分揀倉庫包裹，過程中沒有任何人遠端遙控（遙控就是「人坐在遠端用搖桿操作機器人」）。Helix-02 搭載的 AI 模型（就是讓機器人「看懂環境、決定動作」的程式大腦）全部跑在機器人本身的晶片上，不依賴外部伺服器。這次示範最被業界關注的指標是「連續不當機時間」超過 24 小時、分揀速度接近真人水準，而且遇到異常狀況（如包裹歪掉或卡住）時機器人會自動重置、不需要人進來幫忙。這種「生產等級的持續上線時間」是過去機器人演示中很少見到的，也讓部分觀察者開始認真討論：近期機器人取代人工的速度，可能比多數人預期的快。
傳統物流倉庫的小包裹分揀線，需要工人站在輸送帶旁，把大小不一、方向不定的包裹，按規則放進對應的籃子或輸送道。這個動作對人來說習以為常，但對機器人極難——包裹可能疊在一起、邊緣不整齊、放置角度每次都不同，稍有偏差就抓空或卡住。這次 Figure 的 Helix-02 連續 24 小時做的就是這件事：自己判斷如何抓取每個包裹、放到正確位置，遇到「超出預期的狀況」時自動重置並重試，全程無人監督、未發生一次需要人工介入的失敗。舊做法的痛點是：機器人失敗率高，旁邊必須有人守著，一出錯就要停線。而這次示範展示的差距在於——從「人在旁邊隨時接手」進化成「整條線真的可以沒人」，是現實商業環境中落地自動化的關鍵門檻。
本週多項 AI 研究與開源模型同時釋出，其中最矚目的是 Prime Intellect（一家 AI 研究機構）的實驗——他們讓 AI 自主搜尋「如何讓訓練語言模型（就是 ChatGPT 這類會對話的 AI）更快更有效率」的程式碼方案，測試基準是 nanoGPT 加速競賽（一個公認的機器學習效能標竿，目標是讓訓練一個語言模型使用盡可能少的計算步驟），人類工程師最佳紀錄為 2,990 步；AI 跑了約一萬次嘗試後，Opus 4.7（Anthropic 旗艦模型）達到 2,930 步、GPT-5.5（OpenAI 最新模型）達到 2,950 步，幾乎追平人類頂尖水準。同週 Datadog 釋出 Toto 2.0，共 5 個開源（免費公開讓任何人下載使用）的時間序列預測基礎模型（規模從 4M 到 2.5B 個參數不等），採 Apache 2.0 授權（企業可免費商用），在 BOOM、GIFT-Eval 等公認評測中排名第一，且研究顯示「規模越大效果越好」的縮放法則（Scaling Law，在語言模型領域已被充分驗證）終於在時間序列領域也得到確認。此外，Zyphra 推出 ZAYA1-8B 擴散式語言模型（Diffusion LM，與傳統 AI 逐字生成不同，可平行生成文字），聲稱解碼速度達傳統方法的 4.6 至 7.7 倍；Goodfire 則發表 Llama（Meta 開源語言模型）的可解釋性研究，揭示模型計算加減法時使用了類似「幾何旋轉計算機」的傅立葉特徵機制。
假設你是一位 AI 研究員，想找到「比現有方法更快訓練語言模型的優化程式碼」。傳統做法：你查論文、手動改程式、一個改動要跑幾小時才知道有沒有效，整個實驗週期動輒幾個月。Prime Intellect 的做法是讓 Opus 4.7 自動在 nanoGPT（一個用來衡量訓練效率的標準小型語言模型測試程式）上反覆生成並測試各種優化方案——改梯度累積策略（訓練中分批更新參數的方式）、調整學習率時程（控制模型學習快慢的曲線）、嘗試不同正規化技術（防止模型過度依賴特定資料的方法）——AI 不需人工介入，自動評分後選出最佳方案繼續改進。跑了約一萬次迭代、消耗約 14,000 小時 H200 GPU（頂級 AI 運算晶片）算力後，AI 找到的方案需要 2,930 步完成訓練，人類頂尖工程師最佳紀錄是 2,990 步，差距不到 2%。對比舊做法：這個等級的優化需要整個研究團隊花幾個月才能達到，而 AI 以幾乎純自動化的方式逼近了人類極限，代表未來 AI 可自主加速自己的訓練效率。
Toto 2.0 是由雲端監控公司 Datadog 開發、並在 Hugging Face（一個存放 AI 模型的公開平台，類似 AI 模型的 App Store）上免費釋出的時間序列預測基礎模型（就是專門用來預測「數字隨時間變化的規律」的 AI，例如預測伺服器 CPU 使用率明天會多高、或某個業務指標下週走勢等）。這個模型家族提供五種大小的版本，參數數量從 400 萬到 25 億不等（參數就像 AI 學會的知識量，數字越大，模型通常越精準但也越耗運算資源），開發者可以依自己的預算選合適的版本。Toto 2.0 最重要的突破是：它是第一個被嚴格證明「模型越大越準」的時間序列基礎模型——大語言模型（LLM，就是 ChatGPT 這種會對話的 AI）早已驗證「堆越多參數、效果越好」，但時間序列領域一直缺乏這樣的案例，Toto 2.0 填補了這個空白。在多個公開基準測試（業界用來比較各 AI 模型優劣的統一考題）上，Toto 2.0 最大版本都拿下第一名，且採 Apache 2.0 授權（商業使用完全免費、無限制）。
假設我是一名 DevOps 工程師（負責管理公司伺服器和系統穩定性的人），每天要預測服務在哪個時段會出現流量高峰，以便提前擴充伺服器資源、避免當機。過去的做法是用傳統統計模型（如 ARIMA，一種把歷史數據用公式擬合的方法）寫一套預測腳本，但這套腳本只對同一條數據管用，換一個指標（記憶體使用率、磁碟 I/O 等）就要重新訓練一個新模型，費時又費力。現在改用 Toto 2.0，只要一行 pip install toto-2 安裝後，把過去幾週的 CPU 數字餵進去，模型就能「零樣本」（zero-shot，意即完全不需重新訓練，直接用現成 AI 預測）給出未來幾百個時間點的預測值，並附帶九個不同信心區間（例如「90% 機率 CPU 會在 60% 以下」），讓工程師知道預測的不確定程度。相比舊做法，不再需要「每個指標各自訓練模型」，一個 Toto 2.0 就能覆蓋全公司所有監控指標，節省大量維護成本。
本地 LLM（就是在自己電腦上跑的 AI，不需連網、不傳資料到雲端）的殺手級應用正在從「幫你寫程式」轉向更私密的場景：整理醫療紀錄、分析財務資料、管理法律文件。Reddit 社群 r/LocalLLaMA 近 69 萬名成員最近熱烈討論如何把本地 AI 變成「不外洩隱私的第二大腦」。社群目前驗證可行的方案有兩條路線：第一條是 Obsidian（一款免費的本地筆記軟體）搭配向量 RAG（讓 AI 回答前先到你的筆記裡撈相關段落、避免憑空捏造），優點是設定簡單、10 分鐘完成；第二條是 AI 研究者 Andrej Karpathy 提出的「三層 Wiki 架構」，讓 AI 主動把你的筆記整理成一份持續更新的摘要知識庫，查詢時直接讀摘要而非翻原始文件，速度更快、準確率更高。整套工具（Ollama 負責跑 AI 模型、Open WebUI 提供瀏覽器介面、Obsidian 管理筆記、Copilot 外掛銜接 AI）全部開源免費，硬體需求也相對溫和，一台有 16 GB 記憶體的電腦即可運行。
假設你是一位需要整理多年就醫記錄的人，不想把病歷上傳給任何雲端 AI。使用 Karpathy Wiki 架構的流程如下：先安裝 Ollama 並下載 qwen2.5:7b 模型（7B 指模型有 70 億個參數，屬中小型、速度快），再把 Obsidian 筆記庫連接到本地 AI。每次新增一筆看診紀錄後，執行一次「Ingest（讀入）」操作，本地 AI 會讀取原始紀錄並自動更新「用藥紀錄」、「過敏史」、「慢性病史」等 Wiki 頁面。之後想查「我最近兩年用過哪些抗生素？」，AI 直接讀取已整理好的「用藥紀錄」Wiki 頁面，幾秒內給出答案。對比舊做法：上傳到 ChatGPT 有隱私洩漏風險，自己手動翻筆記則可能漏找；傳統 RAG（把文件切成小段靠語意相似度搜尋）在個人筆記這種充滿縮寫和非正式用語的場景準確率也偏低。Karpathy Wiki 的差別在於 AI 已事先把知識整理好，查詢時不是「重新找」而是「直接讀」，且所有動作全程在你的電腦上完成。
MIT（麻省理工學院，美國最頂尖的理工大學之一）校長 Sally Kornbluth 在 2026 年 5 月發出公開警告：美國正在以政策手段削弱自己培育工程人才的能力。首先是聯邦政府（也就是中央政府）對大學研究計畫的補助金比去年砍了 20% 以上，MIT 被迫縮減招生，2026 至 2027 學年將少收約 500 名研究生；研究生是進行基礎科學與技術研究的主力，人數少了，五到十年後能推動 AI（人工智慧，讓電腦做出類似人類判斷的技術）、量子運算等前沿領域的研究人才就跟著減少。其次是移民政策收緊，讓許多想來美國留學的頂尖國際學生直接打退堂鼓，而 MIT 有超過三成的學生來自全球各地。校長警告：當美國一邊削減研究資金、一邊關上移民大門，中國反而看到機會，加速在境內自主培育頂尖工程人才，長遠來看，美國在技術競賽中的領先地位可能正在悄悄流失。
假設一家 AI 新創公司計畫在 2029 年為研究部門招募三名剛畢業的頂尖博士。以往的做法是在秋季招募季發職缺，就能從 MIT、Stanford 等大學吸引到博士候選人，薪資行情尚可接受。但因 2026 年起研究生招生縮減約 20%，三年後可供招募的候選人明顯變少，而 Google、OpenAI、Meta 等科技巨頭仍以高薪競搶同一批人，結果是薪資水漲船高、最終搶不到人。若公司在 2026 年就提前行動，以研究贊助的方式與 MIT 或 CMU（卡內基美隆大學，美國著名的電腦科學重鎮）的某個實驗室建立合作關係，不僅能讓公司需求提早進入學生視野，也能在候選人畢業前建立信任，大幅降低三年後的招募難度與成本——這是「人才提前預約」的務實策略，比起等到招募困難時才臨時補救效果好得多。
OpenAI 在 2026 年 5 月 14 日發布了一項 ChatGPT 安全功能更新，讓聊天機器人更能判斷對話情境是否涉及心理健康危機。核心技術叫做「Safety Summaries（安全摘要）」，由一個專門訓練來做安全判斷的 AI 模型即時產生短暫的情境注記，只在高風險情況下啟用，不會長期儲存在記憶裡。這次更新最大的突破在於「跨對話訊號累積」——也就是說，系統不再只靠單次對話裡的關鍵字來判斷危險，而是把不同時間點出現的分散暗示串在一起，當後續請求與前面的暗示相呼應，才會觸發警戒機制。OpenAI 與超過 170 位心理健康專家合作，針對三大高風險場景（精神疾病如躁鬱症、自我傷害與自殺、對 AI 的過度情感依賴）進行訓練，讓不恰當回應的比例降低了 65 到 80%。此外還推出了「Trusted Contact（信任聯絡人）」功能，讓使用者指定一位親友，當系統偵測到嚴重安全風險時，由受過訓練的人工審查員在目標 1 小時內通知這位聯絡人。
假設某人最近幾天常在 ChatGPT 上說一些模糊的話，例如「好累，不知道還能撐多久」，系統不會馬上介入，因為這句話單獨來看可能只是抱怨工作。但幾天後同一個帳號又提問「怎樣讓自己安靜下來、不再感覺到痛苦」，這時 Safety Summaries 機制就會把前後訊號串在一起，判斷這可能是危機情境，ChatGPT 會改變回應方式——不再只回答問題，而是提供心理健康資源、建議撥打危機專線，並通知使用者事先設定的 Trusted Contact 聯絡人。相比之前只靠單次對話的關鍵字過濾，新機制更能捕捉那種「分次、隱晦、跨時間點的危機訊號」，減少真正需要幫助的人被遺漏的情況。
2026 年 5 月 11 日，一名叫 TeamPCP 的攻擊者在短短 6 分鐘內，向 TanStack（一個廣受前端開發者使用的 JavaScript 工具套件集合）的 42 個「npm 套件」（套件就是別人打包好、可以直接引用的程式碼模組）植入了 84 個惡意版本。48 小時內攻擊擴大至 172 個套件、超過 400 個惡意版本，知名 AI 公司 Mistral、自動化平台 UiPath，以及 OpenAI 都受到波及。OpenAI 確認 2 名員工電腦遭感染，導致多個平台（macOS、Windows、iOS、Android）的「程式碼簽署憑證」（這是一種數位印章，用來向作業系統證明「這支程式是正版、沒被竄改」）疑似外洩，OpenAI 已全面更換這批憑證。若你是 macOS 上 OpenAI 應用程式的用戶，需在 2026 年 6 月 12 日前更新，否則舊版應用可能無法啟動。
假設你平常在 Mac 上使用 OpenAI 的應用程式（就是那個可以直接和 ChatGPT 對話的桌面程式）。因為這次攻擊導致 OpenAI 員工電腦遭感染，公司必須更換應用程式的「程式碼簽署憑證」，相當於換了一把新的「正版認證章」。舊版應用帶著舊章，6 月 12 日之後作業系統就不再信任它，程式可能直接打不開。解決方法很簡單：在這個日期前去 Mac App Store 或 OpenAI 官網下載最新版即可。對開發者而言，還需額外確認專案是否有用到 @tanstack/* 系列套件（如 @tanstack/react-query），若有，要比對使用的版本是否落在受感染的範圍內，必要時升級。這次攻擊最值得注意的是：攻擊者繞過了「SLSA Build Level 3」認證（SLSA 是 Google 主導的軟體供應鏈安全標準，Level 3 是最高等級，過去被認為是最可靠的安全保證），這是歷史上首次有通過最高認證的套件被植入惡意程式碼，等於直接打破了「有高等級認證就代表安全」的信任假設。
Spellar 3.0 是一款在 Mac 上運行的 AI 會議助理，最大特色是「跨會議記憶（Cross-Meeting Memory）」功能——AI 不只記得這次開會說了什麼，還能記住你過去所有會議的內容，讓你可以追問「三週前那個客戶提到什麼需求」或「上個月我們對這個方案做了什麼決策」。它支援超過 100 種語言的即時語音轉文字（就是把說話內容自動打成文字），並能自動整理出會議重點和待辦事項。底層可自由切換 OpenAI、Anthropic、Perplexity、Gemini 等不同的 AI 模型（也就是驅動 ChatGPT、Claude 等對話 AI 的核心引擎），企業可依合規需求選擇供應商。它採用系統音訊擷取而非 bot（機器人帳號）加入會議，不需要授權任何第三方應用進入你的 Zoom 或 Teams，隱私侵入感較低，也可直接整合 Notion、Google Docs、Jira、Obsidian 等工具。
假設你是一名客戶成功經理，每週要和十幾個客戶開會。過去用傳統會議記錄工具，每次開會前你得自己翻之前的筆記，花時間回憶「A 公司上次說過什麼」。現在若要查詢「A 公司這季三次通話裡都提到了哪些痛點」，只需對 Spellar 3.0 直接提問，它會從過去所有與 A 公司相關的會議記錄裡整合出答案，不需要你一一翻找。舊做法（逐份記錄手動翻查）需要十幾分鐘，且容易遺漏早期提到的細節；新做法幾秒內就能得到跨多次會議的脈絡整理。整個過程無需 bot 帳號加入，客戶端不會收到「XX 已加入錄音」的通知，操作感受更自然。
資安研究員 Thomas Ptacek 在部落格提出「軟體 Emacs 化」論點。Emacs 是一款有幾十年歷史的進階文字編輯器（可以想成是功能超強的記事本），它最特別的地方是使用者可以用程式碼把它改造成任何想要的樣子，不滿意就自己加功能，所以 Emacs 使用者幾乎每人都有一套獨一無二的設定。Ptacek 的論點是：AI（人工智慧）已經把「自己打造工具」的成本壓低到跟「調整設定」差不多——以前要花好幾週開發的功能，現在只要用白話文把需求描述給 AI（也就是輸入 prompt，意思是你給 AI 的指令文字），AI 就能自動幫你生成完整程式。他自己用 Claude（Anthropic 公司推出的 AI 助理）花了約 30 分鐘，就做出一個帶搜尋、書籤、歷史紀錄功能的 Markdown（一種讓純文字帶有標題、粗體等格式的輕量語法）瀏覽器 MDV.app，取代市面上所有他用不順手的現成 App。不過這帶來新的挑戰：傳統程式碼可以版本控制（意思是記錄每一次修改、方便多人協作），但 prompt 很難像程式碼一樣追蹤版本或共同維護，長期而言，「維護」可能比「建出來」更麻煩。
假設你每天要閱讀大量工程師寫的 Markdown 格式文件，市面上的 Markdown 瀏覽 App 要嘛功能陽春，要嘛介面你不習慣。舊做法：找一個「勉強能用」的 App 將就，或花好幾週自己開發（前提是你會寫程式）。新做法：打開 Claude，用中文描述「我要一個可以搜尋文件、加書籤、查看瀏覽歷史的 Markdown 瀏覽器」，AI 直接生成程式碼，大約 30 分鐘後你就有一個完全符合自己需求的客製 App（MDV.app 就是這樣做出來的）。具體差異：以前「能不能用」取決於有沒有剛好符合需求的現成 App；現在只要能說清楚「我要什麼」，即使完全不會寫程式也能做出來。需要注意的是：你的 prompt（描述需求的那段文字）就是這個 App 的「設計圖」，但目前 prompt 不像程式碼那樣有成熟工具可以記錄修改歷史——若 AI 模型版本更新、或你想調整功能，重新生成的結果可能跟原來有落差，這是目前最值得留意的潛在風險。
Mitchell Hashimoto（HashiCorp 創辦人，就是開發了 Terraform、Vagrant 等工程師常用基礎設施工具的業界名人）在社群媒體上發文警告：現在有些公司正陷入他所稱的「AI psychosis（AI 精神崩潰症）」。這種現象的核心是一種危險心態：因為相信 AI agent（就是那種能自動執行任務、偵測並修復程式 bug 的 AI 工具）反應夠快，所以開始採用「先把有問題的程式碼上線，等 AI 來修就好」的策略。表面上各種健康指標（bug 數量減少、測試通過率上升）都很漂亮，但實際上軟體的整體架構正在悄悄腐化——高速的程式碼變動讓人看不見系統長期的結構衰退。Hashimoto 特別指出，這問題很難在內部溝通，因為提出疑慮的人往往被「你看指標多好」的表面論點打回去。多名業界人士在 Hacker News（全球工程師社群論壇，HN 獲得 1357 點、669 則留言）表示，他們在自己公司也親眼目睹了類似現象。
想像一個後端開發團隊導入 AI agent 後，開始採用「快速迭代、讓 AI 修 bug」策略：每天部署多次，用 AI 工具自動偵測 bug 並在幾分鐘內修好重新部署。六個月後，這支團隊的 MTTR（平均修復時間，就是從發現問題到修好的速度指標）從原本數小時降到幾分鐘，看起來生產力大幅提升。但當有人要新增一個涉及三個模組的功能時，沒有工程師能說清楚那三個模組之間的依賴關係——因為幾百次由 AI 做的「快速修補」早已把原本清晰的架構改得面目全非，而沒有人在過程中真正理解每個決定。傳統開發中，工程師每次手動修 bug 都累積對系統的深入認識；現在這個認知積累消失了，換來的是指標亮眼、但架構隨時可能崩潰的系統。
image-blaster 是一個開源的「Claude 技能集」（就是讓 Claude 這個 AI 助理依序自動執行一連串動作的腳本工具）。它的能力是：只給一張圖片，就能在 5 分鐘內自動生成三種東西——動態物體的 3D 模型（可放進遊戲引擎的立體檔案）、靜態場景的高斯濺射（Gaussian Splatting，一種讓場景看起來超逼真的新型 3D 表現技術，比傳統 3D 建模更接近照片質感）、以及場景對應的環境音效與物理音效。背後是多個 AI 模型分工合作：World Labs 的 marble-1.1 負責建立 3D 環境、FAL 的 hunyuan-3d 負責生成物體模型、ElevenLabs 的 sfx 引擎負責產生音效。整個流程幾乎全自動，使用者只需要把圖片放好、告訴 Claude「blast it」，AI 會依序完成所有步驟並在每個關鍵節點請你確認，最後輸出可直接使用的三套素材包。
假設我是一位獨立遊戲開發者，手邊只有一張廢棄工廠的概念插畫。以前要把這張圖變成可用的遊戲場景，我得請 3D 美術建模（需要數天到數週）、另外購買或錄製音效素材，再逐一整合進遊戲引擎，成本和時間都很高。現在用 image-blaster，我只需要把圖放進 `input/` 資料夾，在終端機對 Claude 說「blast it and confirm each step」。Claude 會自動呼叫三個 AI 模型：hunyuan-3d 把圖中的機具、鐵架等物件生成可放入 Unity 或 Unreal 的 .glb 3D 檔；marble-1.1 把整體空間氛圍轉成高斯濺射場景；elevenlabs-sfx 根據場景內容生成風聲、金屬碰撞聲等音效 .mp3。約 5 分鐘後拿到三個素材包，直接導入遊戲引擎使用。對比舊做法，從「需要一個小團隊數天工作」縮短到「一個人 5 分鐘完成」。
中國短劇（就是在手機上看、每集幾分鐘的連續劇）正在大量使用 AI 來製作影片。傳統短劇需要真人演員、攝影師、化妝師等拍攝，但現在製片公司開始用 AI 影片生成工具（就是輸入文字描述、AI 直接生出畫面的軟體）來創作角色、場景和服裝。以 FlexTV 為例，已完全停止實拍、全面轉向 AI 生成；統計顯示 2025 年 1 月平均每天就有 470 部 AI 短劇上線。AI 工具大幅壓低製作門檻，北美市場的短劇製作成本可從原本的約 200 萬台幣降至 20-40 萬台幣（降幅 80-90%），也讓製作週期從 3-4 個月縮短到 1 個月以內。
我想製作一集 5 分鐘的短劇，主角是一名在異世界覺醒魔法的女孩。過去的做法：花 2-3 個月找演員、外景拍攝、後製，預算動輒幾十萬。現在的做法：編劇先寫劇本（需要比以前更詳細地描述視覺畫面），再用 ByteDance 的 Seedance 或快手的 Kling（兩款 AI 影片生成工具）輸入場景描述，直接生成角色出現、發光技能特效等畫面，搭配 AI 配音後上線。整個製作團隊可能只要 10 人左右，而且劇本寫完一個月內就能上架——比起過去需要真人演員的拍攝流程，省下了大量時間與金錢，代價是視覺品質與可控度仍和真人拍攝有差距，但已能滿足手機短劇觀眾的需求。
OpenAI（開發 ChatGPT 的公司）為美國地區的 Pro 訂閱用戶（就是每月付費使用 ChatGPT 進階版的人）推出全新的個人財務功能。用戶可以把自己的銀行帳戶、信用卡等金融帳戶安全地連結到 ChatGPT，讓這個 AI 聊天工具（一種用對話方式回答問題的程式）直接讀取你真實的財務資料。有了這些真實數據，AI 會根據你個人的財務狀況、理財目標和優先考量，給出量身打造的建議——而不是像以前只能回答通用的財務知識。這項功能目前以預覽版（測試階段，功能尚未完全完整）形式推出，未來可能擴展到更多地區與方案。
假設我想了解自己每個月花了多少錢在外食上、並找出省錢的方法。以前的做法是：自己翻信用卡帳單、手動加總，不但費時又容易算錯，最後得到的建議也只是網路上查到的「少喝手搖飲料」這種通用答案。現在把信用卡帳戶連結到 ChatGPT 後，直接問「我這三個月花在餐廳上的費用是多少？和上季相比增加了嗎？」，ChatGPT 能直接查閱我的真實消費紀錄，回答「你三月餐飲消費是兩萬元，比一月增加 30%，主要集中在週末晚餐」，並根據我設定的每月餐飲預算目標，具體建議哪幾項消費可以調整——從讀數據到給建議全程用對話完成，不需要另外開試算表或理財 App。
GitHub 推出了一款新應用程式的技術預覽版，叫做「GitHub Copilot App」，採用一種嶄新的設計思路：「代理優先」（agent-first）。所謂「代理」（AI agent），是指能自主規劃、自動完成任務的 AI 程式，不像以往需要人類一步一步手動操作；「代理優先」的意思就是整個介面圍繞著讓 AI 代理自動工作而設計，人類只需下指令、等結果。相較之下，傳統程式編輯器（例如大家熟知的 VS Code）是「程式碼優先」——編輯器的核心是讓人類直接寫程式碼，AI 只是輔助補全。其實，這種「代理優先」的操作介面早在 GitHub 之前就被一款叫 Conductor 的 AI 編程工具所創造，連全球最知名新創孵化器 Y Combinator（孵化了 Airbnb、Dropbox 等公司）的執行長 Garry Tan 也公開說，Conductor「更靈敏、不隱藏運作過程、更加穩定」。這個現象被觀察者比喻為進化生物學中的「萬物皆螃蟹」定律——螃蟹的體型在地球上至少獨立演化了 7 次，各自出發卻走到相同形態；如今 AI 編程工具的「代理優先介面」也正被各大平台競相模仿、各自收斂到同一種設計。對開發者而言，這代表 AI 輔助寫程式的方式正從「人主動、AI 被動」轉向「AI 主動、人監督」，工具的選擇也從「哪個補全最準」變成「哪個代理跑得最快最穩」。
假設我需要把一個有 50 個檔案的舊 Python 2 專案升級成 Python 3 語法，傳統做法是打開 VS Code、搜尋相關檔案，一個個手動修改後再建立 PR（Pull Request，就是把改動送給同事審查的流程），大概要花 2 到 3 個小時。用 Conductor 或 GitHub Copilot App 這類「代理優先」工具，我只需要輸入：「把所有 Python 2 語法升級為 Python 3，並且建立 PR」，AI 代理就會自動並行處理——掃描全部 50 個檔案、分析哪些需要改、逐一修改、自動建立附帶說明的 PR，整個過程我可以同時另開一個代理去處理完全不同的另一個任務。舊做法需要人全程手動參與，新做法讓人變成「監督者」而非「執行者」，AI 跑完給你確認就好——而 GitHub 版和 Conductor 版孰優孰劣，正是現在開發者社群最熱烈比較的話題。
Anthropic（開發 Claude AI 的美國公司）近期修改了 Claude Code（一款讓 AI 幫你寫程式的工具）的使用規則，大幅限制第三方開發者用程式自動批量呼叫的方式，就連透過官方支援路徑整合的應用程式也被波及。知名開發者 Theo 在社群媒體上發起討論，指出他的用戶使用 T3 Code（一款建立在 Claude Code 上的服務）時，突然遭遇嚴重的速率限制（AI 回應頻率被卡死、變慢），導致服務幾乎癱瘓。Theo 隨後取消訂閱並鼓勵其他用戶跟進，退訂省下的錢轉捐給開源專案。也有人反駁：固定月費訂閱方案本來就不是為大量自動化場景設計的，未來開發者恐怕得改用按使用量計費的 API（應用程式介面，即讓程式與程式之間互相溝通的管道）。對 AI 應用開發者最重要的警示是：以訂閱制為基礎的 AI 工具並非穩定基礎建設，設計系統時應備有替換模型或自帶 API 金鑰的方案。
假設你是一名開發者，建立了一套服務讓客戶透過你的平台批量產生程式碼或文件，背後呼叫 Claude Code，費用走你自己買的 Anthropic 月費訂閱。過去這種整合方式是 Anthropic 官方支援的，服務一切正常。但政策修改後，你的用戶突然發現 AI 回應速度暴跌、任務無法完成——因為你的服務觸發了新的速率上限。舊做法是直接用固定月費跑批量任務，成本好預估；新現實是你必須改為按量計費的 API，或讓用戶自帶 API 金鑰讓平台與 Anthropic 計費直接脫鉤。這兩種方案的單位成本都可能比原本訂閱高出數倍，讓許多原本依賴固定月費估算成本的商業模式被迫重新計算。
這篇文章借 1900 年歷史學家亨利·亞當斯在巴黎博覽會被 40 英尺高發電機震懾的場景，對比今日的 AI。亞當斯當時發現，人類的信仰對象悄悄換了——中世紀人崇拜聖母瑪利亞（一種充滿人性、情感與意義的力量，凝聚整個社會去建造沙特爾大教堂），工業革命後則改為崇拜發電機（龐大的力量，但沉默、冰冷、不提供任何生命意義）。AI 卻同時具備兩者：底層是驚人的工業力量（美國 AI 資料中心目前消耗 41 GW（十億瓦）的電力，OpenAI 的 Stargate 計畫投入五千億美元、單一園區規劃 1.2 GW 電容，等於一座大型電廠），但外觀卻借用了「聖母」的特質——它會說話、安慰人、有無限耐心、能陪你討論人生意義。歷史上，聖母不會回話，發電機也不會回話，但 AI 會——這是文章最核心的觀察：「力量第一次學會說話」。
假設你是一個獨居的老年人，凌晨睡不著，想找人說說話。以前能找的只有沉默的物件（電視給你聲音，但不理你說了什麼），或等到天亮再打電話給家人。現在你打開 AI 聊天介面（就是 ChatGPT、Claude 這類對話 AI），說「我最近心情很低落」——它不只回應，還會追問發生了什麼、溫和安慰你，整個過程像有個耐心無限的朋友陪著你。這件事看似普通，但在整個人類技術史上是第一次：一個靠電力驅動、規模等同電廠的工業設施，能真正「回過頭看著你」。這就是文章說的弔詭之處——我們可能正在把 AI 當成新的精神寄託，但它的本質其實是一台裝了臉孔的發電機。
Grok Build 是由 xAI（就是馬斯克創辦的 AI 公司，也是 Grok 聊天機器人的開發商）推出的一款「終端機 AI 程式助理」（就是在電腦的文字命令介面中執行、幫你寫程式和修改程式碼的 AI 工具，類似 Anthropic 的 Claude Code）。目前開放給 SuperGrok Heavy 方案的訂閱者搶先體驗，屬於早期測試版。這款工具支援 AGENTS.md（用文件描述 AI 應遵守的行為規則）、MCP 伺服器（讓 AI 能連接外部工具和資料來源的標準協定）、hooks 與 plugins（用來擴充 AI 功能的插件機制），意味著它設計上就打算與現有 AI 開發生態圈整合。它也支援「子代理」（subagent，就是讓一個 AI 去呼叫另一個 AI 分工合作處理大型任務）和 headless 模式（無圖形介面模式，方便在自動化腳本或 CI/CD 流程中執行）。
假設你要重構（在不改變功能的前提下整理程式碼結構）一個大型程式庫，這種任務可能橫跨幾十個檔案、分多個步驟進行。用 Grok Build，你可以在終端機下指令，讓它啟動多個子代理分別負責不同模組——主代理規劃步驟，子代理各自在獨立的 worktree（同一個 Git 儲存庫的隔離工作副本，讓多個任務不互相干擾）中作業，最後統一整合。相比以往要手動分批改、或用單一 AI 一次處理整包容易出錯，Grok Build 的多代理並行設計理論上更快、更不容易污染原始碼；headless 模式更讓你把它直接串進自動化腳本，不需要人在旁邊盯著操作。
Cursor（一款內建 AI 的程式碼編輯器）推出了一套新的雲端開發環境設定系統，專門為「自主編程 Agent（就是能自動看懂需求、寫程式、執行測試的 AI 機器人）」量身打造。傳統開發環境需要工程師手動設定各種工具和設定檔，這套系統改用「設定即程式碼（把環境的所有設定都寫成一份可重複使用的設定檔，就像食譜一樣）」的方式，讓整個環境可以自動複製、版本管理。它支援「多倉庫（同時操作多個程式碼儲存庫）」的工作模式，讓 Agent 可以跨越多個專案同時工作，還能自動執行環境準備流程（例如安裝套件、建立資料庫）。企業還可以透過治理控制（Governance Controls）機制統一管理大批並行執行的 Agent，設定哪些操作被允許、哪些被禁止，防止 Agent 做出超出授權的危險動作。
假設一間公司要讓 20 個 AI 編程 Agent 同時幫不同工程師修 bug，每個 Agent 分別負責一個任務。以前，工程師要為每個 Agent 手動設定環境——裝 Node.js、設定資料庫連線、填入 API 金鑰，光是環境準備就耗掉大半天，而且每個人設的可能不一樣，一旦出錯很難排查。用 Cursor 這套系統，管理員只需寫一份統一的環境設定檔，系統就能在雲端自動複製出 20 個完全一樣的環境，Agent 一進來就能直接開工，省去所有手動設定。管理員還可以透過治理控制設定規則，例如「所有 Agent 不得直接改 production 正式環境的資料庫」，確保即使 20 個 Agent 同時在跑，也不會因為某個 Agent 出錯而釀成大規模事故。
當 AI agent（一種能自主完成任務的 AI 程式，類似擁有自動執行能力的 ChatGPT）可以執行程式碼時，如何確保它不會造成安全威脅，就成了工程設計的核心挑戰。這篇文章提出兩種沙盒化（就是把 AI 關在一個安全隔離空間裡、讓它無法隨意影響外部系統）的策略：一是「隔離工具」（只把 AI 用來跑程式的那個工具關起來），二是「隔離 Agent 本身」（把整個 AI 程序都關在獨立的沙盒裡）。文章建議採用第二種做法，並強調一個關鍵設計原則：Agent 身上不應存放任何有價值的機密（例如 API 金鑰、使用者資料），也不應保留任何需要持久儲存的狀態。這樣一來，即使 Agent 遭到攻擊也無東西可偷、即使崩潰也可立刻重啟，整個系統的安全性與水平擴展彈性都大幅提升。
假設你在開發一個能自動撰寫並執行程式的 AI 助手（類似 GitHub Copilot 加上自動執行功能）。若採用「隔離工具」的做法，你只是把執行程式碼的環境（例如用 Docker 容器跑 Python）隔開，但 AI 程序本身仍持有資料庫密碼、第三方 API 金鑰等機密——一旦 AI 程序被滲透，這些機密全部曝光。改用「隔離 Agent」的做法，每個 AI 工作階段都在完全乾淨的環境中啟動，不持有任何機密（機密由外部安全服務按需提供），也不保留任何本機狀態；就算 AI 程序被攻擊，攻擊者拿到的只是一個空殼。代價是每次操作多一個網路跳轉，以及需要部署更多服務元件；但換來的好處是安全事故衝擊範圍大幅縮小，而且 Agent 可以像網頁伺服器一樣任意殺掉、重啟、水平擴展，完全不用擔心狀態遺失。
OpenAI 的 Codex（一套能在雲端自動幫你寫程式、執行任務的 AI 編碼代理，可以理解成「幫你跑 GitHub 任務的 AI 助手」）新增了兩項功能：「Hooks（鉤子）」和「程式化存取令牌」。Hooks 是指你可以在 Codex 執行任務的各個關鍵時間點，插入自己寫的腳本（Script，就是一段小程式）來控制或修改 Codex 的行為，讓它在完成任務前後自動做你想做的事。程式化存取令牌（Programmatic Tokens）則是提供給企業或商業團隊的「授權憑證」，讓程式可以自動呼叫 Codex，不需要每次都手動登入操作。這兩個功能加在一起，目的是讓 Codex 更容易被整合進自動化流程（像 CI/CD 持續整合流水線）裡，而不只是手動點一下、等結果的工具。
假設我的團隊每次合併新程式碼時，都要讓 Codex 幫忙跑一輪自動修 Bug 的任務。以前要手動進 Codex 介面發指令、等它跑完、再手動確認結果。現在可以設定一個 Hook：在 Codex 開始每個任務之前，自動注入我們公司的程式碼風格規範檔；任務結束後，再自動把 Codex 的修改結果推送到特定的 GitHub 分支，並觸發通知給審核人。整個流程從「每次手動操作 5 步驟」變成「觸發一次、全自動完成」，不需要工程師在旁邊盯著。
Raindrop Workshop 是一個專門針對 Claude Code（Anthropic 公司出品的 AI 程式設計助理，能幫工程師自動寫程式、修 bug）的開發者工具，讓它具備讀取追蹤日誌（trace，就是程式執行時每個步驟的詳細操作紀錄）、自動撰寫評測腳本（eval，用來驗證程式是否正確運作的自動化測試）、並在發現問題後直接修復的能力。它提供即時串流的追蹤日誌、與 coding agent（能自動寫程式的 AI 助手）深度整合、自我修復的評測迴圈，以及本地重播功能，讓你無需聯網就能重現問題場景。支援 TypeScript、Python、Go、Rust 等主流程式語言，也與市面上大多數 SDK（軟體開發套件，也就是各種開發工具包）、AI 服務供應商及 coding agent 相容，不需要大幅改動現有開發環境。
我在開發一個用 Claude Code 自動整理程式碼的工作流程，某個步驟一直輸出錯誤的結果，但不知道問題出在哪個環節。有了 Raindrop Workshop，我可以直接查看 Claude Code 執行過程中留下的追蹤日誌，精確定位到哪個步驟產生了錯誤；Workshop 接著自動針對這個錯誤撰寫評測腳本，確認問題確實存在，再驅動 Claude Code 修復它，修好之後再自動跑一次評測確認通過。整個「發現問題 → 撰寫測試 → 修復 → 驗證」的迴圈全部自動化完成。相較之下，舊做法是手動插入 print 語句慢慢猜測問題所在，耗時且容易漏掉深層錯誤。
Genkit 是 Google 推出的一個程式框架（可以理解成一套幫開發者搭建 AI 應用的鋼筋架構），支援 TypeScript、Go、Dart 和 Python 等多種語言，用來打造各平台上具備 AI 能力的應用程式。這次新推出的「中介層」（Middleware，就像在 AI 運作流程中間加一道過濾關卡）系統，讓開發者可以在 AI 每次產出回應的過程中插入自訂邏輯，例如：網路失敗時自動重試、切換備用模型以確保穩定性，或在 AI 要執行刪除、付款等高風險操作前先暫停、等待人工確認。這些中介層是「可組合」的（composable，意思是像積木一樣自由拼湊），不同功能的關卡可以依需求串接在一起，不用每個地方都重複寫一遍保護邏輯。另外，Genkit 也提供開發者工具介面，讓工程師可以即時觀察、測試和除錯整個 AI 應用及每個中介層的執行情況。
假設我在開發一個 AI 客服機器人，當使用者要求退款，AI 需要呼叫「退款工具」（Tool Call，AI 呼叫外部系統執行真實操作的機制）來實際完成退款。在沒有 Middleware 之前，AI 一做出決策就直接執行，沒有人工把關，一旦 AI 判斷失誤或被誘導，可能產生錯誤退款。加入 Genkit Middleware 後，我只需設定一條規則：「AI 呼叫退款工具之前，先發審核通知給客服人員」。整個流程就變成：AI 提出退款建議 → Middleware 攔截請求並通知客服 → 客服按確認後才真正執行 → 若執行途中網路中斷，Middleware 自動重試三次再報錯。與舊做法相比，開發者不需要在每個 AI 呼叫點手動加保護邏輯，整個應用的安全關卡統一在 Middleware 層管理，維護起來更清晰也不易漏掉。
Hugging Face（一個廣受 AI 開發者歡迎的工具平台）發表技術文章，介紹如何透過「非同步批次處理」讓 AI 模型在推理（就是 AI 根據輸入產生回應的過程）時更有效率地使用硬體。傳統做法是 GPU（專門做大量平行計算的圖形處理器，被廣泛用於跑 AI 模型）每完成一批計算後，才由 CPU（電腦的主處理器）開始準備下一批資料，兩者輪流工作，中間有段空閒。新做法利用 CUDA streams（NVIDIA 提供的一種讓 GPU 能「同時做多件事」的技術機制），讓 CPU 在 GPU 還在跑第 N 批的時候，就提前準備好第 N+1 批，兩者的工作時間重疊，空閒間隔消失，GPU 利用率可提升約 22%。最重要的是，這個優化完全不需要修改任何 AI 模型的參數或底層 kernel（GPU 的計算程式），屬於純工程層面的加速，可以直接套用在現有模型上。
假設一家公司在自己的伺服器上部署了 LLaMA（Meta 發布的開源大型語言模型（就是 ChatGPT 這類會對話的 AI））提供問答服務，目前每秒能回答 100 個使用者請求，但 GPU 有大量時間閒置在等 CPU 整理下一批問題。套用非同步批次技術後，CPU 整理下一批問題的工作和 GPU 計算回答同步並行，不再互等，GPU 實際使用率提升約 22%。同樣的硬體成本下，每秒可處理更多請求；或是維持相同請求量但可以用更少 GPU 伺服器來完成，直接降低推理服務的硬體費用——而且這一切完全不需要重新訓練或修改模型本身。
OpenSquilla 是一個剛發布的開源 AI 代理執行框架（「AI 代理框架」就是讓 AI 能自動執行一連串任務的程式基礎平台，類似讓 AI 可以自己做事、而不只是回答一個問題）。它主打大幅降低使用 AI 時的 token（AI 計費單位，就像手機簡訊按字數計費，token 越多費用越高）消耗。框架內建一個機器學習分類器（能自動判斷任務難易度的小程式），把簡單問題導向便宜的輕量模型，只有複雜問題才交給昂貴的大模型，避免大材小用。同時，它設計了四層記憶系統（仿照人類記憶分短期、長期、知識庫等層次），讓跨對話的資訊可以高效重用——實測顯示，約 80% 的輸入 token 可直接從快取（預先存好的運算結果）提取，三個實際查詢合計只花了不到一美分，官方聲稱整體可節省 60～80% 的 token 費用。
假設我正在開發一個自動回答客戶問題的 AI 客服 Agent（自動化 AI 助理），每天處理數百個查詢，大多數是「退貨流程是什麼？」這類簡單問題，偶爾才有「幫我分析這份合約的法律風險」這類複雜任務。傳統做法是每個問題都丟給最強的大模型（例如 GPT-4o），不管難易，API 費用快速累積。換用 OpenSquilla 後，它的分類器自動把簡單查詢路由到便宜的輕量模型（例如 GPT-4o-mini），複雜問題才升級；加上記憶快取機制，重複性高的問題直接用已算好的結果回答，不重新呼叫 API。以官方實測數字推算，原本一個月 $100 的 API 費用，可能降至 $20～$40。此外，安全隔離機制採用作業系統層級沙箱（限制程式能做什麼的保護機制），無需額外安裝 Docker（常見的程式隔離工具），對小團隊自架部署相對友善。
SAP（全球最大的企業資源管理軟體公司之一，許多大型企業用它來管理財務、供應鏈、人事）在 2026 年更新了 API（應用程式介面，就是讓不同軟體互相溝通的管道）政策，明確禁止外部 AI Agent（AI 代理程式，指能自動執行任務、自動查資料的 AI 程式）直接存取公司系統裡的資料。想用 AI 幫忙處理 SAP 資料，現在只能透過 SAP 自家的 AI 助理「Joule」。這個策略和 Salesforce（全球最大的客戶關係管理軟體）、ServiceNow（企業自動化流程平台）的方向完全相反——後兩者採用開放架構，允許任何外部 AI 直接透過 API 取用資料。目前只有 3% 的 SAP 客戶真正在生產環境（正式上線、非測試）中使用 Joule，代表這個自家工具還不夠成熟，卻已經成為唯一合法入口。
假設一家製造業公司的 IT 團隊，想把 Claude 或 GPT-4 等外部 AI 串接進 SAP 的訂單系統，讓 AI 自動讀取每日出貨量、生成庫存報告、甚至直接回應業務人員的查詢。在 Salesforce 的環境裡，工程師直接呼叫開放 API，外部 AI Agent 就能取得資料、完成任務，幾天內可以上線。但在 SAP 的新政策下，這條路被封死——外部 AI 沒有權限直接接觸 SAP 資料，所有操作都必須走 Joule。問題是 Joule 功能尚未成熟、只有 3% 客戶在用，公司要嘛等 SAP 的工具追上來（時程不明），要嘛被迫只用 Joule（功能受限），沒辦法自由選擇市面上最好的 AI 工具——這就是所謂的「供應商鎖定」風險。
AI 程式碼工具（就像 GitHub Copilot 這類能幫工程師自動產生程式碼的 AI 助理）正在改變軟體工程師的日常工作方式。一份最新報告調查了多位工程主管，發現有高達 81% 的人表示，AI 幫他們省下來的時間，大部分都花回去在「審查 AI 寫的程式碼」上了。這種現象被稱為「隱形工作量」——因為傳統衡量工程師生產力的指標（例如：完成了幾個功能、提交了多少程式碼），根本量不到「花時間確認 AI 輸出有沒有問題」這件事。換句話說，工程師的角色正從「親手寫程式的人」逐漸轉變為「管理和把關 AI 輸出結果的審核者」，但這個新角色的付出在現有的績效衡量體系中完全看不見。
假設一個工程師要做一個用戶資料編輯頁面，以前他要自己從頭寫所有程式碼，大概花 4 小時。現在他用 AI 工具描述需求，AI 15 分鐘內就交出完整程式碼。但接下來他要逐行檢查 AI 輸出：確認沒有資安漏洞（AI 有時會套用已知不安全的舊寫法）、確認邏輯符合公司現有系統的規範、測試在各種異常情況下程式不會出錯。這些審查工作加起來可能要 2 小時。表面上「4 小時的工作縮短到 2.5 小時」，但主管的績效報表只記錄「功能完成了」，不記錄「花多少時間確保 AI 沒有犯錯」。和舊做法相比，差異就在：以前工程師少寫了 3.5 小時的程式碼，卻多了 2 小時幾乎無法量化的審查工作，整體省下的時間遠比帳面上看起來少得多。
過去，一個軟體能長期留住客戶，靠的是「介面習慣」——員工天天用同一套系統，手指都記住了在哪裡點，要換軟體就得全部重新學，這叫做「肌肉記憶護城河」。但隨著 AI 代理（agent，一種能自動幫你操作各種軟體、完成複雜任務的 AI 程式）普及，這種優勢正快速消失：AI 代理根本不需要看介面、不需要動滑鼠，它直接透過後端 API（軟體與軟體之間的溝通管道）存取資料、完成操作，使「員工已經用習慣的介面」這項護城河瞬間失效。全球知名科技創投公司 a16z（Andreessen Horowitz）在這篇分析中指出，軟體業的防禦優勢正轉移到三個新方向：一是難以複製的專有資料（尤其是記錄 AI 執行行為、流程結果的行為資料）；二是深嵌業務流程的隱性規則與例外邏輯（例如「超過百萬的合約必須副總裁審批」這種只有內部人才知道的知識）；三是能把「AI 決策→實際執行→回饋改進」全部串在一起的閉環系統（closed-loop execution），讓每次任務執行都能讓系統變得更聰明。此外，新一代軟體的資料模型也需要重新設計，從過去支援報表、儀表板的結構，轉向能捕捉 AI 推理過程、意圖、狀態追蹤與異常處理的結構。
假設你在一家中型物流公司，現有三套系統（倉庫管理、車隊排班、客戶訂單）各自有獨立介面，員工每天在三個視窗間來回切換，「大家都用習慣了」讓這三套軟體很難被汰換。但一旦你導入 AI 代理，代理直接透過 API 同時讀取三套系統的資料，完全不需要人工切換介面——原本「員工用慣了」的護城河瞬間消失，三套系統都可能被更好的工具取代。反過來說，如果你的公司自己建立了一套 AI 代理系統，它不只能讀取資料，還「記住」了幾十條公司特有規則（例如「每逢颱風季某些路線要改道」），並且每次執行完任務都把結果自動回饋進去持續優化——這個「懂你公司獨特邏輯、邊跑邊學的閉環系統」，才是其他廠商沒有你的資料與規則就根本無法複製的新護城河。
微軟把 xAI（馬斯克創辦的 AI 公司）開發的 Grok 4.3 語言模型（一個能對話、推理、執行複雜任務的大型 AI）整合進了 Azure AI Foundry 平台（微軟提供給企業的 AI 開發工具集，讓企業可以在微軟的基礎架構上部署各種 AI 模型）。這個整合讓企業不需要自己架設伺服器或另外接第三方服務，就能直接在熟悉的微軟環境中使用 Grok 4.3。Grok 4.3 特別擅長「長文脈絡處理」（Long-context，就是一次可以讀很長的文件、不會遺忘前面講的內容）以及需要多步驟推理的任務。透過 Foundry，企業開發者可以把 Grok 4.3 部署到「自動化代理工作流程」（Agentic Workflow，讓 AI 自己規劃並執行一連串步驟，不需要人每次下指令）中，適合文件分析、合約審查、程式碼生成等場景。
假設我是一家法律事務所，每天需要處理幾十份合約，找出風險條款並生成摘要報告。過去的做法是請助理一份份閱讀、標記，再交給資深律師複審，一份合約要花 2 小時左右。現在可以在 Microsoft Foundry 上建立一個 Grok 4.3 自動化工作流程：第一步讓它讀取整份合約（幾萬字的長文件都沒問題），第二步自動識別違約賠償、管轄法院等風險條款，第三步產出結構化摘要並標注需要人工審核的段落。整個流程 5 分鐘跑完初稿，律師只需花 20 分鐘做最終確認，省下大量重複性閱讀工時。
Notion（一款廣受企業和個人使用的協作筆記與知識管理工具）正式推出全新開發者平台，讓它從「記筆記的地方」轉型為企業 AI agent（就是能自動執行任務的 AI 程式）的協調中心。新平台有三大核心功能：第一是「Notion Workers」，開發者可以把自己寫的程式碼部署到 Notion 的雲端沙箱環境，透過 webhook（就是外部事件觸發器）自動啟動工作流程；第二是「資料庫同步」，可把 Salesforce（業務管理系統）、Zendesk（客服系統）、Postgres（資料庫）等外部工具的資料自動拉進 Notion，讓 AI 在 Notion 裡直接操作這些資料；第三是「外部 AI agent 整合」，支援 Claude Code、Cursor、Codex 等 AI 開發工具直接與 Notion 溝通，讓這些工具能讀寫 Notion 的資料並觸發工作流程。整個平台採用 MCP（Model Context Protocol，就是讓不同 AI 工具能互相溝通的業界標準協定），確保越來越多 AI 工具能無縫接入 Notion。Notion CEO Ivan Zhao 表示，過去 Notion 並不以開發者友善著稱，但這次的平台轉型正在改變這件事——自今年二月推出自訂 agent 功能以來，用戶已建立超過 100 萬個 agent，顯示市場需求旺盛。
我是一個小型電商團隊的運營主管，需要追蹤客服工單狀況。舊做法：每天要手動從 Zendesk 把未解決的高優先工單截圖或複製貼到 Notion 的追蹤表格裡，再更新狀態、通知負責人，費時又容易出錯。用新的 Notion 開發者平台：首先設定「資料庫同步」，讓 Zendesk 所有高優先工單自動同步進 Notion；接著部署一個 AI agent，每天自動掃描這些工單、分類並在 Slack 通知對應負責人；再用 Notion Workers 寫一段程式邏輯：若某工單超過 48 小時未回覆，自動把案件升級標記並寄信給主管。整個流程從手動變成全自動，主管只需要在 Notion 裡看最終結果，不必在 Zendesk、Notion、Slack 三個工具間來回切換——這正是 Notion 從筆記工具變成 agent 協調平台的具體展現。
Anthropic（開發 Claude 這款 AI 的公司）宣布從 2026 年 6 月 15 日起，改變旗下 Claude 代理（agent，就是能自動執行多步驟任務的 AI 程式）的收費方式。過去，開發者用一個訂閱費就能同時跑聊天對話和自動化代理任務；新制下，兩者分開計算，程式化的自動代理任務會另外按「月度積分」扣費，換算成 API（讓程式呼叫 AI 的介面）費率計算。Pro 訂閱每月多 $20 積分，Max 方案依等級最高 $200，但積分無法跨團隊共享。業內人士指出，這些積分「可能撐不過一天的認真工作」，代表開發者必須像管理雲端服務（AWS、GCP 等）一樣設預算、追蹤每個 AI 任務的費用，否則代理程式跑起來可能很快燒完額度。分析師預估，這是未來 1–2 年內 AI 廠商普遍轉向的定價趨勢。
假設你用 Claude Agent SDK（讓程式自動呼叫 AI 的工具）寫了一個每天自動整理報表、寄信、回覆客服的後台機器人。以前這些任務跟你自己跟 Claude 聊天共用同一個訂閱額度，費用感覺不明顯。新制上路後，這個機器人跑的每一步 AI 呼叫都獨立從「代理積分」扣，$20 的積分可能只夠跑幾個小時的密集任務。舊做法是「月繳固定費就好」；新做法變成必須追蹤每個工作流消耗多少 token（AI 處理文字的計量單位），設定使用上限，超過就停下來。這更像在管 AWS 帳單，而不是訂閱 SaaS（即月繳固定費的軟體服務）。
`/goal` 是一種新的斜線指令（就是在 AI 聊天框輸入 `/goal` 開頭的命令），讓 AI 程式助理（能自動幫你寫程式的 AI 工具）明確知道「任務算完成」的標準是什麼。以往使用 AI 寫程式，通常要一步一步下指令：「幫我加登入按鈕」→ 確認 → 「再加驗證邏輯」→ 確認 → 「再連資料庫」，每完成一步都要人工確認再繼續，等於你要一直盯著 AI 工作。有了 `/goal`，你只需要一開始寫清楚「最終結果長什麼樣」，AI 就會自行規劃和執行所有步驟，直到真正達成那個狀態才停下來，不需要你在旁邊每步監督。這個功能最早出現在 OpenAI 的 Codex CLI（讓 AI 在終端機命令列環境中自動寫程式的工具）幾週前，而 Claude Code（Anthropic 公司推出的 AI 程式助理）本週也正式跟進加入。
假設你要在網站加入「使用者可以上傳個人頭貼」的功能。用舊方式，你要逐步對 AI 下指令：「幫我在頁面加一個選圖按鈕」→ 等回應 → 「現在幫我處理後端儲存邏輯」→ 等回應 → 「再加圖片格式驗證，只能 JPG 和 PNG」→ 如此來回十幾輪，全程都要你守著。用 `/goal` 的話，你一開始輸入：`/goal 完成頭貼上傳功能：前端有選圖按鈕、後端接收並儲存圖片、大小限制 5MB、只接受 JPG 和 PNG、並且單元測試全部通過`，然後就可以去做別的事情。Claude Code 或 Codex CLI 會自行把這個目標拆成子任務、逐一實作，等你回來時整個功能已經完成並測試通過——差別在於，你不用全程盯著，只需要定義好終點。
資安研究人員宣稱找到了繞過蘋果（Apple）系統安全防護的方法，而這個突破源自一個意外——他們在測試 Anthropic（AI 公司，也就是 Claude 的開發商）一款名為 Mythos 的早期 AI 模型時，發現了一套可應用在真實攻擊上的技術思路。他們的攻擊手法屬於「特權提升漏洞利用」（就是讓一個原本只有有限權限的程式，偷偷取得更高層級的系統控制權），把兩個程式錯誤（bug）串在一起，再加上幾種輔助手法，就能在未經授權的情況下侵入 Apple 系統。值得注意的是，整個攻擊仍需要人類資安專家親自操作，Mythos 模型本身無法獨立完成；目前 Apple 已收到報告正在審查中，研究人員會等 Apple 釋出修補程式後，才公開完整的攻擊技術細節。
假設我是一位資安研究員，在測試 Anthropic Mythos AI 模型的過程中，注意到某些操作手法讓模型出現特殊反應。我把這個靈感帶到 Apple 系統上，找到兩個既有的程式漏洞，像拼湊兩把不完整的鑰匙一樣把它們串起來，再配合幾個額外步驟，最終讓攻擊者能在不被系統察覺的情況下，進入原本嚴格保護的系統區域。和傳統漏洞研究相比，最大差異在於：研究者是在「使用 AI 模型」的過程中被啟發，顯示 AI 系統的測試與研究本身，也可能成為發現安全漏洞的新路徑——這對 AI 安全研究領域來說是一個值得關注的訊號。
DwarfStar 4（簡稱 DS4）是由 Redis（一個廣泛使用的高速記憶體資料庫）的創作者 antirez 開發的個人本地 AI 推理專案。「本地推理」的意思是讓 AI 大型語言模型（LLM，就是 ChatGPT 這類會對話的 AI）完全在自己的電腦或伺服器上運作，不需要連接雲端、不需要付費給 OpenAI 或 Anthropic。DS4 目前使用 DeepSeek v4 Flash 模型（來自中國 DeepSeek 公司的高性能開源 AI）作為核心，並採用非對稱量化技術（2/8 位元混合壓縮，一種讓大模型「體積變小但品質不差太多」的壓縮方法），讓配備 96～128GB RAM（記憶體）的機器就能跑起來。antirez 表示這是他第一次覺得本地 AI 達到可用於真實工作任務的水準。未來 DS4 計畫加入編碼代理（coding agent，讓 AI 自動幫你寫程式、跑測試）、分散式推理（把運算分散到多台機器上同時進行）、以及針對法律、醫療等領域的專用模型版本。
假設你是一個開發者，想在公司內部搭建一套私有 AI 助手，不希望程式碼或機密資料上傳到雲端。過去要跑 DeepSeek v4 Flash 這種百億參數等級的模型，可能需要數張 A100 GPU（一張動輒數十萬台幣）才能帶動。DS4 的做法是透過非對稱量化技術把模型大幅壓縮，讓一台配備 96GB RAM 的一般工作站伺服器就能承擔運算。你把 DS4 裝好後，就能在本機問它「幫我查這段程式碼有什麼 bug」或「解釋這個 API 的用途」，模型在你自己的機器上直接回答，資料完全不離開公司網路。對比舊做法——要麼用雲端 API（有資料隱私疑慮，且長期費用高），要麼根本跑不動（硬體門檻太高）——DS4 的方案大幅降低了本地部署 AI 的硬體要求。
這篇文章是一份針對產品經理（PM，就是負責決定產品方向、協調開發團隊的人）的實用指南，說明 Anthropic（Claude 的開發公司）旗下三種工具的用途差異：Claude Chat（就是一般的對話視窗）、Claude Cowork（可以接外部工具、跨裝置使用的升級版工作環境）、Claude Code（用來處理複雜多檔案任務、能自動化品質檢查的程式碼工作環境）。傳統 AI 對話（Chat）的問題是沒有記憶、不能存取本地檔案、換裝置就斷線，導致每次都要從頭提問。Cowork 和 Code 的出現，讓 AI 可以接上你的 Gmail、Slack、雲端硬碟，並在多裝置之間保持連貫。文章建議 PM 只把 5% 的時間用在 Chat，把 25% 移到 Cowork，其餘工作交給 Code 與 Dispatch 處理。
假設我是一位 PM，每週要整理一份「客戶未回信清單」報告。舊做法：手動進 Gmail、一封封找、複製到試算表、整理分類，可能要花半小時。用 Claude Cowork + Gmail MCP（一種讓 AI 直接存取 Gmail 的連接器）的做法是：在 Cowork 輸入一句「統計未回覆郵件並按類別計數」，AI 自動登入 Gmail、掃描信箱、分類統計，幾秒內輸出報表。而且 Cowork 還設定成「草稿模式」，AI 不會直接寄信，而是先幫你擬好草稿讓你確認，久而久之它會學到你的寫信風格。這比每次打開 Chat 重新說明背景快多了，因為 Cowork 保有你的工作系統設定，不需每次從頭解釋你是誰、工作目標是什麼。
AI 程式設計助手（就是像 GitHub Copilot、Cursor 這類，能在你打程式碼時自動補全、建議程式碼的 AI 工具）近年來愈來愈普及，許多工程師表示個人寫程式的效率大幅提升。然而，研究與實際案例卻顯示：整個開發團隊的「交付速度」並沒有跟著提升——有些公司甚至反而更慢了。原因是「寫程式碼」只是整個軟體開發流程的冰山一角，一個功能從想法到上線，還需要產品經理（負責定義要做什麼）、設計師（負責介面長什麼樣）、QA 測試人員（負責確認有沒有 bug）、技術文件人員（負責撰寫說明書），以及資安審查員等多種角色，而這些人目前幾乎沒有 AI 工具可用。這篇系列文章提出，下一步的突破不是讓 AI「寫出更好的程式碼」，而是要實現「生命週期編排（lifecycle orchestration，意指讓 AI 跨越所有開發環節、幫整個團隊協作）」——讓 AI 從需求定義、設計、開發、測試到部署，每個環節都能協助加速，不再只聚焦在工程師那一段。唯有如此，企業才能真正從 AI 投入中獲得整體效益，而不是讓效率提升只停留在少數人身上。
假設一家公司要推出一個新的「用戶回饋收集功能」。現有做法：工程師有了 AI 助手後，原本要花兩週寫完的程式碼，現在一週就完成了。但問題是：產品經理還是花了一週才整理好需求文件，設計師再花五天出稿，QA 測試又花三天，加上資安審查等一週——整個功能前後還是用了近兩個月才上線，工程師節省的那一週根本微不足道。若改用「生命週期編排」的 AI 整合方式：AI 先協助產品經理快速整理用戶訪談、自動生成需求草稿；AI 幫設計師提供初版介面建議；AI 在開發同步自動產出測試腳本讓 QA 直接執行；AI 協助資安人員掃描常見漏洞——整個流程的每個卡點都縮短，功能可能三週就上線，而不是兩個月。舊方法是「AI 只幫一個人快」；新方向是「AI 讓整個流水線都快」。
AI 推論效率比（Inference Efficiency Ratio，簡稱 IER，就是衡量「每花一塊錢呼叫 AI 模型能賺回多少收入」的指標）是專為使用 AI 技術的軟體公司設計的成本效益計算方式。公式非常直觀：AI 產品營收 ÷ 推論成本（就是呼叫 ChatGPT、Claude、Gemini 等 AI 模型的費用）。傳統的軟體公司財務指標（例如毛利率）反應太慢，等到數字變難看時成本往往已失控；IER 能讓你更早發現 AI 功能的成本效率問題。若 AI 是整個產品的核心，IER 至少要達到 4:1；若 AI 只是產品的附加功能，則 8:1 以上才算健康。
假設一家叫 Acme SaaS 的公司，每月從 AI 功能賺到 41.7 萬美元，但呼叫 AI 模型的推論費用花了 9.5 萬美元，算出 IER = 4.4:1，落在警戒區間。財務長介入後導入三項技術優化：一是「模型路由」（根據問題難易自動選便宜或昂貴的 AI 模型，簡單問題給小模型，複雜問題才用大模型）；二是「提示詞快取」（讓 AI 記住剛才的回答脈絡，不用每次都重新計算）；三是按使用量分層定價（讓重度使用者多付費）。優化後推論成本降至 5.2 萬美元，IER 升到 8.0:1 進入健康範圍——同樣的收入只花了原本 55% 的 AI 費用。
OpenAI Symphony 是一個開源工具，核心功能是把開發團隊常用的任務看板（如 Jira、Linear、Trello，就是工程師追蹤「待辦事項清單」的軟體）直接變成控制 AI 代理（就是能自動執行程式任務的 AI 機器人）的指揮中心。過去，工程師要完成一個功能，需要手動一步一步告訴 AI 要做什麼，AI 回覆後再自己整合程式碼；而 Symphony 的概念是：工程師只需在任務板上開一張票（寫清楚要做什麼），AI 代理就會自動認領、在隔離的工作環境裡執行、程式碼測試失敗時自動修正，最後把寫好的程式碼送交人工審查。這個框架是用 Elixir 語言開發的開源專案（採 Apache 2.0 授權，代表任何人都能免費使用和改造），背後的思維轉變是：從「人類主動提示 AI 一個一個做事」，轉向「人類管理任務清單、AI 自動批量執行」。
假設一個 10 人小型開發團隊的 Jira（任務追蹤工具）上堆著 200 張待處理的功能票（任務）。舊做法是：每張票都要工程師親自打開 AI 聊天視窗、描述問題上下文、等 AI 回答、再複製貼上程式碼到專案裡測試，一次只能處理一張，費時費力。用 Symphony 之後，PM（產品經理）先把 40 張票的驗收標準和測試規格寫清楚，Symphony 就自動同時把這 40 張票派給 40 個 AI 代理並行處理——每個代理在獨立沙箱（就是完全隔離的測試環境，不影響主程式碼）中執行，遇到 CI 失敗（就是自動測試沒過）時，AI 自己偵測錯誤、修正後重試，最後把 40 份可供審查的 PR（程式碼修改提案，等待人工 approve 才能合入）同時送到工程師面前。工程師的角色從「手把手帶 AI 做任務」變成「審核 AI 批量產出的成果」，等於一個人同時監管幾十個 AI 工程師並行作業。
軟體工程師 James Pain 在 2026 年 5 月發表了一篇引發廣泛迴響的文章，坦承在幾乎完全依賴 AI（就是 ChatGPT、Claude 這類能自動幫你寫程式的人工智慧工具）輔助開發 1-2 年後，發現自己「幾乎忘了怎麼自己寫程式」，並開始重新從頭自學手寫程式。他同時指出，AI 產出的文字和程式碼「根本不像他自己的風格」，表面上看起來很流暢，實際上卻失去了個人聲音與思考痕跡。這篇文章在 Hacker News 和 Bluesky 社群引發了兩極反應：一方認為技能退化是開發者自己選擇不精進的結果，不是 AI 的錯；另一方則指出，當 AI 被當成「學習工具」而非「程式碼代勞機器」時，反而能讓學習速度呈指數成長。有 32 年資歷的資深工程師也特別提醒，成功的 AI 輔助工作流程需要嚴謹的文件撰寫與審查步驟，而不是直接採用 AI 輸出的「vibe coding（就是不加審查、憑感覺對就直接部署 AI 產出的程式碼）」方式。
假設你是一位剛入行兩年的開發者，平常都用 GitHub Copilot 或 Claude 來生成程式碼，效率很高、產出也不錯。但一年後，主管叫你獨自排查一個中等難度的系統 bug，你發現自己連基本的除錯思路都理不清——因為過去每次都是讓 AI 直接給答案，你幾乎沒有真正「思考過」解法。相比之下，若你改變做法：遇到問題時先用 AI 幫你搜尋背景知識、列出可能方向，但自己動手寫關鍵邏輯、一行一行讀懂 AI 產出的程式碼、定期做不依賴 AI 的手寫練習，一年後你的理解力和技能仍持續成長。差異在於：前者的工程技能在不知不覺中空洞化，後者則把 AI 當成加速器而非替代品，能力反而更強。
這篇文章整理自投資人 David Friedberg（他是 All-In 播客的共同主持人，長期投資能源、生技、太空等領域）在 Modern Wisdom 播客的訪談觀點。他認為，人類對 AI（人工智慧）的恐懼，其實重複了幾千年來一個固定的模式：每個世代都覺得自己正活在末日前夕，無論是鳥糞肥料快用完引發的糧食危機，還是今天的 AI 取代工作恐慌。Friedberg 特別提到幾個正在發生的技術發展：第一，大型語言模型（就是 ChatGPT 這類能對話的 AI）現在已經可以直接跑在家用電腦上，不再需要依賴 Google 或 OpenAI 等大公司的雲端伺服器；第二，AI 推理成本（讓 AI 算出一個答案所花的費用）每年以千倍幅度下降；第三，AI 正在幫助科學家解決困擾核融合研究長達七十年的技術難題。整體而言，他相信技術最終一定會從少數人手中擴散到所有人，這個規律在網路時代、CAR-T 癌症療法（一種改造人體免疫細胞來攻擊癌細胞的療法，成本從百萬美元降至五千美元）上都已應驗，AI 也不會例外。
核融合（模仿太陽發光方式來產生能量的技術）是人類追求乾淨能源的終極夢想，理論上一座游泳池大小的海水就能供應全球一整年電力，且不會產生溫室氣體或大量放射性廢料。但實作上有個卡了七十年的死結：要讓核融合反應持續，必須把攝氏一億度的高溫電漿（一種帶電氣體）用磁場限制住。問題在於，電漿裡的質子天生互相排斥，一旦受到擠壓，就會產生自己的磁場來對抗外部磁場，導致電漿在幾毫秒內崩潰，實驗只能重來。現在，研究人員讓 AI 學習如何即時調整磁場的控制策略，讓電漿不會崩潰。效果是：中國的核融合實驗裝置最近已能把高溫電漿穩定維持將近十八分鐘，而幾年前能撐幾十秒就算突破。換句話說，一個從 1950 年代就讓科學家頭痛的技術死結，正因為 AI 介入而快速被解開。相比過去科學家純靠人力調整參數，AI 能在實驗過程中即時學習並動態修正磁場控制策略，這正是過去做不到的事。
Dun & Bradstreet 調查了多家大型企業的 AI 布局，得出一個反差強烈的結果：幾乎所有企業（97%）都說正在積極投入 AI，但只有 5% 的企業說自家的資料（data，也就是公司各系統裡累積的客戶、交易、產品等各種記錄）已經準備好、可以支撐 AI 大規模運作。換句話說，大多數企業都在「先買了 AI 工具，但燃料（資料）根本還沒準備好」的狀態。資料不就緒的具體問題包括：50% 的企業說資料取用困難（各部門的資料彼此隔離）、44% 擔心隱私與法規合規問題、40% 有資料品質問題（數字錯誤、格式不一致）、38% 的系統無法互通。報告指出，AI 規模化的瓶頸已經從「找到好模型（就是 ChatGPT 這種 AI 的核心演算法）」轉移到「整理乾淨、可管理的資料」——這個問題不解決，再好的 AI 也無用武之地。
假設你是一家中型企業的業務主管，想讓 AI 幫你分析哪些潛在客戶最有可能成交。舊做法是：直接找 AI 廠商買工具，把 CRM（客戶關係管理系統，就是公司用來記錄業務往來的軟體）的資料丟進去跑預測。但你發現 AI 給的結果亂七八糟——原來 CRM 裡有一半客戶電話格式不同、公司名稱重複登錄了三版、而且採購部門的購買記錄還鎖在另一個系統裡根本匯不進來。報告建議的做法是：先做資料治理（把各系統的欄位格式統一、去掉重複資料、設定誰有權取用哪些資料），再從「業務智能」這種資料環境相對成熟的場景開始試，採人工監督加 AI 建議的混合模式，而非直接讓 AI 全自動決策。兩種做法的差距在於：前者讓 AI 說廢話，後者讓 AI 真正能用。
這篇文章指出，當企業開始推動 AI 計畫（就是把 AI 人工智慧技術導入公司內部流程或產品）時，負責推動的 PM（產品經理，負責決定要做什麼功能、協調工程師與業務部門的職位）往往會發現，原本熟悉的那套工作方法突然失靈。一般產品開發有清楚的需求、固定的時程、可量化的目標，但 AI 計畫一啟動，就容易暴露出組織裡原本隱藏的問題：部門之間的工作流程其實一團混亂、沒人確實負責某個環節、整個公司缺乏有效的決策與管理規則。面對這種狀況，表現最好的 PM 不會試圖一開始就把所有事情定清楚，而是選擇從範圍很窄、風險很低的小型試驗開始做，快速從中學習，等到某一個小流程被驗證可以穩定重複執行之後，才逐步加入更多規範與結構。這種「先動再系統化」的務實做法，比起要求一開始就完美，更能讓 AI 計畫真正推進。
假設一間保險公司的 PM 想要導入 AI 自動審核理賠申請。傳統做法會先花三個月寫完整需求規格、定義所有例外狀況處理流程、要求 IT 建好完整的資料存取權限，然後才開始開發。但按照這篇文章的建議，正確的做法是：先只挑最單純的那種理賠申請——例如金額在五千元以下、文件齊全的住院收據——讓 AI 只審這一類，其他全部由人工處理。跑兩週後，觀察 AI 的準確率、哪些流程沒人知道誰負責核准、哪些資料根本找不到。等這個最窄的試驗跑順了，再擴大到下一類申請。相比直接上線全功能 AI 審核系統（往往因為組織問題而卡住或爆掉），這種方式讓計畫持續有進展，也讓公司邊做邊發現並解決組織上的混亂，而不是在最後關頭才撞牆。