Ruby China 社区 Rails 节点

新书《Rails 8 现代单体架构实战》发布

apexy — Wed, 10 Jun 2026 11:50:47 +0800

2024 年，我在 RubyConf China 上做了《下一个十年的 Monolith》讲演：https://www.bilibili.com/video/BV1R2cceWEvS

但是大会一个主题的时间毕竟有限，所以感觉还有很多东西没有讲到或讲透，加上这两年里 Rails 8、8.1 的接连推出，让 Rails 在这个领域不断发展。因此我觉得有必要写一本书来对这个主题——我称之为“现代单体架构（Modern Monolith）”——做一些更深入的阐述和探讨。

经过近半年的时间，我的这本书终于完成，正式发布在 Leanpub。

购买链接：https://leanpub.com/therails8modernmonolithinaction

新书介绍

俗话说“天下大势，合久必分，分久必合”。

对于 Web 应用来说，经过微服务、前后端分离的十多年流行之后，随着硬件和网络的进步，回归单体架构的趋势开始出现了。越来越多的开发者、团队或公司，都在逐渐认识到这一变化。

Rails 8 通过一系列新特性，填平了旧时代单体架构面临的技术鸿沟，构筑起了现代单体架构（Modern Monolith）的新体系。

阅读这本书，通过一个实际 Rails 应用的完整开发到上线的全过程，你将会深刻理解并掌握到：

Rails 8 两种不同的现代单体架构（标准现代单体、组件驱动单体）的详细实战运用；
从产品设计到部署上线的 Rails 应用产品的真实迭代开发流程全貌；
涵盖测试金字塔、持续集成、持续部署、Storybook 等业界真正工业级的软件工程实践模式；
各种 Ruby/Rails 开发的高级经验和技巧；

如果你热爱 Ruby，想了解 Rails 8 的最新特性，并且愿意看看现代单体架构如何实战落地，这本书就是为你写的。

新书样章

在 Leanpub 新书页面有新书试读样章可以直接免费下载。

另外还有内容更多一些的社区版（Community Edition），可以通过邮件免费获取。

社区折扣

既为了庆祝新书发布，也为了庆祝世界杯开赛，我为 Ruby China 社区准备了 20 个名额的五折优惠券。

有兴趣的朋友可以私信联系我（备注 rubychina book）。

rails 项目里用 kamal 部署阿里云 ssl 证书流程总结

flchenhp — Wed, 03 Jun 2026 15:45:16 +0800

背景

在我的部署过程中，有些域名总是无法成功自动申请 ssl 证书，暂时我也没搞清为什么无法自动申请成功，先尝试在阿里云申请 ssl 证书然后部署，现流程跑通特记录加深印象。

以下是使用 Kamal 将阿里云 SSL 证书自定义部署的完整流程：

一、准备 SSL 证书文件

获取证书：从阿里云获取 SSL 证书
- 证书文件（ .pem）
- 私钥文件（ .key）

注意：只需要申请主域名如 caibaoying.fun 的 ssl 证书，不需要同时申请 www.caibaoying.fun 的，我就踩了一次坑，哈哈。

二、创建本地证书存储

创建存放证书的文件夹和文件：
config/ssl
config/ssl/certificate.crt - 合并后的证书链
config/ssl/private.key - 私钥文件

将证书和私钥分别复制粘贴至文件内

三、配置 .kamal/secrets

在 .kamal/secrets 文件中添加环境变量定义：

CERTIFICATE_PEM=$(cat config/ssl/certificate.crt)
PRIVATE_KEY_PEM=$(cat config/ssl/private.key)

四、配置 config/deploy.yml

proxy:
  ssl:
    certificate_pem: CERTIFICATE_PEM    # 对应 secrets 中的变量名
    private_key_pem: PRIVATE_KEY_PEM    # 对应 secrets 中的变量名
  hosts:
    - www.caibaoying.fun
    - caibaoying.fun

五、部署验证

bin/kamal deploy

六、打开网页测试

看到网站可以通过 https 方式安全打开，成功！

讓 ActiveRecord model 只能在特定 service class 裏被更新

mizuhashi — Fri, 22 May 2026 19:56:56 +0800

class Post < ApplicationRecord
  include ActiveRecordReadOnly
end

# Anywhere else in the codebase — blocked
Post.find(1).update!(title: "x")
# => ActiveRecord::ReadOnlyRecord

# In a service class — allowed
class PostService
  include Post::Writable

  def self.publish(post)
    post.update!(published: true)   # works
  end
end

實驗後發現這是可行的，可以通過在 model 的readonly?方法裏檢查caller_locations來判斷能否處在一個已經include Post::Writable的環境，不過也有不少限制。

https://github.com/onyxblade/active_record_read_only

Just for fun

早说了转语言了身体却很诚实...

shawnyu — Fri, 22 May 2026 12:35:12 +0800

前情提要

https://ruby-china.org/topics/26838

现在我们还有 Rails 项目呢，兜兜转转这么多年看到自己写的这个帖子...

没有哪种技术能让我像对 Rails 和 Ruby 一样，长长的年头里，总是会忍不住在某个需求里面落地。

Rails/Ruby to da moon!

gems.ruby-china.com 缺少 bigdecimal 4.1.1 版本

shin — Sun, 05 Apr 2026 19:43:08 +0800

在使用 source "https://gems.ruby-china.com" 作为 Bundler 源时，发现 bigdecimal (4.1.1) 无法获取。

具体情况如下：

在升级 Rails 从 8.1.1 到 8.1.2 过程中，依赖解析需要使用 bigdecimal (4.1.1) 该版本在 https://rubygems.org 上是存在的，并且可以正常安装但在 gems.ruby-china.com 镜像源中无法获取，导致 bundle install 失败，进而影响部署

报错类似：

Your bundle is locked to bigdecimal (4.1.1) ... but that version can no longer be found in that source.

请问是否可以帮忙同步或刷新该版本的索引？

感谢支持！

官网宣传语变成“省 Token” “方便 Agent 编写”

tistest — Thu, 12 Mar 2026 10:14:25 +0800

