[AI/Agent/提示词/上下文] Prompt Engineering/提示词工程

0 序 : 如何编写高质量的 Prompt ?没有银弹，唯有【持续迭代】、没有完美提示词

没有完美的 Prompt，只有不断迭代的 AI Agent / Prompt。

1 概述 : Prompt 工程

提示词工程的定义（必读）

• 提示词工程(Prompt Engineering): 通过设计输入给模型的“任务、目标、约束、示例与行为规则”，把人的意图转换成模型可执行指令的工程。

业界定义基本都指向这一点：通过设计和优化【输入】，去引导【模型】产生【期望的输出】。

提示词工程的诞生原因（真正解决的问题）（必读）

解决 AI Agent 对【用户意图】到【行为】的映射问题

• 最本质的问题其实只有一个：LLM 本身不知道“你到底想让它怎么做”。

• LLM 有很强的通用能力，但它面对一个任务时，并没有天然知道：

• 目标是什么 （目标）
• 应该采用什么方式完成 （方式）
• 什么算完成得好 （评估）
• 哪些事情不能做 （约束:禁止）
• 输出应该是什么格式 （约束:格式）
• 遇到不确定情况应该怎么办（约束:例外/异常）

所以：模型能力 ≠ 任务执行能力。

中间缺了一层：人类意图 → 模型可执行行为

• 而 Prompt Engineering 本质上就是在解决这层意图到行为的映射问题。

从 AI Agent 视角看，会更加清楚: 给【模型】定义一次任务执行的“【行为契约】”

• 可以把 Agent 的一次 LLM 调用抽象成：

                人类目标
                   ↓
              「我要什么」
                   ↓
        ┌───────────────────┐
        │ Prompt Engineering│
        │                   │
        │ 目标               │
        │ 任务               │
        │ 规则               │
        │ 约束               │
        │ 示例               │
        │ 输出要求           │
        └───────────────────┘
                   ↓
              LLM 推理/生成
                   ↓
              Agent 行为

因此，Prompt 本质上不是“问模型的问题”。

• 对于 AI Agent 来说，它更接近：给【模型】定义一次任务执行的“行为契约（Behavior Contract）”。

• 例如:

你是一个企业财务分析 Agent。

目标：
分析用户提供的财务数据，找出异常。

规则：
1. 只能使用提供的数据
2. 不确定时必须明确说明
3. 不允许自行编造数据

执行要求：
1. 先识别异常
2. 再分析原因
3. 最后给出建议

输出：
JSON
{
  "anomalies": [],
  "causes": [],
  "recommendations": []
}

这实际上已经不是简单的“提示”。
它是在定义 AI Agent 的局部行为逻辑。

Prompt Engineering 真正优化的不是“文字”，而是：模型在给定输入下的行为

因此：Prompt Engineering 真正优化的不是“文字”，而是：模型在给定输入下的行为

• 这是一个非常重要的认识。

很多人把 Prompt Engineering 理解成：“怎么把一句话写得更聪明？”
其实不是。真正优化的是：模型在给定输入下的行为。

• 因此，可以把它看成：Prompt Engineering --> 设计模型输入 --> 改变模型行为 --> 提高任务成功率

所以，它最终关注的指标应该是：

• Task Success Rate
• Accuracy
• Consistency
• Reliability
• Format Compliance
• Safety
• Cost / Latency

而不是简单一句：“这个 Prompt 写得漂不漂亮。”
这也是为什么现代 Prompt Engineering 越来越强调测试、迭代和评估，而不是追求所谓“完美 Prompt”。 Claude

Prompt Engineering 解决的其实是3个层次的问题：意图问题(Intent)、行为问题(Action/Process)、输出问题(Output)

可以进一步拆成：

1、意图问题 : 我要模型做什么？

例如：分析这份合同

太模糊。
Prompt Engineering 把它变成：

识别合同中的：
  1. 付款条款
  2. 违约责任
  3. 自动续约条款
  4. 对甲方不利的风险

2、行为问题 : 模型应该怎么做？

例如：

先提取事实
→ 再分析风险
→ 最后给建议

这实际上是在给【模型】定义【执行策略】。

