EvoC2Rust 编译修复与 OpenCode 智能体深度增强

在上一阶段的深度排障中，我们成功锁定了阻碍函数体通过率跨过 73% 天花板的根本原因——typedef 条目产生的空结构体壳在符号层面引发了 Ptr<T> 泛型参数的类型坍缩。然而，由于此前调试过程中反复修改 max_trial 参数并遗留了大量交叉引用的缓存文件，导致流水线执行频繁触发超时与依赖混乱。为彻底排除环境干扰，我们决定从零构建一个干净的 EvoC2Rust 工作目录，并在此之前进一步强化 OpenCode 编码智能体的基础能力，以更精确地辅助对翻译失败的诊断与修复。

1. OpenCode 能力基座加固：Skills 生态与插件体系的实践验证

1.1 ohmyopencode 的引入与适配失败

为提升 OpenCode 的配置管理与工作流编排效率，我们首先尝试引入社区生态中的 ohmyopencode。ohmyopencode 是一套面向 OpenCode 的即开即用型增强套件，其定位类似于 Oh My Zsh 之于 Zsh——它提供模块化的脚本管理、预设的工作流模板、以及集中的 Skills 与 Rules 配置框架，能够使开发者无需从零编写规则即可快速获得强大的领域适配能力。然而，在安装完成后，系统持续抛出异常错误。经排查，ohmyopencode 的核心插件体系对 Anthropic Claude API 存在强依赖，其内部许多自动化流程（如文件摘要、长上下文压缩）硬编码了 Claude 特有的消息格式与模型行为。在全局配置中全面切换至 DeepSeek 后端并不能消除此兼容性屏障，最终我们选择卸载该组件，转而直接调用 OpenCode 的原生 Skills 与 Rules 机制进行手动强化。

1.2 面向 C→Rust 翻译的 Skills 矩阵构建

绕过 ohmyopencode 后，我们从 OpenCode 社区 Skills 仓库中精选并加载了一组高度相关的技能文件，构建起一个精准面向 C→Rust 翻译任务的技能矩阵。已安装技能列表及其说明如下：

Skill	用途
create-skill	创建可复用的 Skill 工作流文件 (SKILL.md)，沉淀领域知识
port-c-module	C 模块到 Rust 模块的系统化移植指南，涵盖接口映射与所有权转换
rust-expert	Rust 语言专家：深度掌握所有权、生命周期、async/await、Trait 与 unsafe 语义
rust-patterns	惯用 Rust 模式：错误处理、并发模型、性能敏感场景的最佳实践
rust-review	Rust 代码审查：unsafe 安全性审计、文档完整性评估、C-to-Rust 翻译语义保真度校验

这一技能组合将 OpenCode 从通用编程助手提升为C→Rust 翻译领域的专用推理与审查引擎，为后续的全项目编译错误修复提供了坚实的语义理解底座。

2. Plan A：强化技能加持下的 EvoC2Rust 全流水线重执行

在全新的 EvoC2Rust 目录下，我们启动翻译流水线，使用 c-algorithms 项目（19 个 .c 文件 + 19 个 .h 文件，约 5,000 行代码，涵盖红黑树、AVL 树、二项堆、哈希表、布隆过滤器等高复杂度数据结构算法）进行测试。在流水线执行前，我们对即将处理的 C 项目特征与 EvoC2Rust、OpenCode 独立翻译两种范式进行了能力差异评估：

维度	EvoC2Rust	强化后 OpenCode (独立翻译)
编译成功率	高 (~80%+，基于流水线自动化修复)	较低（跨文件依赖与上下文窗口限制）
代码质量	中（Ptr<T> 非惯用，本质为 “C 写法的 Rust”）	高（真正的所有权/借用语义，Option<Box<>> 替代 void*）
安全代码占比	中（Ptr<T> 内部封装 unsafe）	高（几乎全为 safe Rust）
完整度	低（TODO 空函数被原样翻译为死代码）	高（可主动补全缺失实现，如 rb_tree_remove_node）
可重复性	高（一键运行标准化流水线）	低（长上下文导致需多次会话迭代修复）

