编写 Rust 代码，让智能体把它优化得比最先进的库更快

2025 年 1 月，我为一篇博客文章想出了一个有趣的假设：如果不断要求 LLM「写出更好的代码」，它们真能写出更好的代码吗？那时 agentic coding 还没有兴起，但 Claude Sonnet 3.5 已经能对算法类的 Python 代码做迭代改进。结果「更好」这个指令本身定义得太模糊：Sonnet 利用这种模糊性塞进了一大堆没用的功能，不过代码确实变快了。即便后来出现了专门经过 RLHF、擅长解决常见 pass/fail 编程题的 agentic LLM，优化通常也不在这类能力范围之内。在那篇文章的结尾，我畅想了一个假设性的未来：LLM 可以转而编写 Rust 代码，再用 PyO3 把两种语言桥接起来，从而兼得 Python 的易用性与 Rust 的速度，写出超快的 Python 代码。那篇文章的早期草稿曾断言，同样一句「写出更好的代码」也可以直接用在底层 Rust 代码上，大幅提升其速度，再传导到 Python 代码：但当时我对 Rust 了解得还不够，没有证据就下这种结论未免太辛辣了。Opus 4.5 发布后，agentic coding 变得更为可行，经过数月的测试与实验，我可以确信地证实：现代 agentic LLM 确实能写出比当前最先进方案快得多的 Rust 代码——前提是给出恰当的护栏与约束。此外，自 Opus 4.5 以来，每一代前沿模型在编程上都有大幅提升，这些优化也变得越来越好，累计下来，视具体领域不同，速度提升可达 2 倍到 20 倍。更重要的是，这篇文章不是含糊其辞的吐槽，我会把用到的 prompt 和 benchmark 结果一并附上。丑话说在前头。

迭代式「Benchmaxxing」

起初，让软件变快是我测试和比较这些新 agentic 模型的一个很好的量化手段。我选择 Rust 作为目标语言，主要是看中它与 Python 的集成和速度，但 Rust 还有一些其他特性，一旦真的找到了快速的实现，这些特性会格外有用，比如内存安全，以及能编译成 WebAssembly/WASM，几乎不费什么力气就能在浏览器里运行。不过有一条我会遵守的重要约束——它从技术上讲可能无法带来最快的代码——那就是尽可能禁止 unsafe 代码。我的第一个测试用例是用 Rust 重新实现机器学习算法。如果我能有更快、可扩展的工具，这对作为数据科学家的我来说会带来实实在在的生产力提升。当时，认为自己能打败那些经过十多年迭代、久经考验、而且本来就用 C 写成的算法，是种傲慢——Rust 的底层优势在它们面前并不明显。我最想优化的算法是 UMAP，它是我工作中用到的降维算法，很有价值，但面对大数据时扩展性很差，速度也非常慢，而 cuML 之类的替代方案配置起来又很费时间。像 umap-rs 这样的 UMAP Rust crate 已经存在，我完全可以 fork 过来，让 Claude Opus 4.5 加上 Python/PyO3 支持，但作为一次实验和学习，我想让 agent 从零开始写这个算法，尽量少用 Rust 依赖，以便在尽可能低的层面上做优化。Rust 有一个全面的基准测试工具，即 criterion crate，所有 agent 都知道怎么用它。criterion 会运行基准测试，跨迭代跟踪结果，看性能是提升还是退步，并能判断这一变化在统计上是否显著，还是只是噪声。

criterion 的典型输出，显示相对于上一次基准测试运行有 3.5 倍加速。

最初，在编写用于创建 UMAP 的 Rust crate 的提示词时，我要求 Opus 4.5 针对不同输入数据规模创建基准测试，因为针对小数据集的优化可能不适用于大数据集，反之亦然。

Afterwards, create and run a benchmark suite which stores the results as a Markdown file. The benchmark suite MUST include inputs up to 100000x768 and be tested in both CPU and GPU modes.

这种做法使用 criterion 创建了基准测试，我在提示性能特性改进（例如使用 faer 加速线性代数、使用 simsimd 加速 SIMD 操作）后手动重新运行基准测试套件。这很快就变得繁琐，因为每次更改后我都必须手动重新运行每个基准测试，以验证没有速度回退。

