Ruby China

寻找“乡村黑客”：向着广阔的乡土出发

jiang_plus — Tue, 12 May 2026 12:06:29 +0800

将实验室搬进稻田，把代码写在大地，对物理世界编程，以创意文化展现乡村之美。科技赋能，设计向善，用人工智能重塑中国乡村的数字化进程。

前往先进的乡土

关于乡村，我们听过太多流行的叙事：回不去的乡愁、需要被振兴的落后、直播间里的土味猎奇，或是盆景化的古村落。乡村的位置始终是被叙述的那一方——被怀念、被帮扶、被消费、被观赏。这次，我们想换一个位置。当无人机掠过稻田，代码在垄亩间编织成新的经纬。在 AI 加速迭代、数字逻辑几乎统治日常的当下，我们想提出一种乡村未来主义：开阔的场域安放多元的生活姿态，自然的环境滋养不异化人的技术。乡村广阔、包容，正以一种深邃的姿态，供前卫的实验在此扎根。我们希望从一场前后周期一个月的黑客松开始，延展至持续几年的活动以及大社群的建立，向世界发送这样两条信息： 1.乡村不再是凝固的传统空间，而是灵感迸发与先进实验的策源地。2.乡村是温柔且积极的，它是想象力与创造力最宽广的试验场。何出此言？且让我们邀请你来亲历这场实验，去感受当所有要素一起聚集在乡村的时刻：一片虚位以待的土地，一种回归人本的环境，一群跨界共生的伙伴，一种温润克制的技术......我们邀请你来想象，当它们在田垄间交织、在泥地中碰撞，可能会缝合起怎样一个崭新的未来？

这次有什么特别的？

这不是一场典型黑客松，不是普通乡创，而是站在人类科技发展进程的十字路口，思考我们走过的道路，并放眼去看未来更多的可能性。在务实与技术之余，它更是关乎人文，关乎想象，关乎未来的。

这场乡村 + 黑客松：一不拘泥于传统乡村应用场景——如农用机械，文创等；二不局限于经典的黑客松人群——不是只有技术黑客才能参加。它是面向先进的、不断演化的、有无限空间和可能性的乡村，也因而需要一种更加复合的想象力。我们想寻找的人，想链接的社区，所形成的是一种整全的集体：会技术，有思考，可艺术，能实干，强经验。

促成几种人群，几类社区的链接：

✦✦擅长跨地域链接、善用技术的独立组织和来自创意社群的社区朋友们拥有多年在地经验、深耕乡村的乡建朋友们穿梭在城乡之间、寻找生活新可能的探索者们

✦✦我们希望借助黑客松的形式，为他们创造一个交流、链接和创造的场域，邀请他们来乡村的田野上体验“思辨推演”、“经验验证”、“技术实现”，在彼此的交流中实现融合的过程，让文化、技术、经验共铸一个具有想象力的乡村未来。或许你想寻找乡村创业的机会，或许你想尝试 AI+ 乡村的可能，或许你只是想探索乡村生活的可能性。那么，这里不只是一场极客聚会，不是一场消费乡村概念的快闪，也不只会是一场灵感的冲刺，而是通过比赛的契机相互链接之后，未来的长期共建：✦去思考近代百年来的乡土变革去看回村创业如何长期落地，驻村怎样可持续去看各式各样的另类社区、创意社群如何进行链接和别样实践去看由实业者、返乡青年、数字游民，多元社区聚合起来的村庄会生长出怎样的可能

✦✦ 我们邀请你去作为思考者、创作者参与在地对话，我们会向你们呈现乡村真实的面貌——它的机会与困境、在这里生活的人和真实发生的人和故事。

我们想要你来创什么？或许你感到迟疑，认为乡村的图景过于传统或遥远。但我们希望你打开想象：乡村不是只有农地、民宿和旅游。在 AI 工具的加持下，我们将探索技术与人文的崭新耦合。你的创作可以是：务实、具有公益底色的：比如具身智能的农用方案、促进信息流通的分布式平台、实现数字平权的教育工具，或是针对老人与儿童的看护系统；充满创意与生命力的：比如利用 AIGC 转译非遗文化的数字艺术、跨越时空坐标的乡村潮玩、或是重塑在地美学的建筑插件；前卫、富有实验性的：去构筑一个乡村 OPC 社区、去实验 AI Commons（数字公地）、或开发 AI For Good 的应用，探索算法治理下一种人性化的社区契约。

✦✦我们将划分软件、硬件、文创三大赛道，并提供一系列可选的主题参考。当然，我们更期待那些跳脱出预设主题之外的、自由生长的想法。

需要什么人？这不是一场只有写代码才能参加的黑客松，相反，我们期待这样一帮对乡村未来有好奇心的普通人：✦生活逻辑的思考者：你未必研读过哲学，但你习惯对习以为常的生活方式发问。在 AI 席卷而来的时代，你关心人的主体性在哪里，关心那些被效率抹平的价值如何重新显现。社区秩序的观察者：你关注人与人的连接，能敏锐地察觉到乡土结构在现代性冲击下的裂痕与温情。你懂得如何倾听土地的声音，也理解城市人群在过饱和竞争中的精神突围。感官与美感的创造者：你擅长将抽象的想法转化为具象的触感。无论是文字、影像、设计还是艺术装置，你能够赋予技术一种温润的界面，让冷冰冰的代码拥有人文的温度。在地经验的守望者：你可能是有几十年经验的乡建人，也可能是吾爱吾乡的新老村民。你深耕田野，理解土地的脾气与村庄的肌理；你拥有最真实的体感经验，知道什么叫“落地”，帮助团队避开悬浮的构想，让技术精准接入乡村真实的需要。技术与工具的实干家：你可能是代码的高手，也可能是擅长应用各类数字工具的极客。你享受那种亲手解决一个问题的踏实感，并愿意尝试让技术向下扎根，去回应最真实的生存需求。 ✦✦不同特长的人组成队伍，从思想到技术再到经验的完整对话，实现理想与实际的结合，让我们既实在又富有想象力地在乡村碰撞一场，创造一场。

怎么创？不必担心你不懂乡村，不必担心你不懂技术：乡村经验不是必需，软件硬件知识不是必需，不熟悉 AI 工具也没关系，我们一个月的线上预热工作坊会全力促进大家进行知识的交流互换和共享；我们将邀请乡建团队讲诉乡建历程，分享几十年在地经验；邀请技术社区分享跨社群的技术连接，平台搭建；邀请创变社群分享他们的多样实践。在知识和技能以外，更重要的，是让不同的社区，不同背景的人群提前熟悉彼此。在组队时，根据需要，我们也会帮助大家进行不同技能角色上的搭配，一个典型的队伍，或许是：灵感哲学家 + 艺术家 + 乡建人 + 技术咖。灵感可以提前一个月酝酿，易上手的技术可以提前学习，队友可以提前交流互动。没有传统黑客松的时间焦虑，不是为了创而创的赶鸭子上架，我们细细聊，慢慢了解，好好来往。AI 工具已经先进到任何人都可以只动嘴不动手，只要够好奇就大胆来吧！

你会收获什么？这不仅是一场比赛，更是一张进入人文与技术高度融合共创圈的入场券。我们试图在这次集结中，打破孤岛，建立一个长期互动的社区共生体。在这里，你不仅能链接到各地深耕乡村建设二十年、拥有深厚在地智慧的实践者，更能对话链接全球开源精神与公民科技的创新社群。为了让这份构想实现落地，我们同时为比赛准备了最坚实的支撑：✦全方位的共创保障：我们设立了 10 万元人民币的现金奖金池，用以奖赏那些最具启发性的方案。在 5 月 21 日至 5 月 24 日的核心比赛期间，我们将为参赛者提供全包式的住宿支持——我们负责解决琐碎，你只需负责灵感。一份长期的入乡邀约：参赛者将有机会进入“数智乡建屏南人才库”。对于优秀的共创项目与团队，我们将开放四坪村“数字人才驿站”的长期入驻权，及后续的专业孵化支持。 ✦✦我们希望每一位“乡村黑客”，不仅能在这里碰撞出惊艳世界的瞬时灵感，更能在这片土地上安放理想，实现真正的长久栖居。

活动信息

活动地点：福建省宁德市屏南县·熙岭乡（龙潭村、四坪村双村联动）线上：4 月底至 5 月赛事前整月工作坊主题预热线下：5 月 18 日~20 日线下预热活动（可自由选择是否参与）赛事：5 月 21 日~24 日黑客松比赛落地支持：

黑客松 10 万元奖金池；参赛者住宿全包；合作伙伴餐饮交通补贴长期福利：数智乡建屏南人才库；四坪数字人才驿站；优秀项目孵化支持更多工作坊信息、黑客松具体赛道设计、评委、审核标准将在后续公布。

共创招募

在大幕开启之前，我们欢迎大家以“共建者”的身份先行入场。我们需要更多志同道合的伙伴，在不同的社群脉络间穿针引线，共同筹备那些激发灵感的工作坊和相遇。在正式相聚前，亲手编织出这场碰撞的底色。

我们正式向你发出邀请：无论你是技术极客、视觉艺术家、跨界实践者、社群活动家、乡建工作者，还是新老村民，请带上你的专长与经验来到这里。在碰撞、交流与合作中，我们一起植根乡土，完成一场不设限的共创大集。让我们用代码与技术、用艺术与创意，去搭建乡村与未来的桥梁。不预设创意的边界，不定义乡村的需求，我们只提供一方田野上的空地，让来自各个背景的伙伴架起一簇篝火，用彼此的碰撞来点燃它。

赛道

我们设计了三条不同的赛道，让每一种才能都能找到发挥的方向：

01 软件：村镇经济体与 AI 乡村赋能 跨越基础信息化阶段，探索大语言模型（LLM）、空间计算与复杂系统模拟在乡村经济体中的深度应用。可参考方向 Vibe Coding：通过 AI 为乡村数字应用的快速迭代助力。OpenClaw（小龙虾）：服务乡村场景的 Agent 智能体与工作流。村务信息服务：打通村务信息孤岛，为村民提供全方位的信息服务。

02 硬件：具身智能与农用智能设备 针对中国复杂地形与农村经济特征，研发低成本、高鲁棒性、易维护的边缘计算设备与具身智能硬件。可参考方向机器人：为农业场景打造具身智能的前沿。无人机：用无人机进行农田巡查、病虫害监测、作物生长监测等。智能传感器在传感器和智慧农业方向深度探索。

03 文创：社会创新与可持续设计 超越传统的包装美化，运用系统性设计思维与 AIGC 等新媒介，重塑乡村文化资产与生态循环模式。可参考方向服务设计与社区营造：重构乡村公共空间交互体验，设计吸引"数字游民"与原住民共居共创的社会化服务流。AIGC 与非遗保育：利用生成式 AI 提取传统手工艺（如刺绣、木雕）的参数化特征，生成现代设计应用。乡村循环经济设计：针对农业废弃物（秸秆、果壳）的材料创新与高附加值产品转化设计。参考方向仅供定位，我们也欢迎更多大胆创新的想法

