Prompt Engineering（提示词工程）

什么是 Prompt Engineering

Prompt Engineering 是设计和优化 LLM 输入提示词的技术，目标是让模型生成更准确、更有用的输出。

它不是"哄模型"，而是用结构化的方式精确传达你的意图。

核心技巧

1. 角色设定

给模型一个明确的角色，让它知道用什么视角回答。

你是一个资深 Python 后端工程师，擅长 FastAPI 和 PostgreSQL。
请审查以下代码的安全性和性能问题。

2. Few-shot 示例

给模型几个输入输出范例，让它学会你期望的模式。

输入：这个函数太慢了
输出：该函数时间复杂度为 O(n²)，建议改为哈希表查找，降至 O(n)。

输入：这里会内存泄漏
输出：该代码创建了事件监听器但未在组件销毁时移除，导致内存无法回收。

输入：{{用户输入}}
输出：

3. Chain-of-Thought (CoT)

让模型"想一想再回答"，显著提高推理准确率。

请逐步分析以下问题，先写出推理过程，再给出最终答案。

问题：一个水池有两个进水管，A 管 3 小时注满，B 管 5 小时注满，同时开几小时注满？

对于 Claude Sonnet 4 / GPT-5 等推理模型，不需要显式要求 CoT——它们内置了思维链能力。

4. 结构化输出

要求模型用特定格式输出，方便程序解析。

请以 JSON 格式输出，包含以下字段：
{
  "bug_found": true/false,
  "severity": "high/medium/low",
  "description": "问题描述",
  "fix_suggestion": "修复建议"
}

生产场景下不要靠 prompt"求"模型出 JSON——用 Structured Outputs（OpenAI）、Tool Use（Anthropic）或 responseSchema（Gemini）做硬约束。

5. 约束条件

明确告诉模型什么该做、什么不该做。

规则：
1. 只审查安全相关的问题，不评论代码风格
2. 如果没有安全问题，明确说"未发现安全问题"
3. 每个问题必须给出具体的代码行号
4. 不要给出模糊的建议如"注意安全"

6. 分步指令

复杂任务拆成明确步骤。

请按以下步骤执行：
1. 读取 src/auth.ts 文件
2. 找出所有 SQL 查询
3. 检查是否使用了参数化查询
4. 列出有 SQL 注入风险的查询
5. 给出修复建议

XML vs Markdown 结构化

主流两种 prompt 结构化方式，按模型挑：

<!-- XML 风格（Anthropic 官方推荐）-->
<context>
  <file path="src/auth.ts">...</file>
</context>
<task>Review for security issues.</task>
<rules>
  <rule>Only report security findings.</rule>
</rules>

<!-- Markdown 风格（OpenAI 偏好）-->
## Context

File: src/auth.ts
[content]

## Task
Review for security issues.

## Rules
- Only report security findings.

经验：

• Claude 系列：XML 标签明显更稳定，错读概率低
• GPT 系列：Markdown 标题更自然，对 ## / ### 层级敏感
• Gemini：两者差不多
• 国产模型：建议 Markdown，部分模型对 XML 的训练数据少

混搭也行，但一个 prompt 内挑一种贯彻到底，不要 XML 和 Markdown 交替。

Anthropic / OpenAI 官方模板风格

工业级 prompt 通常长这样（Anthropic 风格示例）：

<role>
You are a senior security engineer reviewing pull requests.
</role>

<instructions>
1. Read the diff in <diff> below
2. Identify security vulnerabilities
3. Output findings in the format specified in <output_format>
</instructions>

<output_format>
For each finding:
- severity: critical | high | medium | low
- file: <path>
- line: <number>
- issue: <one sentence>
- fix: <code or text>
</output_format>

<examples>
<example>
Input: ... diff with SQL injection ...
Output: { "severity": "critical", "file": "auth.py", ... }
</example>
</examples>

<diff>
{{actual diff}}
</diff>

要点：

• 角色、指令、输出格式、示例、动态内容各占独立标签
• 动态内容（用户输入、检索结果）放最后——既配合 prompt cache，又减少注入风险
• Few-shot 数量 1-5 个最佳，过多反而稀释指令权重