关于提示风格的旁注

我提示智能体式 LLM 的方式不太寻常：我通常会给智能体非常长的提示词，预先写在 Markdown 文档中，并额外使用全大写和加粗来强调。这是为了通过提示工程捕捉所有细微之处，以及本博客文章中详述的其他几种技巧。尽管有些人可能认为，随着最新模型已经足够聪明，能够正确处理歧义，提示工程已死，但我强烈反对，因为 LLM 在遵循这些细微之处方面也变得好得多。

通过标记文件（左）从 Markdown 文档（右）运行提示词，使用 Zed Agent。

在足够确信智能体不会意外 rm -rf 仓库后，我尝试让智能体自主运行，允许它们迭代直到实现速度提升，但愿如此。

**YOU MUST KEEP ITERATING OPTIMIZATIONS AND SOLVING ISSUES UNTIL THE BENCHMARK RESULTS STOP IMPROVING AND THE CRATE IS AS FAST AS IT CAN BE**. You have permission to keep iterating until you run out of ideas.

事实证明，“尽可能快”太模糊，而 Opus 4.5 很懒，所以它调整了几个超参数，并没有实际速度提升，就收工了。我需要的是一个明确的、可以通过/失败的目标，所以我改进了提示词：

First, **without making any futher changes**, run the CPU Rust benchmarks to establish a True Performance Baseline.

Then, optimize the crate code to make it such that ALL CPU benchmarks run **atleast 1.2x faster** than the True Performance Baseline; ideally as fast as possible. NEVER hack the benchmarks to accomplish this runtime reduction, only iterate on the library code.

You may use ANY techniques to do so (e.g. import new crates) other than adding `unsafe` code. **REPEAT THIS PROCESS UNTIL BENCHMARK PERFORMANCE CONVERGES AND YOU ARE OUT OF OPTIMIZATION IDEAS.** You have permission to keep iterating. After each benchmark iteration, report the relative results to the True Performance Baseline to console.

Prioritize making quick/high-impact wins iteratively and making changes accordingly. Do not overthink the necessary changes.

这非常有效，我不仅在基准测试上获得了 1.2 倍加速，而且智能体在达到指标约束后继续运行，只有在指标约束不可行时才停止；在这次实例中，智能体达到了 1.5 倍-2.0 倍 加速。底层 Rust 优化围绕多种技术，包括但不限于：更积极地利用 SIMD 操作、融合函数、展开循环、创建中间缓存、尽可能使用 Arc 而不是借用，以及根据输入数据创建性能配置文件（例如，如果数据很小，不要使用 rayon 数据并行，因为开销会抵消收益）。

我选了“1.2 倍加速”作为 sanity test：目标定得太高，agent 可能为了达标而作弊，用激进或冗长的重写硬凑。改动越小越好，因为这样 agent 更容易定位加速或回退的原因，这也是我强调迭代的原因。GPT-5.3 Codex、Opus 4.6 等新一代前沿 LLM 发布后，我把这段 prompt 原封不动地重复用于每一个新 LLM，每一次都能在上一轮的基础上再实现 累计 1.5x-2.0x 的加速。这样一路走到几个月后的 GPT-6 Astra，相比最初的实现基线大约快了 7.5x-32x。

这种做法是针对给定 benchmark 的极致优化，因此可以算作 benchmaxxing：一个贬义词，指前沿 LLM 只盯着在 benchmark 上拿高分，而这种高分很难泛化到真实场景。不过，如果 benchmark 足够多样、且确实能代表真实用例，这个顾虑就小得多。对这类项目，有两种办法应对 benchmaxxing 的质疑：1）让 agent 自己设计多样、不寻常、对抗性的输入数据集，而不是用那种千篇一律的“inputs up to 100000x768”；2）对输出设质量门禁，把结果与已知正确的实现做对比。对机器学习算法来说，速度和质量永远要权衡，但在这个例子里，先把模型做快、再把它做对，反而出乎意料地容易。科学工程通常不是这么干的，但一个新实现如果在多个不同 benchmark 的同等对比中都能匹配已知良好的实现，那它基本就是真的正确。

一个由 agent 优化的 gradient boosted decision tree 实现，速度上显著超过 xgboost，有时质量也更好！（MSE：越低越好；其他指标：越高越好）

