EvoC2Rust 本地化部署与实验验证（续）：编译修复流水线、缓存一致性诊断与项目生成

在上一阶段的实验中，我们成功驱动 EvoC2Rust 完成了元数据提取与 LLM 翻译两大流水线，将 c-algorithms 示例项目中的 29 个宏、95 个类型定义、200 个函数签名及 200 个函数体从 C 映射为 Rust 中间表示，并转入了编译修复流程。本文将深入剖析修复阶段的三级串行机制、验证环节的缓存一致性问题，以及最终 Rust 项目的生成与编译验证结果。

1. 第三阶段：分级编译修复流水线

EvoC2Rust 的修复阶段并非单一的一轮 LLM 纠错，而是被设计为三级串行修复流水线（3a 括号修复 → 3b 规则修复 → 3c LLM 修复），每一级针对不同粒度的语法与语义错误，在最小化 API 消耗的同时逐步提升代码通过率。修复效果通过每次修复后对宏、类型定义、函数签名及函数体四类实体的编译通过测试进行量化评估。

1.1 3a 级——括号修复（Bracket Fix）

括号修复阶段主要依赖确定性算法对未配对括号、错误的 delim 结构进行本地化修正，仅在复杂情况下触发 LLM 辅助决策。该阶段运行结果如下：

• 宏 (macro)：通过率 96.55% (28/29)，无需触发 LLM。
• 类型定义 (definition)：通过率 93.68% (89/95)，零 LLM 调用。
• 函数签名 (dummy_function)：通过率 98.00% (196/200)，纯规则修复即达到高位通过率。
• 函数体 (function)：通过率仅为 54.50% (109/200)，成为本轮修复的瓶颈，表明大量函数体存在超越括号匹配范畴的语法或语义问题。

1.2 3b 级——规则修复（Rule-based Fix）

3b 阶段引入确定性规则库，专门处理铸造（casting）语义差异、可变引用借用（borrowing）规范、以及 Rust 所有权模型所要求的显式注解等 C 语言中不存在的概念。该阶段同样优先使用无调用成本的确定性变换，仅在规则无法覆盖时保留错误供下一级处理。

经过规则修复，函数体通过率由 54.50% 提升至 62.00% (124/200)，其他实体类别通过率保持不变（因它们已在 3a 阶段接近饱和）。这验证了规则修复在补充语言特性差异方面的有效性，函数体仍遗留的结构性与逻辑性错误则交由最终级 LLM 修复处理。

1.3 3c 级——LLM 修复（LLM Repair）

作为修复流水线的最后一级，3c 阶段调用大型语言模型对前两级未能消除的剩余错误进行语义分析和上下文感知的修复。该阶段需要对每个失败函数生成修复提示并应用补丁，因此耗时最长，但能解决前两级确定性方法无法处理的逻辑错误与类型不匹配问题。

LLM 修复完成后，函数体通过率进一步提升至 73.00% (146/200)。综合来看，三级修复流水线将函数体通过率从初始 54.50% 拉升了 18.5 个百分点，充分体现了“规则尽可能、LLM 补其缺”策略在控制 API 成本与修复质量之间的良好平衡。

2. 第四阶段：验证环节的缓存一致性问题分析与修复

按照框架的既定流水线，第四阶段 verify 应对最终缓存中的翻译产物进行全量编译验证，以保证输出指标与最新修复状态一致。然而，实际运行时验证脚本报告的函数体通过率仍为 54.50%，与 3a 阶段完全相同，明显陈旧。

通过审查 verify.py 源码，定位到第 21 行所引用的缓存路径为 delim_fix 阶段之前的旧缓存（即第二步 LLM 翻译之后的原始缓存），而非 3c 阶段 LLM_repair 生成的最新缓存。delim_fix 目录内包含的 old_cache 正是指向该旧缓存的符号链接，这导致验证模块读取的是未经任何修复的初始翻译结果。

进一步核实发现，LLM_repair 目录中的 new_cache 才是经历三级修复之后的最新产出。该缓存同样被最终的第五阶段项目生成脚本所使用，这解释了为何原作者可能未察觉验证阶段的异常——项目生成仍然使用了正确的最新的缓存，输出结果无受影响。

为确保验证指标与最终产物一致，我们将 verify.py 的缓存引用修正为 LLM_repair/new_cache。修正后重新运行验证脚本，结果与 3c 阶段完全吻合——函数体通过率 73.00%，宏、定义与函数签名接近 100%，证实了修复流水线的实际效能。

3. 第五阶段：完整 Rust 项目生成与编译验证

通过验证后，启动第五阶段脚本，将翻译缓存中的所有 Rust 源码、模块声明以及构建配置文件（Cargo.toml）生成为完整的 Rust 项目，目标输出位置为 final_project/c-algorithms/。

全流水线执行摘要：

阶段	结果
1. 元数据提取	C 解析 → Rust 骨架（编译通过）
2. LLM 翻译	29 宏 + 95 类型 + 200 函数签名 + 200 函数体
3a. 括号修复	函数体通过率 54.50%
3b. 规则修复	提升至 62.00%（casting/borrow 规则修正）
3c. LLM 修复	提升至 73.00%（146/200 函数通过）
4. 验证	修正缓存后确认 73.00% 通过率
5. 项目生成	输出 final_project/c-algorithms/

最终 Rust 项目位于 final_project/c-algorithms/。使用 cargo build 进行编译验证时，编译器报告了若干错误，主要集中在**命名重定义（name redefinition）**问题——部分模块或函数名在翻译过程中产生了冲突。这类错误与 3c 阶段后仍存在 27% 未通过函数体密切相关。

进一步分析显示，仍有相当数量的函数体在类型标注、生命周期参数、所有权语义等维度上未完全符合 Rust 的严格检查，而 LLM_repair 流程在校验逻辑上倾向于优先消除语法错误，对跨模块的符号解析与重名冲突处理能力有限。这表明当前的修复流水线在跨文件语义一致性和Rust 特性地道的转换上仍需进一步增强，人工干预在此阶段仍是弥合最后差距的必要手段。

4. 讨论与改进方向

本次本地化实验完整遍历了 EvoC2Rust 从元数据提取到项目生成的全流程，取得以下关键发现：

1. 三级修复流水线的有效性：通过将错误修复拆解为确定性括号修复、规则修复和 LLM 语义修复，框架在控制 API 成本的同时实现了函数体通过率 18.5 个百分点的提升，验证了混合修复策略的工程价值。
2. 缓存一致性的工程陷阱：验证脚本读取旧缓存的缺陷虽未影响最终项目生成，但揭示了在多阶段流水线中确保元数据溯源与缓存版本一致的重要性。此类问题需通过严格的流程编排与自动化兼容性检查来规避。
3. Rust 语义鸿沟的挑战：即便经过三级修复，仍有 27% 的函数体未能通过编译验证，说明从 C 的弱类型、手动内存管理范式到 Rust 的所有权、生命周期和类型安全范式之间存在深层语义鸿沟。单纯依赖当前 LLM 的“修复”能力还不足以完全弥合此差距，未来需要引入更精细的语义映射规则、领域特化的提示词工程，以及人工在回路（Human-in-the-loop）的质量把关机制。

后续工作将聚焦于优化 LLM_repair 的提示策略，尝试引入符号表级上下文以消除跨文件重定义错误，并结合 OpenCode 的 Skills 体系封装领域知识，逐步提升全自动翻译的编译通过率，向 SDAA 驱动运行时这类大规模系统软件的 Rust 化改造稳步推进。