開發者體驗
瞭解如何使用規範驅動開發（spec-driven development）和 Gemini 來規劃、編寫程式碼並迭代高質量的 Flutter 應用程式。
生成式 AI 不僅有助於實現應用中的功能，還有助於生成實現這些功能的程式碼。
遺憾的是，向 AI 編碼智慧體發出“構建一個解填字遊戲的 Flutter 應用”這種指令太簡單了。我相信這樣的提示語確實會產生一些東西，但我非常懷疑它能否提供像 Crossword Companion 那樣強大的、由 AI 輔助且經使用者驗證的組合方案。
然而，透過更好的提示詞引導，示例應用的大部分功能透過 Gemini 2.5 Pro 實現，並由 Gemini 3 Pro Preview 完成了最後的潤色。從兩個模型中獲得最佳結果的過程是相同的：
- 規劃
- 編碼
- 驗證
- 迭代
規劃
#規劃過程的目標是在編碼開始前提供足夠的細節，讓智慧體瞭解你的想法。Crossword Companion 的規劃過程始於以下提示詞：
I'd like to create a file called requirements.md in the plans folder at the root of the project. here's a description of the project:
The application will be an open-source sample hosted on GitHub in the flutter/demos directory. It aims to demonstrate the use of Flutter, Firebase AI Logic, and Gemini to produce an agentic workflow that can solve a small crossword puzzle (one with a size under 10x10)....lots more description of the app along with a sample puzzle screenshot...
Ask any questions you may have before you get started.
這個提示詞，經過少量的問答、人工手動編輯以及編碼過程中的一些更新，最終生成了需求文件。
在進行架構設計之前，我們要求 Gemini CLI 初始化 GEMINI.md 規則檔案，並隨後更新了一份架構原則列表。
DRY (Don't Repeat Yourself) – eliminate duplicated logic by extracting shared utilities and modules.
Separation of Concerns – each module should handle one distinct responsibility.
Single Responsibility Principle (SRP) – every class/module/function/file should have exactly one reason to change.
Clear Abstractions & Contracts – expose intent through small, stable interfaces and hide implementation details.
Low Coupling, High Cohesion – keep modules self-contained, minimize cross-dependencies.
Scalability & Statelessness – design components to scale horizontally and prefer stateless services when possible.
Observability & Testability – build in logging, metrics, tracing, and ensure components can be unit/integration tested.
KISS (Keep It Simple, Sir) - keep solutions as simple as possible.
YAGNI (You're Not Gonna Need It) – avoid speculative complexity or over-engineering.
GEMINI.md 檔案會被載入到你與 Gemini 建立的每一個新提示中；它為你希望 AI 在任何活動中記住的一組規則提供了保障。當時 Gemini 在一個空的 Flutter 應用專案中執行，因此 /init 命令記錄瞭如何構建、測試和執行它，這在編碼過程中非常有用。
如果你構建的不僅僅是一個示例，我還建議新增一些關於測試驅動開發的內容：
- **TDD (Test-Driven Development)** - write the tests first; the implementation
code isn't done until the tests pass.
這有助於建立護欄，確保編碼智慧體隨著時間的推移編寫出紮實的程式碼。
在確定了需求和規則後，下一步就是針對 design.md 檔案發出提示。
great. i'd like to work on the design with you to be created in a design.md file to be stored in the plans folder. please use the @GEMINI.md and @requirements.md files as input. ask any questions you may have before you get started.
在檢查並編輯了生成的應用設計後，我們提示 Gemini 將其細分為多個任務。
please read the files in the @specs folder and create a corresponding tasks.md file in the same folder that lays out a set of tasks and subtasks representing the functionality of this app. lay out the top-level tasks as minimal new functionality that the user can see in the running app, step-by-step as each top-level task is completed. each top-level task should include sub-tasks for creating and running tests and updating the @README.md with a description of the current functionality of the app. ask any questions you may have before you get started.
所有這些工作都在編寫任何程式碼之前完成。你不需要將事物拆分成單獨的檔案，但透過仔細考慮需求、設計和任務拆分，你是在幫助智慧體提供符合你期望的結果。這被稱為“規範驅動開發”，它是目前我們所知的將你的流程從“憑感覺編碼（vibe coding）”升級為“AI 輔助軟體開發”的最佳方式。
此外，“在開始之前提出你可能有的任何問題”這句話，是讓智慧體澄清它不理解的內容的絕佳方式，而不是讓它在過程中胡亂猜測答案。這也有助於你決定一些原本可能沒考慮到的細節。
編碼
#有了需求、規則、設計和任務，開始編碼部分就變得很簡單了。
Read the @tasks.md file and implement the first milestone.
你可以觀察編碼智慧體的工作，並在它工作時介入糾正，或者乾脆讓它自行完成。無論哪種方式，完成後，都是時候檢查它的工作成果了。
驗證
#此時，你擁有了一些程式碼，並且（在示例之外的現實世界中）還有一些測試。為了驗證，請問自己一些問題：
- 分析器顯示它沒有錯誤嗎？沒有警告嗎？
- 應用能執行嗎？
- 它具備你要求的功能嗎？這些功能有效嗎？
- 測試通過了嗎？
- 程式碼通過了你的審查嗎？
這些問題的答案是下一階段的輸入。
迭代
#收集需要解決的問題，並將需要修復的部分交還給編碼智慧體，在智慧體編碼和你的驗證之間進行迭代，直到從功能角度達到理想狀態。
現在，從架構原則的角度再次進行驗證，啟動一個新的智慧體來檢查程式碼。透過清除智慧體的上下文，你可以消除原始智慧體在最初選擇編寫程式碼時所產生的偏見。為了讓它僅基於智慧體剛才所做的程式碼更改進行評估，請使用類似這樣的提示詞：
Use git diff to find the new code and check it against the architectural principles listed here: @GEMINI.md. Make recommendations for important improvements.
多次這樣做可以讓程式碼保持良好的狀態，既適合 AI 智慧體，也適合人類閱讀。