资讯 · 改写稿
用 LLM 把 TypeScript 编译器移植到 Rust：40 万美元的教训
结论先给：同一个移植任务，第一次花了 40 多万美元仍卡在约 84% 兼容，换模型从头重写后，两周约 2.4 万美元就出了可用版本——贵的往往不是模型，而是路线。
来源开篇就说清楚了动机：想知道 LLM 能不能把 TypeScript 的编译器、类型检查器和语言服务器（LSP）移植到 Rust——顺便得到一个更快的类型检查器、一个能在 WASM 里跑的高性能检查器，以及一点「看看模型到底行不行」的好奇。
第一次：40 多万美元，卡在 84%
来源先用了一批 OpenAI 模型（GPT-5.6 Sol 与 GPT 6 Astra），跑了好几个月的 /goal 循环，写出130 万行以上的 Rust，累计消耗的 API 计价 token超过 40 万美元，但兼容度一直没能超过约 84%。
第二次：换个模型从头重写
转折来自一次观察：他发现自己 Claude 套餐的额度几乎没怎么消耗，于是把 Opus 5.5 也丢进这个任务。结果是10 小时就有了可用的 v0。更关键的是，他本以为新模型会复用前一轮写好的代码——并没有，Opus 5.5 是从头开始的，而且用 1/10 的时间走到了比之前更远的地方。继续跑下去，两周的 API 花费约 24,047 美元。
本站计算——把两次的成本并排：400,000 ÷ 24,047 ≈ 16.6 倍。来源还提到，这轮换算下来约等于其 $200 套餐周限额的 925% 到 983%，也就是说他实际是靠把多个账号的额度用满才顶下来的——这也解释了为什么「订阅套餐的限额」和「API 计价 token」是两笔账。
来源自己的提醒
这个项目带着一串很坦白的警示：属于早期版本；作者自称在测过的真实项目里达到了 100% 兼容，可以当作绝大多数应用的替换；但同样据其自述，他一行代码都没读过。这类「让模型自己跑、人来验收结果」的做法，收益和风险都很极端——省下的是人力，压上的是可维护性。
以为换模型会复用前一轮的代码：来源说 Opus 5.5 是彻底从头重写的。
把「订阅套餐额度」和「API 计价 token」混为一谈：两笔账差着数量级。
只看结果不看维护：来源直言自己一行代码都没读过，这本身就是一个风险点。
自检清单
常见问题
这个项目做了什么？
来源尝试用 LLM 把 TypeScript 的编译器、类型检查器和 LSP 移植到 Rust，目标是得到更快的类型检查器，以及能在 WASM 中高性能运行的版本。
两次尝试的成本差多少？
来源称第一次用 GPT-5.6 Sol 与 GPT 6 Astra，累计超过 40 万美元的 API 计价 token；第二次改用 Opus 5.5，两周约 24,047 美元，前者约为后者的 16.6 倍。
第二次为什么要从头重写？
来源本以为是复用前一轮代码，但实际是 Opus 5.5 从零开始；它在 10 小时内产出可用 v0，并用约 1/10 的时间超过了此前进度。
这个版本能直接用吗？
来源称属于早期版本，在其测过的真实项目里达到 100% 兼容、可当作大多数应用的替换；但作者也自述从未读过其中任何一行代码。
来源参考
以上为外部来源；本文为 RefHub 用自己的结构重写，事实以来源页为准，价格与政策会变，请回源核对当日。