“Ruby 是最适合 AI 的栈” 只说对了一半

---

先说说那对的一半：写 Ruby 这事，AI 确实拿捏了

过去一年里，你在任何 Ruby 相关的讨论帖里都能看到这个说法：“Ruby 和 Rails 是对 AI 最友好的技术栈。” 理由听起来也很合理——token 更少、幻觉更少、模型写出来的代码干净利落。

我承认，这说法有一半是真的，而且我没什么好争的。另一半嘛，我花了点功夫，在十三个真实的 Ruby 代码库上做了实测，结果画出了一条非常清晰的分界线——它把每个仓库都划到了两边。包括你的。

为什么写 Ruby 这件事对 AI 来说这么顺手？因为 Rails 的“约定优于配置”哲学，不只是为下一个读代码的人设计的。它同样为“下一个读代码的模型”铺好了路。一个见过上万个 Rails 应用的模型，在你还没写一行代码之前，就已经知道 model 该放哪、job 该去哪、concern 是干嘛的、has_many 意味着什么。

所以当你跟它说“写个 service object”、“加个 scope”、“重构这个 controller”——栈本身已经帮模型回答了它一半的问题。更少的错误猜测、更短的反馈循环、更少的幻觉空间，因为代码的骨架已经是明牌。

任何一个用 Rails 干活的人都体验过这个，Ruby 的 AI 友好口碑就是这么来的。我不是来否定这个的。我是想指出，这个能力回答的是一个没人真正处于危险中的问题。

---

那另一半呢：在规模化的 Ruby 里导航，AI 翻车了

“AI 能不能写 Ruby”这个问题已经盖棺定论了。但真正导致线上事故的问题是另一个：AI 能不能在 Ruby 代码库里导航？

比如：这个 model 改了，会破坏什么？谁依赖它？爆炸半径在哪？

当你自己是个熟练的开发者时，读代码和导航代码看起来像同一件事。但对于一个 AI agent 来说，它们完全不是一回事。

• 读一个文件是局部的——答案就在那几行文本里。
• 导航代码是结构性的——答案藏在文件之间的边里：谁调了谁、谁破坏了谁。没有任何一个文件能单独告诉你这个。

所以我在这十三个仓库上跑了同样的测试。任务都一样：选一个核心 model（比如 Chatwoot 的 Inbox、GitLab 的 MergeRequest、Solidus 的 Spree::Order），然后在做 teardown 变更之前，找到所有依赖这个 model 的地方。那些分散的、不明显的依赖项，我手动标记好藏起来了。

测试分两组跑，用同一个模型、同一个 commit：

• 普通 agent：只会 grep 加推理的 agent
• 带结构地图的 agent：同一个 agent，但给它一个可以查询的结构化依赖图

最后对照我藏好的关键依赖，逐行检查每个引用是否命中。

看看这组数据，你就明白了。先看基线召回率，然后看加上结构地图后的召回率：

仓库	核心模型	基线召回率	+地图召回率
Chatwoot	Inbox	0.29	0.97
Mastodon	Status	0.28	0.83
GitLab	MergeRequest	0.26	0.67
Discourse	Upload	0.35	0.75
Solidus	Spree::Order	0.40	0.68
Forem	Article	0.35	0.63
Rails	ActiveRecord::Relation	0.67	0.92

然后，差距突然缩小了：

仓库	核心模型	基线召回率	+地图召回率
Lobsters	Story	0.68	0.79
Redmine	Issue	0.67	0.78
RubyLLM	provider/Chat	0.76	0.80
raix	-	0.60	0.73
llm.rb	provider	0.48	0.48

下面这一组，就是 Ruby 那个“AI 友好”口碑的完美体现。小、可读、代码集中——Ruby 用字面量命名依赖，实现也紧挨着。一个强一点的 agent 直接读完 app/models 就能找到大部分依赖，地图只是多帮你找出一个两个。对于 llm.rb，地图甚至没增加任何答案——只是用少了 1/5 的 token 就得到了同样的结果。这半句话是真的，没有任何星号。

还有一个仓库不属于这两组——langchainrb，基线 0.24 → 地图后 0.41。一个小 gem，但得分却像个单体巨石。原因是：模型“知道”langchainrb，但它知道的是一个已经不再发布的版本——因为这个 gem 迭代太快，训练数据没跟上。记住这个点，后面会回来。

