用好 AI
Prompt（提示词）是你与 AI 沟通的语言，也是决定输出质量的第一道关卡。
同样一个 AI 模型，有人用它生成的代码可以直接跑通，有人却连编译都过不了 — 差距往往不在模型本身，而在你怎么跟它说话。
Prompt 就是你对 AI 说的那句话。它可以是一句简单的提问，也可以是一段结构化的任务描述。
比如下面这些，都是 Prompt：
- 「帮我写一段 Swift 代码，实现图片缓存」
- 「用小学生能理解的话解释什么是 HTTP」
- 「从产品经理视角，分析一下小红书和抖音的差异」
你对 AI 说的每一句话，都是 Prompt。
- 即时性：只存在于当前对话中，下次对话 AI 不会记得
- 灵活性：随时调整措辞、补充条件，改变 AI 的输出
- 门槛低，上限高：谁都能写，但写出能稳定产出高质量结果的 Prompt，需要刻意练习
| 概念 | 作用 | 特点 |
|---|---|---|
| Prompt | 告诉 AI「这一次做什么」 | 一次性指令，用完即消 |
| Rules | 告诉 AI「始终遵守什么」 | 持久化的行为规范 |
| Skills | 告诉 AI「这类事按什么流程做」 | 可复用的能力模块 |
Prompt 像是你在餐厅点菜时说的那句话，Rules 是厨房的卫生规范，Skills 是大厨的拿手菜谱。三者配合，才能端出一桌好菜。
| 模糊 Prompt | 清晰 Prompt | |
|---|---|---|
| 输入 | 「写个登录功能」 | 「用 Swift + UIKit 实现登录页，包含账号密码输入框、表单校验、网络请求，使用 async/await，不用第三方库」 |
| AI 表现 | 可能给你一段没有校验、没有错误处理、甚至语言都不对的代码 | 直接输出一份结构清晰、可以跑通的登录模块 |
原因在于大模型的工作方式 — 你给的信息越模糊，它要「猜」的地方就越多，结果就越不可控。下一节详细解释。
控制方向 — 告诉 AI 从什么角度做。
「解释 TCP」→ AI 可能泛泛而谈。
「从 iOS 开发者的角度，解释 TCP 三次握手在网络请求中的实际影响」→ 聚焦到你关心的层面。
提供上下文 — 给 AI 足够的背景信息，减少猜测空间。
你是一名资深 iOS 架构师，请设计一个支持千万级用户的订单系统，包含架构图、核心模块和数据库设计。
一句话同时给了角色、任务、约束和输出形式。信息越完整，输出越贴合预期。
施加约束 — 限定输出的范围、格式和风格。
- 「用 200 字以内解释什么是 GitHub」
- 「请用表格形式输出」
- 「只列要点，不要展开论述」
一句话总结：好的 Prompt = 方向明确 + 上下文充分 + 约束具体。
学习写好 Prompt，收益不只是「AI 听话了」：
- 提升表达精度：写 Prompt 的过程，本质上是在梳理「我到底要什么」。很多时候你觉得 AI 输出不好，回头看看 Prompt，往往是自己没想清楚。
- 节省时间成本：一个精准的 Prompt 可以一次到位，省去反复沟通、多轮修改的时间。
- 建立结构化思维：Prompt 的写法（角色、背景、任务、约束、输出）其实就是一套需求分析框架，这个能力在任何协作场景中都有用。
写不好 Prompt，往往不是技巧不够，而是不理解模型在做什么。
你输入的 Prompt（上下文）
↓
模型计算每个 Token 出现的概率
↓
选出概率最高的 Token，拼接成回答
模型不是在「思考」你的问题，而是在做文本接龙 — 根据前文，预测最可能的下文。
这有点像手机输入法的联想：你打「今天天气」，输入法建议「不错」「很好」，因为这些词出现频率最高。大模型做的事本质一样，只不过「联想」范围覆盖了整个人类知识库。
(1) AI 不理解世界，它理解的是文本模式
当你问「解释 TCP 三次握手」，模型并不是在思考网络协议的工作机制。它做的是：在训练数据中找到「解释 TCP 三次握手」这个上下文最常出现的后续文本，然后生成一段最像「正确解释」的回答。
它靠的是语言中的统计规律，而不是对协议本身的理解。这就是为什么 AI 有时候能写出看似正确但细节有误的内容 — 因为它追求的是「像」，不是「对」。
(2) Prompt 越清晰，模型「猜」得越少
- 模糊 Prompt → 概率分散 → 模型靠猜补全 → 结果不可控
- 清晰 Prompt → 概率集中 → 生成范围被锁定 → 结果稳定
「写段代码」→ 模型要猜语言、猜功能、猜风格。「用 Swift 写一个快速排序函数，包含泛型和详细注释」→ 所有关键变量被锁定。
(3) Prompt 不是「提问」，而是「上下文编程」
很多人把 Prompt 当「提一个问题，等回答」。更准确的理解：你在用自然语言给模型写一段临时程序，配置它的输出行为。
你是一名资深 iOS 工程师。请分析下面代码的线程安全问题。只输出风险点。
拆开看：
| Prompt 中的文字 | 实际作用 |
|---|---|
| 你是一名资深 iOS 工程师 | 配置模型的知识域 |
| 请分析线程安全问题 | 配置执行目标 |
| 只输出风险点 | 配置输出过滤条件 |
理解这一点，你写 Prompt 时就会从「随口一问」变成「有意识地设计」。
(4) 上下文有容量限制
大模型有「上下文窗口」（Context Window），目前主流模型在 128K ~ 200K Token。超过就会截断。所以提供高质量的精炼上下文，比提供大量低质量的信息更重要。
关于 Token 和上下文窗口的详细解释，参见 Token。
写之前过一遍这五类信息，不需要每次全写，但心里要有这个框架：
| 要素 | 作用 | 示例 |
|---|---|---|
| 角色 | 让 AI 站在特定专业视角 | 「你是一名有 10 年经验的 iOS 架构师」 |
| 任务 | 明确要做什么 | 「设计一个图片缓存系统」 |
| 背景 | 补充项目、场景、技术栈 | 「项目使用 Swift 5.9 + UIKit + SnapKit」 |
| 输入 | 提供需要处理的素材 | 「以下是现有的网络层代码：...」 |
| 输出 | 定义格式、长度、风格 | 「用 Markdown 表格输出，不超过 500 字」 |
最小可用组合：任务 + 输出格式。只写这两条，效果也比「裸问」好很多。
完整示例：
你是一名资深 iOS 工程师（角色）， 请分析下面 Swift 代码在网络请求场景下可能存在的问题（任务 + 背景）， 重点关注线程安全和循环引用（约束）， 只列出风险点，不需要解释基础语法（输出格式）。
你是 [角色]。
请 [任务]。
输出要求：[格式/长度/形式]。
你是一名资深 iOS 工程师。请解释 Swift 中 escaping closure 的使用场景。输出要求：结合网络请求回调举例，并给出代码示例。
背景：[项目/技术栈/当前状况]
任务：[要完成的事]
约束：[必须/禁止/偏好]
背景：正在开发一个 iOS App，需要实现图片列表加载。
任务：设计图片加载方案。
约束：使用 Swift，不用第三方库，支持内存 + 磁盘双级缓存，列表滚动时避免重复下载。
需要 AI 严格按特定格式输出时，最有效的方法不是描述格式，而是给例子。
请把用户反馈分类为：功能建议 / Bug 报告 / 其他
示例：
输入：希望支持深色模式 → 输出：功能建议
输入：点击保存会闪退 → 输出：Bug 报告
现在分类：
输入：登录时一直转圈
给了示例后，模型会非常稳定地模仿格式输出。
| 字母 | 含义 | 作用 |
|---|---|---|
| C | Capacity / Role | 定义角色 |
| R | Request | 明确任务 |
| I | Input | 提供输入 |
| S | Steps | 指定步骤 |
| P | Personality | 设定风格 |
| E | Experiment | 要求多方案 |
示例：
Role：资深 iOS 架构师
Request：根据 PRD 设计客户端技术方案
Input：以下是产品需求文档摘要：（粘贴内容）
Steps：1. 分析核心业务模块 → 2. 设计数据模型 → 3. 给出接口结构和数据流
Personality：回答风格偏工程化，直接给方案
实际使用中不需要六个全写。社区中还有 BROKE、ICIO 等框架，核心思路都类似。不必纠结用哪个，找到一个顺手的就好。
思维链（CoT） — 加一句「请一步步分析」，AI 会展开推理过程，准确率显著提升。适合复杂推理和 Debug 场景。
分隔符 — Prompt 同时包含指令和数据时，用 """、--- 或 XML 标签把两者分开，防止模型把数据当指令执行。
请分析下面 """ 包裹的代码中的循环引用风险：
"""
class ViewController {
var onComplete: (() -> Void)?
func setup() {
onComplete = { self.doSomething() }
}
}
"""
结构化 Prompt — 当 Prompt 变复杂时，借鉴编程思路，用 Markdown 模块化组织。LangGPT 是这个思路的典型代表：
# Role: iOS 代码审查专家
## Profile
- Language: 中文
- Description: 专注于 Swift/iOS 代码质量审查
## Skills
1. 识别内存泄漏、循环引用等常见问题
2. 评估代码的可读性和可维护性
## Rules
1. 只指出实际存在的问题，不要过度解读
2. 每个问题附上具体的代码行号和修改建议
## Workflow
1. 先通读代码，理解整体结构
2. 按优先级列出问题（严重 → 一般 → 建议）
3. 给出修改后的代码示例模块清晰、易于复用、方便迭代。当某个 Prompt 需要反复使用时，把它结构化是值得投入的优化。
精准描述，减少歧义
| 写法 | 问题 |
|---|---|
| ❌ 「优化一下这段代码」 | 不知道优化什么：性能？可读性？安全性？ |
| ✅ 「重构这段代码，将嵌套回调改为 async/await，保持原有功能不变」 | 目标明确 |
拆分大任务，逐步推进
第一步：「分析这段代码的架构问题，列出 3 个最严重的」
第二步：「针对第 1 个问题，给出重构方案和代码」
第三步：「检查重构后的代码是否有性能问题」
明确边界，控制发挥空间
- 「只列出风险点，不需要解释基础概念」
- 「不要使用第三方库」
- 「必须包含错误处理逻辑」
| 问题 | 原因 | 解决 |
|---|---|---|
| 输出太泛 | 没有限定角色和场景 | 加角色设定和具体场景 |
| 输出太长 | 没有格式约束 | 加「200 字以内」「只列要点」 |
| 答非所问 | 混了多个任务 | 拆成多个 Prompt |
| 格式不对 | 没给输出示例 | 用 Few-shot 给范例 |
| 代码跑不了 | 没指定技术栈版本 | 写清语言、框架、版本 |
当 Prompt 越来越多，值得系统化管理：
模板化 — 把常用 Prompt 固定为模板，每次只替换变量部分。
版本管理 — Prompt 改一个词，输出可能完全不同。给 Prompt 编版本号（v1、v2、v3），便于对比效果和回滚。
团队沉淀 — 在团队内部建立 Prompt Library，按场景分类（代码生成、代码审查、文档写作、Bug 分析），避免重复造轮子。
好的 Prompt 不是一次写出来的，而是调出来的。
第一步：写最简版本
解释 Swift 中的 escaping closure
看 AI 怎么回答，建立「基线」。
第二步：诊断问题
| 问题 | 表现 |
|---|---|
| 太浅 | 只讲概念，没深入到实际场景 |
| 太泛 | 什么都提了一嘴，但没针对你的需求 |
| 缺示例 | 全是文字，没有代码 |
| 偏离场景 | 讲的是通用场景，和你的项目不匹配 |
第三步：补约束，迭代
从 iOS 开发角度解释 escaping closure，结合网络请求回调场景，重点说明循环引用问题及解决方案，并给出代码示例。
对比第一步的输出，不满意就继续微调。先写「能跑」的版本，再有针对性地加约束、加示例、加角色 — 比冥思苦想一个「完美 Prompt」高效得多。
几个常见开发场景的 Prompt，可以直接复用或根据你的技术栈微调。
代码解释
你是一名资深 iOS 工程师。请解释下面 Swift 代码的作用，重点说明线程安全和潜在问题。用要点列出，每个要点不超过两句话。
代码重构
请重构下面的 Swift 代码：1. 将回调嵌套改为 async/await；2. 保持原有功能不变；3. 添加错误处理；4. 提高可读性。
Bug 分析
下面是一段 Swift 代码和崩溃日志。请分析崩溃原因，列出排查思路，给出修复建议。重点关注内存管理和线程安全。
技术方案设计
你是一名 iOS 架构师。根据下面的需求，设计客户端实现方案，包括：模块划分、核心数据模型、关键接口设计、技术风险。输出用 Markdown 格式。
代码审查
请审查下面的代码，从代码规范、潜在 Bug、性能、可维护性四个角度给出反馈。每个问题附上具体代码行和修改建议。
| 资源 | 说明 |
|---|---|
| OpenAI Prompt Engineering 指南 | 官方最佳实践 |
| Claude Prompt Engineering 文档 | Anthropic 官方指南 |
| LangGPT | 结构化 Prompt 设计方法，中文社区活跃 |
| Claude 提示词库 | 官方示例库，覆盖多种场景 |
| 通往 AGI 之路 | AI 学习社区，含 Prompt 案例 |
使用建议：先理解角色、任务、约束、示例这些核心要素，再去模板站找相近场景改一改。在日常工作中刻意练习「加角色、加约束、加示例」，比只看教程进步快。效果好的 Prompt 保存下来按场景归类，下次直接复用。
Prompt 是与 AI 交互的基础，但它有明确的能力边界。
上下文窗口有限 — 你无法把整个代码仓库一次性塞给 AI。信息不全时，AI 会用「常识」补全，这就是幻觉的来源之一。
单次 Prompt 驾驭不了复杂任务 — 涉及多文件、多步骤、多角色配合时，模型容易漏步骤、忘约束。Prompt 最适合「单点、明确、少步骤」的任务。
Prompt 无法替代系统化流程 — 完整的开发流程（需求 → 架构 → 编码 → 测试）靠 Prompt 推进，环节之间缺乏稳定衔接。这正是 Rules、Skills、Agent、MCP 出现的原因 — 当任务复杂到一定程度时，你需要从「写一句指令」升级到「配置一套系统」。