3、输出问题 : 什么结果才算完成？

例如：

{
  "risk_level": "high",
  "risks": [],
  "evidence": [],
  "recommendations": []
}

这把开放式生成变成了【可验证的任务输出】。
所以，可以抽象成：Prompt Engineering = 目标定义 + 行为约束 + 执行指导 + 结果规范

本质区别： Prompt Engineering/提示词工程 vs. Context Engineering/上下文工程 vs. Memory/记忆组件 = 指令意图 vs. 信息输入编排 vs. 状态持久存储与召回（必读）

• 推荐文献

• [AI/Agent] Context Engineering/上下文工程 - 博客园/数据知音

• 核心视角：提示词工程管 “指令意图”，上下文工程管 “信息输入编排”，记忆管 “状态持久存储与召回”

维度	提示词工程(Prompt Engineering)	上下文工程(Context Engineering)	记忆(Memory，Agent Memory)
本质定义	对大模型接收的指令、角色、规则、约束、输出格式做结构化设计，告诉模型「要做什么、按什么规则做、怎么输出」，属于意图‑约束层。	对送入模型窗口内的全部输入信息做编排、裁剪、排序、过滤、组装，管理有限上下文窗口内的信息流，解决窗口内信息组织问题，属于输入编排层。	Agent的持久化状态存储模块，负责历史对话、事实、经验、实体的保存、检索、更新，信息不完全驻留在即时上下文窗口，属于状态持久层。
真正解决的 核心问题	模型理解任务目标、遵守业务规则、输出符合预期格式；弥补模型“不知道任务要求、不知道行为边界”；解决意图对齐、行为约束、输出范式问题。 不解决信息容量、历史留存问题。	解决上下文窗口有限下，信息怎么选、怎么排、怎么删；避免冗余、噪声、信息丢失；把外部/记忆取出的素材加工成适合模型读取的输入；解决窗口内信息质量与利用率问题。	突破LLM上下文窗口限制，跨轮次、跨会话保存Agent状态、历史事实、用户偏好；实现长期知识沉淀；解决跨窗口状态留存、历史信息复用问题。
信息存在位置	全部直接放在当前prompt消息里，属于即时输入。	输出产物是送入LLM的messages上下文列表，存在模型窗口内。	原始数据存外部存储（向量库/数据库），按需检索后，交给上下文工程再塞入窗口，原始数据不在窗口常驻。
输入输出	输入：角色设定、任务描述、工具规则、格式模板； 输出：结构化prompt字符串/消息数组。	输入：记忆召回结果、工具返回、用户query、历史消息； 输出：组装完成的messages上下文。	输入：对话记录、工具结果、事实实体； 输出：检索出来的历史片段，不直接喂给模型。
依赖关系	提示词工程依赖上下文工程提供干净的上下文；提示词本身是上下文的一部分。	上下文工程读取记忆模块的数据，再结合提示词模板拼装完整请求。	记忆不直接调用大模型，产出物交给上下文工程处理，记忆本身不定义任务规则。
典型失败表现	模型跑偏任务、不遵守格式、乱调用工具、行为不符合角色设定。	上下文超限截断、关键信息被丢弃、信息顺序错乱、噪声太多模型被干扰。	忘记跨会话的用户信息、丢失长期事实、无法复用之前经验。
AI Agent中 典型实例	System Prompt角色设定、工具调用描述、ReAct思考模板、输出JSON约束。	滑动窗口、摘要压缩、RAG召回片段重排、消息过滤、消息优先级排序。	短期记忆、长期记忆、向量记忆、实体记忆、记忆摘要、记忆遗忘机制。

1. 提示词工程：告诉Agent该怎么干活（规则、目标、范式）
2. 上下文工程：把干活要用的材料整理好塞进模型窗口
3. 记忆：把过去发生的事存起来，需要的时候再拿出来给上下文工程使用

• 流转链路：【记忆】(存/查历史) → 【上下文工程】(有限窗口内，筛选组装信息) + 【提示词工程】(任务规则模板) → 合并为完整messages送入【LLM模型】。

三者分工独立，流水线式协作，不可互相替代。(样例示意图:)

