在不改變畫面功能的前提下重構單一畫面

此使用案例適用於 SwiftUI 檔案已膨脹為單一龐大畫面、連小幅修改都讓人覺得有風險的情況。目標不是重新設計功能或另創新架構，而是要求 Codex 保留行為與版面配置，再將畫面拆分成具有明確資料流的小型子檢視，讓之後的變更更易於審查。

請使用 Build iOS Apps 外掛程式 進行這類整理。該外掛程式的 SwiftUI 檢視重構技能提供一套明確而實用的原則：預設採用 MV 而非 MVVM，將業務邏輯留在服務或模型中，優先使用區域檢視狀態與環境相依項目，而且只有在功能明確需要時才保留檢視模型。

要讓 Codex 執行哪些工作

先指定一個具體的畫面檔案，要求 Codex 在改善結構的同時保留既有行為。下列重構規則很值得直接寫進提示詞：

• 重新調整檔案內容的順序，讓環境相依項目、儲存屬性、計算型非檢視狀態、init、body、檢視輔助項目和輔助方法從上到下都易於快速掌握。
• 將有明確用途的區段擷取成專用的 View 型別，搭配精簡明確的輸入、@Binding 和回呼。
• 少用計算型 some View 輔助項目，並保持其精簡。不要把單一龐大畫面重建為一長串私有的計算型檢視片段。
• 將較複雜的按鈕動作和副作用移出 body，並將真正的業務邏輯移至服務或模型。
• 維持根檢視樹穩定。若要使用條件式，優先將條件限制在區段或修飾器中，不要使用頂層 if/else 分支來切換整個畫面。
• 同時修正 Observation 的所有權。若是 iOS 17+ 的根 @Observable 模型，擁有該模型的檢視應以 @State 儲存；只有當部署目標有此需求時，才使用舊式的可觀察物件包裝方式。

要求執行精簡的驗證迴圈

保留行為不變的重構應有驗證結果佐證。每完成一次有意義的擷取後，要求 Codex 執行能驗證該畫面的最小範圍建置、預覽、測試或模擬器檢查，然後摘要說明結構上有哪些改變，以及刻意維持了哪些部分。

實用提示

先拆分，再討論架構

如果畫面過於龐大，請先要求 Codex 擷取區段檢視，再引入新的抽象層。更精簡明確的檢視樹，往往能讓新增檢視模型變得完全沒有必要。

為每個子檢視提供盡可能精簡的介面

應優先傳入 let 值、@Binding 和用途單一的回呼，而非把完整的父層模型交給每個子檢視。如此一來，每個擷取出的區段都更容易預覽，也較不容易意外重新與整個畫面耦合。

要求 Codex 明確指出刻意未做的變更

進行安全重構時，讓 Codex 明確列出未變更的項目會很有幫助：業務規則、導覽行為、持久化、分析資料語意，以及使用者可見的版面配置。如此可大幅加快審查速度。