Ruby China

外包岗位值不值得去？6 年 Java 开发分享真实跳槽经历

KEKE666 — Fri, 31 Jul 2026 15:00:00 +0800

很多程序员都在纠结外包岗位到底能不能去，会不会踩坑。我有过外包任职经历，后续顺利跳槽两家头部互联网企业，今天客观分享我的真实职场经历，内容全部为个人真实感受，理性讨论，不喜勿喷。简单介绍个人背景：普通二本院校，后端 Java 开发，拥有六年开发经验。我的职业发展路线：外包岗位任职一年，之后分别在两家大型互联网企业各工作两年，只是普通技术从业者，谈不上行业大佬。

当初为什么选择外包岗位 2020 年行业环境较差，我此前任职的小型公司直接倒闭，开启了长达两个月的求职空窗期。投递的绝大多数简历都没有回复，少数通过初面的岗位，最终也止步终面。求职低谷阶段，我拿到了大厂外包岗位的录用通知，现在回头客观评价，在当时的处境下，这个选择对我而言十分合适。在外包岗位的一年，技术成长速度远超小型公司先说明，我并不是单纯吹捧外包，客观来讲，这一年是我技术提升最快的阶段之一。大型企业成熟完整的工程体系、大规模线上项目，是中小型公司很难接触到的： 1.亲身落地线上高并发业务场景，不再只是面试题里纸上谈兵； 2.完整标准化 CI/CD 自动化流程，灰度发布、线上回滚、故障治理流程规范清晰； 3.团队代码评审标准严格，初期经常被指出代码漏洞与逻辑问题，长期坚持下来，代码规范、逻辑思维能力提升十分明显。

外包员工和正式员工日常工作差距大吗日常业务开发、团队协作层面基本没有区别：统一办公工位、开发设备、业务需求、项目例会，同事不会刻意区分用工身份，工作只看个人技术实力。园区公共资源全部通用，员工食堂菜品丰富，日常就餐体验很好。客观存在的差异也不会回避：劳动合同签约主体不同，长期股权、专属员工激励福利仅直招正式员工享有。但对于急需积累项目经验、入行时间不长的普通开发者，这类长期福利短期内很难触及，不必过度纠结。

外包项目经历，跳槽时行业认可度如何直接给出结论：市场完全认可，认可度远比大部分人想象的高。我凭借外包阶段的项目经验面试头部互联网企业时，面试官全程只深挖项目技术细节、性能优化落地成果，完全没有纠结我的用工模式。企业招聘技术人员，核心关注点是你落地过什么项目、解决过哪些线上问题、技术实操能力如何，不会单纯因为外包经历否定候选人。我身边同期在外包岗位工作的同事，后续不少人成功入职各大一线互联网企业，职业发展都十分稳定。

最后分享几句职场心里话六年程序员职场走下来，我最深的感悟是：职场没有绝对完美或者一无是处的工作选择，只分适不适合当下的你。长远来看，程序员职业发展的上限，最终取决于自身技术沉淀与持续学习的能力，用工模式只是短期过渡的载体。

如果此刻你正在纠结是否选择外包岗位，希望这篇真实经历能给你一点参考，有任何职场、求职相关疑问，都可以在评论区留言交流。

全栈工程师 / Web3 + Ai Agent / 远程全职 / 45-50K RMB

caidejun — Thu, 30 Jul 2026 00:36:02 +0800

关于我们

我们是一支由加密原生爱好者、工程师和研究人员组成的精锐团队，深耕前沿技术与全球市场的交汇地带，在新加坡设有办公室。我们在创建和扩展科技公司方面的专业能力，使我们不仅能够提供资金支持，更能从工程层面为我们的被投项目赋能，增强其技术实力

岗位职责

1。参与核心系统全生命周期管理，从架构设计、代码实现到部署监控与持续迭代，覆盖 Indexer、API、后台任务、数据管道及内部服务

2。负责云基础设施的搭建与运维，在 AWS 或 GCP 上管理容器、队列、缓存、数据库，并通过 CI/CD、日志、监控、告警和成本控制保障生产环境稳定运行

3。构建低延迟、高可用的实时数据推送系统，通过 WebSocket 向客户端推送价格、交易、看板等数据，并在多条 EVM 链扩展中协调 Indexer 与 RPC 基础设施，确保跨链状态一致性与容错机制

4。设计并维护驱动 AI Agent 的后端基础设施，支持开发者工具、链上推理工作流和内部自动化，涵盖 LLM API 集成、Tool Calling 循环、Skill 执行、日志监控与可靠性保障

5。端到端交付产品功能 —— 从链上事件捕捉、Indexer 数据处理、API 暴露，到 React / Next.js 前端界面落地，覆盖交易、发射、代币看板、钱包连接等完整链路

6。深度参与 AI Agent 生态建设，不仅使用 AI 编程工具，更参与开发、调优和优化 Agent Skill，服务于外部开发者与内部工程流程

岗位要求

1。中文书面与口语流利（必须），英文书面与口语流利（加分项，优先考虑）

2。拥有扎实的生产级全栈开发经验，熟练使用 TypeScript / Node.js / React / Next.js，掌握 Rust 或 Go 者优先

3。深入掌握 PostgreSQL、Redis、消息队列、后台任务、缓存策略与高并发系统设计，能构建正确、快速、稳定的高负载系统

4。具备 AWS 或 GCP 生产环境实操经验，熟悉 Docker、Kubernetes 等容器编排方案，以及部署、扩容、CI/CD、日志、监控、告警和成本优化

5。具有链上数据处理的生产系统经验，包括 Indexer、事件监听、RPC 协调、交易提交等模块

