AI 找漏洞的速度，已經比人類修漏洞的速度更快。

HackerOne 三月暫停了 Internet Bug Bounty 計畫。不是因為沒人參加，是因為 AI 輔助的漏洞研究把開源專案的漏洞利用窗口壓縮到維護者根本來不及反應。你的 patch cycle 是兩週，AI 找到新漏洞只需要兩小時。這個速差不是線性的，是指數級的，而且只會繼續拉開。

同一天，Google I/O 2026 開場，預計丟出 Gemini 4。OpenAI 推出 Daybreak 資安平台，用 AI 來找漏洞修漏洞。Kiro Web 版上線讓你在瀏覽器裡跑 coding agent。Windsurf 2.0 把整個 Devin 塞進編輯器。GitHub Copilot 暫停接受新用戶——需求超過了供給。

六條新聞，一個結構性問題：AI 工具的擴張速度，正在系統性地超越安全防線的建設速度。

Google I/O 2026 今天登場：Gemini 4 可能來了

今天早上十點（太平洋時間），Google I/O 2026 keynote 正式開場。距離二月發布 Gemini 3.1 Pro 過了三個月，市場的期待值已經拉到 Gemini 4。

但模型只是冰山一角。更大的動作在生態系層面——Android 17 的核心口號叫「Gemini Intelligence」，意思是 Gemini 不再是手機裡的一個 App，而是整個作業系統的底層引擎。ChromeOS 上的整合也在推進。更激進的是 Aluminium OS，一套基於 Android 的 PC 作業系統，直接跨入桌機戰場。Android XR 眼鏡也會有預覽——Google 想從手機、電腦到穿戴裝置，全部用 Gemini 串起來。

為什麼重要？

Google 正在做的事情，用一句話講就是：把 AI 從「功能」變成「基礎設施」。Gemini 不再是你打開來問問題的東西，它是你的手機、你的電腦、你的眼鏡背後那層你看不見的運算層。

這聽起來很美好。但有一個被低估的風險。

當 AI 從獨立功能變成作業系統的一部分，它的故障模式也跟著改變。一個聊天機器人出錯，你關掉重開就好。一個作業系統底層的 AI 出錯，你的通知排序壞掉、你的搜尋結果歪掉、你的相簿分類亂掉——而你甚至不知道是 AI 的問題，因為它藏在系統裡面。越看不見的東西，出問題越難抓。

原文來源：What to expect from Google I/O 2026 — Android Authority
原文來源：Google debuts Gemini-focused updates at I/O 2026 — Let’s Data Science

Google 想把 AI 塞進所有東西裡。OpenAI 則選了一個更精準的切入點——資安。

OpenAI Daybreak：用 AI 找漏洞，然後用 AI 修漏洞

OpenAI 推出 Daybreak 資安計畫。核心想法很直白：結合 frontier model 的推理能力和 Codex Security 的程式碼分析，幫組織自動發現漏洞並產出修補建議。

更有意思的是 GPT-5.5-Cyber——這是 GPT-5.5 的資安特化版，目前只以限定預覽方式提供給經過審核的資安團隊。「特化」的意思是它在安全相關任務上的限制更寬鬆，可以做一些通用模型被擋住的事情。Palo Alto Networks 的實測結果顯示，GPT-5.5-Cyber 和它們自家的 Mythos 模型在漏洞發現能力上「超出預期」。

為什麼重要？

把這條新聞和最後一條放在一起看，會看到一個很矛盾的局面。

HackerOne 暫停 Bug Bounty 的原因是 AI 找漏洞太快了，開源維護者修不過來。OpenAI 推出 Daybreak 的賣點也是 AI 找漏洞很快。同一個能力，對防守方是工具，對攻擊方也是武器。OpenAI 選擇把 GPT-5.5-Cyber 限定在經審核的資安團隊手上，但模型的能力邊界是很難用行政手段控制的。

逆過來想：怎樣讓 Daybreak 一定失敗？答案是它只負責「找到」而沒人負責「修好」。目前企業資安的瓶頸從來不是「不知道有漏洞」——CVE 資料庫裡躺了幾十萬條，大多數組織的修補率不到三成。找的速度再快，修的速度跟不上，效果就是生產了更多焦慮而不是更多安全。

