Chris Oliver 談 Rails 為什麼在 AI 時代吃香：一支 1 分 44

來源：LinkedIn｜Phoenix Health（多倫多）Industry Discussions Episode 06
講者：Chris Oliver（GoRails 創辦人）
影片長度：1 分 44 秒｜整理日期：2026-07-28
原始貼文與完整逐字稿備份於 sources/2026-07-28-chris-oliver-rails-ai-linkedin-video.md

Chris Oliver 在多倫多 Phoenix HQ 的錄影現場。畫面截自原影片 01:10。

摘要

這支影片很短，論點也不新，但它把「Rails 為什麼跟 AI 合得來」講成了四句可以直接拿去說服人的話。我把它整理下來，是因為我們這邊常常要回答同一個問題：既然 AI 都會寫程式了，為什麼還要挑 Rails。

Chris 的答案是：AI 是在既有的程式碼上訓練出來的，所以哪個框架的慣例累積得最久、寫法最一致，AI 在上面就最準。Rails 二十年的約定本身就是訓練資料。

我同意這個方向，但他給的入門建議（讓 AI 幫你除錯 production 錯誤）我覺得已經是兩年前的門檻了。後面我補三件我們這邊實際踩過的事。

他說了什麼

一、Ruby 可以被塑造成你自己的方言。

Rails works incredibly well with LLMs because Ruby as a language allows you to really take the language and turn it into your own dialect.

這句是整支影片的第一句。意思是 Ruby 的語法彈性讓你能把領域概念直接寫成語言的一部分，而不是包在一堆樣板底下。對 LLM 來說，讀到的東西愈接近問題本身，猜錯的機會愈小。

二、二十年的慣例就是 AI 的訓練資料。

you can use the tried and true methods that have been baked into everybody's code and applications for many years, which AI has been trained on.

這點是我覺得最值得拿去講的。很多人比較框架時比的是功能，但在 AI coding 的情境下，真正的變數是「網路上有多少寫法一致的範例」。Rails 因為約定優於設定，全世界的 Rails 專案長得都很像，這種一致性直接變成 AI 的準確度。

三、可讀性：不會寫程式的人也改過他的程式碼。

I've worked with people who aren't programmers at all, and they've edited my code because they can read it. It reads like English.

他舉的例子是括號可以省略、方法名可以用問號結尾，所以讀起來像英文句子。他說每次看到不會寫程式的人讀懂 Ruby，他都還是覺得很驚訝。

人讀得懂的東西，LLM 也讀得懂。這兩件事是同一件事。

四、入門建議：先讓 AI 幫你除錯。

The easiest way to get in to using AI with Rails is just to have it debug your errors that are happening in production.

五、進階：先想清楚功能怎麼做，再讓 AI 生成。

AI can be incredibly valuable for asking for advice, but also to have it generate the code when you know how you want to build a feature.

我想補的三件事

一、第三點在醫院場景的價值比他講的還大

Chris 講可讀性時舉的例子是「非程式設計師能改我的程式碼」。這在一般產品公司是加分，在醫院是關鍵。

我們的規則有一大半不是技術規則，是健保規則、臨床規則、行政規則。這些規則的正確答案不在我這裡，在護理師、藥師、個管師那裡。如果程式碼寫成他們讀不懂的樣子，驗證的唯一辦法就是等它上線出錯。

Ruby 的可讀性讓我可以把一段規則印出來，指著問「這樣對嗎」。這件事省掉的不是工時，是誤判。

二、第四點是兩年前的門檻，不要停在那裡

「讓 AI 幫你除錯 production 的錯誤」當入門建議沒錯，但如果你今天才開始，直接跳過這一步也可以。

現在真正有差別的是把 AI 放進一個有紀律的流程：先討論、再提案、確認後才動手、動完歸檔。重點不在 AI 寫得多好，在於每一次改動都有一個你看過並且同意的提案。這條線一旦鬆掉，AI 產出的速度會直接變成技術債累積的速度。

我們這邊的做法整理在〈我的 agentic workflow：NanoClaw、Claude、Spectra 與 Rails〉。

三、「AI 訓練資料多」這個優勢有保存期限，但沒有大家想的那麼短

有人會說，等其他框架的資料也累積夠了，Rails 這個優勢就沒了。我覺得沒那麼快，因為累積的不只是數量，是一致性。一個框架如果本來就允許十種寫法，再多寫十年也還是十種寫法。

不過這個論點不能無限用下去。真正撐住 Rails 的還是那件老事情：一個人可以從想法做到上線。AI 只是把這段路又縮短了一次。

補充：這跟台灣在推的 CQL 是同一件事（2026-07-28 加）

看完影片我第一個反應是，Chris 講的可讀性，跟現在台灣醫療資訊圈在推的 CQL 概念非常像。

CQL（Clinical Quality Language）之所以長成那個樣子，就是為了讓臨床專家自己讀得懂邏輯。它不是為了讓程式跑得快設計的，是為了讓一條照護缺口的判斷條件、一個品質指標的分母分子，能夠攤在醫師面前被檢查。這跟 Chris 說「不會寫程式的人改過我的程式碼」是完全同一個目標，只是兩個社群各自走到的。

把他影片的第一點和第三點合起來看會更清楚。他說 Ruby 可以被塑造成你自己的方言，又說 Ruby 讀起來像英文。這兩句合起來的意思就是：Ruby 讓你自己寫一套像 CQL 的東西出來。

那什麼時候該用哪個。我目前的分法是這樣。

用 CQL 的時機：這條規則要跟別人共用。品質指標、照護缺口、事前審查這一類，規則本身是政策定的，不是你定的，而且未來很可能要跟其他醫院對答案。這時候標準的價值大於方便，值得付出那套基礎建設的代價，翻譯成 ELM、包成 Library 資源、ValueSet 要有 terminology service 撐著。

用 Ruby DSL 的時機：這條規則只有你們家在用。院內流程、行政規則、跟你們資料結構綁在一起的判斷。這種東西寫成 CQL 反而是折磨，因為它本來就沒有要跟誰交換。用 Ruby 寫成讀得懂的樣子，成本幾乎是零，你不用多養一顆引擎。

兩個都不用的時機也存在。如果那條規則三個月會改五次，而且只有一個人在用，寫成設定檔就好，不要為它蓋 DSL。

要提醒一件事：Ruby DSL 讀得懂是給人看的，可攜性是零。你寫得再漂亮，別家醫院也拿不走。這是它跟 CQL 最大的差別，也是決定要用哪個時真正該問的問題：這條規則將來要不要離開這家醫院。

細節見〈HAPI FHIR 內建 CQL 引擎：clinical reasoning 模組怎麼用〉。

給同伴的三個可以馬上做的

下次有人問「為什麼不用比較新的框架」，用第二點回答。不要比功能，比一致性，比 AI 在上面的準確度。這是對方沒想過的角度。
把一段你負責的業務規則印出來，拿去問實際在用的人。如果他讀不懂，那不是他的問題，是那段程式碼寫得不夠像規則本身。
如果你還停在「讓 AI 幫我除錯」，把下一步設成流程而不是工具。先建立提案與確認的習慣，再談要用哪個模型。

Chris Oliver 談 Rails 為什麼在 AI 時代吃香：一支 1 分 44 秒的影片，和我想補的三件事

摘要