一名开发者用约 5 周的晚上和周末，做出了一个 Rust 版 RAR 实现：rars。它已经发布为开源命令行工具，可以通过 cargo install rars-cli 安装。

这个项目最反常的地方，不是“AI 写了很多代码”。而是 RAR 这种缺完整规格、历史包袱重、还牵涉授权边界的格式，过去更像长期体力活。现在，OpenAI Codex 5.5 和 Claude Opus 4.7 把它推进到了可用阶段。

但别急着把它理解成 WinRAR 替代品。项目说明里也写得很清楚：rars 能工作，覆盖了不少功能，可速度慢数倍，压缩率通常比 WinRAR 差 5%-10%。代码约 5.5 万行，作者也承认臃肿。token 成本约 40 英镑，但这是 heavily subsidised tokens，不能直接当商业开发成本。

我更在意的是另一个问题：LLM 到底把逆向工程的哪一段压短了，又把风险挪到了哪里。

rars 难做，不是因为 Rust 难写

RAR 不是一个文档完备、实现自由的现代格式。官方 unrar 有源码，但授权并非真正自由软件；完整规格文档也长期缺位。

这意味着开发者不能照着一份标准文档把代码写出来。更现实的路径是拼图：从 unar、libarchive、UNRARLIB、网页资料和社区经验里重建规格，再用旧版 RAR 二进制、Ghidra、DOSBox-x、十六进制比对去补洞。

RAR 的复杂度还来自历史。它有多个版本，涉及压缩、多卷、恢复记录、加密等功能。一个实现如果只解最简单的文件，意义有限；一旦碰到老档案和边角格式，坑就会浮出来。

rars 目前的状态大致可以这样看：

维度rars 当前表现现实判断
功能覆盖支持压缩、恢复记录、加密、多卷等大量功能覆盖面不小，对老档案处理有价值
压缩率通常比 WinRAR 差 5%-10%可用，但谈不上追平
性能慢数倍不适合直接放进高吞吐生产链路
代码规模约 55k 行，作者称臃肿产出快，技术债也来得快
成本token 成本约 40 英镑有补贴背景，不能外推为真实商业成本

所以，这个项目的价值不在于“替代 WinRAR”。更准确地说，它给了开源工具和数字档案维护者一个新的自由软件路径。遇到旧 RAR 1.3、1.4，或者现有工具支持不稳的历史压缩包时，多一个实现，就少一层锁定。

这类工作过去像愚公移山。现在山还在，但铲子变快了。

LLM 写代码，测试负责把它拉回现实

项目里的模型分工很有代表性。Codex 更常负责按规格生成 Rust 代码，尤其适合大段、重复、可验证的实现工作。开发者还用到了 OpenAI 的 /goal 长任务循环，让模型连续跑 6 小时以上，甚至一次跑到 16 小时。

Claude Opus 4.7 的角色更像讨论对象和审稿人。它更多参与策略、评审、文档整理和测试组织。

但真正让项目没有滑向“看起来能跑”的，是测试。开发者用测试夹具、兼容性回归、真实 RAR 文件、benchmark 和 oracle 去校准规格。模型可以生成解释，也会生成幻觉；只有让代码碰到真实文件，问题才会暴露。

项目说明里有个细节很有价值：Codex 曾清掉经过多轮审查后仍残留的幻觉规格。这不是在证明模型会自我纠错，而是在提醒一件事：单靠模型互评不够。测试数据才是硬边界。

这里还要看授权和安全风险。规格研究过程中曾出现 WinRAR 注册绕过相关内容，后来作者把它从 git 历史中移除，并决定不实现相关功能。

对企业团队来说，这个细节比“5 周做完”更重要。LLM 会加速逆向，也可能把不该进入代码库的材料带进上下文。法务、安全和开源合规不能事后补票。

对开发团队和档案维护者，动作不一样

这件事对不同读者的影响不一样。不能把它一概写成“AI 程序员成熟了”。目前更稳的判断是：LLM 已经很适合承担大量可测试实现工作，但项目方向、架构取舍、授权红线和纠偏仍要靠人。

读者应该怎么做不该怎么做
软件开发者把 LLM 用在规格转代码、测试补齐、兼容性回归上不要把模型输出直接当可信规格
工程管理者预算要从“人天”转向测试资产、审查流程、上下文管理不要把 40 英镑 token 成本当外包报价
开源工具维护者可把 rars 作为补充路径，尤其用于老档案和兼容性研究不要急着替换成熟工具链
数字档案维护者可以观望并积累测试样本，验证真实历史文件覆盖率不要把单个实验当长期维护承诺

对开发团队来说，流程会变。过去逆向工程的瓶颈在手工阅读、重写和验证。现在瓶颈更像三件事：规格能不能沉淀，测试够不够硬，审查能不能守住边界。

如果团队真要参考 rars 的路线，最该补的是测试夹具，而不是先买更多 token。没有真实样本、回归用例和性能基准，模型只会更快地产生更多不确定代码。

接下来要看的变量也很具体。

第一，性能能不能追上来。慢数倍不是小问题，它决定 rars 能否从研究工具走向日常工具。

第二，真实世界 RAR 文件兼容性是否稳定。尤其是旧版本、损坏文件、多卷包、加密包和恢复记录。

第三，社区是否愿意维护这 5.5 万行代码。AI 可以把项目推到第一个可用点，但长期维护不是一次长任务循环能解决的。

如果这些变量没有改善，rars 更像一次漂亮的工程实验。如果测试、性能和维护跟上，它才可能成为数字档案领域少见的自由 RAR 工具。