swiftui-patterns
作者 affaan-mswiftui-patterns 是一份面向 Apple 平台前端开发的实用指南。它涵盖 SwiftUI 状态管理、NavigationStack 流程、视图组合和性能建议，帮助你为真实应用代码选择合适的模式。适合在重构或构建界面时使用，尤其是在需要明确职责划分、减少重复渲染的场景中。
该技能得分 84/100，说明它是目录用户寻找 SwiftUI 专项指导、而不是通用提示词时的可靠候选。仓库展示了一个真实、非占位、面向工作流的技能，激活信号清晰，模式指导具体，并且包含足够多的 SwiftUI 实质内容，值得安装。
- SwiftUI 相关工作的适用范围很明确：视图、状态管理、NavigationStack、view model、性能和依赖注入。
- 内容具有较强的教学性，包含标题、表格和代码示例，能让 agent 更少猜测地应用该技能。
- 没有占位或实验性标记；技能正文篇幅充足，聚焦于现代 Apple 平台的 SwiftUI 模式。
- 没有安装命令或配套参考文件，因此用户只能依据 SKILL.md 内容来判断采用信心。
- 内容更偏向模式与最佳实践，可能不太适合高度具体的业务场景或调试工作流。
swiftui-patterns 技能概览
swiftui-patterns 是做什么的
swiftui-patterns 技能帮助你用正确的状态、导航和组合模式来构建 SwiftUI 界面，而不是停留在泛泛的提示词建议上。它尤其适合 Apple 平台上的 Frontend Development 场景：当你需要在真实 App 代码里判断该用 @State、@Binding、@Observable、@Bindable 还是 @Environment 时，它能提供更实用的选择指南。
谁应该使用它
如果你符合下面这些情况，就适合使用 swiftui-patterns 技能：
- 正在开始一个新的 SwiftUI 功能，需要做清晰的架构选择
- 在重构一个状态过多、难以维护的视图
- 要添加
NavigationStack流程、列表密集型页面，或共享依赖 - 想减少不必要的重新渲染并提升视图性能
安装决策中的主要价值
当任务不是“写任何 SwiftUI 代码”，而是“让一个 SwiftUI 页面行为正确，并且保持易改”时，这个 repo 很有用。它最强的信号，是围绕现代 SwiftUI 状态管理与 @Observable 的指导；相比笼统的 UI 提示，它更可执行，因为它会把你引向合适的所有权模型和渲染边界。
如何使用 swiftui-patterns 技能
swiftui-patterns 安装方式
把 swiftui-patterns 技能安装到你的 Claude Code skills 目录中，然后在需要架构判断的 SwiftUI 任务上调用它。一个典型的安装命令是：
npx skills add affaan-m/everything-claude-code --skill swiftui-patterns
安装后，先确认该技能已可用，再把它用于功能分支或重构任务。
它需要什么输入
这个技能在你提供具体的 SwiftUI 场景时效果最好，而不是模糊需求。建议包含：
- 平台目标：iOS、macOS，或两者都有
- 页面类型：列表、详情、表单、引导、设置等
- 状态归属：本地、父级持有、共享，或基于 environment
- 导航形态：push、stack、sheet、split view，或 deep link
- 性能关注点：大列表、频繁更新、昂贵布局等
较弱的提示是：“改进这个 SwiftUI 视图。”
更强的提示是：“用 @Observable 处理模型状态、用 NavigationStack 做下钻导航，并在单个条目变化时尽量减少重新渲染，重构这个 iOS 17 的 SwiftUI 列表页。”
先看哪里
想把 swiftui-patterns 用好，建议先看 SKILL.md，重点关注与问题对应的部分：When to Activate、State Management、Property Wrapper Selection 和 @Observable ViewModel。这些内容会告诉你技能适用的场景，以及它预期状态如何在应用中流动。
实用工作流
- 用状态归属和导航方式来描述功能或 bug。
- 先让模型决定要用哪个 wrapper 或模式，再写完整代码。
- 检查结果是否采用了最简单、且足够用的状态模型。
- 如果输出看起来过度设计，就让它简化所有权或移除不必要的 wrappers。
- 用真实更新来测试视图，而不只是看静态渲染结果。
swiftui-patterns 技能 FAQ
swiftui-patterns 只适合新项目吗？
不是。swiftui-patterns 技能同样适合已有代码库，尤其是在你想替换较旧的 ObservableObject 模式、降低视图耦合，或者在不推倒重写的前提下清理导航和列表性能时。
它和普通提示词有什么区别？
普通提示词可能会生成 SwiftUI 代码，但 swiftui-patterns 会先给你一套选择正确模式的决策框架。当真正的风险不是语法，而是状态归属错误、不必要的重绘或脆弱的导航时，这一点尤其重要。
它适合初学者吗？
适合，只要你把它当作一个引导式决策工具来用。这个技能最有帮助的场景，是你已经有具体页面，想知道哪个 wrapper 或组合方式更合适，而不是单纯背 SwiftUI 理论。
什么情况下不该用它？
如果你的任务主要是 UIKit、服务端 Swift，或者非 Apple 前端，就不要依赖 swiftui-patterns。对于纯视觉设计工作、且不涉及状态、流程或渲染行为的场景，它也不是最佳选择。
如何改进 swiftui-patterns 技能
把状态归属说清楚
最好的结果来自你对每一块状态归属的明确说明。比如，说明表单字段是属于视图本身、模型是由父级传入，还是多个页面需要同一份单一事实源。这是获得更好 swiftui-patterns 输出的最快方式。
要求说明 wrapper 选择理由
如果你想得到更高质量的答案，可以要求技能解释为什么选择 @State、@Binding、@Observable、@Bindable 或 @Environment。这样能减少 wrapper 被误用或过度使用，也能帮助你在实现前发现不匹配的问题。
留意常见失败模式
最常见的失败模式是过度工程化：明明本地状态更简单，却用了共享状态或 observable 模型。另一个问题是导航建议过于空泛，忽略了真实的应用流程。你可以通过补充具体用户动作、目标页面，以及导航后哪些状态应该保留，来改进提示词。
用具体代码样例反复迭代
第一次输出后，把真实的 SwiftUI view 或 view model 贴进去，要求做定向重写。明确说明你想改进什么，比如减少重复计算、简化 binding，或者让组合方式更清晰。对于 Frontend Development 场景下的 swiftui-patterns，这通常是从通用建议走到可交付 SwiftUI 代码最快的路径。