报名入口：

https://build.xjdao.xyz/forms/hackathon-2026

公众号链接：

https://mp.weixin.qq.com/s/Si7mUhGLYSukZR4TjpR3tg

matz 用 claude 把 mruby 的 issues 全关了

xiaoLinger — Tue, 12 May 2026 10:13:16 +0800

https://github.com/mruby/mruby/issues 已经只有一个 issues 了

随便点开几个基本上都是 matz and claude committed

[成都 / 远程] Python 后端工程师 - 前硅谷大厂资深工程师带队，美资 FinTech 初创投资决策平台 (15k / 月)

pulse08 — Tue, 12 May 2026 01:49:36 +0800

我们是一家在美国的 FinTech 初创公司，由前硅谷大厂资深工程师带队。目前我们正在研发一款全新的美股投资决策平台。现在，我们诚寻一位能独立承担开发工程项目落地的全栈极客加入，作为国内研发节点的第一位研发骨干。

💻 你将负责什么？

你需要开发支撑业务运转的工程系统：

数据管道：负责海外金融数据获取，以及海量异构财务数据的清洗与入库。
工程计算：将复杂的财务数据计算逻辑工程化
全栈落地：开发前端 UI 看板系统及移动端 App。
系统保障：负责整个软件生命周期的自动化测试及系统健康度监控体系。

🎯 我们在寻找怎样的你？

背景：正规高校计算机相关专业，3-5 年工作经验。
技术栈：扎实的后端功底（Python/Go/Node.js 等语言不限，看重底层系统思维）+ 数据管线经验 + 现代前端/移动端开发落地能力。
软素质：聪明，极度自驱。具备在没有庞大运维团队支持下，独立架构、部署和排查疑难杂症的能力。

💰 我们能提供什么？

薪资：15,000 RMB / 月及每年最多 2 个月奖金
合规保障：通过全球顶级平台 Deel 与你签订 Contractor 协议
工作方式：纯 Remote，地点限成都。不打卡，没有无效会议
技术成长：使用最先进的 AI 编程工具，与资深专家协同开发，深度了解华尔街价值投资与基本面分析的底层逻辑

如果你想在一个极其纯粹的工程师环境里主导搭建一套极具挑战的线上系统，请联系我们。

📫投递邮箱：

info@pulsefeed.ai

投递请务必附上 GitHub 链接或技术博客 , 请在 Email 开头写上 Pulse Alpha

11 英寸 MacBook 的第二春：从零开始配置 Ruby on Rails 开发环境

AixCoder — Sun, 10 May 2026 13:22:14 +0800

🌸 旧 MacBook 的第二春：从零配置 Ruby on Rails 开发环境

"最好的设备是你手里那台。"

很多同学手里都有一台旧的 MacBook Air，可能是当年为了写论文买的。现在用起来有点卡，打开 App 要转圈圈，似乎只能沦为追剧专用机。

但别急着放弃它。

MacBook 的硬件做工一向扎实，老机器的问题往往不是性能不够，而是系统里堆积了太多垃圾，以及没有装对工具。就像一间堆满杂物的房间，不是房子太小，而是需要重新整理。

给这台旧电脑重装系统 → 安装 Homebrew → 配置 Ruby → 搭建 Rails，它就能从追剧神器变身成一台趁手的编程学习机、写作工具，甚至是一台随身携带的代码终端。

安装前的准备：重装系统

强烈推荐先重装系统。 如果这台 MacBook 从买来到现在就没重装过，系统里可能积累了各种残留文件。

操作很简单：

备份重要文件到移动盘或云盘
开机时按住 Option + Command + R，进入在线恢复模式
选择重新安装 macOS，把系统恢复到最干净的状态

重装后的系统就像刚搬进的空房子，接下来我们往里面添置需要的家具。

第一步：安装 Homebrew

Homebrew 是什么？

Homebrew 就像 Mac 中隐藏版的应用商店，但比 App Store 强大得多。

想象你想在新家里添置家具：

App Store	Homebrew
像大型商场，卖的都是精装成品（爱奇艺）	像万能仓库，程序员需要的各种工具、语言、软件，一条命令就能自动下载、安装、配置好
买不到专业工具，或者版本很旧	永远是最新版，不需要你到处找安装包、点下一步、输密码

安装命令

打开终端，复制粘贴下面这行命令：

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

系统会提示你输入开机密码（输入时不会显示字符，这是正常的，输完直接回车）安装过程可能需要几分钟，取决于网速。(建议安装的过程中全局科学上网)

安装 Homebrew 的过程中，它会顺带安装 Command Line Tools for Xcode。

Command Line Tools for Xcode 是什么？ Xcode 是苹果官方出的集成开发工具，里面包含了开发 iPhone App 需要的所有重型设备（几十个 GB）。但对于 90% 的开发者来说，我们不需要那个庞然大物，只需要里面最核心的几件工具

编译器 (Compiler)：把人类能看懂的代码，"翻译"成电脑能听懂的机器指令 构建工具 (Make)：相当于安装指南，告诉电脑第一步拼哪块，第二步缝哪条线

这就是 Command Line Tools for Xcode，包含了所有让代码"跑起来"的必要工具。

验证安装成功

brew --version

如果显示出版本号（例如 Homebrew 5.1.10），恭喜你，Homebrew 已经就位。

第二步：安装 rbenv

rbenv 是什么？

rbenv 是 Ruby 的「版本管家」。 它让你在同一台电脑上安装多个 Ruby 版本，想用什么版本就切什么版本，互不干扰。

为什么我们需要它？

想象一下，你是一个热爱生活且多才多艺的女生：

今天你想做一个现代感十足的网站，需要请 Ruby 3.2 大师来帮忙
明天你想维护一个几年前的老项目，那个项目很挑剔，需要指定某个版本的 Ruby
而你的 Mac 系统一直带着一个"老古董" Ruby 2.6 系统管理员，它是用来维持系统运行的，你最好不要动它

如果没有 rbenv： 你得在电脑里装好几个 Ruby，它们会为了争夺"谁才是真正的 Ruby"打架，最后把你的系统搞得一团糟

有了 rbenv： 简单管理多个版本的 Ruby，系统自带的旧版本不动，新版本各住各的房间，互不打扰

安装命令

brew install rbenv

安装的过程可能比较慢，因为电脑比较老了，很多工具得现场编译，耐心等待吧⌛️

安装完成后，请运行以下命令来配置 rbenv

rbenv init

关闭终端，重新打开，以确保更改生效。

验证安装

rbenv -v

第三步：安装 Ruby

Ruby 的美丽：一门像诗一样的编程语言

rbenv 管家已经就位，现在该请真正的主角进场了。

Ruby 像一首诗

它的发明者松本行弘（Yukihiro Matsumoto）说过一句话：

"我希望 Ruby 让程序员感到快乐。"

安装命令

先查看 rbenv 目前能提供的比较稳定的几个 Ruby 版本：

rbenv install -l

对于这台老旧 MacBook，我装了的 Ruby3.3.10，和其他设备保持版本一致性

rbenv install 3.3.10

💻 老旧 MacBook 特别提示：编译 Ruby 可能需要 10-20 分钟，风扇会狂转，这是正常的。建议插电进行，去泡杯茶，回来就好了。

装完后，设为默认版本：

rbenv global 3.3.10

验证安装

ruby -v

ruby 3.3.10 (2025-10-23 revision 343ea05002) [x86_64-darwin20] 旧 MacBook 现在拥有了一颗年轻的心脏

第四步：安装 Rails

Rails：Ruby 的黄金搭档，让想法快速落地

如果说 Ruby 是一首诗，Rails 就是一家出版社 它不负责写诗，但它让诗能被印刷、装订、送到读者手中，而且整个过程快得惊人。

Rails 像是一套「盖房子的标准化流程」。

你想搭一个网站，Rails 已经帮你把地基打好了、水电接通了、门窗装好了。你只需要决定：墙上刷什么颜色的漆、客厅里摆什么家具。

想象你去一家很懂你的咖啡馆：

你一坐下，店员就知道你要燕麦拿铁、半糖、去冰
不需要你每次都说一遍

Rails 就是这样。它假设你「大概率会这样做」，所以提前帮你把选择做好了。这种哲学叫 "约定优于配置"（Convention over Configuration）。

对于初学者来说，这太重要了。 你不需要先成为「全栈专家」，就能先做出一个「能用的东西」。成就感来得早，学习动力就足。

记得当时做一个诗歌小站——可以读诗、投稿、玩一个简单的文字游戏，结合 AI 编程，好像用了大半天就做出来了。

gem 是什么？

当你通过 rbenv 安装好 Ruby 的那一刻，gem 就已经坐在你电脑里了。

gem 的全名叫 RubyGems，是 Ruby 官方的包管理器，可以理解成 Ruby 世界的「快递总站」。

它的工作流程：

你在终端说：gem install rails
gem 就联网去 rubygems.org（Ruby 的官方仓库）
找到 Rails，把它连同所有依赖一起打包下载、自动安装

安装命令

gem install rails -v 你想要的rails版本

⚠️ 如果下载很慢：因为 gem 默认去国外的仓库拉货，可能会卡很久。建议先换成国内镜像源（ruby-china 镜像源）

安装过程可能需要几分钟，gem 会自动下载 Rails 及其所有依赖。

验证安装

rails -v

第五步：创建并启动你的第一个项目

1. 新建项目

在终端里输入：

rails new rails_nice

你会看到很多绿色的输出，正在新建项目，请稍等。

💻 老旧 MacBook 特别提示：第一次创建项目时，Rails 需要安装依赖，可能会比较慢，请耐心等待。

2. 进入项目文件夹

cd rails_nice

3. 启动服务器

bin/rails s

4. 你会看到什么？

终端里会显示：

=> Booting Puma
=> Rails 7.2.3 application starting in development 
=> Run `bin/rails server --help` for more startup options
Puma starting in single mode...
* Puma version: 8.0.1 ("Into the Arena")
* Ruby version: ruby 3.3.10 (2025-10-23 revision 343ea05002) [x86_64-darwin20]
*  Min threads: 3
*  Max threads: 3
*  Environment: development
*          PID: 14775
* Listening on http://127.0.0.1:3000
* Listening on http://[::1]:3000
Use Ctrl-C to stop

看到 Listening on http://127.0.0.1:3000，就是启动成功了。

5. 在浏览器里查看成果

打开 Safari（或任何浏览器），地址栏输入：

http://127.0.0.1:3000

写在最后

从重装系统，到 Homebrew，到 rbenv，到 Ruby，到 gem，到 Rails，再到 bin/rails s——这台旧 MacBook，终于焕发了第二春。

