lyfi2003 (windy)

Harness 工程经验分享：实现 100% 缓存命中 OpenClacky（RubyAgent）的 7 个关键决策

lyfi2003 — Thu, 14 May 2026 19:40:04 +0800

感谢社区朋友的支持，OpenClacky 的关注量从 200+ 马上破 400 了~ 用户活跃量已经翻倍。

我把这二年的坑和 Ruby 重写 AIAgent 的思考放出来，大家一起看看离 ClaudeCode 这种顶级 Harness 工程还有多远。

开篇

为了让新朋友重新了解一下我们的评测结果，我再列一下。

成本极优：3 项任务实测，4 家 Agent 横评，OpenRouter CSV 逐请求核算：

Agent	总成本	请求数	Cache 命中率
OpenClacky	$5.10	51	90.6%
Claude Code	$5.49	70	95.2%
OpenClaw	$15.70	81	88.7%
Hermes	$30.14	218	60.3%

完整数据和产物对比：openclacky.com/benchmark

51 个请求 + 90.6% 命中率 → $5.10。218 个请求 + 60.3% 命中率 → $30.14。成本差距的直接原因就两个：请求数和 cache 命中率。

不要忘了，OpenClacky 是一个全功能 Agent：WebUI + 命令行、长期记忆、Skill 技能库、定时任务、IM 接入（飞书/企微/微信）、浏览器自动化、子 Agent、运行时切模型、Skill 自进化与动态加载。

而很多开源 Agent 也许有较好的 Token 消耗，或功能不全，或命中率不高。

在实践中最大的问题是：这些功能里很多跟"高 cache 命中率"是结构性冲突的。

举例：

切模型 → 模型 ID 写在哪？写进 system prompt 就 cache 失效一次。
中途装 skill → skill 列表写在哪？写进 system prompt 就 cache 失效一次。
知道"今天日期" → 写进 system prompt？跨天就失效。
加"读 PDF"能力 → 最容易的实现是再加一个工具 → 工具 schema 变了 → cache 失效面变大，模型选错工具的概率也变大。
上下文不爆 → 最容易的做法是开一次独立 LLM call 做压缩 → 压缩本身 100% miss，压完之后主对话 cache 也凉了。

单看任意一头都不难做：少做功能，命中率自然高；不管账单，功能可以堆得很猛。难的是两头同时做。这篇文章讲我们在每个冲突点上具体怎么取舍。

效果已经不是当前 Agent 的主要矛盾，成本才是。

起步：两年失败史

第三代之前还有两代，失败的很严重。但我感觉现在还有很多人在踩坑，估计很多人有争议，但我 100% 站我自己的观点。

第一代（2024-2025 上半）：RAG / 知识库

把用户 codebase、文档、历史会话全 embedding 进向量库，hybrid 检索 + 重排 + query rewrite。Agent 流程是"先查上下文，再答"。

实际跑下来的问题：

成本高，每次更新的 codebase，需要同步更新向量，实时性无法保证。
准确率有限，例如听起来 90% 的召回率是不是还不错，但是对不起，不仅没有用，还可能有害，我预测，97% 的召回率可能才刚刚够用。
多了一个会失败的部件（向量库），增加了很多延迟。

结论：千万不要搞任何 RAG、知识库分片。如果你要上 Agent，请直接上 Agent，外加一个适合 AI 去阅读的网站就可以了。（参考我们自反思 Skill product-help 的实现）

第二代（2025 中期）：SWEBench / 多 Agent 工作流

Planner / Coder / Reviewer / Tester 各一个 agent，消息总线 + 角色 prompt 编排。

实际跑下来的问题：

每个 sub-agent 各有 system prompt，各有 cache 命名空间。Agent 间交接靠消息序列化状态，每次交接 = 一次 cache miss。
一个单 agent 4 分钟能完成的任务，多 agent 编排到 14 分钟，成本 6×。
SWEBench 分数能刷上去，但榜单跑分跟用户实际感受脱节得很厉害。

结论：

不要做工作流编排。 多 Agent 在结构上就是 cache 灾难。人类的分工不对 AI 有任何价值。AI 是万能的。
不要被 benchmark 绑架。 模型每 6 个月跨一个台阶，用今天的二流模型 + 工作流堆出来的分数，会被半年后顶级模型 + 朴素 harness 直接抹平。把工程预算花在 harness 上，不要花在编排上。对 Agent 工程来说，Benchmark 本身也并不重要，一个朴素的 Agent 思想打败一切：站在 AI 的角度思考你的上下文。

第三代（2025 年底至今）

Ruby 从零重写，4 个月。围绕"cache 局部性"和"工具集稳定性"来组织。后面讲的所有决策都属于这一代。

核心决策 1：双 cache 标记 + 允许失败回退

OpenClacky 同时跑在 Claude / OpenAI 兼容这两条主线上，两边的 prompt cache 行为不同，但工程上我们只关心一个共性：cache 是按"前缀"匹配的——前缀里改一个字节，从那里往后全部失效。

所以前缀的"层次"和"标记位置"，决定了你下一轮还能 hit 到哪里。我们把请求前缀分成几段考虑：

session-stable 段：system prompt、工具 schema。session 内绝不变。
append-only 段：历史消息。只追加、不修改。
session-volatile 段：当前轮新消息（用户输入、工具结果、模型回复）。

前两段交给"系统提示词层"的天然断点，后续每轮都能 hit。真正需要工程的是"append-only 段"——它每轮都在长尾部，标记打哪儿、打几个，决定了下一轮还认不认得它。

朴素做法为什么不够

最直觉的做法是"每轮在 messages 末尾打一个 marker"。它在以下场景都会失效：

history 单调追加：第 N 轮在 messages[-1] 打 marker，第 N+1 轮 messages 又长了一条，原 marker 的位置内容已经不一样了——服务端找不到匹配，整段 history 上 cache miss。
模型回退一次工具调用：工具报错、用户 Ctrl-C 重试、或者模型自己决定换一种 tool call——这一刻"原本的最后一条"被丢弃，单 marker 直接作废。
运行时切模型：用户在 session 中途从 Sonnet 切到 Opus，请求路由到新 endpoint，最理想情况下我们希望两个模型共享尽可能多的前缀。任何不必要的 marker 抖动都会让"切换"成为新的 cache miss 事件。

我们一开始就栽在 (1) 上。修复链能从 git log 里看出节奏：

8ff66cc fix: cache
6ea99fe fix: prompt cache
e9a3602 feat: prompt cache works fine
7734c97 feat: try 2 point cache

前三个 commit 是逐步逼近，最后一个是结构性正解。

双标记是怎么工作的

每轮我们标两条连续消息，不是一条：

第 N 轮：    [..., msg_A, msg_B(*), msg_C(*)]
                                ↑       ↑
                          marker 1   marker 2

第 N+1 轮：  [..., msg_A, msg_B(*), msg_C(*), msg_D(*)]
                                ↑       ↑          ↑
                          (仍在)   (仍在)     新 marker

第 N+1 轮发出请求时：

服务端尝试匹配 msg_C 的 marker → 命中到 msg_C 之前的所有内容（system prompt + 工具 + 整段历史除最后一条）。
我们在 msg_D 上加新 marker，建立新的尾部断点供下一轮使用。

这是一个滚动双缓冲：任何时刻都持有两个断点——一个"刚建立的"（写）和一个"上一轮建立的"（读）。下一轮把"读"再读一次，把"写"扔掉，再在新尾部写一个。永远不会出现两个 buffer 同时失效的瞬间。

为什么是 2，不是 3 或 4

主流大模型的 cache 都允许多个标记位（上限不一），但更多并不更好：

每多一个 marker，那一轮就多一次 cache write，按写入费率收。
双标记要解决的失败模式只有一个位置："昔日尾部 / 今日尾部"这个边界。两个 marker 正好覆盖。第三个 marker 落在更靠前的位置，对应的 cache 段在下一轮仍然会被前两个 marker 之一覆盖——它写的是一段永远不会被独立读到的前缀。
标记多了之后，部分 endpoint 上服务端的候选前缀匹配代价也会涨。

简单说：2 是覆盖尾部边界的最小数量，3 多余，4 浪费。

允许失败：单步回退仍然命中

这是双标记的第二个好处，也是当时 7734c97 的真正动机。

模型偶尔需要回退一次 tool call：工具返回错误、用户 Ctrl-C 重试、或者上游 streaming 断了一半。这种情况下"昨天的最后一条"被丢弃了，但倒数第二个 marker 通常仍然落在仍存在的消息上——单步回退后还能命中。

单 marker 在回退时直接作废；双标记是能扛住单步回退的最小数量。我们没继续往上加（三标记也能扛两步回退，但成本不划算）——回退超过一步的概率已经低到可以接受全 miss 一次。

模型切换：为什么要 marker 不动

OpenClacky 支持在 session 中途换模型。工程上要保证两件事：

新模型的请求前缀和老模型尽量一致。 我们不在 system prompt 里写当前模型 ID（写在 [session context] 块里，见决策 2），换模型不动 system prompt。
marker 位置不变。 切完模型的下一轮，前两个 marker 落在和切换前完全相同的 message 上。新 endpoint 第一次请求会因为"换了上游账号 / 区域"产生一次 cache write，但前缀的几何结构是连续的，warm-up 只发生一轮。

这个细节不做的话，每次切模型一定要都要付完整 cache 重建的钱，用户会很不开心。

不能标的位置

marker 选择逻辑里有一条硬规则：跳过 system_injected: true 的消息。

[session context] 块就是典型例子——它是一次性信息，下一轮尾部已经变了，落在它身上的 marker 是一笔永远读不回来的写入。压缩指令注入也是同样的处理（决策 5 会展开）。

marker 选择从尾部往前走，system_injected 的跳过，凑够两个真实对话消息为止。

本节总结

system prompt + 工具 schema：靠 system prompt 段的天然断点 hit。
history 滚动：靠双标记。
单步回退：靠双标记容错。
模型切换：靠"动态信息不写进 system prompt"+ marker 位置不变。

把这四件事同时做到，普通一轮的 cache 命中率才有可能稳定在 95%+。前三件是 cache 几何，第四件是设计纪律。

决策 2：永不变的 system prompt

OpenClacky 的 system prompt 在 session 启动时一次性构建，之后字节冻结。 任何"想往 system prompt 里塞动态信息"的需求，必须重定向到别的位置。