基于此评估，Plan A 选择以 EvoC2Rust 流水线为主路径，将 OpenCode 的 Skills 强化能力应用于流水线后的全项目编译错误修复，以在工程化可重复性的基础上逼近更高质量代码。

2.1 翻译流水线执行结果

全流水线执行完毕后，获得以下阶段性指标：

EvoC2Rust 翻译流水线: c-algorithms (38 文件 C → Rust)

阶段	增量编译通过率
1. 元数据提取	✅ 骨架编译成功
2. LLM 翻译生成	529 个翻译产物文件生成
3. 括号修复	function: 83/200 (41.5%)
4. 规则修复	function: 103/200 (51.5%)
5. LLM 修复	function: 135/200 (67.5%)
6. 增量编译验证	确认 67.5%
7. 全项目编译	❌ 72 errors + 673 warnings

尽管 67.5% 的函数体在增量编译验证中通过，但将全部模块整合进行全项目编译时，仍然产生了 72 个错误 与 673 个警告。错误分类如下：

错误类别	数量
Ptr<T> 字段访问错误	~20
宏/常量命名冲突	~12
类型/导入缺失	~8
重复定义	~5
类型不匹配	~10
其他	~17

核心瓶颈依然围绕 Ptr<T> 类型系统：流水线生成的代码将 Ptr<T> 当作拥有 .children 等字段的裸指针去使用，而实际 Ptr<T> 封装要求通过 inner 等方法间接访问数据，导致大量 E0609 类错误。

2.2 OpenCode 深度修复：72 错误 → 9 错误（降低 87.5%）

鉴于此前直接修改 EvoC2Rust 内部修复提示词的效果有限，本次我们采用“外部修复”策略：将全项目编译产生的 72 个完整错误列表直接交付给经过 Skills 强化的 OpenCode，启用 DeepSeek V4 最高级别的深度思考模式（xhigh），对错误进行分阶段修复。

修复分为三个串行阶段：

• Phase 1：机械修复 — 自动补充缺失的 use 导入、移除冗余的 mut、修正简单的语法冲突。
• Phase 2：Ptr 字段访问修复 — 识别所有对 Ptr<T> 的直接字段访问，将其转换为符合 translation_utils 库封装的方法调用。
• Phase 3：语义修复 — 处理类型不匹配、Trait 约束缺失等需要上下文推理的复杂错误。

经过逾二十分钟的深度思考与自动迭代修复，最终将全项目编译错误从 72 个压缩至 9 个，降幅达 87.5%。剩余 9 个错误分布如下：

错误位置	占比
translation_utils/ 模板工具库层级	多数
src/src/ 生成代码层级	少数

这 9 个残余错误大多触及 translation_utils 内部底层类型系统的设计哲学——如 Null、CastInto、CastFrom 等 Trait 的深度实现细节，需要对该模板库的抽象层有全面理解才能安全消解。

3. 阶段性结论与后续展望

本次实验通过环境清洁、Skills 矩阵构建和 DeepSeek 深度思考模式的组合应用，将 EvoC2Rust 翻译产物从全量编译失败的状态推升至仅剩 9 个底层类型系统错误的水平。这一过程充分证明：将自动化翻译流水线与高度定制的智能体推理能力结合，能够在对流水线内部逻辑零侵入的前提下，显著提升最终产物的编译通过率与代码质量。

下一步，我们将继续利用 OpenCode 深入处理这 9 个底层错误，并同步启动 Plan B——由强化后的 OpenCode 完全独立重构 c-algorithms 的核心模块，以对比两种路径在代码安全性、惯用度与完整度上的最终差异。通向 100% 编译与语义保真 Rust 代码的旅程，正进入最终的攻坚阶段。