好在 UMAP 有一个标准实现：Python 包 umap-learn，而指向该 Rust crate 的 Python bindings 也已经顺手加好了，所以新的目标变成了同时满足两个约束：提升代码质量，同时把速度损失控制住。

Create a Python Jupyter Notebook comparing the performance of the Python bindings with `umap-learn`, including a check to confirm where the outputs and UMAP losses are as similar. Use diverse datasets with different matrix sizes than the benchmarks.

If the outputs are not sufficiently similar, investigate methods to fix it **without causing more than a 5% speed regression**.

确实，agentic Rust 实现的质量更差，但这次后续提示词奏效了，所有质量指标都提升到接近持平的水平，速度损失极小。而且这个新 crate 仍然比带 Python 绑定的 umap-learn 快 4 到 15 倍，比同类的 Rust umap-rs 实现快 2 到 4 倍。

Rust UMAP crate 最新一轮优化后的结果。除了速度更快，它在大多数质量指标上也追平或超过了 Python。

当一轮 agentic 迭代只带来约 3-5% 的速度提升——这个幅度可能并不具有统计显著性——而 agent 却为此添加了不成比例的大量代码时，就说明已经收敛；这笔交易不划算。

我接着用同样的提示词推进流程测试了其他机器学习算法：梯度提升决策树（GBDT）、多层感知机（MLP）、图网络，以及 scikit-learn 里许多常见算法……结果全都奏效。我不想只盯着机器学习优化这一件事过拟合，尽管它本身价值高得离谱，于是我把类似的流程用在更日常的软件库上做优化：模板引擎、HTML 解析，甚至 Web 服务器……结果又一次全都奏效。

这些优化不是简单流程，你没法只靠那句模因式的“来吧，试着搞个突破”就拿到更好的代码，因为这种说法本身太模糊。我并不满足于仅仅写出最快的软件：我要的是软件尽可能快，就这样。所以，和我的 agent 一样，我不断迭代，找出更多提示词工程技巧，逼出真正的突破。

提示约束，而不是提示结果

在建项目

本文中演示的所有项目都在积极开发中，结果未必代表最终发布版本……不过我猜最终版本只会更好。😇

必须再次强调，agent 只要能作弊就一定会作弊。举个例子，我把 agentic 迭代流程用在 ballin 上——那是我用终端写的 2D 球体物理模拟——想替换掉已经撞到性能天花板的 rapier2d 物理引擎。Opus 4.5 确实能加速每一个物理步……只是加得有点太过了。

数字表示模拟中小球的数量：最初模拟在 15k 时出现卡顿。

在headless_step中，34,500 倍的加速，以及在各种小球数量下都保持一致的性能，这两点都非常非常可疑：手动检查后发现，Claude 是通过完全禁用物理引擎来实现这一加速的。这招确实够意思，但并不理想；后续的一次提示确实修复了它，并带来了整体性能提升（还顺带加了回归测试以防万一）。

对于我上面的实验，我使用了一份面向 Rust 的自定义 AGENTS.md；其最新版本可在此处获取。出乎意料的是，自从我二月份最初的 agent 实验以来，我并没有太多需要更新核心规则的地方，因为 LLM 在编码方面不断进步，我也没有遇到需要新增规则的重大问题。不过，从我的基准测试实验中吸取教训，我在 AGENTS.md 中又加了一节，包含一些规则，用来减少已观察到的作弊来源：

## Benchmarking and Optimization

- **NEVER** run benchmarks in parallel, as the benchmarks will compete for resources and the results will be invalid
- **NEVER** game the benchmarks. Do not manipulate the benchmarks themselves to satisfy any required performance constraints
- **NEVER** run benchmarks with `target-cpu=native` or any other `RUSTFLAGS`
- Ensure benchmark tests are independent. If the tests are dependent due to a feature (e.g. caching), ensure the feature is disabled
- **ALWAYS** use `criterion` directly for running benchmarks if available

我们逐条解释：