这条纪律是 cache 命中率的第一道地基——system prompt 一变，后面所有 cache 全废，没有任何"局部修补"能挽回。

但日常跑下来，至少有四类信息"天然想插入到 system prompt"：

当前时间、当前工作目录、操作系统——模型需要这些来生成正确的命令和路径。
当前模型 ID——模型知道自己是谁有助于自适应行为。
用户装了新 skill——模型需要看到新的 skill 名称和描述才能调用。
用户更新了 USER.md / SOUL.md——agent 的人格和用户偏好发生了变化。

这四类信息都是"session 中途可能变"的。如果写进 system prompt，任何一次变更都意味着全量 cache 失效。

[session context] 块

我们的做法是把这些信息写进 message 流，而非 system prompt。每当环境发生模型需要感知的变化时（跨天、切模型、切工作目录），agent 在 history 里追加一条 user 角色的消息：

[Session context: Today is 2026-05-13, Tuesday. Current model: claude-sonnet-4-6.
OS: macOS. Working directory: /Users/.../project]

这条消息被标记为 system_injected: true。它不会被 cache marker 选中（决策 1 已经讲过），不会被算作真实用户轮数，压缩时也不会被原样搬进新历史。

注入是按日期 gate 的：同一天内只注入一条。跨天了，插一条新的。切了模型，插一条新的。大多数 session 里你只会看到一条 session context 块。

这个设计踩过的坑

第一版 inject_session_context 是在 agent 构造期就急切注入的。结果 @history.empty? 返回 false，run() 误以为是后续轮，跳过了 system prompt 的构建——第一次请求带着一条"today is Tuesday"但没有 system prompt 就发出去了。agent 的行为诡异了大约一天才定位到。

修复只有一行：等 system prompt 构建完毕之后再注入。代码里有一段注释记录了这个约束：

# IMPORTANT: Skip injection when the system prompt hasn't been built yet.
# Otherwise, appending a user message to an empty history makes
# @history.empty? false, which causes run() to skip building the
# system prompt entirely.

教训是：前缀的组装顺序比前缀的内容更要紧。 你可以花大力气设计每一段的内容，但只要组装顺序错一步，整个 cache 策略就是废的。

Skill 列表怎么处理

Skill 列表是最容易跟"永不变的 system prompt"冲突的需求。用户可以随时装新 skill，模型需要看到 skill 名和描述才能通过 invoke_skill 去调用它。

我们的取舍：skill 列表在 session 启动时渲染进 system prompt，之后冻结。 session 中途装的新 skill，模型在当前 session 里看不到——它会看到一条 [session context] 通告说"skill 列表已更新，新 skill 从下一个 session 可用"。

这意味着用户装完 skill 想立刻用会发现用不了，要开新 session。我们接受这个摩擦，因为替代方案是重渲染 system prompt 导致全量 cache 失效——这个代价打到所有用户的所有 session 的每一轮上。装 skill 是低频操作，cache 命中是每轮都在享受的收益，取舍方向很清楚。

USER.md / SOUL.md 的更新也是同样的处理：session 启动时读取，session 内不再变。

但是，在用户体验上，我们虽然降低了一些 Skill 发现的概率，但一旦用户主动提起新的 skill 时，我们系统仍能及时发现新 Skill。没有任何缓存，每次都会重建 Skill 列表。

决策 3：invoke_skill 的妙用

invoke_skill 是 OpenClacky 的 16 个工具之一，它是整个 OpenClacky 最核心的设计，花费的时间也最多，它提供 Skill 热加载能力，子 Agent 架构支持，记忆召回能力、Skill 进化能力，但它只占 system prompt 不超过 200 个 Token。

启动子 agent。
子 agent 用的工具集跟主 agent 完全相同（16 个）。它不是一个"精简版"，它能做主 agent 能做的一切事情。
子 agent 执行完后，把结果文本返回给主 agent，主 agent 的 history 里只看到"invoke_skill → 结果"这一对消息。

这个设计一口气解决了好几个问题：

子 agent = 状态隔离

做代码审查的 skill 可能需要读几十个文件、跑 grep、输出长篇分析。如果这些中间步骤都在主 agent 的 history 里，history 会膨胀得很快——cache 命中率没变，但上下文总量上去了，压缩触发得更早，成本更高。

子 agent 把这些中间过程隔离在自己的 session 里。主 agent 只看到最终结论。主 agent 的 history 没有被污染。

动态加载 Skill，不改 system prompt

装新 skill 的流程就是把一个 SKILL.md 放到 ~/.clacky/skills/<name>/ 或 .clacky/skills/<name>/ 下。skill 列表渲染进 system prompt 的时间点是 session 启动，决策 2 已经讲过。

但 invoke_skill 这个工具本身是始终存在的——它不需要 system prompt 里列出所有 skill 才能调用。模型可以通过 [session context] 通告知道新 skill 的名称，然后直接 invoke_skill(skill_name: "xxx")。Skill 的 SKILL.md 是在调用那一刻才读取的，不是预编译进 system prompt 的。

所以"动态加载 skill"这个能力，实际上是 invoke_skill 的运行时读取 + [session context] 的通告组合出来的。不需要改 system prompt，不需要改工具列表，不需要重启 session。

Skill 注入与路径处理

每个 skill 的 SKILL.md 可以引用相对路径的资源文件（模板、配置等）。invoke_skill 在启动子 agent 之前会把 skill 的目录作为上下文路径注入，子 agent 能用 file_reader、glob 直接读到 skill 附带的资源。

这让 skill 可以做到"自包含"——一个 skill zip 包里既有指令又有模板，装上就能用。

加密 Skill 与选择性落盘

部分 skill 包含商业敏感内容（客户的 prompt 策略、内部流程等）。OpenClacky 支持对 SKILL.md 做加密存储，运行时解密到内存、用完不落盘。同时 session 的落盘也是选择性的——对于涉及加密 skill 的 session，可以配置为不持久化到磁盘，只在内存中存在。

这不是 cache 工程的范畴，但它是 invoke_skill 架构的延伸：因为子 agent 的状态是隔离的，选择性不落盘可以精确到某次 skill 调用，而不需要把整个 session 的落盘关掉。

决策 4：控制稳定可靠的工具集 16 个

工具 schema 紧贴 system prompt 之后，在 cache 前缀里。schema 一变，后面全失效。这意味着：每多加一个工具，你不只是多了一份 schema 的 token 成本，你还多了一份"下次改工具时全量 cache 失效"的风险面。

另一面，工具太少也有代价：模型本来一步能做完的事，现在要分两三步（先调一个通用工具获取信息，再调另一个来操作），轮次上去了，每轮都要付 cache 和 output 的钱。

所以这不是一个"越少越好"的问题，而是一个经验平衡点。我们的答案是 16 个。

这 16 个分别是什么

类别	工具	说明
文件读写	`file_reader`, `write`, `edit`	读、写、搜索替换
代码搜索	`glob`, `grep`	文件查找 + 内容搜索
执行	`terminal`	shell 命令
浏览器	`browser`	接管 Chrome/Edge
网络	`web_search`, `web_fetch`	搜索 + 抓取网页内容
任务管理	`todo_manager`, `list_tasks`, `undo_task`, `redo_task`	规划、撤销、重做
交互	`request_user_feedback`	需要用户输入时
扩展	`invoke_skill`	调用 skill（决策 3）
安全	`trash_manager`	安全删除（rm → trash）

设计原则

简化参数。 每个工具的参数尽量少、语义尽量明确。比如 glob 只要 pattern 和 base_path，不需要模型去组合 --include / --exclude / --type 这些 flag。参数越多，模型出错的概率越高，出错就要重试，重试就是成本。

够用但不冗余。 glob 和 grep 是两个工具而不是一个：glob 负责"哪些文件匹配"，grep 负责"文件里哪些行匹配"。合成一个会让参数变复杂，模型调错的概率上升。但也没有继续拆成 find_files / list_dir / tree 三个——glob 一个就能覆盖这三个场景。

为每个工具写丰富的测试用例。 工具是 agent 跟外部世界的接口，一个工具出 bug 的代价远高于普通代码出 bug——它会让模型产生错误的观察，进而做出错误的决策，进而需要更多轮次来纠正。我们一共有 1600+ 的用例去覆盖各种场景的处理。最近有朋友给我们提交了子项目扫描慢（对，OpenClacky 支持子项目处理）的一个相关优化 issue。

为什么不是 10 个，也不是 25 个

10 个做不到。undo_task / redo_task / list_tasks 这些看起来"可以不要"的工具，拿掉之后模型就只能用 terminal 跑 git 来处理代码回滚——成功率远低于专用工具，而且 git 操作的副作用很难控制。很多工具设计了一个 code_run，我们并不推荐，实测反而导致任务变慢（需要写长代码），轮次变多（多次尝试）。

不需要 40+，只需要 16 个。

省掉的能力	替代方式	工具数节省
代码库分析专用工具	code-explorer Skill	~5 个
记忆读写专用工具	recall-memory Skill	~3 个
浏览器自动化（多动作拆分为多工具）	单一 browser 工具统一覆盖	~8 个
Sub-agent 编排工具	invoke_skill 统一入口	~6 个
定时任务管理工具	cron-task-creator Skill	~4 个

如果以后需要第 17 个，我们会加。4 个月了，还没加。

决策 5：压缩——不换模型、空闲时做、压到底

上下文窗口是有限的。不管 200K 还是 1M，长任务跑下来总会填满。填满之前必须压缩，否则要么截断丢信息，要么溢出直接报错。

压缩是 cache 命中率最大的单点威胁：老的消息被替换成一段摘要，前缀从那一刻起就跟之前不一样了——必然 cache miss。但压缩不可避免，所以问题不是"要不要压"，而是"怎么把压缩的破坏降到最低"。

结论一：不要换模型压缩

很多 agent 的压缩流程是开一个独立的 LLM call，用一个便宜/快速的小模型来做摘要。

问题：

独立 call 的 system prompt 跟主 session 不一样（通常是"你是一个摘要助手"），跟主 session 的 cache 没有任何共享前缀，压缩本身就是一次 100% cache miss。
压缩完之后，主 session 的 history 被替换了（老消息变成了摘要），主 session 的 cache 也跟着失效——接下来 4–5 轮跑在 cold 费率上。

