Awesome CursorRules 实战指南：用 .cursorrules 统一 AI 生成的 iOS 代码风格-平芜编程栈

Awesome CursorRules 实战指南：用 .cursorrules 统一 AI 生成的 iOS 代码风格

【免费下载链接】awesome-cursorrules📄 Configuration files that enhance Cursor AI editor experience with custom rules and behaviors项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-cursorrules

Awesome CursorRules 是面向 Cursor AI 的开源规则库，把社区贡献的大量现成 .cursorrules 规则文件集中维护在一个仓库里。对做 iOS AI 辅助开发的团队来说，它解决一个很实际的痛点：AI 写出来的代码总跟你们的架构风格对不上，每次都要返工修风格。把规则文件放进项目，Cursor AI 就会照着你的规矩生成代码。适合正在用 Cursor、想把代码风格统一起来的 iOS 开发者。

先用大白话搞懂规则文件

第一次看到 .cursorrules 的人多半会疑惑：一个文本文件，凭什么能"管住"AI？

可以这么理解：新同事入职时，你会递给他一份"我们项目用 MVVM、网络请求走统一封装、命名用驼峰"的说明书——规则文件就是这份说明书，只是阅读对象换成了 Cursor AI。编辑器在生成代码前会先加载这些规则，把它当作本项目的"内部规章"。没有规则时，AI 只能凭训练学来的"通用经验"发挥；有了规则，它按你的标准干活，AI 生成代码风格自然就统一了。

从零到可用：Cursor AI 规则配置最短路径

拿到规则文件

最省事的方式是直接把仓库克隆到本地：

git clone https://gitcode.com/GitHub_Trending/aw/awesome-cursorrules

所有规则都在rules/目录下，一份文件对应一个技术栈。iOS 相关的两份：

SwiftUI 规则：覆盖 Swift 6、MVVM、状态管理、并发纪律等规范
UIKit 规则：覆盖程序化布局、事件传递等约定

拆开看规则里写了什么

以 SwiftUI 规则为例，文件头部是 frontmatter，正文是四块内容：

--- description: "Cursor rules for SwiftUI development guidelines." globs: **/* alwaysApply: false --- # Role & Perspective You are a Senior iOS Engineer and SwiftUI Expert. # Code Generation Guidelines - **Architecture:** MVVM or Clean Architecture. - **Naming:** Verbose and clear. `fetchUserData` > `getData`.

开头的角色设定告诉 AI"你是谁"，正文则是四块约束：目录与结构规范（如body不得超 50 行、必须拆子视图）、UI 规范、架构约束（MVVM/Clean Architecture、SOLID 原则）、第三方库偏好（AsyncImage、Nuke、Kingfisher 等）。每条都写清了"怎么做、不做什么"，AI 没有自由发挥的空间。

放进项目并验证生效

把规则文件放到项目根目录的.cursor/rules/里：

mkdir -p YourApp/.cursor/rules cp awesome-cursorrules/rules/swiftui-guidelines-cursorrules-prompt-file.mdc YourApp/.cursor/rules/

Cursor 会自动识别这个目录下的.mdc文件，不需要额外配置。frontmatter 决定生效范围：globs指定规则自动附带的文件模式，alwaysApply: true表示所有请求都强制附带。

怎么确认规则真的生效？两个办法：一是直接在对话里问"这个项目新建 View 时有哪些必须遵守的约定？"，如果 AI 答出"body 不超过 50 行、闭包必须[weak self]"，说明规则被读进去了；二是让它随手写一个小页面，看代码是否带着#Preview、MARK:分节这类细节。

规则里最值得抄的两个细节

SwiftUI 规则：用硬性数字约束代码长度

SwiftUI 规则里最"硬核"的一条是：body属性不得超过 50 行，超出就必须拆成可复用的子视图。这把模糊的"写简洁点"变成了可量化的指标，AI 生成的视图天然就是小而可复用的组件。它还要求闭包默认写[weak self]，并推荐用.task(id:)代替.onAppear，让异步任务随视图生命周期自动取消：

struct ProfileView: View { @StateObject private var vm: ProfileViewModel var body: some View { // body 超 50 行必须拆分 VStack(spacing: 16) { /* 内容 */ } .task(id: vm.profileID) { await vm.load() } } }

UIKit 规则：布局与事件各有一条铁律

UIKit 规则对布局的态度很坚决：Auto Layout 只允许用 SnapKit，避免手写 NSLayoutConstraint，同时要求支持 Dynamic Type 和 Safe Area。事件处理上，它规定组件必须通过闭包向外传递事件，且闭包参数必须包含自身，方便外部识别事件来源：

class SampleView: UIView { var didTapButton: ((SampleView) -> Void)? private let button = UIButton() @objc private func buttonTapped() { didTapButton?(self) // 传递 self，外部可识别来源组件 } }

如果团队在做混合开发，这两份规则可以放进同一个项目，SwiftUI 页面和 UIKit 组件各按各的规范来。

按团队口味定制规则

社区规则是"毛坯"，团队自己的偏好要自己补。常见做法是在现有文件末尾追加条目，并用!标记强制规则、?标记可选规则：

# Networking ! 所有请求必须走团队统一的 NetworkService 封装 ! 页面消失时必须支持请求取消 ? 图片加载可选 Kingfisher 或 Nuke # ! = 强制遵守，不可变通 # ? = 建议遵循，偏离需说明理由

这样"我们偏好用 Alamofire""必须用自研组件库"就变成了 AI 的硬性约束，而不是每次对话里都要口头强调一遍。

落地收益与延伸入口

配置完成后的直接收益：

新项目从第一天就立住规范，省掉 AI "自由发挥"造成的返工
老项目不用事后修风格，代码评审能聚焦业务逻辑
多人共用同一套 .cursorrules，AI 输出在团队内保持一致

再给几个延伸阅读入口：

SwiftUI 规则文件
UIKit 规则文件
完整规则索引与使用方法：README.md
想贡献自己的规则：contributing.md

AI 辅助开发的价值不在打字快，而在输出与团队标准一致。挑一份 SwiftUI 或 UIKit 规则放进你 iOS 项目的.cursor/rules/，让 Cursor 按"项目规范"写一个 List 页面看看效果——这是感受差距最快的方式。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

Awesome CursorRules 实战指南：用 .cursorrules 统一 AI 生成的 iOS 代码风格