科技新知

前言 Microsoft 的 Superintelligence team 在 2026 年 6 月 2 日正式推出了 MAI-Code-1-Flash——一個專為日常開發者工作流設計的高效編碼模型。這個模型由 Microsoft 端到端打造，使用乾淨且具合法授權的資料訓練，目前已開始部署到 GitHub Copilot 的 VS Code 個人版使用者中。 簡單來說，這是 Microsoft 在「讓 AI 真正好用」這條路上又踏出的一步。 三大核心能力 根據官方公告，MAI-Code-1-Flash 主打三個特色： Agentic Coding（智能代理編碼）：模型直接在 GitHub Copilot harness 環境中訓練，能與開發者日常使用的工具和系統無縫協作，不是只在實驗室跑分，而是在真實環境中學習如何寫碼。 Adaptive Thinking（自適應思考）：遇到簡單任務時保持精簡，遇到複雜問題時自動分配更多推理預算。這就像一個懂得看場合的同事——小事不廢話，大事肯花時間。 強指令遵循能力：無論是一次性提問還是多輪對話，都能精準理解並執行開發者的意圖。 為什麼說「為開發者而生，不是為跑分而生」？ 這可能是這篇文章最關鍵的概念。大多數 AI 編碼模型的訓練目標是「在 benchmark 上拿高分」，但 MAI-Code-1-Flash 反其道而行——它在 GitHub Copilot 的生產環境中直接訓練，用真實開發者的使用數據來優化模型。 訓練過程中，團隊評估了核心軟體工程任務、倉庫問答、重構能力，以及從真實 Copilot 使用記錄中提取的遥測數據任務。這種「訓練、評估、生產」三者一致的方法，確保了實驗室裡的改進能真正轉化為開發者的體驗提升。 每個 token 都要花在刀口上 MAI-Code-1-Flash 引入了 自適應解決方案長度控制（Adaptive Solution Length Control） 技術。用白話來說： 簡單任務 → 精簡回答，少花 token 複雜任務 → 深入分析，多花 token 實際效果是：在 SWE-Bench Verified 上，MAI-Code-1-Flash 解決難題時最多少了 60% 的 token 用量。這不僅降低了延遲和成本，更讓互動式工作流變得更順暢——開發者不用等那麼久就能看到有用的輸出。 ...

前幾天，一堆 Instagram 帳號——包括像白宮帳號這種高知名度的——好像都被黑了。 我雖說不是什麼小年輕了，但在獨角獸級公司找漏洞跟開發也快十五年，但這絕對是我見過最無厘頭、「蠢到不太可能成真」的一個。 劫持流程：簡單到令人髮指 Step 01：偽造位置 + 啟動客服 攻擊者只需要你的帳號名稱就能開工。接著連上一個靠近你城市位置的 VPN 或 proxy，讓 Instagram 的安全演算法不會起疑（這個資訊從你的公開個人頁面、About 區塊，或一百種其他方式就能拿到）。一旦看起來請求來自正確的地區，攻擊者就會告訴 Meta 支援 AI 帳號被黑了，要求把驗證碼發到他們控制的任意 Email。 Step 02：就結束了 真的，就結束了。這是我在生產環境中看過的第一個真正的「零驗證密碼重置」。系統似乎不會檢查你提供的 Email 是不是使用者以前用過的。一旦 AI 把驗證碼發到攻擊者的信箱，攻擊者再把碼填回去完成驗證，平台就乖乖送上一條新密碼重置連結，帳號歸屬權直接移交。 Instagram 的 AI 可能會問攻擊者要一段自拍影片來證明身分。目前的 AI 辨識力還不太夠，所以簡單到拿目標個人動態裡一張已經公開的 AI 動畫照片就能搞定。 雙重驗證（2FA）也沒用 如果你在想，因為這個高權限恢復流程被系統視為「真正的擁有者」進行的完整帳號重置，原本的雙重驗證會在過程中被徹底繞過。 既有的工作階段會被撤銷，密碼被更改，而且不會有任何 Email、簡訊或推播通知。真正的擁有者無法再發起恢復，因為 Email 和電話號碼現在都對應到攻擊者。沒有客服人員可以升級處理，就只有你跟一個聊天機器人奮戰，希望能奪回控制權，同時祈禱對方不要再來一次。 如果你屬於 A/B 測試中 AI 支援選項啟用的帳號，更慘——你甚至關不掉它。 黑市熱鬧滾滾 多個黑市的 Telegram 群組紛紛推出「帳號劫持」服務，價格高昂但交付速度極快。考慮到短帳號可以價值數十萬到數百萬美元，這也就不令人意外了。 帳號已經被轉賣（例如 hey），被用於宣傳（例如 obamawhitehouse 或美國太空軍上士長的帳號 ocmssf）。 已經修好了 所有 Telegram 群組都安靜下來了，因為 Meta 似乎已經修復了這個問題。但這個方法似乎已經活躍了好幾週，甚至好幾個月。 一個市值 1.5 兆美元的公司竟然連基本的安全防護都沒有，他們的支援 AI 只要你開口，就會隨意更換任何人的綁定 Email——這事實本身既恐怖又搞笑。 原文：The Newest Instagram “Exploit” is the Goofiest I’ve Seen by Sid’s Blog | 2026-06-01 ...