不并行运行基准测试：我看到 Opus 4.5 为了效率同时启动了两个基准测试，值得称赞的是它立刻意识到了其中的固有问题，并改为顺序重新运行基准测试，但主动加一条规则来阻止它们更省时间。
不钻基准测试的空子：尽管这本应是“不要犯错”级别的常识，但这条是在我抓到 Opus 4.5 为一个基准测试减少训练轮数并声称获得加速之后加上的。
target-cpu=native：这个设置确实通常会带来加速，但对于可泛化的使用来说并不是公平的比较，而且多个 LLM 在碰壁之后仍不断尝试它。
基准测试相互独立：同样，这本应是常识，但在上述作弊之后，主动告诉 LLM 别这么干也无妨。
使用criterion：如果不指定，有时 LLM 会自己造一套基准测试工具，这可能给它们提供更难审计的作弊机会。

对于今天的 agentic LLM，这些约束一直很有效，尽管我可能仍会出于习惯把它们写进提示里。如果你在git diff里看到基准测试文件，就很容易判断某个算法是否钻了基准测试的空子——agent 没法（至少不容易）在这上面作弊。

随着时间推移，我又发现了不少额外的提示工程技巧和约束条件，它们在创造性能加速方面同样出奇地有效。

鼓励创新

要想找到实现比当前最先进水平快 10 倍所需的优化，智能体必须跳出框框思考，避免被当前的最佳算法实践锚定。因此，我既给了它们明确的警告，也给了鼓励性的指令：

Due to the current highly-optimized state of this repository, this is a very difficult problem and traditional engineering approaches **WILL BE GUARANTEED TO FAIL** to hit the specified metric constraint. Therefore, you have permission and encouragement to investigate more radical fundamental low-level changes to hit the desired metrics. You have permission and encouragement to invent completely new/bespoke algorithms and engineering approaches that have never been before been utilized for this problem in order to hit the specified metric constraint.

这招奏效了，在各个基准测试和不同软件领域上带来了 1.2-1.5 倍的累计加速。

子智能体

另一个促使智能体跳出框框思考的技巧是调用子智能体。我的假设是，强制这些子智能体用不同的提示去做研究，可以 a) 给父智能体播下不同的想法，为它提供灵感；b) 通过审查代码中不同区域的实现是否正确，起到对父智能体的检查作用。说到这里，我对软件开发社区有笔账要算：每个人都在谈论自己的子智能体员工大军有多厉害，却没人谈在 Codex 这类标准 harness 里如何调用子智能体。

对于困难且高度并行的问题，harness 会自动调用子智能体工具来完成工作。但一个大问题是，在某些 harness 中，子智能体工具会用当前 LLM 的规模来调用子智能体，使用 Opus/Sol 级模型时这会变得很贵。

通过 Zed Agent 中的子智能体工具调用的 GPT 5.6 Sol 子智能体。我的 Codex 配额 RIP。

子智能体不需要写代码，所以我想用 GPT-5.6 Luna 这样更便宜的小模型。于是我想出了一个不管用哪个父 harness 都管用的天才方案：让模型运行独立的 CLI 命令，由这些命令自己去调用智能体：

codex exec --sandbox read-only -m gpt-5.6-luna \
 -c 'model_reasoning_effort="high"' \
 PROMPT

于是我在提示里写了：

To best accomplish innovative implementations, you **MUST** spin up 7-12 independent distinct "subagents" by running a long-duration CLI command (do not use the subagent tool) which can explore and evaluate different feasible hypotheses for improving the performance, usability, and security of this crate. Only have the agents return their response; do not save their full transcript to a file. Instruct them to be **very** picky. These subagents MUST use `gpt-5.6-luna` in Codex, e.g.

>>

You must instruct these subagents to NOT run tests/benchmarks, as they will compete for resources and not be valid. After you are done making changes, before handing off to the user, spin up the subagents again to confirm your implementation matches their hypotheses and ask for potential further areas of improvement. Keep iterating until ALL subagents are satisfied with your implementation.

这确实稳定有效；“长时间运行”“CLI 命令”“不要使用子智能体工具”“不要把完整记录保存到文件”这些约束，都是在智能体干了浪费 token 的低效事情之后才加上的。7-12 是随意定的数字范围；Luna 用起来太便宜，我就选了个比实际需要更高的数字。不是所有子智能体都有值得注意的想法，但父 harness 可以处理并忽略掉糟糕的想法。

