这周只讲一条。arXiv 上八月十三号挂的一篇论文，让大模型把 C 代码翻译成 Rust。
为什么值得单独一期？因为 C 转 Rust 这个题目，天然带着一个判断题。搬过去不难，难的是搬得像 Rust。一堆 unsafe 包着的 Rust，本质上还是 C，只是语法更啰嗦了。所以真正的问题是：AI 翻出来的东西，算不算数。
论文的做法分三段。先继续预训练，喂一堆 C 和 Rust 代码。然后做调试感知的监督微调，数据集叫 Verus_Training_Data。最后拿 LeetCode 的配对数据再微调一轮。
三段流程本身我不觉得新鲜。让我想写这期的，是它评估的那部分。
它没有只看“翻译完的代码能不能跑”。它用了一个叫 SACTOR 的框架，做两阶段的结构感知翻译，再通过外部函数接口做端到端测试。这些词绕，白话版：不光看结果对不对，还看翻译的姿势对不对。
具体看什么？两个指标。Clippy lint 的数量，unsafe 代码的占比。
这两个指标选得好。Clippy 是 Rust 官方的惯用写法检查器，lint 越少，说明代码越像人写的 Rust，而不是机器逐句搬过来的 Rust。unsafe 占比就更直接。Rust 的全部意义在内存安全，翻完满篇 unsafe，等于把新家的门锁全拆了，然后跟人说你搬家了。
补充一句，论文里还有失败模式的分析。这点我给好评。同类工作很多只报成功率，翻挂的例子一概不提。愿意把翻车现场摆出来的，可信度天然高一截。
基线是 Qwen3-27B，另外拉了几个别的大模型在同一个框架下比。微调过的比没微调的强，这个不意外。我更在意它和更大的通用模型比怎么样。论文里给了数，具体多少建议自己去翻，我转述数字容易错位。
坦白说，这篇我只消化了七成。中间那段调试感知的微调，具体怎么个感知法，我没吃透。先放在这里，搞明白了再补。
说完论文，讲我真正想说的那口气。
普通人看到“C 翻译成 Rust”，第一反应多半是这跟我有什么关系，我又不写 C。我原来也这么想。后来发现不是。
这个研究真正示范的东西，是怎么判断 AI 干的活算不算数。AI 写代码这件事，“能跑”是最便宜的标准，便宜到快没意义了。真正的问题永远是：它是不是用对的方式跑起来的。论文用 Clippy lint 数量和 unsafe 占比回答这个问题。你手上没有 Rust 项目，思路也可以抄。AI 替你写了个脚本，别光看跑通了，问它一句为什么这么写，或者换个输入再跑一遍。验证的手艺比生成的手艺稀缺，这个话我之前收过一次，这次算是又找到一个例子。
还有一个点。这篇走的是微调路线，不是拿最大的模型硬怼。一个 27B 的模型，喂对了数据，在一个具体任务上就能跟更大的模型掰手腕。这对预算有限的普通人是个好消息。你不需要最贵的那档订阅才能干活，你需要的是一个足够窄的任务和足够对的数据。窄任务上加功夫，比宽任务上堆参数划算，这个判断我愿意站。
当然也别高兴过头。C 到 Rust 是个边界特别清楚的任务，输入输出明明白白。你手上那些“帮我做个能看的东西”的模糊需求，是另一回事。任务清楚的时候 AI 是翻译工，任务模糊的时候它得替你想。两种活，难度差着量级。
本周就这些。
上面任何一条你试过、或者觉得我讲错了，欢迎告诉我。那篇论文要是有人读得比我细，特别是中间那段微调，回来给我讲讲的，更欢迎。
下周见。