Rails World 2026 的主旨演讲结束到今天已经三天了我所在的技术群还在反复用“AI Euphoria”这个词刷屏。去之前我预感这会是一场模型功能秀结果整场听下来感受反而像降压——主讲人没有堆跑分没有现场吹嘘 Agent 能替代程序员而是花了一半时间讨论“约束”“回滚”“审计”这些听起来一点也不性感的工程词。如果你和我一样过去一年被各种 AI Demo 搞得既兴奋又疲惫这篇笔记应该能给你一个思考框架Rails 团队到底应该以什么姿态进入 AI 时代。文章里我会把现场 Demo 的关键技术点拆开讲也会补上我自己的实际落地经验。内容集中在 Rails AI 的应用开发、编码工具、生产可靠性这三个层面适合那些已经打算用 AI 做点真业务、但不想被模型和热门框架牵着鼻子走的团队。1. 主旨演讲开篇AI Euphoria 不是兴奋是 Rails 社区的一次自我校准1.1 开场的前二十分钟从狂热到理性的时间线演讲开场抛出了一张时间线把 Rails 社区对 AI 的态度分了四段。2023 年是看见什么都要“接入”一下的兴奋期2024 年不少团队把大模型 API 接进后台后发现成本、幻觉和验收标准全都失控于是进入怀疑期。2025 年大家开始算账一个 AI 功能每个月烧掉多少 token又真正带来多少可量化的收益。到了 2026 年还能坐在会场里的人基本都达成了共识——AI 不是舞台上的主角而是脚手架。真正让大家笑出声的是一张对比图左侧是“用户想象的 AI”右侧是“生产环境里的 AI”。左边是会自动思考的机器人右边是带着超时重试、JSON Schema 校验、审计日志和回滚按钮的普通后端服务。主讲人用这张图定调AI Euphoria 的“狂喜”不应该来自于模型能力又涨了多少而应该来自于你终于找到了自己的坐标系知道哪些地方让 AI 上手哪些地方必须死死抓在人类手里。这个开场很聪明。Rails 社区其实是被大模型时代搅得最不安的一群人因为我们最核心的优势就是“约定优于配置”和“让开发者睡个好觉”。如果 AI 进来以后是一团不确定性那这种改造就是负资产。所以整场演讲其实都在回答一个问题怎么让 AI 变成 Rails 默认值的一部分而不是每次部署都要做一场魔法实验。1.2 核心论点默认值哲学如何迁移到 AI 功能Rails 最宝贵的东西从来不是某个具体功能而是默认值。你新建项目时有目录结构建模型时有命名约定跑迁移时有版本管理。演讲者把这一套直接迁移到了 AI 开发上AI 功能的默认值应该是提示词版本管理、评估集、可观测性和回滚机制。这些东西先立住模型才有发挥空间。现场有个类比很妙传统的rails new生成的是代码骨架未来的rails ai:new生成的是提示词工作流和评估目录骨架。目前这个命令还没有在正式版里落地但思路已经非常清晰。默认值的本质是约束约束越明确模型输出的质量就越稳定。如果你的团队连输出格式都没有固定连失败预案都没有那接再大的模型也只是给混乱加了个加速器跑得快但更容易翻车。我自己听到这里很受触动。过去半年我在做一个客服摘要的功能一开始总想搞一个“万能大脑”把所有流程都丢给模型自由发挥。结果就是同一个摘要格式今天一套明天一套客户根本没法用。后来我把业务流程切成一个个小工具让模型只做路由和组句格式全用代码强制兜底问题立刻缓解。这和演讲里的判断完全一致模型是执行层约束才是架构层。2. 现场最炸裂的 Demo四条命令把 Rails 变成 AI 原生应用2.1 从 rails new 到 AI 原生主线任务只用了一个空白项目现场最长的演示是用一个接近空白的 Rails 项目做“AI 旅行规划”。用户输入三天行程的要求系统根据预算、天气和偏好生成路线还能直接跳转到预订流程。类似的应用很多人用 Node 或 Python 写过但这次演示的重点不是界面而是主体代码量——大约 300 行 Ruby 就完成了从路由、模型、流式输出到回滚的完整闭环。第一印象是生成器设计得很聪明。演讲者用了一个类似rails g ai_agent itinerary的命令生成器同时创建了控制器、服务对象、提示词模板和评估夹具。这里最关键的架构决策是模型没有直接进入 Controller而是被包在一个命令对象里。比如Itinerary::Generate这样一个服务对象负责组装上下文、调用外部模型、校验结果、保存草稿。Controller 依然保持瘦业务规则依然在模型和服务层。AI 只是整个调用链里一个可以被替换的组件。我当时记了下代码思路大概长这样# app/services/itinerary/generate.rb class Itinerary::Generate def call(input) context build_context(input) validate!(context) draft Itinerary.build(parent_id: input[:parent_id], status: :draft) draft.payload ai_client.complete( prompt: PromptLoader.render(itinerary, context), schema: Itinerary::CONTRACT ) draft.save! end end这个结构和我平时在项目里推荐的规则完全一致提示词不散落在 Controller 里模型返回结果不直接写正式数据。先把上下文准备好再把输出锁进一个契约结构最后落库。Rails 的 MVC 结构天然适合做这层封装你不需要引入微服务不需要上复杂的编排框架一个服务对象加上一个结果对象就能稳住。2.2 流式输出与一键回滚两个看起来矛盾但可以共存的设计演示里最让人尖叫的是交互体验。用户侧看到的是 AI 一行一行把行程吐出来用的是 SSERails 里可以通过ActionController::Live或者 turbo_stream 很轻松实现。但真正让我觉得“这个设计值得抄”的是旁边那个“回滚”按钮。AI 生成的行程不会直接覆盖正式记录而是作为草稿写入。表结构大致是这样create_table :itineraries do |t| t.integer :parent_id t.integer :version, default: 1 t.integer :status, default: 0 # draft / confirmed / canceled t.jsonb :payload t.string :model_id t.string :prompt_version t.timestamps end每次生成都是一条新的草稿带有parent_id指向上一版本。用户点“确认”时事务里把旧版本标记为历史版本把草稿提升为正式版本点“回滚”时直接切回上一个有效版本。这个机制成本极低但解决了一个很关键的体验问题AI 功能最常见的失败不是技术报错而是“生成了一个看起来合理但不符合用户预期”的结果。如果没有版本化设计用户只能要么接受要么愤然离开。现场有人问“向量数据库存在哪”演讲者的回答我完全赞同如果你在做 Rails 业务第一个向量数据库可能根本不需要。先把应用数据库里的结构化数据用好用精确查询缩小范围必要时再加 pgvector。只有搜索、推荐这类真正非结构化的场景才值得引入额外组件。对多数业务系统来说RAG 的最佳检索源就是 PostgreSQL 里的几张表和几个索引别看其他框架吹得天花乱坠粘合层简单才是长期能维护的前提。3. 工具箱展示哪种 AI 编码工具进 Rails 工作流是稳赚的3.1 补全、Agent、自动重构三个层级的真实风险工具演示的顺序很有意思从最无聊到最激进。第一类是 IDE 里的自动补全比如 Fitten Code、GitHub Copilot 这类风险最低适合日常快速写 CRUD。第二类是编码 Agent给它一句话它在终端里连续改多个文件甚至自己跑测试。第三类是“自然语言要求整个重构”的交互式模式现场效果很震撼但演示者自己承认这一类必须人工逐行审查。他给了一张工具选择表我回来后凭记忆整理了一下工具类型适合场景主要风险建议的介入方式自动补全样板代码、命名重复度高生成结果有一定随机性靠测试兜底提交前 review编码 Agent跨文件小改动、补测试容易顺手改坏周边代码要求 Agent 输出 diff禁止直接提交自动重构大范围结构调整隐藏的副作用和业务假设必须有完整测试覆盖必要时回滚他强调了一个对我来说很新的动作“反生成审查”。也就是不要用审查人类代码的眼光去看 AI 代码要反过来想哪一行是模型为了迎合提示词而硬凑出来的。模型很喜欢编造不存在的配置项、过度设计接口、修饰命名这些都要靠人来过滤。我试过之后觉得这个动作应该写进团队的 code review checklist比反复调 prompt 更有效。3.2 测试生成才是甜点区业务代码生成是雷区现场最重要的一个判断也是对我最有用的一句话AI 编码工具提升最大的不是生产代码生成而是测试代码生成。原因是测试有明确的正确性边界——失败就是失败成功就是成功机器可以判断。而业务代码是否正确往往要等上线后用户来裁决。他展示了一个 RSpec 文件AI 自动生成了三类测试用例订单状态迁移、权限边界、第三方 API 超时。这些场景覆盖覆盖面比我手写的还要宽。我一开始以为是运气后来发现窍门在于提示词里给了明确的“边界描述”要求模型专门盯着空值、重复提交、并发修改、超时这些反面场景。还有一个很实用的模式用 Agent 自动修测试失败。重点在于只把失败日志和测试文件路径喂给 Agent不给业务背景。这样模型不会瞎猜业务意图只会老老实实修测试本身的脆弱点或者定位到代码层的直接原因。人负责定义意图AI 负责处理令人烦躁的迭代循环。这个分工方式我现在已经在团队里推广了。3.3 提示词也要进 Git模型版本也要进日志演讲里有一个建议是每个 Rails 团队今天就能落地的把提示词当成代码来管理。提示词的每一次改动本质上都是业务逻辑在变它不应该只存在数据库或者后台配置里而应该跟着代码一起合入 PR、参与 code review。更可操作的形式是这样每个业务场景对应一个prompts/xxx.md文件文件里写好模板变量说明和版本号CI 里跑一个静态检查保证模板变量都能被正确替换参考文档没有过期。调用日志里必须记录prompt_version和model_id。一旦线上行为出现偏差你能直接定位到是提示词版本变了还是模型被厂商悄悄升级了。这个外部成本几乎为零但对故障复盘帮助巨大。我回来以后顺手把我们项目的摘要调用改成了这个模式上个星期就排掉一个 A/B 组模型串动的诡异问题靠的就是日志里的summary_v2和summary_v1之差。4. 生产级 Rails LLM我记下的三个反直觉结论4.1 不要用 Retry 代替确定性校验层第二个重头戏是生产环境可靠性的“三个反直觉结论”。第一个是不要把重试当成容错。LLM 调用失败后如果直接重试大概率会得到同一种失败因为问题往往出在输入数据的边界条件上模型本身没有变结果也不会变。更合理的做法是在调用外部模型之前和之后各加一道确定性校验。这道校验层可以很简单比如用ActiveModel::Validations锁住状态枚举值class ItineraryContract ActiveModel::Validator def validate(record) unless %w[pending confirmed canceled].include?(record.status_key) record.errors.add(:status_key, must be one of allowed keys) end end end模型不再直接返回自由的“已送达”“已完成”这种文本而是返回一个枚举 key再由代码映射成用户看到的文案。这个转变很微小但效果立竿见影。我之前的 AI 客服摘要功能就是被“自由文本”坑过后来改成“让模型选择预定义的状态”错误率几乎降到零。模型适合在约束范围内做生成不适合承担数据契约的责任。4.2 上下文不是越长越好先用 SQL 缩小数据第二个结论反直觉上下文窗口越大不等于越智能。演示里做了一个小实验同一道任务背景资料从 8 篇增加到 20 篇准确率反而下降了 5%。原因是资料里一旦有重复、矛盾或者大量无关信息模型会把它们当作噪声注意力被稀释。所以演讲者的建议是把数据筛选交给 SQL而不是交给模型。在 Rails 里就是先where后prompt。先用 ActiveRecord 把数据精确到你知道的范围内再把这些记录按模板组装成上下文最后让模型做摘要或组装。不要把整个业务库或者所有文档变成上下文那只会让模型做更多它不擅长的判断。这与 RAG 的工程实践直接相关。很多团队 RAG 效果不好问题往往不是向量检索不够好而是没有做业务流程的二次分解。订单、发票、用户档案这些结构化数据完全可以直接查库获得不需要靠向量召回。模型应该只在真正非结构化的那部分工作比如语义搜索、推荐排序、自然语言摘要。当你能确定的数据都确定化后幻觉问题的概率会明显下降。4.3 自主容错不是模型变聪明而是能记录、能回滚、能接管第三个结论对应的是“LLM 智能体自主容错控制”这个方向。演讲者认为Agent 的“自主容错”不是让模型看起来更聪明而是让它知道自己错了就主动降级。现场有个演示镜头AI 生成的日程和用户的余额校验冲突Agent 没有继续硬生成而是停下来告诉用户“钱包余额不匹配请先充值”。这一刻全场掌声比任何华丽功能都热烈。能承认自己不知道对模型来说才是真正的可靠。落到工程上我的理解是把决策点暴露给人类。Rails 里可以用ActiveJob的执行历史加审计表记录每次 Agent 的动作调了哪个工具、输入是什么、输出是否通过校验、在哪一步触发了回退。之前我觉得这是重活但现场演示后我发现它其实只需要在服务对象外层包一个 result 对象把每个动作的 input、output、validated 状态写进事件表就行。一旦事故发生了你能像看时间线一样回溯 Agent 的每一步幻觉就从玄学变成了可排查的工程问题。这个审计层比调模型温度、调 top_p 有用一百倍。AI 功能上线之前我会建议每个团队先做这件事而不是先追求准确率。5. 散场后的实践清单把 AI 放进默认值而不是放进银弹5.1 第一批改动单出入口、意图命名、安全开关散场后我在酒店和几个朋友又聊到半夜。把整场演讲压成一份可执行清单最值得先做的是三件事。第一所有 AI 调用必须经过单一入口不要在各 Controller 里东一个西一个。我现在的做法是在app/services/ai/下建统一客户端无论后面接哪个模型外面代码都不用改。第二给每一个业务意图起清晰的名字比如itinerary_generate_v3、summary_v2。这个名字不只是给人看的它必须出现在日志字段、提示词版本号、评估记录的 metadata 里。第三加一个安全开关。AI 功能出错时运维可以直接在 Admin 后台关闭它而不是紧急重部署。这三步花不了多少时间但作用很大。我们内部项目照做后上星期刚好做了一次事故演练客服摘要 A/B 组模型串动因为意图名写错了日志立刻暴露问题。整场排障不到半小时靠的就是记录了prompt_version和model_id的审计表。AI 功能真正让人安心的方式不是永远不出错而是出错了能快速定位、快速止血。5.2 评估集与离线评测部署前先问“评判标准是什么”演讲里关于 AI 模型部署的部分对我触动也很大。他建议把评估做进 CI而不是每次都“凭感觉换个模型试试”。最简单的实践在 RSpec 里准备一组“黄金问题”每个问题都有标准回答或可接受答案。每次改提示词、升级模型版本时跑一遍rails ai:evaluate得到准确率、时效、成本三个指标。这个思路的本质是让模型选型从玄学变成工程判断。现场展示了一个订单自动分派的评估结果找出来的赢家居然不是一个最大的模型而是某个厂商的小模型——因为它在关键路径上更快、更便宜、更稳定。这件事放在以往我会觉得很反直觉但有了评估集一切都有数据支撑。Rails 团队的优势在于本来就重视 fixture 和测试数据把评估集也做成 fixture 是很自然的事。不要一个 LLM 调用散落在三十几个地方应该像测试一样作为一等公民来维护。第一批场景可以从高频且低风险的开始比如标题改写、客服摘要先圈 20 条提问记录每条回答的模型、时长、成本两周后再分析。你会发现思路立刻清晰因为你不再是 “看演示很惊艳” 就换模型而是有一套自己的验收标准。5.3 AI 会帮你写更多业务代码但不会替你拍板整场演讲最核心的密码我留在最后。原话大意是AI Euphoria 只会发生在你信任默认值之后。Rails 社区最擅长的就是把复杂问题收敛成简单约定。AI 也一样提示词怎么存、模型版本怎么记录、输出怎么校验、失败怎么回滚、审计在哪里这些默认点全部立住之后你才有资格谈“狂喜”。否则你只是在为别人的不确定系统买单。我现在越来越认同一个判断AI 会让 Rails 开发者写更多的业务代码而不是更少。因为当模型的边际成本降到足够低很多过去不值得做的边缘功能会进入“可做”的区间。你想给用户加一个按自然语言筛选订单的功能以前要评估语义解析的成本现在可能两天就能做出原型。而 Rails 提供的那套结构恰好能保证这些快速生成的功能不会把系统拖垮。这场主旨演讲没有给我一个让人“哇”一声的大杀器但它给了我一个很稳的框架。别怕 AI 改造 Rails要去改造 AI让它适应 Rails 的默认值、纪律和边界。这是我在会后第三天仍然觉得最有价值的收获。
Rails World 2026 的主旨演讲结束到今天已经三天了我所在的技术群还在反复用“AI Euphoria”这个词刷屏。去之前我预感这会是一场模型功能秀结果整场听下来感受反而像降压——主讲人没有堆跑分没有现场吹嘘 Agent 能替代程序员而是花了一半时间讨论“约束”“回滚”“审计”这些听起来一点也不性感的工程词。如果你和我一样过去一年被各种 AI Demo 搞得既兴奋又疲惫这篇笔记应该能给你一个思考框架Rails 团队到底应该以什么姿态进入 AI 时代。文章里我会把现场 Demo 的关键技术点拆开讲也会补上我自己的实际落地经验。内容集中在 Rails AI 的应用开发、编码工具、生产可靠性这三个层面适合那些已经打算用 AI 做点真业务、但不想被模型和热门框架牵着鼻子走的团队。1. 主旨演讲开篇AI Euphoria 不是兴奋是 Rails 社区的一次自我校准1.1 开场的前二十分钟从狂热到理性的时间线演讲开场抛出了一张时间线把 Rails 社区对 AI 的态度分了四段。2023 年是看见什么都要“接入”一下的兴奋期2024 年不少团队把大模型 API 接进后台后发现成本、幻觉和验收标准全都失控于是进入怀疑期。2025 年大家开始算账一个 AI 功能每个月烧掉多少 token又真正带来多少可量化的收益。到了 2026 年还能坐在会场里的人基本都达成了共识——AI 不是舞台上的主角而是脚手架。真正让大家笑出声的是一张对比图左侧是“用户想象的 AI”右侧是“生产环境里的 AI”。左边是会自动思考的机器人右边是带着超时重试、JSON Schema 校验、审计日志和回滚按钮的普通后端服务。主讲人用这张图定调AI Euphoria 的“狂喜”不应该来自于模型能力又涨了多少而应该来自于你终于找到了自己的坐标系知道哪些地方让 AI 上手哪些地方必须死死抓在人类手里。这个开场很聪明。Rails 社区其实是被大模型时代搅得最不安的一群人因为我们最核心的优势就是“约定优于配置”和“让开发者睡个好觉”。如果 AI 进来以后是一团不确定性那这种改造就是负资产。所以整场演讲其实都在回答一个问题怎么让 AI 变成 Rails 默认值的一部分而不是每次部署都要做一场魔法实验。1.2 核心论点默认值哲学如何迁移到 AI 功能Rails 最宝贵的东西从来不是某个具体功能而是默认值。你新建项目时有目录结构建模型时有命名约定跑迁移时有版本管理。演讲者把这一套直接迁移到了 AI 开发上AI 功能的默认值应该是提示词版本管理、评估集、可观测性和回滚机制。这些东西先立住模型才有发挥空间。现场有个类比很妙传统的rails new生成的是代码骨架未来的rails ai:new生成的是提示词工作流和评估目录骨架。目前这个命令还没有在正式版里落地但思路已经非常清晰。默认值的本质是约束约束越明确模型输出的质量就越稳定。如果你的团队连输出格式都没有固定连失败预案都没有那接再大的模型也只是给混乱加了个加速器跑得快但更容易翻车。我自己听到这里很受触动。过去半年我在做一个客服摘要的功能一开始总想搞一个“万能大脑”把所有流程都丢给模型自由发挥。结果就是同一个摘要格式今天一套明天一套客户根本没法用。后来我把业务流程切成一个个小工具让模型只做路由和组句格式全用代码强制兜底问题立刻缓解。这和演讲里的判断完全一致模型是执行层约束才是架构层。2. 现场最炸裂的 Demo四条命令把 Rails 变成 AI 原生应用2.1 从 rails new 到 AI 原生主线任务只用了一个空白项目现场最长的演示是用一个接近空白的 Rails 项目做“AI 旅行规划”。用户输入三天行程的要求系统根据预算、天气和偏好生成路线还能直接跳转到预订流程。类似的应用很多人用 Node 或 Python 写过但这次演示的重点不是界面而是主体代码量——大约 300 行 Ruby 就完成了从路由、模型、流式输出到回滚的完整闭环。第一印象是生成器设计得很聪明。演讲者用了一个类似rails g ai_agent itinerary的命令生成器同时创建了控制器、服务对象、提示词模板和评估夹具。这里最关键的架构决策是模型没有直接进入 Controller而是被包在一个命令对象里。比如Itinerary::Generate这样一个服务对象负责组装上下文、调用外部模型、校验结果、保存草稿。Controller 依然保持瘦业务规则依然在模型和服务层。AI 只是整个调用链里一个可以被替换的组件。我当时记了下代码思路大概长这样# app/services/itinerary/generate.rb class Itinerary::Generate def call(input) context build_context(input) validate!(context) draft Itinerary.build(parent_id: input[:parent_id], status: :draft) draft.payload ai_client.complete( prompt: PromptLoader.render(itinerary, context), schema: Itinerary::CONTRACT ) draft.save! end end这个结构和我平时在项目里推荐的规则完全一致提示词不散落在 Controller 里模型返回结果不直接写正式数据。先把上下文准备好再把输出锁进一个契约结构最后落库。Rails 的 MVC 结构天然适合做这层封装你不需要引入微服务不需要上复杂的编排框架一个服务对象加上一个结果对象就能稳住。2.2 流式输出与一键回滚两个看起来矛盾但可以共存的设计演示里最让人尖叫的是交互体验。用户侧看到的是 AI 一行一行把行程吐出来用的是 SSERails 里可以通过ActionController::Live或者 turbo_stream 很轻松实现。但真正让我觉得“这个设计值得抄”的是旁边那个“回滚”按钮。AI 生成的行程不会直接覆盖正式记录而是作为草稿写入。表结构大致是这样create_table :itineraries do |t| t.integer :parent_id t.integer :version, default: 1 t.integer :status, default: 0 # draft / confirmed / canceled t.jsonb :payload t.string :model_id t.string :prompt_version t.timestamps end每次生成都是一条新的草稿带有parent_id指向上一版本。用户点“确认”时事务里把旧版本标记为历史版本把草稿提升为正式版本点“回滚”时直接切回上一个有效版本。这个机制成本极低但解决了一个很关键的体验问题AI 功能最常见的失败不是技术报错而是“生成了一个看起来合理但不符合用户预期”的结果。如果没有版本化设计用户只能要么接受要么愤然离开。现场有人问“向量数据库存在哪”演讲者的回答我完全赞同如果你在做 Rails 业务第一个向量数据库可能根本不需要。先把应用数据库里的结构化数据用好用精确查询缩小范围必要时再加 pgvector。只有搜索、推荐这类真正非结构化的场景才值得引入额外组件。对多数业务系统来说RAG 的最佳检索源就是 PostgreSQL 里的几张表和几个索引别看其他框架吹得天花乱坠粘合层简单才是长期能维护的前提。3. 工具箱展示哪种 AI 编码工具进 Rails 工作流是稳赚的3.1 补全、Agent、自动重构三个层级的真实风险工具演示的顺序很有意思从最无聊到最激进。第一类是 IDE 里的自动补全比如 Fitten Code、GitHub Copilot 这类风险最低适合日常快速写 CRUD。第二类是编码 Agent给它一句话它在终端里连续改多个文件甚至自己跑测试。第三类是“自然语言要求整个重构”的交互式模式现场效果很震撼但演示者自己承认这一类必须人工逐行审查。他给了一张工具选择表我回来后凭记忆整理了一下工具类型适合场景主要风险建议的介入方式自动补全样板代码、命名重复度高生成结果有一定随机性靠测试兜底提交前 review编码 Agent跨文件小改动、补测试容易顺手改坏周边代码要求 Agent 输出 diff禁止直接提交自动重构大范围结构调整隐藏的副作用和业务假设必须有完整测试覆盖必要时回滚他强调了一个对我来说很新的动作“反生成审查”。也就是不要用审查人类代码的眼光去看 AI 代码要反过来想哪一行是模型为了迎合提示词而硬凑出来的。模型很喜欢编造不存在的配置项、过度设计接口、修饰命名这些都要靠人来过滤。我试过之后觉得这个动作应该写进团队的 code review checklist比反复调 prompt 更有效。3.2 测试生成才是甜点区业务代码生成是雷区现场最重要的一个判断也是对我最有用的一句话AI 编码工具提升最大的不是生产代码生成而是测试代码生成。原因是测试有明确的正确性边界——失败就是失败成功就是成功机器可以判断。而业务代码是否正确往往要等上线后用户来裁决。他展示了一个 RSpec 文件AI 自动生成了三类测试用例订单状态迁移、权限边界、第三方 API 超时。这些场景覆盖覆盖面比我手写的还要宽。我一开始以为是运气后来发现窍门在于提示词里给了明确的“边界描述”要求模型专门盯着空值、重复提交、并发修改、超时这些反面场景。还有一个很实用的模式用 Agent 自动修测试失败。重点在于只把失败日志和测试文件路径喂给 Agent不给业务背景。这样模型不会瞎猜业务意图只会老老实实修测试本身的脆弱点或者定位到代码层的直接原因。人负责定义意图AI 负责处理令人烦躁的迭代循环。这个分工方式我现在已经在团队里推广了。3.3 提示词也要进 Git模型版本也要进日志演讲里有一个建议是每个 Rails 团队今天就能落地的把提示词当成代码来管理。提示词的每一次改动本质上都是业务逻辑在变它不应该只存在数据库或者后台配置里而应该跟着代码一起合入 PR、参与 code review。更可操作的形式是这样每个业务场景对应一个prompts/xxx.md文件文件里写好模板变量说明和版本号CI 里跑一个静态检查保证模板变量都能被正确替换参考文档没有过期。调用日志里必须记录prompt_version和model_id。一旦线上行为出现偏差你能直接定位到是提示词版本变了还是模型被厂商悄悄升级了。这个外部成本几乎为零但对故障复盘帮助巨大。我回来以后顺手把我们项目的摘要调用改成了这个模式上个星期就排掉一个 A/B 组模型串动的诡异问题靠的就是日志里的summary_v2和summary_v1之差。4. 生产级 Rails LLM我记下的三个反直觉结论4.1 不要用 Retry 代替确定性校验层第二个重头戏是生产环境可靠性的“三个反直觉结论”。第一个是不要把重试当成容错。LLM 调用失败后如果直接重试大概率会得到同一种失败因为问题往往出在输入数据的边界条件上模型本身没有变结果也不会变。更合理的做法是在调用外部模型之前和之后各加一道确定性校验。这道校验层可以很简单比如用ActiveModel::Validations锁住状态枚举值class ItineraryContract ActiveModel::Validator def validate(record) unless %w[pending confirmed canceled].include?(record.status_key) record.errors.add(:status_key, must be one of allowed keys) end end end模型不再直接返回自由的“已送达”“已完成”这种文本而是返回一个枚举 key再由代码映射成用户看到的文案。这个转变很微小但效果立竿见影。我之前的 AI 客服摘要功能就是被“自由文本”坑过后来改成“让模型选择预定义的状态”错误率几乎降到零。模型适合在约束范围内做生成不适合承担数据契约的责任。4.2 上下文不是越长越好先用 SQL 缩小数据第二个结论反直觉上下文窗口越大不等于越智能。演示里做了一个小实验同一道任务背景资料从 8 篇增加到 20 篇准确率反而下降了 5%。原因是资料里一旦有重复、矛盾或者大量无关信息模型会把它们当作噪声注意力被稀释。所以演讲者的建议是把数据筛选交给 SQL而不是交给模型。在 Rails 里就是先where后prompt。先用 ActiveRecord 把数据精确到你知道的范围内再把这些记录按模板组装成上下文最后让模型做摘要或组装。不要把整个业务库或者所有文档变成上下文那只会让模型做更多它不擅长的判断。这与 RAG 的工程实践直接相关。很多团队 RAG 效果不好问题往往不是向量检索不够好而是没有做业务流程的二次分解。订单、发票、用户档案这些结构化数据完全可以直接查库获得不需要靠向量召回。模型应该只在真正非结构化的那部分工作比如语义搜索、推荐排序、自然语言摘要。当你能确定的数据都确定化后幻觉问题的概率会明显下降。4.3 自主容错不是模型变聪明而是能记录、能回滚、能接管第三个结论对应的是“LLM 智能体自主容错控制”这个方向。演讲者认为Agent 的“自主容错”不是让模型看起来更聪明而是让它知道自己错了就主动降级。现场有个演示镜头AI 生成的日程和用户的余额校验冲突Agent 没有继续硬生成而是停下来告诉用户“钱包余额不匹配请先充值”。这一刻全场掌声比任何华丽功能都热烈。能承认自己不知道对模型来说才是真正的可靠。落到工程上我的理解是把决策点暴露给人类。Rails 里可以用ActiveJob的执行历史加审计表记录每次 Agent 的动作调了哪个工具、输入是什么、输出是否通过校验、在哪一步触发了回退。之前我觉得这是重活但现场演示后我发现它其实只需要在服务对象外层包一个 result 对象把每个动作的 input、output、validated 状态写进事件表就行。一旦事故发生了你能像看时间线一样回溯 Agent 的每一步幻觉就从玄学变成了可排查的工程问题。这个审计层比调模型温度、调 top_p 有用一百倍。AI 功能上线之前我会建议每个团队先做这件事而不是先追求准确率。5. 散场后的实践清单把 AI 放进默认值而不是放进银弹5.1 第一批改动单出入口、意图命名、安全开关散场后我在酒店和几个朋友又聊到半夜。把整场演讲压成一份可执行清单最值得先做的是三件事。第一所有 AI 调用必须经过单一入口不要在各 Controller 里东一个西一个。我现在的做法是在app/services/ai/下建统一客户端无论后面接哪个模型外面代码都不用改。第二给每一个业务意图起清晰的名字比如itinerary_generate_v3、summary_v2。这个名字不只是给人看的它必须出现在日志字段、提示词版本号、评估记录的 metadata 里。第三加一个安全开关。AI 功能出错时运维可以直接在 Admin 后台关闭它而不是紧急重部署。这三步花不了多少时间但作用很大。我们内部项目照做后上星期刚好做了一次事故演练客服摘要 A/B 组模型串动因为意图名写错了日志立刻暴露问题。整场排障不到半小时靠的就是记录了prompt_version和model_id的审计表。AI 功能真正让人安心的方式不是永远不出错而是出错了能快速定位、快速止血。5.2 评估集与离线评测部署前先问“评判标准是什么”演讲里关于 AI 模型部署的部分对我触动也很大。他建议把评估做进 CI而不是每次都“凭感觉换个模型试试”。最简单的实践在 RSpec 里准备一组“黄金问题”每个问题都有标准回答或可接受答案。每次改提示词、升级模型版本时跑一遍rails ai:evaluate得到准确率、时效、成本三个指标。这个思路的本质是让模型选型从玄学变成工程判断。现场展示了一个订单自动分派的评估结果找出来的赢家居然不是一个最大的模型而是某个厂商的小模型——因为它在关键路径上更快、更便宜、更稳定。这件事放在以往我会觉得很反直觉但有了评估集一切都有数据支撑。Rails 团队的优势在于本来就重视 fixture 和测试数据把评估集也做成 fixture 是很自然的事。不要一个 LLM 调用散落在三十几个地方应该像测试一样作为一等公民来维护。第一批场景可以从高频且低风险的开始比如标题改写、客服摘要先圈 20 条提问记录每条回答的模型、时长、成本两周后再分析。你会发现思路立刻清晰因为你不再是 “看演示很惊艳” 就换模型而是有一套自己的验收标准。5.3 AI 会帮你写更多业务代码但不会替你拍板整场演讲最核心的密码我留在最后。原话大意是AI Euphoria 只会发生在你信任默认值之后。Rails 社区最擅长的就是把复杂问题收敛成简单约定。AI 也一样提示词怎么存、模型版本怎么记录、输出怎么校验、失败怎么回滚、审计在哪里这些默认点全部立住之后你才有资格谈“狂喜”。否则你只是在为别人的不确定系统买单。我现在越来越认同一个判断AI 会让 Rails 开发者写更多的业务代码而不是更少。因为当模型的边际成本降到足够低很多过去不值得做的边缘功能会进入“可做”的区间。你想给用户加一个按自然语言筛选订单的功能以前要评估语义解析的成本现在可能两天就能做出原型。而 Rails 提供的那套结构恰好能保证这些快速生成的功能不会把系统拖垮。这场主旨演讲没有给我一个让人“哇”一声的大杀器但它给了我一个很稳的框架。别怕 AI 改造 Rails要去改造 AI让它适应 Rails 的默认值、纪律和边界。这是我在会后第三天仍然觉得最有价值的收获。