等于你为每次压缩付了两笔钱：一笔给压缩 call 本身的 cache miss，一笔给主 session 压缩后的 cold-warm 阶段。

我们的做法：压缩不开独立 call，而是把压缩指令作为一条消息插进当前对话的末尾（Insert-then-Compress）。

这条指令被打上 system_injected: true，走正常请求路径。效果：

压缩 call 命中现有 cache：同样的 system prompt、同样的 tools、同样的 history 前缀。只有尾部的压缩指令是 cold 的，几百 token。
压缩完成后，重建 history：[system_prompt, summary, last_N_messages]。这一刻 cache 确实会 miss 一次——但只 miss 一轮，从第二轮开始双标记重新接管。

对比（一次 50K-token 会话的压缩事件）：

	独立 call 方案	Insert-then-Compress
压缩 call 的 cache hit	0%	~95%
压缩期间 cold token	~50,000	~500
主 session cold-warm 轮数	4–5	1

结论二：20–30 万 token 是压缩的甜区

太早压：浪费了上下文里还有价值的细节，摘要丢信息。太晚压：上下文太长导致模型注意力分散、推理变慢、输出质量下降。

我们测过多个阈值。20–30 万 token 是效果和成本的甜区——模型还能有效利用上下文，但离溢出还有足够余量来完成压缩本身。

压缩后无论如何会压到 1 万 token 以内。这不是省钱，这是控制后续每一轮的 baseline 成本——history 越短，每轮 input 越少，cache miss 时的惩罚也越小。

结论三：空闲第 3 分钟启动压缩

这是跟 cache TTL 的博弈。大模型厂商的 prompt cache 普遍有 TTL——cache 在一段时间无请求后会过期。过期之后下一轮的 input 是全量 cold，直接翻到 10× 成本。而且后续每轮都在叠加成本，直到 cache 重新 warm 起来。

所以我们跑了一个空闲计时器（idle_compression_timer.rb）：

用户停止输入 90 秒后开始检查。
如果 history 已经接近压缩阈值 → 立刻触发压缩。此时 cache 还是热的，压缩代价很低。
压缩完之后，新的短 history 在 TTL 过期前就建立了新的 cache 断点。

效果是：用户思考了几分钟回来，看到的是一个已经压缩好、cache 已经 warm的 session。相比之下，如果不做空闲压缩，用户回来时面对的是一个 cache 过期的长 history——那一轮的 input 可能是 30 万 token 全量付费。单这一个行为，在长思考间隔的场景下就能省 10× 的钱。

空闲计时器跑在后台线程里。记得加锁！

百万上下文的真相

"百万 token 上下文"听起来很性感，但做 agent 有两个现实：

过长的上下文对模型效果并不总是正面的。 模型在超长上下文里的注意力分散问题是已知的——关键信息被淹没在大量历史里，输出质量反而下降。
你真不一定用得起。 记住，模型每轮都要把上一轮所有的上下文全部带上。100 万 token 的 input，即使全部 cache hit（0.1× 费率），一轮也要付 10 万 token 等价的钱。如果 cache miss 了一次，那就是 100 万 token 全价。

真实世界用户停下来思考太过于常见，Cache Missing 太容易发生，Agent 开发者必须想办法帮用户减少开销。

所以我们的策略不是"尽量用满上下文"，而是"积极压缩，保持 history 短小"。1 万 token 的压缩后 history + 95% cache hit，比 100 万 token 的未压缩 history + 99% cache hit 便宜得多，效果也更可控。

如何确保压缩后仍然保证足够好的效果，这是另一个话题，我们后面展开。

决策 6：自进化的工具能力

PDF、Excel、Word、PPT 的阅读和解析是 Agent 经常遇到的需求。处理这类文件通常有两种路径：

内置一个 tool：比如 read_pdf、read_excel。好处是开箱即用，坏处是每个格式一个工具，工具列表膨胀（违背决策 4），而且解析库的依赖链往往需要 C 扩展，装起来就不"零痛"了。
做成 skill 让用户装：对用户来说不友好——遇到一个 PDF 还得先去装 skill，体验断裂。而且 skill 描述怎么写、什么时候触发，AI 效果不可控。

我们选了第三种路径：首次安装时把预设的文档处理脚本 copy 到用户目录，之后允许 AI 自行更新维护这些脚本。

具体做法：

首装 OpenClacky 时，onboard skill 会把一组 Python 脚本（PDF 解析、Excel 读取、OCR 等）copy 到 ~/.clacky/scripts/。
这些脚本不是 Ruby，而是 Python 3。原因很实际：Python 的文档处理生态（pdfplumber、openpyxl、python-docx、python-pptx）是当前最成熟的，OCR 方面 pytesseract / paddleocr 也远比 Ruby 生态完善。
当 agent 需要读一个 PDF 时，它不调一个专用 tool——它用 terminal 工具跑 python3 ~/.clacky/scripts/read_pdf.py <file>。工具列表没有增加。
如果脚本跑不过去（缺依赖、格式变了），agent 可以直接 write 修改脚本、terminal 跑 pip install 装依赖。下次再遇到同类文件就不会出问题了。

这就是"自进化"的含义：处理文档的能力不是写死在 gem 里的，它活在用户目录的脚本里，agent 自己可以维护。 第一次可能需要装个 pdfplumber，装完之后就是永久能力。

这个设计把"文档处理"从工具层面拉到了脚本层面，避免了工具列表膨胀，也避免了硬编码 C 扩展依赖。trade-off 是用户机器上需要有 Python 3——但 macOS 和大多数 Linux 发行版默认自带，这个前提在实际用户群里几乎都满足。

决策 7：内置浏览器工具，No Headless

浏览器自动化是 Agent 越来越重要的能力——验证前端改动、抓取文档、自动化测试流程。

市面上主流的做法有两种：

Headless 浏览器（Puppeteer / Playwright）：agent 启一个无头浏览器实例，完全在后台跑。
外接 MCP：通过 MCP 协议连接一个外部浏览器服务，agent 发 JSON-RPC 指令。

我们两种都不用，或者说——我们自己内置了一个 MCP Client，去接管用户已经在跑的 Chrome / Edge。

为什么不用 Headless

Headless 浏览器的问题是"看不见"。agent 操作的页面用户看不到、不知道 agent 在干什么、出了问题也无法判断。对于 Agent 的使用场景——用户在旁边盯着 agent 干活——"看不见"是很大的信任问题。

另外，Headless 经常遇到反爬检测：登录态拿不到、Cloudflare challenge 过不去、需要手动验证。用户自己的浏览器里已经登录好了、cookie 都在，为什么不直接用？

我们怎么做的

lib/clacky/tools/browser.rb（610 行）+ lib/clacky/server/browser_manager.rb 是整套实现。架构是：

用户的 Chrome / Edge 开启 Remote Debugging 端口（一次性配置，browser-setup skill 引导完成）。
OpenClacky 内置一个 MCP Client，通过 stdio JSON-RPC 2.0 连接 chrome-devtools-mcp 这个 daemon。
daemon 进程首次调用时启动，后续跨多次 tool call 保持存活。
browser 工具对外暴露的是高层语义动作：snapshot、click、type、navigate、screenshot 等——不是底层 CDP 指令。

对模型来说，"浏览器"就是 16 个工具里的 1 个，schema 跟其他工具一样稳定，不会因为浏览器的状态变化而改 schema。 这符合决策 4 的原则。

为什么不把浏览器做成外部 MCP

我们可以不内置浏览器、让用户自己配一个 Browser MCP 服务。但这样做的问题是：

用户体验差：装 agent 之外还要装 MCP 服务、配端口、配认证。
稳定性不可控：外部 MCP 的版本、协议兼容性、超时行为都不在我们手里。
工具 schema 不可控：外部 MCP 可能暴露几十个细粒度工具（page.click、page.evaluate、page.waitForSelector……），直接打进主 agent 的 tool list 就违背了决策 4。

内置一层封装的代价是我们要自己维护 MCP Client 和 daemon 的生命周期管理——browser_manager.rb 里处理了 daemon 启动、心跳检测、超时、crash recovery。但这个代价是一次性的工程投入，换来的是用户零配置（只要 Chrome 在跑）和工具列表的稳定。

最后，选择 Ruby 的理由

这不是一个显而易见的选择。LLM agent 生态里 Python 和 TypeScript 是主流，Ruby 几乎没有前例。但我们选 Ruby，而且选对了。

动态语言 + 元编程

Ruby 的元编程能力是我们实现 Skill 自进化、动态加载、工具注册等能力的基础。method_missing、define_method、class_eval 这些能力让运行时的行为修改非常自然。Python 也有类似能力，但 Ruby 在这一层的表达力明显更高。

对于一个"agent 自己可能改自己的辅助脚本"的系统来说，动态语言比静态语言更合适——你不需要重编译、不需要重启，改了就生效。

极致的分发能力

gem install openclacky 一行搞定。RubyGems 的分发链路非常成熟：版本管理、依赖解析、全局可执行文件注册（clacky 命令）都是开箱即用的。用户不需要 clone 仓库、不需要 npm install、不需要 pip 虚拟环境。

对比 Python 的分发——pip install + 虚拟环境 + 可能的 C 扩展编译——Ruby gem 的安装体验明显更丝滑。

零 C 库依赖

这是我们做了大量工程投入才做到的。看 openclacky.gemspec 的依赖列表：

faraday, thor, tty-prompt, tty-spinner, diffy, pastel,
tty-screen, tty-markdown, base64, logger, websocket,
webrick, artii, rubyzip, rouge, chunky_png

全部是纯 Ruby gem，没有一个需要编译 C 扩展。

这意味着在 macOS / Linux 上，只要有 Ruby（2.6+），gem install openclacky 就能装上、立刻能跑。不需要 brew install libxml2，不需要 apt-get install libffi-dev，不需要 Xcode Command Line Tools。

为了做到这一点，我们做了一些反常规的选择：

WebSocket：没有用 websocket-driver（需要 C 扩展做 UTF-8 校验），而是用了纯 Ruby 的 websocket gem。性能差一点点，但对 agent 场景来说完全够用，换来的是安装零阻力。
LLM 接口调用：完全零依赖，没有用任何第三方 LLM SDK（anthropic-rb、ruby-openai 等都没用）。直接用 faraday 做 HTTP，自己处理 streaming、tool_use 协议、cache_control 注入。这样我们对请求格式有完全的控制权——决策 1 的双标记就是在 client.rb 里直接操作 cache_control 字段实现的。
TUI：没有用 curses（C 扩展），直接用 tty-screen + ANSI escape code "画"出整个终端界面。