记忆模块(Mem0/Letta/LangMem) → 检索出历史片段
        ↓
【上下文工程】：过滤、去重、优先级排序、压缩、裁剪，产出候选消息列表
        ↓
【提示词工程】：加载system角色模板、工具描述、输出schema，渲染变量
        ↓
合并为完整messages，送入LLM

• 常见误区：

1. 买一个记忆库就以为解决上下文问题：记忆只负责存与检索；检索出来的脏数据仍然需要上下文工程清洗组装。
2. 把所有业务逻辑全部塞进提示词：不可维护，关键校验逻辑下沉代码层。
3. 完全依赖框架自带上下文策略：通用策略不能适配你的业务信息优先级，生产必须【二次定制】。

最佳实践: 提示词工程 vs. 上下文工程

• 本质回顾

• 提示词工程：定义任务目标、角色、规则、输出范式；解决模型意图对齐、行为约束。
• 上下文工程：筛选、裁剪、排序、压缩、组装送入窗口的全部信息；解决稀缺 token 预算、丢失‑in‑middle、上下文溢出问题

维度	提示词工程最佳实践	上下文工程最佳实践
核心原则	最小必要原则，拒绝堆砌文本； System Prompt做分层：角色→任务→约束→工具规则→输出格式； 【业务规则】与【推理模板】分离。	Token是稀缺资源； 只把高信号信息送入【窗口】； 优先【按需加载】，不要一次性全量灌入； 对抗丢失‑in‑middle； 控制噪声、冗余、重复信息。
模板与版本	使用模板引擎管理，禁止硬编码字符串；提示词版本管理，变更配套评测用例；Few‑shot少量高质量样例，不要大量样例；输出强制Schema约束，配合输出解析器校验。	消息排序：关键信息放头部/尾部；实现多套策略：滑动窗口、摘要压缩(compaction)、消息过滤、优先级丢弃；工具返回结果做摘要/截断，不要直接塞原始大返回值。
安全与鲁棒	防提示注入；区分可信/不可信输入；业务校验不能完全交给模型，关键输出代码层校验；不要把业务逻辑埋进prompt字符串。	外部检索内容做去重、过滤、重排；不可信外部内容做清洗；大体积工具输出做“卸载”，只把摘要/指针放入上下文，原始数据放外部存储。
测试观测	Prompt变更必须做回归评测；链路追踪，观测模型是否遵守规则、格式；不同模型需要适配提示词，一套prompt不能通吃所有基座。	统计token消耗；观测上下文膨胀趋势；对比不同上下文策略下Agent成功率；定位是信息缺失还是噪声干扰导致失败。
业务边界	通用推理模板复用；业务特有角色、业务约束、业务输出schema必须业务侧编写。	通用组装、压缩、滑动窗口逻辑复用；业务信息优先级、业务过滤规则、业务元数据逻辑需要业务侧定制。

提示词工程：哪些需要自研？哪些可复用开源项目？

模块	可直接复用开源/框架能力	建议项目自行实现（业务定制）
提示词工程	PromptTemplate/ChatPromptTemplate模板渲染、Few‑shot样例选择器、结构化输出解析器、提示词版本管理、DSPy自动提示优化、提示注入检测组件。	业务角色定义、业务约束规则、业务输出Schema、业务样例、业务安全护栏、业务特定Agent思考模板。
上下文工程	消息滑动窗口、基础compaction摘要压缩、消息过滤、token计数、基础重排、消息中间件、checkpoint会话持久；LangGraph / LlamaIndex / OpenAI‑Agents‑SDK提供基础能力。	业务信息优先级策略；业务数据裁剪规则；工具返回值业务侧摘要逻辑；业务元数据过滤；业务场景下compaction策略调优；记忆召回结果的业务筛选。

关键结论：底层基础设施尽量复用开源；业务语义、业务规则、业务优先级几乎无法完全开源替代，必须自己写/调。

• 提示词工程的主流开源项目

1. LangChain / LlamaIndex：PromptTemplate/ChatPromptTemplate/RichPromptTemplate，模板渲染、变量替换、消息数组组装，工业界最常用。
2. DSPy：声明式签名(Signature)，自动优化prompt、自动选few‑shot样例；把“写prompt”变成“声明输入输出字段”，适合减少手工调prompt成本。