6。能清晰理解并做出技术取舍：eth_getLogs 分页、Subgraph 查询、第三方 API、自建 Indexer 在不同场景下的优劣与选型；

7。具备 Web3 前端开发经验，熟悉 wagmi、viem、ethers，能处理钱包连接、交易签名、合约交互、切链、Pending、Revert 等复杂场景

8。日常使用 AI 编程工具（如 Cursor、Claude Code、Codex），并能清晰阐述其在开发流程中的实际应用

9。具备 LLM API、Tool Calling、Agent 工作流及 AI 系统生产化经验

10。默认关注安全与边界场景：限流、输入校验、鉴权、钱包交互安全、滥用防护、交易 Pending / Revert / 切链等

加分项

1。有智能合约开发经验，能阅读、编写或审计 Solidity 合约；

2。深入理解 EVM 底层机制，能安全构建与智能合约交互的后端系统；

3。有 BNB Chain、Base、Solana 等高吞吐公链的生产级 Indexer 开发经验；

4。有生产级 Agentic AI 系统开发经验，而非仅限 Prompt Engineering；

5。有高并发、高可用、低延迟系统设计经验；

6。有丰富的前端性能优化经验，能构建流畅、响应迅速的 Web3 应用；

7。有主流 Web3 开源项目贡献经历（Indexer、钱包、区块浏览器、前端 SDK 等）；

8。有 Web3 基础设施公司、交易所或钱包公司工作背景。

我们提供

1。具有竞争力的薪资（45-50K 月）

2。远程办公，弹性工作时间，以结果为导向

3。扁平化沟通环境，与全球化团队和行业顶尖工程师共事，可独立推动想法落地

联系方式

简历投递邮箱：mia@oryon.team

请将简历直接发送至上述邮箱，我们会尽快与您联系。（仅通过此邮箱接收简历与沟通）

面试官问"DeepSeek 开始峰谷定价了，你怎么看 AI 商业模式"

KEKE666 — Wed, 29 Jul 2026 10:07:17 +0800

上周面了一家 AI 赛道的 B 轮公司，面的是产品技术负责人岗位。

三面，前两轮技术面和业务面都聊得挺顺。到了 CEO 面，他喝了口水，抛了个问题：

"你看到 DeepSeek V4 开始搞峰谷定价了吗？你怎么看这件事？"

这个问题乍一听像是在问新闻看法，但我知道没那么简单。CEO 面的问题，考的永远不是你的信息量，而是你的思考框架。

我的回答分三层：

第一层：这件事的本质是什么？

我说："DeepSeek 搞峰谷定价，表面上是价格策略调整，本质上是在解决算力供需失衡的问题。"

"AI API 的算力消耗是不均匀的。每天上午 9 点到 12 点、下午 2 点到 6 点是高峰，大量开发者和企业在这些时段集中调用 API。但算力基础设施是固定投入的，不可能按峰值来建——否则低谷期就浪费了。"

"峰谷定价的本质，是用价格杠杆来调节需求分布，把一部分非紧急调用从高峰期转移到低谷期，从而在不增加硬件投入的前提下提升整体服务稳定性。这和电力的峰谷电价是同一个逻辑。"

CEO 点了点头："继续。"

第二层：这说明了什么行业趋势？

"第二点，我觉得这说明 AI API 市场已经从'抢用户'阶段进入了'精细化运营'阶段。"

"前两年的逻辑是：拼命降价、免费额度拉满、先把开发者圈进来。DeepSeek 自己就是靠极致性价比杀出来的——V3 的定价一度低到让 OpenAI 都紧张。"

"但当用户量上来了，算力成本的压力就藏不住了。峰谷定价其实是一个信号：AI API 的'价格战'阶段要结束了，接下来是'效率战'阶段。谁能用更少的算力、更聪明的调度策略、更稳定的服务质量来留住用户，谁就能活下来。"

"这不是 DeepSeek 一家的问题，是所有大模型厂商迟早要面对的。"

第三层：对我们公司有什么启示？

"第三点，也是最重要的一点——这件事对我们自己的商业模式设计有直接参考价值。"

"我们做的是垂直行业的 AI 解决方案，不是通用大模型。但底层同样面临算力成本问题。DeepSeek 的峰谷定价给了我一个启发：我们是不是也可以根据客户的调用场景，设计差异化的定价策略？ "

"比如，金融客户对实时性要求高，愿意付溢价；而一些做数据分析的客户，可以接受延迟几小时的处理，那我们就可以在低谷期帮他们跑，既降低了我们的算力成本，也给了客户更低的价格。"

"这不是简单的涨价或降价，而是通过场景分层来优化整个成本结构。"

面试官追问

CEO 听完，追问了一个问题："那你觉得峰谷定价会不会导致开发者流失？比如一些小团队，他们只能在高峰期调用，贵了一倍可能就跑了。"

我说："会有一定流失，但不大。原因有两个："

"第一，真正对价格敏感的小团队，本来就更倾向于用开源模型自建，而不是调 API。峰谷定价影响的主要是中型客户，而他们有足够的灵活性来调整调用时段。"

"第二，服务稳定性本身就是价值。如果高峰期能因为价格调节而变得更稳定，很多开发者反而愿意付这个钱。你想想，线上服务因为 API 抖动崩一次，损失的可不只是几分钱的调用费。"

"所以我的看法是：峰谷定价短期内会有争议，但长期看是正确的方向。它说明中国 AI 市场正在走向成熟，不再是靠烧钱换规模，而是开始用商业智慧来平衡供需。 "

面试结果

面完第二天就收到了 offer。HR 反馈说 CEO 对我的评价是"有商业 sense 的技术人"。

