Article

Flutter AI 學習 Day 7：從學習專案走向可交付品質

Flutter AI 學習 Day 7 回顧整個 Flutter Learning Lab，理解 CI、coverage、官方 sample checklist、打包發布概念，以及下一輪該補的品質能力。

2026-05-11 3816 字預計閱讀 8 分鐘點閱 5

標籤：

系列：

Flutter AI 學習筆記

快速導覽查看本文目錄

Hi~ 我是 Eric！

Day 1 到 Day 6，我一路從 Dart、Widget、Form、Router、Posts 資料流、Settings 本地偏好，走到測試分層。

今天進入 Day 7。

這一天我不打算再新增一個 feature。

Day 7 比較像驗收日。

我想回頭看整個 Flutter Learning Lab，問一個比較工程化的問題：

這個 AI 生成並整理過的學習專案，離「可交付品質」還差什麼？

這裡的可交付，不是說它今天就可以上架 App Store 或 Google Play。

它目前仍然是學習型範例專案，不是完整商業產品模板。

但它至少應該要做到：可閱讀、可測試、可驗證、可延伸，而且每個範例都知道自己在教什麼。

Day 7 的目標：不是寫功能，而是做品質回顧

今天對照的專案內容主要是：

PROJECT_STATUS.md
docs/ci_and_environment.md
docs/governance/official_sample_quality_checklist.md
docs/lessons/NATIVE_TESTING_DEPLOYMENT.md
docs/sample_index.md
.github/workflows/flutter.yml

Day 7 我想完成幾件事：

回顧這個 repo 目前完成了什麼
理解 GitHub Actions 如何補足本機沒有 Flutter SDK 的限制
看懂 coverage artifact 的用途
用官方 sample checklist 檢查範例品質
理解打包發布前還需要哪些概念
規劃下一輪要補的 accessibility、localization、deployment、golden test

這一天不追求「多做一點」。

而是練習判斷：「現在這個專案站在哪裡？」

目前這個 repo 已經完成什麼？

先看 PROJECT_STATUS.md。

這份文件把專案定位寫得很清楚：

Flutter 百科教學範例
不是完整商業產品模板

目前已完成的重點包括：

pubspec.yaml 補齊實作需要的套件
analysis_options.yaml 啟用 flutter_lints
main.dart、app.dart、router.dart、theme.dart 拆出 app shell
首頁拆到 lib/views/home_page.dart
Posts feature 補上 search、filter、pagination、debounce、retry
Profile Form feature 補上 validator、submit loading、error display
Settings feature 補上 SharedPreferences、ThemeMode、使用者偏好
三個 feature 都有 repository / ViewModel / widget test
補上 integration test
補上 GitHub Actions
補上 docs/ 知識庫、七天學習計畫、sample index、架構總覽、測試策略、CI 說明
程式碼與測試補上繁體中文教學註解

這份清單對我很有用。

因為它讓我知道，這個專案不是只生成一堆 Flutter 檔案，而是有被整理成一個可以學習、可以維護、可以驗證的知識庫。

本機不能跑 Flutter 時，CI 就是驗證責任的延伸

這個專案有一個現實限制：

目前本機無法安裝 Flutter SDK。

所以 docs/ci_and_environment.md 把工作流定義成：

本機靜態維護 + GitHub Actions 遠端驗證

本機可以做：

編輯 Dart / Flutter 原始碼
編輯 Markdown 文件
用 rg 搜尋舊路徑、舊套件版本、文件不一致
檢查 git diff

本機不能做：

flutter pub get
flutter analyze
flutter test
flutter run

這一開始看起來像限制，但 Day 7 我反而覺得它是一個很好的工程提醒。

不是所有驗證都一定發生在本機。

如果本機環境受限，就要把驗證責任清楚交給 CI，而且要在文件裡說明限制。

GitHub Actions 目前做了什麼？

CI 設定在：

.github/workflows/flutter.yml

目前流程是：

- name: Install dependencies
  run: flutter pub get

- name: Analyze
  run: flutter analyze

- name: Test with coverage
  run: flutter test --coverage

- name: Upload coverage report
  uses: actions/upload-artifact@v4
  with:
    name: flutter-coverage-lcov
    path: coverage/lcov.info