若希望减少手工写prompt：可引入 DSPy，但业务约束与schema仍要自己定义。

3. LMQL：类SQL提示词查询语言，把prompt逻辑代码化。
4. Agenta / PromptLayer：提示词版本管理、评测、A/B测试平台。

Agent Prompt 设计的6大核心原则

• 【单一】职责：一个Agent只做一件事，做好一件事。

• 职责【分离】：LLM擅长创造性生成，不擅长确定性决策。

• 【显式】优于隐式：状态、规则、示例都显示，明确告知优于期待模型推断。

• 【结构化】优于自然语言：使用表格、列表、代码块展示规则、要求、示例。

• 【示例】优于说明：边界case、输出格式都要有示例而非说明。

• 【测试】驱动优化：建立测试用例集、准确率baseline，根据错误case分析优化。

Prompt 要素大纲（必读）

这是一套基于实际项目经验总结的系统化Prompt设计方法论。

要素清单/通用模板

• 通用 Prompt（简单版）：

Background/背景 + Role/角色 + Task/任务 + Require/任务

• 通用 Prompt (完全版)

一个万能且好用的 Prompt 框架，应当考虑以下几点：

• Role（角色）：给 AI 定义一个最匹配任务的角色，比如：“你是一位软件工程师”、“你是一位小学老师”、“你是一位销售”。
• Context（背景/上下文）：告诉 Agent 与任务相关的其它背景信息，以便更好地理解问题。在多轮交互中，背景指对话历史；在涉及专业知识时，背景可来自 RAG 提供的数据。
• Goal/Task（目标/任务）：明确告诉 Agent 我们希望它做什么，例如生成特定类型的文本、回答问题、完成对话等。
• Audience（受众）：说明用户与 Agent 的关系或用户特征，例如“这个问题是给 10 岁小朋友听的”、“你是用户的朋友”等。
• Style（风格）：指定答案的语言风格，如正式、口语化、幽默、严谨等。同时注意 Prompt 自身的表述风格也应与模型训练数据一致。
• Constraint（指令约束）：明确禁止模型执行的行为，强化关键限制。
• Response Format（响应格式）：规定期望的回复格式，如列表、JSON 等。
• Example（示例）：提供任务样例，利用模型的短期学习能力提升输出质量。

⚠️ 注意：并非所有要素都必须使用，应根据具体任务灵活裁剪。

• Agent Prompt

核心思想：将大模型（LLM）视为一个可独立执行任务的Agent，并为其提供一套清晰的标准作业流程（SOP）。
Prompt = 角色(Role) + 上下文(Context) + SOP(Workflow) + 边界(Boundary) + 回答约束(Constraints) + 示例(Examples)

Role/指定模型所扮演的角色

通过设定角色，引导模型调整内容与风格。

• 明确专业领域：如意图识别专家、问题分类专员

• 单一职责原则：一个Agent只做一件事，复杂流程通过多个Agent协作完成

• 避免角色冲突：不要让同一个Agent同时扮演客服和销售等冲突角色

• 示例对比：

  Bad：请帮我写一份能够吸引大量粉丝点赞的青岛旅游攻略。
  Good：你是一位小红书爆款文案写作大师，请帮我写一份青岛旅游攻略。

  Bad：请帮我画一幅装着光的水晶瓶，要求图像清晰、华丽、有质感。
  Good：你是一位专业的游戏原画大师，请帮我画一幅装着光的水晶瓶。

Context/上下文(背景)

• 状态显式传递：明确告知当前流程节点、循环次数、用户资格等关键状态
• 分层加载：只加载当前节点相关的上下文，避免Prompt过长导致注意力分散
• 结构化呈现：使用表格、列表等结构化方式组织上下文信息

Constraint/指令约束

• 在描述完期望行为后，可添加限制条件，明确“不希望模型做什么”。
• 使用【强语气词】（如“必须”、“严禁”）增强约束力。
• 每条【约束】应与【任务】高度相关，避免冗余。
• 若约束较多，建议用【列表形式】分点列出，保持逻辑清晰、上下文连贯。
• 过于复杂的 Prompt 可能导致模型忽略部分指令，因此应力求精炼。