后来入职后才知道，那道题其实是他面试产品技术负责人的"标配题"——不是要看你知不知道 DeepSeek 的新闻，而是要看你能不能从一个新闻事件里拆解出商业逻辑、行业趋势和对自身业务的启发。

三个层次，缺一不可。只说"降价是好事"或"涨价不合理"，都太浅了。

RubyGems 安全公告：不正确的缓存配置可能导致旧版 API 密钥泄露

Rei — Tue, 28 Jul 2026 15:27:22 +0800

https://blog.rubygems.org/2026/07/22/security-advisory-legacy-api-key-leak.html

rubygems.org 不正确的 CDN 缓存导致用户 api key 可能被泄漏。
旧的 api key 已经全部撤销，gem 发布者应该检查自己管理的 gem 有没有不正常的内容。

技术细节见正文。

中国科学技术大学 USTC 提供 cache.ruby-lang.org 镜像！

ccmywish — Mon, 27 Jul 2026 14:19:54 +0800

新的服务

rbenv 使用 CRuby 的源代码来编译安装 Ruby，因而需要访问 https://cache.ruby-lang.org/ 很遗憾，Ruby China 停止对其镜像，我们只能另寻它法。

由于之前在 USTC（中国科学技术大学）镜像站参与镜像工作的 @iBug 在尝试增加和完善对 RubyGems 的镜像服务，我因此将 USTC 镜像站加入 chsrc 的换源列表中，与 Ruby China 并列（其他镜像站均不可用），所以我认为 USTC 镜像站对 Ruby 的镜像支持也许是开放和接纳的，于是我提出了 issue: https://github.com/ustclug/mirrorrequest/issues/449

USTC 的工作人员很快响应了这个请求，为我们带来了 https://mirrors.ustc.edu.cn/ruby/ 🎉🎉🎉

rbenv-cn

使用 rbenv-cn 的朋友，可以直接使用 rbenv update 命令更新即可完成镜像切换

致谢

感谢中国科学技术大学镜像站提供的存储与带宽，感谢各位工作人员，尤其是接手此 issue 的 @iBug 与 MirageTurtle

感谢提供了十几年镜像服务的 Ruby China 社区，尤其是 @huacnlee 的持续推动和维护！

Claude Code 初学者必看指南

KEKE666 — Mon, 27 Jul 2026 09:33:22 +0800

01｜什么是 Claude Code

一句话：

👉 Claude Code = 终端里的 AI 执行助手

你可以用一句人话，让它帮你：

写代码改文件整理资料分析数据自动完成任务

📌 和普通 AI 最大区别：

ChatGPT：告诉你怎么做 Claude Code：直接帮你做

02｜快速安装核心只有一句话：

👉 先装 Node → 再装 Claude Code

安装 Node.js

nodejs.org 选择 LTS 版本验证：node -v npm -v 安装 Claude Code