原文來源：OpenAI launches Daybreak for AI-powered cybersecurity — The Hacker News
原文來源：OpenAI rolls out new GPT-5.5-Cyber to vetted cybersecurity teams — CNBC

大廠在搶 AI 資安市場，coding agent 生態也沒閒著。Amazon 的 Kiro 剛把戰場搬到瀏覽器上。

Kiro Web 版正式上線：瀏覽器裡的 Coding Agent

Kiro 推出 Web 版（app.kiro.dev），Pro、Pro+ 和 Power 用戶可以直接用瀏覽器啟動 agent。不需要裝 VS Code 擴充、不需要跑 CLI、不需要本地環境。打開網頁就能開始。

功能面支援 agent chat（丟想法進去、修 bug、從零到一開 PR），分成 collaborative 和 autonomous 兩種模式。你可以開多 repo session，接上 GitHub issue，所有操作跑在隔離沙箱裡。更重要的是支援 HTTP-based MCP servers，預設就能接 Slack、GitHub、Figma 的 OAuth。

為什麼重要？

Kiro Web 版的意義不在於功能多了什麼，在於門檻少了什麼。

之前要用 coding agent，你得先搞定本地開發環境——Node 版本、Python 虛擬環境、Docker、SSH key。光是 setup 就能卡住一半想試的人。Web 版把這些全省掉了。一個產品經理想讓 AI 幫他開一個簡單的 PR？打開瀏覽器就行。

這同時也意味著 coding agent 的使用者輪廓正在改變。它不再只是工程師的工具。當進入門檻降到「打開網頁」的程度，會有大量非工程背景的人開始操作程式碼庫。這些人不一定看得懂 agent 產出的 diff，不一定知道什麼改動會炸 production。

工具的易用性和使用者的判斷力之間的落差，就是風險住的地方。

原文來源：Kiro updates — ReleaseBot

Kiro 從瀏覽器切入，Windsurf 走了完全相反的路——它把雲端 agent 拉回編輯器裡面。

Windsurf 2.0：把 Devin 直接塞進編輯器

Windsurf 2.0 最大的賣點就一句話：Devin 現在住在你的編輯器裡了。

之前 Devin 是一個獨立的雲端 agent，你在網頁上開任務、等它跑完、看結果。Windsurf 2.0 把這整套搬進了編輯器——你在寫程式的時候，可以一鍵把任務委派到遠端 VM 上跑。新增的 Planning Mode 讓你在啟動長時間任務前先看 agent 打算怎麼做。內建瀏覽器讓 agent 能感知端到端工作流。還多了 EU production cluster 處理合規需求。

為什麼重要？

Coding agent 的架構正在快速收斂成兩種模式：一種是 Kiro 這樣的純雲端（你在瀏覽器裡操作，所有運算在雲上）；一種是 Windsurf 這樣的混合式（你在本地編輯器操作，重活丟到遠端 VM 跑）。

兩種模式解決的核心問題其實一樣：coding agent 需要的運算資源太大，你的筆電跑不動。差別在信任邊界畫在哪裡——Kiro 的模式是「你的程式碼離開你的電腦」；Windsurf 的模式是「你的程式碼還是在你看得到的地方，但執行在別人的機器上」。對企業來說，這個差別很重要。CTO 們現在多了一個需要回答的問題：我的程式碼在誰的機器上跑？

Planning Mode 是一個有意思的功能。讓 agent 先說它要幹嘛，你看了覺得 OK 再放手讓它跑。這本質上是一種「可審計的自主性」——agent 有自主能力，但執行前先讓人類看過計畫。真正的考驗在於：計畫和實際執行之間的偏差有多大？如果 agent 計畫說「我要改三個檔案」，結果改了八個，那 Planning Mode 就只是一個安慰劑。

原文來源：AI Coding Agents Comparison 2026 — Lush Binary

Coding agent 供應商在拼功能、拼架構。但市場領先者 GitHub Copilot 此刻正在做一件完全相反的事——關門。

GitHub Copilot 暫停新用戶註冊：需求大到接不住

GitHub 暫停了 Copilot Pro、Pro+ 和 Student 方案的新用戶註冊。同時收緊現有用戶的使用額度。理由？「保護現有客戶的體驗品質」。

白話翻譯：用量炸了，伺服器撐不住。

