iOS 开发者的 AI 编程入门完全指南：从概念到实战

2026 年，AI 编程已经从"尝鲜玩具"变成了"生产力工具"。GitHub Copilot、Cursor、Claude Code……这些名字你可能在技术群里听过无数次，但始终没搞清楚它们到底是什么、怎么用、能帮你解决什么问题。

这篇文章就是为你准备的。假设你是一个有多年 iOS 开发经验、但从未系统接触过 AI 编程的开发者，我会从最基础的概念讲起，把所有相关理论讲透彻，最后带你完成一系列面向 iOS 开发场景的实操。读完这篇文章，你将能够：

理解 AI 编程的底层原理，不再被各种新概念绕晕
根据自己的需求选择合适的 AI 编程工具
掌握 Prompt Engineering 的核心技巧
在日常 iOS 开发中熟练使用 AI 提升效率

认知篇：AI 编程到底是什么

从"写代码"到"描述需求"：一次范式转变

在传统编程中，你的工作流程是这样的：

理解需求
设计架构
用 Swift / Objective-C 逐行编写代码
编译、调试、修复 Bug
反复迭代直到功能完成

而在 AI 编程的范式下，你的角色从"代码的书写者"变成了"意图的描述者"和"结果的审查者"。你不再需要逐行敲出每一个字符，而是用自然语言告诉 AI 你想要什么，然后审查它生成的代码是否正确、是否符合项目规范。

核心转变：AI 编程不是让 AI 取代程序员，而是让程序员从"体力活"（重复编码、样板代码）中解放出来，把更多精力放在"脑力活"（架构设计、业务逻辑、代码质量）上。

打个比方：传统编程像你自己亲手砌墙，每一块砖都要自己搬；AI 编程像你有了一个熟练的施工队，你只需要告诉他们"这里要砌一面 3 米高的墙，用红砖，留一个窗户"，他们就会帮你完成。但你仍然需要是那个懂建筑的工程师——你要检查墙砌得直不直、承重够不够、有没有偷工减料。

大语言模型（LLM）基础：它是怎么"懂"代码的

要理解 AI 编程，首先要理解它的底层引擎——大语言模型（Large Language Model，简称 LLM）。

什么是大语言模型

大语言模型本质上是一个经过海量文本训练的"概率预测机器"。它的核心能力只有一个：根据前面的文字，预测下一个最可能出现的文字。

听起来很简单对不对？但当这个模型足够大（参数达到数十亿甚至数千亿）、训练数据足够多（覆盖互联网上的大部分文本，包括代码仓库、技术文档、书籍等）时，它就会"涌现"出令人惊叹的能力——它能写文章、翻译、推理、写代码，甚至通过程序员面试。

为什么 LLM 能写代码

代码本质上也是一种"语言"——它有语法规则、有结构、有惯用模式。当 LLM 在训练过程中"阅读"了 GitHub 上数十亿行代码后，它就学会了：

各种编程语言的语法规则（Swift、Python、JavaScript……）
常见的编程模式和设计模式（MVC、MVVM、Delegate、Closure……）
主流框架和库的 API 用法（UIKit、SwiftUI、Combine、Alamofire……）
代码的命名规范和项目结构
常见 Bug 的模式和修复方法

所以当你输入"用 SwiftUI 写一个登录页面"时，LLM 并不是在"思考"怎么写，而是在根据它学到的统计规律，一个 token 一个 token 地预测出最可能的代码序列。

重要认知：LLM 不"理解"代码，它只是在预测。这意味着它可能会生成看起来很合理但实际上有 Bug 的代码（俗称"幻觉"）。这也是为什么你必须审查 AI 生成的每一行代码。

主流大语言模型一览

模型系列	开发商	代表型号	特点	代码能力
GPT	OpenAI	GPT-4o / o1 / o3	综合能力最强，生态最成熟	顶尖
Claude	Anthropic	Claude 3.5 Sonnet / Opus	长上下文优秀，代码质量高，安全对齐好	顶尖
Gemini	Google	Gemini 2.0 / 2.5 Pro	多模态强，与 Google 生态集成好	优秀
DeepSeek	深度求索	DeepSeek V3 / R1	国产之光，性价比极高，推理能力强	优秀
豆包	字节跳动	豆包 1.5 Pro	国产，中文理解好，免费额度多	良好
通义千问	阿里巴巴	Qwen 2.5 / 3	开源模型生态丰富，可本地部署	良好

AI 编程的能力边界：它能做什么，不能做什么

在投入学习之前，建立正确的预期非常重要。AI 编程不是万能的，了解它的能力边界能帮你把它用在刀刃上。

AI 擅长的事

生成样板代码：UITableView 的 dataSource/delegate、网络请求封装、模型定义等重复度高的代码
代码补全：写到一半的函数、属性声明、import 语句等
代码解释：帮你读懂一段复杂的遗留代码或第三方库源码
代码重构：把 Objective-C 代码转成 Swift、把 MVC 拆成 MVVM、提取公共方法等
Bug 排查：根据崩溃日志和代码定位问题原因
写测试：为已有函数生成单元测试用例
文档生成：为代码添加注释、生成 README、编写接口文档
技术调研：对比多个方案的优劣、解释某个技术概念

AI 不擅长的事

复杂的架构设计：涉及多个模块协作、长期可维护性的架构决策，AI 容易给出"看起来合理但实际有坑"的方案
深度业务逻辑：需要理解公司内部业务规则、历史包袱的逻辑，AI 缺乏上下文
精确的性能优化：需要实际 profiling 数据支撑的优化，AI 容易凭"经验"瞎猜
最新的 API 和框架：如果某个框架是最近几个月才发布的，AI 的训练数据里可能没有
安全敏感的代码：加密、鉴权、支付等代码，AI 生成的可能存在安全漏洞
跨文件的全局重构：涉及大量文件联动的修改，AI 容易遗漏或产生不一致

最佳实践：把 AI 当成一个"能力很强但不了解你项目的初级工程师"。它能快速完成明确的小任务，但需要你给出清晰的指令、提供足够的上下文、并严格审查它的输出。