如图 😆

发现 Rails 在 AI 时代好像挺适合做实验性质的项目的

willx — Wed, 11 Mar 2026 21:35:57 +0800

最近组里在做一些数据生产端 AI 的探索，结果一个很直接的感受是：Rails 好像特别适合开发企业内部的 AI 实验项目，用起来贼爽。

目前体感比较明显的点有两个：

1 自带完善的测试框架，fixtures、test db 这些都很顺手，挺适合 vibe coding 的时候自己快速迭代

因为这种项目本身就是实验性质，主打的就是一个又糙又快，老板恨不得 1 天之内就能试出结论，所以 Vibe Coding 基本是必不可少的。

但问题在于，很多别的语言或框架，光是想让 AI 具备一套像样的自我验证能力，前面就得先折腾一轮。Rails 在这点上基本算是开箱即用，优势还是挺大的。

2 Solid Queue 本地就能提供消息队列能力，碰到大模型 API 限流这类问题，处理起来也比较简单

本地开箱即用、而且基本不需要额外依赖的消息队列，这一点其实也特别适合大模型相关场景。很多实验项目一开始并不想把基础设施铺得太重，能先在本机或者开发机上把流程跑通就已经很舒服了。

AI 开发 Rails，如果遇到 bug 看不懂咋办？

ironboxer — Tue, 10 Mar 2026 12:04:13 +0800

不懂 Rails，让 AI 写 rails。万一复杂度上来了，遇到问题了，又看不懂代码，咋办？

一個用 DIDComm 實現服務器間通信的 Rails demo

mizuhashi — Wed, 04 Mar 2026 07:14:39 +0800

DIDComm是一個基於 W3C DID（去中心化 ID）的通信協議。如果一個服務器想和另一個實現了 DIDComm 的服務器通信，它會需要在/.well-known/did.json 提供一個 DID 文檔，文檔裏包含了公鑰以及 DIDComm 的 service endpoint。我的 demo 服務器的 DID 文檔長這樣：https://dc.mbkr.ca/.well-known/did.json 。

擁有了這個文檔之後，did:web:dc.mbkr.ca這個 DID 就會對應我的服務器，你只需要這個 id 就可以給我發信息，發信方會根據這個 id 解析到 DID 文檔，獲取公鑰構建信息，並推到 service endpoint 上。

我也做了一個公開的 demo 服務器， https://dc-public.mbkr.ca/ ，你可以用public做密碼登錄。

Demo 的 repo: https://github.com/onyxblade/didcomm-rails-demo

實現上，我本來是讓 AI 生成了一個 Ruby 版本的 DIDComm 實現，不過密碼學的內容很多，我最後還是決定直接用didcomm-rust這個標準的參考實現。這個 Rust 的實現可以輸出 wasm，但 wasmtime-rb 好像還沒成熟到能直接用，所以最終我做了一個 HTTP 服務器didcomm-http，來把 wasm 接口包裝成 HTTP API。

Happy Hacking!

内容审核（头像审核、昵称审核）技术对比，阿里云内容安全审核 api 和大模型 LLM 的 PK 对比

yfscret — Fri, 13 Feb 2026 16:08:53 +0800

一、背景与目标

1.1 为什么需要做对比

内容审核是社区、电商等业务的基础能力，需对用户上传的头像/图片和昵称/文本进行合规检测。我们之前一直使用的是阿里云的内容审核 api 来检测的，但是偶尔会有检测出错的情况，尤其是头像的广告引流，偶尔会有识别不出来的情况。因此考虑使用大模型能力来做个测试对比：

传统审核 API：如阿里云 profilePhotoCheck、text_scan 等
LLM 多模态审核：通过通义、GPT、Claude 等大模型的提示词限制来判断（我们是通过 Dify 工作流来提供的 api 接口来服务业务系统）

不同方案在耗时、费用、准确度上差异显著，需要系统对比后做出技术选型。

1.2 对比目标

梳理各方案（阿里云、通义、GPT、Claude 等）的价格与准确性
通过实际测试，验证阿里云 API 与 Dify + LLM 的耗时、费用、准确度
给出最终选型与实施建议

二、先直接给出结论

场景	选型	理由
图片审核	Dify + qwen-vl-flash	费用约 7 元/万张，低于阿里云 15 元；耗时优于 qwen-vl-plus；准确度满足需求
昵称审核	Dify + qwen-plus-latest	费用约 2.6 元/万次，低于阿里云 7.5 元；对引流、联系方式等更敏感
兜底/强合规	阿里云	延迟低、稳定，可作为主流程失败或高并发时的补充

三、方案调研

3.1 昵称/文本审核：准确性与价格

方案	准确性	价格 (元/万次)
通义 qwen-plus	高	约 3.4
通义 qwen-max	最高	约 50–60（按 250 input + 80 output token 估算）
通义 qwen-turbo	中高	约 1.1
DeepSeek-V3	中	约 7.6
GPT-4o	精确率高、召回率低	约 4–5

3.2 头像/图片审核：准确性与价格

方案	准确性	价格 (元/万张)
Qwen-VL-Max	最高	约 19.8
阿里云 profilePhotoCheck	高（专项）	15
Qwen-VL-Plus	中高	约 9.6
Qwen-VL-Flash	中高	约 7（实测）
Claude 3.5 Sonnet	高	约 200–300（按单张约 $0.003–0.004 换算）
GPT-4o vision	高	约 20–45（随分辨率与 token 波动）

3.3 阿里云现有方案（对比基准）

类型	价格 (元/万次或元/万张)
文本审核（增强版）	约 7.5
图片/头像审核（profilePhotoCheck）	约 15

四、我们的实际对比测试

4.1 测试设计

图片：来自我们实际生产数据的用户头像
昵称：30 组预设样本（含正常、敏感、边界）

4.2 图片审核实测

4.2.1 qwen-vl-plus vs qwen-vl-flash（50 张图，统一 q100 jpg）

注意这张图，引流内容不容易被发现，阿里云 api 就检测通过了，大模型精准识别