旧物值得被认真对待，学习也可以从当下便宜的设备开始。

M 芯片的 MacBook 就留着干重活吧，这台 macbook air 小电脑，很轻巧。

💡 小结

整个流程其实就是一个“套娃”安装的过程：

用 command line tools for xocde 为 Homebrew 铺路。
用 Homebrew 安装 rbenv。
用 rbenv 安装 Ruby。
用 Ruby（自带的 gem）安装 Rails。

每一个上层工具都依赖下层提供的环境。这就是为什么当初我们必须先解决 Xcode 开发工具安装的问题。

好啦，看到这台“小破机”重新跑起代码，😄 作为编程学习机和写作工具来说真是很好，非常适合带出门轻度使用。小电脑，很轻巧。

OpenClacky 1.0 正式发布 —— Ruby 圈第一个通用 Agent 来了

lyfi2003 — Sat, 02 May 2026 11:50:26 +0800

前段时间社区里一直有人在问：Python 那边 agent 框架一个接一个，Ruby 圈怎么就没一个拿得出手的通用 Agent？

我们憋了两年，今天它来了。

OpenClacky 1.0.0 正式发布，MIT 开源，纯 Ruby 写的。

GitHub：https://github.com/clacky-ai/openclacky
官网（桌面安装包）：https://www.openclacky.com/#install

本文分两部分：先说是什么、怎么用；然后讲讲我们是怎么把 Token 成本打下来的 —— 后半段才是干货，欢迎直接跳到第三节。

一、这是个什么东西

一句话：最省 Token 的开源通用 AI Agent。

能力上对齐 Claude Code，成本打到它的 0.8~1.2×；相比其它开源 agent（如 OpenClaw、Hermes），大约便宜 50% ~ 3 倍。

两种用法，30 秒就能跑起来：

# 安装
gem install openclacky

# 命令行
openclacky

# 或者跑 Web UI（多会话并行）
openclacky server    # 默认 http://localhost:7070

BYOK，任意 OpenAI 兼容模型都支持：Claude / GPT / DeepSeek / Kimi / MiniMax / OpenRouter，或者任何自定义 endpoint。进去 /config 填 API Key、Model、Base URL 就完事了。

二、为什么我们又要再写一个

用过 Claude Code 的朋友应该都很惊艳，但三个问题一直没解：

闭源 + 订阅制，拿不到内部细节，也没办法定制
只能用 Anthropic 自家模型，不能 BYOK
对中国开发者来说，付费通路不顺畅

我们也试过 OpenClaw、Hermes 这些开源方案，能力是有的，但实测下来 Token 成本是 Claude Code 的 1.5× ~ 3×。

这是什么概念？一个中等规模的项目，一天下来 token 费可能就是几十到几百块，差 2~3 倍就是实打实的 RMB 差 2~3 倍。对个人开发者和小团队太贵了。

所以我们自己做了一个。目标很明确：能力不输，成本打到最低。

三、怎么把 Token 成本打下来的（干货）

先看对比表：

Agent	相对成本	工具数	开源	BYOK	IM 集成
Claude Code	1.0×（基准）	40+	❌ 闭源	❌	❌
OpenClaw	~1.5×	23	✅	✅	✅
Hermes	~3×	52	✅	✅	✅
OpenClacky	~0.8	16	✅ MIT	✅	✅

注：数据是内部常见 agent 任务的平均值，以 Claude Code 为基准。完整 benchmark 后续会放到 GitHub。

不是靠砍功能，是靠每一层都做对选择，复利叠加下来的。下面讲四个关键决策。

3.1 缓存命中率接近 100%

这是最大的一块。Agent 类应用的对话上下文非常长，API 侧的 prompt caching 是省钱的核心。做对了，成本直接砍一半以上；做错了，基本等于没开。

我们做了三件事：

Session 不重启。 很多 agent 每次启动或切换任务都会重建上下文，前缀一变 cache 全丢。OpenClacky 的 session 生命周期贯穿整个进程，工具调用、子 agent 调度、Skill 执行都挂在同一条上下文上。

双 cache marker。 OpenAI / Anthropic 家的 caching 都是按前缀对齐。我们在 system prompt 尾部和对话中段各打一个 marker，确保即使中段有动态插入，前半段仍然完整命中。

Insert-then-Compress。 这是关键。传统做法是上下文满了就"压缩 + 重写 system prompt"，一旦 system prompt 变了，前缀 cache 全失效，下一条消息变成冷启动。

我们反过来：system prompt 永远不变，压缩发生在对话区，用"插入一条总结 + 裁剪被总结的内容"的方式。system prompt 那段前缀的 cache 永远是热的。

实测下来 cache 命中率接近 100%。

3.2 最小工具集：只有 16 个

这点反直觉，我们反复测过 —— 工具不是越多越好，是越精越好。

OpenClacky	Claude Code	OpenClaw	Hermes
16	40+	23	52

为什么？因为工具的 schema 是要塞进每一次请求的 system prompt 的。52 个工具意味着 schema 膨胀 3~4 倍，每次对话都要多烧这么多 token。更糟的是 schema 越大，模型选工具的准确率反而下降（这点我们跑过对照实验）。

我们的做法是把所有非核心能力下沉到 Skill 体系，主工具只保留一个 invoke_skill 元工具。需要 PPT？有 skill。需要 SQL 调优？有 skill。需要内部规范？有 skill。

工具数量不是指标，任务完成率才是。

3.3 空闲时间自动压缩

这个功能用起来很爽。你去开会、喝咖啡、吃饭，agent 并不是闲着 —— 它在后台做两件事：

把长上下文做渐进式压缩
预热压缩后的 cache

等你回来发第一条消息，直接命中热 cache。冷启动首 token 成本降低 50%+。

3.4 BYOK + 子任务路由

BYOK 大家都有，但我们多走了一步：主任务用 Claude，子 agent 的子任务可以路由到 DeepSeek / Kimi 这种便宜模型。能力不损失太多，成本再砍一大块。

这四条叠起来，才是那个 0.8 的数字。

四、Skill —— Agent 的灵魂

Skill 是我们认为 Agent 下一个阶段的关键。简单讲就是可插拔的"领域技能包"。

/ 直接召唤：即时浏览、模糊搜索、直接调用，上百个 Skill 随手可用
自然语言创建：你描述想要什么，agent 自己起草 SKILL.md、拆步骤、跑验证，不用写代码
自我进化：每次执行完，agent 根据执行过程和结果回写更新。下一次调用更稳、更准
开放兼容：支持 Claude Skills / Markdown Pack / 自定义格式
可变现：打磨好的 Skill 可以打包加密分发、License 管理、自定价格

现在已经有用户在上面做垂直专家 Skill 了 —— 法律、医疗、理财规划，都有人跑起来。创作者计划的细节可以看官网。

五、用例示范

今天 agent 能"问个项目问题"已经是及格线了，真正拉开差距的是能不能端到端交付一件事。下面几个是我们自己和早期用户每天在跑的真实场景。

用例一：从零交付一个 SaaS 原型（多 session 并行）

$ openclacky server

开三个 session 并行：

Session A:/new 生成 Rails 7 + Tailwind 项目，建好 User / Subscription 模型，接 Stripe 订阅
Session B：写落地页文案、SEO meta、FAQ，同时用 Skill 调 PPT 生成器出一份投资人 deck
Session C：跑用户访谈资料分析，输出 PMF 判断报告

三个 session 共享同一份 workspace 上下文，改完 A 的定价策略，B 的落地页文案自动跟上。以前这是三个人半天的活。

用例二：给一个 20 万行的老项目加功能，并让它自己跑完回归

> 我要在订单模块加"部分退款"能力，退款后要同步更新财务对账表、
  触发用户邮件、并在 admin 后台补一个退款审核流程。
  跑完 rake test 确保所有测试通过再交付。

它会自己：读相关模块 → 列修改计划 → 写代码 → 跑测试 → 测试挂了自己修 → 再跑 → 通过后给你一份变更摘要。

整个过程基本不用盯，空闲时它还在后台做 context 压缩，你去吃个饭回来直接看结果。

用例三：自己造一个垂直 Skill，让它永久变强

> 我经常要做"Rails 项目性能体检"，固定看 7 个指标：
  N+1、慢查询、索引缺失、Puma 配置、内存占用、cache 命中、日志异常。
  帮我做成一个 Skill。

它会起草 SKILL.md、拆步骤、跑一次验证、让你确认。之后 / 搜 "体检" 直接召唤，跑一次自动进化一次，下次更准。好的 Skill 可以打包加密分发、定价出售 —— 我们已经有用户靠卖垂直 Skill 跑通商业闭环了。

用例四：跨代码库迁移 / 大重构

比如把一个 Rails 5.2 + Sprockets + jQuery 的老项目，迁到 Rails 7.2 + Importmap + Stimulus + Turbo。这种活以前外包报价 5 万起，而且没人愿意接。

现在开一个 session 挂上去，分阶段跑：依赖升级 → Asset Pipeline 切换 → 前端重写 → 测试补齐。每一阶段都让它先出计划再动手，人只做把关。

用例五：Web UI 当成"自己的研发中台"

openclacky server 起来的 Web UI 不止是聊天窗口，是一个常驻的多人 / 多项目协作平台：

团队内几个人共享 session，接力干活
跑 IM 集成（飞书 / 企微 / 微信），在群里 @ 它派任务，结果回群
本机跑、或者扔一台服务器上 --host 0.0.0.0 团队一起用

这一条是我们自己团队现在的日常 —— OpenClacky 自己就是用 OpenClacky 开发的。

六、关于技术选型的一些闲话

很多人问我们为什么坚持用 Ruby 做这个。

其实 agent 这种场景，Rails 那套"convention over configuration"的哲学一样好使。迭代速度、元编程能力、gem 生态都是加分项。这两年我们三代架构、六个核心 harness 工程决策，反复推翻重来，Ruby 的表达力帮我们省了大量时间。

我希望 Ruby 社区也有自己拿得出手的 AI 基础设施。不只是"能用"，而是"够硬、能打"。

七、最后

OpenClacky 1.0.0 正式发布了，来源 100% 开放（MIT），所有决策都可追溯。

GitHub：https://github.com/clacky-ai/openclacky
官网 / 桌面安装包（macOS、Windows）：https://www.openclacky.com/

欢迎 star、试用、提 issue、贡献 Skill，也欢迎直接在本帖回复交流。后续我会再写几篇详细技术博客：缓存命中率的工程细节、Skill 自进化的实现、子 agent 路由的 scheduling —— 每一篇都是这种干货。

项目背后由奇绩创坛、真格基金、红杉中国、高瓴资本支持，特此致谢。

希望本文对大家有所帮助。有问题欢迎交流。

一夜重构！我用 18000 行代码打造了完全自研的 AI TUI 终端-IFAI Cli

