零散逆向代码重建为可编译工程

要解决的问题

逆向工作产出的代码往往不是一份干净仓库：你拿到的是按函数切散的片段、C 与 Python 混写的伪代码、缺头文件少声明的函数体，甚至夹着一段 ASM 内联。这些碎片彼此引用却对不上接口，构建系统更是无从谈起。手工整理很容易陷入「改一个符号引发十个错误」的循环，最后连最小的可编译子集都拼不出来。

project-rebuild-skill 要处理的就是这个从碎片到工程的中间层：把盘点、接口推导、构建选型、骨架搭建、编译纠错串成一条可重复的流水线，而不是靠一次性灵光一现。

核心能力与工作流程

技能按六个阶段推进：

• 碎片盘点与分类：按语言、模块、依赖关系聚类碎片，记录每个片段的来源，并标注置信度与缺口。
• 接口与依赖推导：提取外部调用，推导缺失的函数签名与类型，产出 deps.dot 依赖图。
• 构建系统选型：按目标语言推荐方案，如 C/C++ 用 CMake，混合语言则分层构建再加桥接封装。
• 骨架搭建：建立 src/、include/ 目录，生成构建配置与入口，把碎片归位。
• 编译纠错迭代：先跑首次编译收集错误清单，补 stub、修正类型签名，循环直至通过。
• 运行验证与交付：产出 BUILD_REPORT.md 记录重建率与未还原清单。

适用边界与注意点

几个值得写在最前面的前提：

• 合法性：只用于自有或已获授权代码的恢复重建。
• Stub 管理：未知依赖以声明或桩函数形式补齐，必须标注来源。
• 行为验证：编译通过不等于行为正确，需用已知输入对比输出。
• 渐进整合：先让最小子集编译通过再逐步扩大，避免一次性大爆炸式重构。