方案	总耗时 (ms)	总费用 (元)	单次平均耗时 (ms)	万张预估费用 (元)
阿里云	37,781	0.075	756	15
qwen-vl-plus-latest	157,416	0.048	3,148	9.6
qwen-vl-flash	127,056	0.035	2,541	7

结论：qwen-vl-flash 费用更低、耗时更短、准确率和 qwen-vl-plus-latest 相当，选型为图片审核方案。

4.2.2 原图 vs 800px 宽格式化为 jpg(image/resize,w_800/quality,q_90/format,jpg

)（80 张图，同一 Dify 工作流）

做这个对比是因为现在用户的手机拍照随便都是 5M 起步，如果用原图的话，大模型先下载图片再转成输入 token 就比较大，比较慢了，所以先格式化为宽 800 的 jpg（十几 M 的图片变几百 K）用作大模型输入。

方案	总耗时 (ms)	总费用 (元)	单次平均耗时 (ms)	万张预估费用 (元)
阿里云	66,126	0.12	827	15
Dify 原图	253,539	0.081	3,169	10.1
Dify 800px jpg(q90)	281,114	0.078	3,514	9.7

说明： 上面这个测试的原图我们保存时候已经转过格式压缩过了，所以这个对比其实是失败的，没有测试出几兆那种原图和格式化后的图在费用上的差异，写出来只是给大家提供一下思路。
结论：最终采用 800px jpg q90 jpg 作为统一输入，兼顾清晰度与体积。

4.3 昵称审核实测（30 组，使用 qwen-plus-latest）

方案	总耗时 (ms)	总费用 (元)	单次平均耗时 (ms)	万次预估费用 (元)
阿里云	7,370	0.023	246	7.5
Dify + qwen-plus-latest	53,419	0.008	1,781	2.6

4.4 准确度对比

图片审核

能力	阿里云	LLM (qwen-vl)
政治敏感（领导人等）	识别	识别（含 inappropriate content 拒绝）
平台水印/引流（抖音、小红书）	识别	识别
饰品/合规展示	通过	通过，可附带说明
复杂场景/边界	规则为主	语义理解更细

昵称审核

测试用例	阿里云	Dify + qwen-plus-latest
小明、翠翠、珠宝爱好者	通过	通过
VX123456、加我微信	不通过	不通过（联系方式引流）
xhs_abc	通过	不通过（含引流信息）
闲鱼号 123	通过	不通过（联系方式引流）

结论：qwen-plus-latest 对引流、联系方式类昵称更敏感，拦截更严格。

4.5 我们的 dify 工作流

其实也可以不用 dify 工作流，直接在代码里调用大模型来识别，不过 dify 的好处就是切换大模型简单，可以随时更新其他大模型。
说明：大模型的识别能力非常依赖提示词，但我们这种识别其实提示词很简单，后续如果有识别不出来的，把提示词修改一下即可。举例：比如昵称是”你们公司真下头“，这个调用传统内容审核 api 是通过的，但我们不想让他通过，使用传统内容审核就不好定制，但使用大模型的话，我们只用在提示词加一句，如果内容包含”下头“则视为审核不通过。大模型就会按审核不通过处理。是不是特别灵活。

4.6 关于费用怎么对比
阿里云内容审核 api 有明确的文档说明每次调用多少钱
大模型是按输入输出 token 计费的，我们用来 format w800 jpg 格式的图片的话，那输入 token 就是图片和提示词，基本可以确定，输出我们也是严格限制了格式，所以也是确定的。另外 dify 每次调用都会返回 useage，我们保存到数据库即可。方便我们选型和统计

五、阿里云 API vs LLM 优劣势

5.1 阿里云内容审核 API

优势	劣势
延迟低：图片约 800 ms，文本约 250 ms	费用高：图片 15 元/万张，文本 7.5 元/万次
稳定：成熟商用接口，SLA 保障	规则化：依赖预设规则，边界场景易漏检
部署简单：HTTP 调用即可	定制难：无法按业务语义微调策略
合规背书：符合监管要求	结果简单：多为 pass/block，缺少详细说明

5.2 LLM 多模态审核

优势	劣势
成本低：图片约 7 元/万张，文本约 2.6 元/万次，还有更低成本的大模型可选	延迟高：图片 2.5–3 s，文本约 1.8 s
语义理解好：能识别「饰品展示」「联系方式引流」等	依赖模型：不当内容可能返回 400，需专门处理
结果更细：可返回原因说明，便于运营排查	需自建工作流：需维护 Dify 与模型配置
可定制：prompt 可调整审核策略	稳定性：依赖第三方模型服务可用性

六、最终选型与实施建议

6.1 选型结论

场景	选型	理由
图片审核	Dify + qwen-vl-flash	费用最低（约 7 元/万张），耗时优于 plus，准确度满足需求
昵称审核	Dify + qwen-plus-latest	费用低，对引流/联系方式更敏感
兜底/强合规	阿里云	低延迟、稳定，可作为主流程失败或高并发时的补充

6.2 实施建议

图片输入：统一使用 format q90 jpg（oss-process），平衡清晰度与体积
异常处理：Dify 返回 400 且含「inappropriate content」时，按不通过处理
混合策略：高并发或要求极低延迟时，可考虑阿里云；长尾审核、成本敏感时用 LLM
持续监控：记录耗时、费用、通过率，定期对比不同方案表现

Rails 技术实战之 AI 找货小助手设计

ThxFly — Tue, 10 Feb 2026 19:16:13 +0800

AI 找货助手技术实现指南

最近阿里云千问的"点奶茶"技能很火，碾压了微信红包的 AI 玩法。这波 AI 热潮下，我们在 APP 里也做了一个 AI 找货功能。

用户搜"温润的手镯"，传统搜索只认"温润"和"手镯"两个字。但用户真正想要的是和田玉——因为"温润"是和田玉的特征。

这篇讲讲怎么用向量搜索 + AI 对话，让系统理解用户真正想要什么。淘宝、京东、美团、携程都有类似功能，我们这个还比较粗浅，讲个大概，体验看起来还有待优化，还请包涵。