這裡有三個重點。

第一，flutter pub get 確認套件可以正確解析。

第二，flutter analyze 確認靜態分析和 lints 沒有 error。

第三，flutter test --coverage 不只是跑測試，也產出 coverage。

coverage 在這個專案不是拿來追求 100%。

它比較像一個提醒：

新增 feature 時，有沒有 repository test？
有沒有 ViewModel test？
有沒有 widget test？
文件宣稱的學習重點，真的有測試保護嗎？

這讓 CI 不只是「有跑過」，而是成為學習專案的品質儀表板。

官方 sample checklist：學習範例也要有品質標準

docs/governance/official_sample_quality_checklist.md 是 Day 7 我最喜歡的一份文件。

它不是教語法，而是在定義這個專案要像什麼。

它要求範例要：

可執行
可閱讀
可測試
只教一個清楚主題
README 能說清楚目標、索引、執行方式與限制
pubspec.yaml 只保留實際需要的套件
analysis_options.yaml 啟用官方 lint
flutter analyze 沒有 error
flutter test 通過
CI 產出 coverage artifact
程式碼註解解釋「為什麼」，不要只重複「這一行做什麼」
文件中的套件、API 名稱與程式碼一致
API token、金鑰、個人資料不可硬編碼

這份 checklist 讓我意識到一件事：

教學範例不是比較低標準的程式碼。

反而因為它要被拿來學習，它更需要清楚、穩定、可驗證。

如果範例自己都混亂，初學者只會學到混亂。

學習專案和可上架 App 差在哪？

docs/lessons/NATIVE_TESTING_DEPLOYMENT.md 裡提到上架前還會碰到很多東西：

MethodChannel
unit test / widget test / integration test
app icon
splash screen
Android .aab
iOS .ipa
keystore
provisioning profile
App Store Connect / Google Play Console

這些目前不是 Flutter Learning Lab 第一週的主線。

第一週的重點是先建立 Flutter app 的正確骨架。

但 Day 7 我至少要知道，學習專案距離真正可上架 App 還有一段距離。

我先用這張表記：

面向	學習專案目前狀態	可交付 App 還需要
架構	已有 app shell、feature-first、repository、ViewModel	更完整的錯誤處理、環境切換、權限流程
測試	已有 repository / ViewModel / widget / integration smoke test	更多 edge cases、golden test、真機測試
CI	已有 analyze、test、coverage artifact	build artifact、release workflow、環境 secrets
視覺	有 Material 3 theme 和 UI kit	app icon、splash、品牌視覺、accessibility
國際化	目前以繁體中文學習為主	localization、字串資源、語系切換
發布	有概念文件	Android/iOS 實際簽章、打包、商店流程

這讓我不會把「我看懂 Flutter 專案」誤以為「我已經能交付成熟產品」。

兩者之間還差很多工程工作。

但至少我現在知道差在哪。

下一輪最值得補什麼？

docs/sample_index.md 已經列出下一輪適合補的 sample。

我會把它整理成三個方向。

1. Accessibility / Localization

這會讓專案更接近真正可用的 app。

可以補：

Semantics
大字體測試
螢幕閱讀器友善標籤
l10n
繁中 / 英文語系切換

這類主題很適合接在 Settings 後面，因為語言和字級也可以是使用者偏好。

2. Deployment / Environment

這會補齊從學習專案到交付流程的缺口。

可以補：

dev / staging / prod 設定
build command 表
app icon
splash screen
CI build artifact
環境變數和 secrets 管理

這些是很多初學專案不會碰，但真實專案一定會遇到的東西。

3. Golden / Snapshot-style UI 深化

目前專案已經有 snapshot-style UI 結構檢查。

下一輪可以思考：

哪些 UI 值得做 golden test？
哪些只需要結構檢查？
golden test 如何降低平台差異造成的不穩定？

這能讓 UI 品質保護更完整。

我怎麼用 Codex 做 Day 7 回顧？

Day 7 我沒有請 Codex 幫我寫新功能。

我改問它：

請閱讀 PROJECT_STATUS.md、docs/ci_and_environment.md、
docs/governance/official_sample_quality_checklist.md。
幫我整理這個 repo 目前已達到哪些官方 sample 品質，
以及哪些項目仍需要 Flutter SDK 或 CI 驗證。