引言：一台「不該跑 AI」的機器 這篇文章是 point.free 上一篇 Gemma 4 系列的最後一篇——前面兩篇講了怎麼把 Gemma 4 的 MTP drafter 量化、怎麼跟 verifier 配對，而這一篇要回答一個更刁鑽的問題： 「把這些成果丟到一台根本沒有資格跑 AI 的機器上，會怎樣？」 作者的硬體規格聽起來像是一台從墳墓裡挖出來的古董： CPU：Intel Xeon E5-2620 v4（2016 年產，約為當前筆電 CPU 的五分之一慢） 記憶體：128 GB DDR3（頻寬只有最新筆電 RAM 的五分之一到六分之一） GPU：無（連內顯都沒有） 換作一般工具，比如 ollama，直接放棄。但這篇文章的作者說：「等等，聽我說完……」 核心問題：記憶体牆（Memory Wall） 要理解這篇文章的精髓，先搞懂一個概念——LLM 推理的瓶頸不在運算能力，而在記憶體頻寬。 當你使用 ChatGPT 看著文字逐字流出時，你看到的是「decoder pass」。在這個階段，處理器要不斷把龐大的模型權重從記憶體拉進 CPU cache 才能計算下一個 token。處理器的運算速度其實很快，但它大部分時間都在等記憶體傳輸——這就叫「記憶體受限」（memory-bound），而非「運算受限」（compute-bound）。 這就是著名的「記憶体牆」問題。不管你用的是 2016 年的 Xeon 還是最新的 H100，這堵牆都在那裡。 所以，直接拿預設參數跑 llama-cli 在 DDR3 機器上會慢到令人發指。解法是什麼？把 ik_llama.cpp 能用的優化選項全部拉滿。 那串「魔法咒語」 作者甩出了一長串 llama-cli 參數，看起來像中世紀巫師的咒語： llama-cli \ --model gemma-4-26B-A4B-it-Q8_0.gguf \ --model-draft wikitext-2-raw_ik-llama-mtp_drafter-conservative/gemma-4-26B-A4B-it-assistant-Q8_0.gguf \ --spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune \ -cnv --color --jinja --special \ -sm graph -smgs -sas -mea 256 --split-mode-f32 \ --temp 0.7 -t 8 --parallel 8 \ --cpu-moe --merge-up-gate-experts \ --flash-attn on --mla-use 3 \ --mlock --run-time-repack --no-kv-offload 25 個參數，一半沒有文件說明，四分之一會靜默失敗。這就是作者所說的「可用性的護城河」（usability moat）——黑盒工具讓你看不見這些，但也讓你無法優化。 ...

前情提要 過去幾年，OpenAI 的旗艦模型（GPT-4o、GPT-5 系列、o1/o3 推理模型、Codex 程式生成模型）只能透過 OpenAI 自家 API 呼叫。不管你的公司用什麼雲端，只要想用 OpenAI 最強的模型，就得連到 api.openai.com。 現在，這個局面被打破了。 2026 年 6 月 1 日，OpenAI 正式宣布其 frontier models（包含 GPT-5、o3、Codex 等）以及 Codex CLI 開發工具，全面上架 AWS Marketplace 。 這聽起來像是「又多了一個呼叫方式」，但實際上，這一步的意義遠比你想像的深。 這次上線了什麼？ 簡單來說，這次 AWS 上架的包含兩大塊： 1. OpenAI 模型作為 AWS Marketplace 產品 你可以在 AWS Marketplace 直接訂閱 OpenAI 的模型，然後透過 AWS 的 API Gateway、Bedrock 或直連方式呼叫。计费走 AWS 帳單，跟其他 AWS 服務（EC2、S3、Lambda）的帳單合在一起。 支援的模型包括： GPT-5 系列（包含不同尺寸與成本效能比的版本） o3 / o4 推理模型（高階邏輯推理、數學、程式生成） Codex 模型（專為程式碼生成與理解優化） 2. Codex CLI 工具 Codex CLI 是 OpenAI 推出的命令列開發助手，可以直接在終端機裡跟 AI 對話、生成程式碼、review PR。現在這個工具也可以透過 AWS 基礎設施運行，對已經深度使用 AWS 生態的開發者來說，整合度更高。 ...

前陣子 Hacker News 上有一篇貼文衝上熱門，標題是「AI Agent Guidelines for CS336 at Stanford」，短短時間內拿到了四百多則按讚。 第一眼看到的時候，我心裡想的是：不過就是一份 prompt 吧？但仔細看完之後，發現這份只有兩千多字的 Markdown 檔案，其實藏著不少值得開發者思考的東西。 什麼是 CS336？ CS336 是史丹佛大學一門叫做「Language Modeling from Scratch」的課程。簡單來說，這門課不教你怎麼呼叫 API，而是從零開始，用 Python 和 PyTorch 實作一個語言模型。 課程非常硬核——你需要自己寫 tokenizer、transformer block、訓練迴圈，甚至 Triton kernel。正因如此，學生在作業上花的时间非常多。 於是教授們想了一個辦法：讓學生在寫作業時，可以請 AI 助手幫忙，但有一套明確的「遊戲規則」。 核心原則：Agent 是助教，不是解答器 這份 Guidelines 的第一句話就點出了核心精神： AI agents should function as teaching aids that help students learn through explanation, guidance, and feedback—not by completing assignments for them. 換句話說，AI Agent 的角色是「老師」，不是「代考」。 接下來，文件列出了 Agent 應該做和不應該做的事情。我整理成幾個重點： Agent 應該做的： ...