哈嘍，我是老劉
老劉帶着團隊做Flutter開發已經六七年了，這期間被問到最多的三個問題是：
- 跨平台開發選什麼？
- Flutter選哪個版本？
- Flutter的狀態管理方案有選哪個？
今天我們主要來聊聊狀態管理方案的選擇問題。
老劉自己的團隊早期是小項目用Provider，中大型項目用Bloc。
最近這兩年新項目主要還是用Riverpod比較多，RIverpod逐步取代了Bloc成為第一選擇。
但是隨着AI在開發中的比重越來越高，似乎RIverpod不再是最佳選擇了。
這不前兩天，一個朋友跟我吐槽。
他們團隊把項目從Provider重構到Riverpod。
重構完成後，團隊使用AI生成的Riverpod代碼錯誤率提高了30%！
要麼是註解用錯了，要麼是Provider依賴關係搞混了。
團隊成員每天都在修AI的bug，效率反而比之前更低了。
為什麼人類程序員覺得好用的技術，AI卻"水土不服"？
因為我們的技術選型思維，還停留在"純人工"時代。
在這個新時代，技術選型不能只看性能和優雅度。
"AI友好度"正在成為一個全新的、至關重要的評估標準。
今天，老劉就來聊聊Flutter狀態管理的AI適配度問題。
首先我們來看看歷史上Flutter官方推薦的狀態管理方案。
Flutter官方推薦的狀態管理方案
1. Provider (2019年左右)
- 時間 ：大約2019年被Flutter官方推薦
- 特點 ：基於InheritedWidget的封裝，Flutter官方文檔推薦的入門方案
- 官方地位 ：Flutter官方文檔明確推薦作為新手首選方案
2. Bloc/Cubit (2019年左右)
- 時間 ：flutter_bloc包發佈於2018年
- 特點 ：基於BLoC（Business Logic Component）模式
- 官方認可 ：在Flutter官方文檔中被列為推薦方案之一
3. Riverpod (2021年)
- 時間 ：2021年由Remi Rousselet發佈1.0版本
- 特點 ：Provider的完全重寫版本，解決了Provider的一些設計問題
- 發展 ：Riverpod 2.0在2022年發佈，Riverpod 3.0在2024年9月發佈
三大狀態管理方案的"AI適配度"大PK
AI適配度是老劉自己提出來的一個概念，有兩個主要指標：
1、AI代碼生成的成功率。
2、AI生成的代碼對程序員是否友好（讀得懂，好修改）。
因為老劉這邊的主要場景還是AI和開發者協同工作。
Provider：小型項目入門首選
從人類程序員的視角來看，Provider確實是簡單易懂的"新手村神器"。
Flutter官方欽定的入門方案，學習成本低，上手快。
從AI的視角來看，Provider的代碼也很容易生成和理解，但是自由度過高。
也就是説如果你讓AI隨意發揮，那麼生成的代碼和你們項目中的整體代碼風格可能會有比較大的差異。
而且最大的問題是，小項目用Provider還行，但大項目往往需要二次封裝來滿足更多場景。
所以我認為，Provider適合小型項目，而且需要在使用中給AI明確的生成規則的限制。
Riverpod：程序員的"白月光"，AI的"硃砂痣"
從人類程序員的角度，Riverpod功能強大，代碼簡潔，開發效率高。
這是Remi大神的"完美作品"，解決了Provider的諸多痛點。
但從AI的視角來看，Riverpod的註解魔法太多了。
代碼生成邏輯複雜，AI"看不懂"那些@riverpod註解背後的門道。
Bloc：AI時代的"扛把子"
從人類程序員的視角，Bloc確實代碼略顯冗長。
但結構清晰，是企業級項目的"老司機"。
從AI的視角來看，Bloc簡直是"如魚得水"。
Event-State模式高度標準化，訓練數據豐富，AI"見多識廣"。
Bloc的核心優勢在於：
顯式的代碼結構，AI一眼就能看懂整個數據流。
為啥有些框架在AI開發中表現更好
説到這裏，可能有朋友會問：為什麼同樣是狀態管理方案，AI對它們的"理解能力"差這麼多？
這背後其實有兩個關鍵因素。
第一個因素：訓練數據的豐富度
AI模型就像一個"見多識廣"的老師傅。
它見過的代碼越多，理解得就越深入。
Bloc在Flutter生態中存在時間最長，從2019年就開始積累大量的實際項目案例。
GitHub上你能找到成千上萬個開源項目使用bloc。
這意味着AI在訓練時接觸到的Bloc代碼樣本最多，理解最深入。
相比之下，Riverpod雖然技術更先進，但2021年才發佈，訓練數據相對較少。
因此AI對Riverpod的"熟練度"自然不如Bloc。
第二個因素：代碼邏輯的直觀性
這個更關鍵。
AI的底層邏輯是模式匹配，所以最擅長處理的是"所見即所得"的代碼結構。
Bloc的Event-State模式，所有的業務邏輯都明明白白寫在代碼裏：
class CounterBloc extends Bloc<CounterEvent, CounterState> {
CounterBloc() : super(CounterInitial()) {
on<CounterIncrement>((event, emit) {
emit(CounterValue(state.value + 1));
});
}
}AI一看就懂：接收CounterIncrement事件，發出CounterValue狀態。
但Riverpod的註解模式就不一樣了：
@riverpod
Future<String> userProfile(UserProfileRef ref) async {
// AI需要理解註解背後的代碼生成邏輯
}這個@riverpod註解對AI來説就是個"黑盒子"。
AI需要理解註解背後複雜的代碼生成邏輯，理解成本大大增加。
簡單來説，通過註解、依賴注入等方式組合的邏輯，容易讓AI理解錯誤。
而所有邏輯都在代碼中直觀體現的方案，更有利於AI準確理解和生成代碼。
GitHub上Bloc的案例最多，AI在訓練時"見多識廣"。
模式固定，AI生成代碼的準確率最高。
根據我們團隊的實際測試數據，使用Bloc的項目，AI代碼生成準確率比Riverpod高30%。
這就是為什麼在AI時代，Bloc重新成為了最佳選擇。
避坑：不要盲目從Riverpod遷移到Bloc
但是，看到這裏千萬別急着把現有項目從Riverpod遷移到Bloc！
什麼時候適合遷移？
項目頁面還比較少，遷移成本不高的情況下。
比如你的項目只有5-10個頁面，狀態管理邏輯相對簡單。
這種情況下，遷移成本可控，收益明顯。
但如果你的項目已經有幾十個頁面，狀態管理邏輯複雜。
那就別折騰了！
Riverpod在AI中只是表現得沒有那麼好，但也不是非常差。
Riverpod作為目前最流行的狀態管理方案，可以找到大量的開源項目和案例。
這為AI提供了豐富的訓練數據。
所以AI生成的效果其實比大多數非官方推薦的狀態管理方案要好很多。
不遷移怎麼辦？學會正確的使用AI生成代碼。
- 給AI提供標準的使用案例！
比如準備一個包含完整業務邏輯的頁面，讓AI參照這個案例進行代碼生成。 - 清晰地描述生成代碼的規則和約定。
這樣AI就能更準確地理解你的項目結構和編碼風格。
事實上即使採用了Bloc，老劉也推薦採用上面的方式，讓AI生成的代碼符合你的項目規範。
總結：技術選型的新時代已經到來
説到這裏，老劉想跟大家分享一個觀點。
在AI協同開發時代，"AI友好度"已經成為技術選型的新維度。
老劉斗膽預測，未來3年內，不考慮AI協作的技術方案將逐漸被淘汰。
因為開發效率的差距會越來越明顯。
一個AI友好的項目，開發速度可能是傳統項目的2-3倍。
而一個AI"水土不服"的項目，反而會拖累整個團隊的效率。
所以，技術選型不能只看人類程序員的體驗了。
你還要站在AI的角度思考，這些代碼對AI來説是否能理解、能維護。
因此，Bloc雖然"囉嗦"，但在AI時代反而是優勢。
因為它的每一行代碼都在"告訴"AI：我在做什麼，為什麼這麼做。
最後，老劉想説：
前面的這些統計數據主要基於老劉這邊團隊的項目，可能具有一定的侷限性。
但是AI協同開發帶來的影響和趨勢不會有問題。
記住，未來的代碼不只是寫給人看的，更是寫給AI看的。
你準備好迎接這個新時代了嗎？
如果看到這裏的同學對客户端開發或者Flutter開發感興趣，歡迎聯繫老劉，我們互相學習。
點擊免費領老劉整理的《Flutter開發手冊》，覆蓋90%應用開發場景。
可以作為Flutter學習的知識地圖。
覆蓋90%開發場景的《Flutter開發手冊》