需求预览

核心概念

概念	说明
Dify	开源 LLM 应用开发平台，我们用它做工作流编排。Dify 部署成独立服务，Rails 后端通过 HTTP API 调用。
SSE	Server-Sent Events，服务器主动推送数据给前端，比 WebSocket 简单，适合这种单向实时推送的场景。
向量搜索	把文本转成 1024 维向量，算向量相似度来找商品。比如"温润的手镯"能匹配到"和田玉手镯"。
KNN	K 最近邻算法，在向量空间里找最相似的 K 个商品。K 越大结果越多，但也越慢。
Embedding	把文本转成向量的过程，语义相近的文本向量也相近。
HNSW	一种高效的向量索引算法，ES 8.x 原生支持，用来加速 KNN 搜索。

一、技术架构总览

1.1 整体架构图

整体流程

用户在前端输入需求 → SSE 建立长连接 → Rails 把请求转给 Dify → Dify 识别意图、提取参数 → Dify 调用 Rails 的搜索接口 → Rails 生成查询向量 → ES 做 KNN 向量搜索 → 结果沿路返回 → 前端展示。

几个关键点

前端和 Rails 之间用 SSE，服务器主动推送，不用轮询。
Dify 是外部服务，Rails 只负责转发和调用搜索接口。
搜索用的是向量搜索，不是传统的关键词匹配。

核心配置

配置项	环境变量	作用
Dify API 地址	`DIFY_API_BASE_URL`	Dify 服务的 URL
Dify API Key	`DIFY_CHATFLOW_API_KEY`	调用工作流的认证密钥

核心接口

接口	路径	谁调用
SSE 对话接口	`POST /api/v1/chat/stream`	前端
商品语义搜索接口	`POST /api/v1/products/ai_search`	Dify 工作流

1.2 商品列表接口

GET /api/v1/products 这个接口支持两种搜索方式：普通搜索（传 q、category_id、price_min/max 等参数），和 ai_search_id 搜索（传之前搜索的 ID，复用搜索参数）。

使用场景是这样的：用户在对话里看到商品列表，想看更多，点"查看更多"按钮，前端把之前的 ai_search_id 传过来，后端直接从数据库捞出之前的搜索参数，做分页查询。

1.3 数据流转

两个关键点

商品向量是上架时生成的，存在 ES 里；查询向量是每次搜索实时生成的。
向量生成失败了怎么办？降级处理，返回空结果或者转关键词搜索。

1.4 技术栈

组件	选型	说明
工作流引擎	Dify	最新版，做 AI 流程编排
LLM	通义千问 qwen-plus-latest	意图理解、参数提取
搜索引擎	Elasticsearch 8.x	商品索引 + KNN 向量搜索
后端框架	Ruby on Rails 8.x	业务逻辑

二、SSE 事件设计

2.1 事件流程图

2.2 事件类型

事件类型	触发时机	作用
`system_message`	连接建立后、stream_end 前	系统提示，比如"正在匹配货品中"，或者错误提示
`message_start`	第一次收到 Dify 的 message	告诉前端准备接收消息
`message`	收到 Dify 的 message	真正推送内容，可能拆成多个片段
`thought`	Dify 节点开始处理	显示"正在处理：xxx"，让用户知道进度
`message_end`	收到 Dify 的 message_end	一条消息发送完成
`stream_end`	整个流程结束	前端可以关闭连接了

msg_type 的取值

message_start 和 message 的 msg_type：

Dify 返回 PRODUCT_CARD → product_card（商品卡片）
Dify 返回 CLARIFY_CARD → clarify_card（追问卡片）
Dify 返回 TEXT → text（普通文本）
其他情况默认 text，结构化内容可能是 blocks

system_message 的 msg_type：

show_thinking：显示思考过程
hide_thinking：隐藏思考过程
text：普通系统文本
retry：可重试的错误

2.3 事件数据格式

message_start

{
  "event": "message_start",
  "data": {
    "msg_id": "uuid",
    "msg_type": "text",
    "role": "assistant",
    "task_id": "uuid"
  }
}

message

{
  "event": "message",
  "data": {
    "msg_id": "uuid",
    "content": "这是消息内容",
    "task_id": "uuid"
  }
}

message_end

{
  "event": "message_end",
  "data": {
    "msg_id": "uuid",
    "status": "success",
    "usage": {
      "prompt_tokens": 100,
      "completion_tokens": 50,
      "total_tokens": 150
    }
  }
}

stream_end

{
  "event": "stream_end",
  "data": {
    "conversation_id": "uuid",
    "status": "success"
  }
}

system_message

{
  "event": "system_message",
  "data": {
    "id": "uuid",
    "msg_type": "text",
    "role": "system",
    "content": "正在匹配货品中",
    "user_message_id": 123
  }
}

thought

{
  "event": "thought",
  "data": {
    "msg_id": "uuid",
    "content": "正在处理：属性提取",
    "task_id": "uuid"
  }
}

2.4 事件顺序和处理规范

标准顺序

连接建立后，先发 system_message（show_thinking）告诉用户"正在匹配"
收到 Dify 的 message，第一次发 message_start，然后发 message（可能多次）
收到 node_started 时可以发 thought
收到 message_end 时发 message_end
有系统消息（错误或提示）发 system_message
最后发 stream_end

错误处理

错误不走单独的 error 事件，统一用 system_message
msg_type 是 retry 表示可重试的错误
不管成功失败，最后都会发 stream_end

前端注意事项

message 是流式的，前端要累积内容直到收到 message_end
根据 msg_type 决定怎么渲染
收到 stream_end 就关闭连接

三、Dify 对话流设计详解

3.1 工作流核心结构

我们用 Dify 的节点式编排来做对话流，核心节点如下：

节点类型	作用
Start	接收用户输入和认证信息
Question Classifier	意图识别，分成 4 种意图
LLM	属性提取，把用户输入转成结构化参数
If-Else	判断要不要追问用户
LLM	生成追问话术和选项按钮
HTTP Request	调用后端搜索接口
Code	结果合并，各分支互斥，只返回其中一个结果