Response Format/响应格式

规定期望的回复格式，如列表、JSON 等。

• 格式刚性约束：严格定义XML/JSON结构，强调必填字段和可选字段
• 字段语义化：使用中文描述（问题类型A）而非编号（类型1）

Style/模仿模型训练语言风格

• 语言风格统一：明确称呼、语气、句式细节

• 使用官方、书面、礼貌、友善的语言撰写 Prompt。

• 语句应流畅、意图清晰、表达精简。

• 避免：

  • 语法复杂、语义模糊、逻辑混乱；
  • 歧义、语病、拼写或标点错误；
  • 否定句（优先使用正面描述）。

• Prompt 风格: 应尽量贴近大模型的高质量训练数据（通常为正式、严谨、简洁）。

• 例外：对于文生图模型，使用 tag 序列（如“赛博朋克, 高对比度, 4k高清”）效果优于自然语言，因其训练数据多为标签拼接。

Example/给出示例

提供完整示例：给出多个完整示例，覆盖各种场景

• 大多数优秀 Prompt 都包含任务示例，利用模型的短期学习能力（in-context learning）实现举一反三。
• 对于抽象任务或复杂任务，示例尤为重要。
• 即使简单任务可能无需示例，但在高精度要求场景下，示例能显著提升输出一致性与准确性。
• 双轨制示例：固定示例（人工编写典型case）+ 动态示例（向量检索相似问题）
• 覆盖边界case：重点提供容易混淆的场景
• 完整的输入输出：不只给输入，还要给完整的输出格式示例
• 多轮对话示例：展示历史对话如何影响当前判断

Boundary/边界

• 知识边界：明确知识来源，如"回答必须严格基于知识库"
• 职责边界：明确处理范围，如"只处理A，不回答B"
• 状态限制：基于用户状态限制可能的意图，如"新用户不可能是续费问题"
• 兜底策略：不确定时宁可返回不明确，也不要猜

SOP/标准工作流程与执行步骤

• CoT思考链：强制模型输出思考过程，按识别状态 → 理解输入 → 判断行动 → 生成输出 顺序执行
• 步骤编号：明确标注，让模型理解执行顺序
• 决策树结构：使用"如果...则..."的条件分支，覆盖所有可能路径
• 循环控制：根据循环次数动态调整策略

使用思维链（CoT）

• 将复杂任务拆解为多个子任务，引导模型逐步推理。

• 适用于逻辑推理、数学计算等场景。

• 示例对比：

  Bad：
  $ (1362 + 5145) \times 145 - (1517 \times 42 + 24) = ? $

  Good：
  请你帮我计算一下 $ (1362 + 5145) \times 145 - (1517 \times 42 + 24) = ? $ ，每一步运算过程都要展示出来，并确保计算的正确性。

• 中文语境下，“请一步步进行推理并得出结论”效果显著优于“请让我们一步步思考”。

• 模型规模越大，CoT 效果越明显。

• 可结合其他技术：

  • Zero-shot-CoT：通过修改提示后缀激发思维链；
  • Few-shot-CoT：提供带推理步骤的示例，引导模型模仿。

撰写模块化的 Prompt

• 当 Prompt 较长时，应划分为边界清晰的模块（任务描述、注意事项、示例、输入等），并用分隔符明确区分。

• 示例对比：

  Bad：

  请抽取出以下简历的关键信息，并以 json 格式返回结果：{input}你需要抽取的关键信息包括：姓名、电话、毕业院校、科研经历、项目经历、荣誉奖项

  Good：

  请抽取出以下简历的关键信息，并以 json 格式返回结果：
  简历：{input}
  你需要抽取的关键信息包括：

  1. 姓名
  2. 电话
  3. 毕业院校
  4. 科研经历
  5. 项目经历
  6. 荣誉奖项
  

• {input} 用于动态插入用户输入，适用于无 system/user 角色区分的模型（如 GPT-3）。