这一切是 AI Coding 的产物

说实话，"从零重写 WebSocket 客户端"、"从零实现 LLM streaming 协议"、"用 ANSI escape code 手画 TUI"——这些事情如果纯手写，工程量很大，这在以往完全不现实。

但 OpenClacky 本身就是一个 AI coding agent。这些"为了极致安装体验而大胆从零重写依赖"的决策，是用 OpenClacky 自己来完成的。一个能写代码的 agent 让"零依赖"从不切实际变成了可执行。这是一个自举的过程——产品帮助自己变得更好。

结语

回头看这 7 个决策，它们背后其实只有一句话：把工程预算花在 harness 上，把智能预算留给模型。

不做 RAG，不做多 Agent 编排，不做工具堆叠——不是因为这些东西没用，而是因为模型在快速变好。半年前需要 4 个 agent 协作才能勉强通过的任务，今天一个 agent + 一个好的 harness 就能做得更快更便宜。

我们选择把精力放在那些不会随模型进步而过时的事情上：cache 命中率、工具稳定性、安装体验、压缩策略。这些是 harness 层面的基础设施，不管模型换到哪一代都用得上。

如果这篇对你有用，请帮我们点赞，欢迎 PR。欢迎转发和分享。

OpenClacky 完全开源，MIT 协议：github.com/clacky-ai/openclacky

gem install openclacky 一行装完即用，不需要 Docker、不需要 clone 仓库。如果你也在做 Agent，欢迎试试，遇到问题直接开 issue 聊。

4 家 Agent 横评的完整数据、产物对比、录像回放：openclacky.com/benchmark

本文引用的核心代码：Cache 标记 · Insert-then-Compress · Session context 注入 · 空闲压缩 · 浏览器工具

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 —— 每一篇都是这种干货。

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

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

分享一个 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 和满满的乐趣。😎

学 Ruby 和想创业的朋友看过来，ClackyAI 产品研发成功，15 分钟 Vibe 一个超强的全功能的 Rails 项目

lyfi2003 — Wed, 26 Nov 2025 18:45:45 +0800

大家好，我是 ClackyAI 的创始人李亚飞，一个 Ruby 社区老玩家。

7 月大家如果去过成都 RubyConf China 2025 活动的话，可能看到我现场演示了一个 Rails 博客系统的从零生成，大家还蛮兴奋的，现在，这一切正在以更快的速度在迁移编程范式。

今天，我想给大家分享下 ClackyAI 最新的进展。

一句话总结：ClackyAI 受益于 Rails 架构支持，目前已经达到了生产级项目生成能力。无须技术，即可完成商业级 APP 的开发。

废话少说，我们来看真正实战及效果

我们来看一个创业想法（这是源自 7-8 月份一个投资人背景的女性创业者的想法，她反复试了 N 多个平台都很不顺利)：

开发一个 web 应用，用户登录注册后，帮用户进行命座运势分析的系统，接入大模型。免费用户只能用 3 次，付费 19.9 用户可以解锁使用 20 次（每月重置）做完好，绑定自己的域名，全球发布，再做一些引流，用户有付费需求动机的。我们做一些塔罗牌类的、MBTI、紫微星之类的有很多玩法。

像这样一个需求，不管是多厉害的技术高手，也要考虑第三方登录管理、大模型对接、支付系统设计，都是一件件非常有挑战的事件，我们问过一些外包公司，他们的报价是这样的：

人员需求：5 个（前端、后端、设计、产品、项目），周期：1-2 个月，报价：10 万。

现在是布署上线的成品： https://direct-krill.clackyai.app/ （有 demo 账号，可深入体验），花费时长 1 小时，花费 10 美金，在项目开始前就可以选择 12 种 UI，又可以随时定义自己的风格。

效果视频：https://assetscdn.clacky.ai/admin/showcases/celestial_fortune_1111.mp4

拥有的功能有：

完善的用户认证系统（邮件服务、自由定制 UI、功能、加第三方登录，所有免配置）
支付系统（Stripe 全球支付，在生产发布前采用真实支付的沙盒模式）
大模型调用（极致用户体验，支持流式输出）

全功能，免配置，接入支付，全球布署和自定义域名，仅仅需要 2 分钟即可出 DEMO 效果页，15 分钟完成全部功能。

Clacky 真的能完成生产级交付吗？我们用更多真实的案例来展现：

一个 AI 文案及图片生成平台（支持文案生成、图片搜索、图片生成）

https://assetscdn.clacky.ai/admin/showcases/ai_writing_assistant_1112.mp4

https://good-sturgeon.clackyai.app/

一个在线课件销售系统（将上海小学的课件销售给北美家长）

https://assetscdn.clacky.ai/admin/showcases/course_store_1112.mp4

https://discrete-spaniel.clackyai.app/

还有很多真实项目案例，在线产品销售系统（https://main-bream.clackyai.app/Logo)、生成系统（https://loved-haddock.clackyai.app/）等等。

From HelloWorld to IPO，Clacky 让你第一天就准备好生产环境级的 0-1，和 1-N 产品迭代能力。经过我们内部多次试验，和外部朋友们的真实体验，100 美金以内就足以完成一个生产级项目。

ClackyAI 为什么能达到生产级代码生成能力？在长达一年的打磨中，我们做了以下的努力：

第一，从一开始我们就以真实后端框架支持为第一优先级，ClackyAI CDE（云端开发环境）可以真实启动 Rails、NextJS、Django 等先进的全栈级开发框架，是全球少有的敢用 No Supabase 架构 AICoding 端对端生成能力，能响应真实复杂的技术需求。我们在 Auth/LLM/AsyncJob/FileUpload/WS 均有深度的针对 AI 的优化，确保在真实应用需求面前有良好的表现。

第二，全栈自研的 AIAgent 方案，经过三代（编排架构 → 多角色 Plan 架构 → TODO+SubAgent 架构）的迭代，在需求理解、任务执行速度、成本上均接近世界顶级 CodeAgent 表现力，在全栈生成综合性能上甚至超过某 30 亿美金估值公司的效果。例如在支付集成上，对方连续 5 次反馈无法成功处理，而 Clacky 一般 1 次成功，最多不超过 2 次。

第三，快速响应能力，我们保持每周至少一次的发布节奏，每周处理 5 项以上的客户反馈意见，例如最近两个月我们支持了多种社交化登录能力、增加了 20 余种第三方集成能力、改进了布署速度、增强了前端 UI 的控制能力。

这是一个新的时代，是 CodeAgent 真真正正帮助到每位创业者的新时刻，利好具备商业赚钱思考的创业者。一个个细分方向的真实需求，给小学教师生成配诗图与动画、为律师行业构建案例追踪、为四十万港漂教育提供中小学教育信息等等等等，都可能让一个真正的创业者挣到几十甚至上百万收入。

创业者建议

我看到咱们社区有不少新人在学习 Ruby 和 Rails，我仍然强力推荐学好 Rails，它是我看到在 AICoding 时代最强力的中小型应用开发神器。

在 AI 时代，创业已经是单兵最强的时刻，不要轻易招聘、直面市场、相信直觉、做自己有热情的事。

ClackyAI 如何使用、怎么申请账号？

Clacky 面向全球化运营，目前已经全线放开注册，并且对中国用户有很大的友好性，我们有全球加速国内用户访问，支持支付宝等。所以首先准备好你的电脑，把网络搞好。

没有内测等待、没有夸大的宣传，只有真实的 AI 效果，不信你就试试。

第一，无须技术背景，只需要一个浏览器，电脑端访问 https://clacky.ai ，之后直接注册账号即可（邮箱、google、github 登录均可）

第二，自动获得价值 $10 美元 1000 Credits，输入你的创业需求即可（开箱即用，什么都不需要准备，如果你的应用想要支付接入，建议提前注册一个 Stripe 账号，等布署前填入即可）

第三，尽情开始吧，如果觉得不错，可以充值升级，如果你真的要创造一个商业化产品，大约需要 70-200 美金左右。推荐 PRO 版本性价比最好。

招募运营负责人

最后，我们正在招募一位 Clacky 产品全球化运营的运营负责人，如果你具备以下要求：

强执行力，能够独立推进项目达成目标，有国际化产品经验
2-3 年产品运营经验，有 SaaS/开发者工具背景优先
有过产品海外运营的能力，对海外产品有深度认识和见解
有海外留学或工作经历，英语六级以上，具备流利的口语和书面表达能力
优秀的跨文化沟通能力和数据分析能力
熟悉开发者群体需求和使用习惯

如果你觉得你的实力很强，苦于没有一款优秀的 AI 产品提供强有力的 aha 时刻和留存付费能力，你的运营才华正在被浪费，那我们也许是非常合适的伙伴，欢迎投递简历深入交流。我们有充分的运营预算和匹配市场能力的待遇等待你的参与。

Base 城市：深圳。

HR 邮箱：hr@dao42.com

【帮发】【兼职 + 远程】奇绩创坛招聘全栈工程师 2~3 名，时薪 200 元+

lyfi2003 — Mon, 10 Mar 2025 17:57:45 +0800

奇绩创坛招聘全栈工程师（兼职 + 远程）计划招聘人数：2-3 人薪资待遇：¥200/小时左右，具体数字可在第二轮面试和负责人聊，第一轮是技术面（限时 6 小时做一个小项目，涉及前后端和数据库）

奇绩创坛是我们的天使轮股东，在早期技术类创投做的非常不错，打造了一个技术项目社区，有自研技术需求，也一直在用 Ruby on Rails，所以推荐朋友们可以投一下试试。

我们是谁？

奇绩创坛投资加速早期科创企业，目前已经形成国内最大的早期技术项目社区奇绩有自己的技术团队，通过技术提效，帮助到更多的创业者更多信息请访问：https://www.miracleplus.com/about/

招聘岗位

全栈工程师（兼职）（远程）

工作职责

每周兼职工作 10+ 小时
奇绩系统全栈开发，有很多种前后台的产品需要开发

会接触哪些技术： Python, Ruby, Vue.js, React, AWS, 微信小程序，GraphQL, Clickhouse, Superset, Spark, K8s, LLM

