Ch12 Prompt工程修订于 二〇二六年七月六日
概念-提示词注入
一句话理解
提示词注入(Prompt Injection as a Technique)是一种上下文管理技术,核心做法是把工具描述、可用数据、外部信息直接塞进 Prompt,让模型”看到”外部信息后再生成回答。这里的”注入”是技术手段,而非安全攻击——它指的是将外部上下文”注入”到模型的输入中,以扩展模型的知识边界。
注意:本文讨论的是”提示词注入”作为上下文管理技术,而非作为安全攻击的 Prompt Injection Attack。两者虽然共享同一个术语,但语境完全不同。
技术定义 vs 安全攻击
| 维度 | 提示词注入(技术) | 提示词注入攻击(安全) |
|---|---|---|
| 目的 | 扩展模型能力,让模型获取外部信息 | 覆盖模型指令,让模型做不该做的事 |
| 执行者 | 开发者(系统设计的一部分) | 攻击者(恶意用户) |
| 注入内容 | 工具描述、搜索结果、数据库记录 | 恶意指令、越狱 Prompt |
| 注入位置 | System Prompt 或 User Prompt 的固定位置 | 用户输入中的任意位置 |
| 对系统的影响 | 正面(增强功能) | 负面(破坏安全) |
| 是否可控 | 完全可控 | 需要防御 |
| 2026年状态 | 演化为 RAG 和 System Prompt 设计 | 仍是重要的安全课题 |
核心机制
提示词注入的运作流程:
外部数据源(数据库/API/搜索结果)
│
▼
数据获取层(查询/检索/格式化)
│
▼
注入层(拼接进 Prompt 模板)
│
▼
LLM(看到完整上下文,生成回答)
典型示例:搜索结果注入
# 示例:将搜索引擎结果注入 Prompt
def search_and_inject(user_query: str) -> str:
# Step 1: 执行搜索
search_results = google_search(user_query)
# Step 2: 格式化搜索结果
formatted_results = ""
for i, result in enumerate(search_results[:5], 1):
formatted_results += f"[结果{i}] 标题: {result['title']}\n"
formatted_results += f" 摘要: {result['snippet']}\n"
formatted_results += f" 链接: {result['url']}\n\n"
# Step 3: 注入到 Prompt
system_prompt = f"""你是一个问答助手。以下是搜索引擎返回的相关信息:
{formatted_results}
请基于以上信息回答用户问题。如果信息不足,请明确说明。
在回答中引用信息时,请标注来源编号(如 [结果1])。"""
# Step 4: 调用 LLM
messages = [
{"role": "system", "content": system_prompt},
{"role": "user", "content": user_query}
]
return llm_call(messages)
典型示例:数据库记录注入
# 示例:将数据库查询结果注入 Prompt
def inject_database_context(user_id: str, user_query: str) -> str:
# Step 1: 查询相关数据
user_profile = db.query(f"SELECT * FROM users WHERE id = '{user_id}'")
recent_orders = db.query(f"SELECT * FROM orders WHERE user_id = '{user_id}' ORDER BY created_at DESC LIMIT 10")
support_history = db.query(f"SELECT * FROM tickets WHERE user_id = '{user_id}' ORDER BY created_at DESC LIMIT 5")
# Step 2: 注入到 Prompt
context = f"""
用户信息:
- 姓名: {user_profile['name']}
- 会员等级: {user_profile['tier']}
- 注册时间: {user_profile['created_at']}
最近订单(最近10条):
{format_orders(recent_orders)}
客服历史(最近5条):
{format_tickets(support_history)}
"""
system_prompt = f"""你是一个客服助手。以下是当前用户的相关信息:
{context}
请基于以上信息回答用户问题。如果用户询问的信息不在上下文中,请告知用户。"""
messages = [
{"role": "system", "content": system_prompt},
{"role": "user", "content": user_query}
]
return llm_call(messages)
提示词注入的局限性
| 局限 | 说明 | 影响 |
|---|---|---|
| 上下文窗口有限 | 早期模型只有 4K-8K tokens,注入内容受限 | 无法注入大量数据,只能精选 |
| 数据格式受限 | 只能注入纯文本,无法传递结构化数据 | 模型可能误解数据格式 |
| 信息位置效应 | “Lost in the Middle”——模型对中间位置的信息关注度低 | 重要信息必须放在开头或结尾 |
| 无法动态交互 | 注入是一次性的,模型不能主动请求更多数据 | 需要开发者预判模型需要什么信息 |
| 模板维护成本 | 每种场景需要不同的注入模板 | 场景增多后模板难以维护 |
| 信息过载 | 注入太多信息会导致模型”迷失” | 需要精心设计信息密度 |
2026 年:提示词注入的演化
提示词注入作为一项独立技术,已经演化为以下几个方向:
- RAG(Retrieval-Augmented Generation):系统化的提示词注入——自动检索 + 自动注入 + 自动优化,不再需要手动拼接
- System Prompt 设计:提示词注入的思想被吸收到 System Prompt 的工程化设计中——如何组织工具描述、如何编排上下文顺序
- Tool Use 的 result 回传:Function Calling 中,工具执行结果被自动注入回上下文——本质上是”系统化的提示词注入”
- Dynamic Context Assembly:根据查询动态组装上下文,而不是固定模板注入
相关笔记
- 概念-上下文管理技术 — 四种上下文管理技术的综述
- 概念-Hook机制 — 通过输出标记触发外部操作
- 概念-渐进式加载 — 分步注入上下文
- 提示词的局限 — 提示词的边界和局限
- 上下文压缩(深挖) — 上下文压缩技术
- 上下文工程 — 上下文工程的现代实践
来源
- https://arxiv.org/abs/2307.11760 — “Lost in the Middle: How Language Models Use Long Contexts”
- https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering — Anthropic Prompt Engineering 中关于上下文注入的最佳实践
- https://www.anthropic.com/engineering/building-effective-agents — 关于工具结果如何注入上下文的设计讨论
- https://arxiv.org/abs/2312.10997 — RAPTOR: 分层上下文组织策略