上面那组仓库，就是同一个栈在规模大到可读性不再能缩放时的情况。核心 model 的依赖通过 association、concern、多态、配置字符串注册表，散落在各个目录里——没有任何一个 token 能让 grep 抓到。普通 agent 只能找到一小部分，然后自信地停下来。

这不是 Chatwoot 写得乱。恰恰相反——它分解得太符合教科书了，而教科书式的分解，恰恰把依赖散布到了 grep 够不着的地方。

---

同一个问题，两种规模

这就是问题的本质：同一件事，在不同规模下表现完全不同。

• 在分界线以下：模型能读完整个仓库，地图是多余的。
• 在分界线以上：模型只能从你的代码库里读到一个样本——而且它不会告诉你它读的是哪个样本。

---

两个我没想到的反直觉发现

1. 最小的模型拿到了第二大的提升

我跑了五个模型：两个前沿模型，三个开源模型。提升幅度：

• Opus（前沿模型）：+0.26
• Devstral（最小的开源模型）：+0.24——排在第二，超过了另一个前沿模型和其他所有模型。

这看起来反直觉，直到你想明白原因：地图替模型补上了它自己脑子里装不下的东西。模型自己能装得越少，地图的价值就越大。 模型大小和代码库大小，其实是同一个杠杆从两端拉。

2. 最出名的代码库反而是最难搞的

Forem 就是 dev.to 本身——互联网上被读过最多次的 Ruby 代码库之一。你可能会猜模型处理它应该最拿手。但恰恰相反，它是个警示案例。

一个前沿模型可能部分记住了这个代码库，有时能直接从训练数据里背出核心 model 的依赖——完全不靠任何工具。地图带来的提升确实存在，但那个方差才是真正的教训：一个靠记忆背诵代码库的模型，仍然可能漏掉它今天实际是怎么连接的——而你无法判断自己拿到的是记忆版本还是实时版本。

Rails 是同一个效应的干净版本。每个模型都背过 Rails 源码，地图在那里的全部提升都来自查询编译器的内部逻辑——那些从未进入模型权重的部分。

而之前那个 langchainrb，得分像个单体巨石——它就是过时版本：模型背诵的是一个已经不存在的 langchainrb。名气让代码库被更多背诵，而不是被更好理解。

---

你可能想找的出口——以及它为什么是堵死的

每个读这种文章的人，心里都会默默把自己排除在外：“我的代码很整洁。我的应用分解得很好。如果有隐藏的依赖，我肯定知道。我肯定在下面那组。”

也许你现在确实在。今天在。

但这条分界线不是固定的。当你的代码库大到模型一次读不完时，你就从“grep 就够了”的那一半，滑到了“grep 不够”的那一半。 没有“你已超出 agent 能力范围”的弃用警告。你发现的方式永远是一样的——一个通过了 review 的 diff，三周后，在生产环境里炸了。

而且这条分界线正朝着不利于你的方向移动。

模型读代码的能力越来越强——这就是为什么小仓库那一半已经是平局，而且只会更安全。但你实际上线的应用，增长速度快于上下文窗口的增长。依赖随着代码库的增长而越散越远。

地图获胜的那一半，描述的是真正的生产工作——而且那一半正在变大。

---

为什么“等更好的模型”解决不了问题

这也是为什么“等更好的模型”不是一个答案。更好的模型能读更多代码，所以它会把分界线往前推。但你的代码库也在增长，所以它又把分界线往后推。这是一个你永远追不上的赛跑。

地图不是赌在“弱模型永远弱”上。它是：

• 仓库专属的：基于你当前 commit 的代码构建，没有模型背过它
• 保持新鲜的：代码变了，地图就变
• 模型无关的：通过 MCP 服务任何 agent，换模型不会让你卡住

---

别猜了，测一下

你没法靠推理判断自己在哪一半。在你的代码上跑一下。只要几分钟。

选一个你会在改之前专门安排一个下午小心处理的 model。让你的 agent 直接问：“在我改这个 model 的 teardown 方式之前，找到所有依赖它的地方。” 看它 grep 和猜测。数它找到了多少。

然后给它地图：

curl -fsSL https://luuuc.github.io/sense/install.sh | sh
sense scan    # 在你最熟悉的项目根目录跑
sense setup   # 连接你的 agent

再问一次，对比结果。

• 小且整洁？ 你会看到一个平局——这是真正可信的答案：你的仓库在友好那一半，可以不用操心了。
• 大应用？ 你会看到差距打开。

不管结果如何，你都会拿到那个口碑给不了你的数字：你的代码库到底在哪一边。