peterfei — Mon, 27 Apr 2026 21:20:00 +0800

作者：peterfei 发布时间：2026-04-27 阅读时间：3 分钟 难度：⭐⭐⭐⭐⭐

凌晨 3 点的挑战

深夜，电脑屏幕前的咖啡已经凉了第三遍。

我盯着一段 1200 行的 match 语句——这是 IfAI CLI 的事件处理系统。每次添加新功能，都要在 15 个文件里修修补补，单元测试覆盖率一团糟。

"这不是我想要写的代码。"我对自己说。

凌晨 3 点，我做出了一个疯狂的决定：推倒重来，一夜之间重构整个 TUI 架构。

天亮之前，我做到了。

为什么选择自研 TUI？

市面上有现成的 TUI 框架（ratatui、crossterm），为什么还要自研？

因为 AI 工具的交互需求，与传统终端应用完全不同：

传统 TUI 应用	AI CLI 工具
静态菜单	实时流式输出
单一模式	多模式切换（输入/搜索/帮助/审批）
简单事件	复杂事件链（键盘 + 鼠标 + 流+工具调用）
固定布局	自适应布局（欢迎页/内容/帮助覆盖层）

现有的 TUI 框架解决的是"如何渲染"，但 AI 工具需要的是"如何智能交互"。

所以，我选择在 ratatui 之上，从零构建一套完整的 TUI 应用层架构。

一夜之间：从混乱到优雅

重构前的痛点

// ❌ 重构前：1200 行面条式代码
fn handle_event(event: Event, app: &mut App) {
    match event {
        Event::Key(key) => match key.code {
            KeyCode::Char('c') if key.modifiers == CONTROL => {
                // Ctrl+C 处理（嵌套 if-else）
                if app.input_mode {
                    if app.search_mode {
                        // ...
                    } else {
                        // ...
                    }
                }
            }
            // ... 还有 100+ 个按键组合
        }
        Event::Mouse(mouse) => match mouse.kind {
            MouseEventKind::ScrollUp => {
                // 滚动处理（30 行嵌套逻辑）
            }
            // ...
        }
    }
}

问题：

添加一个搜索功能，需要改 8 个文件
单元测试难以编写（所有逻辑耦合在一起）
模式切换逻辑混乱（if app.search_mode && !app.input_mode）

重构后的架构

// ✅ 重构后：声明式事件路由
fn build_event_router() -> EventRouter<Event> {
    EventRouter::new()
        .on(|e| matches!(e, Event::Key(_)), HelpEnterHandler)
        .on(|e| matches!(e, Event::Key(_)), HelpExitHandler)
        .on(|e| matches!(e, Event::Key(_)), SearchEnterHandler)
        .on(|e| matches!(e, Event::Key(_)), SearchInputHandler)
        .on(|e| matches!(e, Event::Key(_)), CombinedKeyHandler)
        .on(|e| matches!(e, Event::Mouse(_)), MouseScrollHandler::new())
        .fallback(IgnoreHandler)
}

优势：

每个处理器平均 30 行代码
添加新功能只需 2 个文件改动
单元测试覆盖率 100%

代码量对比： | 指标 | 重构前 | 重构后 | 改善 | |------|--------|--------|------| | 事件处理代码 | 1200 行 | 400 行 | -67% | | 单元测试覆盖 | 未知 | 404/404 通过 | 100% | | 新功能改动文件 | 15 个 | 2 个 | -87% |

完全自研的 TUI 组件

IfAI CLI 的 TUI 不是简单的 ratatui 封装，而是从应用需求出发，完全自研的组件系统。

1. 自研输入框 (input_composer.rs)

为什么不用 rustyline？因为需要与 ratatui 渲染深度集成。

pub struct InputComposer {
    buffer: String,
    cursor_pos: usize,  // 字节索引，正确处理 UTF-8
    history: Vec<String>,
    history_index: Option<usize>,
    draft_backup: String,  // 浏览历史时保存草稿
}

impl InputComposer {
    // 正确处理 CJK 字符的 Backspace
    pub fn handle_key(&mut self, key: KeyEvent) -> InputAction {
        match key.code {
            KeyCode::Backspace => {
                let prev_char_start = self.buffer[..self.cursor_pos]
                    .char_indices()
                    .last()
                    .map(|(i, _)| i)
                    .unwrap_or(0);
                self.buffer.drain(prev_char_start..self.cursor_pos);
                self.cursor_pos = prev_char_start;
            }
            // ...
        }
    }
}

// 光标列计算（CJK 字符占 2 列）
pub fn cursor_col(composer: &InputComposer) -> u16 {
    let display_width: usize = composer.buffer[..composer.cursor_pos]
        .chars()
        .map(char_width)
        .sum();
    (composer.prompt.len() + display_width + 2) as u16
}

技术亮点：

字节级光标位置（正确处理 UTF-8 多字节字符）
CJK 字符显示宽度计算
历史记录草稿备份
与 ratatui 的 Widget trait 集成

2. 自研欢迎页 (welcome.rs)

极简设计，无 ASCII art，启动时自动显示：

pub struct WelcomeWidget {
    title: String,
    subtitle: String,
}

impl WelcomeWidget {
    pub fn render(&self) -> Vec<Line<'static>> {
        vec![
            Line::from(""),
            Line::from(vec![
                Span::default(), /* ... 21 个 default spans 用于居中 ... */
                Span::styled(
                    "Welcome to IfAI",
                    Style::default()
                        .fg(Color::Cyan)
                        .add_modifier(Modifier::BOLD),
                ),
            ]),
            // 快捷键提示...
        ]
    }
}

实现细节：

空状态检测：app.is_empty() → 显示欢迎页
静态字符串满足 'static 生命周期
居中对齐算法（21 个 Span::default() 硬编码）

3. 自研快捷键帮助系统 (keybindings.rs)

声明式快捷键定义，分类展示：

pub struct KeybindingCategory {
    pub name: &'static str,
    pub bindings: Vec<KeyBinding>,
}

pub fn get_all_categories() -> Vec<KeybindingCategory> {
    vec![
        KeybindingCategory::new(
            "📝 输入操作",
            vec![
                KeyBinding { keys: "Enter", description: "提交输入" },
                KeyBinding { keys: "Ctrl+C", description: "清空输入 / 中断" },
            ],
        ),
        // ...
    ]
}

按 ? 键唤起帮助覆盖层，左对齐 + 缩进布局，比 Codex 的复杂边框更易读。

4. 实时搜索高亮算法

支持大小写不敏感匹配、循环导航、三种高亮样式：

fn highlight_search_term(
    line: &str,
    query: &str,
    is_current: bool,
    is_other: bool
) -> Line<'static> {
    let mut spans = Vec::new();
    let mut last_pos = 0;

    while let Some(pos) = line[last_pos..].to_lowercase()
        .find(&query.to_lowercase()) {

        let style = if is_current {
            Style::default().fg(Color::Black).bg(Color::Yellow)
        } else if is_other {
            Style::default().fg(Color::Black).bg(Color::White)
        } else {
            Style::default().fg(Color::Yellow)
        };

        spans.push(Span::styled(&line[pos..pos + query.len()], style));
        last_pos = pos + query.len();
    }

    Line::from(spans)
}

技术要点：

零配置：Ctrl+F 进入搜索模式
实时反馈：输入即显示
循环导航：↑/Enter / ↓/Shift+Enter
状态持久化：搜索结果在匹配项间切换

18000 行代码的工程奇迹

代码结构

src-tauri/src/bin/ifai/
├── main.rs                 (1065 行) — 入口 + 事件循环
├── tui.rs                  (896 行)  — TUI 核心
├── session.rs              (1788 行) — 会话管理
├── render.rs               (1148 行) — 渲染引擎
├── input_composer.rs       (661 行)  — 输入框
├── approval_overlay.rs     (777 行)  — 审批面板
├── permission_store.rs     (1078 行) — 权限存储
├── commands.rs             (1308 行) — 命令处理
├── event/
│   └── handlers.rs         (480 行)  — 事件处理器
├── token/
│   └── stream_status.rs    (795 行)  — Token 追踪
└── ... (20+ 其他模块)

总计：18013 行纯手工打造的 Rust 代码

测试覆盖

$ cargo test -p ifainew
test result: ok. 404 passed; 0 failed; 9 ignored

404 个单元测试，100% 通过率，涵盖：

UTF-8 字符边界处理
CJK 宽度计算
事件处理器责任链
搜索高亮算法
权限规则匹配

技术亮点

1. 责任链模式事件系统

每个事件处理器都是独立的 struct，实现了 EventHandler trait：

pub trait EventHandler<E> {
    fn handle(&mut self, event: &E, app: &mut App) -> ControlFlow;
}

pub enum ControlFlow {
    Continue,  // 继续传递给下一个处理器
    Break(AppResult),  // 停止处理并返回结果
}

优势：

单一职责：每个处理器只做一件事
可测试性：独立 struct，单元测试简单
可扩展性：添加新功能只需新增处理器

2. 零拷贝渲染

使用 Line<'static> 避免字符串分配：

pub fn render(&self) -> Vec<Line<'static>> {
    vec![
        Line::from("Welcome to IfAI"),  // &'static str
        Line::from(vec![
            Span::styled("快捷键：", Style::default().fg(Color::Yellow)),
        ]),
    ]
}

3. 多模态智能切换

自动检测图片内容并切换到视觉模型：

pub fn select_model_with_multimodal_support(
    request: &StreamRequest
) -> String {
    let has_multimodal = request.messages.iter()
        .any(|msg| matches!(msg.content, MessageContent::Image { .. }));

    if has_multimodal {
        if !model.contains("4v") && !model.contains("5v") {
            return "glm-4.5v".to_string();
        }
    }

    request.model.clone()
}

4. Claude Code 风格审批系统

底部弹出面板 + 数字选项选择 + 持久化白名单：

pub enum ApprovalDecision {
    ApproveOnce,         // 本次允许
    ApproveAlways,       // 持久化白名单（Bash 工具）
    ApproveSession,      // 会话级允许（文件编辑）
    Deny,                // 拒绝
    Abort,               // 中止请求
}

持久化到 ~/.ifai/permissions.toml：

[[allow]]
tool = "bash"
pattern = "git diff:*"

[[deny]]
tool = "bash"
pattern = "rm -rf /*"

通宵重构的经验总结

如果你也想挑战一夜重构，这几点经验或许有用：

✅ DO - 应该做的

写测试先行 - 元编程的 bug 往往更难调试
保持责任链简洁 - 每个处理器只做一件事
善用 IDE - Rust-Analyzer 对宏支持很好
记录设计决策 - 为第二天重构的自己留文档

❌ DON'T - 避免做的

不要过度抽象 - 表驱动不是万能药
不要忽视性能 - 元数据加载也有开销
不要忘记 Windows - 条件编译要测试
不要牺牲可读性 - 代码是写给人看的

