第 3 章：產生設計規格¶

本章你要產出詳細的設計文件，寫在 design.md 中。

design.md 是你記錄技術架構、循序圖與實作考量的地方。這份文件描述系統如何運作的「全貌」，包含各個元件以及它們之間的互動。

design.md → 滿意？ ──否──→ 編輯 / 要求修改 ─┐
              │                          │
              是                         └─→ 回到 design.md
              ↓
          進入 tasks 階段

3.1 檢視設計草稿¶

上一章結尾你已經進入設計階段，Kiro 產出了 design.md。點 Design 圖示開啟這份檔案。

3.2 精修設計¶

檢視 design.md 後，你可以請 Kiro 強化它。

向 Kiro 詢問最佳實務¶

想得到更好的設計，可以先問問 Kiro 有哪些該考慮的事。

例如問它常數與參數該放哪裡：

我希望能輕鬆調整常數與參數，你有什麼建議？

我應該把程式邏輯和數值分開嗎？

把應用程式常數集中管理¶

寫一個 prompt 要 Kiro 把參數集中到一處。

更新設計，把所有應用程式常數集中到一個地方管理。

這件事對後面的章節很有幫助。遊戲的手感（重力、跳躍力道、水管間距、速度）需要反覆微調，常數集中在一處時，調整一個數字就能立刻試玩，不用在程式各處翻找。

（選配）補充其他設計細節¶

和需求階段一樣，你可以持續檢視並更新 design.md。

加入精確的偵測演算法：Ghosty 用圓形碰撞、牆面用矩形邊界、地板與天花板偵測。

納入最佳化準則，包含 60 FPS 的目標、有效率的 sprite 批次繪製，
以及障礙物物件池的記憶體管理。

3.3 （選配）用 property-based test 確保正確性¶

為了確保產出的應用程式符合你的預期，Kiro 的 correctness 機制採用 property-based testing（PBT，性質導向測試）。這讓 Kiro 能在整個專案範圍驗證通用性質。透過自動把自然語言規格轉譯成可執行的性質、並產生完整的測試案例，Kiro 建立起一個回饋迴路，同時幫助 AI agent 與人類開發者做出更可靠的軟體。

在設計階段，Kiro 會從你的需求中萃取出性質並產生測試案例。這是整個流程的第一步 — Kiro 分析你的需求，找出哪些性質是可測試的。

要檢視應用程式的 property-based test，在 design.md 中找 Correctness Properties 段落。

為什麼這對遊戲特別有用：遊戲的核心邏輯（重力、碰撞、計分、水管生成）是純粹的數值運算，很適合用性質來驗證。例如「Ghosty 的垂直速度永遠不超過終端速度」、「分數只會增加不會減少」這類性質，用一般的範例測試很難覆蓋完整，但 PBT 會自動產生大量隨機輸入去嘗試打破它。

3.4 完成設計¶

在 IDE 終端機視窗中，把設計 commit 到本機 Git repository：

git add .
git commit -m 'Produced design'

完成設計後，點編輯器視窗上方的 Continue > Generate Tasks 進入下一階段

提示：Kiro 的彈性足以讓你用多種方式設計與建構應用程式。你也可以直接在 chat panel 中指示 Kiro 進入下一階段，就像你從需求階段進到設計階段那樣。

本章小結¶

你已完成設計文件。

接下來要產生、審查、迭代並完成詳細的實作計畫。

← 上一章：產生需求規格 | 下一章：產生實作任務 →