为我的 Rust 词云 crate，父级 GPT-6 Astra agent 会拉起 Luna 子 agent，用不同的提示词分别处理代码库的不同部分。

总体而言，借助子 agent 审查，我又额外榨出了 1.2–1.5 倍的累计加速。另外，从 GPT-5.6 Sol 开始，提示词里的“安全”部分现在能给出一些思路，让 agent 生成的代码在面对未知输入时更健壮，同时仍然拿到速度提升。

重构与减少代码行数

在 AGENTS.md 强制执行的风格约束下，每次优化新增的代码量还算合理，大约每次提交净增 1k 行代码（LoC）。但 agent 通常会把代码堆进同一个文件，而且不会主动重构。文件臃肿在开发阶段问题不大，只要最终能收拾干净就行，所以我写了一个提示词来做这件事：

The Rust code in `/src` has become particularly bloated, with several source files >1k SLoC. Refactor and reduce the Rust source codebase by **atleast 20% SLoC** through deduplication, pruning redundant code, and following idiomatic DRY Rust principles. Simultanously, refactor and split the code such that no single source file has >1k SLoC, splitting larger files into multiple subfiles in accordance to Rust standards for popular open-source repositories. Ensure **all current tests pass and there are no severe regressions**.

我特意用 SLoC（源代码行数）而不是 LoC 作为目标指标，因为我不想让 agent 靠删注释来凑那 20% 的削减量。

有意思的是，这种重构比实际写代码更费算力，耗时往往也更长。但它最终确实能跑通，而在验证没有严重回归的基准测试中，数据却出乎意料地古怪：

重构我的图网络 Rust crate 后的基准测试结果。

有些基准测试出现了两位数的百分比速度提升/运行时间下降，尽管我并没有明确要求 agent 优化运行速度。这在直觉上说不通：Rust 是编译型语言，而且在必须保持所有现有测试/功能不变的约束下，编译出来的代码性能应该差不多，不该有实质性的提速。¹ 不过我肯定不会抱怨，所以我又加了一条约束，至少避免回归：

Additionally, ensure there are **zero `criterion` benchmark speed regressions**: if a speed regression occurs on a given benchmark as a result of the refactor, you **MUST** keep iterating afterwards to improve those benchmarks to atleast zero regression. NEVER hack the benchmarks to accomplish this speed increase, only iterate on the library code.

效果符合预期。

竞争

另一个有用的做法是建立竞争对手基准——这本来就是开源软件里做基准测试的一半理由。拿模板引擎举例：Python 的 Jinja2 是该语言中最著名的包之一。Rust 里有几个选择：同一位开发者维护的 minijinja、受 Jinja2 启发的 tera，以及与前两者不同的 askama——它用的是编译期模板而非运行时模板。

于是，在让 Codex 用 Rust 写了一个模板引擎并跑了几轮优化之后，我指示 Codex 再写一些 benchmark：

Create an additional comparison script containing **atleast 10** `criterion` benchmarks which compare the performance speed and quality metrics between this crate and the following crates:

- askama
- minijinja
- tera

These benchmarks **ALL MUST**:

- be perfectly fair, containing apples-to-apples comparisons of ALL frameworks, with no bespoke advantage for any tested framework
- be based around real-world use cases instead of highly-synthetic use cases
- be independent and distinct, covering as many sailent hot paths of the code as possible
- cover data input sizes small and large, simple and complex

紧接着，我按老规矩用同样的 benchmark 手法追加了一个 prompt，只改了一处：

Then, optimize the Rust library code such that this crate MUST be:

- **atleast 2.0x faster** than **ALL** competing Rust crates in all benchmarks on apples-to-apples comparisons; ideally as fast as possible.

对，我选择了暴力。而且它奏效了，大部分情况下。

S_J 是我的模板引擎 crate 的在研名称。

在大多数 benchmark 里，它相对 minijinja/tera 拿到了 2 倍加速，比单纯的 agentic 迭代效果更好。我并没有完全搞懂原因：我本以为它会去翻其他 crate 的代码，从中找思路来研究怎么打败它们，但它很少这么做。也许 agent 也有好胜心。

不过它在 askama 上输了，原因是编译期差异。于是我很自然地让 Codex 再实现一条编译期路径，然后去打败 askama。

