重构单个屏幕，同时保持其功能不变

当 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 执行能覆盖该屏幕且范围最小的构建、预览、测试或模拟器检查，然后总结结构上做了哪些更改，以及哪些内容有意保持不变。

实用技巧

先拆分，再讨论架构

如果屏幕过于庞大，请先让 Codex 提取区段视图，再引入新的抽象层。更短、更明确的视图树通常足以消除添加视图模型的必要。

为每个子视图提供尽可能精简的接口

与其把完整的父级模型交给每个子视图，不如优先传入 let 值、@Binding 和单一用途的回调。这样，每个提取出的区段都更易预览，也不易意外地再次与整个屏幕耦合。

让 Codex 明确指出哪些内容有意保持不变

对于安全的重构，让 Codex 明确列出它未更改的内容会很有帮助：业务规则、导航行为、持久化、分析语义和用户可见布局。这能大幅加快审查。