Rust 学习的 7 月：用里程碑式目标替代每天学多少小时的策略
Rust 学习的 7 月：用里程碑式目标替代每天学多少小时的策略
一、为什么"每天学 X 小时"注定失败
我 6 月份统计过自己的学习时间——最高峰一天 10 小时，最低峰不到 1 小时，平均下来每天 3.5 小时。但这个"平均 3.5 小时"掩盖了一个致命的问题：我在 10 小时那天学的，和 1 小时那天学的，效果相差 10 倍不止。
关键不是我学了多久，而是我在那段时间里学到了什么。复盘 6 月的 100 多个小时，我发现时间投入和知识掌握的 R² 不到 0.3。影响因素太多了：精神状态、难度、环境、是否有卡点——这些都比"学了几小时"影响大。
7 月我彻底废掉了时间追踪。不看番茄钟、不设每日目标、不统计学习时长。取而代之的是 4 个明确里程碑：完成 AI CLI 的最小闭环、实现 Provider trait 支持多后端、拆 workspace 降低编译时间、插件系统能注册并执行技能。
二、里程碑式学习的三个核心原则
里程碑式策略不是不做计划，而是把计划的粒度从"时间"变成"结果"。我总结了三个原则：
原则一：里程碑必须可验证。"学会所有权"不是里程碑，因为它无法验证。"能用所有权概念解释为什么这段代码不编译"才是。7 月每个里程碑的前面都有具体可验证的输出——一段能跑的代码、一张依赖图、一套能编译通过的测试。
原则二：里程碑之间要有递进关系。这四个里程碑不是并列的——前一个的输出是后一个的输入。完成 CLI 闭环后，我自然知道 Provider 需要什么接口；拆完 workspace 后，插件需要哪些 crate 就清楚了。这种递进保证了知识不是散装积累的，而是有结构地生长的。
原则三：里程碑完成才向前走，不能"差不多就行"。这一点对我这种尤其重要。很多时候代码"差不多能跑"就想推进下一个里程碑，但这样堆积的问题会像雪球一样滚大。
// ============================================================ // 里程碑验证：不是"代码能跑"，是"各种情况都考虑到了" // ============================================================ /// 里程碑一的验证代码：CLI 闭环各种边界都要处理好 use clap::Parser; /// AI CLI 的命令行参数定义 /// 用 clap 的 derive 宏自动生成解析逻辑 #[derive(Parser, Debug)] #[command(name = "ai-cli", about = "终端 AI 助手")] struct Cli { /// 用户提问内容（必填，不能为空） #[arg(required = true)] prompt: Vec<String>, /// 指定使用哪个 AI 模型 #[arg(short, long, default_value = "gpt-4o-mini")] model: String, /// 是否使用流式输出（打字机效果） #[arg(long, default_value_t = false)] stream: bool, } fn validate_cli(cli: &Cli) -> Result<(), String> { // 里程碑验证第一步：输入不能为空 let prompt = cli.prompt.join(" "); if prompt.trim().is_empty() { return Err("prompt 不能为空 — 里程碑一要求输入校验到位".to_string()); } // 里程碑验证第二步：模型名不能为空 if cli.model.trim().is_empty() { return Err("model 不能为空 — 默认值应该在参数层兜底".to_string()); } Ok(()) }验证代码才是里程碑的"验收标准"。功能能跑只是及格——考虑边界、错误处理、输入校验这些才算真正完成。
三、从经验贴到实战：真的能"抄作业"吗
我看了大量 Rust 学习路径的经验贴，它们通常推荐"看 The Book → 做 Rustlings → 写小项目"。这路径没错，但它忽略了一个独有的痛点：基础断层。
科班生说"这跟 C 的内存管理很像"时的我不知道 C 是怎么管内存的。科班生说"类似操作系统的页面置换"时，我没学过操作系统。这就是为什么我不能完全照搬别人的路径，必须在每个里程碑里把"缺失的知识"也补上。
7 月做 workspace 拆分时，我不懂什么是"增量编译"、不懂 cargo 怎么决定重编译哪些 crate。我没有跳过这一步去抄别人的 workspace 配置，而是花了一下午读 cargo book 的编译模型章节，彻底理解了"为什么拆 crate 能加速编译"之后，才动手设计自己的 workspace 结构。
四、7 月里程碑驱动的实际数据
既然说月度复盘，就拿出数据。四个里程碑的实际耗时和产出：
| 里程碑 | 计划天数 | 实际天数 | 产出 |
|---|---|---|---|
| CLI 最小闭环 | 7 天 | 9 天 | main.rs 1200 行，单一后端 |
| Provider trait 抽象 | 5 天 | 6 天 | 3 个后端适配器，统一错误类型 |
| Workspace 拆分 | 7 天 | 8 天 | 5 个 crate，编译 20s→3s |
| 插件系统 | 10 天 | 8 天 | 5 个技能，测试覆盖率 32% |
最后里程碑还提前了两天——因为前三步的知识积累让判断更准了。这也是里程碑式学习的正反馈：你越了解自己在学什么，就越能准确估计下一步需要什么资源。
五、总结
7 月从"时间驱动"切换成"里程碑驱动"是我学习 Rust 以来最重要的策略调整。不怕起步慢，怕的是在焦虑里乱撞。
三条总结：
- 放弃计时器，拥抱可验证的输出。"学 8 小时"不如"让这个函数处理 5 种错误并写测试"。
- 里程碑之间要递进，前一个的输出就是后一个的输入，这样知识是长出来的而不是堆积的。
- 补基础不丢人比科班多做的每一步都是在弥补信息差——这个时间花得值。
8 月我的里程碑已经定好了：把 AI CLI 的测试覆盖推到 80% 以上，让这个工具真正能"放心用"。