npm install -g [@anthropic(https://x.com/@anthropic) -ai/claude-code验证

claude --version

03｜连接国内大模型

一、编辑或新增 settings.json 文件 MacOS 在.claude 文件夹下创建 settings.json， ~/.claude/settings.jsonWindows 为用户目录/.claude/settings.json#新增或修改里面的env字段# 注意替换里面的 your_deepseek_key 为您上一步获取到的 API Key{"env": {"ANTHROPIC_AUTH_TOKEN": "your_deepseek_key","ANTHROPIC_BASE_URL":"https://api.deepseek.com/anthropic,API_TIMEOUT_MS:" "3000000","CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": 1,"ANTHROPIC_DEFAULT_HAIKU_MODEL": "glm-4.5-air","ANTHROPIC_DEFAULT_SONNET_MODEL": "glm-4.7","ANTHROPIC_DEFAULT_OPUS_MODEL": "glm-4.7"}}

二、再编辑或新增 .claude.json 文件用去跳过 MacOS & Linux 为 ~/.claude.jsonWindows 为用户目录/.claude.json# 再编辑或新增.claude.json 文件# 新增 hasCompletedOnboarding 参数{"hasCompletedOnboarding": true}

三、进入 ClaudeCode 确认首先确认系统默认的模型名称然后输入/status 命令查看 baseUrl 和模型名称，输入命令 /status

——转载自：想不到一个好的 ID

Ruby China Gems 镜像服务停服公告

huacnlee — Tue, 21 Jul 2026 10:27:20 +0800

今天（2026 年 7 月 21 日），Ruby China 正式停止以下镜像服务：

gems.ruby-china.com：RubyGems 镜像
cache.ruby-china.com：Ruby 源代码及安装包镜像
index.ruby-china.com：RubyGems 静态文件服务 (备用)

这些服务已经运行了十多年。

我们做出这个决定，主要还是因为费用以及长期赞助的问题。

为什么停止服务

Ruby China 的镜像一直是一项完全免费、面向所有人的公共服务。

这些年来，镜像能够持续运行，主要依赖阿里巴巴、腾讯云、又拍云等厂商在不同阶段提供的服务器、CDN 和网络资源，以及 Ruby China 社区自身承担的一部分费用。

Ruby China 本身没有稳定的商业收入。社区经费主要来自厂商赞助以及历届 RubyConf China 活动结束后剩余的少量资金。

最近一年，我们陆续向腾讯云账户充值了大约 6000 元。目前腾讯云部分平均每月产生四五百元费用，但这是在已经设置流量限制的情况下产生的，也并不是整套镜像服务的全部成本。

RubyGems 的大量静态文件以及 Ruby 安装包的流量，长期以来仍然由又拍云提供资源支持。如果把这一部分实际消耗的 CDN 和存储费用也计算进去，整体成本会高出很多。

这类公共镜像服务还有一个比较麻烦的问题：费用不是固定的。

镜像的费用主要根据流量计算，而公开服务的流量很难准确预测。

这些年来，我们经常会遇到一些程序持续下载大量文件、企业内部做全量镜像、基于本站再次搭建二次镜像，以及其他异常请求。有些单个 IP 每天就会产生几十 GB，甚至上百 GB 的流量。

以前我也曾经在很长一段时间里，经常检查每日流量，将消耗异常的 IP 手工封禁。但这些请求的来源和 IP 随时会发生变化，不可能完全依靠人工处理。

如果不设置限制，一次异常流量就可能在很短时间内产生上千元费用。因此，最近我们不得不为 CDN 增加单日流量封顶限制。当流量达到限制后，服务会被自动关闭。

今年社区中出现的 418、证书错误以及服务无法访问，部分也是因为触发了这套流量限制：

Ruby China Gems 变茶壶了

所以，这个问题并不只是再去找几千元赞助就能够解决。

理论上，我们仍然可以继续联系厂商，尝试申请新的赞助。但对于一个按照流量计费、费用可能随时发生较大变化的公共服务，我们很难准确判断一年究竟需要申请多少预算，也很难让赞助方长期承担一项没有明确费用边界的服务。

过去很多年里，又拍云以不计流量费用的方式支持 Ruby China，承担了这套镜像服务中很大一部分实际成本。正是因为有这种长期支持，镜像才得以持续运行十多年。

随着国内云服务市场逐渐成熟，厂商的社区合作和赞助策略也在发生变化。以前熟悉的合作渠道和联系人不断变动，重新沟通和申请赞助也变得越来越困难。

我们完全理解厂商在不同阶段需要调整自己的经营与合作策略，也非常感谢他们已经为 Ruby China 社区提供了这么多年的帮助。

综合这些因素，我们最终决定停止镜像服务。

Ruby China 镜像服务的历史

回头来看，这套服务大致经历了三个主要阶段。

第一阶段：ruby.taobao.org

RubyGems 镜像最早可以追溯到 2011 年。

2011 年 11 月，我在社区介绍了 rubygems-mirror 和 geminabox，尝试寻找一种搭建 RubyGems 镜像的方式：

有想搞 Rubygems 镜像的可以试试 rubygems-mirror 和 geminabox

随后，淘宝内部提供了服务器和网络资源，ruby.taobao.org 正式上线：

现在起，改用国内镜像服务器来装 Gem 吧

当时的实现方式，是通过 rubygems-mirror 定期将 RubyGems.org 的数据同步到国内服务器，然后由国内的 Nginx 对外提供服务。

在当年的网络环境下，国内访问 RubyGems.org 非常困难。安装一个 Gem 经常需要等待很长时间，甚至会反复失败。ruby.taobao.org 的上线，解决了很多国内 Ruby 开发者安装依赖的问题。

这一阶段的服务器、网络以及相关费用，主要由淘宝和阿里巴巴提供。

但传统同步镜像的问题，不只是实时性。

同步任务需要持续、定期运行。同步过程中只要境外网络出现抖动、连接中断，或者上游的索引和文件发生异常，就可能导致同步失败、数据不完整，甚至整个镜像长时间停留在旧状态。

RubyGems 当时的镜像和索引生成机制本身也并不完善。将 .gem 文件下载到本地相对容易，但重新生成完整索引时，只要遇到一个格式不规范的旧 Gem，就可能导致整个过程失败。

同步失败后，通常还需要人工检查日志、重新执行任务、清理不完整文件，并确认索引与文件是否重新保持一致。

这套方案看起来比较直接，但实际运行起来需要持续关注。网络只要出现一次抖动，就可能需要人工介入，维护上需要投入不少时间。

同时，一个新的 Gem 版本发布以后，也必须等待下一轮同步完成才能从镜像中安装。如果同步任务刚好出现故障，新版本可能在较长时间里一直无法使用。

到了后期，随着维护人员的工作变动以及阿里内部服务器管理环境的变化，ruby.taobao.org 逐渐变得难以继续维护。

第二阶段：迁移到 Ruby China，改用实时回源

2016 年 3 月，我们宣布由 Ruby China 接手 RubyGems 镜像：

Ruby China 的 RubyGems 镜像上线

这一次，我们没有继续采用传统的定时全量同步，而是改成了一套基于 CDN 和实时回源的架构。

动态 API 和索引文件通过境外节点实时访问 RubyGems.org，可以长期缓存的 .gem 文件则进入国内 CDN 和镜像存储。

这套方案主要解决了两个问题：

不再需要持续运行全量同步任务，减少因为同步失败而产生的人工维护；
新发布的 Gem 不需要等待下一轮同步，可以立即通过镜像获取。

实际安装过程中，RubyGems 会产生很多不同类型的请求。

其中 .gem 文件是静态文件，一旦某个版本发布，内容就不会再发生变化，因此可以长期缓存到国内 CDN。

但版本索引、API 以及部分元数据文件需要保持实时，无法简单地永久缓存。这部分请求仍然需要通过境外线路访问 RubyGems.org。

因此，这套方案本质上做了两件事情：

为 RubyGems 的动态 API 和索引请求提供实时代理；
为可以长期缓存的 .gem 文件提供国内 CDN 加速。

最初的实时镜像通过腾讯云 CDN 和境外服务器提供服务。随后，我们逐步将 .gem 文件迁移到又拍云的 CDN 和镜像存储中。

2016 年 5 月，镜像曾经因为缓存规则以及境外回源问题出现过一段时间的 502。当时的故障说明也记录了这套架构的具体工作方式：

gems.ruby-china.org 最近两天 Bad Gateway 502 的问题

问题解决后，当时 RubyGems 上的 60 多万个 .gem 文件被存储到又拍云的国内存储中。已经进入存储的文件不再需要回源，可以直接从国内 CDN 下载。

同年 4 月，我们又上线了 Ruby 官方安装包镜像：

上线 Ruby 安装包镜像 - cache.ruby-china.org

这个服务通过又拍云 CDN 对 cache.ruby-lang.org 进行实时回源，并将访问过的 Ruby 源代码和安装包长期存储在国内。

它同样不需要定时同步：

Ruby 官方发布新版本后可以立即获取；
不需要人工运行同步任务；
Ruby 源代码和安装包通过国内 CDN 下载；
RVM、rbenv 和 ruby-build 都可以使用。

在之后的很多年里，cache.ruby-china.com 一直是国内开发者安装 Ruby 时常用的下载地址。

2018 年，由于 .org 域名无法备案，两个镜像域名从 .org 更换为 .com：

gems.ruby-china.org → gems.ruby-china.com
cache.ruby-china.org → cache.ruby-china.com

当年的公告：

Ruby China 镜像域名变化

这一次只是更换了服务域名，背后的架构没有发生变化。

第三阶段：腾讯云与又拍云的混合架构

又运行了几年以后，由于又拍云自身网络架构和境外回源线路的调整，动态请求的稳定性开始受到影响。

RubyGems 安装过程中，虽然体积较大的 .gem 文件可以从国内 CDN 获取，但 API、版本索引以及部分无法长期缓存的文件仍然需要实时回源。境外线路只要发生抖动，就可能导致一次 bundle install 失败。

为了改善这部分请求的稳定性，我们又将主要服务逐步迁移到腾讯云。

2023 年，我们对 RubyGems 镜像进行了最后一次比较大的架构调整：

Ruby China Gems 镜像变更公告

最终的架构主要由以下几部分组成：

动态 API 请求通过腾讯云境外 CDN 节点回源到 RubyGems.org；
可以长期缓存的 .gem 文件通过 302 跳转到 index.ruby-china.com；
静态文件继续通过又拍云国内 CDN 下载；
/versions 等常用索引文件通过腾讯云的预热机制定期更新；
又拍云上原有的服务继续作为备用线路；
后来又增加了全球 CDN 节点，减少国内网络直连香港时可能出现的丢包问题。

这套混合架构一直运行到今天。

2023 年，我在社区的回复里也再次说明过 Ruby China 镜像的设计方式：

镜像站速度哪家强？Ruby 的源到底有哪些可用？

简单来说，最后这套 RubyGems 镜像由三个部分共同支撑：

腾讯云 CDN 负责动态 API 和索引请求；
又拍云 CDN 和存储负责大量静态文件；
Ruby China 社区经费负责腾讯云动态回源部分产生的费用。

大多数时候，这套服务可以处于低维护状态，不需要频繁人工处理。但只要境外回源线路、CDN 缓存规则、SSL 证书或者账户费用出现变化，仍然需要人工介入。

2025 年 10 月，index.ruby-china.com 曾经因为又拍云境外回源异常，持续出现 503：

index.ruby-china.com/gems 的相关 Gem 开始报 503

当时经过临时调整后恢复了服务，但这也再次说明，实时回源方案仍然依赖云厂商跨境网络的稳定性。

到了 2026 年，腾讯云 CDN 又开始出现明显的异常流量。为了避免账户余额在短时间内被大量消耗，我们不得不增加单日流量封顶限制。

随着又拍云长期社区赞助政策发生变化，这套由腾讯云、又拍云和 Ruby China 社区经费共同维持的架构，也无法再按照过去的方式继续运行。

为什么今天不再那么依赖公共镜像

十多年前，国内开发者直接访问 RubyGems.org 非常困难。

当时很多 Rails 项目仍然通过 Capistrano 将源代码发布到服务器，然后直接在生产服务器上执行 bundle install。生产服务器通常不会配置代理，因此一个能够直接访问的国内 RubyGems 镜像非常重要。

今天的开发和部署方式已经发生了很大变化。

Docker、CI/CD 和容器镜像已经成为常见的发布方式。项目依赖通常会在 CI 或镜像构建阶段提前安装，并打包进最终的发布产物，而不是每次部署时都在生产服务器上重新下载。

开发者访问 GitHub、海外云平台以及其他开发基础设施的方式也比十多年前更加丰富。在一个可控的 CI 或构建环境中直接使用 RubyGems.org，通常会是更简单、直接的方案。

包括我自己在实际项目中的经验，也是尽量直接使用官方源，并在 CI 或 Docker 构建阶段提前准备好依赖。

公共镜像曾经很好地解决了那个阶段的问题，但它在今天已经不像当年那样不可替代。

如何迁移

请检查本地开发环境、生产服务器、CI 配置和 Dockerfile 中，是否还在使用 Ruby China 镜像。

RubyGems

将 RubyGems Source 改回官方源：

gem sources --remove https://gems.ruby-china.com/
gem sources --add https://rubygems.org/
gem sources --list

Bundler

如果 Gemfile 中使用了 Ruby China 镜像：

source "https://gems.ruby-china.com"

请修改为：

source "https://rubygems.org"

如果配置过 Bundler Mirror，可以移除对应配置：

bundle config unset --global mirror.https://rubygems.org

也请检查项目目录中的 .bundle/config，以及 CI 环境中是否存在相关配置。

Ruby 安装包

Ruby 源代码和安装包请改用官方地址：

使用 RVM、rbenv 或 ruby-build 的用户，也请检查是否配置过：

https://cache.ruby-china.com

并将相关配置移除或改回 Ruby 官方地址。

RVM

Ruby China 以前的安装文档曾建议通过下面的命令，将 RVM 下载 Ruby 源代码的地址切换到本站镜像：

echo "ruby_url=https://cache.ruby-china.com/pub/ruby" > ~/.rvm/user/db

如果曾经执行过这条命令，停服后再次运行 rvm install 安装新的 Ruby 版本时，下载可能会失败。已经通过 RVM 安装好的 Ruby 不受影响；这项配置也不影响 RubyGems 或 Bundler 下载 Gem。

可以先检查是否存在该配置：

grep '^ruby_url=' ~/.rvm/user/db

如果输出指向 cache.ruby-china.com，请编辑 ~/.rvm/user/db，删除对应的 ruby_url 配置，或者改为 Ruby 官方地址：

ruby_url=https://cache.ruby-lang.org/pub/ruby

请不要直接覆盖或删除整个 ~/.rvm/user/db，因为其中可能还保存了其他 RVM 自定义配置。

rbenv 与 ruby-build

如果使用 ruby-build，也请检查 Shell 配置、CI 环境变量和 Dockerfile 中是否设置过：

RUBY_BUILD_MIRROR_URL=https://cache.ruby-china.com

请移除该环境变量，让 ruby-build 恢复使用默认下载地址。如果安装过 rbenv-china-mirror 等镜像插件，也需要将其禁用或移除。

感谢

感谢阿里巴巴、腾讯云、又拍云在不同阶段为 Ruby China 镜像服务提供的服务器、CDN、存储和资金支持。

尤其感谢又拍云，多年来一直为 Ruby China 提供大量 CDN 和存储资源，这些镜像服务能够持续运行十多年，离不开他们的长期支持。

也感谢所有使用、反馈和帮助维护过这些服务的朋友。

[Remote][美国 A 轮] Bidbus 招聘高级全栈工程师和 Agent 工程师

zamia — Tue, 21 Jul 2026 03:16:27 +0800

公司

Bidbus 是一家美国二手车在线拍卖平台，通过 online 拍卖的形式让 dealer 竞价以便帮助个人卖家获得更高的售价。团队过去一年业务量增长了 8 倍，也刚完成 A 轮 $15M 的融资。创新的商业模式加上 AI Agent 的广泛使用得到了行业和投资人的追捧。

基本信息：

官网：Bidbus
TechCrunch 融资报道：TechCrunch

待遇和福利

目前准备在中国招聘全职、Remote 的全栈工程师和 AI 工程师，大约共招聘 3～5 名。基本的待遇和福利如下：

薪资：根据不同候选人的能力和经验，约 ¥4w~7w/月
五险一金、额外商业保险
全远程：日常沟通主要是每日 15min 例会
每月 $300 刀的信用卡额度用来订阅 AI coding subscription
很重要的一点是，目前公司还在 A 轮，期权空间比较大，我们也准备了期权池给新员工

全栈工程师

负责公司核心业务系统开发，包括 Ruby on Rails（主业务）, Python FastAPI（AI 和其他）, React 技术栈
5 年以上全栈开发经验，有独立负责生产系统核心业务模块的经历
良好的代码品味
一定的产品能力，可以把需求转化为系统设计

AI Agent 工程师

主要负责公司 AI Chat/Call Agent 开发，以及训练模型和推荐算法等
与运营团队合作，建立评测体系、持续优化 Agent 性能
2 年以上 Agent 相关开发经验，有 ML、算法经验更好

欢迎直接投递简历到 hr@bidbus.com

Ruby 全栈开发高级工程师

Kimilyd2026 — Sat, 18 Jul 2026 14:26:48 +0800

岗位 JD

一、岗位信息

岗位名称：Ruby 全栈开发高级工程师
工作地点：深圳・龙华
工作年限：3-8 年
汇报给 CTO
招聘人数：2-3 人
岗位性质：全职
薪资范围：25k-45k
岗位职责

参与公司 SaaS 产品的设计，开发，测试。开发支付，后台管理，数据统计，移动端后端 API 服务 web 应用

两年以上 Tuby rails 开发经验
熟练掌握 Ruby、rails 高并发多线程分布式调优，精通引擎以及中间件加载
熟练掌握前端开发 html css JS 熟悉 linux mysql 对 passenger，puma 等 app server 有一定了解
对架构和代码质量有高要求掌握 redis 基本操作 ssl tls 协议熟悉 nginx 配置
熟悉 go，python 等为加分项
熟悉 react，angular vue 前端框架

联系方式 76232004@qq.com 邮件投递简历沟通此岗位仅仅接受现场办公不接受远程支持慎投慎投慎投

用 rails 做了个小网站，拯救老 Kindle。

AixCoder — Fri, 17 Jul 2026 15:33:13 +0800

老 Kindle 的 AI 时代重生记

从泡面盖到村上春树私人图书馆，我只用了一个周末 https://kindle.petercat.life

Kindle 图书馆

缘起：一块被遗忘的墨水屏

家里的 Kindle 在吃灰，偶尔想起来充个电，想着怎么样在 AI 时代能够盘活这个老设备

作为一个正在自学 Rails 开发的小白，在找一个"有真实需求"的练手项目。

"既然手里这台还能用，就自己建一个图书馆。"

项目定位：Kindle × 村上春树 × Rails

我给自己定了三个原则：

解决真实痛点：Kindle 用户现在下载书不是很方便
技术栈统一：全用 Rails 7，不引入不必要的复杂度，纯原生 js 交互，方便兼容老 Kindle

第一个版本的目标很小：让 Kindle 能方便地下载村上春树的电子书。加入了订阅微信公众号，在老 Kindle 上读公众号还不错，目前还没有开放，很快就开放注册账号。

正好在整理他的作品集，做自己喜欢的东西，才不会烂尾。

技术架构：轻量、快速、可扩展

技术选型

层级	技术	理由
后端	Ruby on Rails 7
数据库	SQLite	个人项目够用，部署零配置

核心功能模块

kindle.petercat.life
├── 📚 订阅（自己使用中，稍后再开放注册）
├── ⬇️ 村上文学馆（无需登录，开启电子书下载，适配Kindle的mobi/azw3格式）

开发实录：gpt 十几个小时做了个这么个小项目

第三天：公众号订阅功能

这是目前还在调试的功能，也是试下来比较好的部分，得益于墨水屏的观感好。

思路很简单：

用户输入想关注的公众号🔗
后端抓取最新文章
自动排版成适合 Kindle 阅读的格式

在 Kindle 上读公众号：一种全新的阅读仪式

Kindle 的慢，反而成了一种优势。 它强迫你进入深度阅读的状态，而这正是公众号长文最需要的。

未来计划

[ ] 公众号订阅功能正式上线
[ ] 支持 RSS 源聚合（不只是公众号）
[ ] 接入更多作家作品（不只是村上春树）

写在最后

如果你家里也有吃灰的 Kindle，利用起来，Kindle 的屏幕放到今天来看也不过时。

[上海][2026 年 07 月 14 日] Ruby Tuesday: OpenCode 企业二开 & AI-DLC 由 ai 驱动的开发流程

ericguo — Thu, 09 Jul 2026 15:24:49 +0800

时间：2026 年 07 月 14 日 (周二) 19:45 - 21:15

地点：上海市静安区南京西路 699 号东方投资大厦 26 楼 Faria 办公室 (地铁 2 号线南京西路地铁站)

主题：如何控制 AI 写出稳定的 Rails 功能

2026 年第二次聚会

主题一：OpenCode 企业二开

分享人：@Eric-Guo

回顾 OpenCode 近半年的进展 OpenCode has doubled its monthly active users since April
如何在 OpenCode Desktop 的基础上搭建一个企业自己的 AI workbench
介绍一个开源的例子，IT support 机器人，UI 自己 Vibe，Agentic Core 使用opencode serve

主题二：AI-DLC 由 AI 驱动的开发流程

分享人：@ChenNima

Chorus AIDLC

现场会议（推荐）

在线拨入

会议主题：OpenCode 企业二开 & AI-DLC 由 ai 驱动的开发流程会议时间：2026/07/14 19:45-20:15 (GMT+08:00)

OpenCode 企业二开 https://meeting.tencent.com/dm/AkbS65JIbwRJ

AI-DLC 由 ai 驱动的开发流程 https://meeting.tencent.com/dm/jzVw9dnD4ggh

Show Ruby China: 我用 Rails 8 开发的开源技术社区网站 MZFOSS

daqing — Sat, 04 Jul 2026 17:47:10 +0800

大家好！

最近我用 Rails 8，开发了一个开源技术社区网站，用来追踪社区进展、技术观点与开发者正在讨论的高质量内容。

经过 2 天的开发，网站基本上线了。

网址：https://mzfoss.com

如果你感兴趣，欢迎来看看。

另外，社区投稿，可以领红包，欢迎投稿哦～～

写了一个 Ruby 框架来管理个人环境初始化脚本

yetrun — Sat, 04 Jul 2026 15:29:38 +0800

已经两年没有逛 Ruby 社区了，抛弃 Ruby 语言也大概有两年之久了。现在重新捡起来，并开发了一个小项目 setup-env，用来把个人环境初始化流程（tmux、zsh、dotfiles、开发工具等）写成可维护的 Ruby 脚本。

仓库：https://github.com/yetrun/setup-env

它解决什么问题

相信大家手里都攒了一堆初始化脚本，新机器/虚拟机来了就执行一遍。但脚本一多，常见问题就来了：

中途失败不知道跑到哪，只能从头再来；
已经装过的步骤重复执行，浪费时间，还可能覆盖配置；
每个脚本都要自己处理代理、包管理器差异（apt/yum/brew）；
Bash 写复杂流程、状态记录和交互越来越痛苦。

setup-env 的做法

用 Ruby DSL 把初始化流程拆成一个个 step，框架帮你记录状态：

失败后支持重试、跳过、切换代理；
已完成的步骤自动跳过；
内置代理和包管理器差异处理；
配合 Vagrant 做测试验证。

仓库里的 scripts/ 是我的自用脚本和示例，大家可以参考写法，也可以 fork 后改成自己的初始化仓库。

项目刚起步，欢迎试用、提 issue 或给建议 🙏

怎么让 AI 写出更有 Rails 味的代码？

willx — Wed, 01 Jul 2026 13:04:05 +0800

最近用 AI 写 Rails，发现它很喜欢按那种 controller -> service -> model 的方式组织代码。代码能跑，但是确实完全没有 Rails 的味道。

经常上来就加 service，把 model 写得很贫血；concerns、mixin、Ruby 本身的一些顺手写法也不太会主动用。

我想让 AI 写得更接近 Rails 传统那种 fat model、skinny controller 的感觉，不要动不动就分层分到很远。

大家有类似经验吗？有没有 SKILL 可以推荐一下的。

有没有招 Rails 远程开发的

eylu — Wed, 24 Jun 2026 15:43:25 +0800

从事全栈（rails）开发有 8, 9 年了，可熟练使用 Redis、Sentry、Slack、Elasticsearch、Git、队列 (Sidekiq)、Docker 等。

熟悉 TDD 流程，习惯编写 Rspec、Capybara 自动化测试，覆盖率 95% 以上，熟练构建 CI/CD 集成化部署。

精通 react、vue、css、css3、stimulus、tailwind、next.js 等。

对 CSS 有洁癖，可以高度还原 UI 设计。

熟悉 webpack、vite 打包等。

完成过商城系统，商城 App，后台管理系统，社区杂志等多种类系统。

可以使用 ClaudeCode、OpenCode、Cursor、Trae 等进行 AI 辅助开发。

可以做 Rails 开发，也可以做前端开发。

一个仅 500 行 Ruby 代码的极简 Agent，支持 ReAct、Skill、MCP、异步压缩、持久化记忆、hooks、sandbox、安全审批等能力

kkhaha — Fri, 19 Jun 2026 13:43:48 +0800

Langdriver 是一个仅 500 行 Ruby 代码的极简 Agent：基于 ReAct 与 macOS 沙箱机制构建，针对 DeepSeek 进行了开箱即用的深度优化，全面兼容 DeepSeek 工具调用（tool-calls），支持 Skill、MCP、异步压缩、持久化记忆、hooks、sandbox、安全审批等能力。随着 LLM 能力的提升和 Skill 生态的扩展，LangDriver 的能力也会随之增强。 https://github.com/kevin0x5/langdriver

新书《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）。

【更新】

社区五折名额已经用完了。非常感谢这些读者对本书的购买支持！

不过社区用户依然可以微信联系我，我会对 RubyChina 用户给予九折优惠！

使用 1password environments 来管理环境变量

ironboxer — Tue, 09 Jun 2026 15:28:33 +0800

最近的一个项目中，用了 1password environments 来管理环境变量，感觉还行，用起来比较简单。

而且还支持 mount，修改之后，本地 mount 的文件自动也修改了。

Ontology driven Agent：从“提示词工程（Prompt Engineering）”向“智能体软件工程（Agent Software Engineering）”

shoushen — Fri, 05 Jun 2026 09:10:45 +0800

目前，我感觉全球的 agent 开发陷入了一个瓶颈期，虽然大家在做各种努力，但本质上仍然是提示词工程。

我最近在看本体论，我发现将本体论（Ontology）加入到 agent 开发中来，能够彻底改变当前 agent 开发遇到的问题。

一、消除幻觉。提示词只能用自然语言“建议”模型去遵循规则，但 LLM 随时可能产生幻觉。本体论则是用严格的数据结构定义了业务的“物理法则”。
二、动态能力路由与权限控制。当不同的用户或子 Agent 介入时，系统通过图谱查询动态计算出当前上下文应该拼装哪些 Tool 的 Schema，然后再转化为提示词发给模型。
三、增强逻辑推理能力。通过推理机实现推理，而不是依赖于大语言模型。
四、提示词无法可靠地控制复杂的先后顺序和错误恢复。本体定义了有向无环图 (DAG) 依赖关系，可以驱动工作流。

还有：

安全护栏、动态本体上下文裁剪、反思与自我纠错、分布式本体、多 agent、长期记忆、自适应演进、零代码 Agent、事件和时间、跨智能体协议、复杂任务、神经 - 符号混合推理等方面，在引入本体论后都有更优雅的实现方式。

特别是：

在编程 agent 中，将代码以某种形式本体化后，就可以实现代码、业务逻辑、开发流水线的有机融合，将会极大的提高编程 agent 的工程能力。

另外补充：/

看了这个项目的解释视频（我也是看到这个视频的启发），虽然比较初步，但是可以看到将本体论引入编程 agent 的巨大潜力。

Ruby on Rails / DiscoursePluginEngineerRemote

ninebeta — Wed, 03 Jun 2026 16:25:56 +0800

About Us

Building next-gen AI developer community centered on knowledge sharing, collaboration & open innovation. Platform based on Discourse, iterated via custom plugins, AI modules, recommendation engine and developer tools. Hiring seasoned Ruby on Rails engineer specializing in Discourse plugin development.

Responsibilities

Develop & maintain customized Discourse plugins
Modify and expand Discourse core capabilities
Construct new community functions and business workflows
Connect third-party APIs and AI service interfaces
Optimize system performance and expand platform scalability
Diagnose and fix online production faults
Cross-team cooperation with product & community teams

Requirements

Mandatory Qualifications

Solid Ruby on Rails development background
Practical Discourse plugin development track record
In-depth grasp of Discourse underlying architecture
Proficiency in PostgreSQL, Redis
Hands-on experience with Docker & Linux operation
Skilled in Git and mainstream development processes
Capable of reading English technical documents smoothly

Preferred Qualifications

Operation experience of large-scale online communities
Discourse Theme Components development experience
Ember.js relevant knowledge
Past integration work with AI/LLM APIs
Open-source contribution history
DevOps or cloud infrastructure experience

Personal Expectation for Candidates

Self-motivated, capable of independent work
Enthusiastic about open source and developer community construction
Excellent troubleshooting capability
Focus on product quality and user experience
Able to deliver deployable production code

Compensation Package

Competitive salary package
100% remote working
Flexible working schedule
Long-term stable employment
Equity option for top-performing hires

Application Materials & Submission

Required attachments:

GitHub homepage link
Resume / LinkedIn profile
Self-developed Discourse plugin samples
Related project portfolio
Expected salary range

tel&wechat:MTc1MjEyMTM5ODU=