跨国深谈← 返回←从拒用 AI 到全面拥抱：Dioxus 团队的智能体编程实战课

从拒用 AI 到全面拥抱：Dioxus 团队的智能体编程实战课

关联

人物 Jonathan Kelley

公司 Dioxys

概念 智能体 · Rust · Blitz · 提示词工程 · 模糊测试 · 测试 · 软件架构

Jonathan Kelly 是 Dioxus 的创造者——一个用 Rust 语言写的跨平台应用框架（目标是像 React Native 那样一套代码跑多个平台，但性能是纯原生的）。五年前他用本科最后一个暑假启动了这个项目，如今它有近 37,000 GitHub 星、数百万下载、累计超过 2 亿终端用户，甚至被 Cognition 收购。但这场分享真正想讲的，是一支「顶级 Rust 工程师团队」如何从长期怀疑 AI，到彻底改变工作方式的故事。

他们的起点：AI 写的代码全躺在草稿里

Dioxus 团队一直认为「交付高质量代码」和「用智能体编程工具」不兼容，日常完全不碰 AI。转折发生在过去六个月：AI 编程智能体在 Rust 上突然变得非常强，他们兴奋地用爆了 Claude Code 订阅额度，产出数万行 Rust 代码——结果很少有代码能过他们「是否该合并」的质量门槛，成千上万行想要多年的功能和修复一直躺在草稿里。Kelly 承认，当时太容易变成他们所谓的「slop cannon」（垃圾代码炮）——疯狂生成、无法合入 。

反直觉的发现：为人类做的易用性优化，智能体不在乎

反思后他们意识到一件讽刺的事：这些年他们拼命让 Dioxus 对人类开发者友好——好读、好写、好工具、好错误信息——而编程智能体根本不在乎这些。但 Dioxus 对智能体依然友好，原因是 Rust 本身难写：智能体替你承担开发负担、处理边界情况、跟借用检查器（Rust 中防止内存错误、对新手最劝退的机制）搏斗。

Kelly 的总结很有味道：「我们曾经努力降低的学习曲线，现在变成了一个特性。」

智能体真正擅长的三件事

知识问题。 Dioxys 的很多难题本质是知识问题——团队不可能懂每个构建系统、每个操作系统、每个 API 的每个怪癖。

智能体能翻几千页文档、逆向工程 API，比任何个人都有耐心。最典型的例子：他们给 Dioxus 做了 Kotlin 和 Swift 插件，深度集成进构建系统——React Native 的同类功能（Turbo modules）花了好几年才做对，他们用智能体两三周就发布了，实现第一天就完成，剩下两周全花在真实设备测试上。在自研渲染引擎 Blitz 里，智能体对 CSS 规范熟到能立刻说出 Chrome 和 Safari 是怎么处理某个布局问题的，不用去翻 Apple 仓库深处的 WebKit 源码。

用正确的方式做事。 过去人类总按项目复杂度决定要不要走捷径；现在智能体让「用正确的方式、不取巧」变得可负担——这是相对过去做法的一个反转。

平凡琐事。 团队只有三个核心工程师，花在「验证压缩包解压出正确目录」上的每一分钟都是从架构思考里偷走的。

发布清单验证、bug 修复向后移植、保证文档质量，全部交给智能体。结果是：他们做到了每周甚至一周多次的发布节奏——以前他们对发布是害怕的。文档这块尤其受益：人类改代码不改注释，注释很快过时；让智能体检「每条文档是否如实描述了它说的东西」很容易。

还没到位的地方

写测试。 Kelly 明确说自己还没百分之百信服用 AI 写测试。

智能体能给任何 API 轻松写出测试，但和人类一样写不出「对的测试」——你给它一个构造函数，它就去测那个构造函数，没意思。团队仍然手动列举测试条件、自己设计测试 API。不过有个例外他们很喜欢：构建模糊测试工具（fuzzing，即把程序置于数百万种包括恶意格式错误在内的输入下找崩溃）——智能体搭这类测试架子非常在行。