性能数据

指标	v0.4.3	v0.4.4	改善
二进制大小	3.2 MB	3.1 MB	-3%
编译时间	45s	38s	-16%
内存占用	12 MB	10 MB	-17%
启动时间	80ms	65ms	-19%

为什么 Rust + 元编程是未来？

1. 编译时计算替代运行时开销

Rust 的宏系统 + 零成本抽象，让元编程不像反射那样拖累性能。

2. 类型安全的动态配置

表驱动设计在动态语言中很常见，但 Rust 带来了类型安全 + 内存安全的双重保障。

3. 符合 AI 时代的开发范式

当你在写 AI 代码生成工具时，元编程思维是必备技能。因为：

🤖 AI 本质上是 "元"（Meta）的 - 代码生成代码
📊 表驱动是 AI 配置的基础
🔄 可扩展性决定了 AI 工具的上限

结语

凌晨 5 点，当最后一杯咖啡喝完，我看到测试通过的绿色输出：

test result: ok. 404 passed; 0 failed; 9 ignored

这种满足感，是任何技术热点都给不了的。

因为我知道：这不仅是一个工具，更是对未来开发范式的一次探索。

IfAI CLI v0.4.4 是一次通宵重构的成果，更是对"如何构建优雅的 AI 工具"的一次回答。

完全自研的 TUI 架构，不是炫技，而是对用户体验的极致追求。

试用 & 参与

如果你对 IfAI CLI 感兴趣，欢迎：

⭐ GitHub：github.com/peterfei/ifai
brew 下载：brew install ifai
🐛 提 Issue 或者回复：任何问题都有反馈
💬 加微信群：和更多技术爱好者交流

如果你也想打造自己的 AI CLI，或者对元编程架构有疑问，欢迎在评论区讨论！

作者：peterfei

全栈工程师 / AI 架构师 / Rust 爱好者 / 通宵战士/ IFAI 作者

#AI 工具 #Rust 编程 #TUI 开发 #元编程 #通宵重构 #CLI 工具

一个 Tauri + Rust AI 编辑器是怎么同时适配 5 家 AI 大厂的？IfAI v0.4.3 架构拆解

peterfei — Fri, 24 Apr 2026 17:52:27 +0800

一份 YAML 文件搞定一家 AI 提供商。IfAI Editor v0.4.3 用元数据驱动架构同时接入 OpenAI、DeepSeek、智谱、Kimi、Gemini 五家大模型厂商共 53 个模型，一行配置即可扩展新 Provider。本文拆解其架构设计、多模态统一抽象、SSE 流解析关键 Bug 修复，以及国际化工程化实践。

五家 AI 大厂，一个编辑器

2026 年的大模型战场，没有一家通吃。

厂商	代表模型	优势场景
OpenAI	GPT-5.4, O1, O3	最强推理、视觉理解、工具调用
DeepSeek	DeepSeek V3.2	极致性价比，$0.028/千 Token
智谱 AI	GLM-5.1, GLM-4.5V	中文优化、视觉模型、Flash 高速推理
Kimi（月之暗面）	K2.6, K2.5	Thinking 思维链、256K 超长上下文、多模态
Google Gemini	Gemini 3.1, 2.5 Pro	百万级上下文、原生多模态、免费 API

这五家提供商，协议各不相同：OpenAI 一套、Gemini 一套、DeepSeek 和 Kimi 虽然走 OpenAI 兼容格式但字段有差异。

做一个 AI 编辑器，最痛苦的事不是写前端 UI、不是做工具调用审批——是每接入一个新的 AI 提供商，就要手写 500 行适配代码。模型列表硬编码、请求格式手动转换、SSE 解析各写各的。

IfAI Editor v0.4.3 的核心目标只有一个：消灭这种重复。

元数据驱动：用 YAML 替代 500 行 Rust 代码

我们的方案是元数据驱动的 Provider 架构。每个 AI 提供商不再需要手写 Rust 客户端，而是用一个 YAML 文件描述全部信息：

metadata:
  id: kimi-official
  name: Kimi 官方
  provider_type: ai

api_spec:
  base_url: https://api.moonshot.cn/v1
  endpoint: /chat/completions
  auth:
    type: bearer_header
    header_name: Authorization
    format: "Bearer {key}"

models:
  - id: kimi-k2.6
    name: Kimi K2.6
    context_tokens: 256000
    capabilities: [tools, streaming, vision, thinking, json_output]

后端通过 Rust 的 generate_provider_client! 宏，在编译期自动生成客户端代码。前端读取同一份 YAML 配置，自动渲染 Provider 选择界面和模型列表。

效果：

指标	重构前	重构后
单个 Provider 代码量	~500 行	~150 行
接入新 Provider 耗时	数天	数分钟
重复代码率	~95%	~0%

多模态：一张图、一个 PDF、一段代码，怎么统一？

多模态输入是 2025 年 AI 编辑器的标配。但不同提供商的多模态传输格式完全不同：

OpenAI：content: [{type: "image_url", image_url: {url: "base64..."}}]
Gemini：inline_data: {mime_type: "image/png", data: "base64..."}
Kimi/DeepSeek：走 OpenAI 兼容格式，但支持的字段有差异

IfAI v0.4.3 的做法是统一内容抽象——所有输入被归一化为 MultimodalContent 格式：

// 统一的多模态内容表示
interface MultimodalContent {
  type: 'text' | 'image' | 'pdf' | 'code';
  content: string;
  metadata?: {
    filename?: string;
    language?: string;
    mimeType?: string;
    size?: number;
  };
}

// 发送时，FormatAdapter 自动转换为各提供商格式
const message = [
  { type: 'text', content: '分析这张架构图' },
  { type: 'image', content: 'data:image/png;base64,...' },
  { type: 'code', content: 'fn main() { ... }',
    metadata: { filename: 'main.rs', language: 'rust' } }
];

前端还实现了智能粘贴检测——用户粘贴截图、拖拽文件时，自动识别内容类型并转换为多模态格式。图片超过 5MB 自动压缩，相同图片 Base64 只编码一次（缓存命中省 40% 内存）。

那个让所有 Provider 都罢工的 SSE Bug

这是 v0.4.3 修复的最关键 Bug，影响所有 OpenAI 兼容提供商。

问题出在 SSE 流解析的 finish_reason 判断：

// Bug：finish_reason: null 也被判定为 finish 事件
let is_finish_event = json.get("finish_reason").is_some();
// 结果：所有内容事件被跳过，用户收到空响应

JSON 中 finish_reason: null 意味着"流还没结束"，但 Rust 的 json.get("finish_reason").is_some() 对 null 值也返回 true——于是每个 content chunk 都被错误识别为结束事件。

修复：

// 正确：null 不会通过 as_str()
let is_finish_event = json.get("finish_reason")
    .and_then(|v| v.as_str())
    .is_some();

一行修复，解决 Kimi、DeepSeek、智谱、OpenAI 以及所有使用 OpenAIFormatAdapter 的提供商的流式响应问题。

Kimi K2 的 Thinking 模式：双重内容流

Kimi K2 系列有个独特功能——SSE 流中同时返回思考过程和最终响应：

{
  "choices": [{
    "delta": {
      "reasoning_content": "让我分析一下用户的需求...",
      "content": "根据您的需求，建议如下..."
    },
    "finish_reason": null
  }]
}

IfAI v0.4.3 自动识别 reasoning_content 字段，将思考过程和正式响应分流显示。用户可以查看模型的"思维链"，同时获得干净的回答。

53 个模型，各有所长

v0.4.3 共接入 5 家提供商、53 个模型，覆盖从轻量到旗舰的全系列：

OpenAI（15 个模型）：从 GPT-3.5 Turbo 到 GPT-5.4，覆盖 O1/O3 推理系列。GPT-5.4 和 O3 支持最长 200K 上下文，适合复杂代码审查和长文档分析。

DeepSeek（1 个模型）：DeepSeek Chat V3.2，128K 上下文，支持工具调用和函数调用。关键是价格——缓存命中仅需 $0.028/千 Token，是日常编码助手的最佳选择。

智谱 AI（11 个模型）：GLM-5.1 为最新旗舰，GLM-4.5V 提供视觉理解能力，GLM-4.7 Flash 提供高速推理。中文场景表现突出，GLM-3 Turbo 提供 32K 上下文的轻量选择。

Kimi（12 个模型）：K2.6 为最新旗舰，支持 Thinking 模式和 256K 超长上下文。K2 Thinking 系列专门用于复杂推理，V1 系列提供 8K/32K/128K 三种上下文选择，还有 Vision Preview 版本支持图片理解。

Gemini（15 个模型）：从 1.5 到 3.1 三代产品。Gemini 1.5 Pro 拥有 2.8M 超长上下文（行业最长），3.1 系列支持图像生成预览。全部模型支持 1M 以上上下文，适合处理大型代码库和长文档。

国际化工程化：2749 个键，三种语言，怎么保证一致性？

v0.4.3 新增俄语支持，现在覆盖中/英/俄三种语言，共 2749 个翻译键。

真正的难点不是翻译本身，而是一致性保障。2749 个键分布在 3 个 JSON 文件中，手动对齐几乎不可能出错。

我们用工程化手段解决：

