週末在評估 Tsuzuri 的前端框架該從 Stimulus 換到哪一套時，為了維持整體的輕量，評估過程中我打開了 Svelte 的教學文件，沒想到全程禁止複製貼上，倒是久違的手寫了一遍程式。

花一小時左右手寫後，我對於 Svelte 用很精簡的語法實作許多功能感到讚嘆，也開始思考讓 AI 實作時，還能找到這樣的驚喜嗎？

近期我印象最深刻的，是 YouTuber 壹加壹開發的 What’Sub 這套字幕工具，大多數情境只要有人需要處理影片字幕，我通常會直接推薦。

然而，時間往回推半年前左右，朋友來問我「有沒有辦法做逐字稿？」「有辦法對逐字稿做翻譯嗎？」的問題時，都有一個前提「不能用雲端」這就讓市面上大多數選項無法使用。

這個時代很棒的一點，就是 AI 讓任何人都能針對自己需求客製化，而 Tsuzuri 剛好在這樣的背景下誕生。

當我們有了標準輸出能力後，執行腳本是否正常就可以順利地被驗證，這表示我們可以開始真正的來把 Ruby 跑在 Kobako 的沙盒（Sandbox）環境下。

解決 mruby 在 WebAssembly 執行的基本條件後，是時候開始考慮能夠有更多實際的應用方式，至少要讓一個腳本可以執行，然後順利看到 Hello World 這樣的訊息，但是 mruby 本身的設計並沒有考慮 WASI（WebAssembly System Interface）環境，因此有很多 Gem 是無法使用的。

在 Kobako：WebAssembly 的記憶體交換中解決了 Ruby 和 WebAssembly 互動的問題，也讓 Ruby 和 mruby 的數值能夠有互相交換的能力，基本上已經把「沙盒（Sandbox）」的問題處理乾淨。

然而 Kobako 的開發仍在非常初期，因為還有許多實際使用才會遇到的問題需要解決，其中一個就是「決定怎麼停下來」這樣的問題。

Sumitsubo 是我用來將「規格」變成實際可驗證程式碼的工具，在 Sumitsubo：把規格做成 Linter 的初期試做中採用了 JSON 來描述規格，然而在調查有沒有相似工具時，意外發現直接讓 Markdown 變成結構化的資訊來源，就可以用寫文件的方式來設計工具。

開發 Kobako 的過程到中後期，一直讓我對於「規格有沒有對齊」這樣的問題困擾著我。理論上規格驅動開發（Spec-Driven Development）是很理想的，但語言模型本身就不是確定性的設計，即使有規格參照也還是會偏移，或者遺漏。

因此 Sumitsubo 這個專案就在最近被設計出來，作為一個通用的檢查工具。

前幾篇說明了選擇 MessagePack 的過程，然而使用 WebAssembly 還要能夠互動，跟原生的套件互動方式有一點不太一樣。

理由是我們要打造的是沙盒（Sandbox）來隔離不安全的程式碼，這表示操作基本上是接近單向的，在沙盒中執行的程式，是不能碰到任何宿主（Host）的記憶體，那麼原本預想的方法呼叫，就需要一些特別的方式來處理。

上週末我在 COSCUP 的演講「讓 AI 接管你的應用，打造微秒級無縫的 Ruby 安全沙盒」分享 Kobako 設計過程中的一些考量，後續的提問被問到在 AI 時代不太需要考慮語言時，為什麼要選 Ruby 呢？

簡單地回答，單純就是「我喜歡用 Ruby 這個語言」然而在 Kobako 的設計，還有很多更深層的考量。

雖然是受到 ruby.wasm 的限制才選擇 mruby 來作為沙盒（Sandbox）的語言，但也不代表跟 CRuby 都使用相同的語言標準（ISO/IEC 30170:2012）就讓這個目標輕鬆實現，相比 CRuby 在 mruby 上有很多限制存在。

這是 mruby 為了能夠在嵌入式系統這類環境運作必要的取捨，相對的輕量的特性剛好也是一種 Embedded Sandbox 的優勢，我們把 Ruby 語言沙盒嵌入到任何語言的這種想法，變成可行的選項。