推理模型的 prompt 写法不一样

GPT-5、Claude Opus 4 thinking、DeepSeek-R1 等推理模型不应再写 CoT 指令：

❌ 老写法（对 GPT-4o 有效）
"请一步一步思考，先写出推理过程..."

✅ 推理模型新写法
直接说目标和约束，不要教它怎么想

原因：推理模型内置了思维链，再加 CoT 反而会让它在"展示思考"上花更多 token、却没有更聪明。给清楚目标和验收标准即可。

类似的：

• 推理模型不需要 "take a deep breath" / "you are an expert" 这类老套激励
• Few-shot 仍然有效，但作用从"示范怎么想"变成"约束输出格式"
• 温度建议保持默认（通常 1.0），别强行调 0

高级技巧

Self-Consistency

让模型多次回答同一个问题，取多数结果。适用于数学/推理题。

ReAct

Thought → Action → Observation 循环，Agent 的基础模式。

Tree of Thoughts

让模型探索多条推理路径，选最优的。适合复杂决策。

Prompt Chaining

把一个复杂任务拆成多个 prompt 串联：

Prompt 1: 提取文章关键信息 → 输出 JSON
Prompt 2: 基于 JSON 生成摘要 → 输出摘要
Prompt 3: 基于摘要生成社交媒体文案 → 输出文案

Prompt 的工程化：当 prompt 变成代码

生产级 prompt 不是字符串拼接，是要进 git 的"代码"。需要：

1. 版本化 + Code Review

每个 prompt 一个文件（.md / .txt），改动走 PR review。模板插值用 Jinja2 / Handlebars 而不是 f-string 散落各处。

2. 评测集（Eval Set）

任何 prompt 改动前必跑回归测试：

golden_dataset.jsonl
├─ 100 条典型 case
│  - input
│  - expected_output（或 expected_format）
│  - rubric（评分细则）
└─ 跑新 prompt → 自动比对 → 通过率不降才合并

工具：Promptfoo / LangSmith / Braintrust / 自己写。

3. A/B 测试

灰度发布 prompt 变更，看真实用户场景下指标（任务成功率、用户满意度、token 成本）。

4. 监控

线上每个调用都记 prompt_version + input + output + tokens，方便定位回归。

把 prompt 当代码维护后，"改一个字模型就崩"的痛苦会大幅减少。这是从 demo 到生产最关键的工程化跃迁。

在 AI 编程中的实践

Cursor / Claude Code

这些工具内部用了大量 prompt engineering：

• System Prompt — 定义 AI 的角色和行为规范
• Context Assembly — 组装文件、光标位置、对话历史
• Tool Definitions — 定义搜索、编辑、终端等工具
• Few-shot — 展示工具调用的正确格式

代码审查 Prompt

你是一个代码审查专家。请审查以下 Git diff：

{{diff}}

检查以下方面：
1. 安全漏洞（SQL 注入、XSS、敏感信息泄露）
2. 性能问题（N+1 查询、内存泄漏、不必要的计算）
3. 逻辑错误（边界条件、空指针、竞态条件）
4. 可维护性（命名、复杂度、重复代码）

输出格式：
- 🔴 严重：[问题描述] (行号)
- 🟡 建议：[问题描述] (行号)
- 🟢 良好：[做得好的地方]

常见误区

1. "Prompt 越长越好"

不。无关内容会分散模型注意力。每个词都应有存在理由。

2. "加'你是专家'就有用"

角色设定只在角色与任务相关时有效。"你是诗人"对代码审查没有帮助。

3. "示例越多越好"

3-5 个精选示例通常优于 10 个冗余示例。质量 > 数量。

4. "一个 prompt 解决所有问题"

复杂任务应该用 prompt chaining 或 agent 模式拆分，而不是写一个巨型 prompt。

5. "调好的 prompt 一直能用"

模型每次升级（GPT-4 → GPT-5），prompt 行为都会微变。改基础模型必须重跑评测集。

延伸阅读

• 进阶视角：Context Engineering——Prompt 是其中一部分
• 结构化输出：Function Calling 的 Structured Outputs
• Agent 中的 prompt：AI Agent
• 控制随机性：Temperature 与 Top-P