自动化校验脚本：check-i18n-parity.mjs 在每次 commit 时自动比对三个语言文件的键集合，发现不一致直接阻止提交（退出码 1）
硬编码扫描：scan-hardcoded-strings.mjs 扫描源码中未走 i18n 的中文硬编码
Pre-commit Hook：husky + lint-staged，修改 locales/*.json 时自动触发校验
CI 门禁：GitHub Actions 中 TypeScript 类型检查 + i18n 一致性校验 + 单元测试三道关卡

数据总览

v0.4.3 版本的工程数据：

指标	数据
AI 提供商	5 家（OpenAI、DeepSeek、智谱、Kimi、Gemini）
模型总数	53 个
最长上下文	2.8M (Gemini 1.5 Pro)
最短上下文	8K (GLM-3 Turbo, Moonshot V1 8K)
支持视觉	4 家（OpenAI、智谱、Kimi、Gemini）
支持工具调用	5 家（全部）
支持 Thinking	2 家（OpenAI O1/O3、Kimi K2）
协议	OpenAI Standard（4 家）+ Gemini Custom（1 家）
i18n	2,749 键，中/英/俄 100% 对齐
测试	1155 单元测试通过，417 E2E 测试零失败
代码变更	+5,500 / -2,000 行

写在最后

AI 编辑器的竞争，正在从"能不能用"转向"好不好接"。

元数据驱动架构的核心思想其实很简单：把变化的部分从代码中抽离出来，变成数据。Provider 会越来越多，模型会越来越快，协议会不断演进——但只要描述这些变化的元数据格式稳定，代码就不用改。

这是 v0.4.3 最重要的架构决策：让配置做配置的事，让代码做代码的事。

*IfAI Editor 是基于 Tauri 2.0 + Rust 构建的跨平台 AI 代码编辑器，开源地址见 GitHub。 *

开源地址:Ifai

Spinel -- Ruby AOT 编译器

Rei — Fri, 24 Apr 2026 17:12:44 +0800

https://github.com/matz/spinel

Spinel 将 Ruby 源代码编译成独立的本地可执行文件。它执行全程序类型推断并生成优化的 C 代码，与 CRuby 相比速度显著提升。

show history for selection lines in Zed

qinsicheng — Thu, 23 Apr 2026 22:20:47 +0800

相信使用过 JetBrains 产品的用户，对内置的 Git 操作都会觉得很方便。其中很重要的一个功能：选中某几行代码，鼠标右键，使用 show history for selection。就能展示出这几行代码的 git 提交历史记录，这个功能真的太香了。

这个功能在很多编辑器上都不支持，我目前在使用 Zed 编辑器，最开始对 Git 操作支持很少，我都是使用 lazygit 来操作，但上面提到的功能无法实现。所以我就尝试编写脚本去实现这个功能。本质上就是使用 git 原生命令行操作：git log -L <range:file> 。将内容输出到一个临时文件中，然后通过 zed 编辑器打开它，同时使用 diff 语法展示高亮信息。

效果展示：

Fish 代码

function git_line_history --description "Show git history for specific lines in a file"
    # Validate argument count
    if test (count $argv) -ne 3
        echo "Usage: git_line_history <file_path> <start_line> <end_line>"
        return 1
    end

    set -l file_path $argv[1]
    set -l start_line $argv[2]
    set -l end_line $argv[3]

    # Verify the file exists
    if not test -f "$file_path"
        echo "Error: file '$file_path' does not exist"
        return 1
    end

    # Verify we are inside a git repository
    if not git rev-parse --is-inside-work-tree >/dev/null 2>&1
        echo "Error: current directory is not inside a git repository"
        return 1
    end

    # Create temporary files
    set -l temp_file (mktemp -t git_history.XXXXXXXXXX.diff)
    set -l raw_log_file (mktemp -t git_history.XXXXXXXXXX.raw)

    # Build the line range argument for git log -L
    set -l line_range "$start_line,$end_line:$file_path"

    # Fetch the line history
    git log --date=format:'%Y-%m-%d %H:%M:%S' -L $line_range >$raw_log_file 2>&1

    if test $status -ne 0
        echo "Error: failed to execute git log"
        if test -s $raw_log_file
            echo "Details:"
            cat $raw_log_file
        end
        rm -f $raw_log_file $temp_file
        return 1
    end

    # Process output: filter diff metadata and add separators between commits
    awk '
    BEGIN { in_commit = 0; has_content = 0; }
    /^commit / {
        if (in_commit && has_content) print "\n--------------------------------------------------\n"
        in_commit = 1
        has_content = 1
        print
        next
    }
    /^diff --git|^index |^--- a\/|^\+\+\+ b\/|^@@ .* @@/ { next }
    {
        if (in_commit) print
        has_content = 1
    }
    ' $raw_log_file >$temp_file

    rm -f $raw_log_file

    # Check if the result is empty
    if not test -s $temp_file
        echo "Note: no matching commit history found"
        rm -f $temp_file
        return 0
    end

    # Choose an editor: prefer zeditor (Arch Linux), fall back to subl, then $EDITOR
    set -l editor_cmd
    if command -q zeditor
        set editor_cmd zeditor
    else if command -q zed
        set editor_cmd zed
    else if command -q subl
        set editor_cmd subl
    else if set -q EDITOR
        set editor_cmd $EDITOR
    else
        echo "Error: no suitable editor found"
        echo "Temporary file location: $temp_file"
        return 1
    end

    $editor_cmd "$temp_file"

    # Clean up old temporary files from previous runs
    function cleanup_git_history --on-event fish_exit
        # Clean up old temporary files from previous runs
        set -l tmpdir (dirname (mktemp -u))
        rm -f $tmpdir/git_history.*.diff 2>/dev/null
        rm -f $tmpdir/git_history.*.raw 2>/dev/null
    end

    return 0
end

function zed_git_line_history --description "Zed editor wrapper for git_line_history"
    # Extract line range from Zed environment variables
    set -l start_line $ZED_ROW
    set -l selection "$ZED_SELECTED_TEXT"
    set -l line_count (printf '%s\n' "$selection" | wc -l | string trim)
    set -l end_line (math $start_line + $line_count - 1)
    set -l file_path "$ZED_FILE"

    git_line_history "$file_path" $start_line $end_line
end

Zed 配置

task

{
   "label": "git_line_history",
   "command": "zed_git_line_history",
   "env": {
     "ZED_ROW": "$ZED_ROW",
     "ZED_SELECTED_TEXT": "$ZED_SELECTED_TEXT",
     "ZED_FILE": "$ZED_FILE"
   },
   "hide": "always",
   "allow_concurrent_runs": true,
   "use_new_terminal": true
 },

keymap

{
  "context": "vim_mode == normal || vim_mode == visual",
  "bindings": {
      "g h": ["task::Spawn", { "task_name": "git_line_history" }],
   }
}

试图交了个提升 Ruby Hash 性能的补丁

dsh0416 — Thu, 23 Apr 2026 13:15:53 +0800

动机

昨天在参加 RubyKaigi 的时候顺便瞄到了 st.c 的实现，然后让我回想起来，现在的 Ruby 的 Hash 实现主要来自于 Vladimir Makarov 在 2016 年实现的精心调优的 open-addressing 实现的版本。我突然想起 Google absl 实现里有个 Swiss Tables 实现吊打了 C++ 标准库的实现，而 Rust 的标准库实现基于的 hashbrown 也是基于相同的原理。我就在思考时隔十年我们能不能把 SwissTables 相关的算法移植到 Ruby 上进一步提升 Ruby 处理 Hash 类型的性能，要知道 Hash 类型是 Ruby 中调用极其频繁的类型，它替代了很多其它语言中 struct 的功能，因此性能提升能带来很直观的收益。

尝试

直接的移植后发现性能不升反降了，这和 Ruby 中 Hash 的用法很有关系。Ruby 中非常多的 Hash 对象非常小，而 Makarov 2016 年的实现对此做了非常细腻的优化。

于是我的做法转变成了，保留 Ruby 中原先对不同大小 Hash 的分层存储，从 Swiss Tables 对 control bit 更好的对超标量 / 向量化的支持和 H2 短哈希更好的缓存命中这两个角度进一步进行优化，只针对大的 Hash 对象（容量 >= 64）的情况进行处理。

设计

1. 三数组布局

array	width	role
`entries[]`	16B (以前为 24B)	以插入顺序记录 `(key, record)` 的日志
`hashes[]`	每 slot 4B	与之并行的截断 32 位哈希数组（也编码删除标记）
`bins[]`	自适应 1 / 2 / 4 / 8B	基于哈希的索引数组，存放指向 `entries[]` 的索引
`ctrl[]`	每 slot 1B	`H2`（哈希的高 7 位）或 `EMPTY (0xff)` / `DELETED (0xfe)`

entries[] 和 hashes[] 长度相同并由相同索引寻址，因此迭代和 slot 重用保持简单。ctrl[] 是快速拒绝过滤器，和 bins[] 并列；只有当某个 ctrl 字节与 H2 匹配时，我们才会加载（现在更小的）entry 和并行哈希以确认匹配。对 ctrl[] 在 uint64_t 读取上完成，这本质上是一种 SWAR 优化。

2. 紧凑的 `st_table_entry`

修改前：

struct st_table_entry {
    st_hash_t  hash;    /* 8 B */
    st_data_t  key;     /* 8 B */
    st_data_t  record;  /* 8 B */
};                       /* 24 B */

修改后：

struct st_table_entry {
    st_data_t  key;     /* 8 B */
    st_data_t  record;  /* 8 B */
};                       /* 16 B */

哈希移入 tab->hashes[i]，由于大多数情况可以依赖 H2 进行匹配。因此这样我们可以进一步提升 cacheline 的命中效率，从而提高 CPU L1 的命中率。

3. 新的哈希函数

仅存储低 32 位哈希意味着我们不能再从原始 unsigned long 哈希的高位 7 位读取 H2，而这是 SwissTables 原先设计所采用的做法。naive 的实现是在每次重建/重哈希/st_shift/st_general_foreach 中重新计算完整 64 位哈希以保证正确性，但会严重损害插入和重建性能 —— 尤其是对于类似 string 这样的变长类型的性能损害很大。

解决方法是从截断的 32 位哈希的一个不同位段推导 H2，该位段与用于选取 bin 的位段不重叠：

/* bin index: low `bin_power` bits, masked by `bins_mask(tab)`     */
hash_bin(uint32_t h, st_table *tab) { return h & bins_mask(tab); }

/* H2: bits 25..31 of the same 32-bit hash, never overlaps with     */
/* the bin index because bin_power is capped well under 25 in       */
/* practice.                                                        */
static inline unsigned char
st_swiss_h2(st_hash_t hash) {
    return (unsigned char)((hash >> 25) & 0x7f);
}

这使得存储的 uint32_t 是自包含的：每次探测都能从同一字中读取 bin 索引和 H2 字节，无需调用 do_hash()，重建/重哈希/移位/foreach 全部使用 ST_HASH_AT_IDX(tab, i) 而不是重新计算。

截断带来的另外两个细节：

normalize_hash_value() 已更新，以确保 0xFFFFFFFF（32 位哈希 slot 的墓碑标记）永远不会与真实哈希值冲突——如果截断结果落在该保留值上我们会进行跳变（bump）。在未启用 ST_USE_SWISS_BINS 编译的平台上保留 64 位的保留值。
MARK_ENTRY_DELETED / DELETED_ENTRY_P 宏新增了 table 参数，以便读取/写入并行的哈希 slot。

4. 在 H2 匹配时进行 prefetch

当 SWAR 在控制组中找到候选的 H2 匹配时，下一步是加载匹配的 st_table_entry 的哈希。我们在 find_table_entry_ind / find_table_bin_ind / find_table_bin_ptr_and_reserve 中在检测到匹配后立即对两者发出 __builtin_prefetch。在以查找为主的工作负载上，这能掩盖 SWAR 快速过滤器本会暴露的 CPU L2 缓存延迟。

与 `master` 的结果比较

两个二进制均来自相同代码树（master = 42b3cdc51a，swiss = 3c0446847f），相同编译器，相同编译选项。每个脚本运行 5 次，使用 --disable-gems，报告最佳结果。内存为 macOS arm64（M4 Max）上 /usr/bin/time -l 的最大常驻集大小（maximum resident set size）。

吞吐量（时间越低越好）