工作优势：

工作时间灵活。可以远程，也可以来北京五道口办公
能够接触到不少优秀创业者和项目，有国内最优秀的早期技术创业者社区
与创业一样，练习和见证从 0 到 1 的技术建设

职位要求：

技术动手能力强
有较强的自我驱动力
有很强的技术实战经验

补充：

面试时所用的技术栈和工具不限，但是入职之后至少需要学习使用 Ruby，以及其他必须的后端技能。

联系方式：

如果对以上岗位有兴趣，简历请发至 hiring@miracleplus.com

[深圳][2025 年 3 月 1 日]Ruby 线下技术活动 - AI Coding 专项主题

lyfi2003 — Thu, 20 Feb 2025 18:04:19 +0800

主题

Ruby 线下技术活动 - AI Coding：趋势与应用

活动安排

时间：2025 年 3 月 1 日（周六）下午 14:00 - 17:00

地点：深圳市南山区科发路 19 号华润置地大厦 B 座 13 楼亚马逊云科技

线下规模：限额 20 人

简介

希望聚集一群对 AI 编程感兴趣的小伙伴，搭建一个轻松、开放的交流平台，大家一起聊聊这方面的新技术、新想法，以及未来的发展方向。除 Ruby 外，其他技术圈的伙伴也欢迎加入～

活动流程

主持人开场 14:00 - 14:15
主讲嘉宾分享 14:15 - 16:30（暂定 3-4 位，欢迎报名）
1. 主题：《AI Coding 趋势发展和 ClackyAI 产品介绍》 李亚飞 （ClackyAI 创始人）
2. 主题：《AI Coding 的现在与未来》肖培庆 （亚马逊云科技初创资深解决方案架构师）
自由话题交流 16:30 - 17:00

主讲嘉宾邀请

如果你：

对 AI 编程有深入研究，拥有独到的前沿洞察
主导过 AI 编程相关的项目
热爱分享，愿意推动 AI 编程领域的发展

欢迎加入我们，成为主讲嘉宾！

分享内容非常灵活，你可以：

聊聊 AI 怎么改变开发方式、未来可能会怎么发展
分享你对国内外 AI 编程产品的使用感受，国内产品如何突破崛起
聊聊你用 AI 工具提升效率的经验和踩坑故事等等

报名方式

这次沙龙我们希望保持一个小而精的规模，方便大家更高效地互动和交流，营造轻松交流的氛围。如果你感兴趣的话，欢迎填写报名表单，通过审核的小伙伴会收到报名成功的通知～

主讲嘉宾及与会伙伴报名通道：https://dao-42.feishu.cn/share/base/form/shrcnQMcCgYUntc9CP7fTmRDy8e

会议主题：[深圳]Ruby 线下沙龙 - AI Coding 专项主题

如有任何咨询需要，可添加微信号：sizzychen，备注：沙龙。

感谢联合发起与支持：回流技术团队 & Clacky AI 技术团队，AWS 提供活动场地

面向专业开发者招募天使用户，介绍一位新的 AI 编程产品 Clacky 给大家（优先支持 Ruby on Rails）

lyfi2003 — Fri, 24 Jan 2025 15:09:06 +0800

现在 AI 编程产品如火如荼发展着，Github Copilot、Cursor、Bolt、Devin 一路向前，大家可能都有所接触，或正在使用，除了享受 AI 编程带的好处，但不知大家是否遇到以下问题：

“我发现现在 ai 写代码也挺坑的，以前键盘不小心碰到顶多插入不可运行代码，现在光标放在哪里就提示怎么写，空格插进去就是一整段的无错代码，一不小心掉大坑得了”

“我提出的需求，AI 规划的基本到位，但其中有些代码我不想要了”

“跟 AI 反馈了几次，每次写的都差点意思，我想自己改一改”

AI 编程正在经历：L2（单行）→ L2.5（多行）→ L3（codebase 规划）→ L4（自主行动）这样一个发展过程。

Clacky 正是一个 L3 级别的 Agentic AI CDE（云端开发环境），原生 AIAgent 架构，工程师可控的任务规划与执行，让 AI 代码写的恰到好处。

你思考架构，AI 完成代码。 这是我们认为未来将长期存在的开发模式，也是 Clacky 的产品追求。

我们期望你是一位专业的开发者，在充分了解需求如何实现的前提下，与 Clacky 合作高效完成工作。Clacky 是一个可视化的 AIAgent，它在每一个关键步骤前会支持你去确认，在执行后你可以随时撤回，目前它的水平约等于一个初级工程师，在某些问题上表现出了中级水平，未来 Clacky 将持续进化至中高级水平。

Clacky 提供的开发环境现在支持 web 单体类项目的在线开发与调试（golang、Python、Node、Vue/React、Ruby 等数十种框架及语言），另外内置 Mysql、Postgres、Redis 等中间件，环境一旦构建好，Clacky 同学就像一个真正的助理工程师随时帮你规划需求解决 Bug，任何不满意的改动都可以随时调整。

官方演示：

【L3 Agentic AI CDE，为严肃开发员而生】

实战分享：

【创始人分享利用 Clacky Agentic AI CDE 完成一个 Ruby on Rails 全栈项目的需求开发】

官网地址：

https://clacky.ai

Clacky 与 Cursor、Devin 的对比？

如何使用？

Clacky 目前需要你准备一个项目放在 github 上面（支持私有），授权 Clacky 与 AI 一起构建一个可运行的开发环境，提交你第一个 PR。

第二个 PR 你就可以随时向 Clacky 用自然语言或者按下“#”号导入 github issues 来提出新的需求了。

文字版 Quick Start：https://docs.clacky.ai/getting-started

视频版看我的录像：https://www.bilibili.com/video/BV1rufJYyEsR

首期招募 50 名天使用户，如何申请？

如果你是一名专业的 web 开发者，拥有自己 Github 账户，有自己的项目，就可以申请我们的早期用户权限。

目前我们第一批会在 Golang、Python、Node、Ruby 语言及相关 web 框架等单体应用（内置数据库）开启测试。

也即目前的天使用户要符合以下几个要求：

个人开发者、创业团队、团队 Leader 等一线开发者
拥有自己的 github 项目
属于第一批 Golang、Python、Vue/React、Ruby on Rails 技术栈画像

你可以直接添加我的微信号：lyfi2003

或扫码添加

在确认你符合以上条件下，会接受一个邀请码，注册后即可开始使用。

我们为天使用户准备了以下福利：

3 个月内无限使用 Token
在后续一年内额外每月赠送 2000 AI 积分（正常每个用户 2000 积分）
AICoding 城市活动优先参与权

但同时需要你：

容忍一定的 Bug，乐意反馈使用意见
乐意传播与分享使用体验

我们会在收到申请的 24 小时内完成邀请码发放，本次天使用户有 50 名限额。

欢迎一起参与 AI 编程新方式的探索与交流。

【深圳】ShowMeBug 招聘初中级 Ruby 开发工程师，期待你的到来

lyfi2003 — Mon, 24 Jun 2024 19:29:16 +0800

公司介绍

深圳至简天成科技有限公司成立于 2019 年，旗下产品「ShowMeBug」是一个支持实战编程的技术能力评估平台。2020 年 -2022 年连续完成真格基金、高瓴创投、红杉资本等顶级风投机构 PreA 及 A 轮融资，累计总金额超亿元，是数字化技术招聘领域中的头部企业。

招聘岗位

Ruby 开发工程师（2 名，薪资待遇：12-17K）

岗位职责

负责 ShowMeBug 系统设计，核心代码开发，系统优化等工作；
在复杂模块到子系统级别独当一面，高质量把控相关研发工作的全生命周期；
参与并推动团队基础设施建设，逐步提升研发效率、研发质量，通过技术不断产出驱动业务的发展；
关注前沿技术发展，能够将新知识传递给团队，并且转化到潜在项目中。

岗位要求

统招本科及以上学历，计算机 / 软件工程等相关专业，有后端/服务端研发工作经验；
熟练 Rails 技术栈，包括不限于 Ruby 语言能力，Rails MVC 架构，Webpacker/Turbolinks，Minitest/RSpec 等标准 Rails 技术栈；
熟悉 JavaScript，掌握 Bootstrap/Vue 或 React 等前端框架，HTML/CSS 扎实，能写出良好质量的前端代码；
内心极度热爱 Ruby 和 Rails，期望成为中国 Ruby TOP 的技术高手。（有这样想法并愿意付诸实践的不管能力如何都可以来试一试。）
对人生乐观积极，喜欢有一定挑战的事物，善于待人；
具备 Ruby on Rails 全栈开发的技术能力，能够专业高效完成任务。有一定的创业心态和服务意识。

加分项

Cloud IDE / 协同软件 / SaaS / 互联网背景；
有代码洁癖，对技术有强烈的进取心，了解行业技术发展；
有优质技术产品或开源贡献经验；
博客，GitHub 内容质量较高。

福利待遇

入职提供 Apple MacBook Pro 和大屏显示器，BYOD 发放每月补贴；
公司为员工每年设有 2 次调薪机会；
公司为员工提供公平而广阔的职业晋升通道；
社会福利：公司为员工入职即购买五险一金（一档社保）；
下午茶：每周多次下午茶供给零食、水果、面包、各种饮品等丰富多样的食材；
团建津贴：为增强员工幸福感和团队凝聚力，公司为员工和团队每月设置专项团建经费，鼓励员工和团队开展各种形式的团建活动；
各种奖励：公司会设有各种奖励机制，用以激励员工不断创新成就卓尔不凡的自己；
年终奖。

公司信息

公司名称：深圳至简天成科技有限公司
公司地址：深圳市南山区惠恒大楼一期 301
公司主页：https://www.showmebug.com/
联系邮箱：hr@dao42.com（简历注明来自 RubyChina）

[深圳] 深圳至简天成科技（ShowMeBug）招聘 2 名 Ruby 中级后端开发工程师（15-30K）

lyfi2003 — Mon, 04 Mar 2024 16:55:18 +0800

Ruby 社区各位朋友下午好，我是 ShowMeBug 创始人李亚飞。产品首发至今已经快 5 年时间，感谢各位 Rubyist 的支持。现随着业务发展，我们一起邀请更多热爱技术的人才一起参与 ShowMeBug 的发展。

