谷歌用AI将C库迁到Rust：如何验证代码可靠性？

2026 年 9 月 28 日 · IT/AI 热点观察

AI 写代码越来越快，老系统能不能跟着“一键升级”？今天筛选技术热点时，Google 用 Gemini 辅助把 GIF 图像库 giflib 从 C 迁到 Rust 的案例很值得读。它把一个现实问题摆到了台前：生成代码之后，我们拿什么证明它可以接替旧代码？

先说明时间：Google 原始文章发布于 2026 年 8 月 24 日，InfoQ 于 9 月 27 日作了报道。本文是对近期热点的梳理，不是把旧案例写成今天刚发布的新产品。

Google 做了什么？

据 Google 原文，团队选中了约 3,000 行、代码稳定的 giflib：先让 Gemini 生成 Rust 初版，再修正与 C 调用方衔接的接口层，由专家审查不安全代码，并把测试发现的问题反馈给模型。验证覆盖了超过 3,000 万张 GIF；差分模糊测试连续运行超过六天、完成超过 2 亿次迭代。来源：Google Bug Hunters。

这是一项有明确对象和验证条件的试点。阅读时可以把“生成得快”与“替换得可靠”分开看：前者是产出速度，后者需要工程证据。

仓库里的边界，比标题更值得读

giflib-rs 的 README写得很直接：业务逻辑不使用 unsafe，但提供 C API、处理 C 指针仍需要 unsafe。项目还列出了无效尺寸、写入失败和内存分配失败等已知行为差异。若不要求兼容旧 API，作者建议使用另一款 gif crate；该项目也不属于 Google 官方支持的产品。

这些说明提醒我们，评估替代组件时，不能只问“是不是 Rust 写的”。还要问：原来的调用方依赖了哪些行为？失败时返回什么？哪些变化属于主动修正，哪些变化会让现有流程出错？

差分测试，普通开发者也能理解

可以把它想成让两位厨师收到同一张订单，再逐项比较出餐结果。放到程序里，就是让旧实现和新实现接收同一份输入，比较输出与错误处理。遇到不一致，先定位原因，再决定修正新实现、保留差异，还是调整调用方。

下面是一组用于理解方法的假设测试，不是 Google 公开测试集：

• 正常文件：比较解码结果、尺寸和帧数。

• 损坏文件：比较是否拒绝输入、如何报告错误。

• 边界输入：检查空数据、异常尺寸和资源不足时的行为。

• 真实调用：检查上层服务能否继续处理成功结果和失败结果。

比较不一致并不总意味着新实现有错，旧实现也可能有缺陷。因此，验收标准应当写清楚哪些行为必须保持，哪些修正允许改变。

我的建议：先把验收问题交给 AI，再交迁移任务

对于维护业务系统的团队，我更建议从一个边界清楚的小模块开始。先整理调用入口、输入输出、错误约定和已有测试，再决定是否需要迁移。已有成熟组件能满足需求时，直接复用往往更省事。

可以用下面这段提示词启动讨论：

请先阅读这个模块和所有调用方，列出必须保持的输入输出、异常行为与资源释放规则。先不要修改代码。请找出已有测试缺口，给出最小验证方案，并区分“应保持的历史行为”和“需要人工决定的缺陷修正”。

等验收条件清楚后，再让 AI 完成一小步实现，运行检查并审查差异。上线前明确负责人和回滚路径；如果无法确认行为差异的影响，就先缩小改动范围。

这个案例给我的启发是：随着生成成本降低，团队更需要把“如何判断做对了”写清楚。对开发者来说，设计验收条件、识别兼容性边界和解释测试结果，会越来越有价值。

资料核对日期：2026 年 9 月 28 日。本文依据公开资料整理，未独立复现 Google 的迁移与测试结果；文中实践建议为作者分析。封面由 AI 生成，为概念示意图。