Ruby 的 ri 命令在 Coding Agent 的潛力

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

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

脈絡

脈絡（Context）或者說上下文在目前 LLM（Large Language Model，大型語言模型）的應用中幾乎影響了大部分的生成品質。

這是因為當我們能夠提供足夠的資訊給 LLM 的時候，更容易找出相對應的關鍵字用於後續內容的生成，而 Coding Agent（程式撰寫代理）在撰寫過程中，如果遇到無法確認的使用方式時，能夠自主地透過工具來搜尋文件，進一步提高撰寫正確程式的機率。

然而使用搜尋工具並不一定是精確的，他可能混雜許多不同人的個人見解或者錯誤資訊，此時套件提供的「官方文件」反而是品質極高的參考標準，如果能先確認官方文件再判斷是否需要尋整更多參考，遠比直接使用搜尋更好。

在這樣的前提下，使用 ri 命令作為優先的的選項是非常理想的，例如我們想要確認 Array#map 的標準使用方式，只需要透過 ri Array#map 就可以得到正確的資訊，而且不會浪費太多的上下文。

限制

不過，使用 ri 仍有些限制存在，在一些簡單的檢驗中，我很難讓 Coding Agent（如：Claude Code）自然的選擇使用 ri 技能來查詢文件，而不是依靠搜尋或者利用 #source_location 方法直接閱讀原始碼。

在 Claude Code 中，我對 Agent Skill 的描述已經是比較強制性的建議，但是 LLM 的不確定性還是很難確保優先使用 ri 去確認文件，也許會在未來找到更好地說明或者等待 LLM 改進後得到改善。

現階段折衷的方式是提供一個 /ruby:info 的命令，明確的說明使用 ri 技能查詢文件。

/ruby:info how to use expect in rails params

像這樣就會先使用 ri expect 確認一個相關的 ActionController::Parameters#expect 方法，再使用 ri 'ActionController::Parameters#expect' 讀取文件，並且向使用者說明。

另一方面，我目前還無法確定 ri 是否會優先參考 Gemfile 中所定義的版本，以及我們過去使用 bundle install 所安裝的套件是否都會預設加入 ri 文件，這些都限制了我們讓 LLM 善用這個存在已久的工具。

潛力

整體而言，使用 ri 會是一個遠比從網路搜尋資料來確認的文件，不論是速度或者對 Token（詞元）的消耗而言，都是更加有效率並且精確的方案。

但這也受到許多限制，像是 Ruby 生態系中存在 RDoc 和 YARD 兩種體系，即使 RDoc 能解析 YARD 的內容但呈現也會受到一些限制，是否會對 ri 讀取文件造成影響也需要確認。

RDoc 的 HTML 呈現已經由 Stan Lo 的貢獻變得非常容易使用，我認為應該多加善用 Ruby 原生的 RDoc 來為套件撰寫文件

另外，在我的測試過程中也有許多套件無法順利呈現文件，即使我知道存在這個方法，可能使我在使用上有問題，或者我的電腦並沒有安裝到這些以 ri 格式保存的文件，這都讓 LLM 直接使用 ri 確認文件的使用受到限制。

實際上我私心希望 ri 也能支援對當下目錄的預設偵測，這樣對開始利用 Coding Agent 維護 Gem 的開發者也會更友善，不用讓 Coding Agent 搜尋原始碼，而是先從文件下手，速度遠比使用 ls 快得多