AI 编码代理正在消除编程语言壁垒：一个十年 Ruby 开发者的跨语言之旅

原文来源：Rails at Scale — Shopify 的 Ruby 工程师 Stan Lo 分享了他如何借助 AI 编码工具在不到一年内从纯 Ruby 开发者转型为跨语言开发者，参与 C++、C 和 Rust 项目的亲身经历。

Stan Lo 做了十年 Ruby 开发者——从 2014 年到 2024 年，他的工作覆盖了整个 Ruby 生态：Rails 框架、IRB、RDoc、debug gem……但无论他在技术栈的哪个层次活动，始终没有离开 Ruby 的边界。Ruby 不只是他的主力语言，实际上就是他的唯一语言。

这种局面在 2025 年发生了根本性变化。

这一年，他给 Sorbet（Ruby 的类型检查器，C++ 编写）提交了代码，参与了 RBS 解析器（C 语言）的开发，现在正在深入 ZJIT（Rust 编写的新一代 JIT 编译器）。这曾经是他梦寐以求但又不敢尝试的事情。而促成这一切的关键因素，是 AI 编码工具——Shopify 内部广泛使用的 Cursor 和 Claude Code。

天时地利

在谈到 AI 的作用之前，Stan Lo 强调，这次转型有两个重要的客观条件。

首先是团队路线的调整。Ruby DX 团队需要让 Sorbet 支持 RBS，这迫使他要处理 C++ 和 C 编写的项目——需要理解 Ruby 中从未接触过的系统编程概念。需求驱动学习，这是很多开发者跨语言转型的真实起点。

其次是团队氛围。Shopify 的 Ruby 和 Rails 基础设施团队有一群乐于分享的专家。Alexander Momchilov、Alexandre Terrasa、Max Bernstein 等同事花了大量时间跟他结对编程和辅导，给了他掌握 C/C++/JIT 基础知识的机会。

但这里有一个关键问题：优秀的导师和跨语言的项目机会一直都有。真正改变游戏规则的，是 AI 如何重塑了学习曲线。

系统编程的双重挑战

以 ZJIT 为例——这是 Shopify 正在开发的 Ruby JIT 编译器，用 Rust 编写。这个项目完美展示了跨语言开发的挑战：既要理解深层的概念（JIT 编译器如何工作、GC 如何运作），又要掌握语言和工具链的细节（Rust 的惯用写法、C 的编程惯例、Ruby 的构建系统）。

一个 Pull Request 往往同时涉及 2-4 个领域：

• Rust：ZJIT 的实现语言
• C：Ruby 本身的语言
• JIT 知识：编译器理论、优化策略
• ZJIT 特有概念：它的架构和设计决策
• Ruby 内部机制：VM 的实际运作方式
• Ruby 构建系统：autoconf、Makefile 等工具链

对前三个领域——语言语法、通用概念、标准模式——Claude 表现得相当出色。对后三个领域——项目特定知识、深层内部机制、构建系统细节——Claude 就时好时坏了。

但这已经把他的学习障碍减少了一半。

把 AI 当成结对编程搭档

Stan Lo 真正的突破来自一个心态转变：不再把 AI 当成代码生成器，而是把它当作一个有互补技能的结对编程搭档。

这不是让 AI 替他写代码。如果期待 Claude 能正确实现 ZJIT 的功能，他大概率会非常沮丧，浪费的时间比节省的还多——AI 缺乏项目特定的上下文和深层领域知识。

相反，他们像两个技术侧重点不同的工程师一样合作。AI 比他更了解语言特定的语法和模式，而他更理解项目需求和约束条件。这创造了一种高效的学习动态：

• 他提供任务需求和项目上下文
• AI 识别现有模式，充当语言专家
• 他质疑某些方案为什么可行或不可行
• AI 探索理论可能性，通过修改代码或推理给出结果
• 在对话过程中，他既在学习语言，也在学习如何有效应用这门语言

举个例子：当需要分析 ZJIT 中的某个 Ruby 字节码指令时，他可以请 Claude Code 查看之前类似的 PR，逐行解释他看不懂的部分。他可以问一些"愚蠢"的问题，比如"为什么 JIT 编译器需要性能分析？"，而不用担心浪费别人的时间。他能立即得到关于陌生 Rust 语法的解释。

当然，也有过两人一起走错方向的时候——这时只能靠同事的指点和知识分享来纠正。AI 能加速学习，但人类的专业知识对于纠偏来说仍然不可替代。

语言壁垒正在瓦解

最让人兴奋的一点是：我们再也不用花 100 多个小时学习 C 语言的基础知识，才能给一个 C 项目提交第一行代码了。AI 充当了第二双眼睛，帮我们避开新手常见的错误——用错的变量声明语法、误解的类型约定、不熟悉的工具链。从第一天起就能做出有意义的贡献，边做边学。

这不是说深度学习专家的价值被取代了——恰恰相反，团队里的语言专家依然至关重要。但它的确意味着，对于更多开发者来说，在多门语言中保持生产力已经变得可行。语法、标准库函数和常见模式的认知负担可以被分担出去，让我们能专注于真正要解决的问题。

而对于一个当了十年"Ruby 开发者"的人来说，在不到一年的时间里变成多语言开发者——这种感觉像是革命性的。而 Stan Lo 相信，自己只是这个趋势的早期受益者。编程语言的专业化分工，正在被 AI 从根本上重塑。

这对开发者意味着什么

Stan Lo 的经历不是一个孤例。随着 Cursor、Claude Code、GitHub Copilot 等工具的成熟，"X 语言开发者"这个身份标签正在变得模糊。AI 虽然还不能可靠地写出完整的系统级代码，但它能充当翻译层和加速器——把熟悉的概念翻译成不熟悉的语法，帮你在陌生的语言生态中快速定位。

当然，AI 编码代理不是万能药。它擅长语法和模式匹配，但对项目特定的架构决策、深层性能优化、安全敏感代码的处理仍然力不从心。Stan Lo 自己也承认，AI 在 ZJIT 项目中的表现"时好时坏"——在涉及项目内部机制和构建系统细节时尤其靠不住。

但关键是，AI 把跨语言学习的门槛从"半年基础学习"降到了"边做边学"。对于一个独立开发者或者小团队来说，这意味着技术选型不再受限于团队现有的语言栈。用什么语言写后端、用什么框架做前端，这些决策可以更多地基于实际需求，而不是"我们团队只会 Ruby"。