另外 5/15 已經棄用 Grok Code Fast 1 模型。CLI 那邊倒是更新很勤，1.0.44 到 1.0.48 連出四版，加了 model picker、/autopilot 指令和 MCP server search。

為什麼重要？

一個軟體產品因為太多人想用而暫停註冊——這在 SaaS 的世界裡幾乎聞所未聞。通常你只會在產品快死的時候看到註冊被關掉，不會在產品最紅的時候。

但這恰好揭示了 AI coding tool 的一個結構性困境：每一次使用都消耗大量運算資源。 傳統 SaaS 產品，一個新用戶上來大概就是多一行資料庫記錄、多幾 KB 的儲存空間。AI coding tool 不一樣——每一次 code completion、每一次 agent 任務，都是在燒 GPU。使用者越多、GPU 燒越多、成本越高、但訂閱費是固定的。

這跟前兩天講的 Anthropic 拿下 SpaceX 22 萬顆 GPU 是同一個故事的不同章節。GPU 供給有限，需求在指數成長。GitHub 選擇關門限流，Anthropic 選擇搶 GPU 開門迎客。兩種策略，同一個瓶頸。

原文來源：Changes to GitHub Copilot plans for individuals — GitHub Blog

GitHub 關門是因為接不住需求。HackerOne 關門則是因為接不住後果。

HackerOne 暫停開源 Bug Bounty：攻擊加速，防守沒跟上

回到開頭的數字。

HackerOne 在三月暫停了 Internet Bug Bounty 計畫。這個計畫從 2013 年跑到現在，獎勵全球的安全研究者幫開源專案找漏洞。十三年了，現在暫停。

原因不是沒有人找漏洞。恰恰相反——AI 輔助漏洞研究讓漏洞被發現的速度暴增，但開源維護者的修補速度沒有跟上。漏洞利用窗口正在縮短。以前一個漏洞從被發現到被利用可能有幾週的緩衝期，現在可能只剩幾天。AI 生成的惡意軟體也開始繞過傳統偵測工具——pattern matching 的偵測方式面對多態變種的惡意軟體，已經開始力不從心。

為什麼重要？

把今天六條新聞全部攤開來看，會看到一個極度不對稱的局面。

攻擊端：AI 找漏洞更快、生成惡意軟體更多態、繞過偵測更容易。防守端：開源維護者還是那幾個人、patch cycle 還是那個速度、偵測工具還在用老方法。OpenAI 推 Daybreak 用 AI 補防守的缺口，但 Daybreak 服務的是有錢買服務的企業，不是開源社群。開源專案的安全依然靠志工撐著，而志工的頻寬不會因為 AI 出現就突然變大。

這才是 HackerOne 暫停 Bug Bounty 的深層意義。它不是一個計畫的結束，是一個訊號——現有的「找漏洞→回報→修補→獎勵」流程假設了防守方能跟上攻擊方的節奏。當這個假設不再成立，整個流程就失效了。

原文來源：2026: Year of AI-assisted attacks — The Hacker News
原文來源：Defender’s guide: Frontier AI impact on cybersecurity — Palo Alto Networks

六條新聞，一個框架。

Google 把 Gemini 塞進作業系統。Kiro 讓你在瀏覽器裡跑 coding agent。Windsurf 把 Devin 拉進編輯器。GitHub Copilot 的使用者多到要關門。每一條都指向同一個方向：AI 工具正在加速滲透到軟體開發的每一個環節。

但同一時間，OpenAI 推出 Daybreak 是因為漏洞太多了需要 AI 幫忙。HackerOne 暫停 Bug Bounty 是因為漏洞被找到的速度超過修補的速度。AI 生成的惡意軟體正在繞過傳統偵測。

工具的擴散速度和安全的建設速度之間，存在一個持續擴大的落差。

這不是「某個產品不安全」的問題。是整個系統的動力學出了問題。AI 讓開發變快，也讓攻擊變快。但防守的速度受限於人——開源維護者的時間、資安團隊的規模、patch review 的流程——這些東西不會因為 AI 的出現就自動加速。

最危險的情境不是「AI 被拿來攻擊」。而是大家都很興奮地在用 AI 寫程式、AI 找漏洞、AI 修漏洞，覺得問題正在被解決——但實際上，整個攻防天平正在悄悄傾斜，而大多數人只看到了天平的其中一端。