小菜一碟。

禁忌黑魔法

把目前所有的 prompt 工程发现汇总成一个 prompt，我就造出了用于 agentic 迭代的 Ur-Prompt，点此获取。建议大家按自己的场景改一改再试。

最后一个技巧来自某个让我很恼火的时刻：一轮 Ur-Prompt 跑下来，零提升。于是，趁着失败还留在会话上下文里，加上我抱着“再差也差不到哪去”的心态，我试了某个 prompt。

对不起。真的很对不起。

c'mon, try doing a breakthrough

……然后它奏效了。在一个已经收敛的代码库上，它又拿到了 1.2-1.5 倍的累计加速。因为这个 prompt 是在会话末尾发出的，它的歧义天然更小：“别再做你之前做过的事，因为那些做得不够好”。

有一次，我发现 agent 只是调了调函数的超参数就拿到了加速，这确实算一个突破，但不是我想看到的。我把它推到了逻辑终点，追加了一个 prompt：

c'mon, you can do a more fundamental breakthrough that's more than just changing hyperparameters, you are forbidden from giving up easily

这足以促使 agent 去彻底尝试一些不同于 Ur-Prompt 那轮、也不同于第一次突破那轮的做法，往往能在前一次加速的基础上再拿到 1.2-1.5 倍的累计加速。看来对一个被训练来遵循用户指令的软件来说，“只是改改超参数”是一种极大的侮辱，能把 LLM 一脚踹进高挡位。

GPT-6 Astra 发布后，为了测试它，我对所有已经用 GPT-5.6 Sol 收敛过的仓库跑了一遍 Ur-Prompt + breakthrough + second breakthrough。Astra 确实拿到了累积加速，但在某些情况下，它真的找到了算法层面上的根本性重写，带来了 2x-3x 的加速。

在我的 GBDT 实现上跑 breakthrough 流水线的结果；质量与基线持平。写作本文时，我承认自己并不完全理解这个 breakthrough。

加速我收下了，但为了我的精神状态，最好还是别深究。

明显变好的项目实例

Ur-Prompt，加上我 AGENTS.md 里的规则和约束 + 两个 breakthroughmaxxing prompt + 一轮 competition prompt + 一轮 refactor prompt，配合 GPT-6 Astra，让我可以把 prompt 排好队过夜，去睡觉，醒来就是超快的软件。优化通常也会在这个阶段收敛，不再需要更多 agentic 迭代，省时也省钱。话虽如此，这比我想要的更放手，而且其中包含大量明确的信任——相信新 agent 不是特别擅长以我无法察觉的方式作弊。有理由怀疑，也有理由认为代码可能因为重度 vibecoding 而有 bug，所以这里给出一些更偏视觉的项目的凭证，这些项目的输出很容易验证是好的，而不是精心设计的作弊。

ASCII

我脑子里一直有个项目：超高速、高质量地把图像转成 ASCII art，以便将来可能把视频转成 ASCII——一个 webcam-to-ASCII 项目可能挺好玩。今年早些时候 Alex Harri 写了一篇很棒的博客文章，讲一种渲染高质量 ASCII 的新方法，但也指出即使使用 GPU 编程，也很难达到实时渲染速度。为了科学，我把博客文章的文本丢给 Codex 里的各种 GPT 模型，告诉它“用 Rust 实现”，它确实做到了……并且在 CPU 上开箱就跑出了 2-3 ms 的文本输出耗时。然而，Codex 的实现里 ASCII 的主观质量并不好（比如负空间利用很差），而且令人意外的是，即使向 Codex 指出缺陷也修不好，所以我把它搁置了……直到我注意到 GPT-6 Astra 在给定功能需求时更擅长处理图像设计，于是我重新从零开始，把基础实现放进 agentic 迭代流水线，重点放在视觉上确认输出图像。

用我的 ASCII crate 渲染的 Tux 和 Pikachu，并支持盲文字符。

除了质量提升，它还变得更快了：文本输出不到 1 毫秒，图像光栅化即使开启 2 倍超采样也只要 1-2 毫秒。有了这个速度，我可以在不到一秒内把视频和 GIF 转成高分辨率 ASCII 动画。

下载视频。