接著問：

請用「學習專案」和「可交付 App」的角度，
比較目前 repo 還缺哪些工程能力。
不要泛泛而談，請對照現有 docs 和程式碼。

最後問下一輪：

如果我要讓這個 Flutter Learning Lab 更接近官方 sample，
下一輪應該優先補 accessibility / localization、
deployment environment，還是 golden test？
請給我排序和理由。

這種問法讓 Codex 不再只是程式碼產生器。

它變成一個幫我做專案健檢的 reviewer。

Day 7 對我來說很重要，因為 AI 不只可以幫我把東西做出來，也可以幫我回頭檢查：「這樣真的夠好嗎？」

Day 7 常見卡點：從完成到可交付，中間差什麼？

Day 7 最容易誤會的是：系列寫完、功能看起來完整，就等於專案完成。

所以我用 Codex 問了幾個比較像 reviewer 的問題。

Q1：CI 通過就代表可以上架嗎？

如果 flutter analyze 和 flutter test 都通過，
是不是就代表這個 App 可以上架？

Codex 的回答很清楚：

CI 通過代表基本品質門檻通過。
不代表完成上架準備。

真正要上架還需要簽章、icon、splash、隱私權、商店素材、真機測試、環境設定等一整段流程。

Q2：學習專案為什麼也要 checklist？

這只是學習 repo，
為什麼還要 official sample quality checklist？

Codex 幫我換了一個角度：

因為學習範例會被拿來模仿。
範例越清楚，學到的習慣越正確。

所以範例不是低標準程式碼。它反而要更清楚地呈現架構邊界和教學意圖。

Q3：coverage artifact 要怎麼看？

CI 上傳 coverage/lcov.info，
我應該怎麼用它，而不是只把它當報表？

我得到的答案是：

用它檢查 feature 的學習重點是否有測試保護。

例如新增 Settings 偏好後，如果只有 UI，沒有 repository / ViewModel test，那 coverage 就是在提醒測試保護不完整。

Q4：下一輪先補什麼最有價值？

下一輪要補 accessibility / localization、deployment environment、golden test。
如果只能先選一個，該怎麼排序？

Codex 建議先看目標。

如果要更像成熟 app，先補 accessibility / localization。

如果要更接近交付流程，先補 deployment / environment。

如果 UI 已經開始穩定，才投入 golden test。

這個回答讓我不再把下一步當成清單亂補，而是回到目標選擇。

今日最小練習：做一份專案驗收筆記

Day 7 的最小練習不是改程式。

我會做一份驗收筆記，分成四段：

目前已完成
仍需 Flutter SDK / CI 驗證
下一輪優先補強
我現在能解釋的 Flutter 工程概念

其中「我現在能解釋的概念」至少要包含：

app shell
Widget tree
route
ThemeData
Form / validator
ViewModel
Repository
Service
SharedPreferences
fake repository
Riverpod override
CI / coverage artifact

如果我能用自己的話講完這些，代表這七天不是只看過程式碼，而是真的把專案地圖、畫面語言、資料流和品質檢查串起來了。

Day 7 結論：AI 讓我更快開始，但品質仍然要靠工程判斷

七天走完，我對「用 AI 學 Flutter」的感覺更具體了。

AI 很適合幫我：

生成一個可拆解的學習專案
解釋陌生語法和架構
把 Widget tree 翻成白話
從 View 一路追到 Repository 和 Service
幫我列修改影響範圍
幫我做測試策略和品質檢查

但 AI 不能替我省掉工程判斷。

我仍然需要問：

這個狀態應該放在哪一層？
這個範例是不是只教一個主題？
這個錯誤使用者看得到嗎？
這個功能有測試保護嗎？
這份文件和程式碼一致嗎？
本機不能驗證時，CI 有沒有補上？

所以這七天最大的收穫，不是「我已經精通 Flutter」。

而是我終於有一張地圖，知道 Flutter 專案可以怎麼被閱讀、拆解、驗證和延伸。

接下來如果要繼續，我會從三個方向開始：

accessibility / localization
deployment / environment
golden test 或更完整的 UI 回歸測試

這一週不是終點。

它比較像是把第一條路鋪出來。