本期 Tempest Rust Daily 從 7 篇原始情報整理出 7 則深度摘要，整體可以收斂成四條主線：第一條是 Rust 專案對 AI 協助貢獻畫出第一條正式紅線——rust-lang/rust-forge 上正在審議一份政策提案，要把「LLM 可以參與哪些核心貢獻」明文化；第二條是 Bun 從 Zig 改寫成 Rust 的後續討論，社群開始反思「Bun 走到今天是 Zig 撐起來的」這個歷史脈絡，並把它放在 Rust 與 Zig 的根本設計差異旁邊看；第三條是 Rust 在實戰專案的硬派應用，從解析 Godot .tres 資源圖、到 mRuby + Rust 把物理模擬加速近十倍、再到五天連發 31 個 Rust crate 給小 LLM 用的 dev stack；第四條是 從 C++ 走進 Rust 學習路徑的真實困境。以下是本日 7 則深度整理。
Rust 對 AI 協助貢獻畫紅線
Rust 專案就核心貢獻的 AI 協助劃出正式界線——Rust 程式語言長期把「仔細審查、人類判斷」放在開發流程的核心位置，現在一份新的提案要測試這套文化怎麼面對「幾秒內就能產出程式碼與文字」的工具。四月中旬在 rust-lang/rust-forge 上送出的一份 pull request，目標是把 LLM 在核心貢獻流程裡能做什麼、不能做什麼，明文寫進專案規範。對台灣的 Rust 貢獻者與企業內部評估「AI 協助開源貢獻」政策的法務／工程主管，這份提案是「主流系統程式語言社群第一份明文規範」的指標，值得逐條讀並對照自家的內部規範。原文：[https://ift.tt/BUZo3ge]
Bun 改寫 Rust 後的回望：Zig 撐起來的歷史與兩種語言的設計差
Jiacai Liu 對 Bun 改寫 Rust 的省思：別忘了 Zig 是 Bun 的起點——在討論 oven-sh/bun PR#30412「Rewrite Bun in Rust」之前，Jiacai Liu 想先說一件「沒人在說」的事：Bun 之所以能走到今天，是因為 Zig 撐起來的。Jarred 當年選 Zig 不是因為它「酷」，而是因為 Zig 讓一個小團隊有辦法快速做出 JS runtime 該有的東西。對台灣關注語言選型的工程主管，這篇提供了一個很重要的提醒：當一個專案改寫到別的語言時，工程社群很容易把「目前選擇」當成「最佳選擇」，而忘了原本選擇所帶來的階段性正確性。Rust 是不是 Bun 的最終解暫且不論，但回顧 Zig 在 Bun 早期角色是必要的歷史責任。原文：[https://ift.tt/YfEkDau]
Rust 與 Zig 解同一個問題的方式很不一樣——Shrijith Venkatramana（同時也是在開發 git-lrc 這個跑在每次 commit 上的 AI code reviewer）整理了六個小範例，用對照的方式呈現 Rust 與 Zig 在解同樣問題時設計哲學上的根本差異。這篇放在前一則 Bun 改寫的脈絡裡看特別有意義：當社群在爭「該選 Rust 還是 Zig」時，多半在比表面語法或工具鏈，而真正的差別藏在「面對相同需求時兩個語言怎麼把責任分配給編譯器、執行期與工程師」這層。對台灣同時在評估 Rust／Zig 的系統程式設計團隊，這篇是值得讀完並當成內部讀書會材料的對照分析。原文：[https://ift.tt/GKbTpvy]
硬派 Rust 實戰：Godot 資源解析、物理模擬加速、小 LLM dev stack
用 Rust 解析 Godot .tres 並走完整個 resource graph——作者一開始以為 Godot 的 .tres 檔案很單純：打開像 INI，有 header、有 section、有 key-value，看起來離「幾個 regex 就能解完」只差五分鐘。這個錯覺維持了大約五分鐘——Godot 的 resource 檔其實是一種自訂格式，要把它正確解出來、再順著資源之間的關聯走完整張圖，遠比表面複雜。整篇是作者用 Rust 從頭刻一個 .tres parser 與 resource graph walker 的實作筆記。對在做 Godot 工具鏈、又想用 Rust 寫穩定 CLI 的台灣遊戲開發者，這篇是「不要相信表面像 INI 的格式」這條教訓的活範例。原文：[https://ift.tt/g1NhTBH]
Durable Programming：mRuby + Rust 把物理模擬從 50ms 壓到 3-4ms——Durable Programming, LLC 在做一個複雜的物理系統時，把模擬 tick 時間從約 50ms 壓到 3-4ms，幾乎是十倍提升（官方數字 93%）。手法是把 mRuby 與 Rust 結合，讓腳本層的彈性與 Rust 編譯後執行期的速度同時上桌。對在做遊戲、模擬或機器人等「需要在腳本層快速迭代、又對單 tick 預算極度敏感」場景的台灣團隊，這條給了一個具體的整合範例：不必為了效能放棄腳本層，而是把熱路徑搬到 Rust。原文：[https://ift.tt/1SwFOZG]
五天內發 31 個 Rust crate：給小型 LLM 的 dev stack，全部開源——作者用五天時間在 crates.io 上連發 31 個 Rust crate，每個多半只有 150 到 300 行。重點是它們「不是 framework」——每個 crate 各自修掉一個「把較小型開源模型放到真實任務時會壞掉」的具體問題。整篇是這趟連發的事後檢討：做了什麼、學到什麼、為什麼選 Rust 來實作這條 stack。對在評估「自架小型 LLM 跑生產工作」的台灣團隊，這條提供了一個明顯不同於 LangChain 路線的設計觀點——粒度更細、每個 crate 解單一問題、由使用者自己拼裝。原文：[https://ift.tt/wETR8S7]
從 C++ 走進 Rust 的學習現場
「我真的想學 Rust，請幫我」：一位 C++ 工程師被 Qt5／Qt6 QML 打到想轉——這篇來自一位主力是 C++ 的工程師：日常工作也都是 C++、平時對 C++ 本身沒什麼意見，但 Qt5 與 Qt6 搭 QML 的開發體驗讓他受夠了，於是決定試 iced（Rust GUI framework）——結果在「對 Rust 的掌控感」上達不到自己的期待。他在文章裡公開求教 Rust 學習路線。對台灣同樣從 C++ 想走 Rust GUI 路線的工程師，這則討論的價值不是學習資源本身，而是看到「同類型背景的人卡在哪」——iced 的學習曲線、Rust GUI 框架對 C++ 直覺的反差，是值得當成內部選型評估時的真實樣本。原文：[https://ift.tt/OotYFK4]
本期觀察
把 7 則放在一起看，2026 年 5 月 17 日的 Rust 生態有兩個值得記下的時刻：一是 Rust 專案開始正式處理「AI 怎麼參與核心貢獻」這道題，rust-lang/rust-forge 上的政策提案，標誌主流系統程式語言社群面對 LLM 的第一次明文化嘗試；二是社群在 Bun 改寫 Rust 的浪潮之後開始「回望」——Jiacai Liu 提醒大家別忘了 Zig 撐起 Bun 的歷史責任，Shrijith Venkatramana 則用六個小範例呈現 Rust 與 Zig 解同一題的不同邏輯。實戰側則三線並進：解析 Godot 自訂格式、用 mRuby + Rust 把物理模擬加速近十倍、五天連發 31 個 Rust crate 給小型 LLM dev stack——三件事的共同點都是「Rust 不是只能做底層基建，也能做你今天就要解的特定問題」。最後那則 C++ 工程師求學 Rust 的貼文，則提醒我們：Rust 採用的最後一哩，永遠是「從相鄰語言過來的人是不是真的學得會」這道題。一句話總結：本期是「Rust 社群開始正視 AI、回望 Zig、深入垂直應用」的整理切片。