原文核对：2026-10-13 · 中文正文 · 英文提示词与演示
场景定位
拆分长视图，将副作用移出 body，稳定状态与 Observation，优先 MV，避免不必要的 view model。
- 难度
- 高级
- 时间跨度
- 1 小时
适合用于
- body 混合布局、分支、异步任务和内联操作的巨大页面。
- 要求视觉和行为不变、只改善内部结构的功能。
- 需要简化计算型视图片段、可选 view model 或状态传递的页面。
相关工具
提取独立子视图、保留稳定数据流、简化 Observation，同时保持行为。
Build iOS Apps ↗起步提示词
英文原文 · 可复制后按实际材料修改
Use the Build iOS Apps plugin and its SwiftUI view refactor skill to clean up [NameOfScreen.swift] without changing what the screen does or how it looks.
Constraints:
- Preserve behavior, layout, navigation, and business logic unless you find a bug that must be called out separately.
- Default to MV, not MVVM. Prefer `@State`, `@Environment`, `@Query`, `.task`, `.task(id:)`, and `onChange` before introducing a new view model, and only keep a view model if this feature clearly needs one.
- Reorder the view so stored properties, computed state, `init`, `body`, view helpers, and helper methods are easy to scan top to bottom.
- Extract meaningful sections into dedicated `View` types with small explicit inputs, `@Binding`s, and callbacks. Do not replace one giant `body` with a pile of large computed `some View` properties.
- Move non-trivial button actions and side effects out of `body` into small methods, and move real business logic into services or models.
- Keep the root view tree stable. Avoid top-level `if/else` branches that swap entirely different screens when localized conditional sections or modifiers are enough.
- Fix Observation ownership while refactoring: use `@State` for root `@Observable` models on iOS 17+, and avoid optional or delayed-initialized view models unless the UI genuinely needs that state shape.
- After each extraction, run the smallest useful build or test check that proves the screen still behaves the same.
Deliver:
- the refactored screen and any extracted subviews
- a short explanation of the new subview boundaries and data flow
- any places where you intentionally kept a view model and why
- the validation checks you ran to prove behavior stayed intact保持行为地重构一个页面
文件膨胀、每次小改都有风险时，保留布局与行为，拆成数据流明确的小视图，使后续修改易于审阅。
Build iOS Apps 的 view refactor 技能默认 MV 优于 MVVM：业务逻辑放服务或模型，先使用本地视图状态和环境依赖，确有需要才保留 view model。
明确重构要求
指定一个页面文件，并加入以下规则：
- 按环境依赖、存储属性、非视图计算状态、init、body、视图辅助和辅助方法组织文件。
- 有意义的区块提取为独立 View，使用少量显式输入、@Binding 和回调。
- 计算型 some View 辅助保持少而小，避免把大页面换成一长串私有计算片段。
- 复杂按钮操作和副作用移出 body，真正业务逻辑放服务或模型。
- 保持根视图树稳定，优先局部条件或修饰符，避免顶层 if/else 替换整页。
- 理顺 Observation 归属：iOS 17+ 的根 @Observable 模型由拥有它的视图用 @State 保存，仅旧部署目标需要时使用旧包装器。
小步验证
每次重要提取后运行最小构建、预览、测试或模拟器检查，并说明结构变化和有意保持不变的内容。
实用建议
先拆分，再讨论架构
先提取区块视图，再考虑新增抽象层；更短、更明确的视图树可能已无需 view model。
传递最小接口
优先 let、@Binding 和单一职责回调，避免向每个子视图传整个父模型，以便预览并降低耦合。
列出有意不改的内容
明确业务规则、导航、持久化、分析埋点语义和可见布局未改变，有助快速审阅。
技术栈
| 需要 | 默认选项 | 用途 |
|---|---|---|
| UI 架构 | 以 MV 为先的 SwiftUI，将状态分配给 @State、@Environment 和小型专用 View 类型 | 先简化视图树和状态流，再考虑增加视图模型层，通常更有利于维护大型页面。 |
| 重构流程 | Build iOS Apps 插件Build iOS Apps plugin ↗ | 插件中的 SwiftUI 视图重构技能提供抽取、Observation 和副作用清理规则，同时保持行为一致。 |
| 验证 | xcodebuild、预览和聚焦的 UI 检查 | 每次抽取后进行小范围构建或模拟器检查，更容易确认重构保留了行为。 |
展开英文原文对照
Use Codex and the Build iOS Apps plugin to break a long SwiftUI view into dedicated section views, move side effects out of body, stabilize state and Observation usage, and keep the refactor MV-first instead of introducing unnecessary view models.
Refactor one screen without changing what it does
This use case is for the moment when a SwiftUI file has grown into one giant screen and every small edit feels risky. The goal is not to redesign the feature or invent a new architecture. Ask Codex to preserve behavior and layout, then split the screen into small subviews with explicit data flow so the next change becomes easier to review.
Use the Build iOS Apps plugin for this kind of cleanup. Its SwiftUI view refactor skill is opinionated in a useful way: default to MV over MVVM, keep business logic in services or models, use local view state and environment dependencies first, and only keep a view model when the feature clearly needs one.
What to ask Codex to do
Start by naming one concrete screen file and asking Codex to preserve behavior while improving structure. These are the refactor rules worth putting directly in your prompt:
- Reorder the file so environment dependencies, stored properties, computed non-view state, init, body, view helpers, and helper methods are easy to scan top to bottom.
- Extract meaningful sections into dedicated View types with small explicit inputs, @Bindings, and callbacks.
- Keep computed some View helpers rare and small. Do not rebuild one giant screen as a long list of private computed view fragments.
- Move non-trivial button actions and side effects out of body, and move real business logic into services or models.
- Keep the root view tree stable. Prefer localized conditionals in sections or modifiers over top-level if/else branches that swap whole screens.
- Fix Observation ownership as you go. For root @Observable models on iOS 17+, the owning view should store them in @State; use legacy observable wrappers only when your deployment target requires that.
Ask for a small validation loop
Behavior-preserving refactors should come with proof. Ask Codex to run the smallest build, preview, test, or simulator check that exercises the screen after each meaningful extraction, then summarize what changed structurally and what stayed intentionally the same.
Practical tips
Split first, then debate architecture
If a screen is too large, ask Codex to extract section views before introducing a new abstraction layer. A shorter, more explicit view tree often removes the pressure to add a view model at all.
Pass the smallest possible interface into each subview
Prefer let values, @Bindings, and one-purpose callbacks over handing every child view the entire parent model. That makes each extracted section easier to preview and harder to accidentally couple back to the whole screen.
Ask Codex to call out intentional non-changes
For a safe refactor, it helps when Codex explicitly lists what it did not change: business rules, navigation behavior, persistence, analytics semantics, and user-visible layout. That makes review much faster.