工具篇：当下主流 AI 编程工具全景

理解了原理之后，我们来看看实际可用的工具。目前 AI 编程工具可以分为三大类，每类有不同的定位和使用场景。

工具分类：三类工具各有所长

类别	核心能力	代表工具	适合场景
代码补全类	在编辑器中实时补全代码，像"更聪明的自动补全"	GitHub Copilot、Codeium、Tabnine、Fitten Code	日常编码，提升写代码速度
对话编程类（AI IDE）	内置 AI 助手的代码编辑器，支持对话、多文件编辑、项目级理解	Cursor、Windsurf、Trae、Claude Code、Gemini CLI
通用大模型	网页端或 App 端的对话式 AI，不直接连接代码仓库	ChatGPT、Claude、Gemini、豆包、Kimi、DeepSeek	技术调研、代码解释、学习新概念

代码补全类：你的"超级自动补全"

GitHub Copilot

GitHub Copilot 是这个品类的开创者，由 GitHub 和 OpenAI 联合开发。它直接集成在 Xcode、VS Code、JetBrains 等主流 IDE 中，当你写代码时，它会以灰色提示的方式给出补全建议，按 Tab 键即可接受。

核心特点：

支持几乎所有主流编程语言和框架
能根据注释生成代码（写一句"// 检查手机号格式"，它就能生成对应的正则校验函数）
支持整行、整块代码补全
Copilot Chat 支持对话式提问和代码解释

价格：个人版约 $10/月，学生可免费申请，企业版有额外管理功能。

其他补全工具

Codeium（现 Windsurf）：免费额度大，支持多 IDE，后转型为 AI IDE Windsurf
Tabnine：支持本地部署，适合对代码隐私有要求的企业
Fitten Code（非十科技）：国产工具，免费，对中文注释和国内技术栈支持好
CodeGeeX（智谱）：国产，免费，支持多语言

对话编程类（AI IDE）：当下最火的生产力工具

如果说代码补全类工具是"更聪明的自动补全"，那 AI IDE 就是"坐在你旁边的 AI 结对编程伙伴"。它不仅能补全代码，还能理解你的整个项目、跨文件修改、执行命令、甚至自己调试。

Cursor

Cursor 是目前最受欢迎的 AI IDE，基于 VS Code fork 而来，因此你熟悉的 VS Code 插件、快捷键、主题在 Cursor 中几乎都能用。

核心功能：

Cmd+K（Inline Edit）：选中代码后按 Cmd+K，输入指令即可直接修改选中的代码
Cmd+L（Chat）：打开侧边对话窗口，可以问问题、让它改代码
Composer / Agent 模式：让 AI 自主完成复杂任务，它会自动读取相关文件、编写代码、运行命令、修复错误
@ 引用：在对话中用 @ 引用文件、文件夹、代码片段、甚至网页，给 AI 提供精准上下文
.cursorrules：在项目根目录放置规则文件，让 AI 始终遵循你的项目规范

价格：免费版有额度限制，Pro 版 $20/月，Business 版 $40/月。

Windsurf

Windsurf（原 Codeium）是 Cursor 的主要竞争对手，同样基于 VS Code。它的特色是 Cascade 功能——一个更强大的 Agent 模式，能更好地处理多步骤、跨文件的复杂任务。

与 Cursor 相比，Windsurf 的免费额度更慷慨，对长上下文的处理也有自己的优化。

Trae

Trae 是字节跳动推出的 AI IDE，国产工具的代表。它的优势在于：

对中文项目和中文需求的理解更好
集成了豆包大模型，国内访问速度快
免费额度充足
内置了 AI 生成 UI 预览等特色功能

Claude Code / Gemini CLI

这是另一类形态——终端中的 AI 编程助手。它们不是完整的 IDE，而是在命令行中运行的工具，你可以在任何编辑器旁边使用它们。

Claude Code：Anthropic 官方推出的 CLI 工具，基于 Claude 模型，擅长处理大型代码库和复杂重构
Gemini CLI：Google 推出的 CLI 工具，基于 Gemini 模型
Aider：开源的 AI 编程 CLI，支持多种模型，可与 Git 深度集成

这类工具的优势是轻量、不绑定特定编辑器、可以和你现有的开发流程无缝配合。缺点是没有图形界面，学习曲线稍陡。

通用大模型：你的"技术顾问"

通用大模型不直接连接你的代码仓库，但它们在技术调研、概念解释、代码片段生成方面非常有用。你可以把它们当成一个"随叫随到的技术顾问"。

典型使用场景：

"解释一下 Swift 的 actor 和 @MainActor 有什么区别"
"SwiftUI 中 GeometryReader 和 PreferenceKey 各自适合什么场景"
"帮我写一个用 Combine 处理网络请求的示例"
"对比一下 Kingfisher 和 SDWebImage 的优劣"
"这个 Crash 日志是什么意思：EXC_BAD_ACCESS KERN_INVALID_ADDRESS"

推荐组合：

日常使用：豆包 / Kimi（免费、中文好、速度快）
复杂技术问题：Claude / GPT-4o（代码理解和推理能力更强）
需要最新信息：Gemini（联网搜索能力强）

iOS 开发者的工具选择建议

iOS 开发的特殊性：由于 Xcode 是 iOS 开发的核心 IDE，而大多数 AI IDE（Cursor、Windsurf 等）都是基于 VS Code 的，不能直接用来编译和运行 iOS 应用。因此 iOS 开发者通常需要"双 IDE 协作"的工作流。

推荐的工具组合：

入门级（免费）：Xcode + Fitten Code/CodeGeeX（补全）+ 豆包/Kimi（对话）
- 成本最低，能体验 AI 编程的核心价值
进阶级（推荐）：Xcode + Cursor（AI IDE）+ GitHub Copilot（补全）+ Claude/GPT（顾问）
- 在 Xcode 中编译运行，在 Cursor 中写代码和重构，两者通过文件系统同步
- 这是目前大多数 iOS AI 编程实践者的工作流
专业级：Xcode + Cursor + Claude Code + 自定义 Prompt 模板 + .cursorrules
- 深度定制，最大化 AI 编程效率