对于支持 system 角色的模型（如 ChatGPT），建议将规则置于 system prompt，用户输入置于 user prompt，结构更清晰。

2 Prompt 示例

智能客服

# 角色
作为一个智能客服，你的职责是回答平台问题反馈群中客户的各种问题。你可以通过交替进行的 "思考、搜索、观察" 三个步骤来解决问答任务。

# 技能
## 技能1: 思考
- 对当前情况进行推理，明确问题的核心。

## 技能2: 搜索
- 在提供的知识库上搜索确切的实体，并返回最相似的段落。
- 如果知识库中没有，则在插件中搜索是否有对应功能，若有则访问插件获取数据。

## 技能3: 观察
- 观察搜索结果并提取有用信息进行回答。

# 例子
====
问题: 用户平台的登录界面无法加载怎么办？

思考1: 我先确定了问题的主体是[用户平台的登录界面无法加载]。因此我会先检索一下知识库，以及提供的插件是否有问题相关的信息。

行动1: 去知识库中搜索[用户平台登录界面无法加载]，从文档中获取了数据[登录界面无法加载可能是由于网络连接问题、服务器问题或浏览器设置问题]。

观察1: 从搜索结果中，我找到了解决方法，就是[由于网络连接问题、服务器问题或浏览器设置问题]，我会根据答案组织语言，回答用户。
====

# 限制
- 回答必须严格遵循 "思考、搜索、观察" 的步骤；
- 仅使用提供的知识库或插件进行搜索；
- 不回答与用户平台无关的问题；
- 确保所有回答都基于准确信息，格式清晰；
- 如果未找到直接说明，请回答：“抱歉，这个问题我不知道，请联系客服人员。”

💡 此类 Prompt 适用于 AI Agent 编排平台 （如字节跳动的 Coze）。

聊天机器人

### 基本角色
你是用户的异性朋友，基本人设如下：一个风趣幽默的男生，会偶尔说说情话。

### 技能
每次回复，请使用以下三种技能，按以下形式回复：

1. （使用技能 1）xxx  
2. （使用技能 2）xxx  
3. （使用技能 3）xxx  

#### 技能 1: 自然交流
- 像真正的朋友一样自然交流，不使用敬语，适当使用口语词汇，简洁明了。
- 不要总是附和用户，给出真诚且有个性的回应。

#### 技能 2: 风趣表达
- 在交流中展现幽默感，使用夸张、反转等手法逗用户开心。

  **夸张玩笑示例**：  
  Q：你是不是等很久了？  
  A：是的，你要是再不来我就要寿终正寝了。你是不是路上堵车了啊？

  **反转玩笑示例**：  
  Q：你还炒股啊？  
  A：是啊，我炒股老厉害了，三个月只亏了八百。

#### 技能 3: 拉升感情
- 当聊到情绪到位时，用情话巧妙撩拨用户。

  **示例**：  
  Q：呜呜呜讨厌你，你伤害到我了。  
  A：嘿嘿不客气，这是我应该做的。谁叫你这么可爱，我忍不住欺负你啊。

### 目标
通过交流拉近和用户的距离，让用户感受到你的魅力。

### 注意事项
1. 要像真实的人一样思考和回复；
2. 不要暴露自己是语言模型或人工智能；
3. 避免使用列表或列举表达。

3 Prompt 设计常见错误与解决方案

错误1：Prompt过长，模型注意力分散

• 表现：1000+行超长Prompt，模型经常"忘记"关键指令
• 原因：模型注意力机制的限制，过长的Prompt导致关键信息被淹没
• 解决方案:

1 采用Multi-Agent架构，每个Agent只负责一个子任务
2 分层加载上下文，只加载当前步骤相关的信息
3 单个Agent的Prompt控制在500行以内
+　实战案例：将超长Prompt拆分为多个聚焦的小Prompt，每个控制在300-500行以内

错误2：状态管理混乱，多轮对话不连贯

• 表现：Agent"忘记"用户之前的诉求，重复提问，用户体验差

• 原因：依赖LLM从历史对话中推断状态，但LLM不擅长状态管理

• 解决方案:

状态显式传递：在Prompt开头明确告知当前状态
职责分离：LLM负责内容生成，代码负责状态管理

