AI 辅助 Rust 项目重构让模型理解上下文后做安全的批量修改的方法一、重构恐惧症与 AI 的第一缕阳光我第一次面对把 120 个文件里的anyhow::Result统一改成自定义DayuanResult这个任务时整整拖了三天。不是不会是怕。怕改漏、怕改错、怕编译器不报但运行时崩。后来是 AI 救了我——但不是那种一键重构的魔法按钮而是一套我自己摸索出来的上下文注水 分批验证工作流。作为自学编程的程序员我对 AI 的态度很务实它不是一个能单独干活的高级工程师而是一个理解力 80 分、记忆力 20 分的实习生。你的任务是帮它补齐那 60 分。二、核心方法论上下文是唯一的货币AI 辅助重构最大的坑不是AI 写得不好而是你给了它不完整的上下文。LLM 的窗口再大也是有边界的你不能一次性把整个项目塞给它。三、实战批量迁移错误处理类型3.1 上下文提取在把任务交给 AI 之前我写了一个小工具来自动化上下文提取。它能分析Cargo.toml的依赖图找到所有受影响的模块。use std::collections::{HashMap, HashSet}; use std::path::Path; use std::fs; /// 模块依赖图分析器 /// 用于在重构前确定影响范围 struct ModuleDependencyGraph { /// 模块名 - 它依赖的模块列表 deps: HashMapString, VecString, } impl ModuleDependencyGraph { /// 从项目源码中构建依赖图 fn from_project(root: Path) - Self { let mut graph HashMap::new(); // 遍历所有 .rs 文件 for entry in walkdir::WalkDir::new(root) .into_iter() .filter_map(|e| e.ok()) .filter(|e| e.path().extension().map_or(false, |ext| ext rs)) { let content fs::read_to_string(entry.path()).unwrap(); let module Self::extract_module_name(entry.path()); let deps Self::extract_use_statements(content); graph.insert(module, deps); } ModuleDependencyGraph { deps: graph } } /// 解析 use 语句提取模块依赖 fn extract_use_statements(content: str) - VecString { content .lines() .filter(|line| line.trim().starts_with(use )) .filter_map(|line| { // 提取 crate 内部引用 let trimmed line.trim().strip_prefix(use )?; // 只关心本项目内部的模块 if trimmed.starts_with(crate::) { Some(trimmed.to_string()) } else { None } }) .collect() } fn extract_module_name(path: Path) - String { path.with_extension() .to_string_lossy() .replace(/, ::) } }3.2 喂给 AI 的 Prompt 设计有了依赖图我就知道影响面有多大。接下来是 prompt 设计的核心——给 AI 看什么# 我在给 AI 的 prompt 里固定的三段式 ## 第一段项目背景一次性不必重复 你是一个 Rust 专家。我们正在维护一个 AI CLI 工具项目 dayuan使用 tokio clap anyhow。现在要把所有 anyhow::ResultT 替换为自定义的 DayuanResultT定义如下 [粘贴 DayuanResult 的定义代码] ## 第二段当前文件上下文每次不同 请修改以下文件。该文件在项目中的位置是 src/handler/completion.rs 它被以下模块依赖src/main.rs, src/router.rs。 所以你的修改不能改变公开 API 的签名。 [粘贴文件内容] ## 第三段约束条件 1. 不要修改 pub fn 的返回类型 2. 内部函数可以用 ? 继续传播错误 3. 如果某个函数需要从 anyhow::Error 转为 DayuanError显式写转换代码 4. 修改完成后在注释中标记所有变更点3.3 分批验证流水线我没有一次性把所有文件丢给 AI而是把 120 个文件分成 12 批每批 10 个文件。处理流程如下/// 重构批次管理器 /// 将大重构拆解为多个小批次每批独立验证 struct RefactoringBatcha { /// 本批次包含的文件路径 files: Veca Path, /// 批次编号 batch_id: u32, } struct RefactoringPipeline { /// 剩余待处理的文件 remaining: VecRefactoringBatchstatic, /// 已完成批次 completed: Vecu32, } impl RefactoringPipeline { /// 处理下一批次 /// 返回 (成功处理的文件数, 失败的文件) fn process_nextF(mut self, ai_modifier: F) - Result(usize, VecString), String where F: Fn(str) - String, // AI 修改函数输入代码输出修改后的代码 { let batch self.remaining.pop() .ok_or(所有批次已完成)?; let mut success_count 0; let mut failures Vec::new(); for file_path in batch.files { let original fs::read_to_string(file_path) .map_err(|e| format!(读取文件失败: {}, e))?; // 调用 AI 进行修改 let modified ai_modifier(original); // 写回文件 if let Err(e) fs::write(file_path, modified) { failures.push(format!({}: {}, file_path.display(), e)); continue; } success_count 1; } // 批次完成后立即运行编译验证 let build_result std::process::Command::new(cargo) .args([check]) .output() .expect(cargo 命令执行失败); if !build_result.status.success() { // 编译失败回滚本批次所有修改 return Err(format!( 批次 {} 编译失败:\n{}, batch.batch_id, String::from_utf8_lossy(build_result.stderr) )); } self.completed.push(batch.batch_id); Ok((success_count, failures)) } }教训上面这段process_next里有个隐蔽 bug——cargo check会对整个项目做检查但如果之前批次引入了一个只影响其他 crate 的问题cargo check可能通过了到运行时才发现。解决方法是在更新频率低的批次末尾加一次cargo test全量回归。四、真实踩过的坑坑 1AI 会忘记远程依赖当你让它改一个函数签名时它可能不知道这个函数在 15 个其他文件中被调用。所以我的做法是让依赖图工具把调用方列表作为上下文一并喂进去。坑 2AI 的懒人倾向LLM 有时会为了省事把所有anyhow::Error都改成Boxdyn Error。必须在 prompt 里明确说不要引入任何新的 trait 或类型。坑 3风格漂移每批独立处理的文件代码风格可能不一样。我会在最后统一跑一次cargo fmt和cargo clippy --fix。这步必须放到 AI 修改之后、人工 review 之前。AI 重构的真实数据120 个文件总共改了 487 处anyhow::Result。AI 自动处理了 412 处成功率 84.5%剩余 75 处需要人工修正。失败主要集中在两处涉及泛型约束的类型替换36 处和跨 crate 边界的 API 变更39 处。人工修正花了 4 个小时而如果全手动改预估需要 16 个小时。省下的 12 个小时就是 AI 辅助重构的价值。后来我们还发现一个规律把重构 prompt 的主语从你改成我们我们需要把 anyhow::Result 替换成...AI 生成的内容会更多保留原有的注释风格。可能是训练数据里大量高质量的协作式重构都用了我们这个视角。五、总结AI 辅助重构的关键不是让 AI 替你写代码而是让 AI 在你验证过的上下文中做机械性修改。你的价值体现在三个地方提取上下文的能力——知道该给 AI 看什么、不该看什么设计验证流程的能力——编译通过 测试通过 人工 review三层防线评估 AI 输出质量的眼光——能判断 AI 的修改是否安全。作为程序员我在学校里没上过编译原理课但我有和 AI 一起 debug 到凌晨三点的经验。这套工作流不是书本上学的是一百多次cargo check 炸了又修中磨出来的。它不完美但它 work。下一篇预告异步 Rust 在嵌入式中的应用——用 embassy 在 STM32 上跑并发任务。