TypeScript 7.0 RC 發布：以 Go 重寫編譯器，效能提升 10 倍
Microsoft Dev Blogs · 2026-06-18
Microsoft 於 2026 年 6 月 18 日發布 TypeScript 7.0 Release Candidate，這是該語言史上最大規模的底層重構——將整個編譯器從 TypeScript 移植至 Go，並宣稱在多數工作負載下速度較 TypeScript 6.0 快約 10 倍。原始碼已公開於 microsoft/typescript-go。
背景
效能瓶頸長期困擾大型 TypeScript 專案，尤其在多百萬行程式碼的 monorepo 中，型別檢查與 Language Server 的回應延遲已成為開發體驗的主要痛點。Microsoft 花費約一年時間，選擇以 Go 重寫，目的是利用原生執行效率與共享記憶體的平行化能力，而不是在 JavaScript 執行環境上疊加工作執行緒。現有的型別檢查邏輯刻意與 6.0 保持一致，以確保型別安全行為不會因此改變。
Go 版本的程式碼庫目前佔整個 typescript-go 儲存庫的 84.5%，其餘為 TypeScript 與 JavaScript 的測試基礎設施。Bloomberg、Canva、Figma、Google、Linear、Slack、Vercel 等公司均參與了早期驗證，在各自的多百萬行程式碼庫上執行測試。
核心改動
平行化是本次架構改動的核心，透過三個新的 CLI 旗標加以控制：
--checkers <N>：型別檢查工作執行緒數量，預設值為 4--builders <N>：專案參考（project references）的平行建置數量--singleThreaded：強制單執行緒模式，用於偵錯或受限環境
檔案監看（watch mode）基礎設施以 Parcel bundler 的 C++ 檔案監看器為基礎，移植至 Go，避免引入額外工具鏈依賴。Language Server Protocol（LSP）實作採用多執行緒請求處理，語言伺服器命令失敗率較 6.0 下降 20 倍。語義高亮、import 排序、未使用 import 移除等功能亦已在本版本恢復。
Unicode 代碼點（code point）的處理行為也有所修正。Template literal type 在推斷時現在能正確保留完整的 Unicode 代碼點，而非將代理對（surrogate pair）拆開：
type HeadTail<S> = S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;
type Result = HeadTail<"😀abc">;
// TypeScript 7.0: ["😀", "abc"]
// TypeScript 6.0 以前: ["\ud83d", "\ude00abc"] ← 代理對被拆開預設值也有多項破壞性變更，新建專案無需手動調整即可符合現代最佳實踐：
strict: true（原預設為 false）module: "esnext"types: []（原預設為["*"]，即自動引入所有@types/*）rootDir: "./"stableTypeOrdering: true（強制啟用，無法關閉）
同時移除多項已過時的功能，包含 target: es5、AMD / UMD / SystemJS / CommonJS 模組系統、baseUrl（應改用相對路徑的 paths）、Classic 模組解析策略，以及 downlevelIteration。
影響範圍
現有 6.0 專案可透過 @typescript/typescript6 套件實現並存，該套件提供獨立的 tsc6 執行檔：
# 安裝 RC 版
npm install -D typescript@rc
# 若需同時保留 6.0
npm install -D typescript@npm:@typescript/typescript6遷移時有兩個常見的設定調整需要注意。若 tsconfig.json 位於原始碼目錄之外，需明確指定 rootDir 與 include。由於 types 預設改為空陣列，原先依賴自動全域型別（如 node、jest）的專案需在設定檔中明確列舉：
{
"compilerOptions": {
"rootDir": "./src",
"types": ["node", "jest"]
},
"include": ["./src"]
}程式化 API（Programmatic API）的穩定版本預計於 TypeScript 7.1 推出，因此目前仍依賴 compiler API 進行自定義轉換的工具鏈（如部分 Babel 外掛、程式碼生成器）需等待正式穩定後再行遷移。穩定版 7.0 預計於 RC 發布後一個月內釋出。VS Code 使用者可透過 TypeScript Native Preview 擴充功能立即體驗。
原始來源：Microsoft Dev Blogs — Announcing TypeScript 7.0 RC、microsoft/typescript-go
Cloudflare 推出 AI Agent 臨時帳號機制，無需身份驗證即可部署 Workers
Cloudflare Blog · 2026-06-19
Cloudflare 於 2026 年 6 月 19 日宣布推出 Temporary Accounts 功能，允許 AI agent 在無需人工身份驗證的情況下，透過 wrangler deploy --temporary 指令在數秒內部署至 Cloudflare Workers 平台，並提供後續認領（claim）機制將臨時資源轉為永久帳號。此功能需要 Wrangler v4.102.0 以上版本。
背景
自主性 AI coding agent 在執行「寫程式 → 部署 → 驗證」迴圈時，面臨的核心障礙是 OAuth 登入流程需要人工介入——瀏覽器彈出、點擊授權、貼上 token，每一步都會打斷 agent 的無人值守工作階段。現有的 API token 方案雖可自動化，但仍需要使用者預先持有帳號並手動建立 token，對首次使用者或暫時性的原型開發情境而言摩擦成本過高。Cloudflare 將此問題定義為「設計給人類使用者的限制不應套用在 agent 上」，並以此為出發點設計臨時帳號機制。
核心改動
臨時帳號的核心是一套自動化的帳號生命週期管理機制，整個流程分為四個階段：
- agent 執行
npx wrangler deploy --temporary，CLI 向 Cloudflare 請求建立臨時帳號 - Cloudflare 完成用戶端 Proof-of-Work 驗證後，發放 API token 並回傳至 Wrangler
- Worker 部署至
workers.dev子網域，CLI 快取臨時帳號憑證供後續重複部署使用 - 系統產生格式為
https://dash.cloudflare.com/claim-preview?claimToken=<TOKEN>的認領 URL，人工使用者可於此完成所有權轉移
帳號有效期為 60 分鐘。若在此期間未被認領，帳號與所有部署資源將自動刪除；認領後資源則永久保留。Wrangler 會在同一工作階段內快取臨時帳號，跨多次部署重複使用，避免每次部署都建立新帳號。執行 wrangler login 或 wrangler logout 會清除快取並強制切換至正式帳號流程。
臨時帳號支援的 Cloudflare 產品與資源上限如下：
| 資源 | 限制 |
|---|---|
| Workers Static Assets | 最多 1,000 個檔案；每個 5 MiB |
| D1 Database | 單一資料庫；100 MB |
| Hyperdrive | 2 個設定；10 個連線 |
| Queues | 最多 10 個 |
| Workers KV、Durable Objects、SSL/TLS | 僅限臨時憑證操作 |
安全設計上採用多層防護：Proof-of-Work 機制在用戶端自動執行（對 agent 透明）、平台層面限制帳號快速建立的速率、認領 URL 應被視為敏感憑證妥善保管。若 CLI 環境已透過 OAuth、CLOUDFLARE_API_TOKEN 或 API key 完成身份驗證，--temporary 旗標將回傳錯誤，避免混淆。
影響範圍
此功能直接對應的是 agentic coding 工作流程中「冷啟動」問題——agent 可以在使用者從未建立過 Cloudflare 帳號的情況下完成完整的部署驗證迴圈，再由人工決定是否認領結果。官方文件明確列出四種適用情境：AI 生成部署、背景 agent 工作階段、快速原型開發、首次 Workers 體驗；並強調生產環境與 CI/CD 管線應使用永久帳號。
Cloudflare 同時揭露了與 Stripe 的合作（針對 agent 付款場景的帳號配置）以及與 WorkOS 在 auth.md 協定上的協作，後者基於 OAuth 標準，讓 agent 能在不需人工介入的情況下完成帳號配置。相關的 Wrangler SDK 版本更新記錄可查閱 workers-sdk releases，完整的資源限制與設定細節則記錄於 官方開發者文件。
原始來源：Cloudflare Blog — Temporary Cloudflare Accounts for AI agents、Cloudflare Developers — Claim Deployments
工業摘要系統中將確定性萃取與 AI 推論分離的架構實踐
Microsoft ISE Dev Blogs · 2026-06-19
Microsoft ISE 工程團隊於 2026 年 6 月 19 日發表一篇架構案例研究，描述在工業班次日誌（operational shift log）摘要系統的開發過程中，如何從「100% 輸出合法 JSON、0% 符合資料契約」的失敗原型，透過四個 pass 的流水線架構，達到 100% 的資料結構合規性，且在更換底層語言模型後仍維持相同結果。
原本的問題
原型系統要求 LLM 同時負責資料萃取與推論兩類工作，但這兩類工作在本質上具有根本差異：萃取是確定性的（來源欄位存在則複製，不存在則記錄缺失），推論是機率性的（需要模型判斷路由分類、趨勢解讀等）。當兩者混合後，模型會傾向「填補」缺失欄位——用推測性內容代替空值，或將需要精確對應的識別符（如 log_entry_id）自行編造。結果是輸出的 JSON 結構合法，但必填欄位缺失或填入了無法回溯至來源記錄的虛構資料，違反了 Responsible AI 的透明性與可問責性原則。
問題的根源在於系統缺乏一份明確的「欄位分類契約」，導致模型無從判斷哪些欄位應直接複製、哪些欄位需要推論。這種設計缺陷在 prototype 階段以 JSON 格式有效性遮蔽了資料品質問題，直到對照資料契約逐欄驗證才暴露真正的合規率為 0%。
採用的方法
解決方案的核心是一份欄位分類登錄（classification registry）——一個將每個輸出欄位標記為 deterministic 或 llm_required 的對映結構，作為整個流水線的架構契約。在此基礎上，系統實作了四個 pass 的處理流程：
- Pass 1 — 確定性萃取：直接從來源資料複製
deterministic欄位，不經過 LLM。缺失欄位以真實的缺失元資料（如{ "status": "not_found", "source_id": "..." }）填入，禁止虛構。 - Pass 2 — 受限模型判斷：模型僅接收標記為
llm_required的欄位清單，以log_entry_id為鍵回答特定的路由與分類問題，輸出嚴格約束於預定義的答案空間。 - Pass 3 — 守衛合併：以來源識別符為 join key，將 Pass 2 的 AI 輸出合併至 Pass 1 建立的確定性骨架中。確定性欄位值永遠優先於模型輸出；衝突時記錄違規日誌，並在輸出中附加資料溯源（data provenance）區段，追蹤每個欄位的填充狀態。
- Pass 4 — 證據對映：完成合併後，模型產生可追溯性連結，將每個推論結論對應回具體來源記錄，並附上信心評估。
「記錄缺失，而非虛構內容」是整個設計的核心原則。Pass 1 明確禁止以任何推測性資料填補確定性欄位，確保輸出的確定性部分在數學意義上可被驗證正確。
實際效果
資料結構合規率的改善呈現出清晰的 pass-by-pass 遞增趨勢：
| 階段 | 結構合規率 |
|---|---|
| 原型（單一 LLM pass） | 0% |
| 加入 Pass 1 後 | 47% |
| 加入 Pass 2 + 3 後 | 73% |
| 完整四 pass 流水線 | 100% |
確定性欄位經測試達到 100% 與來源資料一致。更關鍵的是，當底層語言模型被替換為不同的基礎模型後，合規率仍維持在 100%，驗證了架構本身（而非模型能力）才是合規性的保證來源。欄位分類登錄同時成為可維護的文件，清楚界定每個輸出欄位的責任歸屬，降低後續維護時對模型行為的依賴與不確定性。