★ FEATURED ARTICLE 1. 主旨演讲说了什么AI Euphoria 不是 PPT 之喜1.1 从Rails is magic到AI is in the stackRails World 2026 的主旨演讲主题定为AI Euphoria这个词选得很有意思。如果你常年混 Ruby 社区应该知道 Rails 过去的 slogan 是 Rails is magic强调的是框架帮你把繁琐的底层细节藏起来让你专注业务逻辑。而这次演讲的核心关键词从magic转向了euphoria不是简单的口号替换而是一次基调转换AI 大规模进入 Rails 开发者的日常之后那种原本要写两小时、现在五分钟搞定的体验确实是会让人上头狂喜的。我看了演讲回放之后最大的感受是演讲者并没有像很多技术大会那样拿一堆 Future Roadmap 画饼。他现场做了一次真实演示让 AI 直接基于需求描述生成一套完整的 Rails 多租户脚手架包括迁移文件、模型关联、路由、控制器和基础测试然后现场跑迁移、跑测试、打开页面验证。整个过程大概十分钟中途还故意设计了需求变更让 AI 修改数据库结构。这在过去是不可想象的哪怕是 Rails 的脚手架也需要你先有清晰的表结构设计而 AI 连这一步都给你省了它还会主动提出这里需要用 lockbox 加密敏感字段这种建议。所以狂喜不是口号。如果你也经历过手动敲 migration、反复改 schema、被 has_many 关联绕晕的阶段看到 AI 直接生成完整可运行的代码你很难不产生类似的感觉。但演讲里也提了一句非常重要的话Euphoria is a feeling, but software is still engineering.意思是兴奋归兴奋工程问题还是工程问题这就引出了后面我想重点展开的内容。1.2 三个核心信号原生工具链、Agent 化应用、Rails 成为 AI 后端主旨演讲的信息量很大但拉出骨架之后我认为真正有价值的可以浓缩成三个信号。第一个信号是AI 原生工具链全面入驻 Rails 开发流程。这不是指装个 Copilot 补全代码那么简单而是指从项目的生成、测试、代码审查到发布每个环节都有 AI 参与。演讲里提到了一个新的 Rails 官方插件体系能在你执行rails new的时候就根据项目描述自动生成基础结构并在后续的rails generate命令中理解模型之间的语义关系而不是只做关键词匹配。开发者对代码的掌控方式从手写每一行变成了审查、调整、纠正 AI 的结果。第二个信号是Agent 化应用的工程化。Rails 社区终于不再停留在讨论 AI 聊天机器人而是开始讨论如何用 Rails 构建真正有自主行为的 AI Agent。所谓 Agent通俗说就是一个能自己决定下一步做什么的 AI 程序它不只是回答你的问题还会自己去调数据库、查 API、操作文件系统然后基于结果继续决策。演讲用一个客户支持系统做例子用户发邮件说账号被锁了Agent 自动查询用户状态、执行解锁操作、给用户发确认邮件全程不需要人手动介入。而这套系统的后端就是标准的 Rails MVC 结构。第三个信号是Rails 作为 AI 应用后端基座的定位越来越清晰。过去几年Python 在 AI 领域几乎一家独大很多做 AI 应用的人第一反应是 FastAPI。但演讲给出了一个很有意思的论点AI 应用不仅仅是一堆模型调用它需要用户体系、支付、后台管理、任务队列、数据库迁移这些恰恰是全栈框架 Rails 最擅长的领域。你可以在 Rails 里通过一个 API endpoint 调用语言模型然后利用 ActiveJob 处理异步任务用 ActionCable 推送流式响应用 ActiveRecord 管理 Agent 的长期记忆这套组合比想象中更顺滑。这三个信号合并起来其实在说一件事AI 不再是贴在 Rails 边上的一块补丁它开始进入框架的内核。对于 Rails 开发者来说这是一个手艺层面的大洗牌。以前我们拼的是谁更熟悉 API、谁记得更多方法以后拼的是谁能更准确地描述需求、谁能更快审查 AI 生成代码的质量、谁能设计出更好的 Agent 工作流。演讲结尾放了张幻灯片上面就一句话The best Rails developer in 2026 is not the one who writes the most code, but the one who understands the most.我想这句话值得每个 Rails 开发者抄下来。2. 为什么是 RailsAI 时代框架选择的底层逻辑2.1 数据库驱动的 Agent状态持久化被严重低估最近两年我做了不少 AI 相关项目绕了一圈之后对为什么是 Rails有了自己的理解。最核心的一点是Rails 的数据库中心化设计天然契合 Agent 应用对状态管理的需求。你可以把 AI Agent 想象成一个非常聪明但健忘的助手。它每次调用语言模型模型的上下文窗口都是有限的就像助手的短期记忆。如果你不给它长期记忆它下次再找你的时候什么都不记得。长期记忆放在哪里最可靠的地方就是数据库。Rails 的 ActiveRecord 在这方面有碾压性的优势它把表、关联、迁移、验证、查询全部统一在一个抽象层里你写user.orders.includes(:items).where(paid: true)就能拿到结构清晰的数据Agent 完全可以利用这些数据做决策。打个生活化的比方。如果你的 Agent 是一个餐厅服务员它需要在短时间内记住每桌客人点了什么、有没有忌口、上菜顺序是什么。如果让它在对话里硬记很快就会被新信息冲掉。但如果它每次下单都把信息写进一张表格等客人喊它的时候查一下表就行。Rails 提供的正是这套表格系统。pgvector 插件还能给表格增加向量列让 Agent 可以做语义搜索找最近有没有用户抱怨过支付失败这样的信息而不只是精确匹配关键词。我在一个真实项目里验证过这个思路。当时做一个内部知识库问答工具最开始用的是无状态的纯 API 调用问题是用户每问一句模型都要重新理解一遍对话背景稍微复杂的对话就上下文爆炸、token 费用飙升。后来我把对话历史、用户偏好、知识片段全部落进 PostgreSQL通过外键关联到用户表每个会话都能实时读取历史上下文。改造之后token 消耗降了将近一半回答的连贯性反而提升了。这件事让我彻底想明白了很多 AI 项目的瓶颈不在模型能力而在数据架构。2.2 约定优于配置让 AI 生成的代码更可控Rails 最经典的哲学是约定优于配置Convention over Configuration放在 AI 编程这个语境下它有了全新的价值。大模型生成代码的原理是概率预测它读过的训练数据里绝大多数是符合框架惯例的代码。当一个框架高度约定化比如 Rails 规定模型文件名必须是单数、表名必须是复数、控制器命名必须遵循 RESTful 风格AI 生成代码时的猜测空间就被大幅压缩。你让 AI 写一个posts资源的 CRUD它几乎不会在命名上出幺蛾子因为它训练数据里 Rails 项目的写法都长一个样。而如果你的项目是用 Node.js 写的你很可能要被 AI 的随机性气死。没有强约定同一个需求它能给你写出 Express、Fastify、Koa 三种不同风格目录结构一会儿分层一会儿扁平甚至同一个项目里前后两段代码风格不统一。我最近接手过一个 Node 项目就是这样AI 生成的核心模块还好但干活的人不是同一个提示词导致代码风格割裂看得我头皮发麻。反观 Rails 项目AI 生成的东西至少风格是统一的跑起来之后你一眼就能知道去哪找 controller、去哪加 migration。更重要的是Rails 的脚手架和生成器让 AI 的产出可以被快速验证。AI 生成的代码如果是一堆散落的文件你没法轻易验证它有没有副作用、DB schema 对不对。但 AI 生成的是rails generate model的输出格式你可以直接跑bin/rails db:migrate看是否成功再跑bin/rails test看测试是否通过。这种生成后可立即验证的能力是 Rails 在 AI 时代非常大的加分项。你可以用 AI 快速生成一个骨架然后基于骨架不断迭代而不是让 AI 在混沌中盲飞。2.3 社区信号与市场热度为什么这个话题会炸如果把镜头拉远看看热搜词里ai编程、ai agent、ai大模型、ai测试开发这些词条的密度你会发现 AI 与编程的结合已经不是一个技术话题而是市场级的焦虑释放口。Rails World 2026 把主旨演讲定为AI Euphoria本质上是在响应整个行业的集体情绪大家都在拼命找 AI 与自身技能的接合点而 Rails 恰好提供了一个相对稳妥的落脚点。为什么是 Rails 而不是其他框架因为 Rails 社区有一个特质它在技术上保守但在工程效率上激进。二十年里 Rails 一直坚持一套成熟的模式没有盲目追新这让它积累了大量可被 AI 学习的范式化代码。另一方面Rails 又在持续引入现代能力比如 Rails 8 的原生 SQLite 支持、固态缓存Solid Cache、定时任务Solid Queue这些功能让 Rails 可以承担 AI 应用的后台基础设施而不必像以前那样为了队列和缓存去额外部署一堆外部服务。市场信号也很明确。越来越多的独立开发者和中小团队发现用 Rails 做 AI 应用的原型速度极快。你不需要自己训练模型只需要调用现成的模型 API然后把精力放在产品逻辑上。Rails 全家桶提供了一个完整的闭环Devise 做用户认证、ActiveAdmin 做运营后台、ActiveJob 做异步任务、ActionCable 做实时交互。很多 AI 应用项目的非 AI 部分其实占了八成工作量而 Rails 把这些部分的工期压得非常短。这就是为什么Rails 是 AI 应用的最佳后端这句话虽然听起来有点激进但在实践层面是有依据的。3. 实操把演讲落地到自己的 Rails 项目3.1 五分钟搭一个 Rails 大模型 API 的最小示例光说不练没有意义。我带你从零走一遍最基础的Rails 接入大模型 API的流程你跟着做就能跑通。首先确保你的环境里有 Ruby 3.3 以上和 Rails 8。执行rails new ai_bot --csstailwind cd ai_bot然后安装一个 HTTP 客户端 gem。过去大家可能用 rest-client现在我推荐直接用标准库的Net::HTTP也可以上httparty但为了少一个依赖我用Net::HTTP做示例。接下来创建一个简单的控制器用来接收用户的提示词、调用大模型 API、返回结果# app/controllers/chat_controller.rb class ChatController ApplicationController def create prompt params[:prompt] response call_llm(prompt) render json: { reply: response } end private def call_llm(prompt) uri URI(https://api.example.com/v1/chat/completions) http Net::HTTP.new(uri.host, uri.port) http.use_ssl true request Net::HTTP::Post.new(uri) request[Authorization] Bearer #{ENV.fetch(LLM_API_KEY)} request[Content-Type] application/json request.body { model: your-model, messages: [ { role: system, content: 你是一个严格的Ruby技术专家。 }, { role: user, content: prompt } ] }.to_json body JSON.parse(http.request(request).body) body.dig(choices, 0, message, content) end end加上路由# config/routes.rb post /chat, to: chat#create然后用bin/rails s启动服务用 curl 测试curl -X POST http://localhost:3000/chat \ -H Content-Type: application/json \ -d {prompt:解释一下什么是Rails的约定优于配置}这个流程虽然简单但你需要注意一个问题不要在控制器里做同步 HTTP 调用。如果大模型响应慢整个 Rails 进程会被阻塞请求经验稍多就会拖垮服务器。正确做法是把任务塞给 ActiveJob 做异步处理或者用流式响应让用户看到逐字出现的效果。我个人推荐一开始就上流式用户体验完全不同。3.2 用 SSE 实现流式响应告别干等三分钟大模型 API 通常支持流式输出stream也就是说服务器是一块一块地把内容推给客户端的而不是憋一大段完整内容再返回。要实现这个效果Rails 里最轻量的方案是使用 SSEServer-Sent Events配合 Rails 自带的 ActionController::Live。先看控制器怎么写# app/controllers/stream_chat_controller.rb class StreamChatController ApplicationController include ActionController::Live def create response.headers[Content-Type] text/event-stream prompt params[:prompt] # 这里调用大模型的流式接口把每一块文本即时写出 llm_client.stream_chat(prompt) do |chunk| response.stream.write(data: #{chunk}\n\n) end ensure response.stream.close end end对应的前端你可以用原生的EventSource或者 fetch API 配合 ReadableStream 来接收。关键点是SSE 只是单向推送如果用户需要中断输出、发多轮对话你可能还需要配合 ActionCable 来做。实测下来SSE 方案在开发环境用得很顺但部署到 Puma 多线程模式下要特别小心ActionController::Live 会占用一个线程如果并发高了Puma 线程池很容易被打满。如果你预计并发会上去建议把流式交互转移到 ActionCable 的 WebSocket 上或者直接用一套独立的流式服务Rails 只负责业务逻辑。我在生产环境踩过这个坑当时 20 个并发请求就把 Puma 默认线程数吃光了页面全部转圈后来把流式模块迁到独立服务才解决。3.3 给 Rails 加一个 Agent 端点从聊天到自主执行现在做一个稍微进阶的玩法让 AI 不只是回答而是能执行操作。我们构建一个简单的 Agent它根据用户指令决定调用哪个工具Tool比如查天气、查订单、修改状态Rails 负责提供这些工具。核心是一个工具分发器# app/services/agent_dispatcher.rb class AgentDispatcher TOOLS { query_order -(args) { Order.find(args[order_id]).to_json }, update_order_status -(args) { Order.find(args[order_id]).update(status: args[status]); OK }, get_customer -(args) { Customer.find(args[customer_id]).to_json } }.freeze def self.call(prompt, user) # 先让 LLM 分析意图返回 JSON 格式的 tool_call tool_call llm_parse_intent(prompt, TOOLS.keys) tool_name tool_call[name] args tool_call[arguments] raise Unknown tool: #{tool_name} unless TOOLS.key?(tool_name) TOOLS[tool_name].call(args) end end这个设计参照了函数调用function calling的模式。大模型接口会返回一个结构化的调用指令你的代码再根据指令去执行真实的业务操作。Rails 在这里的角色是提供一套安全的工具舱Agent 的每个动作都要受权限控制不能让模型直接执行任意代码。我强烈建议你把 Agent 的每一次工具调用记录下来。建一张表# app/models/agent_log.rb class AgentLog ApplicationRecord belongs_to :user serialize :request, coder: JSON serialize :response, coder: JSON end每次调用都写日志包括用户是谁、模型说了什么、调了什么工具、参数是什么、结果如何。这不仅是审计需要当你发现 Agent 行为异常的时候这张表就是你的破案线索。3.4 用 pgvector 做语义检索给 Agent 装上长期记忆前面提到 Agent 需要长期记忆具体落地我推荐用 pgvector 插件直接在 PostgreSQL 里加向量字段顺畅得很不需要额外引一个向量数据库。先启用插件并添加一个记忆表class AddMemoryTableToAgent ActiveRecord::Migration[8.0] def change enable_extension vector create_table :agent_memories do |t| t.references :user, null: false t.text :content t.vector :embedding, limit: 1536 t.timestamps end end end写入记忆时先调用大模型的 embedding 接口把文本转成向量然后存进embedding字段。查询的时候class AgentMemory ApplicationRecord def self.relevant(query_embedding, user:, limit: 5) where(user: user) .order(Arel.sql(embedding ?, query_embedding)) .limit(limit) end end这个流程实测下来非常稳。向量距离用表示余弦距离取最近的几条作为上下文拼进提示词里模型就能想起这个用户以前讨论过什么。需要注意一点embedding 的生成是外部 API 调用会引入延迟和 token 费用。我的做法是写一个异步的 ActiveJob在对话结束后把内容存进记忆库不阻塞主流程。否则用户每说一句话都要先等半天 embedding体验直接崩。4. 常见问题与排查实录4.1 AI 生成的 Rails 代码跑起来直接挂先查这三个地方AI 生成代码翻车是最常见的但我发现大量问题其实集中在三个固定位置排查起来可以有的放矢。第一是migration 里的数据默认值。AI 经常会在 change_column 里用一个带随机数的默认值比如default: - { uuid_generate_v4() }如果你的数据库不是 PostgreSQL 或者没装 uuid-ossp 扩展跑迁移就会报函数不存在。解决方法是先把数据库类型统一或者在生成后审查一遍 schema。第二是model 里关联的 class_name 拼写。AI 生成belongs_to :order的时候如果对应的模型叫CustomerOrder就会因为找不到Order模型而崩溃。你需要在模型里显式指定class_name: CustomerOrder。审查 AI 代码时先重点扫一遍关联声明。第三是强参数strong parameters的漏配。Rails 7/8 的控制器默认用 Strong Parameters 校验参数AI 生成 controller 经常会漏掉params.require(...).permit(...)导致所有写操作都报ForbiddenAttributesError。这类问题报错信息很明确看日志基本一眼就能定位。我自己的铁律是AI 生成的 migration 必须人工 review 完再db:migrateAI 生成的控制器必须先跑一遍测试再合入主干。这不是不信 AI而是对工程风险的基本敬畏。4.2 流式响应卡住的排查思路如果你发现 SSE 流式响应偶尔吐到一半就停了别急着怀疑大模型接口。多数情况是 Rails 侧的问题。第一次遇到这个情况我排查的顺序是先看 Puma 线程池是否打满再看反向代理/负载均衡的 buffer 设置。注意 Nginx 默认会缓冲代理响应你可能需要在配置里关掉缓冲location /stream { proxy_buffering off; proxy_cache off; proxy_set_header X-Accel-Buffering no; }另一个容易忽略的点是HTTP/1.1 的 keep-alive。SSE 依赖长连接如果你在客户端和服务器之间有某个中间层把连接断开了就会出现只收到一半的情况。开发环境用 Puma 直连通常没问题生产环境就得逐层排查。4.3 性能毛刺大模型调用与数据库连接池争抢当一个请求既要调用大模型 API耗时 2 到 5 秒又要操作数据库时如果数据库连接被长时间占用就会拖垮整个应用。我有个客户项目就出现过这种情况首页加载3秒还打不开查了半天是 ActiveJob 里同步调用大模型占住了数据库连接。我的建议是凡是涉及大模型调用一律走异步作业不要在 controller 或 model 里同步调用外部 API。ActiveJob 默认用的是async适配器开发环境够用生产环境配合 Solid Queue 或者 Sidekiq 都能扛住。另外给数据库连接池加足够的容量Puma 的线程数和连接池大小要匹配。一个粗略的参考RAILS_MAX_THREADS10 DB_POOL20让连接池比线程数多一些避免高并发时请求排队等连接。如果你同时开了很多 ActiveJob 跑 AI 任务他们的并发也会吃掉连接所以预留余量是必要的。4.4 常见问题速查表症状可能原因快速解决迁移失败function does not exist数据库函数/扩展缺失确认插件扩展调整默认值写法ForbiddenAttributesError缺少强参数配置补全 params.require/permitSSE 只收一半Nginx buffer / 连接断开关 proxy_buffering检查 keepalivePuma 线程打满同步调用大模型/SSE 占线程改异步 ActiveJob或迁移到独立流服务聊天没有上下文忘记做记忆存取接入 pgvector 语义存储token 消耗过高每次请求都带超长历史限制历史条数摘要化旧对话5. 我的实践体会与后续扩展建议5.1 用 AI 提升 Rails 开发效率的真实感受讲完技术细节说点我自己的操作体会。经过这段时间大量使用 AI 辅助 Rails 开发我最大的感受是AI 最适合的工作是生成结构而不是解决问题。让 AI 生成一堆 CRUD 控制器、迁移文件、表单视图它又快又好。但是一旦你让它解决为什么这个关联会 N1 查询或者如何设计一套支持多租户的权限模型它的表现就时好时坏需要你反复引导。所以我现在的工作流是AI 负责体力活我负责判断和兜底。代码审查的时间占比明显上升但总工时是降下来了的。给你们一个小技巧给 AI 的提示词里一定要带上你的 Rails 版本和 Ruby 版本。比如Rails 8.0, Ruby 3.4放在最开头AI 就会尽量使用对应版本的语法生成的代码基本不用改就能跑。如果不说版本它经常给你生成一堆旧版的写法比如render :json 这种老语法。5.2 从主旨演讲延伸出的团队落地建议如果你想在自己的团队里推进 Rails AI 的改造我建议不要一上来就做很大的 Agent 平台那样大概率翻车。从最小闭环开始先挑一个内部工具比如客户支持工单分类、知识库检索机器人、日常 SQL 查询生成器用 Rails 把它们做出来跑通用户输入到 AI 反馈的闭环再逐步增加 Agent 能力。团队里一定要有一个人专门负责提示词资产库的建设。所谓提示词资产就是公司内部项目生成的、被验证过的提示词模板比如根据以下自然语言生成 SQL 查询遵循 company_style 规则。数据库表: ...。需求: ...。把这些模板沉淀下来团队效率会显著提高。我在一个咨询项目里帮客户建了这个资产库原本每个新成员要熟悉业务数据结构两周现在用 AI 辅助查询三天就能上手。5.3 最后再分享一个实用小技巧如果你在 Rails 里做 Agent 设计一定要给 Agent 的输出加一层验证器。大模型经常“一本正经地胡说八道”它声称自己更新了订单状态实际上因为权限不足、订单 ID 不存在等原因根本没有成功。所以 Agent 执行工具之后必须把执行结果回传给模型让模型知道真实结果是什么再基于真实结果给用户答复。我在实际项目中曾经因为没有做这层反馈Agent 煞有介事地告诉用户订单已退款结果订单还挂着直接引发客诉。自从强制加了结果确认并反馈这一步这类问题基本绝迹。AI 时代做 Rails 开发兴奋是真实存在的但这种兴奋必须建立在扎实的工程底线之上。狂喜没错醒来之后把地基打好才真正算数。
阅读完成 · 觉得有帮助？