工作流里的变量：环境变量 HTTP_DOMAIN 存 API 域名。

3.2 Start 节点

起点，接收前端传来的变量：

变量	类型	说明
intent	string	用户意图标识
authorization	string	Bearer Token
version_date	string	版本日期（可选）

3.3 意图识别

用 Dify 的 Question Classifier 节点，把用户请求分成 4 类：

分类 ID	名称	例子
1	找货意图	"找翡翠手镯"、"想买和田玉"
2	知识问答	"怎么鉴别翡翠 A 货"、"如何保养和田玉"
3	App 问答	"怎么注册账号"、"如何发布商品"
4	闲聊	"你好"、"谢谢"、"再见"、"今天天气怎么样"

模型配置：通义千问 qwen-plus-latest，Temperature 设 0.3 保证分类稳定，对话记忆保留最近 10 轮。

3.4 属性提取

从用户输入里提取搜索参数，用 LLM 节点，模型也是通义千问，Temperature 0.3。

q 字段（核心搜索描述）

要包含明确的商品品类词
50-100 字的自然语言描述
有些默认规则：用户说"玉石"没具体说是和田玉还是翡翠，默认当和田玉处理；说"高货"默认当翡翠处理。

价格范围

price_min 只有满足"品类 + 高价值信号 + 高价值形态 + 无瑕疵"时才推断。比如用户说"高品质玻璃种翡翠手镯，无纹无裂"，才可能推断最低价。

price_max 按用户字面描述来，用户说"5000 元左右"就设 5000。

分类映射

1=>翡翠，2=>玉石，3=>钻石，4=>彩宝，39=>书画，40=>黄金，107=>黄金饰品，109=>文玩古玩，110=>钱币邮票

输出字段

字段	类型	必填	说明
q	string	是	核心搜索描述
price_min/max	number/null	否	价格范围（元）
category_id	number/null	否	商品分类 ID
inner_circle_size_min/max	number/null	否	圈口尺寸（mm）
heat_min/max	number/null	否	参与热度范围
is_uncertain	boolean	否	是否模糊需追问
has_discount	boolean	否	是否要优惠商品
negative_filters	array[string]	否	排除关键词

3.5 条件判断

检查 is_uncertain 字段，true 就进入追问分支，false 直接搜索。

触发追问的例子

"想买个手镯" → 缺少价格、材质，追问
"5000 元的" → 缺少商品类型，追问
"翡翠手镯，5000-8000 元" → 信息完整，直接搜

3.6 生成追问

当需要追问时，用 LLM 生成话术和选项。Temperature 设 0.7 高一点，让回答更有创造性。

生成规则：message 字段要共情 + 归因 + 引导，suggested_questions 至少 3 个肯定式选项。

{
  "message": "追问话术",
  "suggested_questions": [
    { "title": "问题标题", "intent": "find_item" }
  ]
}

3.7 HTTP 请求节点

真正调用 Rails 搜索接口的地方：

POST 请求
URL：{{#env.HTTP_DOMAIN#}}/api/v1/products/ai_search
请求头带 X-Authorization（从 Start 节点取）

超时和重试：连接/读取/写入都设 10 秒，失败自动重试 1 次。

3.8 结果合并

根据条件判断走不同的分支，各分支互斥，只返回其中一个：追问分支返回追问话术，搜索分支返回商品列表结果，无结果时返回默认话术。

四、向量搜索技术详解

4.1 为什么用向量搜索

传统搜索的局限：

搜索方式	问题
关键词搜索	无法理解语义，"温润的手镯"匹配不到和田玉
短语匹配	要求太精确，用户不会打完整短语
布尔搜索	AND/OR/NOT 组合太复杂，用户不会用

向量搜索能理解语义：

搜什么	关键词搜索	向量搜索
"温润的手镯"	匹配含"温润"和"手镯"的商品	匹配和田玉手镯
"高货"	匹配含"高货"的商品	匹配翡翠高品
"送妈妈的礼物"	几乎没结果	匹配适合送长辈的手镯

4.2 向量搜索原理

流程：文本 → Embedding 模型 → 1024 维向量 → KNN 搜索 → 返回结果。

步骤：1) 把用户输入转成向量；2) 在 ES 里用余弦相似度找最相似的 20 个商品；3) 用 min_score 阈值过滤。

4.3 EmbeddingService 实现

我们用阿里云百炼的 Embedding 接口。一次请求把文本转成 1024 维向量，耗时大概 100-200ms。

缓存策略：相同文本 10 分钟内重复查询直接返回缓存。

错误处理：向量生成失败了返回空数组，后面的 ES 查询就不做了，避免浪费资源。

vector = EmbeddingService.encode("翡翠手镯，种水细腻，色泽温润")
# => [0.023, -0.156, 0.089, ..., 0.012] (1024个浮点数)

4.4 商品向量同步 Job

商品上架后，AI 总结生成完成时自动触发向量生成。流程：

取商品的 AI 总结（必须是已生成的）
组合文本：商品标题 + AI 总结内容
调用 EmbeddingService 生成 1024 维向量
验证向量维度
同步到 ES 的 ai_summary_vector 字段
标记生成时间 vector_generated_at

注意事项：版本冲突自动重试 3 次，失败了要报警。向量是预先生成的，搜索时直接用，不用实时生成。

4.5 ES KNN 查询构建

核心方法：

方法	作用
`build_ai_knn_search_body`	构建 KNN 查询 Body
`extract_knn_filters`	提取过滤条件（排除关键词、圈口尺寸等）
`apply_filters_to_knn_query`	应用过滤条件

关键参数

k：返回多少条结果。翡翠设 30，玉石 25，钻石和彩宝设 20。翡翠商品多，设大一点有足够候选。
min_score：相似度阈值。翡翠设 0.85，玉石 0.8。翡翠商品描述比较标准化，设高一点不容易跑偏。

核心词加权：如果提取到核心词（如"翡翠"），生成向量时重复 3 次，让这个词权重更高。"翡翠手镯" → "翡翠翡翠翡翠手镯" → 生成向量。