架构仍是人的活。 智能体速度极高，但「它们落地的基底不好，贡献也不会好」。

而且和人类工程师不同，智能体不怕随便大规模重构——功能不合身就直接发了。所以团队大部分开发时间现在花在思考架构和系统未来演进上。

「人类能写面条代码，智能体也能，只是更快。」

意图传达。 他们逐行审查每一个 PR（也收到大量陌生人贡献的 PR），发现用户向模型传达意图的能力相当差，很多解决方案是硬拼凑的。

智能体还读不了心思，仍然受限于文本媒介——「提示词工程是相当真实的」。但从另一个角度，什么都没变：读代码从来都比写代码重要。

结语

Kelly 的收尾：「代码现在很廉价，但质量不是。」软件工程师的工作从来不是往屏幕上堆代码行，而是为复杂问题设计优雅方案、提前十步思考系统演进、在需求变化中保持灵活性——这些没变，而且软件工程的门槛比以往任何时候都高。

本集带走

• AI 代码过不了质量门槛，先怀疑工作方式而不是工具：他们的数万行代码躺草稿，问题出在不会用，反思后才有产出。
• 智能体最适合「知识型难题」：跨语言集成、文档检索、逆向 API 这类拼耐心和知识广度的活，几天顶几年。
• 难度可以是卖点：Rust 难写反而成了智能体场景的优势，因为它把人类最痛的部分接走了。
• 别让智能体盲目写测试：让它写测试用例多半平庸，让它搭模糊测试这类测试基础设施则非常值。
• 人的时间该花在架构和意图传达上：基底不好智能体贡献也差；提示词质量直接决定实现质量。

我们确实不知道如何正确地使用这些工具，而且太容易变成我们所说的「垃圾代码炮」。
We definitely did not know how to properly wield these tools, and it was way too easy to become what we call a slop cannon.
—— Jonathan Kelley · [06:45]

我们努力让 Rust 对人类变得容易，而事实上，这并不重要。
We tried to make Rust easy for humans, and in fact, it didn’t really matter.
—— Jonathan Kelley · [07:14]

我们曾经努力降低的学习曲线，现在变成了一个特性。
The learning curve, which we fought to reduce, is now a feature.
—— Jonathan Kelley · [07:34]

你交付的速度建立在你构建的这份基底之上，如果基底不好，你在上面构建的任何东西都不会好。
The velocity that you ship lays down on this substrate that you’ve built, and if the substrate isn’t good, nothing you build on top is going to be good.
—— Jonathan Kelley · [08:53]

我们用编程智能体大概两到三周就把它发布出来了，而且我们本可以更快。
We were able to ship this in like two to three weeks with coding agents, and we probably could have gone faster.
—— Jonathan Kelley · [11:03]

它们可以轻松地为任何给定的 API 写测试，但和人类一样，它们无法写出正确的测试。
They can easily write tests for any given API, but much like humans, they fail to write the right tests.
—— Jonathan Kelley · [15:05]

如果你的智能体代码所落地的底层基础不好，它们的贡献也会不好。
If the substrate on which your agent’s code lands is bad, their contributions will be bad as well.
—— Jonathan Kelley · [16:15]

就像人类工程师能写出面条式代码一样，智能体也能，只是现在更快了。
Just like human engineers can write spaghetti code, so can the agents, but now just faster.
—— Jonathan Kelley · [16:40]

阅读代码一直以来都比编写代码更重要。
Reading code has always been more important than writing code.
—— Jonathan Kelley · [17:59]

关于使用编码智能体构建有雄心的软件，我的结语是：代码现在很廉价，但质量不是。
So my closing thoughts on using coding agents to build ambitious software is that code is now cheap, but quality is not.
—— Jonathan Kelley · [18:07]

软件工程师的工作从来都不只是把代码行放到屏幕上。
The job of a software engineer has never really been about putting lines of code on the screen.
—— Jonathan Kelley · [18:17]