企业官网建设流程全解析

AI 加 Rust：一个月的学习数据复盘，看进步曲线和下一阶段目标

一、7 月学习全景数据

先上总账。这是 7 月 1 号到 31 号的完整数据统计：

具体产出数据：

几个变化值得单独说：日均编译错误从 40 次降到 15 次，解决每个错误的平均时间从 12.5 分钟降到 3.2 分钟。这不是因为代码写得更快，是因为我对 Rust 的类型系统和错误模式越来越熟了——不再需要每个错误都查文档、搜 StackOverflow。

二、进步曲线：不是线性的，是阶梯式的

单看总数会掩盖一个重要事实：进步不是线性的，是阶梯式的。7 月的学习曲线大致是这样的：

第一周（1~7 日）：效率低（3 分），在做 AI CLI 的最小闭环。时间主要花在"我想做什么"和"Rust 应该怎么写"的反复对齐上。这个阶段看似产出低，但它确定了整个月的工作方向。

第二周（8~14 日）：效率爬升（5 分），Provider trait 抽象开始生效。我感受到了 Rust 类型系统的威力——当抽象做对时，加新功能就像拼积木。但也是对 async/tokio 的理解还在表层，遇到网络超时和并发问题还需要反复查文档。

第三周（15~21 日）：效率突破（7 分），Workspace 拆分让编译快 6 倍。也是这周我开始"感觉到 Rust 的节奏"——不再跟编译器对抗，而是顺着它的约束来设计代码。ownership 和 borrow 的报错不再让我恐惧，变成了"又来提醒我重新组织代码"。

第四周（22~31 日）：效率稳定（8 分），插件系统的设计一周就搞定了。到这个阶段，我已经能独立做出"这个东西应该用 trait 还是 enum"、"这里应该 borrow 还是 clone"、"这个错误是 recoverable 还是 unrecoverable"的判断了。

// ============================================================ // 进步的一个具体证据：同样功能的代码，月初 vs 月末 // ============================================================ /// 月初写法：到处 unwrap，混合了逻辑和错误处理 fn v1_load_config(path: &str) -> Config { let f = std::fs::File::open(path).unwrap(); let reader = std::io::BufReader::new(f); let config: Config = serde_json::from_reader(reader).unwrap(); config } /// 月末写法：类型安全、错误可传播、职责分离 fn v2_load_config(path: &str) -> Result<Config, AppError> { // 第一步：检查文件是否存在，给出明确的错误提示 if !std::path::Path::new(path).exists() { return Err(AppError::Config(format!( "配置文件不存在: {}，请运行 'ai init' 创建默认配置", path ))); } // 第二步：读取并解析，所有错误通过 ? 向上传播 let content = std::fs::read_to_string(path) .context("配置文件读取失败")?; let config: Config = toml::from_str(&content) .context("配置文件格式错误，请检查是否为合法的 TOML")?; // 第三步：校验配置的有效性（如 API Key 非空） config.validate()?; Ok(config) }

三、"+ AI + Rust"这个组合的独特优势

7 月我越来越确信，"+ AI + Rust"不是一个妥协，而是一个有独特优势的组合。

的优势在于不受既有惯性约束。科班程序员学 Rust 时，经常会和 C/C++ 的既有习惯打架——"为什么要这么管内存"、"为什么不能随便 cast"。没有这个包袱，所有权和生命周期对我来说就是"本来就应该这样"，而不是"为什么要改成这样"。

**AI 的优势在于填补信息差。**最大的痛点是知识盲区——你不知道这东西叫"线程池"、不知道这个概念叫"RAII"、不知道这个问题在 JS 里叫"回调地狱"。AI 能把我的模糊描述翻译成准确的术语，然后我就能用术语去查更深入的文档。这个"翻译层"大大缩短了我从"困惑"到"找到正确答案"的时间。

Rust 的优势在于编译器当 mentor。对我来说，Rust 编译器有时候比 AI 更有用。AI 会给你一个"可能是对的"答案，编译器会给你一个"一定是错的"错误。而且 Rust 的错误信息已经足够好，对我来说就像一个随时在线的 code reviewer。

四、8 月目标：从"能做"到"做好"

7 月我是"能做"阶段——把东西做出来、把它跑起来。8 月要进入"做好"阶段：

目标一：测试覆盖率从 32% 推到 80%。这是最紧急的事。AI CLI 现在已经有一点基础用户了（都是我自己 + 几个朋友），没有测试覆盖的重构就是在裸奔。计划把ai-core的测试做到 90%+，ai-providers用 mock HTTP server 做集成测试。

目标二：错误处理的等级五落地。库（ai-core、ai-provider）用 thiserror 精确错误类型，应用层（main.rs）用 anyhow 做上下文传播。让用户看到的错误信息全部是"人话"。

目标三：性能基准线建立。目前我对 AI CLI 的"够不够快"全凭感觉。8 月要引入 criterion 做核心路径的 benchmark：启动时间、首次响应延迟、流式输出的 token 速率。有数据才能优化。

目标四：WASM 推理打通完整链路。把真实的 ONNX 模型通过 candle 编译成 WASM，在浏览器端跑一次完整的推理，记录延迟数据和可行性结论。

目标五：每周至少一篇深度复盘。7 月的写作密度有进步，但质量不够稳定。8 月不求数量多，每篇要有"别人读完后能用得上"的信息密度。

五、总结

7 月，一个自学编程的人，靠着 Rust + AI 的基本组合，在一个月里做出了一个能用的 AI CLI 工具、写了 30 篇博客、积累了 47 条踩坑笔记。这个成绩放到半年前我自己都不会信——那时候我还在背"什么是 HTTP 协议"。

对我来说，进步不只体现在产出上，更体现在一个质变上：7 月之前，我是"在学习 Rust"。7 月之后，我是"用 Rust 做事"。从学习到做事，这个心理身份的转换，才是这一个月最重要的变化。

三条月度总结：

1. 进步是阶梯式的，不是线性的。在低效期不要慌——你可能正在为下一个飞跃打基础。
2. "+ AI + Rust"不是妥协，是优势组合。没有惯性包袱，AI 填补信息差，Rust 编译器当 mentor。
3. 从"能做"到"做好"，差的是测试、错误处理、性能基准。这些不是加分项，是工具的根基。

8 月的任务已经清楚：测试、错误、性能、WASM、深度写作。31 天后，我再交一份这样的复盘。如果你也在自学 Rust 或者做 AI 工具，希望我的数据能帮到你。