Vue.js v3.6.0-beta.16 發布：Vapor Mode 穩定化的第 16 輪衝刺
github.com/vuejs/core · 2026-06-17
Vue.js 核心團隊於 2026 年 6 月 17 日釋出 v3.6.0-beta.16，這是 3.6 minor 分支的第 16 個公開測試版本。本次發布集中於 Vapor Mode 的編譯器與執行期修復，共解決 26 項已知問題，並附帶一項效能最佳化，顯示 3.6.0 正式版發布已步入最終收尾階段。距上一個 v3.6.0-beta.15（6 月 11 日）僅六天，版本迭代節奏仍相當密集。
背景
Vue 3.6 的核心新功能是 Vapor Mode——一套完全繞過虛擬 DOM（VDOM）的替代編譯目標。Vapor Mode 將元件直接編譯為對應的 DOM 命令式操作，省去每次重新渲染時建立虛擬節點樹的開銷，目標是在高頻更新場景下大幅降低記憶體分配與 GC 壓力。自 beta.1 至今，每個版本主要都在填補 Vapor 與傳統 VDOM 模式之間的行為差異，確保兩套路徑能夠無縫混用（island-style hybrid）。
3.6 分支的其他亮點包括：對事件委派行為提供更細粒度控制（beta.15 新增的 disabling event delegation）、非同步元件錯誤處理改善（beta.14）、以及對 SSR 水合（hydration）錯誤偵測與復原路徑的全面強化。從 beta 進程可以觀察到，官方測試涵蓋範圍已擴展至 teleport、transition-group、slot fallback 等複合場景，顯示 Vapor Mode 的 API 曲面已大致凍結。
核心改動
beta.16 的修復分為兩個子套件：compiler-vapor 與 runtime-vapor。
compiler-vapor 端修復了以下問題：
- 處理
setup-let的行內賦值（inline assignment） - 在文字轉換（text transforms）之前正確忽略
v-html的子節點 - 防止不安全屬性名稱（unsafe attr names）被帶入產出模板
- 對動態修飾符引數鍵（dynamic modifier arg keys）進行正規化
- 修正
v-model修飾符鍵的引號處理（quote handling）
runtime-vapor 端則解決了更複雜的執行期語義問題：
- 在水合節點因 mismatch 被重建後正確套用動態 props
- 避免靜態模板快取在重複的水合採用（hydration adoption）時被重複複製
- 按類型正確分桶（bucket）
transition-group的離場動畫 - Fragment 與 Teleport 的邊界案例處理
- Symbol 屬性的字串化行為修正
效能面新增一項最佳化（issue #14969）：對穩定的 slot fallback 略過 SlotFragment 封裝，減少不必要的元件包裝節點，降低渲染路徑深度。雖然單次效益有限，但在大量靜態 slot 的元件樹中，累積效果可觀。
影響範圍
beta.16 仍屬預覽版，不建議用於生產環境。目前主要受影響的使用場景如下：
- 使用
v-model並帶有自訂 modifier 的 Vapor 元件 - SSR + Vapor 混用並依賴 fragment 水合的應用
- 在 Vapor 模式下使用
<Transition>、<TransitionGroup>或<Teleport>的元件 - 靜態模板被多次動態掛載（如列表 item 使用靜態子樹）的場景
- 含 symbol 屬性值的 Vapor 元件
# 安裝最新 beta
npm install vue@3.6.0-beta.16
# 或指定各子套件
npm install @vue/compiler-vapor@3.6.0-beta.16
npm install @vue/runtime-vapor@3.6.0-beta.16完整 changelog 可查閱 minor 分支 CHANGELOG.md。對使用標準 VDOM 模式的 Vue 3 專案，此版本無直接影響——3.6 正式版在 Vapor Mode 上將採用漸進採用策略，現有元件無需改寫即可繼續運作。
原始來源：github.com/vuejs/core — v3.6.0-beta.16、CHANGELOG.md (minor branch)
GLM-5.2 發布：753B 參數、1M Token 上下文與 IndexShare 稀疏注意力架構
huggingface.co · 2026-06-17
智譜 AI（ZhipuAI）旗下的 zai-org 於 2026 年 6 月 17 日在 HuggingFace 正式發布 GLM-5.2，這是 GLM-5 系列的第二個主要版本，參數量 753B，以 MIT 授權開源，無地區限制。GLM-5.2 的核心目標是長時程任務（long-horizon tasks）——在需要跨多步驟規劃與執行的場景（如大型程式碼庫修改、複雜代理工作流）中取得可持續的高表現，並透過 IndexShare 架構將 1M token 長上下文推論的 FLOPs 降低 2.9 倍。
背景
大型語言模型在處理超長上下文時面臨兩個根本瓶頸：稀疏注意力（sparse attention）的索引計算成本隨序列長度平方成長，以及 KV-cache 的記憶體佔用在百萬 token 級別難以管理。GLM-5.1 已將上下文視窗從 32K 擴展至 200K，但在實際部署中仍有明顯的推論延遲問題。GLM-5.2 針對這兩個層面同時提出系統性解法。
技術基礎來自 2026 年 3 月投稿 arXiv 的 IndexCache 論文（arXiv:2603.12201）。該研究由清華大學知識工程實驗室與智譜 AI 聯合完成，核心發現是相鄰 Transformer 層之間的 top-k token 選擇高度相似，可安全地跨層共用索引而幾乎不損失品質。論文提出兩種實作路徑：無需訓練的貪婪搜尋（greedy search）與訓練感知的多層蒸餾（multi-layer distillation）。
核心改動
IndexShare 是 GLM-5.2 最重要的架構創新：每四個稀疏注意力層共用同一個索引器（indexer），將整體 indexer 計算複雜度從 O(L²) 大幅壓縮。IndexCache 論文的實驗結果顯示，在 30B 模型上可移除 75% 的 indexer 計算量，前置處理（prefill）速度提升 1.82×，解碼速度提升 1.48×；在 GLM-5.2 的 1M token 長度下，整體 per-token FLOPs 降低達 2.9 倍。
推論端的另一改進是 Multi-Token Prediction（MTP）強化版本，透過 IndexShare 優化 KV-cache 共用方式、結合拒絕取樣（rejection sampling）與端到端 TV loss 訓練，使推測解碼（speculative decoding）的接受長度（acceptance length）提升 20%，有效降低單 token 實際延遲。
KV-cache 記憶體管理採三層策略：
- LayerSplit：細粒度記憶體分區管理
- Context-aware kernel 最佳化
- CPU 側快取協作（CPU-side cache orchestration）
訓練後強化學習（RL post-training）使用自研 slime 框架，支援平行 OPD（On-Policy Distillation）訓練，在約兩天內合併超過十個專家模型。為防止獎勵破解（reward hacking），系統採兩階段偵測：先以規則過濾，再用 LLM 驗證意圖。
影響範圍
效能基準方面，GLM-5.2 在 Terminal-Bench 2.1 上得分 81.0（GLM-5.1 為 63.5），SWE-bench Pro 62.1（前版 58.4），FrontierSWE 74.4。在 PostTrainBench 長時程任務排行榜上位居第二，數學推理方面，AIME 2026 得 99.2，GPQA-Diamond 得 91.2。
| 基準 | GLM-5.1 | GLM-5.2 |
|---|---|---|
| Terminal-Bench 2.1 | 63.5 | 81.0 |
| SWE-bench Pro | 58.4 | 62.1 |
| FrontierSWE | — | 74.4 |
| AIME 2026 | — | 99.2 |
| 上下文視窗 | 200K tokens | 1M tokens |
模型支援 SGLang（v0.5.13+）、vLLM（v0.23.0+）、Transformers、KTransformers 等主流推論框架，並相容昇騰 NPU 部署。對於需要在單一推論工作中處理大型程式碼庫或長文件的工程場景，1M token 穩定上下文搭配 2.9× FLOPs 降低，使本地或雲端自部署在成本上具備實際可行性。
原始來源：HuggingFace Blog — GLM-5.2、arXiv:2603.12201 — IndexCache、HuggingFace Model Card
Anthropic《創業者手冊》：以代理工作流取代創辦人注意力的四階段框架
claude.com · 2026-05-14
Anthropic 於 2026 年 5 月 14 日發布《The Founder's Playbook: Building an AI-Native Startup》，這份完整手冊以 PDF 形式提供下載，針對從構想到規模化的四個創業階段，提供具體的 AI 工具整合策略與提示範本。文件的核心論點是：創辦人的角色正從個人貢獻者轉移到代理工作流的編排者（orchestrator），AI 原生公司在組織架構與技術決策上應從第一天起就反映這一前提。
背景
過去兩年間，多數新創公司對 AI 的運用停留在「在現有流程中嵌入 LLM 呼叫」的層次，而非重新設計工作流。Anthropic 認為這種「AI 輔助」（AI-assisted）模式與「AI 原生」（AI-native）模式之間存在根本差異：前者以人為核心、AI 加速；後者以 AI 代理為執行單元、人負責目標設定與品質把關。本手冊旨在提供後者的實作藍圖。
手冊援引五家公司的創辦人案例：Ambral、Anything、Carta Healthcare、HumanLayer 與 Vulcan Technologies。這些案例橫跨醫療、金融基礎設施、人力資源與企業軟體，呈現 AI 原生架構在不同行業垂直的共通模式與差異。
核心改動
手冊將新創生命週期劃分為四個階段，每個階段配對特定的 AI 整合策略：
- Idea 階段：以 AI 協助問題驗證、競爭格局分析與客戶訪談設計，壓縮從假設到證偽的週期。
- MVP 階段：架構決策、範疇管理與安全實踐，防止 AI 生成程式碼在快速迭代中累積技術債。
- Launch 階段：以代理工作流（agentic workflows）取代需要創辦人持續注意力的重複性任務，包括客戶溝通、資料分析管線與部署流程。
- Scale 階段：產品矩陣決策框架，涵蓋 Chat、Claude Cowork 與 Claude Code 三種工具定位的策略性選擇。
MVP 階段的技術建議特別具體。手冊明確區分哪些決策應由人工主導、哪些可委派給 AI 代理：資料庫 schema 設計、API 介面定義、安全邊界屬於需要人工審查的決策點；樣板程式碼生成、測試案例撰寫、文件初稿則適合完全代理化。這種分層方法旨在避免「AI 生成的程式碼在架構層面缺乏連貫性」的常見陷阱。
Launch 階段提出的「代理操作系統（agentic operating system）」概念，是將重複性的創辦人工作（如每週投資人更新、客戶健康分析、招募管線追蹤）封裝為可排程的代理工作流。手冊提供對應的提示範本與觸發條件設計，讓這些工作流在無需人工啟動的情況下定期執行。
影響範圍
本手冊主要受眾是處於早期階段的技術型創辦人，尤其是計畫以 Claude Code、Claude API 或 Anthropic 代理基礎設施為核心開發工具的團隊。文件中對技術債預防的強調，隱含著對目前市場上常見「快速生成、不審查、反覆堆疊」開發方式的直接批評——這種模式在達到 MVP 里程碑後往往導致難以維護的程式碼庫。
Scale 階段的產品矩陣框架涉及 Anthropic 自身產品線的使用場景區分：Chat 適合非結構化探索，Claude Cowork 適合跨職能知識工作，Claude Code 適合工程執行。創業者在參考其建議時，應留意手冊同時兼具產品推廣脈絡，部分場景假設可能預設使用 Anthropic 工具生態系而非中立評估。