截至 2026 年 6 月，系统化的 Prompt Engineering 方法框架、核心技巧清单、场景化模板、评估和版本管理体系。指导如何写出"稳定、可复用、可测试"的 Prompt。

一句话解释

Prompt Engineering 不是"技巧堆砌"，而是系统化设计 LLM 交互行为的工程方法——核心是在"模型会犯错"这个前提下，通过结构化设计让模型的输出尽可能稳定、可靠、可控。

两个核心框架

CRISP 框架（结构化 Prompt 设计）

要素	含义	示例
C — Context	背景信息	"你是一个 10 年经验的 iOS 工程师"
R — Role	角色定义	"你正在帮助初级开发者审查代码"
I — Instruction	具体指令	"请找出代码中的内存泄漏风险"
S — Style	输出风格	"用 Markdown 格式输出，每个问题附修复代码"
P — Purpose	明确目标	"目标是帮助开发者写出更安全的 Swift 代码"

应用场景：写一次性 Prompt 时的快速脚手架——确保不遗漏关键要素。

RISEN 框架（复杂任务拆解）

要素	含义	示例
R — Role	角色	"你是一个技术架构师"
I — Instruction	指令	"分析这个系统的性能瓶颈"
S — Steps	步骤拆解	"1. 先识别瓶颈点 2. 分析根因 3. 提出优化方案"
E — Examples	示例	"类似系统的分析案例参考"
N — Narrowing	范围限定	"仅分析数据库层，不超过 500 字"

应用场景：复杂多步任务——先让模型按步骤执行，每一步的输出作为下一步的输入。

技巧选择决策流

使用原则：从最简技巧开始，只有当前技巧不够用时才叠加更复杂的技巧。一顿完整的 prompt 通常组合 2-4 个技巧。

10 个核心技巧

1. 角色设定（Role Prompting）

❌ "写一篇关于 AI 安全的文章。"
✅ "你是 AI 安全领域的研究员，要为 CTO 级别的读者写一篇 1000 字的技术趋势分析。"

原理：角色设定激活了模型在训练数据中学到的特定"说话方式"。

2. 步骤拆解（Step-by-Step）

❌ "分析这份用户反馈数据。"
✅ "按以下步骤分析：
    1. 先提取各用户的反馈主题
    2. 按主题聚类
    3. 统计频次并排序
    4. 按频率输出 Top-5 问题"

原理：模型在顺序推理时比一次性输出更准确。

3. Few-shot 示例（Example-Driven）

❌ "用 SQL 写一个复杂查询。"
✅ "给定以下模式：users(id, name, email), orders(id, user_id, amount, created_at)
   类似查询示例：'找出上月消费最多的用户' → 
   SELECT users.name, SUM(orders.amount) as total
   FROM users JOIN orders ON users.id = orders.user_id
   WHERE orders.created_at >= '2026-05-01'
   GROUP BY users.id ORDER BY total DESC LIMIT 1
   
   现在写：'找出从未下单的用户'"

4. 输出格式控制（Structure Control）

请用以下 YAML 格式输出：
```yaml
summary: "一句话总结"
key_points:
  - "要点 1"
  - "要点 2"
risk_assessment:
  level: high/medium/low
  reason: "原因"

### 5. 约束分支（Constraint Branching）

如果需要代码，用 Python 写并附测试 如果需要解释，用 3 句话以内 如果都不适合，直接说"我不确定这个问题的答案"

### 6. 思维链（Chain of Thought）

问题：一个池子，甲 4 小时能装满，乙 6 小时能排空。如果同时开甲和乙，多长时间能装满？ 请先一步步推理，再给出答案。

### 7. 反向指令（Negative Prompting）

❌ "不要胡说八道。" ✅ "如果你不确定答案，直接说"我不确定"，不要编造事实。"

### 8. 自我纠错（Self-Correction）

生成回答后，请检查：你的回答有没有基于合理的数据来源？ 如果有不确定的信息，请用 [citation needed] 标注。

### 9. 温度/参数控制（Parameter Tuning）

| 参数 | 低值 (0-0.3) | 中值 (0.5-0.7) | 高值 (0.8-1.0) |
|------|-------------|---------------|---------------|
| **temperature** | 事实性、确定性任务 | 平衡 | 创意写作 |
| **top_p** | 严格采样 | 平衡 | 多样性 |
| **max_tokens** | 越短越聚焦 | — | 越长越发散 |

### 10. 多轮精度策略（Iterative Refinement）

Round 1: "写一个 Python 函数处理 CSV 文件" Round 2: "优化性能，用 pandas 而非 csv 模块" Round 3: "加上类型注解和单元测试"

## 5 个场景化 System Prompt 模板

### 模板 1：代码生成

```markdown
你是一位资深软件工程师，精通 Python/TypeScript/Go。

要求：
1. 每次先理解需求，不急着写代码
2. 输出包含：类型注解、error handling、docstring
3. 复杂逻辑附单元测试
4. 安全优先——不使用高风险函数（eval/exec）
5. 性能敏感时注明时间复杂度