ShowMeBug 的使命目标

提供工程能力考察和精准高效的技术测评，解决企业与人才筛选的难题。
建立中国一流的技术团队，落实优秀的 CDE（Cloud Development Environment）解决方案

我们的核心技术是基于全栈自研的 CDE（云 IDE 的挑战难度被称为技术工程上的明珠），拥有很强技术基因的产品。

基本要求

学历：统招本科
工作年限：三年以上
薪资待遇：20-30K

岗位职责

负责 showmebug.com 系统设计，核心代码开发，系统优化等工作；
在复杂模块到子系统级别独当一面，高质量把控相关研发工作的全生命周期；
参与并推动团队基础设施建设，逐步提升研发效率、研发质量，通过技术不断产出驱动业务的发展；
关注前沿技术发展，能够将新知识传递给团队，并且转化到潜在项目中。

岗位要求

统招本科及以上学历，计算机 / 软件工程等相关专业，有后端/服务端研发工作经验；
掌握 Ruby / Golang 中的一种或者多种语言，有良好的数据结构和算法基础；
熟悉常见的设计模式并能运用；
良好的设计和编码品味，优秀的工程化和编码能力，模块级别的工作输出品质达到业内一流；
熟练掌握 Ruby on Rails / CloudWeGo ( kitex & hertz) / Gin 等开源框架和中间件；
熟悉 PostgreSQL / MySQL 等主流数据库，精通 SQL 语言，熟练掌握 SQL 常用性能优化技术；
能合理运用后端研发常用技术包括而不限于：存储、缓存、消息、搜索等；
良好的团队沟通能力、协作能力、责任心、自驱力和学习能力；
较好的产品意识，深入参与产品设计 / 讨论，善于规划执行、结果导向。

加分项

Cloud IDE / 协同软件 / SaaS / 互联网背景；
有使用云原生技术 Docker、Kubernetes、Istio 等经验；
有代码洁癖，对技术有强烈的进取心，了解行业技术发展；
有优质技术产品或开源贡献经验。

福利待遇

入职提供 Apple MacBook Pro 和大屏显示器，BYOD 发放每月补贴；
公司为员工每年设有 2 次调薪机会；
公司为员工提供公平而广阔的职业晋升通道；
社会福利：公司为员工入职即购买五险一金（一档社保）；
下午茶：每周多次下午茶供给零食、水果、面包、各种饮品等丰富多样的食材；
学习福利：公司为员工划出图书阅读专区用于员工自我深造和职业技能提升；
团建津贴：为增强员工幸福感和团队凝聚力，公司为员工和团队每月设置专项团建经费，鼓励员工和团队开展各种形式的团建活动；
各种奖励：公司会设有各种奖励机制，用以激励员工不断创新成就卓尔不凡的自己。
优秀员工设有年终奖 2-4 个月
重大贡献超 10W 大奖

简历请投递至：hr@dao42.com，或直接加我微信我帮拉群：lyfi2003（微信号）

高级岗位见：https://ruby-china.org/topics/43608

[深圳] ShowMeBug 招聘 Ruby 中高级工程师 2-3 名

lyfi2003 — Wed, 19 Jul 2023 19:34:38 +0800

Hi，Ruby 社区各位朋友大家好，我是 ShowMeBug 创始人亚飞，可能不少朋友都认识。在这里我介绍一下 ShowMeBug 现在做的一些事情。

ShowMeBug 发展了 3 年多，目前是 2.0 版本，用 Ruby on Rails 全栈打造了一个基于轻协同 IDE 环境的技术能力评估（TSA）系统，通俗说，就是用真实的编程代码环境来测验工程师的工程能力，确保企业正确的用人，也确保有能力的候选人不用纸上谈兵。

2.0 版本，提出了技术测评的概念，可以根据岗位需求自动生成匹配的岗位题目，千企千卷，题目精准，鼓励工程实战。

因为产品技术含量很高，对工程师提出了很高的工程能力要求：优秀的代码设计能力、代码质量、工程效率过硬。产品体验地址：https://www.showmebug.com

如果你乐意承担以下职责和要求，欢迎投递简历。

岗位职责

负责 ShowMeBug 产品的维护和业务迭代；
关注技术动向，研究和攻关技术难点；

任职要求

熟练 Rails 技术栈，包括不限于 Ruby 语言能力，Rails MVC 架构，Webpacker，Turbolinks，Minitest/RSpec 等标准 Rails 技术栈。
熟悉 JavaScript，掌握 Bootstrap，Vue 或 React 等前端框架，HTML/CSS 扎实，能写出良好质量的前端代码。
有用户思维，能够有意识主动反馈产品问题，写出更适合用户使用的功能。
如果你的操作系统、计算机体系扎实，对 Rails 很有兴趣接触。可以快速上手，我们也非常欢迎。加分项：博客，github 内容质量较高

待遇福利

Base 20-35K
年终奖 1~4 个月（年终绩效而定）
弹性三个时间段，不打卡
工程师和产品文化双驱动
重点员工持股计划，财富自由机会

HR 总结的优点

上班时间：周一至周五，10:00--19:30，中午休息 1 个半小时。周末双休！
工作地点：深圳南山区惠恒大厦，南山核心区。
晋升发展：公司晋升体系非常完善，我们也欢迎有能力的人士向上爬。即便没有向上爬一级，我们每年都有调薪的窗口期，会根据大家工作一年的表现进行适当的调薪。
五险一金：一入职公司就会帮忙缴纳社保，还有五险一金。缴纳金额，是按照当地的标准来。如果十五号以后入职，次月缴纳。举例，如果我 16 号入职，那么公司只能帮忙缴纳下月的社保，还有五险一金。
下午茶和团建：我们公司非常重视程序员的幸福指数，也非常重视程序员的身心健康，所以每个月都会有活动经费~
股权激励：公司将每位同事都当成一同发展的伙伴，在职一定时间后会进行股权分配。公司上市后所持有的股权可以成百倍的增加。

不夸张的说，ShowMeBug 是有技术追求的极客工程师值得长期去做的事业，我们的使命是帮助国内的工程师更好的成长、更好的工作。

因为业务发展的阶段需要大量的沟通需求，暂不开放远程，未来 2 年会逐步考虑开放部分。

投递地址：hr#dao42.com（#换成@，备注 Ruby 社区，也欢迎加我个人微信交流：lyfi2003）

[支持远程][兼职] 背书推荐：奇绩创坛招聘兼职 Ruby on Rails 全栈工程师

lyfi2003 — Wed, 12 Apr 2023 18:29:08 +0800

奇绩创坛招聘全栈工程师（兼职 + 远程）

Hi，各位 Rubyist，我是李亚飞，现 ShowMeBug 创始人，得益于很多 Ruby 圈的朋友支持，我们发展的还不错。今天特别帮助我们的早期股东奇绩创坛招募 Ruby 工程师，期待因为更多招聘需求帮助社区更多活力。

奇绩创坛是由陆奇博士创立，原 YC 中国，中国技术创业者的早期加速器，以下是招聘介绍。

我们是谁？

奇绩创坛投资加速早期科创企业，目前已经形成国内最大的早期技术项目社区
奇绩有自己的技术团队，通过技术提效，帮助到更多的创业者
更多信息请访问：https://www.miracleplus.com/about/

招聘岗位

全栈工程师（兼职）（远程）（人数：1-2 位）

工作职责

每周兼职工作 10+ 小时
奇绩系统全栈开发，有很多种前后台的产品需要开发

会接触哪些技术：

GPT, Ruby, Vue.js, React, AWS, 微信小程序，GraphQL, Clickhouse, Superset

工作优势：

工作时间灵活。
可以远程，也可以来北京五道口办公
能够接触到不少优秀创业者和项目，有国内最优秀的早期技术创业者社区
与创业一样，练习和见证从 0 到 1 的技术建设

职位要求

有很强的前端实战和运维经验
熟悉 Ruby / Python 和前端
有较强的自我驱动力

补充：面试时所用的技术栈和工具不限，但是入职之后至少需要学习使用 Ruby，以及其他必须的后端技能。

联系方式：如果对以上岗位有兴趣，简历请发至 hiring@miracleplus.com

分享自己多年理解 Ruby 所必备的一些程序练习集

lyfi2003 — Sat, 31 Dec 2022 11:21:21 +0800

直接点击，体验学习：（可直接练习）成为 Ruby 高手必须吃透的程序集

不知不觉用 Ruby 已经超过 10 年了，还清晰记得 12 年写过的一个 RubyProxy，在代码前缀加上一个 ATU，就能把运行逻辑自动转发给另一个电脑的程序运行，把 Ruby 元编程的优雅发挥出来的那种喜悦。

Ruby 的魅力在于给予了我们开发者无穷的自由，创造了巨大的编程想像力，我后面接触过 watir，Rails，Metasploit 等等优雅的 Ruby 项目都让我觉得惊奇，这已经不是在写代码了，而是在搞艺术创造。

class Integer
  alias :old_plus :+
  def +(other)
    self.old_plus(other).old_plus(1)
  end
end

# 这里演示了 Ruby 的开放性，修改了原始的 a+b 的结果，也许只有 Ruby 语言能完成这样酷的效果
puts "1+1= #{1+1}"
# Ruby 中所有的调用都是 klass.method(arg) 的形式，所有的类型数据都是对象
puts "1+1= #{1.+(1)}"
# 1+2
puts "1+2= #{1+2}"

感受 1+1=3 的魅力：1+1=3

然而，这些多年过去了，仍然有大量在编程迷途中探索的初学者，仍然在纠结是否要学 Ruby，在怀疑 Ruby 的自由度是否是一个上吊的绳子会害了自己等等。

我作为过来人，建议大家大可不必犹豫，好好学学 Ruby，就如《七周七语言》的作者说过的一句话，”每一种编程语言都是一种哲学思想，都值得我们深入去理解它的理念”。

在这里，我分享一下自己多年理解 Ruby 所必备的一些程序练习集。分别有：

1+1 = 3
Singleton Class
Method Call
Method Missing
Block Call

建议大家配合去看一本元编程的书，然后在我做的这个程序集上再直接实践理解。去体验三点：

Ruby 的调用链是如何做的这么简洁的
Ruby 的对象模型（Module，Class，MetaClass）是如何像上帝一般构建起来的
高阶函数（Block，Proc，Lamda）的魅力

