7 月 Rust AI CLI 开发全记录：310 篇文章背后的一条主线和三条支线的总结

关注

原创最新推荐文章于 2026-11-10 18:38:07 发布 5k 阅读 AI 写同款· GEO 优化 ›

＜数据集＞咖啡叶片病害识别＜目标检测＞ YOLO与VOC格式的咖啡叶片病害识别数据集，适用于YOLO系列、Faster Rcnn、SSD等模型训练，类别：Cercospora、Miner、Phoma、Rust，图片数量1744。文件中包含图片、txt标签、指定类别信息的yaml文件、xml标签，已将图片和txt标签划分为训练集、验证集和测试集，可直接用于YOLOv5、YOLOv6、YOLOv7、YOLOv8、YOLOv9、YOLOv10、YOLOv11、YOLOv12、YOLOv13、YOLOv26等YOLO系列算法的训练。阅读详情

7 月 Rust AI CLI 开发全记录：310 篇文章背后的一条主线和三条支线的总结

一、310 篇文章的起点：一个失眠夜晚的决定

6 月 30 日晚上，我躺在床上刷手机，看到一篇文章说"AI 编程已经让入门门槛降低了 90%"。我突然想到一个问题：如果 AI 真的降低了门槛，那为什么我在 dayuan 项目里写的几百行 prompt 构建代码，反而让我觉得比手写逻辑更复杂？

那天晚上我做了两个决定。第一，从 7 月 1 日开始每天写一篇技术文章，把 dayuan 开发过程中的每一个决策、每一次失败、每一次"原来如此"都记录下来。第二，用这 31 天做一个实验：AI 到底在 Rust 开发的什么阶段最有用？

这个决定后来演变成了 310 篇文章——不是 31 篇，而是 31 天每天 10 篇。每天早上 5 点起床，写到中午 12 点。晚上 coding 到凌晨，复盘当天的代码，准备第二天的素材。

今天这篇是月度终章的第一篇。我想把这条主线拉出来——AI CLI 工具开发——再梳理出三条支线：AI 辅助开发、Rust 系统编程、WASM/WASI 工程化。这四条线构成了我 7 月的全部技术生活。

二、一条主线和三条支线的全景

三、主线复盘：AI CLI 工具开发的底层逻辑

超越"命令行包装器"

dayuan 项目的本质不是把 OpenAI 的 API 封装成一个命令行工具。如果只是做这件事，Python 一行 subprocess.run(["curl", ...]) 比 Rust 快十倍。

dayuan 解决的核心问题是：如何让 AI CLI 工具理解你的整个项目上下文，而不只是当前文件？

/// 上下文管理器：不只是收集文件，而是构建关系图谱
pub struct ContextManager {
    /// 项目根目录
    root: PathBuf,
    /// 文件索引图：文件路径 → 它引用的依赖列表
    dependency_graph: HashMap<PathBuf, Vec<PathBuf>>,
    /// 符号表：函数/类型定义 → 位置
    symbol_index: HashMap<String, Vec<SourceLocation>>,
}

impl ContextManager {
    /// 构建项目上下文：收集当前修改相关文件的全链路
    pub fn build_context(&self, changed_file: &Path) -> ContextResult {
        // ① 从变更文件出发，沿依赖图向上追溯
        let upstream = self.trace_upstream(changed_file);
        
        // ② 再向下追溯：变更影响的文件
        let downstream = self.trace_downstream(changed_file);
        
        // ③ 合并：形成一个"变更影响域"的文件集合
        let relevant_files: HashSet<_> = upstream
            .into_iter()
            .chain(downstream)
            .collect();
        
        // ④ 只把影响域内的文件内容发给 AI，而不是整个项目
        ContextResult {
            files: relevant_files,
            total_tokens: self.estimate_total_tokens(&relevant_files),
        }
    }
}

这个设计的核心思想是：AI 不需要看整个代码库，它只需要看你的变更可能影响的那些代码。 这比简单地把整个目录 dump 进 prompt 节省了 60%~80% 的 token 消耗。

三条核心设计原则的演进

7 月的 31 天里，dayuan 的三条核心设计原则经历了四次迭代：

版本	日期	核心变化	教训
v0.1	7月1日	单一 prompt，硬编码	最简单但最脆弱
v0.2	7月8日	角色系统 + 工具链	过度抽象，15 个 trait
v0.3	7月17日	重构回 3 个核心 trait	Rule of Three 的胜利
v0.4	7月28日	MCP 协议集成 + 流式输出	插件化 ≠ 过度设计

最大的教训：7 月 8 日到 17 日的"过度抽象期"浪费了 9 天时间。15 个 trait object 的动态分发比具体类型调用慢了近 8 倍。当我把代码从 4200 行瘦身到 1800 行后，性能反而提升了。这让我深刻理解了一句老话："过早优化是万恶之源"的另一面是"过早抽象也是万恶之源"。

四、三条支线的交叉验证

支线一：AI 辅助开发 —— 哪里最有用？

经过 31 天的实验，我发现 AI 在 Rust 开发中有三个"高 ROI 区域"和三个"低 ROI 区域"：

高 ROI（值得全力投入 AI）：

文档/注释生成：30 秒生成一段标准化的 doc comment，节省 80% 时间
错误信息解读：把 E0597: borrowed value does not live long enough 翻译成人话
测试用例生成：给定函数签名和行为规范，生成边界测试

低 ROI（AI 对 Rust 不够好）：

生命周期标注：AI 经常标错，而错误的标注比不标更危险
unsafe 代码块：AI 无法理解 unsafe 的正确性前提
宏编写：declarative macro 的展开逻辑 AI 基本不能正确推理

/// 高 ROI 示例：用 AI 生成测试用例模板
/// AI 输入："为这个函数生成测试：给定有序数组，返回目标值的索引或 None"
/// AI 输出如下（经过人工审查和微调）：
#[cfg(test)]
mod tests {
    use super::*;
    
    #[test]
    fn test_binary_search_found_first() {
        let arr = vec![1, 3, 5, 7, 9];
        assert_eq!(binary_search(&arr, 1), Some(0)); // 首元素
    }
    
    #[test]
    fn test_binary_search_found_middle() {
        let arr = vec![1, 3, 5, 7, 9];
        assert_eq!(binary_search(&arr, 5), Some(2)); // 中间元素
    }
    
    #[test]
    fn test_binary_search_not_found() {
        let arr = vec![1, 3, 5, 7, 9];
        assert_eq!(binary_search(&arr, 6), None); // 不存在
    }
    
    #[test]
    fn test_binary_search_empty_array() {
        let arr: Vec<i32> = vec![];
        assert_eq!(binary_search(&arr, 1), None); // 空数组边界情况
    }
    
    #[test]
    fn test_binary_search_duplicate_first_occurrence() {
        let arr = vec![1, 2, 2, 2, 3];
        // 有重复元素时，返回任意匹配位置（这里是我们自己的语义约定）
        let result = binary_search(&arr, 2);
        assert!(result.is_some()); // 只要找到了就行
    }
}