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

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 的三条核心设计原则经历了四次迭代：

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

四、三条支线的交叉验证

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

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

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

低 ROI（AI 对 Rust 不够好）：

/// 高 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()); // 只要找到了就行
}
}

支线二：Rust 系统编程 —— 从"能用"到"用对"

7 月份我在 Rust 方面最大的进步不是学会了什么新概念，而是理解了什么时候不该用某些概念。比如：

• 不是所有地方都需要 Arc<Mutex<T>>——80% 的场景用消息传递（channel）更合适
• 不是所有 trait 都需要 #[async_trait]——如果只有一个实现，用具体类型
• 不是所有错误都需要自定义 Error 类型——anyhow::Result 在 binary crate 里完全够用

支线三：WASM/WASI —— 从浏览器到系统编程

WASM 这条线是我 7 月投入最多、收获也最多的一条。从 wasm-pack 编译 Rust 到浏览器端推理，再到 WASI 预览版 2 的系统接口探索，我搭建了一个从编译到运行时的完整知识体系。

最重要的认知是：WASM 不是 JavaScript 的替代品，而是浏览器和系统编程之间的桥梁。 当你用 Rust 写逻辑、编译到 WASM、在浏览器里运行时，你获得的是一个"零运行时开销的沙箱化执行环境"。

五、总结

七月的 310 篇文章，表面上是我在"输出"，本质上是我在"输入"——输入的是对 AI CLI 工具开发的深层理解，输入的是 Rust 系统编程的实践经验，输入的是 WASM 生态的工程化认知。

如果说有一条贯穿始终的感悟，那就是：自学出身不是劣势，而是给了你一个"无知者无畏"的视角。 你不会被"这不可能"的思维定势束缚，你会去尝试那些科班生觉得"不科学"的方案——然后有些方案真的有效。

八月份我计划把 dayuan 正式发布到 crates.io，并开始探索 WASI 在 Serverless 场景下的应用。这篇文章是这个系列的第一篇，下午我还会分享 Rust 核心概念的月度图谱。

保持 coding，保持复盘。我们第二篇见。

这个月我写了 310 篇文章，其中 31 篇是每日的 10 篇连发。如果你也在用 Rust 做 AI 工具，欢迎在评论区交流你的踩坑经历。

资料说明

本文中的协议、版本、性能、成本和行业趋势应以可核验的一手资料为准。未标注统计口径的比例、时间表和预测仅作工程讨论，不应视为行业事实。可参考 0731 资料来源索引，并在发布前将具体来源贴到对应断言之后。