Prompt：作为模型推理与生成的输入上下文，用于提供任务指令、约束条件、背景信息与期望输出格式，从而引导模型产生目标响应。
Prompt四要素框架
|---------------|------------------|----------------|
| 要素 | 作用 | 常见表述 |
| Role（角色） | 告诉模型该用哪个领域的知识和语气 | "你是一位？？？" |
| Task（任务） | 说明要完成什么动作 | "请完成以下内容：？？" |
| Contxext（上下文） | 补充和任务相关的背景 | "当前？？，？？" |
| Format（格式） | 规定输出长什么样 | "输出为？？格式，包含？？" |
Prompt调试
|------|---------------------------------------------|
| 步骤 | 做法 |
| 准备样例 | 选10-30条代表性输入，覆盖正常、边缘、异常场景 |
| 固定变量 | 固定模型、Temperature、System Prompt 和检索材料，避免变量混杂 |
| 记录指标 | 看格式合规率、事实错误率、字段缺失率、人工修改次数 |
| 单点修改 | 每次只改一个prompt变量 |
| 回归测试 | 上线后保留失败样例，定期回放，防止新规则修一坏三 |
常用提示词技巧
1.角色扮演
给模型一个具体身份，回答会更贴近对应领域。角色越具体，通常越稳。
2.思维链（Chain-of-Thought，CoT）
在普通模型上，要求模型给出简要推理过程，可能提升复杂任务稳定性；但在 reasoning model 上，不应假设能看到完整内部推理链。工程实践里更建议要求模型输出"关键依据、检查步骤、最终结论"，而不是暴露完整草稿。
调试时看检查点也够用：你要知道它用了哪些变量、引用了哪些证据、在哪一步可能拐错弯，而不是把所有中间念头都打印出来。
| CoT 类型名称 | 具体例子 |
|---|---|
| Few-shot CoT | 在 prompt 中给出 2--3 个"数学题 + 分步推理 + 答案"的示例，再让模型解一道新数学题。 |
| Zero-shot CoT | 在问题后加入"请逐步分析后给出答案"，例如：一个商品原价 200 元，打 8 折后再减 20 元，最终价格是多少？请逐步分析。 |
| Self-Consistency CoT | 让模型对同一道逻辑题生成多条不同推理路径，再选择出现频率最高或最一致的答案。 |
| Guided CoT / 引导式 CoT | 要求模型按固定步骤回答，例如：先识别条件 → 再列出公式 → 再计算 → 最后验证答案。 |
| Least-to-Most CoT | 面对复杂任务时，先拆成简单子问题，例如先判断每个条件含义，再组合条件求最终答案。 |
| Plan-and-Solve CoT | 先让模型制定解题计划，例如：先列出解题步骤，再按照步骤完成计算并给出结论。 |
| Tree-of-Thought（ToT） | 对一道开放题生成多个候选方案，如 A、B、C 三种解法，再分别评估优缺点并选择最优方案。 |
| Graph-of-Thought（GoT） | 将多个推理节点组织成图结构，例如在商业分析中同时考虑用户、成本、市场、风险等因素，并合并得出结论。 |
| Program-of-Thought（PoT） | 让模型把计算问题转化为代码执行，例如用 Python 计算一组销售数据的均值、方差和趋势。 |
| ReAct（Reasoning + Acting） | 模型一边推理一边调用工具，例如先判断需要实时信息，再调用搜索工具查询天气，最后基于结果给出出行建议。 |
3.少样本学习
复杂任务或者格式严格的任务，给1~3个示例，示例会告诉模型输出应该长什么样。示例尽量和真实任务同类型，能覆盖边缘情况，格式要足够清楚。必要时可以用 XML 标签包起来。
4.任务分解
如果任务复杂，可以拆解为几个小任务让模型一步一步做。
静态分解适合流程固定的任务。任务开始前就把步骤规划好。
动态分解适合探索性任务。执行过程中根据当前结果，再决定下一步做什么。
5.结构化输出
如果希望模型按固定格式输出，prompt里要把schema说清楚。
Schema：是一种用于描述数据结构与格式约束的规范，定义字段名称、数据类型、必填规则、取值限制、嵌套关系等，以保证数据可验证、可解析、可交换。
6.XML标签与预填充
XML 标签：是在 prompt 中用类似 <instruction>...</instruction>、<context>...</context>、<output_format>...</output_format> 的标签包裹不同信息模块，帮助模型区分指令、背景、输入数据和输出要求，从而提升上下文解析的准确性与结构稳定性。
预填充（Prefill）：指在模型开始生成前，提前给出输出的开头、格式框架或部分内容，引导模型沿着指定结构继续生成，降低跑题和格式漂移的概率。
复杂场景处理
长文本处理:
1.把文档放在 Query 之前。先给模型材料，再把问题和指令放到后面，通常效果更稳。多文档任务可以用 XML 标签做结构化。
2.先引用，再分析。长文档任务里，可以先让模型提取相关原文，再基于引用做判断。
减少幻觉：
1.在 Prompt 里明确允许模型承认不知道。
2.涉及长文档时，可以要求模型先提取逐字引用，再根据引用分析。
3.做 Best-of-N 验证（多次采样一致性检查）。
4.做迭代验证，把模型上一轮输出作为下一轮输入，让它检查事实、补充证据或者修正表述。
提高输出一致性：
使用 JSON Schema 或 XML Schema 直接定义结构。
预填充，比如需要 JSON，就先给一个 {。需要 XML，就先给 <response>。
链式提示设计：
链式提示（Prompt Chaining）就是把一个大任务拆成多条 Prompt，每条 Prompt 只处理一个子任务。设计时记住几条就行：任务要拆小，前一步输出要能传给下一步，每一步只做一件事，哪一步出错就单独调哪一步。链式提示最大的价值是方便定位问题。
企业级安全实践
|------------------|------------------------|--------------------------|
| 类型 | 常见来源 | 主要目标 |
| Prompt Injection | 外部内容，比如网页、邮件、文档、工具返回结果 | 覆盖引用指令，诱导Agent调错工具或泄露上下文 |
| Jailbreak | 用户直接输入的对抗性指令 | 绕过模型安全策略，让模型回答本不应该回答的内容 |
Prompt 注入（Prompt Injection）指的是攻击者通过构造外部输入，试图覆盖或篡改 Agent 原本的系统指令。
Jailbreak（越狱提示）：指通过特殊 prompt 诱导模型绕过系统指令、安全策略或行为边界，使其生成本应被限制、拒绝或不符合规范的内容。
prompt注入防护
| 防护层级 | 术语说明 | 核心作用 |
|---|---|---|
| 输入层防护（Input Sanitization / Prompt Injection Detection） | 对用户输入、网页内容、文档内容等外部文本进行清洗、分类、风险检测与恶意指令识别。 | 在信息进入模型前识别"忽略之前指令""泄露系统提示"等注入内容。 |
| 上下文层防护（Context Isolation / Instruction Hierarchy） | 将系统指令、开发者指令、用户输入、外部检索内容进行权限分层与语义隔离，防止低优先级内容覆盖高优先级指令。 | 保证模型遵循系统指令优先级，不被外部内容篡改行为边界。 |
| 输出层防护（Output Validation / Policy Enforcement） | 对模型输出进行格式校验、安全审查、敏感信息过滤与工具调用权限控制。 | 防止模型输出违规内容、泄露隐私，或执行危险操作。 |
越狱与提示词注入缓解
越狱和提示词注入通常要组合处理。输入进来前，先做无害性筛选。对明显的越狱模式、已知攻击语句、危险工具调用意图做过滤。进入执行阶段后，再配合权限控制、沙箱隔离、人工审批。这里不能指望一条 Prompt 解决所有问题。安全要靠多层策略叠起来。
提示词路由（Prompt Routing）：指根据用户输入的意图、任务类型、复杂度或上下文特征，将请求自动分发到不同的 prompt 模板、模型、工具链或 Agent 流程，以提升响应准确性、效率与可控性。