4.6 召回、排序、重排

召回流程

生成查询向量
用 HNSW 在向量空间里找最近的 k 个
应用 knn.filter 过滤条件
计算余弦相似度，过滤低于 min_score 的
返回商品 ID 列表

排序：目前只用 _score（相似度分数）降序，简单的做法，后续可以加其他排序维度。

重排：没有额外的重排逻辑，ES 返回什么顺序就是什么顺序。

4.7 完整 ES KNN 查询示例

{
  "knn": {
    "field": "ai_summary_vector",
    "query_vector": [0.023, -0.156, 0.089, 0.234, -0.067, 0.178, ..., 0.012],
    "k": 20,
    "filter": {
      "bool": {
        "filter": [
          { "term": { "category_id": 1 } },
          { "term": { "status": "onsale" } },
          { "term": { "hide_in_miniprogram": false } },
          { "range": { "confirmed_price": { "gte": 5000, "lte": 7000 } } },
          { "range": { "inner_circle_size": { "gte": 55, "lte": 58 } } },
          { "exists": { "field": "ai_summary_vector" } }
        ],
        "must_not": [
          { "match_phrase": { "goods_description_text": { "query": "镶嵌", "analyzer": "ik_max_word" } } }
        ]
      }
    }
  },
  "min_score": 0.8,
  "from": 0,
  "size": 10,
  "sort": [
    { "_score": { "order": "desc" } },
    { "updated_at": { "order": "desc" } }
  ]
}

说明：过滤条件都在 knn.filter 里处理，在向量搜索阶段就过滤，减少计算量。

五、商品语义搜索模块详解

5.1 AiSearch 数据模型

AiSearch 表记录每次搜索的完整参数，搜索条件用 JSONB 存。为什么要冗余存一份 keywords_text？因为运营同学要统计数据，JSONB 查起来麻烦。每条记录关联 ai_chat_id 和 ai_chat_message_id，方便回溯"这条搜索结果是谁发的"。

主要字段

字段名	类型	说明
msg_id	string	消息 ID（唯一索引）
search_params	jsonb	完整搜索参数
keywords_text	string	搜索关键词文本（冗余字段）
category	string	商品分类（冗余字段）
price_min/max	decimal	价格范围（冗余字段）
ai_chat_id	bigint	关联的对话 ID
ai_chat_message_id	bigint	关联的消息 ID

使用场景：记录搜索参数支持"再次搜索"，通过 ai_search_id 复用参数实现"查看更多"，也支持搜索行为分析和统计。

5.2 API Controller 实现

POST /api/v1/products/ai_search

处理流程

参数校验：q 或 category_id 至少一个不为空
创建 AiSearch 记录，生成 ai_search_id
执行搜索：生成查询向量 → 构建 KNN 查询 → ES 查询
数据组装：从数据库捞商品详情，用 Presenter 格式化
返回结果：带 ai_search_id、total、products

成功返回

{
  "success": true,
  "data": {
    "ai_search_id": "uuid",
    "total": 15,
    "products": [
      { "id": 12345, "title": "翡翠手镯", "price": 6000, ... }
    ]
  }
}

错误返回

{
  "success": false,
  "error": "参数错误：q 或 category_id 不能为空"
}

curl 调用示例

curl -X POST "https://api.example.com/api/v1/products/ai_search" \
  -H "X-Authorization: Bearer token" \
  -H "Content-Type: application/json" \
  -d '{"is_ai_search": true, "q": "翡翠手镯，5000-8000元", "category_id": 1, "price_min": 5000, "price_max": 8000}'

错误处理

错误类型	处理方式
参数校验失败	返回 400，提示具体错误信息
向量生成失败	记录日志，返回空结果
ES 查询失败	返回 500，提示"搜索失败，请稍后重试"

六、KNN 按分类配置

配置表：ai_search_knn_category_config

分类 ID	分类名称	k	min_score
1	翡翠	30	0.85
2	玉石（和田玉等）	25	0.8
3	钻石	20	0.82
4	彩宝	20	0.8

k：返回多少条结果。翡翠商品多，设 30；其他品类设 20-25。

min_score：相似度阈值。翡翠设 0.85 因为商品描述标准化，不容易跑偏；其他品类设 0.8。

调参建议：搜索结果太少就降 min_score 或增 k；结果不相关就提高 min_score。如果某个分类经常没结果，可以把 min_score 降 0.05-0.1。

七、常见问题与故障排查

7.1 SSE 连接问题

现象：SSE 连接建立失败或频繁断开

排查步骤

检查请求头：Accept: text/event-stream
检查 token：X-Authorization: Bearer <token>
检查网络和代理设置
看 Rails 日志里的错误信息

常见原因：token 过期或无效、网络超时（默认 60 秒）、服务器主动关闭连接。

7.2 向量生成失败

现象：搜索返回空结果

排查步骤

检查 Embedding 服务 API 是否可访问
检查 API 密钥是否有效
看 Rails 日志的错误信息
检查缓存是否正常（失败的请求也可能被缓存）

解决：向量失败会降级为返回空结果，检查 Embedding 服务配置和网络，清理缓存后重试。

7.3 Dify 工作流调用失败

现象：调用超时或返回错误

排查步骤

检查 DIFY_API_BASE_URL 环境变量
检查 DIFY_CHATFLOW_API_KEY 是否有效
检查 Dify 服务是否正常
看 Rails 日志的详细错误

常见错误：ConnectionError（连不上 Dify）、ResponseError（Dify 返回错误）、ParseError（响应解析失败）。

7.4 ES 查询慢

现象：查询超时或延迟高

排查步骤

检查 ES 集群状态和负载
检查索引分片和副本配置
检查 k 值是否过大（建议不超过 50）
检查 HNSW 参数

优化：适当降低 k、缩小 knn.filter 范围、检查 ES 集群资源。

7.5 搜索结果不相关

现象：返回的商品和用户需求不匹配

排查步骤

检查 Dify 提取的 q 字段是否正确
检查 ES 里的 ai_summary_vector 是否正常
检查 min_score 阈值是否合适
检查核心词加权是否生效