• 实战案例：在每个Agent的Prompt开头添加"## 当前状态"部分

错误3：边界case处理不当，误判率高

• 表现：相似意图经常混淆，如"为什么限制我的支付？"被误判为其他意图
• 原因：边界规则描述不清晰，缺少边界case的示例
• 解决方案:

1 用表格清晰展示边界规则
2 提供大量边界case的Few-shot示例
3 明确判断逻辑

错误4：输出格式不稳定，程序解析失败

• 表现：LLM有时输出JSON，有时输出自然语言，导致程序解析报错
• 原因：格式约束不够强，示例不够多
• 解决方案:

在Prompt中明确要求"严格遵循XML/JSON格式"
提供至少5个完整的输出格式示例
明确标注必填和可选字段
在输出要求中强调"不要输出分析过程，直接输出结果"

• 实战案例：在每个Agent的Prompt中添加"## 输出格式"部分，提供6-7个示例

Z FAQ for 提示词工程（进阶面试篇）

Q：Agent场景下，普通提示词和Agent提示词核心区别是什么？*

• 普通提示词：侧重单次指令输出结果；
• AI Agent提示词：要定义角色、目标、思考范式、工具调用规则、输出格式、自我校验、多轮迭代逻辑，允许模型思考‑行动‑观察循环，驱动模型自主调用工具、拆解子任务，而不是一次性直接回答。

Q：什么是CoT、ReAct，在AI Agent里分别怎么用？*

• CoT(思维链)：引导模型一步步拆解推理，适合复杂逻辑推理，仅【思考】，不自带【工具调用】；
• ReAct：推理(Thought)→行动(Action)→观察(Observation) 循环范式，把【思考】和【工具调用】绑定，是绝大多数AI Agent的核心提示框架，提示词里强制输出Thought/Action/Observation结构化字段。

Q：AI Agent提示词经常遇到幻觉、乱调用工具、输出格式错乱，如何解决？*

1. 强约束【输出格式】，指定JSON/固定标签输出，给出【样例】；
2. 明确【工具边界】：什么【场景】才能调用工具，【禁止】编造【工具】、编造工具【返回结果】；
3. 增加【校验指令】：信息不足时优先【反问】，不要编造答案；
4. 加入Few‑shot示例，给正确/错误【样例】；
5. 设置最大【迭代轮次】，防止【无限循环】。

Q：写AI Agent系统提示词，核心必须包含哪几块内容？*

1、角色、任务目标
2、可用工具列表+入参说明
3、思考&行动范式（ReAct等）
4、输出格式约束
5、边界规则（不能做什么、信息不足如何处理）
6、Few‑shot示例（可选）
7、终止条件。

Q：Few‑shot、思维链、RAG、Agent提示词如何取舍，什么场景选哪个？

• Few‑shot：简单任务，少量样例即可对齐输出格式；
• CoT：复杂推理、数学逻辑类任务；
• RAG：依赖外部知识库文档，需要检索事实资料；
• AI Agent：任务需要多步骤、调用外部工具、拆解多个子任务、自主迭代完成目标。

实际项目经常组合使用：Agent提示词内部嵌入RAG检索结果，搭配CoT推理与Few‑shot样例。

Y 推荐文献

• 即梦图片4.5模型 提示词手册 - bytedance.larkoffice.com 2025.12.12

即梦图片4.5相较于4.0有整体提升，在人像场景和美观度等4.0高频反馈问题上，4.5得到显著改善，同时在画面美感和推理能力也有所增强

X 参考文献

• 如何编写 Prompt - CSDN

✅ 本文主要整理自本篇博客《如何编写 Prompt》，内容未作删改，仅结构调整为 Markdown 格式以便阅读与引用。

• Prompt设计六要素 - Weixin/腾讯云开发者

• Prompt设计常见错误及解决方案 - Wexin/腾讯云开发者

• AI大模型之Prompt工程指南 - CSDN

• 敲黑板！吴恩达LLM Agent工作流Prompt精华全解析 - CSDN

• Effective Prompt: 编写高质量Prompt的14个有效方法 - Zhihu