直接点击，体验学习：成为 Ruby 高手必须吃透的程序集

后面有好的想法会持续补充。

附

Rails 信条

[支持远程][兼职] 背书推荐：奇绩创坛招聘兼职 Ruby on Rails 全栈偏前端工程师

lyfi2003 — Mon, 08 Aug 2022 13:30:14 +0800

Hi，我是李亚飞，Ruby 圈 12 年的老兵，现 ShowMeBug 创始人，我们自己正在招聘全职 Ruby 工程师，见帖子：[https://ruby-china.org/topics/42528]。奇绩创坛是目前国内最优秀的早期技术孵化器与社区，特别荣幸他们也选择了 Ruby on Rails 作为创业社区的技术栈，其实与 Ruby 的文化也特别适合与匹配。

我们在 2020 年春很幸运拿到他们的投资，陆奇博士和奇绩创坛对技术创业者的加速帮助是很显著的。特别的，在这里也帮助他们背书发一个招聘。各位 Rubyist 如有远程需求，特别适合试一试。当然如果有想干大事的，来深圳可以直接联系我。以下是招聘正文。

我们是谁？

奇绩创坛投资加速早期科创企业，目前已经形成国内最大的早期技术项目社区
奇绩有自己的技术团队，通过技术提效，帮助到更多的创业者
更多信息请访问：https://www.miracleplus.com/about/

招聘岗位

全栈工程师（兼职）（远程）（人数：1-2 位）

工作职责

每周兼职工作 10+ 小时
奇绩系统全栈开发，但大部分偏前端工作，后端不复杂

会接触哪些技术： Ruby on Rails, Vue.js, React.js, AWS, 微信小程序，GraphQL。

工作优势

工作时间灵活。可以远程，也可以来北京五道口办公
能够接触到不少优秀创业者和项目，有国内最优秀的早期技术创业者社区
与创业一样，练习和见证从 0 到 1 的技术建设

职位要求

有很强的前端实战和运维经验
熟悉 Ruby on Rails 和前端
有较强的自我驱动力

补充：面试时所用的技术栈和工具不限，但是入职之后至少需要学习使用 Ruby on Rails，以及其他必须的后端技能。

时薪具有很好的竞争力，根据能力：150～250 元/小时

联系方式：如果对以上岗位有兴趣，简历请发至【hiring@miracleplus.com】

[深圳] 持续打造国内顶尖 Ruby 团队，ShowMeBug 现正在火热招聘中！

lyfi2003 — Wed, 20 Jul 2022 12:34:47 +0800

鲁迅说：人一旦去上班，智商，情商都会提高 86.4%，烦恼也会消失 95%。但问题来了，去哪里上班，鲁迅不肯说，只留下了一串神秘的字符：[https://www.zhipin.com/gongsi/44d8bfda3fcb6d811H162N20GQ~~.html?ka=search_rcmd_company_44d8bfda3fcb6d811H162N20GQ~~_custompage] hi，各位 Rubyist 们，我是深圳 Ruby 社区发起人李亚飞。以 Ruby 为核心技术 20 年，这是我们的正在做的第 3 年。我们的技术团队不断在壮大，技术领域不断的再加深。我们的技术使命仍旧是打造中国最一流的 Ruby 技术团队。

关于我们

深圳至简天成科技有限公司坐落于深圳南山，ShowMeBug 是旗下一款数字化驱动的可记录、可分析、可复盘的技术评估与在线 Coding 面试平台。团队 50% 都是研发人员组成，成员来自于一线互联网企业，我们是一个技术驱动型企业。公司追求全体员工物质与精神的幸福；量化开发者，为开发者提供全生命周期的技术评估、学习成长、协同交流平台。公司已经服务 3000+ 企业用户，超过 10 万注册用户，并获得 4 家一级机构投资。

我们期望的候选人

熟练 Rails 技术栈，包括不限于 Ruby 语言能力，Rails MVC 架构，Webpacker，Turbolinks，Minitest/RSpec 等标准 Rails 技术栈。
熟悉 JavaScript，掌握 Bootstrap，Vue 或 React 等前端框架，HTML/CSS 扎实，能写出良好质量的前端代码。
有用户思维，能够有意识主动反馈产品问题，写出更适合用户使用的功能。
如果你的操作系统、计算机体系扎实，对 Rails 很有兴趣接触、可以快速上手，我们也非常欢迎。加分项：博客，github 内容质量较高。

职业发展道路

全面培养全栈 Ruby 工程师，不以资历年限为界定，技术能力定乾坤。公司目前有位两年工作经验的 Ruby 技术高级工程师！并且具备架构师的潜质！期望下一位优秀的你加入！

工作的氛围

以技术为核心，追求技术极致的巅峰造诣，极具极客创造精神。
创始人为 Ruby 社区大拿，坚持打造以 Ruby 技术为核心 20 年，为 Ruby 技术爱好者提供栖息地。
硅谷技术文化氛围，不打卡，不加班，自我驱动。
我们不以资历说话，以技术定英雄。

福利待遇

现寻求 Ruby 工程师 3 名，中高级架构都极度欢迎，15-35k，保底 13 薪，年终奖优秀的 2-7 个月。另外，每年都有百倍成长潜力的股票期权发放，每年 6、12 月两次调薪，以及零食下午茶，团建，每月活动等各种人性化福利。

联系方式

简历可以直接投放在人力资源部：ruijing@dao42.com，jingmin@dao42.com 备注 RubyChina 可以大大加快处理。也可以加我微信：lyfi2003 进一步交流。

‘伯牙’已在，‘子期’未来，关于 Ruby 这曲‘高山流水’何时能真正奏响。

Rails 7 正式发布（译文）

lyfi2003 — Thu, 16 Dec 2021 19:43:01 +0800

Rails7 的新理念几年前就开始了。这是我们愿景的实现，真真正正的全栈 Web 开发框架，完美将前端和后端的技术挑战进行了融合和平衡。其中包括了全方位的开箱即用的点菜单，从餐前开胃菜到餐后甜点都有。

这个理念其实几年前就有，但之前无法启动。主要是我们没有足够的相关技术成熟度。随着浏览器全面支持 ES6、ESM，和 HTTP/2 的适配，还有令人兴奋的 importmap 相关标准，这一切变为了可能。Rails7 发挥了以上所有的优势，打造了一个无 Node 依赖的前端解决方案，无须过早引入 npm 包系统或者现代 JavaScript 流程。

Hotwire 结合了 Turbo 和 Stimulus，交付了一系列工具帮助打造超级优秀用户体验的产品，关键是与传统单页应用相比，几乎没有新增复杂度。这是新 Rails 应用的默认配置，取代了有更多限制的 Turbolinks 和 Rails UJS。

虽然大多数 Rails 应用不需要依赖 Node，但我们还是会持续改进与 Node 相关环境的集成工作。

用 Webpacker 紧密绑定 Webpack 的做法已经过去了，我们现在会采用松耦合的一种绑定方式，这估计是开发者更喜欢的方式。无论你是喜欢 esbuild 或者 rollup.js，亦或者是 Webpack，你都可以用我们新打造的 jsbundling-rails 集成方案，并且你可用 --javascript esbuild 来提前进行配置。

同样的，我们针对 CSS 打包采用相同的思路。在 Rails7 中，所有需要的文件都会编译打包在 application.css 中，完美整合。从 Tailwind CSS 到 Bootstrap，从 Dart-powered Sass 到 PostCSS 都有很好的整合。如果你也乐意接受 Node 依赖的复杂度，你仍然可以通 --css bootstrap 这个参数提前配置你的新 Rails 应用。它将使用 cssbundling-rails 来进行打包。（偷偷告诉你，我们针对 Tailwind，做了一个无 Node 依赖的版本）

这里有最好的缺省选择，Rails7 中的前端开发方案如此优秀。缺省的配置下没有 Node，超级简单，却令人惊奇的超强能力，有弹性地扩展。高级配置里面 Node 部分相比从前更加轻量，更少的规范，也更健壮。

但是，当然不止如此，Rails7 更大的梦想是重新定义现在的前端解决方案，目前也很多不错的进展值得庆祝。比如我们全新的 Rails 官网，是由 Basecamp 的设计师 Sean Mitchell 完成。新 Rails 应用也有新的启动画面。我（DHH）还非常专业的录制了新的 demo 演示视频。

下面再介绍一些其他新的相关特性或改进点：

在 ActiveRecord 中提供工作时加密机制

从 HEY 项目中抽象出来的 Active Record 的加密字段支持。这样的话，你的应用除了传统的静态和中转加密外，还可以直接工作时加密。

这是一项立即收益的功能，加密敏感字段添加了额外的安全能力。举个例子，如果攻击者已经获得你的数据库权限，或者你的日志，他们也无法解开这些隐私数据。当然即使不考虑这些入侵者，正常情况也不应用获取到这些敏感的个人信息。

但是更重要的，通过 ActiveRecord 加密技术，你可以从代码层面定义哪些信息是属于敏感信息。这样就可以有效控制这些信息该怎样被访问和构建相关服务。举个例子，审计 Rails 控制台操作，保护敏感信息，或者检查内建系统来自动过滤控制器参数。

通过 `MarginaliaStyle Tagging` 追踪原始查询

几乎 10 年前，Marginalia 已经从 Basecamp 抽象出来，通过 SQL 注释标签功能来追踪原始查询了。现在这个 Gem 包已经升级为 QueryLogs 并进入到 ActiveRecord 了。

异步查询加载技术

当你有一个控制器和 action 需要加载两个不相关的查询时，现在你可以通过 Relation#load_async 来进行并发查询了。例如，你有三个复杂的查询，每个要花费 100ms 时间，以前就必须用 300ms 的时间。现在就可以进行并行查询，总共只需要 100ms 即可。

全面使用 Zeitwerk

自动加载技术在 Rails 中是超级酷的魔术技术之一，它表现的如此简单，就像本应该如此一样。原来一直信任并使用的 const_missing 有一些毛病，也缺失一些特性，所以最终我们全面切到了 Zeitwerk 代码加载技术。针对旧的应用，这里有一些少量的升级事项，不过我们的升级向导日志会帮助你不花费什么时间就完成升级。

其他一些值得注意的

Spring 取消了缺省支持，因为更快的电脑往往不需要它，只有大型应用才能用上它。

ActionController::Live#send_stream 让由控制器动态生成的文件推送到客户端变的更加方便。

并行测试现在会比较你的 CPU 核心数，进行弹性的并行测试。

Active Storage 现在会采用更快更安全的 libvips 作为缺省的多版本处理器。

从我们到你们

过去一年，从 Rails6 到 Rails7, 中间有着超过 4000 次的提交。这是好几百个贡献者的成果，也有很多是第一次提交代码。他们加入了超过 6000 人的贡献者团队，多年来一直在为 Rails 代码作出贡献。

在开发过程中，所有的工作都经过数千个应用的验证，像大型的如 Shopify，Github，Basecamp 和 HEY，都一直跑在最终的生产版本上。

对于 Ruby on Rails 框架来说这是一个了不起的时刻。在这个框架上构建着如此大的应用，并且一直在响应能力和伸缩性上创造着新的记录。在招聘最优秀的 Rails 开发者上，从来没有像今天这么激烈。每周都在有新的贡献者在推进着 Rails 的发展和迭代。

我希望大家喜欢这次新的旅程。

原文：https://rubyonrails.org/2021/12/15/Rails-7-fulfilling-a-vision

翻译者 WinDy：https://yafeilee.com

2021 年 6 月 19 日深圳 Ruby 线下活动总结：Rails6 Hotwire&Turbo 全栈解决方案

lyfi2003 — Sat, 19 Jun 2021 19:23:56 +0800

今天活动比较成功，约 15 位参加活动，非常感谢各位在疫情加紧防护的情况下还能参加到本次线下活动中。

正如 Ruby 的诞生一样，深圳 Ruby 活动能够持续举办也来自兴趣和热爱，我们自豪使用 Ruby 来更好完成开发工作。也非常欢迎新的 Ruby 同学加入阵营。

今天的主题有 3 场，主要是《Rails6 的前端解决方案介绍》，还有一个《MQTT 的简介》。

亚飞与智恒分别从独立的思考角度阐述了 Hotwire 和 Turbo 的解决方案，Webpacker + Turbo（Drive+Frame+Stream）+Stimulus 全栈解决方案。

大家可以从主题一和主题二的 PPT 上查看。

主题一：李亚飞《Rails6 Turbo 详解》，https://slides.com/windy/rails6-turbo-chinese-version/fullscreen

主题二：Lan 蓝智恒《聊聊最近 Hotwire 的使用感受》，https://daotestimg.dao42.com/ipic/Hotwire.pdf

主题三：新一《MQTT 简介》https://docs.google.com/presentation/d/1k3pIG2KlR2MP0VoC2AzJp51xrDP1vf_AN9wAEHraP_8/edit?usp=sharing（需翻墙）

[支持远程][兼职] 背书推荐：奇绩创坛招聘兼职 Ruby on Rails 全栈偏前端工程师

lyfi2003 — Mon, 07 Jun 2021 13:39:29 +0800

工作职责

每周兼职工作 10+ 小时
奇绩系统全栈开发，但大部分偏前端工作，后端不复杂

工作优势

工作时间灵活。可以远程，也可以来中关村办公
能够接触到不少优秀创业者和项目，有国内最优秀的早期技术创业者社区
与创业一样，练习和见证从 0 到 1 的技术建设

职位要求

有很强的前端实战和运维经验
熟悉 Ruby on Rails 和前端
有较强的自我驱动力

薪资待遇

根据能力，时薪约 150-300 元/小时

如果有兴趣，简历可以发至 xuwen@miracleplus.com，注明 showmebug 亚飞 可获优先考虑

另外，ShowMeBug 本身也在广招全职的全栈工程师，Base 深圳，也欢迎投递简历，详见 ShowMeBug 招聘帖

[深圳][南山][已结束]2021年6月19号周六下午深圳 Ruby 活动，主题已更新

lyfi2003 — Fri, 04 Jun 2021 11:41:03 +0800

活动主题：深圳 Ruby 技术活动

活动时间：2021 年 6 月 19 日（周六）14:30-17:30

地点：深圳市南山区惠恒大楼一期 301

简介：

深圳 2021 年 Ruby 技术线下活动，最好的 Ruby 爱好者交流活动。

流程：

主持人开场白：2:30 ~ 2:45
主题一《Rails 6.0 Turbo 介绍》（李亚飞）2:45 ~ 4:00
休息与交流时间：4:00 ~ 4:15
主题二《聊聊最近 HotWire 的使用感受》(蓝智恒) 4:15 ~ 5:30
休息与交流时间：5:30 ~ 6:00
AA 制晚餐 ( 可选 ) 晚 6:00 ~ 8:00

为什么要来参加？

深圳 Ruby 活动是 Ruby 爱好者自发的组织，已经坚持数年有余，无费用无广告，纯技术干货。适合于 Ruby 群体的任何水平前来交流技术学习。

如何报名

请在活动行上登记报名：http://hdxu.cn/V1Agc

附近期活动照片

[深圳] 构建中国一流的 Ruby 团队，ShowMeBug 招聘 Ruby on Rails 全栈工程师 5-10 名

lyfi2003 — Thu, 29 Apr 2021 14:48:26 +0800

Hello，各位 Rubyist 们，我是深圳 Ruby 社区发起人李亚飞，相信有不少朋友认识哈，我们正式开始大规模扩招 Ruby 团队了。我们的技术使命是打造中国最一流的 Ruby 技术团队。

为什么坚持使用 Ruby 技术栈

很简单，ShowMeBug 项目特点决定了使用 Ruby 是最合适的。

一是我们坚信 Ruby & Ruby on Rails 是 Web3.0 应用最高效的架构，ShowMeBug 底层采用 ActionCable + 实时协同 OT 算法，其他部分全面拥抱 Rails6.0 标准全栈架构。每周发版的迭代速度，是市面上同类产品的 4 倍开发速度。正如《黑客与画家》激发了我的创业动机，Ruby 激发了我们的创造力和改变世界的动力。

二是我们在探索最边界的技术自动评估方案，创新力比拟 10 年前的 Github 创立过程。需要很强的技术创新力，用户思维（技术人的用户思维）。所以技术团队需要有很强的自驱力，创新力，和用户思维。我相信 Rubyist 在这些方面都是最好的。

关于公司

深圳至简天成科技有限公司成立于 2019 年 3 月，是一家技术驱动的新秀软件科技公司。公司专注于打造国内领先人代码人才评估社区，为中国未来 2000 万工程师提供技术评估和职业成长平台。目前已经构建了一套优秀的线上代码面试评估系统。公司已经服务 3000+ 企业用户，超过 10 万注册用户，并获得 4 家一级机构投资。产品体验地址：showmebug.com

公司在深圳南山，如果你也对硅谷范创业文化及高速成长感兴趣，欢迎加入。

工作内容

我们是全栈 Rails 技术栈，喜欢 Rails 全栈的同学千万不要错过。
创始人是深圳 Ruby 社区大牛，致力于打造世界一流的 Ruby 团队。
硅谷技术范的氛围，敏捷开发模式，不打卡，弹性工作，不鼓励加班，自驱动。
产品特点导致技术上限很高，会 C 语言的 Ruby 工程师也有很好的发展空间。
产品体验要求极高，需要你有一定的产品思维。

我们希望你有以下能力

熟练 Rails 技术栈，包括不限于 Ruby 语言能力，Rails MVC 架构，Webpacker，Turbolinks，Minitest/RSpec 等标准 Rails 技术栈。不管目前能力高低都有合适你的位置。
熟悉 JavaScript，掌握 Bootstrap，Vue 或 React 等前端框架，HTML/CSS 扎实，能写出良好质量的前端代码。如果这方面自己觉得有点弱，也没有太大关系，我们会教你。
有用户思维，能够有意识主动反馈产品问题，写出更适合用户使用的功能。
如果你的操作系统、计算机体系扎实，对 Rails 很有兴趣接触。可以快速上手，我们也非常欢迎。加分项：博客，github 内容质量较高。

最后，欢迎加入公司，一起高速增长，一起用技术改变技术招聘。

待遇

提供极有竞争力的薪酬待遇，针对高级工程师，我们提供 20-40K 的薪水，针对普通级别，我们提供 12-20K 的薪水，最少 13 薪。另外，每年都有百倍成长潜力的股票期权发放，以及零食下午茶，每月活动等各种人性化福利

联系方式

简历可以直接投放在 hr@dao42.com，备注 RubyChina 可以大大加快处理。也可以加我微信：lyfi2003 进一步交流。

看到这里不要走，动手帮转发一下，为一起打造中国一流的 Ruby 团队添个砖，转发文案推荐：深圳最牛逼的 Ruby 团队正在招聘中。

深圳 Ruby 活动 2021 年 01 月活动总结 ( 内有干货 )

lyfi2003 — Fri, 15 Jan 2021 18:47:46 +0800

2021 年深圳 Ruby 线下活动于 2021 年 01 月 09 日举办，本次活动到场近 20 人。

主持人李亚飞在开场环节介绍了深圳 Ruby 线下活动的宗旨：

以免费的模式凝聚深圳 Ruby 社区的氛围，技术交流为核心，提高 Rubyist 的技术能力，让编程更快乐。

主题一：《WebRTC 简介》

分享人：新一

主要分享：

Web 实时通信（WebRTC）的原理和功能，p2p 的实现。

主题二：《如何利用 GrahpQL 和代码生成器提高生产力》

分享人：阿远

主要分享：

分享了一个类似 Rails 的 Node.js 生产力神器：strapi，并基于 Strapi 演示了如何快速搭建 Restful API 和 GraphQL API，以及通过 GraphQL Code Generator 去自动生成 React.js 和 Typescript 代码，提高开发效率。

轻主题：《Rails 的前端：Turbolinks 与最新的 Turbo》

分享人：李亚飞

主要内容：

站在全栈的视角，Rails 是怎么解决前端问题的，如何让用户获得极致的访问体验，如何获得更快的开发速度，更好的前端代码管理。

RJS，Turbolinks 的技术加持，到最新的 Turbo，Stimulus 的组合，建议各位有兴趣可以深入了解学习。

招聘需求：ShowMeBug 正在招聘 Rails 高级工程师 15~30K，详见帖子：https://ruby-china.org/topics/40666

最后，与部分参与朋友做了晚餐与交流，相信大家都有足够的收获。感谢大家的参与，期待我们下次的活动。