跳到主要内容
返回使用场景

Codex 使用场景

重构 SwiftUI 屏幕

使用 Codex 将一个过大的 SwiftUI 屏幕拆分成小型子视图，同时不改变行为或布局。

高级1 小时iOS代码
在 Codex app 中尝试官方来源

概览

使用 Codex 和 Build iOS Apps plugin，将一个冗长的 SwiftUI 视图拆分为专门的分区视图，把副作用移出 `body`，稳定 state 和 Observation 的用法，并让重构保持 MV 优先，而不是引入不必要的视图模型。

适合场景

  • 庞大的 SwiftUI 文件，其中 `body` 在一个难以审查的屏幕里混合了布局、分支、异步工作和内联操作
  • 现有 iOS 功能需要在视觉效果和行为上保持完全一致，同时让内部实现更易于维护
  • 包含计算得出的 `some View` 片段、可选视图模型或 state 传递逻辑的屏幕，这些内容应当被简化为明确的子视图输入和回调

在不改变行为的情况下重构一个大型屏幕

使用 Build iOS Apps plugin 及其 SwiftUI 视图重构技能来清理 [NameOfScreen.swift]，不要改变这个屏幕的功能或外观。

约束：
- 保留行为、布局、导航和业务逻辑，除非你发现了必须单独指出的 bug。
- 默认采用 MV，而不是 MVVM。在引入新的视图模型之前，优先使用 `@State`、`@Environment`、`@Query`、`.task`、`.task(id:)` 和 `onChange`；只有当这个功能确实明显需要时，才保留视图模型。
- 重新组织视图，使存储属性、计算状态、`init`、`body`、视图辅助代码和辅助方法从上到下都易于浏览。
- 将有意义的分区提取为专门的 `View` 类型，使用小而明确的输入、`@Binding` 和回调。不要只是用一堆大型计算得出的 `some View` 属性去替换一个巨大的 `body`。
- 将不简单的按钮操作和副作用移出 `body` 放到小方法中，并将真正的业务逻辑移到服务或模型中。
- 保持根视图树稳定。避免使用顶层 `if/else` 分支去切换完全不同的屏幕；如果局部条件分区或修饰符已经足够，就优先使用它们。
- 在重构时修正 Observation 的所有权：对于 iOS 17+ 上根级别的 `@Observable` 模型，使用 `@State`；除非 UI 的确需要那种状态形态，否则避免使用可选或延迟初始化的视图模型。
- 每次提取后，运行最小但有意义的构建或测试检查，以证明屏幕行为仍然一致。

交付内容：
- 重构后的屏幕以及任何提取出的子视图
- 对新的子视图边界和数据流的简短说明
- 任何你有意保留视图模型的位置以及原因
- 你运行过的验证检查，用于证明行为保持不变

在不改变屏幕功能的情况下重构单个屏幕

这个用例适用于这样一种情况：某个 SwiftUI 文件已经膨胀成一个巨大的屏幕，每次做一点小改动都感觉有风险。目标不是重新设计这个功能，也不是发明一种新架构。让 Codex 保留行为和布局，然后把屏幕拆分成具有明确数据流的小型子视图，这样下一次改动就会更容易审查。

对于这类清理工作，请使用 Build iOS Apps 插件。它的 SwiftUI 视图重构技能带有一种很有帮助的明确倾向：默认优先采用 MV 而不是 MVVM，将业务逻辑保留在服务或模型中，优先使用本地视图 state 和环境依赖，并且只有在功能确实明显需要时才保留视图模型。

让 Codex 做什么

先指定一个具体的屏幕文件，并要求 Codex 在保留行为的同时改进结构。以下这些重构规则值得直接写进你的提示词中：

  • 重新组织文件，使环境依赖、存储属性、计算得出的非视图 state、init、body、视图辅助代码和辅助方法从上到下都易于浏览。
  • 将有意义的分区提取为专门的 View 类型，使用小而明确的输入、@Binding 和回调。
  • 让计算得出的 some View 辅助代码尽量少且保持简短。不要把一个巨大的屏幕重新构建成一长串私有的计算视图片段。
  • 将不简单的按钮操作和副作用移出 body，并将真正的业务逻辑移到服务或模型中。
  • 保持根视图树稳定。优先在分区或修饰符中使用局部条件，而不是通过顶层 if/else 分支来切换整个屏幕。
  • 在进行过程中修正 Observation 的所有权。对于 iOS 17+ 上根级别的 @Observable 模型，拥有它们的视图应将其存储在 @State 中；仅在部署目标确实要求时才使用旧式可观察包装器。

要求一个小型验证循环

保持行为不变的重构应当附带证据。让 Codex 在每次有意义的提取之后，运行能够覆盖该屏幕的最小构建、预览、测试或模拟器检查，然后总结结构上发生了什么变化，以及哪些内容被有意保持不变。

实用建议

先拆分，再讨论架构

如果一个屏幕过于庞大，先让 Codex 提取分区视图，再考虑是否需要引入新的抽象层。更短、更明确的视图树通常会消除必须添加视图模型的压力。

向每个子视图传入尽可能小的接口

优先使用 let 值、@Binding 和单一用途的回调，而不是把整个父模型都交给每个子视图。这样每个提取出的分区都更容易预览，也更不容易意外地重新耦合回整个屏幕。

让 Codex 明确指出有意不做的改动

对于安全的重构，如果 Codex 能明确列出它没有改动的内容，会很有帮助：业务规则、导航行为、持久化、分析语义以及用户可见的布局。这样可以让审查快得多。