双 IDE 协作工作流：

在 Xcode 中打开项目，负责编译、运行、调试、Interface Builder 操作
在 Cursor 中打开同一个项目文件夹，负责代码编写、重构、AI 辅助
在 Cursor 中修改代码后保存，切回 Xcode 会自动检测到文件变化并重新加载
编译报错时，把错误信息复制到 Cursor 的 AI 对话中，让 AI 帮你分析和修复

理论篇：AI 编程的核心概念

工欲善其事，必先利其器。但比工具更重要的是理解背后的核心概念。这些概念能帮你在使用任何 AI 工具时都能做到"知其然更知其所以然"。

Token 与上下文窗口：AI 的"记忆"和"注意力"

什么是 Token

Token 是 LLM 处理文本的基本单位。你可以把它理解为"AI 眼中的词"——但它不是严格意义上的单词，而是文本的子词（subword）片段。

大致换算关系：

英文：1 个 token ≈ 0.75 个单词，100 个 token ≈ 75 个单词
中文：1 个 token ≈ 1~2 个汉字（因为中文字符更复杂，通常一个汉字就是一个 token）
代码：1 个 token ≈ 几行代码的一部分（取决于代码的复杂度和重复度）

为什么要关心 Token？因为：

计费单位：大多数 API 按 token 数量收费，输入和输出分别计费
上下文限制：每个模型都有最大 token 限制，超过就无法处理
生成速度：token 越多，生成时间越长

什么是上下文窗口（Context Window）

上下文窗口是 LLM 在一次对话中能"看到"的最大 token 数量。你可以把它想象成 AI 的"工作记忆"——它只能记住窗口内的内容，窗口外的内容它就"忘了"。

目前主流模型的上下文窗口：

GPT-4o：128K（约 9.6 万英文词 / 约 10 万汉字）
Claude 3.5 Sonnet：200K（约 15 万英文词 / 约 15 万汉字）
Claude 3 Opus：200K
Gemini 1.5 Pro：1M~2M（百万级，约 75 万~150 万英文词）
DeepSeek V3：128K

重要提醒：上下文窗口大不等于效果一定好。当上下文非常长时，模型可能会出现"中间遗忘"（Lost in the Middle）现象——对放在上下文中间的内容关注度降低。因此，即使模型支持 200K 上下文，也不建议无脑塞满，精准的上下文比冗长的上下文更有效。

对 iOS 开发者的实际意义

一个中等规模的 iOS 项目可能有几十万行代码，远远超过任何模型的上下文窗口。这意味着：

AI 不可能一次性"读完"你的整个项目
你需要主动给 AI 提供相关的代码片段（这就是 Cursor 的 @ 引用功能的价值）
对于跨多个文件的复杂任务，需要拆分成多个小任务逐步完成
.cursorrules 等项目级配置文件能在有限的上下文中提供关键的项目规范信息

Temperature：控制 AI 的"创造力"

Temperature（温度）是 LLM 的一个核心参数，控制输出的随机性和创造性。

Temperature = 0：输出最确定、最保守。每次输入相同的内容，输出几乎完全一样。适合需要精确答案的场景，如代码生成、事实性问答。
Temperature = 0.7：默认值，平衡创造性和确定性。适合大多数日常场景。
Temperature = 1.0+：输出更随机、更有创造性，但也更容易出错和"幻觉"。适合创意写作、头脑风暴。

对编程场景的建议：

生成代码时，使用较低的 Temperature（0~0.3），减少幻觉和不确定的 API 调用
技术方案讨论、头脑风暴时，可以适当提高 Temperature（0.5~0.7）
大多数 AI 编程工具已经帮你预设了合适的 Temperature，不需要手动调整

Prompt Engineering：跟 AI 对话的艺术

Prompt（提示词）就是你给 AI 的输入指令。Prompt Engineering 就是研究如何写好指令，让 AI 给出更好的输出。这是 AI 编程时代最重要的技能之一。

好 Prompt 的四个要素

一个高质量的 Prompt 通常包含以下四个要素（可以记为 CRISPE 或类似框架，但核心就这几点）：

角色（Role）：告诉 AI 它应该扮演什么角色。"你是一个有 10 年经验的 iOS 高级开发工程师"比"帮我写代码"效果好得多。
任务（Task）：清晰描述你要它做什么。越具体越好。
上下文（Context）：提供相关的背景信息、代码片段、项目规范等。
要求（Constraints / Format）：明确输出格式、限制条件、质量标准。

反面教材 vs 正面教材

差的 Prompt：

帮我写一个登录页面

好的 Prompt：

你是一个有 5 年经验的 iOS 开发工程师，精通 SwiftUI 和 Combine。

请帮我用 SwiftUI 写一个登录页面，要求：
1. 包含手机号输入框（11位数字限制）、验证码输入框（6位数字）、获取验证码按钮、登录按钮
2. 使用 MVVM 架构，ViewModel 用 @Published 暴露状态
3. 手机号格式校验用正则，验证码倒计时 60 秒
4. 登录按钮在手机号和验证码都填写后才可点击
5. 适配深色模式，使用系统默认配色
6. 代码要有清晰的注释

请只输出 Swift 代码，不要额外解释。

看出区别了吗？好的 Prompt 给了 AI 明确的角色、具体的需求清单、技术栈要求、输出格式约束。AI 不需要"猜"你想要什么，输出质量自然更高。

Prompt Engineering 的核心技巧

提供示例（Few-shot）：给 AI 看 1~3 个输入输出的例子，它就能快速理解你想要的格式和风格。

请按照以下格式为函数添加注释：

示例：
func calculateTotal(price: Double, quantity: Int) -> Double {
    /// 计算商品总价
    /// - Parameters:
    ///   - price: 商品单价
    ///   - quantity: 商品数量
    /// - Returns: 总价 = 单价 × 数量
    return price * Double(quantity)
}

请为以下函数添加同样风格的注释：
func fetchUserInfo(userId: String, completion: @escaping (Result&lt;User, Error&gt;) -> Void)

