说实话,写这篇文章之前我犹豫了一下。
因为过去一个月,我公众号后台收到不少留言,大意都是:"AI 编程工具到底能干啥?不就是帮你补全代码、写点单元测试吗?"
我以前也这么想。
直到上周,我干了一件以前想都不敢想的事——用 Rust 写了一个小小的命令行工具,然后把它集成到了一个 C 项目里。
如果你三年前告诉我:"嘿,你一个只会写 JavaScript 和 Python 的人,有一天能碰 Rust 和 C。" 我肯定觉得你疯了。
但这真的发生了。而且不是因为我突然变聪明了,也不是因为我花了一百个小时啃《Rust 程序设计》。我只是用对了 AI 编程工具。
一篇让我破防的文章
事情要从一篇博客说起。
前两天 Shopify 的 Stan Lo 发了一篇文章,标题就叫《AI Coding Agents Are Removing Programming Language Barriers》。这哥们是个 Ruby 开发者,写了十年 Ruby,从 Rails 到 IRB 到 Ruby 的 debug gem,全都是 Ruby 生态里的东西。十年来,Ruby 不只是他的主要语言,基本上是他唯一会用的语言。
然后 2025 年一切都变了。
他今年给 Sorbet(一个 C++ 项目)贡献了代码,改过 RBS 的 parser(C 语言),现在又在搞 ZJIT(Rust 写的 Ruby JIT 编译器)。
一年之内,从 Ruby-only 到 C++、C、Rust 全面开花。

看到这段的时候我直接破防了——这不就是我的现状吗?
我是怎么从"Python 仔"变成"什么都能写一点"的
先交代下我的背景。
我工作这些年,主力语言一直是 Python 和 JavaScript。不是没想过学 Rust——谁没在 Hacker News 上被 Rust 刷屏过呢?但每次打开《The Book》,看到 ownership 和 borrowing 那些概念,我就默默关掉了浏览器。
不是学不会,是真的时间成本太高。要学到能写生产代码的水平,没几百个小时下不来。谁有这时间?
转折点出现在三个月前。我开始认真用 Claude Code 和 Cursor 来做日常开发。
一开始也就是让它写写测试、补补文档。但有一天我接到了一个需求——需要优化一个 Python 数据处理管道的性能,同事建议用 Rust 重写核心部分。
搁以前我肯定拒绝了:"我不会 Rust。"
但那天我试了试:把 Python 代码扔给 Claude,说"帮我用 Rust 重写这个函数,保持同样的逻辑"。
十分钟后,我拿到了第一版能编译通过的 Rust 代码。
不是完美的代码,但能跑。而且跑得比 Python 快 40 倍。
之后我花了两天时间,在 Claude 的辅助下把那段 Rust 代码打磨到了可上线的水平。过程中我不只是在抄代码——我在问它"为什么这里要用 match?""为什么这个变量要加 mut?""这个 unwrap 什么时候会 panic?"
Claude 回答得比大部分教科书都清楚。
AI 不是在替你写代码,而是在帮你"跨过那道坎"
Stan Lo 文章里有一句话我特别喜欢:
"AI 不是代码生成器,而是一个技能互补的结对编程伙伴。"
他把这个过程描述为:他知道项目需求和约束,AI 知道语言语法和模式。他负责判断"这么做对不对",AI 负责探索"还可以怎么做"。
这个描述太精准了。
我以前学新语言的最大障碍不是学不会语法——语法再复杂,花时间总能搞懂。真正的障碍是前 100 个小时的"挫败期":连编译都过不了、连基本的工程结构都搭不起来、连标准库有哪些函数都不知道。
AI 直接把这段时间抹掉了。
你可以从"有意义的事情"开始做——直接写业务逻辑、直接提交 PR、直接在真实项目里学习。AI 帮你处理那些"stupid rookie mistakes":变量声明语法错了、类型约定搞反了、跟不熟悉的构建工具打架了。

这不是在让你变懒,而是在让你更快地跨过那道门槛。
但 AI 也有翻车的时候
当然,事情没那么完美。
Stan Lo 也说了:AI 对项目特有的上下文、深层的内部机制、构建系统的古怪约定,经常是"hit or miss"。
我自己的经历也印证了这一点。前几天我在搞一个 Rust + C 的 FFI 绑定,Claude 写出来的 unsafe 代码我根本不敢直接用。问了团队里的 C 语言老手,才发现 Claude 对某些内存布局的假设完全是错的。
这种时候,AI 帮不了你。你需要的还是真人的经验和判断。
但换个角度想:如果没有 AI,我连那段 FFI 代码的初版都写不出来。即使它只有 60% 是对的,那也比从零开始强太多了。剩下的 40% 我可以问人、可以查文档、可以自己调试。
AI 把"从 0 到 1"的时间压缩了 90%,但"从 1 到 10"还得靠自己。
另一个有意思的趋势:Agent 编排平台正在兴起
说到 AI coding agent,这两天还有一个项目挺火的——Optio,一个在 K8s 上编排 AI coding agent 的平台。

它的思路很有意思:把 agent 的工作分成三个层级——Tasks(从 ticket 到 PR 全自动)、Jobs(一次性的参数化任务)、Persistent Agents(长驻的、可寻址的 agent 进程)。
这背后的逻辑是:单个 agent 的能力是有限的,但把多个 agent 编排成一个"开发流水线"——从需求分析到代码生成到 CI 修复到代码审查到合并——就能处理更复杂的工作流。
有点像 Jenkins 之于 CI/CD,Optio 想做的是 Agent 时代的 CI/CD 平台。
当然,它还很早期。评论区里有人直接问"怎么防止 agent 写出垃圾代码把你的代码库搞崩?"——这个问题现在还很难回答。
但方向是对的。当单个 coding agent 的能力逐渐趋同(各家模型差距在缩小),真正的差异化会出现在"怎么把 agent 组织成团队"这件事上。
所以,程序员还要不要学新语言?
写到这里,我猜有人会问:既然 AI 能帮你写任何语言的代码,那我还学新语言干嘛?
我的答案是:要学,但可以换个学法。
以前学新语言 = 先花 100 小时学语法 + 再花 100 小时学框架 + 再花 100 小时做项目 = 300 小时后才能写生产代码。
现在学新语言 = 直接开干 + 遇到不懂的问 AI + 边写边学 = 20 小时后就能贡献 PR。
这不是说不用学了,而是说学习的 ROI 变了。
你可以更快地从一个语言跳到另一个语言,更快地在不同技术栈之间切换,更快地解决那些"需要多种语言知识"的问题。
Stan Lo 在他的文章最后说了一段话,我觉得是对这个时代最好的总结:
"这不会取代深度 expertise——团队里的语言专家仍然不可或缺。但它确实意味着,同时在多个语言中保持生产力,对更多开发者来说已经成为现实。"
写在最后
前几天我在跟一个朋友聊天,他说他现在招人不再看"你精通什么语言",而是看"你能不能快速上手我们不熟悉的技术栈"。
AI 正在做的,就是让"快速上手"这件事变得前所未有的容易。
我不是在鼓吹"AI 会替代程序员"——恰恰相反,我觉得 AI 让程序员这个角色的天花板更高了。你不再被你的第一门编程语言定义,你可以是任何语言的开发者。
所以,如果你到现在还没试过用 AI 写一门你没学过的语言——去试试。
说实话,那感觉还挺爽的。
(完)
📌 如果你喜欢这篇文章:
点个「在看」让更多人看到 留言说说你用 AI 写过什么"本不该会"的语言 关注我,每周分享 AI 开发工具和效率心得
夜雨聆风