EvoC2Rust 深度排障与修复流水线优化：突破 73% 通过率

在上一阶段的实验中，EvoC2Rust 的三级修复流水线将 c-algorithms 项目的函数体编译通过率从 54.50% 提升至 73.00%，但仍有 54 个函数体未能通过翻译验证。这挡在通往全自动 Rust 化路径前的 27%，其核心障碍并非翻译能力的缺失，而是更深层的类型系统抽象失配。本章我们将使用 OpenCode 编码智能体对失败日志展开系统性诊断，定位根因并设计针对性修复方案。

1. 失败根因深度剖析：Ptr<T> 泛型抽象层的类型坍缩

将未通过测试的 54 个函数体导入 OpenCode 进行结构化分析，错误分布呈现出显著的聚类特性，根源指向框架为绕开 Rust 所有权模型而引入的 Ptr<T> 指针抽象层。

1.1 错误频谱与根源追溯

上述错误的共同根源在于：EvoC2Rust 采用 Ptr<T> 对底层裸指针进行安全封装，LLM 在翻译函数体时，须根据上下文精确推断泛型参数 T 的具体类型。一旦 T 被误推断为 i32 等占位类型，所有依赖于结构体字段的访问表达式（如 .children）便会直接失效，触发 E0609 系列错误。这是典型的类型信息沿翻译管线衰减问题——C 侧的类型名称与 Rust 内部结构体之间的符号映射在类型别名与多级包装中逐渐丢失。

2. 优化尝试与预期偏差：从提示词工程到模型切换的多次迭代

基于上述诊断，我们尝试了一系列有针对性的修复增强措施，旨在提升 LLM 修复阶段的上下文保真度：

1. 修复提示词重构：在 repair_prompt 中注入 E0609 与 E0599 (缺失 Default) 的修复示例，并移除存在误导性的 .cast() 错误模式。
2. 自动化规则注入：编写 derive 规则代理，自动检测 E0599 错误并为类型附加 #[derive(Default)]。
3. 修复域扩展：将 LLM repair 的作用范围从函数体扩展至 definition（类型定义），力图在源头矫正错误类型映射。
4. 迭代深度倍增：将 max_trial 由 3 提升至 5，赋予修复流水线更多试错机会。

然而，完整重跑修复流水线后，通过率顽固地停留在 73%，没有任何改善。后续对 Python 修复脚本流程本身的改进尝试同样石沉大海。进一步的对照实验显示，将 LLM 模型从原本的 v4-pro 降级为 v4-flash 后，通过率反而锐减至 50% 以下，反向验证了模型推理能力的下限效应，但同时也排除了“模型能力不足”作为瓶颈的主要原因——问题不在模型的生成质量，而在于输入它面前的符号上下文本身就是混乱的。

3. 启用深度思考模式

在 OpenCode 中启用 DeepSeek V4 的深度思考模式时，意外触发了 reasoning_content 的上下文传递缺陷——OpenCode 默认不会在多轮对话中回传模型上一轮的思维链，导致思考模式服务中断。通过查阅社区方案（GitHub Issue #6040），我们在自定义 Providers 配置中添加 "interleaved":{"field":"reasoning_content"} 字段，成功修复了该问题。随后开启 xhigh 级别的深度思考，让模型对失败日志进行链式推理。

根本症结：typedef 条目的重复结构体生成。

C 语言中的一对经典模式：

struct _SortedArray { ... };           // 条目1: 带字段的真实结构体定义
typedef struct _SortedArray SortedArray; // 条目2: 类型别名

LLM 在翻译条目2时，错误地生成了一个空的结构体壳 pub struct _SortedArray {}，同时再生成 pub type SortedArray = _SortedArray;。这个空壳与条目1翻译出的真实结构体发生同名冲突，导致 Rust 编译器在整个编译单元内将 _SortedArray 的类型错误地解析为空结构体，进而泛型参数 T 在推断时退化到 i32 占位符，使所有依赖该类型的字段访问操作全部失败。

数据验证：精确命中 8 个关键类型——SortedArray、AVLTree、HashTablePair、SListEntry、Queue、BloomFilter 等。这 8 个 typedef 条目产生的名字污染，直接解释了报告中 93 个 E0609 错误的由来。

4. 系统化修复

基于根因发现，opencode制定了一套分阶段修复，目标是逐步将函数体通过率推向 100%：

其中 Phase 2 的后处理脚本作为确定性规则过滤器，在 LLM 修复阶段之后运行，从符号层面根治污染。Phase 3 与 Phase 4 则转向更细腻的语义校准，必要时注入少量人工干预以完成闭环。

5. 当前进展与工程反思

目前修复流水线因 max_trial 翻倍导致执行时间显著拉长，正在恢复至原始配置后重新发起 Phase 1→Phase 2 的修复流程。本次深度排障过程揭示了一条重要经验：在基于 LLM 的代码翻译系统中，错误往往并非源于模型“不够聪明”，而是输入到模型中的符号上下文已经被管线自身污染。只有通过严格的元数据溯源与确定性后处理，才能打通类型信息从 C 抽象到 Rust 具象的完整链路。

待流水线修复完成，我们将输出 Phase 2 之后的最新通过率数据，并详细评估空结构体剔除策略的实际收益。