[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-nitro-split-kernel-isolation-math-zh":3,"article-related-nitro-split-kernel-isolation-math-zh":30,"series-research-01a0e759-2366-485d-bafa-db75293c9f0c":75},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":29},"01a0e759-2366-485d-bafa-db75293c9f0c","nitro-split-kernel-isolation-math-zh","Nitro 把隔離拆成可證明的數學","\u003Cp data-speakable=\"summary\">\u003Ca href=\"\u002Ftag\u002Faws\">AWS\u003C\u002Fa> split Nitro’s isolation logic into a tiny \u003Ca href=\"\u002Ftag\u002Frust\">Rust\u003C\u002Fa> kernel and proved VM isolation with machine-checked math.\u003C\u002Fp>\u003Cp>我看雲端安全系統看久了，最怕的不是 bug，最怕的是那種「應該沒事啦」的架構。隔離邏輯跟排程、驅動、產品特化、AWS 自家 hook 全黏在一起，然後有人拍拍胸口說 VM 會被隔開。拜託，我真的看過太多這種故事。不是團隊不認真，是東西一大包之後，你根本沒辦法乾淨地推理哪一段在管邊界、哪一段只是順手做事。每次改動都像在賭，這種安全軟體我很難放心。\u003C\u002Fp>\u003Cp>這次讓我停下來看的，是 Amazon Science 這篇 \u003Ca href=\"https:\u002F\u002Fwww.amazon.science\u002Fblog\u002Fec2s-formally-verified-isolation-engine-provides-mathematical-assurance-of-virtual-machine-isolation\">EC2’s formally verified ‘isolation engine’ provides mathematical assurance of virtual-machine isolation\u003C\u002Fa>。作者是 Dominic Mulligan 跟 Nathan Chong。文中最刺眼的不是雲端宣傳，而是他們真的把隔離邏輯拆出去，縮成一個小核心，再用機器檢查的數學去證明它。Amazon 還說\u003Ca href=\"\u002Fnews\u002Fmodel-triage-coding-tests-cost-win-zh\">模型\u003C\u002Fa>和證明總共是 330,000 行，Nitro Isolation Engine 是第一個部署在商業雲環境的 formally verified hypervisor。這個數字我不會拿來灌水，但它很能說明一件事：這不是玩具。\u003C\u002Fp>\u003Ch2>別拿整個 hypervisor 去做證明，那是在自找麻煩\u003C\u002Fh2>\u003Cblockquote>“Splitting the ‘separation kernel’ off from the rest of the Nitro security system … enabled its formal verification.”\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：他們沒有硬著頭皮去證明整個 hypervisor，而是先承認一件事，整包系統太肥，根本不適合直接做形式驗證。這個判斷很老實，也很重要。因為一旦你的系統同時混著隔離\u003Ca href=\"\u002Fnews\u002Fopenai-right-to-hire-dean-ball-policy-power-zh\">政策\u003C\u002Fa>、裝置處理、排程、遷移、AWS 特化邏輯，你證明的就不再是 kernel，而是一個超大應用程式，只是它剛好跑在 VM 底下。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781843603985-dhih.png\" alt=\"Nitro 把隔離拆成可證明的數學\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>Amazon 的文章裡寫得很清楚：原本的 Nitro Hypervisor 同時管隔離、驅動、AWS-specific 功能，這種架構一看就知道會把 proof target 撐爆。後來他們把真正重要的那塊，也就是 VM 分離這件事，抽成獨立元件 Nitro Isolation Engine。這才是他們能下手證明的目標。\u003C\u002Fp>\u003Cp>我自己做系統設計時也常看到這種爛局。你叫團隊「把安全性證明出來」，大家最後都會偷偷縮小範圍，只挑一個 invariant、一條 data flow、一個邊界。Amazon 只是把這件事明講出來，不再假裝整包都能一起證。這差很多。前者是 proof plan，後者是祈禱。\u003C\u002Fp>\u003Cp>實操上我會這樣做：先找出那個一出錯就會變成資安事故的子系統，再把其他東西從它身上剝掉。如果你怎麼切都切不小，通常不是你不會證明，是你的架構根本不配被證明。這句話很難聽，但常常是真的。\u003C\u002Fp>\u003Cul>\u003Cli>把 enforcement 跟 policy 分開。\u003C\u002Fli>\u003Cli>把 proof target 壓到最小。\u003C\u002Fli>\u003Cli>讓其他模組請求核心幫忙，不要自己碰安全邊界。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>這裡也順便點到 separation kernel 的老派價值。John Rushby 在 1981 年提出這個詞，講的就是一個最小 OS 元件，專門把系統切成彼此隔離的 compartment。Amazon 只是把這個老觀念搬到雲端，場景更大、程式碼更髒，但原理沒變。\u003C\u002Fp>\u003Ch2>Rust 不是魔法，少用它才是重點\u003C\u002Fh2>\u003Cp>Amazon 說 Nitro Isolation Engine 是用 Rust 寫的，但不是整個語言都拿來用，而是挑了適合形式推理的子集。這點我很有感。很多團隊嘴上說想用 Rust 是因為「比較安全」，結果一上手就把所有 feature 都打開，最後 proof story 還是卡死。\u003C\u002Fp>\u003Cp>重點不是「Rust 讓一切可驗證」。重點是「把語言限制到可推理」。這兩句差很多。Amazon 還把 Rust 的核心子集形式化成 μRust，收進開源的 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fawslabs\u002Fautocorrode\">AutoCorrode\u003C\u002Fa>。這代表他們不是只在口頭上說「我們用了安全語言」，而是真的替程式碼建立一個 proof-friendly 的語意模型。\u003C\u002Fp>\u003Cp>我很喜歡這種做法，因為它承認一個很多人不想面對的事實：驗證工作有一半是在處理語言本身，不是在處理邏輯。語言太多 sharp edge，你的 proof 就會一直追著 aliasing、undefined behavior、編譯器假設跑。到那時候，難的不是 theorem prover，是你的 programming model 根本不乾淨。\u003C\u002Fp>\u003Cp>實操寫法很直接：如果你想驗證某個子系統，先定義 safe subset，再寫 code。不要先從語言手冊開始讀。先從這個子系統實際需要哪些操作開始，然後把其他功能禁掉。很煩，對，沒錯；但這通常才是能落地的方法。\u003C\u002Fp>\u003Cul>\u003Cli>先寫 subset 規格，再寫實作。\u003C\u002Fli>\u003Cli>資料結構越普通越好。\u003C\u002Fli>\u003Cli>unsafe escape hatch 要少，而且要明顯。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Amazon 這次最值得抄的，不是 Rust 這個名字，而是「先收斂語言，再談證明」的態度。程式碼的意義變小了，證明才有機會變得可做。\u003C\u002Fp>\u003Ch2>規格要白紙黑字，不能靠大家默契\u003C\u002Fh2>\u003Cp>Amazon 把驗證拆成兩塊：specifications 跟 proofs。這聽起來像廢話，直到你真的開始寫 spec，才會發現自己以前的安全敘述到底有多少是靠默契撐著。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781843604076-je8a.png\" alt=\"Nitro 把隔離拆成可證明的數學\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>他們證明的性質分成四類：confidentiality、integrity、functional correctness，還有 absence of runtime errors。這個切法我覺得很合理，因為 VM 隔離本來就不是「程式沒 crash」而已。真正重要的是，別的 VM 不能偷看你的東西，也不能亂改你的狀態。\u003C\u002Fp>\u003Cp>也就是說，這個 engine 不只是「寫得比較安全」，而是有 machine-checked 的理由去說：guest memory 重新使用前會被清掉、只有授權過的資訊流可以發生、實作行為符合規格。這跟「我們有 review 過」不是同一個層級的句子。\u003C\u002Fp>\u003Cp>我以前看過太多 \u003Ca href=\"\u002Ftag\u002Fcode-review\">code review\u003C\u002Fa> 裡的「secure」其實只是「我們沒看到明顯問題」。那真的不算安全敘述。形式化規格的好處，就是逼你把「authorized」「reuse」「guest state」這些詞講清楚，不能再靠大家腦補。過程很痛，因為它會把模糊地帶全翻出來；但那也正是 bug 常躲的地方。\u003C\u002Fp>\u003Cp>實操上，我會先用白話把性質寫乾淨，完全不要行銷腔。接著把每條性質變成可檢查的條件。你如果說不出什麼情況算違反，那你其實還沒有 spec。\u003C\u002Fp>\u003Cp>想看這套東西背後的工具鏈，可以直接看 \u003Ca href=\"https:\u002F\u002Fisabelle.in.tum.de\u002F\">Isabelle\u002FHOL\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.nitro-enclaves.org\u002F\">AWS Nitro\u003C\u002Fa>，還有前面那篇 \u003Ca href=\"https:\u002F\u002Fwww.amazon.science\u002Fblog\u002Fec2s-formally-verified-isolation-engine-provides-mathematical-assurance-of-virtual-machine-isolation\">Amazon Science 文章\u003C\u002Fa>。你選什麼 formal language，會直接影響你能說出什麼樣的保證。\u003C\u002Fp>\u003Ch2>他們證明的是邊界，不是整個雲\u003C\u002Fh2>\u003Cp>我覺得 Amazon 這次最成熟的地方，是 scope 夠清楚。Nitro Isolation Engine 不是整個雲，它是 VM 隔離的 enforcement point。Nitro Hypervisor 仍然管 policy，像 VM 建立、資源分配、遷移、排程這些事，但它被 deprivilege 了，碰 guest state 前得先問 engine。\u003C\u002Fp>\u003Cp>這種架構很乾淨。policy layer 可以很吵、很複雜、很產品導向；enforcement layer 則維持小、可審、適合證明。對客戶來說，這也給了一個具體的信任錨點：真正守 VM 邊界的那個元件，才是被數學處理過的地方。\u003C\u002Fp>\u003Cp>我看過太多團隊把這條線搞糊。嘴上說整個平台都安全，但實際上 enforcement logic 散在一堆服務裡。出事後大家只會互踢皮球，因為沒人知道哪一層才是最後決策者。Amazon 的做法至少避免了這種亂象。\u003C\u002Fp>\u003Cp>實操寫法是：如果你有一條安全邊界，就只允許一個元件做最後裁決。其他模組只能提 request，不能直接碰受保護狀態。這樣測試比較好寫，audit 比較好看，證明也比較有機會成立。\u003C\u002Fp>\u003Cul>\u003Cli>policy 放外層。\u003C\u002Fli>\u003Cli>enforcement 放核心。\u003C\u002Fli>\u003Cli>所有狀態變更都要穿過同一個核心。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>另外一個我在意的細節，是 Amazon 說 Nitro Isolation Engine 對 Graviton5 使用者是 always-on。這表示它不是 demo mode，也不是某個特殊開關，而是實際 production path。這很重要，因為 proof work 很容易在 paper 裡看起來很漂亮，真正在流量下能不能站住腳，才是另一回事。\u003C\u002Fp>\u003Ch2>330,000 行不是炫耀，是成本帳單\u003C\u002Fh2>\u003Cp>Amazon 說 Isabelle\u002FHOL 的模型和證明總共 330,000 行，規模跟 seL4 差不多。這個數字如果拿來當噱頭，我覺得很無聊；但如果拿來當成本帳單，我反而覺得誠實。因為它告訴你：要對一個真的有用的系統做嚴格保證，本來就不會是幾十行定理那麼輕鬆。\u003C\u002Fp>\u003Cp>這裡提到 \u003Ca href=\"https:\u002F\u002Fsel4.systems\u002F\">seL4\u003C\u002Fa> 很合理，因為 seL4 長年就是大家講 proof-based OS 時最常拿來當例子的專案。Amazon 等於是在說：我們現在把這種等級的形式化工作，搬進商業雲 hypervisor，而且還是跑在 production hardware 上。\u003C\u002Fp>\u003Cp>這件事真正的意思，不是 proof 要維持微型，而是你要把「需要被證明的那一小塊」維持得夠小。證明本身可以很大，但 proof target 必須夠小，否則就會直接爆掉。這是完全不同的工程折衷。\u003C\u002Fp>\u003Cp>我看過很多人低估 proof size，因為他們腦中以為 theorem 就是一小段漂亮文字。不是。工業級 verification 是工程資產，要命名、要結構、要維護。這種東西不是研究展示品。你如果對這件事不舒服，我反而覺得正常，因為安全聲明本來就不該輕飄飄。\u003C\u002Fp>\u003Cp>實操上不要問「我們能不能週末做完證明？」要問的是「系統裡哪一塊值得這個等級的 rigor？」先定義範圍，再把 proof 當正式工程排進去，不要把它當學術表演。\u003C\u002Fp>\u003Cp>如果你想往下挖，Amazon 文章有提到 white paper 跟 re:Invent 2025 的 talk。這些材料通常會把 scope、assumption、限制講得比 blog 更清楚。我如果要評估這種保證是不是我真的需要，我會先看那裡。\u003C\u002Fp>\u003Ch2>這篇真正值得學的是架構上的謙虛\u003C\u002Fh2>\u003Cp>我覺得整個故事最有價值的地方，不是他們用了 Isabelle\u002FHOL，也不是因為 Rust，也不是 330,000 行這個數字，而是他們承認原本的系統太大，不能直接拿來驗證。所以他們先改架構，改到 proof 變得可能。\u003C\u002Fp>\u003Cp>這種態度很少見。很多團隊把 formal verification 當成可以外掛的 badge，架構不動、複雜度不動、邊界不動，然後叫 theorem prover 幫忙蓋章。順序完全錯了。架構必須先配合。\u003C\u002Fp>\u003Cp>Amazon 的 policy\u002Fenforcement split 就算你永遠不做 proof，也一樣有價值。它讓責任更清楚、耦合更少、審查目標更小。形式化驗證只是把這些好處變得更難裝沒看到而已。\u003C\u002Fp>\u003Cp>實操上，我會這樣問團隊：當一個系統太複雜、太難推理時，不要只加測試。先問哪些東西可以拆開、降權、或收斂成更小的 trusted core。如果答案是「沒什麼能拆」，那通常就是問題本身。\u003C\u002Fp>\u003Cp>而且對雲端客戶來說，真正該在意的不是 proof 本身，而是讓 proof 成立的那個架構。因為產品不是證明，產品是那個能被證明的系統設計。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># 形式化驗證友善的安全核心模板（可直接改成你們的設計稿或 RFC）\n\n## 1) 先定義邊界\n- 用一句話寫出這個元件負責的安全性質。\n- 範例：\"This component enforces isolation between tenants\u002FVMs\u002Fprocesses.\"\n\n## 2) 把 policy 跟 enforcement 分開\n- Policy 決定要做什麼。\n- Enforcement 決定能不能做，並且真的執行狀態變更。\n- Enforcement core 必須是唯一能碰敏感狀態的地方。\n\n## 3) 把 trusted core 壓到最小\n- 把跟安全邊界無關的東西搬出去：\n  - scheduling\n  - device drivers\n  - feature flags\n  - product-specific glue\n- 留下的只應該是「沒它就沒有安全保證」的程式。\n\n## 4) 限制實作語言子集\n- 先定義 safe subset。\n- 禁掉會讓推理變難的語言特性，除非真的必要。\n- 優先選簡單資料結構與明確狀態轉移。\n\n## 5) 寫出可機器檢查的 spec\n每條性質都要寫：\n- 必須永遠成立的事\n- 什麼算違反\n- 作用範圍有哪些 state \u002F input\n- proof 可以接受哪些 assumptions\n\n## 6) 至少證明四類性質\n- Confidentiality：沒有未授權資訊流\n- Integrity：沒有未授權狀態修改\n- Functional correctness：實作符合 spec\n- Safety：沒有 runtime error、沒有 memory unsafety\n\n## 7) 讓外層系統只提 request，不直接裁決\n- 外層可以建立、排程、分配、遷移。\n- 但它不能自己碰受保護狀態。\n- 每個敏感動作都要經過 core 的 allow\u002Fdeny 或由 core 直接執行。\n\n## 8) 把 proof 當工程資產\n- 清楚寫 scope。\n- 清楚寫 assumptions。\n- 清楚寫沒證明什麼。\n- 把 proof 當需要維護的 artefact，不是一次性展示品。\n\n## 9) 架構草圖\n[Policy layer]\n- VM creation\n- Resource allocation\n- Scheduling\n- Migration\n- Product-specific features\n\n        |\n        v\n\n[Verification boundary]\n- Authorization check\n- State transition\n- Guest-memory scrubbing\n- Isolation enforcement\n- Error handling\n\n        |\n        v\n\n[Protected state]\n- Guest memory\n- VM metadata\n- Isolation metadata\n- Device access state\n\n## 10) Spec 起手式\n- The enforcement core never allows two tenants to observe each other’s protected state.\n- Any reused guest memory is scrubbed before reassignment.\n- Every state transition is authorized by the core.\n- The implementation never performs an out-of-bounds access.\n- The implementation never dereferences invalid memory.\n\n## 11) Review checklist\n- Proof target 能不能用一段話講完？\n- Outer system 壞掉會不會直接破壞 isolation？\n- 每個敏感轉移是不是都走同一個 core？\n- runtime \u002F memory safety 有沒有算進主張裡？\n- assumptions 有沒有寫出來，而不是默認大家懂？\n\n## 12) 給團隊的 prompt\n\"找出最小的子系統。只要把它證明對了，就能對安全邊界有信心。把其他東西都移出 proof target。接著定義要證明的性質、允許的語言子集，以及我們願意接受的 assumptions。\"\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>我會抄 Amazon 的不是規模，是紀律：\u003Ca href=\"\u002Fnews\u002Fopenai-ipo-prep-policy-hiring-play-zh\">先把\u003C\u002Fa>安全邊界拆出來，然後逼實作去配合 proof，而不是反過來。這才是一般團隊真的用得到的地方。\u003C\u002Fp>\u003Cp>來源主要來自 Amazon Science 這篇文章：\u003Ca href=\"https:\u002F\u002Fwww.amazon.science\u002Fblog\u002Fec2s-formally-verified-isolation-engine-provides-mathematical-assurance-of-virtual-machine-isolation\">amazon.science\u003C\u002Fa>。我上面的大方向解讀、拆解順序跟模板整理是我自己的整理；技術事實與數字則以原文為準。\u003C\u002Fp>","我拆 Amazon Nitro 的做法：把隔離邏輯切成小核心，再用機器檢查的數學證明 VM 隔離。","www.amazon.science","https:\u002F\u002Fwww.amazon.science\u002Fblog\u002Fec2s-formally-verified-isolation-engine-provides-mathematical-assurance-of-virtual-machine-isolation",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781843603985-dhih.png","research","zh","8abdf0aa-3fa8-4123-adec-4b0d3cd6b7de",[17,18,19,20,21],"formal verification","Rust","separation kernel","AWS Nitro","Isabelle\u002FHOL",[23,24,25],"先把安全邊界拆成最小核心，再談證明，不然只是在證明一坨雜訊。","Rust 不是重點，限制到可推理的語言子集才是。","把 policy 和 enforcement 分開，能讓架構、審查和形式化驗證一起變簡單。",0,"2026-06-19T04:32:57.737498+00:00","2026-06-19T04:32:57.71+00:00","0c35a120-52fc-41fc-afa3-d404eb934158",{"tags":31,"relatedLang":34,"relatedPosts":38},[32],{"name":18,"slug":33},"rust",{"id":15,"slug":35,"title":36,"language":37},"nitro-split-kernel-isolation-math-en","Nitro’s split kernel turns isolation into math","en",[39,45,51,57,63,69],{"id":40,"slug":41,"title":42,"cover_image":43,"image_url":43,"created_at":44,"category":13},"e3e27211-1d3e-41d5-bc4e-828679944083","turboquant-does-not-hurt-search-quality-equal-bytes-zh","TurboQuant 在等字節預算下不會傷害搜尋品質","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781857969634-naia.png","2026-06-19T08:32:21.766491+00:00",{"id":46,"slug":47,"title":48,"cover_image":49,"image_url":49,"created_at":50,"category":13},"ed7ed094-2671-4723-8105-a89dc805f8a9","deterministic-multicalibration-optimal-sample-use-zh","確定性多重校準終於達標","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781850776591-fs2z.png","2026-06-19T06:32:28.220144+00:00",{"id":52,"slug":53,"title":54,"cover_image":55,"image_url":55,"created_at":56,"category":13},"b84a7dd2-d3f3-428c-a37f-1ac69cb01d4b","uniego-proxy-teachers-egocentric-video-zh","UNIEGO 用代理教師統一自我中心影片","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781849878221-5dnm.png","2026-06-19T06:17:31.822125+00:00",{"id":58,"slug":59,"title":60,"cover_image":61,"image_url":61,"created_at":62,"category":13},"b630264c-6adf-4808-8c75-2b887020e0d9","diffusiongemma-transparency-measured-zh","DiffusionGemma 的透明度問題被量化了","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781848974850-kk3o.png","2026-06-19T06:02:30.127489+00:00",{"id":64,"slug":65,"title":66,"cover_image":67,"image_url":67,"created_at":68,"category":13},"97b3890c-40b6-4bdd-89b2-4a040d50784e","blackwell-wins-agentic-ai-infrastructure-benchmark-zh","Blackwell 會贏，因為 agentic AI 需要全堆疊基礎設施","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781803972649-hb56.png","2026-06-18T17:32:18.277048+00:00",{"id":70,"slug":71,"title":72,"cover_image":73,"image_url":73,"created_at":74,"category":13},"ba82ac15-7751-4d2c-82b0-3cbbf76b8a09","locus-local-ordinance-corpus-us-zh","LOCUS把美國地方法規變機器可讀","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781764380299-ajfw.png","2026-06-18T06:32:29.60696+00:00",[76,81,86,91,96,101,106,111,116,121],{"id":77,"slug":78,"title":79,"created_at":80},"f18dbadb-8c59-4723-84a4-6ad22746c77a","deepmind-bets-on-continuous-learning-ai-2026-zh","DeepMind 押注 2026 連續學習 AI","2026-03-26T08:16:02.367355+00:00",{"id":82,"slug":83,"title":84,"created_at":85},"f4a106cb-02a6-4508-8f39-9720a0a93cee","ml-papers-of-the-week-github-research-desk-zh","每週 ML 論文清單，為何紅到 GitHub","2026-03-27T01:11:39.284175+00:00",{"id":87,"slug":88,"title":89,"created_at":90},"c4f807ca-4e5f-47f1-a48c-961cf3fc44dc","ai-ml-conferences-to-watch-in-2026-zh","2026 AI 研討會投稿時程整理","2026-03-27T01:51:53.874432+00:00",{"id":92,"slug":93,"title":94,"created_at":95},"cf046742-efb2-4753-aef9-caed5da5e32e","adaptive-block-scaled-data-types-zh","IF4：神經網路量化的聰明選擇","2026-03-31T06:00:36.990273+00:00",{"id":97,"slug":98,"title":99,"created_at":100},"53a0dc54-0371-4e40-8d5e-74e94a73840c","geometry-aware-similarity-metrics-for-neural-representations-zh","超越距離測量：用微分幾何重新理解神經網路","2026-03-31T06:01:01.241968+00:00",{"id":102,"slug":103,"title":104,"created_at":105},"fee7d472-a775-4b1d-bbc2-1e8bca1bbf8b","on-the-fly-repulsion-in-the-contextual-space-for-rich-divers-zh","讓AI繪圖更有創意：用排斥力提升生成多樣性","2026-03-31T06:01:25.439673+00:00",{"id":107,"slug":108,"title":109,"created_at":110},"a9901203-d69b-447b-8854-15d14eab32b4","vision-aided-beam-prediction-cnn-eca-zh","影像輔助波束預測升級 CNN","2026-04-01T10:00:25.8073+00:00",{"id":112,"slug":113,"title":114,"created_at":115},"b55e7dd4-0a24-4b3d-804d-b0309a03f498","triple-band-fss-mimo-antenna-sub-6-ghz-zh","三頻 FSS MIMO 天線瞄準 sub-6 GHz","2026-04-01T13:18:36.857305+00:00",{"id":117,"slug":118,"title":119,"created_at":120},"f68290bd-e7f3-4b30-ba22-dcd4e0130a66","openclaw-1299-repos-eight-weeks-analysis-zh","OpenClaw 1299 個 Repo 的資料解讀","2026-04-02T05:03:45.208411+00:00",{"id":122,"slug":123,"title":124,"created_at":125},"ed9f80eb-eb02-4d35-8ad4-0ddf428751dd","beam-coherence-aware-combining-mmwave-mimo-zh","毫米波 MIMO 的雙階合併法","2026-04-02T05:27:26.897188+00:00"]