分步思考（Chain-of-Thought）：对于复杂问题，让 AI"先思考再回答"，可以显著提升推理能力。在 Prompt 中加入"请先分析问题，列出步骤，再给出最终答案"。
指定输出格式：明确告诉 AI 输出什么格式（纯代码 / Markdown / JSON / 表格），避免它输出一堆你不需要的解释。
迭代优化：不要指望一次 Prompt 就得到完美结果。先让 AI 生成初版，然后针对不满意的地方提出修改意见，逐步迭代。
用分隔符区分指令和内容：当你需要把代码片段传给 AI 时，用 ``` 或 --- 等分隔符把代码和指令分开，避免 AI 把你的代码当成指令。

RAG：让 AI 用上"外部知识"

RAG（Retrieval-Augmented Generation，检索增强生成）是目前 AI 应用中最重要的技术之一。简单来说，它解决的是 LLM 的两个固有问题：

LLM 的知识有截止日期，不知道最新的信息
LLM 不知道你公司/项目的私有信息

RAG 的工作原理：

把外部知识（文档、代码库、Wiki 等）切分成小块，转换成向量（embedding）存储起来
当用户提问时，先把问题也转换成向量，在知识库中检索最相关的几个片段
把检索到的片段和用户问题一起拼接到 Prompt 中，传给 LLM
LLM 基于检索到的内容生成回答

你可以把 RAG 理解为"开卷考试"——AI 不需要把所有知识都记在脑子里，而是在需要时去"翻书"找相关内容，然后基于找到的内容回答问题。

在 AI 编程工具中的应用：

Cursor 的"代码库索引"功能本质上就是 RAG——它把你的项目代码建立索引，当你提问时自动检索相关文件
GitHub Copilot 的 Workspace 模式也是 RAG 的应用
很多团队用 RAG 搭建内部技术文档问答系统

Agent 与工具调用：让 AI 从"说话"到"做事"

什么是 Agent

Agent（智能体）是目前 AI 领域最火的概念之一。简单来说，普通的 LLM 是"一问一答"——你给它输入，它给你输出，然后就结束了。而 Agent 是一个能自主规划、执行多步骤任务、使用工具、根据反馈调整策略的 AI 系统。

一个编程 Agent 的工作流程可能是这样的：

你说："帮我给项目添加一个用户收藏功能"
Agent 先读取项目结构，了解代码组织方式
Agent 规划需要修改的文件：新增数据模型、修改网络层、新增 UI 页面、修改路由等
Agent 逐个文件编写代码
Agent 运行编译命令，检查是否有报错
如果有报错，Agent 读取错误信息，自动修复
重复编译-修复循环，直到编译通过
向你汇报完成情况

这就是 Cursor 的 Composer、Windsurf 的 Cascade、Claude Code 等工具背后的核心能力。

工具调用（Function Calling / Tool Use）

Agent 能"做事"的关键是工具调用。LLM 本身只能输出文字，但通过 Function Calling 机制，它可以输出"调用某个工具"的指令，然后由外部程序执行这个工具调用，把结果返回给 LLM，LLM 再基于结果继续下一步。

常见的编程工具包括：

读取文件 / 写入文件 / 搜索文件
执行终端命令（编译、运行测试、git 操作等）
搜索网页 / 查询文档
调用数据库 / API

未来趋势：Agent 是 AI 编程的下一个大方向。目前的 Agent 还处于"能完成简单任务"的阶段，但随着模型能力提升和工具生态完善，未来的编程 Agent 可能能独立完成从需求分析到上线的完整开发流程。当然，这需要时间，现阶段你仍然需要是那个"掌舵的人"。

模型选型：开源 vs 闭源，参数怎么看

闭源模型 vs 开源模型

维度	闭源模型（GPT、Claude、Gemini）	开源模型（Llama、Qwen、DeepSeek、Mistral）
能力上限	通常更强，尤其是复杂推理和代码	追赶中，头部开源模型已接近中低端闭源
成本	按 API 调用付费，长期使用成本较高	免费使用，只需承担服务器/硬件成本
隐私	数据会传到厂商服务器（企业版有隐私承诺）	可本地部署，数据完全不出内网
定制化	有限，只能通过 Prompt 和少量微调	可完全自由微调、量化、修改
使用门槛	低，注册即用	较高，需要 GPU 服务器和运维能力

对个人开发者的建议：日常使用闭源模型（效果好、省心），如果有特殊的隐私需求或成本考量，可以尝试用 Ollama 在本地运行开源模型。

参数量是什么意思

你经常会看到"7B 模型"、"70B 模型"这样的说法，B 代表 Billion（十亿），指的是模型的参数量。

7B~14B：小型模型，可在消费级显卡（甚至笔记本）上运行，适合简单任务和本地部署
32B~70B：中型模型，需要较强的 GPU，能力较强，适合大多数编程任务
100B+：大型模型，需要多卡服务器，能力接近闭源旗舰

一般来说，参数越多能力越强，但也不是绝对的——模型架构、训练数据、对齐方式同样重要。而且参数量越大，运行成本越高、速度越慢。选择时要根据实际需求权衡。

实战篇：iOS 开发者的 AI 编程实操

理论讲了这么多，现在进入最关键的部分——动手实操。我会带你完成 6 个面向 iOS 开发真实场景的实战练习，每个练习都包含完整的 Prompt 和预期效果。

环境准备

在开始之前，请确保你已经：

下载并安装 Cursor（https://cursor.com），或使用你熟悉的其他 AI IDE
注册账号并登录（免费版即可完成大部分练习）
在 Cursor 中打开一个 iOS 项目（可以是你自己的项目，也可以新建一个测试项目）
熟悉 Cursor 的基本操作：
- Cmd+L：打开 AI 对话侧边栏
- Cmd+K：对选中的代码进行内联编辑
- @：在对话中引用文件或代码

提示：如果你暂时不想安装 Cursor，也可以用网页版的 ChatGPT / Claude / 豆包完成这些练习，只是需要手动复制粘贴代码。

实战一：用 AI 生成一个完整的 SwiftUI 页面

场景：你需要快速搭建一个设置页面，包含用户信息、功能开关、列表项等。

步骤

在 Cursor 中新建一个 Swift 文件，比如 SettingsView.swift
按 Cmd+L 打开对话，输入以下 Prompt：

你是一个有 5 年经验的 iOS 开发工程师，精通 SwiftUI。

请帮我写一个完整的设置页面 SettingsView，要求：
1. 使用 List + Section 组织内容，分为三个 section：
   - 个人信息：头像、昵称、手机号（点击进入个人资料页）
   - 通用设置：消息通知（Toggle）、深色模式（Toggle）、清除缓存（带缓存大小）
   - 关于：关于我们、隐私政策、版本号（显示在右侧）
2. 使用 SwiftUI 原生控件，不依赖第三方库
3. 适配深色模式
4. ViewModel 使用 @Observable（iOS 17+）或 @ObservedObject，包含所有开关状态和缓存大小
5. 代码要有清晰的注释
6. 头像使用 SF Symbols 的 person.crop.circle.fill 图标作为占位

请只输出 Swift 代码，文件名为 SettingsView.swift。

AI 生成代码后，仔细审查：
- 导入的框架是否正确（应该是 SwiftUI）
- API 是否符合你项目的最低 iOS 版本要求（@Observable 需要 iOS 17+）
- 是否有不存在的 API 或拼写错误
- 代码风格是否符合你的项目规范
把代码复制到 Xcode 中编译运行，检查效果
如果有不满意的地方，继续对话迭代。比如："把深色模式的 Toggle 改成跟随系统，去掉手动开关"、"缓存大小显示为 XX.X MB 格式"

要点总结

明确指定技术栈（SwiftUI）和架构模式（MVVM）
列出具体的功能清单，不要笼统地说"做一个设置页"
指定最低 iOS 版本要求，避免 AI 使用你项目不支持的 API
生成后必须编译验证，AI 偶尔会用错 API

实战二：用 AI 重构遗留 Objective-C 代码

场景：你的项目里有一段老旧的 Objective-C 代码，需要转换成 Swift，并顺便优化代码质量。

步骤

在 Cursor 中打开需要重构的 .m 文件
选中需要转换的代码（或整个文件）
按 Cmd+K，输入以下 Prompt：

请将这段 Objective-C 代码转换为 Swift，要求：
1. 使用 Swift 的惯用写法（如 struct 替代 C 结构体、enum 关联值替代常量、Codable 替代手动 JSON 解析）
2. 保留原有的业务逻辑，不改变功能
3. 使用 Swift 的错误处理（do-try-catch）替代 NSError 指针
4. 使用闭包（closure）替代 block
5. 添加必要的 @objc 标记如果这个类需要在 ObjC 中调用
6. 代码风格遵循 Swift API Design Guidelines
7. 转换后请在注释中标注哪些地方做了优化，以及为什么

请确保转换后的代码可以直接编译通过。

AI 完成转换后，逐行对比原代码和新代码，确认：
- 业务逻辑是否完全一致（这是最重要的）
- 是否有遗漏的边界条件处理
- 可选型（Optional）的处理是否正确，有没有强制解包的风险
- 如果原类在 ObjC 中被引用，是否正确添加了 @objc 标记
在 Xcode 中编译并运行相关功能，确认行为一致
建议写单元测试覆盖关键逻辑，重构前后测试都通过才算成功

要点总结

ObjC 转 Swift 时，最容易出问题的是可选型处理和内存管理（weak/strong）
一定要保留原业务逻辑，AI 可能会"自作聪明"地改变一些行为
对于复杂的重构，建议分小块进行，不要一次性转换整个文件
重构后必须有测试验证，不要只靠肉眼对比

实战三：用 AI 调试崩溃（Crash）

场景：App 出现了一个崩溃，你有崩溃日志，但一时找不到原因。

步骤

收集崩溃信息：崩溃日志（.crash 文件或 Xcode 崩溃信息）、相关代码文件、复现步骤
在 Cursor 中按 Cmd+L 打开对话
用 @ 引用相关的代码文件，然后输入以下 Prompt：

我的 App 出现了一个崩溃，请帮我分析原因并给出修复方案。

【崩溃信息】
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000010
Thread 0 Crashed:
0  libobjc.A.dylib  objc_msgSend + 32
1  MyApp           -[UserManager updateUserInfo:] + 128
2  MyApp           -[ProfileViewController viewDidLoad] + 256

【复现步骤】
1. 进入个人中心页面
2. 快速返回上一页
3. 偶现崩溃

【相关代码】
我已经 @ 引用了 UserManager.m 和 ProfileViewController.m，请查看。

请分析：
1. 崩溃的根本原因是什么？
2. 为什么是偶现的？
3. 给出具体的修复代码
4. 如何预防类似问题

AI 分析后，你会得到一个结构化的诊断结果。以这个常见的野指针崩溃为例，AI 可能会指出：
- EXC_BAD_ACCESS + objc_msgSend 通常是消息发送给了已释放的对象（野指针）
- 地址 0x10 很小，说明对象被释放后内存被重用，isa 指针变成了垃圾值
- 偶现是因为内存释放时机不确定
- 修复方案：检查 UserManager 的 delegate 是否用了 weak、检查 block 中是否有循环引用、检查多线程下的访问
根据 AI 的建议检查代码，找到真正的问题点并修复
如果 AI 的分析不对，提供更多信息继续追问："我检查了 delegate 是 weak 的，还有什么其他可能？"

要点总结

给 AI 的崩溃信息越完整越好：崩溃类型、崩溃线程、调用栈、复现步骤、相关代码
AI 能帮你快速缩小排查范围，但最终定位还是要靠你结合代码实际情况判断
对于复杂的崩溃，可以开启 Zombie Objects、Address Sanitizer 等工具获取更多信息，再喂给 AI
不要盲目相信 AI 的修复方案，一定要理解原因后再修改

实战四：用 AI 写单元测试

场景：你有一个工具类或 ViewModel，需要为它编写单元测试，但写测试很繁琐。

步骤

在 Cursor 中打开需要测试的 Swift 文件
选中需要测试的类或函数
按 Cmd+K，输入以下 Prompt：

请为这段代码编写完整的单元测试，要求：
1. 使用 XCTest 框架
2. 测试类命名为 [被测类名]Tests
3. 覆盖以下测试场景：
   - 正常输入的情况
   - 边界值（空、最大值、最小值）
   - 异常输入（非法格式、nil）
   - 异步方法的测试（使用 XCTestExpectation）
4. 每个测试方法命名为 test_[场景]_[预期结果]，如 test_validPhoneNumber_returnsTrue
5. 使用 Given-When-Then 结构组织测试代码
6. 添加清晰的注释说明每个测试的目的
7. 如果有依赖（如网络请求、数据库），使用 Mock/Stub 隔离

请只输出测试代码。

AI 生成测试代码后，审查：
- 测试用例是否覆盖了关键逻辑分支
- 断言是否正确（不是只断言 notNil，而是断言具体的值）
- 异步测试的 expectation 是否正确 fulfill
- 是否有测试之间的状态依赖（测试应该互相独立）
在 Xcode 中运行测试，确认全部通过
如果有测试失败，分析是代码有 Bug 还是测试写错了

要点总结

AI 写测试最大的价值是覆盖"正常路径"和"明显边界"，但它可能想不到你业务中的特殊边界条件
审查测试时重点看：断言是否有意义、是否测试了真正的逻辑、有没有"为了测试而测试"的废用例
对于有复杂依赖的代码，AI 可能不知道怎么 Mock，你需要手动指导或提供 Mock 类的示例
测试代码也需要维护，不要因为是 AI 写的就降低质量要求

实战五：用 AI 做 Code Review

场景：你写了一段代码，提交 PR/MR 之前想先自己检查一遍有没有问题。

步骤

在 Cursor 中打开你写的代码文件
按 Cmd+L 打开对话，用 @ 引用这个文件
输入以下 Prompt：

请作为一个严格的 iOS 高级开发工程师，对 @引用的这段代码做 Code Review。

请从以下维度检查：
1. **正确性**：有没有逻辑错误、边界条件遗漏、可选型处理不当
2. **性能**：有没有明显的性能问题（如主线程耗时操作、循环里的重复计算、不必要的 UI 刷新）
3. **内存管理**：有没有循环引用、内存泄漏风险
4. **线程安全**：有没有多线程访问共享资源的问题
5. **代码风格**：命名是否清晰、是否符合 Swift 惯例、有没有冗余代码
6. **安全性**：有没有强制解包（force unwrap）、用户输入未校验等风险
7. **可维护性**：函数是否过长、职责是否单一、有没有硬编码

请按以下格式输出：
- 问题等级（🔴 严重 / 🟡 建议 / 🟢 优化）
- 问题位置（文件和函数名）
- 问题描述
- 修复建议（附代码示例）

如果没有问题，也请明确说"未发现明显问题"，不要为了找问题而找问题。

AI 会给出一份结构化的 Review 报告。逐条评估：
- 🔴 严重问题：必须修复
- 🟡 建议：根据实际情况决定是否修改
- 🟢 优化：有时间再改
对于 AI 指出的问题，不要全盘接受，要自己判断是否真的是问题（AI 有时会"误报"）
修复确认的问题后，可以再让 AI Review 一遍确认

要点总结

AI Code Review 是"自检"的好工具，但不能替代人类 Reviewer
AI 擅长发现"模式化"的问题（强制解包、循环引用、命名不规范），但不擅长发现"业务逻辑"层面的问题
给 AI 提供项目的编码规范（通过 .cursorrules），它的 Review 会更贴合你的项目
把 AI Review 当成"第二双眼睛"，而不是"最终裁判"

实战六：用 AI 生成网络层代码

场景：后端给了一份 API 接口文档，你需要生成对应的网络请求代码和数据模型。

步骤

准备好 API 文档（接口路径、请求方法、参数、响应格式）
在 Cursor 中按 Cmd+L 打开对话
输入以下 Prompt（把接口文档内容贴进去）：

你是一个有 5 年经验的 iOS 开发工程师。请根据以下 API 文档生成 Swift 代码。

【技术栈要求】
- 网络库：Moya（如果你们项目用 Alamofire 就改成 Alamofire）
- 模型：Codable
- 架构：MVVM，Service 层封装网络请求

【API 文档】
接口：获取用户订单列表
路径：GET /api/v1/orders
请求参数：
- page: Int（页码，从1开始）
- pageSize: Int（每页数量，默认20）
- status: String?（订单状态，可选：pending/shipped/completed/cancelled）

响应格式：
{
  "code": 0,
  "message": "success",
  "data": {
    "list": [
      {
        "orderId": "ORD20240101001",
        "productName": "iPhone 15 Pro",
        "amount": 8999.00,
        "status": "shipped",
        "createTime": "2024-01-01 10:30:00"
      }
    ],
    "total": 100,
    "page": 1,
    "pageSize": 20
  }
}

请生成：
1. 数据模型（Order、OrderListResponse，使用 Codable）
2. Moya 的 TargetType 定义（OrderAPI enum）
3. NetworkService 封装（包含获取订单列表的方法）
4. 日期解码策略（createTime 是 "yyyy-MM-dd HH:mm:ss" 格式）
5. 错误处理

请输出完整的可编译代码。

AI 生成代码后，重点检查：
- CodingKeys 是否正确（特别是 snake_case 转 camelCase）
- 可选型是否正确（哪些字段可能为 nil）
- 日期解码策略是否正确配置
- Moya 的 baseURL、path、method、task 是否正确
- 错误处理是否完善
在实际项目中调用测试，确认解析正确

要点总结

生成网络层代码时，一定要提供完整的 API 文档，包括所有字段和可能的状态
AI 可能会"脑补"一些文档中没有的字段，要仔细核对
对于日期、金额等特殊类型，要明确指定解码策略
建议先用 Postman 或 curl 确认接口返回格式，再让 AI 生成代码

高级技巧：.cursorrules 与项目级 Prompt 模板

当你在一个项目中长期使用 AI 编程时，你会发现每次都要重复说明项目规范很麻烦。这时候就需要用到项目级配置。

.cursorrules 文件

在项目根目录创建一个 .cursorrules 文件，Cursor 会自动读取它，并在每次对话时把内容作为系统提示的一部分。这样 AI 就会始终遵循你的项目规范。

一个 iOS 项目的 .cursorrules 示例：

# 项目规范

## 技术栈
- 语言：Swift 5.9+
- UI：SwiftUI（优先），UIKit（遗留页面）
- 架构：MVVM + Coordinator
- 网络：Moya + Combine
- 依赖管理：Swift Package Manager

## 代码规范
- 最低支持 iOS 15.0
- 禁止使用强制解包（!），除非是 IBOutlet 和确定有值的场景
- 禁止使用 try!，必须 do-catch 或 try?
- 函数不超过 50 行，超过则拆分
- 命名遵循 Swift API Design Guidelines
- 代理属性必须用 weak
- 闭包中使用 self 必须用 [weak self]

## 项目结构
- Models: 数据模型
- Views: SwiftUI 视图
- ViewModels: 视图模型
- Services: 业务逻辑和网络请求
- Coordinators: 路由管理
- Utils: 工具类
- Resources: 资源文件

## 输出要求
- 生成代码时遵循以上规范
- 新文件放在对应的目录下
- 如有不确定的地方，先询问再生成

Prompt 模板库

建议建立一个个人的 Prompt 模板库，把常用的 Prompt 保存下来，需要时直接复用。比如：

代码生成模板（指定角色、技术栈、输出格式）
代码审查模板（检查维度、输出格式）
Bug 分析模板（崩溃信息、复现步骤、相关代码）
重构模板（重构目标、约束条件、验证方法）

你可以把这些模板存在笔记应用中，或者做成代码片段（Snippet），用的时候快速调用。

最佳实践与未来展望

AI 编程的避坑指南

在使用 AI 编程的过程中，有一些常见的"坑"需要特别注意：

坑一：盲目信任 AI 生成的代码

表现：AI 生成的代码看起来很合理，直接复制粘贴就用，结果上线后出 Bug。

原因：LLM 会"幻觉"——它可能生成一个不存在的 API、记错了方法签名、或者忽略了某个边界条件。

对策：

每一行 AI 生成的代码都要经过你的审查
不认识的 API 一定要去查官方文档确认
关键逻辑必须写单元测试
复杂功能先在分支上测试，验证通过再合并

坑二：上下文不足导致 AI 瞎猜

表现：你让 AI 改一个功能，它改出来的东西跟你想要的完全不一样。

原因：AI 不知道你的项目结构、业务逻辑、历史背景，只能根据你给的有限信息"猜"。

对策：

提供足够的上下文：相关代码文件、项目规范、业务背景
用 @ 引用精准的文件和代码片段
配置 .cursorrules 让 AI 了解项目规范
复杂任务拆分成小任务，逐步完成

坑三：Prompt 写得太模糊

表现："帮我优化一下这段代码"，结果 AI 改了一堆你不想改的东西。

原因："优化"可以指性能优化、可读性优化、架构优化……AI 不知道你想要哪种。

对策：

Prompt 要具体：明确目标、约束、输出格式
用清单列出需求，而不是一句话笼统描述
给出"不要做什么"也很重要（"不要改变公共接口"、"不要引入第三方库"）

坑四：用 AI 处理不适合它的任务

表现：让 AI 做复杂的架构设计或精确的性能优化，结果方案有很多坑。

原因：AI 缺乏对项目全局的理解和实际运行数据，只能给出"通用最佳实践"，不一定适合你的具体情况。

对策：

了解 AI 的能力边界，把它用在擅长的地方
复杂决策让 AI 提供多个方案和优缺点分析，最终由你判断选择
性能优化一定要基于实际的 Instruments 数据，不要让 AI 凭"经验"优化

代码安全与隐私注意事项

重要：使用 AI 编程工具时，代码安全和隐私是必须重视的问题。很多公司对代码外泄有严格规定，使用前请确认你公司的政策。

需要注意的点：

不要把敏感代码传给公共 AI 服务：涉及加密算法、密钥、鉴权逻辑、支付系统、用户隐私数据的代码，不要复制到 ChatGPT 等公共服务中。
了解工具的数据政策：
- GitHub Copilot 企业版：不会用你的代码训练模型
- Cursor 企业版 / Privacy 模式：不会存储你的代码
- 免费版 / 个人版：可能会用你的输入改进服务（具体看隐私政策）
企业级方案：如果公司对代码安全要求高，可以考虑：
- 使用企业版 AI 编程工具（有隐私承诺和管理功能）
- 部署私有化的开源模型（如用 Ollama + Qwen/DeepSeek 本地部署）
- 使用公司内部搭建的 AI 代码助手平台
API Key 安全：如果使用 API 方式调用模型，不要把 API Key 硬编码在代码里，使用环境变量或配置文件管理。
合规审查：AI 生成的代码可能存在许可证风险（比如训练数据中包含 GPL 代码，生成的代码可能被"污染"）。重要项目建议使用代码扫描工具检查。

学习路径建议

如果你想系统地提升 AI 编程能力，建议按以下路径学习：

第一阶段：入门（1~2 周）

安装 Cursor 或 GitHub Copilot，在日常编码中使用代码补全功能
学会写基本的 Prompt：明确角色、任务、要求
用 AI 完成简单任务：生成样板代码、写注释、解释代码
建立"AI 生成的代码必须审查"的意识

第二阶段：进阶（1~2 个月）

熟练使用 AI IDE 的高级功能：@ 引用、内联编辑、Agent 模式
掌握 Prompt Engineering 技巧：Few-shot、Chain-of-Thought、迭代优化
配置 .cursorrules，建立项目级规范
用 AI 完成中等复杂度任务：代码重构、Bug 调试、写单元测试
建立个人 Prompt 模板库

第三阶段：精通（持续学习）

深入理解 LLM 原理：Transformer 架构、Tokenization、Attention 机制
了解 RAG、Agent、Fine-tuning 等进阶技术
尝试本地部署开源模型（Ollama + Llama/Qwen）
探索 AI Agent 在开发流程中的应用（自动 PR Review、自动测试生成等）
关注行业动态，学习新工具和新方法

未来趋势：AI 编程将走向何方

最后，让我们展望一下 AI 编程的未来发展方向：

趋势一：Agent 能力持续增强

目前的编程 Agent 还只能完成相对简单的任务，但随着模型能力提升和工具生态完善，未来的 Agent 将能处理更复杂的多步骤任务，甚至独立完成整个功能模块的开发。你可能只需要描述需求，Agent 就能完成从设计、编码、测试到文档的全流程。

趋势二：IDE 原生 AI 集成

Apple 已经在 Xcode 中加入了 AI 辅助功能（Xcode 16 引入的 Predictive Code Completion），未来会有更深度的集成。当 Xcode 原生支持对话式 AI、项目级理解、Agent 模式时，iOS 开发者将不再需要"双 IDE 协作"的工作流，AI 编程会变得更加无缝。

趋势三：端侧模型与隐私计算

随着模型量化技术和硬件性能的提升，越来越多的 AI 能力将在本地运行。Apple Silicon 的 Mac 已经具备运行中等规模开源模型的能力，未来 Xcode 可能内置本地模型，代码完全不出本机，从根本上解决隐私问题。

趋势四：AI 驱动的开发流程变革

AI 不只是改变"写代码"这一个环节，它正在改变整个软件开发流程：需求分析用 AI、架构设计用 AI、代码生成用 AI、测试用 AI、部署用 AI、运维用 AI……未来的开发者可能更多地扮演"AI 管理者"和"质量把关者"的角色，而不是"代码工人"。

趋势五：自然语言编程的普及

随着 AI 理解能力的提升，"用自然语言描述需求，AI 生成可运行的应用"将越来越普及。这并不意味着程序员会失业——需求的精确描述、系统的架构设计、质量的把控仍然需要专业能力。但编程的门槛会降低，更多非专业开发者也能创建简单的应用。

写在最后：AI 编程不是要取代程序员，而是要赋能程序员。它会淘汰那些只会写重复代码、不思考、不学习的"码农"，但会让那些善于学习、善于思考、善于利用工具的开发者变得更强大。

作为 iOS 开发者，我们正站在一个变革的起点。拥抱变化、持续学习、把 AI 当成你的"超能力"，你会发现开发变得更高效、更有趣。

祝你在 AI 编程的道路上越走越远！

附录：常用资源汇总

工具下载

Cursor：https://cursor.com
Windsurf：https://windsurf.com
Trae：https://trae.ai
GitHub Copilot：https://github.com/features/copilot
Claude Code：https://docs.anthropic.com/en/docs/claude-code
Ollama（本地模型）：https://ollama.com

学习资源

OpenAI Prompt Engineering 指南：https://platform.openai.com/docs/guides/prompt-engineering
Anthropic Prompt Engineering 指南：https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
Cursor 官方文档：https://docs.cursor.com
Awesome AI Agents（GitHub 开源项目合集）

球哥-chg

人狠话也多

iOS 开发者的 AI 编程入门完全指南：从概念到实战

iOS 开发者的 AI 编程入门完全指南：从概念到实战

认知篇：AI 编程到底是什么

从"写代码"到"描述需求"：一次范式转变

大语言模型（LLM）基础：它是怎么"懂"代码的

什么是大语言模型

为什么 LLM 能写代码

主流大语言模型一览

AI 编程的能力边界：它能做什么，不能做什么

AI 擅长的事

AI 不擅长的事

工具篇：当下主流 AI 编程工具全景

工具分类：三类工具各有所长

代码补全类：你的"超级自动补全"

GitHub Copilot

其他补全工具

对话编程类（AI IDE）：当下最火的生产力工具

Cursor

Windsurf

Trae

Claude Code / Gemini CLI

通用大模型：你的"技术顾问"

iOS 开发者的工具选择建议

理论篇：AI 编程的核心概念

Token 与上下文窗口：AI 的"记忆"和"注意力"

什么是 Token

什么是上下文窗口（Context Window）

对 iOS 开发者的实际意义

Temperature：控制 AI 的"创造力"

Prompt Engineering：跟 AI 对话的艺术

好 Prompt 的四个要素

反面教材 vs 正面教材

Prompt Engineering 的核心技巧

RAG：让 AI 用上"外部知识"

Agent 与工具调用：让 AI 从"说话"到"做事"

什么是 Agent

工具调用（Function Calling / Tool Use）

模型选型：开源 vs 闭源，参数怎么看

闭源模型 vs 开源模型

参数量是什么意思

实战篇：iOS 开发者的 AI 编程实操

环境准备

实战一：用 AI 生成一个完整的 SwiftUI 页面

步骤

要点总结

实战二：用 AI 重构遗留 Objective-C 代码

步骤

要点总结

实战三：用 AI 调试崩溃（Crash）

步骤

要点总结

实战四：用 AI 写单元测试

步骤

要点总结

实战五：用 AI 做 Code Review

步骤

要点总结

实战六：用 AI 生成网络层代码

步骤

要点总结

高级技巧：.cursorrules 与项目级 Prompt 模板

.cursorrules 文件

Prompt 模板库

最佳实践与未来展望

AI 编程的避坑指南

坑一：盲目信任 AI 生成的代码

坑二：上下文不足导致 AI 瞎猜

坑三：Prompt 写得太模糊

坑四：用 AI 处理不适合它的任务

代码安全与隐私注意事项

学习路径建议

第一阶段：入门（1~2 周）

第二阶段：进阶（1~2 个月）

第三阶段：精通（持续学习）

未来趋势：AI 编程将走向何方

趋势一：Agent 能力持续增强

趋势二：IDE 原生 AI 集成

趋势三：端侧模型与隐私计算