Mike Chong

DHH 錯了：Rails 並不適合 AI 時代的開發

2025年8月28日

近年來，圍繞「Rails 是否仍是最佳生產力框架」的討論再起。我的結論很直接：在 AI 原生（AI‑native）的產品與工程范式下，Rails 的核心假設與關鍵瓶頸，使它很難成為最佳選擇。

這不是對 Ruby 語言的否定，而是對「單體全棧、約定優於配置、伺服器渲染 + 胶水式 ActiveRecord」這套哲學，與 AI 工程實際需求之間的結構性不匹配的討論。

为什么 Rails/Ruby 不再适合 AI 编程

Rails不太适合AI编程，我觉得有如下几个原因。

第一点，Rails是没有强类型的，这个没法工程化。你可能有说，比如说Shopify和Stripe规模是用了Ruby，Ruby他们即使是在这种超大型的项目使用也是需要一个类型检查器的。如果没有类型检查器是没办法，这个对AI来说也是，AI如果没有类型检查器，它可能写出来很坏的代码，你一开始没有检查到，最后会出现差之毫厘，谬以千里的结果。第一点，Rails是没有强类型的，这个没法工程化。你可能有说，比如说Shopify和Stripe规模是用了Ruby，Ruby他们即使是在这种超大型的项目使用也是需要一个类型检查器的。如果没有类型检查器是没办法，这个对AI来说也是，AI如果没有类型检查器，它可能写出来很坏的代码，你一开始没有检查到，最后会出现差之毫厘，谬以千里的结果。

第二点是Ruby on Rails的前后端体系过度约束。David他个人不喜欢现在的前端的工具链，但是如果你想要前端工具链的话就没有什么official solution。我知道有一些不错的solution，但是都不是官方的。像Rails这种框架如果不用官方的solution，未来的迁移和维护成本会非常高，这也是我最大的concern之一。第二点是Ruby on Rails的前后端体系过度约束。David他个人不喜欢现在的前端的工具链，但是如果你想要前端工具链的话就没有什么official solution。我知道有一些不错的solution，但是都不是官方的。像Rails这种框架如果不用官方的solution，未来的迁移和维护成本会非常高，这也是我最大的concern之一。

第三点就是说，它的生态已经远远落后于Node.js、TypeScript和Python。为什么这么说呢？因为举个例子，像AI的工具库，地球上没有第二个工具库像Vercel的AI SDK一样更全面。这只是AI这方面，还有比如说Mobile移动端开发没有React Native和Expo这么好的东西。Ruby在很早期会有一个框架商业的会花钱的叫Ruby Motion，但是它早就已经过时了。所以我作为一个十多年经验同样也是Ruby和Rails的开发者来说，我不会再用它做任何新项目了。第三点就是说，它的生态已经远远落后于Node.js、TypeScript和Python。为什么这么说呢？因为举个例子，像AI的工具库，地球上没有第二个工具库像Vercel的AI SDK一样更全面。这只是AI这方面，还有比如说Mobile移动端开发没有React Native和Expo这么好的东西。Ruby在很早期会有一个框架商业的会花钱的叫Ruby Motion，但是它早就已经过时了。所以我作为一个十多年经验同样也是Ruby和Rails的开发者来说，我不会再用它做任何新项目了。

框架设计：為什麼 AI 原生開發與 Rails 不合拍

1) 架構假設衝突：

  • Rails 假設請求‑回應同步交互、MVC 緊耦合與資料庫中心化。
  • AI 工作流是長時任務、事件驅動、流式（streaming）、多代理協作與外部工具編排。

2) 吞吐與並發模型：

  • 大量 LLM/向量檢索/函式調用需要高併發、非阻塞 I/O、任務隊列與可觀測性鏈路。
  • Rails 傳統堆疊（Puma + ActiveRecord + callbacks）在 I/O 密集場景容易形成瓶頸與 N+1 模式蔓延。

3) 上下文與狀態管理：

  • AI 應用核心在「長期記憶」「對話上下文」「工作記錄與可回放」。
  • 這更適合事件溯源（event sourcing）、append‑only 日誌、向量索引與可組合的管道，而非典型 CRUD 驅動的頁面/表單模型。

4) 多模態與邊緣協作：

  • 語音、影像、文件代理協作需要邊緣與雲之間靈活調度。
  • Rails 的單體形態不利於在不同執行環境（雲函數、Workers、GPU 服務）之間細粒度拆分。

5) 成本與可觀測性：

  • AI 成本主要在推理與檢索路徑，要求對每次 span 做精細追蹤與動態策略（如分級模型、退避、Guardrails）。
  • Rails 傳統監控鏈路更偏頁面請求、資料庫查詢，難以直觀表達「prompt → 檢索 → 工具 → 代理迭代」的全鏈路。

什麼樣的技術棧更貼近 AI 原生

不一定要追逐新潮，而是選擇與「事件、流、任務、可觀測」對齊的設計：

  • 執行環境：雲原生（Serverless/Workers/Queues）+ 可並行的任務編排（Temporal/Cloud Tasks/Workflows）。
  • 通訊模型：HTTP/3、WebSocket、Server‑Sent Events，支援長連線與流式回傳。
  • 資料層：Postgres + 向量索引（pgvector）或專用向量庫；事件日誌（Kafka/PubSub）承載可回放上下文。
  • 服務切分：把「人機回路」「檢索」「工具執行」「評估/觀測」拆成可獨立擴縮的服務或函數。
  • 語言/框架：重視非阻塞 I/O 與輕量組合，如 TypeScript/Node、Go、Elixir、Rust，或 Swift on server（針對蘋果生態）。

Rails 仍可用，但要付出「違背框架」的代價

如果團隊深諳 Rails，也可以疊加以下做法勉強適配：

  • 用 Sidekiq/Queues 轉移長任務；
  • 以 ActionCable/SSE 提供流式輸出；
  • 引入 OpenTelemetry 建立 LLM 與工具調用的 trace；
  • 把檢索與代理服務外掛為獨立服務（非 ActiveRecord 中心）。

問題在於：當你做到這一步，已經在「繞過」Rails 的主要路徑，並承擔了複雜度與一致性成本。

結語

AI 原生開發不是「把 LLM 貼到舊的 MVC 上」。它需要從請求模型、狀態管理、可觀測、成本控制到部署拓撲的整體重構。Rails 作為經典的生產力框架，在傳統 Web CRUD 場景依舊優雅，但面對多代理、流式與任務編排驅動的 AI 應用時，並不是最省心的選擇。

選擇能順勢而為的工具，比選擇你最熟悉的工具更重要。