---
title: "Ruby 的 ri 命令在 Coding Agent 的潛力"
date: 2025-10-29T00:00:00+08:00
publishDate: 2025-10-29T00:00:00+08:00
lastmod: 2025-10-26T19:59:06+08:00
tags: ["Claude Code","Coding Agent","AI","Ruby"]
toc: true
permalink: "https://blog.aotoki.me/posts/2025/10/29/ruby-ri-command-potential-for-coding-agent/"
language: "zh-tw"
---



最近 Hono 框架推出了 [Hono CLI](https://github.com/honojs/cli) 工具，我很快的就幫 Claude Code 製作了 [Hono Plugin](https://github.com/elct9620/claude-hono-plugin) 加入 Agent Skill 支援使用 Hono CLI 查詢文件。

同時我也想到，我很少使用的 `ri`（Ruby Information）命令，跟 Hono CLI 提供的功能非常相似，因此提早將 [Ruby Plugin](https://github.com/elct9620/claude-ruby-plugin) 製作出來，提供 `ri` 技能。

<!--more-->

## 脈絡 {#context}

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

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

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

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

## 限制 {#limitation}

不過，使用 `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 善用這個存在已久的工具。

## 潛力 {#potential}

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

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

> RDoc 的 HTML 呈現已經由 [Stan Lo](https://x.com/_st0012) 的貢獻變得非常容易使用，我認為應該多加善用 Ruby 原生的 RDoc 來為套件撰寫文件

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

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