解决：提高 min_score、检查商品 AI 总结质量、优化属性提取规则。

技术架构总结

┌─────────────────────────────────────────────────────────────
│                    AI 找货助手技术架构                         
├─────────────────────────────────────────────────────────────
│  前端层 → SSE 对话接口 → Dify 工作流 → 商品语义搜索接口       
│                              ↓                               
│                      Elasticsearch KNN 搜索                   
│                              ↓                               
│                      商品向量同步 + 查询向量生成               
├─────────────────────────────────────────────────────────────
│  核心流程：Dify 对话流 → 意图识别 → 属性提取 → 追问 → 搜索     
│  核心技术：SSE 实时推送 + 向量语义搜索 + HNSW 高性能索引       
└─────────────────────────────────────────────────────────────

1

willx — Wed, 14 Jan 2026 20:38:35 +0800

分享一个 Rails AI Agent 开发库：ActiveAgent

lyfi2003 — Wed, 24 Dec 2025 16:35:53 +0800

初步看过代码，质量很高，作者是一个 15 年经验的 Rails 工程师：

官网：https://www.activeagents.ai/

Rails 原生方式构建 AI 功能

Active Agent 是一个免费的开源框架，让任何 Rails 开发者都可以使用控制器、视图和后台作业交付真正面向用户的 AI 功能。

无需代码粘合。没有复杂性。只有 Rails 和满满的乐趣。😎

有没有预置字符串的汉化包？

tistest — Fri, 05 Dec 2025 17:45:26 +0800

https://github.com/rails/rails/blob/main/activesupport/lib/active_support/locale/en.yml

https://github.com/rails/rails/blob/main/activemodel/lib/active_model/locale/en.yml

Active Support 与 Active Model 的汉化包，有没有质量尚可的？

response content-type negotiation 的一些问题

hmsk86 — Tue, 11 Nov 2025 21:33:54 +0800

学习 controller 的 respond_to 方法时遇到的一个问题

# app/controllers/test_controller.rb
class TestController < ApplicationController
  def create
    params = self.params.expect user: [ :name, :email ]
    name = params[:name]
    email = params[:email]
    respond_to do |format|
      format.html { render html: "这是html: name=#{name} email=#{email}" }
      format.json { render json: { msg: "这是json", **params } }
    end
  end
end

# config/route.rb
Rails.application.routes.draw do
  post "/test", to: "test#create"
end

用 httpie 发送 post 请求，注意请求头带有Accept: application/json, */*;q=0.5，按理说应该返回 json 响应，但是 rails 返回了 html 响应

$ http POST http://localhost:3000/test user[name]=foo user[email]=foo@example.com --verbose
POST /test HTTP/1.1
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 53
User-Agent: HTTPie/3.2.4
Accept: application/json, */*;q=0.5
Content-Type: application/json
Host: localhost:3000

{"user": {"name": "foo", "email": "foo@example.com"}}

HTTP/1.1 200 OK
x-frame-options: SAMEORIGIN
x-xss-protection: 0
x-content-type-options: nosniff
x-permitted-cross-domain-policies: none
referrer-policy: strict-origin-when-cross-origin
content-type: text/html; charset=utf-8
etag: W/"644544dc838ec7f5f9d146a6efaf52af"
cache-control: max-age=0, private, must-revalidate
x-request-id: ef6be23e-f655-4368-ad0e-5561c1b975ac
x-runtime: 0.002610
server-timing: start_processing.action_controller;dur=0.01, render_template.action_view;dur=0.01, process_action.action_controller;dur=1.32
content-length: 42

这是html: name=foo email=foo@example.com

把Accept: application/json, */*;q=0.5改成Accept: application/json就行了，也就是说，如果请求头的Accept带有*/*，那么 rails 一律返回 html 响应，无视优先级

$ http POST http://localhost:3000/test user[name]=foo user[email]=foo@example.com Accept:'application/json' --verbose
POST /test HTTP/1.1
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 53
User-Agent: HTTPie/3.2.4
Accept: application/json
Content-Type: application/json
Host: localhost:3000

{"user": {"name": "foo", "email": "foo@example.com"}}

HTTP/1.1 200 OK
x-frame-options: SAMEORIGIN
x-xss-protection: 0
x-content-type-options: nosniff
x-permitted-cross-domain-policies: none
referrer-policy: strict-origin-when-cross-origin
content-type: application/json; charset=utf-8
vary: Accept
etag: W/"f1ca37f45944a0eb8cc6bc093b6fc5c8"
cache-control: max-age=0, private, must-revalidate
x-request-id: cdf64112-4d57-4569-af76-ce712b165fe9
x-runtime: 0.001742
server-timing: start_processing.action_controller;dur=0.01, process_action.action_controller;dur=0.31
content-length: 59

{"msg":"这是json","name":"foo","email":"foo@example.com"}

zsh prezto 的这些 shell alias 感觉挺实用的

hmsk86 — Mon, 10 Nov 2025 06:02:24 +0800

if ! zstyle -t ':prezto:module:rails:alias' skip; then
  alias ror='bundle exec rails'
  alias rorc='bundle exec rails console'
  alias rordc='bundle exec rails dbconsole'
  alias rordm='bundle exec rake db:migrate'
  alias rordM='bundle exec rake db:migrate db:test:clone'
  alias rordr='bundle exec rake db:rollback'
  alias rorg='bundle exec rails generate'
  alias rorl='tail -f "$(ruby-app-root)/log/development.log"'
  alias rorlc='bundle exec rake log:clear'
  alias rorp='bundle exec rails plugin'
  alias rorr='bundle exec rails runner'
  alias rors='bundle exec rails server'
  alias rorsd='bundle exec rails server --debugger'
  alias rorx='bundle exec rails destroy'
fi

https://github.com/sorin-ionescu/prezto/blob/7b3b798eb5038eb05938399f245fa643c630a7f1/modules/rails/init.zsh#L22

Rails 8.1 发布

Rei — Wed, 22 Oct 2025 19:27:52 +0800