benchmark	master (s)	swiss (s)	speedup
aref_int_large	0.8352	0.6862	+17.8 %
aref_str_large	0.9915	0.8406	+15.2 %
aref_miss_large	1.0803	0.7896	+26.9 %
aref_mix_50	1.0337	0.8201	+20.7 %
insert_grow	0.1138	0.1105	+2.9 %
churn (mixed RW)	0.0321	0.0304	+5.5 %
iterate	0.0566	0.0565	±0.1 %

查找是主要的收益点——成功查找（+15 % … +20 %）和未命中（+27 %）均有提升，后者的原因是缺失的 key 现在能在第一个 SWAR 组立即短路，无需加载 entry/bin。插入和混合负载略有提速，因为重建不再调用 do_hash。迭代不受影响（它不需要访问 bins 或 ctrl）。

内存

benchmark	master (MB)	swiss (MB)	delta
insert_grow	66.62	60.44	−9.3 %
aref_str_large	15.27	15.23	−0.3 %
aref_mix_50	16.64	16.61	−0.2 %
churn	13.19	13.03	−1.2 %

每表内存（通过 ObjectSpace.memsize_of，在多个哈希上求和）：

workload	master	swiss	delta
2 000 hashes × 200 entries	14.66 MB	12.11 MB	−17.4 %
1 hash × 100 000 entries	4.19 MB	3.28 MB	−21.9 %

2000 hashes × 200 entries 模拟了常见的 Rails 负载，这可以节省 ~17.4% 的 Hash 内存占用。

这两种内存视图一致：任何保留大量存活条目的工作负载（无论是一个大哈希还是许多小哈希）都会因条目从 24B → 16B 的变化以及每槽 1B 的 ctrl[] / 4B 的 hashes[] 配对而显著减少内存，因为它们合计（每槽 5B）仍小于在 entries[] 中每槽节省的 8 B。表的每表开销在小于约 64 条目时大致保持不变；Swiss 路径仅在 entry_power ≥ 6（表容量 ≥ 64）时启用。

详见

https://bugs.ruby-lang.org/issues/22011

西安垚海有大佬在里面吗？求问怎么样

qinsicheng — Mon, 20 Apr 2026 21:37:54 +0800

想了解里面公司内文化，氛围。以及是否靠谱

有没有招聘 rails/nodejs 兼职

puma — Mon, 20 Apr 2026 18:15:40 +0800

有招聘 rails/nodejs 兼职的欢迎联系我

有正式工作，也是从事这方面的，想在晚上和周末做点兼职

有八年左右这方面工作经验的老登，技术还算熟练

开发了一个自动化运维平台，现在内测中，免费，有命令行自动化需求的欢迎试用

zhb85 — Thu, 16 Apr 2026 20:56:43 +0800

可以一站式帮你用自然语言开发命令行自动化脚本地址 https://qingxun.online

试用可以找我加信用点

用 railway 这个服务器部署 ruby on rails, 发现很不错，但是有点贵，大家看看可以参考

shibin — Thu, 16 Apr 2026 19:31:53 +0800

我最近帮客户做网站，我把网站放到了 railway.com 上面，用 railway 的服务器和数据库，用 Google 存储，存储图片，

里面有 330 个产品信息。分别是 330 个产品图片、中英产品介绍。

但是用了 13 天，railway 的 5 美金就花完了，又充值了 5 美金...

感觉对这客户有点贵，官网展示网站，服务器费用一个月得超过 10 美金...

procodile, 一款类似 foreman 的工具，但可运行在前台或后台，也支持定时任务

zw963 — Wed, 15 Apr 2026 15:33:12 +0800

宣布发布 `procodile` 2.0.0-rc1

我很高兴地宣布 procodile 2.0.0-rc1 正式发布。自上一个版本以来，这是一次重大更新，累计包含了 130 多个 commit。

这次更新之所以非常重要，主要有以下几个原因：

