重構 SwiftUI 介面

📖 本篇術語速查表

英文 / 縮寫	中文	一句話解釋
SwiftUI	—	Apple 宣告式 UI 框架。
重構	refactor	不改行為、改善結構的修改。
行為保持	behavior parity	重構前後介面行為要一致。

不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你把一次 SwiftUI 介面重構拆成安全、可驗證的步驟。

你是 SwiftUI 重構規劃顧問，幫我把一次介面重構拆成安全、不改行為的步驟。

【角色】
你熟悉 SwiftUI 重構的關注點，知道重構要保持行為不變、小步推進、每步可驗證。

【輸入】
- 要重構的介面 / 元件：___
- 重構目標（拆分 / 複用 / 狀態管理）：___
- 現有的測試或驗證方式：___
- 我的 SwiftUI 經驗：___

【工作流程】
1. 把重構拆成小步、每步行為不變
2. 給每步的重構目標和邊界
3. 設計行為對比驗證（前後一致）
4. 標出需視覺確認的部分

【輸出規範】
▌一、重構的分步
▌二、每步目標與邊界
▌三、行為保持的驗證
▌四、需視覺確認的部分

【硬約束】
- 重構不改變介面行為，每步驗證
- 小步可回復，不一次大改
- 視覺效果人工確認
- 沒測試先建議補關鍵路徑驗證
- 不確定的 API 標註需查官方文件
- 每完成一步重構就跑一次介面確認行為沒變，別攢一堆改動到最後才發現哪步出了問題

當一個 SwiftUI file 長成巨大的 screen，body 裡混著 layout、branching、async work 和 inline actions，每次小改都會變得高風險。這個用例的目標不是重設計 feature，也不是引入新架構，而是在不改變行為和佈局的前提下，把 screen 拆成小的 subviews，讓下一次修改更容易 review。

SwiftUI 重構的邊界是 behavior-preserving。不要藉機換架構、改導航、改視覺、改 analytics 或重寫業務邏輯，除非這些變化被明確列為單獨任務並有驗證證據。

官方頁面：https://developers.openai.com/codex/use-cases/ios-swiftui-view-refactor

適合什麼任務

場景	Codex 應該做什麼
巨大的 SwiftUI screen 很難 review	拆出 meaningful section views，保持 explicit data flow
現有 iOS feature 視覺和行為都不能變	只做結構重構，並用 build/test/simulator checks 驗證
`body` 裡混著 side effects 和 business logic	把 non-trivial actions 移到 methods，把業務邏輯移到 services 或 models
screen 裡有 optional view models 或 state plumbing	修 Observation ownership，優先 MV-first，不預設加 view model

使用的能力

能力	用法	連結
`build-ios-apps`	使用 SwiftUI view refactor skill，抽取 subviews、穩定 data flow、簡化 Observation，並保持行為不變	https://github.com/openai/plugins/tree/main/plugins/build-ios-apps

相關官方說明：

Build iOS Apps plugin：https://github.com/openai/plugins/tree/main/plugins/build-ios-apps
Agent skills：https://developers.openai.com/codex/skills

起始提示詞

請使用 Build iOS Apps plugin 和其中的 SwiftUI view refactor skill，清理 [NameOfScreen.swift]，但不要改變 screen 的行為或外觀。

約束：
- 保持 behavior、layout、navigation 和 business logic 不變；如果發現必須單獨指出的 bug，請明確說明。
- 預設採用 MV，而不是 MVVM。引入新 view model 前，優先使用 `@State`、`@Environment`、`@Query`、`.task`、`.task(id:)` 和 `onChange`；只有這個 feature 明確需要時，才保留 view model。
- 重新整理 view 順序，讓 stored properties、computed state、`init`、`body`、view helpers 和 helper methods 從上到下容易掃描。
- 把有意義的 sections 抽成獨立 `View` types，使用小而明確的 inputs、`@Binding`s 和 callbacks。不要把一個巨大 `body` 換成一堆巨大的 computed `some View` properties。
- 把 non-trivial button actions 和 side effects 從 `body` 移到小 methods，把真正的 business logic 移到 services 或 models。
- 保持 root view tree 穩定。區域性 conditional sections 或 modifiers 足夠時，避免用 top-level `if/else` 切換完全不同的 screens。
- 重構時修正 Observation ownership：iOS 17+ 上 root `@Observable` models 由 owning view 用 `@State` 持有；除非 UI 確實需要這種 state shape，否則避免 optional 或 delayed-initialized view models。
- 每完成一次 extraction，執行最小有用 build 或 test check，證明 screen 行為仍然一致。

交付：
- 重構後的 screen 和抽取出的 subviews
- 簡短解釋新的 subview boundaries 和 data flow
- 哪些地方有意保留了 view model，以及原因
- 你執行過哪些 validation checks 來證明行為保持不變

這個 prompt 明確要求 behavior-preserving refactor。Codex 不能把重構變成架構重寫。

需要	推薦預設值	原因
UI architecture	SwiftUI，MV-first，圍繞 `@State`、`@Environment` 和 small dedicated `View` types 拆分	大 screen 通常先簡化 view tree 和 state flow，再決定是否真的需要 view model
Refactor workflow	Build iOS Apps plugin	SwiftUI view refactor skill 提供 extraction、Observation 和 side-effect cleanup 規則
Validation	`xcodebuild`、previews、focused UI checks	每次 extraction 後跑小驗證，比一次性大改更可信

要求 Codex 做什麼

把這些規則直接放進 prompt：

按 environment dependencies、stored properties、computed non-view state、init、body、view helpers、helper methods 的順序整理檔案。
抽取 meaningful sections 到 dedicated View types。
子檢視只接收 small explicit inputs、@Bindings 和 callbacks。
computed some View helpers 保持少而小。
不要把一個巨大 body 改成一長串 private computed view fragments。
non-trivial button actions 和 side effects 移出 body。
業務邏輯放進 services 或 models。
root view tree 保持穩定，儘量使用區域性 conditional sections 或 modifiers。
iOS 17+ root @Observable models 由 owning view 用 @State 持有。