https://rubyonrails.org/2025/10/22/rails-8-1

要点：

Active Job 长任务中断恢复
结构化事件
本地 CI
Markdown 渲染
命令行获取密钥
关联弃用声明
Kamal 可以使用本地 docker registry

关于 Postgresql 使用 NULLS NOT DISTINCT 还是无法唯一索引允许多个 NULL

ratazzi — Wed, 17 Sep 2025 21:23:44 +0800

因为原帖关闭了回复，所以单独发一个，我喜欢用 PostgreSQL 的一个原因就是条件索引（Partial Indexes）

add_index :users, :auth_token, unique: true, where: "auth_token IS NOT NULL"
add_index :users, :password_reset_token, unique: true, where: "password_reset_token IS NOT NULL"

Rails + Postgresql17 使用 NULLS NOT DISTINCT 还是无法唯一索引允许多个 NULL

chuckaiyu — Mon, 15 Sep 2025 22:32:31 +0800

create_table :users do |t|
  t.string :email, null: false
  t.string :username, null: false
  t.string :display_name, null: false
  t.string :password_digest, null: false
  t.integer :status, default: 0, null: false
  t.string :security_question
  t.string :security_answer_digest
  t.string :password_reset_token
  t.datetime :password_reset_sent_at
  t.string :auth_token

  t.timestamps
end

add_index :users, :email, unique: true
add_index :users, :username, unique: true
add_index :users, :auth_token, unique: true, nulls_not_distinct: true
add_index :users, :password_reset_token, unique: true, nulls_not_distinct: true

测试一直跑不过，看了日志，数据库报错 duplicate key value。然后，直接在 Pg 里面去试试。

-- 1. 创建测试表
DROP TABLE IF EXISTS test_nulls_distinct;
CREATE TABLE test_nulls_distinct (
    id SERIAL PRIMARY KEY,
    data TEXT
);

-- 2. 创建带 NULLS NOT DISTINCT 的唯一索引
CREATE UNIQUE INDEX idx_test_data_unique
ON test_nulls_distinct (data)
NULLS NOT DISTINCT;

-- 3. 插入测试数据
-- 插入唯一非 NULL 值 (应该成功)
INSERT INTO test_nulls_distinct (data) VALUES ('A');
INSERT INTO test_nulls_distinct (data) VALUES ('B');

-- 插入多个 NULL 值 (这应该成功，因为 NULLS NOT DISTINCT)
INSERT INTO test_nulls_distinct (data) VALUES (NULL);
INSERT INTO test_nulls_distinct (data) VALUES (NULL);

-- 执行上面这行应该会报错:
-- ERROR:  duplicate key value violates unique constraint "idx_test_data_unique"
-- DETAIL:  Key (data)=(NULL) already exists.

有没有同学解决过这个问题，网上搜索了半天资料，都是说会遇到错误都是 Pg 版本低，我一开始用 16，最后换到 latest，还是一样。

一句 has_many 在背后做了哪些事情？

zzz6519003 — Fri, 05 Sep 2025 12:09:12 +0800

Ruby China 社区 Rails 节点

新书《Rails 8 现代单体架构实战》发布

新书介绍

新书样章

社区折扣

rails 项目里用 kamal 部署阿里云 ssl 证书流程总结

背景

以下是使用 Kamal 将阿里云 SSL 证书自定义 部署的完整流程：

一、准备 SSL 证书文件

二、创建本地证书存储

三、配置 .kamal/secrets

四、配置 config/deploy.yml

五、部署验证

六、打开网页测试

讓 ActiveRecord model 只能在特定 service class 裏被更新

早说了转语言了身体却很诚实...

前情提要

gems.ruby-china.com 缺少 bigdecimal 4.1.1 版本

官网宣传语变成“省 Token” “方便 Agent 编写”

发现 Rails 在 AI 时代好像挺适合做实验性质的项目的

AI 开发 Rails，如果遇到 bug 看不懂咋办？

一個用 DIDComm 實現服務器間通信的 Rails demo

内容审核（头像审核、昵称审核）技术对比，阿里云内容安全审核 api 和大模型 LLM 的 PK 对比

一、背景与目标

1.1 为什么需要做对比

1.2 对比目标

二、先直接给出结论

三、方案调研

3.1 昵称/文本审核：准确性与价格

3.2 头像/图片审核：准确性与价格

3.3 阿里云现有方案（对比基准）

四、我们的实际对比测试

4.1 测试设计

4.2 图片审核实测

4.2.1 qwen-vl-plus vs qwen-vl-flash（50 张图，统一 q100 jpg）

4.2.2 原图 vs 800px 宽格式化为 jpg(image/resize,w_800/quality,q_90/format,jpg

4.3 昵称审核实测（30 组，使用 qwen-plus-latest）

4.4 准确度对比

图片审核

昵称审核

4.5 我们的 dify 工作流

4.6 关于费用怎么对比

五、阿里云 API vs LLM 优劣势

5.1 阿里云内容审核 API

5.2 LLM 多模态审核

六、最终选型与实施建议

6.1 选型结论

6.2 实施建议

Rails 技术实战之 AI 找货小助手设计

AI 找货助手技术实现指南

需求预览

目录

核心概念

一、技术架构总览

1.1 整体架构图

1.2 商品列表接口

1.3 数据流转

1.4 技术栈

二、SSE 事件设计

2.1 事件流程图

2.2 事件类型

2.3 事件数据格式

2.4 事件顺序和处理规范

三、Dify 对话流设计详解

3.1 工作流核心结构

3.2 Start 节点

3.3 意图识别

3.4 属性提取

3.5 条件判断

3.6 生成追问

3.7 HTTP 请求节点

3.8 结果合并

四、向量搜索技术详解

4.1 为什么用向量搜索

4.2 向量搜索原理

4.3 EmbeddingService 实现

4.4 商品向量同步 Job

4.5 ES KNN 查询构建

4.6 召回、排序、重排

4.7 完整 ES KNN 查询示例

以下是使用 Kamal 将阿里云 SSL 证书自定义部署的完整流程：