iOSUIKit架构Skill：让 AI 按 MVVM 与 Coordinator 规范写出可维护的 UIKit 代码
- 它是什么：一个面向 iOS UIKit 工程的架构知识技能，把 MVVM、Coordinator、依赖注入、程序化自动布局、Diffable Data Source、UIKit 与 SwiftUI 互操作等最佳实践沉淀成 AI 可调用的规则与示例。
- 它解决什么：iOS 老项目常见的“巨型 ViewController”“故事板 segue 意大利面”“强制类型转换单元格”等问题，让 AI 生成代码时不再写出能跑但难维护的写法。
- 怎么用：这是一个由模型自动参考的技能（详情中标注
user-invocable: false），无需输入斜杠命令，安装后在提问中描述你的 UIKit 架构需求，即可被自动引用。 - 适合谁：正在维护 UIKit 存量工程、准备做架构分层改造的 iOS 开发者与团队技术负责人。
- 一句话结论：它把“架构规范”从文档里的口头约定，变成 AI 直接可执行的编码习惯。
1. 该技能叫什么？如何下载安装 AI 技能提升开发效率？
基本信息
| 项目 | 内容 |
|---|---|
| 技能中文名 | iOSUIKit架构Skill |
| 技能英文名 | ios-uikit-architecture |
| 技能ID | 14015 |
| 技能类型 | 模型自动参考型技能（user-invocable: false，不通过斜杠命令手动触发） |
| 声明可用工具 | Read（读取）、Write（写入）、Edit（编辑）、Bash（命令行）、Grep（内容检索）、Glob（文件匹配） |
它解决什么问题
UIKit 已经非常成熟，但成熟也意味着写法太多：同一个页面，有人写 MVC 塞满一个 ViewController，有人用 MVVM 拆视图模型，有人用 Coordinator 管理跳转，还有人把 SwiftUI 混进来。团队没有统一规范时，代码风格靠口口相传，新人和 AI 生成的代码往往“能跑但无法维护”。这个技能就是把架构约定固化成可被 AI 直接读取和遵循的规则集，覆盖架构模式、最佳实践与反模式三类内容。
一键安装的思路与步骤
该技能声明了文件读写与命令行工具，因此它更像是“装进 AI 编程环境里的一份架构规范手册”。由于技能详情未提供具体的安装命令与分发地址，以下为通用流程，具体命令与入口请以官方说明为准：
- 确认安装前提：你的 AI 编程助手/客户端需要支持 AI 技能（Skill）机制，并已登录可用的账号；本地需有可访问的 iOS 工程目录。
- 获取技能：在客户端提供的技能市场或技能库中搜索英文名
ios-uikit-architecture，或按官方说明导入技能包。 - 启用技能：安装后在技能列表中确认其状态为“已启用”。因为它是非手动调用型技能，通常不需要额外配置快捷指令。
- 确认权限范围：检查是否授予了读取/写入代码文件的权限（对应 Read、Write、Edit、Grep、Glob），若只希望它“只读给建议”，可在客户端侧限制写入权限。
- 验证是否生效：在对话中提出一个典型的 UIKit 架构问题，例如“我的商品详情页 ViewController 有 1200 行，怎么按 MVVM 拆分？”观察回答是否引用了视图模型、协调器、依赖注入等概念，并给出可编译的 Swift 示例。若回答仍是泛泛而谈，说明技能未被引用，需回到第 2–3 步检查安装状态。
2. 该技能的主要功能和特点
- 三大架构模式落地：覆盖 MVVM（模型 / 视图 / 视图模型分层）、MVC 与 Coordinator 模式，明确各层职责边界，并给出模型、视图模型、视图控制器的完整代码示例。
- 导航逻辑解耦：通过 Coordinator 协议（含
childCoordinators、navigationController、start()）把页面跳转从视图控制器中抽离，解决“故事板 segue 意大利面”问题。 - 依赖注入规范：以初始化器注入服务协议（如
UserServiceProtocol），提升可测试性，并给出init?(coder:)的显式处理方式。 - 程序化 UI 与自动布局：提供使用
NSLayoutConstraint.activate构建自定义视图的标准写法，强调translatesAutoresizingMaskIntoConstraints = false等易错细节。 - 现代集合视图：使用
UICollectionViewDiffableDataSource与UICollectionViewCompositionalLayout.list构建列表，替代传统dataSource手动维护数组的做法。 - UIKit 与 SwiftUI 双向互操作：既给出用
UIHostingController在 UIKit 中托管 SwiftUI 视图的写法，也给出用UIViewRepresentable在 SwiftUI 中包装 UIKit 控件（如地图）的写法。 - 生命周期与内存管理：示范用
Task管理异步加载并在viewDidDisappear中取消任务，以及用[weak self]避免闭包循环引用。 - 反模式清单：明确指出巨型视图控制器、复杂 segue、
as!强制转换单元格等坏味道，并给出“好”的替代写法。 - 与相邻技能衔接：可配合
ios-swiftui-patterns（声明式 UI）与ios-swift-concurrency（异步数据加载）一起使用。
和普通代码补全工具相比，它的差异不在“补全速度”，而在“补全方向”——它优先输出分层清晰、可测试、可扩展的写法，而不是最短的写法。
3. 如何使用该技能？
由于该技能为模型自动参考型，使用方式就是用自然语言描述架构诉求，让 AI 在技能规则约束下产出代码。推荐按以下步骤操作：
- 明确上下文：告诉 AI 你使用的 UI 框架（UIKit / SwiftUI / 混合）、最低系统版本、是否已有架构基础。
- 描述目标与约束：例如“需要 MVVM 分层”“跳转由 Coordinator 管理”“不引入第三方库”。
- 让 AI 先给结构再给代码：先要分层清单（模型 / 视图模型 / 视图 / 协调器 / 服务），确认无误后再要具体实现。
- 逐文件落地：让 AI 输出可直接写入工程的 Swift 文件，并用 Grep/Glob 检查重复定义。
- 复核与测试：重点检查循环引用、线程切换、
coder初始化等易错点。
输入示例
我有一个商品详情页
ProductDetailViewController，目前集合了网络请求、价格格式化、跳转和 UI 布局，约 1100 行。请按 MVVM + Coordinator 拆分，网络层用协议注入，列表部分用 Diffable Data Source 重写，输出各文件职责与关键代码。
预期输出说明
- 一份分层职责表：
Product（模型）、ProductDetailViewModel（表示逻辑与格式化）、ProductDetailViewController（只负责渲染与事件转发）、ProductDetailCoordinator（页面跳转）。 - 视图模型示例形态：把
price转换成priceDisplay这类“供显示用的计算属性”，不把格式化逻辑留在视图里。 - 视图控制器示例形态：通过
init(viewModel:)注入视图模型，viewDidLoad中只做赋值与约束。 - 列表示例形态：注册
UICollectionView.CellRegistration，通过dataSource.apply(snapshot, animatingDifferences: true)刷新。 - 导航示例形态：
coordinator.showDetail(for:)替代直接pushViewController。 - 反模式提示：AI 通常会主动提醒避免
as!强转与过长的viewDidLoad。
混合项目示例
这个页面主体是 UIKit，但设置区块想用 SwiftUI 写，怎么嵌？
预期会给出 UIHostingController 的挂载方式（addChild、didMove(toParent:)、autoresizingMask），反向场景则给出 UIViewRepresentable 配合 Coordinator 的包装写法。
4. 同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| ios-uikit-architecture（本技能） | UIKit 架构规范与示例库 | MVVM/Coordinator/依赖注入、程序化布局、Diffable Data Source、UIKit 与 SwiftUI 互操作、反模式清单 | 需支持技能机制的 AI 客户端；非手动调用，随对话自动引用 | 存量 UIKit 工程分层改造、新页面架构统一、代码评审对齐 | 优势：规则集中、示例完整、能约束 AI 输出方向；不足：聚焦架构层面，不含 UI 视觉细节与性能调优专项 |
| Apple 官方文档与 WWDC 视频 | 权威一手资料 | API 语义、系统行为、官方推荐写法 | 免费公开，但需自行检索与消化 | 查具体 API、确认系统行为边界 | 优势：权威准确；不足：不针对你的工程结构给方案，缺少“团队落地规范”视角 |
| Xcode 工程模板 / 脚手架 | 项目初始化工具 | 生成目录结构与基础类 | 低，IDE 内置 | 新项目起步 | 优势：开箱即用；不足：只给骨架，不解释取舍，也管不住后续代码风格漂移 |
| 通用 AI 编程助手直接对话 | 通用代码生成 | 写代码、解释代码、改 Bug | 极低 | 零散编码问题 | 优势：灵活；不足：缺少 iOS 架构专项上下文，容易输出“能跑但扁平”的巨型控制器写法 |
一句话选择建议：查 API 用官方文档，新建工程用模板，而“怎么组织代码才不会越写越乱”这类问题，正是本技能的主场。
5. 该技能的典型应用场景与实际体验情况
场景一：存量工程的大控制器拆分（iOS 开发工程师） 痛点：页面逻辑膨胀，改动一处就要回归全页。使用方式：把视图控制器的职责列给 AI，要求按 MVVM 拆分并生成视图模型草案。实际体验：上手几乎零成本，回答通常直接给出“模型 / 视图模型 / 视图 / 协调器 / 服务”的划分，并附可编译代码；注意需自行确认原有业务逻辑是否被完整迁移，不要一次性全量替换。
场景二：新项目架构选型（技术负责人） 痛点：团队对新项目该用 MVC 还是 MVVM+Coordinator 争论不下。使用方式：让 AI 对比两种模式在本项目规模下的取舍，并输出团队规范草稿。实际体验：技能给出的分层示例可直接作为规范附件；注意技能本身不提供团队规范文档格式，需要自己整理成内网文档。
场景三：UIKit 老工程局部接入 SwiftUI（迭代开发者）
痛点：整体重写成本太高，只想先把设置页换成 SwiftUI。使用方式：请求 UIHostingController 嵌入方案与状态回传方案。实际体验：双向互操作示例覆盖了常见情形，尤其是 UIViewRepresentable 的 Coordinator 写法省去了查文档时间；注意跨框架的状态同步仍需手动设计。
场景四：代码评审统一口径（团队评审人）
痛点：评审意见因人而异，容易变成风格之争。使用方式：让 AI 按技能中的反模式清单检查待评审代码。实际体验：as! 强转、巨型控制器、复杂 segue 这几类高频问题能被快速点出；注意工具声明了文件读写权限，评审场景建议只读使用，避免误改。
6. 该技能能为用户带来的价值
- 效率提升：把“查文档 + 想分层 + 写样板代码”合并成一次提问，页面拆分这类工作的前期设计时间可从半天压缩到一次对话内完成。
- 门槛降低：对刚接手 UIKit 存量工程的开发者，Coordinator、依赖注入、Diffable Data Source 这些概念通过可直接运行的示例理解，比读抽象文档更快。
- 质量收益：反模式清单相当于一份可执行的评审标准，长期使用能减少大控制器和强制转换的增量。
- 可测试性提升：初始化器注入 + 协议抽象的组合，让视图控制器具备被替换依赖、单独测试的条件。
- 长期价值：架构规范一旦被沉淀进技能，团队里每个人（以及每个 AI 助手）产出的代码都朝同一个方向收敛，减少架构漂移带来的长期维护成本。
7. 常见问题 FAQ
Q1：怎么安装这个技能？需要敲什么命令？
A：在支持技能机制的 AI 客户端中搜索英文名 ios-uikit-architecture 或按官方说明导入技能包即可。技能详情本身未提供具体安装命令与分发地址，请以官方说明为准。安装后在技能列表中确认启用状态，并通过一次架构提问验证是否生效。
Q2：为什么我在对话里找不到斜杠命令触发它？
A：因为该技能标注了 user-invocable: false，属于由模型自动参考的类型，不需要也无法通过手动命令触发。你只需正常描述 UIKit 架构需求，例如“按 MVVM 拆分这个页面”，它会在需要时被引用。
Q3：收费吗？ A：技能详情中未包含任何价格信息，是否收费取决于你所使用的技能分发平台与账号套餐，请以官方说明为准。
Q4：它适合谁用？我就写个小 Demo，需要装吗？ A：主要适合维护 UIKit 存量工程、做架构分层改造、需要统一团队编码规范的 iOS 开发者与技术负责人。如果只是几十行的演示项目，收益有限，不必强上分层。
Q5：和直接用通用 AI 助手问 UIKit 问题有什么区别？ A：通用助手也能回答，但缺少架构专项上下文，容易给出扁平写法。本技能内置了 MVVM/Coordinator 示例与反模式清单，输出方向更稳定。遇到具体 API 细节，仍建议以 Apple 官方文档为准。