这是第一个完整实现原始 Ruby 版本功能的 procodile 发布版本。
它还修复了原始 Ruby 版本中存在的许多 bug 和边界情况问题。(感谢 Crystal 程序语言，让暴露和修复这些问题，相对于 Ruby 简单得多）

与此同时，2.0 版本在原始 Ruby 版本的基础上也有了显著增强，并引入了一些此前 Ruby 版本并不具备的新功能：

支持通过 .env 文件加载环境变量，这项功能基于 @jwoertink 开发的 lucky_env。
支持定时任务。这是一次重要更新，使你可以在同一个地方同时管理长期运行的进程和定时任务。得益于 @kostya 开发的 cron_parser，它不仅支持标准的五段式 crontab 表达式，还支持精确到秒级的 cron 调度。
引入了 Runtime Issues。当命令执行结束后如果检测到问题，你会立即在命令行中收到反馈。

请参阅 Wiki，其中提供了结构清晰且内容详尽的文档说明。

南京全职，预招聘，Ruby on Rails 全栈开发工程师一名（discourse 插件方向）

chengr25 — Tue, 14 Apr 2026 16:34:42 +0800

招 Rails 全栈开发

岗位职责

开发 Discourse 插件（Ruby on Rails + Ember.js）
维护现有插件代码，排查线上问题
只招一人，学习能力强的可作为技术总监（涨工资 + 期权）

任职要求

必须

2 年以上 Rails 开发经验，熟悉 ActiveRecord、Sidekiq（若 Rails 经验少，学习能力很强亦可）
有前端框架经验（Vue/React/Ember 最好）
能阅读英文技术文档
熟练使用 AI 工具（Claude/Cursor 等）辅助开发

加分

有 Discourse 或其他论坛系统开发经验
PostgreSQL 性能优化经验
开源项目贡献

薪资福利

月薪 18-20K，13 薪
五险一金
工作时间 9:00-11:30，13:30-17:30，不加班（以后趋势都让 AI 干活）

备注

南京地区几年没有 Ruby 岗位帖子，所以提前发布，预计 5 月开始招
后期面试有 10-20 道 AI 出的选择题，判断能力范围（毕竟我也不懂代码，不会手写算法题）
介意勿扰

联系方式请发送简历至：724969715@qq.com 标题格式：【Rails 开发】姓名 - 工作年限

用 kamal 部署 rails 至阿里云主机总结

flchenhp — Mon, 13 Apr 2026 01:25:32 +0800

需求背景

rails 开发速度很快，体验很好，但是如果无法部署到服务器上，最后也就是自己在本机玩玩，开发的网页服务不能给别人使用。我在 deepseek 的帮助下经过一周的摸索终于实现了部署，特记录供自己后期查阅，也供其他人借鉴。真的感谢好时代，有 deepseek 不然想也不敢去想我一个个人业余开发者，身边没一个同语言开发指导老师怎么敢去想自行摸索完成部署功能。

让 deepseek 总结 kamal 一次完整部署的生命周期

下面是 Kamal 从初始化到部署完成的完整工作流程，每一步都对应具体的操作：

阶段 0：准备工作（只需一次）

初始化配置：运行 kamal init，生成 config/deploy.yml 配置文件
配置服务器列表：在 deploy.yml 中指定服务器的 IP 地址或域名
配置容器注册表：设置注册表的用户名和密码（通过环境变量加密存储）
设置 SSH 密钥：确保本地可以免密登录服务器
编写 Dockerfile：Rails 7+ 会自动生成，确保镜像构建正确

阶段 1：初始部署（`kamal setup`）

这个命令会完成服务器的首次配置：

SSH 连接并安装 Docker：连接到配置文件中的服务器，如果 Docker 未安装，自动通过 apt-get 安装
登录容器注册表：在本地和远程服务器上都登录，以便推送和拉取镜像
构建 Docker 镜像：使用项目根目录的 Dockerfile 构建镜像
推送镜像到注册表：将构建好的镜像推送到配置的容器注册表
在服务器上拉取镜像：通过 SSH 命令让服务器从注册表拉取镜像
启动 Kamal Proxy：确保代理服务正在运行，并监听 80/443 端口
启动应用容器：基于拉取的镜像启动新的 Docker 容器
健康检查：验证应用是否响应 GET /up 请求（必须返回 200 OK）
清理旧资源：删除未使用的镜像和停止的容器，防止磁盘占满

阶段 2：后续部署（`kamal deploy`）

这是日常更新应用的命令，只执行部署流程，不重复安装 Docker：

构建新镜像：基于最新的代码构建新版本镜像
推送到注册表：新镜像被推送到注册表，标签通常是 Git commit hash
SSH 连接服务器并拉取新镜像：服务器从注册表拉取新版本镜像
启动新容器（旧容器仍在运行）：在旧容器旁边启动新容器，确保服务不中断
健康检查：等待新容器通过健康检查（GET /up）
Kamal Proxy 切换流量：代理原子性地将流量从旧容器切换到新容器
停止旧容器：新容器稳定运行后，停止并删除旧容器
清理资源：删除旧镜像和未使用的容器，释放磁盘空间

我理解 kamal 的功能（没怎么接触过 docker）

我理解 kamal 大致功能是先将本机的开发环境和项目通过 docker 打包成镜像，push 到镜像仓库，然后登陆服务器先下载 docker，然后从镜像仓库 pull 这个镜像再还原运行。之前尝试过在本机和服务机均安装网络代理工具，这一步实现了，但是直接参考 rails guide 部署还是会存在问题，没搞明白。只能尝试将所有可能会用到科学上网的源替换成国内的源。

部署记录

step1：准备 hello world 项目

新建 rails 项目

ruby -v
rails -v
rails new rails106

用编辑器（我用的是 trae）打开项目，做初始化保存

#iterm
git add .
git commit -m "initial commit"

将 gem 源改成 rubychina 的源

# gemfile
-source "https://rubygems.org"
+source "https://gems.ruby-china.com"

添加 hello world 页面

#iterm
rails g controller welcome index

# app/views/welcome/index.html.erb
+<h1>hello world</h1>
-<h1>Welcome#index</h1>
-<p>Find me in app/views/welcome/index.html.erb</p>

# config/routes.rb
  root "welcome#index"
  get "welcome/index"

启动项目，查看 hello word 页面

# iterm
bin/dev

将代码加入 git 保存

# iterm
git add .
git commit -m "add hello world page"

step2:选择云主机

阿里云主机可以直接添加 docker，免去安装 docker 的麻烦。直接用 root 账号和设定的自定义密码，这个会用于远程服务器。

远程主机验证 docker 安装成功：

# 云主机命令行
docker --version
docker run hello-world

step3:申请阿里云容器镜像服务（ACR）

进入控制台：登录后搜索“容器镜像服务”，或直接访问容器镜像服务控制台。
按提示创建个人版实例（下面的信息都很重要，部署的配置文件要用）
按提升建立命名空间
按提示设置密码，获取登录命令
获取个人加速器地址

step4:在本机下载 docker

访问 Docker Desktop for Mac 下载页面选择适宜自己电脑版本下载安装
点击 Mac 顶部菜单栏的 Docker 图标，选择 Settings。在左侧菜单选择 Docker Engine，将阿里云和一些其他的加速器地址填上 { "builder": { "gc": { "defaultKeepStorage": "20GB", "enabled": true } }, "experimental": false, "registry-mirrors": [ "https://5ex1e6il.mirror.aliyuncs.com", "https://docker.1panel.live", "https://hub.rat.dev", "https://docker.m.daocloud.io", "https://docker.nju.edu.cn", "https://docker.xuanyuan.me", "https://docker.1ms.run" ] }
打开“终端”应用，运行docker --version 和docker run hello-world 进行验证 docker 是否正确安装

step5:进行部署配置

#rails106/config/deploy.yml
-image: rails106
+image: myrailsapp/rails106 # myrailsapp是阿里云的镜像仓库命名空间

-    - 192.168.0.1
+    - 47.x x.xx.236 # 这是阿里云的IP地址

-  server: localhost:5555
+  # 这里填阿里云的镜像仓库的公网地址
+  server: crpi-xxxxxxxxxxx.cn-zhangjiakou.personal.cr.aliyuncs.com 

-  # username: your-user
+  # 这里填阿里云的账号
+  username: chenxxxxxx21

-  # password:
+   # 这里填阿里云的镜像的固定秘密
+  password: cxxxxxx9

代码类似

# rails106/Dockerfile
-# syntax=docker/dockerfile:1
+# #syntax=docker/dockerfile:1 # 第一行这里要再加个注释符号注释，不然会报错，不知道为什么

-FROM docker.io/library/ruby:$RUBY_VERSION-slim AS base
+# FROM docker.io/library/ruby:$RUBY_VERSION-slim AS base
+# 要换成ruby的国内的源，不然会卡住
+FROM docker.m.daocloud.io/library/ruby:$RUBY_VERSION-slim AS base

WORKDIR /rails
+# 设定 apt 源为阿里云镜像，不然会卡住
+RUN sed -i 's/deb.debian.org/mirrors.aliyun.com/g' /etc/apt/sources.list.d/debian.sources && \
+    sed -i 's/security.debian.org/mirrors.aliyun.com/g' /etc/apt/sources.list.d/debian.sources
# Install base packages
RUN apt-get update -qq && \

代码类似加入 git 仓库

# iterm
git add .
git commit -m "add deploy set"

step6:打部署命令开始部署

# iterm
bin/kamal setup

部署成功：浏览器输入 ip 测试大功告成！！！

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.

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

感谢支持！

坐班宁波，集中办公，提供食宿，招聘测试组长、钱包产品经理、风控产品经理、UI/UX 设计师、Pay 大客户运营

Camellia — Thu, 02 Apr 2026 16:01:41 +0800

项目介绍：

我们是一家注册在马来西亚的公司，主要开发 CEX（0-1），目前团队正处于 0-1 组建阶段。

工作方式：

集中办公，坐班宁波

工作时间：

单双休、九九六

薪资发放形式：

RMB，每月 10 号发放

其他福利：

提供食宿

测试组组长

岗位职责： 1、参与需求评审，编写测试用例、测试计划，执行功能测试、回归测试、兼容性测试等，确保测试覆盖率和质量 2、提交、跟踪、验证缺陷，与开发团队协作推动问题解决 3、参与或主导自动化测试脚本编写、维护，提升测试效率 4、参与性能测试、安全测试等专项测试工作 5、编写测试报告，输出测试结果，为产品发布提供决策依据 6、参与测试流程优化，推动测试左移和持续集成实践 7、测试团队管理：团队搭建、绩效管理等 8、测试流程搭建等岗位要求： 1、5 年以上工作经验 2、精通软件测试理论、方法和流程，熟练掌握至少一种主流编程语言（如 Java/Python）。在自动化测试、性能测试、安全测试或白盒测试等某一专业领域有深厚积累 3、熟悉敏捷开发、DevOps 流程，对 CI/CD 有深入理解。具备大型复杂系统（如微服务架构、云原生应用）的测试规划和实施经验 4、对新技术保持敏感，能主动引入创新测试方法和工具（如 AI 在测试中的应用）以提升效能 5、拥有跨部门沟通和协调能力，能有效解决冲突，推动复杂问题解决加分项： 1、能 base 宁波 2、有理财、支付测试经验优先薪资待遇： 25K-35KRMB

钱包产品经理

岗位核心目标：设计安全、合规、高性能的数字资产钱包系统，支持上层业务需求。详细职责：架构设计：负责钱包产品，深度调研 Fireblocks、Cobo 方案。资产管理：设计并优化资产充值、提现、内部调拨流程；负责多链 Gas Fee 策略优化及归集逻辑。安全合规：设计提现审核风控引擎，确保存储与传输层符合安全合规标准。对账系统：构建链上数据与平台内部数据库的实时、准实时对账系统，确保账实相符。任职资格： 3 年以上加密货币钱包产品经验，熟悉 MPC (Multi-Party Computation) 或 TSS 技术原理。精通主流公链（BTC, ETH, Solana, Layer2s）的转账机制、签名算法及链上节点交互。有处理高并发资金流水对账、资产清算的实战经验。加分项：熟悉 Account Abstraction (EIP-4337) 协议及智能合约钱包。有通过 SOC2 或同级别安全审计的项目经验。薪资待遇： 25K-35KRMB

风控产品经理

岗位核心目标：构建多维度的风险防御矩阵，识别并拦截链上安全威胁、业务欺诈及 DeFi 流动性风险。详细职责：链上风控：能够利用 Chainalysis/Elliptic 等工具监控黑地址流入，设计链上充提币风险评分模型。 DeFi 风险管控：分析 DeFi 理财产品的底层协议安全（如 Flash Loan 攻击、清算风险），建立实时预警机制。反欺诈/反洗钱：负责 KYC/KYB 流程中的风险识别，设计异常登录、薅羊毛、对倒交易拦截策略。处置引擎：建立风险标签体系，设计自动冻结、人工审核、风险降级等分级处置流程。任职资格：熟悉 AML/CFT 合规要求，对加密货币洗钱套路有深度研究。理解 DeFi 协议架构（Uniswap, Aave 等）及其经济模型，能识别智能合约逻辑风险。具备较强的数据建模能力，能协同算法工程师优化风控模型。加分项：具备网络安全、风控背景，熟悉常见的链上攻击和风控手段。薪资待遇： 25K-35k RMB

UI

岗位核心目标：通过极致的交互与视觉细节，降低 Web3 产品的用户认知门槛，打造丝滑的交易体验。详细职责：

设计系统：构建并维护可跨平台（iOS/Android/Web）复用的 Design System，确保全局体验一致性。
用户路径优化：针对 KYC、资产划转、DeFi 认购等复杂流程进行深度交互优化，减少漏斗流失。
本地化设计：针对不同语种（RTL 阿拉伯语等）及区域习惯进行 UI 适配与体验调优。任职资格：
3 年以上移动端 UI 设计经验，有成功上线并面向海外市场的 FinTech 产品案例。
深刻理解 Atomic Design 设计模式，追求像素级的视觉精准度。
熟悉 Web3 特有的交互痛点（如私钥备份、Gas 确认、签名请求）并能提供优雅的 UI 方案。加分项：
具备基础的 Lottie 动效制作能力，提升产品交互反馈质感。
熟悉 HTML/CSS 原理，能与前端开发无缝对接。薪资待遇： 25K-35KRMB

pay 大客户运营

岗位职责： 1、负责社交金融平台的大客户（机构投资者、高净值用户、项目方、KOL 等）的识别、拓展和关系维护 2、建立大客户档案和分级管理体系，制定差异化的客户服务策略 3、定期进行客户拜访、需求调研和满意度回访，建立长期稳定的客户关系 4、深入理解大客户业务需求，挖掘客户潜在价值，推动客户业务规模增长 5、负责大客户的续约、增购、交叉销售等业务拓展，提升客户 LTV（生命周期价值） 6、制定大客户业务增长策略，对客户 ARPU 值、续约率等核心指标负责 7、作为大客户的主要联系人，提供 7×24 小时响应服务，及时解决客户问题 8、协调内部资源（产品、技术、风控等）解决大客户的复杂需求和技术问题 9、建立大客户数据监控体系，追踪客户健康度、活跃度、业务贡献等指标岗位要求： 1、必须有 3 年以上海外运营经验，有 1 年以上跨境支付经验优先 2、对跨境&社交金融有深刻理解，具备独立思考能力 3、基于数据研究和整张需求，完善目标业务的用户生命周期管理 4、洞察 VIP/大客户痛点和需求，完善平台大客户服务体系，提升满意度和忠诚度 5、与产品、运营、技术等团队合作，整合资源，实现业务持续增长薪资待遇： 35K-50K

投递邮箱：camellia@we-boss.com

Base 深圳、自动驾驶 AI 应用公司 ruby 后端工程师 20-30K/月

jeffaima — Thu, 02 Apr 2026 13:41:16 +0800

任职要求：全日制统招计算机科学/相关专业本科及以上学历，5 年以上 Ruby on Rails 全栈加 AI 应用开发经验（联系微信：13822214255）

2、丰富的单元测试经验，注重 TDD（测试驱动开发）\熟练运用 Rails 7 框架；

3、具备 BDD 经验，推动团队采用测试驱动的开发方法；熟练掌握数据库设计和优化；

4、熟悉 SaaS 产品架构设计，有丰富的分布式系统设计、高并发、高可用性经验；

5、熟悉 Ruby on Rails 框架，了解其原理和机制，有丰富的 Rails 项目实战经验；

6、熟悉 AI 大模型应用技术，如 TensorFlow、PyTorch 等，有实际项目应用经验；

7、熟悉 PostgreSQL、Redis、MongoDB 等数据库，了解数据库优化技巧；

8、熟悉 Linux 操作系统，熟悉常用命令和脚本编程；

9、具备良好的团队协作和沟通能力，能承担一定的技术领导责任；

10、有成功带领团队开发大型项目的经验，有带团队解决复杂技术问题的经验。

岗位职责：

负责 SaaS 产品的整体架构设计、技术选型与技术创新/优化
带领团队进行系统开发、优化及维护，确保系统稳定、高效、可扩展；
负责制定并推行技术规范和开发流程，提升团队开发效率和代码质量；
负责技术难题的攻关，解决系统性能瓶颈，提高系统资源利用率；
参与公司战略规划，推动新技术的研究与实践，提升产品竞争力；
领导团队进行 AI 大模型业务场景应用的研发，探索业务场景的创新应用，提供技术方案和实施指导。我们提供：
具有竞争力的薪资待遇，股权激励；
宽广的个人发展空间和职业晋升机会；
舒适的工作环境和良好的团队氛围；
完善的福利待遇，如五险一金、带薪年假、员工体检等。