1. 课程导论：为什么需要版本控制？AI模型迭代的痛点与挑战
大家好，欢迎来到这门实战课。
先问一个问题：你手头有没有一个训练好的AI模型，想部署到STM32上？
如果有，那你大概率遇到过这种情况——模型在电脑上跑得好好的，量化后精度掉了一截；或者今天改了个网络结构，明天就忘了之前哪个版本效果最好。嗯，这些坑我都踩过。
1.1 一个真实的“翻车”现场
我记得几年前，团队给一个工业视觉项目做模型迭代。当时没有版本管理，大家靠文件名区分：
model_final.h5
model_final_v2.h5
model_final_v2_真的不改了.h5
model_final_v2_真的不改了_最终版.h5结果呢？部署到产线后，发现精度不如一周前的版本。但那个“一周前的版本”早就被覆盖了。最后只能重新训练，浪费了整整两周。
你想想看，如果当时用了版本控制，这种问题根本不会发生。
1.2 AI模型迭代的四大痛点
在嵌入式AI领域，模型迭代的痛点比纯软件项目更突出。我总结为四点：
| 痛点 | 具体表现 | 后果 |
|---|---|---|
| 版本混乱 | 文件名随意命名，训练参数无记录 | 无法回溯，重复劳动 |
| 精度退化 | 量化、剪枝后精度下降，找不到原因 | 部署失败，返工重训 |
| 环境漂移 | 换了训练框架或库版本，结果不一致 | 结果不可复现，信任崩塌 |
| 协作冲突 | 多人同时改模型，互相覆盖 | 效率低下，团队内耗 |
⚠️ 我曾经踩过的坑： 有一次，我为了赶进度，直接在STM32Cube.AI里反复导入导出模型，没有记录每次的量化参数。结果部署后模型输出全是乱码。后来花了三天才定位到是量化校准集选错了。如果当时有版本记录，十分钟就能搞定。
1.3 为什么版本控制对嵌入式AI尤其重要？
纯软件项目的版本控制，大家已经很熟悉了。但嵌入式AI有它的特殊性：
- 模型文件大：一个 .h5 或 .tflite 文件动辄几十MB，Git 根本管不了。
- 依赖链长：训练框架、量化工具、STM32Cube.AI 版本、固件库，任何一个变了，结果都可能不同。
- 硬件绑定：同一个模型，在STM32F4和STM32H7上的表现可能天差地别。
- 迭代周期短：从训练到部署，可能一天要迭代好几个版本。
说白了，嵌入式AI的版本控制，不只是管代码，还要管模型、管数据、管工具链、管硬件配置。
1.4 版本控制能解决什么？
我个人习惯把版本控制的价值归纳为三个词：可追溯、可复现、可协作。
- 可追溯：随时知道“谁、在什么时候、改了什么、为什么改”。
- 可复现：三个月后，还能用同样的代码和数据，训练出同样的模型。
- 可协作：团队多人并行开发，不会互相踩脚。
💡 一个小建议： 哪怕你是一个人做项目，也建议用版本控制。因为“未来的你”就是“最好的协作者”——前提是你得给他留下清晰的记录。
1.5 本章知识体系总览
下面这张图，概括了本章的核心逻辑。你可以把它当作整个课程的“导航图”。
1.6 这门课会怎么讲？
接下来的课程，我会带着你一步步搭建一套适合STM32Cube AI的版本控制体系。不是讲理论，而是直接上手干。
- 我们会用 Git + DVC 管理模型和数据
- 我们会用 STM32Cube.AI 做量化、评估和部署
- 我们会设计一套 迭代策略，让模型越改越好，而不是越改越乱
🔧 准备工具： 建议提前装好 Git、DVC（Data Version Control）、STM32CubeMX 和 STM32Cube.AI。如果你还没装，别担心，下一章我会手把手带你配环境。
好了，导论就到这里。记住一句话：没有版本控制的AI项目，就像没有刹车的跑车——快是快，但迟早要翻。