Pikachu 的第五世代动画精灵图，从 63×55 像素放大到 120 字符宽的 ASCII。

词云

这篇博文本身生成的词云。

这个快得离谱的词云生成器是我最早用 vibecoding 做的项目之一，也是我想做了好几年的项目之一。今年 2 月，这个词云生成器在 WASM 里用默认设置生成一张图大约要 100 毫秒，而其他生成器在同等质量下要花上几秒，这足以让我认定速度优化值得一做。重新拾起这个项目、跑完整个 agentic 迭代流程之后，生成速度一路降到了 10-20 毫秒。

下载视频。

这个世界需要超快的词云生成器吗？不需要。我需要超快的词云生成器吗？不需要。我想要超快的词云生成器吗？想。既然我手里有一个词云生成器，那它就得尽可能快，就这样。而且这个 crate 会开源，以后所有人都能在这个超快词云实现的基础上继续做。说到这个……

我的全部开源计划

和往常一样，我开发这里演示的所有软件时，都打算最终开源，只要不出意外，所有东西都会以宽松的 MIT License 开源。如果是一年前，我早就全部开源了，默认大家都明白代码还在开发中、可能有粗糙的地方。但开源软件开发的氛围和一年前已经大不相同。

开源软件正在经历一场 vibecoding 疫情。坦白承认用了 LLM 做开发辅助（无论多少），如今就是一个快速信号：这个代码库是“slop”。我还是会披露自己的 LLM 使用情况，这是礼貌，但如果完全由 vibecoding 写出的软件真的带来了此前人类不知道的、有实际意义的性能提升，会怎样？围绕 vibecoding 的怀疑会让没人相信这些说法，因此这些新的开源项目需要拿出大量证据，证明速度确实配得上宣传。所以，我会比平时花更多时间再发布，用来 a) 积累真实世界的示例来演示这个工具，尤其是配上文档 b) 扩充测试套件2，覆盖更多真实世界的测试用例 c) 写一篇配套博文，详述技术和基准测试上的成果。

还有一个事实：我是在一个已经挤满热门工具的生态里再造一个工具。我用智能体迭代出来的 Rust crate 之所以能有这么大的速度提升，部分原因是从零开始，因此其中的创新没法轻易回流到已有的 crate 上。而且，如果我基于这些 crate 里的创新去给现有项目提 pull request，那按定义就是一个 vibecoded PR——哪怕我避开了典型的 PR 垃圾，也可能惹人烦。从这个角度看，正确的做法就是维护自己的项目：这是合规，不是恶意的那种。有人会说这反社会，但在我看来更准确的说法是我在此生造的词：内向式编程。

tl;dr 我那些比 SOTA 还快的软件项目，准备好了就会发布，全部做完总共要花好几个月。好在我因为一次重组目前失业，除了找工作没有别的计划，所以有充足的时间全职推进这些项目的发布。想知道什么时候发布，可以订阅我的博客 RSS 源，配套的博客文章会出现在那里，或者在 Bluesky 或 Patreon 上关注我。不，我不在 Twitter/X 上发那种让人抓狂的含糊其辞。

五年前我刚对 Rust 产生兴趣时，梦想是做出性能最强的软件工具。但用上我过去几个月发现的智能体迭代优化技术之后，新软件能达到的速度和健壮性，进展比我预想的还要快。再说一次，欢迎拿我的 AGENTS.md 和 Ur-Prompt 去折腾，看看它们对你是不是也像我一样管用（不过能提一句出处我会很感激！）。如果你觉得我把 prompt 都公开了就没货了，那我袖子里还藏着不止几个惊喜，比如怎么把这些底层项目组合成一个超快的复杂应用，甚至开发新工具帮智能体更高效地找到这类优化。

一种新的 Rust 基准测试方法的半成品，对 agent 更友好，并配有一个用于读取和管理结果的 TUI。

我确实在一个纯 Python 项目里测试了重构提示词，因为 Python 是解释型语言。它在某些基准测试上仍然带来了两位数的百分比提速，这只会引出更多疑问。 ↩︎
顺带一提，这些由 agent 写出来的代码仓库，测试基础设施会比我所有那些受欢迎的人工编写的 Python 包（零）都要好。 ↩︎