關於 #Ruby 的內容

Kobako 的開發過程中有蠻多有趣的案例，延續上一篇 Kobako：用 AI 開發終究會翻車？的經歷，後續又再次撞到新的問題，而且是過去開發很擔心看到的 Segmentation Fault 錯誤，這表示在 Rust 和 WebAssembly 這段非 Ruby 的地方，很高機率做錯。

上週發表 Kobako：讓 Agent 安全的操作 Rails 介紹 Kobako 這個 Gem 的目標後，繼續透過 Claude Code 推進開發進度，然而很快地就遇到要大幅度修改的狀況，這難道就是使用 AI 開發的宿命嗎？

這是很值得討論的問題，也就是使用 AI 協助開發，到底是因為 AI 能力不足所以做不好，還是人類給的設計太差。

今年 RubyKaigi 2026 時，剛好在跟朋友聊 Harness Engineering 提到 Sandbox 的部分，覺得 Ruby 語言目前還沒有比較完善的解決方案，剛好第二天晚上的 Code Party 被分配到 druby（Ruby 語言內建的分散式系統）組別，讓我有了靈感，讓 Kobako 被設計出來。

最近 Hono 框架推出了 Hono CLI 工具，我很快的就幫 Claude Code 製作了 Hono Plugin 加入 Agent Skill 支援使用 Hono CLI 查詢文件。

同時我也想到，我很少使用的 ri（Ruby Information）命令，跟 Hono CLI 提供的功能非常相似，因此提早將 Ruby Plugin 製作出來，提供 ri 技能。

經過一週左右，根據 2024 年底 ihower 的淺談 LLM-based AI Agents 應用開發演講提到的核心概念，用了數百行程式碼完成 Autoflux 這個設計給 Ruby 的 AI Agent 框架，設計過程中反覆修改時思考了一些問題，很值得分享給大家參考。

最近因為工作的關係稍微回顧了一下 Open Policy Agent 而發現了 AWS 推出的 Cedar Language 更適合在軟體應用上實現類似 AWS IAM 的 Policy（政策）機制，因為是以 Rust 為基底，為了讓 Ruby 可以使用，就決定嘗試使用 Rust 來撰寫 Extension。

我們現在處理好保存狀態的機制，目前還剩下 POST /api/checkout 的實作還沒加入到裡面，除此之外每次開啟前端時也無法看到最新的購物車狀態，我們要來將這些情境處理到可用的情形。

使用 ActiveModel 將資料轉換成模型物件後，我們可以繼續利用 ActiveRecord 來跟資料庫整合，達到持久化資料的效果。接下來我們會修改現有的實作，讓資料可以持久化的被保存起來。

ActiveRecord 是基於 ActiveModel 所以製作的，因此我們只需要少量的重構就可以實現持久化保存的效果。

我們已經初步的完成可以給前端使用的 API 實作，然而在這個狀態下後端並沒有實際保存資料的能力，也有一些不好的實作方式（如：@@items 的 Class Variable）因此接下來我們要整合 SQLite 來作為持久化儲存的機制。

我們目前已經將商品資料的基礎 API 實現，接下來讓購物車新增、移除商品的行為也從前端轉移到後端，這段我們會需要加入相對多的調整來實現。