输出格式：\`\`\`语言 + 代码 + \`\`\` + 简要说明

模板 2：写作/内容创作

你是擅长结构化写作的内容创作者。

规则：
1. 每段不超过 5 行
2. 第一段直接给出核心结论（倒金字塔结构）
3. 使用类比和具体例子
4. 避免空洞的形容词（"非常好""极其重要"等）
5. 技术术语第一次出现时给出简明解释

风格：简洁、清晰、有说服力。目标读者是科技行业的中层管理者。

模板 3：数据分析

你是数据科学家，擅长从数据中提取可执行的洞察。

处理流程：
1. 先验证数据的完整性和潜在的异常值
2. 描述数据的分布和统计特征
3. 基于数据做分析，明确区分"事实"和"推测"
4. 每个洞察附上数据支撑（具体数字/百分比）
5. 最终给出 3 条可操作的建议

输出：markdown 表格优先，避免冗长段落。

模板 4：教学/教师

你是擅长用苏格拉底式提问法的技术导师。

教学原则：
1. 不要直接给答案——先用问题引导学生思考
2. 如果学生卡住，从更基础的概念开始解释
3. 每个概念附实际代码/案例
4. 用类比解释抽象概念
5. 确认学生理解后再进入下一主题

规则：
- 如果学生的问题超出了你的知识范围，直接说明
- 涉及最佳实践时，说明"为什么"而不是只说"要这样做"

模板 5：产品经理/需求分析

你是资深产品经理，擅长需求分析。

分析框架：
1. 用户故事：谁 + 想要什么 + 为什么
2. 验收标准：可量化的完成条件
3. 优先级评估：用户价值 > 开发成本 > 技术风险
4. 边界情况：至少列出 3 个边界场景
5. 依赖关系：依赖什么、被什么依赖

输出格式：user story → acceptance criteria → edge cases 的结构。

Prompt 版本管理

为什么需要版本管理？

• Prompt 和代码一样——不改不知道下一个版本是否更好
• 小修改（加一个逗号、换一个词）可能对输出质量产生显著影响
• 多人协作时 A 改了 Prompt，B 不知道，结果输出变了

版本管理实践

v1.0 — 初始版本 | 2026-06-01 — 基于 CRISP 框架创建
v1.1 — 2026-06-05 — 增加 role 定义（从"助手"改为"iOS 工程师"）
v2.0 — 2026-06-10 — 重构输出格式为 YAML

版本管理工具

方法	适合场景	工具
Git 管理	团队协作，Prompt 与代码共存	GitHub/GitLab
Prompt 管理工具	大型项目	PromptLayer、Agenta
Spreadsheet	个人/小团队	Airtable、Notion DB
注释版本号	最小化方案	Prompt 文件头部注释

Prompt 评估体系

评估维度

维度	方法	指标
准确性	与人工答案对比	精确匹配率、BLEU
一致性	同一 Prompt 多次测试	输出差异度、方差
鲁棒性	修改输入措辞	输出变化幅度
效率	Token 消耗	输入/输出 token 数
安全性	越狱测试	有害输出率

评估流程

1. 写 5-10 个测试用例（覆盖正常/边界/异常场景）
2. 用当前 Prompt 跑一遍，记录输出
3. 对照评估标准打分
4. 修改 Prompt 后重新测试
5. 比较修改前后的得分

不要靠"感觉"评估 Prompt。 人类对 Prompt 质量的感觉极不可靠，尤其在 2-3 次测试后会产生偏差。至少 10 次测试 + 结构化评分才能判断一个修改是否有改进。

常见反模式

1. "越长越好" — 冗长的 Prompt 会稀释关键指令，模型注意力有限。每句话都问：这句对输出有影响吗？
2. "一次写完不再改" — 好的 Prompt 是迭代出来的，第一版永远不是最好版
3. "一个 Prompt 通用所有" — 不同任务（写作/编码/分析）需要不同的指令设计
4. "用否定句控制行为" — "不要...""禁止..." 模型对否定句的遵守效果较差，改为肯定句（"只输出事实，不确定的用"我不确定""）
5. "不设输出格式限制" — 不指定格式 = 每次输出结构不同，无法自动化处理
6. "Prompt 温度始终用默认值" — 事实性任务用 0-0.3，创意任务用 0.7-1.0，默认 0.7 对很多任务不最优

与其他概念的关系

• System Prompt设计 — System Prompt 的深入设计方法
• Few-shot Prompt — Few-shot 技术详解
• Chain of Thought使用边界 — CoT 技术的最佳实践和局限
• Prompt反模式 — 常见的 Prompt 错误
• Prompt版本管理 — 版本管理具体操作
• LLM应用模式 — Prompt 设计在不同应用模式中的作用
• 认知负荷 — 认知负荷理论直接指导 Prompt 的长度控制和分步策略
• LLM模型对比 — 不同模型的指令遵循能力和格式要求不同，影响 Prompt 设计

可继续补充的方向

• Prompt 评估自动化：用 LLM 自动评估 Prompt 输出的质量和一致性
• Prompt 链（Prompt Chaining）：多步 Prompt 的连接策略（前一步输出=后一步输入）
• 工具增强 Prompt：结合 Function Calling 和 MCP 的 Prompt 设计
• 多语言 Prompt 设计：中文 vs 英文 Prompt 的质量差异和处理策略
• Prompt Injection 防护：防止恶意 Prompt 注入的安全设计模式

---

参考资料：OpenAI Prompt Engineering Guide、Anthropic Claude Prompt Engineering Guide、DAIR.AI Prompt Engineering Guide、个人实践经验。框架（CRISP/RISEN）为业界常见 Prompt 设计框架的整理，非原创理论。