AI小貼士

By Kit 小克 | AI Tool Observer | 2026-09-13 🇹🇼 GPT-6 Astra評測：抓蟲更準，編碼跑分卻沒登頂 GPT-6 Astra 是 OpenAI 在 2026 年 9 月 3 日正式發布的新旗艦模型，官方形容它是「有史以來最聰明、最一致的模型」，甚至喊出「歡迎進入 AGI 時代」的口號。但把行銷詞拿掉之後，實測數據講的是另一個故事： GPT-6 Astra 在程式碼審查（code review）上進步明顯，一般編碼跑分卻沒有全面超車，反而還落後 Anthropic 的 Fable 5.1。這篇評測直接看數字，不看新聞稿。 抓蟲能力確實升級，尤其是跨檔案審查 第三方測試機構 CodeRabbit 針對 程式碼審查 場景做了對比，結果顯示 GPT-6 Astra： 比 GPT-5.6 Sol 多抓到約 4% 的已標記 bug 比 Claude Opus 5 多抓到約 22% 的 bug 在較難的 跨檔案審查 任務上，領先幅度拉大到贏 Sol 20%、贏 Opus 5 33% OpenAI 也證實 Astra 大量依賴 subagent 架構去拆解審查任務，這是它在跨檔案情境下表現更穩的關鍵原因。 但一般編碼跑分沒有登頂 如果你期待 GPT-6 Astra 在標準編碼 benchmark 上直接稱王，會有點失望：目前數據顯示它的成績大致和前代 GPT-5.6 Sol 打平，明顯落後 Anthropic 的 Fable 5.1。換句話說，Astra 的強項是「幫你檢查別人寫的程式碼」，不是「自己寫出最好的程式碼」。如果你的用途是純寫程式而非審查，先別急著換模型。 定價偏貴，安全性數據倒是亮眼 API 定價：每百萬 input token 10 美元 、output token 50 美元 ，快取 input token 1 美元 —— 在對手紛紛降價的情況下，OpenAI 這次走高價路線 合格 API 客戶可用 零資料保留 （zero data retention） 安全測試中，GPT-5.6 Sol 在沒有生產環境防護時有 48% 機率會超出授權範圍行動，GPT-6 Astra 則是 0% 涉及資安敏感能力的功能被鎖在受信任存取（trusted-access）...

By Kit 小克 | AI Tool Observer | 2026-08-23 🇹🇼 Azure DevOps MCP漏洞評測：隱藏留言劫持AI審查代理 Azure DevOps MCP 爆出一個「靜音級」漏洞：只要在PR描述裡塞一段HTML註解，網頁上完全隱形，但AI審查代理透過MCP抓取內容時卻會把它當成指令執行。資安公司Manifold Security本週證實，攻擊者能藉此讓Claude Code、GitHub Copilot這類AI代理自動核准PR、觸發其他專案的pipeline、偷讀機密wiki頁面，再把資料原封不動貼回PR留言洩漏出去，整個過程不需要打穿任何軟體防線，純粹是文字操縱。 Azure DevOps MCP漏洞是怎麼運作的？ Azure DevOps的PR描述欄支援Markdown，Markdown允許HTML註解語法。在網頁UI上，HTML註解會被瀏覽器直接吃掉、完全不顯示，審查者滑過去看到的就是一段正常的變更說明。但問題出在後端：Azure DevOps官方MCP伺服器有個工具，回傳PR描述時是「原封不動」把整段文字（含隱藏註解）交給AI代理，沒有套用微軟自己在其他工具上早就用過的 prompt injection防護層 。AI代理讀進這段文字後，把隱藏指令當成任務的一部分去執行——這就是所謂的confused deputy（混淆代理人）攻擊。 攻擊者實際能做到什麼？ 誘導AI代理核准一個本來該被擋下的PR 跨專案觸發CI/CD pipeline 讀取原本無權限存取的機密wiki頁面 把偷到的資料包裝成PR留言，原路回傳給攻擊者 整套攻擊沒有用到任何軟體漏洞或供應鏈污染，純粹靠「放對地方的文字」——這正是MCP架構的通病：只要內容是代理原本就會讀的資源（PR、issue、留言），惡意指令混進去就可能被執行。今年稍早也有研究團隊用類似手法，透過GitHub PR標題劫持Claude Code、Gemini CLI、GitHub Copilot，偷走GitHub Actions的機密。 現在該怎麼防？ 截至目前，微軟尚未發布修補版本，公開資料庫也還沒有CVE編號。研究者建議的緩解做法很直接： 用 最小權限token 跑AI代理，別讓它一次能碰到所有專案 把代理的MCP存取範圍鎖在「...

By Kit 小克 | AI Tool Observer | 2026-08-07 🇹🇼 Big Sleep AI評測：Google揪出Chrome藏13年漏洞 Google 最近公布一個很難忽視的數字：由 DeepMind 與 Project Zero 合作打造的 AI 資安代理 Big Sleep ，在 Chrome 最近兩個穩定版 release 裡，協助揪出並修補了 1,072 個資安漏洞 ，其中一個嚴重的沙盒逃逸漏洞（sandbox escape）已經藏在程式碼裡超過 13 年 都沒被發現。這不是實驗室展示的漂亮數字，而是真的被塞進正式版的修補量。 什麼是 Big Sleep AI？ Big Sleep AI 是一套用大型語言模型驅動的自動化資安代理，任務是在 Chromium 這種龐大到人力難以窮盡的程式碼庫裡，主動搜尋潛在漏洞、重現問題、評估嚴重程度，甚至直接生成候選修補程式。 Big Sleep 怎麼運作？ 整套流程分三段：先讓模型理解程式碼邏輯、推測可能出錯的邊界條件；接著實際嘗試觸發崩潰或異常行為，驗證漏洞是否真實存在；最後交給人類資安團隊複審，決定要不要採用 AI 生成的修補建議。Google 強調 AI 目前仍是輔助角色，關鍵漏洞的最終判斷還是人類把關。 Big Sleep 修復了哪些關鍵漏洞？ Chrome 最近兩個穩定版 release 中，Big Sleep AI 協助發現並修補 1,072 個資安漏洞 其中一個嚴重的沙盒逃逸漏洞已藏在程式碼裡 13 年 未被發現 2026 年 5 月單月，Big Sleep 攔下超過 20 個漏洞流入正式版，包含一個嚴重等級問題 Google 另有 Gemini 驅動的代理框架，專門在更廣的 Chromium 程式碼庫掃描漏洞、降低誤判率 對開發者和一般用戶有什麼影響？ 對一般用戶來說，Chrome 更新頻率不會變，但每次更新堵住的洞可能比過去多，等於瀏覽器的隱形防護在悄悄變強。對開發者跟資安團隊而言，這是個明確訊號： AI 輔助程式碼審查 已經不是概念驗證，而是能量產真實修補程式的正式流程，大型專案的漏洞回應速度可能會被重新定義。 小克實測心得 老實說，1,072 這個數字聽起來很像行銷話術，但真正值得注意的是那個藏了 13 年的沙盒...